- syslog-ng - lists.balabit.hu

Re: [syslog-ng] syslog-ng 1.1.27
by Ispanovits imre 11 Jul '99

11 Jul '99

Balazs Scheidler, SZO, 10 JÚL 1999-n írta: >>Hello, > >I have released version 1.1.27 aka 1.2.0rc1 of syslog-ng and the >corresponding libol versioned 0.2.0. I worked on this release a lot to >make it as bugfree as possible, and make installation flawless. T > >Syslog-ng is available at the usual places: > >http://www.balabit.hu/downloads/syslog-ng/source/ > >The official webpage is at: > >http://www.balabit.hu/products/syslog-ng/ >^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Hali! Biztos, hogy kint van? Miért nem látom? Imre ----------------------------------------------------------------- Cyrix 6x86 PR200MX/Amptron PM9900A/80MB/QFB EL5.1A/R6 6.0/2.2.9/KDE-1.1.1 -----------------------------------------------------------------

1 0

Archive test
by Balazs Scheidler 11 Jul '99

11 Jul '99

Archiver test, sorry for inconvinence

1 0

Archive test
by root 11 Jul '99

11 Jul '99

Archiver test, sorry for inconvinence

1 0

inetd/tcp_wrappers and syslog-ng
by Nathaniel Couper-Noles 21 Jun '99

21 Jun '99

Has anyone had any success integrating syslog-ng and inetd and/or tcp_wrappers? Running syslog-ng inside of inetd on a linux 2.0.36 box seems to generate unfavorable results. Each time a remote system reports data to udp 514, the system loads a new instatiation of syslog-ng, until there are literally 50+ copies running parallel. Any possibility for future support of these services? TIA Nathaniel

3 2

syslog-ng and solaris doors again
by Balazs Scheidler 21 Jun '99

21 Jun '99

Hi, I have digged into low level solaris. I found the followings: * I receive NULL's in the server procs parameters, because they are sent as NULLs. (I've put a breakpoint in _door_call, and after familiarizing myself with SPARC assembly, I could find the passed door_arg_t structure, and the fields are indeed NULLs. * Seeing the truss output of the logger program I found that the message is also sent to the sun STREAMS device /dev/log So as it seems the native syslogd receives the message using STREAMS instead of the door. The reason for this is unknown, maybe if the message is successfully sent using STREAMS, it is not sent via the DOOR. I have began implementing the STREAMS driver. (to be exact, I have already hacked it together, currently trying to compile it) -- Bazsi

2 7

[bazsi@blurp.balabit.hu: Fwd: Re: Solaris and syslogd]
by Balazs Scheidler 17 Jun '99

17 Jun '99

