Think of a server as a large cake in a box. The cake can have several layers – jam, sponge, whatever – and is topped off with something like icing or cream. Now, each layer represents the server resources (RAM, hard drive space, CPU power, etc, etc) available and the icing/cream on top are the websites or clients’ applications.

With shared hosting, website owners only get to change the topping on their parts of the cake (which is why they pay far less), and with dedi hosting they own the whole cake so they have pay a lot more. What virtualisation does is chop up that cake into slices, then put each slice into it’s own, smaller box inside the cake box. The slice owner then gets a dedi environment at a fraction of the cost.

Pretty nifty, no? You are essentially dividing the server resources up and allocating them to separate “containers” (usually called a Virtual Machines (VM) or Virtual Private Server (VPS)) that can run their own OS and software. I think you can imagine how economical and very profitable this can be. For companies, you could maybe run several mail and web servers as VMs on a single box and save lots of money on hosting. And if they sold those 10-20 VMs, all hosted on one box, they could make a decent profit per box (even without overselling!). For clients, VMs allow you to have a dedi environment for non-dedi prices. This is extremely popular with developers who need full control over a system, plus website owners whose sites have outgrown shared hosting but they can’t afford a dedi.

Uh…. no you don’t. Just use your hosts file. How do you think your computer knows how to resolve localhost anyway? This little file is often overlooked, which is a shame. Just slap the domains in there and you’ll be able to host multiple sites on your computer (obviously you’ll need to configure the webserver to handle the domains). On Linux, the file is usually /etc/hosts, on Windows it’s C:\windows\system32\drivers\etc\hosts and on the Mac (Mac OS 10.2 and later) it’s /private/etc/hosts. They all follow the same format ([ip address] [domain name], eg 127.0.0.1 localhost).

Once edited, the domain will start resolving immediately. Trust me, it’ll work. Yeah, DNS is more feature-full, etc, etc, however for purely internal use the humble hosts file is still the best way to do things.

Luckily, Postfix does allow you to log warning messages for subject lines, and so we’ll use this to simply log a warning message for any subject line. It’s a bit of a ‘hack’, but works and doesn’t cause any problems (Postfix doesn’t block or alter the emails).

Firstly, edit the main.cf file and add the following line:

header_checks = regexp:/etc/postfix/header_checks

Next, create the /etc/postfix/header_checks file and add the following line:

/^subject:/ WARN

Reload/restart Postfix and send a test message. You’ll see something like the following in your logs:

Dec 10 10:57:01 localhost postfix/cleanup[22492]: 2290326720: warning: header subject: test email from localhost[127.0.0.1]; from= to= proto=SMTP helo=

Notice the “warning: header subject” bit. Now, every subject line will be logged :) It makes life a lot easier when doing email troubleshooting on a mail server.

As quite a few of my VPSes were affected, I guess there’s a bug with some of the OpenVZ Ubuntu 8.04 images where SSH logins (and mail errors) are logged to the wrong file. Easy enough to fix – just edit /etc/syslog.conf and change any instance of /var/logauth.log to read /var/log/auth.log. While we’re at it, change /var/logmail.err Instance to say /var/log/mail.err.

Restarting sysklogd should load up the new values, but if you want to be paranoid I suppose you could just reboot the VPS (shouldn’t be necessary, but if you do rather use the hosting company’s control panel to do it)

Step 1

First off, let’s configure the log rotation for Squid. Replace the contents of /etc/logrotate.d/squid with the following:

#!/bin/bash
LOG_FILES=
if [ -s /var/log/squid/access.log.1 ]; then
LOG_FILES=”$LOG_FILES -l /var/log/squid/access.log.1″
fi
if [ -s /var/log/squid/access.log ]; then
LOG_FILES=”$LOG_FILES -l /var/log/squid/access.log”
fi
# Get yesterday’s date
YESTERDAY=$(date –date “1 days ago” +%d/%m/%Y)
# Get one week ago date
WEEKAGO=$(date –date “7 days ago” +%d/%m/%Y)
exec /usr/bin/sarg \\
$LOG_FILES \\
-o /var/www/squid-reports/Weekly \\
-d $WEEKAGO-$YESTERDAY &>/dev/null
exit 0

Step 2

Modify the crontab (/etc/crontab), add in the two sarg-rules. Remove the sarg file in /etc/cron.daily/ as it’s not needed anymore. The two crontab rules:

00 08-18/1 * * * root /usr/sbin/sarg-reports today
00 00 * * * root /usr/sbin/sarg-reports daily

