OSEC

Neohapsis is currently accepting applications for employment. For more information, please visit our website www.neohapsis.com or email hr@neohapsis.com
 
Re: POP before SMTP HOWTO

From: William Kimball Jr. (billkimballfrii.com)
Date: Wed Oct 01 2003 - 20:03:17 CDT


| I'm sure it is, but you can test it as follows.
|
| Create a file that has a line (or two lines, in your case) exactly like
| you'd find in the log file. cat that file to the fifo. (cat
| samplefile >/var/log/popauth.fifo) and see if it works. The IP address
| should end up in the popauth file (or whatever you called it) in the
| postfix directory. If that works, I guarantee it's syslog that's your
| problem. (Just tried that here and it works fine - I mean, as a way of
| verifying which half of this that your problem is in... although my money
| is on the fact that syslog won't recognize the fifo)
|
| I suppose it could be a permissions issue on the directory containing the
| fifo... another reason to have it in its own directory - you can muck with
| the permissions and not affect the rest of logging...

Excellent recommendation. The results are discouraging, however. I set a tail on the fifo file for a while (about 15
minutes) to watch for activity. I had a second terminal open with a similar tail on the maillog file. No matter how
busy the maillog gets, the fifo sees no activity. So, I opened a third term to watch the top activity report.
Initially, popauth was sleeping. I opened yet another terminal and followed your instructions above to force
information into the fifo. Sure enough, the fifo tail window reflected the new information and the top report window
showed immediate activity with popauth. Popauth started utilizing about 4% CPU, but jumped quickly to 99.2%. As I
write this
message (a few minutes later), the popauth CPU consumption has not reduced. It looks like it hangs on activity.
(breaking for a few minutes to repeat this experiment...)

In trying the same experiment again (after killing and restarting popauth), I get the same results. I can force feed
the fifo, which wakes up popauth, but
popauth hangs almost immediately. I'm guessing, but I think you're onto something with the directory/file permissions.
I'll recreate the
/var/adm/ directory with the permissions you specify, update popauth, and see what happens. (breaking for a few minutes
again so you don't have to wait for me to reply...)

No change. I made the new directory, set the permissions (which turned out to be identical to the /var/log/ directory
in which the fifo was originally placed), set up the new fifo file and updated syslog.conf to point to it. I then
updated the popauth source file to point to the new location and restarted the server. On boot, syslogd reported the
same error message, STILL unable to find the fifo file that is clearly available (I double checked again). I believe it
is important to figure out why syslog can't find a file that does indeed exist where specified. I don't know if it's
important, but the man page on chmod has no documentation for the -p mode (it covers u, g, o coupled only with d, r, w,
and/or x) being put on the fifo file. Even though I can successfully set the p mode on the fifo file (0600), it is
undocumented as far as I can tell.

I also duplicated the force feed experiment and got the same results. Popauth hangs with 99% CPU utilization. Also,
popauth never opens the log file unless I kickstart it with the force feed. All I ever get is one line (with varying
pids):

Oct 01 18:52:10 Starting log for popauth.watcher at pid 1288

Based on the perl source, it looks like this log file should be opened and initialized with this line automatically
every time popauth is started, then updated for every action taken, successful or not. Things aren't adding up. Any
ideas?

| What Linux version are you running?

RedHat 7.2 (Linux 2.4.7-10).