The Joys of Configuration!

At the moment we're working on a fairly BIG Drupal 6-Drupal 7 migration for the Twin Cities Daily Planet.

As part of that I am attempting to get the rather unwieldy site completely under code and configuration management.  The code part is well understood (well, at least by others) and semi working for us, so I'm not going to talk about the issues of getting sites under control of git - lots of others have written about that.  I am going to talk about the configuration management part.

I have always been more than a little disheartened by the use of Features to control all those icky parts of the site that are held in the database rather than code.  For one thing, that's not really what Features was intended to do - it was intended to pile up a single hunk of site functionality and turn it into a feature.  This I can dig, but from a general site administration viewpoint it is a pretty awkward tool.   So I was really excited to realize that this whole configuration issue is being seriously worked on in Drupal 8, and that all of those messy things in the database will now get written out into flat config files that can actually be code managed.  I was even MORE excited to see a few  months back that there is now a configuration module for Drupal 7. This looked to me like it was exactly what the Doctor. ordered.   But as often happens, the drug seems to have some side effects.

Drupal time in the midwest

It's that time of year again, when Drupal camps spring up around the midwest.  I'm happy to say that Cruiskeen Consulting is sponsoring two different Drupal camps in the area, and that I am presenting at Drupal Camp Wisconsin tomorrow.

Drupal Camp Wisconsin is taking place this Friday and Saturday (July 25 and 26). Drupal Camp Wisconsin is always great fun, with good talks, a nice party, and a great opportunity to meet with other Drupalistas.  And it's always free.  More information about Drupal Camp Wisconsin can be found at http://drupalcampwi.com/ .  I will be presenting a talk tomorrow about Drupal Migrate for the non-coder. 

Regression in Drupal 7.29 can lead to data loss - 7.30 out and fixes it

Update --- Drupal 7.30 was released yesterday, and fixes the regression in 7.29 .   So -- If you've not updated to 7.29, update to 7.30.

 

Thanks to Acquia for the heads-up.   There's a serious reported regression in Drupal 7.29 that can lead to data loss.

Because of this, we are at this time not doing automatic Drupal upgrades for clients who are on maintenance and are running the Drupal 7 branch. We're waiting until this problem is more fully understood and, we hope,  a patch or new releasse is available. We think the potential security risk of not doing the upgrade for a few days is less than the risk of clients destroying data on their sites. We want to at least understand the issue better.

We ARE in the process of doing Drupal 6 upgrades and filefield module upgrades for maintenance service customers, however.

A simple rule to block some Drupal spammers

We've all been there - your Drupal site is being overwhelmed by people and robots trying to post to your site, or trying to create accounts.  These attempts can really hammer your web server, and it's the sort of traffic that isn't going to be helped any by the thirty-five different kinds of caching you have set up on your site.  

We've seen thsi recently get much worse with some of our clients, so we set out to do something about it that's simple and reliable. We currently use fail2ban on all of our servers to try to cut back on the attempts at breaking in to the servers through ssh, ftp, etc.   Fail2ban reads your server logs, and looks for matching patterns.  If a pattern matches, the server can carry out any number of activities, including temporarily banning an IP address through iptables.  We thought "why not use fail2ban to block bots that are hammering the server?"  So - we came up with this simple plan.

On our servers that have been having particular difficulty, we have implemented a couple of fail2ban rules designed to protect the web server from incoming spam traffic and email address crawlers.  The email address crawler rule is part of the fail2ban package, and we just enabled it.  

Drupal 6 Extended Support Announcement

Three has been a fair amount of question about Drupal 6 and when support for Drupal 6 will end (there is a huge backlog of Drupal 6 sites that have for one reason or another not transitioned to 7).  Partly in recognition of this, the Drupal Association has announced that there will be a 3-month extension of Drupal 6 support after Drupal 8 ends ..  It also seems likely that a couple of commercial companies will provide Drupal 6 support service after that at least for security updates. This has happened in the past for older legacy Drupal releases, though I must say that I think the end result has had mixed success.

