- syslog-ng - lists.balabit.hu

Information request
by Rui Teixeira 22 Sep '03

22 Sep '03

Hi to all, I'm a student finishing a degree in Computer Science (Informatic Engenier) with a final project with the name "XML - based Logging Platform". The main ideia of the project is to convert the current log's into XML so that they can be kept in disk for future use (backup) and inserted in a Database. I know that most of you may think the use of XML may be unnecessary, but i'm thinking in making a standart so that future student's may upgrade my work and use with other system's. The final part of the project will be making a web interface so that an admin may search the log's for specific information sothat he can compare different services log's to find some sort of information. - a quick example is to find someone connected in a network by DHCP ( you only know the mac address and the ip that DHCP released) by crossing their ip with the log generated by the pop3d service. with this you can find the username and associate the machine to a person. This is just a quick example of the possibilities of crossing the information in a quick and easy way. The main reason for me to write to this list is my interest in using Syslog-ng to generate (if possible) my XML format and to send the data to a secure machine where the infrormation will be kept. My biggest questions are: - can i change the syslog-ng code to a academic work - does the team behind syslog-ng intend to make a simmilar system in a near future - and if is it viable to use Syslog-ng to write my XML standard and send it to a secure machine Thanks in advance Rui Teixeira

2 1

Still getting "Assertion `i == nfds' failed." error
by Dennis Skinner 22 Sep '03

22 Sep '03