Hi, Good news. The problem with sun-doors are solved: ----- Forwarded message from Balazs Scheidler <bazsi(a)blurp.balabit.hu> ----- Date: Thu, 17 Jun 1999 22:48:14 +0200 From: Balazs Scheidler <bazsi(a)blurp.balabit.hu> To: bazsi(a)balabit.hu Subject: Fwd: Re: Solaris and syslogd Path: news.iif.hu!news.bme.hu!news-ge.switch.ch!newsfeed.berkeley.edu!dispose.news.demon.net!demon!colt.net!easynet-tele!easynet.net!btnet-feed2!btnet!carbon.eu.sun.com!uk-usenet.uk.sun.com!nl-usenet.holland.sun.com!not-for-mail From: Casper.Dik(a)Holland.Sun.Com (Casper H.S. Dik - Network Security Engineer) Newsgroups: comp.unix.solaris Subject: Re: Solaris and syslogd Date: 15 Jun 1999 07:46:58 GMT Organization: Sun Microsystems, Netherlands Distribution: inet Message-ID: <casper.929432774(a)nl-usenet.sun.com> References: <slrn7m85qd.2gg.bazsi(a)blurp.balabit.hu> NNTP-Posting-Host: room101.holland.sun.com Mail-Copies-To: never Lines: 22 [[ PLEASE DON'T SEND ME EMAIL COPIES OF POSTINGS ]] bazsi(a)blurp.balabit.hu (Balazs Scheidler) writes: >I am writing a portable syslogd replacement, and I have a small problem with >Solaris. I hope someone can help me out. >So, the facts I know: Solaris uses the new multithreaded door mechanism to >send messages from client programs to the syslogd server. The used door is >called /etc/.syslog_door. No, it doesn't. It uses the msglog device to sendmessages. The syslog door is used to confirm that syslogd is still running. Casper -- Expressed in this posting are my opinions. They are in no way related to opinions held by my employer, Sun Microsystems. Statements on Sun products included here are not gospel and may be fiction rather than truth. ----- End forwarded message ----- -- Bazsi

1 0

Re: syslog-ng
by Balazs Scheidler 17 Jun '99

17 Jun '99

On Thu, Jun 17, 1999 at 11:35:53AM -0400, Forrest Aldrich wrote: > Okay, perhaps I don't understand. Syslog takes a number of attributes > and logs them into a file /var/log/syslog (or whatever you define). Those > attributes could be translated into a schema/table and inserted into > the database each time. Then, those same fields can be keyed or > indexed, searched against... reports run. I would think that would > be very useful. > > The alternative is to hack shell and perl scripts together to pull out that > data... or by viewing them manually, which involves sore eyes and headaches. The problem with exactly this "translation into a schema/table". log messages are quite different, and it is very difficult to write a general parser, which extracts information from log messages. I do not want to put this difficulty to syslog-ng itself, however it is possible to write this functionality to an external program or perl script. -- Bazsi

1 0

Re: syslog-ng
by Balazs Scheidler 17 Jun '99

17 Jun '99

On Tue, Jun 15, 1999 at 05:33:16PM -0400, Forrest Aldrich wrote: > What about a database backend... like MySQL. To have the > capability to log syslog messages into (perhaps multiple) SQL > databases would be very useful, I think. I think logging to an SQL table with only one column has no point. Analyzed log entries would have a point, but analyzing messages is beyond the scope of syslog-ng. An external program hooked to syslog-ng with a local communication mechanism (unix-stream, or named pipe) should be used instead. -- Bazsi

1 0

Re: syslog_ng suggestion
by Marc Duponcheel 14 Jun '99

14 Jun '99

On 1999 Jun 14, Balazs Scheidler wrote: > Hi, > > (cc-ing the message to the syslog-ng mailing list) Thanks, I better subscibe ! > On Mon, Jun 14, 1999 at 01:45:02AM +0200, Marc Duponcheel wrote: > > First of all: CONGRATULATIONS with syslog_ng! > > > > UNIX is waiting 20 years already to get rid of the limited syslog > > daemon ;-) > > Thanks. > > > Since you use a real language to write syslog_ng.conf I would like you > > to propose a generalisation, which, I believe, should be easy (and > > powerful). > > > > You may have noticed that big parts of a syslog_ng.conf are simply > > substitutions of some template ... > > > > What about variables (coming out of the log itself)? > > > > like: > > variables=level,facility,program,host > > > > Then syslog_ng could interpret generic specifications resulting in > > generating multiple log files without the syslog_ng.conf writer having > > to worry about the actual possible values. For 'program' and 'host' I > > believe this could be a real win. > > > > Of course you should make ${program}=foo for such things like > > foo[NNN]: and foo: > > > > destination d_${variable} { > > file /var/log/${variable}; > > }; > > filter f_${variable} { > > level(${variable}); > > }; > > log { source src; > > filter f_${variable}; > > destination d_${variable}; > > }; > > > > > > In fact one could combine variables (2 below) to generate any kind of > > combinations. > > > > destination d_${level}.${program} { > > file /var/log/${level}.${program}; > > }; > > filter f_${level}.${program} { > > level(${level}); > > program(${program}) > > }; > > log { source src; > > filter f_${level}.${program}; > > destination d_${level}.${program}; > > }; > > this approach has some difficulties. > > syslog-ng opens all files at startup and keeps them open, and using > variables above would make it rather difficult to find out the possible > files at startup. (= impossible) Yeah, I was somewhat aware of this and also about the dangers of having too many files opening closing all the time ... > A workaround would be to open a destination only when some output is written > there, but this would require quite big changes in syslog-ng internally. And would probably slow down things ... I don't know. > The same effect you proposed above could be done using some config file > generation script: > > for fac in mail news auth; do > for lev in crit alert debug; do > cat syslog-ng.template | > sed -e "s/\$\{facility\}/$fac/g" -e "s/\$\{level\}/$lev" > done > done That's indeed what I do for (fac, lev) ;-) but for program and hostname I don't have a list ... since any program or host could suddenly decide to log something, a fact by the way a sysadmin might be interested in (such a new program or host). -- Marc Duponcheel marc(a)offline.be [home] +32 (0)3 449.44.94 mduponch(a)cisco.com [work] +32 (0)2 704.52.40

1 0

Re: syslog_ng suggestion
by Balazs Scheidler 14 Jun '99

14 Jun '99

Hi, (cc-ing the message to the syslog-ng mailing list) On Mon, Jun 14, 1999 at 01:45:02AM +0200, Marc Duponcheel wrote: > First of all: CONGRATULATIONS with syslog_ng! > > UNIX is waiting 20 years already to get rid of the limited syslog > daemon ;-) Thanks. > > Since you use a real language to write syslog_ng.conf I would like you > to propose a generalisation, which, I believe, should be easy (and > powerful). > > You may have noticed that big parts of a syslog_ng.conf are simply > substitutions of some template ... > > What about variables (coming out of the log itself)? > > like: > variables=level,facility,program,host > > Then syslog_ng could interpret generic specifications resulting in > generating multiple log files without the syslog_ng.conf writer having > to worry about the actual possible values. For 'program' and 'host' I > believe this could be a real win. > > Of course you should make ${program}=foo for such things like > foo[NNN]: and foo: > > destination d_${variable} { > file /var/log/${variable}; > }; > filter f_${variable} { > level(${variable}); > }; > log { source src; > filter f_${variable}; > destination d_${variable}; > }; > > > In fact one could combine variables (2 below) to generate any kind of > combinations. > > destination d_${level}.${program} { > file /var/log/${level}.${program}; > }; > filter f_${level}.${program} { > level(${level}); > program(${program}) > }; > log { source src; > filter f_${level}.${program}; > destination d_${level}.${program}; > }; this approach has some difficulties. syslog-ng opens all files at startup and keeps them open, and using variables above would make it rather difficult to find out the possible files at startup. (= impossible) A workaround would be to open a destination only when some output is written there, but this would require quite big changes in syslog-ng internally. The same effect you proposed above could be done using some config file generation script: for fac in mail news auth; do for lev in crit alert debug; do cat syslog-ng.template | sed -e "s/\$\{facility\}/$fac/g" -e "s/\$\{level\}/$lev" done done -- Bazsi

1 0