- syslog-ng - lists.balabit.hu

syslog-ng 1.1.29
by Balazs Scheidler 26 Jul '99

26 Jul '99

Hi, I have silently released 1.1.29 of syslog-ng, which contains the previous patch I posted here against 1.1.28. This contains the single quotation marks patch, so that you can specify regexps more easily. Tell me if you have problems. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt

1 0

Weird behavior
by Nathaniel Couper-Noles 22 Jul '99

22 Jul '99

I have setup syslog-ng version 1.1.27 on a i386 running a (nearly) pure Debian Linux 2.1 install, libol version 0.2. This machine is being used to collect logs sent from NT machines running a program called EventSlog. I am trying to use the match() function to direct logs containing the string "/Security (" to a file bob.security, logs containing the string "/Applications (" to a file bob.app, logs containing the string "/SYSTEM (" to a file called bob.system, and logs that contain none of these strings to a file called bob.misc. My first attempt at this is in the first attachment to this document. It erred by redirecting all of the logs to each of the three files bob.app, bob.security, and bob.system all of the input to port 514. bob.misc was empty. Figuring perhaps that multiple filters aren't and'ed together in a log statement, I then wrote the conditional statements inside the filters, as in the second attachment to this email. This setup erred in the same way. I noticed also that the appropriately syntaxed configurations would behave similarly using syslog-ng version 1.2.23 and libol 0.1.19. Am I misusing the match() call? Or perhaps the logical connectors? Thanks for a great program! PS if there is a syntactical error in the files it is because I copied them wrong...syslog-ng always ran without explicit error... PPS I noticed the version-printing command line option syslog-ng -V does not work...though it is listed in the man page. _______________________________________________ Nathaniel Couper-Noles Department of Information Techonology School of Social Administration University of Chicago options { long_hostnames(off); sync(0); }; # sources source ntboxes { udp ( port(514) ); }; source sysl-ng { internal(); }; # destinations destination bob.security { file ("/var/log/bob.security"); }; destination bob.system { file ("/var/log/bob.system"); }; destination bob.app { file ("/var/log/bob.app"); }; destination bob.misc { file ("/var/log/bob.misc"); }; # filters filter f_security { match ("/Security ("); }; filter f_app { match ("/Application ("); }; filter f_system { match ("/SYSTEM ("); }; filter f_misc { not match ("/Security (") and not match ("/SYSTEM (") and not match ("/Application ("); }; filter f_bob { host ("bob"); }; # logs log { source (ntboxes); filter (f_bob); filter (f_security); destination (bob.security); }; log { source (ntboxes); filter (f_bob); filter (f_system); destination (bob.system); }; log { source (ntboxes); filter (f_bob); filter (f_app); destination (bob.app); }; log { source (ntboxes); filter (f_bob); filter (f_misc); destination (bob.misc); }; options { long_hostnames(off); sync(0); }; # sources source ntboxes { udp ( port(514) ); }; source sysl-ng { internal(); }; # destinations destination bob.security { file ("/var/log/bob.security"); }; destination bob.system { file ("/var/log/bob.system"); }; destination bob.app { file ("/var/log/bob.app"); }; destination bob.misc { file ("/var/log/bob.misc"); }; # filters filter f_bob_security { host ("bob") and match ("/Security ("); }; filter f_bob_app { host ("bob") and match ("/Application ("); }; filter f_bob_system { host ("bob") and match ("/SYSTEM ("); }; filter f_bob_misc { host ("bob") and not match ("/Security (") and not match ("/SYSTEM (") and not match ("/Application ("); }; # logs log { source (ntboxes); filter (f_bob_app); destination (bob.security); }; log { source (ntboxes); filter (f_bob_security); destination (bob.system); }; log { source (ntboxes); filter (f_bob_system); destination (bob.app); }; log { source (ntboxes); filter (f_bob_misc); destination (bob.misc); };

2 1

elso kerdes :) (fwd)
by Boda Karoly jr. 22 Jul '99

22 Jul '99

