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:
- One or more users is insisting that there is an XMLRPC exploit in 2.5.1.
- The same one or more users refuses to back this claim up with data, or apparently send the WordPress security e-mail alias any info (maybe, how would other people know what was sent via e-mail?)
- Many people tried to reasonably explain that such an exploit may exist but without data there is nothing to solve.
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.
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.
I did not really mean to upgrade my home server today, it just worked out that way.
Weeks ago I cleaned up my basement computer room and Alek had dropped off an old PC for my use. It is a dual Pentium III 800 MHz machine with 700 odd megabytes of RAM. It does not work well with my old WinTV PVR-350, Windows Media Center Edition 2005, and can’t play most AVI or MPEG files.
My server is a 3GHz P4 with 1 GB of RAM and a okay Geforce 5600 FX in it. So I figured I’d swap the drives and just use the server as a workstation and vice versa. Just to be on the safe side I moved my blog to the backup server on my VPS.
The server hard disk would not boot on the PIII box. The initrd image did not have the drivers for the ide system in the new box. Getting the initrd updated would have required the openSUSE 10.1 which I could not find.
I did have a recently burned openSUSE 10.3 DVD lying around so after a couple of hours I was able to get my server working by upgrading from 10.1 to 10.3. The updated 10.3 YaST is faster than before and I’m going to start using zypper to keep my system up to date.
Once I get the system to a point where I am comfortable then I’ll move the blog back to my basement.
I moved WordPress back to the primary server. I took a working copy of all the files and database from the backup and restored it to the primary and poof it works.
Yesterday I did get a PHP update for Opensuse, that might have been part of it.
Updated: I bumped the version from 0.9.5 to 0.9.5.1.
The source RPM for 0.9.5.1 can be found here.
The 32 bit compiled version can be found here.
I no longer have access to a x86_64 opensuse installation but running this command:
rpmbuild -bb php5-eaccelerator-0.9.5.1-1.src.rpm
should create them on your system.
I wanted to add APC or even XCache but found that my PHP version 5.0.4 was not supported. Changing to 5.2.1 did not really seem to work well for me and some plugins did not work. So I went back to the default updated opensuse 10.0 packages.
The PHP cache software eaccelerator 0.9.5 does work with php 5.0.4. In fact sometimes it speeds up php by almost half.
The opensuse 10.0 source rpm I put together can be found here. I built the .x86_64.rpm and put a copy here. The src.rpm will figure out where to put the extension so if you do a rpmbuild on the src.rpm on another opensuse which has php5 installed it should work.
The spec file has some build requirements, most of which can be commented out I am sure. I built it with
configure –enable-eaccelerator=shared –with-php-config=/usr/bin/php-config
I put the eaccelerator.cache_dir in /var/spool/eaccelerator and made that directory part of the package.
Inside the footer of my theme I put
<!– <?php echo get_num_queries(); ?> queries. <?php timer_stop(1); ?> seconds. –>
The timer shows that pages were taking 1.3 seconds or more to generate, sometimes longer.
With eaccelerator I get 0.628 seconds or so.
I also keep
define( ‘ENABLE_CACHE’, true );
in my wp-config.php right below the line that reads define (‘WPLANG’, ”);.
This caches database information such as categories etc. I turned it off and the frequent hitting of my mysql tables introduced a big delay in response time.
Next up will be to tune my mysql settings.
Sunday I went to Stefan’s to upgrade my main server. It was running Fedora Core 1 and was well past an upgrade.
I wanted to get away from Fedora because it was not supported in a way that I liked. But I did not want to waste too much time so I took with me the latest Fedora and tried to upgrade.
The new Fedora did not like my hard disk setup and refused to see the existing system. So I figured I’d put on Opensuse 10.1, move files on the file system and do an install over the old Fedora Core 1.
Everything that could go wrong did. Massively. Non-stop. The DVD drives did not work. The boot sector was not installing. It installed but refused to boot.
I finally moved the mail and web pages over to another server (more that 3 GB of data) and did a clean install of Opensuse. I’m still recovering. Last night I finally got postfix with TLS and SMTP AUTH working. The web pages are working (sorta).