First off there are two ways to install a PECL package. First is to simply issue a pecl command at the prompt: pecl install geoip

Or, you can download the package and install it manually:

Either of these methods still requires you to add a file in /etc/php.d to enable the new package. For the geoip package you can add a file called geoip.ini to /etc/php.d

You can check quickly if geoip is installed by running 'php -r 'print_r(phpinfo());' | grep -i geoip' at the command line:

If there is no output, then you have done something wrong and geoip is not installed.

However, if you get something like this:

You might scratch your head and say to yourself, but I am trying to install the geoip distribution, what gives? What the PECL package is looking for is the geoip-devel rpm. Simply issue yum install geoip-devel at the prompt, then go ahead with one of the above methods of installing the PECL geoip package.

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!

As scary as all that looks, it was easy to find the solution. Apparently this is caused by a well known rpm DB lock. First ensure that no instances of yum or rpm are running. You can do this by issuing the command 'ps ax | grep yum' and 'os ax | grep rpm'. If either of these show an instance of yum or running, kill it off or wait for it to finish. Then as super user, following these tho instructions:

That is it. You should be able to run 'yum clean all' and 'yum update'. Since we use MailScanner, I had to then contend with the annoying conflict with the MailScanner perl packages. But... that is another story.

SmartMonTools will monitor your Self Monitoring And Reporting Technology (S.M.A.R.T.) enable hard drives for potential problems which can occur before a hard drive completely files. If properly setup, it will warn you of these potential issues and possibly save your data. Of course you have a proper backup system in case just such a disaster should occur.

I am assuming that SmartMonTools is already installed on your machine, but if not, you can get it here http://smartmontools.sourceforge.net/.

First step is to see if your hard drives are S.M.A.R.T. enabled. You can do this using the smartctl application that comes with SmartMonTools. Here is the output I get when I run 'smartctl -d ata -i /dev/sda'

Those last two lines are what we are looking for. This drive is SMART enabled, so we are good to go. A couple of comments about the command I issued. If you want more information about your hard drive, try using the -a flag, which will show a lot about your hard drive. The '-d ata' flag was required for me to tell smartctl that I am going to check an ata drive. You may not require the -d flag.

The next step is to modify the /etc/smartd.conf file. Using your favourite editor, open up /etc/smartd.conf. The first thing you will do is remove the first line of the file. This line tells smartd that you have modified the file and not to over-write it. If you don't have a smartd.conf file, then you can auto-generate the first version simply by starting and stopping smartd with /etc/init.d/smartd start and then /etc/init.d/smartd stop.

Modify the conf file so that our drives will be monitored regularly. Here is my conf file:

First off, you will see that I defined the '-d ata' device flag. The -H flag is telling smartd to monitor the Health of the drive. -m is telling smartd to mail someone, in this case me, of any issues. The '-M test' flag can only be used in conjunction with the -m flag and in this case is telling smartd to send a test email to me on start up. I have added the -M flag as I want to be sure that smartd is really working and can email me.

At the bottom of this post is a partial list of flags that you can use with smartd.

If we try to start smartd right now, you will most likely be disappointed as nothing will happen. We first need to force smartd to see our drives by registering our hard drives with smartd. We can do this by running a quick CLI command for each drive:

We are piping a string of commands to smartd. The commands should look familiar to you, so I won't go over them again. The flags for smartd in this example are a little different, so lets go over those now. The -c flag is telling smartd to use a specific configuration file. The next single dash, when used with the smartd -c flag, is telling smartd to not use any configuration file, but rather, just accept commands piped in. The -q flag is telling smartd when it should quit. In this case, we are telling smartd to register our drive, run one check on the drive, and then quit. This command line serves two purposes, it registers the device, then verifies that an email can be sent out.

Here is what I get when I run this command:

The important line here is:

We have now registered /dev/sda with smartd, and smartd will now monitor this device. In my inbox I got this email:

Once you have successfully run the command for all your devices, you can now fire up smartd with '/etc/init.d/smartd start'. If all went well you should have an email like above in your inbox for each device you set up in the config file. This is telling you that the daemon is running, and can send an email when an issue occurs. The last step is to remove the '-M test' flag from each device your /etc/smartd.conf file. Then restart smartd again with '/etc/init.d/smartd restart'.

Be sure that you have added smartd to your init levels 3, 4 and 5 with this command:

That's it for today. Hopefully it will help you sleep better at night.

Not just for sshd, but also for pop and pop3 and smtp. Searching Google for a bit I came across this fix:

Change the lines like this:

to this:

Do not change the lines that start with 'account', only the auth lines. You need to remove all occurances of pam_stack.so. Please see below for a more definitive guide and a link to the complete upgrade guide. Change these in each file that contains the bad line in these places:

To quickly find the files that need changing you can issue these commands:

The original solution can be found here.

From the upgrade guide below:

Important: There are four facilities in PAM configuration: auth, account, password and session. You need to update the configuration files for all of them, not just auth.
Please note that you might also need to reorder the calls when making this change, as sometimes modules like pam_nologin were listed after pam_stack, even though they now need to be listed before the include directive.

The original how to can be found here. My apologies for the link above, as it does have the fix, but offers no explanation or how-to for this patching.