The first rule tells sarg to update the current report every hour between 8am and 6pm (ie, an average work day), and the second tells sarg to generate a report of the day’s traffic at midnight each night. I only really started adding the first rule because a lot of clients didn’t want to wait a day to see what their employees are browsing. Note though that you may want to comment that line out (put a # in front of it) if the server is under high load or if there is a LOT of browsing happening – report generation can be CPU intensive and single-cores get hammered the most (logically).

Step 3

Next, replace the contents of the sarg cron files with the following:

/etc/cron.monthly/sarg:

#!/bin/bash
LOG_FILES=
if [ -s /var/log/squid/access.log.4.gz ]; then
LOG_FILES=”$LOG_FILES -l /var/log/squid/access.log.4.gz”
fi
if [ -s /var/log/squid/access.log.3.gz ]; then
LOG_FILES=”$LOG_FILES -l /var/log/squid/access.log.3.gz”
fi
if [ -s /var/log/squid/access.log.2.gz ]; then
LOG_FILES=”$LOG_FILES -l /var/log/squid/access.log.2.gz”
fi
if [ -s /var/log/squid/access.log.1 ]; then
LOG_FILES=”$LOG_FILES -l /var/log/squid/access.log.1″
fi
if [ -s /var/log/squid/access.log ]; then
LOG_FILES=”$LOG_FILES -l /var/log/squid/access.log”
fi
# Get yesterday’s date
YESTERDAY=$(date –date “1 day ago” +%d/%m/%Y)
# Get 1 month ago date
MONTHAGO=$(date –date “1 month ago” +%d/%m/%Y)
exec /usr/bin/sarg \\
$LOG_FILES \\
-o /var/www/squid-reports/Monthly \\
-d $MONTHAGO-$YESTERDAY &>/dev/null
exit 0

/etc/cron.weekly/sarg:

#!/bin/bash
LOG_FILES=
if [ -s /var/log/squid/access.log.1 ]; then
LOG_FILES=”$LOG_FILES -l /var/log/squid/access.log.1″
fi
if [ -s /var/log/squid/access.log ]; then
LOG_FILES=”$LOG_FILES -l /var/log/squid/access.log”
fi

# Get yesterday’s date
YESTERDAY=$(date –date “1 days ago” +%d/%m/%Y)

# Get one week ago date
WEEKAGO=$(date –date “7 days ago” +%d/%m/%Y)

exec /usr/bin/sarg \
$LOG_FILES \
-o /var/www/squid-reports/Weekly \
-d $WEEKAGO-$YESTERDAY &>/dev/null
exit 0

Once this is done, you will have working Sarg reports! It’s a highly annoying bug in an otherwise very good distro, however it’s one of those nice ones that’s easy to solve.

Luckily, blocking specific mail attachments in Postfix is pretty straightforward and only takes a minute or two to set up.

Step 1:
First, we’ll need to activate the header checker in postfix. Make sure the mime_header_checks option is uncommented in main.cf and looks like this:

mime_header_checks = regexp:/etc/postfix/mime_header_checks

Naturally, /etc/postfix/mime_header_checks is the location of file that contains the info on the blocked attachments.

Step 2:
Create /etc/postfix/mime_header_checks, then add in the following content:

/^\s*Content­(Disposition|Type).*name\s*=\s*”?(.+\.(mov|mpg|mpeg|avi|wmv))”?\s*$/ REJECT Files attached to emails that contain or end in “$3″ are prohibited on this server as they may contain viruses. The file named “$2″ was rejected

Note that I couldn’t wrap the above in <pre></pre> tags as the formatting looked stupid, also that all goes on one line. Anyway, the file types to be blocked go in the brackets containing ‘mov|mpg…’, and each one is seperated by a pipe (”|”).

Restart Postfix, or get it to reload the configuration files, and there you have it! Whenever a forbidden file attachment is detected (based on the MIME type), it is removed and the message is added to the email information the recipient of this.

CONCURRENCY=none

Change it to this:

CONCURRENCY=shell

And then restart your machine:

sudo shutdown -r now

You’ll notice that it’ll start up faster, as it’ll run several of the startup scripts concurrently. This only works on multi-core systems, mind you – doing this on a single-core system will make the startup sloooow. You can then optimise the boot order to make things faster, but I’ll leave that for another blog post, as it’s a bit more complicated (you have to take things like script sequence numbers and possible dependencies into account)

try running alsamixer in a console and check everything is unmuted and maxed. (use arrow keys to move/adjust , M key to mute/unmute and ESC to save and exit)

Worked 100% for me, though that’s because I’m using ALSA as my playback device.

As such, I’m moving the site to a new host and am recovering as much data as possible.

Please bear with me while I sort this out. I couldn’t recover a lot of the old posts, unfortunately.