You may want to read the official announcement at https://drupal.org/d6-lts-support

Yet Another OpenSSL issue

So -- it's time for another OpenSSL upgrade on our servers.  There's another fairly serious security flaw in recent OpenSSL releases, which was found due to the increased scrutiny of the OpenSSL software.  Again, this only affects the recent 1.0 versions of OpenSSL, so in our case it's again the servers running CentOS 6.  We have not yet started this upgrade since we are waiting for the update to go out to our CentOS update servers --- but it should start to roll out later this afternoon.

Drupal 7.28 out

Drupal 7.28 was just released.  It's a bug-fix release, so does not correct any security issues.   There are multiple bug fixes, the biggest and scariest one of which is that they have finally fixed the oddity in both Drupal 6 and 7 where the update module often cannot actually query for updates all on its own.  This is mostly a Drupal 7 issue, and is what happens that causes your site to not reliably report updates unless you go in and check for them manually.  The BAD news here is that if you've got your site set up to just use the built-in "Poorman's Cron" implementation in Drupal 7, you'll find that once in a while one of your users will go to the site and have a page wait for a really long time while running the update check.  In general best policy here is to run cron explicitly rather than use the built-in cron.  This will avoid those really long page loads you'll see when a user going to your site starts up a cron run.

CERT -- Stop Using Internet Explorer till it's fixed!

This is really unusual.  Today CERT suggested that everyone just plain stop using Internet Explorer until such time that Microsoft fixes the current Zero-Day exploit against it.  This rarely happens, but it's a particularly egregious bug, and it's on the worlds most common OS platform.  I think the thing that's particularly interesting here is that it's not ever going to get fixed for Windows XP users since they are now completely out of support.  So I think the lesson here is:

1.  If you're still using XP it's time to stop.  Got a low-power old machine?  Convert to one of the small-system Linux distributions.  Forced to use it at work?  Well, that's really too bad.

2.  Don't use IE until Microsoft fixes it.  Personally web developers around the world would probably thank you if you'd just stop using it, period. 

3.  Make sure you keep your OS up to date, including applications.

Drupal 6.31 and 7.27

New security releases of Drupal came out yesterday.  We are in the process of upgrading the sites that we have under maintenance contracts. This wil take a few days to get through all of the different sites. This is only a moderately concerning update and will only affect some sites depending on how they are configured.  In particular, this is likely to only affect sites that use multi-step or ajax forms that are exposed to anonymous users.  We will attempt to work our way through sites in the order of how vulnerable we believe they wil be to this bug.

Heartbleed Security Flaw

Many of you have undoubtedly been reading about the Hearbleed security issue with OpenSSL. Some of our servers were vulnerable to Heartbleed - notably our CentOS 6 servers.  The ones running CentOS 5 were not vulnerable because they are based on an older version of OpenSSL.  We upgraded the OpenSSL library on all of our vulnerable servers as soon as a patched version was available, and none of our servers are now vulnerable to this exploit.  We have re-keyed the secure certificates for our clients who were under maintenance contracts.  We would recommend that everyone go out and update your passwords on any web-based systems that may have been vulnerable to this exploit, including logins for email accounts.  If you are having any trouble with this on our systems, please let us know.

Please note that the administrative panel logins on our servers were not vulnerable to this exploit - but your logins through SSL on your own web sites were, possibly.  In any case, rotating passwords occasionally is always a good policy, and we would also recommend (as the Internet gets more and more lawless) that you think seriously about using a password system (we happen to like LastPass) to keep track of your passwords, allowing you to generate random passwords for sites, but to still keep track of them.  Last of all, we'd like to recommend that you think about implementing dual authorization on your important logins.  We are using Authy on some of our administration software to require that we not only have a password, but a random one-time key to log in to our servers. 

Pages

Subscribe to Cruiskeen Consulting LLC RSS