Roy Schestowitz's blog
TUX Machines has become an integral part of our life right here in this humble home. It's a rewarding experience but also a demanding experience. I personally write my articles in the lounge (which is no 'press room') and it requires many hours of digging and researching news. In Tux Machines, unlike in Techrights for example, it's mostly about finding news of high relevance and importance, and finding them fast! Timing counts. We don't want readers to waste their time wading/going through irrelevant, unimportant and out-of-date reports.
24/7 coverage of news is easy for us. Rianne works mostly at daytime, whereas I usually work at nights (customers are mostly government/public sector and they require 24/7 coverage). When Rianne is working I take over the responsibilities at Tux Machines and vice versa. We swap responsibilities like this when it comes to housework as well; we work out together when we are out of the house (also separately in terms of gym sections, e.g. cardiovascular/weights). This week we go to yoga classes as much as 5 times, but we usually just to Town for other facilities like pool, table tennis, sauna (men and women separately), gym, etc. This is our main escape from Tux Machines; given Wi-Fi (scarce coverage but definitely existent in Manchester City Centre), we sometimes update Tux Machines while out of the house as well.
The site forums are now open for participation and every registered member can add blog posts and push them to the front page (now that we've got the spam epidemic under control). Please do consider participating. This week, as in previous weeks, we are seeing a ~10% growth in traffic (week-to-week), perhaps owing to the slight redesign, loading speeds (Varnish cache), and very frequent updates. We check for news once in a few hours in order to keep abreast of breaking events.
Running Tux Machines will hopefully become more of a community effort over time. Anyone who is logged in can now submit stories. Unless this gets abused by spammers, we will keep it that way. █
Drupal's very own Mollom is a Free/Open Source (collaboratively-developed and freely-shared) software for battling script kiddies and fighting against SPAM. The past 2 weeks were difficult because spammers exploited the fact that we had opened up the site for registration/subscription (to leave comments). After exploring some options for dealing with the problem (spam making it to the front page even!) we found that Mollom was good enough to eliminate almost 100% of all of spam (so far). Hence, for the time being, it seems safe to say now that we beat the script kiddies. Thanks, Mollom! █
Tux Machines behind Varnish cache proxy
Summary: Tux Machines growth and a note regarding SPAM prevention after a week or so of experiments
Here are the first four weeks' log sizes, plotted with LibreOffice and demonstrating week-to-week growth since the site's nameservers changed and the server moved to CoPilotCo. After 4 weeks all logs get deleted (
logrotate) to ensure privacy through lack of data retention (except short term in case of DDOS).
Script kiddies can't get their way
Summary: Script kiddies made it impractical to manage comments and forum posts; we are trying to tackle this issue today
IN ANOTHER attempt to restore user registrations, this time on the new server which has just been configured for mail, we are enabling anyone to quickly self-register (takes less than a minute and requires no verification), then immediately post comments, forum posts, etc.
Summary: Recent changes at Tux Machines, in just a nutshell
INSPIRED in part by Slashdot, we recently added topical icons to submissions, applying these changes retroactively to over 50,000 older pages. The idea was, this can improve orientation by helping to quickly associate text with topics. More minor modifications were made as well, some textual and some layout related. They are subtle but they can be seen. After receiving feedback regrading icons size we made further modifications. Regarding social media buttons, some of the ones we initially found were unbelievably privacy-infringing (allowing Google, Facebook, Twitter etc. to see visitors of this site), so we disabled them immediately and replaced them with static buttons. Right now we can assure that whenever loading pages in this Web site nothing except our security-aware network gets contacted. We share no data about visitors (with anyone) and Apache logs get shredded for good after a few weeks, leaving sufficient trail just in case of attacks on the site, which would merit investigation. Log rotation is similarly privacy-respecting at the cache level, which leads to the following point.
Today, after the above changes had been made and stability attained (there were some network disruptions yesterday), we also updated Drupal, ensuring it is secure and fully up to date (the latest minor bugfix release is a month old). There is still an issue with Varnish and until we tackle this issue users who are not logged in might be getting error pages. One way to overcome this is to append "?something" to the URL requested. This bypasses the Varnish cache until we finish our investigation of this issue and resolve it for good. █
Update: The issue with Varnish turns out to be a conflict between two caching layers. It's fixed now. If you spot an issue, still, please let us know.
Update #2: Yesterday we identified another issue and soon thereafter fixed it. After Twitter syndication had failed we realised that RSS feeds were not standards-compliant, due to a blank line at the start of each generated page in Drupal. This is a common issue and it is a nightmare to debug (requires a complete code review with help of GNU utilities like grep). After 4 hours of investigation I found the culprit and fixed the coding error. RSS feeds are back.
VARNISH is valuable for a number of reasons, including security, privacy, and performance. I first used it around 2009 when another site of mine had repeatedly come under DDOS attacks. Using Varnish means that requests for pages usually come from the same IP address (the cache proxy), if at all. Much of the time visitors get served static (cached) pages transparently and quickly. The downside is, this interferes with statistics (the Apache server does not even see all requests) and it is not compatible with modules like polls, where each IP addressed is allowed just one vote.
During the server/site migration we tried to preserve as many of the features as we could. There was a transition from old Debian to new CentOS and the new architecture is quite different (still 2 CPU cores but with more RAM, a virtual container, and resilience owing to proxies/redundancy). Thanks to those who suggested workarounds. We have looked at some of them, but without losing on performance there is no way to keep meaningful statistics. These statistics have been disabled. Not even we, with direct access to the server and the CMS, have access to meaningful statistics.
We are going to try to focus on high quality selection of news, not on numbers. █
Yesterday, following a mostly successful migration (there are still some impending fixes to
.htaccess), slight changes were applied. For regular readers of the site, here they are summarised: