- syslog-ng - lists.balabit.hu

syslog-ng 1.1.24
by Balazs Scheidler 13 Jun '99

13 Jun '99

Hi, This release fixes the solaris compilation bugs. Nothing else is changed now. -- Bazsi PGP key: http://www.balabit.hu/pgpkey.txt, or finger bazsi(a)balabit.hu

4 10

Re: syslog-ng digest, Vol 1 #39 - 14 msgs
by Marcin Okraszewski 13 Jun '99

13 Jun '99

> Yes, it's a good idea. My solution will be that I'll simply call a script > and the local sysadmin can do anything he wants. By default a script which > sends a pgp encrypted message will be supplied. I don't think it is good idea to call external script. It can be simply repleaced by any one who will get root privileges in any way. -- -------------------------------------------------------------------- Marcin Okraszewski mailto:okrasz@vlo.ids.gda.pl http://www.vlo.ids.gda.pl/~okrasz/ -------------------------------------------------------------------- PGP key: http://www.vlo.ids.gda.pl/~okrasz/pgp.txt finger okrasz(a)vlo.ids.gda.pl

2 1

hdd crash
by Balazs Scheidler 13 Jun '99

13 Jun '99

Hi, Sorry for the unresponsiveness from my part but I had a major HDD crash. Luckily I had backups about my most important things, and at the end I could also save the whole disk. Replacement is due next week, so my development efforts will be stalled a bit. I am sorry for not answering mails etc. -- Bazsi

1 0

Re: hashing
by canacar＠ea.eee.metu.edu.tr 10 Jun '99

10 Jun '99

> Or yet another, I like this one best. syslog-ng generates a random value > which it will use to generate hash #0, then a copy of this random value is > sent to the sysadmin in an email message. Later when somebody wants to check > logfile integrity, a copy of this key is needed. This could also be a > security risk if that message remains on the same box. This security risk can be reduced if the message is encrypted using the administrators (pgp) public key. Only the admin with the correct passphrase (and private key) will be able to obtain the random key. Can --=< Can Erkin Acar (canacar(a)bigfoot.com, canacar(a)eee.metu.edu.tr) >=--

1 0

Chroot jails
by Ian Vaudrey 10 Jun '99

10 Jun '99

Hi, Would I be right in thinking that Syslog-ng's ability to use multiple message sources could be useful in building chroot jails on Linux, e.g. would source src { unix-stream /dev/log; /chroot/named/dev/log; internal; }; work in place of using holelogd? - Ian

2 1

RE: [syslog-ng] hashing
by Ian Vaudrey 10 Jun '99

10 Jun '99

On 09 June 1999 18:29, Balazs Scheidler wrote: <snip> > Or yet another, I like this one best. syslog-ng generates a random value > which it will use to generate hash #0, then a copy of this random value is > sent to the sysadmin in an email message. Later when somebody wants to check > logfile integrity, a copy of this key is needed. This could also be a > security risk if that message remains on the same box. I'm very much a *n?x newbie so this may be an incredibly stupid idea, but FWIW how about PGP encrypting the email using the admin's public key? - Ian

2 1

compile problem
by Rob Cermak 10 Jun '99

10 Jun '99

I'd love to trash my current syslogd on Solaris. I'd like to see this work and transmit logging back to a Linux box to collate all the messages. Let me know if you need anything else...willing to take patches to test. I'll see what changed between version .22 and .23... uname -a SunOS magellan1 5.6 Generic_105181-03 sun4m sparc SUNW,SPARCstation-20 System: Solaris 2.6 / # gcc -v Reading specs from /usr/local/lib/gcc-lib/sparc-sun-solaris2.6/egcs-2.90.29/specs gcc version egcs-2.90.29 980515 (egcs-1.0.3 release) syslog-ng-1.1.23 / libol-0.1.19 I compiled the prior release fine, but it core dumped once it was started and I forced a message to the syslog. Compiling the new version I hit this: gcc -DHAVE_CONFIG_H -I. -I/h0/cermak/src/syslog-ng-1.1.23/src -I. -O2 -Wall -I/usr/local/include/libol -c center.c center.c:72: warning: missing braces around initializer for `loglock.__pthread_mutex_flags' center.c: In function `do_distribute_log': center.c:101: warning: implicit declaration of function `pthread_lock_mutex' center.c:105: warning: implicit declaration of function `pthread_unlock_mutex' gcc -O2 -Wall -I/usr/local/include/libol -o syslog-ng main.o sources.o center.o filters.o destinations.o log.o cfgfile.o cfg-grammar.o cfg-lex.o affile.o afsocket.o afinter.o afuser.o afdoor.o utils.o syslog-names.o getopt.c getopt1.c -lpthread -ldoor -ll /usr/local/lib/libol.a -lsocket -lnsl -lxnet Undefined first referenced symbol in file pthread_lock_mutex center.o pthread_unlock_mutex center.o ld: fatal: Symbol referencing errors. No output written to syslog-ng collect2: ld returned 1 exit status *** Error code 1 make: Fatal error: Command failed for target `syslog-ng' Current working directory /h0/cermak/src/syslog-ng-1.1.23/src *** Error code 1 make: Fatal error: Command failed for target `all-recursive'

