From rgerhards at hq.adiscon.com Wed Jul 6 12:03:35 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 6 Jul 2005 12:03:35 +0200 Subject: [rsyslog] rsyslog 0.9.2 released - with TCP support! Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E354C@grfint2.intern.adiscon.com> Hi all: Good news: rsyslog 0.9.2 is out. Finally, the syslog/tcp receiver has arrived! This is a big step forward for rsyslog. Now, it supports reliable message delivery via TCP. Our implementation is compatible with leading tools and devices like syslog-ng, Cisco PIX and MonitorWare under Windows. Note, however, the 0.9.2 release only supports receiving via TCP. Forwarding is not yet supported. So in a relay chain, rsyslog must be the last daemon to receive the message. Guess what is next on the todo list; ) Syslog/tcp support is activated via a simple command line switch without any need for complex configuration file changes! This time, I have tested rsyslog on FreeBSD immediately and as it looks, it works without any special tricks. I hope the new version is useful. Any feedback is highly appreciated. Rainer From rgerhards at hq.adiscon.com Wed Jul 6 18:36:32 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 6 Jul 2005 18:36:32 +0200 Subject: [rsyslog] bug in message forwarding Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3555@grfint2.intern.adiscon.com> Hi all, I am currently working on the syslog/tcp sender. While testing, I noticed a format bug for relayed messages. As it looks, in some cases, the date stamp is duplicated. I am looking into this issue, but it will eventually take a bit to fix (because the source must be stabilized first). As I got no bug report so far, I assume its not such a big issue. If I am wrong, let me know. I expect to have a fix out next week, hopefully together with the tcp sender ;) Rainer From rgerhards at hq.adiscon.com Tue Jul 19 10:07:43 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 19 Jul 2005 10:07:43 +0200 Subject: [rsyslog] rsyslog 0.9.3 released - important FIX Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3633@grfint2.intern.adiscon.com> Hi all, I've just released rsyslog 0.9.3. It primarily is a bug fixing release! It fixes a nasty bug where the TIMESTAMP was not properly decoded (just in some months). It also adds the capability to specify the destination port when forwarding messages to remote host. Lastly, a very experimental TCP sender is now included. However, the TCP sender can not yet be used in production, as it causes rsyslogd to hang during certain events, e.g. when connecting to the receiver. As the timestamp bug is a really bad one, ALL USERS ARE ADVISED TO UPGRADE to this version (but not yet use the TCP sender feature). As always, feedback is appreciated. Rainer Gerhards From dennisolvany at gmail.com Tue Jul 19 12:17:22 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Tue, 19 Jul 2005 05:17:22 -0500 Subject: [rsyslog] FreeBSD Startup Script Message-ID: <003a01c58c4b$0df764c0$0366a8c0@d> I've been researching how to do this without success. I tried modifying the syslogd startup script, but it doesn't seem to work. Maybe someone else could take a crack at it? #!/bin/sh # # $NetBSD: syslogd,v 1.12 2002/03/22 04:34:00 thorpej Exp $ # $FreeBSD: src/etc/rc.d/syslogd,v 1.9.2.1 2004/10/10 09:50:54 mtm Exp $ # # PROVIDE: rsyslogd # REQUIRE: mountcritremote cleanvar # BEFORE: SERVERS . /etc/rc.subr name="rsyslogd" rcvar=`set_rcvar` #pidfile="/var/run/syslog.pid" command="/usr/sbin/${name}" required_files="/etc/rsyslog.conf" #start_precmd="syslogd_precmd" #extra_commands="reload" #_sockfile="/var/run/syslogd.sockets" #evalargs="rc_flags=\"\`set_socketlist\` \$rc_flags\"" #altlog_proglist="named" #syslogd_precmd() #{ # Transitional symlink for old binaries # # if [ ! -L /dev/log ]; then # ln -sf /var/run/log /dev/log # fi # rm -f /var/run/log # Create default list of syslog sockets to watch # # ( umask 022 ; > $_sockfile ) # If running named(8) or ntpd(8) chrooted, added appropriate # syslog socket to list of sockets to watch. # # for _l in $altlog_proglist; do # eval _ldir=\$${_l}_chrootdir # if checkyesno `set_rcvar $_l` && [ -n "$_ldir" ]; then # echo "${_ldir}/var/run/log" >> $_sockfile # fi # done # If other sockets have been provided, change run_rc_command()'s # internal copy of $syslogd_flags to force use of specific # syslogd sockets. # # if [ -s $_sockfile ]; then # echo "/var/run/log" >> $_sockfile # eval $evalargs # fi # return 0 #} #set_socketlist() #{ # _socketargs= # for _s in `cat $_sockfile | tr '\n' ' '` ; do # _socketargs="-l $_s $_socketargs" # done # echo $_socketargs #} load_rc_config $name run_rc_command "$1" From dennisolvany at gmail.com Tue Jul 19 14:21:49 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Tue, 19 Jul 2005 07:21:49 -0500 Subject: [rsyslog] FreeBSD Startup Script References: <577465F99B41C842AAFBE9ED71E70ABA0E3638@grfint2.intern.adiscon.com> Message-ID: <000801c58c5c$70a52c40$0366a8c0@d> Using the modified syslogd script, rsyslogd did not start. There were no error messages that I know of. Not that I would know where to find them. I did get a script working. I tried to add the line # BEFORE: SERVERS, but this also caused rsyslogd to not start. The below script works for me. Perhaps you'd like to suggest appropriate modifications. Perhaps you'd like to add it to the rsyslog distribution. added rsyslogd_enable="yes" to /etc/rc.conf added /etc/rc.d/rsyslogd: #!/bin/sh # PROVIDE: rsyslogd # REQUIRE: NETWORKING . /etc/rc.subr name="rsyslogd" rcvar=`set_rcvar` command="/usr/sbin/rsyslogd" pidfile="/var/run/rsyslogd.pid" required_files="/etc/rsyslog.conf" load_rc_config $name run_rc_command "$1" Appropriate execute permissions must be applied to /etc/rc.d/rsyslogd. Other files in /etc/rc.d have permissions of 555. 555 or 755 would be appropriate. Also, rsyslog-093 seems to be logging it's version as 092. I'd like to suggest that the semi-colon be added to the end of line 178 in sample.conf. This is such a simple fix that can eliminate potential problems when a user attempts to log to a MySQL database. From dennisolvany at gmail.com Tue Jul 19 14:44:04 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Tue, 19 Jul 2005 07:44:04 -0500 Subject: [rsyslog] FreeBSD Startup Script References: <577465F99B41C842AAFBE9ED71E70ABA0E363B@grfint2.intern.adiscon.com> Message-ID: <000501c58c5f$8c548be0$0366a8c0@d> Version number isn't important enough to go back and rebuild. I have no idea about the libmysql client startup issue. I suppose you saw something on the screen to that effect. I implemented the script on a headless machine, so I couldn't see any startup messages. Don't forget about the semi-colon...line 178...sample.conf. It's ticking me off. 8) From dennisolvany at gmail.com Wed Jul 20 12:40:10 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Wed, 20 Jul 2005 05:40:10 -0500 Subject: [rsyslog] FreeBSD Startup Script References: <577465F99B41C842AAFBE9ED71E70ABA0E363D@grfint2.intern.adiscon.com> Message-ID: <000701c58d17$67ca42c0$0366a8c0@d> I was able to reproduce the libmysql errors during startup. Of course, I have no earthly idea how to go about troubleshooting or fixing them. I did do some testing on the startup script. The FreeBSD boot sequence goes in the following order: NETWORKING, SERVERS, DAEMON, LOGIN. I'd like to see rsyslogd start up as soon as possible in order to log a maximum amount of information. If logging to a remote database, rsyslogd must obviously be started after NETWORKING. This is the scenario I use for testing, since this is the scenario I use in production. I tried configuring rsyslogd to start before each of the following checkpoints (SERVERS, DAEMON, LOGIN) without success. Libmysql error with every configuration. The only working configuration was to omit the # BEFORE statement in the rsyslogd startup script. The following information from the FreeBSD rc(8) man page may or may not having some bearing. The FreeBSD startup script currently uses the bar configuration. I honestly have no idea what advantages the foo.sh configuration could offer. foo.sh Scripts that are to be sourced into the current shell rather than a subshell have a .sh suffix. Extreme care must be taken in using this, as the startup sequence will terminate if the script does. bar Scripts that are sourced in a subshell. From rgerhards at hq.adiscon.com Fri Jul 22 18:44:45 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 22 Jul 2005 18:44:45 +0200 Subject: [rsyslog] Tutorial on encrypting syslog traffic with rsyslog - Feedback Requested Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E368E@grfint2.intern.adiscon.com> Hi all, I have just written a tutorial on encrypting syslog traffic. This is to be released as part of the 1.0 release of rsyslog. I would deeply appreciate if some of you could have a look at it and provide me some feedback. My intention is to make encrypted syslog much more popular than it is nowadays. Besides a syslogd capable of doing it easy, good documentation is needed. The question is where I have arrrive - and what can be improved. I also intend to ship the configuration files as part of the rsyslogd package. Please follow this link: http://www.rsyslog.com/module-Static_Docs-view-f-rsyslog_stunnel.html.ph tml One important thing: as this is a preview, the rsyslog code necessary to actually *follow* the tutorial is not yet on the download servers. You need to obtain it from CVS on sourceforge: http://sourceforge.net/projects/rsyslog/ Please note that my main intention is to get some feedback on the text, so it probably is not necessary to follow with actual code (I except the next release of rsyslog to come out early next week). Any feedback is highly appreciated. Rainer From rgerhards at hq.adiscon.com Mon Jul 25 15:09:07 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 25 Jul 2005 15:09:07 +0200 Subject: [rsyslog] rsyslog 0.9.4 is out - full TCP support Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3699@grfint2.intern.adiscon.com> Hi all, I am pleased to announce rsyslog 0.9.4. With 0.9.4, full tcp support has finally arrived at rsyslog. It now can act both as a receiver as well as a tcp sender. This provides multiple benefits. For example, syslog traffic can now easily be encrypted. A paper on how to do that is available at http://www.rsyslog.com/rsyslog_stunnel.html Version 0.9.4 has only minor other changes, all of which are listed at http://www.rsyslog.com/Article17.phtml. Please note that the www.rsyslog.com site mentioned in this mail is not yet fully operational. We are currently moving content over to it. For the time being, http://www.monitorware.com/rsyslog/ is still the project home page. Rsyslog development will focus on getting the 0.9.x series very stable and then releasing a stable release of it. We hope this will soon be the case. No major additional features are planned for the 0.9.x (soon to become 1.0) series. When we start a new development branch, the focus will initially be on implementing the upcoming syslog protocol RFC and then Move to either a RFC 3195 wrapper or bringing native SSL to the syslog/tcp connection. Your feedback is appreciated and might very well influence the schedule. I hope this tool is useful. Deployment reports are appreciated. Rainer Gerhards From rgerhards at hq.adiscon.com Wed Jul 6 12:03:35 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 6 Jul 2005 12:03:35 +0200 Subject: [rsyslog] rsyslog 0.9.2 released - with TCP support! Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E354C@grfint2.intern.adiscon.com> Hi all: Good news: rsyslog 0.9.2 is out. Finally, the syslog/tcp receiver has arrived! This is a big step forward for rsyslog. Now, it supports reliable message delivery via TCP. Our implementation is compatible with leading tools and devices like syslog-ng, Cisco PIX and MonitorWare under Windows. Note, however, the 0.9.2 release only supports receiving via TCP. Forwarding is not yet supported. So in a relay chain, rsyslog must be the last daemon to receive the message. Guess what is next on the todo list; ) Syslog/tcp support is activated via a simple command line switch without any need for complex configuration file changes! This time, I have tested rsyslog on FreeBSD immediately and as it looks, it works without any special tricks. I hope the new version is useful. Any feedback is highly appreciated. Rainer From rgerhards at hq.adiscon.com Wed Jul 6 18:36:32 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 6 Jul 2005 18:36:32 +0200 Subject: [rsyslog] bug in message forwarding Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3555@grfint2.intern.adiscon.com> Hi all, I am currently working on the syslog/tcp sender. While testing, I noticed a format bug for relayed messages. As it looks, in some cases, the date stamp is duplicated. I am looking into this issue, but it will eventually take a bit to fix (because the source must be stabilized first). As I got no bug report so far, I assume its not such a big issue. If I am wrong, let me know. I expect to have a fix out next week, hopefully together with the tcp sender ;) Rainer From rgerhards at hq.adiscon.com Tue Jul 19 10:07:43 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 19 Jul 2005 10:07:43 +0200 Subject: [rsyslog] rsyslog 0.9.3 released - important FIX Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3633@grfint2.intern.adiscon.com> Hi all, I've just released rsyslog 0.9.3. It primarily is a bug fixing release! It fixes a nasty bug where the TIMESTAMP was not properly decoded (just in some months). It also adds the capability to specify the destination port when forwarding messages to remote host. Lastly, a very experimental TCP sender is now included. However, the TCP sender can not yet be used in production, as it causes rsyslogd to hang during certain events, e.g. when connecting to the receiver. As the timestamp bug is a really bad one, ALL USERS ARE ADVISED TO UPGRADE to this version (but not yet use the TCP sender feature). As always, feedback is appreciated. Rainer Gerhards From dennisolvany at gmail.com Tue Jul 19 12:17:22 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Tue, 19 Jul 2005 05:17:22 -0500 Subject: [rsyslog] FreeBSD Startup Script Message-ID: <003a01c58c4b$0df764c0$0366a8c0@d> I've been researching how to do this without success. I tried modifying the syslogd startup script, but it doesn't seem to work. Maybe someone else could take a crack at it? #!/bin/sh # # $NetBSD: syslogd,v 1.12 2002/03/22 04:34:00 thorpej Exp $ # $FreeBSD: src/etc/rc.d/syslogd,v 1.9.2.1 2004/10/10 09:50:54 mtm Exp $ # # PROVIDE: rsyslogd # REQUIRE: mountcritremote cleanvar # BEFORE: SERVERS . /etc/rc.subr name="rsyslogd" rcvar=`set_rcvar` #pidfile="/var/run/syslog.pid" command="/usr/sbin/${name}" required_files="/etc/rsyslog.conf" #start_precmd="syslogd_precmd" #extra_commands="reload" #_sockfile="/var/run/syslogd.sockets" #evalargs="rc_flags=\"\`set_socketlist\` \$rc_flags\"" #altlog_proglist="named" #syslogd_precmd() #{ # Transitional symlink for old binaries # # if [ ! -L /dev/log ]; then # ln -sf /var/run/log /dev/log # fi # rm -f /var/run/log # Create default list of syslog sockets to watch # # ( umask 022 ; > $_sockfile ) # If running named(8) or ntpd(8) chrooted, added appropriate # syslog socket to list of sockets to watch. # # for _l in $altlog_proglist; do # eval _ldir=\$${_l}_chrootdir # if checkyesno `set_rcvar $_l` && [ -n "$_ldir" ]; then # echo "${_ldir}/var/run/log" >> $_sockfile # fi # done # If other sockets have been provided, change run_rc_command()'s # internal copy of $syslogd_flags to force use of specific # syslogd sockets. # # if [ -s $_sockfile ]; then # echo "/var/run/log" >> $_sockfile # eval $evalargs # fi # return 0 #} #set_socketlist() #{ # _socketargs= # for _s in `cat $_sockfile | tr '\n' ' '` ; do # _socketargs="-l $_s $_socketargs" # done # echo $_socketargs #} load_rc_config $name run_rc_command "$1" From dennisolvany at gmail.com Tue Jul 19 14:21:49 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Tue, 19 Jul 2005 07:21:49 -0500 Subject: [rsyslog] FreeBSD Startup Script References: <577465F99B41C842AAFBE9ED71E70ABA0E3638@grfint2.intern.adiscon.com> Message-ID: <000801c58c5c$70a52c40$0366a8c0@d> Using the modified syslogd script, rsyslogd did not start. There were no error messages that I know of. Not that I would know where to find them. I did get a script working. I tried to add the line # BEFORE: SERVERS, but this also caused rsyslogd to not start. The below script works for me. Perhaps you'd like to suggest appropriate modifications. Perhaps you'd like to add it to the rsyslog distribution. added rsyslogd_enable="yes" to /etc/rc.conf added /etc/rc.d/rsyslogd: #!/bin/sh # PROVIDE: rsyslogd # REQUIRE: NETWORKING . /etc/rc.subr name="rsyslogd" rcvar=`set_rcvar` command="/usr/sbin/rsyslogd" pidfile="/var/run/rsyslogd.pid" required_files="/etc/rsyslog.conf" load_rc_config $name run_rc_command "$1" Appropriate execute permissions must be applied to /etc/rc.d/rsyslogd. Other files in /etc/rc.d have permissions of 555. 555 or 755 would be appropriate. Also, rsyslog-093 seems to be logging it's version as 092. I'd like to suggest that the semi-colon be added to the end of line 178 in sample.conf. This is such a simple fix that can eliminate potential problems when a user attempts to log to a MySQL database. From dennisolvany at gmail.com Tue Jul 19 14:44:04 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Tue, 19 Jul 2005 07:44:04 -0500 Subject: [rsyslog] FreeBSD Startup Script References: <577465F99B41C842AAFBE9ED71E70ABA0E363B@grfint2.intern.adiscon.com> Message-ID: <000501c58c5f$8c548be0$0366a8c0@d> Version number isn't important enough to go back and rebuild. I have no idea about the libmysql client startup issue. I suppose you saw something on the screen to that effect. I implemented the script on a headless machine, so I couldn't see any startup messages. Don't forget about the semi-colon...line 178...sample.conf. It's ticking me off. 8) From dennisolvany at gmail.com Wed Jul 20 12:40:10 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Wed, 20 Jul 2005 05:40:10 -0500 Subject: [rsyslog] FreeBSD Startup Script References: <577465F99B41C842AAFBE9ED71E70ABA0E363D@grfint2.intern.adiscon.com> Message-ID: <000701c58d17$67ca42c0$0366a8c0@d> I was able to reproduce the libmysql errors during startup. Of course, I have no earthly idea how to go about troubleshooting or fixing them. I did do some testing on the startup script. The FreeBSD boot sequence goes in the following order: NETWORKING, SERVERS, DAEMON, LOGIN. I'd like to see rsyslogd start up as soon as possible in order to log a maximum amount of information. If logging to a remote database, rsyslogd must obviously be started after NETWORKING. This is the scenario I use for testing, since this is the scenario I use in production. I tried configuring rsyslogd to start before each of the following checkpoints (SERVERS, DAEMON, LOGIN) without success. Libmysql error with every configuration. The only working configuration was to omit the # BEFORE statement in the rsyslogd startup script. The following information from the FreeBSD rc(8) man page may or may not having some bearing. The FreeBSD startup script currently uses the bar configuration. I honestly have no idea what advantages the foo.sh configuration could offer. foo.sh Scripts that are to be sourced into the current shell rather than a subshell have a .sh suffix. Extreme care must be taken in using this, as the startup sequence will terminate if the script does. bar Scripts that are sourced in a subshell. From rgerhards at hq.adiscon.com Fri Jul 22 18:44:45 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 22 Jul 2005 18:44:45 +0200 Subject: [rsyslog] Tutorial on encrypting syslog traffic with rsyslog - Feedback Requested Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E368E@grfint2.intern.adiscon.com> Hi all, I have just written a tutorial on encrypting syslog traffic. This is to be released as part of the 1.0 release of rsyslog. I would deeply appreciate if some of you could have a look at it and provide me some feedback. My intention is to make encrypted syslog much more popular than it is nowadays. Besides a syslogd capable of doing it easy, good documentation is needed. The question is where I have arrrive - and what can be improved. I also intend to ship the configuration files as part of the rsyslogd package. Please follow this link: http://www.rsyslog.com/module-Static_Docs-view-f-rsyslog_stunnel.html.ph tml One important thing: as this is a preview, the rsyslog code necessary to actually *follow* the tutorial is not yet on the download servers. You need to obtain it from CVS on sourceforge: http://sourceforge.net/projects/rsyslog/ Please note that my main intention is to get some feedback on the text, so it probably is not necessary to follow with actual code (I except the next release of rsyslog to come out early next week). Any feedback is highly appreciated. Rainer From rgerhards at hq.adiscon.com Mon Jul 25 15:09:07 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 25 Jul 2005 15:09:07 +0200 Subject: [rsyslog] rsyslog 0.9.4 is out - full TCP support Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3699@grfint2.intern.adiscon.com> Hi all, I am pleased to announce rsyslog 0.9.4. With 0.9.4, full tcp support has finally arrived at rsyslog. It now can act both as a receiver as well as a tcp sender. This provides multiple benefits. For example, syslog traffic can now easily be encrypted. A paper on how to do that is available at http://www.rsyslog.com/rsyslog_stunnel.html Version 0.9.4 has only minor other changes, all of which are listed at http://www.rsyslog.com/Article17.phtml. Please note that the www.rsyslog.com site mentioned in this mail is not yet fully operational. We are currently moving content over to it. For the time being, http://www.monitorware.com/rsyslog/ is still the project home page. Rsyslog development will focus on getting the 0.9.x series very stable and then releasing a stable release of it. We hope this will soon be the case. No major additional features are planned for the 0.9.x (soon to become 1.0) series. When we start a new development branch, the focus will initially be on implementing the upcoming syslog protocol RFC and then Move to either a RFC 3195 wrapper or bringing native SSL to the syslog/tcp connection. Your feedback is appreciated and might very well influence the schedule. I hope this tool is useful. Deployment reports are appreciated. Rainer Gerhards From rgerhards at hq.adiscon.com Wed Jul 6 12:03:35 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 6 Jul 2005 12:03:35 +0200 Subject: [rsyslog] rsyslog 0.9.2 released - with TCP support! Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E354C@grfint2.intern.adiscon.com> Hi all: Good news: rsyslog 0.9.2 is out. Finally, the syslog/tcp receiver has arrived! This is a big step forward for rsyslog. Now, it supports reliable message delivery via TCP. Our implementation is compatible with leading tools and devices like syslog-ng, Cisco PIX and MonitorWare under Windows. Note, however, the 0.9.2 release only supports receiving via TCP. Forwarding is not yet supported. So in a relay chain, rsyslog must be the last daemon to receive the message. Guess what is next on the todo list; ) Syslog/tcp support is activated via a simple command line switch without any need for complex configuration file changes! This time, I have tested rsyslog on FreeBSD immediately and as it looks, it works without any special tricks. I hope the new version is useful. Any feedback is highly appreciated. Rainer From rgerhards at hq.adiscon.com Wed Jul 6 18:36:32 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 6 Jul 2005 18:36:32 +0200 Subject: [rsyslog] bug in message forwarding Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3555@grfint2.intern.adiscon.com> Hi all, I am currently working on the syslog/tcp sender. While testing, I noticed a format bug for relayed messages. As it looks, in some cases, the date stamp is duplicated. I am looking into this issue, but it will eventually take a bit to fix (because the source must be stabilized first). As I got no bug report so far, I assume its not such a big issue. If I am wrong, let me know. I expect to have a fix out next week, hopefully together with the tcp sender ;) Rainer From rgerhards at hq.adiscon.com Tue Jul 19 10:07:43 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 19 Jul 2005 10:07:43 +0200 Subject: [rsyslog] rsyslog 0.9.3 released - important FIX Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3633@grfint2.intern.adiscon.com> Hi all, I've just released rsyslog 0.9.3. It primarily is a bug fixing release! It fixes a nasty bug where the TIMESTAMP was not properly decoded (just in some months). It also adds the capability to specify the destination port when forwarding messages to remote host. Lastly, a very experimental TCP sender is now included. However, the TCP sender can not yet be used in production, as it causes rsyslogd to hang during certain events, e.g. when connecting to the receiver. As the timestamp bug is a really bad one, ALL USERS ARE ADVISED TO UPGRADE to this version (but not yet use the TCP sender feature). As always, feedback is appreciated. Rainer Gerhards From dennisolvany at gmail.com Tue Jul 19 12:17:22 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Tue, 19 Jul 2005 05:17:22 -0500 Subject: [rsyslog] FreeBSD Startup Script Message-ID: <003a01c58c4b$0df764c0$0366a8c0@d> I've been researching how to do this without success. I tried modifying the syslogd startup script, but it doesn't seem to work. Maybe someone else could take a crack at it? #!/bin/sh # # $NetBSD: syslogd,v 1.12 2002/03/22 04:34:00 thorpej Exp $ # $FreeBSD: src/etc/rc.d/syslogd,v 1.9.2.1 2004/10/10 09:50:54 mtm Exp $ # # PROVIDE: rsyslogd # REQUIRE: mountcritremote cleanvar # BEFORE: SERVERS . /etc/rc.subr name="rsyslogd" rcvar=`set_rcvar` #pidfile="/var/run/syslog.pid" command="/usr/sbin/${name}" required_files="/etc/rsyslog.conf" #start_precmd="syslogd_precmd" #extra_commands="reload" #_sockfile="/var/run/syslogd.sockets" #evalargs="rc_flags=\"\`set_socketlist\` \$rc_flags\"" #altlog_proglist="named" #syslogd_precmd() #{ # Transitional symlink for old binaries # # if [ ! -L /dev/log ]; then # ln -sf /var/run/log /dev/log # fi # rm -f /var/run/log # Create default list of syslog sockets to watch # # ( umask 022 ; > $_sockfile ) # If running named(8) or ntpd(8) chrooted, added appropriate # syslog socket to list of sockets to watch. # # for _l in $altlog_proglist; do # eval _ldir=\$${_l}_chrootdir # if checkyesno `set_rcvar $_l` && [ -n "$_ldir" ]; then # echo "${_ldir}/var/run/log" >> $_sockfile # fi # done # If other sockets have been provided, change run_rc_command()'s # internal copy of $syslogd_flags to force use of specific # syslogd sockets. # # if [ -s $_sockfile ]; then # echo "/var/run/log" >> $_sockfile # eval $evalargs # fi # return 0 #} #set_socketlist() #{ # _socketargs= # for _s in `cat $_sockfile | tr '\n' ' '` ; do # _socketargs="-l $_s $_socketargs" # done # echo $_socketargs #} load_rc_config $name run_rc_command "$1" From dennisolvany at gmail.com Tue Jul 19 14:21:49 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Tue, 19 Jul 2005 07:21:49 -0500 Subject: [rsyslog] FreeBSD Startup Script References: <577465F99B41C842AAFBE9ED71E70ABA0E3638@grfint2.intern.adiscon.com> Message-ID: <000801c58c5c$70a52c40$0366a8c0@d> Using the modified syslogd script, rsyslogd did not start. There were no error messages that I know of. Not that I would know where to find them. I did get a script working. I tried to add the line # BEFORE: SERVERS, but this also caused rsyslogd to not start. The below script works for me. Perhaps you'd like to suggest appropriate modifications. Perhaps you'd like to add it to the rsyslog distribution. added rsyslogd_enable="yes" to /etc/rc.conf added /etc/rc.d/rsyslogd: #!/bin/sh # PROVIDE: rsyslogd # REQUIRE: NETWORKING . /etc/rc.subr name="rsyslogd" rcvar=`set_rcvar` command="/usr/sbin/rsyslogd" pidfile="/var/run/rsyslogd.pid" required_files="/etc/rsyslog.conf" load_rc_config $name run_rc_command "$1" Appropriate execute permissions must be applied to /etc/rc.d/rsyslogd. Other files in /etc/rc.d have permissions of 555. 555 or 755 would be appropriate. Also, rsyslog-093 seems to be logging it's version as 092. I'd like to suggest that the semi-colon be added to the end of line 178 in sample.conf. This is such a simple fix that can eliminate potential problems when a user attempts to log to a MySQL database. From dennisolvany at gmail.com Tue Jul 19 14:44:04 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Tue, 19 Jul 2005 07:44:04 -0500 Subject: [rsyslog] FreeBSD Startup Script References: <577465F99B41C842AAFBE9ED71E70ABA0E363B@grfint2.intern.adiscon.com> Message-ID: <000501c58c5f$8c548be0$0366a8c0@d> Version number isn't important enough to go back and rebuild. I have no idea about the libmysql client startup issue. I suppose you saw something on the screen to that effect. I implemented the script on a headless machine, so I couldn't see any startup messages. Don't forget about the semi-colon...line 178...sample.conf. It's ticking me off. 8) From dennisolvany at gmail.com Wed Jul 20 12:40:10 2005 From: dennisolvany at gmail.com (Dennis Olvany) Date: Wed, 20 Jul 2005 05:40:10 -0500 Subject: [rsyslog] FreeBSD Startup Script References: <577465F99B41C842AAFBE9ED71E70ABA0E363D@grfint2.intern.adiscon.com> Message-ID: <000701c58d17$67ca42c0$0366a8c0@d> I was able to reproduce the libmysql errors during startup. Of course, I have no earthly idea how to go about troubleshooting or fixing them. I did do some testing on the startup script. The FreeBSD boot sequence goes in the following order: NETWORKING, SERVERS, DAEMON, LOGIN. I'd like to see rsyslogd start up as soon as possible in order to log a maximum amount of information. If logging to a remote database, rsyslogd must obviously be started after NETWORKING. This is the scenario I use for testing, since this is the scenario I use in production. I tried configuring rsyslogd to start before each of the following checkpoints (SERVERS, DAEMON, LOGIN) without success. Libmysql error with every configuration. The only working configuration was to omit the # BEFORE statement in the rsyslogd startup script. The following information from the FreeBSD rc(8) man page may or may not having some bearing. The FreeBSD startup script currently uses the bar configuration. I honestly have no idea what advantages the foo.sh configuration could offer. foo.sh Scripts that are to be sourced into the current shell rather than a subshell have a .sh suffix. Extreme care must be taken in using this, as the startup sequence will terminate if the script does. bar Scripts that are sourced in a subshell. From rgerhards at hq.adiscon.com Fri Jul 22 18:44:45 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 22 Jul 2005 18:44:45 +0200 Subject: [rsyslog] Tutorial on encrypting syslog traffic with rsyslog - Feedback Requested Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E368E@grfint2.intern.adiscon.com> Hi all, I have just written a tutorial on encrypting syslog traffic. This is to be released as part of the 1.0 release of rsyslog. I would deeply appreciate if some of you could have a look at it and provide me some feedback. My intention is to make encrypted syslog much more popular than it is nowadays. Besides a syslogd capable of doing it easy, good documentation is needed. The question is where I have arrrive - and what can be improved. I also intend to ship the configuration files as part of the rsyslogd package. Please follow this link: http://www.rsyslog.com/module-Static_Docs-view-f-rsyslog_stunnel.html.ph tml One important thing: as this is a preview, the rsyslog code necessary to actually *follow* the tutorial is not yet on the download servers. You need to obtain it from CVS on sourceforge: http://sourceforge.net/projects/rsyslog/ Please note that my main intention is to get some feedback on the text, so it probably is not necessary to follow with actual code (I except the next release of rsyslog to come out early next week). Any feedback is highly appreciated. Rainer From rgerhards at hq.adiscon.com Mon Jul 25 15:09:07 2005 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 25 Jul 2005 15:09:07 +0200 Subject: [rsyslog] rsyslog 0.9.4 is out - full TCP support Message-ID: <577465F99B41C842AAFBE9ED71E70ABA0E3699@grfint2.intern.adiscon.com> Hi all, I am pleased to announce rsyslog 0.9.4. With 0.9.4, full tcp support has finally arrived at rsyslog. It now can act both as a receiver as well as a tcp sender. This provides multiple benefits. For example, syslog traffic can now easily be encrypted. A paper on how to do that is available at http://www.rsyslog.com/rsyslog_stunnel.html Version 0.9.4 has only minor other changes, all of which are listed at http://www.rsyslog.com/Article17.phtml. Please note that the www.rsyslog.com site mentioned in this mail is not yet fully operational. We are currently moving content over to it. For the time being, http://www.monitorware.com/rsyslog/ is still the project home page. Rsyslog development will focus on getting the 0.9.x series very stable and then releasing a stable release of it. We hope this will soon be the case. No major additional features are planned for the 0.9.x (soon to become 1.0) series. When we start a new development branch, the focus will initially be on implementing the upcoming syslog protocol RFC and then Move to either a RFC 3195 wrapper or bringing native SSL to the syslog/tcp connection. Your feedback is appreciated and might very well influence the schedule. I hope this tool is useful. Deployment reports are appreciated. Rainer Gerhards