Installing PECL geoip problem

I needed the pecl package geoip installed on one of my RHEL5 servers running PHP 5. This is an easy task but you might get a slightly confusing error which will stop you.

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:
cd /tmp
wget http://pecl.php.net/get/geoip-1.0.6.tgz
tar -zxvf geoip-1.0.6.tgz
cd geoip-1.0.6
phpize
./configure
make
make install

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
; Enable geoip extension module
extension=geoip.so

You can check quickly if geoip is installed by running ‘php -r ‘print_r(phpinfo());’ | grep -i geoip’ at the command line:
[08:19:27 root@server php.d]# php -r ‘print_r(phpinfo());’ | grep -i geoip
/etc/php.d/geoip.ini,
geoip
geoip support => enabled
geoip extension version => 1.0.6
geoip library version => 1004005
geoip.custom_directory => no value => no value
OLDPWD => /tmp/geoip-1.0.6
_SERVER[“OLDPWD”] => /tmp/geoip-1.0.6
_ENV[“OLDPWD”] => /tmp/geoip-1.0.6

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

However, if you get something like this:
[07:57:57 root@server geoip-1.0.6]# ./configure
checking for egrep… grep -E
checking for a sed that does not truncate output… /bin/sed
checking for gcc… gcc
checking for C compiler default output file name… a.out
checking whether the C compiler works… yes
checking whether we are cross compiling… no
checking for suffix of executables…
checking for suffix of object files… o
checking whether we are using the GNU C compiler… yes
checking whether gcc accepts -g… yes
checking for gcc option to accept ANSI C… none needed
checking whether gcc and cc understand -c and -o together… yes
checking if compiler supports -R… no
checking if compiler supports -Wl,-rpath,... yes
checking build system type… i686-redhat-linux-gnu
checking host system type… i686-redhat-linux-gnu
checking target system type… i686-redhat-linux-gnu
checking for PHP prefix… /usr
checking for PHP includes… -I/usr/include/php -I/usr/include/php/main -I/usr/include/php/TSRM -I/usr/include/php/Zend -I/usr/include/php/ext
checking for PHP extension directory… /usr/lib/php/modules
checking for PHP installed headers prefix… /usr/include/php
checking for re2c… no
configure: WARNING: You will need re2c 0.9.11 or later if you want to regenerate PHP parsers.
checking for gawk… gawk
checking for geoip support… yes, shared
checking for geoip files in default path… not found
configure: error: Please reinstall the geoip distribution

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.

Telnet 25 - checking email connections

As I use this frequently to test remote mail hosts for one of my clients, I figure it deserves a spot here. This will allow you to manually test a remote mail server using telnet and port 25:

First get the mail server address for a website. We will use gmail.com for our example:
dig gmail.com mx ... gmail.com. 1654 IN MX 50 gsmtp183.google.com. gmail.com. 1654 IN MX 5 gmail-smtp-in.l.google.com. gmail.com. 1654 IN MX 10 alt1.gmail-smtp-in.l.google.com. gmail.com. 1654 IN MX 10 alt2.gmail-smtp-in.l.google.com. gmail.com. 1654 IN MX 50 gsmtp147.google.com. ...

Not sure if there is a specific mail server to choose, but I usually choose one with a higher priority. In this case I will choose gmail-smtp-in.l.google.com to test from my server:

telnet alt2.gmail-smtp-in.l.google.com 25 Trying 66.249.91.27... Connected to alt2.gmail-smtp-in.l.google.com (66.249.91.27). Escape character is '^]'. 220 mx.google.com ESMTP y37si31029380iky.4 HELO outofcontrol.ca 250 mx.google.com at your service MAIL FROM:<myemailaddress@outofcontrol.ca> 250 2.1.0 OK y37si31029380iky.4 RCPT TO:<mygmailaddress@gmail.com> 250 2.1.5 OK y37si31029380iky.4 DATA 354 Go ahead y37si31029380iky.4 This is a test. . 250 2.0.0 OK 1230083982 y37si31029380iky.4 QUIT 221 2.0.0 closing connection y37si31029380iky.4 Connection closed by foreign host.

A few notes:
On most email servers you do NOT need to include the < or > tags around the email address. Stricter mail servers require it. On gmail if you do not include them you get a nasty '555 5.5.2 Syntax error'.
Don't do anything nasty or stupid, as you can be easily traced through the remote servers mail log. This how-to is to help remind me and to help you trouble shot potential email issues with remote servers, or even to your own server.

