Category: Uncategorized

Today, I logged into one server to have a rummage and see if I could free up some disk space… on a whim I do an ‘ls’ of /tmp and find a file called ‘att1.txt’. Hmm. Lets take a look – ‘head att1.txt’ gave :

... POST http://....../admin/record_company.php/password_forgotten.php?action=insert
... POST http://..../index.php?main_page=products_all/admin/record_company.php/password_forgotten.php?action=insert

... GET /index.php?main_page=products_all/images/6e072.php?site=http://...../index.php?main_page=products_all/images     /6e072.php

It turns out there was a security update for Zen-cart sometime ago – see http://www.zen-cart.com/forum/showthread.php?t=130161

Suffice to say the various attackers had left a few files on the filesystem; thanks to ‘find -user www-data’ these were easy to find and remove. Interestingly Zen-Cart suggests you rename the ‘admin’ directory – I wonder how many people don’t (in this case) or do it to e.g. ‘admin.old’ …

*sigh*

Here’s a short python script I must have knocked up some time ago – and totally forgotten – hopefully it’ll be of some use to others….

Purpose: backup all MySQL databases, one in each file with a timestamp on the end. You’ll probably want to have a secondary cron job which does something like :

find /backups/mysql -mtime +5 -print | xargs -r rm

to delete old copies… changing +5 to how ever many days history you wish to have.

Method: Read /etc/mysql/debian.cnf to get login details for MySQL, connect to MySQL and ask it for a list of all databases, go through this list calling mysqldump on each one.

Code:

(Last updated: 2012/10/10 – skip trying to backup the performance_schema).

#!/usr/bin/env python
import ConfigParser
import os
import time

# On Debian, /etc/mysql/debian.cnf contains 'root' a like login and password.
config = ConfigParser.ConfigParser()
config.read("/etc/mysql/debian.cnf")
username = config.get('client', 'user')
password = config.get('client', 'password')
hostname = config.get('client', 'host')

filestamp = time.strftime('%Y-%m-%d')

# Get a list of databases with :
database_list_command="mysql -u %s -p%s -h %s --silent -N -e 'show databases'" % (username, password, hostname)
for database in os.popen(database_list_command).readlines():
    database = database.strip()
    if database == 'information_schema':
        continue
    if database == 'performance_schema':
        continue
    filename = "/backups/mysql/%s-%s.sql" % (database, filestamp)
    os.popen("mysqldump -u %s -p%s -h %s -e --opt -c %s | gzip -c > %s.gz" % (username, password, hostname, database, filename))

I don’t normally do anything with WordPress from a work point of view – I’ve always left such work to ‘designer’ types…

Anyway, yesterday I had a referral for someone who has two fairly busy websites (anorak.co.uk / whoateallthepies.tv) sat on a fairly beefy server (8 core, 16g of ram… oh in a few years that’ll be entry level… but I digress)… anyway, they were having performance difficulties with one site – a bit of investigation found the problem to be related to their migration from one server to another – rinetd was directing traffic from the old server, but had filled the filesystem up and was consuming all cpu time …… Easy enough to fix. Job done. Everything started working again.

After a bit more investigation I found that the two sites needed updates applying and plugins upgraded, and they had no backup job in place *doh* …. Clone the site, whizz through the wordpress upgrade routine on the clone, get the customer to OK it (he did) and then we did it on the live server…. and it looked like a success. Until an hour after I’d done the update and the customer realised part of his front page was missing….

Great. Just what I’d hoped to avoid – delving into wordpress’s code.

On opening up the theme’s index.php file it was easy to see where the content should be –  add in some debugging on the clone – and “Oh look – that ‘thing’ is empty.. it should contain ‘stuff’….”

Turns out there’s a WP_Query class; and it seems WordPress 2.9.x treats it’s query slightly differently to previous versions – ‘they’ used category_name=blah as a parameter – this no longer works, instead it needed changing to cat=1234 .. bingo, data returned; site fixed; customer happy.

I breathed a big sigh of relief. I was worried that they previous developers had made some weird customisation to wordpress core which I’d have to forward port and debug/fix.

Being the nice chap I am, I also installed xcache onto the server to help PHP out – I suspect they could cut their hardware ‘allocation’ by half and still have ample capacity to serve the sites. A few days with munin running and I’ll know for certain. Perhaps they’ll appreciate the cost saving?

Server: Debian Lenny

Installed .deb from here

# wget http://sourceforge.net/projects/postfixadmin/files/postfixadmin/postfixadmin_2.3_all.deb/download

....

# dpkg -i postfixadmin_2.3_all.deb

... dpkg moans about missing dependencies

Selecting previously deselected package postfixadmin.(Reading database ... 38632 files and directories currently installed.)Unpacking postfixadmin (from postfixadmin_2.3_all.deb) ...dpkg: dependency problems prevent configuration of postfixadmin: postfixadmin depends on dbconfig-common; however:  Package dbconfig-common is not installed. postfixadmin depends on wwwconfig-common; however:  Package wwwconfig-common is not installed. postfixadmin depends on php5-imap; however:  Package php5-imap is not installed.dpkg: error processing postfixadmin (--install): dependency problems - leaving unconfiguredErrors were encountered while processing: postfixadmin

# apt-get -f install

(dependencies now get installed...)

…. Goes into the Postfixadmin .deb installer thing.

• Tell it to use Apache2 (in my case) as the webserver,
• Give it the ‘root’ user’s database password (if MySQL).
• Tell it to generate a password for the postfixadmin user…
• Tell it to use the package maintainers version of /etc/postfixadmin/config.inc.php (well I did).

I think something went wrong for me – as I needed to do this afterwards; perhaps you’ll have better luck.

# mv /etc/postfixadmin/config.inc.php.ucf-dist /etc/postfixadmin/config.inc.php

Next, goto http://yourserver/postfixadmin/setup.php – you should see lots of text saying how it’s updating the database to version xyz, xyz+1 etc.

Choose a password to protect the setup.php page; press submit, and you’ll be presented with a ‘hash’ – copy and paste this into the config.inc.php file – so you get something like this on line 32 :

$CONF[‘setup_password’] = ‘my long hash thingy goes in here’;

Next, create a super admin account, using the setup.php page – remembering to type in the setup password you used to create the hash above.

That’s it.

(Well, now you need to configure Postfix and/or courier and/or dovecot etc etc)

You might want to read my other article which covers this…