Since I wrote that article, I found that my MailScanner was again hogging the CPU. Last time it was an issue with f-prot interaction, this time it is a problem apparently with MailScanner.

Here is what I did to debug this issue, and here is the post that helped me learn more about MailScanner.

First thing was to check top:

When I did a strace -p 7078 I saw nothing. Literally. So that was not much help. Next up, see what ps has for me:

There is my stuck process, and apparently it is stuck cleaning messages. But which messages? The MailScanner working directory has more than one email in it, and to be picky I would prefer not to delete a valid email. Next step to be thorough is to do an strace on MailScanner itself and see what it is up to. You will see a lot of output, and then finally you should see a list of PID's coupled with the email that is stuck:

Note the different PID on these files that seem to cause MailScanner to loop indefinitely: [pid 24167]. Now we can run a trace on that PID:

Now we will get more looping text, but this time it will show the emails that MailScanner is stuck on:

While MailScanner is still running, you can go to the MailScanner working directory and see a list of folders named after the MailScanner PID's:

Go into the problem PID's directory and you will see a list of files that make up the email that is stuck. This might help you determine why the email is stuck. In my case, there was a virus attached to an email, which, like the this post pointed out, was also causing MailScanner to loop.

Yes, you can easily just go to /home/virtual/FILESYSTEMTEMPLATE/services/sendmail/mqueue/ and delete all the emails in the queue and restart MailScanner, but I wanted to be sure that one of the emails was really the problem.

This little how-to does not fix the real issue of MailScanner getting stuck in an endless loop, but merely solves the current issue of MailScanner hogging the CPU. We can fully expect the issue to rear its ugly little head again at some point. Hopefully by that time, we will have solved the root issue.

Why f-prot? It works and it is easier on the server. I have noticed that the server load with f-prot is noticeably lower than when using ClamAV.

Once the new version of f-prot was properly installed, I wanted to test that it worked as it should. A friend suggested to test the virus scanner I should put it to a real-world test using one of Declude.com's free tools.

This test would actually send an email to my server with a file that was made to get caught be anti-virus filters.

The test worked well, too bad my anti-virus f-prot filter didn't. After a quick check I realized I had not modified one path in my MailScanner rules file to point to the new f-prot location. After I fixed that, I ran the test again, and sure enough, my anti-virus filter was working as it should.

Lesson learnt? Never assume your new software works, test it!

For me, I am fascinated with part of the weather, namely METAR data and using it to mash up Google map stuff. I haven't actually done any mashups but I plan too. To help me with my fascination, I was thinking of trying out the PEAR Services_Weather package. Installing this is super easy on my own servers, just enter 'pear install Services_Weather' and poof, there it is. On a 1and1 account, if you have never installed any non-mainstream packages for PEAR, you are in for a short shock. 1and1 won't let you install your own packages by default. Luckily there is a work around, and it is really quite simple.

You need an account with SSH access to do this.

First, take a look at the current configuration in your 1and1 account:

The important lines to use are directory entries. Note that they are all out of reach in /usr/bin and /usr/lib. We can't install in there! So how do we install our PEAR package? Easy. Set PEAR up to work from our own home directory.

The first command tells pear to create a local config file. The next command simply tells PEAR to install itself according to the local config file you just created. Don't forget to include the new path in your PHP files with something like:

Now when you run pear config-show you should see something like this:

This little how-to would not have been so easy to figure out without the aid of thecodecase.com.

It was time that I added a little something for these spam bots to help reduce their ability to see my sites. Simply adding the following code to an .htaccess file in the root of the site structure would help to curb evil good for nothing spam bots:

[Last Updated: April 7th 2009]

This code is a cleaned up version of the code found here and here. Note that you really should look through all the User Agents and be sure you are not blocking someone or some software that you would like to keep. The list above is far from complete, but is a good start.

For a fairly up-to-date list of User Agents you will find a useful User Agent database here.

As I have a fair number of sites I did not want to host them all where placed my clients, as I could not afford that much. So I looked around and tried out a number of low price hosting options. As it turns out, they are low priced for a reason--commen sense right?

So, this week I rented another server at ThePlanet. I find their network unbeatable, and their tech support excellent when needed. Never had a billing issue either. This week ThePlanet had a sale on which made getting a Dual 3.2Ghz with 2GB of RAM and 2.5Terabytes of bandwidth for only $147 a good thing. This is a plain RHEL5 box with no control panel. Something I wanted to try for sometime.

Over the next few weeks I will write up my experience, whether good or bad, smart or stupid, right here.

Phase one involved installing a few items:

• Install Trac
• Install Subversion (SVN)
• Install watchdog
• Install APF firewall
• Install BFD brute force detection
• Install MySQL 5
• Remove Sendmail
• Install Exim

Install Trac:

Install Subversion:

Install watchdog:
cd /usr/local/src
wget http://dag.wieers.com/rpm/packages/watchdog/watchdog-5.3.1-1.el5.rf.i386.rpm
rpm -Uvh watchdog-5.3.1-1.el5.rf.i386.rpm

Install APF firewall

Install BFD Brute force Detection

Install MySQL:
This is a straight yum install and I recommend staying with this to make future upgrades easier.

Make sure you enter your desired password here!

Remove sendmail:
Why remove sendmail? I want to use something a little newer and after polling my friends, I have chosen exim. This may change in the future, but for now this is my choice.

That was it! Cool!

Install Exim:

That was it! Cool again.

I have not gone into the setting up and configure of each app on the system. Other posts on my site will cover some of those things, and for Exim configuration, I will try to do my best to document my progress. Happy or otherwise.

Don't do it, Don't even fix it right. Don't pay the Dreamhost man! (ala Chris de Burgh's Ferry man).

