Date: Thu, 23 Aug 2001 11:33:56 -0400 (EDT) From: Victor Danilchenko Subject: Stunnel logging facility?.. Our installation relies on stunnel logging to authenticate remote users -- by pairing up stunnel connection notice and IMAP or POP login notice, we create a ticket for the user's IP. This was working fine (kinda sorta -- SSL/POP wasn't working until version 3.19), until recent upgrade, at which point stunnel started partially ignoring the loigging spec. We start it as follows: /usr/local/sbin/stunnel -D mail.info -E /var/egd/randsock -d spop3 \ -p /usr/local/ssl/certs/stunnel.pem -l /usr/local/etc/ipop3d spop3d The mail facility logs the following startup entries, and nothing else (well, it also logs the terminating entries): Aug 23 09:36:54 freya stunnel[26963]: Using 'spop3d' as tcpwrapper service name Aug 23 09:36:54 freya stunnel[26963]: PRNG seeded successfully Aug 23 09:36:54 freya stunnel[26963]: stunnel 3.20 on alpha-dec-osf4.0 PTHREAD BUT... the entries after that get logged in user.log (NOT mail.log) are: Aug 23 10:15:50 freya syslog: spop3d connected from 128.119.243.34:49221 Aug 23 10:17:46 freya syslog: spop3d connected from 128.119.243.34:49222 Note that they are logged without the name or PID... I am sure the other entries get logged thusly as well, but without the name they are harder to track, and the "connected from" entry is what we are interested in. I took a quick look at log.c, and it looks like it's *supposed* to work -- and it obviously does, at first (the initial entries get logged correctly); but somewhere along the line, the logging information gets lost. Out of curiosity, I rebuilt stunnel with threading disabled; the forking stunnel now logs into the mail.log as follows: Besides the error message at the end, the FORKing version does log the connections correctly. It looks to me like the syslog facility on Digital Unix 4.0d (and earlier, presumably) is not thread-safe -- only the parent thread seems to log the connections correctly. Unfortunately, I don't have enough experience with C Pthreads to implement the seemingly viable solution -- have the parent thread do nothing but logging, have the children pass messaged to be logged to the parent, and have a separate boss/listener thread to spawn the workers. For now, I am running the FORKing version of stunnel 3.20; the severed SSL connection when wrapping POP that was plaguing stunnel 3.18, does not reappear. ------------------------------------------------------- Date: Thu, 23 Aug 2001 11:17:01 -0500 From: Brian Hatch Here's something you could do to test. Edit sthreads.c and find the create_client function. Just before the 'return' statements, add the following lines: log_close(); log_open(); That'll close and re-open the log, which may do the trick. I haven't actually tried this, so I don't know if this is the best spot, or even the only spot you'd need to try. ------------------------------------------------------- Date: Tue, 28 Aug 2001 10:01:05 -0400 (EDT) From: Victor Danilchenko Actually, I took the idea of reopening the log, and applied it one step further -- and it seems to work. Essentially, instead of wrapping each client opening into a log reopen statements, I wrap each log call into a log open/close pair; this approach seems to have worked, in that the subthread syslog calls are now being processed and logged correctly. Patch included. I am not sure what else such a drastic approach might break, though, and it will certainly be a performance hit under heavy load and high logging level.