3 4

hashing
by Balazs Scheidler 09 Jun '99

09 Jun '99

Hi, I am thinking about the way digital hashes on output files should work. Syslog-ng version 1.0.x implemented things this way: The hash #0 is generated using some random salt and a password supplied by the system administrator. The next hash is always generated by the previous one (or #0 if this is the first) and the current log message sent to the file. Each hash is stored in a file. Verifying the hashes is simple, you give the password and check all the written hash entries for validity. The hash algorithm used was sha1, though it could use md5 just as well. The problem with the above approach is logrotation. To be really secure the password may not be saved to the disk, and since starting the hash required a password, new log files cannot be started automatically. A solution could be "delayed hash start". This means, that when logfiles are restarted no starthash is generated, and hashing is not done as long as the system admin logs in, and initializes hashing by giving his password. After initialization, hash is calculated for each message written this far. And hashing could continue as normal. The problem with the above may be that, if huge amounts of log had been written, regenerating hashes could take some time, and could take log service down for a while. Other solution could be "interactive logrotation", where the system administrator would have to give his password to restart logrotation. Or yet another, I like this one best. syslog-ng generates a random value which it will use to generate hash #0, then a copy of this random value is sent to the sysadmin in an email message. Later when somebody wants to check logfile integrity, a copy of this key is needed. This could also be a security risk if that message remains on the same box. Does anybody else have an idea? -- Bazsi PGP key: http://www.balabit.hu/pgpkey.txt, or finger bazsi(a)balabit.hu

1 0

version 1.1.23 released
by Balazs Scheidler 09 Jun '99

09 Jun '99

Hi, I have found the Solaris bug I mentioned yesterday, so I released a new version of syslog-ng, this time 1.1.23. The "bug" was in libol, so I released 0.1.19 of libol as well. Here's the changelog of libol: 1999-06-09 Balazs Scheidler <bazsi(a)balabit.hu> * wait at most 60 seconds in poll (so that pending closes are really closed in at most 60 seconds) * changed fatal() to werror() if the poll fails syslog-ng has not changed since yesterday. The exact bug on solaris has been fixed by the 2nd change above. poll failed in libol since the config file I tested syslog-ng with was referring to /dev/tty as a destination. When syslog-ng forked and became a session leader trying to poll /dev/tty failed. poll() returned an ENXIO error (which by the way is undocumented) and fatal() aborted the program. -- Bazsi PGP key: http://www.balabit.hu/pgpkey.txt, or finger bazsi(a)balabit.hu

1 0

cvs tree
by Balazs Scheidler 09 Jun '99

09 Jun '99

Hi, I could not deal with a solaris bug I encountered, so I don't release any snapshots now. What I have done since last release, and what's available in cvs: 1999-06-08 Balazs Scheidler <bazsi(a)balabit.hu> * named pipes work now with the file driver (I may introduce a pipe driver later on, which could be an alias for "file") * fixed a bug in log_handler.destroy handling * changed -HUP handling, it reverts to the old config if the new cannot be initialized * changed afsocket_dest_reopen to be a general callback, capable of reinitializing any log_handler (and moved to destinations.c) * debian control file fixes (reported by Peter Gervai, grin(a)tolna.net) * internal source driver checks if used once * fixed a bug in syslog-ng.h, which used the config file in cwd even if debugging was turned off 1999-06-06 Balazs Scheidler <bazsi(a)balabit.hu> * added reference documentation to doc/syslog-ng.html * changed the parser, so IDENTIFIER's can always be quoted using quotation marks (") There have been some bugfixes, and the documentation was added to the tree. I have a quite major problem on solaris. As it seems the way syslog-ng exits the parent process when backgrounding itself conflicts with solaris thread libraries. The parent process waits until the configuration is initialized, so no log messages sent directly after syslog-ng backgrounds itself is not lost. This is accomplished via the TERM signal: parent: wait until term signal arrives child: initialize config send SIGTERM to parent The parent exits without problems, but the child gets a SIGABRT for some unknown reason. If I use the -d switch, which prevents syslog-ng to background itself, everything works fine. -- Bazsi PGP key: http://www.balabit.hu/pgpkey.txt, or finger bazsi(a)balabit.hu

2 2