From rgerhards at hq.adiscon.com Mon Feb 2 14:41:57 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 14:41:57 +0100 Subject: [rsyslog] rsyslog 3.21.10 (beta) released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAEC@grfint2.intern.adiscon.com> Hi all, this is a bug-fixing release. Most importantly, a race that could result in a segfault, in specific scenarios, has been addressed. Also, some command-line switches were incorrectly processed and a debug string was accidentally written to stdout on daemon termination. This is a recommended update for all users of the beta branch. Change Log: http://www.rsyslog.com/Article344.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-148.phtml I hope this release is useful. Feedback is appreciated. Best regards, Rainer Gerhards From r.bhatia at ipax.at Mon Feb 2 16:34:42 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Mon, 02 Feb 2009 16:34:42 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** Message-ID: <49871292.9000900@ipax.at> hi, i do not know if this has already been addressed - so sorry for a possible duplicate. revision: > Feb 2 16:29:58 wc02 kernel: imklog 3.20.0, log source = /proc/kmsg started. > Feb 2 16:29:58 wc02 rsyslogd: [origin software="rsyslogd" swVersion="3.20.0" x-pid="27617" x-info="http://www.rsyslog.com"] restart running on debian logging remotely to another server. cheers, raoul > *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7f639a997948] > /lib/libc.so.6(cfree+0x76)[0x7f639a999a56] > /usr/sbin/rsyslogd(msgDestruct+0x3c)[0x415f7c] > /usr/sbin/rsyslogd(actionCallAction+0xcd)[0x4281cd] > /usr/sbin/rsyslogd[0x409de9] > /usr/sbin/rsyslogd(llExecFunc+0x58)[0x4168e8] > /usr/sbin/rsyslogd[0x409ad5] > /usr/sbin/rsyslogd[0x4244ef] > /usr/sbin/rsyslogd(wtiWorker+0x24f)[0x42124f] > /usr/sbin/rsyslogd[0x420968] > /lib/libpthread.so.0[0x7f639b08afc7] > /lib/libc.so.6(clone+0x6d)[0x7f639a9f35ad] > ======= Memory map: ======== > 00400000-0043c000 r-xp 00000000 09:00 384769 /usr/sbin/rsyslogd > 0053b000-00540000 rw-p 0003b000 09:00 384769 /usr/sbin/rsyslogd > 00540000-00541000 rw-p 00540000 00:00 0 > 00ebc000-00f6e000 rw-p 00ebc000 00:00 0 [heap] > 40219000-4021a000 ---p 40219000 00:00 0 > 4021a000-40a1a000 rw-p 4021a000 00:00 0 > 40c65000-40c66000 ---p 40c65000 00:00 0 > 40c66000-41466000 rw-p 40c66000 00:00 0 > 41466000-41467000 ---p 41466000 00:00 0 > 41467000-41c67000 rw-p 41467000 00:00 0 > 41cff000-41d00000 ---p 41cff000 00:00 0 > 41d00000-42500000 rw-p 41d00000 00:00 0 > 7f638c000000-7f638c021000 rw-p 7f638c000000 00:00 0 > 7f638c021000-7f6390000000 ---p 7f638c021000 00:00 0 > 7f6394000000-7f6394021000 rw-p 7f6394000000 00:00 0 > 7f6394021000-7f6398000000 ---p 7f6394021000 00:00 0 > 7f63995aa000-7f63995c0000 r-xp 00000000 09:00 128682 /lib/libgcc_s.so.1 > 7f63995c0000-7f63997c0000 ---p 00016000 09:00 128682 /lib/libgcc_s.so.1 > 7f63997c0000-7f63997c1000 rw-p 00016000 09:00 128682 /lib/libgcc_s.so.1 > 7f63997c1000-7f63997d1000 r-xp 00000000 09:00 128437 /lib/libresolv-2.7.so > 7f63997d1000-7f63999d1000 ---p 00010000 09:00 128437 /lib/libresolv-2.7.so > 7f63999d1000-7f63999d3000 rw-p 00010000 09:00 128437 /lib/libresolv-2.7.so > 7f63999d3000-7f63999d5000 rw-p 7f63999d3000 00:00 0 > 7f63999d5000-7f63999d9000 r-xp 00000000 09:00 128444 /lib/libnss_dns-2.7.so > 7f63999d9000-7f6399bd8000 ---p 00004000 09:00 128444 /lib/libnss_dns-2.7.so > 7f6399bd8000-7f6399bda000 rw-p 00003000 09:00 128444 /lib/libnss_dns-2.7.so > 7f6399bda000-7f6399bde000 r-xp 00000000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so > 7f6399bde000-7f6399cdd000 ---p 00004000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so > 7f6399cdd000-7f6399cde000 rw-p 00003000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so > 7f6399cde000-7f6399ce0000 r-xp 00000000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so > 7f6399ce0000-7f6399ddf000 ---p 00002000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so > 7f6399ddf000-7f6399de0000 rw-p 00001000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so > 7f6399de0000-7f6399de3000 r-xp 00000000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so > 7f6399de3000-7f6399ee2000 ---p 00003000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so > 7f6399ee2000-7f6399ee3000 rw-p 00002000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so > 7f6399ee3000-7f6399eed000 r-xp 00000000 09:00 128429 /lib/libnss_nis-2.7.so > 7f6399eed000-7f639a0ec000 ---p 0000a000 09:00 128429 /lib/libnss_nis-2.7.so > 7f639a0ec000-7f639a0ee000 rw-p 00009000 09:00 128429 /lib/libnss_nis-2.7.so > 7f639a0ee000-7f639a103000 r-xp 00000000 09:00 128433 /lib/libnsl-2.7.so > 7f639a103000-7f639a302000 ---p 00015000 09:00 128433 /lib/libnsl-2.7.so > 7f639a302000-7f639a304000 rw-p 00014000 09:00 128433 /lib/libnsl-2.7.so > 7f639a304000-7f639a306000 rw-p 7f639a304000 00:00 0 > 7f639a306000-7f639a30d000 r-xp 00000000 09:00 128435 /lib/libnss_compat-2.7.so > 7f639a30d000-7f639a50c000 ---p 00007000 09:00 128435 /lib/libnss_compat-2.7.so > 7f639a50c000-7f639a50e000 rw-p 00006000 09:00 128435 /lib/libnss_compat-2.7.so > 7f639a50e000-7f639a513000 r-xp 00000000 09:00 416987 /usr/lib/rsyslog/imklog.so > 7f639a513000-7f639a613000 ---p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so > 7f639a613000-7f639a614000 rw-p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so > 7f639a614000-7f639a615000 rw-p 7f639a614000 00:00 0 > 7f639a615000-7f639a617000 r-xp 00000000 09:00 416978 /usr/lib/rsyslog/imuxsock.so > 7f639a617000-7f639a717000 ---p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so > 7f639a717000-7f639a718000 rw-p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so > 7f639a718000-7f639a722000 r-xp 00000000 09:00 128440 /lib/libnss_files-2.7.so > 7f639a722000-7f639a922000 ---p 0000a000 09:00 128440 /lib/libnss_files-2.7.so > 7f639a922000-7f639a924000 rw-p 0000a000 09:00 128440 /lib/libnss_files-2.7.so > 7f639a924000-7f639aa6e000 r-xp 00000000 09:00 128443 /lib/libc-2.7.so > 7f639aa6e000-7f639ac6d000 ---p 0014a000 09:00 128443 /lib/libc-2.7.so > 7f639ac6d000-7f639ac70000 r--p 00149000 09:00 128443 /lib/libc-2.7.so > 7f639ac70000-7f639ac72000 rw-p 0014c000 09:00 128443 /lib/libc-2.7.so > 7f639ac72000-7f639ac77000 rw-p 7f639ac72000 00:00 0 > 7f639ac77000-7f639ac7f000 r-xp 00000000 09:00 128449 /lib/librt-2.7.so > 7f639ac7f000-7f639ae7e000 ---p 00008000 09:00 128449 /lib/librt-2.7.so > 7f639ae7e000-7f639ae80000 rw-p 00007000 09:00 128449 /lib/librt-2.7.so > 7f639ae80000-7f639ae82000 r-xp 00000000 09:00 128447 /lib/libdl-2.7.so > 7f639ae82000-7f639b082000 ---p 00002000 09:00 128447 /lib/libdl-2.7.so > 7f639b082000-7f639b084000 rw-p 00002000 09:00 128447 /lib/libdl-2.7.so > 7f639b084000-7f639b09a000 r-xp 00000000 09:00 128439 /lib/libpthread-2.7.so > 7f639b09a000-7f639b29a000 ---p 00016000 09:00 128439 /lib/libpthread-2.7.so > 7f639b29a000-7f639b29c000 rw-p 00016000 09:00 128439 /lib/libpthread-2.7.so > 7f639b29c000-7f639b2a0000 rw-p 7f639b29c000 00:00 0 > 7f639b2a0000-7f639b2b6000 r-xp 00000000 09:00 370185 /usr/lib/libz.so.1.2.3.3 > 7f639b2b6000-7f639b4b6000 ---p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 > 7f639b4b6000-7f639b4b7000 rw-p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 > 7f639b4b7000-7f639b4d3000 r-xp 00000000 09:00 128446 /lib/ld-2.7.so > 7f639b5bd000-7f639b5c2000 r-xp 00000000 09:00 416988 /usr/lib/rsyslog/lmnet.so > 7f639b5c2000-7f639b6c1000 ---p 00005000 09:00 416988 /usr/lib/rsyslog/lmnet.so > 7f639b6c1000-7f639b6c2000 rw-p 00004000 09:00 416988 /usr/lib/rsyslog/lmnet.so > 7f639b6c2000-7f639b6c5000 rw-p 7f639b6c2000 00:00 0 > 7f639b6ce000-7f639b6d2000 rw-p 7f639b6ce000 00:00 0 > 7f639b6d2000-7f639b6d4000 rw-p 0001b000 09:00 128446 /lib/ld-2.7.so > 7fffa36bf000-7fffa36d4000 rw-p 7ffffffea000 00:00 0 [stack] > 7fffa36ff000-7fffa3700000 r-xp 7fffa36ff000 00:00 0 [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] From rgerhards at hq.adiscon.com Mon Feb 2 17:29:26 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 17:29:26 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <49871292.9000900@ipax.at> References: <49871292.9000900@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAF0@grfint2.intern.adiscon.com> This is probably the result of the data race I described in details last week. You need to pull the newest releases. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Monday, February 02, 2009 4:35 PM > To: rsyslog-users > Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double > free or corruption (!prev): 0x0000000000ef03b0 *** > > hi, > > i do not know if this has already been addressed - so sorry for > a possible duplicate. > > revision: > > Feb 2 16:29:58 wc02 kernel: imklog 3.20.0, log source = /proc/kmsg > started. > > Feb 2 16:29:58 wc02 rsyslogd: [origin software="rsyslogd" > swVersion="3.20.0" x-pid="27617" x-info="http://www.rsyslog.com"] > restart > > running on debian logging remotely to another server. > > cheers, > raoul > > > *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption > (!prev): 0x0000000000ef03b0 *** > > ======= Backtrace: ========= > > /lib/libc.so.6[0x7f639a997948] > > /lib/libc.so.6(cfree+0x76)[0x7f639a999a56] > > /usr/sbin/rsyslogd(msgDestruct+0x3c)[0x415f7c] > > /usr/sbin/rsyslogd(actionCallAction+0xcd)[0x4281cd] > > /usr/sbin/rsyslogd[0x409de9] > > /usr/sbin/rsyslogd(llExecFunc+0x58)[0x4168e8] > > /usr/sbin/rsyslogd[0x409ad5] > > /usr/sbin/rsyslogd[0x4244ef] > > /usr/sbin/rsyslogd(wtiWorker+0x24f)[0x42124f] > > /usr/sbin/rsyslogd[0x420968] > > /lib/libpthread.so.0[0x7f639b08afc7] > > /lib/libc.so.6(clone+0x6d)[0x7f639a9f35ad] > > ======= Memory map: ======== > > 00400000-0043c000 r-xp 00000000 09:00 384769 > /usr/sbin/rsyslogd > > 0053b000-00540000 rw-p 0003b000 09:00 384769 > /usr/sbin/rsyslogd > > 00540000-00541000 rw-p 00540000 00:00 0 > > 00ebc000-00f6e000 rw-p 00ebc000 00:00 0 > [heap] > > 40219000-4021a000 ---p 40219000 00:00 0 > > 4021a000-40a1a000 rw-p 4021a000 00:00 0 > > 40c65000-40c66000 ---p 40c65000 00:00 0 > > 40c66000-41466000 rw-p 40c66000 00:00 0 > > 41466000-41467000 ---p 41466000 00:00 0 > > 41467000-41c67000 rw-p 41467000 00:00 0 > > 41cff000-41d00000 ---p 41cff000 00:00 0 > > 41d00000-42500000 rw-p 41d00000 00:00 0 > > 7f638c000000-7f638c021000 rw-p 7f638c000000 00:00 0 > > 7f638c021000-7f6390000000 ---p 7f638c021000 00:00 0 > > 7f6394000000-7f6394021000 rw-p 7f6394000000 00:00 0 > > 7f6394021000-7f6398000000 ---p 7f6394021000 00:00 0 > > 7f63995aa000-7f63995c0000 r-xp 00000000 09:00 128682 > /lib/libgcc_s.so.1 > > 7f63995c0000-7f63997c0000 ---p 00016000 09:00 128682 > /lib/libgcc_s.so.1 > > 7f63997c0000-7f63997c1000 rw-p 00016000 09:00 128682 > /lib/libgcc_s.so.1 > > 7f63997c1000-7f63997d1000 r-xp 00000000 09:00 128437 > /lib/libresolv-2.7.so > > 7f63997d1000-7f63999d1000 ---p 00010000 09:00 128437 > /lib/libresolv-2.7.so > > 7f63999d1000-7f63999d3000 rw-p 00010000 09:00 128437 > /lib/libresolv-2.7.so > > 7f63999d3000-7f63999d5000 rw-p 7f63999d3000 00:00 0 > > 7f63999d5000-7f63999d9000 r-xp 00000000 09:00 128444 > /lib/libnss_dns-2.7.so > > 7f63999d9000-7f6399bd8000 ---p 00004000 09:00 128444 > /lib/libnss_dns-2.7.so > > 7f6399bd8000-7f6399bda000 rw-p 00003000 09:00 128444 > /lib/libnss_dns-2.7.so > > 7f6399bda000-7f6399bde000 r-xp 00000000 09:00 416980 > /usr/lib/rsyslog/lmnsd_ptcp.so > > 7f6399bde000-7f6399cdd000 ---p 00004000 09:00 416980 > /usr/lib/rsyslog/lmnsd_ptcp.so > > 7f6399cdd000-7f6399cde000 rw-p 00003000 09:00 416980 > /usr/lib/rsyslog/lmnsd_ptcp.so > > 7f6399cde000-7f6399ce0000 r-xp 00000000 09:00 416981 > /usr/lib/rsyslog/lmtcpclt.so > > 7f6399ce0000-7f6399ddf000 ---p 00002000 09:00 416981 > /usr/lib/rsyslog/lmtcpclt.so > > 7f6399ddf000-7f6399de0000 rw-p 00001000 09:00 416981 > /usr/lib/rsyslog/lmtcpclt.so > > 7f6399de0000-7f6399de3000 r-xp 00000000 09:00 416985 > /usr/lib/rsyslog/lmnetstrms.so > > 7f6399de3000-7f6399ee2000 ---p 00003000 09:00 416985 > /usr/lib/rsyslog/lmnetstrms.so > > 7f6399ee2000-7f6399ee3000 rw-p 00002000 09:00 416985 > /usr/lib/rsyslog/lmnetstrms.so > > 7f6399ee3000-7f6399eed000 r-xp 00000000 09:00 128429 > /lib/libnss_nis-2.7.so > > 7f6399eed000-7f639a0ec000 ---p 0000a000 09:00 128429 > /lib/libnss_nis-2.7.so > > 7f639a0ec000-7f639a0ee000 rw-p 00009000 09:00 128429 > /lib/libnss_nis-2.7.so > > 7f639a0ee000-7f639a103000 r-xp 00000000 09:00 128433 > /lib/libnsl-2.7.so > > 7f639a103000-7f639a302000 ---p 00015000 09:00 128433 > /lib/libnsl-2.7.so > > 7f639a302000-7f639a304000 rw-p 00014000 09:00 128433 > /lib/libnsl-2.7.so > > 7f639a304000-7f639a306000 rw-p 7f639a304000 00:00 0 > > 7f639a306000-7f639a30d000 r-xp 00000000 09:00 128435 > /lib/libnss_compat-2.7.so > > 7f639a30d000-7f639a50c000 ---p 00007000 09:00 128435 > /lib/libnss_compat-2.7.so > > 7f639a50c000-7f639a50e000 rw-p 00006000 09:00 128435 > /lib/libnss_compat-2.7.so > > 7f639a50e000-7f639a513000 r-xp 00000000 09:00 416987 > /usr/lib/rsyslog/imklog.so > > 7f639a513000-7f639a613000 ---p 00005000 09:00 416987 > /usr/lib/rsyslog/imklog.so > > 7f639a613000-7f639a614000 rw-p 00005000 09:00 416987 > /usr/lib/rsyslog/imklog.so > > 7f639a614000-7f639a615000 rw-p 7f639a614000 00:00 0 > > 7f639a615000-7f639a617000 r-xp 00000000 09:00 416978 > /usr/lib/rsyslog/imuxsock.so > > 7f639a617000-7f639a717000 ---p 00002000 09:00 416978 > /usr/lib/rsyslog/imuxsock.so > > 7f639a717000-7f639a718000 rw-p 00002000 09:00 416978 > /usr/lib/rsyslog/imuxsock.so > > 7f639a718000-7f639a722000 r-xp 00000000 09:00 128440 > /lib/libnss_files-2.7.so > > 7f639a722000-7f639a922000 ---p 0000a000 09:00 128440 > /lib/libnss_files-2.7.so > > 7f639a922000-7f639a924000 rw-p 0000a000 09:00 128440 > /lib/libnss_files-2.7.so > > 7f639a924000-7f639aa6e000 r-xp 00000000 09:00 128443 > /lib/libc-2.7.so > > 7f639aa6e000-7f639ac6d000 ---p 0014a000 09:00 128443 > /lib/libc-2.7.so > > 7f639ac6d000-7f639ac70000 r--p 00149000 09:00 128443 > /lib/libc-2.7.so > > 7f639ac70000-7f639ac72000 rw-p 0014c000 09:00 128443 > /lib/libc-2.7.so > > 7f639ac72000-7f639ac77000 rw-p 7f639ac72000 00:00 0 > > 7f639ac77000-7f639ac7f000 r-xp 00000000 09:00 128449 > /lib/librt-2.7.so > > 7f639ac7f000-7f639ae7e000 ---p 00008000 09:00 128449 > /lib/librt-2.7.so > > 7f639ae7e000-7f639ae80000 rw-p 00007000 09:00 128449 > /lib/librt-2.7.so > > 7f639ae80000-7f639ae82000 r-xp 00000000 09:00 128447 > /lib/libdl-2.7.so > > 7f639ae82000-7f639b082000 ---p 00002000 09:00 128447 > /lib/libdl-2.7.so > > 7f639b082000-7f639b084000 rw-p 00002000 09:00 128447 > /lib/libdl-2.7.so > > 7f639b084000-7f639b09a000 r-xp 00000000 09:00 128439 > /lib/libpthread-2.7.so > > 7f639b09a000-7f639b29a000 ---p 00016000 09:00 128439 > /lib/libpthread-2.7.so > > 7f639b29a000-7f639b29c000 rw-p 00016000 09:00 128439 > /lib/libpthread-2.7.so > > 7f639b29c000-7f639b2a0000 rw-p 7f639b29c000 00:00 0 > > 7f639b2a0000-7f639b2b6000 r-xp 00000000 09:00 370185 > /usr/lib/libz.so.1.2.3.3 > > 7f639b2b6000-7f639b4b6000 ---p 00016000 09:00 370185 > /usr/lib/libz.so.1.2.3.3 > > 7f639b4b6000-7f639b4b7000 rw-p 00016000 09:00 370185 > /usr/lib/libz.so.1.2.3.3 > > 7f639b4b7000-7f639b4d3000 r-xp 00000000 09:00 128446 > /lib/ld-2.7.so > > 7f639b5bd000-7f639b5c2000 r-xp 00000000 09:00 416988 > /usr/lib/rsyslog/lmnet.so > > 7f639b5c2000-7f639b6c1000 ---p 00005000 09:00 416988 > /usr/lib/rsyslog/lmnet.so > > 7f639b6c1000-7f639b6c2000 rw-p 00004000 09:00 416988 > /usr/lib/rsyslog/lmnet.so > > 7f639b6c2000-7f639b6c5000 rw-p 7f639b6c2000 00:00 0 > > 7f639b6ce000-7f639b6d2000 rw-p 7f639b6ce000 00:00 0 > > 7f639b6d2000-7f639b6d4000 rw-p 0001b000 09:00 128446 > /lib/ld-2.7.so > > 7fffa36bf000-7fffa36d4000 rw-p 7ffffffea000 00:00 0 > [stack] > > 7fffa36ff000-7fffa3700000 r-xp 7fffa36ff000 00:00 0 > [vdso] > > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From lorenzo at sancho.ccd.uniroma2.it Mon Feb 2 17:37:35 2009 From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci) Date: Mon, 2 Feb 2009 17:37:35 +0100 (CET) Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <49871292.9000900@ipax.at> References: <49871292.9000900@ipax.at> Message-ID: Feels familiar. Would you mind sending some more info about your server ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free ? ) I think it is the same stuff that Rainer debugged and solved last week. If you feel so, I think you should try and install a later version. Thank you very much, yours lorenzo On Mon, 2 Feb 2009, Raoul Bhatia [IPAX] wrote: RBI> hi, RBI> RBI> i do not know if this has already been addressed - so sorry for RBI> a possible duplicate. RBI> RBI> revision: RBI> > Feb 2 16:29:58 wc02 kernel: imklog 3.20.0, log source = /proc/kmsg started. RBI> > Feb 2 16:29:58 wc02 rsyslogd: [origin software="rsyslogd" swVersion="3.20.0" x-pid="27617" x-info="http://www.rsyslog.com"] restart RBI> RBI> running on debian logging remotely to another server. RBI> RBI> cheers, RBI> raoul RBI> RBI> > *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** RBI> > ======= Backtrace: ========= RBI> > /lib/libc.so.6[0x7f639a997948] RBI> > /lib/libc.so.6(cfree+0x76)[0x7f639a999a56] RBI> > /usr/sbin/rsyslogd(msgDestruct+0x3c)[0x415f7c] RBI> > /usr/sbin/rsyslogd(actionCallAction+0xcd)[0x4281cd] RBI> > /usr/sbin/rsyslogd[0x409de9] RBI> > /usr/sbin/rsyslogd(llExecFunc+0x58)[0x4168e8] RBI> > /usr/sbin/rsyslogd[0x409ad5] RBI> > /usr/sbin/rsyslogd[0x4244ef] RBI> > /usr/sbin/rsyslogd(wtiWorker+0x24f)[0x42124f] RBI> > /usr/sbin/rsyslogd[0x420968] RBI> > /lib/libpthread.so.0[0x7f639b08afc7] RBI> > /lib/libc.so.6(clone+0x6d)[0x7f639a9f35ad] RBI> > ======= Memory map: ======== RBI> > 00400000-0043c000 r-xp 00000000 09:00 384769 /usr/sbin/rsyslogd RBI> > 0053b000-00540000 rw-p 0003b000 09:00 384769 /usr/sbin/rsyslogd RBI> > 00540000-00541000 rw-p 00540000 00:00 0 RBI> > 00ebc000-00f6e000 rw-p 00ebc000 00:00 0 [heap] RBI> > 40219000-4021a000 ---p 40219000 00:00 0 RBI> > 4021a000-40a1a000 rw-p 4021a000 00:00 0 RBI> > 40c65000-40c66000 ---p 40c65000 00:00 0 RBI> > 40c66000-41466000 rw-p 40c66000 00:00 0 RBI> > 41466000-41467000 ---p 41466000 00:00 0 RBI> > 41467000-41c67000 rw-p 41467000 00:00 0 RBI> > 41cff000-41d00000 ---p 41cff000 00:00 0 RBI> > 41d00000-42500000 rw-p 41d00000 00:00 0 RBI> > 7f638c000000-7f638c021000 rw-p 7f638c000000 00:00 0 RBI> > 7f638c021000-7f6390000000 ---p 7f638c021000 00:00 0 RBI> > 7f6394000000-7f6394021000 rw-p 7f6394000000 00:00 0 RBI> > 7f6394021000-7f6398000000 ---p 7f6394021000 00:00 0 RBI> > 7f63995aa000-7f63995c0000 r-xp 00000000 09:00 128682 /lib/libgcc_s.so.1 RBI> > 7f63995c0000-7f63997c0000 ---p 00016000 09:00 128682 /lib/libgcc_s.so.1 RBI> > 7f63997c0000-7f63997c1000 rw-p 00016000 09:00 128682 /lib/libgcc_s.so.1 RBI> > 7f63997c1000-7f63997d1000 r-xp 00000000 09:00 128437 /lib/libresolv-2.7.so RBI> > 7f63997d1000-7f63999d1000 ---p 00010000 09:00 128437 /lib/libresolv-2.7.so RBI> > 7f63999d1000-7f63999d3000 rw-p 00010000 09:00 128437 /lib/libresolv-2.7.so RBI> > 7f63999d3000-7f63999d5000 rw-p 7f63999d3000 00:00 0 RBI> > 7f63999d5000-7f63999d9000 r-xp 00000000 09:00 128444 /lib/libnss_dns-2.7.so RBI> > 7f63999d9000-7f6399bd8000 ---p 00004000 09:00 128444 /lib/libnss_dns-2.7.so RBI> > 7f6399bd8000-7f6399bda000 rw-p 00003000 09:00 128444 /lib/libnss_dns-2.7.so RBI> > 7f6399bda000-7f6399bde000 r-xp 00000000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so RBI> > 7f6399bde000-7f6399cdd000 ---p 00004000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so RBI> > 7f6399cdd000-7f6399cde000 rw-p 00003000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so RBI> > 7f6399cde000-7f6399ce0000 r-xp 00000000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so RBI> > 7f6399ce0000-7f6399ddf000 ---p 00002000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so RBI> > 7f6399ddf000-7f6399de0000 rw-p 00001000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so RBI> > 7f6399de0000-7f6399de3000 r-xp 00000000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so RBI> > 7f6399de3000-7f6399ee2000 ---p 00003000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so RBI> > 7f6399ee2000-7f6399ee3000 rw-p 00002000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so RBI> > 7f6399ee3000-7f6399eed000 r-xp 00000000 09:00 128429 /lib/libnss_nis-2.7.so RBI> > 7f6399eed000-7f639a0ec000 ---p 0000a000 09:00 128429 /lib/libnss_nis-2.7.so RBI> > 7f639a0ec000-7f639a0ee000 rw-p 00009000 09:00 128429 /lib/libnss_nis-2.7.so RBI> > 7f639a0ee000-7f639a103000 r-xp 00000000 09:00 128433 /lib/libnsl-2.7.so RBI> > 7f639a103000-7f639a302000 ---p 00015000 09:00 128433 /lib/libnsl-2.7.so RBI> > 7f639a302000-7f639a304000 rw-p 00014000 09:00 128433 /lib/libnsl-2.7.so RBI> > 7f639a304000-7f639a306000 rw-p 7f639a304000 00:00 0 RBI> > 7f639a306000-7f639a30d000 r-xp 00000000 09:00 128435 /lib/libnss_compat-2.7.so RBI> > 7f639a30d000-7f639a50c000 ---p 00007000 09:00 128435 /lib/libnss_compat-2.7.so RBI> > 7f639a50c000-7f639a50e000 rw-p 00006000 09:00 128435 /lib/libnss_compat-2.7.so RBI> > 7f639a50e000-7f639a513000 r-xp 00000000 09:00 416987 /usr/lib/rsyslog/imklog.so RBI> > 7f639a513000-7f639a613000 ---p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so RBI> > 7f639a613000-7f639a614000 rw-p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so RBI> > 7f639a614000-7f639a615000 rw-p 7f639a614000 00:00 0 RBI> > 7f639a615000-7f639a617000 r-xp 00000000 09:00 416978 /usr/lib/rsyslog/imuxsock.so RBI> > 7f639a617000-7f639a717000 ---p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so RBI> > 7f639a717000-7f639a718000 rw-p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so RBI> > 7f639a718000-7f639a722000 r-xp 00000000 09:00 128440 /lib/libnss_files-2.7.so RBI> > 7f639a722000-7f639a922000 ---p 0000a000 09:00 128440 /lib/libnss_files-2.7.so RBI> > 7f639a922000-7f639a924000 rw-p 0000a000 09:00 128440 /lib/libnss_files-2.7.so RBI> > 7f639a924000-7f639aa6e000 r-xp 00000000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639aa6e000-7f639ac6d000 ---p 0014a000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639ac6d000-7f639ac70000 r--p 00149000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639ac70000-7f639ac72000 rw-p 0014c000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639ac72000-7f639ac77000 rw-p 7f639ac72000 00:00 0 RBI> > 7f639ac77000-7f639ac7f000 r-xp 00000000 09:00 128449 /lib/librt-2.7.so RBI> > 7f639ac7f000-7f639ae7e000 ---p 00008000 09:00 128449 /lib/librt-2.7.so RBI> > 7f639ae7e000-7f639ae80000 rw-p 00007000 09:00 128449 /lib/librt-2.7.so RBI> > 7f639ae80000-7f639ae82000 r-xp 00000000 09:00 128447 /lib/libdl-2.7.so RBI> > 7f639ae82000-7f639b082000 ---p 00002000 09:00 128447 /lib/libdl-2.7.so RBI> > 7f639b082000-7f639b084000 rw-p 00002000 09:00 128447 /lib/libdl-2.7.so RBI> > 7f639b084000-7f639b09a000 r-xp 00000000 09:00 128439 /lib/libpthread-2.7.so RBI> > 7f639b09a000-7f639b29a000 ---p 00016000 09:00 128439 /lib/libpthread-2.7.so RBI> > 7f639b29a000-7f639b29c000 rw-p 00016000 09:00 128439 /lib/libpthread-2.7.so RBI> > 7f639b29c000-7f639b2a0000 rw-p 7f639b29c000 00:00 0 RBI> > 7f639b2a0000-7f639b2b6000 r-xp 00000000 09:00 370185 /usr/lib/libz.so.1.2.3.3 RBI> > 7f639b2b6000-7f639b4b6000 ---p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 RBI> > 7f639b4b6000-7f639b4b7000 rw-p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 RBI> > 7f639b4b7000-7f639b4d3000 r-xp 00000000 09:00 128446 /lib/ld-2.7.so RBI> > 7f639b5bd000-7f639b5c2000 r-xp 00000000 09:00 416988 /usr/lib/rsyslog/lmnet.so RBI> > 7f639b5c2000-7f639b6c1000 ---p 00005000 09:00 416988 /usr/lib/rsyslog/lmnet.so RBI> > 7f639b6c1000-7f639b6c2000 rw-p 00004000 09:00 416988 /usr/lib/rsyslog/lmnet.so RBI> > 7f639b6c2000-7f639b6c5000 rw-p 7f639b6c2000 00:00 0 RBI> > 7f639b6ce000-7f639b6d2000 rw-p 7f639b6ce000 00:00 0 RBI> > 7f639b6d2000-7f639b6d4000 rw-p 0001b000 09:00 128446 /lib/ld-2.7.so RBI> > 7fffa36bf000-7fffa36d4000 rw-p 7ffffffea000 00:00 0 [stack] RBI> > 7fffa36ff000-7fffa3700000 r-xp 7fffa36ff000 00:00 0 [vdso] RBI> > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] RBI> _______________________________________________ RBI> rsyslog mailing list RBI> http://lists.adiscon.net/mailman/listinfo/rsyslog RBI> http://www.rsyslog.com RBI> +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+ From r.bhatia at ipax.at Mon Feb 2 18:02:12 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Mon, 02 Feb 2009 18:02:12 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: References: <49871292.9000900@ipax.at> Message-ID: <49872714.8050901@ipax.at> Lorenzo M. Catucci wrote: > Feels familiar. > > Would you mind sending some more info about your server > ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free ? ) > > I think it is the same stuff that Rainer debugged and solved last week. If > you feel so, I think you should try and install a later version. > > Thank you very much, yours sure, see below. please note that i already rebootet the server. for trying a new release: sure, i have no issue with that. shall i try the one that can be found in sid (3.20.3-1) or a newer one? cheers, raoul > # uname -a > Linux wc02 2.6.27.13 #2 SMP Sat Jan 31 18:32:34 CET 2009 x86_64 GNU/Linux > # cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > stepping : 6 > cpu MHz : 2993.390 > cache size : 6144 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 2 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > bogomips : 5986.78 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 1 > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > stepping : 6 > cpu MHz : 2993.390 > cache size : 6144 KB > physical id : 0 > siblings : 2 > core id : 1 > cpu cores : 2 > apicid : 1 > initial apicid : 1 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > bogomips : 5986.77 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > # cat /etc/debian_version > 5.0 > # free > total used free shared buffers cached > Mem: 2052076 336392 1715684 0 98580 107268 > -/+ buffers/cache: 130544 1921532 > Swap: 1999992 0 1999992 -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From rgerhards at hq.adiscon.com Mon Feb 2 18:16:17 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 18:16:17 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <49872714.8050901@ipax.at> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Hi Raoul, I don't keep track of the bug in the older releases - simply too much work, especially in this case. The best would be to use v3-stable from git (I have not yet released a tarball as I'd like to get some feedback from the field, first - not too often release stable versions..). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Monday, February 02, 2009 6:02 PM > To: rsyslog-users > Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: > double free or corruption (!prev): 0x0000000000ef03b0 *** > > Lorenzo M. Catucci wrote: > > Feels familiar. > > > > Would you mind sending some more info about your server > > ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free > ? ) > > > > I think it is the same stuff that Rainer debugged and solved last > week. If > > you feel so, I think you should try and install a later version. > > > > Thank you very much, yours > > sure, see below. > > please note that i already rebootet the server. > > for trying a new release: sure, i have no issue with that. shall i try > the one that can be found in sid (3.20.3-1) or a newer one? > > cheers, > raoul > > > # uname -a > > Linux wc02 2.6.27.13 #2 SMP Sat Jan 31 18:32:34 CET 2009 x86_64 > GNU/Linux > > > # cat /proc/cpuinfo > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 23 > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > > stepping : 6 > > cpu MHz : 2993.390 > > cache size : 6144 KB > > physical id : 0 > > siblings : 2 > > core id : 0 > > cpu cores : 2 > > apicid : 0 > > initial apicid : 0 > > fpu : yes > > fpu_exception : yes > > cpuid level : 10 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > > bogomips : 5986.78 > > clflush size : 64 > > cache_alignment : 64 > > address sizes : 36 bits physical, 48 bits virtual > > power management: > > > > processor : 1 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 23 > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > > stepping : 6 > > cpu MHz : 2993.390 > > cache size : 6144 KB > > physical id : 0 > > siblings : 2 > > core id : 1 > > cpu cores : 2 > > apicid : 1 > > initial apicid : 1 > > fpu : yes > > fpu_exception : yes > > cpuid level : 10 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > > bogomips : 5986.77 > > clflush size : 64 > > cache_alignment : 64 > > address sizes : 36 bits physical, 48 bits virtual > > power management: > > > # cat /etc/debian_version > > 5.0 > > > > # free > > total used free shared buffers > cached > > Mem: 2052076 336392 1715684 0 98580 > 107268 > > -/+ buffers/cache: 130544 1921532 > > Swap: 1999992 0 1999992 > > -- > ____________________________________________________________________ > DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at > Technischer Leiter > > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at > Barawitzkagasse 10/2/2/11 email. office at ipax.at > 1190 Wien tel. +43 1 3670030 > FN 277995t HG Wien fax. +43 1 3670030 15 > ____________________________________________________________________ > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From lorenzo at sancho.ccd.uniroma2.it Mon Feb 2 18:31:31 2009 From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci) Date: Mon, 2 Feb 2009 18:31:31 +0100 (CET) Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at> <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Message-ID: On Mon, 2 Feb 2009, Rainer Gerhards wrote: RG> Hi Raoul, RG> RG> I don't keep track of the bug in the older releases - simply too much RG> work, especially in this case. The best would be to use v3-stable from RG> git (I have not yet released a tarball as I'd like to get some feedback RG> from the field, first - not too often release stable versions..). RG> RG> Rainer RG> Since I'm git-dumb (I know, it runs (almost) as fast as light, but I still find it too confusing, especially when compared to hg...) I think a quick-recipe could be of use to others too: $ git clone git://git.adiscon.com/git/rsyslog.git rsyslog.git $ cd rsyslog.git $ git checkout origin/v3-stable and now go configure, make, make install... RG> RG> > -----Original Message----- RG> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- RG> > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] RG> > Sent: Monday, February 02, 2009 6:02 PM RG> > To: rsyslog-users RG> > Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: RG> > double free or corruption (!prev): 0x0000000000ef03b0 *** RG> > RG> > Lorenzo M. Catucci wrote: RG> > > Feels familiar. RG> > > RG> > > Would you mind sending some more info about your server RG> > > ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free RG> > ? ) RG> > > RG> > > I think it is the same stuff that Rainer debugged and solved last RG> > week. If RG> > > you feel so, I think you should try and install a later version. RG> > > RG> > > Thank you very much, yours RG> > RG> > sure, see below. RG> > RG> > please note that i already rebootet the server. RG> > RG> > for trying a new release: sure, i have no issue with that. shall i try RG> > the one that can be found in sid (3.20.3-1) or a newer one? RG> > RG> > cheers, RG> > raoul RG> > RG> > > # uname -a RG> > > Linux wc02 2.6.27.13 #2 SMP Sat Jan 31 18:32:34 CET 2009 x86_64 RG> > GNU/Linux RG> > RG> > > # cat /proc/cpuinfo RG> > > processor : 0 RG> > > vendor_id : GenuineIntel RG> > > cpu family : 6 RG> > > model : 23 RG> > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz RG> > > stepping : 6 RG> > > cpu MHz : 2993.390 RG> > > cache size : 6144 KB RG> > > physical id : 0 RG> > > siblings : 2 RG> > > core id : 0 RG> > > cpu cores : 2 RG> > > apicid : 0 RG> > > initial apicid : 0 RG> > > fpu : yes RG> > > fpu_exception : yes RG> > > cpuid level : 10 RG> > > wp : yes RG> > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr RG> > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe RG> > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni RG> monitor RG> > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm RG> > > bogomips : 5986.78 RG> > > clflush size : 64 RG> > > cache_alignment : 64 RG> > > address sizes : 36 bits physical, 48 bits virtual RG> > > power management: RG> > > RG> > > processor : 1 RG> > > vendor_id : GenuineIntel RG> > > cpu family : 6 RG> > > model : 23 RG> > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz RG> > > stepping : 6 RG> > > cpu MHz : 2993.390 RG> > > cache size : 6144 KB RG> > > physical id : 0 RG> > > siblings : 2 RG> > > core id : 1 RG> > > cpu cores : 2 RG> > > apicid : 1 RG> > > initial apicid : 1 RG> > > fpu : yes RG> > > fpu_exception : yes RG> > > cpuid level : 10 RG> > > wp : yes RG> > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr RG> > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe RG> > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni RG> monitor RG> > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm RG> > > bogomips : 5986.77 RG> > > clflush size : 64 RG> > > cache_alignment : 64 RG> > > address sizes : 36 bits physical, 48 bits virtual RG> > > power management: RG> > RG> > > # cat /etc/debian_version RG> > > 5.0 RG> > RG> > RG> > > # free RG> > > total used free shared buffers RG> > cached RG> > > Mem: 2052076 336392 1715684 0 98580 RG> > 107268 RG> > > -/+ buffers/cache: 130544 1921532 RG> > > Swap: 1999992 0 1999992 RG> > RG> > -- RG> > ____________________________________________________________________ RG> > DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at RG> > Technischer Leiter RG> > RG> > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at RG> > Barawitzkagasse 10/2/2/11 email. office at ipax.at RG> > 1190 Wien tel. +43 1 3670030 RG> > FN 277995t HG Wien fax. +43 1 3670030 15 RG> > ____________________________________________________________________ RG> > _______________________________________________ RG> > rsyslog mailing list RG> > http://lists.adiscon.net/mailman/listinfo/rsyslog RG> > http://www.rsyslog.com RG> _______________________________________________ RG> rsyslog mailing list RG> http://lists.adiscon.net/mailman/listinfo/rsyslog RG> http://www.rsyslog.com RG> +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+ From rgerhards at hq.adiscon.com Mon Feb 2 18:37:34 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 18:37:34 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: References: <49871292.9000900@ipax.at><49872714.8050901@ipax.at><577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAF2@grfint2.intern.adiscon.com> Thanks, I should have mentioned. But one step missing: > Since I'm git-dumb (I know, it runs (almost) as fast as light, but I > still > find it too confusing, especially when compared to hg...) I think a > quick-recipe could be of use to others too: > > $ git clone git://git.adiscon.com/git/rsyslog.git rsyslog.git > $ cd rsyslog.git > $ git checkout origin/v3-stable > $ autoreconf -vfi # build ./configure > and now go configure, make, make install... From mic at npgx.com.au Tue Feb 3 06:08:07 2009 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 3 Feb 2009 16:08:07 +1100 Subject: [rsyslog] Logging directives for a milter Message-ID: <20090203050119.M91067@npgx.com.au> Hi, I'm using rsyslog 3.18.0 (have been for longer than I can remember now). I have recently installed a milter for sendmail, and the milter docs show: LOGGING milter-regex sends log messages to syslogd(8) using facility daemon and, with increasing verbosity, level err, notice, info and debug. The fol- lowing syslog.conf(5) section can be used to log messages to a dedicated file: !milter-regex daemon.err;daemon.notice /var/log/milter-regex I use rsyslog in TraditionalFileFormat and have this entry: *.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages which captures all the daemon.info messages (a lot of them) into my /var/log/messages. I added the daemon.info to: mail.*;daemon.info -/var/log/maillog so that I would rightly get the messages included into my maillog file, but how do I now remove the messages from my /var/log/messages file with the *.info capturing that there? I've tried using: *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none /var/log/messages but just that line stopped all daemon logging into the messages file, so basically a day passed and nothing was logged there. Thanks. Michael. From hks.private at gmail.com Tue Feb 3 17:12:25 2009 From: hks.private at gmail.com ((private) HKS) Date: Tue, 3 Feb 2009 11:12:25 -0500 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <20090203050119.M91067@npgx.com.au> References: <20090203050119.M91067@npgx.com.au> Message-ID: On Tue, Feb 3, 2009 at 12:08 AM, Michael Mansour wrote: > Hi, > > I'm using rsyslog 3.18.0 (have been for longer than I can remember now). > > I have recently installed a milter for sendmail, and the milter docs show: > > LOGGING > milter-regex sends log messages to syslogd(8) using facility daemon and, > with increasing verbosity, level err, notice, info and debug. The fol- > lowing syslog.conf(5) section can be used to log messages to a dedicated > file: > > !milter-regex > daemon.err;daemon.notice /var/log/milter-regex > > I use rsyslog in TraditionalFileFormat and have this entry: > > *.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages > > which captures all the daemon.info messages (a lot of them) into my > /var/log/messages. > > I added the daemon.info to: > > mail.*;daemon.info -/var/log/maillog > > so that I would rightly get the messages included into my maillog file, but > how do I now remove the messages from my /var/log/messages file with the > *.info capturing that there? > > I've tried using: > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > /var/log/messages > > but just that line stopped all daemon logging into the messages file, so > basically a day passed and nothing was logged there. > > Thanks. > > Michael. > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com Change this: *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none /var/log/messages To this: *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice /var/log/messages -HKS From mic at npgx.com.au Wed Feb 4 01:30:20 2009 From: mic at npgx.com.au (Michael Mansour) Date: Wed, 4 Feb 2009 11:30:20 +1100 Subject: [rsyslog] Logging directives for a milter In-Reply-To: References: <20090203050119.M91067@npgx.com.au> Message-ID: <20090204002209.M97796@npgx.com.au> Hi HKS, Thanks for your reply. > On Tue, Feb 3, 2009 at 12:08 AM, Michael Mansour wrote: > > Hi, > > > > I'm using rsyslog 3.18.0 (have been for longer than I can remember now). > > > > I have recently installed a milter for sendmail, and the milter docs show: > > > > LOGGING > > milter-regex sends log messages to syslogd(8) using facility daemon and, > > with increasing verbosity, level err, notice, info and debug. The fol- > > lowing syslog.conf(5) section can be used to log messages to a dedicated > > file: > > > > !milter-regex > > daemon.err;daemon.notice /var/log/milter-regex > > > > I use rsyslog in TraditionalFileFormat and have this entry: > > > > *.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages > > > > which captures all the daemon.info messages (a lot of them) into my > > /var/log/messages. > > > > I added the daemon.info to: > > > > mail.*;daemon.info -/var/log/maillog > > > > so that I would rightly get the messages included into my maillog file, but > > how do I now remove the messages from my /var/log/messages file with the > > *.info capturing that there? > > > > I've tried using: > > > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > > /var/log/messages > > > > but just that line stopped all daemon logging into the messages file, so > > basically a day passed and nothing was logged there. > > > > Thanks. > > > > Michael. > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > Change this: > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > /var/log/messages > > To this: > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice > /var/log/messages I've just tried that, restarted rsyslog and the messages for milter-regex keep appearing in /var/log/messages. I'm 100% these are daemon.info messages since I also use: mail.*;daemon.info -/var/log/maillog and the milter-regex messages that show up in /var/log/maillog are the same ones that show up in /var/log/messages. I'm pretty sure the reason that deamon.info is still going to /var/log/messages is because of the "*.info" entry at the beginning of that line, which catches daemon.info? Is there a way I can stop daemon.info from showing up in /var/log/messages while keeping *.info on that same line? Thanks. Michael. > -HKS > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com ------- End of Original Message ------- From kenneho.ndu at gmail.com Wed Feb 4 09:58:54 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 09:58:54 +0100 Subject: [rsyslog] Configuring rsyslog failover Message-ID: Hello list. We're running rsyslog 2.0.6 downloaded from RHN, and are about to set up reliability/failover. I've found two setup tutorials for this: 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer It seems like both setups configure reliable transfer, but using a completely different syntax. Is it so that the former one is the syntax for newer versions of rsyslog? Regards, Kenneth Holter From rgerhards at hq.adiscon.com Wed Feb 4 10:01:48 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 10:01:48 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> Hi Kenneth, the first link does NOT describe a failover case. In the first link, data is queued while the syslogd is not available. A failover case (described in link two) is that if one syslogd goes down, data is sent to another. This is not done in case 1: there, messages are queued while the syslogd is down and sent to *the same syslogd* when it is up again. So no second syslogd involved in case 1, so this is no failover scenario. HTH Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 9:59 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Configuring rsyslog failover > > Hello list. > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to set > up > reliability/failover. I've found two setup tutorials for this: > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > It seems like both setups configure reliable transfer, but using a > completely different syntax. Is it so that the former one is the syntax > for > newer versions of rsyslog? > > Regards, > Kenneth Holter > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 4 10:13:29 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 10:13:29 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> Message-ID: Thanks for the quick reply. You're right, it's not a failover solution by definition. I see now that I should have outlined my needs... What I'm aiming at, at least for now, is a semi-failover solution: If the syslog server (i.e. loghost) goes down, the clients should simply spool the messages until the server gets back online. Back to the examples I linked to: They both seem to provide the functionality I'm looking for. Is that correct? If so: what's the difference between them? On 2/4/09, Rainer Gerhards wrote: > > Hi Kenneth, > > the first link does NOT describe a failover case. In the first link, > data is queued while the syslogd is not available. A failover case > (described in link two) is that if one syslogd goes down, data is sent > to another. This is not done in case 1: there, messages are queued while > the syslogd is down and sent to *the same syslogd* when it is up again. > So no second syslogd involved in case 1, so this is no failover > scenario. > > HTH > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 9:59 AM > > To: rsyslog at lists.adiscon.com > > Subject: [rsyslog] Configuring rsyslog failover > > > > Hello list. > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to set > > up > > reliability/failover. I've found two setup tutorials for this: > > > > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > It seems like both setups configure reliable transfer, but using a > > completely different syntax. Is it so that the former one is the > syntax > > for > > newer versions of rsyslog? > > > > Regards, > > Kenneth Holter > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Wed Feb 4 10:55:51 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 10:55:51 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 10:13 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Thanks for the quick reply. > > You're right, it's not a failover solution by definition. I see now > that I > should have outlined my needs... What I'm aiming at, at least for now, > is a > semi-failover solution: If the syslog server (i.e. loghost) goes down, > the > clients should simply spool the messages until the server gets back > online. > > Back to the examples I linked to: They both seem to provide the > functionality I'm looking for. Is that correct? If so: what's the > difference > between them? No! ;) As I said, #2 is a failover scenario - it does not spool but rather send the messags to another (failover) server if the primary fails. Rainer > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > Hi Kenneth, > > > > the first link does NOT describe a failover case. In the first link, > > data is queued while the syslogd is not available. A failover case > > (described in link two) is that if one syslogd goes down, data is > sent > > to another. This is not done in case 1: there, messages are queued > while > > the syslogd is down and sent to *the same syslogd* when it is up > again. > > So no second syslogd involved in case 1, so this is no failover > > scenario. > > > > HTH > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > To: rsyslog at lists.adiscon.com > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > Hello list. > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to > set > > > up > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > It seems like both setups configure reliable transfer, but using a > > > completely different syntax. Is it so that the former one is the > > syntax > > > for > > > newer versions of rsyslog? > > > > > > Regards, > > > Kenneth Holter > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Wed Feb 4 11:06:08 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 11:06:08 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Oops... and I just noticed you use v2. Spooling is not available in v2. Sorry for not spotting it in the first place... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Wednesday, February 04, 2009 10:56 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 10:13 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > Thanks for the quick reply. > > > > You're right, it's not a failover solution by definition. I see now > > that I > > should have outlined my needs... What I'm aiming at, at least for > now, > > is a > > semi-failover solution: If the syslog server (i.e. loghost) goes > down, > > the > > clients should simply spool the messages until the server gets back > > online. > > > > Back to the examples I linked to: They both seem to provide the > > functionality I'm looking for. Is that correct? If so: what's the > > difference > > between them? > > No! ;) As I said, #2 is a failover scenario - it does not spool but > rather send the messags to another (failover) server if the primary > fails. > > Rainer > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > Hi Kenneth, > > > > > > the first link does NOT describe a failover case. In the first > link, > > > data is queued while the syslogd is not available. A failover case > > > (described in link two) is that if one syslogd goes down, data is > > sent > > > to another. This is not done in case 1: there, messages are queued > > while > > > the syslogd is down and sent to *the same syslogd* when it is up > > again. > > > So no second syslogd involved in case 1, so this is no failover > > > scenario. > > > > > > HTH > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > To: rsyslog at lists.adiscon.com > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > Hello list. > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to > > set > > > > up > > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > It seems like both setups configure reliable transfer, but using > a > > > > completely different syntax. Is it so that the former one is the > > > syntax > > > > for > > > > newer versions of rsyslog? > > > > > > > > Regards, > > > > Kenneth Holter > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 4 13:42:13 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 13:42:13 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: No prob. :) Then I'm even more puzzled...I've configured my rsyslog client with this setup: ** **.* @@client1.example.com:200 $ActionExecOnlyWhenPreviousIsSuspended on & /var/log/localbuffer $ActionExecOnlyWhenPreviousIsSuspended off* If I cut the link to the syslog-server (using iptables to emulate the logserver being down), run "logger hello" on the client, and then after a while attach the link (by flushing the iptable rules), I see that the hello message pops up on the rsyslog server. So some kind of spooling or something seems to be active. Strange. Maybe the spooling or whatever is done on TCP level or something. Maybe the rsyslog version from RHN differs from the "normal" versioning? On 2/4/09, Rainer Gerhards wrote: > Oops... and I just noticed you use v2. Spooling is not available in v2. > > Sorry for not spotting it in the first place... > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Wednesday, February 04, 2009 10:56 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > Thanks for the quick reply. > > > > > > You're right, it's not a failover solution by definition. I see now > > > that I > > > should have outlined my needs... What I'm aiming at, at least for > > now, > > > is a > > > semi-failover solution: If the syslog server (i.e. loghost) goes > > down, > > > the > > > clients should simply spool the messages until the server gets back > > > online. > > > > > > Back to the examples I linked to: They both seem to provide the > > > functionality I'm looking for. Is that correct? If so: what's the > > > difference > > > between them? > > > > No! ;) As I said, #2 is a failover scenario - it does not spool but > > rather send the messags to another (failover) server if the primary > > fails. > > > > Rainer > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > Hi Kenneth, > > > > > > > > the first link does NOT describe a failover case. In the first > > link, > > > > data is queued while the syslogd is not available. A failover case > > > > (described in link two) is that if one syslogd goes down, data is > > > sent > > > > to another. This is not done in case 1: there, messages are queued > > > while > > > > the syslogd is down and sent to *the same syslogd* when it is up > > > again. > > > > So no second syslogd involved in case 1, so this is no failover > > > > scenario. > > > > > > > > HTH > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > To: rsyslog at lists.adiscon.com > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about > to > > > set > > > > > up > > > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > > > > > > > 1. > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > It seems like both setups configure reliable transfer, but using > > a > > > > > completely different syntax. Is it so that the former one is the > > > > syntax > > > > > for > > > > > newer versions of rsyslog? > > > > > > > > > > Regards, > > > > > Kenneth Holter > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From kenneho.ndu at gmail.com Wed Feb 4 14:02:50 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 14:02:50 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: It seems like RHN is way behind on adding rsyslog updates to the repo, so it seems like I'm more or less stuck with version 2 for now. Are there any failover/spooling/etc functionality in version 2? I'd like to increase the chance of syslog messages reaching the syslog server, even if it gets offline for a short while. I'm sure it's possible to acheive this by smart (over-)engineering while waiting for rsyslog v3 being released on RHN, but I'm all for simplicity. :) On 2/4/09, Kenneth Holter wrote: > > No prob. :) > > Then I'm even more puzzled...I've configured my rsyslog client with this > setup: > ** > > **.* @@client1.example.com:200 > $ActionExecOnlyWhenPreviousIsSuspended on > & /var/log/localbuffer > $ActionExecOnlyWhenPreviousIsSuspended off* > > > If I cut the link to the syslog-server (using iptables to emulate the > logserver being down), run "logger hello" on the client, and then after a > while attach the link (by flushing the iptable rules), I see that the hello > message pops up on the rsyslog server. So some kind of spooling or something > seems to be active. Strange. Maybe the spooling or whatever is done on TCP > level or something. Maybe the rsyslog version from RHN differs from the > "normal" versioning? > > > > > On 2/4/09, Rainer Gerhards wrote: > > Oops... and I just noticed you use v2. Spooling is not available in v2. > > > > Sorry for not spotting it in the first place... > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > Thanks for the quick reply. > > > > > > > > You're right, it's not a failover solution by definition. I see now > > > > that I > > > > should have outlined my needs... What I'm aiming at, at least for > > > now, > > > > is a > > > > semi-failover solution: If the syslog server (i.e. loghost) goes > > > down, > > > > the > > > > clients should simply spool the messages until the server gets back > > > > online. > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > functionality I'm looking for. Is that correct? If so: what's the > > > > difference > > > > between them? > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool but > > > rather send the messags to another (failover) server if the primary > > > fails. > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > Hi Kenneth, > > > > > > > > > > the first link does NOT describe a failover case. In the first > > > link, > > > > > data is queued while the syslogd is not available. A failover case > > > > > (described in link two) is that if one syslogd goes down, data is > > > > sent > > > > > to another. This is not done in case 1: there, messages are queued > > > > while > > > > > the syslogd is down and sent to *the same syslogd* when it is up > > > > again. > > > > > So no second syslogd involved in case 1, so this is no failover > > > > > scenario. > > > > > > > > > > HTH > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about > > to > > > > set > > > > > > up > > > > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > > > > > > > > > > 1. > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > It seems like both setups configure reliable transfer, but using > > > a > > > > > > completely different syntax. Is it so that the former one is the > > > > > syntax > > > > > > for > > > > > > newer versions of rsyslog? > > > > > > > > > > > > Regards, > > > > > > Kenneth Holter > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > > From rgerhards at hq.adiscon.com Wed Feb 4 14:12:45 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 14:12:45 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB2D@grfint2.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 1:42 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > No prob. :) > > Then I'm even more puzzled...I've configured my rsyslog client with > this > setup: > ** > > **.* @@client1.example.com:200 > $ActionExecOnlyWhenPreviousIsSuspended on > & /var/log/localbuffer > $ActionExecOnlyWhenPreviousIsSuspended off* > > > If I cut the link to the syslog-server (using iptables to emulate the > logserver being down), run "logger hello" on the client, and then after > a > while attach the link (by flushing the iptable rules), I see that the > hello > message pops up on the rsyslog server. So some kind of spooling or > something > seems to be active. Strange. Maybe the spooling or whatever is done on > TCP > level or something. Maybe the rsyslog version from RHN differs from the > "normal" versioning? This has lot's to do with your test environment (you really don't break the link but just make it impossible to send for a period of time), the local tcp send buffer and the way TCP is designed. I suggest to have an in-depth look at http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.ht ml To do your lab, try to send multiple messages and/or make sure you restart the receiving server while the connection is blocked. You will notice some message loss during that process, this is expected, reasons are in my blog post quoted above. Note that v3 has some improved code to reduce message loss, but in any case there potentially is loss. V2 looses more messages than v3. Rainer > > > > > On 2/4/09, Rainer Gerhards wrote: > > Oops... and I just noticed you use v2. Spooling is not available in > v2. > > > > Sorry for not spotting it in the first place... > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > Thanks for the quick reply. > > > > > > > > You're right, it's not a failover solution by definition. I see > now > > > > that I > > > > should have outlined my needs... What I'm aiming at, at least for > > > now, > > > > is a > > > > semi-failover solution: If the syslog server (i.e. loghost) goes > > > down, > > > > the > > > > clients should simply spool the messages until the server gets > back > > > > online. > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > functionality I'm looking for. Is that correct? If so: what's the > > > > difference > > > > between them? > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool but > > > rather send the messags to another (failover) server if the primary > > > fails. > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > Hi Kenneth, > > > > > > > > > > the first link does NOT describe a failover case. In the first > > > link, > > > > > data is queued while the syslogd is not available. A failover > case > > > > > (described in link two) is that if one syslogd goes down, data > is > > > > sent > > > > > to another. This is not done in case 1: there, messages are > queued > > > > while > > > > > the syslogd is down and sent to *the same syslogd* when it is > up > > > > again. > > > > > So no second syslogd involved in case 1, so this is no failover > > > > > scenario. > > > > > > > > > > HTH > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > about > > to > > > > set > > > > > > up > > > > > > reliability/failover. I've found two setup tutorials for > this: > > > > > > > > > > > > > > > > > > 1. > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > using > > > a > > > > > > completely different syntax. Is it so that the former one is > the > > > > > syntax > > > > > > for > > > > > > newer versions of rsyslog? > > > > > > > > > > > > Regards, > > > > > > Kenneth Holter > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Wed Feb 4 14:14:11 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 14:14:11 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Failover is available - that is done like you described in your last post. But you need to keep an eye on the subtleties, outlined in the response I've written just 2 minutes ago ;). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 2:03 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > It seems like RHN is way behind on adding rsyslog updates to the repo, > so it > seems like I'm more or less stuck with version 2 for now. Are there any > failover/spooling/etc functionality in version 2? I'd like to increase > the > chance of syslog messages reaching the syslog server, even if it gets > offline for a short while. I'm sure it's possible to acheive this by > smart > (over-)engineering while waiting for rsyslog v3 being released on RHN, > but > I'm all for simplicity. :) > > On 2/4/09, Kenneth Holter wrote: > > > > No prob. :) > > > > Then I'm even more puzzled...I've configured my rsyslog client with > this > > setup: > > ** > > > > **.* @@client1.example.com:200 > > $ActionExecOnlyWhenPreviousIsSuspended on > > & /var/log/localbuffer > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > If I cut the link to the syslog-server (using iptables to emulate the > > logserver being down), run "logger hello" on the client, and then > after a > > while attach the link (by flushing the iptable rules), I see that the > hello > > message pops up on the rsyslog server. So some kind of spooling or > something > > seems to be active. Strange. Maybe the spooling or whatever is done > on TCP > > level or something. Maybe the rsyslog version from RHN differs from > the > > "normal" versioning? > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > Oops... and I just noticed you use v2. Spooling is not available in > v2. > > > > > > Sorry for not spotting it in the first place... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > You're right, it's not a failover solution by definition. I see > now > > > > > that I > > > > > should have outlined my needs... What I'm aiming at, at least > for > > > > now, > > > > > is a > > > > > semi-failover solution: If the syslog server (i.e. loghost) > goes > > > > down, > > > > > the > > > > > clients should simply spool the messages until the server gets > back > > > > > online. > > > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > > functionality I'm looking for. Is that correct? If so: what's > the > > > > > difference > > > > > between them? > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > but > > > > rather send the messags to another (failover) server if the > primary > > > > fails. > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > the first link does NOT describe a failover case. In the > first > > > > link, > > > > > > data is queued while the syslogd is not available. A failover > case > > > > > > (described in link two) is that if one syslogd goes down, > data is > > > > > sent > > > > > > to another. This is not done in case 1: there, messages are > queued > > > > > while > > > > > > the syslogd is down and sent to *the same syslogd* when it is > up > > > > > again. > > > > > > So no second syslogd involved in case 1, so this is no > failover > > > > > > scenario. > > > > > > > > > > > > HTH > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > about > > > to > > > > > set > > > > > > > up > > > > > > > reliability/failover. I've found two setup tutorials for > this: > > > > > > > > > > > > > > > > > > > > > 1. > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > 2. > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > using > > > > a > > > > > > > completely different syntax. Is it so that the former one > is the > > > > > > syntax > > > > > > > for > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > Regards, > > > > > > > Kenneth Holter > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Wed Feb 4 12:58:03 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 04 Feb 2009 12:58:03 +0100 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <20090204002209.M97796@npgx.com.au> References: <20090203050119.M91067@npgx.com.au> <20090204002209.M97796@npgx.com.au> Message-ID: <1233748683.19733.113.camel@rf10up.intern.adiscon.com> On Wed, 2009-02-04 at 11:30 +1100, Michael Mansour wrote: > > Change this: > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > > /var/log/messages > > > > To this: > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice > > /var/log/messages > I think it should be *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.none /var/log/messages > I've just tried that, restarted rsyslog and the messages for milter-regex keep > appearing in /var/log/messages. > > I'm 100% these are daemon.info messages since I also use: > > mail.*;daemon.info -/var/log/maillog > > and the milter-regex messages that show up in /var/log/maillog are the same > ones that show up in /var/log/messages. > > I'm pretty sure the reason that deamon.info is still going to > /var/log/messages is because of the "*.info" entry at the beginning of that > line, which catches daemon.info? Yes, because that says "everything with info severity, no matter what the facility is, matches". > > Is there a way I can stop daemon.info from showing up in /var/log/messages > while keeping *.info on that same line? > The .none in my example above is meant to exclude a specific facility from the usual processing and this sounds like what you are looking for. I barely remember that someone had problems with it. So if it does not work, let me know. The part of the code that handles those old-style selectors (old but still good!) is one of the few code sequences that stem directly back to sysklogd and I can't outrule that something went wrong during all that changes of the engine... Please let me know the outcome (saves me the lab). Rainer From danson at rackspace.com Wed Feb 4 17:12:34 2009 From: danson at rackspace.com (Daniel Anson) Date: Wed, 4 Feb 2009 10:12:34 -0600 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Message-ID: <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> I personally run RHEL 5 servers with rsyslog. Due to the lack of a current and stable rsyslog rpm, I always build rsyslog on the server. It takes less than 5 minutes and is very stable. Daniel Anson Rackspace Managed Hosting danson at rackspace.com -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards Sent: Wednesday, February 04, 2009 7:14 AM To: rsyslog-users Subject: Re: [rsyslog] Configuring rsyslog failover Failover is available - that is done like you described in your last post. But you need to keep an eye on the subtleties, outlined in the response I've written just 2 minutes ago ;). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 2:03 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > It seems like RHN is way behind on adding rsyslog updates to the repo, > so it > seems like I'm more or less stuck with version 2 for now. Are there any > failover/spooling/etc functionality in version 2? I'd like to increase > the > chance of syslog messages reaching the syslog server, even if it gets > offline for a short while. I'm sure it's possible to acheive this by > smart > (over-)engineering while waiting for rsyslog v3 being released on RHN, > but > I'm all for simplicity. :) > > On 2/4/09, Kenneth Holter wrote: > > > > No prob. :) > > > > Then I'm even more puzzled...I've configured my rsyslog client with > this > > setup: > > ** > > > > **.* @@client1.example.com:200 > > $ActionExecOnlyWhenPreviousIsSuspended on > > & /var/log/localbuffer > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > If I cut the link to the syslog-server (using iptables to emulate the > > logserver being down), run "logger hello" on the client, and then > after a > > while attach the link (by flushing the iptable rules), I see that the > hello > > message pops up on the rsyslog server. So some kind of spooling or > something > > seems to be active. Strange. Maybe the spooling or whatever is done > on TCP > > level or something. Maybe the rsyslog version from RHN differs from > the > > "normal" versioning? > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > Oops... and I just noticed you use v2. Spooling is not available in > v2. > > > > > > Sorry for not spotting it in the first place... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > You're right, it's not a failover solution by definition. I see > now > > > > > that I > > > > > should have outlined my needs... What I'm aiming at, at least > for > > > > now, > > > > > is a > > > > > semi-failover solution: If the syslog server (i.e. loghost) > goes > > > > down, > > > > > the > > > > > clients should simply spool the messages until the server gets > back > > > > > online. > > > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > > functionality I'm looking for. Is that correct? If so: what's > the > > > > > difference > > > > > between them? > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > but > > > > rather send the messags to another (failover) server if the > primary > > > > fails. > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > the first link does NOT describe a failover case. In the > first > > > > link, > > > > > > data is queued while the syslogd is not available. A failover > case > > > > > > (described in link two) is that if one syslogd goes down, > data is > > > > > sent > > > > > > to another. This is not done in case 1: there, messages are > queued > > > > > while > > > > > > the syslogd is down and sent to *the same syslogd* when it is > up > > > > > again. > > > > > > So no second syslogd involved in case 1, so this is no > failover > > > > > > scenario. > > > > > > > > > > > > HTH > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > about > > > to > > > > > set > > > > > > > up > > > > > > > reliability/failover. I've found two setup tutorials for > this: > > > > > > > > > > > > > > > > > > > > > 1. > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > 2. > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > using > > > > a > > > > > > > completely different syntax. Is it so that the former one > is the > > > > > > syntax > > > > > > > for > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > Regards, > > > > > > > Kenneth Holter > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From mic at npgx.com.au Thu Feb 5 03:01:58 2009 From: mic at npgx.com.au (Michael Mansour) Date: Thu, 5 Feb 2009 13:01:58 +1100 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <1233748683.19733.113.camel@rf10up.intern.adiscon.com> References: <20090203050119.M91067@npgx.com.au> <20090204002209.M97796@npgx.com.au> <1233748683.19733.113.camel@rf10up.intern.adiscon.com> Message-ID: <20090205015904.M19468@npgx.com.au> Hi Reiner, > On Wed, 2009-02-04 at 11:30 +1100, Michael Mansour wrote: > > > Change this: > > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > > > /var/log/messages > > > > > > To this: > > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice > > > /var/log/messages > > > > I think it should be > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.none /var/log/messages I've just popped that in. > > I've just tried that, restarted rsyslog and the messages for milter-regex keep > > appearing in /var/log/messages. > > > > I'm 100% these are daemon.info messages since I also use: > > > > mail.*;daemon.info -/var/log/maillog > > > > and the milter-regex messages that show up in /var/log/maillog are the same > > ones that show up in /var/log/messages. > > > > I'm pretty sure the reason that deamon.info is still going to > > /var/log/messages is because of the "*.info" entry at the beginning of that > > line, which catches daemon.info? > > Yes, because that says "everything with info severity, no matter what > the facility is, matches". > > > Is there a way I can stop daemon.info from showing up in /var/log/messages > > while keeping *.info on that same line? > > The .none in my example above is meant to exclude a specific facility > from the usual processing and this sounds like what you are looking for. > I barely remember that someone had problems with it. So if it does > not work, let me know. The part of the code that handles those old-style > selectors (old but still good!) is one of the few code sequences that > stem directly back to sysklogd and I can't outrule that something > went wrong during all that changes of the engine... > > Please let me know the outcome (saves me the lab). I think this is exactly what I'm looking for. So far I see no milter-regex messages in my /var/log/messages file while they are showing up in my /var/log/maillog file. Also, a restart of apache and crond still shows those messages going to /var/log/messages which is what I want. I'll keep monitoring over the next day or so but I think this is what I'm looking for. Thanks mate! Michael. > Rainer > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com ------- End of Original Message ------- From kenneho.ndu at gmail.com Thu Feb 5 09:58:13 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 09:58:13 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Message-ID: Are you referring to the "smart (over-)engineering" way of doing this? In other words, there are no built in support for failover/spooling/etc in rsyslog version 2? On 2/4/09, Rainer Gerhards wrote: > > Failover is available - that is done like you described in your last > post. But you need to keep an eye on the subtleties, outlined in the > response I've written just 2 minutes ago ;). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 2:03 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > It seems like RHN is way behind on adding rsyslog updates to the repo, > > so it > > seems like I'm more or less stuck with version 2 for now. Are there > any > > failover/spooling/etc functionality in version 2? I'd like to increase > > the > > chance of syslog messages reaching the syslog server, even if it gets > > offline for a short while. I'm sure it's possible to acheive this by > > smart > > (over-)engineering while waiting for rsyslog v3 being released on RHN, > > but > > I'm all for simplicity. :) > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > No prob. :) > > > > > > Then I'm even more puzzled...I've configured my rsyslog client with > > this > > > setup: > > > ** > > > > > > **.* @@client1.example.com:200 > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > & /var/log/localbuffer > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > If I cut the link to the syslog-server (using iptables to emulate > the > > > logserver being down), run "logger hello" on the client, and then > > after a > > > while attach the link (by flushing the iptable rules), I see that > the > > hello > > > message pops up on the rsyslog server. So some kind of spooling or > > something > > > seems to be active. Strange. Maybe the spooling or whatever is done > > on TCP > > > level or something. Maybe the rsyslog version from RHN differs from > > the > > > "normal" versioning? > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > Oops... and I just noticed you use v2. Spooling is not available > in > > v2. > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > You're right, it's not a failover solution by definition. I > see > > now > > > > > > that I > > > > > > should have outlined my needs... What I'm aiming at, at least > > for > > > > > now, > > > > > > is a > > > > > > semi-failover solution: If the syslog server (i.e. loghost) > > goes > > > > > down, > > > > > > the > > > > > > clients should simply spool the messages until the server gets > > back > > > > > > online. > > > > > > > > > > > > Back to the examples I linked to: They both seem to provide > the > > > > > > functionality I'm looking for. Is that correct? If so: what's > > the > > > > > > difference > > > > > > between them? > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > > but > > > > > rather send the messags to another (failover) server if the > > primary > > > > > fails. > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > first > > > > > link, > > > > > > > data is queued while the syslogd is not available. A > failover > > case > > > > > > > (described in link two) is that if one syslogd goes down, > > data is > > > > > > sent > > > > > > > to another. This is not done in case 1: there, messages are > > queued > > > > > > while > > > > > > > the syslogd is down and sent to *the same syslogd* when it > is > > up > > > > > > again. > > > > > > > So no second syslogd involved in case 1, so this is no > > failover > > > > > > > scenario. > > > > > > > > > > > > > > HTH > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > > about > > > > to > > > > > > set > > > > > > > > up > > > > > > > > reliability/failover. I've found two setup tutorials for > > this: > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > 2. > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > > using > > > > > a > > > > > > > > completely different syntax. Is it so that the former one > > is the > > > > > > > syntax > > > > > > > > for > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > Regards, > > > > > > > > Kenneth Holter > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 5 11:11:12 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 5 Feb 2009 11:11:12 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> As I said: the second link you posted is failover and it is a supported in v2. So failover *is* available in v2. Queuing is not. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Thursday, February 05, 2009 9:58 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Are you referring to the "smart (over-)engineering" way of doing this? > In > other words, there are no built in support for failover/spooling/etc in > rsyslog version 2? > > On 2/4/09, Rainer Gerhards wrote: > > > > Failover is available - that is done like you described in your last > > post. But you need to keep an eye on the subtleties, outlined in the > > response I've written just 2 minutes ago ;). > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > It seems like RHN is way behind on adding rsyslog updates to the > repo, > > > so it > > > seems like I'm more or less stuck with version 2 for now. Are there > > any > > > failover/spooling/etc functionality in version 2? I'd like to > increase > > > the > > > chance of syslog messages reaching the syslog server, even if it > gets > > > offline for a short while. I'm sure it's possible to acheive this > by > > > smart > > > (over-)engineering while waiting for rsyslog v3 being released on > RHN, > > > but > > > I'm all for simplicity. :) > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > No prob. :) > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog client > with > > > this > > > > setup: > > > > ** > > > > > > > > **.* @@client1.example.com:200 > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > & /var/log/localbuffer > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to emulate > > the > > > > logserver being down), run "logger hello" on the client, and then > > > after a > > > > while attach the link (by flushing the iptable rules), I see that > > the > > > hello > > > > message pops up on the rsyslog server. So some kind of spooling > or > > > something > > > > seems to be active. Strange. Maybe the spooling or whatever is > done > > > on TCP > > > > level or something. Maybe the rsyslog version from RHN differs > from > > > the > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > Oops... and I just noticed you use v2. Spooling is not > available > > in > > > v2. > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > You're right, it's not a failover solution by definition. I > > see > > > now > > > > > > > that I > > > > > > > should have outlined my needs... What I'm aiming at, at > least > > > for > > > > > > now, > > > > > > > is a > > > > > > > semi-failover solution: If the syslog server (i.e. loghost) > > > goes > > > > > > down, > > > > > > > the > > > > > > > clients should simply spool the messages until the server > gets > > > back > > > > > > > online. > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to provide > > the > > > > > > > functionality I'm looking for. Is that correct? If so: > what's > > > the > > > > > > > difference > > > > > > > between them? > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not > spool > > > but > > > > > > rather send the messags to another (failover) server if the > > > primary > > > > > > fails. > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > wrote: > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > > first > > > > > > link, > > > > > > > > data is queued while the syslogd is not available. A > > failover > > > case > > > > > > > > (described in link two) is that if one syslogd goes down, > > > data is > > > > > > > sent > > > > > > > > to another. This is not done in case 1: there, messages > are > > > queued > > > > > > > while > > > > > > > > the syslogd is down and sent to *the same syslogd* when > it > > is > > > up > > > > > > > again. > > > > > > > > So no second syslogd involved in case 1, so this is no > > > failover > > > > > > > > scenario. > > > > > > > > > > > > > > > > HTH > > > > > > > > Rainer > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and > are > > > about > > > > > to > > > > > > > set > > > > > > > > > up > > > > > > > > > reliability/failover. I've found two setup tutorials > for > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > 2. > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, > but > > > using > > > > > > a > > > > > > > > > completely different syntax. Is it so that the former > one > > > is the > > > > > > > > syntax > > > > > > > > > for > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Kenneth Holter > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Thu Feb 5 11:31:39 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 11:31:39 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> Message-ID: Sorry, my fault. You said this: "Failover is available - that is done like you described in your last post.", and my post you referred to talked about the engineering stuff. Anyway, the second link I posted describes the failover functionality, but not any specifics how the local buffer is used. Back to my configuration which I posted earlier in the thread: **.* @@server1**.example.com:200* * $ActionExecOnlyWhenPreviousIsSuspended on & /var/log/localbuffer $ActionExecOnlyWhenPreviousIsSuspended off* It is my understanding that messages that doesn't reach the server1 machine will be store in the /var/log/localbuffer file. Can you point me to documentation that explains that happens next with these messages? On 2/5/09, Rainer Gerhards wrote: > As I said: the second link you posted is failover and it is a supported > in v2. So failover *is* available in v2. Queuing is not. > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Thursday, February 05, 2009 9:58 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > Are you referring to the "smart (over-)engineering" way of doing this? > > In > > other words, there are no built in support for failover/spooling/etc > in > > rsyslog version 2? > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > Failover is available - that is done like you described in your last > > > post. But you need to keep an eye on the subtleties, outlined in the > > > response I've written just 2 minutes ago ;). > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > It seems like RHN is way behind on adding rsyslog updates to the > > repo, > > > > so it > > > > seems like I'm more or less stuck with version 2 for now. Are > there > > > any > > > > failover/spooling/etc functionality in version 2? I'd like to > > increase > > > > the > > > > chance of syslog messages reaching the syslog server, even if it > > gets > > > > offline for a short while. I'm sure it's possible to acheive this > > by > > > > smart > > > > (over-)engineering while waiting for rsyslog v3 being released on > > RHN, > > > > but > > > > I'm all for simplicity. :) > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > No prob. :) > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog client > > with > > > > this > > > > > setup: > > > > > ** > > > > > > > > > > **.* @@client1.example.com:200 > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > & /var/log/localbuffer > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > emulate > > > the > > > > > logserver being down), run "logger hello" on the client, and > then > > > > after a > > > > > while attach the link (by flushing the iptable rules), I see > that > > > the > > > > hello > > > > > message pops up on the rsyslog server. So some kind of spooling > > or > > > > something > > > > > seems to be active. Strange. Maybe the spooling or whatever is > > done > > > > on TCP > > > > > level or something. Maybe the rsyslog version from RHN differs > > from > > > > the > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > Oops... and I just noticed you use v2. Spooling is not > > available > > > in > > > > v2. > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > You're right, it's not a failover solution by definition. > I > > > see > > > > now > > > > > > > > that I > > > > > > > > should have outlined my needs... What I'm aiming at, at > > least > > > > for > > > > > > > now, > > > > > > > > is a > > > > > > > > semi-failover solution: If the syslog server (i.e. > loghost) > > > > goes > > > > > > > down, > > > > > > > > the > > > > > > > > clients should simply spool the messages until the server > > gets > > > > back > > > > > > > > online. > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > provide > > > the > > > > > > > > functionality I'm looking for. Is that correct? If so: > > what's > > > > the > > > > > > > > difference > > > > > > > > between them? > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not > > spool > > > > but > > > > > > > rather send the messags to another (failover) server if the > > > > primary > > > > > > > fails. > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > wrote: > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > > > first > > > > > > > link, > > > > > > > > > data is queued while the syslogd is not available. A > > > failover > > > > case > > > > > > > > > (described in link two) is that if one syslogd goes > down, > > > > data is > > > > > > > > sent > > > > > > > > > to another. This is not done in case 1: there, messages > > are > > > > queued > > > > > > > > while > > > > > > > > > the syslogd is down and sent to *the same syslogd* when > > it > > > is > > > > up > > > > > > > > again. > > > > > > > > > So no second syslogd involved in case 1, so this is no > > > > failover > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > [mailto:rsyslog- > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and > > are > > > > about > > > > > > to > > > > > > > > set > > > > > > > > > > up > > > > > > > > > > reliability/failover. I've found two setup tutorials > > for > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > 2. > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, > > but > > > > using > > > > > > > a > > > > > > > > > > completely different syntax. Is it so that the former > > one > > > > is the > > > > > > > > > syntax > > > > > > > > > > for > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Kenneth Holter > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 5 12:04:28 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 5 Feb 2009 12:04:28 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> I am sorry, but this is going beyond what I can do for free. I'd consider purchasing commercial services. The reason is you try to get things real reliable, but you have lots of constraints and fine subtle issues. There need to be made tradoffs and some tough decisions. All in all, that's a real consulting project. Everything you need to know is fully documented, either in rsyslog, it's code, my blog and even RFCs. I have pointed you to these things. I fully understand that it is not easy to get the big picture from that. It is far from being that, you need to be an expert in syslog to know exactly how to put together those things. Syslog is boring to most (no bashing), so we have few experts on the matter. So if you need to do things in a quite reliable way, it would probably a good idea to task an expert with consulting. I am sorry if that post is rather blunt, but I think it is better we all know where we are. Honestly, I put up a lot of unpaid time into making the project grow. I am also able to give a lot of free support. I am grateful Adiscon pays for this. But please understand that we not also can give away consulting for free - something needs to pay the power, machines - and my lunch! - at the end of the day ;) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Thursday, February 05, 2009 11:32 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Sorry, my fault. You said this: "Failover is available - that is done > like > you described in your last > post.", and my post you referred to talked about the engineering stuff. > > Anyway, the second link I posted describes the failover functionality, > but > not any specifics how the local buffer is used. Back to my > configuration > which I posted earlier in the thread: > > > **.* @@server1**.example.com:200* * > $ActionExecOnlyWhenPreviousIsSuspended on > & /var/log/localbuffer > $ActionExecOnlyWhenPreviousIsSuspended off* > > > It is my understanding that messages that doesn't reach the server1 > machine > will be store in the /var/log/localbuffer file. Can you point me to > documentation that explains that happens next with these messages? > > > > > On 2/5/09, Rainer Gerhards wrote: > > > As I said: the second link you posted is failover and it is a > supported > > in v2. So failover *is* available in v2. Queuing is not. > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Thursday, February 05, 2009 9:58 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > Are you referring to the "smart (over-)engineering" way of doing > this? > > > In > > > other words, there are no built in support for > failover/spooling/etc > > in > > > rsyslog version 2? > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > Failover is available - that is done like you described in your > last > > > > post. But you need to keep an eye on the subtleties, outlined in > the > > > > response I've written just 2 minutes ago ;). > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > It seems like RHN is way behind on adding rsyslog updates to > the > > > repo, > > > > > so it > > > > > seems like I'm more or less stuck with version 2 for now. Are > > there > > > > any > > > > > failover/spooling/etc functionality in version 2? I'd like to > > > increase > > > > > the > > > > > chance of syslog messages reaching the syslog server, even if > it > > > gets > > > > > offline for a short while. I'm sure it's possible to acheive > this > > > by > > > > > smart > > > > > (over-)engineering while waiting for rsyslog v3 being released > on > > > RHN, > > > > > but > > > > > I'm all for simplicity. :) > > > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > > > No prob. :) > > > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog > client > > > with > > > > > this > > > > > > setup: > > > > > > ** > > > > > > > > > > > > **.* @@client1.example.com:200 > > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > > & /var/log/localbuffer > > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > > emulate > > > > the > > > > > > logserver being down), run "logger hello" on the client, and > > then > > > > > after a > > > > > > while attach the link (by flushing the iptable rules), I see > > that > > > > the > > > > > hello > > > > > > message pops up on the rsyslog server. So some kind of > spooling > > > or > > > > > something > > > > > > seems to be active. Strange. Maybe the spooling or whatever > is > > > done > > > > > on TCP > > > > > > level or something. Maybe the rsyslog version from RHN > differs > > > from > > > > > the > > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > Oops... and I just noticed you use v2. Spooling is not > > > available > > > > in > > > > > v2. > > > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > > To: rsyslog-users > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > > > You're right, it's not a failover solution by > definition. > > I > > > > see > > > > > now > > > > > > > > > that I > > > > > > > > > should have outlined my needs... What I'm aiming at, at > > > least > > > > > for > > > > > > > > now, > > > > > > > > > is a > > > > > > > > > semi-failover solution: If the syslog server (i.e. > > loghost) > > > > > goes > > > > > > > > down, > > > > > > > > > the > > > > > > > > > clients should simply spool the messages until the > server > > > gets > > > > > back > > > > > > > > > online. > > > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > > provide > > > > the > > > > > > > > > functionality I'm looking for. Is that correct? If so: > > > what's > > > > > the > > > > > > > > > difference > > > > > > > > > between them? > > > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not > > > spool > > > > > but > > > > > > > > rather send the messags to another (failover) server if > the > > > > > primary > > > > > > > > fails. > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In > the > > > > > first > > > > > > > > link, > > > > > > > > > > data is queued while the syslogd is not available. A > > > > failover > > > > > case > > > > > > > > > > (described in link two) is that if one syslogd goes > > down, > > > > > data is > > > > > > > > > sent > > > > > > > > > > to another. This is not done in case 1: there, > messages > > > are > > > > > queued > > > > > > > > > while > > > > > > > > > > the syslogd is down and sent to *the same syslogd* > when > > > it > > > > is > > > > > up > > > > > > > > > again. > > > > > > > > > > So no second syslogd involved in case 1, so this is > no > > > > > failover > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > [mailto:rsyslog- > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > Holter > > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, > and > > > are > > > > > about > > > > > > > to > > > > > > > > > set > > > > > > > > > > > up > > > > > > > > > > > reliability/failover. I've found two setup > tutorials > > > for > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > > 2. > > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable > transfer, > > > but > > > > > using > > > > > > > > a > > > > > > > > > > > completely different syntax. Is it so that the > former > > > one > > > > > is the > > > > > > > > > > syntax > > > > > > > > > > > for > > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > Kenneth Holter > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Thu Feb 5 12:52:37 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 12:52:37 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> Message-ID: I understand completely. :) I'll sure I will find the documentation I need, even though I'm using an aceint version of rsyslog. :) Thanks for the help so far, anyway. On 2/5/09, Rainer Gerhards wrote: > > I am sorry, but this is going beyond what I can do for free. I'd > consider purchasing commercial services. The reason is you try to get > things real reliable, but you have lots of constraints and fine subtle > issues. There need to be made tradoffs and some tough decisions. All in > all, that's a real consulting project. > > Everything you need to know is fully documented, either in rsyslog, it's > code, my blog and even RFCs. I have pointed you to these things. I fully > understand that it is not easy to get the big picture from that. It is > far from being that, you need to be an expert in syslog to know exactly > how to put together those things. Syslog is boring to most (no bashing), > so we have few experts on the matter. So if you need to do things in a > quite reliable way, it would probably a good idea to task an expert with > consulting. > > I am sorry if that post is rather blunt, but I think it is better we all > know where we are. Honestly, I put up a lot of unpaid time into making > the project grow. I am also able to give a lot of free support. I am > grateful Adiscon pays for this. But please understand that we not also > can give away consulting for free - something needs to pay the power, > machines - and my lunch! - at the end of the day ;) > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Thursday, February 05, 2009 11:32 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > Sorry, my fault. You said this: "Failover is available - that is done > > like > > you described in your last > > post.", and my post you referred to talked about the engineering > stuff. > > > > Anyway, the second link I posted describes the failover functionality, > > but > > not any specifics how the local buffer is used. Back to my > > configuration > > which I posted earlier in the thread: > > > > > > **.* @@server1**.example.com:200* * > > $ActionExecOnlyWhenPreviousIsSuspended on > > & /var/log/localbuffer > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > It is my understanding that messages that doesn't reach the server1 > > machine > > will be store in the /var/log/localbuffer file. Can you point me to > > documentation that explains that happens next with these messages? > > > > > > > > > > On 2/5/09, Rainer Gerhards wrote: > > > > > As I said: the second link you posted is failover and it is a > > supported > > > in v2. So failover *is* available in v2. Queuing is not. > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Thursday, February 05, 2009 9:58 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > Are you referring to the "smart (over-)engineering" way of doing > > this? > > > > In > > > > other words, there are no built in support for > > failover/spooling/etc > > > in > > > > rsyslog version 2? > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > Failover is available - that is done like you described in your > > last > > > > > post. But you need to keep an eye on the subtleties, outlined in > > the > > > > > response I've written just 2 minutes ago ;). > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > It seems like RHN is way behind on adding rsyslog updates to > > the > > > > repo, > > > > > > so it > > > > > > seems like I'm more or less stuck with version 2 for now. Are > > > there > > > > > any > > > > > > failover/spooling/etc functionality in version 2? I'd like to > > > > increase > > > > > > the > > > > > > chance of syslog messages reaching the syslog server, even if > > it > > > > gets > > > > > > offline for a short while. I'm sure it's possible to acheive > > this > > > > by > > > > > > smart > > > > > > (over-)engineering while waiting for rsyslog v3 being released > > on > > > > RHN, > > > > > > but > > > > > > I'm all for simplicity. :) > > > > > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > > > > > No prob. :) > > > > > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog > > client > > > > with > > > > > > this > > > > > > > setup: > > > > > > > ** > > > > > > > > > > > > > > **.* @@client1.example.com:200 > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > > > & /var/log/localbuffer > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > > > emulate > > > > > the > > > > > > > logserver being down), run "logger hello" on the client, and > > > then > > > > > > after a > > > > > > > while attach the link (by flushing the iptable rules), I see > > > that > > > > > the > > > > > > hello > > > > > > > message pops up on the rsyslog server. So some kind of > > spooling > > > > or > > > > > > something > > > > > > > seems to be active. Strange. Maybe the spooling or whatever > > is > > > > done > > > > > > on TCP > > > > > > > level or something. Maybe the rsyslog version from RHN > > differs > > > > from > > > > > > the > > > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > Oops... and I just noticed you use v2. Spooling is not > > > > available > > > > > in > > > > > > v2. > > > > > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > > > To: rsyslog-users > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > [mailto:rsyslog- > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > > > To: rsyslog-users > > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > > > > > You're right, it's not a failover solution by > > definition. > > > I > > > > > see > > > > > > now > > > > > > > > > > that I > > > > > > > > > > should have outlined my needs... What I'm aiming at, > at > > > > least > > > > > > for > > > > > > > > > now, > > > > > > > > > > is a > > > > > > > > > > semi-failover solution: If the syslog server (i.e. > > > loghost) > > > > > > goes > > > > > > > > > down, > > > > > > > > > > the > > > > > > > > > > clients should simply spool the messages until the > > server > > > > gets > > > > > > back > > > > > > > > > > online. > > > > > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > > > provide > > > > > the > > > > > > > > > > functionality I'm looking for. Is that correct? If so: > > > > what's > > > > > > the > > > > > > > > > > difference > > > > > > > > > > between them? > > > > > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does > not > > > > spool > > > > > > but > > > > > > > > > rather send the messags to another (failover) server if > > the > > > > > > primary > > > > > > > > > fails. > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In > > the > > > > > > first > > > > > > > > > link, > > > > > > > > > > > data is queued while the syslogd is not available. A > > > > > failover > > > > > > case > > > > > > > > > > > (described in link two) is that if one syslogd goes > > > down, > > > > > > data is > > > > > > > > > > sent > > > > > > > > > > > to another. This is not done in case 1: there, > > messages > > > > are > > > > > > queued > > > > > > > > > > while > > > > > > > > > > > the syslogd is down and sent to *the same syslogd* > > when > > > > it > > > > > is > > > > > > up > > > > > > > > > > again. > > > > > > > > > > > So no second syslogd involved in case 1, so this is > > no > > > > > > failover > > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > > [mailto:rsyslog- > > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > > Holter > > > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, > > and > > > > are > > > > > > about > > > > > > > > to > > > > > > > > > > set > > > > > > > > > > > > up > > > > > > > > > > > > reliability/failover. I've found two setup > > tutorials > > > > for > > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > > > 2. > > > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable > > transfer, > > > > but > > > > > > using > > > > > > > > > a > > > > > > > > > > > > completely different syntax. Is it so that the > > former > > > > one > > > > > > is the > > > > > > > > > > > syntax > > > > > > > > > > > > for > > > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Kenneth Holter > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 5 13:06:58 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 5 Feb 2009 13:06:58 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB4D@grfint2.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Thursday, February 05, 2009 12:53 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > I understand completely. :) > > I'll sure I will find the documentation I need, even though I'm using > an > aceint version of rsyslog. :) > Keep in mind that each version comes with a complete doc set. Even if that is missing in the package you have, you can download the same version from www.rsyslog.com and look at the included doc. Rainer > > Thanks for the help so far, anyway. > > > On 2/5/09, Rainer Gerhards wrote: > > > > I am sorry, but this is going beyond what I can do for free. I'd > > consider purchasing commercial services. The reason is you try to get > > things real reliable, but you have lots of constraints and fine > subtle > > issues. There need to be made tradoffs and some tough decisions. All > in > > all, that's a real consulting project. > > > > Everything you need to know is fully documented, either in rsyslog, > it's > > code, my blog and even RFCs. I have pointed you to these things. I > fully > > understand that it is not easy to get the big picture from that. It > is > > far from being that, you need to be an expert in syslog to know > exactly > > how to put together those things. Syslog is boring to most (no > bashing), > > so we have few experts on the matter. So if you need to do things in > a > > quite reliable way, it would probably a good idea to task an expert > with > > consulting. > > > > I am sorry if that post is rather blunt, but I think it is better we > all > > know where we are. Honestly, I put up a lot of unpaid time into > making > > the project grow. I am also able to give a lot of free support. I am > > grateful Adiscon pays for this. But please understand that we not > also > > can give away consulting for free - something needs to pay the power, > > machines - and my lunch! - at the end of the day ;) > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Thursday, February 05, 2009 11:32 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > Sorry, my fault. You said this: "Failover is available - that is > done > > > like > > > you described in your last > > > post.", and my post you referred to talked about the engineering > > stuff. > > > > > > Anyway, the second link I posted describes the failover > functionality, > > > but > > > not any specifics how the local buffer is used. Back to my > > > configuration > > > which I posted earlier in the thread: > > > > > > > > > **.* @@server1**.example.com:200* > * > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > & /var/log/localbuffer > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > It is my understanding that messages that doesn't reach the server1 > > > machine > > > will be store in the /var/log/localbuffer file. Can you point me to > > > documentation that explains that happens next with these messages? > > > > > > > > > > > > > > > On 2/5/09, Rainer Gerhards wrote: > > > > > > > As I said: the second link you posted is failover and it is a > > > supported > > > > in v2. So failover *is* available in v2. Queuing is not. > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Thursday, February 05, 2009 9:58 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Are you referring to the "smart (over-)engineering" way of > doing > > > this? > > > > > In > > > > > other words, there are no built in support for > > > failover/spooling/etc > > > > in > > > > > rsyslog version 2? > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > Failover is available - that is done like you described in > your > > > last > > > > > > post. But you need to keep an eye on the subtleties, outlined > in > > > the > > > > > > response I've written just 2 minutes ago ;). > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > It seems like RHN is way behind on adding rsyslog updates > to > > > the > > > > > repo, > > > > > > > so it > > > > > > > seems like I'm more or less stuck with version 2 for now. > Are > > > > there > > > > > > any > > > > > > > failover/spooling/etc functionality in version 2? I'd like > to > > > > > increase > > > > > > > the > > > > > > > chance of syslog messages reaching the syslog server, even > if > > > it > > > > > gets > > > > > > > offline for a short while. I'm sure it's possible to > acheive > > > this > > > > > by > > > > > > > smart > > > > > > > (over-)engineering while waiting for rsyslog v3 being > released > > > on > > > > > RHN, > > > > > > > but > > > > > > > I'm all for simplicity. :) > > > > > > > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > > > > > > > No prob. :) > > > > > > > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog > > > client > > > > > with > > > > > > > this > > > > > > > > setup: > > > > > > > > ** > > > > > > > > > > > > > > > > **.* @@client1.example.com:200 > > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > > > > & /var/log/localbuffer > > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > > > > emulate > > > > > > the > > > > > > > > logserver being down), run "logger hello" on the client, > and > > > > then > > > > > > > after a > > > > > > > > while attach the link (by flushing the iptable rules), I > see > > > > that > > > > > > the > > > > > > > hello > > > > > > > > message pops up on the rsyslog server. So some kind of > > > spooling > > > > > or > > > > > > > something > > > > > > > > seems to be active. Strange. Maybe the spooling or > whatever > > > is > > > > > done > > > > > > > on TCP > > > > > > > > level or something. Maybe the rsyslog version from RHN > > > differs > > > > > from > > > > > > > the > > > > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > wrote: > > > > > > > > > Oops... and I just noticed you use v2. Spooling is not > > > > > available > > > > > > in > > > > > > > v2. > > > > > > > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer > Gerhards > > > > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > > > > To: rsyslog-users > > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > [mailto:rsyslog- > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > Holter > > > > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > > > > To: rsyslog-users > > > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > > > > > > > You're right, it's not a failover solution by > > > definition. > > > > I > > > > > > see > > > > > > > now > > > > > > > > > > > that I > > > > > > > > > > > should have outlined my needs... What I'm aiming > at, > > at > > > > > least > > > > > > > for > > > > > > > > > > now, > > > > > > > > > > > is a > > > > > > > > > > > semi-failover solution: If the syslog server (i.e. > > > > loghost) > > > > > > > goes > > > > > > > > > > down, > > > > > > > > > > > the > > > > > > > > > > > clients should simply spool the messages until the > > > server > > > > > gets > > > > > > > back > > > > > > > > > > > online. > > > > > > > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > > > > provide > > > > > > the > > > > > > > > > > > functionality I'm looking for. Is that correct? If > so: > > > > > what's > > > > > > > the > > > > > > > > > > > difference > > > > > > > > > > > between them? > > > > > > > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does > > not > > > > > spool > > > > > > > but > > > > > > > > > > rather send the messags to another (failover) server > if > > > the > > > > > > > primary > > > > > > > > > > fails. > > > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. > In > > > the > > > > > > > first > > > > > > > > > > link, > > > > > > > > > > > > data is queued while the syslogd is not > available. A > > > > > > failover > > > > > > > case > > > > > > > > > > > > (described in link two) is that if one syslogd > goes > > > > down, > > > > > > > data is > > > > > > > > > > > sent > > > > > > > > > > > > to another. This is not done in case 1: there, > > > messages > > > > > are > > > > > > > queued > > > > > > > > > > > while > > > > > > > > > > > > the syslogd is down and sent to *the same > syslogd* > > > when > > > > > it > > > > > > is > > > > > > > up > > > > > > > > > > > again. > > > > > > > > > > > > So no second syslogd involved in case 1, so this > is > > > no > > > > > > > failover > > > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > > > [mailto:rsyslog- > > > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > > > Holter > > > > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from > RHN, > > > and > > > > > are > > > > > > > about > > > > > > > > > to > > > > > > > > > > > set > > > > > > > > > > > > > up > > > > > > > > > > > > > reliability/failover. I've found two setup > > > tutorials > > > > > for > > > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > > > > 2. > > > > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable > > > transfer, > > > > > but > > > > > > > using > > > > > > > > > > a > > > > > > > > > > > > > completely different syntax. Is it so that the > > > former > > > > > one > > > > > > > is the > > > > > > > > > > > > syntax > > > > > > > > > > > > > for > > > > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > Kenneth Holter > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Thu Feb 5 13:38:14 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 13:38:14 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> Message-ID: Thanks, I'll consider this approach. On 2/4/09, Daniel Anson wrote: > > I personally run RHEL 5 servers with rsyslog. Due to the lack of a > current and stable rsyslog rpm, I always build rsyslog on the server. > It takes less than 5 minutes and is very stable. > > Daniel Anson > Rackspace Managed Hosting > danson at rackspace.com > > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Wednesday, February 04, 2009 7:14 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Failover is available - that is done like you described in your last > post. But you need to keep an eye on the subtleties, outlined in the > response I've written just 2 minutes ago ;). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 2:03 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > It seems like RHN is way behind on adding rsyslog updates to the repo, > > so it > > seems like I'm more or less stuck with version 2 for now. Are there > any > > failover/spooling/etc functionality in version 2? I'd like to increase > > the > > chance of syslog messages reaching the syslog server, even if it gets > > offline for a short while. I'm sure it's possible to acheive this by > > smart > > (over-)engineering while waiting for rsyslog v3 being released on RHN, > > but > > I'm all for simplicity. :) > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > No prob. :) > > > > > > Then I'm even more puzzled...I've configured my rsyslog client with > > this > > > setup: > > > ** > > > > > > **.* @@client1.example.com:200 > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > & /var/log/localbuffer > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > If I cut the link to the syslog-server (using iptables to emulate > the > > > logserver being down), run "logger hello" on the client, and then > > after a > > > while attach the link (by flushing the iptable rules), I see that > the > > hello > > > message pops up on the rsyslog server. So some kind of spooling or > > something > > > seems to be active. Strange. Maybe the spooling or whatever is done > > on TCP > > > level or something. Maybe the rsyslog version from RHN differs from > > the > > > "normal" versioning? > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > Oops... and I just noticed you use v2. Spooling is not available > in > > v2. > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > You're right, it's not a failover solution by definition. I > see > > now > > > > > > that I > > > > > > should have outlined my needs... What I'm aiming at, at least > > for > > > > > now, > > > > > > is a > > > > > > semi-failover solution: If the syslog server (i.e. loghost) > > goes > > > > > down, > > > > > > the > > > > > > clients should simply spool the messages until the server gets > > back > > > > > > online. > > > > > > > > > > > > Back to the examples I linked to: They both seem to provide > the > > > > > > functionality I'm looking for. Is that correct? If so: what's > > the > > > > > > difference > > > > > > between them? > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > > but > > > > > rather send the messags to another (failover) server if the > > primary > > > > > fails. > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > first > > > > > link, > > > > > > > data is queued while the syslogd is not available. A > failover > > case > > > > > > > (described in link two) is that if one syslogd goes down, > > data is > > > > > > sent > > > > > > > to another. This is not done in case 1: there, messages are > > queued > > > > > > while > > > > > > > the syslogd is down and sent to *the same syslogd* when it > is > > up > > > > > > again. > > > > > > > So no second syslogd involved in case 1, so this is no > > failover > > > > > > > scenario. > > > > > > > > > > > > > > HTH > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > > about > > > > to > > > > > > set > > > > > > > > up > > > > > > > > reliability/failover. I've found two setup tutorials for > > this: > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > 2. > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > > using > > > > > a > > > > > > > > completely different syntax. Is it so that the former one > > is the > > > > > > > syntax > > > > > > > > for > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > Regards, > > > > > > > > Kenneth Holter > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of > the > individual or entity to which this message is addressed, and unless > otherwise > expressly indicated, is confidential and privileged information of > Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at abuse at rackspace.com, and delete the original message. > Your cooperation is appreciated. > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Thu Feb 5 16:52:03 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Thu, 5 Feb 2009 15:52:03 +0000 Subject: [rsyslog] logger problem Message-ID: <69544300902050752h5f78e701m4eebc0024d4826b6@mail.gmail.com> hi guys, I have successfully use logger to send messages to syslog. however this works well locally. now i need to send a message to a remote syslog server. i can't see how to do it with logger. let assume that i am sending from IP1 to IP2 how do i go about it. thanks From danson at rackspace.com Thu Feb 5 17:03:19 2009 From: danson at rackspace.com (Daniel Anson) Date: Thu, 5 Feb 2009 10:03:19 -0600 Subject: [rsyslog] logger problem In-Reply-To: <69544300902050752h5f78e701m4eebc0024d4826b6@mail.gmail.com> References: <69544300902050752h5f78e701m4eebc0024d4826b6@mail.gmail.com> Message-ID: <5942_1233849923_n15G5KPn012483_96AF20FDF4301D419B33CCE8E3A0132B0B133AB7@SAT4MX07.RACKSPACE.CORP> Use IP1 as a relay. Put something like this is syslog.conf and restart (HUP) it: *.* @IP2 This will log locally using logger but will relay the log to IP2 as well. I just used *.* but you can specify facility/severity of logs there. --Daniel ANson -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Jules Pagna Disso Sent: Thursday, February 05, 2009 9:52 AM To: rsyslog-users Subject: [rsyslog] logger problem hi guys, I have successfully use logger to send messages to syslog. however this works well locally. now i need to send a message to a remote syslog server. i can't see how to do it with logger. let assume that i am sending from IP1 to IP2 how do i go about it. thanks _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From hks.private at gmail.com Thu Feb 5 17:53:08 2009 From: hks.private at gmail.com ((private) HKS) Date: Thu, 5 Feb 2009 11:53:08 -0500 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <1233748683.19733.113.camel@rf10up.intern.adiscon.com> References: <20090203050119.M91067@npgx.com.au> <20090204002209.M97796@npgx.com.au> <1233748683.19733.113.camel@rf10up.intern.adiscon.com> Message-ID: On Wed, Feb 4, 2009 at 6:58 AM, Rainer Gerhards wrote: > On Wed, 2009-02-04 at 11:30 +1100, Michael Mansour wrote: >> > Change this: >> > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none >> > /var/log/messages >> > >> > To this: >> > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice >> > /var/log/messages >> > > I think it should be > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.none /var/log/messages > Erp...yes, that's correct. My config would have had all notice+ severity daemon messages going to /var/log/messages (though it should have ignored daemon.debug and daemon.info, right?). Thanks for the correction. -HKS From aoz.syn at gmail.com Fri Feb 6 00:55:06 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 5 Feb 2009 16:55:06 -0700 Subject: [rsyslog] sticky templates Message-ID: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> I'm more feeling things out than requesting a feature, but is there a way to control when templates are evaluated? Say I'd like to name some files with very specific timestamps, but instead of re-evaluating the template every time it receives an event, just re-evaluate whenever rsyslogd has cause to reopen the file. Am I sane? RB From mic at npgx.com.au Fri Feb 6 01:12:25 2009 From: mic at npgx.com.au (Michael Mansour) Date: Fri, 6 Feb 2009 11:12:25 +1100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> Message-ID: <20090206000942.M2544@npgx.com.au> Hi Daniel, > Thanks, I'll consider this approach. > > On 2/4/09, Daniel Anson wrote: > > > > I personally run RHEL 5 servers with rsyslog. Due to the lack of a > > current and stable rsyslog rpm, I always build rsyslog on the server. > > It takes less than 5 minutes and is very stable. Have you tried building an RPM of rsyslog yourself? I put the method on how I did it in the rsyslog wiki, and I have 3.x built in RPM and running on various SL 4 servers (RHEL 4 derivatives). I haven't tried SL 5 with rsyslog yet, but you should be able to use my spec to build it. If you get it running, we can make it available to the community. Regards, Michael. > > Daniel Anson > > Rackspace Managed Hosting > > danson at rackspace.com From david at lang.hm Fri Feb 6 03:59:02 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 5 Feb 2009 18:59:02 -0800 (PST) Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> Message-ID: On Thu, 5 Feb 2009, RB wrote: > I'm more feeling things out than requesting a feature, but is there a > way to control when templates are evaluated? Say I'd like to name > some files with very specific timestamps, but instead of re-evaluating > the template every time it receives an event, just re-evaluate > whenever rsyslogd has cause to reopen the file. Am I sane? I could see the use for this sort of thing. David Lang From aoz.syn at gmail.com Fri Feb 6 03:03:51 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 5 Feb 2009 19:03:51 -0700 Subject: [rsyslog] sticky templates In-Reply-To: References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> Message-ID: <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> On Thu, Feb 5, 2009 at 19:59, wrote: >> I'm more feeling things out than requesting a feature, but is there a >> way to control when templates are evaluated? Say I'd like to name >> some files with very specific timestamps, but instead of re-evaluating >> the template every time it receives an event, just re-evaluate >> whenever rsyslogd has cause to reopen the file. Am I sane? > > I could see the use for this sort of thing. The first use-case I had come up with was with an output channel - I know they're scheduled to disappear, but it'd be quite nice to set a size limit for the channel and see the over-limit "resolved" by closing and re-opening. From rgerhards at hq.adiscon.com Fri Feb 6 12:01:12 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 12:01:12 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> Message-ID: <1233918072.19733.160.camel@rf10up.intern.adiscon.com> On Thu, 2009-02-05 at 19:03 -0700, RB wrote: > On Thu, Feb 5, 2009 at 19:59, wrote: > >> I'm more feeling things out than requesting a feature, but is there a > >> way to control when templates are evaluated? Say I'd like to name > >> some files with very specific timestamps, but instead of re-evaluating > >> the template every time it receives an event, just re-evaluate > >> whenever rsyslogd has cause to reopen the file. Am I sane? > > > > I could see the use for this sort of thing. > > The first use-case I had come up with was with an output channel - I > know they're scheduled to disappear, but it'd be quite nice to set a > size limit for the channel and see the over-limit "resolved" by > closing and re-opening. Actually, I think this is the only use case. What we need to look at is when a file is closed. It is closed when there is need to. So, when is there need? There are currently three cases where need arises a) HUP or restart b) output channel max size logic c) change in filename (for dynafiles, only) I think we can ignore a) in this context. I agree that it may be useful in case b). For the time being let's focus on case c): I simplified a bit. Actually, the file is not closed immediately when the file name changes. The file is kept open, in a kind of cache. So when the very same file name is used again, the file descriptor is taken from the cache and there is no need to call open and close APIs (very time consuming). The usual case is that something like HOSTNAME or TAG is used in dynamic filename generation. In these cases, it is quite common that a small set of different filenames is written to. So with the cache logic, we can ensure that we have good performance no matter in what order messages come in (generally, they appear random and thus there is a large probability that the next message will go to a different file on a sufficiently busy system). A file is actually closed only if the cache runs out of space (or cases a) or b) above happen). Now let's think what happens if the dynamic name would not be evaluated. Let's stick with the hostname. We have the following message sequence: Host Msg A M1 A M2 B Ma A M3 B Mb and we have a filename template, for simplicity, that consists of only % HOSTNAME%. What now happens is that with the first message the file "A" is opened. Obviously, messages M1 and M2 are written to file "A". Now, Ma comes in from host B. If the name is newly evaluated, Ma is written to file B. Then, M3 again to file A and Mb to file B. If we do not evaluate the filename template, we have no need to switch files. Consequently, all messages (M1, ..., Mb) are written to file "B". That, however, we could achive without dynafiles at all, for example by doing a simple *.* /A The same happens when you use time-based properties: if you do not reevaluate the file name, you will never switch files, because the name stays always at the (somewhat random) initial value. So IMO this can not be a valid use-case. What you describe in your post (initial case b)) I would call a side-effect. As the file was closed due to size limitation, as a side-effect a new name could be generated. That is of interest because the name conveys the information how long it took to reach the file size. I think a solution to this need could be to emit a log message, telling which file was closed at what time (if an output channel reaches max size). Does this make sense? Or did I misunderstand your intentions? If I got it right, would the proposed new message on max file size (output channel) solve your need? I think that should be fairly easy to add. Looking forward to your replies. Rainer From aoz.syn at gmail.com Fri Feb 6 14:15:56 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 6 Feb 2009 06:15:56 -0700 Subject: [rsyslog] sticky templates In-Reply-To: <1233918072.19733.160.camel@rf10up.intern.adiscon.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> Message-ID: <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> On Fri, Feb 6, 2009 at 04:01, Rainer Gerhards wrote: > The same happens when you use time-based properties: if you do not > reevaluate the file name, you will never switch files, because the name > stays always at the (somewhat random) initial value. > > So IMO this can not be a valid use-case. Put that way, I agree to a point. However, it (case c) can still be of limited utility for environments using 3rd-party post-processing (like logrotate or FS utilization monitors). In those cases, it would be more useful to HUP the writing process prior to beginning and work on essentially cold files rather than the 'smear' you get when working with live files. The concept could definitely be abused as you showed with the host example. > What you describe in your post > (initial case b)) I would call a side-effect. As the file was closed due > to size limitation, as a side-effect a new name could be generated. That > is of interest because the name conveys the information how long it took > to reach the file size. I think a solution to this need could be to emit > a log message, telling which file was closed at what time (if an output > channel reaches max size). I presume that one would have to create an expression-based filter to handle this, but don't directly see how to generate (and retain) a new filename from it. > Does this make sense? Or did I misunderstand your intentions? If I got > it right, would the proposed new message on max file size (output > channel) solve your need? I think that should be fairly easy to add. It does make sense, I'm just not sure how to apply it. Thanks for your thoughts! RB From rgerhards at hq.adiscon.com Fri Feb 6 13:14:12 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 13:14:12 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> Message-ID: <1233922452.19733.166.camel@rf10up.intern.adiscon.com> On Fri, 2009-02-06 at 06:15 -0700, RB wrote: > > What you describe in your post > > (initial case b)) I would call a side-effect. As the file was closed due > > to size limitation, as a side-effect a new name could be generated. That > > is of interest because the name conveys the information how long it took > > to reach the file size. I think a solution to this need could be to emit > > a log message, telling which file was closed at what time (if an output > > channel reaches max size). > > I presume that one would have to create an expression-based filter to > handle this, but don't directly see how to generate (and retain) a new > filename from it. I probably have not understood your use case. What I propose does not change the file name generation. It "just" logs a message telling you that file xxx has reached its maximum at time ttt and a new file is begun. I thought that was your point. So let me ask: why exactly would you like to have a log files like this log-2009-02-06-11-12 log-2009-02-06-17-12 I thought what you would be interested in is that the first file was created at 1112 hrs while the later was created at 1712 hrs. If I get what the point in it is, I may come up with another solution. Rainer From kenneho.ndu at gmail.com Fri Feb 6 15:00:33 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Fri, 6 Feb 2009 15:00:33 +0100 Subject: [rsyslog] Allowing both TLS and plain TCP connections Message-ID: Hi all. In my testbed I've set up rsyslog 2.0.6 with stunnel, and have one quick design question: I want the rsyslog clients to be able to send rsyslog message over both TLS and plain TCP, depending on the client setup. If I set up the rsyslog server to accept stunnel connections on port 61514 (as described in the documentation), it seems like it accepts both TLS and plain TCP. Is there any reasons why I shouldn't set up the clients to forward all traffick to this port, regardless of it being TLS or TCP (or even UDP)? I'm thinking I'd use port 200 for this (the default TCP port). Greets, Kenneth From aoz.syn at gmail.com Fri Feb 6 16:04:39 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 6 Feb 2009 08:04:39 -0700 Subject: [rsyslog] sticky templates In-Reply-To: <1233922452.19733.166.camel@rf10up.intern.adiscon.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> Message-ID: <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> On Fri, Feb 6, 2009 at 05:14, Rainer Gerhards wrote: > So let me ask: why exactly would you like to have a log files like this > > log-2009-02-06-11-12 > log-2009-02-06-17-12 > > I thought what you would be interested in is that the first file was > created at 1112 hrs while the later was created at 1712 hrs. The point wouldn't necessarily be to have timestamped filenames, but to facilitate at-will rotation, either by HUP or by size. I honestly wouldn't care if the filenames just had an incrementing identifier, like a '%$fileno%' property that incremented with each close/reopen cycle (bonus points for skipping already-existing files). Generalizing the problem to the idea of less-dynamic templates was the next step of my thought process and seemed more interesting than just adding another [potentially less reliable and portable] property. > If I get what the point in it is, I may come up with another solution. Again, I'm just brainstorming. If you think it's worthwhile to pursue now, by all means go for it; I'm just trying to find ways to make my life easier. From rgerhards at hq.adiscon.com Fri Feb 6 16:34:38 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 16:34:38 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> Message-ID: <1233934478.19733.177.camel@rf10up.intern.adiscon.com> On Fri, 2009-02-06 at 08:04 -0700, RB wrote: > On Fri, Feb 6, 2009 at 05:14, Rainer Gerhards wrote: > > So let me ask: why exactly would you like to have a log files like this > > > > log-2009-02-06-11-12 > > log-2009-02-06-17-12 > > > > I thought what you would be interested in is that the first file was > > created at 1112 hrs while the later was created at 1712 hrs. > > The point wouldn't necessarily be to have timestamped filenames, but > to facilitate at-will rotation, either by HUP or by size. I honestly > wouldn't care if the filenames just had an incrementing identifier, > like a '%$fileno%' property that incremented with each close/reopen > cycle (bonus points for skipping already-existing files). > Generalizing the problem to the idea of less-dynamic templates was the > next step of my thought process and seemed more interesting than just > adding another [potentially less reliable and portable] property. Ah, OK, I begin to understand. So what you are actually after is kind of a unique file identifier. I have updates for omfile on my mind which would go in a direction that, I think, is close. One of the things is that I would like to enable the output writer to start new files when, for example - a specific period of time has elapsed - a specific file size has been reached - a specific number of messages has been logged ... I intended to work on the size issue first and use the stream class that was originally developed for the queue. That class supports automatic file naming and numbering (that's how the queue files are generated). It can be set to circular logging (used by the queue, with a modul of 1,000,000 if I remember correctly out of my head) or monotonically increasing file numbers (up to the long long modul). Does this go into the same direction? > > > If I get what the point in it is, I may come up with another solution. > > Again, I'm just brainstorming. If you think it's worthwhile to pursue > now, by all means go for it; I'm just trying to find ways to make my > life easier. You are were welcome. The more use cases I know, the easier it is to do things in the right direction when I change something. Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From aoz.syn at gmail.com Fri Feb 6 17:04:54 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 6 Feb 2009 09:04:54 -0700 Subject: [rsyslog] sticky templates In-Reply-To: <1233934478.19733.177.camel@rf10up.intern.adiscon.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> <1233934478.19733.177.camel@rf10up.intern.adiscon.com> Message-ID: <4255c2570902060804r6aea0df1g902cb75f93803b7f@mail.gmail.com> On Fri, Feb 6, 2009 at 08:34, Rainer Gerhards wrote: > I have updates for omfile on my mind which would go in a direction that, > I think, is close. One of the things is that I would like to enable the > output writer to start new files when, for example > > - a specific period of time has elapsed > - a specific file size has been reached > - a specific number of messages has been logged > ... > > I intended to work on the size issue first and use the stream class that > was originally developed for the queue. That class supports automatic > file naming and numbering (that's how the queue files are generated). It > can be set to circular logging (used by the queue, with a modul of > 1,000,000 if I remember correctly out of my head) or monotonically > increasing file numbers (up to the long long modul). > > Does this go into the same direction? It definitely satisfies my original need, particularly if they could eventually be reset on HUP as well. If I have multiple streams logging to a dedicated partition, it would be preferable to have an outside job watching the partition's status and HUP (or similar) rsyslog when it needs to archive and make more space, as opposed to trying to configure each stream's size individually. From rgerhards at hq.adiscon.com Fri Feb 6 16:51:53 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 16:51:53 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902060804r6aea0df1g902cb75f93803b7f@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> <1233934478.19733.177.camel@rf10up.intern.adiscon.com> <4255c2570902060804r6aea0df1g902cb75f93803b7f@mail.gmail.com> Message-ID: <1233935513.19733.180.camel@rf10up.intern.adiscon.com> On Fri, 2009-02-06 at 09:04 -0700, RB wrote: > On Fri, Feb 6, 2009 at 08:34, Rainer Gerhards wrote: > > I have updates for omfile on my mind which would go in a direction that, > > I think, is close. One of the things is that I would like to enable the > > output writer to start new files when, for example > > > > - a specific period of time has elapsed > > - a specific file size has been reached > > - a specific number of messages has been logged > > ... > > > > I intended to work on the size issue first and use the stream class that > > was originally developed for the queue. That class supports automatic > > file naming and numbering (that's how the queue files are generated). It > > can be set to circular logging (used by the queue, with a modul of > > 1,000,000 if I remember correctly out of my head) or monotonically > > increasing file numbers (up to the long long modul). > > > > Does this go into the same direction? > > It definitely satisfies my original need, particularly if they could > eventually be reset on HUP as well. If I have multiple streams > logging to a dedicated partition, it would be preferable to have an > outside job watching the partition's status and HUP (or similar) > rsyslog when it needs to archive and make more space, as opposed to > trying to configure each stream's size individually. It is not something that I can do immediately, but it sound quite doable. We could also add an "close log if free space is below..." option (which means a cleanup script must be called and a new rollover disabled for n seconds...). I'd appreciate if you could add this to the bugzilla as a feature request. Again, I unfortunately can not do this immediately. Quick status: I am waiting for the race bug dust to settle and then think I will contine to work on performance, as well as straighting out some things that may have caused the HUP fault at David's site. In v4, we already have good performance enhancements, they are just only for UDP so far. This needs to be ported to the other inputs. I expect big savings. Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From friedl at hq.adiscon.com Mon Feb 9 17:53:55 2009 From: friedl at hq.adiscon.com (Florian Riedl) Date: Mon, 9 Feb 2009 17:53:55 +0100 Subject: [rsyslog] rsyslog 3.20.4 (stable) released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB89@grfint2.intern.adiscon.com> Hi all, rsyslog 3.20.4, a member of the v3-stable branch, has been released today. This is a bug-fixing release. Most importantly, it now contains the fix for the data race we have seen under some circumstances. Feedback so far indicates that this fix, in the other branches, seems to solve the issue (or at least improve the situation very much). As such, it has now also been released for v3-stable. There are also some other, minor, fixes. This is a recommended update for all users of the v3-stable branch. Changelog http://www.rsyslog.com/Article346.phtml Download http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-149.phtml As always, feedback is appreciated. Florian Riedl -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From rsyslog at clark-communications.com Tue Feb 10 02:29:00 2009 From: rsyslog at clark-communications.com (Don Jackson) Date: Mon, 9 Feb 2009 17:29:00 -0800 Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 References: Message-ID: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> The update to my OpenBSD port file for rsyslog was posted to the ports mailing list today: Begin forwarded message: > From: Don Jackson > Date: February 9, 2009 4:59:10 PM PST > To: ports at openbsd.org > Subject: UPDATE: sysutils/rsyslog-3.20.4 > > > Port updated to the latest 3.20.4 release of rsyslog. > > $ cat ./pkg/DESCR > > A syslogd replacement > > > > > > > From mbiebl at gmail.com Tue Feb 10 02:53:16 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Tue, 10 Feb 2009 02:53:16 +0100 Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 In-Reply-To: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> References: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> Message-ID: 2009/2/10 Don Jackson : > The update to my OpenBSD port file for rsyslog was posted to the ports > mailing list today: > > Begin forwarded message: > >> From: Don Jackson >> Date: February 9, 2009 4:59:10 PM PST >> To: ports at openbsd.org >> Subject: UPDATE: sysutils/rsyslog-3.20.4 >> >> >> Port updated to the latest 3.20.4 release of rsyslog. Cool. Does (Open)BSD compile and run out-of-the-box or do you need any patches? If so, please consider forwarding them upstream for review and inclusion. It would also be nice, if an (Open)BSD expert could take a look at the atomic operations configure check [1]. Apparently that one fails on FreeBSD (dunno about OpenBSD). Cheers, Michael [1] http://bugzilla.adiscon.com/show_bug.cgi?id=112 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From rgerhards at hq.adiscon.com Tue Feb 10 14:58:06 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 14:58:06 +0100 Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 In-Reply-To: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> References: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB96@grfint2.intern.adiscon.com> Congrats and thanks! Much appreciated! As Michael said, feel free to forward any patches and requests. Rainer PS: I was busy last week and am busy this week, but will become more responsive next week ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Don Jackson > Sent: Tuesday, February 10, 2009 2:29 AM > To: rsyslog-users > Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 > > The update to my OpenBSD port file for rsyslog was posted to the ports > mailing list today: > > Begin forwarded message: > > > From: Don Jackson > > Date: February 9, 2009 4:59:10 PM PST > > To: ports at openbsd.org > > Subject: UPDATE: sysutils/rsyslog-3.20.4 > > > > > > Port updated to the latest 3.20.4 release of rsyslog. > > > > $ cat ./pkg/DESCR > > > > A syslogd replacement > > > > > > > > > > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Tue Feb 10 17:20:37 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Tue, 10 Feb 2009 17:20:37 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? Message-ID: Hello list. I've currently got rsyslog to separate log files based on sending device, as desribed here: http://www.rsyslog.com/Article60.phtml I'd like to filter based on domain, and therefore need the fqdn of each sending device. Is it possible to set up rsyslog to always use fqdn, even if the sending device is on the same domain? From what I've seen in the documentation one can set up rsyslog to always use short names, but not the other way around. I'm using rsyslog v2.0.6. Regards, Kenneth From rgerhards at hq.adiscon.com Tue Feb 10 17:21:21 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 17:21:21 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> I think there is no way to do that in v2 (but I have not checked the docs). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Tuesday, February 10, 2009 5:21 PM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? > > Hello list. > > > I've currently got rsyslog to separate log files based on sending > device, as > desribed here: http://www.rsyslog.com/Article60.phtml > > I'd like to filter based on domain, and therefore need the fqdn of each > sending device. Is it possible to set up rsyslog to always use fqdn, > even if > the sending device is on the same domain? From what I've seen in the > documentation one can set up rsyslog to always use short names, but not > the > other way around. I'm using rsyslog v2.0.6. > > > Regards, > Kenneth > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Tue Feb 10 17:35:43 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Tue, 10 Feb 2009 17:35:43 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> Message-ID: Ok. I've checked the docs, but couldn't see that this was supported. I'll have another look tomorrow. Thanks for the quick response anyway. :) On 2/10/09, Rainer Gerhards wrote: > > I think there is no way to do that in v2 (but I have not checked the > docs). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Tuesday, February 10, 2009 5:21 PM > > To: rsyslog at lists.adiscon.com > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? > > > > Hello list. > > > > > > I've currently got rsyslog to separate log files based on sending > > device, as > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > I'd like to filter based on domain, and therefore need the fqdn of > each > > sending device. Is it possible to set up rsyslog to always use fqdn, > > even if > > the sending device is on the same domain? From what I've seen in the > > documentation one can set up rsyslog to always use short names, but > not > > the > > other way around. I'm using rsyslog v2.0.6. > > > > > > Regards, > > Kenneth > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Feb 10 17:36:43 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 17:36:43 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> As far as I remember, I implemented this recently, so chances are very slim it is in v2. But you may be able to build a patch based on what you find in git... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Tuesday, February 10, 2009 5:36 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > Ok. I've checked the docs, but couldn't see that this was supported. > I'll > have another look tomorrow. > > Thanks for the quick response anyway. :) > > > On 2/10/09, Rainer Gerhards wrote: > > > > I think there is no way to do that in v2 (but I have not checked the > > docs). > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > To: rsyslog at lists.adiscon.com > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > > > > > Hello list. > > > > > > > > > I've currently got rsyslog to separate log files based on sending > > > device, as > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > I'd like to filter based on domain, and therefore need the fqdn of > > each > > > sending device. Is it possible to set up rsyslog to always use > fqdn, > > > even if > > > the sending device is on the same domain? From what I've seen in > the > > > documentation one can set up rsyslog to always use short names, but > > not > > > the > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > Regards, > > > Kenneth > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Feb 10 17:39:52 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 17:39:52 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB9F@grfint2.intern.adiscon.com> This may be a good starting point: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=60b8ce14bf33e76237c f82dd1f68acc750e64316 > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Tuesday, February 10, 2009 5:37 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > As far as I remember, I implemented this recently, so chances are very > slim it is in v2. But you may be able to build a patch based on what > you > find in git... > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Tuesday, February 10, 2009 5:36 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Ok. I've checked the docs, but couldn't see that this was supported. > > I'll > > have another look tomorrow. > > > > Thanks for the quick response anyway. :) > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > I think there is no way to do that in v2 (but I have not checked > the > > > docs). > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > To: rsyslog at lists.adiscon.com > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > > > > > Hello list. > > > > > > > > > > > > I've currently got rsyslog to separate log files based on sending > > > > device, as > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > I'd like to filter based on domain, and therefore need the fqdn > of > > > each > > > > sending device. Is it possible to set up rsyslog to always use > > fqdn, > > > > even if > > > > the sending device is on the same domain? From what I've seen in > > the > > > > documentation one can set up rsyslog to always use short names, > but > > > not > > > > the > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > Regards, > > > > Kenneth > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From michaelt at adam.com.au Wed Feb 11 00:08:27 2009 From: michaelt at adam.com.au (Michael Trewartha) Date: Wed, 11 Feb 2009 09:38:27 +1030 Subject: [rsyslog] Windows Events to a rsyslog server? Message-ID: <499208EB.1030608@adam.com.au> Hello, We have a rsyslog server operating which receives all remote syslog messages from our various linux servers so we can centralise tracking of any issues we encounter. We also run some Windows servers, which we would like to configure to send events of Warning and above remotely to our rsyslog server. I've tried using the pre-built executable for Eventlog to Syslog Utility found here: https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but it appears the events aren't sending. Save installing a winsyslog server, is there any methods anyone is aware of to send Windows Events to a remote rsyslog server? From aoz.syn at gmail.com Wed Feb 11 01:59:55 2009 From: aoz.syn at gmail.com (RB) Date: Tue, 10 Feb 2009 17:59:55 -0700 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <499208EB.1030608@adam.com.au> References: <499208EB.1030608@adam.com.au> Message-ID: <4255c2570902101659q3753a679k9cac2639276d0040@mail.gmail.com> On Tue, Feb 10, 2009 at 16:08, Michael Trewartha wrote: > We also run some Windows servers, which we would like to configure to > send events of Warning and above remotely to our rsyslog server. > I've tried using the pre-built executable for Eventlog to Syslog Utility > found here: > https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but > it appears the events aren't sending. > Save installing a winsyslog server, is there any methods anyone is aware > of to send Windows Events to a remote rsyslog server? Have you, perchance, looked at the company that sponsors rsyslog's development? From DGillies at fairfaxdigital.com.au Wed Feb 11 02:05:21 2009 From: DGillies at fairfaxdigital.com.au (David Gillies) Date: Wed, 11 Feb 2009 12:05:21 +1100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <499208EB.1030608@adam.com.au> References: <499208EB.1030608@adam.com.au> Message-ID: <4310250BC419AC46BB47F728902B0DD603B27246@EXCHDP3.ffx.jfh.com.au> I guess Adiscon's Event Reporter could be an option: http://www.eventreporter.com/en/Product/ David Gillies Systems Engineer Digital Infrastructure Services Fairfax Digital -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Michael Trewartha Sent: Wednesday, 11 February 2009 10:08 AM To: rsyslog at lists.adiscon.com Subject: [rsyslog] Windows Events to a rsyslog server? Hello, We have a rsyslog server operating which receives all remote syslog messages from our various linux servers so we can centralise tracking of any issues we encounter. We also run some Windows servers, which we would like to configure to send events of Warning and above remotely to our rsyslog server. I've tried using the pre-built executable for Eventlog to Syslog Utility found here: https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but it appears the events aren't sending. Save installing a winsyslog server, is there any methods anyone is aware of to send Windows Events to a remote rsyslog server? The information contained in this e-mail message and any accompanying files is or may be confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail is subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. Fairfax does not guarantee the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore Fairfax does not accept legal responsibility for the contents of this message or attached files. From rgerhards at hq.adiscon.com Wed Feb 11 11:23:00 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 11:23:00 +0100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <499208EB.1030608@adam.com.au> References: <499208EB.1030608@adam.com.au> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> Of course, I also recommend EventReporter[1], not only because it funds rsyslog development, but also because it is the only solution that can really pull everything from every Event Log on any Windows and do this in a format that is compatible between Vista, Win2008 and older Windows releases (this is not a sales plug, I have hard technical facts for that, but I think it is not appropriate to send all of them in reply to this post). Having said this, rsyslog will of course accept messages from any process that emits syslog messages. So I would assume that there is a problem with your sender configuration. Most probably, it is not sending to the right port. Also, a firewall at the sender or the receiver (or both) may block the traffic. HTH Rainer [1] http://www.eventreporter.com > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Michael Trewartha > Sent: Wednesday, February 11, 2009 12:08 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Windows Events to a rsyslog server? > > Hello, > We have a rsyslog server operating which receives all remote syslog > messages from our various linux servers so we can centralise tracking > of > any issues we encounter. > We also run some Windows servers, which we would like to configure to > send events of Warning and above remotely to our rsyslog server. > I've tried using the pre-built executable for Eventlog to Syslog > Utility > found here: > https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but > it appears the events aren't sending. > Save installing a winsyslog server, is there any methods anyone is > aware > of to send Windows Events to a remote rsyslog server? > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 11 11:26:46 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 11 Feb 2009 11:26:46 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> Message-ID: Thanks for the tip. I'll have to discuss this with my colleagues, but since this will probably not be very popular with red hat support I suspect that we'll land on not doing this. :/ On 2/10/09, Rainer Gerhards wrote: > > As far as I remember, I implemented this recently, so chances are very > slim it is in v2. But you may be able to build a patch based on what you > find in git... > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Tuesday, February 10, 2009 5:36 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Ok. I've checked the docs, but couldn't see that this was supported. > > I'll > > have another look tomorrow. > > > > Thanks for the quick response anyway. :) > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > I think there is no way to do that in v2 (but I have not checked the > > > docs). > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > To: rsyslog at lists.adiscon.com > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > > > > > Hello list. > > > > > > > > > > > > I've currently got rsyslog to separate log files based on sending > > > > device, as > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > I'd like to filter based on domain, and therefore need the fqdn of > > > each > > > > sending device. Is it possible to set up rsyslog to always use > > fqdn, > > > > even if > > > > the sending device is on the same domain? From what I've seen in > > the > > > > documentation one can set up rsyslog to always use short names, > but > > > not > > > > the > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > Regards, > > > > Kenneth > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Wed Feb 11 11:27:54 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 11:27:54 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Side-note: if you talk to red hat, ask if they will move over to v3 any time before RHEL 6. I do not have specifics, but I would not outrule such a move. In that case, you'd have only a temporary problem (which may be easier to bear). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 11, 2009 11:27 AM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > Thanks for the tip. I'll have to discuss this with my colleagues, but > since > this will probably not be very popular with red hat support I suspect > that > we'll land on not doing this. :/ > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > As far as I remember, I implemented this recently, so chances are > very > > slim it is in v2. But you may be able to build a patch based on what > you > > find in git... > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > devices? > > > > > > Ok. I've checked the docs, but couldn't see that this was > supported. > > > I'll > > > have another look tomorrow. > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > I think there is no way to do that in v2 (but I have not checked > the > > > > docs). > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > To: rsyslog at lists.adiscon.com > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > > devices? > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > sending > > > > > device, as > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > I'd like to filter based on domain, and therefore need the fqdn > of > > > > each > > > > > sending device. Is it possible to set up rsyslog to always use > > > fqdn, > > > > > even if > > > > > the sending device is on the same domain? From what I've seen > in > > > the > > > > > documentation one can set up rsyslog to always use short names, > > but > > > > not > > > > > the > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > Regards, > > > > > Kenneth > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 11 12:51:43 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 11 Feb 2009 12:51:43 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Message-ID: I've contacted red hat to see what their rsyslog plans are. :) I'll post back when I hear something. On 2/11/09, Rainer Gerhards wrote: > > Side-note: if you talk to red hat, ask if they will move over to v3 any > time before RHEL 6. I do not have specifics, but I would not outrule > such a move. In that case, you'd have only a temporary problem (which > may be easier to bear). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 11, 2009 11:27 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Thanks for the tip. I'll have to discuss this with my colleagues, but > > since > > this will probably not be very popular with red hat support I suspect > > that > > we'll land on not doing this. :/ > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > As far as I remember, I implemented this recently, so chances are > > very > > > slim it is in v2. But you may be able to build a patch based on what > > you > > > find in git... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > Ok. I've checked the docs, but couldn't see that this was > > supported. > > > > I'll > > > > have another look tomorrow. > > > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > > > I think there is no way to do that in v2 (but I have not checked > > the > > > > > docs). > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > > sending > > > > > > device, as > > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > > > I'd like to filter based on domain, and therefore need the > fqdn > > of > > > > > each > > > > > > sending device. Is it possible to set up rsyslog to always use > > > > fqdn, > > > > > > even if > > > > > > the sending device is on the same domain? From what I've seen > > in > > > > the > > > > > > documentation one can set up rsyslog to always use short > names, > > > but > > > > > not > > > > > > the > > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Kenneth > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From r.bhatia at ipax.at Wed Feb 11 13:55:38 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Wed, 11 Feb 2009 13:55:38 +0100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> References: <499208EB.1030608@adam.com.au> <577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> Message-ID: <4992CACA.2060403@ipax.at> hello rainer, Rainer Gerhards wrote: > Of course, I also recommend EventReporter[1], not only because it funds > rsyslog development, but also because it is the only solution that can > really pull everything from every Event Log on any Windows and do this > in a format that is compatible between Vista, Win2008 and older Windows > releases (this is not a sales plug, I have hard technical facts for > that, but I think it is not appropriate to send all of them in reply to > this post). i wanted to get a quick overview of the eventrepoert prices but failed until i started the "order" process. there i found a kind of confusing interface using abbreviations (i interpreted UI as "User Interface", not "Upgrade Insurance") and a javascript calculator. so: the price for the product is 65 euro for one licence, right? moreover, i am not sure if the purchased version will still work after one year or if the yearly maintenance-plan is obligatory. but visiting your shop for the second time, i think it will continue to work, right? cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From rgerhards at hq.adiscon.com Wed Feb 11 14:04:35 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 14:04:35 +0100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <4992CACA.2060403@ipax.at> References: <499208EB.1030608@adam.com.au><577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> <4992CACA.2060403@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBBB@grfint2.intern.adiscon.com> I am replying to this on-list, further questions will go via private mail (because I guess this is getting off-topic for the rsyslog list ;)) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Wednesday, February 11, 2009 1:56 PM > To: rsyslog-users > Subject: Re: [rsyslog] Windows Events to a rsyslog server? > > hello rainer, > > Rainer Gerhards wrote: > > Of course, I also recommend EventReporter[1], not only because it > funds > > rsyslog development, but also because it is the only solution that > can > > really pull everything from every Event Log on any Windows and do > this > > in a format that is compatible between Vista, Win2008 and older > Windows > > releases (this is not a sales plug, I have hard technical facts for > > that, but I think it is not appropriate to send all of them in reply > to > > this post). > > i wanted to get a quick overview of the eventrepoert prices but failed > until i started the "order" process. > > there i found a kind of confusing interface using abbreviations (i > interpreted UI as "User Interface", not "Upgrade Insurance") and a > javascript calculator. > Will forward that feedback and see what I can do ;) - thanks! > so: the price for the product is 65 euro for one licence, right? In a nutshell - yes, with volume discounts available > moreover, i am not sure if the purchased version will still work after > one year or if the yearly maintenance-plan is obligatory. but visiting > your shop for the second time, i think it will continue to work, right? Yes - licenses are perpetual. The maintenance plan is purely optional. Rainer From kenneho.ndu at gmail.com Wed Feb 11 14:51:14 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 11 Feb 2009 14:51:14 +0100 Subject: [rsyslog] Using property-based filters to separate log files Message-ID: Hello all. I've read the documentation on property-based filters ( http://www.rsyslog.com/doc-rsyslog_conf_filter.html), and are trying to use this feature combined with file name templating ( http://www.rsyslog.com/Article60.phtml). What I'd like to do is to apply templates to groups of hosts based on their hostname. For example, I'd like to apply template "t1" to hosts such as "test01" and "test02", and template "t2" to hosts "prod01" and "prod02". In other words, different templates should be used based on parts of the file name. To accomplish this I tried this approach: *$template DynaFileTest,"/var/log/syslog/test/system-%HOSTNAME%.log" $template DynaFileProd,"/var/log/syslog/prod/system-%HOSTNAME%.log" * *:HOSTNAME, contains, "test" *.* -?DynaFileTest * *:HOSTNAME, contains, "prod" *.* -?DynaFileProd * This didn't work, so I must have got it wrong. Can anyone point out what I'm doing wrong? Or maybe there are better ways of doing this? Greets, Kenneth From Luis.Fernando.Munoz.Mejias at cern.ch Wed Feb 11 14:59:19 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Wed, 11 Feb 2009 14:59:19 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? Message-ID: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Hello, world! I'm trying to store my logs centrally on an Oracle database. I need it to be Oracle. Due to some restrictions around there, I can't use the recommended version of libdbi, but an older one that is not working with rsyslog. I can't rebuild that RPM, and I have no influence on the upgrade process or schedule. Finally, I also need something with *excellent* performance, and the documentation states omlibdbi doesn't perform as well as other DB-related modules, so I decided to try my own small set of input and output modules. So, my question is: is there any documentation or guide for writing modules, something that gives some insight of what all those macros (BEGINcreateInstance, CODESTARTcreateInstance, etc, etc, etc) I see mean? Do I need to grep the code for that? I've googled for it and reviewed the Git repository, but found nothing. Thanks in advance. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From rgerhards at hq.adiscon.com Wed Feb 11 15:08:14 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 15:08:14 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: <1234361294.19733.230.camel@rf10up.intern.adiscon.com> Hi Luis Fernando, glad you asked :) The documentation is ... well... not much ;) The best thing is probably to start with the existing MySQL module. HOWEVER, I myself would be very interested in a native, high-performing Oracle driver. I neither have the expertise to do it not the test environment. If you like, we could collaborate on this effort. I'd create a skeleton output module for you, guide you through using it and you provide the Oracle bits to it (that should be fairly easy). Of course, that means your module would need to be contributed back to the project. What do you think about this? Rainer On Wed, 2009-02-11 at 14:59 +0100, Luis Fernando Mu?oz Mej?as wrote: > Hello, world! > > I'm trying to store my logs centrally on an Oracle database. I need it > to be Oracle. > > Due to some restrictions around there, I can't use the recommended > version of libdbi, but an older one that is not working with rsyslog. I > can't rebuild that RPM, and I have no influence on the upgrade process > or schedule. > > Finally, I also need something with *excellent* performance, and the > documentation states omlibdbi doesn't perform as well as other > DB-related modules, so I decided to try my own small set of input and > output modules. > > So, my question is: is there any documentation or guide for writing > modules, something that gives some insight of what all those macros > (BEGINcreateInstance, CODESTARTcreateInstance, etc, etc, etc) I see > mean? Do I need to grep the code for that? > > I've googled for it and reviewed the Git repository, but found nothing. > > Thanks in advance. From david at lang.hm Wed Feb 11 16:31:29 2009 From: david at lang.hm (david at lang.hm) Date: Wed, 11 Feb 2009 07:31:29 -0800 (PST) Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: On Wed, 11 Feb 2009, Luis Fernando Mu?oz Mej?as wrote: > Finally, I also need something with *excellent* performance, and the > documentation states omlibdbi doesn't perform as well as other > DB-related modules, so I decided to try my own small set of input and > output modules. one major limitation you will run into is that rsyslog proceses log entries one at a time. this means that each log entry inserted into the oracle database will be a seperate transaction. changing this is a fairly major task that will require someone to sponser it (I've asked about this in the past, but my company has not needed the performance enough to do this yet) David Lang From jules at visionintel.com Wed Feb 11 19:49:31 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Wed, 11 Feb 2009 18:49:31 +0000 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <4310250BC419AC46BB47F728902B0DD603B27246@EXCHDP3.ffx.jfh.com.au> References: <499208EB.1030608@adam.com.au> <4310250BC419AC46BB47F728902B0DD603B27246@EXCHDP3.ffx.jfh.com.au> Message-ID: <69544300902111049p1b213e88m6fb7b05670347032@mail.gmail.com> you can send remote message to syslog by changing the rsyslog.conf # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional *.* @@192.168.15.103:514 # ### end of the forwarding rule ### You need to specify the IP and port where you are sending your logs. basically, you send it locally and syslog will forward them for you. Jules 2009/2/11 David Gillies > I guess Adiscon's Event Reporter could be an option: > > http://www.eventreporter.com/en/Product/ > > David Gillies > Systems Engineer > Digital Infrastructure Services > Fairfax Digital > > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Michael > Trewartha > Sent: Wednesday, 11 February 2009 10:08 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Windows Events to a rsyslog server? > > Hello, > We have a rsyslog server operating which receives all remote syslog > messages from our various linux servers so we can centralise tracking of > any issues we encounter. > We also run some Windows servers, which we would like to configure to > send events of Warning and above remotely to our rsyslog server. > I've tried using the pre-built executable for Eventlog to Syslog Utility > found here: > https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but > it appears the events aren't sending. > Save installing a winsyslog server, is there any methods anyone is aware > of to send Windows Events to a remote rsyslog server? > > The information contained in this e-mail message and any accompanying files > is or may be confidential. If you are not the intended recipient, any use, > dissemination, reliance, forwarding, printing or copying of this e-mail or > any attached files is unauthorised. This e-mail is subject to copyright. No > part of it should be reproduced, adapted or communicated without the written > consent of the copyright owner. If you have received this e-mail in error > please advise the sender immediately by return e-mail or telephone and > delete all copies. Fairfax does not guarantee the accuracy or completeness > of any information contained in this e-mail or attached files. Internet > communications are not secure, therefore Fairfax does not accept legal > responsibility for the contents of this message or attached files. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Wed Feb 11 19:53:08 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Wed, 11 Feb 2009 18:53:08 +0000 Subject: [rsyslog] rsyslog.conf Message-ID: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> Giving that one can change the IP in the rsconfig.conf to send a log remotely, would they be an easy way, or what would be the best approach to change the config file programatically so that IP can be update whenever wanted. thanks, From aoz.syn at gmail.com Wed Feb 11 20:22:32 2009 From: aoz.syn at gmail.com (RB) Date: Wed, 11 Feb 2009 12:22:32 -0700 Subject: [rsyslog] rsyslog.conf In-Reply-To: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> Message-ID: <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso wrote: > Giving that one can change the IP in the rsconfig.conf to send a log > remotely, would they be an easy way, or what would be the best approach to > change the config file programatically so that IP can be update whenever > wanted. Use DNS. There are nearly infinite of ways to programmatically replace FOO with BAR in a text file, but changing the file requires a HUP or restart for an already-running instance of rsyslog, which is inelegant. If you're trying to point to multiple hosts, either float a virtual IP among them or point at a DNS record you can move among hosts. From rgerhards at hq.adiscon.com Wed Feb 11 20:39:23 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 20:39:23 +0100 Subject: [rsyslog] rsyslog.conf Message-ID: <001201c98c80$6b86f89a$060013ac@intern.adiscon.com> >From the phone: You need to be careful - dns changes will most probably not affect the running instance immediately. So IMHO the virtual IP is the best solution. rainer ----- Urspr?ngliche Nachricht ----- Von: "RB" An: "rsyslog-users" Gesendet: 11.02.09 20:21 Betreff: Re: [rsyslog] rsyslog.conf On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso wrote: > Giving that one can change the IP in the rsconfig.conf to send a log > remotely, would they be an easy way, or what would be the best approach to > change the config file programatically so that IP can be update whenever > wanted. Use DNS. There are nearly infinite of ways to programmatically replace FOO with BAR in a text file, but changing the file requires a HUP or restart for an already-running instance of rsyslog, which is inelegant. If you're trying to point to multiple hosts, either float a virtual IP among them or point at a DNS record you can move among hosts. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From jmoyer at redhat.com Wed Feb 11 21:53:59 2009 From: jmoyer at redhat.com (Jeff Moyer) Date: Wed, 11 Feb 2009 15:53:59 -0500 Subject: [rsyslog] [RFC] add an option to buffer masked syslog messages Message-ID: Hi, folks, I posed this question on the libc-alpha mailing list [1]: I was about to start writing support for bufferring debug messages in autofs, when it occurred to me that this is a fairly useful thing to do, and it makes little sense for every application to reinvent the wheel. What I'd like is to have a fixed size ring buffer to which messages that are masked are logged. Then, if the application asks for these messages, dump them to the log. The reason, if it isn't obvious, is so that we can dump application state should a problem present itself when debug logging is disabled. What do folks think about this? Is it better accomplished elsewhere? The response I got was that (at least Roland thinks) this should be done in the syslog daemon, not in the library. So, I'll pose the same question here, and I look forward to hearing your thoughts. Cheers, Jeff [1] http://sourceware.org/ml/libc-alpha/2009-02/msg00036.html From jules at visionintel.com Wed Feb 11 22:14:41 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Wed, 11 Feb 2009 21:14:41 +0000 Subject: [rsyslog] rsyslog.conf In-Reply-To: <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> Message-ID: <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> well, I am not trying to point to multiple addresses at the same time, but i am in an environment where the IP could change every 10min or 15 min. 2009/2/11 RB > On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso > wrote: > > Giving that one can change the IP in the rsconfig.conf to send a log > > remotely, would they be an easy way, or what would be the best approach > to > > change the config file programatically so that IP can be update whenever > > wanted. > > Use DNS. There are nearly infinite of ways to programmatically > replace FOO with BAR in a text file, but changing the file requires a > HUP or restart for an already-running instance of rsyslog, which is > inelegant. If you're trying to point to multiple hosts, either float > a virtual IP among them or point at a DNS record you can move among > hosts. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Wed Feb 11 22:22:47 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 22:22:47 +0100 Subject: [rsyslog] rsyslog.conf In-Reply-To: <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com><4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBC7@grfint2.intern.adiscon.com> On this time window, I think you can not get around issuing a restart-type HUP. As this needs to be synchronised in any case, you'll probably need a script, so you could also write a file that contains the new IP in question. I suggest one extra file that then is included via $IncludeConfig from the main rsyslog.conf. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Jules > Pagna Disso > Sent: Wednesday, February 11, 2009 10:15 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog.conf > > well, > > I am not trying to point to multiple addresses at the same > time, but i am in > an environment where the IP could change every 10min or 15 min. > > 2009/2/11 RB > > > On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso > > > wrote: > > > Giving that one can change the IP in the rsconfig.conf to > send a log > > > remotely, would they be an easy way, or what would be the > best approach > > to > > > change the config file programatically so that IP can be > update whenever > > > wanted. > > > > Use DNS. There are nearly infinite of ways to programmatically > > replace FOO with BAR in a text file, but changing the file > requires a > > HUP or restart for an already-running instance of rsyslog, which is > > inelegant. If you're trying to point to multiple hosts, > either float > > a virtual IP among them or point at a DNS record you can move among > > hosts. > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Thu Feb 12 01:28:08 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Thu, 12 Feb 2009 00:28:08 +0000 Subject: [rsyslog] rsyslog.conf In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBC7@grfint2.intern.adiscon.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FBC7@grfint2.intern.adiscon.com> Message-ID: <69544300902111628y262c769et5d8c6b712714fb42@mail.gmail.com> i came accross this syslogd that supports remote loggin. any one used it before? i was trying to install in on my Fedora 10 but i got the conflictual message with syslog-ng. it seems as if it's either or. http://linux.about.com/od/commands/l/blcmdl8_syslogd.htm hope this help for remote logging but again, remember to set the remote host so that he can accept remote messages. http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch05_:_Troubleshooting_Linux_with_syslog thanks 2009/2/11 Rainer Gerhards > On this time window, I think you can not get around issuing a > restart-type HUP. As this needs to be synchronised in any case, you'll > probably need a script, so you could also write a file that contains the > new IP in question. I suggest one extra file that then is included via > $IncludeConfig from the main rsyslog.conf. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com > > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Jules > > Pagna Disso > > Sent: Wednesday, February 11, 2009 10:15 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] rsyslog.conf > > > > well, > > > > I am not trying to point to multiple addresses at the same > > time, but i am in > > an environment where the IP could change every 10min or 15 min. > > > > 2009/2/11 RB > > > > > On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso > > > > > wrote: > > > > Giving that one can change the IP in the rsconfig.conf to > > send a log > > > > remotely, would they be an easy way, or what would be the > > best approach > > > to > > > > change the config file programatically so that IP can be > > update whenever > > > > wanted. > > > > > > Use DNS. There are nearly infinite of ways to programmatically > > > replace FOO with BAR in a text file, but changing the file > > requires a > > > HUP or restart for an already-running instance of rsyslog, which is > > > inelegant. If you're trying to point to multiple hosts, > > either float > > > a virtual IP among them or point at a DNS record you can move among > > > hosts. > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Fri Feb 13 05:42:14 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Thu, 12 Feb 2009 23:42:14 -0500 Subject: [rsyslog] need some thoughts here Message-ID: <69544300902122042w708bbbb7l369e638af24378a2@mail.gmail.com> I am still trying to find an efficient solution for loggin to a remote location. sysklogd is supposed to do the trick however it is incompatible with rsyslog. when i tried to remove rsyslog, there was a total of 525 packages there was going to be remove, so i decided not to. Any body tried sysklogd? thanks From rgerhards at hq.adiscon.com Fri Feb 13 06:39:18 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 13 Feb 2009 06:39:18 +0100 Subject: [rsyslog] need some thoughts here Message-ID: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> Hi, I do not understand your issue ;) rsyslog is a superset of sysklogd. So you can simply use *.* @remote-host As in sysklogd. rainer ----- Urspr?ngliche Nachricht ----- Von: "Jules Pagna Disso" An: "rsyslog-users" Gesendet: 13.02.09 05:41 Betreff: [rsyslog] need some thoughts here I am still trying to find an efficient solution for loggin to a remote location. sysklogd is supposed to do the trick however it is incompatible with rsyslog. when i tried to remove rsyslog, there was a total of 525 packages there was going to be remove, so i decided not to. Any body tried sysklogd? thanks _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From aoz.syn at gmail.com Fri Feb 13 17:21:16 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 13 Feb 2009 09:21:16 -0700 Subject: [rsyslog] need some thoughts here In-Reply-To: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> Message-ID: <4255c2570902130821k3f1cd9e3wcc2107cee23c4f9f@mail.gmail.com> On Thu, Feb 12, 2009 at 22:39, Rainer Gerhards wrote: > I do not understand your issue ;) rsyslog is a superset of sysklogd. So you can simply use Ditto. There are only a couple of log daemons I can think of that _don't_ log remotely, and they're embedded-only. Again: nearly every log daemon you are going to find will log remotely. Can you explain more of the problem you are trying to solve? Changing IPs every few minutes and getting the impression that a remote log daemon is hard to find indicates more of a misunderstanding of the problem than an actual technological issue to me. From jules at visionintel.com Fri Feb 13 22:06:55 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Fri, 13 Feb 2009 21:06:55 +0000 Subject: [rsyslog] need some thoughts here In-Reply-To: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> Message-ID: <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> basically, in fedora, when i try installing sysklogd i have a message that says conflict with syslogd and syslog-ng therefore i cannot install sysklogd 2009/2/13 Rainer Gerhards > Hi, > > I do not understand your issue ;) rsyslog is a superset of sysklogd. So you > can simply use > > *.* @remote-host > > As in sysklogd. > > rainer > > ----- Urspr?ngliche Nachricht ----- > Von: "Jules Pagna Disso" > An: "rsyslog-users" > Gesendet: 13.02.09 05:41 > Betreff: [rsyslog] need some thoughts here > > I am still trying to find an efficient solution for loggin to a remote > location. sysklogd is supposed to do the trick however it is incompatible > with rsyslog. when i tried to remove rsyslog, there was a total of 525 > packages there was going to be remove, so i decided not to. > > Any body tried sysklogd? > > thanks > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From hks.private at gmail.com Fri Feb 13 22:28:45 2009 From: hks.private at gmail.com ((private) HKS) Date: Fri, 13 Feb 2009 16:28:45 -0500 Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> Message-ID: On Fri, Feb 13, 2009 at 4:06 PM, Jules Pagna Disso wrote: > basically, in fedora, when i try installing sysklogd i have a message that > says conflict with syslogd and syslog-ng therefore i cannot install sysklogd > ... Is there a problem you're trying to solve with rsyslog? -HKS From jules at visionintel.com Fri Feb 13 22:36:54 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Fri, 13 Feb 2009 21:36:54 +0000 Subject: [rsyslog] need some thoughts here In-Reply-To: References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> Message-ID: <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> yes, basically i need to write some code to send alert to a remote host something like send(message_options , list of host, port) i can do it but i have to edit rsyslog.conf by programming, yet if i use sysklogd i can just call some routine and do the job, but i failled to install sysklogd. sysklogd has all the option i need i.e -h for host for instance but i can't installed it on fedora 10. i tried on 3 computers no success. 2009/2/13 (private) HKS > On Fri, Feb 13, 2009 at 4:06 PM, Jules Pagna Disso > wrote: > > basically, in fedora, when i try installing sysklogd i have a message > that > > says conflict with syslogd and syslog-ng therefore i cannot install > sysklogd > > > > > ... > > Is there a problem you're trying to solve with rsyslog? > > -HKS > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Sat Feb 14 06:16:32 2009 From: david at lang.hm (david at lang.hm) Date: Fri, 13 Feb 2009 21:16:32 -0800 (PST) Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> Message-ID: On Fri, 13 Feb 2009, Jules Pagna Disso wrote: > yes, basically i need to write some code to send alert to a remote host > something like send(message_options , list of host, port) > > i can do it but i have to edit rsyslog.conf by programming, yet if i use > sysklogd i can just call some routine and do the job, but i failled to > install sysklogd. sysklogd has all the option i need i.e -h for host for > instance but i can't installed it on fedora 10. i tried on 3 computers no > success. umm, for the versions of sysklog that I've used -h was a flag to tell it to go ahead and forward messages. it didn't specify what host they would go to. basicly any version of syslog will let you do that. by the way, I think that the syslogd that RedHat ships is a variation of sysklogd. if you really do want to install sysklogd you need to talk to people who are gurus with rpm packaging options to help you through the dependancy conflicts, but the rsyslog list is not really the right place to search for the info. David Lang > > 2009/2/13 (private) HKS > >> On Fri, Feb 13, 2009 at 4:06 PM, Jules Pagna Disso >> wrote: >>> basically, in fedora, when i try installing sysklogd i have a message >> that >>> says conflict with syslogd and syslog-ng therefore i cannot install >> sysklogd >>> >> >> >> ... >> >> Is there a problem you're trying to solve with rsyslog? >> >> -HKS >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From martinmie at PartyGaming.com Sat Feb 14 14:53:07 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Sat, 14 Feb 2009 14:53:07 +0100 Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled Message-ID: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> Hi, I'm starting to configure some RHEL5 systems with rsyslog-3.19.7-4. One is the logserver and the rest will slowly become the clients... Only one client with TLS support has been configured so far and I had to stop because it wasn't possible to ssh into the machine once rsyslog was up and running after some hours... IIRC, this happened in the past too when activating the TLS support but never got a fix for this issue... Any ideas? TIA, Martin This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From aoz.syn at gmail.com Sat Feb 14 17:25:18 2009 From: aoz.syn at gmail.com (RB) Date: Sat, 14 Feb 2009 09:25:18 -0700 Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> Message-ID: <4255c2570902140825n767831efpa6c77f459daeee3@mail.gmail.com> On Fri, Feb 13, 2009 at 14:06, Jules Pagna Disso wrote: > basically, in fedora, when i try installing sysklogd i have a message that > says conflict with syslogd and syslog-ng therefore i cannot install sysklogd All three log daemons you're talking about (rsyslog, syslogd, syslog-ng) will happily emit messages of your choice to the remote server of your choice. If you're having trouble at this level, I doubt you're familiar with the differences among the three and should probably stick with whatever's installed by default on your distro. From aoz.syn at gmail.com Sat Feb 14 17:32:09 2009 From: aoz.syn at gmail.com (RB) Date: Sat, 14 Feb 2009 09:32:09 -0700 Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> Message-ID: <4255c2570902140832s5e0f0011ndbc1400b5a4d7537@mail.gmail.com> On Fri, Feb 13, 2009 at 14:36, Jules Pagna Disso wrote: > yes, basically i need to write some code to send alert to a remote host > something like send(message_options , list of host, port) > > i can do it but i have to edit rsyslog.conf by programming, yet if i use > sysklogd i can just call some routine and do the job, but i failled to > install sysklogd. sysklogd has all the option i need i.e -h for host for > instance but i can't installed it on fedora 10. i tried on 3 computers no > success. It would be far more helpful if you gave us more precisely what you are trying to do. From what I gather, you seem to be writing a program that you want to send log messages directly to a remote host. For that use, you don't need any of the syslog daemons - just use 'logger' or any of the dozens of C/C++/Perl/Python logging packages available. There are much better ways to solve this, but at this point I am not sure they'll be any easier for you. From aoz.syn at gmail.com Sat Feb 14 17:38:07 2009 From: aoz.syn at gmail.com (RB) Date: Sat, 14 Feb 2009 09:38:07 -0700 Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> Message-ID: <4255c2570902140838o7778459ew33707fbb581be34@mail.gmail.com> On Sat, Feb 14, 2009 at 06:53, Martin Mielke wrote: > I'm starting to configure some RHEL5 systems with rsyslog-3.19.7-4. One > is the logserver and the rest will slowly become the clients... > > Only one client with TLS support has been configured so far and I had to > stop because it wasn't possible to ssh into the machine once rsyslog was > up and running after some hours... There is nothing inherent to rsyslog (with or without TLS) that will interfere with SSH. Your system may be bogging down or crashing, but you need to find out more exactly what's happening - logs, console messages, resource consumption, etc. From rgerhards at hq.adiscon.com Mon Feb 16 09:27:16 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 09:27:16 +0100 Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBFA@grfint2.intern.adiscon.com> Hi Martin, besides the other (good!) comments, I would strongly suggest to upgrade to the most recent stable first. Most importantly, the last release has fixed a race condition that could explain what you are seeing. It is not tied to TLS, but there is no indication why it could not be the cause. Any troubleshooting on an older version is probably not worth the effort. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Saturday, February 14, 2009 2:53 PM > To: rsyslog-users > Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled > > Hi, > > I'm starting to configure some RHEL5 systems with rsyslog-3.19.7-4. One > is the logserver and the rest will slowly become the clients... > > Only one client with TLS support has been configured so far and I had > to > stop because it wasn't possible to ssh into the machine once rsyslog > was > up and running after some hours... > > IIRC, this happened in the past too when activating the TLS support but > never got a fix for this issue... > > Any ideas? > > > TIA, > > Martin > > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Mon Feb 16 10:17:33 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Mon, 16 Feb 2009 10:17:33 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Message-ID: I talked to Red Hat, and it seems like they will not be upgrading rsyslog to v3 before RHEL 6. :/ On 2/11/09, Rainer Gerhards wrote: > > Side-note: if you talk to red hat, ask if they will move over to v3 any > time before RHEL 6. I do not have specifics, but I would not outrule > such a move. In that case, you'd have only a temporary problem (which > may be easier to bear). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 11, 2009 11:27 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Thanks for the tip. I'll have to discuss this with my colleagues, but > > since > > this will probably not be very popular with red hat support I suspect > > that > > we'll land on not doing this. :/ > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > As far as I remember, I implemented this recently, so chances are > > very > > > slim it is in v2. But you may be able to build a patch based on what > > you > > > find in git... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > Ok. I've checked the docs, but couldn't see that this was > > supported. > > > > I'll > > > > have another look tomorrow. > > > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > > > I think there is no way to do that in v2 (but I have not checked > > the > > > > > docs). > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > > sending > > > > > > device, as > > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > > > I'd like to filter based on domain, and therefore need the > fqdn > > of > > > > > each > > > > > > sending device. Is it possible to set up rsyslog to always use > > > > fqdn, > > > > > > even if > > > > > > the sending device is on the same domain? From what I've seen > > in > > > > the > > > > > > documentation one can set up rsyslog to always use short > names, > > > but > > > > > not > > > > > > the > > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Kenneth > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Mon Feb 16 10:18:55 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 10:18:55 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> I do not know whom to approach, but maybe we can get someone else into the boat who can build an publish non RH RPMs that work on RHEL... Anyone with a suggestion on whom to approach? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Monday, February 16, 2009 10:18 AM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > I talked to Red Hat, and it seems like they will not be upgrading > rsyslog to > v3 before RHEL 6. :/ > > On 2/11/09, Rainer Gerhards wrote: > > > > Side-note: if you talk to red hat, ask if they will move over to v3 > any > > time before RHEL 6. I do not have specifics, but I would not outrule > > such a move. In that case, you'd have only a temporary problem (which > > may be easier to bear). > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 11, 2009 11:27 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > devices? > > > > > > Thanks for the tip. I'll have to discuss this with my colleagues, > but > > > since > > > this will probably not be very popular with red hat support I > suspect > > > that > > > we'll land on not doing this. :/ > > > > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > As far as I remember, I implemented this recently, so chances are > > > very > > > > slim it is in v2. But you may be able to build a patch based on > what > > > you > > > > find in git... > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of > sending > > > > > devices? > > > > > > > > > > Ok. I've checked the docs, but couldn't see that this was > > > supported. > > > > > I'll > > > > > have another look tomorrow. > > > > > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > > > > > I think there is no way to do that in v2 (but I have not > checked > > > the > > > > > > docs). > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of > sending > > > > > devices? > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > > > sending > > > > > > > device, as > > > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > > > > > I'd like to filter based on domain, and therefore need the > > fqdn > > > of > > > > > > each > > > > > > > sending device. Is it possible to set up rsyslog to always > use > > > > > fqdn, > > > > > > > even if > > > > > > > the sending device is on the same domain? From what I've > seen > > > in > > > > > the > > > > > > > documentation one can set up rsyslog to always use short > > names, > > > > but > > > > > > not > > > > > > > the > > > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Kenneth > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at ecker-software.de Mon Feb 16 10:25:57 2009 From: david at ecker-software.de (David Ecker) Date: Mon, 16 Feb 2009 10:25:57 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> Message-ID: <49993125.2060603@ecker-software.de> Hi, have you tried to contact the epel group? http://fedoraproject.org/wiki/EPEL They should be able to include an upgrade for rsyslog into their repository for REL5 if you ask them. Bye David Rainer Gerhards schrieb: > I do not know whom to approach, but maybe we can get someone else into > the boat who can build an publish non RH RPMs that work on RHEL... > Anyone with a suggestion on whom to approach? > > Rainer > > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >> Sent: Monday, February 16, 2009 10:18 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending >> devices? >> >> I talked to Red Hat, and it seems like they will not be upgrading >> rsyslog to >> v3 before RHEL 6. :/ >> >> On 2/11/09, Rainer Gerhards wrote: >> >>> Side-note: if you talk to red hat, ask if they will move over to v3 >>> >> any >> >>> time before RHEL 6. I do not have specifics, but I would not outrule >>> such a move. In that case, you'd have only a temporary problem >>> > (which > >>> may be easier to bear). >>> >>> Rainer >>> >>> >>>> -----Original Message----- >>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >>>> Sent: Wednesday, February 11, 2009 11:27 AM >>>> To: rsyslog-users >>>> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending >>>> devices? >>>> >>>> Thanks for the tip. I'll have to discuss this with my colleagues, >>>> >> but >> >>>> since >>>> this will probably not be very popular with red hat support I >>>> >> suspect >> >>>> that >>>> we'll land on not doing this. :/ >>>> >>>> >>>> >>>> >>>> On 2/10/09, Rainer Gerhards wrote: >>>> >>>>> As far as I remember, I implemented this recently, so chances >>>>> > are > >>>> very >>>> >>>>> slim it is in v2. But you may be able to build a patch based on >>>>> >> what >> >>>> you >>>> >>>>> find in git... >>>>> >>>>> Rainer >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>>>> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >>>>>> Sent: Tuesday, February 10, 2009 5:36 PM >>>>>> To: rsyslog-users >>>>>> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of >>>>>> >> sending >> >>>>>> devices? >>>>>> >>>>>> Ok. I've checked the docs, but couldn't see that this was >>>>>> >>>> supported. >>>> >>>>>> I'll >>>>>> have another look tomorrow. >>>>>> >>>>>> Thanks for the quick response anyway. :) >>>>>> >>>>>> >>>>>> On 2/10/09, Rainer Gerhards wrote: >>>>>> >>>>>>> I think there is no way to do that in v2 (but I have not >>>>>>> >> checked >> >>>> the >>>> >>>>>>> docs). >>>>>>> >>>>>>> Rainer >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>>>>>> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >>>>>>>> Sent: Tuesday, February 10, 2009 5:21 PM >>>>>>>> To: rsyslog at lists.adiscon.com >>>>>>>> Subject: [rsyslog] Get rsyslog to always use fqdn of >>>>>>>> >> sending >> >>>>>> devices? >>>>>> >>>>>>>> Hello list. >>>>>>>> >>>>>>>> >>>>>>>> I've currently got rsyslog to separate log files based on >>>>>>>> >>>> sending >>>> >>>>>>>> device, as >>>>>>>> desribed here: http://www.rsyslog.com/Article60.phtml >>>>>>>> >>>>>>>> I'd like to filter based on domain, and therefore need the >>>>>>>> >>> fqdn >>> >>>> of >>>> >>>>>>> each >>>>>>> >>>>>>>> sending device. Is it possible to set up rsyslog to always >>>>>>>> >> use >> >>>>>> fqdn, >>>>>> >>>>>>>> even if >>>>>>>> the sending device is on the same domain? From what I've >>>>>>>> >> seen >> >>>> in >>>> >>>>>> the >>>>>> >>>>>>>> documentation one can set up rsyslog to always use short >>>>>>>> >>> names, >>> >>>>> but >>>>> >>>>>>> not >>>>>>> >>>>>>>> the >>>>>>>> other way around. I'm using rsyslog v2.0.6. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Kenneth >>>>>>>> _______________________________________________ >>>>>>>> rsyslog mailing list >>>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>> http://www.rsyslog.com >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> rsyslog mailing list >>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>> http://www.rsyslog.com >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> rsyslog mailing list >>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>> http://www.rsyslog.com >>>>>> >>>>> _______________________________________________ >>>>> rsyslog mailing list >>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>> http://www.rsyslog.com >>>>> >>>>> >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com >>>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From Luis.Fernando.Munoz.Mejias at cern.ch Mon Feb 16 11:41:21 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Mon, 16 Feb 2009 11:41:21 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> Rainer, My apologies for the late reply. I was subscribed to the digest format and didn't receive your replies. > glad you asked :) The documentation is ... well... not much ;) Oops! > The best thing is probably to start with the existing MySQL > module. HOWEVER, I myself would be very interested in a native, > high-performing Oracle driver. I neither have the expertise to do it > not the test environment. I don't have the expertise either, but do have the test environment... we can try. ;) > If you like, we could collaborate on this effort. I'd create a > skeleton output module for you, guide you through using it and you > provide the Oracle bits to it (that should be fairly easy). Of course, > that means your module would need to be contributed back to the > project. That sounds really great. Before you start coding or preparing anything, let me check how well our DBs perform, because it's not yet clear if they'll be able to cope with the high insertion rate we expect. If we don't go for the Oracle database this work doesn't make sense. I bet we'll want the Oracle, anyways. For this evaluation, I already have a timestamp formatter that fits into Oracle, something that can be used with the property replacer, like %timereported:::date-oracle%. It still needs some real-world testing, but provided it works, is it interesting for the project? If so, should I submit the patch via bugzilla? Is there any paperwork (copyright assingmnents a la FSF or whatever) that should be fullfilled? Thanks. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From rgerhards at hq.adiscon.com Mon Feb 16 17:35:25 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 17:35:25 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC08@grfint2.intern.adiscon.com> Sorry, this time my reply is sluggish ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Luis Fernando Mu?oz Mej?as > Sent: Monday, February 16, 2009 11:41 AM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] Documentation on writing rsyslog modules? > > Rainer, > > My apologies for the late reply. I was subscribed to the digest format > and didn't receive your replies. > > > glad you asked :) The documentation is ... well... not much ;) > > Oops! > > > The best thing is probably to start with the existing MySQL > > module. HOWEVER, I myself would be very interested in a native, > > high-performing Oracle driver. I neither have the expertise to do it > > not the test environment. > > I don't have the expertise either, but do have the test > environment... we can try. ;) A test environment is first step to expertise ;) > > > If you like, we could collaborate on this effort. I'd create a > > skeleton output module for you, guide you through using it and you > > provide the Oracle bits to it (that should be fairly easy). Of > course, > > that means your module would need to be contributed back to the > > project. > > That sounds really great. Before you start coding or preparing > anything, > let me check how well our DBs perform, because it's not yet clear if > they'll be able to cope with the high insertion rate we expect. If we > don't go for the Oracle database this work doesn't make sense. I bet > we'll want the Oracle, anyways. Sounds fair. > > For this evaluation, I already have a timestamp formatter that fits > into > Oracle, something that can be used with the property replacer, like > %timereported:::date-oracle%. Sounds good. This is one of the bad things about current code base, though. The formatter should long come from the custom plugin, but I didn't manage to do the script engine so far (the core of custom functions). Not a big deal, but something that annoys *me* ;) > It still needs some real-world testing, > but provided it works, is it interesting for the project? Definitely > If so, should > I submit the patch via bugzilla? Any way is fine. You can also just email me. Proper credits, of course are guaranteed. > Is there any paperwork (copyright > assingmnents a la FSF or whatever) that should be fullfilled? Nope, we think the project is in a strong enough position even if the submitter holds the copyright. Actually, this was one project goal: keep contributions easy. I really don't like all the blabla that e.g. you need to do when contributing to syslog-ng. Just be aware that some parts of rsyslog come under GPL while some come under LGPL (the runtime files). We assume that whatever you contribute comes under the license of the core module. For new runtime files, this means we expect LGPL, else we have a problem license-wise. Really looking forward to your results, Rainer > > Thanks. > -- > Luis Fernando Mu?oz Mej?as > Luis.Fernando.Munoz.Mejias at cern.ch > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Feb 16 18:52:07 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 18:52:07 +0100 Subject: [rsyslog] rsyslog on Debian 5.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC0E@grfint2.intern.adiscon.com> Hi folks, I guess most of you already know, but I have some excellent news to share. Rsyslog is now default on the stable Debian version: http://blog.gerhards.net/2009/02/rsyslog-now-default-on-stable-debian.ht ml Thanks to everyone who helped make this happen and special thanks to Michael Biebl, the driving force behind the Debian effort! Rainer From hks.private at gmail.com Mon Feb 16 19:18:13 2009 From: hks.private at gmail.com ((private) HKS) Date: Mon, 16 Feb 2009 13:18:13 -0500 Subject: [rsyslog] rsyslog on Debian 5.0 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC0E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC0E@grfint2.intern.adiscon.com> Message-ID: Congrats! -HKS On Mon, Feb 16, 2009 at 12:52 PM, Rainer Gerhards wrote: > Hi folks, > > I guess most of you already know, but I have some excellent news to > share. Rsyslog is now default on the stable Debian version: > > http://blog.gerhards.net/2009/02/rsyslog-now-default-on-stable-debian.ht > ml > > Thanks to everyone who helped make this happen and special thanks to > Michael Biebl, the driving force behind the Debian effort! > > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From aoz.syn at gmail.com Mon Feb 16 23:48:31 2009 From: aoz.syn at gmail.com (RB) Date: Mon, 16 Feb 2009 15:48:31 -0700 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <49993125.2060603@ecker-software.de> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> Message-ID: <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> On Mon, Feb 16, 2009 at 02:25, David Ecker wrote: > have you tried to contact the epel group? > > http://fedoraproject.org/wiki/EPEL > > They should be able to include an upgrade for rsyslog into their > repository for REL5 if you ask them. Failing that, I already wrote one spec for rsyslog-3.x under CentOS-5 and could be pretty easily persuaded to do so again. From daodennis at gmail.com Tue Feb 17 06:30:06 2009 From: daodennis at gmail.com (Dennis Ordanov) Date: Mon, 16 Feb 2009 21:30:06 -0800 Subject: [rsyslog] rsyslog eating FDs stops logging locally or remotely and eventually dies Message-ID: Hello Everyone, I use syslog to log locally and remotely via stunnel which is bound to the loopback address. It seems syslog will steadily use up FDs until it runs into the per process limit on my oBSD boxes and then either stops logging locally or forwarding traffic to stunnel, I don't know if this is a problem with stunnel or syslog or how to tell, but something is causing it to open a new file descriptor or unable to re-use another one or something...? I can just restart syslogd with a cron job weekly and increase the file descriptor limit, but that's not really a path I want to go down if I don't have to. If you think it will be useful to run syslogd in debug mode, but it can take a week for this problem to occur... I have 4 hypothesis of why this might be hapening: 1) syslog's interaction with stunnel is causing it to just to use more and more FDs 2) regarding #1, if there is a problem with stunnel accepting connections or being too overloaded or not being able to connect to the remote stunnel gateway then maybe its not accepting new conns to it or something? 3) something with myconfiguration is instigating this behaviour...? 4) none of the above Here is a box that will soon be in a broken state: root at hostname# /usr/sbin/syslogd -v rsyslogd 1.12.2, compiled with: FEATURE_REGEXP FEATURE_LARGEFILE SYSLOG_INET (Internet/remote support) root at hostname# uname -a OpenBSD hostname 4.1 GENERIC#1435 i386 # ulimit -a time(cpu-seconds) unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes) 8192 lockedmem(kbytes) 153844 memory(kbytes) 460268 nofiles(descriptors) 128 processes 532 I am running ktrace on this pid until I see it use another file descriptor being used by this process, right now at 109 it looks like. Come to think of it maybe I should be tracing stunnel too? root at host# fstat -n |grep syslog USER CMD PID FD MOUNT INUM MODE R/W DV|SZ root syslogd 20085 wd 0,0 2 40755 r 512 root syslogd 20085 0* unix dgram 0xd14f6a00 root syslogd 20085 1* internet stream tcp root syslogd 20085 2* internet stream tcp root syslogd 20085 3* internet stream tcp root syslogd 20085 4* internet stream tcp root syslogd 20085 5* internet stream tcp root syslogd 20085 6* internet stream tcp root syslogd 20085 7* internet stream tcp root syslogd 20085 8* internet stream tcp root syslogd 20085 9* internet stream tcp root syslogd 20085 10* internet stream tcp root syslogd 20085 11* internet stream tcp root syslogd 20085 12* internet stream tcp root syslogd 20085 13* internet stream tcp root syslogd 20085 14* internet stream tcp root syslogd 20085 15* internet stream tcp root syslogd 20085 16* unix dgram 0xd14048c0 root syslogd 20085 17* internet dgram udp *:514 root syslogd 20085 18* internet stream tcp root syslogd 20085 19* internet stream tcp root syslogd 20085 20* internet stream tcp root syslogd 20085 21* internet stream tcp root syslogd 20085 22* internet stream tcp root syslogd 20085 23* internet stream tcp root syslogd 20085 24* internet stream tcp root syslogd 20085 25* internet stream tcp root syslogd 20085 26* internet stream tcp root syslogd 20085 27* internet stream tcp root syslogd 20085 28* internet stream tcp root syslogd 20085 29* internet stream tcp root syslogd 20085 30* internet stream tcp root syslogd 20085 31* internet stream tcp root syslogd 20085 32* internet stream tcp root syslogd 20085 33* internet stream tcp root syslogd 20085 34* internet stream tcp root syslogd 20085 35* internet stream tcp root syslogd 20085 36* internet stream tcp root syslogd 20085 37* internet stream tcp root syslogd 20085 38* internet stream tcp root syslogd 20085 39* internet stream tcp root syslogd 20085 40* internet stream tcp root syslogd 20085 41* internet stream tcp root syslogd 20085 42* internet stream tcp root syslogd 20085 43* internet stream tcp root syslogd 20085 44* internet stream tcp root syslogd 20085 45* internet stream tcp root syslogd 20085 46* internet stream tcp root syslogd 20085 47* internet stream tcp root syslogd 20085 48* internet stream tcp root syslogd 20085 49* internet stream tcp root syslogd 20085 50* internet stream tcp root syslogd 20085 51* internet stream tcp root syslogd 20085 52* internet stream tcp root syslogd 20085 53* internet stream tcp root syslogd 20085 54* internet stream tcp root syslogd 20085 55* internet stream tcp root syslogd 20085 56* internet stream tcp root syslogd 20085 57* internet stream tcp root syslogd 20085 58* internet stream tcp root syslogd 20085 59* internet stream tcp root syslogd 20085 60* internet stream tcp 0xd6906648 127.0.0.1:4392 --> 127.0.0.1:5140 root syslogd 20085 61* internet stream tcp root syslogd 20085 62* internet stream tcp root syslogd 20085 63 0,4 844952 100644 w 81695 root syslogd 20085 64* internet stream tcp root syslogd 20085 65* internet stream tcp root syslogd 20085 66 0,4 844952 100644 w 81695 root syslogd 20085 67* internet stream tcp root syslogd 20085 68* internet stream tcp root syslogd 20085 69 0,4 844984 100644 w 73 root syslogd 20085 70* internet stream tcp root syslogd 20085 71* internet stream tcp root syslogd 20085 72 0,4 844984 100644 w 73 root syslogd 20085 73* internet stream tcp root syslogd 20085 74* internet stream tcp root syslogd 20085 75* internet stream tcp root syslogd 20085 76 0,4 844984 100644 w 73 root syslogd 20085 77* internet stream tcp root syslogd 20085 78* internet stream tcp root syslogd 20085 79* internet stream tcp root syslogd 20085 80 0,4 844969 100644 w 3437673 root syslogd 20085 81* internet stream tcp root syslogd 20085 82* internet stream tcp root syslogd 20085 83 0,4 844976 100644 w 442 root syslogd 20085 84* internet stream tcp root syslogd 20085 85* internet stream tcp root syslogd 20085 86 0,4 844976 100644 w 442 root syslogd 20085 87* internet stream tcp root syslogd 20085 88* internet stream tcp root syslogd 20085 89 0,4 844930 100640 w 18747 root syslogd 20085 90* internet stream tcp root syslogd 20085 91* internet stream tcp root syslogd 20085 92 0,4 844936 100600 w 74 root syslogd 20085 93* internet stream tcp root syslogd 20085 94* internet stream tcp root syslogd 20085 95 0,4 2328711 100600 w 46522 root syslogd 20085 96* internet stream tcp root syslogd 20085 97* internet stream tcp root syslogd 20085 98 0,4 844972 100640 w 476 root syslogd 20085 99* internet stream tcp root syslogd 20085 100* internet stream tcp root syslogd 20085 101 0,4 844941 100640 w 0 root syslogd 20085 102* internet stream tcp root syslogd 20085 103* internet stream tcp root syslogd 20085 104 0,4 844935 100640 w 0 root syslogd 20085 105* internet stream tcp root syslogd 20085 106* internet stream tcp root syslogd 20085 107 0,4 844931 100600 w 74 root syslogd 20085 108* internet stream tcp 0xd694c7d4 127.0.0.1:19723 --> 127.0.0.1:5140 root syslogd 20085 109* internet stream tcp 0xd694c964 127.0.0.1:42849 --> 127.0.0.1:5140 root at host# netstat -an Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 32 172.20.20.51.22 remote.63117 ESTABLISHED tcp 0 0 172.20.20.51.38090 remote.443 ESTABLISHED tcp 0 0 127.0.0.1.5140 127.0.0.1.42849 ESTABLISHED tcp 0 0 127.0.0.1.42849 127.0.0.1.5140 ESTABLISHED tcp 0 0 172.20.20.51.19898 remote.443 ESTABLISHED tcp 0 0 127.0.0.1.5140 127.0.0.1.19723 ESTABLISHED tcp 0 0 127.0.0.1.19723 127.0.0.1.5140 ESTABLISHED tcp 0 0 172.20.20.51.5494 remote.443 ESTABLISHED tcp 0 0 127.0.0.1.5140 127.0.0.1.4392 ESTABLISHED tcp 0 0 127.0.0.1.4392 127.0.0.1.5140 ESTABLISHED tcp 0 0 *.22 *.* LISTEN tcp 0 0 127.0.0.1.5140 *.* LISTEN tcp 0 0 127.0.0.1.587 *.* LISTEN tcp 0 0 127.0.0.1.25 *.* LISTEN tcp 0 0 *.37 *.* LISTEN tcp 0 0 *.13 *.* LISTEN tcp 0 0 *.113 *.* LISTEN Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 172.20.20.51.2947 172.20.20.92.123 udp 0 0 172.20.20.51.12927 172.20.20.91.123 udp 0 0 *.514 *.* udp 0 0 10.144.73.23.123 *.* udp 0 0 10.144.73.21.123 *.* udp 0 0 172.20.20.51.123 *.* udp 0 0 127.0.0.1.123 *.* udp 0 0 127.0.0.1.512 *.* root at host# fstat|grep stunnel USER CMD PID FD MOUNT INUM MODE R/W DV|SZ _stunnel stunnel 32055 root /var 6141184 drwxr-xr-x r 512 _stunnel stunnel 32055 wd /var 6141184 drwxr-xr-x r 512 _stunnel stunnel 32055 0 / 166117 crw-rw-rw- rw null _stunnel stunnel 32055 1 / 166117 crw-rw-rw- rw null _stunnel stunnel 32055 2 / 166117 crw-rw-rw- rw null _stunnel stunnel 32055 3 pipe 0xe9505e10 state: _stunnel stunnel 32055 4 pipe 0xe9505e10 state: _stunnel stunnel 32055 5 / 165853 crw-rw-rw- rw crypto _stunnel stunnel 32055 6* internet stream tcp 0xd6906e18 127.0.0.1:5140 <-- 127.0.0.1:4392 _stunnel stunnel 32055 7 pipe 0xe95057e0 state: _stunnel stunnel 32055 8 pipe 0xe95057e0 state: _stunnel stunnel 32055 9* internet stream tcp 0xd694cc84 127.0.0.1:5140 _stunnel stunnel 32055 10* internet stream tcp 0xd694c644 172.20.20.51:5494 --> remote:443 _stunnel stunnel 32055 11* internet stream tcp 0xd694c4b4 127.0.0.1:5140 <-- 127.0.0.1:19723 _stunnel stunnel 32055 12* internet stream tcp 0xd694ce14 172.20.20.51:19898 --> remote:443 _stunnel stunnel 32055 13* internet stream tcp 0xd694caf4 127.0.0.1:5140 <-- 127.0.0.1:42849 _stunnel stunnel 32055 14* internet stream tcp 0xd68cb19c 172.20.20.51:38090 --> remote:443 # ulimit -a time(cpu-seconds) unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes) 8192 lockedmem(kbytes) 153844 memory(kbytes) 460268 nofiles(descriptors) 128 processes 532 root at hostname# /usr/sbin/syslogd -v rsyslogd 1.12.2, compiled with: FEATURE_REGEXP FEATURE_LARGEFILE SYSLOG_INET (Internet/remote support) root at hostname# uname -a OpenBSD hostname 4.1 GENERIC#1435 i386 Here is how its getting started out of rc: syslogd_flags="-h -i /var/run/syslog.pid -m 0 -r 514" # flags for rsyslogd Process Entries: # ps -axwww|egrep '[s]yslog|[s]tunnel' 32055 ?? Is 2:22.48 /usr/local/sbin/stunnel 20085 ?? Is 4:50.88 syslogd -h -i /var/run/syslog.pid -m 0 -r 514 -a /var/empty/dev/log Here is the config: /etc/rsyslog.conf # Template to include time received by the Admin Server when forwarded to the Data Center. # Juniper Messages are not passed with a timestamp. $template MissingDate,"<%PRI%>%timegenerated% %HOSTNAME% %syslogtag%%msg%" # Template to remove the syslog tag "root:" for the heartbeat and checks when forwarded to the Data Center. $template NoSyslogTag,"<%PRI%>%timegenerated% %HOSTNAME% %msg%" # Template to allow for easier reading of the Cisco logs. # Include a text designation for the type of Cisco equipment. # Start the message at position at offset 19 to strip out time stamp. $template CiscoSW1,"%TIMESTAMP% %HOSTNAME% Switch1: %msg:19:500:drop-last-lf%\n" $template CiscoSW2,"%TIMESTAMP% %HOSTNAME% Switch2: %msg:19:500:drop-last-lf%\n" $template CiscoTS1,"%TIMESTAMP% %HOSTNAME% Term1: %msg:19:500:drop-last-lf%\n" # Forward messages from the admin server heartbeat and checks based on message id :msg, contains, "NHB10001:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10002:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10003:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10004:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10005:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10006:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10007:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10008:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10009:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10011:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10012:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10015:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10016:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10017:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CLP10020:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CLP10021:" @@127.0.0.1:5140;NoSyslogTag # Forward messages from juniper nodes basd on message id :msg, contains, "ADM10310:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM20255:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM20928:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM22798:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM23046:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM24336:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM24337:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC22051:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC23037:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC23038:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC23039:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT10301:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT21060:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT21089:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT22677:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT22678:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT22696:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT23391:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT23551:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT23552:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT24080:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT24417:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT24418:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20146:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20147:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20148:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20149:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20150:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20151:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20152:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20153:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20154:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20155:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20643:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20644:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20645:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR24016:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR24019:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR24076:" @@127.0.0.1:5140;MissingDate :msg, contains, "LIC10200:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10062:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10087:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10088:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10089:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10090:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10091:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10092:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10093:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10094:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10298:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10299:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10314:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS23041:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS23402:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS23409:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24015:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24020:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24316:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24317:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24348:" @@127.0.0.1:5140;MissingDate # Forward messages from F5 nodes based on lb hostnames :HOSTNAME, contains, "lb1-" @@127.0.0.1:5140 :HOSTNAME, contains, "lb2-" @@127.0.0.1:5140 # Log F5 messages locally for archival purposes based on lb hostnames :HOSTNAME, contains, "lb1-" /var/log/f5.log :HOSTNAME, contains, "lb2-" /var/log/f5.log # Log Cisco messages locally for archival purposes based on ip hostnames :HOSTNAME, contains, "172.20.20.101" /var/log/cisco.log :HOSTNAME, contains, "172.20.20.102" /var/log/cisco.log :HOSTNAME, contains, "172.20.20.227" /var/log/cisco.log # Discard lb1/2 and cisco messages from further processing :HOSTNAME, contains, "lb1-" ~ :HOSTNAME, contains, "lb2-" ~ :HOSTNAME, contains, "172.20.20.101" ~ :HOSTNAME, contains, "172.20.20.102" ~ :HOSTNAME, contains, "172.20.20.227" ~ # Log local7 messages locally for archival purposes local7.* /var/log/local7.log *.notice;\ auth,authpriv,cron,ftp,kern,lpr,mail,user,local7.none /var/log/messages kern.debug;syslog,user.info /var/log/messages auth.info /var/log/authlog authpriv.debug /var/log/secure cron.info /var/cron/log daemon.info /var/log/daemon ftp.info /var/log/xferlog lpr.debug /var/log/lpd-errs mail.info /var/log/maillog #uucp.info /var/log/uucp # Everyone gets emergency messages. *.emerg I've tried to look on the net for anything that had to do with syslog and file descriptors and or how these problems happen and coming out with pretty much squat.. Thank you, Dennis O. From rgerhards at hq.adiscon.com Tue Feb 17 07:18:14 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 17 Feb 2009 07:18:14 +0100 Subject: [rsyslog] rsyslog eating FDs stops logging locally or remotely andeventually dies In-Reply-To: References: Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC10@grfint2.intern.adiscon.com> Hi Dennis, First thing I would upgrade to a recent release, either v2-stable or v3-stable. The version you are using is heavily outdated and looking into the issue with that version simply makes no sense. Plus, I think chances are good the problem will disappear with the new versions. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Dennis Ordanov > Sent: Tuesday, February 17, 2009 6:30 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] rsyslog eating FDs stops logging locally > or remotely andeventually dies > > Hello Everyone, > > I use syslog to log locally and remotely via stunnel which is bound to > the loopback address. It seems syslog will steadily use up FDs until > it runs into the per process limit on my oBSD boxes and then either > stops logging locally or forwarding traffic to stunnel, I don't know > if this is a problem with stunnel or syslog or how to tell, but > something is causing it to open a new file descriptor or unable to > re-use another one or something...? > > > I can just restart syslogd with a cron job weekly and increase the > file descriptor limit, but that's not really a path I want to go down > if I don't have to. > > If you think it will be useful to run syslogd in debug mode, but it > can take a week for this problem to occur... > > I have 4 hypothesis of why this might be hapening: > 1) syslog's interaction with stunnel is causing it to just to use more > and more FDs > 2) regarding #1, if there is a problem with stunnel accepting > connections or being too overloaded or not being able to connect to > the remote stunnel gateway then maybe its not accepting new conns to > it or something? > 3) something with myconfiguration is instigating this behaviour...? > 4) none of the above > > Here is a box that will soon be in a broken state: > > root at hostname# /usr/sbin/syslogd -v > rsyslogd 1.12.2, compiled with: > FEATURE_REGEXP > FEATURE_LARGEFILE > SYSLOG_INET (Internet/remote support) > root at hostname# uname -a > OpenBSD hostname 4.1 GENERIC#1435 i386 > > # ulimit -a > time(cpu-seconds) unlimited > file(blocks) unlimited > coredump(blocks) unlimited > data(kbytes) 1048576 > stack(kbytes) 8192 > lockedmem(kbytes) 153844 > memory(kbytes) 460268 > nofiles(descriptors) 128 > processes 532 > > I am running ktrace on this pid until I see it use another file > descriptor being used by this process, right now at 109 it looks like. > Come to think of it maybe I should be tracing stunnel too? > > root at host# fstat -n |grep syslog > USER CMD PID FD MOUNT INUM MODE > R/W DV|SZ > root syslogd 20085 wd 0,0 2 40755 r 512 > root syslogd 20085 0* unix dgram 0xd14f6a00 > root syslogd 20085 1* internet stream tcp > root syslogd 20085 2* internet stream tcp > root syslogd 20085 3* internet stream tcp > root syslogd 20085 4* internet stream tcp > root syslogd 20085 5* internet stream tcp > root syslogd 20085 6* internet stream tcp > root syslogd 20085 7* internet stream tcp > root syslogd 20085 8* internet stream tcp > root syslogd 20085 9* internet stream tcp > root syslogd 20085 10* internet stream tcp > root syslogd 20085 11* internet stream tcp > root syslogd 20085 12* internet stream tcp > root syslogd 20085 13* internet stream tcp > root syslogd 20085 14* internet stream tcp > root syslogd 20085 15* internet stream tcp > root syslogd 20085 16* unix dgram 0xd14048c0 > root syslogd 20085 17* internet dgram udp *:514 > root syslogd 20085 18* internet stream tcp > root syslogd 20085 19* internet stream tcp > root syslogd 20085 20* internet stream tcp > root syslogd 20085 21* internet stream tcp > root syslogd 20085 22* internet stream tcp > root syslogd 20085 23* internet stream tcp > root syslogd 20085 24* internet stream tcp > root syslogd 20085 25* internet stream tcp > root syslogd 20085 26* internet stream tcp > root syslogd 20085 27* internet stream tcp > root syslogd 20085 28* internet stream tcp > root syslogd 20085 29* internet stream tcp > root syslogd 20085 30* internet stream tcp > root syslogd 20085 31* internet stream tcp > root syslogd 20085 32* internet stream tcp > root syslogd 20085 33* internet stream tcp > root syslogd 20085 34* internet stream tcp > root syslogd 20085 35* internet stream tcp > root syslogd 20085 36* internet stream tcp > root syslogd 20085 37* internet stream tcp > root syslogd 20085 38* internet stream tcp > root syslogd 20085 39* internet stream tcp > root syslogd 20085 40* internet stream tcp > root syslogd 20085 41* internet stream tcp > root syslogd 20085 42* internet stream tcp > root syslogd 20085 43* internet stream tcp > root syslogd 20085 44* internet stream tcp > root syslogd 20085 45* internet stream tcp > root syslogd 20085 46* internet stream tcp > root syslogd 20085 47* internet stream tcp > root syslogd 20085 48* internet stream tcp > root syslogd 20085 49* internet stream tcp > root syslogd 20085 50* internet stream tcp > root syslogd 20085 51* internet stream tcp > root syslogd 20085 52* internet stream tcp > root syslogd 20085 53* internet stream tcp > root syslogd 20085 54* internet stream tcp > root syslogd 20085 55* internet stream tcp > root syslogd 20085 56* internet stream tcp > root syslogd 20085 57* internet stream tcp > root syslogd 20085 58* internet stream tcp > root syslogd 20085 59* internet stream tcp > root syslogd 20085 60* internet stream tcp 0xd6906648 > 127.0.0.1:4392 --> 127.0.0.1:5140 > root syslogd 20085 61* internet stream tcp > root syslogd 20085 62* internet stream tcp > root syslogd 20085 63 0,4 844952 100644 w 81695 > root syslogd 20085 64* internet stream tcp > root syslogd 20085 65* internet stream tcp > root syslogd 20085 66 0,4 844952 100644 w 81695 > root syslogd 20085 67* internet stream tcp > root syslogd 20085 68* internet stream tcp > root syslogd 20085 69 0,4 844984 100644 w 73 > root syslogd 20085 70* internet stream tcp > root syslogd 20085 71* internet stream tcp > root syslogd 20085 72 0,4 844984 100644 w 73 > root syslogd 20085 73* internet stream tcp > root syslogd 20085 74* internet stream tcp > root syslogd 20085 75* internet stream tcp > root syslogd 20085 76 0,4 844984 100644 w 73 > root syslogd 20085 77* internet stream tcp > root syslogd 20085 78* internet stream tcp > root syslogd 20085 79* internet stream tcp > root syslogd 20085 80 0,4 844969 100644 w 3437673 > root syslogd 20085 81* internet stream tcp > root syslogd 20085 82* internet stream tcp > root syslogd 20085 83 0,4 844976 100644 w 442 > root syslogd 20085 84* internet stream tcp > root syslogd 20085 85* internet stream tcp > root syslogd 20085 86 0,4 844976 100644 w 442 > root syslogd 20085 87* internet stream tcp > root syslogd 20085 88* internet stream tcp > root syslogd 20085 89 0,4 844930 100640 w 18747 > root syslogd 20085 90* internet stream tcp > root syslogd 20085 91* internet stream tcp > root syslogd 20085 92 0,4 844936 100600 w 74 > root syslogd 20085 93* internet stream tcp > root syslogd 20085 94* internet stream tcp > root syslogd 20085 95 0,4 2328711 100600 w 46522 > root syslogd 20085 96* internet stream tcp > root syslogd 20085 97* internet stream tcp > root syslogd 20085 98 0,4 844972 100640 w 476 > root syslogd 20085 99* internet stream tcp > root syslogd 20085 100* internet stream tcp > root syslogd 20085 101 0,4 844941 100640 w 0 > root syslogd 20085 102* internet stream tcp > root syslogd 20085 103* internet stream tcp > root syslogd 20085 104 0,4 844935 100640 w 0 > root syslogd 20085 105* internet stream tcp > root syslogd 20085 106* internet stream tcp > root syslogd 20085 107 0,4 844931 100600 w 74 > root syslogd 20085 108* internet stream tcp 0xd694c7d4 > 127.0.0.1:19723 --> 127.0.0.1:5140 > root syslogd 20085 109* internet stream tcp 0xd694c964 > 127.0.0.1:42849 --> 127.0.0.1:5140 > > > root at host# netstat -an > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address > (state) > tcp 0 32 172.20.20.51.22 remote.63117 > ESTABLISHED > tcp 0 0 172.20.20.51.38090 remote.443 > ESTABLISHED > tcp 0 0 127.0.0.1.5140 127.0.0.1.42849 > ESTABLISHED > tcp 0 0 127.0.0.1.42849 127.0.0.1.5140 > ESTABLISHED > tcp 0 0 172.20.20.51.19898 remote.443 > ESTABLISHED > tcp 0 0 127.0.0.1.5140 127.0.0.1.19723 > ESTABLISHED > tcp 0 0 127.0.0.1.19723 127.0.0.1.5140 > ESTABLISHED > tcp 0 0 172.20.20.51.5494 remote.443 > ESTABLISHED > tcp 0 0 127.0.0.1.5140 127.0.0.1.4392 > ESTABLISHED > tcp 0 0 127.0.0.1.4392 127.0.0.1.5140 > ESTABLISHED > tcp 0 0 *.22 *.* > LISTEN > tcp 0 0 127.0.0.1.5140 *.* > LISTEN > tcp 0 0 127.0.0.1.587 *.* > LISTEN > tcp 0 0 127.0.0.1.25 *.* > LISTEN > tcp 0 0 *.37 *.* > LISTEN > tcp 0 0 *.13 *.* > LISTEN > tcp 0 0 *.113 *.* > LISTEN > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address > (state) > udp 0 0 172.20.20.51.2947 172.20.20.92.123 > udp 0 0 172.20.20.51.12927 172.20.20.91.123 > udp 0 0 *.514 *.* > udp 0 0 10.144.73.23.123 *.* > udp 0 0 10.144.73.21.123 *.* > udp 0 0 172.20.20.51.123 *.* > udp 0 0 127.0.0.1.123 *.* > udp 0 0 127.0.0.1.512 *.* > > > root at host# fstat|grep stunnel > USER CMD PID FD MOUNT INUM MODE > R/W DV|SZ > _stunnel stunnel 32055 root /var 6141184 drwxr-xr-x > r 512 > _stunnel stunnel 32055 wd /var 6141184 drwxr-xr-x > r 512 > _stunnel stunnel 32055 0 / 166117 crw-rw-rw- > rw null > _stunnel stunnel 32055 1 / 166117 crw-rw-rw- > rw null > _stunnel stunnel 32055 2 / 166117 crw-rw-rw- > rw null > _stunnel stunnel 32055 3 pipe 0xe9505e10 state: > _stunnel stunnel 32055 4 pipe 0xe9505e10 state: > _stunnel stunnel 32055 5 / 165853 crw-rw-rw- > rw crypto > _stunnel stunnel 32055 6* internet stream tcp 0xd6906e18 > 127.0.0.1:5140 <-- 127.0.0.1:4392 > _stunnel stunnel 32055 7 pipe 0xe95057e0 state: > _stunnel stunnel 32055 8 pipe 0xe95057e0 state: > _stunnel stunnel 32055 9* internet stream tcp > 0xd694cc84 127.0.0.1:5140 > _stunnel stunnel 32055 10* internet stream tcp 0xd694c644 > 172.20.20.51:5494 --> remote:443 > _stunnel stunnel 32055 11* internet stream tcp 0xd694c4b4 > 127.0.0.1:5140 <-- 127.0.0.1:19723 > _stunnel stunnel 32055 12* internet stream tcp 0xd694ce14 > 172.20.20.51:19898 --> remote:443 > _stunnel stunnel 32055 13* internet stream tcp 0xd694caf4 > 127.0.0.1:5140 <-- 127.0.0.1:42849 > _stunnel stunnel 32055 14* internet stream tcp 0xd68cb19c > 172.20.20.51:38090 --> remote:443 > > # ulimit -a > time(cpu-seconds) unlimited > file(blocks) unlimited > coredump(blocks) unlimited > data(kbytes) 1048576 > stack(kbytes) 8192 > lockedmem(kbytes) 153844 > memory(kbytes) 460268 > nofiles(descriptors) 128 > processes 532 > > root at hostname# /usr/sbin/syslogd -v > rsyslogd 1.12.2, compiled with: > FEATURE_REGEXP > FEATURE_LARGEFILE > SYSLOG_INET (Internet/remote support) > root at hostname# uname -a > OpenBSD hostname 4.1 GENERIC#1435 i386 > > Here is how its getting started out of rc: > > syslogd_flags="-h -i /var/run/syslog.pid -m 0 -r 514" # > flags for rsyslogd > > Process Entries: > # ps -axwww|egrep '[s]yslog|[s]tunnel' > 32055 ?? Is 2:22.48 /usr/local/sbin/stunnel > 20085 ?? Is 4:50.88 syslogd -h -i /var/run/syslog.pid -m 0 -r > 514 -a /var/empty/dev/log > > Here is the config: > > /etc/rsyslog.conf > # Template to include time received by the Admin Server when forwarded > to the Data Center. > # Juniper Messages are not passed with a timestamp. > > $template MissingDate,"<%PRI%>%timegenerated% %HOSTNAME% > %syslogtag%%msg%" > > # Template to remove the syslog tag "root:" for the heartbeat and > checks when forwarded to the Data Center. > > $template NoSyslogTag,"<%PRI%>%timegenerated% %HOSTNAME% %msg%" > > # Template to allow for easier reading of the Cisco logs. > # Include a text designation for the type of Cisco equipment. > # Start the message at position at offset 19 to strip out time stamp. > > $template CiscoSW1,"%TIMESTAMP% %HOSTNAME% Switch1: > %msg:19:500:drop-last-lf%\n" > $template CiscoSW2,"%TIMESTAMP% %HOSTNAME% Switch2: > %msg:19:500:drop-last-lf%\n" > $template CiscoTS1,"%TIMESTAMP% %HOSTNAME% Term1: > %msg:19:500:drop-last-lf%\n" > > # Forward messages from the admin server heartbeat and checks based on > message id > :msg, contains, "NHB10001:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10002:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10003:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10004:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10005:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10006:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10007:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10008:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10009:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10011:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10012:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10015:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10016:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10017:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CLP10020:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CLP10021:" > @@127.0.0.1:5140;NoSyslogTag > > # Forward messages from juniper nodes basd on message id > :msg, contains, "ADM10310:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM20255:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM20928:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM22798:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM23046:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM24336:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM24337:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC22051:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC23037:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC23038:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC23039:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT10301:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT21060:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT21089:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT22677:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT22678:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT22696:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT23391:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT23551:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT23552:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT24080:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT24417:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT24418:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20146:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20147:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20148:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20149:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20150:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20151:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20152:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20153:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20154:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20155:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20643:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20644:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20645:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR24016:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR24019:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR24076:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "LIC10200:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10062:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10087:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10088:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10089:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10090:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10091:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10092:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10093:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10094:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10298:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10299:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10314:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS23041:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS23402:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS23409:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24015:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24020:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24316:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24317:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24348:" > @@127.0.0.1:5140;MissingDate > > # Forward messages from F5 nodes based on lb hostnames > :HOSTNAME, contains, "lb1-" > @@127.0.0.1:5140 > :HOSTNAME, contains, "lb2-" > @@127.0.0.1:5140 > > # Log F5 messages locally for archival purposes based on lb hostnames > :HOSTNAME, contains, "lb1-" > /var/log/f5.log > :HOSTNAME, contains, "lb2-" > /var/log/f5.log > > # Log Cisco messages locally for archival purposes based on > ip hostnames > :HOSTNAME, contains, "172.20.20.101" > /var/log/cisco.log > :HOSTNAME, contains, "172.20.20.102" > /var/log/cisco.log > :HOSTNAME, contains, "172.20.20.227" > /var/log/cisco.log > > # Discard lb1/2 and cisco messages from further processing > :HOSTNAME, contains, "lb1-" ~ > :HOSTNAME, contains, "lb2-" ~ > :HOSTNAME, contains, "172.20.20.101" ~ > :HOSTNAME, contains, "172.20.20.102" ~ > :HOSTNAME, contains, "172.20.20.227" ~ > > # Log local7 messages locally for archival purposes > local7.* > /var/log/local7.log > > *.notice;\ > auth,authpriv,cron,ftp,kern,lpr,mail,user,local7.none > /var/log/messages > kern.debug;syslog,user.info > /var/log/messages > auth.info > /var/log/authlog > authpriv.debug > /var/log/secure > cron.info /var/cron/log > daemon.info > /var/log/daemon > ftp.info > /var/log/xferlog > lpr.debug > /var/log/lpd-errs > mail.info > /var/log/maillog > #uucp.info /var/log/uucp > > # Everyone gets emergency messages. > *.emerg > > I've tried to look on the net for anything that had to do with syslog > and file descriptors and or how these problems happen and coming out > with pretty much squat.. > > Thank you, > Dennis O. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From daodennis at gmail.com Tue Feb 17 08:23:05 2009 From: daodennis at gmail.com (Dennis Ordanov) Date: Mon, 16 Feb 2009 23:23:05 -0800 Subject: [rsyslog] rsyslog eating FDs stops logging locally or remotely andeventually dies In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC10@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC10@grfint2.intern.adiscon.com> Message-ID: On Mon, Feb 16, 2009 at 10:18 PM, Rainer Gerhards wrote: > Hi Dennis, > > First thing I would upgrade to a recent release, either v2-stable or > v3-stable. The version you are using is heavily outdated and looking > into the issue with that version simply makes no sense. Plus, I think > chances are good the problem will disappear with the new versions. > Thanks Rainer! I I will look into doing that, if not upgrading OBSD period to something other than 3.8/4.1 (observed on both) for these group of servers (and all the testing that goes along with it...) Thanks, Dennis O. > Rainer > From rgerhards at hq.adiscon.com Tue Feb 17 09:17:53 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 17 Feb 2009 09:17:53 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com><49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> Hi RB, Consider this a persuasion attempt ;) One thing, though is how to make those things easily acessible. Can we (you? ;)) get it pushed to something like EPEL, or are there other places or would it be sufficient to include some packages on rsyslog.com (made inside a specially created part of the git tree, too). How is this usually done? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of RB > Sent: Monday, February 16, 2009 11:49 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of > sending devices? > > On Mon, Feb 16, 2009 at 02:25, David Ecker > wrote: > > have you tried to contact the epel group? > > > > http://fedoraproject.org/wiki/EPEL > > > > They should be able to include an upgrade for rsyslog into their > > repository for REL5 if you ask them. > > Failing that, I already wrote one spec for rsyslog-3.x under CentOS-5 > and could be pretty easily persuaded to do so again. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Feb 17 14:46:50 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 17 Feb 2009 14:46:50 +0100 Subject: [rsyslog] Advise Requested - most important features Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Hi all, I have the chance to write an article about rsyslog for one of the largest German *nix magazines. It shall be an overview over rsyslog. I would like to highlight some features. So which ones do you think are most important for *ordinary* users? Feedback is most welcome and my deadline is tight (as usual ;)). I think this is an excellent opportunity to present rsyslog to a wider audience, one that that should be done as well as possible ;) Rainer From kenneho.ndu at gmail.com Tue Feb 17 15:08:06 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Tue, 17 Feb 2009 15:08:06 +0100 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: Well, I believe local spooling of syslog messages is quite neat. On 2/17/09, Rainer Gerhards wrote: > > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Feedback is most welcome and my > deadline is tight (as usual ;)). > > I think this is an excellent opportunity to present rsyslog to a wider > audience, one that that should be done as well as possible ;) > > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From mbiebl at gmail.com Tue Feb 17 15:19:59 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Tue, 17 Feb 2009 15:19:59 +0100 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: 2009/2/17 Rainer Gerhards : > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Feedback is most welcome and my > deadline is tight (as usual ;)). I think TLS support is pretty cool, db output support probably too. Generally the whole "reliable logging", with on-disk queues, relp etc. is what set's it apart from sysklogd, but definitely a more "advanced" feature that probably not every ordinary user needs. Ordinary users might be interested in the advanced filtering mechanisms, support for "~", templating etc. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From mrdemeanour at jackpot.uk.net Tue Feb 17 15:22:35 2009 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Tue, 17 Feb 2009 14:22:35 +0000 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <499AC82B.9010508@jackpot.uk.net> Rainer Gerhards wrote: > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. > I would like to highlight some features. So which ones do you think > are most important for *ordinary* users? Feedback is most welcome and > my deadline is tight (as usual ;)). > > I think this is an excellent opportunity to present rsyslog to a > wider audience, one that that should be done as well as possible ;) Fantastic support. But I don't know how you do that, when it's you doing the support and you writing the article. Perhaps you need a ghost-writer? -- Jack. From hks.private at gmail.com Tue Feb 17 15:45:59 2009 From: hks.private at gmail.com ((private) HKS) Date: Tue, 17 Feb 2009 09:45:59 -0500 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: On Tue, Feb 17, 2009 at 8:46 AM, Rainer Gerhards wrote: > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Feedback is most welcome and my > deadline is tight (as usual ;)). > > I think this is an excellent opportunity to present rsyslog to a wider > audience, one that that should be done as well as possible ;) > > Rainer For my usage, the greatest benefits are: From hks.private at gmail.com Tue Feb 17 15:49:08 2009 From: hks.private at gmail.com ((private) HKS) Date: Tue, 17 Feb 2009 09:49:08 -0500 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: On Tue, Feb 17, 2009 at 9:45 AM, (private) HKS wrote: > On Tue, Feb 17, 2009 at 8:46 AM, Rainer Gerhards > wrote: >> Hi all, >> >> I have the chance to write an article about rsyslog for one of the >> largest German *nix magazines. It shall be an overview over rsyslog. I >> would like to highlight some features. So which ones do you think are >> most important for *ordinary* users? Feedback is most welcome and my >> deadline is tight (as usual ;)). >> >> I think this is an excellent opportunity to present rsyslog to a wider >> audience, one that that should be done as well as possible ;) >> >> Rainer > > > For my usage, the greatest benefits are: ...not hitting the send button when I forget that tab doesn't work in Gmail like it does in vi. *ahem* - Reliable delivery (TCP/RELP, spooling of undeliverable messages) - Templates (both for reformatting log messages and for dynamic filenames) - Flexible filtering options - Intuitive configuration for someone already familiar with BSD syslog -HKS From danson at rackspace.com Tue Feb 17 16:19:55 2009 From: danson at rackspace.com (Daniel Anson) Date: Tue, 17 Feb 2009 09:19:55 -0600 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <1509_1234884068_n1HFL0eO003870_96AF20FDF4301D419B33CCE8E3A0132B0B41CC11@SAT4MX07.RACKSPACE.CORP> The disk based queue is IMHO the best feature. I use the database plug-in as well but common users may not use that feature as much. It's simple replacement for the stock syslogd and extended timestamp are useful as well. -Daniel Anson -Rackspace Managed Hosting -Linux Systems Engineer III -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards Sent: Tuesday, February 17, 2009 7:47 AM To: rsyslog-users Subject: [rsyslog] Advise Requested - most important features Hi all, I have the chance to write an article about rsyslog for one of the largest German *nix magazines. It shall be an overview over rsyslog. I would like to highlight some features. So which ones do you think are most important for *ordinary* users? Feedback is most welcome and my deadline is tight (as usual ;)). I think this is an excellent opportunity to present rsyslog to a wider audience, one that that should be done as well as possible ;) Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From aoz.syn at gmail.com Tue Feb 17 16:40:10 2009 From: aoz.syn at gmail.com (RB) Date: Tue, 17 Feb 2009 08:40:10 -0700 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <4255c2570902170740x3d235c46t2af8d5e2931e7cae@mail.gmail.com> On Tue, Feb 17, 2009 at 06:46, Rainer Gerhards wrote: > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Ordinary users: - drop-in syslogd replacement - database integration - templates - TLS Power users: - RELP - queues - template abuse - Heavy focus on RFC compliance - modular input/output (can't wait for that filter framework!) From aoz.syn at gmail.com Tue Feb 17 21:11:39 2009 From: aoz.syn at gmail.com (RB) Date: Tue, 17 Feb 2009 13:11:39 -0700 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> Message-ID: <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> On Tue, Feb 17, 2009 at 01:17, Rainer Gerhards wrote: > Hi RB, > > Consider this a persuasion attempt ;) > > One thing, though is how to make those things easily acessible. Can we > (you? ;)) get it pushed to something like EPEL, or are there other > places or would it be sufficient to include some packages on rsyslog.com > (made inside a specially created part of the git tree, too). How is this > usually done? A quick look upstream shows that Fedora is maintaining a _very_ current package (currently 3.21.10, updated 3 hours ago). The person (Tomas) that seems to have taken over the Fedora SPEC maintenance has an @redhat.com address, so they might be the right person to persuade to get a stable (3.20.4) package into EPEL. I'll ask and see what they say. That said, I haven't tested this yet, but generally speaking Fedora RPMs have worked reasonably well for me under CentOS as long as I'm current. Regardless, I'll take the flag and see what I can do to get a readily-accessible reasonably current build available for CentOS-5. From serbulent at pardus.org.tr Wed Feb 18 07:43:11 2009 From: serbulent at pardus.org.tr (Serbulent UNSAL) Date: Wed, 18 Feb 2009 08:43:11 +0200 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <200902180843.11948.serbulent@pardus.org.tr> On Tuesday 17 February 2009 15:46:50 Rainer Gerhards wrote: > I think this is an excellent opportunity to present rsyslog to a wider > audience, one that that should be done as well as possible ;) > > Rainer Flitering is my favorite... -- ?yi ?al??malar, Serb?lent From r.bhatia at ipax.at Wed Feb 18 09:51:50 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Wed, 18 Feb 2009 09:51:50 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at> <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Message-ID: <499BCC26.70605@ipax.at> hello rainer, Rainer Gerhards wrote: > Hi Raoul, > > I don't keep track of the bug in the older releases - simply too much > work, especially in this case. The best would be to use v3-stable from > git (I have not yet released a tarball as I'd like to get some feedback > from the field, first - not too often release stable versions..). just for the records - with rsyslog stable with git cs d742b251a6cdac02b235bd7459fa60890a0e6e i have not seen this issue until now. thanks! raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From rgerhards at hq.adiscon.com Wed Feb 18 09:56:03 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 18 Feb 2009 09:56:03 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <499BCC26.70605@ipax.at> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at><577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> <499BCC26.70605@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC45@grfint2.intern.adiscon.com> Hi Raoul, thanks for this feedback, much appreciated. And for everyone's information: after this patch, I did not get any new reports of any such abort, but got a number of messages which claim that the situation did no longer occur. David Lang, however, has experienced an issue during HUP processing, which I think is a different issue. So at least the situation has very much improved. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Wednesday, February 18, 2009 9:52 AM > To: rsyslog-users > Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: > double free or corruption (!prev): 0x0000000000ef03b0 *** > > hello rainer, > > Rainer Gerhards wrote: > > Hi Raoul, > > > > I don't keep track of the bug in the older releases - simply too much > > work, especially in this case. The best would be to use v3-stable > from > > git (I have not yet released a tarball as I'd like to get some > feedback > > from the field, first - not too often release stable versions..). > > just for the records - with rsyslog stable with git cs > d742b251a6cdac02b235bd7459fa60890a0e6e i have not seen this issue until > now. > > thanks! > raoul > -- > ____________________________________________________________________ > DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at > Technischer Leiter > > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at > Barawitzkagasse 10/2/2/11 email. office at ipax.at > 1190 Wien tel. +43 1 3670030 > FN 277995t HG Wien fax. +43 1 3670030 15 > ____________________________________________________________________ > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Wed Feb 18 13:23:14 2009 From: david at lang.hm (david at lang.hm) Date: Wed, 18 Feb 2009 04:23:14 -0800 (PST) Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC45@grfint2.intern.adiscon.com> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at><577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> <499BCC26.70605@ipax.at> <577465F99B41C842AAFBE9ED71E70ABA44FC45@grfint2.intern.adiscon.com> Message-ID: On Wed, 18 Feb 2009, Rainer Gerhards wrote: > Hi Raoul, > > thanks for this feedback, much appreciated. > > And for everyone's information: after this patch, I did not get any new > reports of any such abort, but got a number of messages which claim that > the situation did no longer occur. David Lang, however, has experienced > an issue during HUP processing, which I think is a different issue. I have been doing more stress testing and have not duplicated the problem in the last two weeks since I compltely removed the install and reinstalled it. I don't know why, but it is looking like when I install a new .deb on a system with rsyslog in it, it's not replacing all the files (specificly the input and output modules). I know that they are in the .deb becouse if I manually delete them they are installed with a new .deb, but if I don't manually remove them they don't get replaced. since the /debian directory was removed I'm using checkinstall to make the packages. David Lang > So at least the situation has very much improved. > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] >> Sent: Wednesday, February 18, 2009 9:52 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: >> double free or corruption (!prev): 0x0000000000ef03b0 *** >> >> hello rainer, >> >> Rainer Gerhards wrote: >>> Hi Raoul, >>> >>> I don't keep track of the bug in the older releases - simply too > much >>> work, especially in this case. The best would be to use v3-stable >> from >>> git (I have not yet released a tarball as I'd like to get some >> feedback >>> from the field, first - not too often release stable versions..). >> >> just for the records - with rsyslog stable with git cs >> d742b251a6cdac02b235bd7459fa60890a0e6e i have not seen this issue > until >> now. >> >> thanks! >> raoul >> -- >> ____________________________________________________________________ >> DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at >> Technischer Leiter >> >> IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at >> Barawitzkagasse 10/2/2/11 email. office at ipax.at >> 1190 Wien tel. +43 1 3670030 >> FN 277995t HG Wien fax. +43 1 3670030 15 >> ____________________________________________________________________ >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 19 15:16:29 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 19 Feb 2009 15:16:29 +0100 Subject: [rsyslog] requesting log samples Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> Hi all, in an effort to enhance the rsyslog legacy syslog parser, I would appreciate if you could provide me with some *raw* syslog samples. I don't need lots of messages, just a few from as many different devices as possible. What I am primarily interested in is the header and early message parts. The full story is here: http://blog.gerhards.net/2009/02/calling-for-log-samples.html I would deeply appreciate if you could forward this to anyone who could be willing to contribute. Thanks, Rainer From david at lang.hm Thu Feb 19 18:21:46 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 19 Feb 2009 09:21:46 -0800 (PST) Subject: [rsyslog] requesting log samples In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> Message-ID: On Thu, 19 Feb 2009, Rainer Gerhards wrote: > Hi all, > > in an effort to enhance the rsyslog legacy syslog parser, I would > appreciate if you could provide me with some *raw* syslog samples. I > don't need lots of messages, just a few from as many different devices > as possible. What I am primarily interested in is the header and early > message parts. > > The full story is here: > > http://blog.gerhards.net/2009/02/calling-for-log-samples.html have you taken a look at www.loganalysis.org? specificly they have a project for this at http://www.loganalysis.org/sample-logs/samples.html not a lot of things there now, but if you are gathering things it would be good to put them in a place where they can be used by lots of folks. David Lang > I would deeply appreciate if you could forward this to anyone who could > be willing to contribute. > > Thanks, > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 19 18:31:09 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 19 Feb 2009 18:31:09 +0100 Subject: [rsyslog] requesting log samples In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC7D@grfint2.intern.adiscon.com> Hi David, I know this place and I know Tina, who builds it, quite well. She started collecting a couple of years ago and there were very, very few contributions. One of the primary show stoppers, as I understand it, was that for the purposes stated by loganalysis.org, they needed somewhat bigger logs. I really need only single log entries, as I do not want to analyze them but parse the header. Thus I wanted to give it a new shot and see if I can get more sample for this very limited use case. Plus, I have to admit, loganalysis.org is now owned by splunk and while I like them, I prefer not to stick with something that I cannot control for things that are quite relevant for the work I do. But that is only a secondary reason. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Thursday, February 19, 2009 6:22 PM > To: rsyslog-users > Subject: Re: [rsyslog] requesting log samples > > On Thu, 19 Feb 2009, Rainer Gerhards wrote: > > > Hi all, > > > > in an effort to enhance the rsyslog legacy syslog parser, I would > > appreciate if you could provide me with some *raw* syslog samples. I > > don't need lots of messages, just a few from as many different > devices > > as possible. What I am primarily interested in is the header and > early > > message parts. > > > > The full story is here: > > > > http://blog.gerhards.net/2009/02/calling-for-log-samples.html > > have you taken a look at www.loganalysis.org? > > > specificly they have a project for this at > http://www.loganalysis.org/sample-logs/samples.html > not a lot of things there now, but if you are gathering things it would > be > good to put them in a place where they can be used by lots of folks. > > David Lang > > > I would deeply appreciate if you could forward this to anyone who > could > > be willing to contribute. > > > > Thanks, > > Rainer > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From Luis.Fernando.Munoz.Mejias at cern.ch Fri Feb 20 13:38:15 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Fri, 20 Feb 2009 13:38:15 +0100 Subject: [rsyslog] Extracting a subset of matches on regular expressions? Message-ID: <200902201338.15815.Luis.Fernando.Munoz.Mejias@cern.ch> Hi, there. I'm trying to extract some fields from SSH log in messages, and store in separate fields so that I can easily retrieve user names and source IPs. I have such match: Accepted (.*) for (.*) from ([^[:space:]]) where $1 is the authentication method (password, RSA...), $2 is the user name and $3 is the source IP for the connection. My idea is to place a separator for these fields, and making parsing easy. Something like $_$$_$$_$$_$ I know I could use a template, the same regular expression 3 times and extract one field at a time. But I wonder if it's possible to process the RE once, and then extract ($1, $2, $3) and NOT $0 in one go. This would be much faster, and speed matters to me. Thanks. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From rgerhards at hq.adiscon.com Mon Feb 23 11:13:47 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 23 Feb 2009 11:13:47 +0100 Subject: [rsyslog] Anyone with ties into Ubuntu on this list? Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC9B@grfint2.intern.adiscon.com> Hi all, is there anyone with ties into Ubuntu on this list (or knows someone who is)? I just learned that Ubuntu seems to ship a very old version of rsyslog[1]. There is a new and well-mainteined Debian package done by Michael Biebl available. I would like to talk to someone who can help get that into Ubuntu (interestingly, Ubuntu this time has way older software than Debian, if that is motivation ;)). Thanks, Rainer [1] http://kb.monitorware.com/install-latest-rsyslog-from-deb-src-on-ubuntu- mbiebl-t8931.html From martinmie at PartyGaming.com Mon Feb 23 16:49:22 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Mon, 23 Feb 2009 16:49:22 +0100 Subject: [rsyslog] rsyslog and load balancers Message-ID: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> Hi all, I've read the docs on rsyslog but everything is related to one server and n-clients sending their logs to it... What if I create at least 2 rsyslog servers and put them behind a load-balancer (on only the virtual IP would be known to the clients)? how to proceed with the TLS certificates for both server and clients? Tips and tricks much appreciated. Cheers, Martin This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From aoz.syn at gmail.com Mon Feb 23 17:12:35 2009 From: aoz.syn at gmail.com (RB) Date: Mon, 23 Feb 2009 09:12:35 -0700 Subject: [rsyslog] rsyslog and load balancers In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> Message-ID: <4255c2570902230812x6f83a2e0m603a153d5460e79@mail.gmail.com> On Mon, Feb 23, 2009 at 08:49, Martin Mielke wrote: > What if I create at least 2 rsyslog servers and put them behind a > load-balancer (on only the virtual IP would be known to the clients)? > how to proceed with the TLS certificates for both server and clients? Although it depends on how you configure your load balancer, it should generally be the same method as a TCP-balanced HTTPS cluster: all server members get the same cert issued for the balanced IP. You'll need to make sure that all packets for a given client session are directed to the same server. Client certs shouldn't be any different than normal. If you plan on using anything other than the client's cert (source IP, hostname, etc.) for identification, filtering, or otherwise, you'll need to route the connections through the LB as opposed to proxying them. From rgerhards at hq.adiscon.com Mon Feb 23 17:44:58 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 23 Feb 2009 17:44:58 +0100 Subject: [rsyslog] rsyslog and load balancers In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCB6@grfint2.intern.adiscon.com> I couldn't stand this ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Monday, February 23, 2009 4:49 PM > To: rsyslog-users > Subject: [rsyslog] rsyslog and load balancers > > > Hi all, > > I've read the docs on rsyslog but everything is related to one server > and n-clients sending their logs to it... > What if I create at least 2 rsyslog servers and put them behind a > load-balancer (on only the virtual IP would be known to the clients)? > how to proceed with the TLS certificates for both server and clients? > > Tips and tricks much appreciated. > > Cheers, > Martin > > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. This conflicts with the list policy ;) Also, there is no way we can delete any copies in the various mail archives that cache this list. Quite seriously, you should forward that as a question to your legal folks (those that make you use such disclaimers ;)). Rainer > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Feb 23 17:43:26 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 23 Feb 2009 17:43:26 +0100 Subject: [rsyslog] rsyslog and load balancers In-Reply-To: <4255c2570902230812x6f83a2e0m603a153d5460e79@mail.gmail.com> References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> <4255c2570902230812x6f83a2e0m603a153d5460e79@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCB5@grfint2.intern.adiscon.com> I agree to RB here, but I - due to lack of environment - I am not able to verify it. So a success report and some doc when you are done would be very much appreciated. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of RB > Sent: Monday, February 23, 2009 5:13 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog and load balancers > > On Mon, Feb 23, 2009 at 08:49, Martin Mielke > wrote: > > What if I create at least 2 rsyslog servers and put them behind a > > load-balancer (on only the virtual IP would be known to the clients)? > > how to proceed with the TLS certificates for both server and clients? > > Although it depends on how you configure your load balancer, it should > generally be the same method as a TCP-balanced HTTPS cluster: all > server members get the same cert issued for the balanced IP. You'll > need to make sure that all packets for a given client session are > directed to the same server. Client certs shouldn't be any different > than normal. > > If you plan on using anything other than the client's cert (source IP, > hostname, etc.) for identification, filtering, or otherwise, you'll > need to route the connections through the LB as opposed to proxying > them. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From bakers at web-ster.com Mon Feb 23 19:01:04 2009 From: bakers at web-ster.com (Scott Baker) Date: Mon, 23 Feb 2009 10:01:04 -0800 Subject: [rsyslog] Matching hostname and facility? Message-ID: <49A2E460.50604@web-ster.com> I have an rsyslog.conf entry like this to send everything from my DHCP server to it's own log file on my central rsyslog server. # DHCP logs :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp Is there a way to specify hostname AND a syslog facility? It'd be nice if I could match that host, and local6.* or something like that. Is that possible? - Scott From hks.private at gmail.com Mon Feb 23 23:56:15 2009 From: hks.private at gmail.com ((private) HKS) Date: Mon, 23 Feb 2009 17:56:15 -0500 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: <49A2E460.50604@web-ster.com> References: <49A2E460.50604@web-ster.com> Message-ID: On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker wrote: > I have an rsyslog.conf entry like this to send everything from my DHCP > server to it's own log file on my central rsyslog server. > > # DHCP logs > :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp > > Is there a way to specify hostname AND a syslog facility? It'd be nice if I > could match that host, and local6.* or something like that. Is that possible? > > - Scott > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > #DHCP logs if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == 'local6' then -?dhcp -HKS From david at lang.hm Tue Feb 24 02:11:03 2009 From: david at lang.hm (david at lang.hm) Date: Mon, 23 Feb 2009 17:11:03 -0800 (PST) Subject: [rsyslog] UDP source forging. Message-ID: I have a need to use some products that are stupid enough to ignore the host field in the syslog message and instead base everything on the IP address the message originates from. some other syslog servers can handle this by forging the source of the UDP packet, can rsyslog do this? one way that I know to do this is to issue a bind command to set the source IP, send the packet, then close the 'connection' (with the kernel set to allow non-local-binds), I've hacked sysklogd to do this sort of thing in the past. another way is to send out raw packets (which I believe requires root access). I suspect that this would require more drastic changes to support, but may have slightly higher performance. David Lang From aoz.syn at gmail.com Tue Feb 24 04:29:25 2009 From: aoz.syn at gmail.com (RB) Date: Mon, 23 Feb 2009 20:29:25 -0700 Subject: [rsyslog] UDP source forging. In-Reply-To: References: Message-ID: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> On Mon, Feb 23, 2009 at 18:11, wrote: > I have a need to use some products that are stupid enough to ignore the > host field in the syslog message and instead base everything on the IP > address the message originates from. > > some other syslog servers can handle this by forging the source of the UDP > packet, can rsyslog do this? So is rsyslog originating the messages, or are you using it to aggregate them and then feed them on to the other [bad] acceptors? I am unaware of a way to get rsyslog to forge packets (short of writing an output module), but unless you must get another syslog daemon into the mix, you may be better off just feeding your messages directly to the other collector. From david at lang.hm Tue Feb 24 04:40:25 2009 From: david at lang.hm (david at lang.hm) Date: Mon, 23 Feb 2009 19:40:25 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> Message-ID: On Mon, 23 Feb 2009, RB wrote: > On Mon, Feb 23, 2009 at 18:11, wrote: >> I have a need to use some products that are stupid enough to ignore the >> host field in the syslog message and instead base everything on the IP >> address the message originates from. >> >> some other syslog servers can handle this by forging the source of the UDP >> packet, can rsyslog do this? > > So is rsyslog originating the messages, or are you using it to > aggregate them and then feed them on to the other [bad] acceptors? I > am unaware of a way to get rsyslog to forge packets (short of writing > an output module), but unless you must get another syslog daemon into > the mix, you may be better off just feeding your messages directly to > the other collector. rsyslog would be the relay from one non-routed network to another non-routed network. this could be a fairly simple change to the UDP output module (adding a couple commands around the sending of a message), but before I dove in to do that I wanted to see if I had missed this feature anywhere. David Lang From rgerhards at hq.adiscon.com Tue Feb 24 08:43:49 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 08:43:49 +0100 Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> Hi David et all, Currently rsyslog does not support this and I have to admit I was always very hesitant to add it (I see potential for misuse). Co-incidentally, I received a similar request and was about to relay it to the mailing list to gather feedback. As it looks, this no longer is necessary ;) When I thought about implementation, I originally thought about raw sockets (which indeed require root access), but if there is any other way, I would be most interested. If you can provide some code, I will happily integrate it. I think an addition to the omfwd module, in udp forwarding, together with a new directive ($SpoofOriginalUDPAddress or so...) would be the right way to go. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, February 24, 2009 4:40 AM > To: rsyslog-users > Subject: Re: [rsyslog] UDP source forging. > > On Mon, 23 Feb 2009, RB wrote: > > > On Mon, Feb 23, 2009 at 18:11, wrote: > >> I have a need to use some products that are stupid enough > to ignore the > >> host field in the syslog message and instead base > everything on the IP > >> address the message originates from. > >> > >> some other syslog servers can handle this by forging the > source of the UDP > >> packet, can rsyslog do this? > > > > So is rsyslog originating the messages, or are you using it to > > aggregate them and then feed them on to the other [bad] > acceptors? I > > am unaware of a way to get rsyslog to forge packets (short > of writing > > an output module), but unless you must get another syslog > daemon into > > the mix, you may be better off just feeding your messages > directly to > > the other collector. > > rsyslog would be the relay from one non-routed network to another > non-routed network. > > this could be a fairly simple change to the UDP output module > (adding a > couple commands around the sending of a message), but before > I dove in to > do that I wanted to see if I had missed this feature anywhere. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Tue Feb 24 09:43:17 2009 From: david at lang.hm (david at lang.hm) Date: Tue, 24 Feb 2009 00:43:17 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> Message-ID: On Tue, 24 Feb 2009, Rainer Gerhards wrote: > Hi David et all, > > Currently rsyslog does not support this and I have to admit I was always > very hesitant to add it (I see potential for misuse). Co-incidentally, I > received a similar request and was about to relay it to the mailing list > to gather feedback. As it looks, this no longer is necessary ;) > > When I thought about implementation, I originally thought about raw > sockets (which indeed require root access), but if there is any other > way, I would be most interested. If you can provide some code, I will > happily integrate it. I think an addition to the omfwd module, in udp > forwarding, together with a new directive ($SpoofOriginalUDPAddress or > so...) would be the right way to go. I'll see about hacking in some example code (probably without any config option and not thread-safe) and send it to you. there's another similar change in the same area that I was looking at, I'll mock it up as well. David Lang > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com >> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Tuesday, February 24, 2009 4:40 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] UDP source forging. >> >> On Mon, 23 Feb 2009, RB wrote: >> >>> On Mon, Feb 23, 2009 at 18:11, wrote: >>>> I have a need to use some products that are stupid enough >> to ignore the >>>> host field in the syslog message and instead base >> everything on the IP >>>> address the message originates from. >>>> >>>> some other syslog servers can handle this by forging the >> source of the UDP >>>> packet, can rsyslog do this? >>> >>> So is rsyslog originating the messages, or are you using it to >>> aggregate them and then feed them on to the other [bad] >> acceptors? I >>> am unaware of a way to get rsyslog to forge packets (short >> of writing >>> an output module), but unless you must get another syslog >> daemon into >>> the mix, you may be better off just feeding your messages >> directly to >>> the other collector. >> >> rsyslog would be the relay from one non-routed network to another >> non-routed network. >> >> this could be a fairly simple change to the UDP output module >> (adding a >> couple commands around the sending of a message), but before >> I dove in to >> do that I wanted to see if I had missed this feature anywhere. >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Feb 24 09:44:24 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 09:44:24 +0100 Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> David, Excellent, please do as you have time. I'll make sure it fits. Thread-safety, btw., is not a big issue at this level as the output modules are guaranteed to be never called by multiple threads concurrently. That was a trade-off to enable other folks to easily write them (but I have an option in the back of my head that a module can tell the engine it *is* capable to run on multiple threads concurrently...). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, February 24, 2009 9:43 AM > To: rsyslog-users > Subject: Re: [rsyslog] UDP source forging. > > On Tue, 24 Feb 2009, Rainer Gerhards wrote: > > > Hi David et all, > > > > Currently rsyslog does not support this and I have to admit I was > always > > very hesitant to add it (I see potential for misuse). Co- > incidentally, I > > received a similar request and was about to relay it to the mailing > list > > to gather feedback. As it looks, this no longer is necessary ;) > > > > When I thought about implementation, I originally thought about raw > > sockets (which indeed require root access), but if there is any other > > way, I would be most interested. If you can provide some code, I will > > happily integrate it. I think an addition to the omfwd module, in udp > > forwarding, together with a new directive ($SpoofOriginalUDPAddress > or > > so...) would be the right way to go. > > I'll see about hacking in some example code (probably without any > config > option and not thread-safe) and send it to you. > > there's another similar change in the same area that I was looking at, > I'll mock it up as well. > > David Lang > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com > >> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of > david at lang.hm > >> Sent: Tuesday, February 24, 2009 4:40 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] UDP source forging. > >> > >> On Mon, 23 Feb 2009, RB wrote: > >> > >>> On Mon, Feb 23, 2009 at 18:11, wrote: > >>>> I have a need to use some products that are stupid enough > >> to ignore the > >>>> host field in the syslog message and instead base > >> everything on the IP > >>>> address the message originates from. > >>>> > >>>> some other syslog servers can handle this by forging the > >> source of the UDP > >>>> packet, can rsyslog do this? > >>> > >>> So is rsyslog originating the messages, or are you using it to > >>> aggregate them and then feed them on to the other [bad] > >> acceptors? I > >>> am unaware of a way to get rsyslog to forge packets (short > >> of writing > >>> an output module), but unless you must get another syslog > >> daemon into > >>> the mix, you may be better off just feeding your messages > >> directly to > >>> the other collector. > >> > >> rsyslog would be the relay from one non-routed network to another > >> non-routed network. > >> > >> this could be a fairly simple change to the UDP output module > >> (adding a > >> couple commands around the sending of a message), but before > >> I dove in to > >> do that I wanted to see if I had missed this feature anywhere. > >> > >> David Lang > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > >> > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From martinmie at PartyGaming.com Tue Feb 24 15:47:30 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Tue, 24 Feb 2009 15:47:30 +0100 Subject: [rsyslog] Not logging TCP connections? Message-ID: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> Hi, Sorry to sound a bit blonde here but... I need rsyslog to accept both TCP and UDP connections to port 514. I have the following relevant parts on the server side: -- ... $DefaultNetstreamDriver ptcp # UDP Syslog Server: $UDPServerRun 514 # start a UDP syslog server at standard port 514 $InputTCPServerStreamDriverAuthMode anon $InputTCPServerStreamDriverPermittedPeer *.mydomain $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode $InputTCPServerRun 514 ... -- ...also disabled all the certificates/keys files just in case And on the client side> -- # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional *.* @logserver.mydomain -- After restarting rsyslog on the server it only logs UDP traffic... Am I overseeing something the obvious? Regards, Martin This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From rgerhards at hq.adiscon.com Tue Feb 24 15:53:13 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 15:53:13 +0100 Subject: [rsyslog] Not logging TCP connections? In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> Martin, on the client @ is udp while @@ is TCP (!) ;) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Tuesday, February 24, 2009 3:48 PM > To: rsyslog-users > Subject: [rsyslog] Not logging TCP connections? > > Hi, > > Sorry to sound a bit blonde here but... > I need rsyslog to accept both TCP and UDP connections to port 514. > > I have the following relevant parts on the server side: > -- > ... > $DefaultNetstreamDriver ptcp > > # UDP Syslog Server: > $UDPServerRun 514 # start a UDP syslog server at standard port 514 > > > $InputTCPServerStreamDriverAuthMode anon > $InputTCPServerStreamDriverPermittedPeer *.mydomain > $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode > $InputTCPServerRun 514 > ... > -- > > ...also disabled all the certificates/keys files just in case > > > And on the client side> > -- > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional > *.* @logserver.mydomain > -- > > After restarting rsyslog on the server it only logs UDP traffic... > > Am I overseeing something the obvious? > > > Regards, > Martin > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From martinmie at PartyGaming.com Tue Feb 24 16:31:52 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Tue, 24 Feb 2009 16:31:52 +0100 Subject: [rsyslog] Not logging TCP connections? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> References: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> <577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> Message-ID: <0B1B9163138571439EAF804646F3F6AA06B9D148@GIBSVWIN004X.partygaming.local> Yes, sorry. Copy & paste worked bad. I just removed some unnecessary lines and re-ordered some directives. Now it works. Sorry for the noise. Martin > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: 24 February 2009 15:53 > To: rsyslog-users > Subject: Re: [rsyslog] Not logging TCP connections? > > Martin, on the client @ is udp while @@ is TCP (!) ;) > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > > Sent: Tuesday, February 24, 2009 3:48 PM > > To: rsyslog-users > > Subject: [rsyslog] Not logging TCP connections? > > > > Hi, > > > > Sorry to sound a bit blonde here but... > > I need rsyslog to accept both TCP and UDP connections to port 514. > > > > I have the following relevant parts on the server side: > > -- > > ... > > $DefaultNetstreamDriver ptcp > > > > # UDP Syslog Server: > > $UDPServerRun 514 # start a UDP syslog server at standard port 514 > > > > > > $InputTCPServerStreamDriverAuthMode anon > > $InputTCPServerStreamDriverPermittedPeer *.mydomain > > $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode > > $InputTCPServerRun 514 > > ... > > -- > > > > ...also disabled all the certificates/keys files just in case > > > > > > And on the client side> > > -- > > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional > > *.* @logserver.mydomain > > -- > > > > After restarting rsyslog on the server it only logs UDP traffic... > > > > Am I overseeing something the obvious? > > > > > > Regards, > > Martin > > > > > > This email and any attachments are confidential, and may be legally > > privileged and protected by copyright. If you are not the intended > > recipient dissemination or copying of this email is prohibited. If you > > have received this in error, please notify the sender by replying by > > email and then delete the email completely from your system. > > > > Any views or opinions are solely those of the sender. This > > communication is not intended to form a binding contract unless > > expressly indicated to the contrary and properly authorised. Any > > actions taken on the basis of this email are at the recipient's own > > risk. > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Feb 24 16:51:42 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 16:51:42 +0100 Subject: [rsyslog] Not logging TCP connections? In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06B9D148@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local><577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> <0B1B9163138571439EAF804646F3F6AA06B9D148@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCDC@grfint2.intern.adiscon.com> No problem at all ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Tuesday, February 24, 2009 4:32 PM > To: rsyslog-users > Subject: Re: [rsyslog] Not logging TCP connections? > > Yes, sorry. Copy & paste worked bad. > > I just removed some unnecessary lines and re-ordered some directives. > Now it works. > > Sorry for the noise. > > > Martin > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: 24 February 2009 15:53 > > To: rsyslog-users > > Subject: Re: [rsyslog] Not logging TCP connections? > > > > Martin, on the client @ is udp while @@ is TCP (!) ;) > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > > > Sent: Tuesday, February 24, 2009 3:48 PM > > > To: rsyslog-users > > > Subject: [rsyslog] Not logging TCP connections? > > > > > > Hi, > > > > > > Sorry to sound a bit blonde here but... > > > I need rsyslog to accept both TCP and UDP connections to port 514. > > > > > > I have the following relevant parts on the server side: > > > -- > > > ... > > > $DefaultNetstreamDriver ptcp > > > > > > # UDP Syslog Server: > > > $UDPServerRun 514 # start a UDP syslog server at standard port 514 > > > > > > > > > $InputTCPServerStreamDriverAuthMode anon > > > $InputTCPServerStreamDriverPermittedPeer *.mydomain > > > $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode > > > $InputTCPServerRun 514 > > > ... > > > -- > > > > > > ...also disabled all the certificates/keys files just in case > > > > > > > > > And on the client side> > > > -- > > > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional > > > *.* @logserver.mydomain > > > -- > > > > > > After restarting rsyslog on the server it only logs UDP traffic... > > > > > > Am I overseeing something the obvious? > > > > > > > > > Regards, > > > Martin > > > > > > > > > This email and any attachments are confidential, and may be legally > > > privileged and protected by copyright. If you are not the intended > > > recipient dissemination or copying of this email is prohibited. If > you > > > have received this in error, please notify the sender by replying > by > > > email and then delete the email completely from your system. > > > > > > Any views or opinions are solely those of the sender. This > > > communication is not intended to form a binding contract unless > > > expressly indicated to the contrary and properly authorised. Any > > > actions taken on the basis of this email are at the recipient's own > > > risk. > > > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From bakers at web-ster.com Wed Feb 25 21:08:01 2009 From: bakers at web-ster.com (Scott Baker) Date: Wed, 25 Feb 2009 12:08:01 -0800 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: References: <49A2E460.50604@web-ster.com> Message-ID: <49A5A521.8040107@web-ster.com> On 02/23/2009 02:56 PM, (private) HKS wrote: > On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker wrote: >> I have an rsyslog.conf entry like this to send everything from my DHCP >> server to it's own log file on my central rsyslog server. >> >> # DHCP logs >> :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp >> >> Is there a way to specify hostname AND a syslog facility? It'd be nice if I >> could match that host, and local6.* or something like that. Is that possible? >> >> - Scott >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > > > #DHCP logs > if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == > 'local6' then -?dhcp Does this syntax work on rsyslog 2.0.x, that's what my server has on it. I've tried this syntax, but it's not logging. - Scott From david at lang.hm Wed Feb 25 21:47:20 2009 From: david at lang.hm (david at lang.hm) Date: Wed, 25 Feb 2009 12:47:20 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> Message-ID: figuring out how to do this is navigating a twisty maze of helper functions, all different ;-) there are a few things that look odd here if I am reading the code properly. rsyslog makes one call to the UDPSend routine for all forwarded messages, this means that they must all send the same format. the UDPSend routine then walks through all destinations attempting to send the message to them. and considers the message successfully sent if any of them can be sent. I would have expected that it would only be considered successful if all of them succeded. UDPSend attempts to use the sockets that were created to listening for messages to send it's message out. in a multi-homed machine the local IP address of those sockets may not be appropriate for the relay. also, what would happen if a system recieves via TCP and forwards via UDP and so doesn't have any UDP listener sockets. so now, my suggestion On Linux in /etc/sysctl.conf add the line net.ipv4.ip_nonlocal_bind=1 this tells the kernel not to fail bind requests to IP addresses that don't exist on the box then in omfwd.c in the routine that calls UDPSend, modify it to pass the source IP address of the message to UDPSend create a new filehandle array to use for outbound messages (one filehandle for each destination since they may end up with different source IPs) in UDPSend three options. 1. default use the appropriate filehandle for each destination and send the message. this is similar to what currently takes place, but instead of walking through each open socket for each destination, there should only be one sendto per destination. when opening the socket it should not be nessasary to do a bind, just issue the socket call. if there is anything in the syslog standard specifying the source port (I don't think there is, although many implementations use port 514 becouse they do the same thing that rsyslog is doing and re-use listening sockets to send messages) 2. randomize source ports to support external load balancers same as default, except that every X (configurable) messages close and re-open the sockets. the reason for this is that each time a message is first sent the OS picks a random source port that will be used for all messages sent through that socket. by closing the socket once in a while, load balancers that balance based on source IP + source port + destination IP + destination port will be able to function (a similar feature for TCP based transports would be useful for the same reason) 3. forge the source IP/port for each message that is sent, open a new socket, then issue a 'bind' command for that socket (filehandle) that sets the local IP address to the IP address that the message initially came from, then issue the sendto, then close the filehandle. there is no need for an array of sockets in this case as the socket needs to be re-opened for each message/destination. in theory there is a possibility of a performance gain by keeping sockets open and re-using them, but since each socket is unique to the sender + destination there would be a large number of sockets and a low probability of re-using a socket for the next message. in sysklogd I implemented #2 with the simple code below (once I created a different filehandle to use for outbound connections) this closed and re-opened the socket for each message, doing it every X messages would save on the overhead and be just as good in practice. the bind command that's commented out is basicly what would be needed for #3, but with real values for the source.sin_addr.s_addr (and source.sin_port if you wanted to forge the port as well, leaving it zero lets the OS pick a port number) if (finet >0) { /* close and re-open the outbound socket after each message so that the source port is randomized and load balancers can distribute the messages */ close(finet); finet = create_inet_socket(); /* if we want to forge the source IP for the outbound packets, this is the place to do it by seeting the IP address to the address we received the message from struct sockaddr_in source; source.sin_addr.s_addr = 0x00000000; source.sin_port = 0x0000; bind(finet,(struct sockaddr *) &source,sizeof(source));*/ } the create_inet_socket() routine is: static int create_inet_socket() { int fd, on = 1; int sockflags; fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { logerror("syslog: Unknown protocol, suspending inet service."); return fd; } if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, \ (char *) &on, sizeof(on)) < 0 ) { logerror("setsockopt(REUSEADDR), suspending inet"); close(fd); return -1; } /* We must not block on the network socket, in case a packet * gets lost between select and recv, otherise the process * will stall until the timeout, and other processes trying to * log will also stall. */ if ((sockflags = fcntl(fd, F_GETFL)) != -1) { sockflags |= O_NONBLOCK; /* * SETFL could fail too, so get it caught by the subsequent * error check. */ sockflags = fcntl(fd, F_SETFL, sockflags); } if (sockflags == -1) { logerror("fcntl(O_NONBLOCK), suspending inet"); close(fd); return -1; } return fd; } this isn't a patch like you asked for and I offered to put togeather, but is it enough to clearly explain this? if not I can continue to work on the patch. David Lang On Tue, 24 Feb 2009, Rainer Gerhards wrote: > David, > > Excellent, please do as you have time. I'll make sure it fits. > Thread-safety, btw., is not a big issue at this level as the output > modules are guaranteed to be never called by multiple threads > concurrently. That was a trade-off to enable other folks to easily write > them (but I have an option in the back of my head that a module can tell > the engine it *is* capable to run on multiple threads concurrently...). > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Tuesday, February 24, 2009 9:43 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] UDP source forging. >> >> On Tue, 24 Feb 2009, Rainer Gerhards wrote: >> >>> Hi David et all, >>> >>> Currently rsyslog does not support this and I have to admit I was >> always >>> very hesitant to add it (I see potential for misuse). Co- >> incidentally, I >>> received a similar request and was about to relay it to the mailing >> list >>> to gather feedback. As it looks, this no longer is necessary ;) >>> >>> When I thought about implementation, I originally thought about raw >>> sockets (which indeed require root access), but if there is any > other >>> way, I would be most interested. If you can provide some code, I > will >>> happily integrate it. I think an addition to the omfwd module, in > udp >>> forwarding, together with a new directive ($SpoofOriginalUDPAddress >> or >>> so...) would be the right way to go. >> >> I'll see about hacking in some example code (probably without any >> config >> option and not thread-safe) and send it to you. >> >> there's another similar change in the same area that I was looking at, >> I'll mock it up as well. >> >> David Lang >> >>> Rainer >>> >>>> -----Original Message----- >>>> From: rsyslog-bounces at lists.adiscon.com >>>> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of >> david at lang.hm >>>> Sent: Tuesday, February 24, 2009 4:40 AM >>>> To: rsyslog-users >>>> Subject: Re: [rsyslog] UDP source forging. >>>> >>>> On Mon, 23 Feb 2009, RB wrote: >>>> >>>>> On Mon, Feb 23, 2009 at 18:11, wrote: >>>>>> I have a need to use some products that are stupid enough >>>> to ignore the >>>>>> host field in the syslog message and instead base >>>> everything on the IP >>>>>> address the message originates from. >>>>>> >>>>>> some other syslog servers can handle this by forging the >>>> source of the UDP >>>>>> packet, can rsyslog do this? >>>>> >>>>> So is rsyslog originating the messages, or are you using it to >>>>> aggregate them and then feed them on to the other [bad] >>>> acceptors? I >>>>> am unaware of a way to get rsyslog to forge packets (short >>>> of writing >>>>> an output module), but unless you must get another syslog >>>> daemon into >>>>> the mix, you may be better off just feeding your messages >>>> directly to >>>>> the other collector. >>>> >>>> rsyslog would be the relay from one non-routed network to another >>>> non-routed network. >>>> >>>> this could be a fairly simple change to the UDP output module >>>> (adding a >>>> couple commands around the sending of a message), but before >>>> I dove in to >>>> do that I wanted to see if I had missed this feature anywhere. >>>> >>>> David Lang >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com >>>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From hks.private at gmail.com Thu Feb 26 00:38:32 2009 From: hks.private at gmail.com ((private) HKS) Date: Wed, 25 Feb 2009 18:38:32 -0500 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: <49A5A521.8040107@web-ster.com> References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> Message-ID: On Wed, Feb 25, 2009 at 3:08 PM, Scott Baker wrote: > On 02/23/2009 02:56 PM, (private) HKS wrote: >> On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker ?wrote: >>> I have an rsyslog.conf entry like this to send everything from my DHCP >>> server to it's own log file on my central rsyslog server. >>> >>> # DHCP logs >>> :FROMHOST, isequal, "dhcp-server.domain.com" ? ? ? ? ? ? -?dhcp >>> >>> Is there a way to specify hostname AND a syslog facility? It'd be nice if I >>> could match that host, and local6.* or something like that. Is that possible? >>> >>> - Scott >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> >> >> #DHCP logs >> if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == >> 'local6' then -?dhcp > > Does this syntax work on rsyslog 2.0.x, that's what my server has on it. > I've tried this syntax, but it's not logging. > > - Scott No, this will require 3+ - which you really should upgrade to anyway. -HKS From rgerhards at hq.adiscon.com Thu Feb 26 14:34:05 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 14:34:05 +0100 Subject: [rsyslog] UDP source forging. References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> Hi David, I think you got lost in the callbacks. The multiple send calls are not for multiple actions. This is all for one action. That code was contributed as part of the IPv6 port. I verified the implementation with what I could find as references to sending on IPv6 and think the implementation uses proper procedures for that environment. In essence, on an IPv6-enabled system, you will receive multiple sockets that you potentially can use to send the message. What the code does is iterate over these sockets and see which one really works. There is also an option (not checked but pretty sure) that permits sending to all receivers. I think that was the other situation you have seen. The listen socket is NOT being reused for sending. RFC3164 actually recommends that port 514 is used as the source port, and we had a lengthy discussion at the IETF about this recommendation. The bottom line is that you cannot reuse the receive socket on a highly parallel syslogd because each thread needs its own (or you have even more sync). Rsyslog creates a new (set of) send sockets *per action*. I guess part of the confusion stems back from your understanding of sysklogd code. Sysklogd works totally different here. I hope this clarifies a bit. I will try to have a look at the code provided asap and see what I can do. Its unfortunately still very busy, so I can not commit when I will finally start. HTH Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Wednesday, February 25, 2009 9:47 PM > To: rsyslog-users > Subject: Re: [rsyslog] UDP source forging. > > figuring out how to do this is navigating a twisty maze of helper > functions, all different ;-) > > there are a few things that look odd here if I am reading the code > properly. > > rsyslog makes one call to the UDPSend routine for all forwarded > messages, > this means that they must all send the same format. > > the UDPSend routine then walks through all destinations attempting to > send > the message to them. and considers the message successfully sent if any > of > them can be sent. I would have expected that it would only be > considered > successful if all of them succeded. > > UDPSend attempts to use the sockets that were created to listening for > messages to send it's message out. in a multi-homed machine the local > IP > address of those sockets may not be appropriate for the relay. also, > what > would happen if a system recieves via TCP and forwards via UDP and so > doesn't have any UDP listener sockets. > > > so now, my suggestion > > On Linux in /etc/sysctl.conf add the line > > net.ipv4.ip_nonlocal_bind=1 > > this tells the kernel not to fail bind requests to IP addresses that > don't > exist on the box > > then in omfwd.c > > in the routine that calls UDPSend, modify it to pass the source IP > address > of the message to UDPSend > > create a new filehandle array to use for outbound messages (one > filehandle > for each destination since they may end up with different source IPs) > > > in UDPSend > > three options. > > > 1. default > > use the appropriate filehandle for each destination and send the > message. this is similar to what currently takes place, but instead of > walking through each open socket for each destination, there should > only > be one sendto per destination. when opening the socket it should not be > nessasary to do a bind, just issue the socket call. > > if there is anything in the syslog standard specifying the source > port > (I don't think there is, although many implementations use port 514 > becouse they do the same thing that rsyslog is doing and re-use > listening > sockets to send messages) > > > 2. randomize source ports to support external load balancers > > same as default, except that every X (configurable) messages close > and > re-open the sockets. > > the reason for this is that each time a message is first sent the OS > picks a random source port that will be used for all messages sent > through > that socket. by closing the socket once in a while, load balancers that > balance based on source IP + source port + destination IP + destination > port will be able to function (a similar feature for TCP based > transports > would be useful for the same reason) > > > 3. forge the source IP/port > > for each message that is sent, open a new socket, then issue a > 'bind' > command for that socket (filehandle) that sets the local IP address to > the > IP address that the message initially came from, then issue the sendto, > then close the filehandle. > > there is no need for an array of sockets in this case as the socket > needs to be re-opened for each message/destination. in theory there is > a > possibility of a performance gain by keeping sockets open and re-using > them, but since each socket is unique to the sender + destination there > would be a large number of sockets and a low probability of re-using a > socket for the next message. > > in sysklogd I implemented #2 with the simple code below (once I created > a > different filehandle to use for outbound connections) > > this closed and re-opened the socket for each message, doing it every X > messages would save on the overhead and be just as good in practice. > > the bind command that's commented out is basicly what would be needed > for > #3, but with real values for the source.sin_addr.s_addr (and > source.sin_port if you wanted to forge the port as well, leaving it > zero > lets the OS pick a port number) > > if (finet >0) { > /* close and re-open the outbound socket after each message so > that the source port is randomized and load balancers can distribute > the messages */ > close(finet); > finet = create_inet_socket(); > /* if we want to forge the source IP for the outbound packets, > this is the place to do it by seeting the IP address to the address we > received the message from > struct sockaddr_in source; > source.sin_addr.s_addr = 0x00000000; > source.sin_port = 0x0000; > bind(finet,(struct sockaddr *) > &source,sizeof(source));*/ > } > > > the create_inet_socket() routine is: > > static int create_inet_socket() > { > int fd, on = 1; > int sockflags; > > fd = socket(AF_INET, SOCK_DGRAM, 0); > if (fd < 0) { > logerror("syslog: Unknown protocol, suspending inet > service."); > return fd; > } > > if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, \ > (char *) &on, sizeof(on)) < 0 ) { > logerror("setsockopt(REUSEADDR), suspending inet"); > close(fd); > return -1; > } > /* We must not block on the network socket, in case a packet > * gets lost between select and recv, otherise the process > * will stall until the timeout, and other processes trying to > * log will also stall. > */ > if ((sockflags = fcntl(fd, F_GETFL)) != -1) { > sockflags |= O_NONBLOCK; > /* > * SETFL could fail too, so get it caught by the > subsequent > * error check. > */ > sockflags = fcntl(fd, F_SETFL, sockflags); > } > if (sockflags == -1) { > logerror("fcntl(O_NONBLOCK), suspending inet"); > close(fd); > return -1; > } > return fd; > } > > > this isn't a patch like you asked for and I offered to put togeather, > but > is it enough to clearly explain this? if not I can continue to work on > the > patch. > > David Lang > > On Tue, 24 Feb 2009, Rainer Gerhards wrote: > > > David, > > > > Excellent, please do as you have time. I'll make sure it fits. > > Thread-safety, btw., is not a big issue at this level as the output > > modules are guaranteed to be never called by multiple threads > > concurrently. That was a trade-off to enable other folks to easily > write > > them (but I have an option in the back of my head that a module can > tell > > the engine it *is* capable to run on multiple threads > concurrently...). > > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm > >> Sent: Tuesday, February 24, 2009 9:43 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] UDP source forging. > >> > >> On Tue, 24 Feb 2009, Rainer Gerhards wrote: > >> > >>> Hi David et all, > >>> > >>> Currently rsyslog does not support this and I have to admit I was > >> always > >>> very hesitant to add it (I see potential for misuse). Co- > >> incidentally, I > >>> received a similar request and was about to relay it to the mailing > >> list > >>> to gather feedback. As it looks, this no longer is necessary ;) > >>> > >>> When I thought about implementation, I originally thought about raw > >>> sockets (which indeed require root access), but if there is any > > other > >>> way, I would be most interested. If you can provide some code, I > > will > >>> happily integrate it. I think an addition to the omfwd module, in > > udp > >>> forwarding, together with a new directive ($SpoofOriginalUDPAddress > >> or > >>> so...) would be the right way to go. > >> > >> I'll see about hacking in some example code (probably without any > >> config > >> option and not thread-safe) and send it to you. > >> > >> there's another similar change in the same area that I was looking > at, > >> I'll mock it up as well. > >> > >> David Lang > >> > >>> Rainer > >>> > >>>> -----Original Message----- > >>>> From: rsyslog-bounces at lists.adiscon.com > >>>> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of > >> david at lang.hm > >>>> Sent: Tuesday, February 24, 2009 4:40 AM > >>>> To: rsyslog-users > >>>> Subject: Re: [rsyslog] UDP source forging. > >>>> > >>>> On Mon, 23 Feb 2009, RB wrote: > >>>> > >>>>> On Mon, Feb 23, 2009 at 18:11, wrote: > >>>>>> I have a need to use some products that are stupid enough > >>>> to ignore the > >>>>>> host field in the syslog message and instead base > >>>> everything on the IP > >>>>>> address the message originates from. > >>>>>> > >>>>>> some other syslog servers can handle this by forging the > >>>> source of the UDP > >>>>>> packet, can rsyslog do this? > >>>>> > >>>>> So is rsyslog originating the messages, or are you using it to > >>>>> aggregate them and then feed them on to the other [bad] > >>>> acceptors? I > >>>>> am unaware of a way to get rsyslog to forge packets (short > >>>> of writing > >>>>> an output module), but unless you must get another syslog > >>>> daemon into > >>>>> the mix, you may be better off just feeding your messages > >>>> directly to > >>>>> the other collector. > >>>> > >>>> rsyslog would be the relay from one non-routed network to another > >>>> non-routed network. > >>>> > >>>> this could be a fairly simple change to the UDP output module > >>>> (adding a > >>>> couple commands around the sending of a message), but before > >>>> I dove in to > >>>> do that I wanted to see if I had missed this feature anywhere. > >>>> > >>>> David Lang > >>>> _______________________________________________ > >>>> rsyslog mailing list > >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>>> http://www.rsyslog.com > >>>> > >>> _______________________________________________ > >>> rsyslog mailing list > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>> http://www.rsyslog.com > >>> > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Feb 26 14:49:00 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 14:49:00 +0100 Subject: [rsyslog] Matching hostname and facility? References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E8F@GRFEXC.intern.adiscon.com> I have no time to try it out, but I think BSD-style hostblocks should be helpful in this case. Details in doc, something along these lines: !hostname local6.* /path/to/hostname-local6 Hostname is an implicit and condition until the next !hostname is seen. Not sure if in v2 it works with FQDN (don't think so) or just the plain hostname without domain. I think there is also a sample in the wiki or forum. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Scott Baker > Sent: Wednesday, February 25, 2009 9:08 PM > To: rsyslog-users > Subject: Re: [rsyslog] Matching hostname and facility? > > On 02/23/2009 02:56 PM, (private) HKS wrote: > > On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker > wrote: > >> I have an rsyslog.conf entry like this to send everything from my > DHCP > >> server to it's own log file on my central rsyslog server. > >> > >> # DHCP logs > >> :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp > >> > >> Is there a way to specify hostname AND a syslog facility? It'd be > nice if I > >> could match that host, and local6.* or something like that. Is that > possible? > >> > >> - Scott > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > >> > > > > > > #DHCP logs > > if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == > > 'local6' then -?dhcp > > Does this syntax work on rsyslog 2.0.x, that's what my server has on > it. > I've tried this syntax, but it's not logging. > > - Scott > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From aoz.syn at gmail.com Thu Feb 26 16:16:06 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 26 Feb 2009 08:16:06 -0700 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E8F@GRFEXC.intern.adiscon.com> References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> <9B6E2A8877C38245BFB15CC491A11DA71E8F@GRFEXC.intern.adiscon.com> Message-ID: <4255c2570902260716t26815e48wc36cb6be6477b451@mail.gmail.com> On Thu, Feb 26, 2009 at 06:49, Rainer Gerhards wrote: > I have no time to try it out, but I think BSD-style hostblocks should be > helpful in this case. Details in doc, something along these lines: > > !hostname > local6.* /path/to/hostname-local6 FWIW, the hostblock is denoted with '+' and '-', '!' is the program-name prefix. From aoz.syn at gmail.com Thu Feb 26 16:53:34 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 26 Feb 2009 08:53:34 -0700 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> Message-ID: <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> On Tue, Feb 17, 2009 at 13:11, RB wrote: > Regardless, I'll take the flag and see what I can do to get a > readily-accessible reasonably current build available for CentOS-5. Good & bad news - the good news is the Fedora upstream is very responsive, the bad news is I got sidetracked after his response. I have been told that rsyslog cannot be put in EPEL since it is already packaged in RHEL, be that package good or bad. Tomas has offered to help with the SPEC should I have any problems, but it looks like we're on our own for the time being. RPM package distribution can be done to various depths. The simplest is to just provide both the SRPM and unsigned binary RPMs for a few chosen CPU architectures for each packaged release as an HTTP or FTP download. This would allow one-off installations (updates would be manual) and generally get the package 'out there' for use. Further steps would involve signing the binaries and possibly publishing a repo that users could subscribe to (using /etc/yum.* or equivalent) for automated updates. Distributing a binary package in whatever form is going to increase the load (however mildly) on the project - each release will involve compiling and distributing binaries and SRPMs, if not signing them as well. I can work with you [Rainer] to automate that process, but as a random user I should probably not be doing the compilation and signing myself. So, we have 4 basic questions: 1. What versions are desired? 2. Are there any rsyslog components or functionality not packaged in the Fedora distribution users here would like to see included? 3. Do we want to sign the packages? 4. Who will perform the compilation/signing? From rgerhards at hq.adiscon.com Thu Feb 26 17:49:30 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 17:49:30 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com><49993125.2060603@ecker-software.de><4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com><4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Hi RB, thanks for all your hard work. I am absolutely willing to help make succeed in that. Just one question before we do down to details. Are there any other options that we can pursue? I remember, quite some time ago, that someone posted the idea that some well-known (non-RH, not EPEL) repositories exist. Unfortunatley, I do no longer know which these were. So the question is: are there any other such repositories where RHEL users turn to and, if so, can we work with them to achieve our joint goals? Sorry for some backtracking here... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of RB > Sent: Thursday, February 26, 2009 4:54 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > On Tue, Feb 17, 2009 at 13:11, RB wrote: > > Regardless, I'll take the flag and see what I can do to get a > > readily-accessible reasonably current build available for CentOS-5. > > Good & bad news - the good news is the Fedora upstream is very > responsive, the bad news is I got sidetracked after his response. > > I have been told that rsyslog cannot be put in EPEL since it is > already packaged in RHEL, be that package good or bad. Tomas has > offered to help with the SPEC should I have any problems, but it looks > like we're on our own for the time being. > > RPM package distribution can be done to various depths. The simplest > is to just provide both the SRPM and unsigned binary RPMs for a few > chosen CPU architectures for each packaged release as an HTTP or FTP > download. This would allow one-off installations (updates would be > manual) and generally get the package 'out there' for use. Further > steps would involve signing the binaries and possibly publishing a > repo that users could subscribe to (using /etc/yum.* or equivalent) > for automated updates. > > Distributing a binary package in whatever form is going to increase > the load (however mildly) on the project - each release will involve > compiling and distributing binaries and SRPMs, if not signing them as > well. I can work with you [Rainer] to automate that process, but as a > random user I should probably not be doing the compilation and signing > myself. > > So, we have 4 basic questions: > 1. What versions are desired? > 2. Are there any rsyslog components or functionality not packaged in > the Fedora distribution users here would like to see included? > 3. Do we want to sign the packages? > 4. Who will perform the compilation/signing? > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Feb 26 18:05:17 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 09:05:17 -0800 (PST) Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com><49993125.2060603@ecker-software.de><4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com><4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: even where rsyslog is included in a distro it's very handy to have a spec file (or debian equivalent) included with the source to allow a 'make rpm' or 'make deb' to properly make packages. I've been using checkinstall to create debian packages from the compiled source, and I don't know what it's doing wrong, but I've been tripped up a few times by it not replacing all the files that it should if rsyslog is already installed (the packages it creates work just fine if rsyslog isn't installed at all) David Lang On Thu, 26 Feb 2009, Rainer Gerhards wrote: > Hi RB, > > thanks for all your hard work. I am absolutely willing to help make > succeed in that. Just one question before we do down to details. Are > there any other options that we can pursue? I remember, quite some time > ago, that someone posted the idea that some well-known (non-RH, not > EPEL) repositories exist. Unfortunatley, I do no longer know which these > were. > > So the question is: are there any other such repositories where RHEL > users turn to and, if so, can we work with them to achieve our joint > goals? > > Sorry for some backtracking here... > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of RB >> Sent: Thursday, February 26, 2009 4:54 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending >> devices? >> >> On Tue, Feb 17, 2009 at 13:11, RB wrote: >>> Regardless, I'll take the flag and see what I can do to get a >>> readily-accessible reasonably current build available for CentOS-5. >> >> Good & bad news - the good news is the Fedora upstream is very >> responsive, the bad news is I got sidetracked after his response. >> >> I have been told that rsyslog cannot be put in EPEL since it is >> already packaged in RHEL, be that package good or bad. Tomas has >> offered to help with the SPEC should I have any problems, but it looks >> like we're on our own for the time being. >> >> RPM package distribution can be done to various depths. The simplest >> is to just provide both the SRPM and unsigned binary RPMs for a few >> chosen CPU architectures for each packaged release as an HTTP or FTP >> download. This would allow one-off installations (updates would be >> manual) and generally get the package 'out there' for use. Further >> steps would involve signing the binaries and possibly publishing a >> repo that users could subscribe to (using /etc/yum.* or equivalent) >> for automated updates. >> >> Distributing a binary package in whatever form is going to increase >> the load (however mildly) on the project - each release will involve >> compiling and distributing binaries and SRPMs, if not signing them as >> well. I can work with you [Rainer] to automate that process, but as a >> random user I should probably not be doing the compilation and signing >> myself. >> >> So, we have 4 basic questions: >> 1. What versions are desired? >> 2. Are there any rsyslog components or functionality not packaged in >> the Fedora distribution users here would like to see included? >> 3. Do we want to sign the packages? >> 4. Who will perform the compilation/signing? >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Thu Feb 26 18:13:57 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 09:13:57 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 26 Feb 2009, Rainer Gerhards wrote: > Hi David, > > I think you got lost in the callbacks. yep, that's what I meant by the 'twisty maze of helper functions' > The multiple send calls are not for multiple actions. This is all for > one action. That code was contributed as part of the IPv6 port. I > verified the implementation with what I could find as references to > sending on IPv6 and think the implementation uses proper procedures for > that environment. > > In essence, on an IPv6-enabled system, you will receive multiple sockets > that you potentially can use to send the message. What the code does is > iterate over these sockets and see which one really works. There is also > an option (not checked but pretty sure) that permits sending to all > receivers. I think that was the other situation you have seen. this I definantly don't understand. I haven't done much coding in this area, and most of what I have done ends up being cut-n-paste out of the 'linux application programming' book examples (which are supposed to work for IPv6 as well as v4) > The listen socket is NOT being reused for sending. when I chased down the callback functions to find what function created the sockets, the only thing that I found was a routine that looked like it was going through the config options to create sockets for all the listening ports. > RFC3164 actually > recommends that port 514 is used as the source port, and we had a > lengthy discussion at the IETF about this recommendation. The bottom > line is that you cannot reuse the receive socket on a highly parallel > syslogd because each thread needs its own (or you have even more sync). > Rsyslog creates a new (set of) send sockets *per action*. if you don't do a bind on the socket you can't specify the source port. if you do bind on the socket and set the source port to 514 aren't you generating a conflict between the multiple send sockets? > I guess part of the confusion stems back from your understanding of > sysklogd code. Sysklogd works totally different here. probably. > I hope this clarifies a bit. I will try to have a look at the code > provided asap and see what I can do. Its unfortunately still very busy, > so I can not commit when I will finally start. thanks. I'll keep poking at this. David Lang > HTH > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Wednesday, February 25, 2009 9:47 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] UDP source forging. >> >> figuring out how to do this is navigating a twisty maze of helper >> functions, all different ;-) >> >> there are a few things that look odd here if I am reading the code >> properly. >> >> rsyslog makes one call to the UDPSend routine for all forwarded >> messages, >> this means that they must all send the same format. >> >> the UDPSend routine then walks through all destinations attempting to >> send >> the message to them. and considers the message successfully sent if > any >> of >> them can be sent. I would have expected that it would only be >> considered >> successful if all of them succeded. >> >> UDPSend attempts to use the sockets that were created to listening for >> messages to send it's message out. in a multi-homed machine the local >> IP >> address of those sockets may not be appropriate for the relay. also, >> what >> would happen if a system recieves via TCP and forwards via UDP and so >> doesn't have any UDP listener sockets. >> >> >> so now, my suggestion >> >> On Linux in /etc/sysctl.conf add the line >> >> net.ipv4.ip_nonlocal_bind=1 >> >> this tells the kernel not to fail bind requests to IP addresses that >> don't >> exist on the box >> >> then in omfwd.c >> >> in the routine that calls UDPSend, modify it to pass the source IP >> address >> of the message to UDPSend >> >> create a new filehandle array to use for outbound messages (one >> filehandle >> for each destination since they may end up with different source IPs) >> >> >> in UDPSend >> >> three options. >> >> >> 1. default >> >> use the appropriate filehandle for each destination and send the >> message. this is similar to what currently takes place, but instead of >> walking through each open socket for each destination, there should >> only >> be one sendto per destination. when opening the socket it should not > be >> nessasary to do a bind, just issue the socket call. >> >> if there is anything in the syslog standard specifying the source >> port >> (I don't think there is, although many implementations use port 514 >> becouse they do the same thing that rsyslog is doing and re-use >> listening >> sockets to send messages) >> >> >> 2. randomize source ports to support external load balancers >> >> same as default, except that every X (configurable) messages close >> and >> re-open the sockets. >> >> the reason for this is that each time a message is first sent the > OS >> picks a random source port that will be used for all messages sent >> through >> that socket. by closing the socket once in a while, load balancers > that >> balance based on source IP + source port + destination IP + > destination >> port will be able to function (a similar feature for TCP based >> transports >> would be useful for the same reason) >> >> >> 3. forge the source IP/port >> >> for each message that is sent, open a new socket, then issue a >> 'bind' >> command for that socket (filehandle) that sets the local IP address to >> the >> IP address that the message initially came from, then issue the > sendto, >> then close the filehandle. >> >> there is no need for an array of sockets in this case as the socket >> needs to be re-opened for each message/destination. in theory there is >> a >> possibility of a performance gain by keeping sockets open and re-using >> them, but since each socket is unique to the sender + destination > there >> would be a large number of sockets and a low probability of re-using a >> socket for the next message. >> >> in sysklogd I implemented #2 with the simple code below (once I > created >> a >> different filehandle to use for outbound connections) >> >> this closed and re-opened the socket for each message, doing it every > X >> messages would save on the overhead and be just as good in practice. >> >> the bind command that's commented out is basicly what would be needed >> for >> #3, but with real values for the source.sin_addr.s_addr (and >> source.sin_port if you wanted to forge the port as well, leaving it >> zero >> lets the OS pick a port number) >> >> if (finet >0) { >> /* close and re-open the outbound socket after each message > so >> that the source port is randomized and load balancers can distribute >> the messages */ >> close(finet); >> finet = create_inet_socket(); >> /* if we want to forge the source IP for the outbound > packets, >> this is the place to do it by seeting the IP address to the address we >> received the message from >> struct sockaddr_in source; >> source.sin_addr.s_addr = 0x00000000; >> source.sin_port = 0x0000; >> bind(finet,(struct sockaddr *) >> &source,sizeof(source));*/ >> } >> >> >> the create_inet_socket() routine is: >> >> static int create_inet_socket() >> { >> int fd, on = 1; >> int sockflags; >> >> fd = socket(AF_INET, SOCK_DGRAM, 0); >> if (fd < 0) { >> logerror("syslog: Unknown protocol, suspending inet >> service."); >> return fd; >> } >> >> if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, \ >> (char *) &on, sizeof(on)) < 0 ) { >> logerror("setsockopt(REUSEADDR), suspending inet"); >> close(fd); >> return -1; >> } >> /* We must not block on the network socket, in case a packet >> * gets lost between select and recv, otherise the process >> * will stall until the timeout, and other processes trying > to >> * log will also stall. >> */ >> if ((sockflags = fcntl(fd, F_GETFL)) != -1) { >> sockflags |= O_NONBLOCK; >> /* >> * SETFL could fail too, so get it caught by the >> subsequent >> * error check. >> */ >> sockflags = fcntl(fd, F_SETFL, sockflags); >> } >> if (sockflags == -1) { >> logerror("fcntl(O_NONBLOCK), suspending inet"); >> close(fd); >> return -1; >> } >> return fd; >> } >> >> >> this isn't a patch like you asked for and I offered to put togeather, >> but >> is it enough to clearly explain this? if not I can continue to work on >> the >> patch. >> >> David Lang >> >> On Tue, 24 Feb 2009, Rainer Gerhards wrote: >> >>> David, >>> >>> Excellent, please do as you have time. I'll make sure it fits. >>> Thread-safety, btw., is not a big issue at this level as the output >>> modules are guaranteed to be never called by multiple threads >>> concurrently. That was a trade-off to enable other folks to easily >> write >>> them (but I have an option in the back of my head that a module can >> tell >>> the engine it *is* capable to run on multiple threads >> concurrently...). >>> >>> Rainer >>> >>>> -----Original Message----- >>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >>>> Sent: Tuesday, February 24, 2009 9:43 AM >>>> To: rsyslog-users >>>> Subject: Re: [rsyslog] UDP source forging. >>>> >>>> On Tue, 24 Feb 2009, Rainer Gerhards wrote: >>>> >>>>> Hi David et all, >>>>> >>>>> Currently rsyslog does not support this and I have to admit I was >>>> always >>>>> very hesitant to add it (I see potential for misuse). Co- >>>> incidentally, I >>>>> received a similar request and was about to relay it to the > mailing >>>> list >>>>> to gather feedback. As it looks, this no longer is necessary ;) >>>>> >>>>> When I thought about implementation, I originally thought about > raw >>>>> sockets (which indeed require root access), but if there is any >>> other >>>>> way, I would be most interested. If you can provide some code, I >>> will >>>>> happily integrate it. I think an addition to the omfwd module, in >>> udp >>>>> forwarding, together with a new directive > ($SpoofOriginalUDPAddress >>>> or >>>>> so...) would be the right way to go. >>>> >>>> I'll see about hacking in some example code (probably without any >>>> config >>>> option and not thread-safe) and send it to you. >>>> >>>> there's another similar change in the same area that I was looking >> at, >>>> I'll mock it up as well. >>>> >>>> David Lang >>>> >>>>> Rainer >>>>> >>>>>> -----Original Message----- >>>>>> From: rsyslog-bounces at lists.adiscon.com >>>>>> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of >>>> david at lang.hm >>>>>> Sent: Tuesday, February 24, 2009 4:40 AM >>>>>> To: rsyslog-users >>>>>> Subject: Re: [rsyslog] UDP source forging. >>>>>> >>>>>> On Mon, 23 Feb 2009, RB wrote: >>>>>> >>>>>>> On Mon, Feb 23, 2009 at 18:11, wrote: >>>>>>>> I have a need to use some products that are stupid enough >>>>>> to ignore the >>>>>>>> host field in the syslog message and instead base >>>>>> everything on the IP >>>>>>>> address the message originates from. >>>>>>>> >>>>>>>> some other syslog servers can handle this by forging the >>>>>> source of the UDP >>>>>>>> packet, can rsyslog do this? >>>>>>> >>>>>>> So is rsyslog originating the messages, or are you using it to >>>>>>> aggregate them and then feed them on to the other [bad] >>>>>> acceptors? I >>>>>>> am unaware of a way to get rsyslog to forge packets (short >>>>>> of writing >>>>>>> an output module), but unless you must get another syslog >>>>>> daemon into >>>>>>> the mix, you may be better off just feeding your messages >>>>>> directly to >>>>>>> the other collector. >>>>>> >>>>>> rsyslog would be the relay from one non-routed network to another >>>>>> non-routed network. >>>>>> >>>>>> this could be a fairly simple change to the UDP output module >>>>>> (adding a >>>>>> couple commands around the sending of a message), but before >>>>>> I dove in to >>>>>> do that I wanted to see if I had missed this feature anywhere. >>>>>> >>>>>> David Lang >>>>>> _______________________________________________ >>>>>> rsyslog mailing list >>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>> http://www.rsyslog.com >>>>>> >>>>> _______________________________________________ >>>>> rsyslog mailing list >>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>> http://www.rsyslog.com >>>>> >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 26 18:16:15 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 18:16:15 +0100 Subject: [rsyslog] UDP source forging. References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Just one quick answer (on the leave) > > RFC3164 actually > > recommends that port 514 is used as the source port, and we had a > > lengthy discussion at the IETF about this recommendation. The bottom > > line is that you cannot reuse the receive socket on a highly parallel > > syslogd because each thread needs its own (or you have even more > sync). > > Rsyslog creates a new (set of) send sockets *per action*. > > if you don't do a bind on the socket you can't specify the source port. > if > you do bind on the socket and set the source port to 514 aren't you > generating a conflict between the multiple send sockets? I am ignoring the RFC recommendation. It is also removed from the soon-to-appear RFC5424. I should have mentioned this... Rainer From bakers at web-ster.com Thu Feb 26 19:00:43 2009 From: bakers at web-ster.com (Scott Baker) Date: Thu, 26 Feb 2009 10:00:43 -0800 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> Message-ID: <49A6D8CB.1010506@web-ster.com> On 02/25/2009 03:38 PM, (private) HKS wrote: >> Does this syntax work on rsyslog 2.0.x, that's what my server has on it. >> I've tried this syntax, but it's not logging. >> >> - Scott > > > No, this will require 3+ - which you really should upgrade to anyway. That's what I figured... this is my CORE syslog server, so I'll need to play a good upgrade proceedure. Is their documentation on configuration file changes going from 2.x to 3.x? - Scott From mbiebl at gmail.com Fri Feb 27 01:55:14 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Fri, 27 Feb 2009 01:55:14 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: 2009/2/26 : > even where rsyslog is included in a distro it's very handy to have a spec > file (or debian equivalent) included with the source to allow a 'make rpm' > or 'make deb' to properly make packages. > > I've been using checkinstall to create debian packages from the compiled > source, and I don't know what it's doing wrong, but I've been tripped up a > few times by it not replacing all the files that it should if rsyslog is > already installed (the packages it creates work just fine if rsyslog isn't > installed at all) FWIW, I as Debian maintainer of rsyslog, explicitly asked Rainer to remove the debian/ directory from the upstream source tree. Reason is simple: Packaging is the task of the downstream distros and the files shipped upstream were always out-of-date anyways. This not only caused more work for me as Debian maintainer but also leads to bad user experience if the rpm/debs created from the upstream spec/debian build files are outdated and potentially create a half-way broken package. If the fedora bits are kept in an entirely separate upstream packaging branch, then I don't really care. But I wouldn't like to see them (or any debian related files) shipped in a release tarball. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From david at lang.hm Fri Feb 27 04:20:37 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 19:20:37 -0800 (PST) Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: On Fri, 27 Feb 2009, Michael Biebl wrote: > 2009/2/26 : >> even where rsyslog is included in a distro it's very handy to have a spec >> file (or debian equivalent) included with the source to allow a 'make rpm' >> or 'make deb' to properly make packages. >> >> I've been using checkinstall to create debian packages from the compiled >> source, and I don't know what it's doing wrong, but I've been tripped up a >> few times by it not replacing all the files that it should if rsyslog is >> already installed (the packages it creates work just fine if rsyslog isn't >> installed at all) > > > FWIW, I as Debian maintainer of rsyslog, explicitly asked Rainer to > remove the debian/ directory from the upstream source tree. Reason is > simple: Packaging is the task of the downstream distros and the files > shipped upstream were always out-of-date anyways. This not only caused > more work for me as Debian maintainer but also leads to bad user > experience if the rpm/debs created from the upstream spec/debian build > files are outdated and potentially create a half-way broken package. > > If the fedora bits are kept in an entirely separate upstream packaging > branch, then I don't really care. > But I wouldn't like to see them (or any debian related files) shipped > in a release tarball. so how am I (a debian user) supposed to create debian compatible packages for versions that you don't yet deal with? why couldn't you push the debian related files upstream and maintain them there? (submitting patches, or git pull requests for updates) David Lang From david at lang.hm Fri Feb 27 08:40:18 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 23:40:18 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 26 Feb 2009, Rainer Gerhards wrote: > Just one quick answer (on the leave) > >>> RFC3164 actually >>> recommends that port 514 is used as the source port, and we had a >>> lengthy discussion at the IETF about this recommendation. The bottom >>> line is that you cannot reuse the receive socket on a highly > parallel >>> syslogd because each thread needs its own (or you have even more >> sync). >>> Rsyslog creates a new (set of) send sockets *per action*. >> >> if you don't do a bind on the socket you can't specify the source > port. >> if >> you do bind on the socket and set the source port to 514 aren't you >> generating a conflict between the multiple send sockets? > > I am ignoring the RFC recommendation. It is also removed from the > soon-to-appear RFC5424. I should have mentioned this... good, that clarifies things a lot. I think I see a significant simplification here. getaddrinfo can return a bunch of different addrinfo structures, which you walk through and try to send to each one until you find one that works. based on the man page for this I see the following reasons for multiple sockets 1. number of IP stacks (IPv4 vs IPv6 vs both) 2. multiple interfaces (and potentially multiple IPs if hostname resolves to more than one) the number of structures that you get back is #1 * #2. however, I don't think that you need to go through this. since you maintain a instance of omfwd for each action (i.e. destination), you should be able to figure out what will work and not waste any time dealing with the others. when you lookup the destination address to send to, you should be able to find out if it's an IPv4 or an IPv6 address. If you have both pick one to use (arguments can be made as to which is the best to use, pick one to default to and have a config option to override it) If you get multiple addresses, use the first one. at this point you have one socket of the correct type to send to that destination. attempting to send to each one until you get sucess works, and may be more robust, but it's a significant amount of complication and overhead that you shouldn't need to go through. I think the basic changes needed to support forging the address are something like this (whitespace munged by cut-n-paste) diff --git a/tools/omfwd.c b/tools/omfwd.c index 1dd184e..1112db6 100644 --- a/tools/omfwd.c +++ b/tools/omfwd.c @@ -193,6 +193,15 @@ static rsRetVal UDPSend(instanceData *pData, char *msg, size_t len) int bSendSuccess; if(pData->pSockArray != NULL) { + /* close and re-open sockets for two possilbe reasons + * so that the source port is randomized again (to support load balancers + * so that we can bind to them to forge the from address on the packet + * this should be conditional on config options (including how frequently to do this) + * David Lang 2009-02-25 + */ + net.closeUDPListenSockets(pData->pSockArray); + pData->pSockArray = net.create_udp_socket((uchar*)pData->f_hname, NULL, 0); + /* we need to track if we have success sending to the remote * peer. Success is indicated by at least one sendto() call * succeeding. We track this be bSendSuccess. We can not simply @@ -203,6 +212,15 @@ static rsRetVal UDPSend(instanceData *pData, char *msg, size_t len) bSendSuccess = FALSE; for (r = pData->f_addr; r; r = r->ai_next) { for (i = 0; i < *pData->pSockArray; i++) { + /* if we are forging the source IP of the packet, issue the bind to do so + * this should be made conditional on a config option -- David Lang 2009-02-25 + * since I don't know how to get the correct source IP, I'll set it to look + * like it comes from 10.201.1.1 IPv4 + */ + + + struct sockaddr_in source; + memset(&source,0,sizeof(source)); + source.sin_family = AF_INET; + source.sin_addr.s_addr = 0x0101c90a; + source.sin_port = 0x0000; + +/* bind(pData->pSockArray[i+1],(struct sockaddr *) &source,sizeof(source)); +*/ + lsent = sendto(pData->pSockArray[i+1], msg, len, 0, r->ai_addr, r->ai_addrlen); if (lsent == len) { bSendSuccess = TRUE; this works for reopening the socket each time, but if I uncomment the bind the sendto fails (error 22, invalid input) I haven't yet figured out what I'm missing on the bind that's causing this David Lang From patrick.shen at net-m.de Fri Feb 27 07:59:40 2009 From: patrick.shen at net-m.de (Patrick Shen) Date: Fri, 27 Feb 2009 14:59:40 +0800 Subject: [rsyslog] Weird fromhost property value Message-ID: <49A78F5C.3000400@net-m.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I've utilized rsyslog as my company's central logging server for half a year. Today I encounterd a very weird issue about value of fromhost property. We use dynamic templates to store logs from clients. The template is like below: $template d_hosts,"/var/rsyslog/HOSTS/%fromhost%/%$year%/%$month%/%syslogfacility-text%_%fromhost%_%$year%_%$month%_%$day %.log" You can see we group logs by fromhost value. Today, I did 3 times test that a client named (sobek) sent logs to central logging server by UDP, TCP and RELP. The FQDN of client node is "sobek.net-m.internal", short name is "sobek", ip address is "172.21.101.13". After testing, I got when sending via UDP, the fromhost value is short name. And via TCP, the value is FQDN. Via RELP, the value is IP address. So I got a very weird directory organization at "/var/rsyslog/HOSTS". ########################################################################## drwxr-x--- 3 root syslog 80 Feb 27 07:24 172.21.101.13 <- RELP drwxr-x--- 3 root syslog 80 Feb 27 05:58 sobek <- UDP drwxr-x--- 3 root syslog 80 Feb 27 06:03 sobek.net-m.internal <- TCP ########################################################################## We are running rsyslog 3.20.0 both on client and server. So I wanna know if any other has encountered this before? Thanks, Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJp49ckHhYtFevC+MRApbbAJ9Dgxtw5mf+ax9D81OZPfh5E9aJPgCdEqF/ FlkFDJpWr4k6pVV4AQiLhRw= =cQzr -----END PGP SIGNATURE----- From david at lang.hm Fri Feb 27 09:03:54 2009 From: david at lang.hm (david at lang.hm) Date: Fri, 27 Feb 2009 00:03:54 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 26 Feb 2009, david at lang.hm wrote: > > this works for reopening the socket each time, but if I uncomment the bind > the sendto fails (error 22, invalid input) > > I haven't yet figured out what I'm missing on the bind that's causing this a little more testing and I find that the bind succeeds, but no traffic goes out unless the source IP exists somewhere on the box (it can be bound to lo:0, but it needs to exist) so the non-local-bind approach may not work :-( it's just hit midnight here, so I'm going to call it a night and try again tomorrow. David Lang From nico at altiva.fr Fri Feb 27 18:05:19 2009 From: nico at altiva.fr (NM) Date: Fri, 27 Feb 2009 17:05:19 +0000 (UTC) Subject: [rsyslog] rsyslog and load balancers References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> <577465F99B41C842AAFBE9ED71E70ABA44FCB6@grfint2.intern.adiscon.com> Message-ID: On Mon, 23 Feb 2009 17:44:58 +0100, Rainer Gerhards wrote: > I couldn't stand this Well unfortunately many companies have this nonsense bullshit added at the server (read: Exchange) level. One company I worked for even added a 10kB gif logo to *every* single outgoing mail, on top of 5kB of (uneforceable, useless) legalese. From rgerhards at hq.adiscon.com Fri Feb 27 18:36:18 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 27 Feb 2009 18:36:18 +0100 Subject: [rsyslog] rsyslog and load balancers References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local><577465F99B41C842AAFBE9ED71E70ABA44FCB6@grfint2.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71ED7@GRFEXC.intern.adiscon.com> Well... and the funny thing is in Germany is part of this even required by law... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of NM > Sent: Friday, February 27, 2009 6:05 PM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] rsyslog and load balancers > > On Mon, 23 Feb 2009 17:44:58 +0100, Rainer Gerhards wrote: > > > I couldn't stand this > > Well unfortunately many companies have this nonsense bullshit added at > the server (read: Exchange) level. One company I worked for even added > a > 10kB gif logo to *every* single outgoing mail, on top of 5kB of > (uneforceable, useless) legalese. > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From Luis.Fernando.Munoz.Mejias at cern.ch Fri Feb 27 18:48:56 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Fri, 27 Feb 2009 18:48:56 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC08@grfint2.intern.adiscon.com> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> <577465F99B41C842AAFBE9ED71E70ABA44FC08@grfint2.intern.adiscon.com> Message-ID: <200902271848.56481.Luis.Fernando.Munoz.Mejias@cern.ch> Rainer, Good and bad news... > > That sounds really great. Before you start coding or preparing > > anything, let me check how well our DBs perform, because it's not > > yet clear if they'll be able to cope with the high insertion rate we > > expect. If we don't go for the Oracle database this work doesn't > > make sense. I bet we'll want the Oracle, anyways. > > Sounds fair. Good news: I did my tests and, for many tasks I need to do, Oracle is our way to go. So, I'm willing to write the module, with your guidance/advise. As I said, I need **excellent** performance. I definitely need batch operations, the ability to prepare the statements given as arguments on the configuration file, and not to commit entries one by one, but after a number of entries are ready or (better) after some not so small time. According to the advise I got from experts around here, I'll have to use Oracle Call Interface for this module, I don't know if there are any licensing issues. It seems I'll have to review how rsyslog's queing modules work... > > For this evaluation, I already have a timestamp formatter that fits > > into Oracle, something that can be used with the property replacer, > > like %timereported:::date-oracle%. > The bad news is that this timestamp formatter works perfectly on interactive sessions (sqlplus) but not on non-interactive ones, f.i, in Python scripts. You need to call Oracle's to_timestamp(string, format), and by bloating your code with this ugly function the rfc-3339 formatter is good enough. So I won't submit this one. Cheers. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From aoz.syn at gmail.com Fri Feb 27 19:42:49 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 27 Feb 2009 11:42:49 -0700 Subject: [rsyslog] Weird fromhost property value In-Reply-To: <49A78F5C.3000400@net-m.de> References: <49A78F5C.3000400@net-m.de> Message-ID: <4255c2570902271042l44d437c9kaa13ff01c509fcc2@mail.gmail.com> On Thu, Feb 26, 2009 at 23:59, Patrick Shen wrote: > You can see we group logs by fromhost value. > > Today, I did 3 times test that a client named (sobek) sent logs to > central logging server by UDP, TCP and RELP. > > The FQDN of client node is "sobek.net-m.internal", short name is > "sobek", ip address is "172.21.101.13". > > After testing, I got when sending via UDP, the fromhost value is short > name. And via TCP, the value is FQDN. Via RELP, the value is IP address. > > So I got a very weird directory organization at "/var/rsyslog/HOSTS". > > ########################################################################## > drwxr-x--- 3 root syslog 80 Feb 27 07:24 172.21.101.13 ? ? ? ? <- RELP > drwxr-x--- 3 root syslog 80 Feb 27 05:58 sobek ? ? ? ? ? ? ? ? <- UDP > drwxr-x--- 3 root syslog 80 Feb 27 06:03 sobek.net-m.internal ?<- TCP > ########################################################################## I've tried something similar and eventually gave up and started using the 'fromhost-ip' property to create per-sender templates. Of course, fromhost* falls down once you have relays in the mix, but that's another problem to solve. From mbiebl at gmail.com Sat Feb 28 02:58:34 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Sat, 28 Feb 2009 02:58:34 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: 2009/2/27 : > On Fri, 27 Feb 2009, Michael Biebl wrote: > >> 2009/2/26 ?: >>> even where rsyslog is included in a distro it's very handy to have a spec >>> file (or debian equivalent) included with the source to allow a 'make rpm' >>> or 'make deb' to properly make packages. >>> >>> I've been using checkinstall to create debian packages from the compiled >>> source, and I don't know what it's doing wrong, but I've been tripped up a >>> few times by it not replacing all the files that it should if rsyslog is >>> already installed (the packages it creates work just fine if rsyslog isn't >>> installed at all) >> >> >> FWIW, I as Debian maintainer of rsyslog, explicitly asked Rainer to >> remove the debian/ directory from the upstream source tree. Reason is >> simple: Packaging is the task of the downstream distros and the files >> shipped upstream were always out-of-date anyways. This not only caused >> more work for me as Debian maintainer but also leads to bad user >> experience if the rpm/debs created from the upstream spec/debian build >> files are outdated and potentially create a half-way broken package. >> >> If the fedora bits are kept in an entirely separate upstream packaging >> branch, then I don't really care. >> But I wouldn't like to see them (or any debian related files) shipped >> in a release tarball. > > so how am I (a debian user) supposed to create debian compatible packages > for versions that you don't yet deal with? > > why couldn't you push the debian related files upstream and maintain them > there? (submitting patches, or git pull requests for updates) Pretty simple: It's less work for me and Rainer and more flexible. Say I (for Debian) start adding the files upstream, so does Fedora, BSD, etc... Now when Rainer wants to make a new release to not have any stale packaging files, he would have to ping all package maintainer first to update the build files and push those changes. That simply doesn't scale. Packaging and upstream software releases should be decoupled. If you are really interested in the Debian Packaging, you can grab the git repository from [1] and either work from there or at it as a "remote" to the rsyslog git repo and merge the debian specific bits. Cheers, Michael [1] http://git.debian.org/?p=collab-maint/rsyslog.git;a=summary -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From david at lang.hm Sat Feb 28 03:16:15 2009 From: david at lang.hm (david at lang.hm) Date: Fri, 27 Feb 2009 18:16:15 -0800 (PST) Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: On Sat, 28 Feb 2009, Michael Biebl wrote: >>> >>> If the fedora bits are kept in an entirely separate upstream packaging >>> branch, then I don't really care. >>> But I wouldn't like to see them (or any debian related files) shipped >>> in a release tarball. >> >> so how am I (a debian user) supposed to create debian compatible packages >> for versions that you don't yet deal with? >> >> why couldn't you push the debian related files upstream and maintain them >> there? (submitting patches, or git pull requests for updates) > > Pretty simple: It's less work for me and Rainer and more flexible. > Say I (for Debian) start adding the files upstream, so does Fedora, BSD, etc... > Now when Rainer wants to make a new release to not have any stale > packaging files, he would have to ping all package maintainer first to > update the build files and push those changes. That simply doesn't > scale. > Packaging and upstream software releases should be decoupled. > > If you are really interested in the Debian Packaging, you can grab the > git repository from [1] and either work from there or at it as a > "remote" to the rsyslog git repo and merge the debian specific bits. it's not that I'm interested in debian packaging, it's that I need to install the stuff that you haven't decided to ship in debian yet on my debian system in such a way that I keep the package manager happy (and don't have it overwriting what I've compiled with an update of an obsolete version) it's not that the upstream version of the files need to be perfect, but they should be good enough to avoid the need for users to have to fight the packaging system and duplicate your efforts. I hate to have to pull in some stuff from your tree and combine it with stuff from the upstream tree because I don't know enough to be sure that I'm both pulling everything I need and not pulling something that will cause grief. you've made your decision, count this as one voice disagreeing with that decision. David Lang From rgerhards at hq.adiscon.com Thu Feb 26 18:46:27 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 18:46:27 +0100 Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Message-ID: <1235670387.28865.2.camel@rf10up.intern.adiscon.com> On Sun, 2009-03-01 at 23:56 -0800, david at lang.hm wrote: > On Fri, 27 Feb 2009, david at lang.hm wrote: > > > On Thu, 26 Feb 2009, david at lang.hm wrote: > > > >> > >> this works for reopening the socket each time, but if I uncomment the bind > >> the sendto fails (error 22, invalid input) > >> > >> I haven't yet figured out what I'm missing on the bind that's causing this > > > > a little more testing and I find that the bind succeeds, but no traffic goes > > out unless the source IP exists somewhere on the box (it can be bound to > > lo:0, but it needs to exist) > > > > so the non-local-bind approach may not work :-( > > > > it's just hit midnight here, so I'm going to call it a night and try again > > tomorrow. > > I abandoned this approach and spent the weekend learning how to do raw > sockets. I found a library that makes it not that bad to do (at least for > the IPv4 that I've done so far, IPv6 adds some wrinkles) > > the one thing thats not clear to me at this point is how to find the > original source IP of the message. Is that available in a variable inside > UDPSend, or is it something that I will have to get earlier in the process > and then pass explicitly to UDPSend? Actually, output modules do not receive access to the full message object. This was originally done for security reasons (do not pass more than needed). All they can receive is the strings that are passed to them. So the module would need to be modified so that a second string (like ommail) is passed and that string needs to be defined as the to-be-spoofed IP (what also enables to rewrite the source IP). >From all the discussion, it may make sense to start with a different output plugin that may later be merged back into the original one... Rainer > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Feb 2 14:41:57 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 14:41:57 +0100 Subject: [rsyslog] rsyslog 3.21.10 (beta) released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAEC@grfint2.intern.adiscon.com> Hi all, this is a bug-fixing release. Most importantly, a race that could result in a segfault, in specific scenarios, has been addressed. Also, some command-line switches were incorrectly processed and a debug string was accidentally written to stdout on daemon termination. This is a recommended update for all users of the beta branch. Change Log: http://www.rsyslog.com/Article344.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-148.phtml I hope this release is useful. Feedback is appreciated. Best regards, Rainer Gerhards From r.bhatia at ipax.at Mon Feb 2 16:34:42 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Mon, 02 Feb 2009 16:34:42 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** Message-ID: <49871292.9000900@ipax.at> hi, i do not know if this has already been addressed - so sorry for a possible duplicate. revision: > Feb 2 16:29:58 wc02 kernel: imklog 3.20.0, log source = /proc/kmsg started. > Feb 2 16:29:58 wc02 rsyslogd: [origin software="rsyslogd" swVersion="3.20.0" x-pid="27617" x-info="http://www.rsyslog.com"] restart running on debian logging remotely to another server. cheers, raoul > *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7f639a997948] > /lib/libc.so.6(cfree+0x76)[0x7f639a999a56] > /usr/sbin/rsyslogd(msgDestruct+0x3c)[0x415f7c] > /usr/sbin/rsyslogd(actionCallAction+0xcd)[0x4281cd] > /usr/sbin/rsyslogd[0x409de9] > /usr/sbin/rsyslogd(llExecFunc+0x58)[0x4168e8] > /usr/sbin/rsyslogd[0x409ad5] > /usr/sbin/rsyslogd[0x4244ef] > /usr/sbin/rsyslogd(wtiWorker+0x24f)[0x42124f] > /usr/sbin/rsyslogd[0x420968] > /lib/libpthread.so.0[0x7f639b08afc7] > /lib/libc.so.6(clone+0x6d)[0x7f639a9f35ad] > ======= Memory map: ======== > 00400000-0043c000 r-xp 00000000 09:00 384769 /usr/sbin/rsyslogd > 0053b000-00540000 rw-p 0003b000 09:00 384769 /usr/sbin/rsyslogd > 00540000-00541000 rw-p 00540000 00:00 0 > 00ebc000-00f6e000 rw-p 00ebc000 00:00 0 [heap] > 40219000-4021a000 ---p 40219000 00:00 0 > 4021a000-40a1a000 rw-p 4021a000 00:00 0 > 40c65000-40c66000 ---p 40c65000 00:00 0 > 40c66000-41466000 rw-p 40c66000 00:00 0 > 41466000-41467000 ---p 41466000 00:00 0 > 41467000-41c67000 rw-p 41467000 00:00 0 > 41cff000-41d00000 ---p 41cff000 00:00 0 > 41d00000-42500000 rw-p 41d00000 00:00 0 > 7f638c000000-7f638c021000 rw-p 7f638c000000 00:00 0 > 7f638c021000-7f6390000000 ---p 7f638c021000 00:00 0 > 7f6394000000-7f6394021000 rw-p 7f6394000000 00:00 0 > 7f6394021000-7f6398000000 ---p 7f6394021000 00:00 0 > 7f63995aa000-7f63995c0000 r-xp 00000000 09:00 128682 /lib/libgcc_s.so.1 > 7f63995c0000-7f63997c0000 ---p 00016000 09:00 128682 /lib/libgcc_s.so.1 > 7f63997c0000-7f63997c1000 rw-p 00016000 09:00 128682 /lib/libgcc_s.so.1 > 7f63997c1000-7f63997d1000 r-xp 00000000 09:00 128437 /lib/libresolv-2.7.so > 7f63997d1000-7f63999d1000 ---p 00010000 09:00 128437 /lib/libresolv-2.7.so > 7f63999d1000-7f63999d3000 rw-p 00010000 09:00 128437 /lib/libresolv-2.7.so > 7f63999d3000-7f63999d5000 rw-p 7f63999d3000 00:00 0 > 7f63999d5000-7f63999d9000 r-xp 00000000 09:00 128444 /lib/libnss_dns-2.7.so > 7f63999d9000-7f6399bd8000 ---p 00004000 09:00 128444 /lib/libnss_dns-2.7.so > 7f6399bd8000-7f6399bda000 rw-p 00003000 09:00 128444 /lib/libnss_dns-2.7.so > 7f6399bda000-7f6399bde000 r-xp 00000000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so > 7f6399bde000-7f6399cdd000 ---p 00004000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so > 7f6399cdd000-7f6399cde000 rw-p 00003000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so > 7f6399cde000-7f6399ce0000 r-xp 00000000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so > 7f6399ce0000-7f6399ddf000 ---p 00002000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so > 7f6399ddf000-7f6399de0000 rw-p 00001000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so > 7f6399de0000-7f6399de3000 r-xp 00000000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so > 7f6399de3000-7f6399ee2000 ---p 00003000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so > 7f6399ee2000-7f6399ee3000 rw-p 00002000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so > 7f6399ee3000-7f6399eed000 r-xp 00000000 09:00 128429 /lib/libnss_nis-2.7.so > 7f6399eed000-7f639a0ec000 ---p 0000a000 09:00 128429 /lib/libnss_nis-2.7.so > 7f639a0ec000-7f639a0ee000 rw-p 00009000 09:00 128429 /lib/libnss_nis-2.7.so > 7f639a0ee000-7f639a103000 r-xp 00000000 09:00 128433 /lib/libnsl-2.7.so > 7f639a103000-7f639a302000 ---p 00015000 09:00 128433 /lib/libnsl-2.7.so > 7f639a302000-7f639a304000 rw-p 00014000 09:00 128433 /lib/libnsl-2.7.so > 7f639a304000-7f639a306000 rw-p 7f639a304000 00:00 0 > 7f639a306000-7f639a30d000 r-xp 00000000 09:00 128435 /lib/libnss_compat-2.7.so > 7f639a30d000-7f639a50c000 ---p 00007000 09:00 128435 /lib/libnss_compat-2.7.so > 7f639a50c000-7f639a50e000 rw-p 00006000 09:00 128435 /lib/libnss_compat-2.7.so > 7f639a50e000-7f639a513000 r-xp 00000000 09:00 416987 /usr/lib/rsyslog/imklog.so > 7f639a513000-7f639a613000 ---p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so > 7f639a613000-7f639a614000 rw-p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so > 7f639a614000-7f639a615000 rw-p 7f639a614000 00:00 0 > 7f639a615000-7f639a617000 r-xp 00000000 09:00 416978 /usr/lib/rsyslog/imuxsock.so > 7f639a617000-7f639a717000 ---p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so > 7f639a717000-7f639a718000 rw-p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so > 7f639a718000-7f639a722000 r-xp 00000000 09:00 128440 /lib/libnss_files-2.7.so > 7f639a722000-7f639a922000 ---p 0000a000 09:00 128440 /lib/libnss_files-2.7.so > 7f639a922000-7f639a924000 rw-p 0000a000 09:00 128440 /lib/libnss_files-2.7.so > 7f639a924000-7f639aa6e000 r-xp 00000000 09:00 128443 /lib/libc-2.7.so > 7f639aa6e000-7f639ac6d000 ---p 0014a000 09:00 128443 /lib/libc-2.7.so > 7f639ac6d000-7f639ac70000 r--p 00149000 09:00 128443 /lib/libc-2.7.so > 7f639ac70000-7f639ac72000 rw-p 0014c000 09:00 128443 /lib/libc-2.7.so > 7f639ac72000-7f639ac77000 rw-p 7f639ac72000 00:00 0 > 7f639ac77000-7f639ac7f000 r-xp 00000000 09:00 128449 /lib/librt-2.7.so > 7f639ac7f000-7f639ae7e000 ---p 00008000 09:00 128449 /lib/librt-2.7.so > 7f639ae7e000-7f639ae80000 rw-p 00007000 09:00 128449 /lib/librt-2.7.so > 7f639ae80000-7f639ae82000 r-xp 00000000 09:00 128447 /lib/libdl-2.7.so > 7f639ae82000-7f639b082000 ---p 00002000 09:00 128447 /lib/libdl-2.7.so > 7f639b082000-7f639b084000 rw-p 00002000 09:00 128447 /lib/libdl-2.7.so > 7f639b084000-7f639b09a000 r-xp 00000000 09:00 128439 /lib/libpthread-2.7.so > 7f639b09a000-7f639b29a000 ---p 00016000 09:00 128439 /lib/libpthread-2.7.so > 7f639b29a000-7f639b29c000 rw-p 00016000 09:00 128439 /lib/libpthread-2.7.so > 7f639b29c000-7f639b2a0000 rw-p 7f639b29c000 00:00 0 > 7f639b2a0000-7f639b2b6000 r-xp 00000000 09:00 370185 /usr/lib/libz.so.1.2.3.3 > 7f639b2b6000-7f639b4b6000 ---p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 > 7f639b4b6000-7f639b4b7000 rw-p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 > 7f639b4b7000-7f639b4d3000 r-xp 00000000 09:00 128446 /lib/ld-2.7.so > 7f639b5bd000-7f639b5c2000 r-xp 00000000 09:00 416988 /usr/lib/rsyslog/lmnet.so > 7f639b5c2000-7f639b6c1000 ---p 00005000 09:00 416988 /usr/lib/rsyslog/lmnet.so > 7f639b6c1000-7f639b6c2000 rw-p 00004000 09:00 416988 /usr/lib/rsyslog/lmnet.so > 7f639b6c2000-7f639b6c5000 rw-p 7f639b6c2000 00:00 0 > 7f639b6ce000-7f639b6d2000 rw-p 7f639b6ce000 00:00 0 > 7f639b6d2000-7f639b6d4000 rw-p 0001b000 09:00 128446 /lib/ld-2.7.so > 7fffa36bf000-7fffa36d4000 rw-p 7ffffffea000 00:00 0 [stack] > 7fffa36ff000-7fffa3700000 r-xp 7fffa36ff000 00:00 0 [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] From rgerhards at hq.adiscon.com Mon Feb 2 17:29:26 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 17:29:26 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <49871292.9000900@ipax.at> References: <49871292.9000900@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAF0@grfint2.intern.adiscon.com> This is probably the result of the data race I described in details last week. You need to pull the newest releases. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Monday, February 02, 2009 4:35 PM > To: rsyslog-users > Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double > free or corruption (!prev): 0x0000000000ef03b0 *** > > hi, > > i do not know if this has already been addressed - so sorry for > a possible duplicate. > > revision: > > Feb 2 16:29:58 wc02 kernel: imklog 3.20.0, log source = /proc/kmsg > started. > > Feb 2 16:29:58 wc02 rsyslogd: [origin software="rsyslogd" > swVersion="3.20.0" x-pid="27617" x-info="http://www.rsyslog.com"] > restart > > running on debian logging remotely to another server. > > cheers, > raoul > > > *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption > (!prev): 0x0000000000ef03b0 *** > > ======= Backtrace: ========= > > /lib/libc.so.6[0x7f639a997948] > > /lib/libc.so.6(cfree+0x76)[0x7f639a999a56] > > /usr/sbin/rsyslogd(msgDestruct+0x3c)[0x415f7c] > > /usr/sbin/rsyslogd(actionCallAction+0xcd)[0x4281cd] > > /usr/sbin/rsyslogd[0x409de9] > > /usr/sbin/rsyslogd(llExecFunc+0x58)[0x4168e8] > > /usr/sbin/rsyslogd[0x409ad5] > > /usr/sbin/rsyslogd[0x4244ef] > > /usr/sbin/rsyslogd(wtiWorker+0x24f)[0x42124f] > > /usr/sbin/rsyslogd[0x420968] > > /lib/libpthread.so.0[0x7f639b08afc7] > > /lib/libc.so.6(clone+0x6d)[0x7f639a9f35ad] > > ======= Memory map: ======== > > 00400000-0043c000 r-xp 00000000 09:00 384769 > /usr/sbin/rsyslogd > > 0053b000-00540000 rw-p 0003b000 09:00 384769 > /usr/sbin/rsyslogd > > 00540000-00541000 rw-p 00540000 00:00 0 > > 00ebc000-00f6e000 rw-p 00ebc000 00:00 0 > [heap] > > 40219000-4021a000 ---p 40219000 00:00 0 > > 4021a000-40a1a000 rw-p 4021a000 00:00 0 > > 40c65000-40c66000 ---p 40c65000 00:00 0 > > 40c66000-41466000 rw-p 40c66000 00:00 0 > > 41466000-41467000 ---p 41466000 00:00 0 > > 41467000-41c67000 rw-p 41467000 00:00 0 > > 41cff000-41d00000 ---p 41cff000 00:00 0 > > 41d00000-42500000 rw-p 41d00000 00:00 0 > > 7f638c000000-7f638c021000 rw-p 7f638c000000 00:00 0 > > 7f638c021000-7f6390000000 ---p 7f638c021000 00:00 0 > > 7f6394000000-7f6394021000 rw-p 7f6394000000 00:00 0 > > 7f6394021000-7f6398000000 ---p 7f6394021000 00:00 0 > > 7f63995aa000-7f63995c0000 r-xp 00000000 09:00 128682 > /lib/libgcc_s.so.1 > > 7f63995c0000-7f63997c0000 ---p 00016000 09:00 128682 > /lib/libgcc_s.so.1 > > 7f63997c0000-7f63997c1000 rw-p 00016000 09:00 128682 > /lib/libgcc_s.so.1 > > 7f63997c1000-7f63997d1000 r-xp 00000000 09:00 128437 > /lib/libresolv-2.7.so > > 7f63997d1000-7f63999d1000 ---p 00010000 09:00 128437 > /lib/libresolv-2.7.so > > 7f63999d1000-7f63999d3000 rw-p 00010000 09:00 128437 > /lib/libresolv-2.7.so > > 7f63999d3000-7f63999d5000 rw-p 7f63999d3000 00:00 0 > > 7f63999d5000-7f63999d9000 r-xp 00000000 09:00 128444 > /lib/libnss_dns-2.7.so > > 7f63999d9000-7f6399bd8000 ---p 00004000 09:00 128444 > /lib/libnss_dns-2.7.so > > 7f6399bd8000-7f6399bda000 rw-p 00003000 09:00 128444 > /lib/libnss_dns-2.7.so > > 7f6399bda000-7f6399bde000 r-xp 00000000 09:00 416980 > /usr/lib/rsyslog/lmnsd_ptcp.so > > 7f6399bde000-7f6399cdd000 ---p 00004000 09:00 416980 > /usr/lib/rsyslog/lmnsd_ptcp.so > > 7f6399cdd000-7f6399cde000 rw-p 00003000 09:00 416980 > /usr/lib/rsyslog/lmnsd_ptcp.so > > 7f6399cde000-7f6399ce0000 r-xp 00000000 09:00 416981 > /usr/lib/rsyslog/lmtcpclt.so > > 7f6399ce0000-7f6399ddf000 ---p 00002000 09:00 416981 > /usr/lib/rsyslog/lmtcpclt.so > > 7f6399ddf000-7f6399de0000 rw-p 00001000 09:00 416981 > /usr/lib/rsyslog/lmtcpclt.so > > 7f6399de0000-7f6399de3000 r-xp 00000000 09:00 416985 > /usr/lib/rsyslog/lmnetstrms.so > > 7f6399de3000-7f6399ee2000 ---p 00003000 09:00 416985 > /usr/lib/rsyslog/lmnetstrms.so > > 7f6399ee2000-7f6399ee3000 rw-p 00002000 09:00 416985 > /usr/lib/rsyslog/lmnetstrms.so > > 7f6399ee3000-7f6399eed000 r-xp 00000000 09:00 128429 > /lib/libnss_nis-2.7.so > > 7f6399eed000-7f639a0ec000 ---p 0000a000 09:00 128429 > /lib/libnss_nis-2.7.so > > 7f639a0ec000-7f639a0ee000 rw-p 00009000 09:00 128429 > /lib/libnss_nis-2.7.so > > 7f639a0ee000-7f639a103000 r-xp 00000000 09:00 128433 > /lib/libnsl-2.7.so > > 7f639a103000-7f639a302000 ---p 00015000 09:00 128433 > /lib/libnsl-2.7.so > > 7f639a302000-7f639a304000 rw-p 00014000 09:00 128433 > /lib/libnsl-2.7.so > > 7f639a304000-7f639a306000 rw-p 7f639a304000 00:00 0 > > 7f639a306000-7f639a30d000 r-xp 00000000 09:00 128435 > /lib/libnss_compat-2.7.so > > 7f639a30d000-7f639a50c000 ---p 00007000 09:00 128435 > /lib/libnss_compat-2.7.so > > 7f639a50c000-7f639a50e000 rw-p 00006000 09:00 128435 > /lib/libnss_compat-2.7.so > > 7f639a50e000-7f639a513000 r-xp 00000000 09:00 416987 > /usr/lib/rsyslog/imklog.so > > 7f639a513000-7f639a613000 ---p 00005000 09:00 416987 > /usr/lib/rsyslog/imklog.so > > 7f639a613000-7f639a614000 rw-p 00005000 09:00 416987 > /usr/lib/rsyslog/imklog.so > > 7f639a614000-7f639a615000 rw-p 7f639a614000 00:00 0 > > 7f639a615000-7f639a617000 r-xp 00000000 09:00 416978 > /usr/lib/rsyslog/imuxsock.so > > 7f639a617000-7f639a717000 ---p 00002000 09:00 416978 > /usr/lib/rsyslog/imuxsock.so > > 7f639a717000-7f639a718000 rw-p 00002000 09:00 416978 > /usr/lib/rsyslog/imuxsock.so > > 7f639a718000-7f639a722000 r-xp 00000000 09:00 128440 > /lib/libnss_files-2.7.so > > 7f639a722000-7f639a922000 ---p 0000a000 09:00 128440 > /lib/libnss_files-2.7.so > > 7f639a922000-7f639a924000 rw-p 0000a000 09:00 128440 > /lib/libnss_files-2.7.so > > 7f639a924000-7f639aa6e000 r-xp 00000000 09:00 128443 > /lib/libc-2.7.so > > 7f639aa6e000-7f639ac6d000 ---p 0014a000 09:00 128443 > /lib/libc-2.7.so > > 7f639ac6d000-7f639ac70000 r--p 00149000 09:00 128443 > /lib/libc-2.7.so > > 7f639ac70000-7f639ac72000 rw-p 0014c000 09:00 128443 > /lib/libc-2.7.so > > 7f639ac72000-7f639ac77000 rw-p 7f639ac72000 00:00 0 > > 7f639ac77000-7f639ac7f000 r-xp 00000000 09:00 128449 > /lib/librt-2.7.so > > 7f639ac7f000-7f639ae7e000 ---p 00008000 09:00 128449 > /lib/librt-2.7.so > > 7f639ae7e000-7f639ae80000 rw-p 00007000 09:00 128449 > /lib/librt-2.7.so > > 7f639ae80000-7f639ae82000 r-xp 00000000 09:00 128447 > /lib/libdl-2.7.so > > 7f639ae82000-7f639b082000 ---p 00002000 09:00 128447 > /lib/libdl-2.7.so > > 7f639b082000-7f639b084000 rw-p 00002000 09:00 128447 > /lib/libdl-2.7.so > > 7f639b084000-7f639b09a000 r-xp 00000000 09:00 128439 > /lib/libpthread-2.7.so > > 7f639b09a000-7f639b29a000 ---p 00016000 09:00 128439 > /lib/libpthread-2.7.so > > 7f639b29a000-7f639b29c000 rw-p 00016000 09:00 128439 > /lib/libpthread-2.7.so > > 7f639b29c000-7f639b2a0000 rw-p 7f639b29c000 00:00 0 > > 7f639b2a0000-7f639b2b6000 r-xp 00000000 09:00 370185 > /usr/lib/libz.so.1.2.3.3 > > 7f639b2b6000-7f639b4b6000 ---p 00016000 09:00 370185 > /usr/lib/libz.so.1.2.3.3 > > 7f639b4b6000-7f639b4b7000 rw-p 00016000 09:00 370185 > /usr/lib/libz.so.1.2.3.3 > > 7f639b4b7000-7f639b4d3000 r-xp 00000000 09:00 128446 > /lib/ld-2.7.so > > 7f639b5bd000-7f639b5c2000 r-xp 00000000 09:00 416988 > /usr/lib/rsyslog/lmnet.so > > 7f639b5c2000-7f639b6c1000 ---p 00005000 09:00 416988 > /usr/lib/rsyslog/lmnet.so > > 7f639b6c1000-7f639b6c2000 rw-p 00004000 09:00 416988 > /usr/lib/rsyslog/lmnet.so > > 7f639b6c2000-7f639b6c5000 rw-p 7f639b6c2000 00:00 0 > > 7f639b6ce000-7f639b6d2000 rw-p 7f639b6ce000 00:00 0 > > 7f639b6d2000-7f639b6d4000 rw-p 0001b000 09:00 128446 > /lib/ld-2.7.so > > 7fffa36bf000-7fffa36d4000 rw-p 7ffffffea000 00:00 0 > [stack] > > 7fffa36ff000-7fffa3700000 r-xp 7fffa36ff000 00:00 0 > [vdso] > > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From lorenzo at sancho.ccd.uniroma2.it Mon Feb 2 17:37:35 2009 From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci) Date: Mon, 2 Feb 2009 17:37:35 +0100 (CET) Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <49871292.9000900@ipax.at> References: <49871292.9000900@ipax.at> Message-ID: Feels familiar. Would you mind sending some more info about your server ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free ? ) I think it is the same stuff that Rainer debugged and solved last week. If you feel so, I think you should try and install a later version. Thank you very much, yours lorenzo On Mon, 2 Feb 2009, Raoul Bhatia [IPAX] wrote: RBI> hi, RBI> RBI> i do not know if this has already been addressed - so sorry for RBI> a possible duplicate. RBI> RBI> revision: RBI> > Feb 2 16:29:58 wc02 kernel: imklog 3.20.0, log source = /proc/kmsg started. RBI> > Feb 2 16:29:58 wc02 rsyslogd: [origin software="rsyslogd" swVersion="3.20.0" x-pid="27617" x-info="http://www.rsyslog.com"] restart RBI> RBI> running on debian logging remotely to another server. RBI> RBI> cheers, RBI> raoul RBI> RBI> > *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** RBI> > ======= Backtrace: ========= RBI> > /lib/libc.so.6[0x7f639a997948] RBI> > /lib/libc.so.6(cfree+0x76)[0x7f639a999a56] RBI> > /usr/sbin/rsyslogd(msgDestruct+0x3c)[0x415f7c] RBI> > /usr/sbin/rsyslogd(actionCallAction+0xcd)[0x4281cd] RBI> > /usr/sbin/rsyslogd[0x409de9] RBI> > /usr/sbin/rsyslogd(llExecFunc+0x58)[0x4168e8] RBI> > /usr/sbin/rsyslogd[0x409ad5] RBI> > /usr/sbin/rsyslogd[0x4244ef] RBI> > /usr/sbin/rsyslogd(wtiWorker+0x24f)[0x42124f] RBI> > /usr/sbin/rsyslogd[0x420968] RBI> > /lib/libpthread.so.0[0x7f639b08afc7] RBI> > /lib/libc.so.6(clone+0x6d)[0x7f639a9f35ad] RBI> > ======= Memory map: ======== RBI> > 00400000-0043c000 r-xp 00000000 09:00 384769 /usr/sbin/rsyslogd RBI> > 0053b000-00540000 rw-p 0003b000 09:00 384769 /usr/sbin/rsyslogd RBI> > 00540000-00541000 rw-p 00540000 00:00 0 RBI> > 00ebc000-00f6e000 rw-p 00ebc000 00:00 0 [heap] RBI> > 40219000-4021a000 ---p 40219000 00:00 0 RBI> > 4021a000-40a1a000 rw-p 4021a000 00:00 0 RBI> > 40c65000-40c66000 ---p 40c65000 00:00 0 RBI> > 40c66000-41466000 rw-p 40c66000 00:00 0 RBI> > 41466000-41467000 ---p 41466000 00:00 0 RBI> > 41467000-41c67000 rw-p 41467000 00:00 0 RBI> > 41cff000-41d00000 ---p 41cff000 00:00 0 RBI> > 41d00000-42500000 rw-p 41d00000 00:00 0 RBI> > 7f638c000000-7f638c021000 rw-p 7f638c000000 00:00 0 RBI> > 7f638c021000-7f6390000000 ---p 7f638c021000 00:00 0 RBI> > 7f6394000000-7f6394021000 rw-p 7f6394000000 00:00 0 RBI> > 7f6394021000-7f6398000000 ---p 7f6394021000 00:00 0 RBI> > 7f63995aa000-7f63995c0000 r-xp 00000000 09:00 128682 /lib/libgcc_s.so.1 RBI> > 7f63995c0000-7f63997c0000 ---p 00016000 09:00 128682 /lib/libgcc_s.so.1 RBI> > 7f63997c0000-7f63997c1000 rw-p 00016000 09:00 128682 /lib/libgcc_s.so.1 RBI> > 7f63997c1000-7f63997d1000 r-xp 00000000 09:00 128437 /lib/libresolv-2.7.so RBI> > 7f63997d1000-7f63999d1000 ---p 00010000 09:00 128437 /lib/libresolv-2.7.so RBI> > 7f63999d1000-7f63999d3000 rw-p 00010000 09:00 128437 /lib/libresolv-2.7.so RBI> > 7f63999d3000-7f63999d5000 rw-p 7f63999d3000 00:00 0 RBI> > 7f63999d5000-7f63999d9000 r-xp 00000000 09:00 128444 /lib/libnss_dns-2.7.so RBI> > 7f63999d9000-7f6399bd8000 ---p 00004000 09:00 128444 /lib/libnss_dns-2.7.so RBI> > 7f6399bd8000-7f6399bda000 rw-p 00003000 09:00 128444 /lib/libnss_dns-2.7.so RBI> > 7f6399bda000-7f6399bde000 r-xp 00000000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so RBI> > 7f6399bde000-7f6399cdd000 ---p 00004000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so RBI> > 7f6399cdd000-7f6399cde000 rw-p 00003000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so RBI> > 7f6399cde000-7f6399ce0000 r-xp 00000000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so RBI> > 7f6399ce0000-7f6399ddf000 ---p 00002000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so RBI> > 7f6399ddf000-7f6399de0000 rw-p 00001000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so RBI> > 7f6399de0000-7f6399de3000 r-xp 00000000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so RBI> > 7f6399de3000-7f6399ee2000 ---p 00003000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so RBI> > 7f6399ee2000-7f6399ee3000 rw-p 00002000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so RBI> > 7f6399ee3000-7f6399eed000 r-xp 00000000 09:00 128429 /lib/libnss_nis-2.7.so RBI> > 7f6399eed000-7f639a0ec000 ---p 0000a000 09:00 128429 /lib/libnss_nis-2.7.so RBI> > 7f639a0ec000-7f639a0ee000 rw-p 00009000 09:00 128429 /lib/libnss_nis-2.7.so RBI> > 7f639a0ee000-7f639a103000 r-xp 00000000 09:00 128433 /lib/libnsl-2.7.so RBI> > 7f639a103000-7f639a302000 ---p 00015000 09:00 128433 /lib/libnsl-2.7.so RBI> > 7f639a302000-7f639a304000 rw-p 00014000 09:00 128433 /lib/libnsl-2.7.so RBI> > 7f639a304000-7f639a306000 rw-p 7f639a304000 00:00 0 RBI> > 7f639a306000-7f639a30d000 r-xp 00000000 09:00 128435 /lib/libnss_compat-2.7.so RBI> > 7f639a30d000-7f639a50c000 ---p 00007000 09:00 128435 /lib/libnss_compat-2.7.so RBI> > 7f639a50c000-7f639a50e000 rw-p 00006000 09:00 128435 /lib/libnss_compat-2.7.so RBI> > 7f639a50e000-7f639a513000 r-xp 00000000 09:00 416987 /usr/lib/rsyslog/imklog.so RBI> > 7f639a513000-7f639a613000 ---p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so RBI> > 7f639a613000-7f639a614000 rw-p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so RBI> > 7f639a614000-7f639a615000 rw-p 7f639a614000 00:00 0 RBI> > 7f639a615000-7f639a617000 r-xp 00000000 09:00 416978 /usr/lib/rsyslog/imuxsock.so RBI> > 7f639a617000-7f639a717000 ---p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so RBI> > 7f639a717000-7f639a718000 rw-p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so RBI> > 7f639a718000-7f639a722000 r-xp 00000000 09:00 128440 /lib/libnss_files-2.7.so RBI> > 7f639a722000-7f639a922000 ---p 0000a000 09:00 128440 /lib/libnss_files-2.7.so RBI> > 7f639a922000-7f639a924000 rw-p 0000a000 09:00 128440 /lib/libnss_files-2.7.so RBI> > 7f639a924000-7f639aa6e000 r-xp 00000000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639aa6e000-7f639ac6d000 ---p 0014a000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639ac6d000-7f639ac70000 r--p 00149000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639ac70000-7f639ac72000 rw-p 0014c000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639ac72000-7f639ac77000 rw-p 7f639ac72000 00:00 0 RBI> > 7f639ac77000-7f639ac7f000 r-xp 00000000 09:00 128449 /lib/librt-2.7.so RBI> > 7f639ac7f000-7f639ae7e000 ---p 00008000 09:00 128449 /lib/librt-2.7.so RBI> > 7f639ae7e000-7f639ae80000 rw-p 00007000 09:00 128449 /lib/librt-2.7.so RBI> > 7f639ae80000-7f639ae82000 r-xp 00000000 09:00 128447 /lib/libdl-2.7.so RBI> > 7f639ae82000-7f639b082000 ---p 00002000 09:00 128447 /lib/libdl-2.7.so RBI> > 7f639b082000-7f639b084000 rw-p 00002000 09:00 128447 /lib/libdl-2.7.so RBI> > 7f639b084000-7f639b09a000 r-xp 00000000 09:00 128439 /lib/libpthread-2.7.so RBI> > 7f639b09a000-7f639b29a000 ---p 00016000 09:00 128439 /lib/libpthread-2.7.so RBI> > 7f639b29a000-7f639b29c000 rw-p 00016000 09:00 128439 /lib/libpthread-2.7.so RBI> > 7f639b29c000-7f639b2a0000 rw-p 7f639b29c000 00:00 0 RBI> > 7f639b2a0000-7f639b2b6000 r-xp 00000000 09:00 370185 /usr/lib/libz.so.1.2.3.3 RBI> > 7f639b2b6000-7f639b4b6000 ---p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 RBI> > 7f639b4b6000-7f639b4b7000 rw-p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 RBI> > 7f639b4b7000-7f639b4d3000 r-xp 00000000 09:00 128446 /lib/ld-2.7.so RBI> > 7f639b5bd000-7f639b5c2000 r-xp 00000000 09:00 416988 /usr/lib/rsyslog/lmnet.so RBI> > 7f639b5c2000-7f639b6c1000 ---p 00005000 09:00 416988 /usr/lib/rsyslog/lmnet.so RBI> > 7f639b6c1000-7f639b6c2000 rw-p 00004000 09:00 416988 /usr/lib/rsyslog/lmnet.so RBI> > 7f639b6c2000-7f639b6c5000 rw-p 7f639b6c2000 00:00 0 RBI> > 7f639b6ce000-7f639b6d2000 rw-p 7f639b6ce000 00:00 0 RBI> > 7f639b6d2000-7f639b6d4000 rw-p 0001b000 09:00 128446 /lib/ld-2.7.so RBI> > 7fffa36bf000-7fffa36d4000 rw-p 7ffffffea000 00:00 0 [stack] RBI> > 7fffa36ff000-7fffa3700000 r-xp 7fffa36ff000 00:00 0 [vdso] RBI> > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] RBI> _______________________________________________ RBI> rsyslog mailing list RBI> http://lists.adiscon.net/mailman/listinfo/rsyslog RBI> http://www.rsyslog.com RBI> +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+ From r.bhatia at ipax.at Mon Feb 2 18:02:12 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Mon, 02 Feb 2009 18:02:12 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: References: <49871292.9000900@ipax.at> Message-ID: <49872714.8050901@ipax.at> Lorenzo M. Catucci wrote: > Feels familiar. > > Would you mind sending some more info about your server > ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free ? ) > > I think it is the same stuff that Rainer debugged and solved last week. If > you feel so, I think you should try and install a later version. > > Thank you very much, yours sure, see below. please note that i already rebootet the server. for trying a new release: sure, i have no issue with that. shall i try the one that can be found in sid (3.20.3-1) or a newer one? cheers, raoul > # uname -a > Linux wc02 2.6.27.13 #2 SMP Sat Jan 31 18:32:34 CET 2009 x86_64 GNU/Linux > # cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > stepping : 6 > cpu MHz : 2993.390 > cache size : 6144 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 2 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > bogomips : 5986.78 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 1 > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > stepping : 6 > cpu MHz : 2993.390 > cache size : 6144 KB > physical id : 0 > siblings : 2 > core id : 1 > cpu cores : 2 > apicid : 1 > initial apicid : 1 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > bogomips : 5986.77 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > # cat /etc/debian_version > 5.0 > # free > total used free shared buffers cached > Mem: 2052076 336392 1715684 0 98580 107268 > -/+ buffers/cache: 130544 1921532 > Swap: 1999992 0 1999992 -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From rgerhards at hq.adiscon.com Mon Feb 2 18:16:17 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 18:16:17 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <49872714.8050901@ipax.at> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Hi Raoul, I don't keep track of the bug in the older releases - simply too much work, especially in this case. The best would be to use v3-stable from git (I have not yet released a tarball as I'd like to get some feedback from the field, first - not too often release stable versions..). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Monday, February 02, 2009 6:02 PM > To: rsyslog-users > Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: > double free or corruption (!prev): 0x0000000000ef03b0 *** > > Lorenzo M. Catucci wrote: > > Feels familiar. > > > > Would you mind sending some more info about your server > > ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free > ? ) > > > > I think it is the same stuff that Rainer debugged and solved last > week. If > > you feel so, I think you should try and install a later version. > > > > Thank you very much, yours > > sure, see below. > > please note that i already rebootet the server. > > for trying a new release: sure, i have no issue with that. shall i try > the one that can be found in sid (3.20.3-1) or a newer one? > > cheers, > raoul > > > # uname -a > > Linux wc02 2.6.27.13 #2 SMP Sat Jan 31 18:32:34 CET 2009 x86_64 > GNU/Linux > > > # cat /proc/cpuinfo > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 23 > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > > stepping : 6 > > cpu MHz : 2993.390 > > cache size : 6144 KB > > physical id : 0 > > siblings : 2 > > core id : 0 > > cpu cores : 2 > > apicid : 0 > > initial apicid : 0 > > fpu : yes > > fpu_exception : yes > > cpuid level : 10 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > > bogomips : 5986.78 > > clflush size : 64 > > cache_alignment : 64 > > address sizes : 36 bits physical, 48 bits virtual > > power management: > > > > processor : 1 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 23 > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > > stepping : 6 > > cpu MHz : 2993.390 > > cache size : 6144 KB > > physical id : 0 > > siblings : 2 > > core id : 1 > > cpu cores : 2 > > apicid : 1 > > initial apicid : 1 > > fpu : yes > > fpu_exception : yes > > cpuid level : 10 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > > bogomips : 5986.77 > > clflush size : 64 > > cache_alignment : 64 > > address sizes : 36 bits physical, 48 bits virtual > > power management: > > > # cat /etc/debian_version > > 5.0 > > > > # free > > total used free shared buffers > cached > > Mem: 2052076 336392 1715684 0 98580 > 107268 > > -/+ buffers/cache: 130544 1921532 > > Swap: 1999992 0 1999992 > > -- > ____________________________________________________________________ > DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at > Technischer Leiter > > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at > Barawitzkagasse 10/2/2/11 email. office at ipax.at > 1190 Wien tel. +43 1 3670030 > FN 277995t HG Wien fax. +43 1 3670030 15 > ____________________________________________________________________ > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From lorenzo at sancho.ccd.uniroma2.it Mon Feb 2 18:31:31 2009 From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci) Date: Mon, 2 Feb 2009 18:31:31 +0100 (CET) Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at> <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Message-ID: On Mon, 2 Feb 2009, Rainer Gerhards wrote: RG> Hi Raoul, RG> RG> I don't keep track of the bug in the older releases - simply too much RG> work, especially in this case. The best would be to use v3-stable from RG> git (I have not yet released a tarball as I'd like to get some feedback RG> from the field, first - not too often release stable versions..). RG> RG> Rainer RG> Since I'm git-dumb (I know, it runs (almost) as fast as light, but I still find it too confusing, especially when compared to hg...) I think a quick-recipe could be of use to others too: $ git clone git://git.adiscon.com/git/rsyslog.git rsyslog.git $ cd rsyslog.git $ git checkout origin/v3-stable and now go configure, make, make install... RG> RG> > -----Original Message----- RG> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- RG> > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] RG> > Sent: Monday, February 02, 2009 6:02 PM RG> > To: rsyslog-users RG> > Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: RG> > double free or corruption (!prev): 0x0000000000ef03b0 *** RG> > RG> > Lorenzo M. Catucci wrote: RG> > > Feels familiar. RG> > > RG> > > Would you mind sending some more info about your server RG> > > ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free RG> > ? ) RG> > > RG> > > I think it is the same stuff that Rainer debugged and solved last RG> > week. If RG> > > you feel so, I think you should try and install a later version. RG> > > RG> > > Thank you very much, yours RG> > RG> > sure, see below. RG> > RG> > please note that i already rebootet the server. RG> > RG> > for trying a new release: sure, i have no issue with that. shall i try RG> > the one that can be found in sid (3.20.3-1) or a newer one? RG> > RG> > cheers, RG> > raoul RG> > RG> > > # uname -a RG> > > Linux wc02 2.6.27.13 #2 SMP Sat Jan 31 18:32:34 CET 2009 x86_64 RG> > GNU/Linux RG> > RG> > > # cat /proc/cpuinfo RG> > > processor : 0 RG> > > vendor_id : GenuineIntel RG> > > cpu family : 6 RG> > > model : 23 RG> > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz RG> > > stepping : 6 RG> > > cpu MHz : 2993.390 RG> > > cache size : 6144 KB RG> > > physical id : 0 RG> > > siblings : 2 RG> > > core id : 0 RG> > > cpu cores : 2 RG> > > apicid : 0 RG> > > initial apicid : 0 RG> > > fpu : yes RG> > > fpu_exception : yes RG> > > cpuid level : 10 RG> > > wp : yes RG> > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr RG> > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe RG> > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni RG> monitor RG> > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm RG> > > bogomips : 5986.78 RG> > > clflush size : 64 RG> > > cache_alignment : 64 RG> > > address sizes : 36 bits physical, 48 bits virtual RG> > > power management: RG> > > RG> > > processor : 1 RG> > > vendor_id : GenuineIntel RG> > > cpu family : 6 RG> > > model : 23 RG> > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz RG> > > stepping : 6 RG> > > cpu MHz : 2993.390 RG> > > cache size : 6144 KB RG> > > physical id : 0 RG> > > siblings : 2 RG> > > core id : 1 RG> > > cpu cores : 2 RG> > > apicid : 1 RG> > > initial apicid : 1 RG> > > fpu : yes RG> > > fpu_exception : yes RG> > > cpuid level : 10 RG> > > wp : yes RG> > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr RG> > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe RG> > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni RG> monitor RG> > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm RG> > > bogomips : 5986.77 RG> > > clflush size : 64 RG> > > cache_alignment : 64 RG> > > address sizes : 36 bits physical, 48 bits virtual RG> > > power management: RG> > RG> > > # cat /etc/debian_version RG> > > 5.0 RG> > RG> > RG> > > # free RG> > > total used free shared buffers RG> > cached RG> > > Mem: 2052076 336392 1715684 0 98580 RG> > 107268 RG> > > -/+ buffers/cache: 130544 1921532 RG> > > Swap: 1999992 0 1999992 RG> > RG> > -- RG> > ____________________________________________________________________ RG> > DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at RG> > Technischer Leiter RG> > RG> > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at RG> > Barawitzkagasse 10/2/2/11 email. office at ipax.at RG> > 1190 Wien tel. +43 1 3670030 RG> > FN 277995t HG Wien fax. +43 1 3670030 15 RG> > ____________________________________________________________________ RG> > _______________________________________________ RG> > rsyslog mailing list RG> > http://lists.adiscon.net/mailman/listinfo/rsyslog RG> > http://www.rsyslog.com RG> _______________________________________________ RG> rsyslog mailing list RG> http://lists.adiscon.net/mailman/listinfo/rsyslog RG> http://www.rsyslog.com RG> +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+ From rgerhards at hq.adiscon.com Mon Feb 2 18:37:34 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 18:37:34 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: References: <49871292.9000900@ipax.at><49872714.8050901@ipax.at><577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAF2@grfint2.intern.adiscon.com> Thanks, I should have mentioned. But one step missing: > Since I'm git-dumb (I know, it runs (almost) as fast as light, but I > still > find it too confusing, especially when compared to hg...) I think a > quick-recipe could be of use to others too: > > $ git clone git://git.adiscon.com/git/rsyslog.git rsyslog.git > $ cd rsyslog.git > $ git checkout origin/v3-stable > $ autoreconf -vfi # build ./configure > and now go configure, make, make install... From mic at npgx.com.au Tue Feb 3 06:08:07 2009 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 3 Feb 2009 16:08:07 +1100 Subject: [rsyslog] Logging directives for a milter Message-ID: <20090203050119.M91067@npgx.com.au> Hi, I'm using rsyslog 3.18.0 (have been for longer than I can remember now). I have recently installed a milter for sendmail, and the milter docs show: LOGGING milter-regex sends log messages to syslogd(8) using facility daemon and, with increasing verbosity, level err, notice, info and debug. The fol- lowing syslog.conf(5) section can be used to log messages to a dedicated file: !milter-regex daemon.err;daemon.notice /var/log/milter-regex I use rsyslog in TraditionalFileFormat and have this entry: *.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages which captures all the daemon.info messages (a lot of them) into my /var/log/messages. I added the daemon.info to: mail.*;daemon.info -/var/log/maillog so that I would rightly get the messages included into my maillog file, but how do I now remove the messages from my /var/log/messages file with the *.info capturing that there? I've tried using: *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none /var/log/messages but just that line stopped all daemon logging into the messages file, so basically a day passed and nothing was logged there. Thanks. Michael. From hks.private at gmail.com Tue Feb 3 17:12:25 2009 From: hks.private at gmail.com ((private) HKS) Date: Tue, 3 Feb 2009 11:12:25 -0500 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <20090203050119.M91067@npgx.com.au> References: <20090203050119.M91067@npgx.com.au> Message-ID: On Tue, Feb 3, 2009 at 12:08 AM, Michael Mansour wrote: > Hi, > > I'm using rsyslog 3.18.0 (have been for longer than I can remember now). > > I have recently installed a milter for sendmail, and the milter docs show: > > LOGGING > milter-regex sends log messages to syslogd(8) using facility daemon and, > with increasing verbosity, level err, notice, info and debug. The fol- > lowing syslog.conf(5) section can be used to log messages to a dedicated > file: > > !milter-regex > daemon.err;daemon.notice /var/log/milter-regex > > I use rsyslog in TraditionalFileFormat and have this entry: > > *.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages > > which captures all the daemon.info messages (a lot of them) into my > /var/log/messages. > > I added the daemon.info to: > > mail.*;daemon.info -/var/log/maillog > > so that I would rightly get the messages included into my maillog file, but > how do I now remove the messages from my /var/log/messages file with the > *.info capturing that there? > > I've tried using: > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > /var/log/messages > > but just that line stopped all daemon logging into the messages file, so > basically a day passed and nothing was logged there. > > Thanks. > > Michael. > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com Change this: *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none /var/log/messages To this: *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice /var/log/messages -HKS From mic at npgx.com.au Wed Feb 4 01:30:20 2009 From: mic at npgx.com.au (Michael Mansour) Date: Wed, 4 Feb 2009 11:30:20 +1100 Subject: [rsyslog] Logging directives for a milter In-Reply-To: References: <20090203050119.M91067@npgx.com.au> Message-ID: <20090204002209.M97796@npgx.com.au> Hi HKS, Thanks for your reply. > On Tue, Feb 3, 2009 at 12:08 AM, Michael Mansour wrote: > > Hi, > > > > I'm using rsyslog 3.18.0 (have been for longer than I can remember now). > > > > I have recently installed a milter for sendmail, and the milter docs show: > > > > LOGGING > > milter-regex sends log messages to syslogd(8) using facility daemon and, > > with increasing verbosity, level err, notice, info and debug. The fol- > > lowing syslog.conf(5) section can be used to log messages to a dedicated > > file: > > > > !milter-regex > > daemon.err;daemon.notice /var/log/milter-regex > > > > I use rsyslog in TraditionalFileFormat and have this entry: > > > > *.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages > > > > which captures all the daemon.info messages (a lot of them) into my > > /var/log/messages. > > > > I added the daemon.info to: > > > > mail.*;daemon.info -/var/log/maillog > > > > so that I would rightly get the messages included into my maillog file, but > > how do I now remove the messages from my /var/log/messages file with the > > *.info capturing that there? > > > > I've tried using: > > > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > > /var/log/messages > > > > but just that line stopped all daemon logging into the messages file, so > > basically a day passed and nothing was logged there. > > > > Thanks. > > > > Michael. > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > Change this: > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > /var/log/messages > > To this: > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice > /var/log/messages I've just tried that, restarted rsyslog and the messages for milter-regex keep appearing in /var/log/messages. I'm 100% these are daemon.info messages since I also use: mail.*;daemon.info -/var/log/maillog and the milter-regex messages that show up in /var/log/maillog are the same ones that show up in /var/log/messages. I'm pretty sure the reason that deamon.info is still going to /var/log/messages is because of the "*.info" entry at the beginning of that line, which catches daemon.info? Is there a way I can stop daemon.info from showing up in /var/log/messages while keeping *.info on that same line? Thanks. Michael. > -HKS > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com ------- End of Original Message ------- From kenneho.ndu at gmail.com Wed Feb 4 09:58:54 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 09:58:54 +0100 Subject: [rsyslog] Configuring rsyslog failover Message-ID: Hello list. We're running rsyslog 2.0.6 downloaded from RHN, and are about to set up reliability/failover. I've found two setup tutorials for this: 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer It seems like both setups configure reliable transfer, but using a completely different syntax. Is it so that the former one is the syntax for newer versions of rsyslog? Regards, Kenneth Holter From rgerhards at hq.adiscon.com Wed Feb 4 10:01:48 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 10:01:48 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> Hi Kenneth, the first link does NOT describe a failover case. In the first link, data is queued while the syslogd is not available. A failover case (described in link two) is that if one syslogd goes down, data is sent to another. This is not done in case 1: there, messages are queued while the syslogd is down and sent to *the same syslogd* when it is up again. So no second syslogd involved in case 1, so this is no failover scenario. HTH Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 9:59 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Configuring rsyslog failover > > Hello list. > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to set > up > reliability/failover. I've found two setup tutorials for this: > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > It seems like both setups configure reliable transfer, but using a > completely different syntax. Is it so that the former one is the syntax > for > newer versions of rsyslog? > > Regards, > Kenneth Holter > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 4 10:13:29 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 10:13:29 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> Message-ID: Thanks for the quick reply. You're right, it's not a failover solution by definition. I see now that I should have outlined my needs... What I'm aiming at, at least for now, is a semi-failover solution: If the syslog server (i.e. loghost) goes down, the clients should simply spool the messages until the server gets back online. Back to the examples I linked to: They both seem to provide the functionality I'm looking for. Is that correct? If so: what's the difference between them? On 2/4/09, Rainer Gerhards wrote: > > Hi Kenneth, > > the first link does NOT describe a failover case. In the first link, > data is queued while the syslogd is not available. A failover case > (described in link two) is that if one syslogd goes down, data is sent > to another. This is not done in case 1: there, messages are queued while > the syslogd is down and sent to *the same syslogd* when it is up again. > So no second syslogd involved in case 1, so this is no failover > scenario. > > HTH > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 9:59 AM > > To: rsyslog at lists.adiscon.com > > Subject: [rsyslog] Configuring rsyslog failover > > > > Hello list. > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to set > > up > > reliability/failover. I've found two setup tutorials for this: > > > > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > It seems like both setups configure reliable transfer, but using a > > completely different syntax. Is it so that the former one is the > syntax > > for > > newer versions of rsyslog? > > > > Regards, > > Kenneth Holter > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Wed Feb 4 10:55:51 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 10:55:51 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 10:13 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Thanks for the quick reply. > > You're right, it's not a failover solution by definition. I see now > that I > should have outlined my needs... What I'm aiming at, at least for now, > is a > semi-failover solution: If the syslog server (i.e. loghost) goes down, > the > clients should simply spool the messages until the server gets back > online. > > Back to the examples I linked to: They both seem to provide the > functionality I'm looking for. Is that correct? If so: what's the > difference > between them? No! ;) As I said, #2 is a failover scenario - it does not spool but rather send the messags to another (failover) server if the primary fails. Rainer > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > Hi Kenneth, > > > > the first link does NOT describe a failover case. In the first link, > > data is queued while the syslogd is not available. A failover case > > (described in link two) is that if one syslogd goes down, data is > sent > > to another. This is not done in case 1: there, messages are queued > while > > the syslogd is down and sent to *the same syslogd* when it is up > again. > > So no second syslogd involved in case 1, so this is no failover > > scenario. > > > > HTH > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > To: rsyslog at lists.adiscon.com > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > Hello list. > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to > set > > > up > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > It seems like both setups configure reliable transfer, but using a > > > completely different syntax. Is it so that the former one is the > > syntax > > > for > > > newer versions of rsyslog? > > > > > > Regards, > > > Kenneth Holter > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Wed Feb 4 11:06:08 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 11:06:08 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Oops... and I just noticed you use v2. Spooling is not available in v2. Sorry for not spotting it in the first place... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Wednesday, February 04, 2009 10:56 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 10:13 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > Thanks for the quick reply. > > > > You're right, it's not a failover solution by definition. I see now > > that I > > should have outlined my needs... What I'm aiming at, at least for > now, > > is a > > semi-failover solution: If the syslog server (i.e. loghost) goes > down, > > the > > clients should simply spool the messages until the server gets back > > online. > > > > Back to the examples I linked to: They both seem to provide the > > functionality I'm looking for. Is that correct? If so: what's the > > difference > > between them? > > No! ;) As I said, #2 is a failover scenario - it does not spool but > rather send the messags to another (failover) server if the primary > fails. > > Rainer > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > Hi Kenneth, > > > > > > the first link does NOT describe a failover case. In the first > link, > > > data is queued while the syslogd is not available. A failover case > > > (described in link two) is that if one syslogd goes down, data is > > sent > > > to another. This is not done in case 1: there, messages are queued > > while > > > the syslogd is down and sent to *the same syslogd* when it is up > > again. > > > So no second syslogd involved in case 1, so this is no failover > > > scenario. > > > > > > HTH > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > To: rsyslog at lists.adiscon.com > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > Hello list. > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to > > set > > > > up > > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > It seems like both setups configure reliable transfer, but using > a > > > > completely different syntax. Is it so that the former one is the > > > syntax > > > > for > > > > newer versions of rsyslog? > > > > > > > > Regards, > > > > Kenneth Holter > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 4 13:42:13 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 13:42:13 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: No prob. :) Then I'm even more puzzled...I've configured my rsyslog client with this setup: ** **.* @@client1.example.com:200 $ActionExecOnlyWhenPreviousIsSuspended on & /var/log/localbuffer $ActionExecOnlyWhenPreviousIsSuspended off* If I cut the link to the syslog-server (using iptables to emulate the logserver being down), run "logger hello" on the client, and then after a while attach the link (by flushing the iptable rules), I see that the hello message pops up on the rsyslog server. So some kind of spooling or something seems to be active. Strange. Maybe the spooling or whatever is done on TCP level or something. Maybe the rsyslog version from RHN differs from the "normal" versioning? On 2/4/09, Rainer Gerhards wrote: > Oops... and I just noticed you use v2. Spooling is not available in v2. > > Sorry for not spotting it in the first place... > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Wednesday, February 04, 2009 10:56 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > Thanks for the quick reply. > > > > > > You're right, it's not a failover solution by definition. I see now > > > that I > > > should have outlined my needs... What I'm aiming at, at least for > > now, > > > is a > > > semi-failover solution: If the syslog server (i.e. loghost) goes > > down, > > > the > > > clients should simply spool the messages until the server gets back > > > online. > > > > > > Back to the examples I linked to: They both seem to provide the > > > functionality I'm looking for. Is that correct? If so: what's the > > > difference > > > between them? > > > > No! ;) As I said, #2 is a failover scenario - it does not spool but > > rather send the messags to another (failover) server if the primary > > fails. > > > > Rainer > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > Hi Kenneth, > > > > > > > > the first link does NOT describe a failover case. In the first > > link, > > > > data is queued while the syslogd is not available. A failover case > > > > (described in link two) is that if one syslogd goes down, data is > > > sent > > > > to another. This is not done in case 1: there, messages are queued > > > while > > > > the syslogd is down and sent to *the same syslogd* when it is up > > > again. > > > > So no second syslogd involved in case 1, so this is no failover > > > > scenario. > > > > > > > > HTH > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > To: rsyslog at lists.adiscon.com > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about > to > > > set > > > > > up > > > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > > > > > > > 1. > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > It seems like both setups configure reliable transfer, but using > > a > > > > > completely different syntax. Is it so that the former one is the > > > > syntax > > > > > for > > > > > newer versions of rsyslog? > > > > > > > > > > Regards, > > > > > Kenneth Holter > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From kenneho.ndu at gmail.com Wed Feb 4 14:02:50 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 14:02:50 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: It seems like RHN is way behind on adding rsyslog updates to the repo, so it seems like I'm more or less stuck with version 2 for now. Are there any failover/spooling/etc functionality in version 2? I'd like to increase the chance of syslog messages reaching the syslog server, even if it gets offline for a short while. I'm sure it's possible to acheive this by smart (over-)engineering while waiting for rsyslog v3 being released on RHN, but I'm all for simplicity. :) On 2/4/09, Kenneth Holter wrote: > > No prob. :) > > Then I'm even more puzzled...I've configured my rsyslog client with this > setup: > ** > > **.* @@client1.example.com:200 > $ActionExecOnlyWhenPreviousIsSuspended on > & /var/log/localbuffer > $ActionExecOnlyWhenPreviousIsSuspended off* > > > If I cut the link to the syslog-server (using iptables to emulate the > logserver being down), run "logger hello" on the client, and then after a > while attach the link (by flushing the iptable rules), I see that the hello > message pops up on the rsyslog server. So some kind of spooling or something > seems to be active. Strange. Maybe the spooling or whatever is done on TCP > level or something. Maybe the rsyslog version from RHN differs from the > "normal" versioning? > > > > > On 2/4/09, Rainer Gerhards wrote: > > Oops... and I just noticed you use v2. Spooling is not available in v2. > > > > Sorry for not spotting it in the first place... > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > Thanks for the quick reply. > > > > > > > > You're right, it's not a failover solution by definition. I see now > > > > that I > > > > should have outlined my needs... What I'm aiming at, at least for > > > now, > > > > is a > > > > semi-failover solution: If the syslog server (i.e. loghost) goes > > > down, > > > > the > > > > clients should simply spool the messages until the server gets back > > > > online. > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > functionality I'm looking for. Is that correct? If so: what's the > > > > difference > > > > between them? > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool but > > > rather send the messags to another (failover) server if the primary > > > fails. > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > Hi Kenneth, > > > > > > > > > > the first link does NOT describe a failover case. In the first > > > link, > > > > > data is queued while the syslogd is not available. A failover case > > > > > (described in link two) is that if one syslogd goes down, data is > > > > sent > > > > > to another. This is not done in case 1: there, messages are queued > > > > while > > > > > the syslogd is down and sent to *the same syslogd* when it is up > > > > again. > > > > > So no second syslogd involved in case 1, so this is no failover > > > > > scenario. > > > > > > > > > > HTH > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about > > to > > > > set > > > > > > up > > > > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > > > > > > > > > > 1. > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > It seems like both setups configure reliable transfer, but using > > > a > > > > > > completely different syntax. Is it so that the former one is the > > > > > syntax > > > > > > for > > > > > > newer versions of rsyslog? > > > > > > > > > > > > Regards, > > > > > > Kenneth Holter > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > > From rgerhards at hq.adiscon.com Wed Feb 4 14:12:45 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 14:12:45 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB2D@grfint2.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 1:42 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > No prob. :) > > Then I'm even more puzzled...I've configured my rsyslog client with > this > setup: > ** > > **.* @@client1.example.com:200 > $ActionExecOnlyWhenPreviousIsSuspended on > & /var/log/localbuffer > $ActionExecOnlyWhenPreviousIsSuspended off* > > > If I cut the link to the syslog-server (using iptables to emulate the > logserver being down), run "logger hello" on the client, and then after > a > while attach the link (by flushing the iptable rules), I see that the > hello > message pops up on the rsyslog server. So some kind of spooling or > something > seems to be active. Strange. Maybe the spooling or whatever is done on > TCP > level or something. Maybe the rsyslog version from RHN differs from the > "normal" versioning? This has lot's to do with your test environment (you really don't break the link but just make it impossible to send for a period of time), the local tcp send buffer and the way TCP is designed. I suggest to have an in-depth look at http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.ht ml To do your lab, try to send multiple messages and/or make sure you restart the receiving server while the connection is blocked. You will notice some message loss during that process, this is expected, reasons are in my blog post quoted above. Note that v3 has some improved code to reduce message loss, but in any case there potentially is loss. V2 looses more messages than v3. Rainer > > > > > On 2/4/09, Rainer Gerhards wrote: > > Oops... and I just noticed you use v2. Spooling is not available in > v2. > > > > Sorry for not spotting it in the first place... > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > Thanks for the quick reply. > > > > > > > > You're right, it's not a failover solution by definition. I see > now > > > > that I > > > > should have outlined my needs... What I'm aiming at, at least for > > > now, > > > > is a > > > > semi-failover solution: If the syslog server (i.e. loghost) goes > > > down, > > > > the > > > > clients should simply spool the messages until the server gets > back > > > > online. > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > functionality I'm looking for. Is that correct? If so: what's the > > > > difference > > > > between them? > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool but > > > rather send the messags to another (failover) server if the primary > > > fails. > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > Hi Kenneth, > > > > > > > > > > the first link does NOT describe a failover case. In the first > > > link, > > > > > data is queued while the syslogd is not available. A failover > case > > > > > (described in link two) is that if one syslogd goes down, data > is > > > > sent > > > > > to another. This is not done in case 1: there, messages are > queued > > > > while > > > > > the syslogd is down and sent to *the same syslogd* when it is > up > > > > again. > > > > > So no second syslogd involved in case 1, so this is no failover > > > > > scenario. > > > > > > > > > > HTH > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > about > > to > > > > set > > > > > > up > > > > > > reliability/failover. I've found two setup tutorials for > this: > > > > > > > > > > > > > > > > > > 1. > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > using > > > a > > > > > > completely different syntax. Is it so that the former one is > the > > > > > syntax > > > > > > for > > > > > > newer versions of rsyslog? > > > > > > > > > > > > Regards, > > > > > > Kenneth Holter > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Wed Feb 4 14:14:11 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 14:14:11 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Failover is available - that is done like you described in your last post. But you need to keep an eye on the subtleties, outlined in the response I've written just 2 minutes ago ;). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 2:03 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > It seems like RHN is way behind on adding rsyslog updates to the repo, > so it > seems like I'm more or less stuck with version 2 for now. Are there any > failover/spooling/etc functionality in version 2? I'd like to increase > the > chance of syslog messages reaching the syslog server, even if it gets > offline for a short while. I'm sure it's possible to acheive this by > smart > (over-)engineering while waiting for rsyslog v3 being released on RHN, > but > I'm all for simplicity. :) > > On 2/4/09, Kenneth Holter wrote: > > > > No prob. :) > > > > Then I'm even more puzzled...I've configured my rsyslog client with > this > > setup: > > ** > > > > **.* @@client1.example.com:200 > > $ActionExecOnlyWhenPreviousIsSuspended on > > & /var/log/localbuffer > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > If I cut the link to the syslog-server (using iptables to emulate the > > logserver being down), run "logger hello" on the client, and then > after a > > while attach the link (by flushing the iptable rules), I see that the > hello > > message pops up on the rsyslog server. So some kind of spooling or > something > > seems to be active. Strange. Maybe the spooling or whatever is done > on TCP > > level or something. Maybe the rsyslog version from RHN differs from > the > > "normal" versioning? > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > Oops... and I just noticed you use v2. Spooling is not available in > v2. > > > > > > Sorry for not spotting it in the first place... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > You're right, it's not a failover solution by definition. I see > now > > > > > that I > > > > > should have outlined my needs... What I'm aiming at, at least > for > > > > now, > > > > > is a > > > > > semi-failover solution: If the syslog server (i.e. loghost) > goes > > > > down, > > > > > the > > > > > clients should simply spool the messages until the server gets > back > > > > > online. > > > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > > functionality I'm looking for. Is that correct? If so: what's > the > > > > > difference > > > > > between them? > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > but > > > > rather send the messags to another (failover) server if the > primary > > > > fails. > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > the first link does NOT describe a failover case. In the > first > > > > link, > > > > > > data is queued while the syslogd is not available. A failover > case > > > > > > (described in link two) is that if one syslogd goes down, > data is > > > > > sent > > > > > > to another. This is not done in case 1: there, messages are > queued > > > > > while > > > > > > the syslogd is down and sent to *the same syslogd* when it is > up > > > > > again. > > > > > > So no second syslogd involved in case 1, so this is no > failover > > > > > > scenario. > > > > > > > > > > > > HTH > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > about > > > to > > > > > set > > > > > > > up > > > > > > > reliability/failover. I've found two setup tutorials for > this: > > > > > > > > > > > > > > > > > > > > > 1. > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > 2. > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > using > > > > a > > > > > > > completely different syntax. Is it so that the former one > is the > > > > > > syntax > > > > > > > for > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > Regards, > > > > > > > Kenneth Holter > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Wed Feb 4 12:58:03 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 04 Feb 2009 12:58:03 +0100 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <20090204002209.M97796@npgx.com.au> References: <20090203050119.M91067@npgx.com.au> <20090204002209.M97796@npgx.com.au> Message-ID: <1233748683.19733.113.camel@rf10up.intern.adiscon.com> On Wed, 2009-02-04 at 11:30 +1100, Michael Mansour wrote: > > Change this: > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > > /var/log/messages > > > > To this: > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice > > /var/log/messages > I think it should be *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.none /var/log/messages > I've just tried that, restarted rsyslog and the messages for milter-regex keep > appearing in /var/log/messages. > > I'm 100% these are daemon.info messages since I also use: > > mail.*;daemon.info -/var/log/maillog > > and the milter-regex messages that show up in /var/log/maillog are the same > ones that show up in /var/log/messages. > > I'm pretty sure the reason that deamon.info is still going to > /var/log/messages is because of the "*.info" entry at the beginning of that > line, which catches daemon.info? Yes, because that says "everything with info severity, no matter what the facility is, matches". > > Is there a way I can stop daemon.info from showing up in /var/log/messages > while keeping *.info on that same line? > The .none in my example above is meant to exclude a specific facility from the usual processing and this sounds like what you are looking for. I barely remember that someone had problems with it. So if it does not work, let me know. The part of the code that handles those old-style selectors (old but still good!) is one of the few code sequences that stem directly back to sysklogd and I can't outrule that something went wrong during all that changes of the engine... Please let me know the outcome (saves me the lab). Rainer From danson at rackspace.com Wed Feb 4 17:12:34 2009 From: danson at rackspace.com (Daniel Anson) Date: Wed, 4 Feb 2009 10:12:34 -0600 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Message-ID: <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> I personally run RHEL 5 servers with rsyslog. Due to the lack of a current and stable rsyslog rpm, I always build rsyslog on the server. It takes less than 5 minutes and is very stable. Daniel Anson Rackspace Managed Hosting danson at rackspace.com -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards Sent: Wednesday, February 04, 2009 7:14 AM To: rsyslog-users Subject: Re: [rsyslog] Configuring rsyslog failover Failover is available - that is done like you described in your last post. But you need to keep an eye on the subtleties, outlined in the response I've written just 2 minutes ago ;). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 2:03 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > It seems like RHN is way behind on adding rsyslog updates to the repo, > so it > seems like I'm more or less stuck with version 2 for now. Are there any > failover/spooling/etc functionality in version 2? I'd like to increase > the > chance of syslog messages reaching the syslog server, even if it gets > offline for a short while. I'm sure it's possible to acheive this by > smart > (over-)engineering while waiting for rsyslog v3 being released on RHN, > but > I'm all for simplicity. :) > > On 2/4/09, Kenneth Holter wrote: > > > > No prob. :) > > > > Then I'm even more puzzled...I've configured my rsyslog client with > this > > setup: > > ** > > > > **.* @@client1.example.com:200 > > $ActionExecOnlyWhenPreviousIsSuspended on > > & /var/log/localbuffer > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > If I cut the link to the syslog-server (using iptables to emulate the > > logserver being down), run "logger hello" on the client, and then > after a > > while attach the link (by flushing the iptable rules), I see that the > hello > > message pops up on the rsyslog server. So some kind of spooling or > something > > seems to be active. Strange. Maybe the spooling or whatever is done > on TCP > > level or something. Maybe the rsyslog version from RHN differs from > the > > "normal" versioning? > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > Oops... and I just noticed you use v2. Spooling is not available in > v2. > > > > > > Sorry for not spotting it in the first place... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > You're right, it's not a failover solution by definition. I see > now > > > > > that I > > > > > should have outlined my needs... What I'm aiming at, at least > for > > > > now, > > > > > is a > > > > > semi-failover solution: If the syslog server (i.e. loghost) > goes > > > > down, > > > > > the > > > > > clients should simply spool the messages until the server gets > back > > > > > online. > > > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > > functionality I'm looking for. Is that correct? If so: what's > the > > > > > difference > > > > > between them? > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > but > > > > rather send the messags to another (failover) server if the > primary > > > > fails. > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > the first link does NOT describe a failover case. In the > first > > > > link, > > > > > > data is queued while the syslogd is not available. A failover > case > > > > > > (described in link two) is that if one syslogd goes down, > data is > > > > > sent > > > > > > to another. This is not done in case 1: there, messages are > queued > > > > > while > > > > > > the syslogd is down and sent to *the same syslogd* when it is > up > > > > > again. > > > > > > So no second syslogd involved in case 1, so this is no > failover > > > > > > scenario. > > > > > > > > > > > > HTH > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > about > > > to > > > > > set > > > > > > > up > > > > > > > reliability/failover. I've found two setup tutorials for > this: > > > > > > > > > > > > > > > > > > > > > 1. > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > 2. > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > using > > > > a > > > > > > > completely different syntax. Is it so that the former one > is the > > > > > > syntax > > > > > > > for > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > Regards, > > > > > > > Kenneth Holter > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From mic at npgx.com.au Thu Feb 5 03:01:58 2009 From: mic at npgx.com.au (Michael Mansour) Date: Thu, 5 Feb 2009 13:01:58 +1100 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <1233748683.19733.113.camel@rf10up.intern.adiscon.com> References: <20090203050119.M91067@npgx.com.au> <20090204002209.M97796@npgx.com.au> <1233748683.19733.113.camel@rf10up.intern.adiscon.com> Message-ID: <20090205015904.M19468@npgx.com.au> Hi Reiner, > On Wed, 2009-02-04 at 11:30 +1100, Michael Mansour wrote: > > > Change this: > > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > > > /var/log/messages > > > > > > To this: > > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice > > > /var/log/messages > > > > I think it should be > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.none /var/log/messages I've just popped that in. > > I've just tried that, restarted rsyslog and the messages for milter-regex keep > > appearing in /var/log/messages. > > > > I'm 100% these are daemon.info messages since I also use: > > > > mail.*;daemon.info -/var/log/maillog > > > > and the milter-regex messages that show up in /var/log/maillog are the same > > ones that show up in /var/log/messages. > > > > I'm pretty sure the reason that deamon.info is still going to > > /var/log/messages is because of the "*.info" entry at the beginning of that > > line, which catches daemon.info? > > Yes, because that says "everything with info severity, no matter what > the facility is, matches". > > > Is there a way I can stop daemon.info from showing up in /var/log/messages > > while keeping *.info on that same line? > > The .none in my example above is meant to exclude a specific facility > from the usual processing and this sounds like what you are looking for. > I barely remember that someone had problems with it. So if it does > not work, let me know. The part of the code that handles those old-style > selectors (old but still good!) is one of the few code sequences that > stem directly back to sysklogd and I can't outrule that something > went wrong during all that changes of the engine... > > Please let me know the outcome (saves me the lab). I think this is exactly what I'm looking for. So far I see no milter-regex messages in my /var/log/messages file while they are showing up in my /var/log/maillog file. Also, a restart of apache and crond still shows those messages going to /var/log/messages which is what I want. I'll keep monitoring over the next day or so but I think this is what I'm looking for. Thanks mate! Michael. > Rainer > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com ------- End of Original Message ------- From kenneho.ndu at gmail.com Thu Feb 5 09:58:13 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 09:58:13 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Message-ID: Are you referring to the "smart (over-)engineering" way of doing this? In other words, there are no built in support for failover/spooling/etc in rsyslog version 2? On 2/4/09, Rainer Gerhards wrote: > > Failover is available - that is done like you described in your last > post. But you need to keep an eye on the subtleties, outlined in the > response I've written just 2 minutes ago ;). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 2:03 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > It seems like RHN is way behind on adding rsyslog updates to the repo, > > so it > > seems like I'm more or less stuck with version 2 for now. Are there > any > > failover/spooling/etc functionality in version 2? I'd like to increase > > the > > chance of syslog messages reaching the syslog server, even if it gets > > offline for a short while. I'm sure it's possible to acheive this by > > smart > > (over-)engineering while waiting for rsyslog v3 being released on RHN, > > but > > I'm all for simplicity. :) > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > No prob. :) > > > > > > Then I'm even more puzzled...I've configured my rsyslog client with > > this > > > setup: > > > ** > > > > > > **.* @@client1.example.com:200 > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > & /var/log/localbuffer > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > If I cut the link to the syslog-server (using iptables to emulate > the > > > logserver being down), run "logger hello" on the client, and then > > after a > > > while attach the link (by flushing the iptable rules), I see that > the > > hello > > > message pops up on the rsyslog server. So some kind of spooling or > > something > > > seems to be active. Strange. Maybe the spooling or whatever is done > > on TCP > > > level or something. Maybe the rsyslog version from RHN differs from > > the > > > "normal" versioning? > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > Oops... and I just noticed you use v2. Spooling is not available > in > > v2. > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > You're right, it's not a failover solution by definition. I > see > > now > > > > > > that I > > > > > > should have outlined my needs... What I'm aiming at, at least > > for > > > > > now, > > > > > > is a > > > > > > semi-failover solution: If the syslog server (i.e. loghost) > > goes > > > > > down, > > > > > > the > > > > > > clients should simply spool the messages until the server gets > > back > > > > > > online. > > > > > > > > > > > > Back to the examples I linked to: They both seem to provide > the > > > > > > functionality I'm looking for. Is that correct? If so: what's > > the > > > > > > difference > > > > > > between them? > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > > but > > > > > rather send the messags to another (failover) server if the > > primary > > > > > fails. > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > first > > > > > link, > > > > > > > data is queued while the syslogd is not available. A > failover > > case > > > > > > > (described in link two) is that if one syslogd goes down, > > data is > > > > > > sent > > > > > > > to another. This is not done in case 1: there, messages are > > queued > > > > > > while > > > > > > > the syslogd is down and sent to *the same syslogd* when it > is > > up > > > > > > again. > > > > > > > So no second syslogd involved in case 1, so this is no > > failover > > > > > > > scenario. > > > > > > > > > > > > > > HTH > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > > about > > > > to > > > > > > set > > > > > > > > up > > > > > > > > reliability/failover. I've found two setup tutorials for > > this: > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > 2. > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > > using > > > > > a > > > > > > > > completely different syntax. Is it so that the former one > > is the > > > > > > > syntax > > > > > > > > for > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > Regards, > > > > > > > > Kenneth Holter > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 5 11:11:12 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 5 Feb 2009 11:11:12 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> As I said: the second link you posted is failover and it is a supported in v2. So failover *is* available in v2. Queuing is not. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Thursday, February 05, 2009 9:58 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Are you referring to the "smart (over-)engineering" way of doing this? > In > other words, there are no built in support for failover/spooling/etc in > rsyslog version 2? > > On 2/4/09, Rainer Gerhards wrote: > > > > Failover is available - that is done like you described in your last > > post. But you need to keep an eye on the subtleties, outlined in the > > response I've written just 2 minutes ago ;). > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > It seems like RHN is way behind on adding rsyslog updates to the > repo, > > > so it > > > seems like I'm more or less stuck with version 2 for now. Are there > > any > > > failover/spooling/etc functionality in version 2? I'd like to > increase > > > the > > > chance of syslog messages reaching the syslog server, even if it > gets > > > offline for a short while. I'm sure it's possible to acheive this > by > > > smart > > > (over-)engineering while waiting for rsyslog v3 being released on > RHN, > > > but > > > I'm all for simplicity. :) > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > No prob. :) > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog client > with > > > this > > > > setup: > > > > ** > > > > > > > > **.* @@client1.example.com:200 > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > & /var/log/localbuffer > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to emulate > > the > > > > logserver being down), run "logger hello" on the client, and then > > > after a > > > > while attach the link (by flushing the iptable rules), I see that > > the > > > hello > > > > message pops up on the rsyslog server. So some kind of spooling > or > > > something > > > > seems to be active. Strange. Maybe the spooling or whatever is > done > > > on TCP > > > > level or something. Maybe the rsyslog version from RHN differs > from > > > the > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > Oops... and I just noticed you use v2. Spooling is not > available > > in > > > v2. > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > You're right, it's not a failover solution by definition. I > > see > > > now > > > > > > > that I > > > > > > > should have outlined my needs... What I'm aiming at, at > least > > > for > > > > > > now, > > > > > > > is a > > > > > > > semi-failover solution: If the syslog server (i.e. loghost) > > > goes > > > > > > down, > > > > > > > the > > > > > > > clients should simply spool the messages until the server > gets > > > back > > > > > > > online. > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to provide > > the > > > > > > > functionality I'm looking for. Is that correct? If so: > what's > > > the > > > > > > > difference > > > > > > > between them? > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not > spool > > > but > > > > > > rather send the messags to another (failover) server if the > > > primary > > > > > > fails. > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > wrote: > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > > first > > > > > > link, > > > > > > > > data is queued while the syslogd is not available. A > > failover > > > case > > > > > > > > (described in link two) is that if one syslogd goes down, > > > data is > > > > > > > sent > > > > > > > > to another. This is not done in case 1: there, messages > are > > > queued > > > > > > > while > > > > > > > > the syslogd is down and sent to *the same syslogd* when > it > > is > > > up > > > > > > > again. > > > > > > > > So no second syslogd involved in case 1, so this is no > > > failover > > > > > > > > scenario. > > > > > > > > > > > > > > > > HTH > > > > > > > > Rainer > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and > are > > > about > > > > > to > > > > > > > set > > > > > > > > > up > > > > > > > > > reliability/failover. I've found two setup tutorials > for > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > 2. > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, > but > > > using > > > > > > a > > > > > > > > > completely different syntax. Is it so that the former > one > > > is the > > > > > > > > syntax > > > > > > > > > for > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Kenneth Holter > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Thu Feb 5 11:31:39 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 11:31:39 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> Message-ID: Sorry, my fault. You said this: "Failover is available - that is done like you described in your last post.", and my post you referred to talked about the engineering stuff. Anyway, the second link I posted describes the failover functionality, but not any specifics how the local buffer is used. Back to my configuration which I posted earlier in the thread: **.* @@server1**.example.com:200* * $ActionExecOnlyWhenPreviousIsSuspended on & /var/log/localbuffer $ActionExecOnlyWhenPreviousIsSuspended off* It is my understanding that messages that doesn't reach the server1 machine will be store in the /var/log/localbuffer file. Can you point me to documentation that explains that happens next with these messages? On 2/5/09, Rainer Gerhards wrote: > As I said: the second link you posted is failover and it is a supported > in v2. So failover *is* available in v2. Queuing is not. > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Thursday, February 05, 2009 9:58 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > Are you referring to the "smart (over-)engineering" way of doing this? > > In > > other words, there are no built in support for failover/spooling/etc > in > > rsyslog version 2? > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > Failover is available - that is done like you described in your last > > > post. But you need to keep an eye on the subtleties, outlined in the > > > response I've written just 2 minutes ago ;). > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > It seems like RHN is way behind on adding rsyslog updates to the > > repo, > > > > so it > > > > seems like I'm more or less stuck with version 2 for now. Are > there > > > any > > > > failover/spooling/etc functionality in version 2? I'd like to > > increase > > > > the > > > > chance of syslog messages reaching the syslog server, even if it > > gets > > > > offline for a short while. I'm sure it's possible to acheive this > > by > > > > smart > > > > (over-)engineering while waiting for rsyslog v3 being released on > > RHN, > > > > but > > > > I'm all for simplicity. :) > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > No prob. :) > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog client > > with > > > > this > > > > > setup: > > > > > ** > > > > > > > > > > **.* @@client1.example.com:200 > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > & /var/log/localbuffer > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > emulate > > > the > > > > > logserver being down), run "logger hello" on the client, and > then > > > > after a > > > > > while attach the link (by flushing the iptable rules), I see > that > > > the > > > > hello > > > > > message pops up on the rsyslog server. So some kind of spooling > > or > > > > something > > > > > seems to be active. Strange. Maybe the spooling or whatever is > > done > > > > on TCP > > > > > level or something. Maybe the rsyslog version from RHN differs > > from > > > > the > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > Oops... and I just noticed you use v2. Spooling is not > > available > > > in > > > > v2. > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > You're right, it's not a failover solution by definition. > I > > > see > > > > now > > > > > > > > that I > > > > > > > > should have outlined my needs... What I'm aiming at, at > > least > > > > for > > > > > > > now, > > > > > > > > is a > > > > > > > > semi-failover solution: If the syslog server (i.e. > loghost) > > > > goes > > > > > > > down, > > > > > > > > the > > > > > > > > clients should simply spool the messages until the server > > gets > > > > back > > > > > > > > online. > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > provide > > > the > > > > > > > > functionality I'm looking for. Is that correct? If so: > > what's > > > > the > > > > > > > > difference > > > > > > > > between them? > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not > > spool > > > > but > > > > > > > rather send the messags to another (failover) server if the > > > > primary > > > > > > > fails. > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > wrote: > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > > > first > > > > > > > link, > > > > > > > > > data is queued while the syslogd is not available. A > > > failover > > > > case > > > > > > > > > (described in link two) is that if one syslogd goes > down, > > > > data is > > > > > > > > sent > > > > > > > > > to another. This is not done in case 1: there, messages > > are > > > > queued > > > > > > > > while > > > > > > > > > the syslogd is down and sent to *the same syslogd* when > > it > > > is > > > > up > > > > > > > > again. > > > > > > > > > So no second syslogd involved in case 1, so this is no > > > > failover > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > [mailto:rsyslog- > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and > > are > > > > about > > > > > > to > > > > > > > > set > > > > > > > > > > up > > > > > > > > > > reliability/failover. I've found two setup tutorials > > for > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > 2. > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, > > but > > > > using > > > > > > > a > > > > > > > > > > completely different syntax. Is it so that the former > > one > > > > is the > > > > > > > > > syntax > > > > > > > > > > for > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Kenneth Holter > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 5 12:04:28 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 5 Feb 2009 12:04:28 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> I am sorry, but this is going beyond what I can do for free. I'd consider purchasing commercial services. The reason is you try to get things real reliable, but you have lots of constraints and fine subtle issues. There need to be made tradoffs and some tough decisions. All in all, that's a real consulting project. Everything you need to know is fully documented, either in rsyslog, it's code, my blog and even RFCs. I have pointed you to these things. I fully understand that it is not easy to get the big picture from that. It is far from being that, you need to be an expert in syslog to know exactly how to put together those things. Syslog is boring to most (no bashing), so we have few experts on the matter. So if you need to do things in a quite reliable way, it would probably a good idea to task an expert with consulting. I am sorry if that post is rather blunt, but I think it is better we all know where we are. Honestly, I put up a lot of unpaid time into making the project grow. I am also able to give a lot of free support. I am grateful Adiscon pays for this. But please understand that we not also can give away consulting for free - something needs to pay the power, machines - and my lunch! - at the end of the day ;) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Thursday, February 05, 2009 11:32 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Sorry, my fault. You said this: "Failover is available - that is done > like > you described in your last > post.", and my post you referred to talked about the engineering stuff. > > Anyway, the second link I posted describes the failover functionality, > but > not any specifics how the local buffer is used. Back to my > configuration > which I posted earlier in the thread: > > > **.* @@server1**.example.com:200* * > $ActionExecOnlyWhenPreviousIsSuspended on > & /var/log/localbuffer > $ActionExecOnlyWhenPreviousIsSuspended off* > > > It is my understanding that messages that doesn't reach the server1 > machine > will be store in the /var/log/localbuffer file. Can you point me to > documentation that explains that happens next with these messages? > > > > > On 2/5/09, Rainer Gerhards wrote: > > > As I said: the second link you posted is failover and it is a > supported > > in v2. So failover *is* available in v2. Queuing is not. > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Thursday, February 05, 2009 9:58 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > Are you referring to the "smart (over-)engineering" way of doing > this? > > > In > > > other words, there are no built in support for > failover/spooling/etc > > in > > > rsyslog version 2? > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > Failover is available - that is done like you described in your > last > > > > post. But you need to keep an eye on the subtleties, outlined in > the > > > > response I've written just 2 minutes ago ;). > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > It seems like RHN is way behind on adding rsyslog updates to > the > > > repo, > > > > > so it > > > > > seems like I'm more or less stuck with version 2 for now. Are > > there > > > > any > > > > > failover/spooling/etc functionality in version 2? I'd like to > > > increase > > > > > the > > > > > chance of syslog messages reaching the syslog server, even if > it > > > gets > > > > > offline for a short while. I'm sure it's possible to acheive > this > > > by > > > > > smart > > > > > (over-)engineering while waiting for rsyslog v3 being released > on > > > RHN, > > > > > but > > > > > I'm all for simplicity. :) > > > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > > > No prob. :) > > > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog > client > > > with > > > > > this > > > > > > setup: > > > > > > ** > > > > > > > > > > > > **.* @@client1.example.com:200 > > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > > & /var/log/localbuffer > > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > > emulate > > > > the > > > > > > logserver being down), run "logger hello" on the client, and > > then > > > > > after a > > > > > > while attach the link (by flushing the iptable rules), I see > > that > > > > the > > > > > hello > > > > > > message pops up on the rsyslog server. So some kind of > spooling > > > or > > > > > something > > > > > > seems to be active. Strange. Maybe the spooling or whatever > is > > > done > > > > > on TCP > > > > > > level or something. Maybe the rsyslog version from RHN > differs > > > from > > > > > the > > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > Oops... and I just noticed you use v2. Spooling is not > > > available > > > > in > > > > > v2. > > > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > > To: rsyslog-users > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > > > You're right, it's not a failover solution by > definition. > > I > > > > see > > > > > now > > > > > > > > > that I > > > > > > > > > should have outlined my needs... What I'm aiming at, at > > > least > > > > > for > > > > > > > > now, > > > > > > > > > is a > > > > > > > > > semi-failover solution: If the syslog server (i.e. > > loghost) > > > > > goes > > > > > > > > down, > > > > > > > > > the > > > > > > > > > clients should simply spool the messages until the > server > > > gets > > > > > back > > > > > > > > > online. > > > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > > provide > > > > the > > > > > > > > > functionality I'm looking for. Is that correct? If so: > > > what's > > > > > the > > > > > > > > > difference > > > > > > > > > between them? > > > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not > > > spool > > > > > but > > > > > > > > rather send the messags to another (failover) server if > the > > > > > primary > > > > > > > > fails. > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In > the > > > > > first > > > > > > > > link, > > > > > > > > > > data is queued while the syslogd is not available. A > > > > failover > > > > > case > > > > > > > > > > (described in link two) is that if one syslogd goes > > down, > > > > > data is > > > > > > > > > sent > > > > > > > > > > to another. This is not done in case 1: there, > messages > > > are > > > > > queued > > > > > > > > > while > > > > > > > > > > the syslogd is down and sent to *the same syslogd* > when > > > it > > > > is > > > > > up > > > > > > > > > again. > > > > > > > > > > So no second syslogd involved in case 1, so this is > no > > > > > failover > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > [mailto:rsyslog- > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > Holter > > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, > and > > > are > > > > > about > > > > > > > to > > > > > > > > > set > > > > > > > > > > > up > > > > > > > > > > > reliability/failover. I've found two setup > tutorials > > > for > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > > 2. > > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable > transfer, > > > but > > > > > using > > > > > > > > a > > > > > > > > > > > completely different syntax. Is it so that the > former > > > one > > > > > is the > > > > > > > > > > syntax > > > > > > > > > > > for > > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > Kenneth Holter > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Thu Feb 5 12:52:37 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 12:52:37 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> Message-ID: I understand completely. :) I'll sure I will find the documentation I need, even though I'm using an aceint version of rsyslog. :) Thanks for the help so far, anyway. On 2/5/09, Rainer Gerhards wrote: > > I am sorry, but this is going beyond what I can do for free. I'd > consider purchasing commercial services. The reason is you try to get > things real reliable, but you have lots of constraints and fine subtle > issues. There need to be made tradoffs and some tough decisions. All in > all, that's a real consulting project. > > Everything you need to know is fully documented, either in rsyslog, it's > code, my blog and even RFCs. I have pointed you to these things. I fully > understand that it is not easy to get the big picture from that. It is > far from being that, you need to be an expert in syslog to know exactly > how to put together those things. Syslog is boring to most (no bashing), > so we have few experts on the matter. So if you need to do things in a > quite reliable way, it would probably a good idea to task an expert with > consulting. > > I am sorry if that post is rather blunt, but I think it is better we all > know where we are. Honestly, I put up a lot of unpaid time into making > the project grow. I am also able to give a lot of free support. I am > grateful Adiscon pays for this. But please understand that we not also > can give away consulting for free - something needs to pay the power, > machines - and my lunch! - at the end of the day ;) > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Thursday, February 05, 2009 11:32 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > Sorry, my fault. You said this: "Failover is available - that is done > > like > > you described in your last > > post.", and my post you referred to talked about the engineering > stuff. > > > > Anyway, the second link I posted describes the failover functionality, > > but > > not any specifics how the local buffer is used. Back to my > > configuration > > which I posted earlier in the thread: > > > > > > **.* @@server1**.example.com:200* * > > $ActionExecOnlyWhenPreviousIsSuspended on > > & /var/log/localbuffer > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > It is my understanding that messages that doesn't reach the server1 > > machine > > will be store in the /var/log/localbuffer file. Can you point me to > > documentation that explains that happens next with these messages? > > > > > > > > > > On 2/5/09, Rainer Gerhards wrote: > > > > > As I said: the second link you posted is failover and it is a > > supported > > > in v2. So failover *is* available in v2. Queuing is not. > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Thursday, February 05, 2009 9:58 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > Are you referring to the "smart (over-)engineering" way of doing > > this? > > > > In > > > > other words, there are no built in support for > > failover/spooling/etc > > > in > > > > rsyslog version 2? > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > Failover is available - that is done like you described in your > > last > > > > > post. But you need to keep an eye on the subtleties, outlined in > > the > > > > > response I've written just 2 minutes ago ;). > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > It seems like RHN is way behind on adding rsyslog updates to > > the > > > > repo, > > > > > > so it > > > > > > seems like I'm more or less stuck with version 2 for now. Are > > > there > > > > > any > > > > > > failover/spooling/etc functionality in version 2? I'd like to > > > > increase > > > > > > the > > > > > > chance of syslog messages reaching the syslog server, even if > > it > > > > gets > > > > > > offline for a short while. I'm sure it's possible to acheive > > this > > > > by > > > > > > smart > > > > > > (over-)engineering while waiting for rsyslog v3 being released > > on > > > > RHN, > > > > > > but > > > > > > I'm all for simplicity. :) > > > > > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > > > > > No prob. :) > > > > > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog > > client > > > > with > > > > > > this > > > > > > > setup: > > > > > > > ** > > > > > > > > > > > > > > **.* @@client1.example.com:200 > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > > > & /var/log/localbuffer > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > > > emulate > > > > > the > > > > > > > logserver being down), run "logger hello" on the client, and > > > then > > > > > > after a > > > > > > > while attach the link (by flushing the iptable rules), I see > > > that > > > > > the > > > > > > hello > > > > > > > message pops up on the rsyslog server. So some kind of > > spooling > > > > or > > > > > > something > > > > > > > seems to be active. Strange. Maybe the spooling or whatever > > is > > > > done > > > > > > on TCP > > > > > > > level or something. Maybe the rsyslog version from RHN > > differs > > > > from > > > > > > the > > > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > Oops... and I just noticed you use v2. Spooling is not > > > > available > > > > > in > > > > > > v2. > > > > > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > > > To: rsyslog-users > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > [mailto:rsyslog- > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > > > To: rsyslog-users > > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > > > > > You're right, it's not a failover solution by > > definition. > > > I > > > > > see > > > > > > now > > > > > > > > > > that I > > > > > > > > > > should have outlined my needs... What I'm aiming at, > at > > > > least > > > > > > for > > > > > > > > > now, > > > > > > > > > > is a > > > > > > > > > > semi-failover solution: If the syslog server (i.e. > > > loghost) > > > > > > goes > > > > > > > > > down, > > > > > > > > > > the > > > > > > > > > > clients should simply spool the messages until the > > server > > > > gets > > > > > > back > > > > > > > > > > online. > > > > > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > > > provide > > > > > the > > > > > > > > > > functionality I'm looking for. Is that correct? If so: > > > > what's > > > > > > the > > > > > > > > > > difference > > > > > > > > > > between them? > > > > > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does > not > > > > spool > > > > > > but > > > > > > > > > rather send the messags to another (failover) server if > > the > > > > > > primary > > > > > > > > > fails. > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In > > the > > > > > > first > > > > > > > > > link, > > > > > > > > > > > data is queued while the syslogd is not available. A > > > > > failover > > > > > > case > > > > > > > > > > > (described in link two) is that if one syslogd goes > > > down, > > > > > > data is > > > > > > > > > > sent > > > > > > > > > > > to another. This is not done in case 1: there, > > messages > > > > are > > > > > > queued > > > > > > > > > > while > > > > > > > > > > > the syslogd is down and sent to *the same syslogd* > > when > > > > it > > > > > is > > > > > > up > > > > > > > > > > again. > > > > > > > > > > > So no second syslogd involved in case 1, so this is > > no > > > > > > failover > > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > > [mailto:rsyslog- > > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > > Holter > > > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, > > and > > > > are > > > > > > about > > > > > > > > to > > > > > > > > > > set > > > > > > > > > > > > up > > > > > > > > > > > > reliability/failover. I've found two setup > > tutorials > > > > for > > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > > > 2. > > > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable > > transfer, > > > > but > > > > > > using > > > > > > > > > a > > > > > > > > > > > > completely different syntax. Is it so that the > > former > > > > one > > > > > > is the > > > > > > > > > > > syntax > > > > > > > > > > > > for > > > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Kenneth Holter > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 5 13:06:58 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 5 Feb 2009 13:06:58 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB4D@grfint2.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Thursday, February 05, 2009 12:53 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > I understand completely. :) > > I'll sure I will find the documentation I need, even though I'm using > an > aceint version of rsyslog. :) > Keep in mind that each version comes with a complete doc set. Even if that is missing in the package you have, you can download the same version from www.rsyslog.com and look at the included doc. Rainer > > Thanks for the help so far, anyway. > > > On 2/5/09, Rainer Gerhards wrote: > > > > I am sorry, but this is going beyond what I can do for free. I'd > > consider purchasing commercial services. The reason is you try to get > > things real reliable, but you have lots of constraints and fine > subtle > > issues. There need to be made tradoffs and some tough decisions. All > in > > all, that's a real consulting project. > > > > Everything you need to know is fully documented, either in rsyslog, > it's > > code, my blog and even RFCs. I have pointed you to these things. I > fully > > understand that it is not easy to get the big picture from that. It > is > > far from being that, you need to be an expert in syslog to know > exactly > > how to put together those things. Syslog is boring to most (no > bashing), > > so we have few experts on the matter. So if you need to do things in > a > > quite reliable way, it would probably a good idea to task an expert > with > > consulting. > > > > I am sorry if that post is rather blunt, but I think it is better we > all > > know where we are. Honestly, I put up a lot of unpaid time into > making > > the project grow. I am also able to give a lot of free support. I am > > grateful Adiscon pays for this. But please understand that we not > also > > can give away consulting for free - something needs to pay the power, > > machines - and my lunch! - at the end of the day ;) > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Thursday, February 05, 2009 11:32 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > Sorry, my fault. You said this: "Failover is available - that is > done > > > like > > > you described in your last > > > post.", and my post you referred to talked about the engineering > > stuff. > > > > > > Anyway, the second link I posted describes the failover > functionality, > > > but > > > not any specifics how the local buffer is used. Back to my > > > configuration > > > which I posted earlier in the thread: > > > > > > > > > **.* @@server1**.example.com:200* > * > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > & /var/log/localbuffer > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > It is my understanding that messages that doesn't reach the server1 > > > machine > > > will be store in the /var/log/localbuffer file. Can you point me to > > > documentation that explains that happens next with these messages? > > > > > > > > > > > > > > > On 2/5/09, Rainer Gerhards wrote: > > > > > > > As I said: the second link you posted is failover and it is a > > > supported > > > > in v2. So failover *is* available in v2. Queuing is not. > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Thursday, February 05, 2009 9:58 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Are you referring to the "smart (over-)engineering" way of > doing > > > this? > > > > > In > > > > > other words, there are no built in support for > > > failover/spooling/etc > > > > in > > > > > rsyslog version 2? > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > Failover is available - that is done like you described in > your > > > last > > > > > > post. But you need to keep an eye on the subtleties, outlined > in > > > the > > > > > > response I've written just 2 minutes ago ;). > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > It seems like RHN is way behind on adding rsyslog updates > to > > > the > > > > > repo, > > > > > > > so it > > > > > > > seems like I'm more or less stuck with version 2 for now. > Are > > > > there > > > > > > any > > > > > > > failover/spooling/etc functionality in version 2? I'd like > to > > > > > increase > > > > > > > the > > > > > > > chance of syslog messages reaching the syslog server, even > if > > > it > > > > > gets > > > > > > > offline for a short while. I'm sure it's possible to > acheive > > > this > > > > > by > > > > > > > smart > > > > > > > (over-)engineering while waiting for rsyslog v3 being > released > > > on > > > > > RHN, > > > > > > > but > > > > > > > I'm all for simplicity. :) > > > > > > > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > > > > > > > No prob. :) > > > > > > > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog > > > client > > > > > with > > > > > > > this > > > > > > > > setup: > > > > > > > > ** > > > > > > > > > > > > > > > > **.* @@client1.example.com:200 > > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > > > > & /var/log/localbuffer > > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > > > > emulate > > > > > > the > > > > > > > > logserver being down), run "logger hello" on the client, > and > > > > then > > > > > > > after a > > > > > > > > while attach the link (by flushing the iptable rules), I > see > > > > that > > > > > > the > > > > > > > hello > > > > > > > > message pops up on the rsyslog server. So some kind of > > > spooling > > > > > or > > > > > > > something > > > > > > > > seems to be active. Strange. Maybe the spooling or > whatever > > > is > > > > > done > > > > > > > on TCP > > > > > > > > level or something. Maybe the rsyslog version from RHN > > > differs > > > > > from > > > > > > > the > > > > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > wrote: > > > > > > > > > Oops... and I just noticed you use v2. Spooling is not > > > > > available > > > > > > in > > > > > > > v2. > > > > > > > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer > Gerhards > > > > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > > > > To: rsyslog-users > > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > [mailto:rsyslog- > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > Holter > > > > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > > > > To: rsyslog-users > > > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > > > > > > > You're right, it's not a failover solution by > > > definition. > > > > I > > > > > > see > > > > > > > now > > > > > > > > > > > that I > > > > > > > > > > > should have outlined my needs... What I'm aiming > at, > > at > > > > > least > > > > > > > for > > > > > > > > > > now, > > > > > > > > > > > is a > > > > > > > > > > > semi-failover solution: If the syslog server (i.e. > > > > loghost) > > > > > > > goes > > > > > > > > > > down, > > > > > > > > > > > the > > > > > > > > > > > clients should simply spool the messages until the > > > server > > > > > gets > > > > > > > back > > > > > > > > > > > online. > > > > > > > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > > > > provide > > > > > > the > > > > > > > > > > > functionality I'm looking for. Is that correct? If > so: > > > > > what's > > > > > > > the > > > > > > > > > > > difference > > > > > > > > > > > between them? > > > > > > > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does > > not > > > > > spool > > > > > > > but > > > > > > > > > > rather send the messags to another (failover) server > if > > > the > > > > > > > primary > > > > > > > > > > fails. > > > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. > In > > > the > > > > > > > first > > > > > > > > > > link, > > > > > > > > > > > > data is queued while the syslogd is not > available. A > > > > > > failover > > > > > > > case > > > > > > > > > > > > (described in link two) is that if one syslogd > goes > > > > down, > > > > > > > data is > > > > > > > > > > > sent > > > > > > > > > > > > to another. This is not done in case 1: there, > > > messages > > > > > are > > > > > > > queued > > > > > > > > > > > while > > > > > > > > > > > > the syslogd is down and sent to *the same > syslogd* > > > when > > > > > it > > > > > > is > > > > > > > up > > > > > > > > > > > again. > > > > > > > > > > > > So no second syslogd involved in case 1, so this > is > > > no > > > > > > > failover > > > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > > > [mailto:rsyslog- > > > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > > > Holter > > > > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from > RHN, > > > and > > > > > are > > > > > > > about > > > > > > > > > to > > > > > > > > > > > set > > > > > > > > > > > > > up > > > > > > > > > > > > > reliability/failover. I've found two setup > > > tutorials > > > > > for > > > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > > > > 2. > > > > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable > > > transfer, > > > > > but > > > > > > > using > > > > > > > > > > a > > > > > > > > > > > > > completely different syntax. Is it so that the > > > former > > > > > one > > > > > > > is the > > > > > > > > > > > > syntax > > > > > > > > > > > > > for > > > > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > Kenneth Holter > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Thu Feb 5 13:38:14 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 13:38:14 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> Message-ID: Thanks, I'll consider this approach. On 2/4/09, Daniel Anson wrote: > > I personally run RHEL 5 servers with rsyslog. Due to the lack of a > current and stable rsyslog rpm, I always build rsyslog on the server. > It takes less than 5 minutes and is very stable. > > Daniel Anson > Rackspace Managed Hosting > danson at rackspace.com > > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Wednesday, February 04, 2009 7:14 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Failover is available - that is done like you described in your last > post. But you need to keep an eye on the subtleties, outlined in the > response I've written just 2 minutes ago ;). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 2:03 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > It seems like RHN is way behind on adding rsyslog updates to the repo, > > so it > > seems like I'm more or less stuck with version 2 for now. Are there > any > > failover/spooling/etc functionality in version 2? I'd like to increase > > the > > chance of syslog messages reaching the syslog server, even if it gets > > offline for a short while. I'm sure it's possible to acheive this by > > smart > > (over-)engineering while waiting for rsyslog v3 being released on RHN, > > but > > I'm all for simplicity. :) > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > No prob. :) > > > > > > Then I'm even more puzzled...I've configured my rsyslog client with > > this > > > setup: > > > ** > > > > > > **.* @@client1.example.com:200 > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > & /var/log/localbuffer > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > If I cut the link to the syslog-server (using iptables to emulate > the > > > logserver being down), run "logger hello" on the client, and then > > after a > > > while attach the link (by flushing the iptable rules), I see that > the > > hello > > > message pops up on the rsyslog server. So some kind of spooling or > > something > > > seems to be active. Strange. Maybe the spooling or whatever is done > > on TCP > > > level or something. Maybe the rsyslog version from RHN differs from > > the > > > "normal" versioning? > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > Oops... and I just noticed you use v2. Spooling is not available > in > > v2. > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > You're right, it's not a failover solution by definition. I > see > > now > > > > > > that I > > > > > > should have outlined my needs... What I'm aiming at, at least > > for > > > > > now, > > > > > > is a > > > > > > semi-failover solution: If the syslog server (i.e. loghost) > > goes > > > > > down, > > > > > > the > > > > > > clients should simply spool the messages until the server gets > > back > > > > > > online. > > > > > > > > > > > > Back to the examples I linked to: They both seem to provide > the > > > > > > functionality I'm looking for. Is that correct? If so: what's > > the > > > > > > difference > > > > > > between them? > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > > but > > > > > rather send the messags to another (failover) server if the > > primary > > > > > fails. > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > first > > > > > link, > > > > > > > data is queued while the syslogd is not available. A > failover > > case > > > > > > > (described in link two) is that if one syslogd goes down, > > data is > > > > > > sent > > > > > > > to another. This is not done in case 1: there, messages are > > queued > > > > > > while > > > > > > > the syslogd is down and sent to *the same syslogd* when it > is > > up > > > > > > again. > > > > > > > So no second syslogd involved in case 1, so this is no > > failover > > > > > > > scenario. > > > > > > > > > > > > > > HTH > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > > about > > > > to > > > > > > set > > > > > > > > up > > > > > > > > reliability/failover. I've found two setup tutorials for > > this: > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > 2. > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > > using > > > > > a > > > > > > > > completely different syntax. Is it so that the former one > > is the > > > > > > > syntax > > > > > > > > for > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > Regards, > > > > > > > > Kenneth Holter > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of > the > individual or entity to which this message is addressed, and unless > otherwise > expressly indicated, is confidential and privileged information of > Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at abuse at rackspace.com, and delete the original message. > Your cooperation is appreciated. > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Thu Feb 5 16:52:03 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Thu, 5 Feb 2009 15:52:03 +0000 Subject: [rsyslog] logger problem Message-ID: <69544300902050752h5f78e701m4eebc0024d4826b6@mail.gmail.com> hi guys, I have successfully use logger to send messages to syslog. however this works well locally. now i need to send a message to a remote syslog server. i can't see how to do it with logger. let assume that i am sending from IP1 to IP2 how do i go about it. thanks From danson at rackspace.com Thu Feb 5 17:03:19 2009 From: danson at rackspace.com (Daniel Anson) Date: Thu, 5 Feb 2009 10:03:19 -0600 Subject: [rsyslog] logger problem In-Reply-To: <69544300902050752h5f78e701m4eebc0024d4826b6@mail.gmail.com> References: <69544300902050752h5f78e701m4eebc0024d4826b6@mail.gmail.com> Message-ID: <5942_1233849923_n15G5KPn012483_96AF20FDF4301D419B33CCE8E3A0132B0B133AB7@SAT4MX07.RACKSPACE.CORP> Use IP1 as a relay. Put something like this is syslog.conf and restart (HUP) it: *.* @IP2 This will log locally using logger but will relay the log to IP2 as well. I just used *.* but you can specify facility/severity of logs there. --Daniel ANson -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Jules Pagna Disso Sent: Thursday, February 05, 2009 9:52 AM To: rsyslog-users Subject: [rsyslog] logger problem hi guys, I have successfully use logger to send messages to syslog. however this works well locally. now i need to send a message to a remote syslog server. i can't see how to do it with logger. let assume that i am sending from IP1 to IP2 how do i go about it. thanks _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From hks.private at gmail.com Thu Feb 5 17:53:08 2009 From: hks.private at gmail.com ((private) HKS) Date: Thu, 5 Feb 2009 11:53:08 -0500 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <1233748683.19733.113.camel@rf10up.intern.adiscon.com> References: <20090203050119.M91067@npgx.com.au> <20090204002209.M97796@npgx.com.au> <1233748683.19733.113.camel@rf10up.intern.adiscon.com> Message-ID: On Wed, Feb 4, 2009 at 6:58 AM, Rainer Gerhards wrote: > On Wed, 2009-02-04 at 11:30 +1100, Michael Mansour wrote: >> > Change this: >> > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none >> > /var/log/messages >> > >> > To this: >> > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice >> > /var/log/messages >> > > I think it should be > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.none /var/log/messages > Erp...yes, that's correct. My config would have had all notice+ severity daemon messages going to /var/log/messages (though it should have ignored daemon.debug and daemon.info, right?). Thanks for the correction. -HKS From aoz.syn at gmail.com Fri Feb 6 00:55:06 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 5 Feb 2009 16:55:06 -0700 Subject: [rsyslog] sticky templates Message-ID: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> I'm more feeling things out than requesting a feature, but is there a way to control when templates are evaluated? Say I'd like to name some files with very specific timestamps, but instead of re-evaluating the template every time it receives an event, just re-evaluate whenever rsyslogd has cause to reopen the file. Am I sane? RB From mic at npgx.com.au Fri Feb 6 01:12:25 2009 From: mic at npgx.com.au (Michael Mansour) Date: Fri, 6 Feb 2009 11:12:25 +1100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> Message-ID: <20090206000942.M2544@npgx.com.au> Hi Daniel, > Thanks, I'll consider this approach. > > On 2/4/09, Daniel Anson wrote: > > > > I personally run RHEL 5 servers with rsyslog. Due to the lack of a > > current and stable rsyslog rpm, I always build rsyslog on the server. > > It takes less than 5 minutes and is very stable. Have you tried building an RPM of rsyslog yourself? I put the method on how I did it in the rsyslog wiki, and I have 3.x built in RPM and running on various SL 4 servers (RHEL 4 derivatives). I haven't tried SL 5 with rsyslog yet, but you should be able to use my spec to build it. If you get it running, we can make it available to the community. Regards, Michael. > > Daniel Anson > > Rackspace Managed Hosting > > danson at rackspace.com From david at lang.hm Fri Feb 6 03:59:02 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 5 Feb 2009 18:59:02 -0800 (PST) Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> Message-ID: On Thu, 5 Feb 2009, RB wrote: > I'm more feeling things out than requesting a feature, but is there a > way to control when templates are evaluated? Say I'd like to name > some files with very specific timestamps, but instead of re-evaluating > the template every time it receives an event, just re-evaluate > whenever rsyslogd has cause to reopen the file. Am I sane? I could see the use for this sort of thing. David Lang From aoz.syn at gmail.com Fri Feb 6 03:03:51 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 5 Feb 2009 19:03:51 -0700 Subject: [rsyslog] sticky templates In-Reply-To: References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> Message-ID: <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> On Thu, Feb 5, 2009 at 19:59, wrote: >> I'm more feeling things out than requesting a feature, but is there a >> way to control when templates are evaluated? Say I'd like to name >> some files with very specific timestamps, but instead of re-evaluating >> the template every time it receives an event, just re-evaluate >> whenever rsyslogd has cause to reopen the file. Am I sane? > > I could see the use for this sort of thing. The first use-case I had come up with was with an output channel - I know they're scheduled to disappear, but it'd be quite nice to set a size limit for the channel and see the over-limit "resolved" by closing and re-opening. From rgerhards at hq.adiscon.com Fri Feb 6 12:01:12 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 12:01:12 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> Message-ID: <1233918072.19733.160.camel@rf10up.intern.adiscon.com> On Thu, 2009-02-05 at 19:03 -0700, RB wrote: > On Thu, Feb 5, 2009 at 19:59, wrote: > >> I'm more feeling things out than requesting a feature, but is there a > >> way to control when templates are evaluated? Say I'd like to name > >> some files with very specific timestamps, but instead of re-evaluating > >> the template every time it receives an event, just re-evaluate > >> whenever rsyslogd has cause to reopen the file. Am I sane? > > > > I could see the use for this sort of thing. > > The first use-case I had come up with was with an output channel - I > know they're scheduled to disappear, but it'd be quite nice to set a > size limit for the channel and see the over-limit "resolved" by > closing and re-opening. Actually, I think this is the only use case. What we need to look at is when a file is closed. It is closed when there is need to. So, when is there need? There are currently three cases where need arises a) HUP or restart b) output channel max size logic c) change in filename (for dynafiles, only) I think we can ignore a) in this context. I agree that it may be useful in case b). For the time being let's focus on case c): I simplified a bit. Actually, the file is not closed immediately when the file name changes. The file is kept open, in a kind of cache. So when the very same file name is used again, the file descriptor is taken from the cache and there is no need to call open and close APIs (very time consuming). The usual case is that something like HOSTNAME or TAG is used in dynamic filename generation. In these cases, it is quite common that a small set of different filenames is written to. So with the cache logic, we can ensure that we have good performance no matter in what order messages come in (generally, they appear random and thus there is a large probability that the next message will go to a different file on a sufficiently busy system). A file is actually closed only if the cache runs out of space (or cases a) or b) above happen). Now let's think what happens if the dynamic name would not be evaluated. Let's stick with the hostname. We have the following message sequence: Host Msg A M1 A M2 B Ma A M3 B Mb and we have a filename template, for simplicity, that consists of only % HOSTNAME%. What now happens is that with the first message the file "A" is opened. Obviously, messages M1 and M2 are written to file "A". Now, Ma comes in from host B. If the name is newly evaluated, Ma is written to file B. Then, M3 again to file A and Mb to file B. If we do not evaluate the filename template, we have no need to switch files. Consequently, all messages (M1, ..., Mb) are written to file "B". That, however, we could achive without dynafiles at all, for example by doing a simple *.* /A The same happens when you use time-based properties: if you do not reevaluate the file name, you will never switch files, because the name stays always at the (somewhat random) initial value. So IMO this can not be a valid use-case. What you describe in your post (initial case b)) I would call a side-effect. As the file was closed due to size limitation, as a side-effect a new name could be generated. That is of interest because the name conveys the information how long it took to reach the file size. I think a solution to this need could be to emit a log message, telling which file was closed at what time (if an output channel reaches max size). Does this make sense? Or did I misunderstand your intentions? If I got it right, would the proposed new message on max file size (output channel) solve your need? I think that should be fairly easy to add. Looking forward to your replies. Rainer From aoz.syn at gmail.com Fri Feb 6 14:15:56 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 6 Feb 2009 06:15:56 -0700 Subject: [rsyslog] sticky templates In-Reply-To: <1233918072.19733.160.camel@rf10up.intern.adiscon.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> Message-ID: <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> On Fri, Feb 6, 2009 at 04:01, Rainer Gerhards wrote: > The same happens when you use time-based properties: if you do not > reevaluate the file name, you will never switch files, because the name > stays always at the (somewhat random) initial value. > > So IMO this can not be a valid use-case. Put that way, I agree to a point. However, it (case c) can still be of limited utility for environments using 3rd-party post-processing (like logrotate or FS utilization monitors). In those cases, it would be more useful to HUP the writing process prior to beginning and work on essentially cold files rather than the 'smear' you get when working with live files. The concept could definitely be abused as you showed with the host example. > What you describe in your post > (initial case b)) I would call a side-effect. As the file was closed due > to size limitation, as a side-effect a new name could be generated. That > is of interest because the name conveys the information how long it took > to reach the file size. I think a solution to this need could be to emit > a log message, telling which file was closed at what time (if an output > channel reaches max size). I presume that one would have to create an expression-based filter to handle this, but don't directly see how to generate (and retain) a new filename from it. > Does this make sense? Or did I misunderstand your intentions? If I got > it right, would the proposed new message on max file size (output > channel) solve your need? I think that should be fairly easy to add. It does make sense, I'm just not sure how to apply it. Thanks for your thoughts! RB From rgerhards at hq.adiscon.com Fri Feb 6 13:14:12 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 13:14:12 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> Message-ID: <1233922452.19733.166.camel@rf10up.intern.adiscon.com> On Fri, 2009-02-06 at 06:15 -0700, RB wrote: > > What you describe in your post > > (initial case b)) I would call a side-effect. As the file was closed due > > to size limitation, as a side-effect a new name could be generated. That > > is of interest because the name conveys the information how long it took > > to reach the file size. I think a solution to this need could be to emit > > a log message, telling which file was closed at what time (if an output > > channel reaches max size). > > I presume that one would have to create an expression-based filter to > handle this, but don't directly see how to generate (and retain) a new > filename from it. I probably have not understood your use case. What I propose does not change the file name generation. It "just" logs a message telling you that file xxx has reached its maximum at time ttt and a new file is begun. I thought that was your point. So let me ask: why exactly would you like to have a log files like this log-2009-02-06-11-12 log-2009-02-06-17-12 I thought what you would be interested in is that the first file was created at 1112 hrs while the later was created at 1712 hrs. If I get what the point in it is, I may come up with another solution. Rainer From kenneho.ndu at gmail.com Fri Feb 6 15:00:33 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Fri, 6 Feb 2009 15:00:33 +0100 Subject: [rsyslog] Allowing both TLS and plain TCP connections Message-ID: Hi all. In my testbed I've set up rsyslog 2.0.6 with stunnel, and have one quick design question: I want the rsyslog clients to be able to send rsyslog message over both TLS and plain TCP, depending on the client setup. If I set up the rsyslog server to accept stunnel connections on port 61514 (as described in the documentation), it seems like it accepts both TLS and plain TCP. Is there any reasons why I shouldn't set up the clients to forward all traffick to this port, regardless of it being TLS or TCP (or even UDP)? I'm thinking I'd use port 200 for this (the default TCP port). Greets, Kenneth From aoz.syn at gmail.com Fri Feb 6 16:04:39 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 6 Feb 2009 08:04:39 -0700 Subject: [rsyslog] sticky templates In-Reply-To: <1233922452.19733.166.camel@rf10up.intern.adiscon.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> Message-ID: <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> On Fri, Feb 6, 2009 at 05:14, Rainer Gerhards wrote: > So let me ask: why exactly would you like to have a log files like this > > log-2009-02-06-11-12 > log-2009-02-06-17-12 > > I thought what you would be interested in is that the first file was > created at 1112 hrs while the later was created at 1712 hrs. The point wouldn't necessarily be to have timestamped filenames, but to facilitate at-will rotation, either by HUP or by size. I honestly wouldn't care if the filenames just had an incrementing identifier, like a '%$fileno%' property that incremented with each close/reopen cycle (bonus points for skipping already-existing files). Generalizing the problem to the idea of less-dynamic templates was the next step of my thought process and seemed more interesting than just adding another [potentially less reliable and portable] property. > If I get what the point in it is, I may come up with another solution. Again, I'm just brainstorming. If you think it's worthwhile to pursue now, by all means go for it; I'm just trying to find ways to make my life easier. From rgerhards at hq.adiscon.com Fri Feb 6 16:34:38 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 16:34:38 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> Message-ID: <1233934478.19733.177.camel@rf10up.intern.adiscon.com> On Fri, 2009-02-06 at 08:04 -0700, RB wrote: > On Fri, Feb 6, 2009 at 05:14, Rainer Gerhards wrote: > > So let me ask: why exactly would you like to have a log files like this > > > > log-2009-02-06-11-12 > > log-2009-02-06-17-12 > > > > I thought what you would be interested in is that the first file was > > created at 1112 hrs while the later was created at 1712 hrs. > > The point wouldn't necessarily be to have timestamped filenames, but > to facilitate at-will rotation, either by HUP or by size. I honestly > wouldn't care if the filenames just had an incrementing identifier, > like a '%$fileno%' property that incremented with each close/reopen > cycle (bonus points for skipping already-existing files). > Generalizing the problem to the idea of less-dynamic templates was the > next step of my thought process and seemed more interesting than just > adding another [potentially less reliable and portable] property. Ah, OK, I begin to understand. So what you are actually after is kind of a unique file identifier. I have updates for omfile on my mind which would go in a direction that, I think, is close. One of the things is that I would like to enable the output writer to start new files when, for example - a specific period of time has elapsed - a specific file size has been reached - a specific number of messages has been logged ... I intended to work on the size issue first and use the stream class that was originally developed for the queue. That class supports automatic file naming and numbering (that's how the queue files are generated). It can be set to circular logging (used by the queue, with a modul of 1,000,000 if I remember correctly out of my head) or monotonically increasing file numbers (up to the long long modul). Does this go into the same direction? > > > If I get what the point in it is, I may come up with another solution. > > Again, I'm just brainstorming. If you think it's worthwhile to pursue > now, by all means go for it; I'm just trying to find ways to make my > life easier. You are were welcome. The more use cases I know, the easier it is to do things in the right direction when I change something. Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From aoz.syn at gmail.com Fri Feb 6 17:04:54 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 6 Feb 2009 09:04:54 -0700 Subject: [rsyslog] sticky templates In-Reply-To: <1233934478.19733.177.camel@rf10up.intern.adiscon.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> <1233934478.19733.177.camel@rf10up.intern.adiscon.com> Message-ID: <4255c2570902060804r6aea0df1g902cb75f93803b7f@mail.gmail.com> On Fri, Feb 6, 2009 at 08:34, Rainer Gerhards wrote: > I have updates for omfile on my mind which would go in a direction that, > I think, is close. One of the things is that I would like to enable the > output writer to start new files when, for example > > - a specific period of time has elapsed > - a specific file size has been reached > - a specific number of messages has been logged > ... > > I intended to work on the size issue first and use the stream class that > was originally developed for the queue. That class supports automatic > file naming and numbering (that's how the queue files are generated). It > can be set to circular logging (used by the queue, with a modul of > 1,000,000 if I remember correctly out of my head) or monotonically > increasing file numbers (up to the long long modul). > > Does this go into the same direction? It definitely satisfies my original need, particularly if they could eventually be reset on HUP as well. If I have multiple streams logging to a dedicated partition, it would be preferable to have an outside job watching the partition's status and HUP (or similar) rsyslog when it needs to archive and make more space, as opposed to trying to configure each stream's size individually. From rgerhards at hq.adiscon.com Fri Feb 6 16:51:53 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 16:51:53 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902060804r6aea0df1g902cb75f93803b7f@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> <1233934478.19733.177.camel@rf10up.intern.adiscon.com> <4255c2570902060804r6aea0df1g902cb75f93803b7f@mail.gmail.com> Message-ID: <1233935513.19733.180.camel@rf10up.intern.adiscon.com> On Fri, 2009-02-06 at 09:04 -0700, RB wrote: > On Fri, Feb 6, 2009 at 08:34, Rainer Gerhards wrote: > > I have updates for omfile on my mind which would go in a direction that, > > I think, is close. One of the things is that I would like to enable the > > output writer to start new files when, for example > > > > - a specific period of time has elapsed > > - a specific file size has been reached > > - a specific number of messages has been logged > > ... > > > > I intended to work on the size issue first and use the stream class that > > was originally developed for the queue. That class supports automatic > > file naming and numbering (that's how the queue files are generated). It > > can be set to circular logging (used by the queue, with a modul of > > 1,000,000 if I remember correctly out of my head) or monotonically > > increasing file numbers (up to the long long modul). > > > > Does this go into the same direction? > > It definitely satisfies my original need, particularly if they could > eventually be reset on HUP as well. If I have multiple streams > logging to a dedicated partition, it would be preferable to have an > outside job watching the partition's status and HUP (or similar) > rsyslog when it needs to archive and make more space, as opposed to > trying to configure each stream's size individually. It is not something that I can do immediately, but it sound quite doable. We could also add an "close log if free space is below..." option (which means a cleanup script must be called and a new rollover disabled for n seconds...). I'd appreciate if you could add this to the bugzilla as a feature request. Again, I unfortunately can not do this immediately. Quick status: I am waiting for the race bug dust to settle and then think I will contine to work on performance, as well as straighting out some things that may have caused the HUP fault at David's site. In v4, we already have good performance enhancements, they are just only for UDP so far. This needs to be ported to the other inputs. I expect big savings. Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From friedl at hq.adiscon.com Mon Feb 9 17:53:55 2009 From: friedl at hq.adiscon.com (Florian Riedl) Date: Mon, 9 Feb 2009 17:53:55 +0100 Subject: [rsyslog] rsyslog 3.20.4 (stable) released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB89@grfint2.intern.adiscon.com> Hi all, rsyslog 3.20.4, a member of the v3-stable branch, has been released today. This is a bug-fixing release. Most importantly, it now contains the fix for the data race we have seen under some circumstances. Feedback so far indicates that this fix, in the other branches, seems to solve the issue (or at least improve the situation very much). As such, it has now also been released for v3-stable. There are also some other, minor, fixes. This is a recommended update for all users of the v3-stable branch. Changelog http://www.rsyslog.com/Article346.phtml Download http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-149.phtml As always, feedback is appreciated. Florian Riedl -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From rsyslog at clark-communications.com Tue Feb 10 02:29:00 2009 From: rsyslog at clark-communications.com (Don Jackson) Date: Mon, 9 Feb 2009 17:29:00 -0800 Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 References: Message-ID: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> The update to my OpenBSD port file for rsyslog was posted to the ports mailing list today: Begin forwarded message: > From: Don Jackson > Date: February 9, 2009 4:59:10 PM PST > To: ports at openbsd.org > Subject: UPDATE: sysutils/rsyslog-3.20.4 > > > Port updated to the latest 3.20.4 release of rsyslog. > > $ cat ./pkg/DESCR > > A syslogd replacement > > > > > > > From mbiebl at gmail.com Tue Feb 10 02:53:16 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Tue, 10 Feb 2009 02:53:16 +0100 Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 In-Reply-To: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> References: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> Message-ID: 2009/2/10 Don Jackson : > The update to my OpenBSD port file for rsyslog was posted to the ports > mailing list today: > > Begin forwarded message: > >> From: Don Jackson >> Date: February 9, 2009 4:59:10 PM PST >> To: ports at openbsd.org >> Subject: UPDATE: sysutils/rsyslog-3.20.4 >> >> >> Port updated to the latest 3.20.4 release of rsyslog. Cool. Does (Open)BSD compile and run out-of-the-box or do you need any patches? If so, please consider forwarding them upstream for review and inclusion. It would also be nice, if an (Open)BSD expert could take a look at the atomic operations configure check [1]. Apparently that one fails on FreeBSD (dunno about OpenBSD). Cheers, Michael [1] http://bugzilla.adiscon.com/show_bug.cgi?id=112 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From rgerhards at hq.adiscon.com Tue Feb 10 14:58:06 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 14:58:06 +0100 Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 In-Reply-To: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> References: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB96@grfint2.intern.adiscon.com> Congrats and thanks! Much appreciated! As Michael said, feel free to forward any patches and requests. Rainer PS: I was busy last week and am busy this week, but will become more responsive next week ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Don Jackson > Sent: Tuesday, February 10, 2009 2:29 AM > To: rsyslog-users > Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 > > The update to my OpenBSD port file for rsyslog was posted to the ports > mailing list today: > > Begin forwarded message: > > > From: Don Jackson > > Date: February 9, 2009 4:59:10 PM PST > > To: ports at openbsd.org > > Subject: UPDATE: sysutils/rsyslog-3.20.4 > > > > > > Port updated to the latest 3.20.4 release of rsyslog. > > > > $ cat ./pkg/DESCR > > > > A syslogd replacement > > > > > > > > > > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Tue Feb 10 17:20:37 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Tue, 10 Feb 2009 17:20:37 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? Message-ID: Hello list. I've currently got rsyslog to separate log files based on sending device, as desribed here: http://www.rsyslog.com/Article60.phtml I'd like to filter based on domain, and therefore need the fqdn of each sending device. Is it possible to set up rsyslog to always use fqdn, even if the sending device is on the same domain? From what I've seen in the documentation one can set up rsyslog to always use short names, but not the other way around. I'm using rsyslog v2.0.6. Regards, Kenneth From rgerhards at hq.adiscon.com Tue Feb 10 17:21:21 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 17:21:21 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> I think there is no way to do that in v2 (but I have not checked the docs). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Tuesday, February 10, 2009 5:21 PM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? > > Hello list. > > > I've currently got rsyslog to separate log files based on sending > device, as > desribed here: http://www.rsyslog.com/Article60.phtml > > I'd like to filter based on domain, and therefore need the fqdn of each > sending device. Is it possible to set up rsyslog to always use fqdn, > even if > the sending device is on the same domain? From what I've seen in the > documentation one can set up rsyslog to always use short names, but not > the > other way around. I'm using rsyslog v2.0.6. > > > Regards, > Kenneth > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Tue Feb 10 17:35:43 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Tue, 10 Feb 2009 17:35:43 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> Message-ID: Ok. I've checked the docs, but couldn't see that this was supported. I'll have another look tomorrow. Thanks for the quick response anyway. :) On 2/10/09, Rainer Gerhards wrote: > > I think there is no way to do that in v2 (but I have not checked the > docs). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Tuesday, February 10, 2009 5:21 PM > > To: rsyslog at lists.adiscon.com > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? > > > > Hello list. > > > > > > I've currently got rsyslog to separate log files based on sending > > device, as > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > I'd like to filter based on domain, and therefore need the fqdn of > each > > sending device. Is it possible to set up rsyslog to always use fqdn, > > even if > > the sending device is on the same domain? From what I've seen in the > > documentation one can set up rsyslog to always use short names, but > not > > the > > other way around. I'm using rsyslog v2.0.6. > > > > > > Regards, > > Kenneth > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Feb 10 17:36:43 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 17:36:43 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> As far as I remember, I implemented this recently, so chances are very slim it is in v2. But you may be able to build a patch based on what you find in git... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Tuesday, February 10, 2009 5:36 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > Ok. I've checked the docs, but couldn't see that this was supported. > I'll > have another look tomorrow. > > Thanks for the quick response anyway. :) > > > On 2/10/09, Rainer Gerhards wrote: > > > > I think there is no way to do that in v2 (but I have not checked the > > docs). > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > To: rsyslog at lists.adiscon.com > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > > > > > Hello list. > > > > > > > > > I've currently got rsyslog to separate log files based on sending > > > device, as > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > I'd like to filter based on domain, and therefore need the fqdn of > > each > > > sending device. Is it possible to set up rsyslog to always use > fqdn, > > > even if > > > the sending device is on the same domain? From what I've seen in > the > > > documentation one can set up rsyslog to always use short names, but > > not > > > the > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > Regards, > > > Kenneth > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Feb 10 17:39:52 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 17:39:52 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB9F@grfint2.intern.adiscon.com> This may be a good starting point: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=60b8ce14bf33e76237c f82dd1f68acc750e64316 > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Tuesday, February 10, 2009 5:37 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > As far as I remember, I implemented this recently, so chances are very > slim it is in v2. But you may be able to build a patch based on what > you > find in git... > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Tuesday, February 10, 2009 5:36 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Ok. I've checked the docs, but couldn't see that this was supported. > > I'll > > have another look tomorrow. > > > > Thanks for the quick response anyway. :) > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > I think there is no way to do that in v2 (but I have not checked > the > > > docs). > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > To: rsyslog at lists.adiscon.com > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > > > > > Hello list. > > > > > > > > > > > > I've currently got rsyslog to separate log files based on sending > > > > device, as > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > I'd like to filter based on domain, and therefore need the fqdn > of > > > each > > > > sending device. Is it possible to set up rsyslog to always use > > fqdn, > > > > even if > > > > the sending device is on the same domain? From what I've seen in > > the > > > > documentation one can set up rsyslog to always use short names, > but > > > not > > > > the > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > Regards, > > > > Kenneth > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From michaelt at adam.com.au Wed Feb 11 00:08:27 2009 From: michaelt at adam.com.au (Michael Trewartha) Date: Wed, 11 Feb 2009 09:38:27 +1030 Subject: [rsyslog] Windows Events to a rsyslog server? Message-ID: <499208EB.1030608@adam.com.au> Hello, We have a rsyslog server operating which receives all remote syslog messages from our various linux servers so we can centralise tracking of any issues we encounter. We also run some Windows servers, which we would like to configure to send events of Warning and above remotely to our rsyslog server. I've tried using the pre-built executable for Eventlog to Syslog Utility found here: https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but it appears the events aren't sending. Save installing a winsyslog server, is there any methods anyone is aware of to send Windows Events to a remote rsyslog server? From aoz.syn at gmail.com Wed Feb 11 01:59:55 2009 From: aoz.syn at gmail.com (RB) Date: Tue, 10 Feb 2009 17:59:55 -0700 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <499208EB.1030608@adam.com.au> References: <499208EB.1030608@adam.com.au> Message-ID: <4255c2570902101659q3753a679k9cac2639276d0040@mail.gmail.com> On Tue, Feb 10, 2009 at 16:08, Michael Trewartha wrote: > We also run some Windows servers, which we would like to configure to > send events of Warning and above remotely to our rsyslog server. > I've tried using the pre-built executable for Eventlog to Syslog Utility > found here: > https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but > it appears the events aren't sending. > Save installing a winsyslog server, is there any methods anyone is aware > of to send Windows Events to a remote rsyslog server? Have you, perchance, looked at the company that sponsors rsyslog's development? From DGillies at fairfaxdigital.com.au Wed Feb 11 02:05:21 2009 From: DGillies at fairfaxdigital.com.au (David Gillies) Date: Wed, 11 Feb 2009 12:05:21 +1100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <499208EB.1030608@adam.com.au> References: <499208EB.1030608@adam.com.au> Message-ID: <4310250BC419AC46BB47F728902B0DD603B27246@EXCHDP3.ffx.jfh.com.au> I guess Adiscon's Event Reporter could be an option: http://www.eventreporter.com/en/Product/ David Gillies Systems Engineer Digital Infrastructure Services Fairfax Digital -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Michael Trewartha Sent: Wednesday, 11 February 2009 10:08 AM To: rsyslog at lists.adiscon.com Subject: [rsyslog] Windows Events to a rsyslog server? Hello, We have a rsyslog server operating which receives all remote syslog messages from our various linux servers so we can centralise tracking of any issues we encounter. We also run some Windows servers, which we would like to configure to send events of Warning and above remotely to our rsyslog server. I've tried using the pre-built executable for Eventlog to Syslog Utility found here: https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but it appears the events aren't sending. Save installing a winsyslog server, is there any methods anyone is aware of to send Windows Events to a remote rsyslog server? The information contained in this e-mail message and any accompanying files is or may be confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail is subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. Fairfax does not guarantee the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore Fairfax does not accept legal responsibility for the contents of this message or attached files. From rgerhards at hq.adiscon.com Wed Feb 11 11:23:00 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 11:23:00 +0100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <499208EB.1030608@adam.com.au> References: <499208EB.1030608@adam.com.au> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> Of course, I also recommend EventReporter[1], not only because it funds rsyslog development, but also because it is the only solution that can really pull everything from every Event Log on any Windows and do this in a format that is compatible between Vista, Win2008 and older Windows releases (this is not a sales plug, I have hard technical facts for that, but I think it is not appropriate to send all of them in reply to this post). Having said this, rsyslog will of course accept messages from any process that emits syslog messages. So I would assume that there is a problem with your sender configuration. Most probably, it is not sending to the right port. Also, a firewall at the sender or the receiver (or both) may block the traffic. HTH Rainer [1] http://www.eventreporter.com > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Michael Trewartha > Sent: Wednesday, February 11, 2009 12:08 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Windows Events to a rsyslog server? > > Hello, > We have a rsyslog server operating which receives all remote syslog > messages from our various linux servers so we can centralise tracking > of > any issues we encounter. > We also run some Windows servers, which we would like to configure to > send events of Warning and above remotely to our rsyslog server. > I've tried using the pre-built executable for Eventlog to Syslog > Utility > found here: > https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but > it appears the events aren't sending. > Save installing a winsyslog server, is there any methods anyone is > aware > of to send Windows Events to a remote rsyslog server? > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 11 11:26:46 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 11 Feb 2009 11:26:46 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> Message-ID: Thanks for the tip. I'll have to discuss this with my colleagues, but since this will probably not be very popular with red hat support I suspect that we'll land on not doing this. :/ On 2/10/09, Rainer Gerhards wrote: > > As far as I remember, I implemented this recently, so chances are very > slim it is in v2. But you may be able to build a patch based on what you > find in git... > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Tuesday, February 10, 2009 5:36 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Ok. I've checked the docs, but couldn't see that this was supported. > > I'll > > have another look tomorrow. > > > > Thanks for the quick response anyway. :) > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > I think there is no way to do that in v2 (but I have not checked the > > > docs). > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > To: rsyslog at lists.adiscon.com > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > > > > > Hello list. > > > > > > > > > > > > I've currently got rsyslog to separate log files based on sending > > > > device, as > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > I'd like to filter based on domain, and therefore need the fqdn of > > > each > > > > sending device. Is it possible to set up rsyslog to always use > > fqdn, > > > > even if > > > > the sending device is on the same domain? From what I've seen in > > the > > > > documentation one can set up rsyslog to always use short names, > but > > > not > > > > the > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > Regards, > > > > Kenneth > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Wed Feb 11 11:27:54 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 11:27:54 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Side-note: if you talk to red hat, ask if they will move over to v3 any time before RHEL 6. I do not have specifics, but I would not outrule such a move. In that case, you'd have only a temporary problem (which may be easier to bear). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 11, 2009 11:27 AM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > Thanks for the tip. I'll have to discuss this with my colleagues, but > since > this will probably not be very popular with red hat support I suspect > that > we'll land on not doing this. :/ > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > As far as I remember, I implemented this recently, so chances are > very > > slim it is in v2. But you may be able to build a patch based on what > you > > find in git... > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > devices? > > > > > > Ok. I've checked the docs, but couldn't see that this was > supported. > > > I'll > > > have another look tomorrow. > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > I think there is no way to do that in v2 (but I have not checked > the > > > > docs). > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > To: rsyslog at lists.adiscon.com > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > > devices? > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > sending > > > > > device, as > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > I'd like to filter based on domain, and therefore need the fqdn > of > > > > each > > > > > sending device. Is it possible to set up rsyslog to always use > > > fqdn, > > > > > even if > > > > > the sending device is on the same domain? From what I've seen > in > > > the > > > > > documentation one can set up rsyslog to always use short names, > > but > > > > not > > > > > the > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > Regards, > > > > > Kenneth > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 11 12:51:43 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 11 Feb 2009 12:51:43 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Message-ID: I've contacted red hat to see what their rsyslog plans are. :) I'll post back when I hear something. On 2/11/09, Rainer Gerhards wrote: > > Side-note: if you talk to red hat, ask if they will move over to v3 any > time before RHEL 6. I do not have specifics, but I would not outrule > such a move. In that case, you'd have only a temporary problem (which > may be easier to bear). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 11, 2009 11:27 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Thanks for the tip. I'll have to discuss this with my colleagues, but > > since > > this will probably not be very popular with red hat support I suspect > > that > > we'll land on not doing this. :/ > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > As far as I remember, I implemented this recently, so chances are > > very > > > slim it is in v2. But you may be able to build a patch based on what > > you > > > find in git... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > Ok. I've checked the docs, but couldn't see that this was > > supported. > > > > I'll > > > > have another look tomorrow. > > > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > > > I think there is no way to do that in v2 (but I have not checked > > the > > > > > docs). > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > > sending > > > > > > device, as > > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > > > I'd like to filter based on domain, and therefore need the > fqdn > > of > > > > > each > > > > > > sending device. Is it possible to set up rsyslog to always use > > > > fqdn, > > > > > > even if > > > > > > the sending device is on the same domain? From what I've seen > > in > > > > the > > > > > > documentation one can set up rsyslog to always use short > names, > > > but > > > > > not > > > > > > the > > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Kenneth > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From r.bhatia at ipax.at Wed Feb 11 13:55:38 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Wed, 11 Feb 2009 13:55:38 +0100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> References: <499208EB.1030608@adam.com.au> <577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> Message-ID: <4992CACA.2060403@ipax.at> hello rainer, Rainer Gerhards wrote: > Of course, I also recommend EventReporter[1], not only because it funds > rsyslog development, but also because it is the only solution that can > really pull everything from every Event Log on any Windows and do this > in a format that is compatible between Vista, Win2008 and older Windows > releases (this is not a sales plug, I have hard technical facts for > that, but I think it is not appropriate to send all of them in reply to > this post). i wanted to get a quick overview of the eventrepoert prices but failed until i started the "order" process. there i found a kind of confusing interface using abbreviations (i interpreted UI as "User Interface", not "Upgrade Insurance") and a javascript calculator. so: the price for the product is 65 euro for one licence, right? moreover, i am not sure if the purchased version will still work after one year or if the yearly maintenance-plan is obligatory. but visiting your shop for the second time, i think it will continue to work, right? cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From rgerhards at hq.adiscon.com Wed Feb 11 14:04:35 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 14:04:35 +0100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <4992CACA.2060403@ipax.at> References: <499208EB.1030608@adam.com.au><577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> <4992CACA.2060403@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBBB@grfint2.intern.adiscon.com> I am replying to this on-list, further questions will go via private mail (because I guess this is getting off-topic for the rsyslog list ;)) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Wednesday, February 11, 2009 1:56 PM > To: rsyslog-users > Subject: Re: [rsyslog] Windows Events to a rsyslog server? > > hello rainer, > > Rainer Gerhards wrote: > > Of course, I also recommend EventReporter[1], not only because it > funds > > rsyslog development, but also because it is the only solution that > can > > really pull everything from every Event Log on any Windows and do > this > > in a format that is compatible between Vista, Win2008 and older > Windows > > releases (this is not a sales plug, I have hard technical facts for > > that, but I think it is not appropriate to send all of them in reply > to > > this post). > > i wanted to get a quick overview of the eventrepoert prices but failed > until i started the "order" process. > > there i found a kind of confusing interface using abbreviations (i > interpreted UI as "User Interface", not "Upgrade Insurance") and a > javascript calculator. > Will forward that feedback and see what I can do ;) - thanks! > so: the price for the product is 65 euro for one licence, right? In a nutshell - yes, with volume discounts available > moreover, i am not sure if the purchased version will still work after > one year or if the yearly maintenance-plan is obligatory. but visiting > your shop for the second time, i think it will continue to work, right? Yes - licenses are perpetual. The maintenance plan is purely optional. Rainer From kenneho.ndu at gmail.com Wed Feb 11 14:51:14 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 11 Feb 2009 14:51:14 +0100 Subject: [rsyslog] Using property-based filters to separate log files Message-ID: Hello all. I've read the documentation on property-based filters ( http://www.rsyslog.com/doc-rsyslog_conf_filter.html), and are trying to use this feature combined with file name templating ( http://www.rsyslog.com/Article60.phtml). What I'd like to do is to apply templates to groups of hosts based on their hostname. For example, I'd like to apply template "t1" to hosts such as "test01" and "test02", and template "t2" to hosts "prod01" and "prod02". In other words, different templates should be used based on parts of the file name. To accomplish this I tried this approach: *$template DynaFileTest,"/var/log/syslog/test/system-%HOSTNAME%.log" $template DynaFileProd,"/var/log/syslog/prod/system-%HOSTNAME%.log" * *:HOSTNAME, contains, "test" *.* -?DynaFileTest * *:HOSTNAME, contains, "prod" *.* -?DynaFileProd * This didn't work, so I must have got it wrong. Can anyone point out what I'm doing wrong? Or maybe there are better ways of doing this? Greets, Kenneth From Luis.Fernando.Munoz.Mejias at cern.ch Wed Feb 11 14:59:19 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Wed, 11 Feb 2009 14:59:19 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? Message-ID: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Hello, world! I'm trying to store my logs centrally on an Oracle database. I need it to be Oracle. Due to some restrictions around there, I can't use the recommended version of libdbi, but an older one that is not working with rsyslog. I can't rebuild that RPM, and I have no influence on the upgrade process or schedule. Finally, I also need something with *excellent* performance, and the documentation states omlibdbi doesn't perform as well as other DB-related modules, so I decided to try my own small set of input and output modules. So, my question is: is there any documentation or guide for writing modules, something that gives some insight of what all those macros (BEGINcreateInstance, CODESTARTcreateInstance, etc, etc, etc) I see mean? Do I need to grep the code for that? I've googled for it and reviewed the Git repository, but found nothing. Thanks in advance. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From rgerhards at hq.adiscon.com Wed Feb 11 15:08:14 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 15:08:14 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: <1234361294.19733.230.camel@rf10up.intern.adiscon.com> Hi Luis Fernando, glad you asked :) The documentation is ... well... not much ;) The best thing is probably to start with the existing MySQL module. HOWEVER, I myself would be very interested in a native, high-performing Oracle driver. I neither have the expertise to do it not the test environment. If you like, we could collaborate on this effort. I'd create a skeleton output module for you, guide you through using it and you provide the Oracle bits to it (that should be fairly easy). Of course, that means your module would need to be contributed back to the project. What do you think about this? Rainer On Wed, 2009-02-11 at 14:59 +0100, Luis Fernando Mu?oz Mej?as wrote: > Hello, world! > > I'm trying to store my logs centrally on an Oracle database. I need it > to be Oracle. > > Due to some restrictions around there, I can't use the recommended > version of libdbi, but an older one that is not working with rsyslog. I > can't rebuild that RPM, and I have no influence on the upgrade process > or schedule. > > Finally, I also need something with *excellent* performance, and the > documentation states omlibdbi doesn't perform as well as other > DB-related modules, so I decided to try my own small set of input and > output modules. > > So, my question is: is there any documentation or guide for writing > modules, something that gives some insight of what all those macros > (BEGINcreateInstance, CODESTARTcreateInstance, etc, etc, etc) I see > mean? Do I need to grep the code for that? > > I've googled for it and reviewed the Git repository, but found nothing. > > Thanks in advance. From david at lang.hm Wed Feb 11 16:31:29 2009 From: david at lang.hm (david at lang.hm) Date: Wed, 11 Feb 2009 07:31:29 -0800 (PST) Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: On Wed, 11 Feb 2009, Luis Fernando Mu?oz Mej?as wrote: > Finally, I also need something with *excellent* performance, and the > documentation states omlibdbi doesn't perform as well as other > DB-related modules, so I decided to try my own small set of input and > output modules. one major limitation you will run into is that rsyslog proceses log entries one at a time. this means that each log entry inserted into the oracle database will be a seperate transaction. changing this is a fairly major task that will require someone to sponser it (I've asked about this in the past, but my company has not needed the performance enough to do this yet) David Lang From jules at visionintel.com Wed Feb 11 19:49:31 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Wed, 11 Feb 2009 18:49:31 +0000 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <4310250BC419AC46BB47F728902B0DD603B27246@EXCHDP3.ffx.jfh.com.au> References: <499208EB.1030608@adam.com.au> <4310250BC419AC46BB47F728902B0DD603B27246@EXCHDP3.ffx.jfh.com.au> Message-ID: <69544300902111049p1b213e88m6fb7b05670347032@mail.gmail.com> you can send remote message to syslog by changing the rsyslog.conf # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional *.* @@192.168.15.103:514 # ### end of the forwarding rule ### You need to specify the IP and port where you are sending your logs. basically, you send it locally and syslog will forward them for you. Jules 2009/2/11 David Gillies > I guess Adiscon's Event Reporter could be an option: > > http://www.eventreporter.com/en/Product/ > > David Gillies > Systems Engineer > Digital Infrastructure Services > Fairfax Digital > > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Michael > Trewartha > Sent: Wednesday, 11 February 2009 10:08 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Windows Events to a rsyslog server? > > Hello, > We have a rsyslog server operating which receives all remote syslog > messages from our various linux servers so we can centralise tracking of > any issues we encounter. > We also run some Windows servers, which we would like to configure to > send events of Warning and above remotely to our rsyslog server. > I've tried using the pre-built executable for Eventlog to Syslog Utility > found here: > https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but > it appears the events aren't sending. > Save installing a winsyslog server, is there any methods anyone is aware > of to send Windows Events to a remote rsyslog server? > > The information contained in this e-mail message and any accompanying files > is or may be confidential. If you are not the intended recipient, any use, > dissemination, reliance, forwarding, printing or copying of this e-mail or > any attached files is unauthorised. This e-mail is subject to copyright. No > part of it should be reproduced, adapted or communicated without the written > consent of the copyright owner. If you have received this e-mail in error > please advise the sender immediately by return e-mail or telephone and > delete all copies. Fairfax does not guarantee the accuracy or completeness > of any information contained in this e-mail or attached files. Internet > communications are not secure, therefore Fairfax does not accept legal > responsibility for the contents of this message or attached files. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Wed Feb 11 19:53:08 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Wed, 11 Feb 2009 18:53:08 +0000 Subject: [rsyslog] rsyslog.conf Message-ID: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> Giving that one can change the IP in the rsconfig.conf to send a log remotely, would they be an easy way, or what would be the best approach to change the config file programatically so that IP can be update whenever wanted. thanks, From aoz.syn at gmail.com Wed Feb 11 20:22:32 2009 From: aoz.syn at gmail.com (RB) Date: Wed, 11 Feb 2009 12:22:32 -0700 Subject: [rsyslog] rsyslog.conf In-Reply-To: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> Message-ID: <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso wrote: > Giving that one can change the IP in the rsconfig.conf to send a log > remotely, would they be an easy way, or what would be the best approach to > change the config file programatically so that IP can be update whenever > wanted. Use DNS. There are nearly infinite of ways to programmatically replace FOO with BAR in a text file, but changing the file requires a HUP or restart for an already-running instance of rsyslog, which is inelegant. If you're trying to point to multiple hosts, either float a virtual IP among them or point at a DNS record you can move among hosts. From rgerhards at hq.adiscon.com Wed Feb 11 20:39:23 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 20:39:23 +0100 Subject: [rsyslog] rsyslog.conf Message-ID: <001201c98c80$6b86f89a$060013ac@intern.adiscon.com> >From the phone: You need to be careful - dns changes will most probably not affect the running instance immediately. So IMHO the virtual IP is the best solution. rainer ----- Urspr?ngliche Nachricht ----- Von: "RB" An: "rsyslog-users" Gesendet: 11.02.09 20:21 Betreff: Re: [rsyslog] rsyslog.conf On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso wrote: > Giving that one can change the IP in the rsconfig.conf to send a log > remotely, would they be an easy way, or what would be the best approach to > change the config file programatically so that IP can be update whenever > wanted. Use DNS. There are nearly infinite of ways to programmatically replace FOO with BAR in a text file, but changing the file requires a HUP or restart for an already-running instance of rsyslog, which is inelegant. If you're trying to point to multiple hosts, either float a virtual IP among them or point at a DNS record you can move among hosts. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From jmoyer at redhat.com Wed Feb 11 21:53:59 2009 From: jmoyer at redhat.com (Jeff Moyer) Date: Wed, 11 Feb 2009 15:53:59 -0500 Subject: [rsyslog] [RFC] add an option to buffer masked syslog messages Message-ID: Hi, folks, I posed this question on the libc-alpha mailing list [1]: I was about to start writing support for bufferring debug messages in autofs, when it occurred to me that this is a fairly useful thing to do, and it makes little sense for every application to reinvent the wheel. What I'd like is to have a fixed size ring buffer to which messages that are masked are logged. Then, if the application asks for these messages, dump them to the log. The reason, if it isn't obvious, is so that we can dump application state should a problem present itself when debug logging is disabled. What do folks think about this? Is it better accomplished elsewhere? The response I got was that (at least Roland thinks) this should be done in the syslog daemon, not in the library. So, I'll pose the same question here, and I look forward to hearing your thoughts. Cheers, Jeff [1] http://sourceware.org/ml/libc-alpha/2009-02/msg00036.html From jules at visionintel.com Wed Feb 11 22:14:41 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Wed, 11 Feb 2009 21:14:41 +0000 Subject: [rsyslog] rsyslog.conf In-Reply-To: <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> Message-ID: <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> well, I am not trying to point to multiple addresses at the same time, but i am in an environment where the IP could change every 10min or 15 min. 2009/2/11 RB > On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso > wrote: > > Giving that one can change the IP in the rsconfig.conf to send a log > > remotely, would they be an easy way, or what would be the best approach > to > > change the config file programatically so that IP can be update whenever > > wanted. > > Use DNS. There are nearly infinite of ways to programmatically > replace FOO with BAR in a text file, but changing the file requires a > HUP or restart for an already-running instance of rsyslog, which is > inelegant. If you're trying to point to multiple hosts, either float > a virtual IP among them or point at a DNS record you can move among > hosts. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Wed Feb 11 22:22:47 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 22:22:47 +0100 Subject: [rsyslog] rsyslog.conf In-Reply-To: <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com><4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBC7@grfint2.intern.adiscon.com> On this time window, I think you can not get around issuing a restart-type HUP. As this needs to be synchronised in any case, you'll probably need a script, so you could also write a file that contains the new IP in question. I suggest one extra file that then is included via $IncludeConfig from the main rsyslog.conf. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Jules > Pagna Disso > Sent: Wednesday, February 11, 2009 10:15 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog.conf > > well, > > I am not trying to point to multiple addresses at the same > time, but i am in > an environment where the IP could change every 10min or 15 min. > > 2009/2/11 RB > > > On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso > > > wrote: > > > Giving that one can change the IP in the rsconfig.conf to > send a log > > > remotely, would they be an easy way, or what would be the > best approach > > to > > > change the config file programatically so that IP can be > update whenever > > > wanted. > > > > Use DNS. There are nearly infinite of ways to programmatically > > replace FOO with BAR in a text file, but changing the file > requires a > > HUP or restart for an already-running instance of rsyslog, which is > > inelegant. If you're trying to point to multiple hosts, > either float > > a virtual IP among them or point at a DNS record you can move among > > hosts. > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Thu Feb 12 01:28:08 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Thu, 12 Feb 2009 00:28:08 +0000 Subject: [rsyslog] rsyslog.conf In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBC7@grfint2.intern.adiscon.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FBC7@grfint2.intern.adiscon.com> Message-ID: <69544300902111628y262c769et5d8c6b712714fb42@mail.gmail.com> i came accross this syslogd that supports remote loggin. any one used it before? i was trying to install in on my Fedora 10 but i got the conflictual message with syslog-ng. it seems as if it's either or. http://linux.about.com/od/commands/l/blcmdl8_syslogd.htm hope this help for remote logging but again, remember to set the remote host so that he can accept remote messages. http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch05_:_Troubleshooting_Linux_with_syslog thanks 2009/2/11 Rainer Gerhards > On this time window, I think you can not get around issuing a > restart-type HUP. As this needs to be synchronised in any case, you'll > probably need a script, so you could also write a file that contains the > new IP in question. I suggest one extra file that then is included via > $IncludeConfig from the main rsyslog.conf. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com > > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Jules > > Pagna Disso > > Sent: Wednesday, February 11, 2009 10:15 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] rsyslog.conf > > > > well, > > > > I am not trying to point to multiple addresses at the same > > time, but i am in > > an environment where the IP could change every 10min or 15 min. > > > > 2009/2/11 RB > > > > > On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso > > > > > wrote: > > > > Giving that one can change the IP in the rsconfig.conf to > > send a log > > > > remotely, would they be an easy way, or what would be the > > best approach > > > to > > > > change the config file programatically so that IP can be > > update whenever > > > > wanted. > > > > > > Use DNS. There are nearly infinite of ways to programmatically > > > replace FOO with BAR in a text file, but changing the file > > requires a > > > HUP or restart for an already-running instance of rsyslog, which is > > > inelegant. If you're trying to point to multiple hosts, > > either float > > > a virtual IP among them or point at a DNS record you can move among > > > hosts. > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Fri Feb 13 05:42:14 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Thu, 12 Feb 2009 23:42:14 -0500 Subject: [rsyslog] need some thoughts here Message-ID: <69544300902122042w708bbbb7l369e638af24378a2@mail.gmail.com> I am still trying to find an efficient solution for loggin to a remote location. sysklogd is supposed to do the trick however it is incompatible with rsyslog. when i tried to remove rsyslog, there was a total of 525 packages there was going to be remove, so i decided not to. Any body tried sysklogd? thanks From rgerhards at hq.adiscon.com Fri Feb 13 06:39:18 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 13 Feb 2009 06:39:18 +0100 Subject: [rsyslog] need some thoughts here Message-ID: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> Hi, I do not understand your issue ;) rsyslog is a superset of sysklogd. So you can simply use *.* @remote-host As in sysklogd. rainer ----- Urspr?ngliche Nachricht ----- Von: "Jules Pagna Disso" An: "rsyslog-users" Gesendet: 13.02.09 05:41 Betreff: [rsyslog] need some thoughts here I am still trying to find an efficient solution for loggin to a remote location. sysklogd is supposed to do the trick however it is incompatible with rsyslog. when i tried to remove rsyslog, there was a total of 525 packages there was going to be remove, so i decided not to. Any body tried sysklogd? thanks _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From aoz.syn at gmail.com Fri Feb 13 17:21:16 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 13 Feb 2009 09:21:16 -0700 Subject: [rsyslog] need some thoughts here In-Reply-To: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> Message-ID: <4255c2570902130821k3f1cd9e3wcc2107cee23c4f9f@mail.gmail.com> On Thu, Feb 12, 2009 at 22:39, Rainer Gerhards wrote: > I do not understand your issue ;) rsyslog is a superset of sysklogd. So you can simply use Ditto. There are only a couple of log daemons I can think of that _don't_ log remotely, and they're embedded-only. Again: nearly every log daemon you are going to find will log remotely. Can you explain more of the problem you are trying to solve? Changing IPs every few minutes and getting the impression that a remote log daemon is hard to find indicates more of a misunderstanding of the problem than an actual technological issue to me. From jules at visionintel.com Fri Feb 13 22:06:55 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Fri, 13 Feb 2009 21:06:55 +0000 Subject: [rsyslog] need some thoughts here In-Reply-To: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> Message-ID: <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> basically, in fedora, when i try installing sysklogd i have a message that says conflict with syslogd and syslog-ng therefore i cannot install sysklogd 2009/2/13 Rainer Gerhards > Hi, > > I do not understand your issue ;) rsyslog is a superset of sysklogd. So you > can simply use > > *.* @remote-host > > As in sysklogd. > > rainer > > ----- Urspr?ngliche Nachricht ----- > Von: "Jules Pagna Disso" > An: "rsyslog-users" > Gesendet: 13.02.09 05:41 > Betreff: [rsyslog] need some thoughts here > > I am still trying to find an efficient solution for loggin to a remote > location. sysklogd is supposed to do the trick however it is incompatible > with rsyslog. when i tried to remove rsyslog, there was a total of 525 > packages there was going to be remove, so i decided not to. > > Any body tried sysklogd? > > thanks > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From hks.private at gmail.com Fri Feb 13 22:28:45 2009 From: hks.private at gmail.com ((private) HKS) Date: Fri, 13 Feb 2009 16:28:45 -0500 Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> Message-ID: On Fri, Feb 13, 2009 at 4:06 PM, Jules Pagna Disso wrote: > basically, in fedora, when i try installing sysklogd i have a message that > says conflict with syslogd and syslog-ng therefore i cannot install sysklogd > ... Is there a problem you're trying to solve with rsyslog? -HKS From jules at visionintel.com Fri Feb 13 22:36:54 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Fri, 13 Feb 2009 21:36:54 +0000 Subject: [rsyslog] need some thoughts here In-Reply-To: References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> Message-ID: <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> yes, basically i need to write some code to send alert to a remote host something like send(message_options , list of host, port) i can do it but i have to edit rsyslog.conf by programming, yet if i use sysklogd i can just call some routine and do the job, but i failled to install sysklogd. sysklogd has all the option i need i.e -h for host for instance but i can't installed it on fedora 10. i tried on 3 computers no success. 2009/2/13 (private) HKS > On Fri, Feb 13, 2009 at 4:06 PM, Jules Pagna Disso > wrote: > > basically, in fedora, when i try installing sysklogd i have a message > that > > says conflict with syslogd and syslog-ng therefore i cannot install > sysklogd > > > > > ... > > Is there a problem you're trying to solve with rsyslog? > > -HKS > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Sat Feb 14 06:16:32 2009 From: david at lang.hm (david at lang.hm) Date: Fri, 13 Feb 2009 21:16:32 -0800 (PST) Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> Message-ID: On Fri, 13 Feb 2009, Jules Pagna Disso wrote: > yes, basically i need to write some code to send alert to a remote host > something like send(message_options , list of host, port) > > i can do it but i have to edit rsyslog.conf by programming, yet if i use > sysklogd i can just call some routine and do the job, but i failled to > install sysklogd. sysklogd has all the option i need i.e -h for host for > instance but i can't installed it on fedora 10. i tried on 3 computers no > success. umm, for the versions of sysklog that I've used -h was a flag to tell it to go ahead and forward messages. it didn't specify what host they would go to. basicly any version of syslog will let you do that. by the way, I think that the syslogd that RedHat ships is a variation of sysklogd. if you really do want to install sysklogd you need to talk to people who are gurus with rpm packaging options to help you through the dependancy conflicts, but the rsyslog list is not really the right place to search for the info. David Lang > > 2009/2/13 (private) HKS > >> On Fri, Feb 13, 2009 at 4:06 PM, Jules Pagna Disso >> wrote: >>> basically, in fedora, when i try installing sysklogd i have a message >> that >>> says conflict with syslogd and syslog-ng therefore i cannot install >> sysklogd >>> >> >> >> ... >> >> Is there a problem you're trying to solve with rsyslog? >> >> -HKS >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From martinmie at PartyGaming.com Sat Feb 14 14:53:07 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Sat, 14 Feb 2009 14:53:07 +0100 Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled Message-ID: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> Hi, I'm starting to configure some RHEL5 systems with rsyslog-3.19.7-4. One is the logserver and the rest will slowly become the clients... Only one client with TLS support has been configured so far and I had to stop because it wasn't possible to ssh into the machine once rsyslog was up and running after some hours... IIRC, this happened in the past too when activating the TLS support but never got a fix for this issue... Any ideas? TIA, Martin This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From aoz.syn at gmail.com Sat Feb 14 17:25:18 2009 From: aoz.syn at gmail.com (RB) Date: Sat, 14 Feb 2009 09:25:18 -0700 Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> Message-ID: <4255c2570902140825n767831efpa6c77f459daeee3@mail.gmail.com> On Fri, Feb 13, 2009 at 14:06, Jules Pagna Disso wrote: > basically, in fedora, when i try installing sysklogd i have a message that > says conflict with syslogd and syslog-ng therefore i cannot install sysklogd All three log daemons you're talking about (rsyslog, syslogd, syslog-ng) will happily emit messages of your choice to the remote server of your choice. If you're having trouble at this level, I doubt you're familiar with the differences among the three and should probably stick with whatever's installed by default on your distro. From aoz.syn at gmail.com Sat Feb 14 17:32:09 2009 From: aoz.syn at gmail.com (RB) Date: Sat, 14 Feb 2009 09:32:09 -0700 Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> Message-ID: <4255c2570902140832s5e0f0011ndbc1400b5a4d7537@mail.gmail.com> On Fri, Feb 13, 2009 at 14:36, Jules Pagna Disso wrote: > yes, basically i need to write some code to send alert to a remote host > something like send(message_options , list of host, port) > > i can do it but i have to edit rsyslog.conf by programming, yet if i use > sysklogd i can just call some routine and do the job, but i failled to > install sysklogd. sysklogd has all the option i need i.e -h for host for > instance but i can't installed it on fedora 10. i tried on 3 computers no > success. It would be far more helpful if you gave us more precisely what you are trying to do. From what I gather, you seem to be writing a program that you want to send log messages directly to a remote host. For that use, you don't need any of the syslog daemons - just use 'logger' or any of the dozens of C/C++/Perl/Python logging packages available. There are much better ways to solve this, but at this point I am not sure they'll be any easier for you. From aoz.syn at gmail.com Sat Feb 14 17:38:07 2009 From: aoz.syn at gmail.com (RB) Date: Sat, 14 Feb 2009 09:38:07 -0700 Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> Message-ID: <4255c2570902140838o7778459ew33707fbb581be34@mail.gmail.com> On Sat, Feb 14, 2009 at 06:53, Martin Mielke wrote: > I'm starting to configure some RHEL5 systems with rsyslog-3.19.7-4. One > is the logserver and the rest will slowly become the clients... > > Only one client with TLS support has been configured so far and I had to > stop because it wasn't possible to ssh into the machine once rsyslog was > up and running after some hours... There is nothing inherent to rsyslog (with or without TLS) that will interfere with SSH. Your system may be bogging down or crashing, but you need to find out more exactly what's happening - logs, console messages, resource consumption, etc. From rgerhards at hq.adiscon.com Mon Feb 16 09:27:16 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 09:27:16 +0100 Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBFA@grfint2.intern.adiscon.com> Hi Martin, besides the other (good!) comments, I would strongly suggest to upgrade to the most recent stable first. Most importantly, the last release has fixed a race condition that could explain what you are seeing. It is not tied to TLS, but there is no indication why it could not be the cause. Any troubleshooting on an older version is probably not worth the effort. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Saturday, February 14, 2009 2:53 PM > To: rsyslog-users > Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled > > Hi, > > I'm starting to configure some RHEL5 systems with rsyslog-3.19.7-4. One > is the logserver and the rest will slowly become the clients... > > Only one client with TLS support has been configured so far and I had > to > stop because it wasn't possible to ssh into the machine once rsyslog > was > up and running after some hours... > > IIRC, this happened in the past too when activating the TLS support but > never got a fix for this issue... > > Any ideas? > > > TIA, > > Martin > > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Mon Feb 16 10:17:33 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Mon, 16 Feb 2009 10:17:33 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Message-ID: I talked to Red Hat, and it seems like they will not be upgrading rsyslog to v3 before RHEL 6. :/ On 2/11/09, Rainer Gerhards wrote: > > Side-note: if you talk to red hat, ask if they will move over to v3 any > time before RHEL 6. I do not have specifics, but I would not outrule > such a move. In that case, you'd have only a temporary problem (which > may be easier to bear). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 11, 2009 11:27 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Thanks for the tip. I'll have to discuss this with my colleagues, but > > since > > this will probably not be very popular with red hat support I suspect > > that > > we'll land on not doing this. :/ > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > As far as I remember, I implemented this recently, so chances are > > very > > > slim it is in v2. But you may be able to build a patch based on what > > you > > > find in git... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > Ok. I've checked the docs, but couldn't see that this was > > supported. > > > > I'll > > > > have another look tomorrow. > > > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > > > I think there is no way to do that in v2 (but I have not checked > > the > > > > > docs). > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > > sending > > > > > > device, as > > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > > > I'd like to filter based on domain, and therefore need the > fqdn > > of > > > > > each > > > > > > sending device. Is it possible to set up rsyslog to always use > > > > fqdn, > > > > > > even if > > > > > > the sending device is on the same domain? From what I've seen > > in > > > > the > > > > > > documentation one can set up rsyslog to always use short > names, > > > but > > > > > not > > > > > > the > > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Kenneth > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Mon Feb 16 10:18:55 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 10:18:55 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> I do not know whom to approach, but maybe we can get someone else into the boat who can build an publish non RH RPMs that work on RHEL... Anyone with a suggestion on whom to approach? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Monday, February 16, 2009 10:18 AM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > I talked to Red Hat, and it seems like they will not be upgrading > rsyslog to > v3 before RHEL 6. :/ > > On 2/11/09, Rainer Gerhards wrote: > > > > Side-note: if you talk to red hat, ask if they will move over to v3 > any > > time before RHEL 6. I do not have specifics, but I would not outrule > > such a move. In that case, you'd have only a temporary problem (which > > may be easier to bear). > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 11, 2009 11:27 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > devices? > > > > > > Thanks for the tip. I'll have to discuss this with my colleagues, > but > > > since > > > this will probably not be very popular with red hat support I > suspect > > > that > > > we'll land on not doing this. :/ > > > > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > As far as I remember, I implemented this recently, so chances are > > > very > > > > slim it is in v2. But you may be able to build a patch based on > what > > > you > > > > find in git... > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of > sending > > > > > devices? > > > > > > > > > > Ok. I've checked the docs, but couldn't see that this was > > > supported. > > > > > I'll > > > > > have another look tomorrow. > > > > > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > > > > > I think there is no way to do that in v2 (but I have not > checked > > > the > > > > > > docs). > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of > sending > > > > > devices? > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > > > sending > > > > > > > device, as > > > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > > > > > I'd like to filter based on domain, and therefore need the > > fqdn > > > of > > > > > > each > > > > > > > sending device. Is it possible to set up rsyslog to always > use > > > > > fqdn, > > > > > > > even if > > > > > > > the sending device is on the same domain? From what I've > seen > > > in > > > > > the > > > > > > > documentation one can set up rsyslog to always use short > > names, > > > > but > > > > > > not > > > > > > > the > > > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Kenneth > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at ecker-software.de Mon Feb 16 10:25:57 2009 From: david at ecker-software.de (David Ecker) Date: Mon, 16 Feb 2009 10:25:57 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> Message-ID: <49993125.2060603@ecker-software.de> Hi, have you tried to contact the epel group? http://fedoraproject.org/wiki/EPEL They should be able to include an upgrade for rsyslog into their repository for REL5 if you ask them. Bye David Rainer Gerhards schrieb: > I do not know whom to approach, but maybe we can get someone else into > the boat who can build an publish non RH RPMs that work on RHEL... > Anyone with a suggestion on whom to approach? > > Rainer > > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >> Sent: Monday, February 16, 2009 10:18 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending >> devices? >> >> I talked to Red Hat, and it seems like they will not be upgrading >> rsyslog to >> v3 before RHEL 6. :/ >> >> On 2/11/09, Rainer Gerhards wrote: >> >>> Side-note: if you talk to red hat, ask if they will move over to v3 >>> >> any >> >>> time before RHEL 6. I do not have specifics, but I would not outrule >>> such a move. In that case, you'd have only a temporary problem >>> > (which > >>> may be easier to bear). >>> >>> Rainer >>> >>> >>>> -----Original Message----- >>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >>>> Sent: Wednesday, February 11, 2009 11:27 AM >>>> To: rsyslog-users >>>> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending >>>> devices? >>>> >>>> Thanks for the tip. I'll have to discuss this with my colleagues, >>>> >> but >> >>>> since >>>> this will probably not be very popular with red hat support I >>>> >> suspect >> >>>> that >>>> we'll land on not doing this. :/ >>>> >>>> >>>> >>>> >>>> On 2/10/09, Rainer Gerhards wrote: >>>> >>>>> As far as I remember, I implemented this recently, so chances >>>>> > are > >>>> very >>>> >>>>> slim it is in v2. But you may be able to build a patch based on >>>>> >> what >> >>>> you >>>> >>>>> find in git... >>>>> >>>>> Rainer >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>>>> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >>>>>> Sent: Tuesday, February 10, 2009 5:36 PM >>>>>> To: rsyslog-users >>>>>> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of >>>>>> >> sending >> >>>>>> devices? >>>>>> >>>>>> Ok. I've checked the docs, but couldn't see that this was >>>>>> >>>> supported. >>>> >>>>>> I'll >>>>>> have another look tomorrow. >>>>>> >>>>>> Thanks for the quick response anyway. :) >>>>>> >>>>>> >>>>>> On 2/10/09, Rainer Gerhards wrote: >>>>>> >>>>>>> I think there is no way to do that in v2 (but I have not >>>>>>> >> checked >> >>>> the >>>> >>>>>>> docs). >>>>>>> >>>>>>> Rainer >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>>>>>> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >>>>>>>> Sent: Tuesday, February 10, 2009 5:21 PM >>>>>>>> To: rsyslog at lists.adiscon.com >>>>>>>> Subject: [rsyslog] Get rsyslog to always use fqdn of >>>>>>>> >> sending >> >>>>>> devices? >>>>>> >>>>>>>> Hello list. >>>>>>>> >>>>>>>> >>>>>>>> I've currently got rsyslog to separate log files based on >>>>>>>> >>>> sending >>>> >>>>>>>> device, as >>>>>>>> desribed here: http://www.rsyslog.com/Article60.phtml >>>>>>>> >>>>>>>> I'd like to filter based on domain, and therefore need the >>>>>>>> >>> fqdn >>> >>>> of >>>> >>>>>>> each >>>>>>> >>>>>>>> sending device. Is it possible to set up rsyslog to always >>>>>>>> >> use >> >>>>>> fqdn, >>>>>> >>>>>>>> even if >>>>>>>> the sending device is on the same domain? From what I've >>>>>>>> >> seen >> >>>> in >>>> >>>>>> the >>>>>> >>>>>>>> documentation one can set up rsyslog to always use short >>>>>>>> >>> names, >>> >>>>> but >>>>> >>>>>>> not >>>>>>> >>>>>>>> the >>>>>>>> other way around. I'm using rsyslog v2.0.6. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Kenneth >>>>>>>> _______________________________________________ >>>>>>>> rsyslog mailing list >>>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>> http://www.rsyslog.com >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> rsyslog mailing list >>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>> http://www.rsyslog.com >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> rsyslog mailing list >>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>> http://www.rsyslog.com >>>>>> >>>>> _______________________________________________ >>>>> rsyslog mailing list >>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>> http://www.rsyslog.com >>>>> >>>>> >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com >>>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From Luis.Fernando.Munoz.Mejias at cern.ch Mon Feb 16 11:41:21 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Mon, 16 Feb 2009 11:41:21 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> Rainer, My apologies for the late reply. I was subscribed to the digest format and didn't receive your replies. > glad you asked :) The documentation is ... well... not much ;) Oops! > The best thing is probably to start with the existing MySQL > module. HOWEVER, I myself would be very interested in a native, > high-performing Oracle driver. I neither have the expertise to do it > not the test environment. I don't have the expertise either, but do have the test environment... we can try. ;) > If you like, we could collaborate on this effort. I'd create a > skeleton output module for you, guide you through using it and you > provide the Oracle bits to it (that should be fairly easy). Of course, > that means your module would need to be contributed back to the > project. That sounds really great. Before you start coding or preparing anything, let me check how well our DBs perform, because it's not yet clear if they'll be able to cope with the high insertion rate we expect. If we don't go for the Oracle database this work doesn't make sense. I bet we'll want the Oracle, anyways. For this evaluation, I already have a timestamp formatter that fits into Oracle, something that can be used with the property replacer, like %timereported:::date-oracle%. It still needs some real-world testing, but provided it works, is it interesting for the project? If so, should I submit the patch via bugzilla? Is there any paperwork (copyright assingmnents a la FSF or whatever) that should be fullfilled? Thanks. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From rgerhards at hq.adiscon.com Mon Feb 16 17:35:25 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 17:35:25 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC08@grfint2.intern.adiscon.com> Sorry, this time my reply is sluggish ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Luis Fernando Mu?oz Mej?as > Sent: Monday, February 16, 2009 11:41 AM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] Documentation on writing rsyslog modules? > > Rainer, > > My apologies for the late reply. I was subscribed to the digest format > and didn't receive your replies. > > > glad you asked :) The documentation is ... well... not much ;) > > Oops! > > > The best thing is probably to start with the existing MySQL > > module. HOWEVER, I myself would be very interested in a native, > > high-performing Oracle driver. I neither have the expertise to do it > > not the test environment. > > I don't have the expertise either, but do have the test > environment... we can try. ;) A test environment is first step to expertise ;) > > > If you like, we could collaborate on this effort. I'd create a > > skeleton output module for you, guide you through using it and you > > provide the Oracle bits to it (that should be fairly easy). Of > course, > > that means your module would need to be contributed back to the > > project. > > That sounds really great. Before you start coding or preparing > anything, > let me check how well our DBs perform, because it's not yet clear if > they'll be able to cope with the high insertion rate we expect. If we > don't go for the Oracle database this work doesn't make sense. I bet > we'll want the Oracle, anyways. Sounds fair. > > For this evaluation, I already have a timestamp formatter that fits > into > Oracle, something that can be used with the property replacer, like > %timereported:::date-oracle%. Sounds good. This is one of the bad things about current code base, though. The formatter should long come from the custom plugin, but I didn't manage to do the script engine so far (the core of custom functions). Not a big deal, but something that annoys *me* ;) > It still needs some real-world testing, > but provided it works, is it interesting for the project? Definitely > If so, should > I submit the patch via bugzilla? Any way is fine. You can also just email me. Proper credits, of course are guaranteed. > Is there any paperwork (copyright > assingmnents a la FSF or whatever) that should be fullfilled? Nope, we think the project is in a strong enough position even if the submitter holds the copyright. Actually, this was one project goal: keep contributions easy. I really don't like all the blabla that e.g. you need to do when contributing to syslog-ng. Just be aware that some parts of rsyslog come under GPL while some come under LGPL (the runtime files). We assume that whatever you contribute comes under the license of the core module. For new runtime files, this means we expect LGPL, else we have a problem license-wise. Really looking forward to your results, Rainer > > Thanks. > -- > Luis Fernando Mu?oz Mej?as > Luis.Fernando.Munoz.Mejias at cern.ch > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Feb 16 18:52:07 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 18:52:07 +0100 Subject: [rsyslog] rsyslog on Debian 5.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC0E@grfint2.intern.adiscon.com> Hi folks, I guess most of you already know, but I have some excellent news to share. Rsyslog is now default on the stable Debian version: http://blog.gerhards.net/2009/02/rsyslog-now-default-on-stable-debian.ht ml Thanks to everyone who helped make this happen and special thanks to Michael Biebl, the driving force behind the Debian effort! Rainer From hks.private at gmail.com Mon Feb 16 19:18:13 2009 From: hks.private at gmail.com ((private) HKS) Date: Mon, 16 Feb 2009 13:18:13 -0500 Subject: [rsyslog] rsyslog on Debian 5.0 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC0E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC0E@grfint2.intern.adiscon.com> Message-ID: Congrats! -HKS On Mon, Feb 16, 2009 at 12:52 PM, Rainer Gerhards wrote: > Hi folks, > > I guess most of you already know, but I have some excellent news to > share. Rsyslog is now default on the stable Debian version: > > http://blog.gerhards.net/2009/02/rsyslog-now-default-on-stable-debian.ht > ml > > Thanks to everyone who helped make this happen and special thanks to > Michael Biebl, the driving force behind the Debian effort! > > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From aoz.syn at gmail.com Mon Feb 16 23:48:31 2009 From: aoz.syn at gmail.com (RB) Date: Mon, 16 Feb 2009 15:48:31 -0700 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <49993125.2060603@ecker-software.de> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> Message-ID: <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> On Mon, Feb 16, 2009 at 02:25, David Ecker wrote: > have you tried to contact the epel group? > > http://fedoraproject.org/wiki/EPEL > > They should be able to include an upgrade for rsyslog into their > repository for REL5 if you ask them. Failing that, I already wrote one spec for rsyslog-3.x under CentOS-5 and could be pretty easily persuaded to do so again. From daodennis at gmail.com Tue Feb 17 06:30:06 2009 From: daodennis at gmail.com (Dennis Ordanov) Date: Mon, 16 Feb 2009 21:30:06 -0800 Subject: [rsyslog] rsyslog eating FDs stops logging locally or remotely and eventually dies Message-ID: Hello Everyone, I use syslog to log locally and remotely via stunnel which is bound to the loopback address. It seems syslog will steadily use up FDs until it runs into the per process limit on my oBSD boxes and then either stops logging locally or forwarding traffic to stunnel, I don't know if this is a problem with stunnel or syslog or how to tell, but something is causing it to open a new file descriptor or unable to re-use another one or something...? I can just restart syslogd with a cron job weekly and increase the file descriptor limit, but that's not really a path I want to go down if I don't have to. If you think it will be useful to run syslogd in debug mode, but it can take a week for this problem to occur... I have 4 hypothesis of why this might be hapening: 1) syslog's interaction with stunnel is causing it to just to use more and more FDs 2) regarding #1, if there is a problem with stunnel accepting connections or being too overloaded or not being able to connect to the remote stunnel gateway then maybe its not accepting new conns to it or something? 3) something with myconfiguration is instigating this behaviour...? 4) none of the above Here is a box that will soon be in a broken state: root at hostname# /usr/sbin/syslogd -v rsyslogd 1.12.2, compiled with: FEATURE_REGEXP FEATURE_LARGEFILE SYSLOG_INET (Internet/remote support) root at hostname# uname -a OpenBSD hostname 4.1 GENERIC#1435 i386 # ulimit -a time(cpu-seconds) unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes) 8192 lockedmem(kbytes) 153844 memory(kbytes) 460268 nofiles(descriptors) 128 processes 532 I am running ktrace on this pid until I see it use another file descriptor being used by this process, right now at 109 it looks like. Come to think of it maybe I should be tracing stunnel too? root at host# fstat -n |grep syslog USER CMD PID FD MOUNT INUM MODE R/W DV|SZ root syslogd 20085 wd 0,0 2 40755 r 512 root syslogd 20085 0* unix dgram 0xd14f6a00 root syslogd 20085 1* internet stream tcp root syslogd 20085 2* internet stream tcp root syslogd 20085 3* internet stream tcp root syslogd 20085 4* internet stream tcp root syslogd 20085 5* internet stream tcp root syslogd 20085 6* internet stream tcp root syslogd 20085 7* internet stream tcp root syslogd 20085 8* internet stream tcp root syslogd 20085 9* internet stream tcp root syslogd 20085 10* internet stream tcp root syslogd 20085 11* internet stream tcp root syslogd 20085 12* internet stream tcp root syslogd 20085 13* internet stream tcp root syslogd 20085 14* internet stream tcp root syslogd 20085 15* internet stream tcp root syslogd 20085 16* unix dgram 0xd14048c0 root syslogd 20085 17* internet dgram udp *:514 root syslogd 20085 18* internet stream tcp root syslogd 20085 19* internet stream tcp root syslogd 20085 20* internet stream tcp root syslogd 20085 21* internet stream tcp root syslogd 20085 22* internet stream tcp root syslogd 20085 23* internet stream tcp root syslogd 20085 24* internet stream tcp root syslogd 20085 25* internet stream tcp root syslogd 20085 26* internet stream tcp root syslogd 20085 27* internet stream tcp root syslogd 20085 28* internet stream tcp root syslogd 20085 29* internet stream tcp root syslogd 20085 30* internet stream tcp root syslogd 20085 31* internet stream tcp root syslogd 20085 32* internet stream tcp root syslogd 20085 33* internet stream tcp root syslogd 20085 34* internet stream tcp root syslogd 20085 35* internet stream tcp root syslogd 20085 36* internet stream tcp root syslogd 20085 37* internet stream tcp root syslogd 20085 38* internet stream tcp root syslogd 20085 39* internet stream tcp root syslogd 20085 40* internet stream tcp root syslogd 20085 41* internet stream tcp root syslogd 20085 42* internet stream tcp root syslogd 20085 43* internet stream tcp root syslogd 20085 44* internet stream tcp root syslogd 20085 45* internet stream tcp root syslogd 20085 46* internet stream tcp root syslogd 20085 47* internet stream tcp root syslogd 20085 48* internet stream tcp root syslogd 20085 49* internet stream tcp root syslogd 20085 50* internet stream tcp root syslogd 20085 51* internet stream tcp root syslogd 20085 52* internet stream tcp root syslogd 20085 53* internet stream tcp root syslogd 20085 54* internet stream tcp root syslogd 20085 55* internet stream tcp root syslogd 20085 56* internet stream tcp root syslogd 20085 57* internet stream tcp root syslogd 20085 58* internet stream tcp root syslogd 20085 59* internet stream tcp root syslogd 20085 60* internet stream tcp 0xd6906648 127.0.0.1:4392 --> 127.0.0.1:5140 root syslogd 20085 61* internet stream tcp root syslogd 20085 62* internet stream tcp root syslogd 20085 63 0,4 844952 100644 w 81695 root syslogd 20085 64* internet stream tcp root syslogd 20085 65* internet stream tcp root syslogd 20085 66 0,4 844952 100644 w 81695 root syslogd 20085 67* internet stream tcp root syslogd 20085 68* internet stream tcp root syslogd 20085 69 0,4 844984 100644 w 73 root syslogd 20085 70* internet stream tcp root syslogd 20085 71* internet stream tcp root syslogd 20085 72 0,4 844984 100644 w 73 root syslogd 20085 73* internet stream tcp root syslogd 20085 74* internet stream tcp root syslogd 20085 75* internet stream tcp root syslogd 20085 76 0,4 844984 100644 w 73 root syslogd 20085 77* internet stream tcp root syslogd 20085 78* internet stream tcp root syslogd 20085 79* internet stream tcp root syslogd 20085 80 0,4 844969 100644 w 3437673 root syslogd 20085 81* internet stream tcp root syslogd 20085 82* internet stream tcp root syslogd 20085 83 0,4 844976 100644 w 442 root syslogd 20085 84* internet stream tcp root syslogd 20085 85* internet stream tcp root syslogd 20085 86 0,4 844976 100644 w 442 root syslogd 20085 87* internet stream tcp root syslogd 20085 88* internet stream tcp root syslogd 20085 89 0,4 844930 100640 w 18747 root syslogd 20085 90* internet stream tcp root syslogd 20085 91* internet stream tcp root syslogd 20085 92 0,4 844936 100600 w 74 root syslogd 20085 93* internet stream tcp root syslogd 20085 94* internet stream tcp root syslogd 20085 95 0,4 2328711 100600 w 46522 root syslogd 20085 96* internet stream tcp root syslogd 20085 97* internet stream tcp root syslogd 20085 98 0,4 844972 100640 w 476 root syslogd 20085 99* internet stream tcp root syslogd 20085 100* internet stream tcp root syslogd 20085 101 0,4 844941 100640 w 0 root syslogd 20085 102* internet stream tcp root syslogd 20085 103* internet stream tcp root syslogd 20085 104 0,4 844935 100640 w 0 root syslogd 20085 105* internet stream tcp root syslogd 20085 106* internet stream tcp root syslogd 20085 107 0,4 844931 100600 w 74 root syslogd 20085 108* internet stream tcp 0xd694c7d4 127.0.0.1:19723 --> 127.0.0.1:5140 root syslogd 20085 109* internet stream tcp 0xd694c964 127.0.0.1:42849 --> 127.0.0.1:5140 root at host# netstat -an Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 32 172.20.20.51.22 remote.63117 ESTABLISHED tcp 0 0 172.20.20.51.38090 remote.443 ESTABLISHED tcp 0 0 127.0.0.1.5140 127.0.0.1.42849 ESTABLISHED tcp 0 0 127.0.0.1.42849 127.0.0.1.5140 ESTABLISHED tcp 0 0 172.20.20.51.19898 remote.443 ESTABLISHED tcp 0 0 127.0.0.1.5140 127.0.0.1.19723 ESTABLISHED tcp 0 0 127.0.0.1.19723 127.0.0.1.5140 ESTABLISHED tcp 0 0 172.20.20.51.5494 remote.443 ESTABLISHED tcp 0 0 127.0.0.1.5140 127.0.0.1.4392 ESTABLISHED tcp 0 0 127.0.0.1.4392 127.0.0.1.5140 ESTABLISHED tcp 0 0 *.22 *.* LISTEN tcp 0 0 127.0.0.1.5140 *.* LISTEN tcp 0 0 127.0.0.1.587 *.* LISTEN tcp 0 0 127.0.0.1.25 *.* LISTEN tcp 0 0 *.37 *.* LISTEN tcp 0 0 *.13 *.* LISTEN tcp 0 0 *.113 *.* LISTEN Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 172.20.20.51.2947 172.20.20.92.123 udp 0 0 172.20.20.51.12927 172.20.20.91.123 udp 0 0 *.514 *.* udp 0 0 10.144.73.23.123 *.* udp 0 0 10.144.73.21.123 *.* udp 0 0 172.20.20.51.123 *.* udp 0 0 127.0.0.1.123 *.* udp 0 0 127.0.0.1.512 *.* root at host# fstat|grep stunnel USER CMD PID FD MOUNT INUM MODE R/W DV|SZ _stunnel stunnel 32055 root /var 6141184 drwxr-xr-x r 512 _stunnel stunnel 32055 wd /var 6141184 drwxr-xr-x r 512 _stunnel stunnel 32055 0 / 166117 crw-rw-rw- rw null _stunnel stunnel 32055 1 / 166117 crw-rw-rw- rw null _stunnel stunnel 32055 2 / 166117 crw-rw-rw- rw null _stunnel stunnel 32055 3 pipe 0xe9505e10 state: _stunnel stunnel 32055 4 pipe 0xe9505e10 state: _stunnel stunnel 32055 5 / 165853 crw-rw-rw- rw crypto _stunnel stunnel 32055 6* internet stream tcp 0xd6906e18 127.0.0.1:5140 <-- 127.0.0.1:4392 _stunnel stunnel 32055 7 pipe 0xe95057e0 state: _stunnel stunnel 32055 8 pipe 0xe95057e0 state: _stunnel stunnel 32055 9* internet stream tcp 0xd694cc84 127.0.0.1:5140 _stunnel stunnel 32055 10* internet stream tcp 0xd694c644 172.20.20.51:5494 --> remote:443 _stunnel stunnel 32055 11* internet stream tcp 0xd694c4b4 127.0.0.1:5140 <-- 127.0.0.1:19723 _stunnel stunnel 32055 12* internet stream tcp 0xd694ce14 172.20.20.51:19898 --> remote:443 _stunnel stunnel 32055 13* internet stream tcp 0xd694caf4 127.0.0.1:5140 <-- 127.0.0.1:42849 _stunnel stunnel 32055 14* internet stream tcp 0xd68cb19c 172.20.20.51:38090 --> remote:443 # ulimit -a time(cpu-seconds) unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes) 8192 lockedmem(kbytes) 153844 memory(kbytes) 460268 nofiles(descriptors) 128 processes 532 root at hostname# /usr/sbin/syslogd -v rsyslogd 1.12.2, compiled with: FEATURE_REGEXP FEATURE_LARGEFILE SYSLOG_INET (Internet/remote support) root at hostname# uname -a OpenBSD hostname 4.1 GENERIC#1435 i386 Here is how its getting started out of rc: syslogd_flags="-h -i /var/run/syslog.pid -m 0 -r 514" # flags for rsyslogd Process Entries: # ps -axwww|egrep '[s]yslog|[s]tunnel' 32055 ?? Is 2:22.48 /usr/local/sbin/stunnel 20085 ?? Is 4:50.88 syslogd -h -i /var/run/syslog.pid -m 0 -r 514 -a /var/empty/dev/log Here is the config: /etc/rsyslog.conf # Template to include time received by the Admin Server when forwarded to the Data Center. # Juniper Messages are not passed with a timestamp. $template MissingDate,"<%PRI%>%timegenerated% %HOSTNAME% %syslogtag%%msg%" # Template to remove the syslog tag "root:" for the heartbeat and checks when forwarded to the Data Center. $template NoSyslogTag,"<%PRI%>%timegenerated% %HOSTNAME% %msg%" # Template to allow for easier reading of the Cisco logs. # Include a text designation for the type of Cisco equipment. # Start the message at position at offset 19 to strip out time stamp. $template CiscoSW1,"%TIMESTAMP% %HOSTNAME% Switch1: %msg:19:500:drop-last-lf%\n" $template CiscoSW2,"%TIMESTAMP% %HOSTNAME% Switch2: %msg:19:500:drop-last-lf%\n" $template CiscoTS1,"%TIMESTAMP% %HOSTNAME% Term1: %msg:19:500:drop-last-lf%\n" # Forward messages from the admin server heartbeat and checks based on message id :msg, contains, "NHB10001:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10002:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10003:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10004:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10005:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10006:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10007:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10008:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10009:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10011:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10012:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10015:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10016:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10017:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CLP10020:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CLP10021:" @@127.0.0.1:5140;NoSyslogTag # Forward messages from juniper nodes basd on message id :msg, contains, "ADM10310:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM20255:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM20928:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM22798:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM23046:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM24336:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM24337:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC22051:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC23037:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC23038:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC23039:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT10301:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT21060:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT21089:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT22677:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT22678:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT22696:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT23391:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT23551:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT23552:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT24080:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT24417:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT24418:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20146:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20147:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20148:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20149:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20150:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20151:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20152:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20153:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20154:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20155:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20643:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20644:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20645:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR24016:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR24019:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR24076:" @@127.0.0.1:5140;MissingDate :msg, contains, "LIC10200:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10062:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10087:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10088:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10089:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10090:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10091:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10092:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10093:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10094:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10298:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10299:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10314:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS23041:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS23402:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS23409:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24015:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24020:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24316:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24317:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24348:" @@127.0.0.1:5140;MissingDate # Forward messages from F5 nodes based on lb hostnames :HOSTNAME, contains, "lb1-" @@127.0.0.1:5140 :HOSTNAME, contains, "lb2-" @@127.0.0.1:5140 # Log F5 messages locally for archival purposes based on lb hostnames :HOSTNAME, contains, "lb1-" /var/log/f5.log :HOSTNAME, contains, "lb2-" /var/log/f5.log # Log Cisco messages locally for archival purposes based on ip hostnames :HOSTNAME, contains, "172.20.20.101" /var/log/cisco.log :HOSTNAME, contains, "172.20.20.102" /var/log/cisco.log :HOSTNAME, contains, "172.20.20.227" /var/log/cisco.log # Discard lb1/2 and cisco messages from further processing :HOSTNAME, contains, "lb1-" ~ :HOSTNAME, contains, "lb2-" ~ :HOSTNAME, contains, "172.20.20.101" ~ :HOSTNAME, contains, "172.20.20.102" ~ :HOSTNAME, contains, "172.20.20.227" ~ # Log local7 messages locally for archival purposes local7.* /var/log/local7.log *.notice;\ auth,authpriv,cron,ftp,kern,lpr,mail,user,local7.none /var/log/messages kern.debug;syslog,user.info /var/log/messages auth.info /var/log/authlog authpriv.debug /var/log/secure cron.info /var/cron/log daemon.info /var/log/daemon ftp.info /var/log/xferlog lpr.debug /var/log/lpd-errs mail.info /var/log/maillog #uucp.info /var/log/uucp # Everyone gets emergency messages. *.emerg I've tried to look on the net for anything that had to do with syslog and file descriptors and or how these problems happen and coming out with pretty much squat.. Thank you, Dennis O. From rgerhards at hq.adiscon.com Tue Feb 17 07:18:14 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 17 Feb 2009 07:18:14 +0100 Subject: [rsyslog] rsyslog eating FDs stops logging locally or remotely andeventually dies In-Reply-To: References: Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC10@grfint2.intern.adiscon.com> Hi Dennis, First thing I would upgrade to a recent release, either v2-stable or v3-stable. The version you are using is heavily outdated and looking into the issue with that version simply makes no sense. Plus, I think chances are good the problem will disappear with the new versions. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Dennis Ordanov > Sent: Tuesday, February 17, 2009 6:30 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] rsyslog eating FDs stops logging locally > or remotely andeventually dies > > Hello Everyone, > > I use syslog to log locally and remotely via stunnel which is bound to > the loopback address. It seems syslog will steadily use up FDs until > it runs into the per process limit on my oBSD boxes and then either > stops logging locally or forwarding traffic to stunnel, I don't know > if this is a problem with stunnel or syslog or how to tell, but > something is causing it to open a new file descriptor or unable to > re-use another one or something...? > > > I can just restart syslogd with a cron job weekly and increase the > file descriptor limit, but that's not really a path I want to go down > if I don't have to. > > If you think it will be useful to run syslogd in debug mode, but it > can take a week for this problem to occur... > > I have 4 hypothesis of why this might be hapening: > 1) syslog's interaction with stunnel is causing it to just to use more > and more FDs > 2) regarding #1, if there is a problem with stunnel accepting > connections or being too overloaded or not being able to connect to > the remote stunnel gateway then maybe its not accepting new conns to > it or something? > 3) something with myconfiguration is instigating this behaviour...? > 4) none of the above > > Here is a box that will soon be in a broken state: > > root at hostname# /usr/sbin/syslogd -v > rsyslogd 1.12.2, compiled with: > FEATURE_REGEXP > FEATURE_LARGEFILE > SYSLOG_INET (Internet/remote support) > root at hostname# uname -a > OpenBSD hostname 4.1 GENERIC#1435 i386 > > # ulimit -a > time(cpu-seconds) unlimited > file(blocks) unlimited > coredump(blocks) unlimited > data(kbytes) 1048576 > stack(kbytes) 8192 > lockedmem(kbytes) 153844 > memory(kbytes) 460268 > nofiles(descriptors) 128 > processes 532 > > I am running ktrace on this pid until I see it use another file > descriptor being used by this process, right now at 109 it looks like. > Come to think of it maybe I should be tracing stunnel too? > > root at host# fstat -n |grep syslog > USER CMD PID FD MOUNT INUM MODE > R/W DV|SZ > root syslogd 20085 wd 0,0 2 40755 r 512 > root syslogd 20085 0* unix dgram 0xd14f6a00 > root syslogd 20085 1* internet stream tcp > root syslogd 20085 2* internet stream tcp > root syslogd 20085 3* internet stream tcp > root syslogd 20085 4* internet stream tcp > root syslogd 20085 5* internet stream tcp > root syslogd 20085 6* internet stream tcp > root syslogd 20085 7* internet stream tcp > root syslogd 20085 8* internet stream tcp > root syslogd 20085 9* internet stream tcp > root syslogd 20085 10* internet stream tcp > root syslogd 20085 11* internet stream tcp > root syslogd 20085 12* internet stream tcp > root syslogd 20085 13* internet stream tcp > root syslogd 20085 14* internet stream tcp > root syslogd 20085 15* internet stream tcp > root syslogd 20085 16* unix dgram 0xd14048c0 > root syslogd 20085 17* internet dgram udp *:514 > root syslogd 20085 18* internet stream tcp > root syslogd 20085 19* internet stream tcp > root syslogd 20085 20* internet stream tcp > root syslogd 20085 21* internet stream tcp > root syslogd 20085 22* internet stream tcp > root syslogd 20085 23* internet stream tcp > root syslogd 20085 24* internet stream tcp > root syslogd 20085 25* internet stream tcp > root syslogd 20085 26* internet stream tcp > root syslogd 20085 27* internet stream tcp > root syslogd 20085 28* internet stream tcp > root syslogd 20085 29* internet stream tcp > root syslogd 20085 30* internet stream tcp > root syslogd 20085 31* internet stream tcp > root syslogd 20085 32* internet stream tcp > root syslogd 20085 33* internet stream tcp > root syslogd 20085 34* internet stream tcp > root syslogd 20085 35* internet stream tcp > root syslogd 20085 36* internet stream tcp > root syslogd 20085 37* internet stream tcp > root syslogd 20085 38* internet stream tcp > root syslogd 20085 39* internet stream tcp > root syslogd 20085 40* internet stream tcp > root syslogd 20085 41* internet stream tcp > root syslogd 20085 42* internet stream tcp > root syslogd 20085 43* internet stream tcp > root syslogd 20085 44* internet stream tcp > root syslogd 20085 45* internet stream tcp > root syslogd 20085 46* internet stream tcp > root syslogd 20085 47* internet stream tcp > root syslogd 20085 48* internet stream tcp > root syslogd 20085 49* internet stream tcp > root syslogd 20085 50* internet stream tcp > root syslogd 20085 51* internet stream tcp > root syslogd 20085 52* internet stream tcp > root syslogd 20085 53* internet stream tcp > root syslogd 20085 54* internet stream tcp > root syslogd 20085 55* internet stream tcp > root syslogd 20085 56* internet stream tcp > root syslogd 20085 57* internet stream tcp > root syslogd 20085 58* internet stream tcp > root syslogd 20085 59* internet stream tcp > root syslogd 20085 60* internet stream tcp 0xd6906648 > 127.0.0.1:4392 --> 127.0.0.1:5140 > root syslogd 20085 61* internet stream tcp > root syslogd 20085 62* internet stream tcp > root syslogd 20085 63 0,4 844952 100644 w 81695 > root syslogd 20085 64* internet stream tcp > root syslogd 20085 65* internet stream tcp > root syslogd 20085 66 0,4 844952 100644 w 81695 > root syslogd 20085 67* internet stream tcp > root syslogd 20085 68* internet stream tcp > root syslogd 20085 69 0,4 844984 100644 w 73 > root syslogd 20085 70* internet stream tcp > root syslogd 20085 71* internet stream tcp > root syslogd 20085 72 0,4 844984 100644 w 73 > root syslogd 20085 73* internet stream tcp > root syslogd 20085 74* internet stream tcp > root syslogd 20085 75* internet stream tcp > root syslogd 20085 76 0,4 844984 100644 w 73 > root syslogd 20085 77* internet stream tcp > root syslogd 20085 78* internet stream tcp > root syslogd 20085 79* internet stream tcp > root syslogd 20085 80 0,4 844969 100644 w 3437673 > root syslogd 20085 81* internet stream tcp > root syslogd 20085 82* internet stream tcp > root syslogd 20085 83 0,4 844976 100644 w 442 > root syslogd 20085 84* internet stream tcp > root syslogd 20085 85* internet stream tcp > root syslogd 20085 86 0,4 844976 100644 w 442 > root syslogd 20085 87* internet stream tcp > root syslogd 20085 88* internet stream tcp > root syslogd 20085 89 0,4 844930 100640 w 18747 > root syslogd 20085 90* internet stream tcp > root syslogd 20085 91* internet stream tcp > root syslogd 20085 92 0,4 844936 100600 w 74 > root syslogd 20085 93* internet stream tcp > root syslogd 20085 94* internet stream tcp > root syslogd 20085 95 0,4 2328711 100600 w 46522 > root syslogd 20085 96* internet stream tcp > root syslogd 20085 97* internet stream tcp > root syslogd 20085 98 0,4 844972 100640 w 476 > root syslogd 20085 99* internet stream tcp > root syslogd 20085 100* internet stream tcp > root syslogd 20085 101 0,4 844941 100640 w 0 > root syslogd 20085 102* internet stream tcp > root syslogd 20085 103* internet stream tcp > root syslogd 20085 104 0,4 844935 100640 w 0 > root syslogd 20085 105* internet stream tcp > root syslogd 20085 106* internet stream tcp > root syslogd 20085 107 0,4 844931 100600 w 74 > root syslogd 20085 108* internet stream tcp 0xd694c7d4 > 127.0.0.1:19723 --> 127.0.0.1:5140 > root syslogd 20085 109* internet stream tcp 0xd694c964 > 127.0.0.1:42849 --> 127.0.0.1:5140 > > > root at host# netstat -an > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address > (state) > tcp 0 32 172.20.20.51.22 remote.63117 > ESTABLISHED > tcp 0 0 172.20.20.51.38090 remote.443 > ESTABLISHED > tcp 0 0 127.0.0.1.5140 127.0.0.1.42849 > ESTABLISHED > tcp 0 0 127.0.0.1.42849 127.0.0.1.5140 > ESTABLISHED > tcp 0 0 172.20.20.51.19898 remote.443 > ESTABLISHED > tcp 0 0 127.0.0.1.5140 127.0.0.1.19723 > ESTABLISHED > tcp 0 0 127.0.0.1.19723 127.0.0.1.5140 > ESTABLISHED > tcp 0 0 172.20.20.51.5494 remote.443 > ESTABLISHED > tcp 0 0 127.0.0.1.5140 127.0.0.1.4392 > ESTABLISHED > tcp 0 0 127.0.0.1.4392 127.0.0.1.5140 > ESTABLISHED > tcp 0 0 *.22 *.* > LISTEN > tcp 0 0 127.0.0.1.5140 *.* > LISTEN > tcp 0 0 127.0.0.1.587 *.* > LISTEN > tcp 0 0 127.0.0.1.25 *.* > LISTEN > tcp 0 0 *.37 *.* > LISTEN > tcp 0 0 *.13 *.* > LISTEN > tcp 0 0 *.113 *.* > LISTEN > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address > (state) > udp 0 0 172.20.20.51.2947 172.20.20.92.123 > udp 0 0 172.20.20.51.12927 172.20.20.91.123 > udp 0 0 *.514 *.* > udp 0 0 10.144.73.23.123 *.* > udp 0 0 10.144.73.21.123 *.* > udp 0 0 172.20.20.51.123 *.* > udp 0 0 127.0.0.1.123 *.* > udp 0 0 127.0.0.1.512 *.* > > > root at host# fstat|grep stunnel > USER CMD PID FD MOUNT INUM MODE > R/W DV|SZ > _stunnel stunnel 32055 root /var 6141184 drwxr-xr-x > r 512 > _stunnel stunnel 32055 wd /var 6141184 drwxr-xr-x > r 512 > _stunnel stunnel 32055 0 / 166117 crw-rw-rw- > rw null > _stunnel stunnel 32055 1 / 166117 crw-rw-rw- > rw null > _stunnel stunnel 32055 2 / 166117 crw-rw-rw- > rw null > _stunnel stunnel 32055 3 pipe 0xe9505e10 state: > _stunnel stunnel 32055 4 pipe 0xe9505e10 state: > _stunnel stunnel 32055 5 / 165853 crw-rw-rw- > rw crypto > _stunnel stunnel 32055 6* internet stream tcp 0xd6906e18 > 127.0.0.1:5140 <-- 127.0.0.1:4392 > _stunnel stunnel 32055 7 pipe 0xe95057e0 state: > _stunnel stunnel 32055 8 pipe 0xe95057e0 state: > _stunnel stunnel 32055 9* internet stream tcp > 0xd694cc84 127.0.0.1:5140 > _stunnel stunnel 32055 10* internet stream tcp 0xd694c644 > 172.20.20.51:5494 --> remote:443 > _stunnel stunnel 32055 11* internet stream tcp 0xd694c4b4 > 127.0.0.1:5140 <-- 127.0.0.1:19723 > _stunnel stunnel 32055 12* internet stream tcp 0xd694ce14 > 172.20.20.51:19898 --> remote:443 > _stunnel stunnel 32055 13* internet stream tcp 0xd694caf4 > 127.0.0.1:5140 <-- 127.0.0.1:42849 > _stunnel stunnel 32055 14* internet stream tcp 0xd68cb19c > 172.20.20.51:38090 --> remote:443 > > # ulimit -a > time(cpu-seconds) unlimited > file(blocks) unlimited > coredump(blocks) unlimited > data(kbytes) 1048576 > stack(kbytes) 8192 > lockedmem(kbytes) 153844 > memory(kbytes) 460268 > nofiles(descriptors) 128 > processes 532 > > root at hostname# /usr/sbin/syslogd -v > rsyslogd 1.12.2, compiled with: > FEATURE_REGEXP > FEATURE_LARGEFILE > SYSLOG_INET (Internet/remote support) > root at hostname# uname -a > OpenBSD hostname 4.1 GENERIC#1435 i386 > > Here is how its getting started out of rc: > > syslogd_flags="-h -i /var/run/syslog.pid -m 0 -r 514" # > flags for rsyslogd > > Process Entries: > # ps -axwww|egrep '[s]yslog|[s]tunnel' > 32055 ?? Is 2:22.48 /usr/local/sbin/stunnel > 20085 ?? Is 4:50.88 syslogd -h -i /var/run/syslog.pid -m 0 -r > 514 -a /var/empty/dev/log > > Here is the config: > > /etc/rsyslog.conf > # Template to include time received by the Admin Server when forwarded > to the Data Center. > # Juniper Messages are not passed with a timestamp. > > $template MissingDate,"<%PRI%>%timegenerated% %HOSTNAME% > %syslogtag%%msg%" > > # Template to remove the syslog tag "root:" for the heartbeat and > checks when forwarded to the Data Center. > > $template NoSyslogTag,"<%PRI%>%timegenerated% %HOSTNAME% %msg%" > > # Template to allow for easier reading of the Cisco logs. > # Include a text designation for the type of Cisco equipment. > # Start the message at position at offset 19 to strip out time stamp. > > $template CiscoSW1,"%TIMESTAMP% %HOSTNAME% Switch1: > %msg:19:500:drop-last-lf%\n" > $template CiscoSW2,"%TIMESTAMP% %HOSTNAME% Switch2: > %msg:19:500:drop-last-lf%\n" > $template CiscoTS1,"%TIMESTAMP% %HOSTNAME% Term1: > %msg:19:500:drop-last-lf%\n" > > # Forward messages from the admin server heartbeat and checks based on > message id > :msg, contains, "NHB10001:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10002:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10003:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10004:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10005:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10006:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10007:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10008:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10009:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10011:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10012:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10015:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10016:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10017:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CLP10020:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CLP10021:" > @@127.0.0.1:5140;NoSyslogTag > > # Forward messages from juniper nodes basd on message id > :msg, contains, "ADM10310:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM20255:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM20928:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM22798:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM23046:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM24336:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM24337:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC22051:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC23037:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC23038:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC23039:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT10301:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT21060:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT21089:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT22677:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT22678:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT22696:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT23391:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT23551:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT23552:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT24080:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT24417:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT24418:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20146:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20147:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20148:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20149:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20150:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20151:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20152:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20153:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20154:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20155:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20643:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20644:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20645:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR24016:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR24019:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR24076:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "LIC10200:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10062:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10087:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10088:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10089:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10090:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10091:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10092:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10093:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10094:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10298:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10299:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10314:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS23041:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS23402:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS23409:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24015:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24020:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24316:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24317:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24348:" > @@127.0.0.1:5140;MissingDate > > # Forward messages from F5 nodes based on lb hostnames > :HOSTNAME, contains, "lb1-" > @@127.0.0.1:5140 > :HOSTNAME, contains, "lb2-" > @@127.0.0.1:5140 > > # Log F5 messages locally for archival purposes based on lb hostnames > :HOSTNAME, contains, "lb1-" > /var/log/f5.log > :HOSTNAME, contains, "lb2-" > /var/log/f5.log > > # Log Cisco messages locally for archival purposes based on > ip hostnames > :HOSTNAME, contains, "172.20.20.101" > /var/log/cisco.log > :HOSTNAME, contains, "172.20.20.102" > /var/log/cisco.log > :HOSTNAME, contains, "172.20.20.227" > /var/log/cisco.log > > # Discard lb1/2 and cisco messages from further processing > :HOSTNAME, contains, "lb1-" ~ > :HOSTNAME, contains, "lb2-" ~ > :HOSTNAME, contains, "172.20.20.101" ~ > :HOSTNAME, contains, "172.20.20.102" ~ > :HOSTNAME, contains, "172.20.20.227" ~ > > # Log local7 messages locally for archival purposes > local7.* > /var/log/local7.log > > *.notice;\ > auth,authpriv,cron,ftp,kern,lpr,mail,user,local7.none > /var/log/messages > kern.debug;syslog,user.info > /var/log/messages > auth.info > /var/log/authlog > authpriv.debug > /var/log/secure > cron.info /var/cron/log > daemon.info > /var/log/daemon > ftp.info > /var/log/xferlog > lpr.debug > /var/log/lpd-errs > mail.info > /var/log/maillog > #uucp.info /var/log/uucp > > # Everyone gets emergency messages. > *.emerg > > I've tried to look on the net for anything that had to do with syslog > and file descriptors and or how these problems happen and coming out > with pretty much squat.. > > Thank you, > Dennis O. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From daodennis at gmail.com Tue Feb 17 08:23:05 2009 From: daodennis at gmail.com (Dennis Ordanov) Date: Mon, 16 Feb 2009 23:23:05 -0800 Subject: [rsyslog] rsyslog eating FDs stops logging locally or remotely andeventually dies In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC10@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC10@grfint2.intern.adiscon.com> Message-ID: On Mon, Feb 16, 2009 at 10:18 PM, Rainer Gerhards wrote: > Hi Dennis, > > First thing I would upgrade to a recent release, either v2-stable or > v3-stable. The version you are using is heavily outdated and looking > into the issue with that version simply makes no sense. Plus, I think > chances are good the problem will disappear with the new versions. > Thanks Rainer! I I will look into doing that, if not upgrading OBSD period to something other than 3.8/4.1 (observed on both) for these group of servers (and all the testing that goes along with it...) Thanks, Dennis O. > Rainer > From rgerhards at hq.adiscon.com Tue Feb 17 09:17:53 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 17 Feb 2009 09:17:53 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com><49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> Hi RB, Consider this a persuasion attempt ;) One thing, though is how to make those things easily acessible. Can we (you? ;)) get it pushed to something like EPEL, or are there other places or would it be sufficient to include some packages on rsyslog.com (made inside a specially created part of the git tree, too). How is this usually done? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of RB > Sent: Monday, February 16, 2009 11:49 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of > sending devices? > > On Mon, Feb 16, 2009 at 02:25, David Ecker > wrote: > > have you tried to contact the epel group? > > > > http://fedoraproject.org/wiki/EPEL > > > > They should be able to include an upgrade for rsyslog into their > > repository for REL5 if you ask them. > > Failing that, I already wrote one spec for rsyslog-3.x under CentOS-5 > and could be pretty easily persuaded to do so again. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Feb 17 14:46:50 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 17 Feb 2009 14:46:50 +0100 Subject: [rsyslog] Advise Requested - most important features Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Hi all, I have the chance to write an article about rsyslog for one of the largest German *nix magazines. It shall be an overview over rsyslog. I would like to highlight some features. So which ones do you think are most important for *ordinary* users? Feedback is most welcome and my deadline is tight (as usual ;)). I think this is an excellent opportunity to present rsyslog to a wider audience, one that that should be done as well as possible ;) Rainer From kenneho.ndu at gmail.com Tue Feb 17 15:08:06 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Tue, 17 Feb 2009 15:08:06 +0100 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: Well, I believe local spooling of syslog messages is quite neat. On 2/17/09, Rainer Gerhards wrote: > > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Feedback is most welcome and my > deadline is tight (as usual ;)). > > I think this is an excellent opportunity to present rsyslog to a wider > audience, one that that should be done as well as possible ;) > > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From mbiebl at gmail.com Tue Feb 17 15:19:59 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Tue, 17 Feb 2009 15:19:59 +0100 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: 2009/2/17 Rainer Gerhards : > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Feedback is most welcome and my > deadline is tight (as usual ;)). I think TLS support is pretty cool, db output support probably too. Generally the whole "reliable logging", with on-disk queues, relp etc. is what set's it apart from sysklogd, but definitely a more "advanced" feature that probably not every ordinary user needs. Ordinary users might be interested in the advanced filtering mechanisms, support for "~", templating etc. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From mrdemeanour at jackpot.uk.net Tue Feb 17 15:22:35 2009 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Tue, 17 Feb 2009 14:22:35 +0000 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <499AC82B.9010508@jackpot.uk.net> Rainer Gerhards wrote: > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. > I would like to highlight some features. So which ones do you think > are most important for *ordinary* users? Feedback is most welcome and > my deadline is tight (as usual ;)). > > I think this is an excellent opportunity to present rsyslog to a > wider audience, one that that should be done as well as possible ;) Fantastic support. But I don't know how you do that, when it's you doing the support and you writing the article. Perhaps you need a ghost-writer? -- Jack. From hks.private at gmail.com Tue Feb 17 15:45:59 2009 From: hks.private at gmail.com ((private) HKS) Date: Tue, 17 Feb 2009 09:45:59 -0500 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: On Tue, Feb 17, 2009 at 8:46 AM, Rainer Gerhards wrote: > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Feedback is most welcome and my > deadline is tight (as usual ;)). > > I think this is an excellent opportunity to present rsyslog to a wider > audience, one that that should be done as well as possible ;) > > Rainer For my usage, the greatest benefits are: From hks.private at gmail.com Tue Feb 17 15:49:08 2009 From: hks.private at gmail.com ((private) HKS) Date: Tue, 17 Feb 2009 09:49:08 -0500 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: On Tue, Feb 17, 2009 at 9:45 AM, (private) HKS wrote: > On Tue, Feb 17, 2009 at 8:46 AM, Rainer Gerhards > wrote: >> Hi all, >> >> I have the chance to write an article about rsyslog for one of the >> largest German *nix magazines. It shall be an overview over rsyslog. I >> would like to highlight some features. So which ones do you think are >> most important for *ordinary* users? Feedback is most welcome and my >> deadline is tight (as usual ;)). >> >> I think this is an excellent opportunity to present rsyslog to a wider >> audience, one that that should be done as well as possible ;) >> >> Rainer > > > For my usage, the greatest benefits are: ...not hitting the send button when I forget that tab doesn't work in Gmail like it does in vi. *ahem* - Reliable delivery (TCP/RELP, spooling of undeliverable messages) - Templates (both for reformatting log messages and for dynamic filenames) - Flexible filtering options - Intuitive configuration for someone already familiar with BSD syslog -HKS From danson at rackspace.com Tue Feb 17 16:19:55 2009 From: danson at rackspace.com (Daniel Anson) Date: Tue, 17 Feb 2009 09:19:55 -0600 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <1509_1234884068_n1HFL0eO003870_96AF20FDF4301D419B33CCE8E3A0132B0B41CC11@SAT4MX07.RACKSPACE.CORP> The disk based queue is IMHO the best feature. I use the database plug-in as well but common users may not use that feature as much. It's simple replacement for the stock syslogd and extended timestamp are useful as well. -Daniel Anson -Rackspace Managed Hosting -Linux Systems Engineer III -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards Sent: Tuesday, February 17, 2009 7:47 AM To: rsyslog-users Subject: [rsyslog] Advise Requested - most important features Hi all, I have the chance to write an article about rsyslog for one of the largest German *nix magazines. It shall be an overview over rsyslog. I would like to highlight some features. So which ones do you think are most important for *ordinary* users? Feedback is most welcome and my deadline is tight (as usual ;)). I think this is an excellent opportunity to present rsyslog to a wider audience, one that that should be done as well as possible ;) Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From aoz.syn at gmail.com Tue Feb 17 16:40:10 2009 From: aoz.syn at gmail.com (RB) Date: Tue, 17 Feb 2009 08:40:10 -0700 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <4255c2570902170740x3d235c46t2af8d5e2931e7cae@mail.gmail.com> On Tue, Feb 17, 2009 at 06:46, Rainer Gerhards wrote: > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Ordinary users: - drop-in syslogd replacement - database integration - templates - TLS Power users: - RELP - queues - template abuse - Heavy focus on RFC compliance - modular input/output (can't wait for that filter framework!) From aoz.syn at gmail.com Tue Feb 17 21:11:39 2009 From: aoz.syn at gmail.com (RB) Date: Tue, 17 Feb 2009 13:11:39 -0700 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> Message-ID: <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> On Tue, Feb 17, 2009 at 01:17, Rainer Gerhards wrote: > Hi RB, > > Consider this a persuasion attempt ;) > > One thing, though is how to make those things easily acessible. Can we > (you? ;)) get it pushed to something like EPEL, or are there other > places or would it be sufficient to include some packages on rsyslog.com > (made inside a specially created part of the git tree, too). How is this > usually done? A quick look upstream shows that Fedora is maintaining a _very_ current package (currently 3.21.10, updated 3 hours ago). The person (Tomas) that seems to have taken over the Fedora SPEC maintenance has an @redhat.com address, so they might be the right person to persuade to get a stable (3.20.4) package into EPEL. I'll ask and see what they say. That said, I haven't tested this yet, but generally speaking Fedora RPMs have worked reasonably well for me under CentOS as long as I'm current. Regardless, I'll take the flag and see what I can do to get a readily-accessible reasonably current build available for CentOS-5. From serbulent at pardus.org.tr Wed Feb 18 07:43:11 2009 From: serbulent at pardus.org.tr (Serbulent UNSAL) Date: Wed, 18 Feb 2009 08:43:11 +0200 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <200902180843.11948.serbulent@pardus.org.tr> On Tuesday 17 February 2009 15:46:50 Rainer Gerhards wrote: > I think this is an excellent opportunity to present rsyslog to a wider > audience, one that that should be done as well as possible ;) > > Rainer Flitering is my favorite... -- ?yi ?al??malar, Serb?lent From r.bhatia at ipax.at Wed Feb 18 09:51:50 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Wed, 18 Feb 2009 09:51:50 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at> <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Message-ID: <499BCC26.70605@ipax.at> hello rainer, Rainer Gerhards wrote: > Hi Raoul, > > I don't keep track of the bug in the older releases - simply too much > work, especially in this case. The best would be to use v3-stable from > git (I have not yet released a tarball as I'd like to get some feedback > from the field, first - not too often release stable versions..). just for the records - with rsyslog stable with git cs d742b251a6cdac02b235bd7459fa60890a0e6e i have not seen this issue until now. thanks! raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From rgerhards at hq.adiscon.com Wed Feb 18 09:56:03 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 18 Feb 2009 09:56:03 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <499BCC26.70605@ipax.at> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at><577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> <499BCC26.70605@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC45@grfint2.intern.adiscon.com> Hi Raoul, thanks for this feedback, much appreciated. And for everyone's information: after this patch, I did not get any new reports of any such abort, but got a number of messages which claim that the situation did no longer occur. David Lang, however, has experienced an issue during HUP processing, which I think is a different issue. So at least the situation has very much improved. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Wednesday, February 18, 2009 9:52 AM > To: rsyslog-users > Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: > double free or corruption (!prev): 0x0000000000ef03b0 *** > > hello rainer, > > Rainer Gerhards wrote: > > Hi Raoul, > > > > I don't keep track of the bug in the older releases - simply too much > > work, especially in this case. The best would be to use v3-stable > from > > git (I have not yet released a tarball as I'd like to get some > feedback > > from the field, first - not too often release stable versions..). > > just for the records - with rsyslog stable with git cs > d742b251a6cdac02b235bd7459fa60890a0e6e i have not seen this issue until > now. > > thanks! > raoul > -- > ____________________________________________________________________ > DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at > Technischer Leiter > > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at > Barawitzkagasse 10/2/2/11 email. office at ipax.at > 1190 Wien tel. +43 1 3670030 > FN 277995t HG Wien fax. +43 1 3670030 15 > ____________________________________________________________________ > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Wed Feb 18 13:23:14 2009 From: david at lang.hm (david at lang.hm) Date: Wed, 18 Feb 2009 04:23:14 -0800 (PST) Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC45@grfint2.intern.adiscon.com> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at><577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> <499BCC26.70605@ipax.at> <577465F99B41C842AAFBE9ED71E70ABA44FC45@grfint2.intern.adiscon.com> Message-ID: On Wed, 18 Feb 2009, Rainer Gerhards wrote: > Hi Raoul, > > thanks for this feedback, much appreciated. > > And for everyone's information: after this patch, I did not get any new > reports of any such abort, but got a number of messages which claim that > the situation did no longer occur. David Lang, however, has experienced > an issue during HUP processing, which I think is a different issue. I have been doing more stress testing and have not duplicated the problem in the last two weeks since I compltely removed the install and reinstalled it. I don't know why, but it is looking like when I install a new .deb on a system with rsyslog in it, it's not replacing all the files (specificly the input and output modules). I know that they are in the .deb becouse if I manually delete them they are installed with a new .deb, but if I don't manually remove them they don't get replaced. since the /debian directory was removed I'm using checkinstall to make the packages. David Lang > So at least the situation has very much improved. > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] >> Sent: Wednesday, February 18, 2009 9:52 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: >> double free or corruption (!prev): 0x0000000000ef03b0 *** >> >> hello rainer, >> >> Rainer Gerhards wrote: >>> Hi Raoul, >>> >>> I don't keep track of the bug in the older releases - simply too > much >>> work, especially in this case. The best would be to use v3-stable >> from >>> git (I have not yet released a tarball as I'd like to get some >> feedback >>> from the field, first - not too often release stable versions..). >> >> just for the records - with rsyslog stable with git cs >> d742b251a6cdac02b235bd7459fa60890a0e6e i have not seen this issue > until >> now. >> >> thanks! >> raoul >> -- >> ____________________________________________________________________ >> DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at >> Technischer Leiter >> >> IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at >> Barawitzkagasse 10/2/2/11 email. office at ipax.at >> 1190 Wien tel. +43 1 3670030 >> FN 277995t HG Wien fax. +43 1 3670030 15 >> ____________________________________________________________________ >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 19 15:16:29 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 19 Feb 2009 15:16:29 +0100 Subject: [rsyslog] requesting log samples Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> Hi all, in an effort to enhance the rsyslog legacy syslog parser, I would appreciate if you could provide me with some *raw* syslog samples. I don't need lots of messages, just a few from as many different devices as possible. What I am primarily interested in is the header and early message parts. The full story is here: http://blog.gerhards.net/2009/02/calling-for-log-samples.html I would deeply appreciate if you could forward this to anyone who could be willing to contribute. Thanks, Rainer From david at lang.hm Thu Feb 19 18:21:46 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 19 Feb 2009 09:21:46 -0800 (PST) Subject: [rsyslog] requesting log samples In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> Message-ID: On Thu, 19 Feb 2009, Rainer Gerhards wrote: > Hi all, > > in an effort to enhance the rsyslog legacy syslog parser, I would > appreciate if you could provide me with some *raw* syslog samples. I > don't need lots of messages, just a few from as many different devices > as possible. What I am primarily interested in is the header and early > message parts. > > The full story is here: > > http://blog.gerhards.net/2009/02/calling-for-log-samples.html have you taken a look at www.loganalysis.org? specificly they have a project for this at http://www.loganalysis.org/sample-logs/samples.html not a lot of things there now, but if you are gathering things it would be good to put them in a place where they can be used by lots of folks. David Lang > I would deeply appreciate if you could forward this to anyone who could > be willing to contribute. > > Thanks, > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 19 18:31:09 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 19 Feb 2009 18:31:09 +0100 Subject: [rsyslog] requesting log samples In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC7D@grfint2.intern.adiscon.com> Hi David, I know this place and I know Tina, who builds it, quite well. She started collecting a couple of years ago and there were very, very few contributions. One of the primary show stoppers, as I understand it, was that for the purposes stated by loganalysis.org, they needed somewhat bigger logs. I really need only single log entries, as I do not want to analyze them but parse the header. Thus I wanted to give it a new shot and see if I can get more sample for this very limited use case. Plus, I have to admit, loganalysis.org is now owned by splunk and while I like them, I prefer not to stick with something that I cannot control for things that are quite relevant for the work I do. But that is only a secondary reason. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Thursday, February 19, 2009 6:22 PM > To: rsyslog-users > Subject: Re: [rsyslog] requesting log samples > > On Thu, 19 Feb 2009, Rainer Gerhards wrote: > > > Hi all, > > > > in an effort to enhance the rsyslog legacy syslog parser, I would > > appreciate if you could provide me with some *raw* syslog samples. I > > don't need lots of messages, just a few from as many different > devices > > as possible. What I am primarily interested in is the header and > early > > message parts. > > > > The full story is here: > > > > http://blog.gerhards.net/2009/02/calling-for-log-samples.html > > have you taken a look at www.loganalysis.org? > > > specificly they have a project for this at > http://www.loganalysis.org/sample-logs/samples.html > not a lot of things there now, but if you are gathering things it would > be > good to put them in a place where they can be used by lots of folks. > > David Lang > > > I would deeply appreciate if you could forward this to anyone who > could > > be willing to contribute. > > > > Thanks, > > Rainer > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From Luis.Fernando.Munoz.Mejias at cern.ch Fri Feb 20 13:38:15 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Fri, 20 Feb 2009 13:38:15 +0100 Subject: [rsyslog] Extracting a subset of matches on regular expressions? Message-ID: <200902201338.15815.Luis.Fernando.Munoz.Mejias@cern.ch> Hi, there. I'm trying to extract some fields from SSH log in messages, and store in separate fields so that I can easily retrieve user names and source IPs. I have such match: Accepted (.*) for (.*) from ([^[:space:]]) where $1 is the authentication method (password, RSA...), $2 is the user name and $3 is the source IP for the connection. My idea is to place a separator for these fields, and making parsing easy. Something like $_$$_$$_$$_$ I know I could use a template, the same regular expression 3 times and extract one field at a time. But I wonder if it's possible to process the RE once, and then extract ($1, $2, $3) and NOT $0 in one go. This would be much faster, and speed matters to me. Thanks. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From rgerhards at hq.adiscon.com Mon Feb 23 11:13:47 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 23 Feb 2009 11:13:47 +0100 Subject: [rsyslog] Anyone with ties into Ubuntu on this list? Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC9B@grfint2.intern.adiscon.com> Hi all, is there anyone with ties into Ubuntu on this list (or knows someone who is)? I just learned that Ubuntu seems to ship a very old version of rsyslog[1]. There is a new and well-mainteined Debian package done by Michael Biebl available. I would like to talk to someone who can help get that into Ubuntu (interestingly, Ubuntu this time has way older software than Debian, if that is motivation ;)). Thanks, Rainer [1] http://kb.monitorware.com/install-latest-rsyslog-from-deb-src-on-ubuntu- mbiebl-t8931.html From martinmie at PartyGaming.com Mon Feb 23 16:49:22 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Mon, 23 Feb 2009 16:49:22 +0100 Subject: [rsyslog] rsyslog and load balancers Message-ID: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> Hi all, I've read the docs on rsyslog but everything is related to one server and n-clients sending their logs to it... What if I create at least 2 rsyslog servers and put them behind a load-balancer (on only the virtual IP would be known to the clients)? how to proceed with the TLS certificates for both server and clients? Tips and tricks much appreciated. Cheers, Martin This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From aoz.syn at gmail.com Mon Feb 23 17:12:35 2009 From: aoz.syn at gmail.com (RB) Date: Mon, 23 Feb 2009 09:12:35 -0700 Subject: [rsyslog] rsyslog and load balancers In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> Message-ID: <4255c2570902230812x6f83a2e0m603a153d5460e79@mail.gmail.com> On Mon, Feb 23, 2009 at 08:49, Martin Mielke wrote: > What if I create at least 2 rsyslog servers and put them behind a > load-balancer (on only the virtual IP would be known to the clients)? > how to proceed with the TLS certificates for both server and clients? Although it depends on how you configure your load balancer, it should generally be the same method as a TCP-balanced HTTPS cluster: all server members get the same cert issued for the balanced IP. You'll need to make sure that all packets for a given client session are directed to the same server. Client certs shouldn't be any different than normal. If you plan on using anything other than the client's cert (source IP, hostname, etc.) for identification, filtering, or otherwise, you'll need to route the connections through the LB as opposed to proxying them. From rgerhards at hq.adiscon.com Mon Feb 23 17:44:58 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 23 Feb 2009 17:44:58 +0100 Subject: [rsyslog] rsyslog and load balancers In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCB6@grfint2.intern.adiscon.com> I couldn't stand this ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Monday, February 23, 2009 4:49 PM > To: rsyslog-users > Subject: [rsyslog] rsyslog and load balancers > > > Hi all, > > I've read the docs on rsyslog but everything is related to one server > and n-clients sending their logs to it... > What if I create at least 2 rsyslog servers and put them behind a > load-balancer (on only the virtual IP would be known to the clients)? > how to proceed with the TLS certificates for both server and clients? > > Tips and tricks much appreciated. > > Cheers, > Martin > > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. This conflicts with the list policy ;) Also, there is no way we can delete any copies in the various mail archives that cache this list. Quite seriously, you should forward that as a question to your legal folks (those that make you use such disclaimers ;)). Rainer > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Feb 23 17:43:26 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 23 Feb 2009 17:43:26 +0100 Subject: [rsyslog] rsyslog and load balancers In-Reply-To: <4255c2570902230812x6f83a2e0m603a153d5460e79@mail.gmail.com> References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> <4255c2570902230812x6f83a2e0m603a153d5460e79@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCB5@grfint2.intern.adiscon.com> I agree to RB here, but I - due to lack of environment - I am not able to verify it. So a success report and some doc when you are done would be very much appreciated. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of RB > Sent: Monday, February 23, 2009 5:13 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog and load balancers > > On Mon, Feb 23, 2009 at 08:49, Martin Mielke > wrote: > > What if I create at least 2 rsyslog servers and put them behind a > > load-balancer (on only the virtual IP would be known to the clients)? > > how to proceed with the TLS certificates for both server and clients? > > Although it depends on how you configure your load balancer, it should > generally be the same method as a TCP-balanced HTTPS cluster: all > server members get the same cert issued for the balanced IP. You'll > need to make sure that all packets for a given client session are > directed to the same server. Client certs shouldn't be any different > than normal. > > If you plan on using anything other than the client's cert (source IP, > hostname, etc.) for identification, filtering, or otherwise, you'll > need to route the connections through the LB as opposed to proxying > them. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From bakers at web-ster.com Mon Feb 23 19:01:04 2009 From: bakers at web-ster.com (Scott Baker) Date: Mon, 23 Feb 2009 10:01:04 -0800 Subject: [rsyslog] Matching hostname and facility? Message-ID: <49A2E460.50604@web-ster.com> I have an rsyslog.conf entry like this to send everything from my DHCP server to it's own log file on my central rsyslog server. # DHCP logs :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp Is there a way to specify hostname AND a syslog facility? It'd be nice if I could match that host, and local6.* or something like that. Is that possible? - Scott From hks.private at gmail.com Mon Feb 23 23:56:15 2009 From: hks.private at gmail.com ((private) HKS) Date: Mon, 23 Feb 2009 17:56:15 -0500 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: <49A2E460.50604@web-ster.com> References: <49A2E460.50604@web-ster.com> Message-ID: On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker wrote: > I have an rsyslog.conf entry like this to send everything from my DHCP > server to it's own log file on my central rsyslog server. > > # DHCP logs > :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp > > Is there a way to specify hostname AND a syslog facility? It'd be nice if I > could match that host, and local6.* or something like that. Is that possible? > > - Scott > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > #DHCP logs if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == 'local6' then -?dhcp -HKS From david at lang.hm Tue Feb 24 02:11:03 2009 From: david at lang.hm (david at lang.hm) Date: Mon, 23 Feb 2009 17:11:03 -0800 (PST) Subject: [rsyslog] UDP source forging. Message-ID: I have a need to use some products that are stupid enough to ignore the host field in the syslog message and instead base everything on the IP address the message originates from. some other syslog servers can handle this by forging the source of the UDP packet, can rsyslog do this? one way that I know to do this is to issue a bind command to set the source IP, send the packet, then close the 'connection' (with the kernel set to allow non-local-binds), I've hacked sysklogd to do this sort of thing in the past. another way is to send out raw packets (which I believe requires root access). I suspect that this would require more drastic changes to support, but may have slightly higher performance. David Lang From aoz.syn at gmail.com Tue Feb 24 04:29:25 2009 From: aoz.syn at gmail.com (RB) Date: Mon, 23 Feb 2009 20:29:25 -0700 Subject: [rsyslog] UDP source forging. In-Reply-To: References: Message-ID: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> On Mon, Feb 23, 2009 at 18:11, wrote: > I have a need to use some products that are stupid enough to ignore the > host field in the syslog message and instead base everything on the IP > address the message originates from. > > some other syslog servers can handle this by forging the source of the UDP > packet, can rsyslog do this? So is rsyslog originating the messages, or are you using it to aggregate them and then feed them on to the other [bad] acceptors? I am unaware of a way to get rsyslog to forge packets (short of writing an output module), but unless you must get another syslog daemon into the mix, you may be better off just feeding your messages directly to the other collector. From david at lang.hm Tue Feb 24 04:40:25 2009 From: david at lang.hm (david at lang.hm) Date: Mon, 23 Feb 2009 19:40:25 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> Message-ID: On Mon, 23 Feb 2009, RB wrote: > On Mon, Feb 23, 2009 at 18:11, wrote: >> I have a need to use some products that are stupid enough to ignore the >> host field in the syslog message and instead base everything on the IP >> address the message originates from. >> >> some other syslog servers can handle this by forging the source of the UDP >> packet, can rsyslog do this? > > So is rsyslog originating the messages, or are you using it to > aggregate them and then feed them on to the other [bad] acceptors? I > am unaware of a way to get rsyslog to forge packets (short of writing > an output module), but unless you must get another syslog daemon into > the mix, you may be better off just feeding your messages directly to > the other collector. rsyslog would be the relay from one non-routed network to another non-routed network. this could be a fairly simple change to the UDP output module (adding a couple commands around the sending of a message), but before I dove in to do that I wanted to see if I had missed this feature anywhere. David Lang From rgerhards at hq.adiscon.com Tue Feb 24 08:43:49 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 08:43:49 +0100 Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> Hi David et all, Currently rsyslog does not support this and I have to admit I was always very hesitant to add it (I see potential for misuse). Co-incidentally, I received a similar request and was about to relay it to the mailing list to gather feedback. As it looks, this no longer is necessary ;) When I thought about implementation, I originally thought about raw sockets (which indeed require root access), but if there is any other way, I would be most interested. If you can provide some code, I will happily integrate it. I think an addition to the omfwd module, in udp forwarding, together with a new directive ($SpoofOriginalUDPAddress or so...) would be the right way to go. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, February 24, 2009 4:40 AM > To: rsyslog-users > Subject: Re: [rsyslog] UDP source forging. > > On Mon, 23 Feb 2009, RB wrote: > > > On Mon, Feb 23, 2009 at 18:11, wrote: > >> I have a need to use some products that are stupid enough > to ignore the > >> host field in the syslog message and instead base > everything on the IP > >> address the message originates from. > >> > >> some other syslog servers can handle this by forging the > source of the UDP > >> packet, can rsyslog do this? > > > > So is rsyslog originating the messages, or are you using it to > > aggregate them and then feed them on to the other [bad] > acceptors? I > > am unaware of a way to get rsyslog to forge packets (short > of writing > > an output module), but unless you must get another syslog > daemon into > > the mix, you may be better off just feeding your messages > directly to > > the other collector. > > rsyslog would be the relay from one non-routed network to another > non-routed network. > > this could be a fairly simple change to the UDP output module > (adding a > couple commands around the sending of a message), but before > I dove in to > do that I wanted to see if I had missed this feature anywhere. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Tue Feb 24 09:43:17 2009 From: david at lang.hm (david at lang.hm) Date: Tue, 24 Feb 2009 00:43:17 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> Message-ID: On Tue, 24 Feb 2009, Rainer Gerhards wrote: > Hi David et all, > > Currently rsyslog does not support this and I have to admit I was always > very hesitant to add it (I see potential for misuse). Co-incidentally, I > received a similar request and was about to relay it to the mailing list > to gather feedback. As it looks, this no longer is necessary ;) > > When I thought about implementation, I originally thought about raw > sockets (which indeed require root access), but if there is any other > way, I would be most interested. If you can provide some code, I will > happily integrate it. I think an addition to the omfwd module, in udp > forwarding, together with a new directive ($SpoofOriginalUDPAddress or > so...) would be the right way to go. I'll see about hacking in some example code (probably without any config option and not thread-safe) and send it to you. there's another similar change in the same area that I was looking at, I'll mock it up as well. David Lang > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com >> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Tuesday, February 24, 2009 4:40 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] UDP source forging. >> >> On Mon, 23 Feb 2009, RB wrote: >> >>> On Mon, Feb 23, 2009 at 18:11, wrote: >>>> I have a need to use some products that are stupid enough >> to ignore the >>>> host field in the syslog message and instead base >> everything on the IP >>>> address the message originates from. >>>> >>>> some other syslog servers can handle this by forging the >> source of the UDP >>>> packet, can rsyslog do this? >>> >>> So is rsyslog originating the messages, or are you using it to >>> aggregate them and then feed them on to the other [bad] >> acceptors? I >>> am unaware of a way to get rsyslog to forge packets (short >> of writing >>> an output module), but unless you must get another syslog >> daemon into >>> the mix, you may be better off just feeding your messages >> directly to >>> the other collector. >> >> rsyslog would be the relay from one non-routed network to another >> non-routed network. >> >> this could be a fairly simple change to the UDP output module >> (adding a >> couple commands around the sending of a message), but before >> I dove in to >> do that I wanted to see if I had missed this feature anywhere. >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Feb 24 09:44:24 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 09:44:24 +0100 Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> David, Excellent, please do as you have time. I'll make sure it fits. Thread-safety, btw., is not a big issue at this level as the output modules are guaranteed to be never called by multiple threads concurrently. That was a trade-off to enable other folks to easily write them (but I have an option in the back of my head that a module can tell the engine it *is* capable to run on multiple threads concurrently...). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, February 24, 2009 9:43 AM > To: rsyslog-users > Subject: Re: [rsyslog] UDP source forging. > > On Tue, 24 Feb 2009, Rainer Gerhards wrote: > > > Hi David et all, > > > > Currently rsyslog does not support this and I have to admit I was > always > > very hesitant to add it (I see potential for misuse). Co- > incidentally, I > > received a similar request and was about to relay it to the mailing > list > > to gather feedback. As it looks, this no longer is necessary ;) > > > > When I thought about implementation, I originally thought about raw > > sockets (which indeed require root access), but if there is any other > > way, I would be most interested. If you can provide some code, I will > > happily integrate it. I think an addition to the omfwd module, in udp > > forwarding, together with a new directive ($SpoofOriginalUDPAddress > or > > so...) would be the right way to go. > > I'll see about hacking in some example code (probably without any > config > option and not thread-safe) and send it to you. > > there's another similar change in the same area that I was looking at, > I'll mock it up as well. > > David Lang > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com > >> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of > david at lang.hm > >> Sent: Tuesday, February 24, 2009 4:40 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] UDP source forging. > >> > >> On Mon, 23 Feb 2009, RB wrote: > >> > >>> On Mon, Feb 23, 2009 at 18:11, wrote: > >>>> I have a need to use some products that are stupid enough > >> to ignore the > >>>> host field in the syslog message and instead base > >> everything on the IP > >>>> address the message originates from. > >>>> > >>>> some other syslog servers can handle this by forging the > >> source of the UDP > >>>> packet, can rsyslog do this? > >>> > >>> So is rsyslog originating the messages, or are you using it to > >>> aggregate them and then feed them on to the other [bad] > >> acceptors? I > >>> am unaware of a way to get rsyslog to forge packets (short > >> of writing > >>> an output module), but unless you must get another syslog > >> daemon into > >>> the mix, you may be better off just feeding your messages > >> directly to > >>> the other collector. > >> > >> rsyslog would be the relay from one non-routed network to another > >> non-routed network. > >> > >> this could be a fairly simple change to the UDP output module > >> (adding a > >> couple commands around the sending of a message), but before > >> I dove in to > >> do that I wanted to see if I had missed this feature anywhere. > >> > >> David Lang > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > >> > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From martinmie at PartyGaming.com Tue Feb 24 15:47:30 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Tue, 24 Feb 2009 15:47:30 +0100 Subject: [rsyslog] Not logging TCP connections? Message-ID: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> Hi, Sorry to sound a bit blonde here but... I need rsyslog to accept both TCP and UDP connections to port 514. I have the following relevant parts on the server side: -- ... $DefaultNetstreamDriver ptcp # UDP Syslog Server: $UDPServerRun 514 # start a UDP syslog server at standard port 514 $InputTCPServerStreamDriverAuthMode anon $InputTCPServerStreamDriverPermittedPeer *.mydomain $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode $InputTCPServerRun 514 ... -- ...also disabled all the certificates/keys files just in case And on the client side> -- # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional *.* @logserver.mydomain -- After restarting rsyslog on the server it only logs UDP traffic... Am I overseeing something the obvious? Regards, Martin This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From rgerhards at hq.adiscon.com Tue Feb 24 15:53:13 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 15:53:13 +0100 Subject: [rsyslog] Not logging TCP connections? In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> Martin, on the client @ is udp while @@ is TCP (!) ;) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Tuesday, February 24, 2009 3:48 PM > To: rsyslog-users > Subject: [rsyslog] Not logging TCP connections? > > Hi, > > Sorry to sound a bit blonde here but... > I need rsyslog to accept both TCP and UDP connections to port 514. > > I have the following relevant parts on the server side: > -- > ... > $DefaultNetstreamDriver ptcp > > # UDP Syslog Server: > $UDPServerRun 514 # start a UDP syslog server at standard port 514 > > > $InputTCPServerStreamDriverAuthMode anon > $InputTCPServerStreamDriverPermittedPeer *.mydomain > $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode > $InputTCPServerRun 514 > ... > -- > > ...also disabled all the certificates/keys files just in case > > > And on the client side> > -- > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional > *.* @logserver.mydomain > -- > > After restarting rsyslog on the server it only logs UDP traffic... > > Am I overseeing something the obvious? > > > Regards, > Martin > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From martinmie at PartyGaming.com Tue Feb 24 16:31:52 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Tue, 24 Feb 2009 16:31:52 +0100 Subject: [rsyslog] Not logging TCP connections? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> References: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> <577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> Message-ID: <0B1B9163138571439EAF804646F3F6AA06B9D148@GIBSVWIN004X.partygaming.local> Yes, sorry. Copy & paste worked bad. I just removed some unnecessary lines and re-ordered some directives. Now it works. Sorry for the noise. Martin > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: 24 February 2009 15:53 > To: rsyslog-users > Subject: Re: [rsyslog] Not logging TCP connections? > > Martin, on the client @ is udp while @@ is TCP (!) ;) > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > > Sent: Tuesday, February 24, 2009 3:48 PM > > To: rsyslog-users > > Subject: [rsyslog] Not logging TCP connections? > > > > Hi, > > > > Sorry to sound a bit blonde here but... > > I need rsyslog to accept both TCP and UDP connections to port 514. > > > > I have the following relevant parts on the server side: > > -- > > ... > > $DefaultNetstreamDriver ptcp > > > > # UDP Syslog Server: > > $UDPServerRun 514 # start a UDP syslog server at standard port 514 > > > > > > $InputTCPServerStreamDriverAuthMode anon > > $InputTCPServerStreamDriverPermittedPeer *.mydomain > > $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode > > $InputTCPServerRun 514 > > ... > > -- > > > > ...also disabled all the certificates/keys files just in case > > > > > > And on the client side> > > -- > > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional > > *.* @logserver.mydomain > > -- > > > > After restarting rsyslog on the server it only logs UDP traffic... > > > > Am I overseeing something the obvious? > > > > > > Regards, > > Martin > > > > > > This email and any attachments are confidential, and may be legally > > privileged and protected by copyright. If you are not the intended > > recipient dissemination or copying of this email is prohibited. If you > > have received this in error, please notify the sender by replying by > > email and then delete the email completely from your system. > > > > Any views or opinions are solely those of the sender. This > > communication is not intended to form a binding contract unless > > expressly indicated to the contrary and properly authorised. Any > > actions taken on the basis of this email are at the recipient's own > > risk. > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Feb 24 16:51:42 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 16:51:42 +0100 Subject: [rsyslog] Not logging TCP connections? In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06B9D148@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local><577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> <0B1B9163138571439EAF804646F3F6AA06B9D148@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCDC@grfint2.intern.adiscon.com> No problem at all ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Tuesday, February 24, 2009 4:32 PM > To: rsyslog-users > Subject: Re: [rsyslog] Not logging TCP connections? > > Yes, sorry. Copy & paste worked bad. > > I just removed some unnecessary lines and re-ordered some directives. > Now it works. > > Sorry for the noise. > > > Martin > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: 24 February 2009 15:53 > > To: rsyslog-users > > Subject: Re: [rsyslog] Not logging TCP connections? > > > > Martin, on the client @ is udp while @@ is TCP (!) ;) > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > > > Sent: Tuesday, February 24, 2009 3:48 PM > > > To: rsyslog-users > > > Subject: [rsyslog] Not logging TCP connections? > > > > > > Hi, > > > > > > Sorry to sound a bit blonde here but... > > > I need rsyslog to accept both TCP and UDP connections to port 514. > > > > > > I have the following relevant parts on the server side: > > > -- > > > ... > > > $DefaultNetstreamDriver ptcp > > > > > > # UDP Syslog Server: > > > $UDPServerRun 514 # start a UDP syslog server at standard port 514 > > > > > > > > > $InputTCPServerStreamDriverAuthMode anon > > > $InputTCPServerStreamDriverPermittedPeer *.mydomain > > > $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode > > > $InputTCPServerRun 514 > > > ... > > > -- > > > > > > ...also disabled all the certificates/keys files just in case > > > > > > > > > And on the client side> > > > -- > > > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional > > > *.* @logserver.mydomain > > > -- > > > > > > After restarting rsyslog on the server it only logs UDP traffic... > > > > > > Am I overseeing something the obvious? > > > > > > > > > Regards, > > > Martin > > > > > > > > > This email and any attachments are confidential, and may be legally > > > privileged and protected by copyright. If you are not the intended > > > recipient dissemination or copying of this email is prohibited. If > you > > > have received this in error, please notify the sender by replying > by > > > email and then delete the email completely from your system. > > > > > > Any views or opinions are solely those of the sender. This > > > communication is not intended to form a binding contract unless > > > expressly indicated to the contrary and properly authorised. Any > > > actions taken on the basis of this email are at the recipient's own > > > risk. > > > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From bakers at web-ster.com Wed Feb 25 21:08:01 2009 From: bakers at web-ster.com (Scott Baker) Date: Wed, 25 Feb 2009 12:08:01 -0800 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: References: <49A2E460.50604@web-ster.com> Message-ID: <49A5A521.8040107@web-ster.com> On 02/23/2009 02:56 PM, (private) HKS wrote: > On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker wrote: >> I have an rsyslog.conf entry like this to send everything from my DHCP >> server to it's own log file on my central rsyslog server. >> >> # DHCP logs >> :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp >> >> Is there a way to specify hostname AND a syslog facility? It'd be nice if I >> could match that host, and local6.* or something like that. Is that possible? >> >> - Scott >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > > > #DHCP logs > if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == > 'local6' then -?dhcp Does this syntax work on rsyslog 2.0.x, that's what my server has on it. I've tried this syntax, but it's not logging. - Scott From david at lang.hm Wed Feb 25 21:47:20 2009 From: david at lang.hm (david at lang.hm) Date: Wed, 25 Feb 2009 12:47:20 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> Message-ID: figuring out how to do this is navigating a twisty maze of helper functions, all different ;-) there are a few things that look odd here if I am reading the code properly. rsyslog makes one call to the UDPSend routine for all forwarded messages, this means that they must all send the same format. the UDPSend routine then walks through all destinations attempting to send the message to them. and considers the message successfully sent if any of them can be sent. I would have expected that it would only be considered successful if all of them succeded. UDPSend attempts to use the sockets that were created to listening for messages to send it's message out. in a multi-homed machine the local IP address of those sockets may not be appropriate for the relay. also, what would happen if a system recieves via TCP and forwards via UDP and so doesn't have any UDP listener sockets. so now, my suggestion On Linux in /etc/sysctl.conf add the line net.ipv4.ip_nonlocal_bind=1 this tells the kernel not to fail bind requests to IP addresses that don't exist on the box then in omfwd.c in the routine that calls UDPSend, modify it to pass the source IP address of the message to UDPSend create a new filehandle array to use for outbound messages (one filehandle for each destination since they may end up with different source IPs) in UDPSend three options. 1. default use the appropriate filehandle for each destination and send the message. this is similar to what currently takes place, but instead of walking through each open socket for each destination, there should only be one sendto per destination. when opening the socket it should not be nessasary to do a bind, just issue the socket call. if there is anything in the syslog standard specifying the source port (I don't think there is, although many implementations use port 514 becouse they do the same thing that rsyslog is doing and re-use listening sockets to send messages) 2. randomize source ports to support external load balancers same as default, except that every X (configurable) messages close and re-open the sockets. the reason for this is that each time a message is first sent the OS picks a random source port that will be used for all messages sent through that socket. by closing the socket once in a while, load balancers that balance based on source IP + source port + destination IP + destination port will be able to function (a similar feature for TCP based transports would be useful for the same reason) 3. forge the source IP/port for each message that is sent, open a new socket, then issue a 'bind' command for that socket (filehandle) that sets the local IP address to the IP address that the message initially came from, then issue the sendto, then close the filehandle. there is no need for an array of sockets in this case as the socket needs to be re-opened for each message/destination. in theory there is a possibility of a performance gain by keeping sockets open and re-using them, but since each socket is unique to the sender + destination there would be a large number of sockets and a low probability of re-using a socket for the next message. in sysklogd I implemented #2 with the simple code below (once I created a different filehandle to use for outbound connections) this closed and re-opened the socket for each message, doing it every X messages would save on the overhead and be just as good in practice. the bind command that's commented out is basicly what would be needed for #3, but with real values for the source.sin_addr.s_addr (and source.sin_port if you wanted to forge the port as well, leaving it zero lets the OS pick a port number) if (finet >0) { /* close and re-open the outbound socket after each message so that the source port is randomized and load balancers can distribute the messages */ close(finet); finet = create_inet_socket(); /* if we want to forge the source IP for the outbound packets, this is the place to do it by seeting the IP address to the address we received the message from struct sockaddr_in source; source.sin_addr.s_addr = 0x00000000; source.sin_port = 0x0000; bind(finet,(struct sockaddr *) &source,sizeof(source));*/ } the create_inet_socket() routine is: static int create_inet_socket() { int fd, on = 1; int sockflags; fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { logerror("syslog: Unknown protocol, suspending inet service."); return fd; } if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, \ (char *) &on, sizeof(on)) < 0 ) { logerror("setsockopt(REUSEADDR), suspending inet"); close(fd); return -1; } /* We must not block on the network socket, in case a packet * gets lost between select and recv, otherise the process * will stall until the timeout, and other processes trying to * log will also stall. */ if ((sockflags = fcntl(fd, F_GETFL)) != -1) { sockflags |= O_NONBLOCK; /* * SETFL could fail too, so get it caught by the subsequent * error check. */ sockflags = fcntl(fd, F_SETFL, sockflags); } if (sockflags == -1) { logerror("fcntl(O_NONBLOCK), suspending inet"); close(fd); return -1; } return fd; } this isn't a patch like you asked for and I offered to put togeather, but is it enough to clearly explain this? if not I can continue to work on the patch. David Lang On Tue, 24 Feb 2009, Rainer Gerhards wrote: > David, > > Excellent, please do as you have time. I'll make sure it fits. > Thread-safety, btw., is not a big issue at this level as the output > modules are guaranteed to be never called by multiple threads > concurrently. That was a trade-off to enable other folks to easily write > them (but I have an option in the back of my head that a module can tell > the engine it *is* capable to run on multiple threads concurrently...). > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Tuesday, February 24, 2009 9:43 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] UDP source forging. >> >> On Tue, 24 Feb 2009, Rainer Gerhards wrote: >> >>> Hi David et all, >>> >>> Currently rsyslog does not support this and I have to admit I was >> always >>> very hesitant to add it (I see potential for misuse). Co- >> incidentally, I >>> received a similar request and was about to relay it to the mailing >> list >>> to gather feedback. As it looks, this no longer is necessary ;) >>> >>> When I thought about implementation, I originally thought about raw >>> sockets (which indeed require root access), but if there is any > other >>> way, I would be most interested. If you can provide some code, I > will >>> happily integrate it. I think an addition to the omfwd module, in > udp >>> forwarding, together with a new directive ($SpoofOriginalUDPAddress >> or >>> so...) would be the right way to go. >> >> I'll see about hacking in some example code (probably without any >> config >> option and not thread-safe) and send it to you. >> >> there's another similar change in the same area that I was looking at, >> I'll mock it up as well. >> >> David Lang >> >>> Rainer >>> >>>> -----Original Message----- >>>> From: rsyslog-bounces at lists.adiscon.com >>>> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of >> david at lang.hm >>>> Sent: Tuesday, February 24, 2009 4:40 AM >>>> To: rsyslog-users >>>> Subject: Re: [rsyslog] UDP source forging. >>>> >>>> On Mon, 23 Feb 2009, RB wrote: >>>> >>>>> On Mon, Feb 23, 2009 at 18:11, wrote: >>>>>> I have a need to use some products that are stupid enough >>>> to ignore the >>>>>> host field in the syslog message and instead base >>>> everything on the IP >>>>>> address the message originates from. >>>>>> >>>>>> some other syslog servers can handle this by forging the >>>> source of the UDP >>>>>> packet, can rsyslog do this? >>>>> >>>>> So is rsyslog originating the messages, or are you using it to >>>>> aggregate them and then feed them on to the other [bad] >>>> acceptors? I >>>>> am unaware of a way to get rsyslog to forge packets (short >>>> of writing >>>>> an output module), but unless you must get another syslog >>>> daemon into >>>>> the mix, you may be better off just feeding your messages >>>> directly to >>>>> the other collector. >>>> >>>> rsyslog would be the relay from one non-routed network to another >>>> non-routed network. >>>> >>>> this could be a fairly simple change to the UDP output module >>>> (adding a >>>> couple commands around the sending of a message), but before >>>> I dove in to >>>> do that I wanted to see if I had missed this feature anywhere. >>>> >>>> David Lang >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com >>>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From hks.private at gmail.com Thu Feb 26 00:38:32 2009 From: hks.private at gmail.com ((private) HKS) Date: Wed, 25 Feb 2009 18:38:32 -0500 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: <49A5A521.8040107@web-ster.com> References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> Message-ID: On Wed, Feb 25, 2009 at 3:08 PM, Scott Baker wrote: > On 02/23/2009 02:56 PM, (private) HKS wrote: >> On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker ?wrote: >>> I have an rsyslog.conf entry like this to send everything from my DHCP >>> server to it's own log file on my central rsyslog server. >>> >>> # DHCP logs >>> :FROMHOST, isequal, "dhcp-server.domain.com" ? ? ? ? ? ? -?dhcp >>> >>> Is there a way to specify hostname AND a syslog facility? It'd be nice if I >>> could match that host, and local6.* or something like that. Is that possible? >>> >>> - Scott >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> >> >> #DHCP logs >> if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == >> 'local6' then -?dhcp > > Does this syntax work on rsyslog 2.0.x, that's what my server has on it. > I've tried this syntax, but it's not logging. > > - Scott No, this will require 3+ - which you really should upgrade to anyway. -HKS From rgerhards at hq.adiscon.com Thu Feb 26 14:34:05 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 14:34:05 +0100 Subject: [rsyslog] UDP source forging. References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> Hi David, I think you got lost in the callbacks. The multiple send calls are not for multiple actions. This is all for one action. That code was contributed as part of the IPv6 port. I verified the implementation with what I could find as references to sending on IPv6 and think the implementation uses proper procedures for that environment. In essence, on an IPv6-enabled system, you will receive multiple sockets that you potentially can use to send the message. What the code does is iterate over these sockets and see which one really works. There is also an option (not checked but pretty sure) that permits sending to all receivers. I think that was the other situation you have seen. The listen socket is NOT being reused for sending. RFC3164 actually recommends that port 514 is used as the source port, and we had a lengthy discussion at the IETF about this recommendation. The bottom line is that you cannot reuse the receive socket on a highly parallel syslogd because each thread needs its own (or you have even more sync). Rsyslog creates a new (set of) send sockets *per action*. I guess part of the confusion stems back from your understanding of sysklogd code. Sysklogd works totally different here. I hope this clarifies a bit. I will try to have a look at the code provided asap and see what I can do. Its unfortunately still very busy, so I can not commit when I will finally start. HTH Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Wednesday, February 25, 2009 9:47 PM > To: rsyslog-users > Subject: Re: [rsyslog] UDP source forging. > > figuring out how to do this is navigating a twisty maze of helper > functions, all different ;-) > > there are a few things that look odd here if I am reading the code > properly. > > rsyslog makes one call to the UDPSend routine for all forwarded > messages, > this means that they must all send the same format. > > the UDPSend routine then walks through all destinations attempting to > send > the message to them. and considers the message successfully sent if any > of > them can be sent. I would have expected that it would only be > considered > successful if all of them succeded. > > UDPSend attempts to use the sockets that were created to listening for > messages to send it's message out. in a multi-homed machine the local > IP > address of those sockets may not be appropriate for the relay. also, > what > would happen if a system recieves via TCP and forwards via UDP and so > doesn't have any UDP listener sockets. > > > so now, my suggestion > > On Linux in /etc/sysctl.conf add the line > > net.ipv4.ip_nonlocal_bind=1 > > this tells the kernel not to fail bind requests to IP addresses that > don't > exist on the box > > then in omfwd.c > > in the routine that calls UDPSend, modify it to pass the source IP > address > of the message to UDPSend > > create a new filehandle array to use for outbound messages (one > filehandle > for each destination since they may end up with different source IPs) > > > in UDPSend > > three options. > > > 1. default > > use the appropriate filehandle for each destination and send the > message. this is similar to what currently takes place, but instead of > walking through each open socket for each destination, there should > only > be one sendto per destination. when opening the socket it should not be > nessasary to do a bind, just issue the socket call. > > if there is anything in the syslog standard specifying the source > port > (I don't think there is, although many implementations use port 514 > becouse they do the same thing that rsyslog is doing and re-use > listening > sockets to send messages) > > > 2. randomize source ports to support external load balancers > > same as default, except that every X (configurable) messages close > and > re-open the sockets. > > the reason for this is that each time a message is first sent the OS > picks a random source port that will be used for all messages sent > through > that socket. by closing the socket once in a while, load balancers that > balance based on source IP + source port + destination IP + destination > port will be able to function (a similar feature for TCP based > transports > would be useful for the same reason) > > > 3. forge the source IP/port > > for each message that is sent, open a new socket, then issue a > 'bind' > command for that socket (filehandle) that sets the local IP address to > the > IP address that the message initially came from, then issue the sendto, > then close the filehandle. > > there is no need for an array of sockets in this case as the socket > needs to be re-opened for each message/destination. in theory there is > a > possibility of a performance gain by keeping sockets open and re-using > them, but since each socket is unique to the sender + destination there > would be a large number of sockets and a low probability of re-using a > socket for the next message. > > in sysklogd I implemented #2 with the simple code below (once I created > a > different filehandle to use for outbound connections) > > this closed and re-opened the socket for each message, doing it every X > messages would save on the overhead and be just as good in practice. > > the bind command that's commented out is basicly what would be needed > for > #3, but with real values for the source.sin_addr.s_addr (and > source.sin_port if you wanted to forge the port as well, leaving it > zero > lets the OS pick a port number) > > if (finet >0) { > /* close and re-open the outbound socket after each message so > that the source port is randomized and load balancers can distribute > the messages */ > close(finet); > finet = create_inet_socket(); > /* if we want to forge the source IP for the outbound packets, > this is the place to do it by seeting the IP address to the address we > received the message from > struct sockaddr_in source; > source.sin_addr.s_addr = 0x00000000; > source.sin_port = 0x0000; > bind(finet,(struct sockaddr *) > &source,sizeof(source));*/ > } > > > the create_inet_socket() routine is: > > static int create_inet_socket() > { > int fd, on = 1; > int sockflags; > > fd = socket(AF_INET, SOCK_DGRAM, 0); > if (fd < 0) { > logerror("syslog: Unknown protocol, suspending inet > service."); > return fd; > } > > if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, \ > (char *) &on, sizeof(on)) < 0 ) { > logerror("setsockopt(REUSEADDR), suspending inet"); > close(fd); > return -1; > } > /* We must not block on the network socket, in case a packet > * gets lost between select and recv, otherise the process > * will stall until the timeout, and other processes trying to > * log will also stall. > */ > if ((sockflags = fcntl(fd, F_GETFL)) != -1) { > sockflags |= O_NONBLOCK; > /* > * SETFL could fail too, so get it caught by the > subsequent > * error check. > */ > sockflags = fcntl(fd, F_SETFL, sockflags); > } > if (sockflags == -1) { > logerror("fcntl(O_NONBLOCK), suspending inet"); > close(fd); > return -1; > } > return fd; > } > > > this isn't a patch like you asked for and I offered to put togeather, > but > is it enough to clearly explain this? if not I can continue to work on > the > patch. > > David Lang > > On Tue, 24 Feb 2009, Rainer Gerhards wrote: > > > David, > > > > Excellent, please do as you have time. I'll make sure it fits. > > Thread-safety, btw., is not a big issue at this level as the output > > modules are guaranteed to be never called by multiple threads > > concurrently. That was a trade-off to enable other folks to easily > write > > them (but I have an option in the back of my head that a module can > tell > > the engine it *is* capable to run on multiple threads > concurrently...). > > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm > >> Sent: Tuesday, February 24, 2009 9:43 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] UDP source forging. > >> > >> On Tue, 24 Feb 2009, Rainer Gerhards wrote: > >> > >>> Hi David et all, > >>> > >>> Currently rsyslog does not support this and I have to admit I was > >> always > >>> very hesitant to add it (I see potential for misuse). Co- > >> incidentally, I > >>> received a similar request and was about to relay it to the mailing > >> list > >>> to gather feedback. As it looks, this no longer is necessary ;) > >>> > >>> When I thought about implementation, I originally thought about raw > >>> sockets (which indeed require root access), but if there is any > > other > >>> way, I would be most interested. If you can provide some code, I > > will > >>> happily integrate it. I think an addition to the omfwd module, in > > udp > >>> forwarding, together with a new directive ($SpoofOriginalUDPAddress > >> or > >>> so...) would be the right way to go. > >> > >> I'll see about hacking in some example code (probably without any > >> config > >> option and not thread-safe) and send it to you. > >> > >> there's another similar change in the same area that I was looking > at, > >> I'll mock it up as well. > >> > >> David Lang > >> > >>> Rainer > >>> > >>>> -----Original Message----- > >>>> From: rsyslog-bounces at lists.adiscon.com > >>>> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of > >> david at lang.hm > >>>> Sent: Tuesday, February 24, 2009 4:40 AM > >>>> To: rsyslog-users > >>>> Subject: Re: [rsyslog] UDP source forging. > >>>> > >>>> On Mon, 23 Feb 2009, RB wrote: > >>>> > >>>>> On Mon, Feb 23, 2009 at 18:11, wrote: > >>>>>> I have a need to use some products that are stupid enough > >>>> to ignore the > >>>>>> host field in the syslog message and instead base > >>>> everything on the IP > >>>>>> address the message originates from. > >>>>>> > >>>>>> some other syslog servers can handle this by forging the > >>>> source of the UDP > >>>>>> packet, can rsyslog do this? > >>>>> > >>>>> So is rsyslog originating the messages, or are you using it to > >>>>> aggregate them and then feed them on to the other [bad] > >>>> acceptors? I > >>>>> am unaware of a way to get rsyslog to forge packets (short > >>>> of writing > >>>>> an output module), but unless you must get another syslog > >>>> daemon into > >>>>> the mix, you may be better off just feeding your messages > >>>> directly to > >>>>> the other collector. > >>>> > >>>> rsyslog would be the relay from one non-routed network to another > >>>> non-routed network. > >>>> > >>>> this could be a fairly simple change to the UDP output module > >>>> (adding a > >>>> couple commands around the sending of a message), but before > >>>> I dove in to > >>>> do that I wanted to see if I had missed this feature anywhere. > >>>> > >>>> David Lang > >>>> _______________________________________________ > >>>> rsyslog mailing list > >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>>> http://www.rsyslog.com > >>>> > >>> _______________________________________________ > >>> rsyslog mailing list > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>> http://www.rsyslog.com > >>> > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Feb 26 14:49:00 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 14:49:00 +0100 Subject: [rsyslog] Matching hostname and facility? References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E8F@GRFEXC.intern.adiscon.com> I have no time to try it out, but I think BSD-style hostblocks should be helpful in this case. Details in doc, something along these lines: !hostname local6.* /path/to/hostname-local6 Hostname is an implicit and condition until the next !hostname is seen. Not sure if in v2 it works with FQDN (don't think so) or just the plain hostname without domain. I think there is also a sample in the wiki or forum. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Scott Baker > Sent: Wednesday, February 25, 2009 9:08 PM > To: rsyslog-users > Subject: Re: [rsyslog] Matching hostname and facility? > > On 02/23/2009 02:56 PM, (private) HKS wrote: > > On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker > wrote: > >> I have an rsyslog.conf entry like this to send everything from my > DHCP > >> server to it's own log file on my central rsyslog server. > >> > >> # DHCP logs > >> :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp > >> > >> Is there a way to specify hostname AND a syslog facility? It'd be > nice if I > >> could match that host, and local6.* or something like that. Is that > possible? > >> > >> - Scott > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > >> > > > > > > #DHCP logs > > if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == > > 'local6' then -?dhcp > > Does this syntax work on rsyslog 2.0.x, that's what my server has on > it. > I've tried this syntax, but it's not logging. > > - Scott > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From aoz.syn at gmail.com Thu Feb 26 16:16:06 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 26 Feb 2009 08:16:06 -0700 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E8F@GRFEXC.intern.adiscon.com> References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> <9B6E2A8877C38245BFB15CC491A11DA71E8F@GRFEXC.intern.adiscon.com> Message-ID: <4255c2570902260716t26815e48wc36cb6be6477b451@mail.gmail.com> On Thu, Feb 26, 2009 at 06:49, Rainer Gerhards wrote: > I have no time to try it out, but I think BSD-style hostblocks should be > helpful in this case. Details in doc, something along these lines: > > !hostname > local6.* /path/to/hostname-local6 FWIW, the hostblock is denoted with '+' and '-', '!' is the program-name prefix. From aoz.syn at gmail.com Thu Feb 26 16:53:34 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 26 Feb 2009 08:53:34 -0700 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> Message-ID: <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> On Tue, Feb 17, 2009 at 13:11, RB wrote: > Regardless, I'll take the flag and see what I can do to get a > readily-accessible reasonably current build available for CentOS-5. Good & bad news - the good news is the Fedora upstream is very responsive, the bad news is I got sidetracked after his response. I have been told that rsyslog cannot be put in EPEL since it is already packaged in RHEL, be that package good or bad. Tomas has offered to help with the SPEC should I have any problems, but it looks like we're on our own for the time being. RPM package distribution can be done to various depths. The simplest is to just provide both the SRPM and unsigned binary RPMs for a few chosen CPU architectures for each packaged release as an HTTP or FTP download. This would allow one-off installations (updates would be manual) and generally get the package 'out there' for use. Further steps would involve signing the binaries and possibly publishing a repo that users could subscribe to (using /etc/yum.* or equivalent) for automated updates. Distributing a binary package in whatever form is going to increase the load (however mildly) on the project - each release will involve compiling and distributing binaries and SRPMs, if not signing them as well. I can work with you [Rainer] to automate that process, but as a random user I should probably not be doing the compilation and signing myself. So, we have 4 basic questions: 1. What versions are desired? 2. Are there any rsyslog components or functionality not packaged in the Fedora distribution users here would like to see included? 3. Do we want to sign the packages? 4. Who will perform the compilation/signing? From rgerhards at hq.adiscon.com Thu Feb 26 17:49:30 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 17:49:30 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com><49993125.2060603@ecker-software.de><4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com><4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Hi RB, thanks for all your hard work. I am absolutely willing to help make succeed in that. Just one question before we do down to details. Are there any other options that we can pursue? I remember, quite some time ago, that someone posted the idea that some well-known (non-RH, not EPEL) repositories exist. Unfortunatley, I do no longer know which these were. So the question is: are there any other such repositories where RHEL users turn to and, if so, can we work with them to achieve our joint goals? Sorry for some backtracking here... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of RB > Sent: Thursday, February 26, 2009 4:54 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > On Tue, Feb 17, 2009 at 13:11, RB wrote: > > Regardless, I'll take the flag and see what I can do to get a > > readily-accessible reasonably current build available for CentOS-5. > > Good & bad news - the good news is the Fedora upstream is very > responsive, the bad news is I got sidetracked after his response. > > I have been told that rsyslog cannot be put in EPEL since it is > already packaged in RHEL, be that package good or bad. Tomas has > offered to help with the SPEC should I have any problems, but it looks > like we're on our own for the time being. > > RPM package distribution can be done to various depths. The simplest > is to just provide both the SRPM and unsigned binary RPMs for a few > chosen CPU architectures for each packaged release as an HTTP or FTP > download. This would allow one-off installations (updates would be > manual) and generally get the package 'out there' for use. Further > steps would involve signing the binaries and possibly publishing a > repo that users could subscribe to (using /etc/yum.* or equivalent) > for automated updates. > > Distributing a binary package in whatever form is going to increase > the load (however mildly) on the project - each release will involve > compiling and distributing binaries and SRPMs, if not signing them as > well. I can work with you [Rainer] to automate that process, but as a > random user I should probably not be doing the compilation and signing > myself. > > So, we have 4 basic questions: > 1. What versions are desired? > 2. Are there any rsyslog components or functionality not packaged in > the Fedora distribution users here would like to see included? > 3. Do we want to sign the packages? > 4. Who will perform the compilation/signing? > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Feb 26 18:05:17 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 09:05:17 -0800 (PST) Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com><49993125.2060603@ecker-software.de><4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com><4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: even where rsyslog is included in a distro it's very handy to have a spec file (or debian equivalent) included with the source to allow a 'make rpm' or 'make deb' to properly make packages. I've been using checkinstall to create debian packages from the compiled source, and I don't know what it's doing wrong, but I've been tripped up a few times by it not replacing all the files that it should if rsyslog is already installed (the packages it creates work just fine if rsyslog isn't installed at all) David Lang On Thu, 26 Feb 2009, Rainer Gerhards wrote: > Hi RB, > > thanks for all your hard work. I am absolutely willing to help make > succeed in that. Just one question before we do down to details. Are > there any other options that we can pursue? I remember, quite some time > ago, that someone posted the idea that some well-known (non-RH, not > EPEL) repositories exist. Unfortunatley, I do no longer know which these > were. > > So the question is: are there any other such repositories where RHEL > users turn to and, if so, can we work with them to achieve our joint > goals? > > Sorry for some backtracking here... > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of RB >> Sent: Thursday, February 26, 2009 4:54 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending >> devices? >> >> On Tue, Feb 17, 2009 at 13:11, RB wrote: >>> Regardless, I'll take the flag and see what I can do to get a >>> readily-accessible reasonably current build available for CentOS-5. >> >> Good & bad news - the good news is the Fedora upstream is very >> responsive, the bad news is I got sidetracked after his response. >> >> I have been told that rsyslog cannot be put in EPEL since it is >> already packaged in RHEL, be that package good or bad. Tomas has >> offered to help with the SPEC should I have any problems, but it looks >> like we're on our own for the time being. >> >> RPM package distribution can be done to various depths. The simplest >> is to just provide both the SRPM and unsigned binary RPMs for a few >> chosen CPU architectures for each packaged release as an HTTP or FTP >> download. This would allow one-off installations (updates would be >> manual) and generally get the package 'out there' for use. Further >> steps would involve signing the binaries and possibly publishing a >> repo that users could subscribe to (using /etc/yum.* or equivalent) >> for automated updates. >> >> Distributing a binary package in whatever form is going to increase >> the load (however mildly) on the project - each release will involve >> compiling and distributing binaries and SRPMs, if not signing them as >> well. I can work with you [Rainer] to automate that process, but as a >> random user I should probably not be doing the compilation and signing >> myself. >> >> So, we have 4 basic questions: >> 1. What versions are desired? >> 2. Are there any rsyslog components or functionality not packaged in >> the Fedora distribution users here would like to see included? >> 3. Do we want to sign the packages? >> 4. Who will perform the compilation/signing? >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Thu Feb 26 18:13:57 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 09:13:57 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 26 Feb 2009, Rainer Gerhards wrote: > Hi David, > > I think you got lost in the callbacks. yep, that's what I meant by the 'twisty maze of helper functions' > The multiple send calls are not for multiple actions. This is all for > one action. That code was contributed as part of the IPv6 port. I > verified the implementation with what I could find as references to > sending on IPv6 and think the implementation uses proper procedures for > that environment. > > In essence, on an IPv6-enabled system, you will receive multiple sockets > that you potentially can use to send the message. What the code does is > iterate over these sockets and see which one really works. There is also > an option (not checked but pretty sure) that permits sending to all > receivers. I think that was the other situation you have seen. this I definantly don't understand. I haven't done much coding in this area, and most of what I have done ends up being cut-n-paste out of the 'linux application programming' book examples (which are supposed to work for IPv6 as well as v4) > The listen socket is NOT being reused for sending. when I chased down the callback functions to find what function created the sockets, the only thing that I found was a routine that looked like it was going through the config options to create sockets for all the listening ports. > RFC3164 actually > recommends that port 514 is used as the source port, and we had a > lengthy discussion at the IETF about this recommendation. The bottom > line is that you cannot reuse the receive socket on a highly parallel > syslogd because each thread needs its own (or you have even more sync). > Rsyslog creates a new (set of) send sockets *per action*. if you don't do a bind on the socket you can't specify the source port. if you do bind on the socket and set the source port to 514 aren't you generating a conflict between the multiple send sockets? > I guess part of the confusion stems back from your understanding of > sysklogd code. Sysklogd works totally different here. probably. > I hope this clarifies a bit. I will try to have a look at the code > provided asap and see what I can do. Its unfortunately still very busy, > so I can not commit when I will finally start. thanks. I'll keep poking at this. David Lang > HTH > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Wednesday, February 25, 2009 9:47 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] UDP source forging. >> >> figuring out how to do this is navigating a twisty maze of helper >> functions, all different ;-) >> >> there are a few things that look odd here if I am reading the code >> properly. >> >> rsyslog makes one call to the UDPSend routine for all forwarded >> messages, >> this means that they must all send the same format. >> >> the UDPSend routine then walks through all destinations attempting to >> send >> the message to them. and considers the message successfully sent if > any >> of >> them can be sent. I would have expected that it would only be >> considered >> successful if all of them succeded. >> >> UDPSend attempts to use the sockets that were created to listening for >> messages to send it's message out. in a multi-homed machine the local >> IP >> address of those sockets may not be appropriate for the relay. also, >> what >> would happen if a system recieves via TCP and forwards via UDP and so >> doesn't have any UDP listener sockets. >> >> >> so now, my suggestion >> >> On Linux in /etc/sysctl.conf add the line >> >> net.ipv4.ip_nonlocal_bind=1 >> >> this tells the kernel not to fail bind requests to IP addresses that >> don't >> exist on the box >> >> then in omfwd.c >> >> in the routine that calls UDPSend, modify it to pass the source IP >> address >> of the message to UDPSend >> >> create a new filehandle array to use for outbound messages (one >> filehandle >> for each destination since they may end up with different source IPs) >> >> >> in UDPSend >> >> three options. >> >> >> 1. default >> >> use the appropriate filehandle for each destination and send the >> message. this is similar to what currently takes place, but instead of >> walking through each open socket for each destination, there should >> only >> be one sendto per destination. when opening the socket it should not > be >> nessasary to do a bind, just issue the socket call. >> >> if there is anything in the syslog standard specifying the source >> port >> (I don't think there is, although many implementations use port 514 >> becouse they do the same thing that rsyslog is doing and re-use >> listening >> sockets to send messages) >> >> >> 2. randomize source ports to support external load balancers >> >> same as default, except that every X (configurable) messages close >> and >> re-open the sockets. >> >> the reason for this is that each time a message is first sent the > OS >> picks a random source port that will be used for all messages sent >> through >> that socket. by closing the socket once in a while, load balancers > that >> balance based on source IP + source port + destination IP + > destination >> port will be able to function (a similar feature for TCP based >> transports >> would be useful for the same reason) >> >> >> 3. forge the source IP/port >> >> for each message that is sent, open a new socket, then issue a >> 'bind' >> command for that socket (filehandle) that sets the local IP address to >> the >> IP address that the message initially came from, then issue the > sendto, >> then close the filehandle. >> >> there is no need for an array of sockets in this case as the socket >> needs to be re-opened for each message/destination. in theory there is >> a >> possibility of a performance gain by keeping sockets open and re-using >> them, but since each socket is unique to the sender + destination > there >> would be a large number of sockets and a low probability of re-using a >> socket for the next message. >> >> in sysklogd I implemented #2 with the simple code below (once I > created >> a >> different filehandle to use for outbound connections) >> >> this closed and re-opened the socket for each message, doing it every > X >> messages would save on the overhead and be just as good in practice. >> >> the bind command that's commented out is basicly what would be needed >> for >> #3, but with real values for the source.sin_addr.s_addr (and >> source.sin_port if you wanted to forge the port as well, leaving it >> zero >> lets the OS pick a port number) >> >> if (finet >0) { >> /* close and re-open the outbound socket after each message > so >> that the source port is randomized and load balancers can distribute >> the messages */ >> close(finet); >> finet = create_inet_socket(); >> /* if we want to forge the source IP for the outbound > packets, >> this is the place to do it by seeting the IP address to the address we >> received the message from >> struct sockaddr_in source; >> source.sin_addr.s_addr = 0x00000000; >> source.sin_port = 0x0000; >> bind(finet,(struct sockaddr *) >> &source,sizeof(source));*/ >> } >> >> >> the create_inet_socket() routine is: >> >> static int create_inet_socket() >> { >> int fd, on = 1; >> int sockflags; >> >> fd = socket(AF_INET, SOCK_DGRAM, 0); >> if (fd < 0) { >> logerror("syslog: Unknown protocol, suspending inet >> service."); >> return fd; >> } >> >> if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, \ >> (char *) &on, sizeof(on)) < 0 ) { >> logerror("setsockopt(REUSEADDR), suspending inet"); >> close(fd); >> return -1; >> } >> /* We must not block on the network socket, in case a packet >> * gets lost between select and recv, otherise the process >> * will stall until the timeout, and other processes trying > to >> * log will also stall. >> */ >> if ((sockflags = fcntl(fd, F_GETFL)) != -1) { >> sockflags |= O_NONBLOCK; >> /* >> * SETFL could fail too, so get it caught by the >> subsequent >> * error check. >> */ >> sockflags = fcntl(fd, F_SETFL, sockflags); >> } >> if (sockflags == -1) { >> logerror("fcntl(O_NONBLOCK), suspending inet"); >> close(fd); >> return -1; >> } >> return fd; >> } >> >> >> this isn't a patch like you asked for and I offered to put togeather, >> but >> is it enough to clearly explain this? if not I can continue to work on >> the >> patch. >> >> David Lang >> >> On Tue, 24 Feb 2009, Rainer Gerhards wrote: >> >>> David, >>> >>> Excellent, please do as you have time. I'll make sure it fits. >>> Thread-safety, btw., is not a big issue at this level as the output >>> modules are guaranteed to be never called by multiple threads >>> concurrently. That was a trade-off to enable other folks to easily >> write >>> them (but I have an option in the back of my head that a module can >> tell >>> the engine it *is* capable to run on multiple threads >> concurrently...). >>> >>> Rainer >>> >>>> -----Original Message----- >>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >>>> Sent: Tuesday, February 24, 2009 9:43 AM >>>> To: rsyslog-users >>>> Subject: Re: [rsyslog] UDP source forging. >>>> >>>> On Tue, 24 Feb 2009, Rainer Gerhards wrote: >>>> >>>>> Hi David et all, >>>>> >>>>> Currently rsyslog does not support this and I have to admit I was >>>> always >>>>> very hesitant to add it (I see potential for misuse). Co- >>>> incidentally, I >>>>> received a similar request and was about to relay it to the > mailing >>>> list >>>>> to gather feedback. As it looks, this no longer is necessary ;) >>>>> >>>>> When I thought about implementation, I originally thought about > raw >>>>> sockets (which indeed require root access), but if there is any >>> other >>>>> way, I would be most interested. If you can provide some code, I >>> will >>>>> happily integrate it. I think an addition to the omfwd module, in >>> udp >>>>> forwarding, together with a new directive > ($SpoofOriginalUDPAddress >>>> or >>>>> so...) would be the right way to go. >>>> >>>> I'll see about hacking in some example code (probably without any >>>> config >>>> option and not thread-safe) and send it to you. >>>> >>>> there's another similar change in the same area that I was looking >> at, >>>> I'll mock it up as well. >>>> >>>> David Lang >>>> >>>>> Rainer >>>>> >>>>>> -----Original Message----- >>>>>> From: rsyslog-bounces at lists.adiscon.com >>>>>> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of >>>> david at lang.hm >>>>>> Sent: Tuesday, February 24, 2009 4:40 AM >>>>>> To: rsyslog-users >>>>>> Subject: Re: [rsyslog] UDP source forging. >>>>>> >>>>>> On Mon, 23 Feb 2009, RB wrote: >>>>>> >>>>>>> On Mon, Feb 23, 2009 at 18:11, wrote: >>>>>>>> I have a need to use some products that are stupid enough >>>>>> to ignore the >>>>>>>> host field in the syslog message and instead base >>>>>> everything on the IP >>>>>>>> address the message originates from. >>>>>>>> >>>>>>>> some other syslog servers can handle this by forging the >>>>>> source of the UDP >>>>>>>> packet, can rsyslog do this? >>>>>>> >>>>>>> So is rsyslog originating the messages, or are you using it to >>>>>>> aggregate them and then feed them on to the other [bad] >>>>>> acceptors? I >>>>>>> am unaware of a way to get rsyslog to forge packets (short >>>>>> of writing >>>>>>> an output module), but unless you must get another syslog >>>>>> daemon into >>>>>>> the mix, you may be better off just feeding your messages >>>>>> directly to >>>>>>> the other collector. >>>>>> >>>>>> rsyslog would be the relay from one non-routed network to another >>>>>> non-routed network. >>>>>> >>>>>> this could be a fairly simple change to the UDP output module >>>>>> (adding a >>>>>> couple commands around the sending of a message), but before >>>>>> I dove in to >>>>>> do that I wanted to see if I had missed this feature anywhere. >>>>>> >>>>>> David Lang >>>>>> _______________________________________________ >>>>>> rsyslog mailing list >>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>> http://www.rsyslog.com >>>>>> >>>>> _______________________________________________ >>>>> rsyslog mailing list >>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>> http://www.rsyslog.com >>>>> >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 26 18:16:15 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 18:16:15 +0100 Subject: [rsyslog] UDP source forging. References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Just one quick answer (on the leave) > > RFC3164 actually > > recommends that port 514 is used as the source port, and we had a > > lengthy discussion at the IETF about this recommendation. The bottom > > line is that you cannot reuse the receive socket on a highly parallel > > syslogd because each thread needs its own (or you have even more > sync). > > Rsyslog creates a new (set of) send sockets *per action*. > > if you don't do a bind on the socket you can't specify the source port. > if > you do bind on the socket and set the source port to 514 aren't you > generating a conflict between the multiple send sockets? I am ignoring the RFC recommendation. It is also removed from the soon-to-appear RFC5424. I should have mentioned this... Rainer From bakers at web-ster.com Thu Feb 26 19:00:43 2009 From: bakers at web-ster.com (Scott Baker) Date: Thu, 26 Feb 2009 10:00:43 -0800 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> Message-ID: <49A6D8CB.1010506@web-ster.com> On 02/25/2009 03:38 PM, (private) HKS wrote: >> Does this syntax work on rsyslog 2.0.x, that's what my server has on it. >> I've tried this syntax, but it's not logging. >> >> - Scott > > > No, this will require 3+ - which you really should upgrade to anyway. That's what I figured... this is my CORE syslog server, so I'll need to play a good upgrade proceedure. Is their documentation on configuration file changes going from 2.x to 3.x? - Scott From mbiebl at gmail.com Fri Feb 27 01:55:14 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Fri, 27 Feb 2009 01:55:14 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: 2009/2/26 : > even where rsyslog is included in a distro it's very handy to have a spec > file (or debian equivalent) included with the source to allow a 'make rpm' > or 'make deb' to properly make packages. > > I've been using checkinstall to create debian packages from the compiled > source, and I don't know what it's doing wrong, but I've been tripped up a > few times by it not replacing all the files that it should if rsyslog is > already installed (the packages it creates work just fine if rsyslog isn't > installed at all) FWIW, I as Debian maintainer of rsyslog, explicitly asked Rainer to remove the debian/ directory from the upstream source tree. Reason is simple: Packaging is the task of the downstream distros and the files shipped upstream were always out-of-date anyways. This not only caused more work for me as Debian maintainer but also leads to bad user experience if the rpm/debs created from the upstream spec/debian build files are outdated and potentially create a half-way broken package. If the fedora bits are kept in an entirely separate upstream packaging branch, then I don't really care. But I wouldn't like to see them (or any debian related files) shipped in a release tarball. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From david at lang.hm Fri Feb 27 04:20:37 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 19:20:37 -0800 (PST) Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: On Fri, 27 Feb 2009, Michael Biebl wrote: > 2009/2/26 : >> even where rsyslog is included in a distro it's very handy to have a spec >> file (or debian equivalent) included with the source to allow a 'make rpm' >> or 'make deb' to properly make packages. >> >> I've been using checkinstall to create debian packages from the compiled >> source, and I don't know what it's doing wrong, but I've been tripped up a >> few times by it not replacing all the files that it should if rsyslog is >> already installed (the packages it creates work just fine if rsyslog isn't >> installed at all) > > > FWIW, I as Debian maintainer of rsyslog, explicitly asked Rainer to > remove the debian/ directory from the upstream source tree. Reason is > simple: Packaging is the task of the downstream distros and the files > shipped upstream were always out-of-date anyways. This not only caused > more work for me as Debian maintainer but also leads to bad user > experience if the rpm/debs created from the upstream spec/debian build > files are outdated and potentially create a half-way broken package. > > If the fedora bits are kept in an entirely separate upstream packaging > branch, then I don't really care. > But I wouldn't like to see them (or any debian related files) shipped > in a release tarball. so how am I (a debian user) supposed to create debian compatible packages for versions that you don't yet deal with? why couldn't you push the debian related files upstream and maintain them there? (submitting patches, or git pull requests for updates) David Lang From david at lang.hm Fri Feb 27 08:40:18 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 23:40:18 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 26 Feb 2009, Rainer Gerhards wrote: > Just one quick answer (on the leave) > >>> RFC3164 actually >>> recommends that port 514 is used as the source port, and we had a >>> lengthy discussion at the IETF about this recommendation. The bottom >>> line is that you cannot reuse the receive socket on a highly > parallel >>> syslogd because each thread needs its own (or you have even more >> sync). >>> Rsyslog creates a new (set of) send sockets *per action*. >> >> if you don't do a bind on the socket you can't specify the source > port. >> if >> you do bind on the socket and set the source port to 514 aren't you >> generating a conflict between the multiple send sockets? > > I am ignoring the RFC recommendation. It is also removed from the > soon-to-appear RFC5424. I should have mentioned this... good, that clarifies things a lot. I think I see a significant simplification here. getaddrinfo can return a bunch of different addrinfo structures, which you walk through and try to send to each one until you find one that works. based on the man page for this I see the following reasons for multiple sockets 1. number of IP stacks (IPv4 vs IPv6 vs both) 2. multiple interfaces (and potentially multiple IPs if hostname resolves to more than one) the number of structures that you get back is #1 * #2. however, I don't think that you need to go through this. since you maintain a instance of omfwd for each action (i.e. destination), you should be able to figure out what will work and not waste any time dealing with the others. when you lookup the destination address to send to, you should be able to find out if it's an IPv4 or an IPv6 address. If you have both pick one to use (arguments can be made as to which is the best to use, pick one to default to and have a config option to override it) If you get multiple addresses, use the first one. at this point you have one socket of the correct type to send to that destination. attempting to send to each one until you get sucess works, and may be more robust, but it's a significant amount of complication and overhead that you shouldn't need to go through. I think the basic changes needed to support forging the address are something like this (whitespace munged by cut-n-paste) diff --git a/tools/omfwd.c b/tools/omfwd.c index 1dd184e..1112db6 100644 --- a/tools/omfwd.c +++ b/tools/omfwd.c @@ -193,6 +193,15 @@ static rsRetVal UDPSend(instanceData *pData, char *msg, size_t len) int bSendSuccess; if(pData->pSockArray != NULL) { + /* close and re-open sockets for two possilbe reasons + * so that the source port is randomized again (to support load balancers + * so that we can bind to them to forge the from address on the packet + * this should be conditional on config options (including how frequently to do this) + * David Lang 2009-02-25 + */ + net.closeUDPListenSockets(pData->pSockArray); + pData->pSockArray = net.create_udp_socket((uchar*)pData->f_hname, NULL, 0); + /* we need to track if we have success sending to the remote * peer. Success is indicated by at least one sendto() call * succeeding. We track this be bSendSuccess. We can not simply @@ -203,6 +212,15 @@ static rsRetVal UDPSend(instanceData *pData, char *msg, size_t len) bSendSuccess = FALSE; for (r = pData->f_addr; r; r = r->ai_next) { for (i = 0; i < *pData->pSockArray; i++) { + /* if we are forging the source IP of the packet, issue the bind to do so + * this should be made conditional on a config option -- David Lang 2009-02-25 + * since I don't know how to get the correct source IP, I'll set it to look + * like it comes from 10.201.1.1 IPv4 + */ + + + struct sockaddr_in source; + memset(&source,0,sizeof(source)); + source.sin_family = AF_INET; + source.sin_addr.s_addr = 0x0101c90a; + source.sin_port = 0x0000; + +/* bind(pData->pSockArray[i+1],(struct sockaddr *) &source,sizeof(source)); +*/ + lsent = sendto(pData->pSockArray[i+1], msg, len, 0, r->ai_addr, r->ai_addrlen); if (lsent == len) { bSendSuccess = TRUE; this works for reopening the socket each time, but if I uncomment the bind the sendto fails (error 22, invalid input) I haven't yet figured out what I'm missing on the bind that's causing this David Lang From patrick.shen at net-m.de Fri Feb 27 07:59:40 2009 From: patrick.shen at net-m.de (Patrick Shen) Date: Fri, 27 Feb 2009 14:59:40 +0800 Subject: [rsyslog] Weird fromhost property value Message-ID: <49A78F5C.3000400@net-m.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I've utilized rsyslog as my company's central logging server for half a year. Today I encounterd a very weird issue about value of fromhost property. We use dynamic templates to store logs from clients. The template is like below: $template d_hosts,"/var/rsyslog/HOSTS/%fromhost%/%$year%/%$month%/%syslogfacility-text%_%fromhost%_%$year%_%$month%_%$day %.log" You can see we group logs by fromhost value. Today, I did 3 times test that a client named (sobek) sent logs to central logging server by UDP, TCP and RELP. The FQDN of client node is "sobek.net-m.internal", short name is "sobek", ip address is "172.21.101.13". After testing, I got when sending via UDP, the fromhost value is short name. And via TCP, the value is FQDN. Via RELP, the value is IP address. So I got a very weird directory organization at "/var/rsyslog/HOSTS". ########################################################################## drwxr-x--- 3 root syslog 80 Feb 27 07:24 172.21.101.13 <- RELP drwxr-x--- 3 root syslog 80 Feb 27 05:58 sobek <- UDP drwxr-x--- 3 root syslog 80 Feb 27 06:03 sobek.net-m.internal <- TCP ########################################################################## We are running rsyslog 3.20.0 both on client and server. So I wanna know if any other has encountered this before? Thanks, Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJp49ckHhYtFevC+MRApbbAJ9Dgxtw5mf+ax9D81OZPfh5E9aJPgCdEqF/ FlkFDJpWr4k6pVV4AQiLhRw= =cQzr -----END PGP SIGNATURE----- From david at lang.hm Fri Feb 27 09:03:54 2009 From: david at lang.hm (david at lang.hm) Date: Fri, 27 Feb 2009 00:03:54 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 26 Feb 2009, david at lang.hm wrote: > > this works for reopening the socket each time, but if I uncomment the bind > the sendto fails (error 22, invalid input) > > I haven't yet figured out what I'm missing on the bind that's causing this a little more testing and I find that the bind succeeds, but no traffic goes out unless the source IP exists somewhere on the box (it can be bound to lo:0, but it needs to exist) so the non-local-bind approach may not work :-( it's just hit midnight here, so I'm going to call it a night and try again tomorrow. David Lang From nico at altiva.fr Fri Feb 27 18:05:19 2009 From: nico at altiva.fr (NM) Date: Fri, 27 Feb 2009 17:05:19 +0000 (UTC) Subject: [rsyslog] rsyslog and load balancers References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> <577465F99B41C842AAFBE9ED71E70ABA44FCB6@grfint2.intern.adiscon.com> Message-ID: On Mon, 23 Feb 2009 17:44:58 +0100, Rainer Gerhards wrote: > I couldn't stand this Well unfortunately many companies have this nonsense bullshit added at the server (read: Exchange) level. One company I worked for even added a 10kB gif logo to *every* single outgoing mail, on top of 5kB of (uneforceable, useless) legalese. From rgerhards at hq.adiscon.com Fri Feb 27 18:36:18 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 27 Feb 2009 18:36:18 +0100 Subject: [rsyslog] rsyslog and load balancers References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local><577465F99B41C842AAFBE9ED71E70ABA44FCB6@grfint2.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71ED7@GRFEXC.intern.adiscon.com> Well... and the funny thing is in Germany is part of this even required by law... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of NM > Sent: Friday, February 27, 2009 6:05 PM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] rsyslog and load balancers > > On Mon, 23 Feb 2009 17:44:58 +0100, Rainer Gerhards wrote: > > > I couldn't stand this > > Well unfortunately many companies have this nonsense bullshit added at > the server (read: Exchange) level. One company I worked for even added > a > 10kB gif logo to *every* single outgoing mail, on top of 5kB of > (uneforceable, useless) legalese. > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From Luis.Fernando.Munoz.Mejias at cern.ch Fri Feb 27 18:48:56 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Fri, 27 Feb 2009 18:48:56 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC08@grfint2.intern.adiscon.com> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> <577465F99B41C842AAFBE9ED71E70ABA44FC08@grfint2.intern.adiscon.com> Message-ID: <200902271848.56481.Luis.Fernando.Munoz.Mejias@cern.ch> Rainer, Good and bad news... > > That sounds really great. Before you start coding or preparing > > anything, let me check how well our DBs perform, because it's not > > yet clear if they'll be able to cope with the high insertion rate we > > expect. If we don't go for the Oracle database this work doesn't > > make sense. I bet we'll want the Oracle, anyways. > > Sounds fair. Good news: I did my tests and, for many tasks I need to do, Oracle is our way to go. So, I'm willing to write the module, with your guidance/advise. As I said, I need **excellent** performance. I definitely need batch operations, the ability to prepare the statements given as arguments on the configuration file, and not to commit entries one by one, but after a number of entries are ready or (better) after some not so small time. According to the advise I got from experts around here, I'll have to use Oracle Call Interface for this module, I don't know if there are any licensing issues. It seems I'll have to review how rsyslog's queing modules work... > > For this evaluation, I already have a timestamp formatter that fits > > into Oracle, something that can be used with the property replacer, > > like %timereported:::date-oracle%. > The bad news is that this timestamp formatter works perfectly on interactive sessions (sqlplus) but not on non-interactive ones, f.i, in Python scripts. You need to call Oracle's to_timestamp(string, format), and by bloating your code with this ugly function the rfc-3339 formatter is good enough. So I won't submit this one. Cheers. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From aoz.syn at gmail.com Fri Feb 27 19:42:49 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 27 Feb 2009 11:42:49 -0700 Subject: [rsyslog] Weird fromhost property value In-Reply-To: <49A78F5C.3000400@net-m.de> References: <49A78F5C.3000400@net-m.de> Message-ID: <4255c2570902271042l44d437c9kaa13ff01c509fcc2@mail.gmail.com> On Thu, Feb 26, 2009 at 23:59, Patrick Shen wrote: > You can see we group logs by fromhost value. > > Today, I did 3 times test that a client named (sobek) sent logs to > central logging server by UDP, TCP and RELP. > > The FQDN of client node is "sobek.net-m.internal", short name is > "sobek", ip address is "172.21.101.13". > > After testing, I got when sending via UDP, the fromhost value is short > name. And via TCP, the value is FQDN. Via RELP, the value is IP address. > > So I got a very weird directory organization at "/var/rsyslog/HOSTS". > > ########################################################################## > drwxr-x--- 3 root syslog 80 Feb 27 07:24 172.21.101.13 ? ? ? ? <- RELP > drwxr-x--- 3 root syslog 80 Feb 27 05:58 sobek ? ? ? ? ? ? ? ? <- UDP > drwxr-x--- 3 root syslog 80 Feb 27 06:03 sobek.net-m.internal ?<- TCP > ########################################################################## I've tried something similar and eventually gave up and started using the 'fromhost-ip' property to create per-sender templates. Of course, fromhost* falls down once you have relays in the mix, but that's another problem to solve. From mbiebl at gmail.com Sat Feb 28 02:58:34 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Sat, 28 Feb 2009 02:58:34 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: 2009/2/27 : > On Fri, 27 Feb 2009, Michael Biebl wrote: > >> 2009/2/26 ?: >>> even where rsyslog is included in a distro it's very handy to have a spec >>> file (or debian equivalent) included with the source to allow a 'make rpm' >>> or 'make deb' to properly make packages. >>> >>> I've been using checkinstall to create debian packages from the compiled >>> source, and I don't know what it's doing wrong, but I've been tripped up a >>> few times by it not replacing all the files that it should if rsyslog is >>> already installed (the packages it creates work just fine if rsyslog isn't >>> installed at all) >> >> >> FWIW, I as Debian maintainer of rsyslog, explicitly asked Rainer to >> remove the debian/ directory from the upstream source tree. Reason is >> simple: Packaging is the task of the downstream distros and the files >> shipped upstream were always out-of-date anyways. This not only caused >> more work for me as Debian maintainer but also leads to bad user >> experience if the rpm/debs created from the upstream spec/debian build >> files are outdated and potentially create a half-way broken package. >> >> If the fedora bits are kept in an entirely separate upstream packaging >> branch, then I don't really care. >> But I wouldn't like to see them (or any debian related files) shipped >> in a release tarball. > > so how am I (a debian user) supposed to create debian compatible packages > for versions that you don't yet deal with? > > why couldn't you push the debian related files upstream and maintain them > there? (submitting patches, or git pull requests for updates) Pretty simple: It's less work for me and Rainer and more flexible. Say I (for Debian) start adding the files upstream, so does Fedora, BSD, etc... Now when Rainer wants to make a new release to not have any stale packaging files, he would have to ping all package maintainer first to update the build files and push those changes. That simply doesn't scale. Packaging and upstream software releases should be decoupled. If you are really interested in the Debian Packaging, you can grab the git repository from [1] and either work from there or at it as a "remote" to the rsyslog git repo and merge the debian specific bits. Cheers, Michael [1] http://git.debian.org/?p=collab-maint/rsyslog.git;a=summary -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From david at lang.hm Sat Feb 28 03:16:15 2009 From: david at lang.hm (david at lang.hm) Date: Fri, 27 Feb 2009 18:16:15 -0800 (PST) Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: On Sat, 28 Feb 2009, Michael Biebl wrote: >>> >>> If the fedora bits are kept in an entirely separate upstream packaging >>> branch, then I don't really care. >>> But I wouldn't like to see them (or any debian related files) shipped >>> in a release tarball. >> >> so how am I (a debian user) supposed to create debian compatible packages >> for versions that you don't yet deal with? >> >> why couldn't you push the debian related files upstream and maintain them >> there? (submitting patches, or git pull requests for updates) > > Pretty simple: It's less work for me and Rainer and more flexible. > Say I (for Debian) start adding the files upstream, so does Fedora, BSD, etc... > Now when Rainer wants to make a new release to not have any stale > packaging files, he would have to ping all package maintainer first to > update the build files and push those changes. That simply doesn't > scale. > Packaging and upstream software releases should be decoupled. > > If you are really interested in the Debian Packaging, you can grab the > git repository from [1] and either work from there or at it as a > "remote" to the rsyslog git repo and merge the debian specific bits. it's not that I'm interested in debian packaging, it's that I need to install the stuff that you haven't decided to ship in debian yet on my debian system in such a way that I keep the package manager happy (and don't have it overwriting what I've compiled with an update of an obsolete version) it's not that the upstream version of the files need to be perfect, but they should be good enough to avoid the need for users to have to fight the packaging system and duplicate your efforts. I hate to have to pull in some stuff from your tree and combine it with stuff from the upstream tree because I don't know enough to be sure that I'm both pulling everything I need and not pulling something that will cause grief. you've made your decision, count this as one voice disagreeing with that decision. David Lang From rgerhards at hq.adiscon.com Thu Feb 26 18:46:27 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 18:46:27 +0100 Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Message-ID: <1235670387.28865.2.camel@rf10up.intern.adiscon.com> On Sun, 2009-03-01 at 23:56 -0800, david at lang.hm wrote: > On Fri, 27 Feb 2009, david at lang.hm wrote: > > > On Thu, 26 Feb 2009, david at lang.hm wrote: > > > >> > >> this works for reopening the socket each time, but if I uncomment the bind > >> the sendto fails (error 22, invalid input) > >> > >> I haven't yet figured out what I'm missing on the bind that's causing this > > > > a little more testing and I find that the bind succeeds, but no traffic goes > > out unless the source IP exists somewhere on the box (it can be bound to > > lo:0, but it needs to exist) > > > > so the non-local-bind approach may not work :-( > > > > it's just hit midnight here, so I'm going to call it a night and try again > > tomorrow. > > I abandoned this approach and spent the weekend learning how to do raw > sockets. I found a library that makes it not that bad to do (at least for > the IPv4 that I've done so far, IPv6 adds some wrinkles) > > the one thing thats not clear to me at this point is how to find the > original source IP of the message. Is that available in a variable inside > UDPSend, or is it something that I will have to get earlier in the process > and then pass explicitly to UDPSend? Actually, output modules do not receive access to the full message object. This was originally done for security reasons (do not pass more than needed). All they can receive is the strings that are passed to them. So the module would need to be modified so that a second string (like ommail) is passed and that string needs to be defined as the to-be-spoofed IP (what also enables to rewrite the source IP). >From all the discussion, it may make sense to start with a different output plugin that may later be merged back into the original one... Rainer > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Feb 2 14:41:57 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 14:41:57 +0100 Subject: [rsyslog] rsyslog 3.21.10 (beta) released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAEC@grfint2.intern.adiscon.com> Hi all, this is a bug-fixing release. Most importantly, a race that could result in a segfault, in specific scenarios, has been addressed. Also, some command-line switches were incorrectly processed and a debug string was accidentally written to stdout on daemon termination. This is a recommended update for all users of the beta branch. Change Log: http://www.rsyslog.com/Article344.phtml Download: http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-148.phtml I hope this release is useful. Feedback is appreciated. Best regards, Rainer Gerhards From r.bhatia at ipax.at Mon Feb 2 16:34:42 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Mon, 02 Feb 2009 16:34:42 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** Message-ID: <49871292.9000900@ipax.at> hi, i do not know if this has already been addressed - so sorry for a possible duplicate. revision: > Feb 2 16:29:58 wc02 kernel: imklog 3.20.0, log source = /proc/kmsg started. > Feb 2 16:29:58 wc02 rsyslogd: [origin software="rsyslogd" swVersion="3.20.0" x-pid="27617" x-info="http://www.rsyslog.com"] restart running on debian logging remotely to another server. cheers, raoul > *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** > ======= Backtrace: ========= > /lib/libc.so.6[0x7f639a997948] > /lib/libc.so.6(cfree+0x76)[0x7f639a999a56] > /usr/sbin/rsyslogd(msgDestruct+0x3c)[0x415f7c] > /usr/sbin/rsyslogd(actionCallAction+0xcd)[0x4281cd] > /usr/sbin/rsyslogd[0x409de9] > /usr/sbin/rsyslogd(llExecFunc+0x58)[0x4168e8] > /usr/sbin/rsyslogd[0x409ad5] > /usr/sbin/rsyslogd[0x4244ef] > /usr/sbin/rsyslogd(wtiWorker+0x24f)[0x42124f] > /usr/sbin/rsyslogd[0x420968] > /lib/libpthread.so.0[0x7f639b08afc7] > /lib/libc.so.6(clone+0x6d)[0x7f639a9f35ad] > ======= Memory map: ======== > 00400000-0043c000 r-xp 00000000 09:00 384769 /usr/sbin/rsyslogd > 0053b000-00540000 rw-p 0003b000 09:00 384769 /usr/sbin/rsyslogd > 00540000-00541000 rw-p 00540000 00:00 0 > 00ebc000-00f6e000 rw-p 00ebc000 00:00 0 [heap] > 40219000-4021a000 ---p 40219000 00:00 0 > 4021a000-40a1a000 rw-p 4021a000 00:00 0 > 40c65000-40c66000 ---p 40c65000 00:00 0 > 40c66000-41466000 rw-p 40c66000 00:00 0 > 41466000-41467000 ---p 41466000 00:00 0 > 41467000-41c67000 rw-p 41467000 00:00 0 > 41cff000-41d00000 ---p 41cff000 00:00 0 > 41d00000-42500000 rw-p 41d00000 00:00 0 > 7f638c000000-7f638c021000 rw-p 7f638c000000 00:00 0 > 7f638c021000-7f6390000000 ---p 7f638c021000 00:00 0 > 7f6394000000-7f6394021000 rw-p 7f6394000000 00:00 0 > 7f6394021000-7f6398000000 ---p 7f6394021000 00:00 0 > 7f63995aa000-7f63995c0000 r-xp 00000000 09:00 128682 /lib/libgcc_s.so.1 > 7f63995c0000-7f63997c0000 ---p 00016000 09:00 128682 /lib/libgcc_s.so.1 > 7f63997c0000-7f63997c1000 rw-p 00016000 09:00 128682 /lib/libgcc_s.so.1 > 7f63997c1000-7f63997d1000 r-xp 00000000 09:00 128437 /lib/libresolv-2.7.so > 7f63997d1000-7f63999d1000 ---p 00010000 09:00 128437 /lib/libresolv-2.7.so > 7f63999d1000-7f63999d3000 rw-p 00010000 09:00 128437 /lib/libresolv-2.7.so > 7f63999d3000-7f63999d5000 rw-p 7f63999d3000 00:00 0 > 7f63999d5000-7f63999d9000 r-xp 00000000 09:00 128444 /lib/libnss_dns-2.7.so > 7f63999d9000-7f6399bd8000 ---p 00004000 09:00 128444 /lib/libnss_dns-2.7.so > 7f6399bd8000-7f6399bda000 rw-p 00003000 09:00 128444 /lib/libnss_dns-2.7.so > 7f6399bda000-7f6399bde000 r-xp 00000000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so > 7f6399bde000-7f6399cdd000 ---p 00004000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so > 7f6399cdd000-7f6399cde000 rw-p 00003000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so > 7f6399cde000-7f6399ce0000 r-xp 00000000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so > 7f6399ce0000-7f6399ddf000 ---p 00002000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so > 7f6399ddf000-7f6399de0000 rw-p 00001000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so > 7f6399de0000-7f6399de3000 r-xp 00000000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so > 7f6399de3000-7f6399ee2000 ---p 00003000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so > 7f6399ee2000-7f6399ee3000 rw-p 00002000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so > 7f6399ee3000-7f6399eed000 r-xp 00000000 09:00 128429 /lib/libnss_nis-2.7.so > 7f6399eed000-7f639a0ec000 ---p 0000a000 09:00 128429 /lib/libnss_nis-2.7.so > 7f639a0ec000-7f639a0ee000 rw-p 00009000 09:00 128429 /lib/libnss_nis-2.7.so > 7f639a0ee000-7f639a103000 r-xp 00000000 09:00 128433 /lib/libnsl-2.7.so > 7f639a103000-7f639a302000 ---p 00015000 09:00 128433 /lib/libnsl-2.7.so > 7f639a302000-7f639a304000 rw-p 00014000 09:00 128433 /lib/libnsl-2.7.so > 7f639a304000-7f639a306000 rw-p 7f639a304000 00:00 0 > 7f639a306000-7f639a30d000 r-xp 00000000 09:00 128435 /lib/libnss_compat-2.7.so > 7f639a30d000-7f639a50c000 ---p 00007000 09:00 128435 /lib/libnss_compat-2.7.so > 7f639a50c000-7f639a50e000 rw-p 00006000 09:00 128435 /lib/libnss_compat-2.7.so > 7f639a50e000-7f639a513000 r-xp 00000000 09:00 416987 /usr/lib/rsyslog/imklog.so > 7f639a513000-7f639a613000 ---p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so > 7f639a613000-7f639a614000 rw-p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so > 7f639a614000-7f639a615000 rw-p 7f639a614000 00:00 0 > 7f639a615000-7f639a617000 r-xp 00000000 09:00 416978 /usr/lib/rsyslog/imuxsock.so > 7f639a617000-7f639a717000 ---p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so > 7f639a717000-7f639a718000 rw-p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so > 7f639a718000-7f639a722000 r-xp 00000000 09:00 128440 /lib/libnss_files-2.7.so > 7f639a722000-7f639a922000 ---p 0000a000 09:00 128440 /lib/libnss_files-2.7.so > 7f639a922000-7f639a924000 rw-p 0000a000 09:00 128440 /lib/libnss_files-2.7.so > 7f639a924000-7f639aa6e000 r-xp 00000000 09:00 128443 /lib/libc-2.7.so > 7f639aa6e000-7f639ac6d000 ---p 0014a000 09:00 128443 /lib/libc-2.7.so > 7f639ac6d000-7f639ac70000 r--p 00149000 09:00 128443 /lib/libc-2.7.so > 7f639ac70000-7f639ac72000 rw-p 0014c000 09:00 128443 /lib/libc-2.7.so > 7f639ac72000-7f639ac77000 rw-p 7f639ac72000 00:00 0 > 7f639ac77000-7f639ac7f000 r-xp 00000000 09:00 128449 /lib/librt-2.7.so > 7f639ac7f000-7f639ae7e000 ---p 00008000 09:00 128449 /lib/librt-2.7.so > 7f639ae7e000-7f639ae80000 rw-p 00007000 09:00 128449 /lib/librt-2.7.so > 7f639ae80000-7f639ae82000 r-xp 00000000 09:00 128447 /lib/libdl-2.7.so > 7f639ae82000-7f639b082000 ---p 00002000 09:00 128447 /lib/libdl-2.7.so > 7f639b082000-7f639b084000 rw-p 00002000 09:00 128447 /lib/libdl-2.7.so > 7f639b084000-7f639b09a000 r-xp 00000000 09:00 128439 /lib/libpthread-2.7.so > 7f639b09a000-7f639b29a000 ---p 00016000 09:00 128439 /lib/libpthread-2.7.so > 7f639b29a000-7f639b29c000 rw-p 00016000 09:00 128439 /lib/libpthread-2.7.so > 7f639b29c000-7f639b2a0000 rw-p 7f639b29c000 00:00 0 > 7f639b2a0000-7f639b2b6000 r-xp 00000000 09:00 370185 /usr/lib/libz.so.1.2.3.3 > 7f639b2b6000-7f639b4b6000 ---p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 > 7f639b4b6000-7f639b4b7000 rw-p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 > 7f639b4b7000-7f639b4d3000 r-xp 00000000 09:00 128446 /lib/ld-2.7.so > 7f639b5bd000-7f639b5c2000 r-xp 00000000 09:00 416988 /usr/lib/rsyslog/lmnet.so > 7f639b5c2000-7f639b6c1000 ---p 00005000 09:00 416988 /usr/lib/rsyslog/lmnet.so > 7f639b6c1000-7f639b6c2000 rw-p 00004000 09:00 416988 /usr/lib/rsyslog/lmnet.so > 7f639b6c2000-7f639b6c5000 rw-p 7f639b6c2000 00:00 0 > 7f639b6ce000-7f639b6d2000 rw-p 7f639b6ce000 00:00 0 > 7f639b6d2000-7f639b6d4000 rw-p 0001b000 09:00 128446 /lib/ld-2.7.so > 7fffa36bf000-7fffa36d4000 rw-p 7ffffffea000 00:00 0 [stack] > 7fffa36ff000-7fffa3700000 r-xp 7fffa36ff000 00:00 0 [vdso] > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] From rgerhards at hq.adiscon.com Mon Feb 2 17:29:26 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 17:29:26 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <49871292.9000900@ipax.at> References: <49871292.9000900@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAF0@grfint2.intern.adiscon.com> This is probably the result of the data race I described in details last week. You need to pull the newest releases. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Monday, February 02, 2009 4:35 PM > To: rsyslog-users > Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double > free or corruption (!prev): 0x0000000000ef03b0 *** > > hi, > > i do not know if this has already been addressed - so sorry for > a possible duplicate. > > revision: > > Feb 2 16:29:58 wc02 kernel: imklog 3.20.0, log source = /proc/kmsg > started. > > Feb 2 16:29:58 wc02 rsyslogd: [origin software="rsyslogd" > swVersion="3.20.0" x-pid="27617" x-info="http://www.rsyslog.com"] > restart > > running on debian logging remotely to another server. > > cheers, > raoul > > > *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption > (!prev): 0x0000000000ef03b0 *** > > ======= Backtrace: ========= > > /lib/libc.so.6[0x7f639a997948] > > /lib/libc.so.6(cfree+0x76)[0x7f639a999a56] > > /usr/sbin/rsyslogd(msgDestruct+0x3c)[0x415f7c] > > /usr/sbin/rsyslogd(actionCallAction+0xcd)[0x4281cd] > > /usr/sbin/rsyslogd[0x409de9] > > /usr/sbin/rsyslogd(llExecFunc+0x58)[0x4168e8] > > /usr/sbin/rsyslogd[0x409ad5] > > /usr/sbin/rsyslogd[0x4244ef] > > /usr/sbin/rsyslogd(wtiWorker+0x24f)[0x42124f] > > /usr/sbin/rsyslogd[0x420968] > > /lib/libpthread.so.0[0x7f639b08afc7] > > /lib/libc.so.6(clone+0x6d)[0x7f639a9f35ad] > > ======= Memory map: ======== > > 00400000-0043c000 r-xp 00000000 09:00 384769 > /usr/sbin/rsyslogd > > 0053b000-00540000 rw-p 0003b000 09:00 384769 > /usr/sbin/rsyslogd > > 00540000-00541000 rw-p 00540000 00:00 0 > > 00ebc000-00f6e000 rw-p 00ebc000 00:00 0 > [heap] > > 40219000-4021a000 ---p 40219000 00:00 0 > > 4021a000-40a1a000 rw-p 4021a000 00:00 0 > > 40c65000-40c66000 ---p 40c65000 00:00 0 > > 40c66000-41466000 rw-p 40c66000 00:00 0 > > 41466000-41467000 ---p 41466000 00:00 0 > > 41467000-41c67000 rw-p 41467000 00:00 0 > > 41cff000-41d00000 ---p 41cff000 00:00 0 > > 41d00000-42500000 rw-p 41d00000 00:00 0 > > 7f638c000000-7f638c021000 rw-p 7f638c000000 00:00 0 > > 7f638c021000-7f6390000000 ---p 7f638c021000 00:00 0 > > 7f6394000000-7f6394021000 rw-p 7f6394000000 00:00 0 > > 7f6394021000-7f6398000000 ---p 7f6394021000 00:00 0 > > 7f63995aa000-7f63995c0000 r-xp 00000000 09:00 128682 > /lib/libgcc_s.so.1 > > 7f63995c0000-7f63997c0000 ---p 00016000 09:00 128682 > /lib/libgcc_s.so.1 > > 7f63997c0000-7f63997c1000 rw-p 00016000 09:00 128682 > /lib/libgcc_s.so.1 > > 7f63997c1000-7f63997d1000 r-xp 00000000 09:00 128437 > /lib/libresolv-2.7.so > > 7f63997d1000-7f63999d1000 ---p 00010000 09:00 128437 > /lib/libresolv-2.7.so > > 7f63999d1000-7f63999d3000 rw-p 00010000 09:00 128437 > /lib/libresolv-2.7.so > > 7f63999d3000-7f63999d5000 rw-p 7f63999d3000 00:00 0 > > 7f63999d5000-7f63999d9000 r-xp 00000000 09:00 128444 > /lib/libnss_dns-2.7.so > > 7f63999d9000-7f6399bd8000 ---p 00004000 09:00 128444 > /lib/libnss_dns-2.7.so > > 7f6399bd8000-7f6399bda000 rw-p 00003000 09:00 128444 > /lib/libnss_dns-2.7.so > > 7f6399bda000-7f6399bde000 r-xp 00000000 09:00 416980 > /usr/lib/rsyslog/lmnsd_ptcp.so > > 7f6399bde000-7f6399cdd000 ---p 00004000 09:00 416980 > /usr/lib/rsyslog/lmnsd_ptcp.so > > 7f6399cdd000-7f6399cde000 rw-p 00003000 09:00 416980 > /usr/lib/rsyslog/lmnsd_ptcp.so > > 7f6399cde000-7f6399ce0000 r-xp 00000000 09:00 416981 > /usr/lib/rsyslog/lmtcpclt.so > > 7f6399ce0000-7f6399ddf000 ---p 00002000 09:00 416981 > /usr/lib/rsyslog/lmtcpclt.so > > 7f6399ddf000-7f6399de0000 rw-p 00001000 09:00 416981 > /usr/lib/rsyslog/lmtcpclt.so > > 7f6399de0000-7f6399de3000 r-xp 00000000 09:00 416985 > /usr/lib/rsyslog/lmnetstrms.so > > 7f6399de3000-7f6399ee2000 ---p 00003000 09:00 416985 > /usr/lib/rsyslog/lmnetstrms.so > > 7f6399ee2000-7f6399ee3000 rw-p 00002000 09:00 416985 > /usr/lib/rsyslog/lmnetstrms.so > > 7f6399ee3000-7f6399eed000 r-xp 00000000 09:00 128429 > /lib/libnss_nis-2.7.so > > 7f6399eed000-7f639a0ec000 ---p 0000a000 09:00 128429 > /lib/libnss_nis-2.7.so > > 7f639a0ec000-7f639a0ee000 rw-p 00009000 09:00 128429 > /lib/libnss_nis-2.7.so > > 7f639a0ee000-7f639a103000 r-xp 00000000 09:00 128433 > /lib/libnsl-2.7.so > > 7f639a103000-7f639a302000 ---p 00015000 09:00 128433 > /lib/libnsl-2.7.so > > 7f639a302000-7f639a304000 rw-p 00014000 09:00 128433 > /lib/libnsl-2.7.so > > 7f639a304000-7f639a306000 rw-p 7f639a304000 00:00 0 > > 7f639a306000-7f639a30d000 r-xp 00000000 09:00 128435 > /lib/libnss_compat-2.7.so > > 7f639a30d000-7f639a50c000 ---p 00007000 09:00 128435 > /lib/libnss_compat-2.7.so > > 7f639a50c000-7f639a50e000 rw-p 00006000 09:00 128435 > /lib/libnss_compat-2.7.so > > 7f639a50e000-7f639a513000 r-xp 00000000 09:00 416987 > /usr/lib/rsyslog/imklog.so > > 7f639a513000-7f639a613000 ---p 00005000 09:00 416987 > /usr/lib/rsyslog/imklog.so > > 7f639a613000-7f639a614000 rw-p 00005000 09:00 416987 > /usr/lib/rsyslog/imklog.so > > 7f639a614000-7f639a615000 rw-p 7f639a614000 00:00 0 > > 7f639a615000-7f639a617000 r-xp 00000000 09:00 416978 > /usr/lib/rsyslog/imuxsock.so > > 7f639a617000-7f639a717000 ---p 00002000 09:00 416978 > /usr/lib/rsyslog/imuxsock.so > > 7f639a717000-7f639a718000 rw-p 00002000 09:00 416978 > /usr/lib/rsyslog/imuxsock.so > > 7f639a718000-7f639a722000 r-xp 00000000 09:00 128440 > /lib/libnss_files-2.7.so > > 7f639a722000-7f639a922000 ---p 0000a000 09:00 128440 > /lib/libnss_files-2.7.so > > 7f639a922000-7f639a924000 rw-p 0000a000 09:00 128440 > /lib/libnss_files-2.7.so > > 7f639a924000-7f639aa6e000 r-xp 00000000 09:00 128443 > /lib/libc-2.7.so > > 7f639aa6e000-7f639ac6d000 ---p 0014a000 09:00 128443 > /lib/libc-2.7.so > > 7f639ac6d000-7f639ac70000 r--p 00149000 09:00 128443 > /lib/libc-2.7.so > > 7f639ac70000-7f639ac72000 rw-p 0014c000 09:00 128443 > /lib/libc-2.7.so > > 7f639ac72000-7f639ac77000 rw-p 7f639ac72000 00:00 0 > > 7f639ac77000-7f639ac7f000 r-xp 00000000 09:00 128449 > /lib/librt-2.7.so > > 7f639ac7f000-7f639ae7e000 ---p 00008000 09:00 128449 > /lib/librt-2.7.so > > 7f639ae7e000-7f639ae80000 rw-p 00007000 09:00 128449 > /lib/librt-2.7.so > > 7f639ae80000-7f639ae82000 r-xp 00000000 09:00 128447 > /lib/libdl-2.7.so > > 7f639ae82000-7f639b082000 ---p 00002000 09:00 128447 > /lib/libdl-2.7.so > > 7f639b082000-7f639b084000 rw-p 00002000 09:00 128447 > /lib/libdl-2.7.so > > 7f639b084000-7f639b09a000 r-xp 00000000 09:00 128439 > /lib/libpthread-2.7.so > > 7f639b09a000-7f639b29a000 ---p 00016000 09:00 128439 > /lib/libpthread-2.7.so > > 7f639b29a000-7f639b29c000 rw-p 00016000 09:00 128439 > /lib/libpthread-2.7.so > > 7f639b29c000-7f639b2a0000 rw-p 7f639b29c000 00:00 0 > > 7f639b2a0000-7f639b2b6000 r-xp 00000000 09:00 370185 > /usr/lib/libz.so.1.2.3.3 > > 7f639b2b6000-7f639b4b6000 ---p 00016000 09:00 370185 > /usr/lib/libz.so.1.2.3.3 > > 7f639b4b6000-7f639b4b7000 rw-p 00016000 09:00 370185 > /usr/lib/libz.so.1.2.3.3 > > 7f639b4b7000-7f639b4d3000 r-xp 00000000 09:00 128446 > /lib/ld-2.7.so > > 7f639b5bd000-7f639b5c2000 r-xp 00000000 09:00 416988 > /usr/lib/rsyslog/lmnet.so > > 7f639b5c2000-7f639b6c1000 ---p 00005000 09:00 416988 > /usr/lib/rsyslog/lmnet.so > > 7f639b6c1000-7f639b6c2000 rw-p 00004000 09:00 416988 > /usr/lib/rsyslog/lmnet.so > > 7f639b6c2000-7f639b6c5000 rw-p 7f639b6c2000 00:00 0 > > 7f639b6ce000-7f639b6d2000 rw-p 7f639b6ce000 00:00 0 > > 7f639b6d2000-7f639b6d4000 rw-p 0001b000 09:00 128446 > /lib/ld-2.7.so > > 7fffa36bf000-7fffa36d4000 rw-p 7ffffffea000 00:00 0 > [stack] > > 7fffa36ff000-7fffa3700000 r-xp 7fffa36ff000 00:00 0 > [vdso] > > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 > [vsyscall] > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From lorenzo at sancho.ccd.uniroma2.it Mon Feb 2 17:37:35 2009 From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci) Date: Mon, 2 Feb 2009 17:37:35 +0100 (CET) Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <49871292.9000900@ipax.at> References: <49871292.9000900@ipax.at> Message-ID: Feels familiar. Would you mind sending some more info about your server ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free ? ) I think it is the same stuff that Rainer debugged and solved last week. If you feel so, I think you should try and install a later version. Thank you very much, yours lorenzo On Mon, 2 Feb 2009, Raoul Bhatia [IPAX] wrote: RBI> hi, RBI> RBI> i do not know if this has already been addressed - so sorry for RBI> a possible duplicate. RBI> RBI> revision: RBI> > Feb 2 16:29:58 wc02 kernel: imklog 3.20.0, log source = /proc/kmsg started. RBI> > Feb 2 16:29:58 wc02 rsyslogd: [origin software="rsyslogd" swVersion="3.20.0" x-pid="27617" x-info="http://www.rsyslog.com"] restart RBI> RBI> running on debian logging remotely to another server. RBI> RBI> cheers, RBI> raoul RBI> RBI> > *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** RBI> > ======= Backtrace: ========= RBI> > /lib/libc.so.6[0x7f639a997948] RBI> > /lib/libc.so.6(cfree+0x76)[0x7f639a999a56] RBI> > /usr/sbin/rsyslogd(msgDestruct+0x3c)[0x415f7c] RBI> > /usr/sbin/rsyslogd(actionCallAction+0xcd)[0x4281cd] RBI> > /usr/sbin/rsyslogd[0x409de9] RBI> > /usr/sbin/rsyslogd(llExecFunc+0x58)[0x4168e8] RBI> > /usr/sbin/rsyslogd[0x409ad5] RBI> > /usr/sbin/rsyslogd[0x4244ef] RBI> > /usr/sbin/rsyslogd(wtiWorker+0x24f)[0x42124f] RBI> > /usr/sbin/rsyslogd[0x420968] RBI> > /lib/libpthread.so.0[0x7f639b08afc7] RBI> > /lib/libc.so.6(clone+0x6d)[0x7f639a9f35ad] RBI> > ======= Memory map: ======== RBI> > 00400000-0043c000 r-xp 00000000 09:00 384769 /usr/sbin/rsyslogd RBI> > 0053b000-00540000 rw-p 0003b000 09:00 384769 /usr/sbin/rsyslogd RBI> > 00540000-00541000 rw-p 00540000 00:00 0 RBI> > 00ebc000-00f6e000 rw-p 00ebc000 00:00 0 [heap] RBI> > 40219000-4021a000 ---p 40219000 00:00 0 RBI> > 4021a000-40a1a000 rw-p 4021a000 00:00 0 RBI> > 40c65000-40c66000 ---p 40c65000 00:00 0 RBI> > 40c66000-41466000 rw-p 40c66000 00:00 0 RBI> > 41466000-41467000 ---p 41466000 00:00 0 RBI> > 41467000-41c67000 rw-p 41467000 00:00 0 RBI> > 41cff000-41d00000 ---p 41cff000 00:00 0 RBI> > 41d00000-42500000 rw-p 41d00000 00:00 0 RBI> > 7f638c000000-7f638c021000 rw-p 7f638c000000 00:00 0 RBI> > 7f638c021000-7f6390000000 ---p 7f638c021000 00:00 0 RBI> > 7f6394000000-7f6394021000 rw-p 7f6394000000 00:00 0 RBI> > 7f6394021000-7f6398000000 ---p 7f6394021000 00:00 0 RBI> > 7f63995aa000-7f63995c0000 r-xp 00000000 09:00 128682 /lib/libgcc_s.so.1 RBI> > 7f63995c0000-7f63997c0000 ---p 00016000 09:00 128682 /lib/libgcc_s.so.1 RBI> > 7f63997c0000-7f63997c1000 rw-p 00016000 09:00 128682 /lib/libgcc_s.so.1 RBI> > 7f63997c1000-7f63997d1000 r-xp 00000000 09:00 128437 /lib/libresolv-2.7.so RBI> > 7f63997d1000-7f63999d1000 ---p 00010000 09:00 128437 /lib/libresolv-2.7.so RBI> > 7f63999d1000-7f63999d3000 rw-p 00010000 09:00 128437 /lib/libresolv-2.7.so RBI> > 7f63999d3000-7f63999d5000 rw-p 7f63999d3000 00:00 0 RBI> > 7f63999d5000-7f63999d9000 r-xp 00000000 09:00 128444 /lib/libnss_dns-2.7.so RBI> > 7f63999d9000-7f6399bd8000 ---p 00004000 09:00 128444 /lib/libnss_dns-2.7.so RBI> > 7f6399bd8000-7f6399bda000 rw-p 00003000 09:00 128444 /lib/libnss_dns-2.7.so RBI> > 7f6399bda000-7f6399bde000 r-xp 00000000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so RBI> > 7f6399bde000-7f6399cdd000 ---p 00004000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so RBI> > 7f6399cdd000-7f6399cde000 rw-p 00003000 09:00 416980 /usr/lib/rsyslog/lmnsd_ptcp.so RBI> > 7f6399cde000-7f6399ce0000 r-xp 00000000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so RBI> > 7f6399ce0000-7f6399ddf000 ---p 00002000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so RBI> > 7f6399ddf000-7f6399de0000 rw-p 00001000 09:00 416981 /usr/lib/rsyslog/lmtcpclt.so RBI> > 7f6399de0000-7f6399de3000 r-xp 00000000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so RBI> > 7f6399de3000-7f6399ee2000 ---p 00003000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so RBI> > 7f6399ee2000-7f6399ee3000 rw-p 00002000 09:00 416985 /usr/lib/rsyslog/lmnetstrms.so RBI> > 7f6399ee3000-7f6399eed000 r-xp 00000000 09:00 128429 /lib/libnss_nis-2.7.so RBI> > 7f6399eed000-7f639a0ec000 ---p 0000a000 09:00 128429 /lib/libnss_nis-2.7.so RBI> > 7f639a0ec000-7f639a0ee000 rw-p 00009000 09:00 128429 /lib/libnss_nis-2.7.so RBI> > 7f639a0ee000-7f639a103000 r-xp 00000000 09:00 128433 /lib/libnsl-2.7.so RBI> > 7f639a103000-7f639a302000 ---p 00015000 09:00 128433 /lib/libnsl-2.7.so RBI> > 7f639a302000-7f639a304000 rw-p 00014000 09:00 128433 /lib/libnsl-2.7.so RBI> > 7f639a304000-7f639a306000 rw-p 7f639a304000 00:00 0 RBI> > 7f639a306000-7f639a30d000 r-xp 00000000 09:00 128435 /lib/libnss_compat-2.7.so RBI> > 7f639a30d000-7f639a50c000 ---p 00007000 09:00 128435 /lib/libnss_compat-2.7.so RBI> > 7f639a50c000-7f639a50e000 rw-p 00006000 09:00 128435 /lib/libnss_compat-2.7.so RBI> > 7f639a50e000-7f639a513000 r-xp 00000000 09:00 416987 /usr/lib/rsyslog/imklog.so RBI> > 7f639a513000-7f639a613000 ---p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so RBI> > 7f639a613000-7f639a614000 rw-p 00005000 09:00 416987 /usr/lib/rsyslog/imklog.so RBI> > 7f639a614000-7f639a615000 rw-p 7f639a614000 00:00 0 RBI> > 7f639a615000-7f639a617000 r-xp 00000000 09:00 416978 /usr/lib/rsyslog/imuxsock.so RBI> > 7f639a617000-7f639a717000 ---p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so RBI> > 7f639a717000-7f639a718000 rw-p 00002000 09:00 416978 /usr/lib/rsyslog/imuxsock.so RBI> > 7f639a718000-7f639a722000 r-xp 00000000 09:00 128440 /lib/libnss_files-2.7.so RBI> > 7f639a722000-7f639a922000 ---p 0000a000 09:00 128440 /lib/libnss_files-2.7.so RBI> > 7f639a922000-7f639a924000 rw-p 0000a000 09:00 128440 /lib/libnss_files-2.7.so RBI> > 7f639a924000-7f639aa6e000 r-xp 00000000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639aa6e000-7f639ac6d000 ---p 0014a000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639ac6d000-7f639ac70000 r--p 00149000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639ac70000-7f639ac72000 rw-p 0014c000 09:00 128443 /lib/libc-2.7.so RBI> > 7f639ac72000-7f639ac77000 rw-p 7f639ac72000 00:00 0 RBI> > 7f639ac77000-7f639ac7f000 r-xp 00000000 09:00 128449 /lib/librt-2.7.so RBI> > 7f639ac7f000-7f639ae7e000 ---p 00008000 09:00 128449 /lib/librt-2.7.so RBI> > 7f639ae7e000-7f639ae80000 rw-p 00007000 09:00 128449 /lib/librt-2.7.so RBI> > 7f639ae80000-7f639ae82000 r-xp 00000000 09:00 128447 /lib/libdl-2.7.so RBI> > 7f639ae82000-7f639b082000 ---p 00002000 09:00 128447 /lib/libdl-2.7.so RBI> > 7f639b082000-7f639b084000 rw-p 00002000 09:00 128447 /lib/libdl-2.7.so RBI> > 7f639b084000-7f639b09a000 r-xp 00000000 09:00 128439 /lib/libpthread-2.7.so RBI> > 7f639b09a000-7f639b29a000 ---p 00016000 09:00 128439 /lib/libpthread-2.7.so RBI> > 7f639b29a000-7f639b29c000 rw-p 00016000 09:00 128439 /lib/libpthread-2.7.so RBI> > 7f639b29c000-7f639b2a0000 rw-p 7f639b29c000 00:00 0 RBI> > 7f639b2a0000-7f639b2b6000 r-xp 00000000 09:00 370185 /usr/lib/libz.so.1.2.3.3 RBI> > 7f639b2b6000-7f639b4b6000 ---p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 RBI> > 7f639b4b6000-7f639b4b7000 rw-p 00016000 09:00 370185 /usr/lib/libz.so.1.2.3.3 RBI> > 7f639b4b7000-7f639b4d3000 r-xp 00000000 09:00 128446 /lib/ld-2.7.so RBI> > 7f639b5bd000-7f639b5c2000 r-xp 00000000 09:00 416988 /usr/lib/rsyslog/lmnet.so RBI> > 7f639b5c2000-7f639b6c1000 ---p 00005000 09:00 416988 /usr/lib/rsyslog/lmnet.so RBI> > 7f639b6c1000-7f639b6c2000 rw-p 00004000 09:00 416988 /usr/lib/rsyslog/lmnet.so RBI> > 7f639b6c2000-7f639b6c5000 rw-p 7f639b6c2000 00:00 0 RBI> > 7f639b6ce000-7f639b6d2000 rw-p 7f639b6ce000 00:00 0 RBI> > 7f639b6d2000-7f639b6d4000 rw-p 0001b000 09:00 128446 /lib/ld-2.7.so RBI> > 7fffa36bf000-7fffa36d4000 rw-p 7ffffffea000 00:00 0 [stack] RBI> > 7fffa36ff000-7fffa3700000 r-xp 7fffa36ff000 00:00 0 [vdso] RBI> > ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] RBI> _______________________________________________ RBI> rsyslog mailing list RBI> http://lists.adiscon.net/mailman/listinfo/rsyslog RBI> http://www.rsyslog.com RBI> +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+ From r.bhatia at ipax.at Mon Feb 2 18:02:12 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Mon, 02 Feb 2009 18:02:12 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: References: <49871292.9000900@ipax.at> Message-ID: <49872714.8050901@ipax.at> Lorenzo M. Catucci wrote: > Feels familiar. > > Would you mind sending some more info about your server > ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free ? ) > > I think it is the same stuff that Rainer debugged and solved last week. If > you feel so, I think you should try and install a later version. > > Thank you very much, yours sure, see below. please note that i already rebootet the server. for trying a new release: sure, i have no issue with that. shall i try the one that can be found in sid (3.20.3-1) or a newer one? cheers, raoul > # uname -a > Linux wc02 2.6.27.13 #2 SMP Sat Jan 31 18:32:34 CET 2009 x86_64 GNU/Linux > # cat /proc/cpuinfo > processor : 0 > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > stepping : 6 > cpu MHz : 2993.390 > cache size : 6144 KB > physical id : 0 > siblings : 2 > core id : 0 > cpu cores : 2 > apicid : 0 > initial apicid : 0 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > bogomips : 5986.78 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > > processor : 1 > vendor_id : GenuineIntel > cpu family : 6 > model : 23 > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > stepping : 6 > cpu MHz : 2993.390 > cache size : 6144 KB > physical id : 0 > siblings : 2 > core id : 1 > cpu cores : 2 > apicid : 1 > initial apicid : 1 > fpu : yes > fpu_exception : yes > cpuid level : 10 > wp : yes > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > bogomips : 5986.77 > clflush size : 64 > cache_alignment : 64 > address sizes : 36 bits physical, 48 bits virtual > power management: > # cat /etc/debian_version > 5.0 > # free > total used free shared buffers cached > Mem: 2052076 336392 1715684 0 98580 107268 > -/+ buffers/cache: 130544 1921532 > Swap: 1999992 0 1999992 -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From rgerhards at hq.adiscon.com Mon Feb 2 18:16:17 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 18:16:17 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <49872714.8050901@ipax.at> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Hi Raoul, I don't keep track of the bug in the older releases - simply too much work, especially in this case. The best would be to use v3-stable from git (I have not yet released a tarball as I'd like to get some feedback from the field, first - not too often release stable versions..). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Monday, February 02, 2009 6:02 PM > To: rsyslog-users > Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: > double free or corruption (!prev): 0x0000000000ef03b0 *** > > Lorenzo M. Catucci wrote: > > Feels familiar. > > > > Would you mind sending some more info about your server > > ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free > ? ) > > > > I think it is the same stuff that Rainer debugged and solved last > week. If > > you feel so, I think you should try and install a later version. > > > > Thank you very much, yours > > sure, see below. > > please note that i already rebootet the server. > > for trying a new release: sure, i have no issue with that. shall i try > the one that can be found in sid (3.20.3-1) or a newer one? > > cheers, > raoul > > > # uname -a > > Linux wc02 2.6.27.13 #2 SMP Sat Jan 31 18:32:34 CET 2009 x86_64 > GNU/Linux > > > # cat /proc/cpuinfo > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 23 > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > > stepping : 6 > > cpu MHz : 2993.390 > > cache size : 6144 KB > > physical id : 0 > > siblings : 2 > > core id : 0 > > cpu cores : 2 > > apicid : 0 > > initial apicid : 0 > > fpu : yes > > fpu_exception : yes > > cpuid level : 10 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > > bogomips : 5986.78 > > clflush size : 64 > > cache_alignment : 64 > > address sizes : 36 bits physical, 48 bits virtual > > power management: > > > > processor : 1 > > vendor_id : GenuineIntel > > cpu family : 6 > > model : 23 > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz > > stepping : 6 > > cpu MHz : 2993.390 > > cache size : 6144 KB > > physical id : 0 > > siblings : 2 > > core id : 1 > > cpu cores : 2 > > apicid : 1 > > initial apicid : 1 > > fpu : yes > > fpu_exception : yes > > cpuid level : 10 > > wp : yes > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni monitor > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm > > bogomips : 5986.77 > > clflush size : 64 > > cache_alignment : 64 > > address sizes : 36 bits physical, 48 bits virtual > > power management: > > > # cat /etc/debian_version > > 5.0 > > > > # free > > total used free shared buffers > cached > > Mem: 2052076 336392 1715684 0 98580 > 107268 > > -/+ buffers/cache: 130544 1921532 > > Swap: 1999992 0 1999992 > > -- > ____________________________________________________________________ > DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at > Technischer Leiter > > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at > Barawitzkagasse 10/2/2/11 email. office at ipax.at > 1190 Wien tel. +43 1 3670030 > FN 277995t HG Wien fax. +43 1 3670030 15 > ____________________________________________________________________ > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From lorenzo at sancho.ccd.uniroma2.it Mon Feb 2 18:31:31 2009 From: lorenzo at sancho.ccd.uniroma2.it (Lorenzo M. Catucci) Date: Mon, 2 Feb 2009 18:31:31 +0100 (CET) Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at> <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Message-ID: On Mon, 2 Feb 2009, Rainer Gerhards wrote: RG> Hi Raoul, RG> RG> I don't keep track of the bug in the older releases - simply too much RG> work, especially in this case. The best would be to use v3-stable from RG> git (I have not yet released a tarball as I'd like to get some feedback RG> from the field, first - not too often release stable versions..). RG> RG> Rainer RG> Since I'm git-dumb (I know, it runs (almost) as fast as light, but I still find it too confusing, especially when compared to hg...) I think a quick-recipe could be of use to others too: $ git clone git://git.adiscon.com/git/rsyslog.git rsyslog.git $ cd rsyslog.git $ git checkout origin/v3-stable and now go configure, make, make install... RG> RG> > -----Original Message----- RG> > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- RG> > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] RG> > Sent: Monday, February 02, 2009 6:02 PM RG> > To: rsyslog-users RG> > Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: RG> > double free or corruption (!prev): 0x0000000000ef03b0 *** RG> > RG> > Lorenzo M. Catucci wrote: RG> > > Feels familiar. RG> > > RG> > > Would you mind sending some more info about your server RG> > > ( $ uname -a, $ cat /proc/cpuinfo, $ cat /etc/debian_version, $ free RG> > ? ) RG> > > RG> > > I think it is the same stuff that Rainer debugged and solved last RG> > week. If RG> > > you feel so, I think you should try and install a later version. RG> > > RG> > > Thank you very much, yours RG> > RG> > sure, see below. RG> > RG> > please note that i already rebootet the server. RG> > RG> > for trying a new release: sure, i have no issue with that. shall i try RG> > the one that can be found in sid (3.20.3-1) or a newer one? RG> > RG> > cheers, RG> > raoul RG> > RG> > > # uname -a RG> > > Linux wc02 2.6.27.13 #2 SMP Sat Jan 31 18:32:34 CET 2009 x86_64 RG> > GNU/Linux RG> > RG> > > # cat /proc/cpuinfo RG> > > processor : 0 RG> > > vendor_id : GenuineIntel RG> > > cpu family : 6 RG> > > model : 23 RG> > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz RG> > > stepping : 6 RG> > > cpu MHz : 2993.390 RG> > > cache size : 6144 KB RG> > > physical id : 0 RG> > > siblings : 2 RG> > > core id : 0 RG> > > cpu cores : 2 RG> > > apicid : 0 RG> > > initial apicid : 0 RG> > > fpu : yes RG> > > fpu_exception : yes RG> > > cpuid level : 10 RG> > > wp : yes RG> > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr RG> > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe RG> > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni RG> monitor RG> > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm RG> > > bogomips : 5986.78 RG> > > clflush size : 64 RG> > > cache_alignment : 64 RG> > > address sizes : 36 bits physical, 48 bits virtual RG> > > power management: RG> > > RG> > > processor : 1 RG> > > vendor_id : GenuineIntel RG> > > cpu family : 6 RG> > > model : 23 RG> > > model name : Intel(R) Core(TM)2 Duo CPU E8400 @ 3.00GHz RG> > > stepping : 6 RG> > > cpu MHz : 2993.390 RG> > > cache size : 6144 KB RG> > > physical id : 0 RG> > > siblings : 2 RG> > > core id : 1 RG> > > cpu cores : 2 RG> > > apicid : 1 RG> > > initial apicid : 1 RG> > > fpu : yes RG> > > fpu_exception : yes RG> > > cpuid level : 10 RG> > > wp : yes RG> > > flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr RG> > pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe RG> > syscall lm constant_tsc arch_perfmon pebs bts rep_good nopl pni RG> monitor RG> > ds_cpl vmx smx est tm2 ssse3 cx16 xtpr sse4_1 lahf_lm RG> > > bogomips : 5986.77 RG> > > clflush size : 64 RG> > > cache_alignment : 64 RG> > > address sizes : 36 bits physical, 48 bits virtual RG> > > power management: RG> > RG> > > # cat /etc/debian_version RG> > > 5.0 RG> > RG> > RG> > > # free RG> > > total used free shared buffers RG> > cached RG> > > Mem: 2052076 336392 1715684 0 98580 RG> > 107268 RG> > > -/+ buffers/cache: 130544 1921532 RG> > > Swap: 1999992 0 1999992 RG> > RG> > -- RG> > ____________________________________________________________________ RG> > DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at RG> > Technischer Leiter RG> > RG> > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at RG> > Barawitzkagasse 10/2/2/11 email. office at ipax.at RG> > 1190 Wien tel. +43 1 3670030 RG> > FN 277995t HG Wien fax. +43 1 3670030 15 RG> > ____________________________________________________________________ RG> > _______________________________________________ RG> > rsyslog mailing list RG> > http://lists.adiscon.net/mailman/listinfo/rsyslog RG> > http://www.rsyslog.com RG> _______________________________________________ RG> rsyslog mailing list RG> http://lists.adiscon.net/mailman/listinfo/rsyslog RG> http://www.rsyslog.com RG> +-------------------------+----------------------------------------------+ | Lorenzo M. Catucci | Centro di Calcolo e Documentazione | | catucci at ccd.uniroma2.it | Universit? degli Studi di Roma "Tor Vergata" | | | Via O. Raimondo 18 ** I-00173 ROMA ** ITALY | | Tel. +39 06 7259 2255 | Fax. +39 06 7259 2125 | +-------------------------+----------------------------------------------+ From rgerhards at hq.adiscon.com Mon Feb 2 18:37:34 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 2 Feb 2009 18:37:34 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: References: <49871292.9000900@ipax.at><49872714.8050901@ipax.at><577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FAF2@grfint2.intern.adiscon.com> Thanks, I should have mentioned. But one step missing: > Since I'm git-dumb (I know, it runs (almost) as fast as light, but I > still > find it too confusing, especially when compared to hg...) I think a > quick-recipe could be of use to others too: > > $ git clone git://git.adiscon.com/git/rsyslog.git rsyslog.git > $ cd rsyslog.git > $ git checkout origin/v3-stable > $ autoreconf -vfi # build ./configure > and now go configure, make, make install... From mic at npgx.com.au Tue Feb 3 06:08:07 2009 From: mic at npgx.com.au (Michael Mansour) Date: Tue, 3 Feb 2009 16:08:07 +1100 Subject: [rsyslog] Logging directives for a milter Message-ID: <20090203050119.M91067@npgx.com.au> Hi, I'm using rsyslog 3.18.0 (have been for longer than I can remember now). I have recently installed a milter for sendmail, and the milter docs show: LOGGING milter-regex sends log messages to syslogd(8) using facility daemon and, with increasing verbosity, level err, notice, info and debug. The fol- lowing syslog.conf(5) section can be used to log messages to a dedicated file: !milter-regex daemon.err;daemon.notice /var/log/milter-regex I use rsyslog in TraditionalFileFormat and have this entry: *.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages which captures all the daemon.info messages (a lot of them) into my /var/log/messages. I added the daemon.info to: mail.*;daemon.info -/var/log/maillog so that I would rightly get the messages included into my maillog file, but how do I now remove the messages from my /var/log/messages file with the *.info capturing that there? I've tried using: *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none /var/log/messages but just that line stopped all daemon logging into the messages file, so basically a day passed and nothing was logged there. Thanks. Michael. From hks.private at gmail.com Tue Feb 3 17:12:25 2009 From: hks.private at gmail.com ((private) HKS) Date: Tue, 3 Feb 2009 11:12:25 -0500 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <20090203050119.M91067@npgx.com.au> References: <20090203050119.M91067@npgx.com.au> Message-ID: On Tue, Feb 3, 2009 at 12:08 AM, Michael Mansour wrote: > Hi, > > I'm using rsyslog 3.18.0 (have been for longer than I can remember now). > > I have recently installed a milter for sendmail, and the milter docs show: > > LOGGING > milter-regex sends log messages to syslogd(8) using facility daemon and, > with increasing verbosity, level err, notice, info and debug. The fol- > lowing syslog.conf(5) section can be used to log messages to a dedicated > file: > > !milter-regex > daemon.err;daemon.notice /var/log/milter-regex > > I use rsyslog in TraditionalFileFormat and have this entry: > > *.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages > > which captures all the daemon.info messages (a lot of them) into my > /var/log/messages. > > I added the daemon.info to: > > mail.*;daemon.info -/var/log/maillog > > so that I would rightly get the messages included into my maillog file, but > how do I now remove the messages from my /var/log/messages file with the > *.info capturing that there? > > I've tried using: > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > /var/log/messages > > but just that line stopped all daemon logging into the messages file, so > basically a day passed and nothing was logged there. > > Thanks. > > Michael. > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com Change this: *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none /var/log/messages To this: *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice /var/log/messages -HKS From mic at npgx.com.au Wed Feb 4 01:30:20 2009 From: mic at npgx.com.au (Michael Mansour) Date: Wed, 4 Feb 2009 11:30:20 +1100 Subject: [rsyslog] Logging directives for a milter In-Reply-To: References: <20090203050119.M91067@npgx.com.au> Message-ID: <20090204002209.M97796@npgx.com.au> Hi HKS, Thanks for your reply. > On Tue, Feb 3, 2009 at 12:08 AM, Michael Mansour wrote: > > Hi, > > > > I'm using rsyslog 3.18.0 (have been for longer than I can remember now). > > > > I have recently installed a milter for sendmail, and the milter docs show: > > > > LOGGING > > milter-regex sends log messages to syslogd(8) using facility daemon and, > > with increasing verbosity, level err, notice, info and debug. The fol- > > lowing syslog.conf(5) section can be used to log messages to a dedicated > > file: > > > > !milter-regex > > daemon.err;daemon.notice /var/log/milter-regex > > > > I use rsyslog in TraditionalFileFormat and have this entry: > > > > *.info;mail.none;authpriv.none;cron.none;local1.none /var/log/messages > > > > which captures all the daemon.info messages (a lot of them) into my > > /var/log/messages. > > > > I added the daemon.info to: > > > > mail.*;daemon.info -/var/log/maillog > > > > so that I would rightly get the messages included into my maillog file, but > > how do I now remove the messages from my /var/log/messages file with the > > *.info capturing that there? > > > > I've tried using: > > > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > > /var/log/messages > > > > but just that line stopped all daemon logging into the messages file, so > > basically a day passed and nothing was logged there. > > > > Thanks. > > > > Michael. > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > Change this: > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > /var/log/messages > > To this: > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice > /var/log/messages I've just tried that, restarted rsyslog and the messages for milter-regex keep appearing in /var/log/messages. I'm 100% these are daemon.info messages since I also use: mail.*;daemon.info -/var/log/maillog and the milter-regex messages that show up in /var/log/maillog are the same ones that show up in /var/log/messages. I'm pretty sure the reason that deamon.info is still going to /var/log/messages is because of the "*.info" entry at the beginning of that line, which catches daemon.info? Is there a way I can stop daemon.info from showing up in /var/log/messages while keeping *.info on that same line? Thanks. Michael. > -HKS > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com ------- End of Original Message ------- From kenneho.ndu at gmail.com Wed Feb 4 09:58:54 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 09:58:54 +0100 Subject: [rsyslog] Configuring rsyslog failover Message-ID: Hello list. We're running rsyslog 2.0.6 downloaded from RHN, and are about to set up reliability/failover. I've found two setup tutorials for this: 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer It seems like both setups configure reliable transfer, but using a completely different syntax. Is it so that the former one is the syntax for newer versions of rsyslog? Regards, Kenneth Holter From rgerhards at hq.adiscon.com Wed Feb 4 10:01:48 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 10:01:48 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> Hi Kenneth, the first link does NOT describe a failover case. In the first link, data is queued while the syslogd is not available. A failover case (described in link two) is that if one syslogd goes down, data is sent to another. This is not done in case 1: there, messages are queued while the syslogd is down and sent to *the same syslogd* when it is up again. So no second syslogd involved in case 1, so this is no failover scenario. HTH Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 9:59 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Configuring rsyslog failover > > Hello list. > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to set > up > reliability/failover. I've found two setup tutorials for this: > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > It seems like both setups configure reliable transfer, but using a > completely different syntax. Is it so that the former one is the syntax > for > newer versions of rsyslog? > > Regards, > Kenneth Holter > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 4 10:13:29 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 10:13:29 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> Message-ID: Thanks for the quick reply. You're right, it's not a failover solution by definition. I see now that I should have outlined my needs... What I'm aiming at, at least for now, is a semi-failover solution: If the syslog server (i.e. loghost) goes down, the clients should simply spool the messages until the server gets back online. Back to the examples I linked to: They both seem to provide the functionality I'm looking for. Is that correct? If so: what's the difference between them? On 2/4/09, Rainer Gerhards wrote: > > Hi Kenneth, > > the first link does NOT describe a failover case. In the first link, > data is queued while the syslogd is not available. A failover case > (described in link two) is that if one syslogd goes down, data is sent > to another. This is not done in case 1: there, messages are queued while > the syslogd is down and sent to *the same syslogd* when it is up again. > So no second syslogd involved in case 1, so this is no failover > scenario. > > HTH > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 9:59 AM > > To: rsyslog at lists.adiscon.com > > Subject: [rsyslog] Configuring rsyslog failover > > > > Hello list. > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to set > > up > > reliability/failover. I've found two setup tutorials for this: > > > > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > It seems like both setups configure reliable transfer, but using a > > completely different syntax. Is it so that the former one is the > syntax > > for > > newer versions of rsyslog? > > > > Regards, > > Kenneth Holter > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Wed Feb 4 10:55:51 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 10:55:51 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 10:13 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Thanks for the quick reply. > > You're right, it's not a failover solution by definition. I see now > that I > should have outlined my needs... What I'm aiming at, at least for now, > is a > semi-failover solution: If the syslog server (i.e. loghost) goes down, > the > clients should simply spool the messages until the server gets back > online. > > Back to the examples I linked to: They both seem to provide the > functionality I'm looking for. Is that correct? If so: what's the > difference > between them? No! ;) As I said, #2 is a failover scenario - it does not spool but rather send the messags to another (failover) server if the primary fails. Rainer > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > Hi Kenneth, > > > > the first link does NOT describe a failover case. In the first link, > > data is queued while the syslogd is not available. A failover case > > (described in link two) is that if one syslogd goes down, data is > sent > > to another. This is not done in case 1: there, messages are queued > while > > the syslogd is down and sent to *the same syslogd* when it is up > again. > > So no second syslogd involved in case 1, so this is no failover > > scenario. > > > > HTH > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > To: rsyslog at lists.adiscon.com > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > Hello list. > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to > set > > > up > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > It seems like both setups configure reliable transfer, but using a > > > completely different syntax. Is it so that the former one is the > > syntax > > > for > > > newer versions of rsyslog? > > > > > > Regards, > > > Kenneth Holter > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Wed Feb 4 11:06:08 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 11:06:08 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Oops... and I just noticed you use v2. Spooling is not available in v2. Sorry for not spotting it in the first place... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Wednesday, February 04, 2009 10:56 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 10:13 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > Thanks for the quick reply. > > > > You're right, it's not a failover solution by definition. I see now > > that I > > should have outlined my needs... What I'm aiming at, at least for > now, > > is a > > semi-failover solution: If the syslog server (i.e. loghost) goes > down, > > the > > clients should simply spool the messages until the server gets back > > online. > > > > Back to the examples I linked to: They both seem to provide the > > functionality I'm looking for. Is that correct? If so: what's the > > difference > > between them? > > No! ;) As I said, #2 is a failover scenario - it does not spool but > rather send the messags to another (failover) server if the primary > fails. > > Rainer > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > Hi Kenneth, > > > > > > the first link does NOT describe a failover case. In the first > link, > > > data is queued while the syslogd is not available. A failover case > > > (described in link two) is that if one syslogd goes down, data is > > sent > > > to another. This is not done in case 1: there, messages are queued > > while > > > the syslogd is down and sent to *the same syslogd* when it is up > > again. > > > So no second syslogd involved in case 1, so this is no failover > > > scenario. > > > > > > HTH > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > To: rsyslog at lists.adiscon.com > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > Hello list. > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about to > > set > > > > up > > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > > > > 1. http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > It seems like both setups configure reliable transfer, but using > a > > > > completely different syntax. Is it so that the former one is the > > > syntax > > > > for > > > > newer versions of rsyslog? > > > > > > > > Regards, > > > > Kenneth Holter > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 4 13:42:13 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 13:42:13 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: No prob. :) Then I'm even more puzzled...I've configured my rsyslog client with this setup: ** **.* @@client1.example.com:200 $ActionExecOnlyWhenPreviousIsSuspended on & /var/log/localbuffer $ActionExecOnlyWhenPreviousIsSuspended off* If I cut the link to the syslog-server (using iptables to emulate the logserver being down), run "logger hello" on the client, and then after a while attach the link (by flushing the iptable rules), I see that the hello message pops up on the rsyslog server. So some kind of spooling or something seems to be active. Strange. Maybe the spooling or whatever is done on TCP level or something. Maybe the rsyslog version from RHN differs from the "normal" versioning? On 2/4/09, Rainer Gerhards wrote: > Oops... and I just noticed you use v2. Spooling is not available in v2. > > Sorry for not spotting it in the first place... > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: Wednesday, February 04, 2009 10:56 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > Thanks for the quick reply. > > > > > > You're right, it's not a failover solution by definition. I see now > > > that I > > > should have outlined my needs... What I'm aiming at, at least for > > now, > > > is a > > > semi-failover solution: If the syslog server (i.e. loghost) goes > > down, > > > the > > > clients should simply spool the messages until the server gets back > > > online. > > > > > > Back to the examples I linked to: They both seem to provide the > > > functionality I'm looking for. Is that correct? If so: what's the > > > difference > > > between them? > > > > No! ;) As I said, #2 is a failover scenario - it does not spool but > > rather send the messags to another (failover) server if the primary > > fails. > > > > Rainer > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > Hi Kenneth, > > > > > > > > the first link does NOT describe a failover case. In the first > > link, > > > > data is queued while the syslogd is not available. A failover case > > > > (described in link two) is that if one syslogd goes down, data is > > > sent > > > > to another. This is not done in case 1: there, messages are queued > > > while > > > > the syslogd is down and sent to *the same syslogd* when it is up > > > again. > > > > So no second syslogd involved in case 1, so this is no failover > > > > scenario. > > > > > > > > HTH > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > To: rsyslog at lists.adiscon.com > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about > to > > > set > > > > > up > > > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > > > > > > > 1. > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > It seems like both setups configure reliable transfer, but using > > a > > > > > completely different syntax. Is it so that the former one is the > > > > syntax > > > > > for > > > > > newer versions of rsyslog? > > > > > > > > > > Regards, > > > > > Kenneth Holter > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From kenneho.ndu at gmail.com Wed Feb 4 14:02:50 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 4 Feb 2009 14:02:50 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: It seems like RHN is way behind on adding rsyslog updates to the repo, so it seems like I'm more or less stuck with version 2 for now. Are there any failover/spooling/etc functionality in version 2? I'd like to increase the chance of syslog messages reaching the syslog server, even if it gets offline for a short while. I'm sure it's possible to acheive this by smart (over-)engineering while waiting for rsyslog v3 being released on RHN, but I'm all for simplicity. :) On 2/4/09, Kenneth Holter wrote: > > No prob. :) > > Then I'm even more puzzled...I've configured my rsyslog client with this > setup: > ** > > **.* @@client1.example.com:200 > $ActionExecOnlyWhenPreviousIsSuspended on > & /var/log/localbuffer > $ActionExecOnlyWhenPreviousIsSuspended off* > > > If I cut the link to the syslog-server (using iptables to emulate the > logserver being down), run "logger hello" on the client, and then after a > while attach the link (by flushing the iptable rules), I see that the hello > message pops up on the rsyslog server. So some kind of spooling or something > seems to be active. Strange. Maybe the spooling or whatever is done on TCP > level or something. Maybe the rsyslog version from RHN differs from the > "normal" versioning? > > > > > On 2/4/09, Rainer Gerhards wrote: > > Oops... and I just noticed you use v2. Spooling is not available in v2. > > > > Sorry for not spotting it in the first place... > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > Thanks for the quick reply. > > > > > > > > You're right, it's not a failover solution by definition. I see now > > > > that I > > > > should have outlined my needs... What I'm aiming at, at least for > > > now, > > > > is a > > > > semi-failover solution: If the syslog server (i.e. loghost) goes > > > down, > > > > the > > > > clients should simply spool the messages until the server gets back > > > > online. > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > functionality I'm looking for. Is that correct? If so: what's the > > > > difference > > > > between them? > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool but > > > rather send the messags to another (failover) server if the primary > > > fails. > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > Hi Kenneth, > > > > > > > > > > the first link does NOT describe a failover case. In the first > > > link, > > > > > data is queued while the syslogd is not available. A failover case > > > > > (described in link two) is that if one syslogd goes down, data is > > > > sent > > > > > to another. This is not done in case 1: there, messages are queued > > > > while > > > > > the syslogd is down and sent to *the same syslogd* when it is up > > > > again. > > > > > So no second syslogd involved in case 1, so this is no failover > > > > > scenario. > > > > > > > > > > HTH > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are about > > to > > > > set > > > > > > up > > > > > > reliability/failover. I've found two setup tutorials for this: > > > > > > > > > > > > > > > > > > 1. > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > It seems like both setups configure reliable transfer, but using > > > a > > > > > > completely different syntax. Is it so that the former one is the > > > > > syntax > > > > > > for > > > > > > newer versions of rsyslog? > > > > > > > > > > > > Regards, > > > > > > Kenneth Holter > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > > From rgerhards at hq.adiscon.com Wed Feb 4 14:12:45 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 14:12:45 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB2D@grfint2.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 1:42 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > No prob. :) > > Then I'm even more puzzled...I've configured my rsyslog client with > this > setup: > ** > > **.* @@client1.example.com:200 > $ActionExecOnlyWhenPreviousIsSuspended on > & /var/log/localbuffer > $ActionExecOnlyWhenPreviousIsSuspended off* > > > If I cut the link to the syslog-server (using iptables to emulate the > logserver being down), run "logger hello" on the client, and then after > a > while attach the link (by flushing the iptable rules), I see that the > hello > message pops up on the rsyslog server. So some kind of spooling or > something > seems to be active. Strange. Maybe the spooling or whatever is done on > TCP > level or something. Maybe the rsyslog version from RHN differs from the > "normal" versioning? This has lot's to do with your test environment (you really don't break the link but just make it impossible to send for a period of time), the local tcp send buffer and the way TCP is designed. I suggest to have an in-depth look at http://blog.gerhards.net/2008/04/on-unreliability-of-plain-tcp-syslog.ht ml To do your lab, try to send multiple messages and/or make sure you restart the receiving server while the connection is blocked. You will notice some message loss during that process, this is expected, reasons are in my blog post quoted above. Note that v3 has some improved code to reduce message loss, but in any case there potentially is loss. V2 looses more messages than v3. Rainer > > > > > On 2/4/09, Rainer Gerhards wrote: > > Oops... and I just noticed you use v2. Spooling is not available in > v2. > > > > Sorry for not spotting it in the first place... > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > Thanks for the quick reply. > > > > > > > > You're right, it's not a failover solution by definition. I see > now > > > > that I > > > > should have outlined my needs... What I'm aiming at, at least for > > > now, > > > > is a > > > > semi-failover solution: If the syslog server (i.e. loghost) goes > > > down, > > > > the > > > > clients should simply spool the messages until the server gets > back > > > > online. > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > functionality I'm looking for. Is that correct? If so: what's the > > > > difference > > > > between them? > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool but > > > rather send the messags to another (failover) server if the primary > > > fails. > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > Hi Kenneth, > > > > > > > > > > the first link does NOT describe a failover case. In the first > > > link, > > > > > data is queued while the syslogd is not available. A failover > case > > > > > (described in link two) is that if one syslogd goes down, data > is > > > > sent > > > > > to another. This is not done in case 1: there, messages are > queued > > > > while > > > > > the syslogd is down and sent to *the same syslogd* when it is > up > > > > again. > > > > > So no second syslogd involved in case 1, so this is no failover > > > > > scenario. > > > > > > > > > > HTH > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > about > > to > > > > set > > > > > > up > > > > > > reliability/failover. I've found two setup tutorials for > this: > > > > > > > > > > > > > > > > > > 1. > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > 2. http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > using > > > a > > > > > > completely different syntax. Is it so that the former one is > the > > > > > syntax > > > > > > for > > > > > > newer versions of rsyslog? > > > > > > > > > > > > Regards, > > > > > > Kenneth Holter > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Wed Feb 4 14:14:11 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 4 Feb 2009 14:14:11 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Failover is available - that is done like you described in your last post. But you need to keep an eye on the subtleties, outlined in the response I've written just 2 minutes ago ;). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 2:03 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > It seems like RHN is way behind on adding rsyslog updates to the repo, > so it > seems like I'm more or less stuck with version 2 for now. Are there any > failover/spooling/etc functionality in version 2? I'd like to increase > the > chance of syslog messages reaching the syslog server, even if it gets > offline for a short while. I'm sure it's possible to acheive this by > smart > (over-)engineering while waiting for rsyslog v3 being released on RHN, > but > I'm all for simplicity. :) > > On 2/4/09, Kenneth Holter wrote: > > > > No prob. :) > > > > Then I'm even more puzzled...I've configured my rsyslog client with > this > > setup: > > ** > > > > **.* @@client1.example.com:200 > > $ActionExecOnlyWhenPreviousIsSuspended on > > & /var/log/localbuffer > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > If I cut the link to the syslog-server (using iptables to emulate the > > logserver being down), run "logger hello" on the client, and then > after a > > while attach the link (by flushing the iptable rules), I see that the > hello > > message pops up on the rsyslog server. So some kind of spooling or > something > > seems to be active. Strange. Maybe the spooling or whatever is done > on TCP > > level or something. Maybe the rsyslog version from RHN differs from > the > > "normal" versioning? > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > Oops... and I just noticed you use v2. Spooling is not available in > v2. > > > > > > Sorry for not spotting it in the first place... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > You're right, it's not a failover solution by definition. I see > now > > > > > that I > > > > > should have outlined my needs... What I'm aiming at, at least > for > > > > now, > > > > > is a > > > > > semi-failover solution: If the syslog server (i.e. loghost) > goes > > > > down, > > > > > the > > > > > clients should simply spool the messages until the server gets > back > > > > > online. > > > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > > functionality I'm looking for. Is that correct? If so: what's > the > > > > > difference > > > > > between them? > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > but > > > > rather send the messags to another (failover) server if the > primary > > > > fails. > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > the first link does NOT describe a failover case. In the > first > > > > link, > > > > > > data is queued while the syslogd is not available. A failover > case > > > > > > (described in link two) is that if one syslogd goes down, > data is > > > > > sent > > > > > > to another. This is not done in case 1: there, messages are > queued > > > > > while > > > > > > the syslogd is down and sent to *the same syslogd* when it is > up > > > > > again. > > > > > > So no second syslogd involved in case 1, so this is no > failover > > > > > > scenario. > > > > > > > > > > > > HTH > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > about > > > to > > > > > set > > > > > > > up > > > > > > > reliability/failover. I've found two setup tutorials for > this: > > > > > > > > > > > > > > > > > > > > > 1. > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > 2. > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > using > > > > a > > > > > > > completely different syntax. Is it so that the former one > is the > > > > > > syntax > > > > > > > for > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > Regards, > > > > > > > Kenneth Holter > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Wed Feb 4 12:58:03 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 04 Feb 2009 12:58:03 +0100 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <20090204002209.M97796@npgx.com.au> References: <20090203050119.M91067@npgx.com.au> <20090204002209.M97796@npgx.com.au> Message-ID: <1233748683.19733.113.camel@rf10up.intern.adiscon.com> On Wed, 2009-02-04 at 11:30 +1100, Michael Mansour wrote: > > Change this: > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > > /var/log/messages > > > > To this: > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice > > /var/log/messages > I think it should be *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.none /var/log/messages > I've just tried that, restarted rsyslog and the messages for milter-regex keep > appearing in /var/log/messages. > > I'm 100% these are daemon.info messages since I also use: > > mail.*;daemon.info -/var/log/maillog > > and the milter-regex messages that show up in /var/log/maillog are the same > ones that show up in /var/log/messages. > > I'm pretty sure the reason that deamon.info is still going to > /var/log/messages is because of the "*.info" entry at the beginning of that > line, which catches daemon.info? Yes, because that says "everything with info severity, no matter what the facility is, matches". > > Is there a way I can stop daemon.info from showing up in /var/log/messages > while keeping *.info on that same line? > The .none in my example above is meant to exclude a specific facility from the usual processing and this sounds like what you are looking for. I barely remember that someone had problems with it. So if it does not work, let me know. The part of the code that handles those old-style selectors (old but still good!) is one of the few code sequences that stem directly back to sysklogd and I can't outrule that something went wrong during all that changes of the engine... Please let me know the outcome (saves me the lab). Rainer From danson at rackspace.com Wed Feb 4 17:12:34 2009 From: danson at rackspace.com (Daniel Anson) Date: Wed, 4 Feb 2009 10:12:34 -0600 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Message-ID: <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> I personally run RHEL 5 servers with rsyslog. Due to the lack of a current and stable rsyslog rpm, I always build rsyslog on the server. It takes less than 5 minutes and is very stable. Daniel Anson Rackspace Managed Hosting danson at rackspace.com -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards Sent: Wednesday, February 04, 2009 7:14 AM To: rsyslog-users Subject: Re: [rsyslog] Configuring rsyslog failover Failover is available - that is done like you described in your last post. But you need to keep an eye on the subtleties, outlined in the response I've written just 2 minutes ago ;). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 04, 2009 2:03 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > It seems like RHN is way behind on adding rsyslog updates to the repo, > so it > seems like I'm more or less stuck with version 2 for now. Are there any > failover/spooling/etc functionality in version 2? I'd like to increase > the > chance of syslog messages reaching the syslog server, even if it gets > offline for a short while. I'm sure it's possible to acheive this by > smart > (over-)engineering while waiting for rsyslog v3 being released on RHN, > but > I'm all for simplicity. :) > > On 2/4/09, Kenneth Holter wrote: > > > > No prob. :) > > > > Then I'm even more puzzled...I've configured my rsyslog client with > this > > setup: > > ** > > > > **.* @@client1.example.com:200 > > $ActionExecOnlyWhenPreviousIsSuspended on > > & /var/log/localbuffer > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > If I cut the link to the syslog-server (using iptables to emulate the > > logserver being down), run "logger hello" on the client, and then > after a > > while attach the link (by flushing the iptable rules), I see that the > hello > > message pops up on the rsyslog server. So some kind of spooling or > something > > seems to be active. Strange. Maybe the spooling or whatever is done > on TCP > > level or something. Maybe the rsyslog version from RHN differs from > the > > "normal" versioning? > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > Oops... and I just noticed you use v2. Spooling is not available in > v2. > > > > > > Sorry for not spotting it in the first place... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > You're right, it's not a failover solution by definition. I see > now > > > > > that I > > > > > should have outlined my needs... What I'm aiming at, at least > for > > > > now, > > > > > is a > > > > > semi-failover solution: If the syslog server (i.e. loghost) > goes > > > > down, > > > > > the > > > > > clients should simply spool the messages until the server gets > back > > > > > online. > > > > > > > > > > Back to the examples I linked to: They both seem to provide the > > > > > functionality I'm looking for. Is that correct? If so: what's > the > > > > > difference > > > > > between them? > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > but > > > > rather send the messags to another (failover) server if the > primary > > > > fails. > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > the first link does NOT describe a failover case. In the > first > > > > link, > > > > > > data is queued while the syslogd is not available. A failover > case > > > > > > (described in link two) is that if one syslogd goes down, > data is > > > > > sent > > > > > > to another. This is not done in case 1: there, messages are > queued > > > > > while > > > > > > the syslogd is down and sent to *the same syslogd* when it is > up > > > > > again. > > > > > > So no second syslogd involved in case 1, so this is no > failover > > > > > > scenario. > > > > > > > > > > > > HTH > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > about > > > to > > > > > set > > > > > > > up > > > > > > > reliability/failover. I've found two setup tutorials for > this: > > > > > > > > > > > > > > > > > > > > > 1. > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > 2. > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > using > > > > a > > > > > > > completely different syntax. Is it so that the former one > is the > > > > > > syntax > > > > > > > for > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > Regards, > > > > > > > Kenneth Holter > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From mic at npgx.com.au Thu Feb 5 03:01:58 2009 From: mic at npgx.com.au (Michael Mansour) Date: Thu, 5 Feb 2009 13:01:58 +1100 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <1233748683.19733.113.camel@rf10up.intern.adiscon.com> References: <20090203050119.M91067@npgx.com.au> <20090204002209.M97796@npgx.com.au> <1233748683.19733.113.camel@rf10up.intern.adiscon.com> Message-ID: <20090205015904.M19468@npgx.com.au> Hi Reiner, > On Wed, 2009-02-04 at 11:30 +1100, Michael Mansour wrote: > > > Change this: > > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none > > > /var/log/messages > > > > > > To this: > > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice > > > /var/log/messages > > > > I think it should be > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.none /var/log/messages I've just popped that in. > > I've just tried that, restarted rsyslog and the messages for milter-regex keep > > appearing in /var/log/messages. > > > > I'm 100% these are daemon.info messages since I also use: > > > > mail.*;daemon.info -/var/log/maillog > > > > and the milter-regex messages that show up in /var/log/maillog are the same > > ones that show up in /var/log/messages. > > > > I'm pretty sure the reason that deamon.info is still going to > > /var/log/messages is because of the "*.info" entry at the beginning of that > > line, which catches daemon.info? > > Yes, because that says "everything with info severity, no matter what > the facility is, matches". > > > Is there a way I can stop daemon.info from showing up in /var/log/messages > > while keeping *.info on that same line? > > The .none in my example above is meant to exclude a specific facility > from the usual processing and this sounds like what you are looking for. > I barely remember that someone had problems with it. So if it does > not work, let me know. The part of the code that handles those old-style > selectors (old but still good!) is one of the few code sequences that > stem directly back to sysklogd and I can't outrule that something > went wrong during all that changes of the engine... > > Please let me know the outcome (saves me the lab). I think this is exactly what I'm looking for. So far I see no milter-regex messages in my /var/log/messages file while they are showing up in my /var/log/maillog file. Also, a restart of apache and crond still shows those messages going to /var/log/messages which is what I want. I'll keep monitoring over the next day or so but I think this is what I'm looking for. Thanks mate! Michael. > Rainer > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com ------- End of Original Message ------- From kenneho.ndu at gmail.com Thu Feb 5 09:58:13 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 09:58:13 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Message-ID: Are you referring to the "smart (over-)engineering" way of doing this? In other words, there are no built in support for failover/spooling/etc in rsyslog version 2? On 2/4/09, Rainer Gerhards wrote: > > Failover is available - that is done like you described in your last > post. But you need to keep an eye on the subtleties, outlined in the > response I've written just 2 minutes ago ;). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 2:03 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > It seems like RHN is way behind on adding rsyslog updates to the repo, > > so it > > seems like I'm more or less stuck with version 2 for now. Are there > any > > failover/spooling/etc functionality in version 2? I'd like to increase > > the > > chance of syslog messages reaching the syslog server, even if it gets > > offline for a short while. I'm sure it's possible to acheive this by > > smart > > (over-)engineering while waiting for rsyslog v3 being released on RHN, > > but > > I'm all for simplicity. :) > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > No prob. :) > > > > > > Then I'm even more puzzled...I've configured my rsyslog client with > > this > > > setup: > > > ** > > > > > > **.* @@client1.example.com:200 > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > & /var/log/localbuffer > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > If I cut the link to the syslog-server (using iptables to emulate > the > > > logserver being down), run "logger hello" on the client, and then > > after a > > > while attach the link (by flushing the iptable rules), I see that > the > > hello > > > message pops up on the rsyslog server. So some kind of spooling or > > something > > > seems to be active. Strange. Maybe the spooling or whatever is done > > on TCP > > > level or something. Maybe the rsyslog version from RHN differs from > > the > > > "normal" versioning? > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > Oops... and I just noticed you use v2. Spooling is not available > in > > v2. > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > You're right, it's not a failover solution by definition. I > see > > now > > > > > > that I > > > > > > should have outlined my needs... What I'm aiming at, at least > > for > > > > > now, > > > > > > is a > > > > > > semi-failover solution: If the syslog server (i.e. loghost) > > goes > > > > > down, > > > > > > the > > > > > > clients should simply spool the messages until the server gets > > back > > > > > > online. > > > > > > > > > > > > Back to the examples I linked to: They both seem to provide > the > > > > > > functionality I'm looking for. Is that correct? If so: what's > > the > > > > > > difference > > > > > > between them? > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > > but > > > > > rather send the messags to another (failover) server if the > > primary > > > > > fails. > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > first > > > > > link, > > > > > > > data is queued while the syslogd is not available. A > failover > > case > > > > > > > (described in link two) is that if one syslogd goes down, > > data is > > > > > > sent > > > > > > > to another. This is not done in case 1: there, messages are > > queued > > > > > > while > > > > > > > the syslogd is down and sent to *the same syslogd* when it > is > > up > > > > > > again. > > > > > > > So no second syslogd involved in case 1, so this is no > > failover > > > > > > > scenario. > > > > > > > > > > > > > > HTH > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > > about > > > > to > > > > > > set > > > > > > > > up > > > > > > > > reliability/failover. I've found two setup tutorials for > > this: > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > 2. > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > > using > > > > > a > > > > > > > > completely different syntax. Is it so that the former one > > is the > > > > > > > syntax > > > > > > > > for > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > Regards, > > > > > > > > Kenneth Holter > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 5 11:11:12 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 5 Feb 2009 11:11:12 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> As I said: the second link you posted is failover and it is a supported in v2. So failover *is* available in v2. Queuing is not. > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Thursday, February 05, 2009 9:58 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Are you referring to the "smart (over-)engineering" way of doing this? > In > other words, there are no built in support for failover/spooling/etc in > rsyslog version 2? > > On 2/4/09, Rainer Gerhards wrote: > > > > Failover is available - that is done like you described in your last > > post. But you need to keep an eye on the subtleties, outlined in the > > response I've written just 2 minutes ago ;). > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > It seems like RHN is way behind on adding rsyslog updates to the > repo, > > > so it > > > seems like I'm more or less stuck with version 2 for now. Are there > > any > > > failover/spooling/etc functionality in version 2? I'd like to > increase > > > the > > > chance of syslog messages reaching the syslog server, even if it > gets > > > offline for a short while. I'm sure it's possible to acheive this > by > > > smart > > > (over-)engineering while waiting for rsyslog v3 being released on > RHN, > > > but > > > I'm all for simplicity. :) > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > No prob. :) > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog client > with > > > this > > > > setup: > > > > ** > > > > > > > > **.* @@client1.example.com:200 > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > & /var/log/localbuffer > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to emulate > > the > > > > logserver being down), run "logger hello" on the client, and then > > > after a > > > > while attach the link (by flushing the iptable rules), I see that > > the > > > hello > > > > message pops up on the rsyslog server. So some kind of spooling > or > > > something > > > > seems to be active. Strange. Maybe the spooling or whatever is > done > > > on TCP > > > > level or something. Maybe the rsyslog version from RHN differs > from > > > the > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > Oops... and I just noticed you use v2. Spooling is not > available > > in > > > v2. > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > You're right, it's not a failover solution by definition. I > > see > > > now > > > > > > > that I > > > > > > > should have outlined my needs... What I'm aiming at, at > least > > > for > > > > > > now, > > > > > > > is a > > > > > > > semi-failover solution: If the syslog server (i.e. loghost) > > > goes > > > > > > down, > > > > > > > the > > > > > > > clients should simply spool the messages until the server > gets > > > back > > > > > > > online. > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to provide > > the > > > > > > > functionality I'm looking for. Is that correct? If so: > what's > > > the > > > > > > > difference > > > > > > > between them? > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not > spool > > > but > > > > > > rather send the messags to another (failover) server if the > > > primary > > > > > > fails. > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > wrote: > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > > first > > > > > > link, > > > > > > > > data is queued while the syslogd is not available. A > > failover > > > case > > > > > > > > (described in link two) is that if one syslogd goes down, > > > data is > > > > > > > sent > > > > > > > > to another. This is not done in case 1: there, messages > are > > > queued > > > > > > > while > > > > > > > > the syslogd is down and sent to *the same syslogd* when > it > > is > > > up > > > > > > > again. > > > > > > > > So no second syslogd involved in case 1, so this is no > > > failover > > > > > > > > scenario. > > > > > > > > > > > > > > > > HTH > > > > > > > > Rainer > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and > are > > > about > > > > > to > > > > > > > set > > > > > > > > > up > > > > > > > > > reliability/failover. I've found two setup tutorials > for > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > 2. > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, > but > > > using > > > > > > a > > > > > > > > > completely different syntax. Is it so that the former > one > > > is the > > > > > > > > syntax > > > > > > > > > for > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > Kenneth Holter > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Thu Feb 5 11:31:39 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 11:31:39 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> Message-ID: Sorry, my fault. You said this: "Failover is available - that is done like you described in your last post.", and my post you referred to talked about the engineering stuff. Anyway, the second link I posted describes the failover functionality, but not any specifics how the local buffer is used. Back to my configuration which I posted earlier in the thread: **.* @@server1**.example.com:200* * $ActionExecOnlyWhenPreviousIsSuspended on & /var/log/localbuffer $ActionExecOnlyWhenPreviousIsSuspended off* It is my understanding that messages that doesn't reach the server1 machine will be store in the /var/log/localbuffer file. Can you point me to documentation that explains that happens next with these messages? On 2/5/09, Rainer Gerhards wrote: > As I said: the second link you posted is failover and it is a supported > in v2. So failover *is* available in v2. Queuing is not. > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Thursday, February 05, 2009 9:58 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > Are you referring to the "smart (over-)engineering" way of doing this? > > In > > other words, there are no built in support for failover/spooling/etc > in > > rsyslog version 2? > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > Failover is available - that is done like you described in your last > > > post. But you need to keep an eye on the subtleties, outlined in the > > > response I've written just 2 minutes ago ;). > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > It seems like RHN is way behind on adding rsyslog updates to the > > repo, > > > > so it > > > > seems like I'm more or less stuck with version 2 for now. Are > there > > > any > > > > failover/spooling/etc functionality in version 2? I'd like to > > increase > > > > the > > > > chance of syslog messages reaching the syslog server, even if it > > gets > > > > offline for a short while. I'm sure it's possible to acheive this > > by > > > > smart > > > > (over-)engineering while waiting for rsyslog v3 being released on > > RHN, > > > > but > > > > I'm all for simplicity. :) > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > No prob. :) > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog client > > with > > > > this > > > > > setup: > > > > > ** > > > > > > > > > > **.* @@client1.example.com:200 > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > & /var/log/localbuffer > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > emulate > > > the > > > > > logserver being down), run "logger hello" on the client, and > then > > > > after a > > > > > while attach the link (by flushing the iptable rules), I see > that > > > the > > > > hello > > > > > message pops up on the rsyslog server. So some kind of spooling > > or > > > > something > > > > > seems to be active. Strange. Maybe the spooling or whatever is > > done > > > > on TCP > > > > > level or something. Maybe the rsyslog version from RHN differs > > from > > > > the > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > Oops... and I just noticed you use v2. Spooling is not > > available > > > in > > > > v2. > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > You're right, it's not a failover solution by definition. > I > > > see > > > > now > > > > > > > > that I > > > > > > > > should have outlined my needs... What I'm aiming at, at > > least > > > > for > > > > > > > now, > > > > > > > > is a > > > > > > > > semi-failover solution: If the syslog server (i.e. > loghost) > > > > goes > > > > > > > down, > > > > > > > > the > > > > > > > > clients should simply spool the messages until the server > > gets > > > > back > > > > > > > > online. > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > provide > > > the > > > > > > > > functionality I'm looking for. Is that correct? If so: > > what's > > > > the > > > > > > > > difference > > > > > > > > between them? > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not > > spool > > > > but > > > > > > > rather send the messags to another (failover) server if the > > > > primary > > > > > > > fails. > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > wrote: > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > > > first > > > > > > > link, > > > > > > > > > data is queued while the syslogd is not available. A > > > failover > > > > case > > > > > > > > > (described in link two) is that if one syslogd goes > down, > > > > data is > > > > > > > > sent > > > > > > > > > to another. This is not done in case 1: there, messages > > are > > > > queued > > > > > > > > while > > > > > > > > > the syslogd is down and sent to *the same syslogd* when > > it > > > is > > > > up > > > > > > > > again. > > > > > > > > > So no second syslogd involved in case 1, so this is no > > > > failover > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > [mailto:rsyslog- > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and > > are > > > > about > > > > > > to > > > > > > > > set > > > > > > > > > > up > > > > > > > > > > reliability/failover. I've found two setup tutorials > > for > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > 2. > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, > > but > > > > using > > > > > > > a > > > > > > > > > > completely different syntax. Is it so that the former > > one > > > > is the > > > > > > > > > syntax > > > > > > > > > > for > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > Kenneth Holter > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 5 12:04:28 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 5 Feb 2009 12:04:28 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> I am sorry, but this is going beyond what I can do for free. I'd consider purchasing commercial services. The reason is you try to get things real reliable, but you have lots of constraints and fine subtle issues. There need to be made tradoffs and some tough decisions. All in all, that's a real consulting project. Everything you need to know is fully documented, either in rsyslog, it's code, my blog and even RFCs. I have pointed you to these things. I fully understand that it is not easy to get the big picture from that. It is far from being that, you need to be an expert in syslog to know exactly how to put together those things. Syslog is boring to most (no bashing), so we have few experts on the matter. So if you need to do things in a quite reliable way, it would probably a good idea to task an expert with consulting. I am sorry if that post is rather blunt, but I think it is better we all know where we are. Honestly, I put up a lot of unpaid time into making the project grow. I am also able to give a lot of free support. I am grateful Adiscon pays for this. But please understand that we not also can give away consulting for free - something needs to pay the power, machines - and my lunch! - at the end of the day ;) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Thursday, February 05, 2009 11:32 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Sorry, my fault. You said this: "Failover is available - that is done > like > you described in your last > post.", and my post you referred to talked about the engineering stuff. > > Anyway, the second link I posted describes the failover functionality, > but > not any specifics how the local buffer is used. Back to my > configuration > which I posted earlier in the thread: > > > **.* @@server1**.example.com:200* * > $ActionExecOnlyWhenPreviousIsSuspended on > & /var/log/localbuffer > $ActionExecOnlyWhenPreviousIsSuspended off* > > > It is my understanding that messages that doesn't reach the server1 > machine > will be store in the /var/log/localbuffer file. Can you point me to > documentation that explains that happens next with these messages? > > > > > On 2/5/09, Rainer Gerhards wrote: > > > As I said: the second link you posted is failover and it is a > supported > > in v2. So failover *is* available in v2. Queuing is not. > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Thursday, February 05, 2009 9:58 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > Are you referring to the "smart (over-)engineering" way of doing > this? > > > In > > > other words, there are no built in support for > failover/spooling/etc > > in > > > rsyslog version 2? > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > Failover is available - that is done like you described in your > last > > > > post. But you need to keep an eye on the subtleties, outlined in > the > > > > response I've written just 2 minutes ago ;). > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > It seems like RHN is way behind on adding rsyslog updates to > the > > > repo, > > > > > so it > > > > > seems like I'm more or less stuck with version 2 for now. Are > > there > > > > any > > > > > failover/spooling/etc functionality in version 2? I'd like to > > > increase > > > > > the > > > > > chance of syslog messages reaching the syslog server, even if > it > > > gets > > > > > offline for a short while. I'm sure it's possible to acheive > this > > > by > > > > > smart > > > > > (over-)engineering while waiting for rsyslog v3 being released > on > > > RHN, > > > > > but > > > > > I'm all for simplicity. :) > > > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > > > No prob. :) > > > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog > client > > > with > > > > > this > > > > > > setup: > > > > > > ** > > > > > > > > > > > > **.* @@client1.example.com:200 > > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > > & /var/log/localbuffer > > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > > emulate > > > > the > > > > > > logserver being down), run "logger hello" on the client, and > > then > > > > > after a > > > > > > while attach the link (by flushing the iptable rules), I see > > that > > > > the > > > > > hello > > > > > > message pops up on the rsyslog server. So some kind of > spooling > > > or > > > > > something > > > > > > seems to be active. Strange. Maybe the spooling or whatever > is > > > done > > > > > on TCP > > > > > > level or something. Maybe the rsyslog version from RHN > differs > > > from > > > > > the > > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > Oops... and I just noticed you use v2. Spooling is not > > > available > > > > in > > > > > v2. > > > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > > To: rsyslog-users > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > > To: rsyslog-users > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > > > You're right, it's not a failover solution by > definition. > > I > > > > see > > > > > now > > > > > > > > > that I > > > > > > > > > should have outlined my needs... What I'm aiming at, at > > > least > > > > > for > > > > > > > > now, > > > > > > > > > is a > > > > > > > > > semi-failover solution: If the syslog server (i.e. > > loghost) > > > > > goes > > > > > > > > down, > > > > > > > > > the > > > > > > > > > clients should simply spool the messages until the > server > > > gets > > > > > back > > > > > > > > > online. > > > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > > provide > > > > the > > > > > > > > > functionality I'm looking for. Is that correct? If so: > > > what's > > > > > the > > > > > > > > > difference > > > > > > > > > between them? > > > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not > > > spool > > > > > but > > > > > > > > rather send the messags to another (failover) server if > the > > > > > primary > > > > > > > > fails. > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > > wrote: > > > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In > the > > > > > first > > > > > > > > link, > > > > > > > > > > data is queued while the syslogd is not available. A > > > > failover > > > > > case > > > > > > > > > > (described in link two) is that if one syslogd goes > > down, > > > > > data is > > > > > > > > > sent > > > > > > > > > > to another. This is not done in case 1: there, > messages > > > are > > > > > queued > > > > > > > > > while > > > > > > > > > > the syslogd is down and sent to *the same syslogd* > when > > > it > > > > is > > > > > up > > > > > > > > > again. > > > > > > > > > > So no second syslogd involved in case 1, so this is > no > > > > > failover > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > [mailto:rsyslog- > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > Holter > > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, > and > > > are > > > > > about > > > > > > > to > > > > > > > > > set > > > > > > > > > > > up > > > > > > > > > > > reliability/failover. I've found two setup > tutorials > > > for > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > > 2. > > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable > transfer, > > > but > > > > > using > > > > > > > > a > > > > > > > > > > > completely different syntax. Is it so that the > former > > > one > > > > > is the > > > > > > > > > > syntax > > > > > > > > > > > for > > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > Kenneth Holter > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Thu Feb 5 12:52:37 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 12:52:37 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> Message-ID: I understand completely. :) I'll sure I will find the documentation I need, even though I'm using an aceint version of rsyslog. :) Thanks for the help so far, anyway. On 2/5/09, Rainer Gerhards wrote: > > I am sorry, but this is going beyond what I can do for free. I'd > consider purchasing commercial services. The reason is you try to get > things real reliable, but you have lots of constraints and fine subtle > issues. There need to be made tradoffs and some tough decisions. All in > all, that's a real consulting project. > > Everything you need to know is fully documented, either in rsyslog, it's > code, my blog and even RFCs. I have pointed you to these things. I fully > understand that it is not easy to get the big picture from that. It is > far from being that, you need to be an expert in syslog to know exactly > how to put together those things. Syslog is boring to most (no bashing), > so we have few experts on the matter. So if you need to do things in a > quite reliable way, it would probably a good idea to task an expert with > consulting. > > I am sorry if that post is rather blunt, but I think it is better we all > know where we are. Honestly, I put up a lot of unpaid time into making > the project grow. I am also able to give a lot of free support. I am > grateful Adiscon pays for this. But please understand that we not also > can give away consulting for free - something needs to pay the power, > machines - and my lunch! - at the end of the day ;) > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Thursday, February 05, 2009 11:32 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > Sorry, my fault. You said this: "Failover is available - that is done > > like > > you described in your last > > post.", and my post you referred to talked about the engineering > stuff. > > > > Anyway, the second link I posted describes the failover functionality, > > but > > not any specifics how the local buffer is used. Back to my > > configuration > > which I posted earlier in the thread: > > > > > > **.* @@server1**.example.com:200* * > > $ActionExecOnlyWhenPreviousIsSuspended on > > & /var/log/localbuffer > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > It is my understanding that messages that doesn't reach the server1 > > machine > > will be store in the /var/log/localbuffer file. Can you point me to > > documentation that explains that happens next with these messages? > > > > > > > > > > On 2/5/09, Rainer Gerhards wrote: > > > > > As I said: the second link you posted is failover and it is a > > supported > > > in v2. So failover *is* available in v2. Queuing is not. > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Thursday, February 05, 2009 9:58 AM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > Are you referring to the "smart (over-)engineering" way of doing > > this? > > > > In > > > > other words, there are no built in support for > > failover/spooling/etc > > > in > > > > rsyslog version 2? > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > Failover is available - that is done like you described in your > > last > > > > > post. But you need to keep an eye on the subtleties, outlined in > > the > > > > > response I've written just 2 minutes ago ;). > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > It seems like RHN is way behind on adding rsyslog updates to > > the > > > > repo, > > > > > > so it > > > > > > seems like I'm more or less stuck with version 2 for now. Are > > > there > > > > > any > > > > > > failover/spooling/etc functionality in version 2? I'd like to > > > > increase > > > > > > the > > > > > > chance of syslog messages reaching the syslog server, even if > > it > > > > gets > > > > > > offline for a short while. I'm sure it's possible to acheive > > this > > > > by > > > > > > smart > > > > > > (over-)engineering while waiting for rsyslog v3 being released > > on > > > > RHN, > > > > > > but > > > > > > I'm all for simplicity. :) > > > > > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > > > > > No prob. :) > > > > > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog > > client > > > > with > > > > > > this > > > > > > > setup: > > > > > > > ** > > > > > > > > > > > > > > **.* @@client1.example.com:200 > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > > > & /var/log/localbuffer > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > > > emulate > > > > > the > > > > > > > logserver being down), run "logger hello" on the client, and > > > then > > > > > > after a > > > > > > > while attach the link (by flushing the iptable rules), I see > > > that > > > > > the > > > > > > hello > > > > > > > message pops up on the rsyslog server. So some kind of > > spooling > > > > or > > > > > > something > > > > > > > seems to be active. Strange. Maybe the spooling or whatever > > is > > > > done > > > > > > on TCP > > > > > > > level or something. Maybe the rsyslog version from RHN > > differs > > > > from > > > > > > the > > > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > Oops... and I just noticed you use v2. Spooling is not > > > > available > > > > > in > > > > > > v2. > > > > > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > > > To: rsyslog-users > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > [mailto:rsyslog- > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > > > To: rsyslog-users > > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > > > > > You're right, it's not a failover solution by > > definition. > > > I > > > > > see > > > > > > now > > > > > > > > > > that I > > > > > > > > > > should have outlined my needs... What I'm aiming at, > at > > > > least > > > > > > for > > > > > > > > > now, > > > > > > > > > > is a > > > > > > > > > > semi-failover solution: If the syslog server (i.e. > > > loghost) > > > > > > goes > > > > > > > > > down, > > > > > > > > > > the > > > > > > > > > > clients should simply spool the messages until the > > server > > > > gets > > > > > > back > > > > > > > > > > online. > > > > > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > > > provide > > > > > the > > > > > > > > > > functionality I'm looking for. Is that correct? If so: > > > > what's > > > > > > the > > > > > > > > > > difference > > > > > > > > > > between them? > > > > > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does > not > > > > spool > > > > > > but > > > > > > > > > rather send the messags to another (failover) server if > > the > > > > > > primary > > > > > > > > > fails. > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. In > > the > > > > > > first > > > > > > > > > link, > > > > > > > > > > > data is queued while the syslogd is not available. A > > > > > failover > > > > > > case > > > > > > > > > > > (described in link two) is that if one syslogd goes > > > down, > > > > > > data is > > > > > > > > > > sent > > > > > > > > > > > to another. This is not done in case 1: there, > > messages > > > > are > > > > > > queued > > > > > > > > > > while > > > > > > > > > > > the syslogd is down and sent to *the same syslogd* > > when > > > > it > > > > > is > > > > > > up > > > > > > > > > > again. > > > > > > > > > > > So no second syslogd involved in case 1, so this is > > no > > > > > > failover > > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > > [mailto:rsyslog- > > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > > Holter > > > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, > > and > > > > are > > > > > > about > > > > > > > > to > > > > > > > > > > set > > > > > > > > > > > > up > > > > > > > > > > > > reliability/failover. I've found two setup > > tutorials > > > > for > > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > > > 2. > > > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable > > transfer, > > > > but > > > > > > using > > > > > > > > > a > > > > > > > > > > > > completely different syntax. Is it so that the > > former > > > > one > > > > > > is the > > > > > > > > > > > syntax > > > > > > > > > > > > for > > > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > Kenneth Holter > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 5 13:06:58 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 5 Feb 2009 13:06:58 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB44@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB47@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB4D@grfint2.intern.adiscon.com> > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Thursday, February 05, 2009 12:53 PM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > I understand completely. :) > > I'll sure I will find the documentation I need, even though I'm using > an > aceint version of rsyslog. :) > Keep in mind that each version comes with a complete doc set. Even if that is missing in the package you have, you can download the same version from www.rsyslog.com and look at the included doc. Rainer > > Thanks for the help so far, anyway. > > > On 2/5/09, Rainer Gerhards wrote: > > > > I am sorry, but this is going beyond what I can do for free. I'd > > consider purchasing commercial services. The reason is you try to get > > things real reliable, but you have lots of constraints and fine > subtle > > issues. There need to be made tradoffs and some tough decisions. All > in > > all, that's a real consulting project. > > > > Everything you need to know is fully documented, either in rsyslog, > it's > > code, my blog and even RFCs. I have pointed you to these things. I > fully > > understand that it is not easy to get the big picture from that. It > is > > far from being that, you need to be an expert in syslog to know > exactly > > how to put together those things. Syslog is boring to most (no > bashing), > > so we have few experts on the matter. So if you need to do things in > a > > quite reliable way, it would probably a good idea to task an expert > with > > consulting. > > > > I am sorry if that post is rather blunt, but I think it is better we > all > > know where we are. Honestly, I put up a lot of unpaid time into > making > > the project grow. I am also able to give a lot of free support. I am > > grateful Adiscon pays for this. But please understand that we not > also > > can give away consulting for free - something needs to pay the power, > > machines - and my lunch! - at the end of the day ;) > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Thursday, February 05, 2009 11:32 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > Sorry, my fault. You said this: "Failover is available - that is > done > > > like > > > you described in your last > > > post.", and my post you referred to talked about the engineering > > stuff. > > > > > > Anyway, the second link I posted describes the failover > functionality, > > > but > > > not any specifics how the local buffer is used. Back to my > > > configuration > > > which I posted earlier in the thread: > > > > > > > > > **.* @@server1**.example.com:200* > * > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > & /var/log/localbuffer > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > It is my understanding that messages that doesn't reach the server1 > > > machine > > > will be store in the /var/log/localbuffer file. Can you point me to > > > documentation that explains that happens next with these messages? > > > > > > > > > > > > > > > On 2/5/09, Rainer Gerhards wrote: > > > > > > > As I said: the second link you posted is failover and it is a > > > supported > > > > in v2. So failover *is* available in v2. Queuing is not. > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Thursday, February 05, 2009 9:58 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > Are you referring to the "smart (over-)engineering" way of > doing > > > this? > > > > > In > > > > > other words, there are no built in support for > > > failover/spooling/etc > > > > in > > > > > rsyslog version 2? > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > Failover is available - that is done like you described in > your > > > last > > > > > > post. But you need to keep an eye on the subtleties, outlined > in > > > the > > > > > > response I've written just 2 minutes ago ;). > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Wednesday, February 04, 2009 2:03 PM > > > > > > > To: rsyslog-users > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > It seems like RHN is way behind on adding rsyslog updates > to > > > the > > > > > repo, > > > > > > > so it > > > > > > > seems like I'm more or less stuck with version 2 for now. > Are > > > > there > > > > > > any > > > > > > > failover/spooling/etc functionality in version 2? I'd like > to > > > > > increase > > > > > > > the > > > > > > > chance of syslog messages reaching the syslog server, even > if > > > it > > > > > gets > > > > > > > offline for a short while. I'm sure it's possible to > acheive > > > this > > > > > by > > > > > > > smart > > > > > > > (over-)engineering while waiting for rsyslog v3 being > released > > > on > > > > > RHN, > > > > > > > but > > > > > > > I'm all for simplicity. :) > > > > > > > > > > > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > > > > > > > > > > > No prob. :) > > > > > > > > > > > > > > > > Then I'm even more puzzled...I've configured my rsyslog > > > client > > > > > with > > > > > > > this > > > > > > > > setup: > > > > > > > > ** > > > > > > > > > > > > > > > > **.* @@client1.example.com:200 > > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > > > > > > & /var/log/localbuffer > > > > > > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > > > > > > > > > > > > > > > > If I cut the link to the syslog-server (using iptables to > > > > emulate > > > > > > the > > > > > > > > logserver being down), run "logger hello" on the client, > and > > > > then > > > > > > > after a > > > > > > > > while attach the link (by flushing the iptable rules), I > see > > > > that > > > > > > the > > > > > > > hello > > > > > > > > message pops up on the rsyslog server. So some kind of > > > spooling > > > > > or > > > > > > > something > > > > > > > > seems to be active. Strange. Maybe the spooling or > whatever > > > is > > > > > done > > > > > > > on TCP > > > > > > > > level or something. Maybe the rsyslog version from RHN > > > differs > > > > > from > > > > > > > the > > > > > > > > "normal" versioning? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > wrote: > > > > > > > > > Oops... and I just noticed you use v2. Spooling is not > > > > > available > > > > > > in > > > > > > > v2. > > > > > > > > > > > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog- > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer > Gerhards > > > > > > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > > > > > > To: rsyslog-users > > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > [mailto:rsyslog- > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > Holter > > > > > > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > > > > > > To: rsyslog-users > > > > > > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > > > > > > > > > > > You're right, it's not a failover solution by > > > definition. > > > > I > > > > > > see > > > > > > > now > > > > > > > > > > > that I > > > > > > > > > > > should have outlined my needs... What I'm aiming > at, > > at > > > > > least > > > > > > > for > > > > > > > > > > now, > > > > > > > > > > > is a > > > > > > > > > > > semi-failover solution: If the syslog server (i.e. > > > > loghost) > > > > > > > goes > > > > > > > > > > down, > > > > > > > > > > > the > > > > > > > > > > > clients should simply spool the messages until the > > > server > > > > > gets > > > > > > > back > > > > > > > > > > > online. > > > > > > > > > > > > > > > > > > > > > > Back to the examples I linked to: They both seem to > > > > provide > > > > > > the > > > > > > > > > > > functionality I'm looking for. Is that correct? If > so: > > > > > what's > > > > > > > the > > > > > > > > > > > difference > > > > > > > > > > > between them? > > > > > > > > > > > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does > > not > > > > > spool > > > > > > > but > > > > > > > > > > rather send the messags to another (failover) server > if > > > the > > > > > > > primary > > > > > > > > > > fails. > > > > > > > > > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > > > > > > > > > > > the first link does NOT describe a failover case. > In > > > the > > > > > > > first > > > > > > > > > > link, > > > > > > > > > > > > data is queued while the syslogd is not > available. A > > > > > > failover > > > > > > > case > > > > > > > > > > > > (described in link two) is that if one syslogd > goes > > > > down, > > > > > > > data is > > > > > > > > > > > sent > > > > > > > > > > > > to another. This is not done in case 1: there, > > > messages > > > > > are > > > > > > > queued > > > > > > > > > > > while > > > > > > > > > > > > the syslogd is down and sent to *the same > syslogd* > > > when > > > > > it > > > > > > is > > > > > > > up > > > > > > > > > > > again. > > > > > > > > > > > > So no second syslogd involved in case 1, so this > is > > > no > > > > > > > failover > > > > > > > > > > > > scenario. > > > > > > > > > > > > > > > > > > > > > > > > HTH > > > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > > > > From: rsyslog-bounces at lists.adiscon.com > > > > > [mailto:rsyslog- > > > > > > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth > > > Holter > > > > > > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from > RHN, > > > and > > > > > are > > > > > > > about > > > > > > > > > to > > > > > > > > > > > set > > > > > > > > > > > > > up > > > > > > > > > > > > > reliability/failover. I've found two setup > > > tutorials > > > > > for > > > > > > > this: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > > > > > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > > > > > > 2. > > > > > > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > > > > > > > > > > > It seems like both setups configure reliable > > > transfer, > > > > > but > > > > > > > using > > > > > > > > > > a > > > > > > > > > > > > > completely different syntax. Is it so that the > > > former > > > > > one > > > > > > > is the > > > > > > > > > > > > syntax > > > > > > > > > > > > > for > > > > > > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > Kenneth Holter > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > > > > > rsyslog mailing list > > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > _______________________________________________ > > > > > > > > > > rsyslog mailing list > > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > > > > > > rsyslog mailing list > > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Thu Feb 5 13:38:14 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Thu, 5 Feb 2009 13:38:14 +0100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> Message-ID: Thanks, I'll consider this approach. On 2/4/09, Daniel Anson wrote: > > I personally run RHEL 5 servers with rsyslog. Due to the lack of a > current and stable rsyslog rpm, I always build rsyslog on the server. > It takes less than 5 minutes and is very stable. > > Daniel Anson > Rackspace Managed Hosting > danson at rackspace.com > > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Wednesday, February 04, 2009 7:14 AM > To: rsyslog-users > Subject: Re: [rsyslog] Configuring rsyslog failover > > Failover is available - that is done like you described in your last > post. But you need to keep an eye on the subtleties, outlined in the > response I've written just 2 minutes ago ;). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 04, 2009 2:03 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > It seems like RHN is way behind on adding rsyslog updates to the repo, > > so it > > seems like I'm more or less stuck with version 2 for now. Are there > any > > failover/spooling/etc functionality in version 2? I'd like to increase > > the > > chance of syslog messages reaching the syslog server, even if it gets > > offline for a short while. I'm sure it's possible to acheive this by > > smart > > (over-)engineering while waiting for rsyslog v3 being released on RHN, > > but > > I'm all for simplicity. :) > > > > On 2/4/09, Kenneth Holter wrote: > > > > > > No prob. :) > > > > > > Then I'm even more puzzled...I've configured my rsyslog client with > > this > > > setup: > > > ** > > > > > > **.* @@client1.example.com:200 > > > $ActionExecOnlyWhenPreviousIsSuspended on > > > & /var/log/localbuffer > > > $ActionExecOnlyWhenPreviousIsSuspended off* > > > > > > > > > If I cut the link to the syslog-server (using iptables to emulate > the > > > logserver being down), run "logger hello" on the client, and then > > after a > > > while attach the link (by flushing the iptable rules), I see that > the > > hello > > > message pops up on the rsyslog server. So some kind of spooling or > > something > > > seems to be active. Strange. Maybe the spooling or whatever is done > > on TCP > > > level or something. Maybe the rsyslog version from RHN differs from > > the > > > "normal" versioning? > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > Oops... and I just noticed you use v2. Spooling is not available > in > > v2. > > > > > > > > Sorry for not spotting it in the first place... > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > > > > Sent: Wednesday, February 04, 2009 10:56 AM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Wednesday, February 04, 2009 10:13 AM > > > > > > To: rsyslog-users > > > > > > Subject: Re: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > Thanks for the quick reply. > > > > > > > > > > > > You're right, it's not a failover solution by definition. I > see > > now > > > > > > that I > > > > > > should have outlined my needs... What I'm aiming at, at least > > for > > > > > now, > > > > > > is a > > > > > > semi-failover solution: If the syslog server (i.e. loghost) > > goes > > > > > down, > > > > > > the > > > > > > clients should simply spool the messages until the server gets > > back > > > > > > online. > > > > > > > > > > > > Back to the examples I linked to: They both seem to provide > the > > > > > > functionality I'm looking for. Is that correct? If so: what's > > the > > > > > > difference > > > > > > between them? > > > > > > > > > > No! ;) As I said, #2 is a failover scenario - it does not spool > > but > > > > > rather send the messags to another (failover) server if the > > primary > > > > > fails. > > > > > > > > > > Rainer > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2/4/09, Rainer Gerhards wrote: > > > > > > > > > > > > > > Hi Kenneth, > > > > > > > > > > > > > > the first link does NOT describe a failover case. In the > > first > > > > > link, > > > > > > > data is queued while the syslogd is not available. A > failover > > case > > > > > > > (described in link two) is that if one syslogd goes down, > > data is > > > > > > sent > > > > > > > to another. This is not done in case 1: there, messages are > > queued > > > > > > while > > > > > > > the syslogd is down and sent to *the same syslogd* when it > is > > up > > > > > > again. > > > > > > > So no second syslogd involved in case 1, so this is no > > failover > > > > > > > scenario. > > > > > > > > > > > > > > HTH > > > > > > > Rainer > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > > Sent: Wednesday, February 04, 2009 9:59 AM > > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > > Subject: [rsyslog] Configuring rsyslog failover > > > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > > > > We're running rsyslog 2.0.6 downloaded from RHN, and are > > about > > > > to > > > > > > set > > > > > > > > up > > > > > > > > reliability/failover. I've found two setup tutorials for > > this: > > > > > > > > > > > > > > > > > > > > > > > > 1. > > > > http://www.rsyslog.com/doc-rsyslog_reliable_forwarding.html > > > > > > > > 2. > > http://wiki.rsyslog.com/index.php/FailoverSyslogServer > > > > > > > > > > > > > > > > It seems like both setups configure reliable transfer, but > > using > > > > > a > > > > > > > > completely different syntax. Is it so that the former one > > is the > > > > > > > syntax > > > > > > > > for > > > > > > > > newer versions of rsyslog? > > > > > > > > > > > > > > > > Regards, > > > > > > > > Kenneth Holter > > > > > > > > _______________________________________________ > > > > > > > > rsyslog mailing list > > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > > > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > > > Confidentiality Notice: This e-mail message (including any attached or > embedded documents) is intended for the exclusive and confidential use of > the > individual or entity to which this message is addressed, and unless > otherwise > expressly indicated, is confidential and privileged information of > Rackspace. > Any dissemination, distribution or copying of the enclosed material is > prohibited. > If you receive this transmission in error, please notify us immediately by > e-mail > at abuse at rackspace.com, and delete the original message. > Your cooperation is appreciated. > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Thu Feb 5 16:52:03 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Thu, 5 Feb 2009 15:52:03 +0000 Subject: [rsyslog] logger problem Message-ID: <69544300902050752h5f78e701m4eebc0024d4826b6@mail.gmail.com> hi guys, I have successfully use logger to send messages to syslog. however this works well locally. now i need to send a message to a remote syslog server. i can't see how to do it with logger. let assume that i am sending from IP1 to IP2 how do i go about it. thanks From danson at rackspace.com Thu Feb 5 17:03:19 2009 From: danson at rackspace.com (Daniel Anson) Date: Thu, 5 Feb 2009 10:03:19 -0600 Subject: [rsyslog] logger problem In-Reply-To: <69544300902050752h5f78e701m4eebc0024d4826b6@mail.gmail.com> References: <69544300902050752h5f78e701m4eebc0024d4826b6@mail.gmail.com> Message-ID: <5942_1233849923_n15G5KPn012483_96AF20FDF4301D419B33CCE8E3A0132B0B133AB7@SAT4MX07.RACKSPACE.CORP> Use IP1 as a relay. Put something like this is syslog.conf and restart (HUP) it: *.* @IP2 This will log locally using logger but will relay the log to IP2 as well. I just used *.* but you can specify facility/severity of logs there. --Daniel ANson -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Jules Pagna Disso Sent: Thursday, February 05, 2009 9:52 AM To: rsyslog-users Subject: [rsyslog] logger problem hi guys, I have successfully use logger to send messages to syslog. however this works well locally. now i need to send a message to a remote syslog server. i can't see how to do it with logger. let assume that i am sending from IP1 to IP2 how do i go about it. thanks _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From hks.private at gmail.com Thu Feb 5 17:53:08 2009 From: hks.private at gmail.com ((private) HKS) Date: Thu, 5 Feb 2009 11:53:08 -0500 Subject: [rsyslog] Logging directives for a milter In-Reply-To: <1233748683.19733.113.camel@rf10up.intern.adiscon.com> References: <20090203050119.M91067@npgx.com.au> <20090204002209.M97796@npgx.com.au> <1233748683.19733.113.camel@rf10up.intern.adiscon.com> Message-ID: On Wed, Feb 4, 2009 at 6:58 AM, Rainer Gerhards wrote: > On Wed, 2009-02-04 at 11:30 +1100, Michael Mansour wrote: >> > Change this: >> > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.info.none >> > /var/log/messages >> > >> > To this: >> > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.notice >> > /var/log/messages >> > > I think it should be > > *.info;mail.none;authpriv.none;cron.none;local1.none;daemon.none /var/log/messages > Erp...yes, that's correct. My config would have had all notice+ severity daemon messages going to /var/log/messages (though it should have ignored daemon.debug and daemon.info, right?). Thanks for the correction. -HKS From aoz.syn at gmail.com Fri Feb 6 00:55:06 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 5 Feb 2009 16:55:06 -0700 Subject: [rsyslog] sticky templates Message-ID: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> I'm more feeling things out than requesting a feature, but is there a way to control when templates are evaluated? Say I'd like to name some files with very specific timestamps, but instead of re-evaluating the template every time it receives an event, just re-evaluate whenever rsyslogd has cause to reopen the file. Am I sane? RB From mic at npgx.com.au Fri Feb 6 01:12:25 2009 From: mic at npgx.com.au (Michael Mansour) Date: Fri, 6 Feb 2009 11:12:25 +1100 Subject: [rsyslog] Configuring rsyslog failover In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB20@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB24@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB27@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB2E@grfint2.intern.adiscon.com> <20856_1233764202_n14GGetE022962_96AF20FDF4301D419B33CCE8E3A0132B0B1336C1@SAT4MX07.RACKSPACE.CORP> Message-ID: <20090206000942.M2544@npgx.com.au> Hi Daniel, > Thanks, I'll consider this approach. > > On 2/4/09, Daniel Anson wrote: > > > > I personally run RHEL 5 servers with rsyslog. Due to the lack of a > > current and stable rsyslog rpm, I always build rsyslog on the server. > > It takes less than 5 minutes and is very stable. Have you tried building an RPM of rsyslog yourself? I put the method on how I did it in the rsyslog wiki, and I have 3.x built in RPM and running on various SL 4 servers (RHEL 4 derivatives). I haven't tried SL 5 with rsyslog yet, but you should be able to use my spec to build it. If you get it running, we can make it available to the community. Regards, Michael. > > Daniel Anson > > Rackspace Managed Hosting > > danson at rackspace.com From david at lang.hm Fri Feb 6 03:59:02 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 5 Feb 2009 18:59:02 -0800 (PST) Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> Message-ID: On Thu, 5 Feb 2009, RB wrote: > I'm more feeling things out than requesting a feature, but is there a > way to control when templates are evaluated? Say I'd like to name > some files with very specific timestamps, but instead of re-evaluating > the template every time it receives an event, just re-evaluate > whenever rsyslogd has cause to reopen the file. Am I sane? I could see the use for this sort of thing. David Lang From aoz.syn at gmail.com Fri Feb 6 03:03:51 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 5 Feb 2009 19:03:51 -0700 Subject: [rsyslog] sticky templates In-Reply-To: References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> Message-ID: <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> On Thu, Feb 5, 2009 at 19:59, wrote: >> I'm more feeling things out than requesting a feature, but is there a >> way to control when templates are evaluated? Say I'd like to name >> some files with very specific timestamps, but instead of re-evaluating >> the template every time it receives an event, just re-evaluate >> whenever rsyslogd has cause to reopen the file. Am I sane? > > I could see the use for this sort of thing. The first use-case I had come up with was with an output channel - I know they're scheduled to disappear, but it'd be quite nice to set a size limit for the channel and see the over-limit "resolved" by closing and re-opening. From rgerhards at hq.adiscon.com Fri Feb 6 12:01:12 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 12:01:12 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> Message-ID: <1233918072.19733.160.camel@rf10up.intern.adiscon.com> On Thu, 2009-02-05 at 19:03 -0700, RB wrote: > On Thu, Feb 5, 2009 at 19:59, wrote: > >> I'm more feeling things out than requesting a feature, but is there a > >> way to control when templates are evaluated? Say I'd like to name > >> some files with very specific timestamps, but instead of re-evaluating > >> the template every time it receives an event, just re-evaluate > >> whenever rsyslogd has cause to reopen the file. Am I sane? > > > > I could see the use for this sort of thing. > > The first use-case I had come up with was with an output channel - I > know they're scheduled to disappear, but it'd be quite nice to set a > size limit for the channel and see the over-limit "resolved" by > closing and re-opening. Actually, I think this is the only use case. What we need to look at is when a file is closed. It is closed when there is need to. So, when is there need? There are currently three cases where need arises a) HUP or restart b) output channel max size logic c) change in filename (for dynafiles, only) I think we can ignore a) in this context. I agree that it may be useful in case b). For the time being let's focus on case c): I simplified a bit. Actually, the file is not closed immediately when the file name changes. The file is kept open, in a kind of cache. So when the very same file name is used again, the file descriptor is taken from the cache and there is no need to call open and close APIs (very time consuming). The usual case is that something like HOSTNAME or TAG is used in dynamic filename generation. In these cases, it is quite common that a small set of different filenames is written to. So with the cache logic, we can ensure that we have good performance no matter in what order messages come in (generally, they appear random and thus there is a large probability that the next message will go to a different file on a sufficiently busy system). A file is actually closed only if the cache runs out of space (or cases a) or b) above happen). Now let's think what happens if the dynamic name would not be evaluated. Let's stick with the hostname. We have the following message sequence: Host Msg A M1 A M2 B Ma A M3 B Mb and we have a filename template, for simplicity, that consists of only % HOSTNAME%. What now happens is that with the first message the file "A" is opened. Obviously, messages M1 and M2 are written to file "A". Now, Ma comes in from host B. If the name is newly evaluated, Ma is written to file B. Then, M3 again to file A and Mb to file B. If we do not evaluate the filename template, we have no need to switch files. Consequently, all messages (M1, ..., Mb) are written to file "B". That, however, we could achive without dynafiles at all, for example by doing a simple *.* /A The same happens when you use time-based properties: if you do not reevaluate the file name, you will never switch files, because the name stays always at the (somewhat random) initial value. So IMO this can not be a valid use-case. What you describe in your post (initial case b)) I would call a side-effect. As the file was closed due to size limitation, as a side-effect a new name could be generated. That is of interest because the name conveys the information how long it took to reach the file size. I think a solution to this need could be to emit a log message, telling which file was closed at what time (if an output channel reaches max size). Does this make sense? Or did I misunderstand your intentions? If I got it right, would the proposed new message on max file size (output channel) solve your need? I think that should be fairly easy to add. Looking forward to your replies. Rainer From aoz.syn at gmail.com Fri Feb 6 14:15:56 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 6 Feb 2009 06:15:56 -0700 Subject: [rsyslog] sticky templates In-Reply-To: <1233918072.19733.160.camel@rf10up.intern.adiscon.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> Message-ID: <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> On Fri, Feb 6, 2009 at 04:01, Rainer Gerhards wrote: > The same happens when you use time-based properties: if you do not > reevaluate the file name, you will never switch files, because the name > stays always at the (somewhat random) initial value. > > So IMO this can not be a valid use-case. Put that way, I agree to a point. However, it (case c) can still be of limited utility for environments using 3rd-party post-processing (like logrotate or FS utilization monitors). In those cases, it would be more useful to HUP the writing process prior to beginning and work on essentially cold files rather than the 'smear' you get when working with live files. The concept could definitely be abused as you showed with the host example. > What you describe in your post > (initial case b)) I would call a side-effect. As the file was closed due > to size limitation, as a side-effect a new name could be generated. That > is of interest because the name conveys the information how long it took > to reach the file size. I think a solution to this need could be to emit > a log message, telling which file was closed at what time (if an output > channel reaches max size). I presume that one would have to create an expression-based filter to handle this, but don't directly see how to generate (and retain) a new filename from it. > Does this make sense? Or did I misunderstand your intentions? If I got > it right, would the proposed new message on max file size (output > channel) solve your need? I think that should be fairly easy to add. It does make sense, I'm just not sure how to apply it. Thanks for your thoughts! RB From rgerhards at hq.adiscon.com Fri Feb 6 13:14:12 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 13:14:12 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> Message-ID: <1233922452.19733.166.camel@rf10up.intern.adiscon.com> On Fri, 2009-02-06 at 06:15 -0700, RB wrote: > > What you describe in your post > > (initial case b)) I would call a side-effect. As the file was closed due > > to size limitation, as a side-effect a new name could be generated. That > > is of interest because the name conveys the information how long it took > > to reach the file size. I think a solution to this need could be to emit > > a log message, telling which file was closed at what time (if an output > > channel reaches max size). > > I presume that one would have to create an expression-based filter to > handle this, but don't directly see how to generate (and retain) a new > filename from it. I probably have not understood your use case. What I propose does not change the file name generation. It "just" logs a message telling you that file xxx has reached its maximum at time ttt and a new file is begun. I thought that was your point. So let me ask: why exactly would you like to have a log files like this log-2009-02-06-11-12 log-2009-02-06-17-12 I thought what you would be interested in is that the first file was created at 1112 hrs while the later was created at 1712 hrs. If I get what the point in it is, I may come up with another solution. Rainer From kenneho.ndu at gmail.com Fri Feb 6 15:00:33 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Fri, 6 Feb 2009 15:00:33 +0100 Subject: [rsyslog] Allowing both TLS and plain TCP connections Message-ID: Hi all. In my testbed I've set up rsyslog 2.0.6 with stunnel, and have one quick design question: I want the rsyslog clients to be able to send rsyslog message over both TLS and plain TCP, depending on the client setup. If I set up the rsyslog server to accept stunnel connections on port 61514 (as described in the documentation), it seems like it accepts both TLS and plain TCP. Is there any reasons why I shouldn't set up the clients to forward all traffick to this port, regardless of it being TLS or TCP (or even UDP)? I'm thinking I'd use port 200 for this (the default TCP port). Greets, Kenneth From aoz.syn at gmail.com Fri Feb 6 16:04:39 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 6 Feb 2009 08:04:39 -0700 Subject: [rsyslog] sticky templates In-Reply-To: <1233922452.19733.166.camel@rf10up.intern.adiscon.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> Message-ID: <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> On Fri, Feb 6, 2009 at 05:14, Rainer Gerhards wrote: > So let me ask: why exactly would you like to have a log files like this > > log-2009-02-06-11-12 > log-2009-02-06-17-12 > > I thought what you would be interested in is that the first file was > created at 1112 hrs while the later was created at 1712 hrs. The point wouldn't necessarily be to have timestamped filenames, but to facilitate at-will rotation, either by HUP or by size. I honestly wouldn't care if the filenames just had an incrementing identifier, like a '%$fileno%' property that incremented with each close/reopen cycle (bonus points for skipping already-existing files). Generalizing the problem to the idea of less-dynamic templates was the next step of my thought process and seemed more interesting than just adding another [potentially less reliable and portable] property. > If I get what the point in it is, I may come up with another solution. Again, I'm just brainstorming. If you think it's worthwhile to pursue now, by all means go for it; I'm just trying to find ways to make my life easier. From rgerhards at hq.adiscon.com Fri Feb 6 16:34:38 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 16:34:38 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> Message-ID: <1233934478.19733.177.camel@rf10up.intern.adiscon.com> On Fri, 2009-02-06 at 08:04 -0700, RB wrote: > On Fri, Feb 6, 2009 at 05:14, Rainer Gerhards wrote: > > So let me ask: why exactly would you like to have a log files like this > > > > log-2009-02-06-11-12 > > log-2009-02-06-17-12 > > > > I thought what you would be interested in is that the first file was > > created at 1112 hrs while the later was created at 1712 hrs. > > The point wouldn't necessarily be to have timestamped filenames, but > to facilitate at-will rotation, either by HUP or by size. I honestly > wouldn't care if the filenames just had an incrementing identifier, > like a '%$fileno%' property that incremented with each close/reopen > cycle (bonus points for skipping already-existing files). > Generalizing the problem to the idea of less-dynamic templates was the > next step of my thought process and seemed more interesting than just > adding another [potentially less reliable and portable] property. Ah, OK, I begin to understand. So what you are actually after is kind of a unique file identifier. I have updates for omfile on my mind which would go in a direction that, I think, is close. One of the things is that I would like to enable the output writer to start new files when, for example - a specific period of time has elapsed - a specific file size has been reached - a specific number of messages has been logged ... I intended to work on the size issue first and use the stream class that was originally developed for the queue. That class supports automatic file naming and numbering (that's how the queue files are generated). It can be set to circular logging (used by the queue, with a modul of 1,000,000 if I remember correctly out of my head) or monotonically increasing file numbers (up to the long long modul). Does this go into the same direction? > > > If I get what the point in it is, I may come up with another solution. > > Again, I'm just brainstorming. If you think it's worthwhile to pursue > now, by all means go for it; I'm just trying to find ways to make my > life easier. You are were welcome. The more use cases I know, the easier it is to do things in the right direction when I change something. Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From aoz.syn at gmail.com Fri Feb 6 17:04:54 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 6 Feb 2009 09:04:54 -0700 Subject: [rsyslog] sticky templates In-Reply-To: <1233934478.19733.177.camel@rf10up.intern.adiscon.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> <1233934478.19733.177.camel@rf10up.intern.adiscon.com> Message-ID: <4255c2570902060804r6aea0df1g902cb75f93803b7f@mail.gmail.com> On Fri, Feb 6, 2009 at 08:34, Rainer Gerhards wrote: > I have updates for omfile on my mind which would go in a direction that, > I think, is close. One of the things is that I would like to enable the > output writer to start new files when, for example > > - a specific period of time has elapsed > - a specific file size has been reached > - a specific number of messages has been logged > ... > > I intended to work on the size issue first and use the stream class that > was originally developed for the queue. That class supports automatic > file naming and numbering (that's how the queue files are generated). It > can be set to circular logging (used by the queue, with a modul of > 1,000,000 if I remember correctly out of my head) or monotonically > increasing file numbers (up to the long long modul). > > Does this go into the same direction? It definitely satisfies my original need, particularly if they could eventually be reset on HUP as well. If I have multiple streams logging to a dedicated partition, it would be preferable to have an outside job watching the partition's status and HUP (or similar) rsyslog when it needs to archive and make more space, as opposed to trying to configure each stream's size individually. From rgerhards at hq.adiscon.com Fri Feb 6 16:51:53 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 06 Feb 2009 16:51:53 +0100 Subject: [rsyslog] sticky templates In-Reply-To: <4255c2570902060804r6aea0df1g902cb75f93803b7f@mail.gmail.com> References: <4255c2570902051555g409c08acldf8856fa48e0dad0@mail.gmail.com> <4255c2570902051803w60637378n9c794b30bc6dff66@mail.gmail.com> <1233918072.19733.160.camel@rf10up.intern.adiscon.com> <4255c2570902060515o1049ba0s7f6e760a0c23e115@mail.gmail.com> <1233922452.19733.166.camel@rf10up.intern.adiscon.com> <4255c2570902060704h7d041bcaxf430711a4b851ece@mail.gmail.com> <1233934478.19733.177.camel@rf10up.intern.adiscon.com> <4255c2570902060804r6aea0df1g902cb75f93803b7f@mail.gmail.com> Message-ID: <1233935513.19733.180.camel@rf10up.intern.adiscon.com> On Fri, 2009-02-06 at 09:04 -0700, RB wrote: > On Fri, Feb 6, 2009 at 08:34, Rainer Gerhards wrote: > > I have updates for omfile on my mind which would go in a direction that, > > I think, is close. One of the things is that I would like to enable the > > output writer to start new files when, for example > > > > - a specific period of time has elapsed > > - a specific file size has been reached > > - a specific number of messages has been logged > > ... > > > > I intended to work on the size issue first and use the stream class that > > was originally developed for the queue. That class supports automatic > > file naming and numbering (that's how the queue files are generated). It > > can be set to circular logging (used by the queue, with a modul of > > 1,000,000 if I remember correctly out of my head) or monotonically > > increasing file numbers (up to the long long modul). > > > > Does this go into the same direction? > > It definitely satisfies my original need, particularly if they could > eventually be reset on HUP as well. If I have multiple streams > logging to a dedicated partition, it would be preferable to have an > outside job watching the partition's status and HUP (or similar) > rsyslog when it needs to archive and make more space, as opposed to > trying to configure each stream's size individually. It is not something that I can do immediately, but it sound quite doable. We could also add an "close log if free space is below..." option (which means a cleanup script must be called and a new rollover disabled for n seconds...). I'd appreciate if you could add this to the bugzilla as a feature request. Again, I unfortunately can not do this immediately. Quick status: I am waiting for the race bug dust to settle and then think I will contine to work on performance, as well as straighting out some things that may have caused the HUP fault at David's site. In v4, we already have good performance enhancements, they are just only for UDP so far. This needs to be ported to the other inputs. I expect big savings. Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From friedl at hq.adiscon.com Mon Feb 9 17:53:55 2009 From: friedl at hq.adiscon.com (Florian Riedl) Date: Mon, 9 Feb 2009 17:53:55 +0100 Subject: [rsyslog] rsyslog 3.20.4 (stable) released Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB89@grfint2.intern.adiscon.com> Hi all, rsyslog 3.20.4, a member of the v3-stable branch, has been released today. This is a bug-fixing release. Most importantly, it now contains the fix for the data race we have seen under some circumstances. Feedback so far indicates that this fix, in the other branches, seems to solve the issue (or at least improve the situation very much). As such, it has now also been released for v3-stable. There are also some other, minor, fixes. This is a recommended update for all users of the v3-stable branch. Changelog http://www.rsyslog.com/Article346.phtml Download http://www.rsyslog.com/Downloads-req-viewdownloaddetails-lid-149.phtml As always, feedback is appreciated. Florian Riedl -- Support ======= Improving rsyslog is costly, but you can help! We are looking for organizations that find rsyslog useful and wish to contribute back. You can contribute by reporting bugs, improve the software, or donate money or equipment. Commercial support contracts for rsyslog are available, and they help finance continued maintenance. Adiscon GmbH, a privately held German company, is currently funding rsyslog development. We are always looking for interesting development projects. For details on how to help, please see http://www.rsyslog.com/doc-how2help.html . From rsyslog at clark-communications.com Tue Feb 10 02:29:00 2009 From: rsyslog at clark-communications.com (Don Jackson) Date: Mon, 9 Feb 2009 17:29:00 -0800 Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 References: Message-ID: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> The update to my OpenBSD port file for rsyslog was posted to the ports mailing list today: Begin forwarded message: > From: Don Jackson > Date: February 9, 2009 4:59:10 PM PST > To: ports at openbsd.org > Subject: UPDATE: sysutils/rsyslog-3.20.4 > > > Port updated to the latest 3.20.4 release of rsyslog. > > $ cat ./pkg/DESCR > > A syslogd replacement > > > > > > > From mbiebl at gmail.com Tue Feb 10 02:53:16 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Tue, 10 Feb 2009 02:53:16 +0100 Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 In-Reply-To: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> References: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> Message-ID: 2009/2/10 Don Jackson : > The update to my OpenBSD port file for rsyslog was posted to the ports > mailing list today: > > Begin forwarded message: > >> From: Don Jackson >> Date: February 9, 2009 4:59:10 PM PST >> To: ports at openbsd.org >> Subject: UPDATE: sysutils/rsyslog-3.20.4 >> >> >> Port updated to the latest 3.20.4 release of rsyslog. Cool. Does (Open)BSD compile and run out-of-the-box or do you need any patches? If so, please consider forwarding them upstream for review and inclusion. It would also be nice, if an (Open)BSD expert could take a look at the atomic operations configure check [1]. Apparently that one fails on FreeBSD (dunno about OpenBSD). Cheers, Michael [1] http://bugzilla.adiscon.com/show_bug.cgi?id=112 -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From rgerhards at hq.adiscon.com Tue Feb 10 14:58:06 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 14:58:06 +0100 Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 In-Reply-To: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> References: <1336EBD5-C6A7-4BFF-9999-16F4EFBCC4C8@clark-communications.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB96@grfint2.intern.adiscon.com> Congrats and thanks! Much appreciated! As Michael said, feel free to forward any patches and requests. Rainer PS: I was busy last week and am busy this week, but will become more responsive next week ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Don Jackson > Sent: Tuesday, February 10, 2009 2:29 AM > To: rsyslog-users > Subject: [rsyslog] OpenBSD port UPDATE: sysutils/rsyslog-3.20.4 > > The update to my OpenBSD port file for rsyslog was posted to the ports > mailing list today: > > Begin forwarded message: > > > From: Don Jackson > > Date: February 9, 2009 4:59:10 PM PST > > To: ports at openbsd.org > > Subject: UPDATE: sysutils/rsyslog-3.20.4 > > > > > > Port updated to the latest 3.20.4 release of rsyslog. > > > > $ cat ./pkg/DESCR > > > > A syslogd replacement > > > > > > > > > > > > > > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Tue Feb 10 17:20:37 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Tue, 10 Feb 2009 17:20:37 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? Message-ID: Hello list. I've currently got rsyslog to separate log files based on sending device, as desribed here: http://www.rsyslog.com/Article60.phtml I'd like to filter based on domain, and therefore need the fqdn of each sending device. Is it possible to set up rsyslog to always use fqdn, even if the sending device is on the same domain? From what I've seen in the documentation one can set up rsyslog to always use short names, but not the other way around. I'm using rsyslog v2.0.6. Regards, Kenneth From rgerhards at hq.adiscon.com Tue Feb 10 17:21:21 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 17:21:21 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> I think there is no way to do that in v2 (but I have not checked the docs). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Tuesday, February 10, 2009 5:21 PM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? > > Hello list. > > > I've currently got rsyslog to separate log files based on sending > device, as > desribed here: http://www.rsyslog.com/Article60.phtml > > I'd like to filter based on domain, and therefore need the fqdn of each > sending device. Is it possible to set up rsyslog to always use fqdn, > even if > the sending device is on the same domain? From what I've seen in the > documentation one can set up rsyslog to always use short names, but not > the > other way around. I'm using rsyslog v2.0.6. > > > Regards, > Kenneth > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Tue Feb 10 17:35:43 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Tue, 10 Feb 2009 17:35:43 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> Message-ID: Ok. I've checked the docs, but couldn't see that this was supported. I'll have another look tomorrow. Thanks for the quick response anyway. :) On 2/10/09, Rainer Gerhards wrote: > > I think there is no way to do that in v2 (but I have not checked the > docs). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Tuesday, February 10, 2009 5:21 PM > > To: rsyslog at lists.adiscon.com > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? > > > > Hello list. > > > > > > I've currently got rsyslog to separate log files based on sending > > device, as > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > I'd like to filter based on domain, and therefore need the fqdn of > each > > sending device. Is it possible to set up rsyslog to always use fqdn, > > even if > > the sending device is on the same domain? From what I've seen in the > > documentation one can set up rsyslog to always use short names, but > not > > the > > other way around. I'm using rsyslog v2.0.6. > > > > > > Regards, > > Kenneth > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Feb 10 17:36:43 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 17:36:43 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> As far as I remember, I implemented this recently, so chances are very slim it is in v2. But you may be able to build a patch based on what you find in git... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Tuesday, February 10, 2009 5:36 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > Ok. I've checked the docs, but couldn't see that this was supported. > I'll > have another look tomorrow. > > Thanks for the quick response anyway. :) > > > On 2/10/09, Rainer Gerhards wrote: > > > > I think there is no way to do that in v2 (but I have not checked the > > docs). > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > To: rsyslog at lists.adiscon.com > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > > > > > Hello list. > > > > > > > > > I've currently got rsyslog to separate log files based on sending > > > device, as > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > I'd like to filter based on domain, and therefore need the fqdn of > > each > > > sending device. Is it possible to set up rsyslog to always use > fqdn, > > > even if > > > the sending device is on the same domain? From what I've seen in > the > > > documentation one can set up rsyslog to always use short names, but > > not > > > the > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > Regards, > > > Kenneth > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Feb 10 17:39:52 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 10 Feb 2009 17:39:52 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FB9F@grfint2.intern.adiscon.com> This may be a good starting point: http://git.adiscon.com/?p=rsyslog.git;a=commitdiff;h=60b8ce14bf33e76237c f82dd1f68acc750e64316 > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: Tuesday, February 10, 2009 5:37 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > As far as I remember, I implemented this recently, so chances are very > slim it is in v2. But you may be able to build a patch based on what > you > find in git... > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Tuesday, February 10, 2009 5:36 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Ok. I've checked the docs, but couldn't see that this was supported. > > I'll > > have another look tomorrow. > > > > Thanks for the quick response anyway. :) > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > I think there is no way to do that in v2 (but I have not checked > the > > > docs). > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > To: rsyslog at lists.adiscon.com > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > > > > > Hello list. > > > > > > > > > > > > I've currently got rsyslog to separate log files based on sending > > > > device, as > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > I'd like to filter based on domain, and therefore need the fqdn > of > > > each > > > > sending device. Is it possible to set up rsyslog to always use > > fqdn, > > > > even if > > > > the sending device is on the same domain? From what I've seen in > > the > > > > documentation one can set up rsyslog to always use short names, > but > > > not > > > > the > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > Regards, > > > > Kenneth > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From michaelt at adam.com.au Wed Feb 11 00:08:27 2009 From: michaelt at adam.com.au (Michael Trewartha) Date: Wed, 11 Feb 2009 09:38:27 +1030 Subject: [rsyslog] Windows Events to a rsyslog server? Message-ID: <499208EB.1030608@adam.com.au> Hello, We have a rsyslog server operating which receives all remote syslog messages from our various linux servers so we can centralise tracking of any issues we encounter. We also run some Windows servers, which we would like to configure to send events of Warning and above remotely to our rsyslog server. I've tried using the pre-built executable for Eventlog to Syslog Utility found here: https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but it appears the events aren't sending. Save installing a winsyslog server, is there any methods anyone is aware of to send Windows Events to a remote rsyslog server? From aoz.syn at gmail.com Wed Feb 11 01:59:55 2009 From: aoz.syn at gmail.com (RB) Date: Tue, 10 Feb 2009 17:59:55 -0700 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <499208EB.1030608@adam.com.au> References: <499208EB.1030608@adam.com.au> Message-ID: <4255c2570902101659q3753a679k9cac2639276d0040@mail.gmail.com> On Tue, Feb 10, 2009 at 16:08, Michael Trewartha wrote: > We also run some Windows servers, which we would like to configure to > send events of Warning and above remotely to our rsyslog server. > I've tried using the pre-built executable for Eventlog to Syslog Utility > found here: > https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but > it appears the events aren't sending. > Save installing a winsyslog server, is there any methods anyone is aware > of to send Windows Events to a remote rsyslog server? Have you, perchance, looked at the company that sponsors rsyslog's development? From DGillies at fairfaxdigital.com.au Wed Feb 11 02:05:21 2009 From: DGillies at fairfaxdigital.com.au (David Gillies) Date: Wed, 11 Feb 2009 12:05:21 +1100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <499208EB.1030608@adam.com.au> References: <499208EB.1030608@adam.com.au> Message-ID: <4310250BC419AC46BB47F728902B0DD603B27246@EXCHDP3.ffx.jfh.com.au> I guess Adiscon's Event Reporter could be an option: http://www.eventreporter.com/en/Product/ David Gillies Systems Engineer Digital Infrastructure Services Fairfax Digital -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Michael Trewartha Sent: Wednesday, 11 February 2009 10:08 AM To: rsyslog at lists.adiscon.com Subject: [rsyslog] Windows Events to a rsyslog server? Hello, We have a rsyslog server operating which receives all remote syslog messages from our various linux servers so we can centralise tracking of any issues we encounter. We also run some Windows servers, which we would like to configure to send events of Warning and above remotely to our rsyslog server. I've tried using the pre-built executable for Eventlog to Syslog Utility found here: https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but it appears the events aren't sending. Save installing a winsyslog server, is there any methods anyone is aware of to send Windows Events to a remote rsyslog server? The information contained in this e-mail message and any accompanying files is or may be confidential. If you are not the intended recipient, any use, dissemination, reliance, forwarding, printing or copying of this e-mail or any attached files is unauthorised. This e-mail is subject to copyright. No part of it should be reproduced, adapted or communicated without the written consent of the copyright owner. If you have received this e-mail in error please advise the sender immediately by return e-mail or telephone and delete all copies. Fairfax does not guarantee the accuracy or completeness of any information contained in this e-mail or attached files. Internet communications are not secure, therefore Fairfax does not accept legal responsibility for the contents of this message or attached files. From rgerhards at hq.adiscon.com Wed Feb 11 11:23:00 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 11:23:00 +0100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <499208EB.1030608@adam.com.au> References: <499208EB.1030608@adam.com.au> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> Of course, I also recommend EventReporter[1], not only because it funds rsyslog development, but also because it is the only solution that can really pull everything from every Event Log on any Windows and do this in a format that is compatible between Vista, Win2008 and older Windows releases (this is not a sales plug, I have hard technical facts for that, but I think it is not appropriate to send all of them in reply to this post). Having said this, rsyslog will of course accept messages from any process that emits syslog messages. So I would assume that there is a problem with your sender configuration. Most probably, it is not sending to the right port. Also, a firewall at the sender or the receiver (or both) may block the traffic. HTH Rainer [1] http://www.eventreporter.com > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Michael Trewartha > Sent: Wednesday, February 11, 2009 12:08 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Windows Events to a rsyslog server? > > Hello, > We have a rsyslog server operating which receives all remote syslog > messages from our various linux servers so we can centralise tracking > of > any issues we encounter. > We also run some Windows servers, which we would like to configure to > send events of Warning and above remotely to our rsyslog server. > I've tried using the pre-built executable for Eventlog to Syslog > Utility > found here: > https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but > it appears the events aren't sending. > Save installing a winsyslog server, is there any methods anyone is > aware > of to send Windows Events to a remote rsyslog server? > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 11 11:26:46 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 11 Feb 2009 11:26:46 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> Message-ID: Thanks for the tip. I'll have to discuss this with my colleagues, but since this will probably not be very popular with red hat support I suspect that we'll land on not doing this. :/ On 2/10/09, Rainer Gerhards wrote: > > As far as I remember, I implemented this recently, so chances are very > slim it is in v2. But you may be able to build a patch based on what you > find in git... > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Tuesday, February 10, 2009 5:36 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Ok. I've checked the docs, but couldn't see that this was supported. > > I'll > > have another look tomorrow. > > > > Thanks for the quick response anyway. :) > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > I think there is no way to do that in v2 (but I have not checked the > > > docs). > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > To: rsyslog at lists.adiscon.com > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > > > > > Hello list. > > > > > > > > > > > > I've currently got rsyslog to separate log files based on sending > > > > device, as > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > I'd like to filter based on domain, and therefore need the fqdn of > > > each > > > > sending device. Is it possible to set up rsyslog to always use > > fqdn, > > > > even if > > > > the sending device is on the same domain? From what I've seen in > > the > > > > documentation one can set up rsyslog to always use short names, > but > > > not > > > > the > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > Regards, > > > > Kenneth > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Wed Feb 11 11:27:54 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 11:27:54 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Side-note: if you talk to red hat, ask if they will move over to v3 any time before RHEL 6. I do not have specifics, but I would not outrule such a move. In that case, you'd have only a temporary problem (which may be easier to bear). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Wednesday, February 11, 2009 11:27 AM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > Thanks for the tip. I'll have to discuss this with my colleagues, but > since > this will probably not be very popular with red hat support I suspect > that > we'll land on not doing this. :/ > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > As far as I remember, I implemented this recently, so chances are > very > > slim it is in v2. But you may be able to build a patch based on what > you > > find in git... > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > devices? > > > > > > Ok. I've checked the docs, but couldn't see that this was > supported. > > > I'll > > > have another look tomorrow. > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > I think there is no way to do that in v2 (but I have not checked > the > > > > docs). > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > To: rsyslog at lists.adiscon.com > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > > devices? > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > sending > > > > > device, as > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > I'd like to filter based on domain, and therefore need the fqdn > of > > > > each > > > > > sending device. Is it possible to set up rsyslog to always use > > > fqdn, > > > > > even if > > > > > the sending device is on the same domain? From what I've seen > in > > > the > > > > > documentation one can set up rsyslog to always use short names, > > but > > > > not > > > > > the > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > Regards, > > > > > Kenneth > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Wed Feb 11 12:51:43 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 11 Feb 2009 12:51:43 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Message-ID: I've contacted red hat to see what their rsyslog plans are. :) I'll post back when I hear something. On 2/11/09, Rainer Gerhards wrote: > > Side-note: if you talk to red hat, ask if they will move over to v3 any > time before RHEL 6. I do not have specifics, but I would not outrule > such a move. In that case, you'd have only a temporary problem (which > may be easier to bear). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 11, 2009 11:27 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Thanks for the tip. I'll have to discuss this with my colleagues, but > > since > > this will probably not be very popular with red hat support I suspect > > that > > we'll land on not doing this. :/ > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > As far as I remember, I implemented this recently, so chances are > > very > > > slim it is in v2. But you may be able to build a patch based on what > > you > > > find in git... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > Ok. I've checked the docs, but couldn't see that this was > > supported. > > > > I'll > > > > have another look tomorrow. > > > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > > > I think there is no way to do that in v2 (but I have not checked > > the > > > > > docs). > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > > sending > > > > > > device, as > > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > > > I'd like to filter based on domain, and therefore need the > fqdn > > of > > > > > each > > > > > > sending device. Is it possible to set up rsyslog to always use > > > > fqdn, > > > > > > even if > > > > > > the sending device is on the same domain? From what I've seen > > in > > > > the > > > > > > documentation one can set up rsyslog to always use short > names, > > > but > > > > > not > > > > > > the > > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Kenneth > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From r.bhatia at ipax.at Wed Feb 11 13:55:38 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Wed, 11 Feb 2009 13:55:38 +0100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> References: <499208EB.1030608@adam.com.au> <577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> Message-ID: <4992CACA.2060403@ipax.at> hello rainer, Rainer Gerhards wrote: > Of course, I also recommend EventReporter[1], not only because it funds > rsyslog development, but also because it is the only solution that can > really pull everything from every Event Log on any Windows and do this > in a format that is compatible between Vista, Win2008 and older Windows > releases (this is not a sales plug, I have hard technical facts for > that, but I think it is not appropriate to send all of them in reply to > this post). i wanted to get a quick overview of the eventrepoert prices but failed until i started the "order" process. there i found a kind of confusing interface using abbreviations (i interpreted UI as "User Interface", not "Upgrade Insurance") and a javascript calculator. so: the price for the product is 65 euro for one licence, right? moreover, i am not sure if the purchased version will still work after one year or if the yearly maintenance-plan is obligatory. but visiting your shop for the second time, i think it will continue to work, right? cheers, raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From rgerhards at hq.adiscon.com Wed Feb 11 14:04:35 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 14:04:35 +0100 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <4992CACA.2060403@ipax.at> References: <499208EB.1030608@adam.com.au><577465F99B41C842AAFBE9ED71E70ABA44FBAC@grfint2.intern.adiscon.com> <4992CACA.2060403@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBBB@grfint2.intern.adiscon.com> I am replying to this on-list, further questions will go via private mail (because I guess this is getting off-topic for the rsyslog list ;)) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Wednesday, February 11, 2009 1:56 PM > To: rsyslog-users > Subject: Re: [rsyslog] Windows Events to a rsyslog server? > > hello rainer, > > Rainer Gerhards wrote: > > Of course, I also recommend EventReporter[1], not only because it > funds > > rsyslog development, but also because it is the only solution that > can > > really pull everything from every Event Log on any Windows and do > this > > in a format that is compatible between Vista, Win2008 and older > Windows > > releases (this is not a sales plug, I have hard technical facts for > > that, but I think it is not appropriate to send all of them in reply > to > > this post). > > i wanted to get a quick overview of the eventrepoert prices but failed > until i started the "order" process. > > there i found a kind of confusing interface using abbreviations (i > interpreted UI as "User Interface", not "Upgrade Insurance") and a > javascript calculator. > Will forward that feedback and see what I can do ;) - thanks! > so: the price for the product is 65 euro for one licence, right? In a nutshell - yes, with volume discounts available > moreover, i am not sure if the purchased version will still work after > one year or if the yearly maintenance-plan is obligatory. but visiting > your shop for the second time, i think it will continue to work, right? Yes - licenses are perpetual. The maintenance plan is purely optional. Rainer From kenneho.ndu at gmail.com Wed Feb 11 14:51:14 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Wed, 11 Feb 2009 14:51:14 +0100 Subject: [rsyslog] Using property-based filters to separate log files Message-ID: Hello all. I've read the documentation on property-based filters ( http://www.rsyslog.com/doc-rsyslog_conf_filter.html), and are trying to use this feature combined with file name templating ( http://www.rsyslog.com/Article60.phtml). What I'd like to do is to apply templates to groups of hosts based on their hostname. For example, I'd like to apply template "t1" to hosts such as "test01" and "test02", and template "t2" to hosts "prod01" and "prod02". In other words, different templates should be used based on parts of the file name. To accomplish this I tried this approach: *$template DynaFileTest,"/var/log/syslog/test/system-%HOSTNAME%.log" $template DynaFileProd,"/var/log/syslog/prod/system-%HOSTNAME%.log" * *:HOSTNAME, contains, "test" *.* -?DynaFileTest * *:HOSTNAME, contains, "prod" *.* -?DynaFileProd * This didn't work, so I must have got it wrong. Can anyone point out what I'm doing wrong? Or maybe there are better ways of doing this? Greets, Kenneth From Luis.Fernando.Munoz.Mejias at cern.ch Wed Feb 11 14:59:19 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Wed, 11 Feb 2009 14:59:19 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? Message-ID: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Hello, world! I'm trying to store my logs centrally on an Oracle database. I need it to be Oracle. Due to some restrictions around there, I can't use the recommended version of libdbi, but an older one that is not working with rsyslog. I can't rebuild that RPM, and I have no influence on the upgrade process or schedule. Finally, I also need something with *excellent* performance, and the documentation states omlibdbi doesn't perform as well as other DB-related modules, so I decided to try my own small set of input and output modules. So, my question is: is there any documentation or guide for writing modules, something that gives some insight of what all those macros (BEGINcreateInstance, CODESTARTcreateInstance, etc, etc, etc) I see mean? Do I need to grep the code for that? I've googled for it and reviewed the Git repository, but found nothing. Thanks in advance. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From rgerhards at hq.adiscon.com Wed Feb 11 15:08:14 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 15:08:14 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: <1234361294.19733.230.camel@rf10up.intern.adiscon.com> Hi Luis Fernando, glad you asked :) The documentation is ... well... not much ;) The best thing is probably to start with the existing MySQL module. HOWEVER, I myself would be very interested in a native, high-performing Oracle driver. I neither have the expertise to do it not the test environment. If you like, we could collaborate on this effort. I'd create a skeleton output module for you, guide you through using it and you provide the Oracle bits to it (that should be fairly easy). Of course, that means your module would need to be contributed back to the project. What do you think about this? Rainer On Wed, 2009-02-11 at 14:59 +0100, Luis Fernando Mu?oz Mej?as wrote: > Hello, world! > > I'm trying to store my logs centrally on an Oracle database. I need it > to be Oracle. > > Due to some restrictions around there, I can't use the recommended > version of libdbi, but an older one that is not working with rsyslog. I > can't rebuild that RPM, and I have no influence on the upgrade process > or schedule. > > Finally, I also need something with *excellent* performance, and the > documentation states omlibdbi doesn't perform as well as other > DB-related modules, so I decided to try my own small set of input and > output modules. > > So, my question is: is there any documentation or guide for writing > modules, something that gives some insight of what all those macros > (BEGINcreateInstance, CODESTARTcreateInstance, etc, etc, etc) I see > mean? Do I need to grep the code for that? > > I've googled for it and reviewed the Git repository, but found nothing. > > Thanks in advance. From david at lang.hm Wed Feb 11 16:31:29 2009 From: david at lang.hm (david at lang.hm) Date: Wed, 11 Feb 2009 07:31:29 -0800 (PST) Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: On Wed, 11 Feb 2009, Luis Fernando Mu?oz Mej?as wrote: > Finally, I also need something with *excellent* performance, and the > documentation states omlibdbi doesn't perform as well as other > DB-related modules, so I decided to try my own small set of input and > output modules. one major limitation you will run into is that rsyslog proceses log entries one at a time. this means that each log entry inserted into the oracle database will be a seperate transaction. changing this is a fairly major task that will require someone to sponser it (I've asked about this in the past, but my company has not needed the performance enough to do this yet) David Lang From jules at visionintel.com Wed Feb 11 19:49:31 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Wed, 11 Feb 2009 18:49:31 +0000 Subject: [rsyslog] Windows Events to a rsyslog server? In-Reply-To: <4310250BC419AC46BB47F728902B0DD603B27246@EXCHDP3.ffx.jfh.com.au> References: <499208EB.1030608@adam.com.au> <4310250BC419AC46BB47F728902B0DD603B27246@EXCHDP3.ffx.jfh.com.au> Message-ID: <69544300902111049p1b213e88m6fb7b05670347032@mail.gmail.com> you can send remote message to syslog by changing the rsyslog.conf # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional *.* @@192.168.15.103:514 # ### end of the forwarding rule ### You need to specify the IP and port where you are sending your logs. basically, you send it locally and syslog will forward them for you. Jules 2009/2/11 David Gillies > I guess Adiscon's Event Reporter could be an option: > > http://www.eventreporter.com/en/Product/ > > David Gillies > Systems Engineer > Digital Infrastructure Services > Fairfax Digital > > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Michael > Trewartha > Sent: Wednesday, 11 February 2009 10:08 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] Windows Events to a rsyslog server? > > Hello, > We have a rsyslog server operating which receives all remote syslog > messages from our various linux servers so we can centralise tracking of > any issues we encounter. > We also run some Windows servers, which we would like to configure to > send events of Warning and above remotely to our rsyslog server. > I've tried using the pre-built executable for Eventlog to Syslog Utility > found here: > https://engineering.purdue.edu/ECN/Resources/Documents/UNIX/evtsys but > it appears the events aren't sending. > Save installing a winsyslog server, is there any methods anyone is aware > of to send Windows Events to a remote rsyslog server? > > The information contained in this e-mail message and any accompanying files > is or may be confidential. If you are not the intended recipient, any use, > dissemination, reliance, forwarding, printing or copying of this e-mail or > any attached files is unauthorised. This e-mail is subject to copyright. No > part of it should be reproduced, adapted or communicated without the written > consent of the copyright owner. If you have received this e-mail in error > please advise the sender immediately by return e-mail or telephone and > delete all copies. Fairfax does not guarantee the accuracy or completeness > of any information contained in this e-mail or attached files. Internet > communications are not secure, therefore Fairfax does not accept legal > responsibility for the contents of this message or attached files. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Wed Feb 11 19:53:08 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Wed, 11 Feb 2009 18:53:08 +0000 Subject: [rsyslog] rsyslog.conf Message-ID: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> Giving that one can change the IP in the rsconfig.conf to send a log remotely, would they be an easy way, or what would be the best approach to change the config file programatically so that IP can be update whenever wanted. thanks, From aoz.syn at gmail.com Wed Feb 11 20:22:32 2009 From: aoz.syn at gmail.com (RB) Date: Wed, 11 Feb 2009 12:22:32 -0700 Subject: [rsyslog] rsyslog.conf In-Reply-To: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> Message-ID: <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso wrote: > Giving that one can change the IP in the rsconfig.conf to send a log > remotely, would they be an easy way, or what would be the best approach to > change the config file programatically so that IP can be update whenever > wanted. Use DNS. There are nearly infinite of ways to programmatically replace FOO with BAR in a text file, but changing the file requires a HUP or restart for an already-running instance of rsyslog, which is inelegant. If you're trying to point to multiple hosts, either float a virtual IP among them or point at a DNS record you can move among hosts. From rgerhards at hq.adiscon.com Wed Feb 11 20:39:23 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 20:39:23 +0100 Subject: [rsyslog] rsyslog.conf Message-ID: <001201c98c80$6b86f89a$060013ac@intern.adiscon.com> >From the phone: You need to be careful - dns changes will most probably not affect the running instance immediately. So IMHO the virtual IP is the best solution. rainer ----- Urspr?ngliche Nachricht ----- Von: "RB" An: "rsyslog-users" Gesendet: 11.02.09 20:21 Betreff: Re: [rsyslog] rsyslog.conf On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso wrote: > Giving that one can change the IP in the rsconfig.conf to send a log > remotely, would they be an easy way, or what would be the best approach to > change the config file programatically so that IP can be update whenever > wanted. Use DNS. There are nearly infinite of ways to programmatically replace FOO with BAR in a text file, but changing the file requires a HUP or restart for an already-running instance of rsyslog, which is inelegant. If you're trying to point to multiple hosts, either float a virtual IP among them or point at a DNS record you can move among hosts. _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From jmoyer at redhat.com Wed Feb 11 21:53:59 2009 From: jmoyer at redhat.com (Jeff Moyer) Date: Wed, 11 Feb 2009 15:53:59 -0500 Subject: [rsyslog] [RFC] add an option to buffer masked syslog messages Message-ID: Hi, folks, I posed this question on the libc-alpha mailing list [1]: I was about to start writing support for bufferring debug messages in autofs, when it occurred to me that this is a fairly useful thing to do, and it makes little sense for every application to reinvent the wheel. What I'd like is to have a fixed size ring buffer to which messages that are masked are logged. Then, if the application asks for these messages, dump them to the log. The reason, if it isn't obvious, is so that we can dump application state should a problem present itself when debug logging is disabled. What do folks think about this? Is it better accomplished elsewhere? The response I got was that (at least Roland thinks) this should be done in the syslog daemon, not in the library. So, I'll pose the same question here, and I look forward to hearing your thoughts. Cheers, Jeff [1] http://sourceware.org/ml/libc-alpha/2009-02/msg00036.html From jules at visionintel.com Wed Feb 11 22:14:41 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Wed, 11 Feb 2009 21:14:41 +0000 Subject: [rsyslog] rsyslog.conf In-Reply-To: <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> Message-ID: <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> well, I am not trying to point to multiple addresses at the same time, but i am in an environment where the IP could change every 10min or 15 min. 2009/2/11 RB > On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso > wrote: > > Giving that one can change the IP in the rsconfig.conf to send a log > > remotely, would they be an easy way, or what would be the best approach > to > > change the config file programatically so that IP can be update whenever > > wanted. > > Use DNS. There are nearly infinite of ways to programmatically > replace FOO with BAR in a text file, but changing the file requires a > HUP or restart for an already-running instance of rsyslog, which is > inelegant. If you're trying to point to multiple hosts, either float > a virtual IP among them or point at a DNS record you can move among > hosts. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Wed Feb 11 22:22:47 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 11 Feb 2009 22:22:47 +0100 Subject: [rsyslog] rsyslog.conf In-Reply-To: <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com><4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBC7@grfint2.intern.adiscon.com> On this time window, I think you can not get around issuing a restart-type HUP. As this needs to be synchronised in any case, you'll probably need a script, so you could also write a file that contains the new IP in question. I suggest one extra file that then is included via $IncludeConfig from the main rsyslog.conf. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Jules > Pagna Disso > Sent: Wednesday, February 11, 2009 10:15 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog.conf > > well, > > I am not trying to point to multiple addresses at the same > time, but i am in > an environment where the IP could change every 10min or 15 min. > > 2009/2/11 RB > > > On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso > > > wrote: > > > Giving that one can change the IP in the rsconfig.conf to > send a log > > > remotely, would they be an easy way, or what would be the > best approach > > to > > > change the config file programatically so that IP can be > update whenever > > > wanted. > > > > Use DNS. There are nearly infinite of ways to programmatically > > replace FOO with BAR in a text file, but changing the file > requires a > > HUP or restart for an already-running instance of rsyslog, which is > > inelegant. If you're trying to point to multiple hosts, > either float > > a virtual IP among them or point at a DNS record you can move among > > hosts. > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Thu Feb 12 01:28:08 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Thu, 12 Feb 2009 00:28:08 +0000 Subject: [rsyslog] rsyslog.conf In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBC7@grfint2.intern.adiscon.com> References: <69544300902111053j47c6b865i3d23278fc7627d06@mail.gmail.com> <4255c2570902111122x1ec00312m73914cd6219f0f74@mail.gmail.com> <69544300902111314o36302e57ie97821e4d91b6f62@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FBC7@grfint2.intern.adiscon.com> Message-ID: <69544300902111628y262c769et5d8c6b712714fb42@mail.gmail.com> i came accross this syslogd that supports remote loggin. any one used it before? i was trying to install in on my Fedora 10 but i got the conflictual message with syslog-ng. it seems as if it's either or. http://linux.about.com/od/commands/l/blcmdl8_syslogd.htm hope this help for remote logging but again, remember to set the remote host so that he can accept remote messages. http://www.linuxhomenetworking.com/wiki/index.php/Quick_HOWTO_:_Ch05_:_Troubleshooting_Linux_with_syslog thanks 2009/2/11 Rainer Gerhards > On this time window, I think you can not get around issuing a > restart-type HUP. As this needs to be synchronised in any case, you'll > probably need a script, so you could also write a file that contains the > new IP in question. I suggest one extra file that then is included via > $IncludeConfig from the main rsyslog.conf. > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com > > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Jules > > Pagna Disso > > Sent: Wednesday, February 11, 2009 10:15 PM > > To: rsyslog-users > > Subject: Re: [rsyslog] rsyslog.conf > > > > well, > > > > I am not trying to point to multiple addresses at the same > > time, but i am in > > an environment where the IP could change every 10min or 15 min. > > > > 2009/2/11 RB > > > > > On Wed, Feb 11, 2009 at 11:53, Jules Pagna Disso > > > > > wrote: > > > > Giving that one can change the IP in the rsconfig.conf to > > send a log > > > > remotely, would they be an easy way, or what would be the > > best approach > > > to > > > > change the config file programatically so that IP can be > > update whenever > > > > wanted. > > > > > > Use DNS. There are nearly infinite of ways to programmatically > > > replace FOO with BAR in a text file, but changing the file > > requires a > > > HUP or restart for an already-running instance of rsyslog, which is > > > inelegant. If you're trying to point to multiple hosts, > > either float > > > a virtual IP among them or point at a DNS record you can move among > > > hosts. > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From jules at visionintel.com Fri Feb 13 05:42:14 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Thu, 12 Feb 2009 23:42:14 -0500 Subject: [rsyslog] need some thoughts here Message-ID: <69544300902122042w708bbbb7l369e638af24378a2@mail.gmail.com> I am still trying to find an efficient solution for loggin to a remote location. sysklogd is supposed to do the trick however it is incompatible with rsyslog. when i tried to remove rsyslog, there was a total of 525 packages there was going to be remove, so i decided not to. Any body tried sysklogd? thanks From rgerhards at hq.adiscon.com Fri Feb 13 06:39:18 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 13 Feb 2009 06:39:18 +0100 Subject: [rsyslog] need some thoughts here Message-ID: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> Hi, I do not understand your issue ;) rsyslog is a superset of sysklogd. So you can simply use *.* @remote-host As in sysklogd. rainer ----- Urspr?ngliche Nachricht ----- Von: "Jules Pagna Disso" An: "rsyslog-users" Gesendet: 13.02.09 05:41 Betreff: [rsyslog] need some thoughts here I am still trying to find an efficient solution for loggin to a remote location. sysklogd is supposed to do the trick however it is incompatible with rsyslog. when i tried to remove rsyslog, there was a total of 525 packages there was going to be remove, so i decided not to. Any body tried sysklogd? thanks _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com From aoz.syn at gmail.com Fri Feb 13 17:21:16 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 13 Feb 2009 09:21:16 -0700 Subject: [rsyslog] need some thoughts here In-Reply-To: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> Message-ID: <4255c2570902130821k3f1cd9e3wcc2107cee23c4f9f@mail.gmail.com> On Thu, Feb 12, 2009 at 22:39, Rainer Gerhards wrote: > I do not understand your issue ;) rsyslog is a superset of sysklogd. So you can simply use Ditto. There are only a couple of log daemons I can think of that _don't_ log remotely, and they're embedded-only. Again: nearly every log daemon you are going to find will log remotely. Can you explain more of the problem you are trying to solve? Changing IPs every few minutes and getting the impression that a remote log daemon is hard to find indicates more of a misunderstanding of the problem than an actual technological issue to me. From jules at visionintel.com Fri Feb 13 22:06:55 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Fri, 13 Feb 2009 21:06:55 +0000 Subject: [rsyslog] need some thoughts here In-Reply-To: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> Message-ID: <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> basically, in fedora, when i try installing sysklogd i have a message that says conflict with syslogd and syslog-ng therefore i cannot install sysklogd 2009/2/13 Rainer Gerhards > Hi, > > I do not understand your issue ;) rsyslog is a superset of sysklogd. So you > can simply use > > *.* @remote-host > > As in sysklogd. > > rainer > > ----- Urspr?ngliche Nachricht ----- > Von: "Jules Pagna Disso" > An: "rsyslog-users" > Gesendet: 13.02.09 05:41 > Betreff: [rsyslog] need some thoughts here > > I am still trying to find an efficient solution for loggin to a remote > location. sysklogd is supposed to do the trick however it is incompatible > with rsyslog. when i tried to remove rsyslog, there was a total of 525 > packages there was going to be remove, so i decided not to. > > Any body tried sysklogd? > > thanks > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From hks.private at gmail.com Fri Feb 13 22:28:45 2009 From: hks.private at gmail.com ((private) HKS) Date: Fri, 13 Feb 2009 16:28:45 -0500 Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> Message-ID: On Fri, Feb 13, 2009 at 4:06 PM, Jules Pagna Disso wrote: > basically, in fedora, when i try installing sysklogd i have a message that > says conflict with syslogd and syslog-ng therefore i cannot install sysklogd > ... Is there a problem you're trying to solve with rsyslog? -HKS From jules at visionintel.com Fri Feb 13 22:36:54 2009 From: jules at visionintel.com (Jules Pagna Disso) Date: Fri, 13 Feb 2009 21:36:54 +0000 Subject: [rsyslog] need some thoughts here In-Reply-To: References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> Message-ID: <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> yes, basically i need to write some code to send alert to a remote host something like send(message_options , list of host, port) i can do it but i have to edit rsyslog.conf by programming, yet if i use sysklogd i can just call some routine and do the job, but i failled to install sysklogd. sysklogd has all the option i need i.e -h for host for instance but i can't installed it on fedora 10. i tried on 3 computers no success. 2009/2/13 (private) HKS > On Fri, Feb 13, 2009 at 4:06 PM, Jules Pagna Disso > wrote: > > basically, in fedora, when i try installing sysklogd i have a message > that > > says conflict with syslogd and syslog-ng therefore i cannot install > sysklogd > > > > > ... > > Is there a problem you're trying to solve with rsyslog? > > -HKS > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Sat Feb 14 06:16:32 2009 From: david at lang.hm (david at lang.hm) Date: Fri, 13 Feb 2009 21:16:32 -0800 (PST) Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> Message-ID: On Fri, 13 Feb 2009, Jules Pagna Disso wrote: > yes, basically i need to write some code to send alert to a remote host > something like send(message_options , list of host, port) > > i can do it but i have to edit rsyslog.conf by programming, yet if i use > sysklogd i can just call some routine and do the job, but i failled to > install sysklogd. sysklogd has all the option i need i.e -h for host for > instance but i can't installed it on fedora 10. i tried on 3 computers no > success. umm, for the versions of sysklog that I've used -h was a flag to tell it to go ahead and forward messages. it didn't specify what host they would go to. basicly any version of syslog will let you do that. by the way, I think that the syslogd that RedHat ships is a variation of sysklogd. if you really do want to install sysklogd you need to talk to people who are gurus with rpm packaging options to help you through the dependancy conflicts, but the rsyslog list is not really the right place to search for the info. David Lang > > 2009/2/13 (private) HKS > >> On Fri, Feb 13, 2009 at 4:06 PM, Jules Pagna Disso >> wrote: >>> basically, in fedora, when i try installing sysklogd i have a message >> that >>> says conflict with syslogd and syslog-ng therefore i cannot install >> sysklogd >>> >> >> >> ... >> >> Is there a problem you're trying to solve with rsyslog? >> >> -HKS >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From martinmie at PartyGaming.com Sat Feb 14 14:53:07 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Sat, 14 Feb 2009 14:53:07 +0100 Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled Message-ID: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> Hi, I'm starting to configure some RHEL5 systems with rsyslog-3.19.7-4. One is the logserver and the rest will slowly become the clients... Only one client with TLS support has been configured so far and I had to stop because it wasn't possible to ssh into the machine once rsyslog was up and running after some hours... IIRC, this happened in the past too when activating the TLS support but never got a fix for this issue... Any ideas? TIA, Martin This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From aoz.syn at gmail.com Sat Feb 14 17:25:18 2009 From: aoz.syn at gmail.com (RB) Date: Sat, 14 Feb 2009 09:25:18 -0700 Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> Message-ID: <4255c2570902140825n767831efpa6c77f459daeee3@mail.gmail.com> On Fri, Feb 13, 2009 at 14:06, Jules Pagna Disso wrote: > basically, in fedora, when i try installing sysklogd i have a message that > says conflict with syslogd and syslog-ng therefore i cannot install sysklogd All three log daemons you're talking about (rsyslog, syslogd, syslog-ng) will happily emit messages of your choice to the remote server of your choice. If you're having trouble at this level, I doubt you're familiar with the differences among the three and should probably stick with whatever's installed by default on your distro. From aoz.syn at gmail.com Sat Feb 14 17:32:09 2009 From: aoz.syn at gmail.com (RB) Date: Sat, 14 Feb 2009 09:32:09 -0700 Subject: [rsyslog] need some thoughts here In-Reply-To: <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> References: <001401c98d9d$7e1ed849$060013ac@intern.adiscon.com> <69544300902131306u117ba24fv58eb1eb54cf88e4e@mail.gmail.com> <69544300902131336h1962680cl3abbbc7f2bbc2a56@mail.gmail.com> Message-ID: <4255c2570902140832s5e0f0011ndbc1400b5a4d7537@mail.gmail.com> On Fri, Feb 13, 2009 at 14:36, Jules Pagna Disso wrote: > yes, basically i need to write some code to send alert to a remote host > something like send(message_options , list of host, port) > > i can do it but i have to edit rsyslog.conf by programming, yet if i use > sysklogd i can just call some routine and do the job, but i failled to > install sysklogd. sysklogd has all the option i need i.e -h for host for > instance but i can't installed it on fedora 10. i tried on 3 computers no > success. It would be far more helpful if you gave us more precisely what you are trying to do. From what I gather, you seem to be writing a program that you want to send log messages directly to a remote host. For that use, you don't need any of the syslog daemons - just use 'logger' or any of the dozens of C/C++/Perl/Python logging packages available. There are much better ways to solve this, but at this point I am not sure they'll be any easier for you. From aoz.syn at gmail.com Sat Feb 14 17:38:07 2009 From: aoz.syn at gmail.com (RB) Date: Sat, 14 Feb 2009 09:38:07 -0700 Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> Message-ID: <4255c2570902140838o7778459ew33707fbb581be34@mail.gmail.com> On Sat, Feb 14, 2009 at 06:53, Martin Mielke wrote: > I'm starting to configure some RHEL5 systems with rsyslog-3.19.7-4. One > is the logserver and the rest will slowly become the clients... > > Only one client with TLS support has been configured so far and I had to > stop because it wasn't possible to ssh into the machine once rsyslog was > up and running after some hours... There is nothing inherent to rsyslog (with or without TLS) that will interfere with SSH. Your system may be bogging down or crashing, but you need to find out more exactly what's happening - logs, console messages, resource consumption, etc. From rgerhards at hq.adiscon.com Mon Feb 16 09:27:16 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 09:27:16 +0100 Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A716D5@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBFA@grfint2.intern.adiscon.com> Hi Martin, besides the other (good!) comments, I would strongly suggest to upgrade to the most recent stable first. Most importantly, the last release has fixed a race condition that could explain what you are seeing. It is not tied to TLS, but there is no indication why it could not be the cause. Any troubleshooting on an older version is probably not worth the effort. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Saturday, February 14, 2009 2:53 PM > To: rsyslog-users > Subject: [rsyslog] Unable to ssh to a rsyslog system with TLS enabled > > Hi, > > I'm starting to configure some RHEL5 systems with rsyslog-3.19.7-4. One > is the logserver and the rest will slowly become the clients... > > Only one client with TLS support has been configured so far and I had > to > stop because it wasn't possible to ssh into the machine once rsyslog > was > up and running after some hours... > > IIRC, this happened in the past too when activating the TLS support but > never got a fix for this issue... > > Any ideas? > > > TIA, > > Martin > > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From kenneho.ndu at gmail.com Mon Feb 16 10:17:33 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Mon, 16 Feb 2009 10:17:33 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Message-ID: I talked to Red Hat, and it seems like they will not be upgrading rsyslog to v3 before RHEL 6. :/ On 2/11/09, Rainer Gerhards wrote: > > Side-note: if you talk to red hat, ask if they will move over to v3 any > time before RHEL 6. I do not have specifics, but I would not outrule > such a move. In that case, you'd have only a temporary problem (which > may be easier to bear). > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > Sent: Wednesday, February 11, 2009 11:27 AM > > To: rsyslog-users > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > devices? > > > > Thanks for the tip. I'll have to discuss this with my colleagues, but > > since > > this will probably not be very popular with red hat support I suspect > > that > > we'll land on not doing this. :/ > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > As far as I remember, I implemented this recently, so chances are > > very > > > slim it is in v2. But you may be able to build a patch based on what > > you > > > find in git... > > > > > > Rainer > > > > > > > -----Original Message----- > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > > To: rsyslog-users > > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > Ok. I've checked the docs, but couldn't see that this was > > supported. > > > > I'll > > > > have another look tomorrow. > > > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > > > I think there is no way to do that in v2 (but I have not checked > > the > > > > > docs). > > > > > > > > > > Rainer > > > > > > > > > > > -----Original Message----- > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > > To: rsyslog at lists.adiscon.com > > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of sending > > > > devices? > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > > sending > > > > > > device, as > > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > > > I'd like to filter based on domain, and therefore need the > fqdn > > of > > > > > each > > > > > > sending device. Is it possible to set up rsyslog to always use > > > > fqdn, > > > > > > even if > > > > > > the sending device is on the same domain? From what I've seen > > in > > > > the > > > > > > documentation one can set up rsyslog to always use short > names, > > > but > > > > > not > > > > > > the > > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Kenneth > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > > > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Mon Feb 16 10:18:55 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 10:18:55 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> I do not know whom to approach, but maybe we can get someone else into the boat who can build an publish non RH RPMs that work on RHEL... Anyone with a suggestion on whom to approach? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > Sent: Monday, February 16, 2009 10:18 AM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > I talked to Red Hat, and it seems like they will not be upgrading > rsyslog to > v3 before RHEL 6. :/ > > On 2/11/09, Rainer Gerhards wrote: > > > > Side-note: if you talk to red hat, ask if they will move over to v3 > any > > time before RHEL 6. I do not have specifics, but I would not outrule > > such a move. In that case, you'd have only a temporary problem (which > > may be easier to bear). > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > Sent: Wednesday, February 11, 2009 11:27 AM > > > To: rsyslog-users > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > > > devices? > > > > > > Thanks for the tip. I'll have to discuss this with my colleagues, > but > > > since > > > this will probably not be very popular with red hat support I > suspect > > > that > > > we'll land on not doing this. :/ > > > > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > As far as I remember, I implemented this recently, so chances are > > > very > > > > slim it is in v2. But you may be able to build a patch based on > what > > > you > > > > find in git... > > > > > > > > Rainer > > > > > > > > > -----Original Message----- > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > Sent: Tuesday, February 10, 2009 5:36 PM > > > > > To: rsyslog-users > > > > > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of > sending > > > > > devices? > > > > > > > > > > Ok. I've checked the docs, but couldn't see that this was > > > supported. > > > > > I'll > > > > > have another look tomorrow. > > > > > > > > > > Thanks for the quick response anyway. :) > > > > > > > > > > > > > > > On 2/10/09, Rainer Gerhards wrote: > > > > > > > > > > > > I think there is no way to do that in v2 (but I have not > checked > > > the > > > > > > docs). > > > > > > > > > > > > Rainer > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > > > > > bounces at lists.adiscon.com] On Behalf Of Kenneth Holter > > > > > > > Sent: Tuesday, February 10, 2009 5:21 PM > > > > > > > To: rsyslog at lists.adiscon.com > > > > > > > Subject: [rsyslog] Get rsyslog to always use fqdn of > sending > > > > > devices? > > > > > > > > > > > > > > Hello list. > > > > > > > > > > > > > > > > > > > > > I've currently got rsyslog to separate log files based on > > > sending > > > > > > > device, as > > > > > > > desribed here: http://www.rsyslog.com/Article60.phtml > > > > > > > > > > > > > > I'd like to filter based on domain, and therefore need the > > fqdn > > > of > > > > > > each > > > > > > > sending device. Is it possible to set up rsyslog to always > use > > > > > fqdn, > > > > > > > even if > > > > > > > the sending device is on the same domain? From what I've > seen > > > in > > > > > the > > > > > > > documentation one can set up rsyslog to always use short > > names, > > > > but > > > > > > not > > > > > > > the > > > > > > > other way around. I'm using rsyslog v2.0.6. > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Kenneth > > > > > > > _______________________________________________ > > > > > > > rsyslog mailing list > > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > > http://www.rsyslog.com > > > > > > _______________________________________________ > > > > > > rsyslog mailing list > > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > > http://www.rsyslog.com > > > > > > > > > > > _______________________________________________ > > > > > rsyslog mailing list > > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > > http://www.rsyslog.com > > > > _______________________________________________ > > > > rsyslog mailing list > > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > > http://www.rsyslog.com > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at ecker-software.de Mon Feb 16 10:25:57 2009 From: david at ecker-software.de (David Ecker) Date: Mon, 16 Feb 2009 10:25:57 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> Message-ID: <49993125.2060603@ecker-software.de> Hi, have you tried to contact the epel group? http://fedoraproject.org/wiki/EPEL They should be able to include an upgrade for rsyslog into their repository for REL5 if you ask them. Bye David Rainer Gerhards schrieb: > I do not know whom to approach, but maybe we can get someone else into > the boat who can build an publish non RH RPMs that work on RHEL... > Anyone with a suggestion on whom to approach? > > Rainer > > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >> Sent: Monday, February 16, 2009 10:18 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending >> devices? >> >> I talked to Red Hat, and it seems like they will not be upgrading >> rsyslog to >> v3 before RHEL 6. :/ >> >> On 2/11/09, Rainer Gerhards wrote: >> >>> Side-note: if you talk to red hat, ask if they will move over to v3 >>> >> any >> >>> time before RHEL 6. I do not have specifics, but I would not outrule >>> such a move. In that case, you'd have only a temporary problem >>> > (which > >>> may be easier to bear). >>> >>> Rainer >>> >>> >>>> -----Original Message----- >>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >>>> Sent: Wednesday, February 11, 2009 11:27 AM >>>> To: rsyslog-users >>>> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending >>>> devices? >>>> >>>> Thanks for the tip. I'll have to discuss this with my colleagues, >>>> >> but >> >>>> since >>>> this will probably not be very popular with red hat support I >>>> >> suspect >> >>>> that >>>> we'll land on not doing this. :/ >>>> >>>> >>>> >>>> >>>> On 2/10/09, Rainer Gerhards wrote: >>>> >>>>> As far as I remember, I implemented this recently, so chances >>>>> > are > >>>> very >>>> >>>>> slim it is in v2. But you may be able to build a patch based on >>>>> >> what >> >>>> you >>>> >>>>> find in git... >>>>> >>>>> Rainer >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>>>> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >>>>>> Sent: Tuesday, February 10, 2009 5:36 PM >>>>>> To: rsyslog-users >>>>>> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of >>>>>> >> sending >> >>>>>> devices? >>>>>> >>>>>> Ok. I've checked the docs, but couldn't see that this was >>>>>> >>>> supported. >>>> >>>>>> I'll >>>>>> have another look tomorrow. >>>>>> >>>>>> Thanks for the quick response anyway. :) >>>>>> >>>>>> >>>>>> On 2/10/09, Rainer Gerhards wrote: >>>>>> >>>>>>> I think there is no way to do that in v2 (but I have not >>>>>>> >> checked >> >>>> the >>>> >>>>>>> docs). >>>>>>> >>>>>>> Rainer >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>>>>>> bounces at lists.adiscon.com] On Behalf Of Kenneth Holter >>>>>>>> Sent: Tuesday, February 10, 2009 5:21 PM >>>>>>>> To: rsyslog at lists.adiscon.com >>>>>>>> Subject: [rsyslog] Get rsyslog to always use fqdn of >>>>>>>> >> sending >> >>>>>> devices? >>>>>> >>>>>>>> Hello list. >>>>>>>> >>>>>>>> >>>>>>>> I've currently got rsyslog to separate log files based on >>>>>>>> >>>> sending >>>> >>>>>>>> device, as >>>>>>>> desribed here: http://www.rsyslog.com/Article60.phtml >>>>>>>> >>>>>>>> I'd like to filter based on domain, and therefore need the >>>>>>>> >>> fqdn >>> >>>> of >>>> >>>>>>> each >>>>>>> >>>>>>>> sending device. Is it possible to set up rsyslog to always >>>>>>>> >> use >> >>>>>> fqdn, >>>>>> >>>>>>>> even if >>>>>>>> the sending device is on the same domain? From what I've >>>>>>>> >> seen >> >>>> in >>>> >>>>>> the >>>>>> >>>>>>>> documentation one can set up rsyslog to always use short >>>>>>>> >>> names, >>> >>>>> but >>>>> >>>>>>> not >>>>>>> >>>>>>>> the >>>>>>>> other way around. I'm using rsyslog v2.0.6. >>>>>>>> >>>>>>>> >>>>>>>> Regards, >>>>>>>> Kenneth >>>>>>>> _______________________________________________ >>>>>>>> rsyslog mailing list >>>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>>> http://www.rsyslog.com >>>>>>>> >>>>>>> _______________________________________________ >>>>>>> rsyslog mailing list >>>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>>> http://www.rsyslog.com >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> rsyslog mailing list >>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>> http://www.rsyslog.com >>>>>> >>>>> _______________________________________________ >>>>> rsyslog mailing list >>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>> http://www.rsyslog.com >>>>> >>>>> >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com >>>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From Luis.Fernando.Munoz.Mejias at cern.ch Mon Feb 16 11:41:21 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Mon, 16 Feb 2009 11:41:21 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> Rainer, My apologies for the late reply. I was subscribed to the digest format and didn't receive your replies. > glad you asked :) The documentation is ... well... not much ;) Oops! > The best thing is probably to start with the existing MySQL > module. HOWEVER, I myself would be very interested in a native, > high-performing Oracle driver. I neither have the expertise to do it > not the test environment. I don't have the expertise either, but do have the test environment... we can try. ;) > If you like, we could collaborate on this effort. I'd create a > skeleton output module for you, guide you through using it and you > provide the Oracle bits to it (that should be fairly easy). Of course, > that means your module would need to be contributed back to the > project. That sounds really great. Before you start coding or preparing anything, let me check how well our DBs perform, because it's not yet clear if they'll be able to cope with the high insertion rate we expect. If we don't go for the Oracle database this work doesn't make sense. I bet we'll want the Oracle, anyways. For this evaluation, I already have a timestamp formatter that fits into Oracle, something that can be used with the property replacer, like %timereported:::date-oracle%. It still needs some real-world testing, but provided it works, is it interesting for the project? If so, should I submit the patch via bugzilla? Is there any paperwork (copyright assingmnents a la FSF or whatever) that should be fullfilled? Thanks. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From rgerhards at hq.adiscon.com Mon Feb 16 17:35:25 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 17:35:25 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC08@grfint2.intern.adiscon.com> Sorry, this time my reply is sluggish ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Luis Fernando Mu?oz Mej?as > Sent: Monday, February 16, 2009 11:41 AM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] Documentation on writing rsyslog modules? > > Rainer, > > My apologies for the late reply. I was subscribed to the digest format > and didn't receive your replies. > > > glad you asked :) The documentation is ... well... not much ;) > > Oops! > > > The best thing is probably to start with the existing MySQL > > module. HOWEVER, I myself would be very interested in a native, > > high-performing Oracle driver. I neither have the expertise to do it > > not the test environment. > > I don't have the expertise either, but do have the test > environment... we can try. ;) A test environment is first step to expertise ;) > > > If you like, we could collaborate on this effort. I'd create a > > skeleton output module for you, guide you through using it and you > > provide the Oracle bits to it (that should be fairly easy). Of > course, > > that means your module would need to be contributed back to the > > project. > > That sounds really great. Before you start coding or preparing > anything, > let me check how well our DBs perform, because it's not yet clear if > they'll be able to cope with the high insertion rate we expect. If we > don't go for the Oracle database this work doesn't make sense. I bet > we'll want the Oracle, anyways. Sounds fair. > > For this evaluation, I already have a timestamp formatter that fits > into > Oracle, something that can be used with the property replacer, like > %timereported:::date-oracle%. Sounds good. This is one of the bad things about current code base, though. The formatter should long come from the custom plugin, but I didn't manage to do the script engine so far (the core of custom functions). Not a big deal, but something that annoys *me* ;) > It still needs some real-world testing, > but provided it works, is it interesting for the project? Definitely > If so, should > I submit the patch via bugzilla? Any way is fine. You can also just email me. Proper credits, of course are guaranteed. > Is there any paperwork (copyright > assingmnents a la FSF or whatever) that should be fullfilled? Nope, we think the project is in a strong enough position even if the submitter holds the copyright. Actually, this was one project goal: keep contributions easy. I really don't like all the blabla that e.g. you need to do when contributing to syslog-ng. Just be aware that some parts of rsyslog come under GPL while some come under LGPL (the runtime files). We assume that whatever you contribute comes under the license of the core module. For new runtime files, this means we expect LGPL, else we have a problem license-wise. Really looking forward to your results, Rainer > > Thanks. > -- > Luis Fernando Mu?oz Mej?as > Luis.Fernando.Munoz.Mejias at cern.ch > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Feb 16 18:52:07 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 16 Feb 2009 18:52:07 +0100 Subject: [rsyslog] rsyslog on Debian 5.0 Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC0E@grfint2.intern.adiscon.com> Hi folks, I guess most of you already know, but I have some excellent news to share. Rsyslog is now default on the stable Debian version: http://blog.gerhards.net/2009/02/rsyslog-now-default-on-stable-debian.ht ml Thanks to everyone who helped make this happen and special thanks to Michael Biebl, the driving force behind the Debian effort! Rainer From hks.private at gmail.com Mon Feb 16 19:18:13 2009 From: hks.private at gmail.com ((private) HKS) Date: Mon, 16 Feb 2009 13:18:13 -0500 Subject: [rsyslog] rsyslog on Debian 5.0 In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC0E@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC0E@grfint2.intern.adiscon.com> Message-ID: Congrats! -HKS On Mon, Feb 16, 2009 at 12:52 PM, Rainer Gerhards wrote: > Hi folks, > > I guess most of you already know, but I have some excellent news to > share. Rsyslog is now default on the stable Debian version: > > http://blog.gerhards.net/2009/02/rsyslog-now-default-on-stable-debian.ht > ml > > Thanks to everyone who helped make this happen and special thanks to > Michael Biebl, the driving force behind the Debian effort! > > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From aoz.syn at gmail.com Mon Feb 16 23:48:31 2009 From: aoz.syn at gmail.com (RB) Date: Mon, 16 Feb 2009 15:48:31 -0700 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <49993125.2060603@ecker-software.de> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> Message-ID: <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> On Mon, Feb 16, 2009 at 02:25, David Ecker wrote: > have you tried to contact the epel group? > > http://fedoraproject.org/wiki/EPEL > > They should be able to include an upgrade for rsyslog into their > repository for REL5 if you ask them. Failing that, I already wrote one spec for rsyslog-3.x under CentOS-5 and could be pretty easily persuaded to do so again. From daodennis at gmail.com Tue Feb 17 06:30:06 2009 From: daodennis at gmail.com (Dennis Ordanov) Date: Mon, 16 Feb 2009 21:30:06 -0800 Subject: [rsyslog] rsyslog eating FDs stops logging locally or remotely and eventually dies Message-ID: Hello Everyone, I use syslog to log locally and remotely via stunnel which is bound to the loopback address. It seems syslog will steadily use up FDs until it runs into the per process limit on my oBSD boxes and then either stops logging locally or forwarding traffic to stunnel, I don't know if this is a problem with stunnel or syslog or how to tell, but something is causing it to open a new file descriptor or unable to re-use another one or something...? I can just restart syslogd with a cron job weekly and increase the file descriptor limit, but that's not really a path I want to go down if I don't have to. If you think it will be useful to run syslogd in debug mode, but it can take a week for this problem to occur... I have 4 hypothesis of why this might be hapening: 1) syslog's interaction with stunnel is causing it to just to use more and more FDs 2) regarding #1, if there is a problem with stunnel accepting connections or being too overloaded or not being able to connect to the remote stunnel gateway then maybe its not accepting new conns to it or something? 3) something with myconfiguration is instigating this behaviour...? 4) none of the above Here is a box that will soon be in a broken state: root at hostname# /usr/sbin/syslogd -v rsyslogd 1.12.2, compiled with: FEATURE_REGEXP FEATURE_LARGEFILE SYSLOG_INET (Internet/remote support) root at hostname# uname -a OpenBSD hostname 4.1 GENERIC#1435 i386 # ulimit -a time(cpu-seconds) unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes) 8192 lockedmem(kbytes) 153844 memory(kbytes) 460268 nofiles(descriptors) 128 processes 532 I am running ktrace on this pid until I see it use another file descriptor being used by this process, right now at 109 it looks like. Come to think of it maybe I should be tracing stunnel too? root at host# fstat -n |grep syslog USER CMD PID FD MOUNT INUM MODE R/W DV|SZ root syslogd 20085 wd 0,0 2 40755 r 512 root syslogd 20085 0* unix dgram 0xd14f6a00 root syslogd 20085 1* internet stream tcp root syslogd 20085 2* internet stream tcp root syslogd 20085 3* internet stream tcp root syslogd 20085 4* internet stream tcp root syslogd 20085 5* internet stream tcp root syslogd 20085 6* internet stream tcp root syslogd 20085 7* internet stream tcp root syslogd 20085 8* internet stream tcp root syslogd 20085 9* internet stream tcp root syslogd 20085 10* internet stream tcp root syslogd 20085 11* internet stream tcp root syslogd 20085 12* internet stream tcp root syslogd 20085 13* internet stream tcp root syslogd 20085 14* internet stream tcp root syslogd 20085 15* internet stream tcp root syslogd 20085 16* unix dgram 0xd14048c0 root syslogd 20085 17* internet dgram udp *:514 root syslogd 20085 18* internet stream tcp root syslogd 20085 19* internet stream tcp root syslogd 20085 20* internet stream tcp root syslogd 20085 21* internet stream tcp root syslogd 20085 22* internet stream tcp root syslogd 20085 23* internet stream tcp root syslogd 20085 24* internet stream tcp root syslogd 20085 25* internet stream tcp root syslogd 20085 26* internet stream tcp root syslogd 20085 27* internet stream tcp root syslogd 20085 28* internet stream tcp root syslogd 20085 29* internet stream tcp root syslogd 20085 30* internet stream tcp root syslogd 20085 31* internet stream tcp root syslogd 20085 32* internet stream tcp root syslogd 20085 33* internet stream tcp root syslogd 20085 34* internet stream tcp root syslogd 20085 35* internet stream tcp root syslogd 20085 36* internet stream tcp root syslogd 20085 37* internet stream tcp root syslogd 20085 38* internet stream tcp root syslogd 20085 39* internet stream tcp root syslogd 20085 40* internet stream tcp root syslogd 20085 41* internet stream tcp root syslogd 20085 42* internet stream tcp root syslogd 20085 43* internet stream tcp root syslogd 20085 44* internet stream tcp root syslogd 20085 45* internet stream tcp root syslogd 20085 46* internet stream tcp root syslogd 20085 47* internet stream tcp root syslogd 20085 48* internet stream tcp root syslogd 20085 49* internet stream tcp root syslogd 20085 50* internet stream tcp root syslogd 20085 51* internet stream tcp root syslogd 20085 52* internet stream tcp root syslogd 20085 53* internet stream tcp root syslogd 20085 54* internet stream tcp root syslogd 20085 55* internet stream tcp root syslogd 20085 56* internet stream tcp root syslogd 20085 57* internet stream tcp root syslogd 20085 58* internet stream tcp root syslogd 20085 59* internet stream tcp root syslogd 20085 60* internet stream tcp 0xd6906648 127.0.0.1:4392 --> 127.0.0.1:5140 root syslogd 20085 61* internet stream tcp root syslogd 20085 62* internet stream tcp root syslogd 20085 63 0,4 844952 100644 w 81695 root syslogd 20085 64* internet stream tcp root syslogd 20085 65* internet stream tcp root syslogd 20085 66 0,4 844952 100644 w 81695 root syslogd 20085 67* internet stream tcp root syslogd 20085 68* internet stream tcp root syslogd 20085 69 0,4 844984 100644 w 73 root syslogd 20085 70* internet stream tcp root syslogd 20085 71* internet stream tcp root syslogd 20085 72 0,4 844984 100644 w 73 root syslogd 20085 73* internet stream tcp root syslogd 20085 74* internet stream tcp root syslogd 20085 75* internet stream tcp root syslogd 20085 76 0,4 844984 100644 w 73 root syslogd 20085 77* internet stream tcp root syslogd 20085 78* internet stream tcp root syslogd 20085 79* internet stream tcp root syslogd 20085 80 0,4 844969 100644 w 3437673 root syslogd 20085 81* internet stream tcp root syslogd 20085 82* internet stream tcp root syslogd 20085 83 0,4 844976 100644 w 442 root syslogd 20085 84* internet stream tcp root syslogd 20085 85* internet stream tcp root syslogd 20085 86 0,4 844976 100644 w 442 root syslogd 20085 87* internet stream tcp root syslogd 20085 88* internet stream tcp root syslogd 20085 89 0,4 844930 100640 w 18747 root syslogd 20085 90* internet stream tcp root syslogd 20085 91* internet stream tcp root syslogd 20085 92 0,4 844936 100600 w 74 root syslogd 20085 93* internet stream tcp root syslogd 20085 94* internet stream tcp root syslogd 20085 95 0,4 2328711 100600 w 46522 root syslogd 20085 96* internet stream tcp root syslogd 20085 97* internet stream tcp root syslogd 20085 98 0,4 844972 100640 w 476 root syslogd 20085 99* internet stream tcp root syslogd 20085 100* internet stream tcp root syslogd 20085 101 0,4 844941 100640 w 0 root syslogd 20085 102* internet stream tcp root syslogd 20085 103* internet stream tcp root syslogd 20085 104 0,4 844935 100640 w 0 root syslogd 20085 105* internet stream tcp root syslogd 20085 106* internet stream tcp root syslogd 20085 107 0,4 844931 100600 w 74 root syslogd 20085 108* internet stream tcp 0xd694c7d4 127.0.0.1:19723 --> 127.0.0.1:5140 root syslogd 20085 109* internet stream tcp 0xd694c964 127.0.0.1:42849 --> 127.0.0.1:5140 root at host# netstat -an Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) tcp 0 32 172.20.20.51.22 remote.63117 ESTABLISHED tcp 0 0 172.20.20.51.38090 remote.443 ESTABLISHED tcp 0 0 127.0.0.1.5140 127.0.0.1.42849 ESTABLISHED tcp 0 0 127.0.0.1.42849 127.0.0.1.5140 ESTABLISHED tcp 0 0 172.20.20.51.19898 remote.443 ESTABLISHED tcp 0 0 127.0.0.1.5140 127.0.0.1.19723 ESTABLISHED tcp 0 0 127.0.0.1.19723 127.0.0.1.5140 ESTABLISHED tcp 0 0 172.20.20.51.5494 remote.443 ESTABLISHED tcp 0 0 127.0.0.1.5140 127.0.0.1.4392 ESTABLISHED tcp 0 0 127.0.0.1.4392 127.0.0.1.5140 ESTABLISHED tcp 0 0 *.22 *.* LISTEN tcp 0 0 127.0.0.1.5140 *.* LISTEN tcp 0 0 127.0.0.1.587 *.* LISTEN tcp 0 0 127.0.0.1.25 *.* LISTEN tcp 0 0 *.37 *.* LISTEN tcp 0 0 *.13 *.* LISTEN tcp 0 0 *.113 *.* LISTEN Active Internet connections (including servers) Proto Recv-Q Send-Q Local Address Foreign Address (state) udp 0 0 172.20.20.51.2947 172.20.20.92.123 udp 0 0 172.20.20.51.12927 172.20.20.91.123 udp 0 0 *.514 *.* udp 0 0 10.144.73.23.123 *.* udp 0 0 10.144.73.21.123 *.* udp 0 0 172.20.20.51.123 *.* udp 0 0 127.0.0.1.123 *.* udp 0 0 127.0.0.1.512 *.* root at host# fstat|grep stunnel USER CMD PID FD MOUNT INUM MODE R/W DV|SZ _stunnel stunnel 32055 root /var 6141184 drwxr-xr-x r 512 _stunnel stunnel 32055 wd /var 6141184 drwxr-xr-x r 512 _stunnel stunnel 32055 0 / 166117 crw-rw-rw- rw null _stunnel stunnel 32055 1 / 166117 crw-rw-rw- rw null _stunnel stunnel 32055 2 / 166117 crw-rw-rw- rw null _stunnel stunnel 32055 3 pipe 0xe9505e10 state: _stunnel stunnel 32055 4 pipe 0xe9505e10 state: _stunnel stunnel 32055 5 / 165853 crw-rw-rw- rw crypto _stunnel stunnel 32055 6* internet stream tcp 0xd6906e18 127.0.0.1:5140 <-- 127.0.0.1:4392 _stunnel stunnel 32055 7 pipe 0xe95057e0 state: _stunnel stunnel 32055 8 pipe 0xe95057e0 state: _stunnel stunnel 32055 9* internet stream tcp 0xd694cc84 127.0.0.1:5140 _stunnel stunnel 32055 10* internet stream tcp 0xd694c644 172.20.20.51:5494 --> remote:443 _stunnel stunnel 32055 11* internet stream tcp 0xd694c4b4 127.0.0.1:5140 <-- 127.0.0.1:19723 _stunnel stunnel 32055 12* internet stream tcp 0xd694ce14 172.20.20.51:19898 --> remote:443 _stunnel stunnel 32055 13* internet stream tcp 0xd694caf4 127.0.0.1:5140 <-- 127.0.0.1:42849 _stunnel stunnel 32055 14* internet stream tcp 0xd68cb19c 172.20.20.51:38090 --> remote:443 # ulimit -a time(cpu-seconds) unlimited file(blocks) unlimited coredump(blocks) unlimited data(kbytes) 1048576 stack(kbytes) 8192 lockedmem(kbytes) 153844 memory(kbytes) 460268 nofiles(descriptors) 128 processes 532 root at hostname# /usr/sbin/syslogd -v rsyslogd 1.12.2, compiled with: FEATURE_REGEXP FEATURE_LARGEFILE SYSLOG_INET (Internet/remote support) root at hostname# uname -a OpenBSD hostname 4.1 GENERIC#1435 i386 Here is how its getting started out of rc: syslogd_flags="-h -i /var/run/syslog.pid -m 0 -r 514" # flags for rsyslogd Process Entries: # ps -axwww|egrep '[s]yslog|[s]tunnel' 32055 ?? Is 2:22.48 /usr/local/sbin/stunnel 20085 ?? Is 4:50.88 syslogd -h -i /var/run/syslog.pid -m 0 -r 514 -a /var/empty/dev/log Here is the config: /etc/rsyslog.conf # Template to include time received by the Admin Server when forwarded to the Data Center. # Juniper Messages are not passed with a timestamp. $template MissingDate,"<%PRI%>%timegenerated% %HOSTNAME% %syslogtag%%msg%" # Template to remove the syslog tag "root:" for the heartbeat and checks when forwarded to the Data Center. $template NoSyslogTag,"<%PRI%>%timegenerated% %HOSTNAME% %msg%" # Template to allow for easier reading of the Cisco logs. # Include a text designation for the type of Cisco equipment. # Start the message at position at offset 19 to strip out time stamp. $template CiscoSW1,"%TIMESTAMP% %HOSTNAME% Switch1: %msg:19:500:drop-last-lf%\n" $template CiscoSW2,"%TIMESTAMP% %HOSTNAME% Switch2: %msg:19:500:drop-last-lf%\n" $template CiscoTS1,"%TIMESTAMP% %HOSTNAME% Term1: %msg:19:500:drop-last-lf%\n" # Forward messages from the admin server heartbeat and checks based on message id :msg, contains, "NHB10001:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10002:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10003:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10004:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CHK10005:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10006:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10007:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10008:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10009:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10011:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10012:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10015:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10016:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "ATH10017:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CLP10020:" @@127.0.0.1:5140;NoSyslogTag :msg, contains, "CLP10021:" @@127.0.0.1:5140;NoSyslogTag # Forward messages from juniper nodes basd on message id :msg, contains, "ADM10310:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM20255:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM20928:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM22798:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM23046:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM24336:" @@127.0.0.1:5140;MissingDate :msg, contains, "ADM24337:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC22051:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC23037:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC23038:" @@127.0.0.1:5140;MissingDate :msg, contains, "ARC23039:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT10301:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT21060:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT21089:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT22677:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT22678:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT22696:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT23391:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT23551:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT23552:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT24080:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT24417:" @@127.0.0.1:5140;MissingDate :msg, contains, "AUT24418:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20146:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20147:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20148:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20149:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20150:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20151:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20152:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20153:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20154:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20155:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20643:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20644:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR20645:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR24016:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR24019:" @@127.0.0.1:5140;MissingDate :msg, contains, "ERR24076:" @@127.0.0.1:5140;MissingDate :msg, contains, "LIC10200:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10062:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10087:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10088:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10089:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10090:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10091:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10092:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10093:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10094:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10298:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10299:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS10314:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS23041:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS23402:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS23409:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24015:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24020:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24316:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24317:" @@127.0.0.1:5140;MissingDate :msg, contains, "SYS24348:" @@127.0.0.1:5140;MissingDate # Forward messages from F5 nodes based on lb hostnames :HOSTNAME, contains, "lb1-" @@127.0.0.1:5140 :HOSTNAME, contains, "lb2-" @@127.0.0.1:5140 # Log F5 messages locally for archival purposes based on lb hostnames :HOSTNAME, contains, "lb1-" /var/log/f5.log :HOSTNAME, contains, "lb2-" /var/log/f5.log # Log Cisco messages locally for archival purposes based on ip hostnames :HOSTNAME, contains, "172.20.20.101" /var/log/cisco.log :HOSTNAME, contains, "172.20.20.102" /var/log/cisco.log :HOSTNAME, contains, "172.20.20.227" /var/log/cisco.log # Discard lb1/2 and cisco messages from further processing :HOSTNAME, contains, "lb1-" ~ :HOSTNAME, contains, "lb2-" ~ :HOSTNAME, contains, "172.20.20.101" ~ :HOSTNAME, contains, "172.20.20.102" ~ :HOSTNAME, contains, "172.20.20.227" ~ # Log local7 messages locally for archival purposes local7.* /var/log/local7.log *.notice;\ auth,authpriv,cron,ftp,kern,lpr,mail,user,local7.none /var/log/messages kern.debug;syslog,user.info /var/log/messages auth.info /var/log/authlog authpriv.debug /var/log/secure cron.info /var/cron/log daemon.info /var/log/daemon ftp.info /var/log/xferlog lpr.debug /var/log/lpd-errs mail.info /var/log/maillog #uucp.info /var/log/uucp # Everyone gets emergency messages. *.emerg I've tried to look on the net for anything that had to do with syslog and file descriptors and or how these problems happen and coming out with pretty much squat.. Thank you, Dennis O. From rgerhards at hq.adiscon.com Tue Feb 17 07:18:14 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 17 Feb 2009 07:18:14 +0100 Subject: [rsyslog] rsyslog eating FDs stops logging locally or remotely andeventually dies In-Reply-To: References: Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC10@grfint2.intern.adiscon.com> Hi Dennis, First thing I would upgrade to a recent release, either v2-stable or v3-stable. The version you are using is heavily outdated and looking into the issue with that version simply makes no sense. Plus, I think chances are good the problem will disappear with the new versions. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Dennis Ordanov > Sent: Tuesday, February 17, 2009 6:30 AM > To: rsyslog at lists.adiscon.com > Subject: [rsyslog] rsyslog eating FDs stops logging locally > or remotely andeventually dies > > Hello Everyone, > > I use syslog to log locally and remotely via stunnel which is bound to > the loopback address. It seems syslog will steadily use up FDs until > it runs into the per process limit on my oBSD boxes and then either > stops logging locally or forwarding traffic to stunnel, I don't know > if this is a problem with stunnel or syslog or how to tell, but > something is causing it to open a new file descriptor or unable to > re-use another one or something...? > > > I can just restart syslogd with a cron job weekly and increase the > file descriptor limit, but that's not really a path I want to go down > if I don't have to. > > If you think it will be useful to run syslogd in debug mode, but it > can take a week for this problem to occur... > > I have 4 hypothesis of why this might be hapening: > 1) syslog's interaction with stunnel is causing it to just to use more > and more FDs > 2) regarding #1, if there is a problem with stunnel accepting > connections or being too overloaded or not being able to connect to > the remote stunnel gateway then maybe its not accepting new conns to > it or something? > 3) something with myconfiguration is instigating this behaviour...? > 4) none of the above > > Here is a box that will soon be in a broken state: > > root at hostname# /usr/sbin/syslogd -v > rsyslogd 1.12.2, compiled with: > FEATURE_REGEXP > FEATURE_LARGEFILE > SYSLOG_INET (Internet/remote support) > root at hostname# uname -a > OpenBSD hostname 4.1 GENERIC#1435 i386 > > # ulimit -a > time(cpu-seconds) unlimited > file(blocks) unlimited > coredump(blocks) unlimited > data(kbytes) 1048576 > stack(kbytes) 8192 > lockedmem(kbytes) 153844 > memory(kbytes) 460268 > nofiles(descriptors) 128 > processes 532 > > I am running ktrace on this pid until I see it use another file > descriptor being used by this process, right now at 109 it looks like. > Come to think of it maybe I should be tracing stunnel too? > > root at host# fstat -n |grep syslog > USER CMD PID FD MOUNT INUM MODE > R/W DV|SZ > root syslogd 20085 wd 0,0 2 40755 r 512 > root syslogd 20085 0* unix dgram 0xd14f6a00 > root syslogd 20085 1* internet stream tcp > root syslogd 20085 2* internet stream tcp > root syslogd 20085 3* internet stream tcp > root syslogd 20085 4* internet stream tcp > root syslogd 20085 5* internet stream tcp > root syslogd 20085 6* internet stream tcp > root syslogd 20085 7* internet stream tcp > root syslogd 20085 8* internet stream tcp > root syslogd 20085 9* internet stream tcp > root syslogd 20085 10* internet stream tcp > root syslogd 20085 11* internet stream tcp > root syslogd 20085 12* internet stream tcp > root syslogd 20085 13* internet stream tcp > root syslogd 20085 14* internet stream tcp > root syslogd 20085 15* internet stream tcp > root syslogd 20085 16* unix dgram 0xd14048c0 > root syslogd 20085 17* internet dgram udp *:514 > root syslogd 20085 18* internet stream tcp > root syslogd 20085 19* internet stream tcp > root syslogd 20085 20* internet stream tcp > root syslogd 20085 21* internet stream tcp > root syslogd 20085 22* internet stream tcp > root syslogd 20085 23* internet stream tcp > root syslogd 20085 24* internet stream tcp > root syslogd 20085 25* internet stream tcp > root syslogd 20085 26* internet stream tcp > root syslogd 20085 27* internet stream tcp > root syslogd 20085 28* internet stream tcp > root syslogd 20085 29* internet stream tcp > root syslogd 20085 30* internet stream tcp > root syslogd 20085 31* internet stream tcp > root syslogd 20085 32* internet stream tcp > root syslogd 20085 33* internet stream tcp > root syslogd 20085 34* internet stream tcp > root syslogd 20085 35* internet stream tcp > root syslogd 20085 36* internet stream tcp > root syslogd 20085 37* internet stream tcp > root syslogd 20085 38* internet stream tcp > root syslogd 20085 39* internet stream tcp > root syslogd 20085 40* internet stream tcp > root syslogd 20085 41* internet stream tcp > root syslogd 20085 42* internet stream tcp > root syslogd 20085 43* internet stream tcp > root syslogd 20085 44* internet stream tcp > root syslogd 20085 45* internet stream tcp > root syslogd 20085 46* internet stream tcp > root syslogd 20085 47* internet stream tcp > root syslogd 20085 48* internet stream tcp > root syslogd 20085 49* internet stream tcp > root syslogd 20085 50* internet stream tcp > root syslogd 20085 51* internet stream tcp > root syslogd 20085 52* internet stream tcp > root syslogd 20085 53* internet stream tcp > root syslogd 20085 54* internet stream tcp > root syslogd 20085 55* internet stream tcp > root syslogd 20085 56* internet stream tcp > root syslogd 20085 57* internet stream tcp > root syslogd 20085 58* internet stream tcp > root syslogd 20085 59* internet stream tcp > root syslogd 20085 60* internet stream tcp 0xd6906648 > 127.0.0.1:4392 --> 127.0.0.1:5140 > root syslogd 20085 61* internet stream tcp > root syslogd 20085 62* internet stream tcp > root syslogd 20085 63 0,4 844952 100644 w 81695 > root syslogd 20085 64* internet stream tcp > root syslogd 20085 65* internet stream tcp > root syslogd 20085 66 0,4 844952 100644 w 81695 > root syslogd 20085 67* internet stream tcp > root syslogd 20085 68* internet stream tcp > root syslogd 20085 69 0,4 844984 100644 w 73 > root syslogd 20085 70* internet stream tcp > root syslogd 20085 71* internet stream tcp > root syslogd 20085 72 0,4 844984 100644 w 73 > root syslogd 20085 73* internet stream tcp > root syslogd 20085 74* internet stream tcp > root syslogd 20085 75* internet stream tcp > root syslogd 20085 76 0,4 844984 100644 w 73 > root syslogd 20085 77* internet stream tcp > root syslogd 20085 78* internet stream tcp > root syslogd 20085 79* internet stream tcp > root syslogd 20085 80 0,4 844969 100644 w 3437673 > root syslogd 20085 81* internet stream tcp > root syslogd 20085 82* internet stream tcp > root syslogd 20085 83 0,4 844976 100644 w 442 > root syslogd 20085 84* internet stream tcp > root syslogd 20085 85* internet stream tcp > root syslogd 20085 86 0,4 844976 100644 w 442 > root syslogd 20085 87* internet stream tcp > root syslogd 20085 88* internet stream tcp > root syslogd 20085 89 0,4 844930 100640 w 18747 > root syslogd 20085 90* internet stream tcp > root syslogd 20085 91* internet stream tcp > root syslogd 20085 92 0,4 844936 100600 w 74 > root syslogd 20085 93* internet stream tcp > root syslogd 20085 94* internet stream tcp > root syslogd 20085 95 0,4 2328711 100600 w 46522 > root syslogd 20085 96* internet stream tcp > root syslogd 20085 97* internet stream tcp > root syslogd 20085 98 0,4 844972 100640 w 476 > root syslogd 20085 99* internet stream tcp > root syslogd 20085 100* internet stream tcp > root syslogd 20085 101 0,4 844941 100640 w 0 > root syslogd 20085 102* internet stream tcp > root syslogd 20085 103* internet stream tcp > root syslogd 20085 104 0,4 844935 100640 w 0 > root syslogd 20085 105* internet stream tcp > root syslogd 20085 106* internet stream tcp > root syslogd 20085 107 0,4 844931 100600 w 74 > root syslogd 20085 108* internet stream tcp 0xd694c7d4 > 127.0.0.1:19723 --> 127.0.0.1:5140 > root syslogd 20085 109* internet stream tcp 0xd694c964 > 127.0.0.1:42849 --> 127.0.0.1:5140 > > > root at host# netstat -an > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address > (state) > tcp 0 32 172.20.20.51.22 remote.63117 > ESTABLISHED > tcp 0 0 172.20.20.51.38090 remote.443 > ESTABLISHED > tcp 0 0 127.0.0.1.5140 127.0.0.1.42849 > ESTABLISHED > tcp 0 0 127.0.0.1.42849 127.0.0.1.5140 > ESTABLISHED > tcp 0 0 172.20.20.51.19898 remote.443 > ESTABLISHED > tcp 0 0 127.0.0.1.5140 127.0.0.1.19723 > ESTABLISHED > tcp 0 0 127.0.0.1.19723 127.0.0.1.5140 > ESTABLISHED > tcp 0 0 172.20.20.51.5494 remote.443 > ESTABLISHED > tcp 0 0 127.0.0.1.5140 127.0.0.1.4392 > ESTABLISHED > tcp 0 0 127.0.0.1.4392 127.0.0.1.5140 > ESTABLISHED > tcp 0 0 *.22 *.* > LISTEN > tcp 0 0 127.0.0.1.5140 *.* > LISTEN > tcp 0 0 127.0.0.1.587 *.* > LISTEN > tcp 0 0 127.0.0.1.25 *.* > LISTEN > tcp 0 0 *.37 *.* > LISTEN > tcp 0 0 *.13 *.* > LISTEN > tcp 0 0 *.113 *.* > LISTEN > Active Internet connections (including servers) > Proto Recv-Q Send-Q Local Address Foreign Address > (state) > udp 0 0 172.20.20.51.2947 172.20.20.92.123 > udp 0 0 172.20.20.51.12927 172.20.20.91.123 > udp 0 0 *.514 *.* > udp 0 0 10.144.73.23.123 *.* > udp 0 0 10.144.73.21.123 *.* > udp 0 0 172.20.20.51.123 *.* > udp 0 0 127.0.0.1.123 *.* > udp 0 0 127.0.0.1.512 *.* > > > root at host# fstat|grep stunnel > USER CMD PID FD MOUNT INUM MODE > R/W DV|SZ > _stunnel stunnel 32055 root /var 6141184 drwxr-xr-x > r 512 > _stunnel stunnel 32055 wd /var 6141184 drwxr-xr-x > r 512 > _stunnel stunnel 32055 0 / 166117 crw-rw-rw- > rw null > _stunnel stunnel 32055 1 / 166117 crw-rw-rw- > rw null > _stunnel stunnel 32055 2 / 166117 crw-rw-rw- > rw null > _stunnel stunnel 32055 3 pipe 0xe9505e10 state: > _stunnel stunnel 32055 4 pipe 0xe9505e10 state: > _stunnel stunnel 32055 5 / 165853 crw-rw-rw- > rw crypto > _stunnel stunnel 32055 6* internet stream tcp 0xd6906e18 > 127.0.0.1:5140 <-- 127.0.0.1:4392 > _stunnel stunnel 32055 7 pipe 0xe95057e0 state: > _stunnel stunnel 32055 8 pipe 0xe95057e0 state: > _stunnel stunnel 32055 9* internet stream tcp > 0xd694cc84 127.0.0.1:5140 > _stunnel stunnel 32055 10* internet stream tcp 0xd694c644 > 172.20.20.51:5494 --> remote:443 > _stunnel stunnel 32055 11* internet stream tcp 0xd694c4b4 > 127.0.0.1:5140 <-- 127.0.0.1:19723 > _stunnel stunnel 32055 12* internet stream tcp 0xd694ce14 > 172.20.20.51:19898 --> remote:443 > _stunnel stunnel 32055 13* internet stream tcp 0xd694caf4 > 127.0.0.1:5140 <-- 127.0.0.1:42849 > _stunnel stunnel 32055 14* internet stream tcp 0xd68cb19c > 172.20.20.51:38090 --> remote:443 > > # ulimit -a > time(cpu-seconds) unlimited > file(blocks) unlimited > coredump(blocks) unlimited > data(kbytes) 1048576 > stack(kbytes) 8192 > lockedmem(kbytes) 153844 > memory(kbytes) 460268 > nofiles(descriptors) 128 > processes 532 > > root at hostname# /usr/sbin/syslogd -v > rsyslogd 1.12.2, compiled with: > FEATURE_REGEXP > FEATURE_LARGEFILE > SYSLOG_INET (Internet/remote support) > root at hostname# uname -a > OpenBSD hostname 4.1 GENERIC#1435 i386 > > Here is how its getting started out of rc: > > syslogd_flags="-h -i /var/run/syslog.pid -m 0 -r 514" # > flags for rsyslogd > > Process Entries: > # ps -axwww|egrep '[s]yslog|[s]tunnel' > 32055 ?? Is 2:22.48 /usr/local/sbin/stunnel > 20085 ?? Is 4:50.88 syslogd -h -i /var/run/syslog.pid -m 0 -r > 514 -a /var/empty/dev/log > > Here is the config: > > /etc/rsyslog.conf > # Template to include time received by the Admin Server when forwarded > to the Data Center. > # Juniper Messages are not passed with a timestamp. > > $template MissingDate,"<%PRI%>%timegenerated% %HOSTNAME% > %syslogtag%%msg%" > > # Template to remove the syslog tag "root:" for the heartbeat and > checks when forwarded to the Data Center. > > $template NoSyslogTag,"<%PRI%>%timegenerated% %HOSTNAME% %msg%" > > # Template to allow for easier reading of the Cisco logs. > # Include a text designation for the type of Cisco equipment. > # Start the message at position at offset 19 to strip out time stamp. > > $template CiscoSW1,"%TIMESTAMP% %HOSTNAME% Switch1: > %msg:19:500:drop-last-lf%\n" > $template CiscoSW2,"%TIMESTAMP% %HOSTNAME% Switch2: > %msg:19:500:drop-last-lf%\n" > $template CiscoTS1,"%TIMESTAMP% %HOSTNAME% Term1: > %msg:19:500:drop-last-lf%\n" > > # Forward messages from the admin server heartbeat and checks based on > message id > :msg, contains, "NHB10001:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10002:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10003:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10004:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CHK10005:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10006:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10007:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10008:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10009:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10011:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10012:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10015:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10016:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "ATH10017:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CLP10020:" > @@127.0.0.1:5140;NoSyslogTag > :msg, contains, "CLP10021:" > @@127.0.0.1:5140;NoSyslogTag > > # Forward messages from juniper nodes basd on message id > :msg, contains, "ADM10310:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM20255:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM20928:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM22798:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM23046:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM24336:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ADM24337:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC22051:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC23037:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC23038:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ARC23039:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT10301:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT21060:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT21089:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT22677:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT22678:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT22696:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT23391:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT23551:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT23552:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT24080:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT24417:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "AUT24418:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20146:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20147:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20148:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20149:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20150:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20151:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20152:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20153:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20154:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20155:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20643:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20644:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR20645:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR24016:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR24019:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "ERR24076:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "LIC10200:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10062:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10087:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10088:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10089:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10090:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10091:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10092:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10093:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10094:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10298:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10299:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS10314:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS23041:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS23402:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS23409:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24015:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24020:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24316:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24317:" > @@127.0.0.1:5140;MissingDate > :msg, contains, "SYS24348:" > @@127.0.0.1:5140;MissingDate > > # Forward messages from F5 nodes based on lb hostnames > :HOSTNAME, contains, "lb1-" > @@127.0.0.1:5140 > :HOSTNAME, contains, "lb2-" > @@127.0.0.1:5140 > > # Log F5 messages locally for archival purposes based on lb hostnames > :HOSTNAME, contains, "lb1-" > /var/log/f5.log > :HOSTNAME, contains, "lb2-" > /var/log/f5.log > > # Log Cisco messages locally for archival purposes based on > ip hostnames > :HOSTNAME, contains, "172.20.20.101" > /var/log/cisco.log > :HOSTNAME, contains, "172.20.20.102" > /var/log/cisco.log > :HOSTNAME, contains, "172.20.20.227" > /var/log/cisco.log > > # Discard lb1/2 and cisco messages from further processing > :HOSTNAME, contains, "lb1-" ~ > :HOSTNAME, contains, "lb2-" ~ > :HOSTNAME, contains, "172.20.20.101" ~ > :HOSTNAME, contains, "172.20.20.102" ~ > :HOSTNAME, contains, "172.20.20.227" ~ > > # Log local7 messages locally for archival purposes > local7.* > /var/log/local7.log > > *.notice;\ > auth,authpriv,cron,ftp,kern,lpr,mail,user,local7.none > /var/log/messages > kern.debug;syslog,user.info > /var/log/messages > auth.info > /var/log/authlog > authpriv.debug > /var/log/secure > cron.info /var/cron/log > daemon.info > /var/log/daemon > ftp.info > /var/log/xferlog > lpr.debug > /var/log/lpd-errs > mail.info > /var/log/maillog > #uucp.info /var/log/uucp > > # Everyone gets emergency messages. > *.emerg > > I've tried to look on the net for anything that had to do with syslog > and file descriptors and or how these problems happen and coming out > with pretty much squat.. > > Thank you, > Dennis O. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From daodennis at gmail.com Tue Feb 17 08:23:05 2009 From: daodennis at gmail.com (Dennis Ordanov) Date: Mon, 16 Feb 2009 23:23:05 -0800 Subject: [rsyslog] rsyslog eating FDs stops logging locally or remotely andeventually dies In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC10@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC10@grfint2.intern.adiscon.com> Message-ID: On Mon, Feb 16, 2009 at 10:18 PM, Rainer Gerhards wrote: > Hi Dennis, > > First thing I would upgrade to a recent release, either v2-stable or > v3-stable. The version you are using is heavily outdated and looking > into the issue with that version simply makes no sense. Plus, I think > chances are good the problem will disappear with the new versions. > Thanks Rainer! I I will look into doing that, if not upgrading OBSD period to something other than 3.8/4.1 (observed on both) for these group of servers (and all the testing that goes along with it...) Thanks, Dennis O. > Rainer > From rgerhards at hq.adiscon.com Tue Feb 17 09:17:53 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 17 Feb 2009 09:17:53 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9D@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com><49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> Hi RB, Consider this a persuasion attempt ;) One thing, though is how to make those things easily acessible. Can we (you? ;)) get it pushed to something like EPEL, or are there other places or would it be sufficient to include some packages on rsyslog.com (made inside a specially created part of the git tree, too). How is this usually done? Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of RB > Sent: Monday, February 16, 2009 11:49 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of > sending devices? > > On Mon, Feb 16, 2009 at 02:25, David Ecker > wrote: > > have you tried to contact the epel group? > > > > http://fedoraproject.org/wiki/EPEL > > > > They should be able to include an upgrade for rsyslog into their > > repository for REL5 if you ask them. > > Failing that, I already wrote one spec for rsyslog-3.x under CentOS-5 > and could be pretty easily persuaded to do so again. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Feb 17 14:46:50 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 17 Feb 2009 14:46:50 +0100 Subject: [rsyslog] Advise Requested - most important features Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Hi all, I have the chance to write an article about rsyslog for one of the largest German *nix magazines. It shall be an overview over rsyslog. I would like to highlight some features. So which ones do you think are most important for *ordinary* users? Feedback is most welcome and my deadline is tight (as usual ;)). I think this is an excellent opportunity to present rsyslog to a wider audience, one that that should be done as well as possible ;) Rainer From kenneho.ndu at gmail.com Tue Feb 17 15:08:06 2009 From: kenneho.ndu at gmail.com (Kenneth Holter) Date: Tue, 17 Feb 2009 15:08:06 +0100 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: Well, I believe local spooling of syslog messages is quite neat. On 2/17/09, Rainer Gerhards wrote: > > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Feedback is most welcome and my > deadline is tight (as usual ;)). > > I think this is an excellent opportunity to present rsyslog to a wider > audience, one that that should be done as well as possible ;) > > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From mbiebl at gmail.com Tue Feb 17 15:19:59 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Tue, 17 Feb 2009 15:19:59 +0100 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: 2009/2/17 Rainer Gerhards : > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Feedback is most welcome and my > deadline is tight (as usual ;)). I think TLS support is pretty cool, db output support probably too. Generally the whole "reliable logging", with on-disk queues, relp etc. is what set's it apart from sysklogd, but definitely a more "advanced" feature that probably not every ordinary user needs. Ordinary users might be interested in the advanced filtering mechanisms, support for "~", templating etc. Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From mrdemeanour at jackpot.uk.net Tue Feb 17 15:22:35 2009 From: mrdemeanour at jackpot.uk.net (Mr. Demeanour) Date: Tue, 17 Feb 2009 14:22:35 +0000 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <499AC82B.9010508@jackpot.uk.net> Rainer Gerhards wrote: > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. > I would like to highlight some features. So which ones do you think > are most important for *ordinary* users? Feedback is most welcome and > my deadline is tight (as usual ;)). > > I think this is an excellent opportunity to present rsyslog to a > wider audience, one that that should be done as well as possible ;) Fantastic support. But I don't know how you do that, when it's you doing the support and you writing the article. Perhaps you need a ghost-writer? -- Jack. From hks.private at gmail.com Tue Feb 17 15:45:59 2009 From: hks.private at gmail.com ((private) HKS) Date: Tue, 17 Feb 2009 09:45:59 -0500 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: On Tue, Feb 17, 2009 at 8:46 AM, Rainer Gerhards wrote: > Hi all, > > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Feedback is most welcome and my > deadline is tight (as usual ;)). > > I think this is an excellent opportunity to present rsyslog to a wider > audience, one that that should be done as well as possible ;) > > Rainer For my usage, the greatest benefits are: From hks.private at gmail.com Tue Feb 17 15:49:08 2009 From: hks.private at gmail.com ((private) HKS) Date: Tue, 17 Feb 2009 09:49:08 -0500 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: On Tue, Feb 17, 2009 at 9:45 AM, (private) HKS wrote: > On Tue, Feb 17, 2009 at 8:46 AM, Rainer Gerhards > wrote: >> Hi all, >> >> I have the chance to write an article about rsyslog for one of the >> largest German *nix magazines. It shall be an overview over rsyslog. I >> would like to highlight some features. So which ones do you think are >> most important for *ordinary* users? Feedback is most welcome and my >> deadline is tight (as usual ;)). >> >> I think this is an excellent opportunity to present rsyslog to a wider >> audience, one that that should be done as well as possible ;) >> >> Rainer > > > For my usage, the greatest benefits are: ...not hitting the send button when I forget that tab doesn't work in Gmail like it does in vi. *ahem* - Reliable delivery (TCP/RELP, spooling of undeliverable messages) - Templates (both for reformatting log messages and for dynamic filenames) - Flexible filtering options - Intuitive configuration for someone already familiar with BSD syslog -HKS From danson at rackspace.com Tue Feb 17 16:19:55 2009 From: danson at rackspace.com (Daniel Anson) Date: Tue, 17 Feb 2009 09:19:55 -0600 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <1509_1234884068_n1HFL0eO003870_96AF20FDF4301D419B33CCE8E3A0132B0B41CC11@SAT4MX07.RACKSPACE.CORP> The disk based queue is IMHO the best feature. I use the database plug-in as well but common users may not use that feature as much. It's simple replacement for the stock syslogd and extended timestamp are useful as well. -Daniel Anson -Rackspace Managed Hosting -Linux Systems Engineer III -----Original Message----- From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards Sent: Tuesday, February 17, 2009 7:47 AM To: rsyslog-users Subject: [rsyslog] Advise Requested - most important features Hi all, I have the chance to write an article about rsyslog for one of the largest German *nix magazines. It shall be an overview over rsyslog. I would like to highlight some features. So which ones do you think are most important for *ordinary* users? Feedback is most welcome and my deadline is tight (as usual ;)). I think this is an excellent opportunity to present rsyslog to a wider audience, one that that should be done as well as possible ;) Rainer _______________________________________________ rsyslog mailing list http://lists.adiscon.net/mailman/listinfo/rsyslog http://www.rsyslog.com Confidentiality Notice: This e-mail message (including any attached or embedded documents) is intended for the exclusive and confidential use of the individual or entity to which this message is addressed, and unless otherwise expressly indicated, is confidential and privileged information of Rackspace. Any dissemination, distribution or copying of the enclosed material is prohibited. If you receive this transmission in error, please notify us immediately by e-mail at abuse at rackspace.com, and delete the original message. Your cooperation is appreciated. From aoz.syn at gmail.com Tue Feb 17 16:40:10 2009 From: aoz.syn at gmail.com (RB) Date: Tue, 17 Feb 2009 08:40:10 -0700 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <4255c2570902170740x3d235c46t2af8d5e2931e7cae@mail.gmail.com> On Tue, Feb 17, 2009 at 06:46, Rainer Gerhards wrote: > I have the chance to write an article about rsyslog for one of the > largest German *nix magazines. It shall be an overview over rsyslog. I > would like to highlight some features. So which ones do you think are > most important for *ordinary* users? Ordinary users: - drop-in syslogd replacement - database integration - templates - TLS Power users: - RELP - queues - template abuse - Heavy focus on RFC compliance - modular input/output (can't wait for that filter framework!) From aoz.syn at gmail.com Tue Feb 17 21:11:39 2009 From: aoz.syn at gmail.com (RB) Date: Tue, 17 Feb 2009 13:11:39 -0700 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> Message-ID: <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> On Tue, Feb 17, 2009 at 01:17, Rainer Gerhards wrote: > Hi RB, > > Consider this a persuasion attempt ;) > > One thing, though is how to make those things easily acessible. Can we > (you? ;)) get it pushed to something like EPEL, or are there other > places or would it be sufficient to include some packages on rsyslog.com > (made inside a specially created part of the git tree, too). How is this > usually done? A quick look upstream shows that Fedora is maintaining a _very_ current package (currently 3.21.10, updated 3 hours ago). The person (Tomas) that seems to have taken over the Fedora SPEC maintenance has an @redhat.com address, so they might be the right person to persuade to get a stable (3.20.4) package into EPEL. I'll ask and see what they say. That said, I haven't tested this yet, but generally speaking Fedora RPMs have worked reasonably well for me under CentOS as long as I'm current. Regardless, I'll take the flag and see what I can do to get a readily-accessible reasonably current build available for CentOS-5. From serbulent at pardus.org.tr Wed Feb 18 07:43:11 2009 From: serbulent at pardus.org.tr (Serbulent UNSAL) Date: Wed, 18 Feb 2009 08:43:11 +0200 Subject: [rsyslog] Advise Requested - most important features In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC2F@grfint2.intern.adiscon.com> Message-ID: <200902180843.11948.serbulent@pardus.org.tr> On Tuesday 17 February 2009 15:46:50 Rainer Gerhards wrote: > I think this is an excellent opportunity to present rsyslog to a wider > audience, one that that should be done as well as possible ;) > > Rainer Flitering is my favorite... -- ?yi ?al??malar, Serb?lent From r.bhatia at ipax.at Wed Feb 18 09:51:50 2009 From: r.bhatia at ipax.at (Raoul Bhatia [IPAX]) Date: Wed, 18 Feb 2009 09:51:50 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at> <577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> Message-ID: <499BCC26.70605@ipax.at> hello rainer, Rainer Gerhards wrote: > Hi Raoul, > > I don't keep track of the bug in the older releases - simply too much > work, especially in this case. The best would be to use v3-stable from > git (I have not yet released a tarball as I'd like to get some feedback > from the field, first - not too often release stable versions..). just for the records - with rsyslog stable with git cs d742b251a6cdac02b235bd7459fa60890a0e6e i have not seen this issue until now. thanks! raoul -- ____________________________________________________________________ DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at Technischer Leiter IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at Barawitzkagasse 10/2/2/11 email. office at ipax.at 1190 Wien tel. +43 1 3670030 FN 277995t HG Wien fax. +43 1 3670030 15 ____________________________________________________________________ From rgerhards at hq.adiscon.com Wed Feb 18 09:56:03 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Wed, 18 Feb 2009 09:56:03 +0100 Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <499BCC26.70605@ipax.at> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at><577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> <499BCC26.70605@ipax.at> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC45@grfint2.intern.adiscon.com> Hi Raoul, thanks for this feedback, much appreciated. And for everyone's information: after this patch, I did not get any new reports of any such abort, but got a number of messages which claim that the situation did no longer occur. David Lang, however, has experienced an issue during HUP processing, which I think is a different issue. So at least the situation has very much improved. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] > Sent: Wednesday, February 18, 2009 9:52 AM > To: rsyslog-users > Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: > double free or corruption (!prev): 0x0000000000ef03b0 *** > > hello rainer, > > Rainer Gerhards wrote: > > Hi Raoul, > > > > I don't keep track of the bug in the older releases - simply too much > > work, especially in this case. The best would be to use v3-stable > from > > git (I have not yet released a tarball as I'd like to get some > feedback > > from the field, first - not too often release stable versions..). > > just for the records - with rsyslog stable with git cs > d742b251a6cdac02b235bd7459fa60890a0e6e i have not seen this issue until > now. > > thanks! > raoul > -- > ____________________________________________________________________ > DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at > Technischer Leiter > > IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at > Barawitzkagasse 10/2/2/11 email. office at ipax.at > 1190 Wien tel. +43 1 3670030 > FN 277995t HG Wien fax. +43 1 3670030 15 > ____________________________________________________________________ > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Wed Feb 18 13:23:14 2009 From: david at lang.hm (david at lang.hm) Date: Wed, 18 Feb 2009 04:23:14 -0800 (PST) Subject: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: double free or corruption (!prev): 0x0000000000ef03b0 *** In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC45@grfint2.intern.adiscon.com> References: <49871292.9000900@ipax.at> <49872714.8050901@ipax.at><577465F99B41C842AAFBE9ED71E70ABA44FAF1@grfint2.intern.adiscon.com> <499BCC26.70605@ipax.at> <577465F99B41C842AAFBE9ED71E70ABA44FC45@grfint2.intern.adiscon.com> Message-ID: On Wed, 18 Feb 2009, Rainer Gerhards wrote: > Hi Raoul, > > thanks for this feedback, much appreciated. > > And for everyone's information: after this patch, I did not get any new > reports of any such abort, but got a number of messages which claim that > the situation did no longer occur. David Lang, however, has experienced > an issue during HUP processing, which I think is a different issue. I have been doing more stress testing and have not duplicated the problem in the last two weeks since I compltely removed the install and reinstalled it. I don't know why, but it is looking like when I install a new .deb on a system with rsyslog in it, it's not replacing all the files (specificly the input and output modules). I know that they are in the .deb becouse if I manually delete them they are installed with a new .deb, but if I don't manually remove them they don't get replaced. since the /debian directory was removed I'm using checkinstall to make the packages. David Lang > So at least the situation has very much improved. > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of Raoul Bhatia [IPAX] >> Sent: Wednesday, February 18, 2009 9:52 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] *** glibc detected *** /usr/sbin/rsyslogd: >> double free or corruption (!prev): 0x0000000000ef03b0 *** >> >> hello rainer, >> >> Rainer Gerhards wrote: >>> Hi Raoul, >>> >>> I don't keep track of the bug in the older releases - simply too > much >>> work, especially in this case. The best would be to use v3-stable >> from >>> git (I have not yet released a tarball as I'd like to get some >> feedback >>> from the field, first - not too often release stable versions..). >> >> just for the records - with rsyslog stable with git cs >> d742b251a6cdac02b235bd7459fa60890a0e6e i have not seen this issue > until >> now. >> >> thanks! >> raoul >> -- >> ____________________________________________________________________ >> DI (FH) Raoul Bhatia M.Sc. email. r.bhatia at ipax.at >> Technischer Leiter >> >> IPAX - Aloy Bhatia Hava OEG web. http://www.ipax.at >> Barawitzkagasse 10/2/2/11 email. office at ipax.at >> 1190 Wien tel. +43 1 3670030 >> FN 277995t HG Wien fax. +43 1 3670030 15 >> ____________________________________________________________________ >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 19 15:16:29 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 19 Feb 2009 15:16:29 +0100 Subject: [rsyslog] requesting log samples Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> Hi all, in an effort to enhance the rsyslog legacy syslog parser, I would appreciate if you could provide me with some *raw* syslog samples. I don't need lots of messages, just a few from as many different devices as possible. What I am primarily interested in is the header and early message parts. The full story is here: http://blog.gerhards.net/2009/02/calling-for-log-samples.html I would deeply appreciate if you could forward this to anyone who could be willing to contribute. Thanks, Rainer From david at lang.hm Thu Feb 19 18:21:46 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 19 Feb 2009 09:21:46 -0800 (PST) Subject: [rsyslog] requesting log samples In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> Message-ID: On Thu, 19 Feb 2009, Rainer Gerhards wrote: > Hi all, > > in an effort to enhance the rsyslog legacy syslog parser, I would > appreciate if you could provide me with some *raw* syslog samples. I > don't need lots of messages, just a few from as many different devices > as possible. What I am primarily interested in is the header and early > message parts. > > The full story is here: > > http://blog.gerhards.net/2009/02/calling-for-log-samples.html have you taken a look at www.loganalysis.org? specificly they have a project for this at http://www.loganalysis.org/sample-logs/samples.html not a lot of things there now, but if you are gathering things it would be good to put them in a place where they can be used by lots of folks. David Lang > I would deeply appreciate if you could forward this to anyone who could > be willing to contribute. > > Thanks, > Rainer > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 19 18:31:09 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 19 Feb 2009 18:31:09 +0100 Subject: [rsyslog] requesting log samples In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FC74@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC7D@grfint2.intern.adiscon.com> Hi David, I know this place and I know Tina, who builds it, quite well. She started collecting a couple of years ago and there were very, very few contributions. One of the primary show stoppers, as I understand it, was that for the purposes stated by loganalysis.org, they needed somewhat bigger logs. I really need only single log entries, as I do not want to analyze them but parse the header. Thus I wanted to give it a new shot and see if I can get more sample for this very limited use case. Plus, I have to admit, loganalysis.org is now owned by splunk and while I like them, I prefer not to stick with something that I cannot control for things that are quite relevant for the work I do. But that is only a secondary reason. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Thursday, February 19, 2009 6:22 PM > To: rsyslog-users > Subject: Re: [rsyslog] requesting log samples > > On Thu, 19 Feb 2009, Rainer Gerhards wrote: > > > Hi all, > > > > in an effort to enhance the rsyslog legacy syslog parser, I would > > appreciate if you could provide me with some *raw* syslog samples. I > > don't need lots of messages, just a few from as many different > devices > > as possible. What I am primarily interested in is the header and > early > > message parts. > > > > The full story is here: > > > > http://blog.gerhards.net/2009/02/calling-for-log-samples.html > > have you taken a look at www.loganalysis.org? > > > specificly they have a project for this at > http://www.loganalysis.org/sample-logs/samples.html > not a lot of things there now, but if you are gathering things it would > be > good to put them in a place where they can be used by lots of folks. > > David Lang > > > I would deeply appreciate if you could forward this to anyone who > could > > be willing to contribute. > > > > Thanks, > > Rainer > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From Luis.Fernando.Munoz.Mejias at cern.ch Fri Feb 20 13:38:15 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Fri, 20 Feb 2009 13:38:15 +0100 Subject: [rsyslog] Extracting a subset of matches on regular expressions? Message-ID: <200902201338.15815.Luis.Fernando.Munoz.Mejias@cern.ch> Hi, there. I'm trying to extract some fields from SSH log in messages, and store in separate fields so that I can easily retrieve user names and source IPs. I have such match: Accepted (.*) for (.*) from ([^[:space:]]) where $1 is the authentication method (password, RSA...), $2 is the user name and $3 is the source IP for the connection. My idea is to place a separator for these fields, and making parsing easy. Something like $_$$_$$_$$_$ I know I could use a template, the same regular expression 3 times and extract one field at a time. But I wonder if it's possible to process the RE once, and then extract ($1, $2, $3) and NOT $0 in one go. This would be much faster, and speed matters to me. Thanks. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From rgerhards at hq.adiscon.com Mon Feb 23 11:13:47 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 23 Feb 2009 11:13:47 +0100 Subject: [rsyslog] Anyone with ties into Ubuntu on this list? Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FC9B@grfint2.intern.adiscon.com> Hi all, is there anyone with ties into Ubuntu on this list (or knows someone who is)? I just learned that Ubuntu seems to ship a very old version of rsyslog[1]. There is a new and well-mainteined Debian package done by Michael Biebl available. I would like to talk to someone who can help get that into Ubuntu (interestingly, Ubuntu this time has way older software than Debian, if that is motivation ;)). Thanks, Rainer [1] http://kb.monitorware.com/install-latest-rsyslog-from-deb-src-on-ubuntu- mbiebl-t8931.html From martinmie at PartyGaming.com Mon Feb 23 16:49:22 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Mon, 23 Feb 2009 16:49:22 +0100 Subject: [rsyslog] rsyslog and load balancers Message-ID: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> Hi all, I've read the docs on rsyslog but everything is related to one server and n-clients sending their logs to it... What if I create at least 2 rsyslog servers and put them behind a load-balancer (on only the virtual IP would be known to the clients)? how to proceed with the TLS certificates for both server and clients? Tips and tricks much appreciated. Cheers, Martin This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From aoz.syn at gmail.com Mon Feb 23 17:12:35 2009 From: aoz.syn at gmail.com (RB) Date: Mon, 23 Feb 2009 09:12:35 -0700 Subject: [rsyslog] rsyslog and load balancers In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> Message-ID: <4255c2570902230812x6f83a2e0m603a153d5460e79@mail.gmail.com> On Mon, Feb 23, 2009 at 08:49, Martin Mielke wrote: > What if I create at least 2 rsyslog servers and put them behind a > load-balancer (on only the virtual IP would be known to the clients)? > how to proceed with the TLS certificates for both server and clients? Although it depends on how you configure your load balancer, it should generally be the same method as a TCP-balanced HTTPS cluster: all server members get the same cert issued for the balanced IP. You'll need to make sure that all packets for a given client session are directed to the same server. Client certs shouldn't be any different than normal. If you plan on using anything other than the client's cert (source IP, hostname, etc.) for identification, filtering, or otherwise, you'll need to route the connections through the LB as opposed to proxying them. From rgerhards at hq.adiscon.com Mon Feb 23 17:44:58 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 23 Feb 2009 17:44:58 +0100 Subject: [rsyslog] rsyslog and load balancers In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCB6@grfint2.intern.adiscon.com> I couldn't stand this ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Monday, February 23, 2009 4:49 PM > To: rsyslog-users > Subject: [rsyslog] rsyslog and load balancers > > > Hi all, > > I've read the docs on rsyslog but everything is related to one server > and n-clients sending their logs to it... > What if I create at least 2 rsyslog servers and put them behind a > load-balancer (on only the virtual IP would be known to the clients)? > how to proceed with the TLS certificates for both server and clients? > > Tips and tricks much appreciated. > > Cheers, > Martin > > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. This conflicts with the list policy ;) Also, there is no way we can delete any copies in the various mail archives that cache this list. Quite seriously, you should forward that as a question to your legal folks (those that make you use such disclaimers ;)). Rainer > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Mon Feb 23 17:43:26 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Mon, 23 Feb 2009 17:43:26 +0100 Subject: [rsyslog] rsyslog and load balancers In-Reply-To: <4255c2570902230812x6f83a2e0m603a153d5460e79@mail.gmail.com> References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> <4255c2570902230812x6f83a2e0m603a153d5460e79@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCB5@grfint2.intern.adiscon.com> I agree to RB here, but I - due to lack of environment - I am not able to verify it. So a success report and some doc when you are done would be very much appreciated. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of RB > Sent: Monday, February 23, 2009 5:13 PM > To: rsyslog-users > Subject: Re: [rsyslog] rsyslog and load balancers > > On Mon, Feb 23, 2009 at 08:49, Martin Mielke > wrote: > > What if I create at least 2 rsyslog servers and put them behind a > > load-balancer (on only the virtual IP would be known to the clients)? > > how to proceed with the TLS certificates for both server and clients? > > Although it depends on how you configure your load balancer, it should > generally be the same method as a TCP-balanced HTTPS cluster: all > server members get the same cert issued for the balanced IP. You'll > need to make sure that all packets for a given client session are > directed to the same server. Client certs shouldn't be any different > than normal. > > If you plan on using anything other than the client's cert (source IP, > hostname, etc.) for identification, filtering, or otherwise, you'll > need to route the connections through the LB as opposed to proxying > them. > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From bakers at web-ster.com Mon Feb 23 19:01:04 2009 From: bakers at web-ster.com (Scott Baker) Date: Mon, 23 Feb 2009 10:01:04 -0800 Subject: [rsyslog] Matching hostname and facility? Message-ID: <49A2E460.50604@web-ster.com> I have an rsyslog.conf entry like this to send everything from my DHCP server to it's own log file on my central rsyslog server. # DHCP logs :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp Is there a way to specify hostname AND a syslog facility? It'd be nice if I could match that host, and local6.* or something like that. Is that possible? - Scott From hks.private at gmail.com Mon Feb 23 23:56:15 2009 From: hks.private at gmail.com ((private) HKS) Date: Mon, 23 Feb 2009 17:56:15 -0500 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: <49A2E460.50604@web-ster.com> References: <49A2E460.50604@web-ster.com> Message-ID: On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker wrote: > I have an rsyslog.conf entry like this to send everything from my DHCP > server to it's own log file on my central rsyslog server. > > # DHCP logs > :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp > > Is there a way to specify hostname AND a syslog facility? It'd be nice if I > could match that host, and local6.* or something like that. Is that possible? > > - Scott > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > #DHCP logs if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == 'local6' then -?dhcp -HKS From david at lang.hm Tue Feb 24 02:11:03 2009 From: david at lang.hm (david at lang.hm) Date: Mon, 23 Feb 2009 17:11:03 -0800 (PST) Subject: [rsyslog] UDP source forging. Message-ID: I have a need to use some products that are stupid enough to ignore the host field in the syslog message and instead base everything on the IP address the message originates from. some other syslog servers can handle this by forging the source of the UDP packet, can rsyslog do this? one way that I know to do this is to issue a bind command to set the source IP, send the packet, then close the 'connection' (with the kernel set to allow non-local-binds), I've hacked sysklogd to do this sort of thing in the past. another way is to send out raw packets (which I believe requires root access). I suspect that this would require more drastic changes to support, but may have slightly higher performance. David Lang From aoz.syn at gmail.com Tue Feb 24 04:29:25 2009 From: aoz.syn at gmail.com (RB) Date: Mon, 23 Feb 2009 20:29:25 -0700 Subject: [rsyslog] UDP source forging. In-Reply-To: References: Message-ID: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> On Mon, Feb 23, 2009 at 18:11, wrote: > I have a need to use some products that are stupid enough to ignore the > host field in the syslog message and instead base everything on the IP > address the message originates from. > > some other syslog servers can handle this by forging the source of the UDP > packet, can rsyslog do this? So is rsyslog originating the messages, or are you using it to aggregate them and then feed them on to the other [bad] acceptors? I am unaware of a way to get rsyslog to forge packets (short of writing an output module), but unless you must get another syslog daemon into the mix, you may be better off just feeding your messages directly to the other collector. From david at lang.hm Tue Feb 24 04:40:25 2009 From: david at lang.hm (david at lang.hm) Date: Mon, 23 Feb 2009 19:40:25 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> Message-ID: On Mon, 23 Feb 2009, RB wrote: > On Mon, Feb 23, 2009 at 18:11, wrote: >> I have a need to use some products that are stupid enough to ignore the >> host field in the syslog message and instead base everything on the IP >> address the message originates from. >> >> some other syslog servers can handle this by forging the source of the UDP >> packet, can rsyslog do this? > > So is rsyslog originating the messages, or are you using it to > aggregate them and then feed them on to the other [bad] acceptors? I > am unaware of a way to get rsyslog to forge packets (short of writing > an output module), but unless you must get another syslog daemon into > the mix, you may be better off just feeding your messages directly to > the other collector. rsyslog would be the relay from one non-routed network to another non-routed network. this could be a fairly simple change to the UDP output module (adding a couple commands around the sending of a message), but before I dove in to do that I wanted to see if I had missed this feature anywhere. David Lang From rgerhards at hq.adiscon.com Tue Feb 24 08:43:49 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 08:43:49 +0100 Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> Hi David et all, Currently rsyslog does not support this and I have to admit I was always very hesitant to add it (I see potential for misuse). Co-incidentally, I received a similar request and was about to relay it to the mailing list to gather feedback. As it looks, this no longer is necessary ;) When I thought about implementation, I originally thought about raw sockets (which indeed require root access), but if there is any other way, I would be most interested. If you can provide some code, I will happily integrate it. I think an addition to the omfwd module, in udp forwarding, together with a new directive ($SpoofOriginalUDPAddress or so...) would be the right way to go. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com > [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, February 24, 2009 4:40 AM > To: rsyslog-users > Subject: Re: [rsyslog] UDP source forging. > > On Mon, 23 Feb 2009, RB wrote: > > > On Mon, Feb 23, 2009 at 18:11, wrote: > >> I have a need to use some products that are stupid enough > to ignore the > >> host field in the syslog message and instead base > everything on the IP > >> address the message originates from. > >> > >> some other syslog servers can handle this by forging the > source of the UDP > >> packet, can rsyslog do this? > > > > So is rsyslog originating the messages, or are you using it to > > aggregate them and then feed them on to the other [bad] > acceptors? I > > am unaware of a way to get rsyslog to forge packets (short > of writing > > an output module), but unless you must get another syslog > daemon into > > the mix, you may be better off just feeding your messages > directly to > > the other collector. > > rsyslog would be the relay from one non-routed network to another > non-routed network. > > this could be a fairly simple change to the UDP output module > (adding a > couple commands around the sending of a message), but before > I dove in to > do that I wanted to see if I had missed this feature anywhere. > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Tue Feb 24 09:43:17 2009 From: david at lang.hm (david at lang.hm) Date: Tue, 24 Feb 2009 00:43:17 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> Message-ID: On Tue, 24 Feb 2009, Rainer Gerhards wrote: > Hi David et all, > > Currently rsyslog does not support this and I have to admit I was always > very hesitant to add it (I see potential for misuse). Co-incidentally, I > received a similar request and was about to relay it to the mailing list > to gather feedback. As it looks, this no longer is necessary ;) > > When I thought about implementation, I originally thought about raw > sockets (which indeed require root access), but if there is any other > way, I would be most interested. If you can provide some code, I will > happily integrate it. I think an addition to the omfwd module, in udp > forwarding, together with a new directive ($SpoofOriginalUDPAddress or > so...) would be the right way to go. I'll see about hacking in some example code (probably without any config option and not thread-safe) and send it to you. there's another similar change in the same area that I was looking at, I'll mock it up as well. David Lang > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com >> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Tuesday, February 24, 2009 4:40 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] UDP source forging. >> >> On Mon, 23 Feb 2009, RB wrote: >> >>> On Mon, Feb 23, 2009 at 18:11, wrote: >>>> I have a need to use some products that are stupid enough >> to ignore the >>>> host field in the syslog message and instead base >> everything on the IP >>>> address the message originates from. >>>> >>>> some other syslog servers can handle this by forging the >> source of the UDP >>>> packet, can rsyslog do this? >>> >>> So is rsyslog originating the messages, or are you using it to >>> aggregate them and then feed them on to the other [bad] >> acceptors? I >>> am unaware of a way to get rsyslog to forge packets (short >> of writing >>> an output module), but unless you must get another syslog >> daemon into >>> the mix, you may be better off just feeding your messages >> directly to >>> the other collector. >> >> rsyslog would be the relay from one non-routed network to another >> non-routed network. >> >> this could be a fairly simple change to the UDP output module >> (adding a >> couple commands around the sending of a message), but before >> I dove in to >> do that I wanted to see if I had missed this feature anywhere. >> >> David Lang >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Tue Feb 24 09:44:24 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 09:44:24 +0100 Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> David, Excellent, please do as you have time. I'll make sure it fits. Thread-safety, btw., is not a big issue at this level as the output modules are guaranteed to be never called by multiple threads concurrently. That was a trade-off to enable other folks to easily write them (but I have an option in the back of my head that a module can tell the engine it *is* capable to run on multiple threads concurrently...). Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Tuesday, February 24, 2009 9:43 AM > To: rsyslog-users > Subject: Re: [rsyslog] UDP source forging. > > On Tue, 24 Feb 2009, Rainer Gerhards wrote: > > > Hi David et all, > > > > Currently rsyslog does not support this and I have to admit I was > always > > very hesitant to add it (I see potential for misuse). Co- > incidentally, I > > received a similar request and was about to relay it to the mailing > list > > to gather feedback. As it looks, this no longer is necessary ;) > > > > When I thought about implementation, I originally thought about raw > > sockets (which indeed require root access), but if there is any other > > way, I would be most interested. If you can provide some code, I will > > happily integrate it. I think an addition to the omfwd module, in udp > > forwarding, together with a new directive ($SpoofOriginalUDPAddress > or > > so...) would be the right way to go. > > I'll see about hacking in some example code (probably without any > config > option and not thread-safe) and send it to you. > > there's another similar change in the same area that I was looking at, > I'll mock it up as well. > > David Lang > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com > >> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of > david at lang.hm > >> Sent: Tuesday, February 24, 2009 4:40 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] UDP source forging. > >> > >> On Mon, 23 Feb 2009, RB wrote: > >> > >>> On Mon, Feb 23, 2009 at 18:11, wrote: > >>>> I have a need to use some products that are stupid enough > >> to ignore the > >>>> host field in the syslog message and instead base > >> everything on the IP > >>>> address the message originates from. > >>>> > >>>> some other syslog servers can handle this by forging the > >> source of the UDP > >>>> packet, can rsyslog do this? > >>> > >>> So is rsyslog originating the messages, or are you using it to > >>> aggregate them and then feed them on to the other [bad] > >> acceptors? I > >>> am unaware of a way to get rsyslog to forge packets (short > >> of writing > >>> an output module), but unless you must get another syslog > >> daemon into > >>> the mix, you may be better off just feeding your messages > >> directly to > >>> the other collector. > >> > >> rsyslog would be the relay from one non-routed network to another > >> non-routed network. > >> > >> this could be a fairly simple change to the UDP output module > >> (adding a > >> couple commands around the sending of a message), but before > >> I dove in to > >> do that I wanted to see if I had missed this feature anywhere. > >> > >> David Lang > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > >> > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From martinmie at PartyGaming.com Tue Feb 24 15:47:30 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Tue, 24 Feb 2009 15:47:30 +0100 Subject: [rsyslog] Not logging TCP connections? Message-ID: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> Hi, Sorry to sound a bit blonde here but... I need rsyslog to accept both TCP and UDP connections to port 514. I have the following relevant parts on the server side: -- ... $DefaultNetstreamDriver ptcp # UDP Syslog Server: $UDPServerRun 514 # start a UDP syslog server at standard port 514 $InputTCPServerStreamDriverAuthMode anon $InputTCPServerStreamDriverPermittedPeer *.mydomain $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode $InputTCPServerRun 514 ... -- ...also disabled all the certificates/keys files just in case And on the client side> -- # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional *.* @logserver.mydomain -- After restarting rsyslog on the server it only logs UDP traffic... Am I overseeing something the obvious? Regards, Martin This email and any attachments are confidential, and may be legally privileged and protected by copyright. If you are not the intended recipient dissemination or copying of this email is prohibited. If you have received this in error, please notify the sender by replying by email and then delete the email completely from your system. Any views or opinions are solely those of the sender. This communication is not intended to form a binding contract unless expressly indicated to the contrary and properly authorised. Any actions taken on the basis of this email are at the recipient's own risk. From rgerhards at hq.adiscon.com Tue Feb 24 15:53:13 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 15:53:13 +0100 Subject: [rsyslog] Not logging TCP connections? In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> Martin, on the client @ is udp while @@ is TCP (!) ;) Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Tuesday, February 24, 2009 3:48 PM > To: rsyslog-users > Subject: [rsyslog] Not logging TCP connections? > > Hi, > > Sorry to sound a bit blonde here but... > I need rsyslog to accept both TCP and UDP connections to port 514. > > I have the following relevant parts on the server side: > -- > ... > $DefaultNetstreamDriver ptcp > > # UDP Syslog Server: > $UDPServerRun 514 # start a UDP syslog server at standard port 514 > > > $InputTCPServerStreamDriverAuthMode anon > $InputTCPServerStreamDriverPermittedPeer *.mydomain > $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode > $InputTCPServerRun 514 > ... > -- > > ...also disabled all the certificates/keys files just in case > > > And on the client side> > -- > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional > *.* @logserver.mydomain > -- > > After restarting rsyslog on the server it only logs UDP traffic... > > Am I overseeing something the obvious? > > > Regards, > Martin > > > This email and any attachments are confidential, and may be legally > privileged and protected by copyright. If you are not the intended > recipient dissemination or copying of this email is prohibited. If you > have received this in error, please notify the sender by replying by > email and then delete the email completely from your system. > > Any views or opinions are solely those of the sender. This > communication is not intended to form a binding contract unless > expressly indicated to the contrary and properly authorised. Any > actions taken on the basis of this email are at the recipient's own > risk. > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From martinmie at PartyGaming.com Tue Feb 24 16:31:52 2009 From: martinmie at PartyGaming.com (Martin Mielke) Date: Tue, 24 Feb 2009 16:31:52 +0100 Subject: [rsyslog] Not logging TCP connections? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> References: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local> <577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> Message-ID: <0B1B9163138571439EAF804646F3F6AA06B9D148@GIBSVWIN004X.partygaming.local> Yes, sorry. Copy & paste worked bad. I just removed some unnecessary lines and re-ordered some directives. Now it works. Sorry for the noise. Martin > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > Sent: 24 February 2009 15:53 > To: rsyslog-users > Subject: Re: [rsyslog] Not logging TCP connections? > > Martin, on the client @ is udp while @@ is TCP (!) ;) > > Rainer > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > > Sent: Tuesday, February 24, 2009 3:48 PM > > To: rsyslog-users > > Subject: [rsyslog] Not logging TCP connections? > > > > Hi, > > > > Sorry to sound a bit blonde here but... > > I need rsyslog to accept both TCP and UDP connections to port 514. > > > > I have the following relevant parts on the server side: > > -- > > ... > > $DefaultNetstreamDriver ptcp > > > > # UDP Syslog Server: > > $UDPServerRun 514 # start a UDP syslog server at standard port 514 > > > > > > $InputTCPServerStreamDriverAuthMode anon > > $InputTCPServerStreamDriverPermittedPeer *.mydomain > > $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode > > $InputTCPServerRun 514 > > ... > > -- > > > > ...also disabled all the certificates/keys files just in case > > > > > > And on the client side> > > -- > > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional > > *.* @logserver.mydomain > > -- > > > > After restarting rsyslog on the server it only logs UDP traffic... > > > > Am I overseeing something the obvious? > > > > > > Regards, > > Martin > > > > > > This email and any attachments are confidential, and may be legally > > privileged and protected by copyright. If you are not the intended > > recipient dissemination or copying of this email is prohibited. If you > > have received this in error, please notify the sender by replying by > > email and then delete the email completely from your system. > > > > Any views or opinions are solely those of the sender. This > > communication is not intended to form a binding contract unless > > expressly indicated to the contrary and properly authorised. Any > > actions taken on the basis of this email are at the recipient's own > > risk. > > > > > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Tue Feb 24 16:51:42 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Tue, 24 Feb 2009 16:51:42 +0100 Subject: [rsyslog] Not logging TCP connections? In-Reply-To: <0B1B9163138571439EAF804646F3F6AA06B9D148@GIBSVWIN004X.partygaming.local> References: <0B1B9163138571439EAF804646F3F6AA06B9D11C@GIBSVWIN004X.partygaming.local><577465F99B41C842AAFBE9ED71E70ABA44FCD5@grfint2.intern.adiscon.com> <0B1B9163138571439EAF804646F3F6AA06B9D148@GIBSVWIN004X.partygaming.local> Message-ID: <577465F99B41C842AAFBE9ED71E70ABA44FCDC@grfint2.intern.adiscon.com> No problem at all ;) > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > Sent: Tuesday, February 24, 2009 4:32 PM > To: rsyslog-users > Subject: Re: [rsyslog] Not logging TCP connections? > > Yes, sorry. Copy & paste worked bad. > > I just removed some unnecessary lines and re-ordered some directives. > Now it works. > > Sorry for the noise. > > > Martin > > > > -----Original Message----- > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > bounces at lists.adiscon.com] On Behalf Of Rainer Gerhards > > Sent: 24 February 2009 15:53 > > To: rsyslog-users > > Subject: Re: [rsyslog] Not logging TCP connections? > > > > Martin, on the client @ is udp while @@ is TCP (!) ;) > > > > Rainer > > > > > -----Original Message----- > > > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > > > bounces at lists.adiscon.com] On Behalf Of Martin Mielke > > > Sent: Tuesday, February 24, 2009 3:48 PM > > > To: rsyslog-users > > > Subject: [rsyslog] Not logging TCP connections? > > > > > > Hi, > > > > > > Sorry to sound a bit blonde here but... > > > I need rsyslog to accept both TCP and UDP connections to port 514. > > > > > > I have the following relevant parts on the server side: > > > -- > > > ... > > > $DefaultNetstreamDriver ptcp > > > > > > # UDP Syslog Server: > > > $UDPServerRun 514 # start a UDP syslog server at standard port 514 > > > > > > > > > $InputTCPServerStreamDriverAuthMode anon > > > $InputTCPServerStreamDriverPermittedPeer *.mydomain > > > $InputTCPServerStreamDriverMode 0 # run driver in no-TLS mode > > > $InputTCPServerRun 514 > > > ... > > > -- > > > > > > ...also disabled all the certificates/keys files just in case > > > > > > > > > And on the client side> > > > -- > > > # remote host is: name/ip:port, e.g. 192.168.0.1:514, port optional > > > *.* @logserver.mydomain > > > -- > > > > > > After restarting rsyslog on the server it only logs UDP traffic... > > > > > > Am I overseeing something the obvious? > > > > > > > > > Regards, > > > Martin > > > > > > > > > This email and any attachments are confidential, and may be legally > > > privileged and protected by copyright. If you are not the intended > > > recipient dissemination or copying of this email is prohibited. If > you > > > have received this in error, please notify the sender by replying > by > > > email and then delete the email completely from your system. > > > > > > Any views or opinions are solely those of the sender. This > > > communication is not intended to form a binding contract unless > > > expressly indicated to the contrary and properly authorised. Any > > > actions taken on the basis of this email are at the recipient's own > > > risk. > > > > > > > > > _______________________________________________ > > > rsyslog mailing list > > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > > http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From bakers at web-ster.com Wed Feb 25 21:08:01 2009 From: bakers at web-ster.com (Scott Baker) Date: Wed, 25 Feb 2009 12:08:01 -0800 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: References: <49A2E460.50604@web-ster.com> Message-ID: <49A5A521.8040107@web-ster.com> On 02/23/2009 02:56 PM, (private) HKS wrote: > On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker wrote: >> I have an rsyslog.conf entry like this to send everything from my DHCP >> server to it's own log file on my central rsyslog server. >> >> # DHCP logs >> :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp >> >> Is there a way to specify hostname AND a syslog facility? It'd be nice if I >> could match that host, and local6.* or something like that. Is that possible? >> >> - Scott >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com >> > > > #DHCP logs > if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == > 'local6' then -?dhcp Does this syntax work on rsyslog 2.0.x, that's what my server has on it. I've tried this syntax, but it's not logging. - Scott From david at lang.hm Wed Feb 25 21:47:20 2009 From: david at lang.hm (david at lang.hm) Date: Wed, 25 Feb 2009 12:47:20 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> Message-ID: figuring out how to do this is navigating a twisty maze of helper functions, all different ;-) there are a few things that look odd here if I am reading the code properly. rsyslog makes one call to the UDPSend routine for all forwarded messages, this means that they must all send the same format. the UDPSend routine then walks through all destinations attempting to send the message to them. and considers the message successfully sent if any of them can be sent. I would have expected that it would only be considered successful if all of them succeded. UDPSend attempts to use the sockets that were created to listening for messages to send it's message out. in a multi-homed machine the local IP address of those sockets may not be appropriate for the relay. also, what would happen if a system recieves via TCP and forwards via UDP and so doesn't have any UDP listener sockets. so now, my suggestion On Linux in /etc/sysctl.conf add the line net.ipv4.ip_nonlocal_bind=1 this tells the kernel not to fail bind requests to IP addresses that don't exist on the box then in omfwd.c in the routine that calls UDPSend, modify it to pass the source IP address of the message to UDPSend create a new filehandle array to use for outbound messages (one filehandle for each destination since they may end up with different source IPs) in UDPSend three options. 1. default use the appropriate filehandle for each destination and send the message. this is similar to what currently takes place, but instead of walking through each open socket for each destination, there should only be one sendto per destination. when opening the socket it should not be nessasary to do a bind, just issue the socket call. if there is anything in the syslog standard specifying the source port (I don't think there is, although many implementations use port 514 becouse they do the same thing that rsyslog is doing and re-use listening sockets to send messages) 2. randomize source ports to support external load balancers same as default, except that every X (configurable) messages close and re-open the sockets. the reason for this is that each time a message is first sent the OS picks a random source port that will be used for all messages sent through that socket. by closing the socket once in a while, load balancers that balance based on source IP + source port + destination IP + destination port will be able to function (a similar feature for TCP based transports would be useful for the same reason) 3. forge the source IP/port for each message that is sent, open a new socket, then issue a 'bind' command for that socket (filehandle) that sets the local IP address to the IP address that the message initially came from, then issue the sendto, then close the filehandle. there is no need for an array of sockets in this case as the socket needs to be re-opened for each message/destination. in theory there is a possibility of a performance gain by keeping sockets open and re-using them, but since each socket is unique to the sender + destination there would be a large number of sockets and a low probability of re-using a socket for the next message. in sysklogd I implemented #2 with the simple code below (once I created a different filehandle to use for outbound connections) this closed and re-opened the socket for each message, doing it every X messages would save on the overhead and be just as good in practice. the bind command that's commented out is basicly what would be needed for #3, but with real values for the source.sin_addr.s_addr (and source.sin_port if you wanted to forge the port as well, leaving it zero lets the OS pick a port number) if (finet >0) { /* close and re-open the outbound socket after each message so that the source port is randomized and load balancers can distribute the messages */ close(finet); finet = create_inet_socket(); /* if we want to forge the source IP for the outbound packets, this is the place to do it by seeting the IP address to the address we received the message from struct sockaddr_in source; source.sin_addr.s_addr = 0x00000000; source.sin_port = 0x0000; bind(finet,(struct sockaddr *) &source,sizeof(source));*/ } the create_inet_socket() routine is: static int create_inet_socket() { int fd, on = 1; int sockflags; fd = socket(AF_INET, SOCK_DGRAM, 0); if (fd < 0) { logerror("syslog: Unknown protocol, suspending inet service."); return fd; } if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, \ (char *) &on, sizeof(on)) < 0 ) { logerror("setsockopt(REUSEADDR), suspending inet"); close(fd); return -1; } /* We must not block on the network socket, in case a packet * gets lost between select and recv, otherise the process * will stall until the timeout, and other processes trying to * log will also stall. */ if ((sockflags = fcntl(fd, F_GETFL)) != -1) { sockflags |= O_NONBLOCK; /* * SETFL could fail too, so get it caught by the subsequent * error check. */ sockflags = fcntl(fd, F_SETFL, sockflags); } if (sockflags == -1) { logerror("fcntl(O_NONBLOCK), suspending inet"); close(fd); return -1; } return fd; } this isn't a patch like you asked for and I offered to put togeather, but is it enough to clearly explain this? if not I can continue to work on the patch. David Lang On Tue, 24 Feb 2009, Rainer Gerhards wrote: > David, > > Excellent, please do as you have time. I'll make sure it fits. > Thread-safety, btw., is not a big issue at this level as the output > modules are guaranteed to be never called by multiple threads > concurrently. That was a trade-off to enable other folks to easily write > them (but I have an option in the back of my head that a module can tell > the engine it *is* capable to run on multiple threads concurrently...). > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Tuesday, February 24, 2009 9:43 AM >> To: rsyslog-users >> Subject: Re: [rsyslog] UDP source forging. >> >> On Tue, 24 Feb 2009, Rainer Gerhards wrote: >> >>> Hi David et all, >>> >>> Currently rsyslog does not support this and I have to admit I was >> always >>> very hesitant to add it (I see potential for misuse). Co- >> incidentally, I >>> received a similar request and was about to relay it to the mailing >> list >>> to gather feedback. As it looks, this no longer is necessary ;) >>> >>> When I thought about implementation, I originally thought about raw >>> sockets (which indeed require root access), but if there is any > other >>> way, I would be most interested. If you can provide some code, I > will >>> happily integrate it. I think an addition to the omfwd module, in > udp >>> forwarding, together with a new directive ($SpoofOriginalUDPAddress >> or >>> so...) would be the right way to go. >> >> I'll see about hacking in some example code (probably without any >> config >> option and not thread-safe) and send it to you. >> >> there's another similar change in the same area that I was looking at, >> I'll mock it up as well. >> >> David Lang >> >>> Rainer >>> >>>> -----Original Message----- >>>> From: rsyslog-bounces at lists.adiscon.com >>>> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of >> david at lang.hm >>>> Sent: Tuesday, February 24, 2009 4:40 AM >>>> To: rsyslog-users >>>> Subject: Re: [rsyslog] UDP source forging. >>>> >>>> On Mon, 23 Feb 2009, RB wrote: >>>> >>>>> On Mon, Feb 23, 2009 at 18:11, wrote: >>>>>> I have a need to use some products that are stupid enough >>>> to ignore the >>>>>> host field in the syslog message and instead base >>>> everything on the IP >>>>>> address the message originates from. >>>>>> >>>>>> some other syslog servers can handle this by forging the >>>> source of the UDP >>>>>> packet, can rsyslog do this? >>>>> >>>>> So is rsyslog originating the messages, or are you using it to >>>>> aggregate them and then feed them on to the other [bad] >>>> acceptors? I >>>>> am unaware of a way to get rsyslog to forge packets (short >>>> of writing >>>>> an output module), but unless you must get another syslog >>>> daemon into >>>>> the mix, you may be better off just feeding your messages >>>> directly to >>>>> the other collector. >>>> >>>> rsyslog would be the relay from one non-routed network to another >>>> non-routed network. >>>> >>>> this could be a fairly simple change to the UDP output module >>>> (adding a >>>> couple commands around the sending of a message), but before >>>> I dove in to >>>> do that I wanted to see if I had missed this feature anywhere. >>>> >>>> David Lang >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com >>>> >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From hks.private at gmail.com Thu Feb 26 00:38:32 2009 From: hks.private at gmail.com ((private) HKS) Date: Wed, 25 Feb 2009 18:38:32 -0500 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: <49A5A521.8040107@web-ster.com> References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> Message-ID: On Wed, Feb 25, 2009 at 3:08 PM, Scott Baker wrote: > On 02/23/2009 02:56 PM, (private) HKS wrote: >> On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker ?wrote: >>> I have an rsyslog.conf entry like this to send everything from my DHCP >>> server to it's own log file on my central rsyslog server. >>> >>> # DHCP logs >>> :FROMHOST, isequal, "dhcp-server.domain.com" ? ? ? ? ? ? -?dhcp >>> >>> Is there a way to specify hostname AND a syslog facility? It'd be nice if I >>> could match that host, and local6.* or something like that. Is that possible? >>> >>> - Scott >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> >> >> #DHCP logs >> if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == >> 'local6' then -?dhcp > > Does this syntax work on rsyslog 2.0.x, that's what my server has on it. > I've tried this syntax, but it's not logging. > > - Scott No, this will require 3+ - which you really should upgrade to anyway. -HKS From rgerhards at hq.adiscon.com Thu Feb 26 14:34:05 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 14:34:05 +0100 Subject: [rsyslog] UDP source forging. References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> Hi David, I think you got lost in the callbacks. The multiple send calls are not for multiple actions. This is all for one action. That code was contributed as part of the IPv6 port. I verified the implementation with what I could find as references to sending on IPv6 and think the implementation uses proper procedures for that environment. In essence, on an IPv6-enabled system, you will receive multiple sockets that you potentially can use to send the message. What the code does is iterate over these sockets and see which one really works. There is also an option (not checked but pretty sure) that permits sending to all receivers. I think that was the other situation you have seen. The listen socket is NOT being reused for sending. RFC3164 actually recommends that port 514 is used as the source port, and we had a lengthy discussion at the IETF about this recommendation. The bottom line is that you cannot reuse the receive socket on a highly parallel syslogd because each thread needs its own (or you have even more sync). Rsyslog creates a new (set of) send sockets *per action*. I guess part of the confusion stems back from your understanding of sysklogd code. Sysklogd works totally different here. I hope this clarifies a bit. I will try to have a look at the code provided asap and see what I can do. Its unfortunately still very busy, so I can not commit when I will finally start. HTH Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of david at lang.hm > Sent: Wednesday, February 25, 2009 9:47 PM > To: rsyslog-users > Subject: Re: [rsyslog] UDP source forging. > > figuring out how to do this is navigating a twisty maze of helper > functions, all different ;-) > > there are a few things that look odd here if I am reading the code > properly. > > rsyslog makes one call to the UDPSend routine for all forwarded > messages, > this means that they must all send the same format. > > the UDPSend routine then walks through all destinations attempting to > send > the message to them. and considers the message successfully sent if any > of > them can be sent. I would have expected that it would only be > considered > successful if all of them succeded. > > UDPSend attempts to use the sockets that were created to listening for > messages to send it's message out. in a multi-homed machine the local > IP > address of those sockets may not be appropriate for the relay. also, > what > would happen if a system recieves via TCP and forwards via UDP and so > doesn't have any UDP listener sockets. > > > so now, my suggestion > > On Linux in /etc/sysctl.conf add the line > > net.ipv4.ip_nonlocal_bind=1 > > this tells the kernel not to fail bind requests to IP addresses that > don't > exist on the box > > then in omfwd.c > > in the routine that calls UDPSend, modify it to pass the source IP > address > of the message to UDPSend > > create a new filehandle array to use for outbound messages (one > filehandle > for each destination since they may end up with different source IPs) > > > in UDPSend > > three options. > > > 1. default > > use the appropriate filehandle for each destination and send the > message. this is similar to what currently takes place, but instead of > walking through each open socket for each destination, there should > only > be one sendto per destination. when opening the socket it should not be > nessasary to do a bind, just issue the socket call. > > if there is anything in the syslog standard specifying the source > port > (I don't think there is, although many implementations use port 514 > becouse they do the same thing that rsyslog is doing and re-use > listening > sockets to send messages) > > > 2. randomize source ports to support external load balancers > > same as default, except that every X (configurable) messages close > and > re-open the sockets. > > the reason for this is that each time a message is first sent the OS > picks a random source port that will be used for all messages sent > through > that socket. by closing the socket once in a while, load balancers that > balance based on source IP + source port + destination IP + destination > port will be able to function (a similar feature for TCP based > transports > would be useful for the same reason) > > > 3. forge the source IP/port > > for each message that is sent, open a new socket, then issue a > 'bind' > command for that socket (filehandle) that sets the local IP address to > the > IP address that the message initially came from, then issue the sendto, > then close the filehandle. > > there is no need for an array of sockets in this case as the socket > needs to be re-opened for each message/destination. in theory there is > a > possibility of a performance gain by keeping sockets open and re-using > them, but since each socket is unique to the sender + destination there > would be a large number of sockets and a low probability of re-using a > socket for the next message. > > in sysklogd I implemented #2 with the simple code below (once I created > a > different filehandle to use for outbound connections) > > this closed and re-opened the socket for each message, doing it every X > messages would save on the overhead and be just as good in practice. > > the bind command that's commented out is basicly what would be needed > for > #3, but with real values for the source.sin_addr.s_addr (and > source.sin_port if you wanted to forge the port as well, leaving it > zero > lets the OS pick a port number) > > if (finet >0) { > /* close and re-open the outbound socket after each message so > that the source port is randomized and load balancers can distribute > the messages */ > close(finet); > finet = create_inet_socket(); > /* if we want to forge the source IP for the outbound packets, > this is the place to do it by seeting the IP address to the address we > received the message from > struct sockaddr_in source; > source.sin_addr.s_addr = 0x00000000; > source.sin_port = 0x0000; > bind(finet,(struct sockaddr *) > &source,sizeof(source));*/ > } > > > the create_inet_socket() routine is: > > static int create_inet_socket() > { > int fd, on = 1; > int sockflags; > > fd = socket(AF_INET, SOCK_DGRAM, 0); > if (fd < 0) { > logerror("syslog: Unknown protocol, suspending inet > service."); > return fd; > } > > if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, \ > (char *) &on, sizeof(on)) < 0 ) { > logerror("setsockopt(REUSEADDR), suspending inet"); > close(fd); > return -1; > } > /* We must not block on the network socket, in case a packet > * gets lost between select and recv, otherise the process > * will stall until the timeout, and other processes trying to > * log will also stall. > */ > if ((sockflags = fcntl(fd, F_GETFL)) != -1) { > sockflags |= O_NONBLOCK; > /* > * SETFL could fail too, so get it caught by the > subsequent > * error check. > */ > sockflags = fcntl(fd, F_SETFL, sockflags); > } > if (sockflags == -1) { > logerror("fcntl(O_NONBLOCK), suspending inet"); > close(fd); > return -1; > } > return fd; > } > > > this isn't a patch like you asked for and I offered to put togeather, > but > is it enough to clearly explain this? if not I can continue to work on > the > patch. > > David Lang > > On Tue, 24 Feb 2009, Rainer Gerhards wrote: > > > David, > > > > Excellent, please do as you have time. I'll make sure it fits. > > Thread-safety, btw., is not a big issue at this level as the output > > modules are guaranteed to be never called by multiple threads > > concurrently. That was a trade-off to enable other folks to easily > write > > them (but I have an option in the back of my head that a module can > tell > > the engine it *is* capable to run on multiple threads > concurrently...). > > > > Rainer > > > >> -----Original Message----- > >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm > >> Sent: Tuesday, February 24, 2009 9:43 AM > >> To: rsyslog-users > >> Subject: Re: [rsyslog] UDP source forging. > >> > >> On Tue, 24 Feb 2009, Rainer Gerhards wrote: > >> > >>> Hi David et all, > >>> > >>> Currently rsyslog does not support this and I have to admit I was > >> always > >>> very hesitant to add it (I see potential for misuse). Co- > >> incidentally, I > >>> received a similar request and was about to relay it to the mailing > >> list > >>> to gather feedback. As it looks, this no longer is necessary ;) > >>> > >>> When I thought about implementation, I originally thought about raw > >>> sockets (which indeed require root access), but if there is any > > other > >>> way, I would be most interested. If you can provide some code, I > > will > >>> happily integrate it. I think an addition to the omfwd module, in > > udp > >>> forwarding, together with a new directive ($SpoofOriginalUDPAddress > >> or > >>> so...) would be the right way to go. > >> > >> I'll see about hacking in some example code (probably without any > >> config > >> option and not thread-safe) and send it to you. > >> > >> there's another similar change in the same area that I was looking > at, > >> I'll mock it up as well. > >> > >> David Lang > >> > >>> Rainer > >>> > >>>> -----Original Message----- > >>>> From: rsyslog-bounces at lists.adiscon.com > >>>> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of > >> david at lang.hm > >>>> Sent: Tuesday, February 24, 2009 4:40 AM > >>>> To: rsyslog-users > >>>> Subject: Re: [rsyslog] UDP source forging. > >>>> > >>>> On Mon, 23 Feb 2009, RB wrote: > >>>> > >>>>> On Mon, Feb 23, 2009 at 18:11, wrote: > >>>>>> I have a need to use some products that are stupid enough > >>>> to ignore the > >>>>>> host field in the syslog message and instead base > >>>> everything on the IP > >>>>>> address the message originates from. > >>>>>> > >>>>>> some other syslog servers can handle this by forging the > >>>> source of the UDP > >>>>>> packet, can rsyslog do this? > >>>>> > >>>>> So is rsyslog originating the messages, or are you using it to > >>>>> aggregate them and then feed them on to the other [bad] > >>>> acceptors? I > >>>>> am unaware of a way to get rsyslog to forge packets (short > >>>> of writing > >>>>> an output module), but unless you must get another syslog > >>>> daemon into > >>>>> the mix, you may be better off just feeding your messages > >>>> directly to > >>>>> the other collector. > >>>> > >>>> rsyslog would be the relay from one non-routed network to another > >>>> non-routed network. > >>>> > >>>> this could be a fairly simple change to the UDP output module > >>>> (adding a > >>>> couple commands around the sending of a message), but before > >>>> I dove in to > >>>> do that I wanted to see if I had missed this feature anywhere. > >>>> > >>>> David Lang > >>>> _______________________________________________ > >>>> rsyslog mailing list > >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>>> http://www.rsyslog.com > >>>> > >>> _______________________________________________ > >>> rsyslog mailing list > >>> http://lists.adiscon.net/mailman/listinfo/rsyslog > >>> http://www.rsyslog.com > >>> > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > > _______________________________________________ > > rsyslog mailing list > > http://lists.adiscon.net/mailman/listinfo/rsyslog > > http://www.rsyslog.com > > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From rgerhards at hq.adiscon.com Thu Feb 26 14:49:00 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 14:49:00 +0100 Subject: [rsyslog] Matching hostname and facility? References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E8F@GRFEXC.intern.adiscon.com> I have no time to try it out, but I think BSD-style hostblocks should be helpful in this case. Details in doc, something along these lines: !hostname local6.* /path/to/hostname-local6 Hostname is an implicit and condition until the next !hostname is seen. Not sure if in v2 it works with FQDN (don't think so) or just the plain hostname without domain. I think there is also a sample in the wiki or forum. Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of Scott Baker > Sent: Wednesday, February 25, 2009 9:08 PM > To: rsyslog-users > Subject: Re: [rsyslog] Matching hostname and facility? > > On 02/23/2009 02:56 PM, (private) HKS wrote: > > On Mon, Feb 23, 2009 at 1:01 PM, Scott Baker > wrote: > >> I have an rsyslog.conf entry like this to send everything from my > DHCP > >> server to it's own log file on my central rsyslog server. > >> > >> # DHCP logs > >> :FROMHOST, isequal, "dhcp-server.domain.com" -?dhcp > >> > >> Is there a way to specify hostname AND a syslog facility? It'd be > nice if I > >> could match that host, and local6.* or something like that. Is that > possible? > >> > >> - Scott > >> _______________________________________________ > >> rsyslog mailing list > >> http://lists.adiscon.net/mailman/listinfo/rsyslog > >> http://www.rsyslog.com > >> > > > > > > #DHCP logs > > if $fromhost == 'dhcp-server.domain.com' and $syslogfacility-text == > > 'local6' then -?dhcp > > Does this syntax work on rsyslog 2.0.x, that's what my server has on > it. > I've tried this syntax, but it's not logging. > > - Scott > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From aoz.syn at gmail.com Thu Feb 26 16:16:06 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 26 Feb 2009 08:16:06 -0700 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E8F@GRFEXC.intern.adiscon.com> References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> <9B6E2A8877C38245BFB15CC491A11DA71E8F@GRFEXC.intern.adiscon.com> Message-ID: <4255c2570902260716t26815e48wc36cb6be6477b451@mail.gmail.com> On Thu, Feb 26, 2009 at 06:49, Rainer Gerhards wrote: > I have no time to try it out, but I think BSD-style hostblocks should be > helpful in this case. Details in doc, something along these lines: > > !hostname > local6.* /path/to/hostname-local6 FWIW, the hostblock is denoted with '+' and '-', '!' is the program-name prefix. From aoz.syn at gmail.com Thu Feb 26 16:53:34 2009 From: aoz.syn at gmail.com (RB) Date: Thu, 26 Feb 2009 08:53:34 -0700 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> Message-ID: <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> On Tue, Feb 17, 2009 at 13:11, RB wrote: > Regardless, I'll take the flag and see what I can do to get a > readily-accessible reasonably current build available for CentOS-5. Good & bad news - the good news is the Fedora upstream is very responsive, the bad news is I got sidetracked after his response. I have been told that rsyslog cannot be put in EPEL since it is already packaged in RHEL, be that package good or bad. Tomas has offered to help with the SPEC should I have any problems, but it looks like we're on our own for the time being. RPM package distribution can be done to various depths. The simplest is to just provide both the SRPM and unsigned binary RPMs for a few chosen CPU architectures for each packaged release as an HTTP or FTP download. This would allow one-off installations (updates would be manual) and generally get the package 'out there' for use. Further steps would involve signing the binaries and possibly publishing a repo that users could subscribe to (using /etc/yum.* or equivalent) for automated updates. Distributing a binary package in whatever form is going to increase the load (however mildly) on the project - each release will involve compiling and distributing binaries and SRPMs, if not signing them as well. I can work with you [Rainer] to automate that process, but as a random user I should probably not be doing the compilation and signing myself. So, we have 4 basic questions: 1. What versions are desired? 2. Are there any rsyslog components or functionality not packaged in the Fedora distribution users here would like to see included? 3. Do we want to sign the packages? 4. Who will perform the compilation/signing? From rgerhards at hq.adiscon.com Thu Feb 26 17:49:30 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 17:49:30 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com><49993125.2060603@ecker-software.de><4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com><4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Hi RB, thanks for all your hard work. I am absolutely willing to help make succeed in that. Just one question before we do down to details. Are there any other options that we can pursue? I remember, quite some time ago, that someone posted the idea that some well-known (non-RH, not EPEL) repositories exist. Unfortunatley, I do no longer know which these were. So the question is: are there any other such repositories where RHEL users turn to and, if so, can we work with them to achieve our joint goals? Sorry for some backtracking here... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of RB > Sent: Thursday, February 26, 2009 4:54 PM > To: rsyslog-users > Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending > devices? > > On Tue, Feb 17, 2009 at 13:11, RB wrote: > > Regardless, I'll take the flag and see what I can do to get a > > readily-accessible reasonably current build available for CentOS-5. > > Good & bad news - the good news is the Fedora upstream is very > responsive, the bad news is I got sidetracked after his response. > > I have been told that rsyslog cannot be put in EPEL since it is > already packaged in RHEL, be that package good or bad. Tomas has > offered to help with the SPEC should I have any problems, but it looks > like we're on our own for the time being. > > RPM package distribution can be done to various depths. The simplest > is to just provide both the SRPM and unsigned binary RPMs for a few > chosen CPU architectures for each packaged release as an HTTP or FTP > download. This would allow one-off installations (updates would be > manual) and generally get the package 'out there' for use. Further > steps would involve signing the binaries and possibly publishing a > repo that users could subscribe to (using /etc/yum.* or equivalent) > for automated updates. > > Distributing a binary package in whatever form is going to increase > the load (however mildly) on the project - each release will involve > compiling and distributing binaries and SRPMs, if not signing them as > well. I can work with you [Rainer] to automate that process, but as a > random user I should probably not be doing the compilation and signing > myself. > > So, we have 4 basic questions: > 1. What versions are desired? > 2. Are there any rsyslog components or functionality not packaged in > the Fedora distribution users here would like to see included? > 3. Do we want to sign the packages? > 4. Who will perform the compilation/signing? > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From david at lang.hm Thu Feb 26 18:05:17 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 09:05:17 -0800 (PST) Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> References: <577465F99B41C842AAFBE9ED71E70ABA44FB9E@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBAF@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com><49993125.2060603@ecker-software.de><4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com><4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: even where rsyslog is included in a distro it's very handy to have a spec file (or debian equivalent) included with the source to allow a 'make rpm' or 'make deb' to properly make packages. I've been using checkinstall to create debian packages from the compiled source, and I don't know what it's doing wrong, but I've been tripped up a few times by it not replacing all the files that it should if rsyslog is already installed (the packages it creates work just fine if rsyslog isn't installed at all) David Lang On Thu, 26 Feb 2009, Rainer Gerhards wrote: > Hi RB, > > thanks for all your hard work. I am absolutely willing to help make > succeed in that. Just one question before we do down to details. Are > there any other options that we can pursue? I remember, quite some time > ago, that someone posted the idea that some well-known (non-RH, not > EPEL) repositories exist. Unfortunatley, I do no longer know which these > were. > > So the question is: are there any other such repositories where RHEL > users turn to and, if so, can we work with them to achieve our joint > goals? > > Sorry for some backtracking here... > > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of RB >> Sent: Thursday, February 26, 2009 4:54 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] Get rsyslog to always use fqdn of sending >> devices? >> >> On Tue, Feb 17, 2009 at 13:11, RB wrote: >>> Regardless, I'll take the flag and see what I can do to get a >>> readily-accessible reasonably current build available for CentOS-5. >> >> Good & bad news - the good news is the Fedora upstream is very >> responsive, the bad news is I got sidetracked after his response. >> >> I have been told that rsyslog cannot be put in EPEL since it is >> already packaged in RHEL, be that package good or bad. Tomas has >> offered to help with the SPEC should I have any problems, but it looks >> like we're on our own for the time being. >> >> RPM package distribution can be done to various depths. The simplest >> is to just provide both the SRPM and unsigned binary RPMs for a few >> chosen CPU architectures for each packaged release as an HTTP or FTP >> download. This would allow one-off installations (updates would be >> manual) and generally get the package 'out there' for use. Further >> steps would involve signing the binaries and possibly publishing a >> repo that users could subscribe to (using /etc/yum.* or equivalent) >> for automated updates. >> >> Distributing a binary package in whatever form is going to increase >> the load (however mildly) on the project - each release will involve >> compiling and distributing binaries and SRPMs, if not signing them as >> well. I can work with you [Rainer] to automate that process, but as a >> random user I should probably not be doing the compilation and signing >> myself. >> >> So, we have 4 basic questions: >> 1. What versions are desired? >> 2. Are there any rsyslog components or functionality not packaged in >> the Fedora distribution users here would like to see included? >> 3. Do we want to sign the packages? >> 4. Who will perform the compilation/signing? >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From david at lang.hm Thu Feb 26 18:13:57 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 09:13:57 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 26 Feb 2009, Rainer Gerhards wrote: > Hi David, > > I think you got lost in the callbacks. yep, that's what I meant by the 'twisty maze of helper functions' > The multiple send calls are not for multiple actions. This is all for > one action. That code was contributed as part of the IPv6 port. I > verified the implementation with what I could find as references to > sending on IPv6 and think the implementation uses proper procedures for > that environment. > > In essence, on an IPv6-enabled system, you will receive multiple sockets > that you potentially can use to send the message. What the code does is > iterate over these sockets and see which one really works. There is also > an option (not checked but pretty sure) that permits sending to all > receivers. I think that was the other situation you have seen. this I definantly don't understand. I haven't done much coding in this area, and most of what I have done ends up being cut-n-paste out of the 'linux application programming' book examples (which are supposed to work for IPv6 as well as v4) > The listen socket is NOT being reused for sending. when I chased down the callback functions to find what function created the sockets, the only thing that I found was a routine that looked like it was going through the config options to create sockets for all the listening ports. > RFC3164 actually > recommends that port 514 is used as the source port, and we had a > lengthy discussion at the IETF about this recommendation. The bottom > line is that you cannot reuse the receive socket on a highly parallel > syslogd because each thread needs its own (or you have even more sync). > Rsyslog creates a new (set of) send sockets *per action*. if you don't do a bind on the socket you can't specify the source port. if you do bind on the socket and set the source port to 514 aren't you generating a conflict between the multiple send sockets? > I guess part of the confusion stems back from your understanding of > sysklogd code. Sysklogd works totally different here. probably. > I hope this clarifies a bit. I will try to have a look at the code > provided asap and see what I can do. Its unfortunately still very busy, > so I can not commit when I will finally start. thanks. I'll keep poking at this. David Lang > HTH > Rainer > >> -----Original Message----- >> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >> Sent: Wednesday, February 25, 2009 9:47 PM >> To: rsyslog-users >> Subject: Re: [rsyslog] UDP source forging. >> >> figuring out how to do this is navigating a twisty maze of helper >> functions, all different ;-) >> >> there are a few things that look odd here if I am reading the code >> properly. >> >> rsyslog makes one call to the UDPSend routine for all forwarded >> messages, >> this means that they must all send the same format. >> >> the UDPSend routine then walks through all destinations attempting to >> send >> the message to them. and considers the message successfully sent if > any >> of >> them can be sent. I would have expected that it would only be >> considered >> successful if all of them succeded. >> >> UDPSend attempts to use the sockets that were created to listening for >> messages to send it's message out. in a multi-homed machine the local >> IP >> address of those sockets may not be appropriate for the relay. also, >> what >> would happen if a system recieves via TCP and forwards via UDP and so >> doesn't have any UDP listener sockets. >> >> >> so now, my suggestion >> >> On Linux in /etc/sysctl.conf add the line >> >> net.ipv4.ip_nonlocal_bind=1 >> >> this tells the kernel not to fail bind requests to IP addresses that >> don't >> exist on the box >> >> then in omfwd.c >> >> in the routine that calls UDPSend, modify it to pass the source IP >> address >> of the message to UDPSend >> >> create a new filehandle array to use for outbound messages (one >> filehandle >> for each destination since they may end up with different source IPs) >> >> >> in UDPSend >> >> three options. >> >> >> 1. default >> >> use the appropriate filehandle for each destination and send the >> message. this is similar to what currently takes place, but instead of >> walking through each open socket for each destination, there should >> only >> be one sendto per destination. when opening the socket it should not > be >> nessasary to do a bind, just issue the socket call. >> >> if there is anything in the syslog standard specifying the source >> port >> (I don't think there is, although many implementations use port 514 >> becouse they do the same thing that rsyslog is doing and re-use >> listening >> sockets to send messages) >> >> >> 2. randomize source ports to support external load balancers >> >> same as default, except that every X (configurable) messages close >> and >> re-open the sockets. >> >> the reason for this is that each time a message is first sent the > OS >> picks a random source port that will be used for all messages sent >> through >> that socket. by closing the socket once in a while, load balancers > that >> balance based on source IP + source port + destination IP + > destination >> port will be able to function (a similar feature for TCP based >> transports >> would be useful for the same reason) >> >> >> 3. forge the source IP/port >> >> for each message that is sent, open a new socket, then issue a >> 'bind' >> command for that socket (filehandle) that sets the local IP address to >> the >> IP address that the message initially came from, then issue the > sendto, >> then close the filehandle. >> >> there is no need for an array of sockets in this case as the socket >> needs to be re-opened for each message/destination. in theory there is >> a >> possibility of a performance gain by keeping sockets open and re-using >> them, but since each socket is unique to the sender + destination > there >> would be a large number of sockets and a low probability of re-using a >> socket for the next message. >> >> in sysklogd I implemented #2 with the simple code below (once I > created >> a >> different filehandle to use for outbound connections) >> >> this closed and re-opened the socket for each message, doing it every > X >> messages would save on the overhead and be just as good in practice. >> >> the bind command that's commented out is basicly what would be needed >> for >> #3, but with real values for the source.sin_addr.s_addr (and >> source.sin_port if you wanted to forge the port as well, leaving it >> zero >> lets the OS pick a port number) >> >> if (finet >0) { >> /* close and re-open the outbound socket after each message > so >> that the source port is randomized and load balancers can distribute >> the messages */ >> close(finet); >> finet = create_inet_socket(); >> /* if we want to forge the source IP for the outbound > packets, >> this is the place to do it by seeting the IP address to the address we >> received the message from >> struct sockaddr_in source; >> source.sin_addr.s_addr = 0x00000000; >> source.sin_port = 0x0000; >> bind(finet,(struct sockaddr *) >> &source,sizeof(source));*/ >> } >> >> >> the create_inet_socket() routine is: >> >> static int create_inet_socket() >> { >> int fd, on = 1; >> int sockflags; >> >> fd = socket(AF_INET, SOCK_DGRAM, 0); >> if (fd < 0) { >> logerror("syslog: Unknown protocol, suspending inet >> service."); >> return fd; >> } >> >> if (setsockopt(fd, SOL_SOCKET, SO_REUSEADDR, \ >> (char *) &on, sizeof(on)) < 0 ) { >> logerror("setsockopt(REUSEADDR), suspending inet"); >> close(fd); >> return -1; >> } >> /* We must not block on the network socket, in case a packet >> * gets lost between select and recv, otherise the process >> * will stall until the timeout, and other processes trying > to >> * log will also stall. >> */ >> if ((sockflags = fcntl(fd, F_GETFL)) != -1) { >> sockflags |= O_NONBLOCK; >> /* >> * SETFL could fail too, so get it caught by the >> subsequent >> * error check. >> */ >> sockflags = fcntl(fd, F_SETFL, sockflags); >> } >> if (sockflags == -1) { >> logerror("fcntl(O_NONBLOCK), suspending inet"); >> close(fd); >> return -1; >> } >> return fd; >> } >> >> >> this isn't a patch like you asked for and I offered to put togeather, >> but >> is it enough to clearly explain this? if not I can continue to work on >> the >> patch. >> >> David Lang >> >> On Tue, 24 Feb 2009, Rainer Gerhards wrote: >> >>> David, >>> >>> Excellent, please do as you have time. I'll make sure it fits. >>> Thread-safety, btw., is not a big issue at this level as the output >>> modules are guaranteed to be never called by multiple threads >>> concurrently. That was a trade-off to enable other folks to easily >> write >>> them (but I have an option in the back of my head that a module can >> tell >>> the engine it *is* capable to run on multiple threads >> concurrently...). >>> >>> Rainer >>> >>>> -----Original Message----- >>>> From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- >>>> bounces at lists.adiscon.com] On Behalf Of david at lang.hm >>>> Sent: Tuesday, February 24, 2009 9:43 AM >>>> To: rsyslog-users >>>> Subject: Re: [rsyslog] UDP source forging. >>>> >>>> On Tue, 24 Feb 2009, Rainer Gerhards wrote: >>>> >>>>> Hi David et all, >>>>> >>>>> Currently rsyslog does not support this and I have to admit I was >>>> always >>>>> very hesitant to add it (I see potential for misuse). Co- >>>> incidentally, I >>>>> received a similar request and was about to relay it to the > mailing >>>> list >>>>> to gather feedback. As it looks, this no longer is necessary ;) >>>>> >>>>> When I thought about implementation, I originally thought about > raw >>>>> sockets (which indeed require root access), but if there is any >>> other >>>>> way, I would be most interested. If you can provide some code, I >>> will >>>>> happily integrate it. I think an addition to the omfwd module, in >>> udp >>>>> forwarding, together with a new directive > ($SpoofOriginalUDPAddress >>>> or >>>>> so...) would be the right way to go. >>>> >>>> I'll see about hacking in some example code (probably without any >>>> config >>>> option and not thread-safe) and send it to you. >>>> >>>> there's another similar change in the same area that I was looking >> at, >>>> I'll mock it up as well. >>>> >>>> David Lang >>>> >>>>> Rainer >>>>> >>>>>> -----Original Message----- >>>>>> From: rsyslog-bounces at lists.adiscon.com >>>>>> [mailto:rsyslog-bounces at lists.adiscon.com] On Behalf Of >>>> david at lang.hm >>>>>> Sent: Tuesday, February 24, 2009 4:40 AM >>>>>> To: rsyslog-users >>>>>> Subject: Re: [rsyslog] UDP source forging. >>>>>> >>>>>> On Mon, 23 Feb 2009, RB wrote: >>>>>> >>>>>>> On Mon, Feb 23, 2009 at 18:11, wrote: >>>>>>>> I have a need to use some products that are stupid enough >>>>>> to ignore the >>>>>>>> host field in the syslog message and instead base >>>>>> everything on the IP >>>>>>>> address the message originates from. >>>>>>>> >>>>>>>> some other syslog servers can handle this by forging the >>>>>> source of the UDP >>>>>>>> packet, can rsyslog do this? >>>>>>> >>>>>>> So is rsyslog originating the messages, or are you using it to >>>>>>> aggregate them and then feed them on to the other [bad] >>>>>> acceptors? I >>>>>>> am unaware of a way to get rsyslog to forge packets (short >>>>>> of writing >>>>>>> an output module), but unless you must get another syslog >>>>>> daemon into >>>>>>> the mix, you may be better off just feeding your messages >>>>>> directly to >>>>>>> the other collector. >>>>>> >>>>>> rsyslog would be the relay from one non-routed network to another >>>>>> non-routed network. >>>>>> >>>>>> this could be a fairly simple change to the UDP output module >>>>>> (adding a >>>>>> couple commands around the sending of a message), but before >>>>>> I dove in to >>>>>> do that I wanted to see if I had missed this feature anywhere. >>>>>> >>>>>> David Lang >>>>>> _______________________________________________ >>>>>> rsyslog mailing list >>>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>>> http://www.rsyslog.com >>>>>> >>>>> _______________________________________________ >>>>> rsyslog mailing list >>>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>>> http://www.rsyslog.com >>>>> >>>> _______________________________________________ >>>> rsyslog mailing list >>>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>>> http://www.rsyslog.com >>> _______________________________________________ >>> rsyslog mailing list >>> http://lists.adiscon.net/mailman/listinfo/rsyslog >>> http://www.rsyslog.com >>> >> _______________________________________________ >> rsyslog mailing list >> http://lists.adiscon.net/mailman/listinfo/rsyslog >> http://www.rsyslog.com > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com > From rgerhards at hq.adiscon.com Thu Feb 26 18:16:15 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 18:16:15 +0100 Subject: [rsyslog] UDP source forging. References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Just one quick answer (on the leave) > > RFC3164 actually > > recommends that port 514 is used as the source port, and we had a > > lengthy discussion at the IETF about this recommendation. The bottom > > line is that you cannot reuse the receive socket on a highly parallel > > syslogd because each thread needs its own (or you have even more > sync). > > Rsyslog creates a new (set of) send sockets *per action*. > > if you don't do a bind on the socket you can't specify the source port. > if > you do bind on the socket and set the source port to 514 aren't you > generating a conflict between the multiple send sockets? I am ignoring the RFC recommendation. It is also removed from the soon-to-appear RFC5424. I should have mentioned this... Rainer From bakers at web-ster.com Thu Feb 26 19:00:43 2009 From: bakers at web-ster.com (Scott Baker) Date: Thu, 26 Feb 2009 10:00:43 -0800 Subject: [rsyslog] Matching hostname and facility? In-Reply-To: References: <49A2E460.50604@web-ster.com> <49A5A521.8040107@web-ster.com> Message-ID: <49A6D8CB.1010506@web-ster.com> On 02/25/2009 03:38 PM, (private) HKS wrote: >> Does this syntax work on rsyslog 2.0.x, that's what my server has on it. >> I've tried this syntax, but it's not logging. >> >> - Scott > > > No, this will require 3+ - which you really should upgrade to anyway. That's what I figured... this is my CORE syslog server, so I'll need to play a good upgrade proceedure. Is their documentation on configuration file changes going from 2.x to 3.x? - Scott From mbiebl at gmail.com Fri Feb 27 01:55:14 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Fri, 27 Feb 2009 01:55:14 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: 2009/2/26 : > even where rsyslog is included in a distro it's very handy to have a spec > file (or debian equivalent) included with the source to allow a 'make rpm' > or 'make deb' to properly make packages. > > I've been using checkinstall to create debian packages from the compiled > source, and I don't know what it's doing wrong, but I've been tripped up a > few times by it not replacing all the files that it should if rsyslog is > already installed (the packages it creates work just fine if rsyslog isn't > installed at all) FWIW, I as Debian maintainer of rsyslog, explicitly asked Rainer to remove the debian/ directory from the upstream source tree. Reason is simple: Packaging is the task of the downstream distros and the files shipped upstream were always out-of-date anyways. This not only caused more work for me as Debian maintainer but also leads to bad user experience if the rpm/debs created from the upstream spec/debian build files are outdated and potentially create a half-way broken package. If the fedora bits are kept in an entirely separate upstream packaging branch, then I don't really care. But I wouldn't like to see them (or any debian related files) shipped in a release tarball. Cheers, Michael -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From david at lang.hm Fri Feb 27 04:20:37 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 19:20:37 -0800 (PST) Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <577465F99B41C842AAFBE9ED71E70ABA44FBFE@grfint2.intern.adiscon.com> <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: On Fri, 27 Feb 2009, Michael Biebl wrote: > 2009/2/26 : >> even where rsyslog is included in a distro it's very handy to have a spec >> file (or debian equivalent) included with the source to allow a 'make rpm' >> or 'make deb' to properly make packages. >> >> I've been using checkinstall to create debian packages from the compiled >> source, and I don't know what it's doing wrong, but I've been tripped up a >> few times by it not replacing all the files that it should if rsyslog is >> already installed (the packages it creates work just fine if rsyslog isn't >> installed at all) > > > FWIW, I as Debian maintainer of rsyslog, explicitly asked Rainer to > remove the debian/ directory from the upstream source tree. Reason is > simple: Packaging is the task of the downstream distros and the files > shipped upstream were always out-of-date anyways. This not only caused > more work for me as Debian maintainer but also leads to bad user > experience if the rpm/debs created from the upstream spec/debian build > files are outdated and potentially create a half-way broken package. > > If the fedora bits are kept in an entirely separate upstream packaging > branch, then I don't really care. > But I wouldn't like to see them (or any debian related files) shipped > in a release tarball. so how am I (a debian user) supposed to create debian compatible packages for versions that you don't yet deal with? why couldn't you push the debian related files upstream and maintain them there? (submitting patches, or git pull requests for updates) David Lang From david at lang.hm Fri Feb 27 08:40:18 2009 From: david at lang.hm (david at lang.hm) Date: Thu, 26 Feb 2009 23:40:18 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 26 Feb 2009, Rainer Gerhards wrote: > Just one quick answer (on the leave) > >>> RFC3164 actually >>> recommends that port 514 is used as the source port, and we had a >>> lengthy discussion at the IETF about this recommendation. The bottom >>> line is that you cannot reuse the receive socket on a highly > parallel >>> syslogd because each thread needs its own (or you have even more >> sync). >>> Rsyslog creates a new (set of) send sockets *per action*. >> >> if you don't do a bind on the socket you can't specify the source > port. >> if >> you do bind on the socket and set the source port to 514 aren't you >> generating a conflict between the multiple send sockets? > > I am ignoring the RFC recommendation. It is also removed from the > soon-to-appear RFC5424. I should have mentioned this... good, that clarifies things a lot. I think I see a significant simplification here. getaddrinfo can return a bunch of different addrinfo structures, which you walk through and try to send to each one until you find one that works. based on the man page for this I see the following reasons for multiple sockets 1. number of IP stacks (IPv4 vs IPv6 vs both) 2. multiple interfaces (and potentially multiple IPs if hostname resolves to more than one) the number of structures that you get back is #1 * #2. however, I don't think that you need to go through this. since you maintain a instance of omfwd for each action (i.e. destination), you should be able to figure out what will work and not waste any time dealing with the others. when you lookup the destination address to send to, you should be able to find out if it's an IPv4 or an IPv6 address. If you have both pick one to use (arguments can be made as to which is the best to use, pick one to default to and have a config option to override it) If you get multiple addresses, use the first one. at this point you have one socket of the correct type to send to that destination. attempting to send to each one until you get sucess works, and may be more robust, but it's a significant amount of complication and overhead that you shouldn't need to go through. I think the basic changes needed to support forging the address are something like this (whitespace munged by cut-n-paste) diff --git a/tools/omfwd.c b/tools/omfwd.c index 1dd184e..1112db6 100644 --- a/tools/omfwd.c +++ b/tools/omfwd.c @@ -193,6 +193,15 @@ static rsRetVal UDPSend(instanceData *pData, char *msg, size_t len) int bSendSuccess; if(pData->pSockArray != NULL) { + /* close and re-open sockets for two possilbe reasons + * so that the source port is randomized again (to support load balancers + * so that we can bind to them to forge the from address on the packet + * this should be conditional on config options (including how frequently to do this) + * David Lang 2009-02-25 + */ + net.closeUDPListenSockets(pData->pSockArray); + pData->pSockArray = net.create_udp_socket((uchar*)pData->f_hname, NULL, 0); + /* we need to track if we have success sending to the remote * peer. Success is indicated by at least one sendto() call * succeeding. We track this be bSendSuccess. We can not simply @@ -203,6 +212,15 @@ static rsRetVal UDPSend(instanceData *pData, char *msg, size_t len) bSendSuccess = FALSE; for (r = pData->f_addr; r; r = r->ai_next) { for (i = 0; i < *pData->pSockArray; i++) { + /* if we are forging the source IP of the packet, issue the bind to do so + * this should be made conditional on a config option -- David Lang 2009-02-25 + * since I don't know how to get the correct source IP, I'll set it to look + * like it comes from 10.201.1.1 IPv4 + */ + + + struct sockaddr_in source; + memset(&source,0,sizeof(source)); + source.sin_family = AF_INET; + source.sin_addr.s_addr = 0x0101c90a; + source.sin_port = 0x0000; + +/* bind(pData->pSockArray[i+1],(struct sockaddr *) &source,sizeof(source)); +*/ + lsent = sendto(pData->pSockArray[i+1], msg, len, 0, r->ai_addr, r->ai_addrlen); if (lsent == len) { bSendSuccess = TRUE; this works for reopening the socket each time, but if I uncomment the bind the sendto fails (error 22, invalid input) I haven't yet figured out what I'm missing on the bind that's causing this David Lang From patrick.shen at net-m.de Fri Feb 27 07:59:40 2009 From: patrick.shen at net-m.de (Patrick Shen) Date: Fri, 27 Feb 2009 14:59:40 +0800 Subject: [rsyslog] Weird fromhost property value Message-ID: <49A78F5C.3000400@net-m.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi All, I've utilized rsyslog as my company's central logging server for half a year. Today I encounterd a very weird issue about value of fromhost property. We use dynamic templates to store logs from clients. The template is like below: $template d_hosts,"/var/rsyslog/HOSTS/%fromhost%/%$year%/%$month%/%syslogfacility-text%_%fromhost%_%$year%_%$month%_%$day %.log" You can see we group logs by fromhost value. Today, I did 3 times test that a client named (sobek) sent logs to central logging server by UDP, TCP and RELP. The FQDN of client node is "sobek.net-m.internal", short name is "sobek", ip address is "172.21.101.13". After testing, I got when sending via UDP, the fromhost value is short name. And via TCP, the value is FQDN. Via RELP, the value is IP address. So I got a very weird directory organization at "/var/rsyslog/HOSTS". ########################################################################## drwxr-x--- 3 root syslog 80 Feb 27 07:24 172.21.101.13 <- RELP drwxr-x--- 3 root syslog 80 Feb 27 05:58 sobek <- UDP drwxr-x--- 3 root syslog 80 Feb 27 06:03 sobek.net-m.internal <- TCP ########################################################################## We are running rsyslog 3.20.0 both on client and server. So I wanna know if any other has encountered this before? Thanks, Patrick -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFJp49ckHhYtFevC+MRApbbAJ9Dgxtw5mf+ax9D81OZPfh5E9aJPgCdEqF/ FlkFDJpWr4k6pVV4AQiLhRw= =cQzr -----END PGP SIGNATURE----- From david at lang.hm Fri Feb 27 09:03:54 2009 From: david at lang.hm (david at lang.hm) Date: Fri, 27 Feb 2009 00:03:54 -0800 (PST) Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com><577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com><577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com><9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Message-ID: On Thu, 26 Feb 2009, david at lang.hm wrote: > > this works for reopening the socket each time, but if I uncomment the bind > the sendto fails (error 22, invalid input) > > I haven't yet figured out what I'm missing on the bind that's causing this a little more testing and I find that the bind succeeds, but no traffic goes out unless the source IP exists somewhere on the box (it can be bound to lo:0, but it needs to exist) so the non-local-bind approach may not work :-( it's just hit midnight here, so I'm going to call it a night and try again tomorrow. David Lang From nico at altiva.fr Fri Feb 27 18:05:19 2009 From: nico at altiva.fr (NM) Date: Fri, 27 Feb 2009 17:05:19 +0000 (UTC) Subject: [rsyslog] rsyslog and load balancers References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local> <577465F99B41C842AAFBE9ED71E70ABA44FCB6@grfint2.intern.adiscon.com> Message-ID: On Mon, 23 Feb 2009 17:44:58 +0100, Rainer Gerhards wrote: > I couldn't stand this Well unfortunately many companies have this nonsense bullshit added at the server (read: Exchange) level. One company I worked for even added a 10kB gif logo to *every* single outgoing mail, on top of 5kB of (uneforceable, useless) legalese. From rgerhards at hq.adiscon.com Fri Feb 27 18:36:18 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Fri, 27 Feb 2009 18:36:18 +0100 Subject: [rsyslog] rsyslog and load balancers References: <0B1B9163138571439EAF804646F3F6AA06A723BC@GIBSVWIN004X.partygaming.local><577465F99B41C842AAFBE9ED71E70ABA44FCB6@grfint2.intern.adiscon.com> Message-ID: <9B6E2A8877C38245BFB15CC491A11DA71ED7@GRFEXC.intern.adiscon.com> Well... and the funny thing is in Germany is part of this even required by law... Rainer > -----Original Message----- > From: rsyslog-bounces at lists.adiscon.com [mailto:rsyslog- > bounces at lists.adiscon.com] On Behalf Of NM > Sent: Friday, February 27, 2009 6:05 PM > To: rsyslog at lists.adiscon.com > Subject: Re: [rsyslog] rsyslog and load balancers > > On Mon, 23 Feb 2009 17:44:58 +0100, Rainer Gerhards wrote: > > > I couldn't stand this > > Well unfortunately many companies have this nonsense bullshit added at > the server (read: Exchange) level. One company I worked for even added > a > 10kB gif logo to *every* single outgoing mail, on top of 5kB of > (uneforceable, useless) legalese. > > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com From Luis.Fernando.Munoz.Mejias at cern.ch Fri Feb 27 18:48:56 2009 From: Luis.Fernando.Munoz.Mejias at cern.ch (Luis Fernando =?utf-8?q?Mu=C3=B1oz_Mej=C3=ADas?=) Date: Fri, 27 Feb 2009 18:48:56 +0100 Subject: [rsyslog] Documentation on writing rsyslog modules? In-Reply-To: <577465F99B41C842AAFBE9ED71E70ABA44FC08@grfint2.intern.adiscon.com> References: <200902111459.20042.Luis.Fernando.Munoz.Mejias@cern.ch> <200902161141.21380.Luis.Fernando.Munoz.Mejias@cern.ch> <577465F99B41C842AAFBE9ED71E70ABA44FC08@grfint2.intern.adiscon.com> Message-ID: <200902271848.56481.Luis.Fernando.Munoz.Mejias@cern.ch> Rainer, Good and bad news... > > That sounds really great. Before you start coding or preparing > > anything, let me check how well our DBs perform, because it's not > > yet clear if they'll be able to cope with the high insertion rate we > > expect. If we don't go for the Oracle database this work doesn't > > make sense. I bet we'll want the Oracle, anyways. > > Sounds fair. Good news: I did my tests and, for many tasks I need to do, Oracle is our way to go. So, I'm willing to write the module, with your guidance/advise. As I said, I need **excellent** performance. I definitely need batch operations, the ability to prepare the statements given as arguments on the configuration file, and not to commit entries one by one, but after a number of entries are ready or (better) after some not so small time. According to the advise I got from experts around here, I'll have to use Oracle Call Interface for this module, I don't know if there are any licensing issues. It seems I'll have to review how rsyslog's queing modules work... > > For this evaluation, I already have a timestamp formatter that fits > > into Oracle, something that can be used with the property replacer, > > like %timereported:::date-oracle%. > The bad news is that this timestamp formatter works perfectly on interactive sessions (sqlplus) but not on non-interactive ones, f.i, in Python scripts. You need to call Oracle's to_timestamp(string, format), and by bloating your code with this ugly function the rfc-3339 formatter is good enough. So I won't submit this one. Cheers. -- Luis Fernando Mu?oz Mej?as Luis.Fernando.Munoz.Mejias at cern.ch From aoz.syn at gmail.com Fri Feb 27 19:42:49 2009 From: aoz.syn at gmail.com (RB) Date: Fri, 27 Feb 2009 11:42:49 -0700 Subject: [rsyslog] Weird fromhost property value In-Reply-To: <49A78F5C.3000400@net-m.de> References: <49A78F5C.3000400@net-m.de> Message-ID: <4255c2570902271042l44d437c9kaa13ff01c509fcc2@mail.gmail.com> On Thu, Feb 26, 2009 at 23:59, Patrick Shen wrote: > You can see we group logs by fromhost value. > > Today, I did 3 times test that a client named (sobek) sent logs to > central logging server by UDP, TCP and RELP. > > The FQDN of client node is "sobek.net-m.internal", short name is > "sobek", ip address is "172.21.101.13". > > After testing, I got when sending via UDP, the fromhost value is short > name. And via TCP, the value is FQDN. Via RELP, the value is IP address. > > So I got a very weird directory organization at "/var/rsyslog/HOSTS". > > ########################################################################## > drwxr-x--- 3 root syslog 80 Feb 27 07:24 172.21.101.13 ? ? ? ? <- RELP > drwxr-x--- 3 root syslog 80 Feb 27 05:58 sobek ? ? ? ? ? ? ? ? <- UDP > drwxr-x--- 3 root syslog 80 Feb 27 06:03 sobek.net-m.internal ?<- TCP > ########################################################################## I've tried something similar and eventually gave up and started using the 'fromhost-ip' property to create per-sender templates. Of course, fromhost* falls down once you have relays in the mix, but that's another problem to solve. From mbiebl at gmail.com Sat Feb 28 02:58:34 2009 From: mbiebl at gmail.com (Michael Biebl) Date: Sat, 28 Feb 2009 02:58:34 +0100 Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: 2009/2/27 : > On Fri, 27 Feb 2009, Michael Biebl wrote: > >> 2009/2/26 ?: >>> even where rsyslog is included in a distro it's very handy to have a spec >>> file (or debian equivalent) included with the source to allow a 'make rpm' >>> or 'make deb' to properly make packages. >>> >>> I've been using checkinstall to create debian packages from the compiled >>> source, and I don't know what it's doing wrong, but I've been tripped up a >>> few times by it not replacing all the files that it should if rsyslog is >>> already installed (the packages it creates work just fine if rsyslog isn't >>> installed at all) >> >> >> FWIW, I as Debian maintainer of rsyslog, explicitly asked Rainer to >> remove the debian/ directory from the upstream source tree. Reason is >> simple: Packaging is the task of the downstream distros and the files >> shipped upstream were always out-of-date anyways. This not only caused >> more work for me as Debian maintainer but also leads to bad user >> experience if the rpm/debs created from the upstream spec/debian build >> files are outdated and potentially create a half-way broken package. >> >> If the fedora bits are kept in an entirely separate upstream packaging >> branch, then I don't really care. >> But I wouldn't like to see them (or any debian related files) shipped >> in a release tarball. > > so how am I (a debian user) supposed to create debian compatible packages > for versions that you don't yet deal with? > > why couldn't you push the debian related files upstream and maintain them > there? (submitting patches, or git pull requests for updates) Pretty simple: It's less work for me and Rainer and more flexible. Say I (for Debian) start adding the files upstream, so does Fedora, BSD, etc... Now when Rainer wants to make a new release to not have any stale packaging files, he would have to ping all package maintainer first to update the build files and push those changes. That simply doesn't scale. Packaging and upstream software releases should be decoupled. If you are really interested in the Debian Packaging, you can grab the git repository from [1] and either work from there or at it as a "remote" to the rsyslog git repo and merge the debian specific bits. Cheers, Michael [1] http://git.debian.org/?p=collab-maint/rsyslog.git;a=summary -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? From david at lang.hm Sat Feb 28 03:16:15 2009 From: david at lang.hm (david at lang.hm) Date: Fri, 27 Feb 2009 18:16:15 -0800 (PST) Subject: [rsyslog] Get rsyslog to always use fqdn of sending devices? In-Reply-To: References: <49993125.2060603@ecker-software.de> <4255c2570902161448i731aa22as2b43e34feb049b55@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FC12@grfint2.intern.adiscon.com> <4255c2570902171211u26bc267brd13cdfb01728df70@mail.gmail.com> <4255c2570902260753u53ab4c46le86afe27437d2ed9@mail.gmail.com> <9B6E2A8877C38245BFB15CC491A11DA71E99@GRFEXC.intern.adiscon.com> Message-ID: On Sat, 28 Feb 2009, Michael Biebl wrote: >>> >>> If the fedora bits are kept in an entirely separate upstream packaging >>> branch, then I don't really care. >>> But I wouldn't like to see them (or any debian related files) shipped >>> in a release tarball. >> >> so how am I (a debian user) supposed to create debian compatible packages >> for versions that you don't yet deal with? >> >> why couldn't you push the debian related files upstream and maintain them >> there? (submitting patches, or git pull requests for updates) > > Pretty simple: It's less work for me and Rainer and more flexible. > Say I (for Debian) start adding the files upstream, so does Fedora, BSD, etc... > Now when Rainer wants to make a new release to not have any stale > packaging files, he would have to ping all package maintainer first to > update the build files and push those changes. That simply doesn't > scale. > Packaging and upstream software releases should be decoupled. > > If you are really interested in the Debian Packaging, you can grab the > git repository from [1] and either work from there or at it as a > "remote" to the rsyslog git repo and merge the debian specific bits. it's not that I'm interested in debian packaging, it's that I need to install the stuff that you haven't decided to ship in debian yet on my debian system in such a way that I keep the package manager happy (and don't have it overwriting what I've compiled with an update of an obsolete version) it's not that the upstream version of the files need to be perfect, but they should be good enough to avoid the need for users to have to fight the packaging system and duplicate your efforts. I hate to have to pull in some stuff from your tree and combine it with stuff from the upstream tree because I don't know enough to be sure that I'm both pulling everything I need and not pulling something that will cause grief. you've made your decision, count this as one voice disagreeing with that decision. David Lang From rgerhards at hq.adiscon.com Thu Feb 26 18:46:27 2009 From: rgerhards at hq.adiscon.com (Rainer Gerhards) Date: Thu, 26 Feb 2009 18:46:27 +0100 Subject: [rsyslog] UDP source forging. In-Reply-To: References: <4255c2570902231929sebf2f0cqf9f840389e6d6a0b@mail.gmail.com> <577465F99B41C842AAFBE9ED71E70ABA44FCBE@grfint2.intern.adiscon.com> <577465F99B41C842AAFBE9ED71E70ABA44FCC2@grfint2.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E8E@GRFEXC.intern.adiscon.com> <9B6E2A8877C38245BFB15CC491A11DA71E9A@GRFEXC.intern.adiscon.com> Message-ID: <1235670387.28865.2.camel@rf10up.intern.adiscon.com> On Sun, 2009-03-01 at 23:56 -0800, david at lang.hm wrote: > On Fri, 27 Feb 2009, david at lang.hm wrote: > > > On Thu, 26 Feb 2009, david at lang.hm wrote: > > > >> > >> this works for reopening the socket each time, but if I uncomment the bind > >> the sendto fails (error 22, invalid input) > >> > >> I haven't yet figured out what I'm missing on the bind that's causing this > > > > a little more testing and I find that the bind succeeds, but no traffic goes > > out unless the source IP exists somewhere on the box (it can be bound to > > lo:0, but it needs to exist) > > > > so the non-local-bind approach may not work :-( > > > > it's just hit midnight here, so I'm going to call it a night and try again > > tomorrow. > > I abandoned this approach and spent the weekend learning how to do raw > sockets. I found a library that makes it not that bad to do (at least for > the IPv4 that I've done so far, IPv6 adds some wrinkles) > > the one thing thats not clear to me at this point is how to find the > original source IP of the message. Is that available in a variable inside > UDPSend, or is it something that I will have to get earlier in the process > and then pass explicitly to UDPSend? Actually, output modules do not receive access to the full message object. This was originally done for security reasons (do not pass more than needed). All they can receive is the strings that are passed to them. So the module would need to be modified so that a second string (like ommail) is passed and that string needs to be defined as the to-be-spoofed IP (what also enables to rewrite the source IP). >From all the discussion, it may make sense to start with a different output plugin that may later be merged back into the original one... Rainer > > David Lang > _______________________________________________ > rsyslog mailing list > http://lists.adiscon.net/mailman/listinfo/rsyslog > http://www.rsyslog.com