Still getting this error: syslog-ng: io.c:270: io_iter: Assertion `i == nfds' failed. syslog-ng version 1.6.0rc3 libol 0.3.10 RedHat 9 I only have 3 sources: internal and 2 udp sources (no /proc/kmsg or /dev/log). It runs fine for a short while and then dies with the above error. Sometimes it runs for a minute or so and sometimes for 15-20 mins without a problem before it dies (logging properly from the various servers while it runs). I had setup the local syslogd to pass its messages to syslog-ng via udp. I stopped syslogd (and klogd) and getting same problem. Tried running both using chroot option and not, same thing. Seems to run forever in debug mode. I can see it does garbage collection every now and then. If it tells you anything, this is what it does during gc: io.c: Preparing fd 9 for writing gc_mark: Marking object of class 'syslog_backend' (0) gc_mark: Marking object of class 'syslog_config' (1) gc_mark: Marking object of class 'resource_list' (2) gc_mark: Marking object of class 'io_fd' (3) gc_mark: Marking object of class 'pkt_buffer' (4) gc_mark: Marking object of class 'io_fd' (4) gc_mark: Marking object of class 'pkt_buffer' (5) gc_mark: Marking object of class 'io_fd' (5) gc_mark: Marking object of class 'pkt_buffer' (6) gc_mark: Marking object of class 'io_fd' (6) gc_mark: Marking object of class 'pkt_buffer' (7) gc_mark: Marking object of class 'io_fd' (7) gc_mark: Marking object of class 'pkt_buffer' (8) gc_mark: Marking object of class 'io_fd' (8) gc_mark: Marking object of class 'pkt_buffer' (9) gc_mark: Marking object of class 'io_fd' (9) gc_mark: Marking object of class 'pkt_buffer' (10) gc_mark: Marking object of class 'io_fd' (10) gc_mark: Marking object of class 'pkt_buffer' (11) gc_mark: Marking object of class 'io_fd' (11) gc_mark: Marking object of class 'log_reader' (12) gc_mark: Marking object of class 'afsocket_source_connection' (13) gc_mark: Marking object of class 'afinet_source' (14) gc_mark: Marking object of class 'inet_address_info' (15) gc_mark: Marking object of class 'object_queue' (15) gc_mark: Marking object of class 'log_source_group' (15) gc_mark: Marking object of class 'log_source_group' (16) gc_mark: Marking object of class 'log_source_driver' (17) gc_mark: Marking object of class 'log_center' (17) gc_mark: Marking object of class 'log_connection' (18) gc_mark: Marking object of class 'log_endpoint_info' (19) gc_mark: Marking object of class 'log_endpoint_info' (20) gc_mark: Marking object of class 'log_endpoint_info' (19) gc_mark: Marking object of class 'log_dest_group' (20) gc_mark: Marking object of class 'affile_dest' (21) gc_mark: Marking object of class 'affile_dest_writer' (22) gc_mark: Marking object of class 'affile_dest_writer' (23) gc_mark: Marking object of class 'affile_dest_writer' (24) gc_mark: Marking object of class 'affile_dest_writer' (25) gc_mark: Marking object of class 'affile_dest_writer' (26) gc_mark: Marking object of class 'affile_dest_writer' (27) gc_mark: Marking object of class 'affile_dest_writer' (28) gc_mark: Marking object of class 'affile_dest_writer' (29) gc_mark: Marking object of class 'log_connection' (19) gc_mark: Marking object of class 'log_endpoint_info' (20) gc_mark: Marking object of class 'log_source_group' (21) gc_mark: Marking object of class 'afinet_source' (22) gc_mark: Marking object of class 'inet_address_info' (23) gc_mark: Marking object of class 'object_queue' (23) gc_mark: Marking object of class 'afsocket_source_connection' (24) gc_mark: Marking object of class 'io_fd' (25) gc_mark: Marking object of class 'log_reader' (26) gc_mark: Marking object of class 'afsocket_source_close_callback' (26) gc_mark: Marking object of class 'log_endpoint_info' (20) gc_mark: Marking object of class 'log_dest_group' (21) gc_mark: Marking object of class 'affile_dest' (22) gc_mark: Marking object of class 'afsocket_source_close_callback' (12) gc_mark: Marking object of class 'UNKNOWN' (1) gc_mark: Marking object of class 'affile_dest_reaper' (1) gc_mark: Marking object of class 'affile_dest_reaper' (1) gc_mark: Marking object of class 'affile_dest_reaper' (1) gc_mark: Marking object of class 'affile_dest_reaper' (1) gc_mark: Marking object of class 'affile_dest_reaper' (1) gc_mark: Marking object of class 'affile_dest_reaper' (1) gc_mark: Marking object of class 'affile_dest_reaper' (1) gc_mark: Marking object of class 'affile_dest_reaper' (1) io.c: Preparing fd 10 for writing Marking fd 12 for closing. Any other ideas? -- Dennis Skinner Systems Administrator BlueFrog Internet http://www.bluefrog.com

2 2

RE: [syslog-ng]Feature Request: More flexibility for automatic "l og rotation"
by Hamilton Andrew 22 Sep '03

22 Sep '03

Marc, This has been discussed lots of times over the past couple of years, and while the things you are asking for seem fairly simple they would add to syslog-ng's complexity. That may not seem like a bad thing but keep in mind that for log intensive networks using a central server, every little bit makes a difference. I think for the most part we on this list have agreed that syslog-ng is to be a logger, and for log rotation you would use a different application, that way everyone that uses syslog-ng would be able to rotate their logs as they see fit. I don't know what platform you are working on but there are a lot of good log rotaters out there. Your ideas are sound but IMO syslog-ng needs to be just a logger. Regards, Drew -----Original Message----- From: Marc Haber [mailto:mh+syslog-ng@zugschlus.de] Sent: Monday, September 22, 2003 7:26 AM To: syslog-ng(a)lists.balabit.hu Subject: [syslog-ng]Feature Request: More flexibility for automatic "log rotation" Hi, I am pretty new to this list. Pardon me if this has been discussed recently, but I'd like to hear the opinion of other syslog-ng users and the author. I am responsible for a number of hosts that use aide as a file system based intrusion detection system. Using aide is quite incompatible with the conservative way of rotating logs since all rotated files change their names on each rotation when logrotate is used (moving foo.n.gz to foo.n+1.gz, compressing foo.1 to foo.2.gz, moving foo to foo.1 and creating a new foo). In this place, syslog-ng's ability to expand log file names and thus directly log to files like syslog.20030911 comes in quite handy. However, some of our hosts generate very small log files, and having one log file per day would greatly increase the number of files. Hence, these hosts currently have their logrotate configured to rotate the log file when it exceeds the size of 6 MB. I'd like to have this behavior natively in syslog-ng. The following proposed changes to the file() driver will allow me to solve my problems, but they're pretty radical since they change some of the file() driver's fundamental semantics while preserving backwards compatibility. A state file is used, which can be regarded as ugly. Another possibility would be to leave file() as it is and to create a new destination driver that could probably be called stateful_file(). I am proposing to introduce the following new options for the file destination driver: Name Type Description state_file() string Set the path to the state file for this file() instance create_new_size() number After exceeding the size given here, create new file create_new_freq() time Create new file each <time> seconds create_new_time() string Create new file on a time matching the expression If state_file() is empty, nothing changes. This preserves backwards compatibility of the file() driver. If state_file() is not empty, its argument is expanded for each incoming message and the result taken as the path to a file containing the path to the real log file. After obtaining the path to the real log file, its size and age are checked. If one of the criteria for new file creation is matched, the old file is closed, and a new log file created by expanding the positional parameter to the file() driver. The new file path is written to the state file, replacing the old path. That way, the positional parameter to the file() driver, the name of the log file, is only expanded when a new file should be created instead of with each message. The process of expanding a file name on each message is moved to the state file. Having a state file makes it easier to continue where we left off after syslog-ng was restarted, and it makes it easy for a gzipping cronjob to determine if a non-compressed file in the log directory is still written to by syslog-ng or if it can be safely compressed. I am currently inclined to leave it to the local administrator to specify a log file name mask that will not make new files clash with old ones, but some algorithms to resolve clashes could be implemented as well. For example, a Macro CLASHNUM could be implemented which is guaranteed by syslog-ng to have a value that will make the generated file name unique. That Macro should be expanded last after all other expansions have been done since we need to have the other parts of the file name fixed before we can determine clash or non-clash. While we're at it, I'd appreciate a link() option that specifies a file name that the current log is always linked to. This makes it easier to satisfy processes that want to read from the current syslog by being able to give them a static file name even if the "real" log file has a dynamic name like syslog.yyyymmdd. What do you think about this change? Thank you very much for sharing your opinion. Greetings Marc -- ---------------------------------------------------------------------------- - Marc Haber | "I don't trust Computers. They | Mailadresse im Header Karlsruhe, Germany | lose things." Winona Ryder | Fon: *49 721 966 32 15 Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29 _______________________________________________ syslog-ng maillist - syslog-ng(a)lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html

2 1

bug report: unparsable UDP syslog message
by Thomas Morin 22 Sep '03

22 Sep '03

Hi, First of all I'd like to say I'm impressed by syslog-ng. I think this is a great software: powerful, configurable and elegant. Thanks for making it free software ! That said, I hope a little bug report can improve the thing.. :) Context: I'm using a syslog plugin written for the log4j package (java logging) to send syslog messages to a central log host (syslog-ng 1.6.0rc3). There is one case where some messages are not properly read by syslog-ng, and which trigger "unparsable log message" errors, though they seem to be properly formed syslog messages. The precise packets triggering this case [tcpdump and ethereal helped me a lot here] are UDP syslog packets which are not terminated by a NULL byte, but which contain one or many NEWLINE bytes inside the message, and after some of those NEWLINES we find a '<' character (actually because log4j is used to dump some xml formatted data) : <xx>javaProgram: here is the dump:\n<xml stuff>\n<foo/></xml> The same UDP datagram with a NULL byte in the end doesn't trigger the "unparseable log message" error. The code in src/sources.c (lines 112-120) seems to use the first newline char as the end of line if it doesn't find a '\0', even if this newline char is not the end of our packet. This makes the < of '<xml' be seen as the start of a syslog message, and syslog-ng then tries to interpret '<xml stuff>' as a syslog standard prefix, which of course fails, so we got this "unparseable log message" error. At least, that's what I would concluded, but I'm not C expert, nor very knowledgeable about syslog-ng. If I read the RFC well, not terminating a syslog message by a NULL byte is fine, so I would say this is a syslog-ng bug. I hope the information provided can help you correct this bug. Cheers, -Thomas PS: this report was already sent a few days ago, but I wasn't subscribed at the time, and the mail was moderated/filtered, and hasn't reached the list yet... -- == Thomas Morin == PGP Id:8CEA233D Key FP:503BF6CFD3AE8719377B832A02FB94E08CEA233D --

1 1

Feature Request: More flexibility for automatic "log rotation"
by Marc Haber 22 Sep '03

22 Sep '03

Hi, I am pretty new to this list. Pardon me if this has been discussed recently, but I'd like to hear the opinion of other syslog-ng users and the author. I am responsible for a number of hosts that use aide as a file system based intrusion detection system. Using aide is quite incompatible with the conservative way of rotating logs since all rotated files change their names on each rotation when logrotate is used (moving foo.n.gz to foo.n+1.gz, compressing foo.1 to foo.2.gz, moving foo to foo.1 and creating a new foo). In this place, syslog-ng's ability to expand log file names and thus directly log to files like syslog.20030911 comes in quite handy. However, some of our hosts generate very small log files, and having one log file per day would greatly increase the number of files. Hence, these hosts currently have their logrotate configured to rotate the log file when it exceeds the size of 6 MB. I'd like to have this behavior natively in syslog-ng. The following proposed changes to the file() driver will allow me to solve my problems, but they're pretty radical since they change some of the file() driver's fundamental semantics while preserving backwards compatibility. A state file is used, which can be regarded as ugly. Another possibility would be to leave file() as it is and to create a new destination driver that could probably be called stateful_file(). I am proposing to introduce the following new options for the file destination driver: Name Type Description state_file() string Set the path to the state file for this file() instance create_new_size() number After exceeding the size given here, create new file create_new_freq() time Create new file each <time> seconds create_new_time() string Create new file on a time matching the expression If state_file() is empty, nothing changes. This preserves backwards compatibility of the file() driver. If state_file() is not empty, its argument is expanded for each incoming message and the result taken as the path to a file containing the path to the real log file. After obtaining the path to the real log file, its size and age are checked. If one of the criteria for new file creation is matched, the old file is closed, and a new log file created by expanding the positional parameter to the file() driver. The new file path is written to the state file, replacing the old path. That way, the positional parameter to the file() driver, the name of the log file, is only expanded when a new file should be created instead of with each message. The process of expanding a file name on each message is moved to the state file. Having a state file makes it easier to continue where we left off after syslog-ng was restarted, and it makes it easy for a gzipping cronjob to determine if a non-compressed file in the log directory is still written to by syslog-ng or if it can be safely compressed. I am currently inclined to leave it to the local administrator to specify a log file name mask that will not make new files clash with old ones, but some algorithms to resolve clashes could be implemented as well. For example, a Macro CLASHNUM could be implemented which is guaranteed by syslog-ng to have a value that will make the generated file name unique. That Macro should be expanded last after all other expansions have been done since we need to have the other parts of the file name fixed before we can determine clash or non-clash. While we're at it, I'd appreciate a link() option that specifies a file name that the current log is always linked to. This makes it easier to satisfy processes that want to read from the current syslog by being able to give them a static file name even if the "real" log file has a dynamic name like syslog.yyyymmdd. What do you think about this change? Thank you very much for sharing your opinion. Greetings Marc -- ----------------------------------------------------------------------------- Marc Haber | "I don't trust Computers. They | Mailadresse im Header Karlsruhe, Germany | lose things." Winona Ryder | Fon: *49 721 966 32 15 Nordisch by Nature | How to make an American Quilt | Fax: *49 721 966 31 29

1 0

Network Intelligence
by Gianpiero Porchia 19 Sep '03

19 Sep '03

Hi, I'm going to evaluate a Network Intelligence solutions, for log aggregation purposes. What do you think about their system (Envision)? I know that the system is Windows based, so to be more secure I would like to use a syslog-ng server as log relayer, and then send the logs to Envision. What do you think about that? Thanks in advance. - gian _____ Ing. Gianpiero Porchia Security Engineer ATS - Advanced Telecom Systems Designing, Testing, Managing Network Quality Via Salgari, 17 - 41100 Modena - ITALY Tel +39 059 821332 Fax +39 059 821492 Cel +39 335 330413 E-mail: gianpiero.porchia(a)atsweb.it messenger.msn.com: http://messenger.msn.com/, gianpiero.porchia(a)atsweb.it Web site: http://www.atsweb.it PGP Key ID: 0xCAE064A4 (pgpkeys.mit.edu:11371) Fingerprint: 080D AD88 C18A FCA3 91BC 0DF2 F05F 7489 CAE0 64A4

1 0

Year in the log
by Zhou, Tao (Tao) 18 Sep '03

18 Sep '03

Is there a way for syslog-ng to include year in a logged message? For example, Sep 17 2003 20:00:00 ... Thanks. Tao Zhou

2 1

bug report: unparsable UDP syslog message
by Thomas Morin 18 Sep '03

18 Sep '03

Hi, First of all I'd like to say I'm impressed by syslog-ng. I think this is a great software: powerful, configurable and elegant. Thanks for making it free software ! That said, I hope a little bug report can improve the thing.. :) Context: I'm using a syslog plugin written for the log4j package (java logging) to send syslog messages to a central log host (syslog-ng 1.6.0rc3). There is one case where some messages are not properly read by syslog-ng, and which trigger "unparsable log message" errors, though they seem to be properly formed syslog messages. The precise packets triggering this case [tcpdump and ethereal helped me a lot here] are UDP syslog packets which are not terminated by a NULL byte, but which contain one or many NEWLINE bytes inside the message, and after some of those NEWLINES we find a '<' character (actually because log4j is used to dump some xml formatted data) : <xx>javaProgram: here is the dump:\n<xml stuff>\n<foo/></xml> The same UDP datagram with a NULL byte in the end doesn't trigger the "unparseable log message" error. The code in src/sources.c (lines 112-120) seems to use the first newline char as the end of line if it doesn't find a '\0', even if this newline char is not the end of our packet. This makes the < of '<xml' be seen as the start of a syslog message, and syslog-ng then tries to interpret '<xml stuff>' as a syslog standard prefix, which of course fails, so we got this "unparseable log message" error. At least, that's what I would concluded, but I'm not C expert, nor very knowledgeable about syslog-ng. If I read the RFC well, not terminating a syslog message by a NULL byte is fine, so I would say this is a syslog-ng bug. I hope the information provided can help you correct this bug. Cheers, -Thomas PS: please Cc me any answer since I'm not subscribed to this mailing list. -- == Thomas Morin == PGP Id:8CEA233D Key FP:503BF6CFD3AE8719377B832A02FB94E08CEA233D --

1 0

RE: [syslog-ng]New user of syslog-ng..problems with installation
by Christoph.Eckart＠COMPUTACENTER.COM 17 Sep '03

17 Sep '03

I did it - thx Best regards Christoph Eckart

1 0

RE: [syslog-ng]New user of syslog-ng..problems with installation
by Christoph.Eckart＠COMPUTACENTER.COM 17 Sep '03

17 Sep '03

It's Red Hat 9 and i will get the following output: First i type "./configure && make && make install" and get something like that: loading cache ./config.cache checking for a BSD compatible install... (cached) /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... (cached) yes checking for working aclocal... found checking for working autoconf... found checking for working automake... found checking for working autoheader... found checking for working makeinfo... found checking whether build environment is sane... yes checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for bison... (cached) bison -y checking how to run the C preprocessor... (cached) gcc -E checking for flex... (cached) flex checking for flex... (cached) flex checking for yywrap in -lfl... (cached) yes checking lex output file root... (cached) lex.yy checking whether yytext is a pointer... (cached) yes checking whether make sets ${MAKE}... (cached) yes checking for ANSI C header files... (cached) yes checking for malloc.h... (cached) yes checking for unistd.h... (cached) yes checking for door.h... (cached) no checking for stropts.h... (cached) yes checking for sys/strlog.h... (cached) no checking for stdarg.h... (cached) yes checking for sys/klog.h... (cached) yes checking for arpa/nameser.h... (cached) yes checking for tcpd.h... (cached) yes checking for working const... (cached) yes checking whether time.h and sys/time.h may both be included... (cached) yes checking for modern utmp... (cached) yes checking whether to compile klogctl... yes checking size of short... (cached) 2 checking size of int... (cached) 4 checking size of long... (cached) 4 checking for I_CONSLOG... (cached) no checking for O_LARGEFILE... (cached) yes checking for res_init in <resolv.h>... (cached) yes checking for working alloca.h... (cached) yes checking for alloca... (cached) yes checking for vprintf... (cached) yes checking for res_init in -lresolv... (cached) no checking for __res_init in -lresolv... (cached) yes checking for door_create in -ldoor... (cached) no checking for socket in -lsocket... (cached) no checking for gethostbyname in -lnsl... (cached) yes checking for select... (cached) yes checking for snprintf... (cached) yes checking for vsnprintf... (cached) yes checking for strerror... (cached) yes checking for inet_aton... (cached) yes checking for strncpy... (cached) yes checking for getutent... (cached) yes checking for getopt_long... (cached) yes checking for strcasecmp... (cached) yes checking for strptime... (cached) yes checking for TCP wrapper library... (cached) -lwrap checking whether to enable Sun STREAMS support... no checking whether to enable Sun door support... no checking whether to enable TCP wrapper support... no checking libol version >= 0.3.9... which: no libol-config in (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin) ./configure: line 1: libol-config: command not found ./configure: line 1: libol-config: command not found ./configure: line 1: libol-config: command not found ./configure: line 3084: test: : integer expression expected ok creating ./config.status creating Makefile creating src/Makefile creating src/tests/Makefile creating doc/Makefile creating doc/sgml/Makefile creating contrib/Makefile creating syslog-ng.spec creating src/config.h src/config.h is unchanged Making all in src make[1]: Entering directory `/usr/local/syslog-ng-1.6.0rc3/src' make all-recursive make[2]: Entering directory `/usr/local/syslog-ng-1.6.0rc3/src' Making all in . make[3]: Entering directory `/usr/local/syslog-ng-1.6.0rc3/src' gcc -DHAVE_CONFIG_H -I. -I/usr/local/syslog-ng-1.6.0rc3/src -I. -g -O2 -Wall -D_GNU_SOURCE -c main.c In file included from main.c:26: syslog-ng.h:31:21: objects.h: No such file or directory In file included from cfgfile.h:29, from main.c:27: sources.h:30:23: read_line.h: No such file or directory In file included from sources.h:32, from cfgfile.h:29, from main.c:27: log.h:30:16: io.h: No such file or directory In file included from sources.h:32, from cfgfile.h:29, from main.c:27: log.h:39: parse error before "UINT32" log.h:39: warning: no semicolon at end of struct or union log.h:43: parse error before "pri" log.h:43: warning: type defaults to `int' in declaration of `pri' log.h:43: warning: data definition has no type or storage class log.h:44: parse error before "flags" log.h:44: warning: type defaults to `int' in declaration of `flags' log.h:44: warning: data definition has no type or storage class log.h:51: parse error before '}' token In file included from log.h:54, from sources.h:32, from cfgfile.h:29, from main.c:27: log.h.x:4: field `super' has incomplete type log.h.x:9: confused by earlier errors, bailing out make[3]: *** [main.o] Error 1 make[3]: Leaving directory `/usr/local/syslog-ng-1.6.0rc3/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/syslog-ng-1.6.0rc3/src' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/usr/local/syslog-ng-1.6.0rc3/src' make: *** [all-recursive] Error 1 After that i type "./configure" and the messages i will get is: loading cache ./config.cache checking for a BSD compatible install... (cached) /usr/bin/install -c checking whether build environment is sane... yes checking whether make sets ${MAKE}... (cached) yes checking for working aclocal... found checking for working autoconf... found checking for working automake... found checking for working autoheader... found checking for working makeinfo... found checking whether build environment is sane... yes checking for gcc... (cached) gcc checking whether the C compiler (gcc ) works... yes checking whether the C compiler (gcc ) is a cross-compiler... no checking whether we are using GNU C... (cached) yes checking whether gcc accepts -g... (cached) yes checking for gcc option to accept ANSI C... (cached) none needed checking for bison... (cached) bison -y checking how to run the C preprocessor... (cached) gcc -E checking for flex... (cached) flex checking for flex... (cached) flex checking for yywrap in -lfl... (cached) yes checking lex output file root... (cached) lex.yy checking whether yytext is a pointer... (cached) yes checking whether make sets ${MAKE}... (cached) yes checking for ANSI C header files... (cached) yes checking for malloc.h... (cached) yes checking for unistd.h... (cached) yes checking for door.h... (cached) no checking for stropts.h... (cached) yes checking for sys/strlog.h... (cached) no checking for stdarg.h... (cached) yes checking for sys/klog.h... (cached) yes checking for arpa/nameser.h... (cached) yes checking for tcpd.h... (cached) yes checking for working const... (cached) yes checking whether time.h and sys/time.h may both be included... (cached) yes checking for modern utmp... (cached) yes checking whether to compile klogctl... yes checking size of short... (cached) 2 checking size of int... (cached) 4 checking size of long... (cached) 4 checking for I_CONSLOG... (cached) no checking for O_LARGEFILE... (cached) yes checking for res_init in <resolv.h>... (cached) yes checking for working alloca.h... (cached) yes checking for alloca... (cached) yes checking for vprintf... (cached) yes checking for res_init in -lresolv... (cached) no checking for __res_init in -lresolv... (cached) yes checking for door_create in -ldoor... (cached) no checking for socket in -lsocket... (cached) no checking for gethostbyname in -lnsl... (cached) yes checking for select... (cached) yes checking for snprintf... (cached) yes checking for vsnprintf... (cached) yes checking for strerror... (cached) yes checking for inet_aton... (cached) yes checking for strncpy... (cached) yes checking for getutent... (cached) yes checking for getopt_long... (cached) yes checking for strcasecmp... (cached) yes checking for strptime... (cached) yes checking for TCP wrapper library... (cached) -lwrap checking whether to enable Sun STREAMS support... no checking whether to enable Sun door support... no checking whether to enable TCP wrapper support... no checking libol version >= 0.3.9... which: no libol-config in (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/X11R6/bin:/root/bin) ./configure: line 1: libol-config: command not found ./configure: line 1: libol-config: command not found ./configure: line 1: libol-config: command not found ./configure: line 3084: test: : integer expression expected ok creating ./config.status creating Makefile creating src/Makefile creating src/tests/Makefile creating doc/Makefile creating doc/sgml/Makefile creating contrib/Makefile creating syslog-ng.spec creating src/config.h src/config.h is unchanged And "make" shows me: Making all in src make[1]: Entering directory `/usr/local/syslog-ng-1.6.0rc3/src' make all-recursive make[2]: Entering directory `/usr/local/syslog-ng-1.6.0rc3/src' Making all in . make[3]: Entering directory `/usr/local/syslog-ng-1.6.0rc3/src' gcc -DHAVE_CONFIG_H -I. -I/usr/local/syslog-ng-1.6.0rc3/src -I. -g -O2 -Wall -D_GNU_SOURCE -c main.c In file included from main.c:26: syslog-ng.h:31:21: objects.h: No such file or directory In file included from cfgfile.h:29, from main.c:27: sources.h:30:23: read_line.h: No such file or directory In file included from sources.h:32, from cfgfile.h:29, from main.c:27: log.h:30:16: io.h: No such file or directory In file included from sources.h:32, from cfgfile.h:29, from main.c:27: log.h:39: parse error before "UINT32" log.h:39: warning: no semicolon at end of struct or union log.h:43: parse error before "pri" log.h:43: warning: type defaults to `int' in declaration of `pri' log.h:43: warning: data definition has no type or storage class log.h:44: parse error before "flags" log.h:44: warning: type defaults to `int' in declaration of `flags' log.h:44: warning: data definition has no type or storage class log.h:51: parse error before '}' token In file included from log.h:54, from sources.h:32, from cfgfile.h:29, from main.c:27: log.h.x:4: field `super' has incomplete type log.h.x:9: confused by earlier errors, bailing out make[3]: *** [main.o] Error 1 make[3]: Leaving directory `/usr/local/syslog-ng-1.6.0rc3/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/usr/local/syslog-ng-1.6.0rc3/src' make[1]: *** [all-recursive-am] Error 2 make[1]: Leaving directory `/usr/local/syslog-ng-1.6.0rc3/src' make: *** [all-recursive] Error 1 It's a closed book for me - sorry! Please help... Best regards Christoph Eckart European Information Management CC CompuNet AG & Co. oHG A part of Computacenter plc Europaring 34-40, 50170 Kerpen, Germany Phone: +49 (0)2273 597-68072, , E-Mail : Christoph.Eckart(a)COMPUTACENTER.COM Visit us on the Internet: http://www.computacenter.com This email is confidential. If you are not the intended recipient, you must not disclose or use the information contained in it. If you have received this mail in error, please tell us immediately by return email and delete the document.

1 0