Andrew, >...but it still fails to acquire a single entry after a restart. I am >suspicious about only cw having write access. My understanding was that >the Postfix daemon(s) needed to be able to write directly to the log if >they weren't going through syslog (or fsl?). > This depends on the output channel being used by fsl/l2 and is at least true for, but not limited to, the filedescriptor (fd) and file (file) output channels.
>> Keep in mind that just permissions 666 do not work because of security >> checks in Postfix. > >Now I'm a bit (more) confused. How does Postfix know anything about this >log file? Isn't fsl acting as an intermediary of some kind? > This was a mistake. You're right, postfix doesn't know about the fsl/l2 output channels and therefore cannot check anything on them. -- Thomas Lotterer, Tel: +49 89 89590047 Fax: +49 89 89590049 Cyvaned Systems GmbH&Co.KG, http://www.cyvaned.com >>> The next question would be how do I use a different log file [...] >Since nothing gets logged to /cw/var/postfix/log/postfix.log, I presume >that changing path in /cw/etc/fsl/fsl.openssh to /var/log/maillog won't >make any difference. > Sure. >Thomas pointed out that there is a loop condition using the fsl-syslog >forwarding, so I expect that is not an option yet. > Exactly, based on our previous discussion i added a warning to the fsl.pod WARNING: Because OSSP fsl is a syslog(3) redirector it must not use the target=local feature of OSSP l2. It would point back to itself and end up in a infinite run-time loop! However, it's safe to use target=remote with remote- host being set to the local host. >What do you suggest as the next step? > I'm afraid it's time to go a little bit deeper into fsl debugging. There're some points to consider: 1.) fsl is not linked into the program This would be a OpenPKG packaging issue. It happend with "inn" that embeds perl which caused the standard c library to be explicitly listed as the first library, inhibiting the overriding of any standard c library functions. We had to patch "inn" to make it work. This is not your problem as we know fsl is working with the OpenPKG postfix package. 2.) something is wrong with fsl configuration That's very likely but hard to debug. As fsl is a library only, no program has a switch to turn on fsl debugging. Our workaround is to control certain behaviour of fsl by hardcoding them into the object file at configure time (see configure help) or through environment variables (see ENVIRONMENT in the fsl.pod). The OpenPKG way of doing it is to build fsl using the "with_fsl_debug yes" option. This adds --with-fsl-debug=... to the configure call. Needless to say, fsl uses l2 for logging purposes. OpenPKG with fsl debugging enabled will write information to %{l_prefix}/var/fsl/trace.log and %{l_prefix}/var/fsl/debug.log. The latter will be truncated everytime the application is being run. Both files can become extremely huge. The trace.log allows you to monitor the fsl activities step by step as they are described under OPERATION in fsl.pod. You need access to the source to make effective use of the debug.log stuff. 3.) the l2 spec is wrong Also verly likely. Have a look at the tiny but precious "l2tool" that comes with the l2 library as it allows you to play around with l2specs from the shell command line. 4.) bug in fsl Unlikely :-) ______________________________________________________________________ The OpenPKG Project www.openpkg.org User Communication List [EMAIL PROTECTED]