Related errors:
Deprecated pam_stack module called from service "pop"
Deprecated pam_stack module called from service "sshd"
Deprecated pam_stack module called from service "smtp"
Deprecated pam_stack module called from service "imap"

Turns out that RHEL5 has the /etc/sudoers file heavily modified with lots of yummy security goodness. A possible solution to this dilemma is to remove the line in the new sudoers marked Default reset_env. What this is does, is reload the environment variables to their default level. Subversion though, according to the official documents, performs the post-commit hooks using an empty environment. The best we could figure out was that sudoers tries to reload the environment variables just before the post-commit hook is run, and causes authentication to crap out. As soon as we commented out the default reset_env line in /etc/sudoers, our auto updates from SVN worked again!

Took a couple of hours to narrow it down to that problem, but we did sort it out in the end. Hope this helps someone else.

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:

Silly me had forgotten that I had compiled my own version of Subversion 1.3.1 way back when and I had compliled my own Trac install, which has since been upgraded to an RPM version also from Dag.weeirs.com.

The solution was simple enough, and I thought I would store it here in case I or anyone else needed the solution at some future point in time.

First, if there are any RPM packages that you previously installed, trying doing 'rpm -e packagename' first. This was the case for one conflicting package that I actually had no use of. Second, my main conflict was that my server was using libraries in /usr/local/lib, and it was using my compiled svn and svnadmin from /usr/local/bin.

The fix was three simple steps:

1 - Edit /etc/ld.so.conf and remove the line linking up the libraries in /usr/local/lib. Save the file and reload the libraries with ldconfig.

2 - Delete svn* in /usr/local/bin. This will delete all svn related binaries.

3 - Delete the libraries in /usr/local/lib that were installed. If you are unsure which ones to delete you can always leave them be, as the server won't load them anymore. I however like a clean machine.

Note that if you use other libraries in /usr/local/lib for other applications, you will NOT want to unlink them in ld.conf. Instead, you will need to remove the svn libs, and all the svn-python libs etc in /usr/local/lib manually.

Once these parts were removed, I was easily able to upgrade my server to Subversion 1.4.6 using the RPM's.

Taken from this Redhat page:

On my server I entered 'repquota /' (without the quotes).

For more information checkout the redhat page on how to set up and manage user and disk quotas.

After some searching through forums and not getting much help or info I found a solution on the Ensim forums. As this solution apparently solved ALL my problems I felt it worth repeating here, with credit where credit is due of course!

My error is just one of many errors that could result from this problem, but here is what my error was:

So, many thanks to Buckaroo at forum.ensim.com for this solution on how to rebuild your /home/virtual/FILESYSTEMTEMPLATE/

First step is to backup all your sites. If you are not sure how to do this, then find out now! You should have backups of all your sites or you might be seriously sorry one day.

Next step, just for safety is too make a tarball of the FILESYSTEMTEMPLATE directory, just in case all hell breaks lose during our fix here. Before you do this, it is best to see if there are any server backups tucked away in /home/virtual/FILESYSTEMTEMPLATE/.tmp/. If there are, in theory you can delete these, or at least move them to /home/admin during this process. To expose my ignorance on these, I really have no clue why there are backups there sometimes, but I can only assume they were placed there during Ensim control panel upgrades previously. At any rate, my /.tmp folder had 3GB of files in it, so I moved them aside before tarballing the /home/virtual/FILESYSTEMTEMPLATE folder.

Next we want to download all of the virtualhost-fst files from the Ensim ftp site. I always place my files in /usr/local/src. Here is what I did:

At this point you will need to know the version of Ensim you are running. You can easily find it by logging into your webppliance as normal and look at the bottom of the left hand menus once you login. Mine says '4.1.0-8.rhel.4ES'.

Using this version number, we next need to ftp to the ensim ftp site and download all of the virtualhost-fst files:

Note that you will need to place this line 'cd /apt/ensim/LWP/4.1.0/8.rhel.4ES/RPMS.lwp' with the proper version number from your installation. DO NOT try to install a different version of fst files.

Next we download all the files we need:

You will need to approve each download, but not to worry, it does not take very long to do this.

Once you are done, quit ftp, and move on to the next step.

Now, we need to create a little script to rebuild the /home/virtual/FILESYSTEMTEMPLATE directory. Copy and paste the following script into a filename of your choice so long as it is in the same directory as all the RPM's we just downloaded. I use pico to open and save a script called rebuild-fst.sh

Save the file, and then chmod 700 rebuild-fst.sh

The above script does a couple of things:
1 - It will loop through the entire /home/virtual/FILESYSTEMTEMPLATE directory and will delete everything in it except the services directory and the log- file. The services menu is where sendmail and mailscanner run its mail queues, so you don't want to touch those, or mail will bork.
2 - Next, the script will rebuild the entire /home/virtual/FILESYSTEMTEMPLATE.
3 - Finally, the script will run the server through maintenance mode, which will recreate the required links in the /home/virtual/FILESYSTEMTEMPLATE directory, and rebuild all the sites one by one.

Let's run that script now, and then sit back and wait. Since this script will completely rebuild every site, it takes quite awhile. All your sites will stay up during the rebuild, but the control panel will be offline thorughout the entire rebuild. Do the following to run the script:

The server I ran this on has 76 sites, and it took almost 2 hours to rebuild, so if you have a couple of hundred sites, it will take awhile.