I wanted to try a few different hosting companies. Dreamhost looked interesting as it offered SVN repositories, for $8 a month. People said they were pretty good. Well, for the past week or so they have been anything but. They claim a file server is down or something, but all I know is mail doesn't work, server loads run between 10 and 80, SSH works half the time, and my sites take forever to load! Then they post in their server status that the problem is fixed. According to me and all the other posts I read, the problem is still very much there, thank you very much. I post trouble tickets to support and so far out of three requests I have one answer. First post took over 12 hours to answer, second post went missing apparently, and the third post is now at 6 hours about and nothing. (shhh, I think they went out to get drunk.)

If you read Dreamhost's blog, you will see they made a huge accounting error a couple of months ago which they refer to the "Fat finger incident, and they now tell the world that the error has cost them hundreds of thousands of dollars. Or at least that is what I got from the post. And they tell this whole story with humour. So perhaps they are losing their shirts and can't afford to replace their equipment anymore, who knows. All speculation from this frustrated and very 'Out of Control' programmer.

Who knows, maybe after they fix this issue, everything will be perfect!

I wish you all a great weekend and bid you all a G'night! I am off for a cold one.

Setup a new server today! This time, instead of using port 465 and setting up the SSL certs etc, I wanted something a little easier to use. So, according to RFC 2476 at this link, I can use port 587.

On our Ensim 10.3 box which runs on RHEL 5, this is an easy change to make. Note this should work equally well on RHEL4 and Ensim 4.0.x and Ensim 4.1.x.

As usual, lets modify the sendmail.mc file and NOT try to modify sendmail.cf, as a lot of others suggest. Modifying sendmail.cf will cause your changes to be lost next time you upgrade Ensim.

Next, you will scroll down until you find this line:

and immediately below it, add this line:

A couple of things here worth mentioning. You don't have to use port 587, you can use pretty much any available port you want. If you wish to RFC compliant however, then port 587 is the right port to use as an alternative sendmail port. Also, for those of us not familiar with the sendmail.mc file, the dnl in front of the line, basically comments the line out. To uncomment the line, simply move the dnl to the end of the line.

Don't uncomment that first DAEMON_OPTIONS line unless you want to block every one on the internet from being able to send email from your server. Uncommenting that line essentially tells the server to listen to port 25 (SMTP) on the localhost (127.0.0.1) only, and ignore all other IP's address (the world!).

Alright, so by now you have made the changes above and are ready to get sendmail.cf updated.

If you use a firewall, be sure to unblock port 587! Many people seem to over look this one (myself included!) and struggle trying to figure out why this little fix doesn't work.

If you have comments or suggestions, I would love to hear them on this topic.

This can be resolved by add this code immediately before this line DAEMON_OPTIONS(`Port=587,Name=MTA')dnl:

Further more, I noticed that sendmail now has the 587 line already in the sendmail.mc file, but it is simply commented out. So instead of all of the above, you can look for this line:

and replace it for these two line:

For this tutorial, we want to merge:

old1, old2, old3 and old4

into a new single repository called

newrepo

First you will need to create a temporary directory to do the work in. You must have enough space in this directory to handle at least two times the current size of your repository.

We will, for the purposes of this Subversion Tutorial, be working in /home/temp/.

Now lets move over to our subversion repository and create the new repository that will house our final merged repository:

The next step is to create root folders in our new 'newrepo' SVN repository. You want to create one new root folder for each repository that you will be merging in:

Note: the backslashes are there to allow me to split command onto separate lines. If you plan on putting the command to create the root repos onto one line, then don't use the backslashes.

The next step is to disable Subversion, which will vary depending on how you have it setup. Once the SVN repository is turned off, we are ready to dump the contents of all our Subversion repositories to our temporary location we created above.

Depending on how large your repositories are, the dumping process could take awhile to process. Once it is complete, the last step is to simply reload your dumped repositories in the order that you want to maintain the update messages.

In your old repositories you theoretically had each repository check-in number starting at 1 and sequentially going up from there. When you remerge the repositories, you can only have a single first check-in. In our example we will re-merge the repositories in this order: old1, old4, old2 and finally old3. Lets assume for a moment that old1 had 100 check-ins, old2 had 54 check-ins, old3 had 1004 check-ins and old4 had 5 check-ins.

Once our merger is complete our check-in numbers will now go like this:

old1 will start at 1 and finish at 100.
old4 will start at 101 and finish at 105
old2 will start at 106 and finish at 159
old3 will start at 160 and finish at 1163

Feel free to ask questions or suggest modifications to my method posted here. Due to my schedule I may not be able to respond very quickly. If you require further assistance right away with your Subversion Repositories, please visit http://www.subversion.tigris.org/

A quick search on Google found me this article which was quite useful.

Basically using the fuser command in Linux we can see which user or pid is accessing files on parition. Usage is quite simple:

fuser -u /mnt/sdb will show me which users are currently using files on the partition.

/sbin/fuser -m /mnt/sdb
/mnt/sdb: 7638c

Using the -m flag, we can get the current pid using files. The 'c' in both cases signifies that this is the current directory of the user or pid.

In my case a Bash file was currently running on the parition I was trying to umount. Once it finished the drive unmounted with no problems.

Unfortunately, there is usually a reason that a drive drops into read only mode. This case was no different. I looked at dmesg from the command line to fine that my drive had some hardware failures and need replacing. Luckily I have lots of current back-ups!

Starting this past Saturday night at 8pm, I have been tracking my consumption in conservation mode. So far, after 68 hours my usage totals 12KWh. Not bad considering last week at this time, I had used roughly 25KWh at this point.

Once I reach the end of the week, I will once again post my usage consumption and give you a little feedback on what I like and dislike about the Kill-A-Watt device.