Mostly about my amusement
Get your latest copy of Firefox 3.0 here. Thursday openSUSE 11 comes out. It’s like an open source cosmic alignment of the planets.
I’ve avoided the openSUSE 11 beta only because I don’t have the time. I’ve been kicking around Firefox 3.0 RC version and a couple of days ago, even Greasemonkey got updated for version 3.
Over a week ago I complained about WordPress users crying security wolf and not being able to recover their blog when the “Bad Thing(tm)” happens.
Since then a real brawl developed on the support forum that could be summed up like so:
This discussion was just plain nuts and went around in circles. Complaining about a problem without providing any proof and then getting all pissy about it is totally useless. It is entirely possible that such an exploit exists and many people replied so. But without any providing data other than saying “I can assure you that the hack occurs via XMLRPC”, then everyone’s time gets wasted.
Fortunately, Donncha provided a page that covers the issue succinctly and today he added another post on setting up aide. His two posts are good and anyone considering monitoring their WordPress files for modification should give this a try.
Aide will let you see if your installation files and directories have been tampered with. It won’t protect you against HTTP POSTS or database attacks but it’s very good if someone succeeds in modifying your files.
There are ways to log what’s being sent via an HTTP POST and examine that information; if (or even when) I get hacked, I’ll try to start looking at that data. MYSQL database monitoring, that could be interesting but for now I’m not aware of a good tool to do that.
On my OpenSuSE installation, installing aide is simple. As root run
zypper install aide aide --init mv /var/lib/aide/aide.db.new /var/lib/aide/aide.db aide --check cp /usr/share/doc/packages/aide/examples/etc/cron.daily/aide.sh /etc/cron.daily/
All of which I just did. I ran the check option to make sure I did not create any issues with the aide.conf file. I’ll play with the aide.conf file and see what kind of output I get when the daily cron job gets run. If I add and modify files and I set it up correctly then I should see that in daily cron job’s output.
Update: this worked but in /etc/aide.conf change the line verbose=1 to verbose=5. That will get you a useful output of which files and directories changed.
If you are not running the latest version of WordPress and you get hacked, don’t go to the WordPress forum and tell the world. Odds are you invited the disaster yourself.
When WordPress 2.5 came out I was disappointed to find that the old version 2.3.x was basically abandoned. There would be no more planned patches for 2.3.x just the current 2.5. The 2.0.x branch would continue to be supported as part of the commitment to the Debian version model.
So as of right now versions 2.0.11 and 2.5.1 are supported. If you are running 2.2.x, 2.3.x, 2.5(.0), or any other version then you run the risk of being exploited.
So why do users continue to use the old versions? Everyday there are posts in the support forum that (so far) always deals with someone’s blog getting hacked and they are not using the current 2.5.1 version (as of this writing). Eventually someone writes “I’ve been hacked” and some other user writes “Is this a vulnerability of insert current version HERE?!? Why are the developers not doing SOMETHING?!”.
It’s like there is some axe to grind and the first one to find the axe gets 1000 gold points. The moderators usually show great patience; I’d get ticked if I were them. These users seriously should just avail themselves of WordPress.com and stop trying to self host a blog.
The freely available WordPress from WordPress.ORG is not commercially supported, and commercial support if often not that good anyway. So for anyone who is thinking about using WordPress.org’s software, they should be able to do the following by themselves.
Read this Codex article for backing up your WordPress installation.
WordPress uses two components. The easy one is the file system and backing that up should be trivial. I use a shell script that creates a tar.gz archive every night. Another cron job deletes backups that are older than 30 days. Why fill up my disk? The backups are not for historical use, just to get me back to the state I was 24 hours ago if need be. 30 days is too much but hey, disk space is cheap.
The mysql database is the other component. The same backup script also creates a text dump of my entire WordPress database. This copy gets gzipped and added to my file backup. The mysqldump command is your friend and should be used.
The Codex has a good article on how to restore your blog database here.
Making the best backups is pointless if you don’t know what to do with them when the “Bad Thing” happens. Take your backup and restore it to a WAMP or LAMP installation on your own PC. If you need a Windows Apache Mysql Php setup, use Google and install the one you feel comfortable with. In Linux just add the packages (See this link for Ubuntu).
Once you have the Apache web server, Mysql, and PHP running locally on your PC then start playing. Install WordPress locally, restore your backup and just change the name of your installation in wp-config.php to localhost and test. To adjust your local installation to run on your PC just add these two lines to the copy of the wp-config.php on your PC:
define('WP_SITEURL', 'http://localhost');
define('WP_HOME', 'http://localhost');
Then on your PC point your browser to http://localhost/ and test it. Beat it up; it’s a local copy on your PC. Go nuts on it and confirm that your posts, categories, tags, comments, etc. are all there. Anything on your PC that you mess up in WAMP or LAMP should be no big deal. Just start over if you get lost.
Play with it until you understand what you are doing, because when you DO lose your blog you’ll need to do this for real.
That sounds like a plan right? Some plugins don’t work with the latest and greatest version. If the version you are running is vulnerable to an exploit then you don’t need that plug in.
Security updates are the number one driver for minor number version releases such as 2.5 to 2.5.1. Yes, there are bugs but they usually are tolerable. Exploitable code is serious business and usually gets fixed quickly.
Once you are comfortable with upgrading and testing your local installation, upgrade your real blog. I personally keep good backups and know how to restore them so I never bother with this step.
If you know how to backup and restore your blog, then even if the upgrade is bad, you will be able to put it back the way it was before the upgrade.
My Ubuntu T40 laptop is “only MOSTLY dead”. The built in LCD display is too dark to read and I replaced it with a HP laptop running Vista Home Premium.
I feel slightly guilty about running Vista on it but it runs really well so ptthhhhppp. I put the T40 onto it’s docking station and hooked it up in the basement with the other equipment.
The upgrade was easy as usual. Just sudo su – and update-manager -d. It took a while to download the files but a reboot later and I’m running.
This new Ubuntu feels faster. It’s hard to really quantify that with old hardware, but it does. So far the only issue I have is that the spell checker in Firefox 3 beta 5 is broken sometimes (I had to use the one built into WordPress for this post).
It’s like a refined version of 7.10.
This happens often. I do something on my servers and six months later I try to rebuild from scratch what I did and wish I wrote it down. This is one of those blog posts.
I reviewed my Apache error logs and noticed that WordPress was tossing fatal PHP errors. I was pretty sure it was a particular plugin but I had made so many changes to Apache and PHP5 and I thought it would be easier to remove and re-install Apache and PHP5. So I switched my blog to my backup VPS, updated DNS and took apart my server.
That turned out to be a little painful and more work looking up how to set it up.
Removing the packages was simple. I just ran rpm -qa | egrep “php5|apache” to get the list of packages and created a small shell script to removed them. But I had forgotten how I had setup the virtual servers for more than one website. I wanted to avoid using the old config because I was sure I had made mistakes.
I had setup the main server dixie.dembowski.net and that worked. My MRTG and Cricket scripts were displaying correctly. Getting additional virtual hosts turned out to be easy.
In /etc/apache2/vhosts.d directory is a file called vhost.template. I copied that file and called it blog.dembowski.net.conf. I edited that copy and change all the dummy-host.example.com to the fully qualified name of my server. In vi thats just :0,%s/dummy-hosts.example.com/blog.dembowski.net/g and all the dummy names were changed.
I removed the cgi portion and added some additional Directory, AllowOverride, and Options statements. I set -Indexes and made other changes so that the rewrite rules for WordPress will work.
I saved that file in /etc/apache2/vhosts.d and that permited that my blog virtual server to work. But that caused my existing server dixie.dembowski.net to stop working. That was simple to fix. I created a file in /etc/apache2/vhosts.d called _dixie.dembowski.net.conf. The underscore character ensures that this file will be read first; the first virtual server becomes the default.
This file was very short and contained only these lines:
NameVirtualHost *:80 <virtualHost *:80> ServerName dixie.dembowski.net DocumentRoot /srv/www/htdocs </virtualHost>
This let the web server at /srv/www/htdocs work as if had before I made the virtuals.
I restart Apache and all is well. I did the same thing for my one SSL host in Apache. Unlike clear text http, the SSL based https can’t do multiple SSL sites on one IP address/TCP port. I could run one on 443 and another on a different port, but I don’t bother as I only need one SSL based site.
As long as a DNS entry exists to point that name to your IP address, you can have multiple web sites served from one IP address.
So far so good. Once I stopped using version 2.3.3 and switched to 2.5 I got the hang of the new admin interface.
The old Admin-SSL plugin stopped working because the cookie code was from the old wp-includes/pluggable.php. The cookies are different so the old plugin failed.
There is a replacement but it does not set the cookies for use with SSL pages only, which was a huge part of the old plugin. I’m going to see if I can get the old one working with the new auth cookie code. My PHP is horrible so I’m not feeling too optimistic.
Mostly WordPress 2.5 worked right out of the box for me. Since I’m using the translation plugin, I get lots of Mysql database timeouts. With 2.3.x I implemented this fix and the translation pages have no issues with database timeouts. The fix has been updated for 2.5 so my database is not complaining anymore.
Thanks to 2.5 I was able to get rid of 2 fix plugins, Optimal Titles and Full Feed. Both are no longer needed. I did modify Bad Behavior slightly and added the Remove Max Width plugin but that’s mostly it.
This is a useful Q&A for common WordPress 2.5 questions.
Image upload does not work on my Ubuntu 7.10 laptop and WordPress 2.5. I’ll check using my Vista box. I’ll also setup a new scratch blog and see if it’s some setting or plugin I’m using. The 1.5 development version of Simple Tags seems to work with 2.5 now.
I’d gotten a surprise when I went to the WordPress.org support forum. To go with the new release of 2.5, WordPress.org has a new look.
Because I have weakness of working with possibly broken software, I backed up my database, all my files, and upgraded to WordPress 2.5. I’ll see how it goes.
In preparation of installing WordPress 2.5 I finally widgetized my theme. I’m using an old 2.0 version of FastTrack. Widgets have been around for a long time so as I play with 2.5 I figured I’d come up to speed with a 2.0 feature.
I had a bunch of nested if..thens so that the home page would show one sidebar and single posts and pages would show another. I had cleaned up the theme so I now had separated the two sidebars in the file.
In my theme’s function.php I added the following lines:
if ( function_exists(’register_sidebar’) ) register_sidebars(2,array( ‘before_widget’ => ”, ‘after_widget’ => ”, ‘before_title’ => ‘<h2>’, ‘after_title’ => ‘</h2>’, ));
This let me define 2 sidebars, one for the home page and one for not the home page.
In my sidebar.php I placed
php code for the is_home() sidebar
<?php endif; ?>
<?php } else { ?>
<?php if ( !function_exists(’dynamic_sidebar’) || !dynamic_sidebar(2) ) : ?>
php code for the all other pages sidebar
<?php endif; ?>
<?php }?>
This let me have a default for each sidebar. That’s where I ran into a snag. I want to re-use the same widgets in both sidebars. The widgets won’t let me use them twice. I wanted to use the meta widget on the home page as well as on the single posts.
If I want I can define additional duplicate widgets but that’s a pain. I’m playing with the idea of defining a third dynamic sidebar and display that on the bottom of each sidebar.
I’ll keep playing with it to find a solution I like.
