Re: Tracking stray fsl logging
On Thu, Dec 14, 2006, Thomas Lotterer wrote:
Bill,
Bill Campbell[EMAIL PROTECTED] wrote on 2006-12-13 19:04:
Is there any easy way to identify the program that's causing
entries to end up in the %{l_prefix}/var/fsl/fsl.log file?
this is really a challenge because fsl doesn't know the application it is
linked into and the application being faked into believing it is using syslog
doesn't know about fsl!
OK:
I've tracked this down to the libwrap implementation in openssh where
it calls the tcpwrappers ``refuse'' routine which uses syslog without
an openlog first. This is done in the sshd.c file. The openssh log.c
routines go through some machinations to determine whether to user
openlog_r or openlog, but do the right thing.
Interestingly enough there's a comment in the log.c file around line
291 that recognized that libwrap may have done syslog things without a
proper open.
A crude hack might be to call the ``logit'' routine from sshd.c just
before calling ``refuse''. It would end up with an extra line in the
logs, but would get them all in the right place.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software, LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
``Microsoft IIS has more holes than a wheel of Swiss Cheese after a shotgun
blast'' -- John Dvorak
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: Tracking stray fsl logging
Bill,
Bill Campbell[EMAIL PROTECTED] wrote on 2006-12-13 19:04:
Is there any easy way to identify the program that's causing
entries to end up in the %{l_prefix}/var/fsl/fsl.log file?
this is really a challenge because fsl doesn't know the application it is
linked into and the application being faked into believing it is using syslog
doesn't know about fsl!
I'm seeing a bunch of things saying ``refused connect from...'',
with nothing to identify the program that generated these.
Because of the library and the application being unable to help each other, the
developer or packager must tie them together. Hints to track down the logging
application:
find packages that use fsl
$ openpkg rpm -q --whatrequires fsl
unpack the sources and hunt for the messages you see
$ openpkg rpm -Uvh foo.src.rpm
$ cd $PREFIX/RPM/SRC/foo
$ openpkg rpm -bp foo.spec
$ cd $PREFIX/RPM/TMP/foo ...
$ grep -R refused connect
if that doesn't help, find executable binaries that have fsl embedded
$ openpkg rpm -ql `openpkg rpm -q --whatrequires fsl` \
| egrep '/([s]bin|libexec)/' \
| xargs what
read openpkg man fsl and hunt for what(1) to understand the search.
Once the applications are identified, their sources can be reviewed to find
calls to openlog(3). The facility passed there is the key for fsl to redirect
log messages catched from syslog(3). The problem with the syslog API is that
the use of openlog is optional. Apps omitting openlog cannot be used with fsl
and must be patched to call openlog.
Going one step deeper is to rebuild fsl with_fsl_debuglogcode=yes, install it
and rebuild one of the candidate packages with this fsl. Again, read openpkg
man fsl and this time hunt for -with-fsl-debug. And yes, you are reading
correct: this debugging stuff uses the contents of a symlink (not the file the
symlink is pointing to) as raw configuration data.
--
Thomas
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Re: Tracking stray fsl logging
On Thu, Dec 14, 2006, Thomas Lotterer wrote:
Bill,
Bill Campbell[EMAIL PROTECTED] wrote on 2006-12-13 19:04:
Is there any easy way to identify the program that's causing
entries to end up in the %{l_prefix}/var/fsl/fsl.log file?
this is really a challenge because fsl doesn't know the application it is
linked into and the application being faked into believing it is using syslog
doesn't know about fsl!
I'm glad it isn't just me :-).
Thanks for the suggestions on dealing with this.
I suspect that the problem is someplace in openssh as swatch
reports looking at the fsl.log and openssh.log files have a
tendency to have entries at similar times.
BTW: I've done some work on the swatch package, cleaning it up t
use perl-openpkg, adding standard rc.d/rc.swatch run control, and
including a prototype configuration file. I plan to update the
CURRENT package after a few days testing here to work on the
configuration file.
I'm seeing a bunch of things saying ``refused connect from...'',
with nothing to identify the program that generated these.
Because of the library and the application being unable to help each other, the
developer or packager must tie them together. Hints to track down the logging
application:
find packages that use fsl
$ openpkg rpm -q --whatrequires fsl
unpack the sources and hunt for the messages you see
$ openpkg rpm -Uvh foo.src.rpm
$ cd $PREFIX/RPM/SRC/foo
$ openpkg rpm -bp foo.spec
$ cd $PREFIX/RPM/TMP/foo ...
$ grep -R refused connect
if that doesn't help, find executable binaries that have fsl embedded
$ openpkg rpm -ql `openpkg rpm -q --whatrequires fsl` \
| egrep '/([s]bin|libexec)/' \
| xargs what
read openpkg man fsl and hunt for what(1) to understand the search.
Once the applications are identified, their sources can be reviewed to find
calls to openlog(3). The facility passed there is the key for fsl to redirect
log messages catched from syslog(3). The problem with the syslog API is that
the use of openlog is optional. Apps omitting openlog cannot be used with fsl
and must be patched to call openlog.
Going one step deeper is to rebuild fsl with_fsl_debuglogcode=yes, install it
and rebuild one of the candidate packages with this fsl. Again, read openpkg
man fsl and this time hunt for -with-fsl-debug. And yes, you are reading
correct: this debugging stuff uses the contents of a symlink (not the file the
symlink is pointing to) as raw configuration data.
--
Thomas
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
--
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
What's this script do?
unzip ; touch ; finger ; mount ; gasp ; yes ; umount ; sleep
Hint for the answer: not everything is computer-oriented. Sometimes you're
in a sleeping bag, camping out.
(Contributed by Frans van der Zande.)
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
Tracking stray fsl logging
Is there any easy way to identify the program that's causing
entries to end up in the %{l_prefix}/var/fsl/fsl.log file?
I'm seeing a bunch of things saying ``refused connect from...'',
with nothing to identify the program that generated these.
Bill
--
INTERNET: [EMAIL PROTECTED] Bill Campbell; Celestial Software LLC
URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
FAX:(206) 232-9186 Mercer Island, WA 98040-0820; (206) 236-1676
Many companies that have made themselves dependent on [the equipment of a
certain major manufacturer] (and in doing so have sold their soul to the
devil) will collapse under the sheer weight of the unmastered complexity of
their data processing systems.
-- Edsger W. Dijkstra, SIGPLAN Notices, Volume 17, Number 5
__
The OpenPKG Projectwww.openpkg.org
Developer Communication List openpkg-dev@openpkg.org