Udvozletem mindenkinek ! Uj vagyok a listan, kezdem is egy kerdessel :) adott a kovetkezo konfigreszlet: source src { unix-stream("/dev/log"); internal(); }; source net { udp(); }; destination console_all { file("/dev/tty13"); }; destination mailconsolerhye { file("/dev/tty22"); }; destination mailconsolerusalka { file("/dev/tty23"); }; destination rusalkalog { file("/dev/tty24"); }; filter f_mail { facility(mail); }; filter n_mail {not facility(mail); }; log { source(src); filter(n_mail); destination(console_all); }; log { source(src); filter(f_mail); destination(mailconsolerhye); }; log { source(net); filter(f_mail); destination(mailconsolerusalka); }; log { source(net); filter(n_mail); destination(rusalkalog); }; A kerdes a kovetkezo: A /dev/tty23-ra miert kerul az _osszes_ maillog, az is, ami a src-bol van ? A /dev/tty22 jol mukodik, oda csak a megfelelo mailuzenetek kerulnek. A /dev/tty13 es a /dev/tty24 szinten jol mukodnek, nem kerulnek oda a maillogok. -- Woockie ..."what is there in this world that makes living worthwhile?" Death thought about it. "CATS," he said eventually, "CATS ARE NICE." (Terry Pratchett, Sourcery)

1 0

syslog-ng-1.1.28
by georg.funke＠netcologne.de 22 Jul '99

22 Jul '99

Hi, you have forgot to patch configure, to work with libol-0.2.1, at the moment it insist on libol-0.2.0. After i patch this, it compiles well. Georg -- Georg Funke Crowns & Flames SDC Cologne, Germany; http://www.geocities.com/Colosseum/4893 "Friendship is Square Dancing's greatest Reward"

2 1

syslog-ng 1.1.28
by Balazs Scheidler 21 Jul '99

21 Jul '99

Hi, I have released syslog-ng 1.1.28 and libol 0.2.1 to fix the bugs that appeared on this mailing list lately: syslog-ng: * on *BSD recvfrom() does not return the source address on connection-oriented sockets (e.g. on TCP channels the source hostname was not found correctly) * The parser took two variables the same if they began with the same string libol: * the number of pending callouts were not counted correctly, so when syslog-ng was restarted via the HUP signal, it may have terminated because no event handlers were left. Otherwise syslog-ng were quite stable, so if nothing goes wrong at the end of July, I'll release 1.2.0. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt

1 0

Re: syslog-ng: new destination driver
by Balazs Scheidler 21 Jul '99

21 Jul '99