Enjoy.

Debugging MailScanner: cleaning messages

Last week I did a short post on testing MailScanner to be sure it was scanning properly. An alert reader pointed out that I missed the easy solution, which was to simply use ‘MailScanner—lint’ to check if MailScanner was running properly.

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:
7078 root     25   0 28936 23m 1960 R   99 0.6   3:19.60 MailScanner

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:
ps -ax | grep MailScanner
[07:40:59 root@secure site1]# ps ax | grep MailScanner
7077 ?      Ss   0:00 MailScanner: master waiting for children, sleeping
7078 ?      R   14:43 MailScanner: cleaning messages
7085 ?      S     0:00 MailScanner: waiting for messages
7123 ?      S     0:00 MailScanner: waiting for messages
7127 ?      S     0:00 MailScanner: waiting for messages
7170 ?      S     0:00 MailScanner: waiting for messages

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:

strace -f /usr/sbin/MailScanner
[pid 24167] open(”/home/virtual/FILESYSTEMTEMPLATE/services/sendmail/mqueue/qfmBJAmQ7J011131”, O_RDWR|O_LARGEFILE) = 7
[pid 24167] ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfddf558) = -1 ENOTTY (Inappropriate ioctl for device)
[pid 24167] _llseek(7, 0, [0], SEEK_CUR) = 0
[pid 24167] fstat64(7, {st_mode=S_IFREG|0600, st_size=1182, ...}) = 0
[pid 24167] fcntl64(7, F_SETFD, FD_CLOEXEC) = 0
[pid 24167] fcntl64(7, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}, 0x99a50a8) = -1 EAGAIN (Resource temporarily unavailable)
[pid 24167] close(7)              = 0
[pid 24167] open(”/home/virtual/FILESYSTEMTEMPLATE/services/sendmail/mqueue/qfmBJE3lHG021993”, O_RDWR|O_LARGEFILE) = 7

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:

strace -p 24167
open(”/home/virtual/FILESYSTEMTEMPLATE/services/sendmail/mqueue/qfmBJAmQ7J011131”, O_RDWR|O_LARGEFILE) = 7
ioctl(7, SNDCTL_TMR_TIMEBASE or TCGETS, 0xbfddf558) = -1 ENOTTY (Inappropriate ioctl for device)
_llseek(7, 0, [0], SEEK_CUR)        = 0
fstat64(7, {st_mode=S_IFREG|0600, st_size=1182, ...}) = 0
fcntl64(7, F_SETFD, FD_CLOEXEC)      = 0
fcntl64(7, F_SETLK64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}, 0x99a50a8) = -1 EAGAIN (Resource temporarily unavailable)
close(7)                      = 0
open(”/home/virtual/FILESYSTEMTEMPLATE/services/sendmail/mqueue/qfmBJE3lHG021993”, O_RDWR|O_LARGEFILE) = 7

Now we will get more looping text, but this time it will show the emails that MailScanner is stuck on:
/home/virtual/FILESYSTEMTEMPLATE/services/sendmail/mqueue/qfmBJAmQ7J011131
/home/virtual/FILESYSTEMTEMPLATE/services/sendmail/mqueue/qfmBJE3lHG021993

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:
cd /home/virtual/FILESYSTEMTEMPLATE/services/mailscanner/MailScanner.work
[08:53:51 root@secure MailScanner.work]# ls -la
total 28
drwx———7 root root 4096 Dec 19 08:13 .
drwxr-xr-x 4 root root 4096 Mar 20 2008 ..
drwx———2 root root 4096 Dec 19 08:39 24167
drwx———2 root root 4096 Dec 19 08:46 26134
drwx———2 root root 4096 Dec 19 08:29 26135
drwx———2 root root 4096 Dec 19 08:46 26136
drwx———2 root root 4096 Dec 19 08:47 26137

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.

Test your servers Virus filters - don’t assume

On one of our RHEL5 servers running Ensim, we noticed after the last big update of RHEL using ‘yum update’, that MailScanner was capped out, using tons of our CPU power. In the past when this happens I usually find it is ClamAV acting up. However, we were using on this server a free version of f-prot. I took a chance and purchased the latest greatest mail server version of f-prot and installed it. Bingo, the problem went away.

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!

Page 3 of 8 pages  < 1 2 3 4 5 >  Last ›