Russell Coker: WordPress Spam Users
Just over a year ago I configured my blog to only allow signed in users to comment to reduce spam [1]. This has stopped all spam comments, it was even more successful than expected but spammers keep registering accounts. I ve now got almost 5000 spam accounts, an average of more than 10 per day. I don t know why they keep creating them without trying to enter comments. At first I thought that they were trying to assemble a lot of accounts for a deluge of comment spam but that hasn t happened.
There are some WordPress plugins for bulk deletion of users but I couldn t find one with support for delete all users who haven t submitted a comment . So I do it a page at a time, but of course I don t want to do it 100 at a time so I used the below SQL to change it to 400 at a time. I initially tried larger numbers like 2000 but got Chrome timeouts when trying to click the check-box to select all users. From experimenting it seems that the time taken to check that is worse than linear. Doing it for 2000 users is obviously much more than 5* the duration of doing it for 400. 800 users was one attempt which resulted in it being possible to select them all but then it gave an error about the URL being too long when it came to actually delete them. After a binary search I found that 450 was too many but 400 worked. So now it s 12 operations to delete all the spam accounts. Each bulk delete operation is 5 GUI operations so it s 60 operations to delete 15 months of spam users. This is annoying, but less than the other problems of spam.
UPDATE wp_usermeta SET meta_value = 400 WHERE user_id = 2 AND meta_key = 'users_per_page';Deleting the spam users reduced the size of the backup (zstd -9 of a mysql dump) for my blog by 6.5%. Then changing from zstd -9 to -19 reduced it by another 13%. After realising this difference I configured all my mysql backups to be compressed with zstd -19, this will make a difference on the system with over 30G of zstd compressed mysql backups.
Like each month, have a look at the work funded by 
Version 0.0.23 of 
Our Debian User Group met on September 27th for our first meeting
since our summer hiatus. As always, it was fun and productive!
Here's what we did:
pollo:
Some of us ended up grabbing a drink after the event at 
We had 886 responses with status code 200 and 64 connections closed.
The backend terminated 64 connections while the load balancer still had
active requests directed to it.
Let's change the Load Balancer 
Great! Now all the requests worked.
This is a common issue, not specific to Envoy Proxy or the setup
shown earlier. Major cloud providers have all documented it.
Even thought the success rate is 100%, the status code distribution
show some responses with status code 503. This is the case where is not
that obvious that the problem is related to idle timeout.
However, it's clear when we look the Envoy access logs:
Key Takeaways:
About 90% of my Debian contributions this month were
A new version 0.3.5 of the 
Another short status update of what happened on my side last
month. Nothing stands out too much, I enjoyed doing the OSK changes
the most as that helped to improve the typing experience further. Also
doing a small bit of kernel work again was fun (still need to figure out
the 6mq's touch controller repsonsiveness though).
See below for details on the above and more:
A tiniest of tiny violins micro maintenance release 0.0.4 of our