cc-ing to the syslog-ng mailing list. On Mon, Jul 19, 1999 at 03:31:21PM -0700, Jeremy Fitzhardinge wrote: > Hi, > > We need a syslog which can parse messages and then farm them out to > other alert mechanisms, which are dynamic and configurable, such as SNMP > traps, emails, pagers, etc... My original idea was to add a regexp > mechanism to syslog and fire off lines which match to the various > programs. After looking around, it looks like your syslog-ng is the > closest to our requirements, but it doesn't have the mechanism to > actually send lines to a program. Indeed it does, but the program statement you suggest below is on my todo list. To send lines to a program, you could use a named pipe. mkfifo /var/run/pager the program would then: #!/bin/sh cat /var/run/pager | batch_and_send and in syslog-ng declare a destination: destination { pipe("/var/run/pager"); }; However since it's impossible to pass arguments to the given script this way, a program destination driver should - and will - be implemented. > > I'm thinking of something along the lines of: > > destination pager { prog("/usr/local/bin/pager.pl") }; > > Each destination using a prog() would start a new instance, which is > persistent for the duration of syslog's life. This is so that they can > batch things together, rather than sending one email for each line of a > multi-line message. > > I've been going through the source to see how to implement it, and it > looks pretty clean. The only thing I don't understand is all the .x > files and make_class. How do these fit together, and what do I need to > do to implement a new afprog.*? syslog-ng uses make_class as a preprocessor to create data structures for object classes, and to generate code needed by the mark & sweep garbage collector. To create a new destination driver, you would create a class from (or directly use) log_dest_driver defined in destinations.h. If you look at affile.c (as one of the simplest destination driver), it derives a class: /* CLASS: (class (name affile_dest) (super log_dest_driver) (vars (name string) (flags simple int) (dest object io_fd) (dest_buf object abstract_buffer) (sync_freq simple UINT32))) */ The constructor of a class is called make_<classname> by convention, so affile_dest is created by make_affile_dest: struct log_dest_driver *make_affile_dest(const char *name, int flags) { NEW(affile_dest, self); self->super.super.init = do_init_affile_dest; self->super.super.handler = do_handle_affile_log; self->super.log_fifo_size = -1; self->name = c_format_cstring("%z", name); self->flags = flags; self->sync_freq = -1; /* use global setting */ return &self->super; } This returns "struct log_dest_driver *" because the derived class itself is private to this module, and externally only the log_dest_driver is known. NEW creates a new instance of affile_dest, and stores a pointer to this instance in self. Then the method pointers are initialized. Internally log messages flow in log-pipes: log_source_driver -> log_source_group -> log_center -> log_dest_group -> log_dest_driver Several log_source_drivers may point to the same source_group, and several source_groups may point to a log_center. There's only one log_center per configuration, and log_center is the one which applies filter rules, and in case they match, it chooses the appropriate log_dest_group, thus sends the log message to all the log_dest_driver belonging to that group. An element of this pipe must be a descendant of log_handler (defined in log.h) Since several element has a next pointer (all except the last log_dest_driver) a less general class: log_handler_pipe is introduced here, which has an additional next field. The above pipe is constructed as the configuration file is read, and if the configuration is found to be syntactically valid, everything is initialized. (this is log_handler.init) Source drivers open source sockets, and install read hooks to get events on them. As a message is read it is passed towards the central log_center using the next->handler method. There's an optional method in log_handlers, which is called destroy. It is called when the log pipe is destroyed. So this is the internal data structure in syslog-ng, for detailed information about the class definition language parsed by make_class, download lsh (ftp://ftp.lysator.liu.se/pub/security/lsh/lsh*.tar.gz) and read the file HACKING. make_class requires scsh (Scheme shell) to run, though make_class is being ported to more free implementations of scheme, like guile. I hope this helps, -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt

2 1

[bazsi@balabit.hu: Re: [syslog-ng] Re: bug?]
by Balazs Scheidler 19 Jul '99

19 Jul '99

This mail contains two patches you may be interested in. (especially under *BSD) ----- Forwarded message from Balazs Scheidler <bazsi(a)balabit.hu> ----- Date: Mon, 19 Jul 1999 23:42:49 +0200 From: Balazs Scheidler <bazsi(a)balabit.hu> To: joeym(a)inficad.com Subject: Re: [syslog-ng] Re: bug? > > Sometimes when I SIGHUP syslog-ng (client or server), I will get this > too: > > SIGHUP received, restarting syslog-ng > new configuration initialized > io_iter(): no waiting fds and no callouts! exiting... > > However, every once in a while, it will say 'new configuration > initilized' and keep right on going. But most of the time, it gives the > io_iter() err and exits. Please try this patch against libol: --- libol-0.2.0/src/io.c Sat Jul 10 15:23:09 1999 +++ libol/src/io.c Mon Jul 19 23:04:46 1999 @@ -268,9 +268,7 @@ ol_queue_remove(&n->header); ol_space_free(n); } - else { - nco++; - } + nco++; } } if (!nfds && !nco) { The other problem should be BSD specific. (or my solution is Linux specific some way. I assumed that recvfrom() on connected sockets return the source address of the connection, but as it seems under BSD this is not the case.) Try the following somewhat (ugly) patch, to see if this is the problem: --- syslog-ng-1.1.27/src/afsocket.c Sat Jul 10 17:58:33 1999 +++ syslog-ng/src/afsocket.c Mon Jul 19 23:22:37 1999 @@ -106,6 +106,16 @@ static void do_handle_afinet_line(struct log_handler *c, struct log_info *msg) { CAST(afsocket_source_connection, self, c); + if (!msg->saddr) { + char sockaddr_buf[256]; + struct sockaddr *sa = (struct sockaddr *) &sockaddr_buf; + int salen = sizeof(sockaddr_buf); + + if (getpeername(self->fd, sa, &salen) != -1) { + msg->saddr = ol_space_alloc(salen); + memcpy(msg->saddr, sa, salen); + } + } HANDLE_LOG(self->super.next, msg); } I've fixed another problem not reported by you. Variable names beginning with the same bytestring (e.g. f_router & f_router_acct) were resolved incorrectly. Check out the mailing list (or the archive at http://lists.balabit.hu/pipermail) for that patch. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt ----- End forwarded message ----- -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt

1 0

Re: syslog-ng parser bug?
by Balazs Scheidler 19 Jul '99

19 Jul '99

On Mon, Jul 19, 1999 at 07:11:55PM +0200, Rolf Offermanns wrote: > Hi Balazs! > I think I have found a bug in the config file parser in 1.2.27. > I will try to describe it as exactly as my english allows me to... Thanks for the report. The problem was that the first few bytes of those variable names were the same, so the same filter rule was applied to both log statement. Try this patch: --- syslog-ng-1.1.27/src/cfgfile.c Sat Jul 10 17:58:33 1999 +++ syslog-ng/src/cfgfile.c Mon Jul 19 23:38:44 1999 @@ -18,7 +18,7 @@ * * Inspired by nsyslog, originally written by Darren Reed. * - * $Id: cfgfile.c,v 1.17 1999/07/10 15:58:33 bazsi Exp $ + * $Id: cfgfile.c,v 1.18 1999/07/18 12:56:11 bazsi Exp $ * ***************************************************************************/ @@ -62,7 +62,8 @@ #define RESOLVE_VAR(s, first, next, i) \ for (s = first; s; s = s->next) { \ - if (strncmp(i->name->data, s->name->data, i->name->length) == 0) { \ + if (i->name->length == s->name->length && \ + strncmp(i->name->data, s->name->data, i->name->length) == 0) { \ i->ref = (struct ol_object *) s; \ break; \ } \ @@ -154,7 +155,7 @@ self->init = do_init_config; self->destroy = do_destroy_config; self->backend = backend; - self->sync_freq = 1; + self->sync_freq = 0; self->mark_freq = 1200; /* 20 minutes */ self->long_hostnames = 1; self->time_reopen = 60; -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt

1 0

Re: bug?
by Balazs Scheidler 18 Jul '99

18 Jul '99

Hi, Thanks for reporting this. I am going to fix these as soon as I'll have some time. On Wed, Jul 14, 1999 at 10:15:06AM -0700, joeym(a)inficad.com wrote: > Sorry to bother you again, but I have noticed some strange behavior when > logging over TCP. > > Client Machine is BSDI 4.0 running syslog-ng. 'Server' machine is > FreeBSD 3.2-STABLE running syslog-ng and receiving UDP, TCP, and local > syslog msgs. When the client machine sends messages via UDP back to the > server machine, the server machine sees the tag as the correct hostname. > When the messages are sent from the client -> server via TCP, then the > server marks those messages as coming from its own hostname, and not the > client's hostname. > > Also, I noticed that sending SIGHUP to syslog-ng on the BSDI client > machine causes this message (in debug mode) to be sent : > new configuration initialized > io_iter(): no waiting fds and no callouts! exiting... > > and then it exits.. If i SIGHUP syslog-ng on the 'server' machine, it > reloads its config and moves happily on. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt

1 1

Re: Small conf suggestion
by Balazs Scheidler 13 Jul '99

13 Jul '99

On Mon, Jul 12, 1999 at 09:01:21PM -0700, joey miller wrote: > I'm currently evaluating syslog-ng for use as a central syslog server in > our facilities, and have come across something that may cut down similar > setups (config file wise) like what I'm implementing by a large margin. > > I plan to have multiple hosts log back to a single syslog-ng server, and > am going to keep each machine/Cisco's logs seperated in a structure such > as: > /var/log/machine1.inficad.com/messages > /var/log/machine1.inficad.com/daemon.log > /var/log/routerX.inficad.com/messages > .. etc .. > > However, I've noticed it's going to require multiple (somewhat redundant) > destination {} entries to get this going the way I'd like. What I was > thinking was something along the lines of allowing a replacable string in > a file(); definition. For example, I could do: > > destination d_auth { file("/var/log/$HOST/auth.log"); }; > > This would allow me to have a single entry for the d_auth destination, > instead of requiring a seperate destination{} entry for each machine + log > level. > > If there is something like this available already, please let me know, as > I'm still exploring the syslog-ng package and haven't even begun to > exploit its full potential yet. It is not available yet, but as it has already been suggested by at least 3 people, I'll implement this in 1.3.x series. For now you have to stick to several destination fields. To make this problem easier to maintain, simply write a shell script or such to generate the config file. -- Bazsi PGP info: KeyID 9AF8D0A9 Fingerprint CD27 CFB0 802C 0944 9CFD 804E C82C 8EB1 url: http://www.balabit.hu/pgpkey.txt

1 0