February 2020 - syslog-ng - lists.balabit.hu

syslog driver: IP instead of hostname
by Alexandre Santos 27 Feb '20

27 Feb '20

Hello, I have the following a syslog-ng server and a syslog-ng client, which configurations I am sending in attachment. I am using the syslog driver in order to have full compatibility with RFC5424. I want to use the IP address and not the hostname, but I keep seeing the hostname in tcpdump: [root@tests tests]# tcpdump -A -i virbr0 port 60514 or 514 tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on virbr0, link-type EN10MB (Ethernet), capture size 262144 bytes 18:30:09.810757 IP 192.168.122.11.34512 > tests.syslog: SYSLOG local0.info, length: 100 E.....@.@..K..z...z......l..<134>1 2020-02-26T18:30:09+00:00 localhost root 9519 - - This is a local0 info buffer filler string and in logfile: <134>1 2020-02-26T18:30:09+00:00 localhost root 9519 - - This is a local0 info buffer filler string Can you help me? Thanks in advance, Alex

2 2

system() vs systemd-journal()
by Alexandre Santos 27 Feb '20

27 Feb '20

Hi. I am using syslog-ng 3.19 in a Linux system. My sources configuration is: source s_src { system(); internal(); }; I would like to stack traces to end up in another facility than local0, which is what is happening with the configuration above. This happens because local0 is default facility when SYSLOG_FACILITY entry of journald is not defined. So I changed my sources configuration to: source s_src { internal(); systemd-journal(default-facility(local1)); }; And now the stacktraces are going to local1 facility. *Is there any difference between system() and systemd-journal() when using Linux? I am going to lose any logs?* Thanks in advance, Alex *BTW:* *source s_src { system(default-facility(local1)); internal();};* *Does not gives any error, but it does not have the desired effect.*

3 2

Re: [syslog-ng] network logging
by SZIGETVÁRI János 25 Feb '20

25 Feb '20

Hi Anatoly, I appreciate the trust you bestowed to me by sending me the bundle. >From syslog-ng perspective your setup looks all sane, and I couldn't spot any problems. Upon checking the debug logs, I saw, that syslog-ng did not report either of the incoming UDP packages as "Incoming messages" even though they were recorded in the pcap file. Given that SELinux is disabled, I and your firewall rules are all ALLOW, there are very few things that could prevent the reception of the messages. That led me to suspect a networking problem: a routing issue. You seem to have two interfaces active: A and B. A has a single IP configured, and B has two. Only two locally connected networks are present in the routing table, and a default route, that points to a host located in the subnet that interface A is connected to. The problem is that the packets arrive to interface B, and the IP address they arrive from should be in the direction of interface A, at least from routing perspective. Due to this the kernel will silently discard these packets. In order to fix this I would recommend you to review your routing table, or reconfigure your setup so that these packets arrive to interface A's configured IP address. If you want to verify this theory of mine, I can point you to the following article on how to make the kernel log these unroutable packets: https://www.cyberciti.biz/faq/linux-log-suspicious-martian-packets-un-routa… Best Regards, János -- Janos SZIGETVARI RHCE, License no. 150-053-692 <https://www.redhat.com/rhtapps/verify/?certId=150-053-692> LinkedIn: linkedin.com/in/janosszigetvari __@__˚V˚ Make the switch to open (source) applications, protocols, formats now: - windows -> Linux, iexplore -> Firefox, msoffice -> LibreOffice - msn -> jabber protocol (Pidgin, Google Talk) - mp3 -> ogg, wmv -> ogg, jpg -> png, doc/xls/ppt -> odt/ods/odp Anatoly Pugachev <matorola(a)gmail.com> ezt írta (időpont: 2020. febr. 25., K, 10:58): > On Wed, Feb 19, 2020 at 6:46 PM SZIGETVÁRI János <jszigetvari(a)gmail.com> > wrote: > > > > Hi Anatoly, > > > > Thank you for the debug log! > > It clearly shows that syslog-ng does not get the remote log at all. > > Could you please run the syslog-ng-debun script with the following > parameters, and send me the resulting tgz file? > > > > # syslog-ng-debun -r -P "port 3514" -D "-Fedv" -t 90 > > > > This will run syslog-ng in debug mode for 90 seconds, and will also > create a network traffic dump of the syslog traffic. Please try sending the > test logs from the other VM while it is running. > > > Janos, > > sorry for the delay, please see attached files. > > Thanks. > > tcpdump command was: > > localhost# tcpdump -n -w udp-3514.pcap -i ens224 udp and port 3514 > > this captured 2 packets coming from 2 different machines, which was run : > > vm1# logger -d -i -n 172.16.3.50 -P 3514 "test from vm1" > vm2# logger -d -i -n 172.16.3.50 -P 3514 "test from vm2" >

1 0

Re: [syslog-ng] Warnings and error while loading default.xml in syslog-ng-3.25.1
by Nitish Saboo 21 Feb '20

21 Feb '20

+Syslog-ng users' and developers' mailing list <syslog-ng(a)lists.balabit.hu> On Mon, Feb 17, 2020 at 2:37 PM Nitish Saboo <nitish.saboo55(a)gmail.com> wrote: > Hi Attila, > > 1,2) The issue is that you used "proxysg" in two different rulesets. I > believe syslog-ng could handle this, but we do not handle it right now. > >> But the same default.xml file is working fine in version > syslog-ng-3,6,2 and syslog-ng-3.7.1 where we have same program in different > rulesets.The behavior in version syslog-ng-3,6,2 and syslog-ng-3.7.1 is the > expected behavior or is the current behavior in syslog-ng-3.25.1 version is > having a Bug ? > > 3/4) You can merge the two rulesets, if it is okay for you: > >>Merging the rulesets is not possible at this moment. > Do we have any workaround for this scenario other than merging the > rulesets? > When can we expect a fix for this in near future ? > > Thanks, > Nitish > > On Mon, Feb 17, 2020 at 2:23 PM Attila Szakacs (aszakacs) < > Attila.Szakacs(a)oneidentity.com> wrote: > >> Hi! >> >> 1,2) The issue is that you used "proxysg" in two different rulesets. I >> believe syslog-ng could handle this, but we do not handle it right now. >> 3/4) You can merge the two rulesets, if it is okay for you: >> >> <?xml version='1.0' encoding='UTF-8'?> >> <patterndb version="4"> >> <ruleset id="f582419b3baa42d4a57e42b89704e38c" description=""> >> <pattern>proxysg</pattern> >> <pattern>ProxySG</pattern> >> <rules> >> <rule id="f1e2bfd7bb85402a88d0b732821a0f94"> >> <patterns> >> <pattern>foo</pattern> >> </patterns> >> </rule> >> <rule id="a681963842014480a83a2a2e38875439"> >> <patterns> >> <pattern>anything</pattern> >> </patterns> >> </rule> >> <rule id="bb169f917216467985cc16e28015f5fa"> >> <patterns> >> <pattern>bar</pattern> >> </patterns> >> </rule> >> <rule id="94d4a0c324c8-44a88cf3d4640477d35e"> >> <patterns> >> <pattern>something</pattern> >> </patterns> >> </rule> >> </rules> >> </ruleset> >> </patterndb> >> >> Regards, >> Attila >> >> ------------------------------ >> *From:* syslog-ng <syslog-ng-bounces(a)lists.balabit.hu> on behalf of >> Nitish Saboo <nitish.saboo55(a)gmail.com> >> *Sent:* Monday, February 17, 2020 6:30 AM >> *To:* Syslog-ng users' and developers' mailing list < >> syslog-ng(a)lists.balabit.hu> >> *Subject:* Re: [syslog-ng] Warnings and error while loading default.xml >> in syslog-ng-3.25.1 >> >> CAUTION: This email originated from outside of the organization. Do not >> follow guidance, click links, or open attachments unless you recognize the >> sender and know the content is safe. >> >> Hi Evan, >> >> Apologies for the confusion but I did close the rule tag in my >> default.xml , missed adding it here. >> The error does not seem to be related to improper closing of tags. >> >> This is how it looks : >> >> <ruleset id="f582419b3baa42d4a57e42b89704e38c" description=""> >> <pattern>proxysg</pattern> >> <rules> >> <rule id="f1e2bfd7bb85402a88d0b732821a0f94"> >> <patterns> >> <pattern>foo</pattern> >> </patterns> >> </rule> >> <rule id="a681963842014480a83a2a2e38875439"> >> <patterns> >> <pattern>anything</pattern> >> </patterns> >> </rule> >> </rules> >> </ruleset> >> <ruleset id="17fae6edff32a53f9f294ab21240fc2641e7a4db" description=""> >> <pattern>ProxySG</pattern> >> <pattern>proxysg</pattern> >> <rules> >> <rule id="bb169f917216467985cc16e28015f5fa"> >> <patterns> >> <pattern>bar</pattern> >> </patterns> >> </rule> >> <rule id="94d4a0c324c8-44a88cf3d4640477d35e"> >> <patterns> >> <pattern>something</pattern> >> </patterns> >> </rule> >> </rules> >> </ruleset> >> >> >> I am getting the following error message: >> >> 2020-02-13T10:47:29.631090] Error parsing pattern database file; >> filename='/home/nsaboo/abc/default.xml', >> error='/home/nsaboo/abc/default.xml:17274:22: Joining rulesets with >> mismatching program name sets, program=proxysg'. >> >> My hunch is the issue is related to merging of two rulesets but I am not >> able to understand why is there mismatching of program names. >> >> 1) Can someone please help me understand the issue here ? >> >> 2) Is the issue seen because a ruleset has multiple programs in it or is >> it because the same program 'proxysg' is being used in different rulesets ? >> >> 3) From the above snippet of default.xml, what changes can I make into >> default.xml to avoid the error ? >> >> 4) Is there a workaround for this issue ? >> >> Thanks, >> Nitish >> >> >> On Sun, Feb 16, 2020 at 12:40 AM Evan Rempel <erempel(a)uvic.ca> wrote: >> >> I'm not exactly sure what is or is not permitted in the pattern database >> but I two comments. >> >> 1. you need end your rule tag and your rules tag before you start a new >> ruleset tag. >> >> 2. What I do in my pattern database is of the form. >> >> <ruleset id="f582419b3baa42d4a57e42b89704e38c" description=""> >> <pattern>proxysg</pattern> >> <rules> >> <rule id="f582419b3baa42d4a57e42b89704e38c"> >> <patterns> >> <pattern>foo</pattern> >> </patterns> >> </rule> >> <rule id="bb169f917216467985cc16e28015f5fa"> >> <patterns> >> <pattern>bar</pattern> >> </patterns> >> </rules> >> </ruleset> >> >> >> Note: >> 1. the closing tag of </rule> before a new starting tag of <rule> >> 2. Multiple "rule" entries inside the the "rules" entry. >> 3. the closing tag of </rule> before the closing tag of </rules> >> 4. the closing tag of </rules> before the closing tag of </ruleset> >> >> I hope that helps. >> >> Evan. >> >> On 2/15/20 12:43 AM, Nitish Saboo wrote: >> >> Hi, >> >> After debugging further into the issue looks like there was a fix for >> patterndb rule clash in syslog-ng-3.8 and this is the commit-id >> '12cd960c8f47260b0b0d4154b096994d66fe345' >> for the fix. And for this reason I am getting the following error for >> same default.xml in syslog-ng-3.25.1 version and not in syslog-ng3.6.2 and >> syslog-ng3.7.1. >> >> 2020-02-13T10:47:29.631090] Error parsing pattern database file; >> filename='/home/nsaboo/abc/default.xml', >> error='/home/nsaboo/abc/default.xml:17274:22: Joining rulesets with >> mismatching program name sets, program=proxysg'. >> >> Snippet from default.xml >> ========================== >> >> <ruleset id="f582419b3baa42d4a57e42b89704e38c" description=""> >> <pattern>proxysg</pattern> >> <rules> >> <rule id="f582419b3baa42d4a57e42b89704e38c"> >> <patterns> >> <pattern>foo</pattern> >> </patterns> >> >> <ruleset id="8d633c824e844a559088d803464e507a" description=""> >> <pattern>ProxySG</pattern> >> <pattern>proxysg</pattern> >> <rules> >> <rule id="bb169f917216467985cc16e28015f5fa"> >> <patterns> >> <pattern>bar</pattern> >> </patterns> >> >> I am not able to understand the error message clearly. >> >> 1) Can someone please help me understand the issue here ? >> >> 2) Is the issue seen because a ruleset has multiple programs in it or is >> it because the same program 'proxysg' is being used in different rulesets ? >> >> 3) From the above snippet of default.xml, what changes can I make into >> default.xml to avoid the error ? >> >> 4) Is there a workaround for this issue ? >> >> Thanks, >> Nitish >> >> On Fri, Feb 14, 2020 at 2:40 PM Nitish Saboo <nitish.saboo55(a)gmail.com> >> wrote: >> >> Hi Attila, >> >> Thanks for your response. >> >> And what about the following error: >> >> 2020-02-13T10:47:29.631090] Error parsing pattern database file; >> filename='/home/nsaboo/abc/default.xml', >> error='/home/nsaboo/abc/default.xml:17274:22: Joining rulesets with >> mismatching program name sets, program=proxysg'. >> >> The same default.xml file was getting loaded correctly in syslog-ng-3.6.2 >> and syslog-ng-3.7.1 but getting following error while loading same >> default.xml in syslog-ng3.25.1 >> >> I came across a similar issue on githib ' >> https://github.com/syslog-ng/syslog-ng/issues/2763 >> <https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.co…>' >> .I see the issue is still in open state.Is there a workaround for >> this issue? >> >> Thanks, >> Nitish >> >> On Fri, Feb 14, 2020 at 1:12 PM Attila Szakacs (aszakacs) < >> Attila.Szakacs(a)oneidentity.com> wrote: >> >> Hi! >> >> WARNING: due to a bug in versions before syslog-ng 3.8numeric comparison >> operators like '!=' in filter expressions were evaluated as string >> operators. This is fixed in syslog-ng 3.8. As we are operating in >> compatibility mode, syslog-ng will exhibit the buggy behaviour as previous >> versions until you bump the @version value in your configuration file; >> >> ^^^ This refers to the syslog-ng.conf file version. >> >> The correct way to resolve it, and fix the buggy behavior of != and ==, >> should be to change the != operators between strings to neq in your filters. >> >> Regards, >> Attila >> ------------------------------ >> *From:* syslog-ng <syslog-ng-bounces(a)lists.balabit.hu> on behalf of >> Nitish Saboo <nitish.saboo55(a)gmail.com> >> *Sent:* Thursday, February 13, 2020 12:17 PM >> *To:* Syslog-ng users' and developers' mailing list < >> syslog-ng(a)lists.balabit.hu> >> *Subject:* [syslog-ng] Warnings and error while loading default.xml in >> syslog-ng-3.25.1 >> >> Hi, >> >> I am using syslog-ng version 3.25.1.Getting following Warnings and error >> while initialising syslog-ng engine: >> >> [2020-02-13T10:47:29.627899] WARNING: due to a bug in versions before >> syslog-ng 3.8numeric comparison operators like '!=' in filter expressions >> were evaluated as string operators. This is fixed in syslog-ng 3.8. As we >> are operating in compatibility mode, syslog-ng will exhibit the buggy >> behaviour as previous versions until you bump the @version value in your >> configuration file; >> [2020-02-13T10:47:29.627968] WARNING: due to a bug in versions before >> syslog-ng 3.8numeric comparison operators like '!=' in filter expressions >> were evaluated as string operators. This is fixed in syslog-ng 3.8. As we >> are operating in compatibility mode, syslog-ng will exhibit the buggy >> behaviour as previous versions until you bump the @version value in your >> configuration file; >> [2020-02-13T10:47:29.628059] WARNING: due to a bug in versions before >> syslog-ng 3.8numeric comparison operators like '!=' in filter expressions >> were evaluated as string operators. This is fixed in syslog-ng 3.8. As we >> are operating in compatibility mode, syslog-ng will exhibit the buggy >> behaviour as previous versions until you bump the @version value in your >> configuration file; >> [2020-02-13T10:47:29.631090] Error parsing pattern database file; >> filename='/opt/tap-parsing/patterns/default.xml', >> error='/opt/tap-parsing/patterns/default.xml:17274:22: Joining rulesets >> with mismatching program name sets, program=proxysg' >> >> >> 1)For the following warnings, to which version I have to bump up the >> configuration file ? >> >> 2020-02-13T10:47:29.627899] WARNING: due to a bug in versions before >> syslog-ng 3.8numeric comparison operators like '!=' in filter expressions >> were evaluated as string operators. This is fixed in syslog-ng 3.8. As we >> are operating in compatibility mode, syslog-ng will exhibit the buggy >> behaviour as previous versions until you bump the @version value in your >> configuration file; >> [2020-02-13T10:47:29.627968] WARNING: due to a bug in versions before >> syslog-ng 3.8numeric comparison operators like '!=' in filter expressions >> were evaluated as string operators. This is fixed in syslog-ng 3.8. As we >> are operating in compatibility mode, syslog-ng will exhibit the buggy >> behaviour as previous versions until you bump the @version value in your >> configuration file; >> [2020-02-13T10:47:29.628059] WARNING: due to a bug in versions before >> syslog-ng 3.8numeric comparison operators like '!=' in filter expressions >> were evaluated as string operators. This is fixed in syslog-ng 3.8. As we >> are operating in compatibility mode, syslog-ng will exhibit the buggy >> behaviour as previous versions until you bump the @version value in your >> configuration file; >> >> Currrently the configuration version is the following: >> >> configuration = cfg_new(0x0302) >> >> Do I have to change it to '0x0319' as defined in 'lib/versioning.h' ? >> >> 2)The same default.xml file was getting loaded correctly in >> syslog-ng-3.6.2 and syslog-ng-3.7.1 but getting following error while >> loading same default.xml in syslog-ng3.25.1 >> >> >> 2020-02-13T10:47:29.631090] Error parsing pattern database file; >> filename='/home/nsaboo/abc/default.xml', >> error='/home/nsaboo/abc/default.xml:17274:22: Joining rulesets with >> mismatching program name sets, program=proxysg'. >> >> What can be the reason for this error ? >> >> >> Thanks, >> Nitish >> >> >> >> ______________________________________________________________________________ >> Member info: https://lists.balabit.hu/mailman/listinfo/syslog-ng >> <https://nam05.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.bal…> >> Documentation: >> http://www.balabit.com/support/documentation/?product=syslog-ng >> <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.balabi…> >> FAQ: http://www.balabit.com/wiki/syslog-ng-faq >> <https://nam05.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.balabi…> >> >>

4 7

Java Destination Method Documentation
by Jamal Habash 20 Feb '20

20 Feb '20

Hey All, I am interested in developing a Java destination for syslog-ng. I have read the documentation which states "To interface with syslog-ng, you will need to extend the TextLogDestination or StructuredLogDestination". There is no documentation or code comments for either of these classes. 1) What is the intended use-case for TextLogDestination? 2) What is the intended use-case for StructuredLogDestination? Additionally, as there are no comments in the code, it is unclear what the abstract methods in these classes are meant to do. For example, each class has the same abstract methods called open(), close(), isOpened(), getNameUniqOptions(). 3) What is the purpose of these methods? 4) When will they be invoked by syslog-ng? It is difficult to write a valid implementation without knowing the purpose of each method. Is there any documentation for this? Thanks in advance! J

2 2

network logging
by Anatoly Pugachev 19 Feb '20

19 Feb '20

Hello! Can someone help me with network logging with syslog-ng : # rpm -q syslog-ng syslog-ng-3.25.1.239.g0535e8a-1.el7.x86_64 # rpm -qf /etc/os-release centos-release-7-7.1908.0.el7.centos.x86_64 server is centos 7 x86_64 vm /etc/syslog-ng/syslog-ng.conf is in the default configuration (no changes made from rpm package installed), have additional configuration in : # cat conf.d/mtcaptive.conf source s_mtcaptive { network( ip("0.0.0.0") port(3514) transport("udp")); }; destination d_mtcaptive { file("/var/log/mt-captive-remote"); }; log { source(s_mtcaptive); destination(d_mtcaptive); }; If i try to log a test message with logger on a localhost (where syslog-ng runs): [root@localhost syslog-ng]# logger -d -i -n 172.16.3.50 -P 3514 "test from localhost" it does work and appears in /var/log/mt-captive-remote : $ tail -1 /var/log/mt-captive-remote Feb 19 06:15:01 172.16.3.50 root[11326]: test from localhost But if i try the same command on a nearby host (vm2, same L2 network, but different IP network), it does not logged, but udp packet with test messages is received by host: [root@vm2 ~]# logger -d -i -n 172.16.3.50 -P 3514 "test from vm2" back to syslog-ng host: # ngrep -d ens224 -n 10 "test from" "udp and port 3514" interface: ens224 (172.16.3.0/255.255.255.0) filter: ( udp and port 3514 ) and ((ip || ip6) || (vlan && (ip || ip6))) match: test from ########################################################################################################################################################################################################################## U 100.64.128.5:24046 -> 172.16.3.50:3514 #218 <5>Feb 19 06:20:27 root[31663]: test from vm2. #####################################################################################################^Cexit 319 received, 1 matched looking at socket status on syslog-ng host: # ss -unlp | grep 3514 UNCONN 0 0 *:3514 *:* users:(("syslog-ng",pid=11198,fd=23)) no firewall or iptables rules (default all ACCEPT). Can someone suggest why syslog-ng does not log remote messages to my destination file? Thanks.

2 3

fedora/rhel & logrotate
by Peter Czanik (pczanik) 18 Feb '20

18 Feb '20

Hi, Recently I received a bug report about logrotate and RHEL 8: https://bugzilla.redhat.com/show_bug.cgi?id=1802165 In RHEL 8 /etc/logroate.d/syslog is now rsyslog specific and thus conflicts with the same file coming from syslog-ng. I changed my test repo https://copr.fedorainfracloud.org/coprs/czanik/syslog-ng-githead/ in a way that RHEL 7 keeps using /etc/logroate/syslog, but all the Fedora and RHEL 8 packages change the logroate file name to /etc/logroate/syslog-ng. Of course this means, that there is no conflict with rsyslog and there are two logrotate scripts for the same set of logs. I am trying to test it on my own as well on RHEL 8, but any additional testing and feedback are very welcome! Thanks, Peter Czanik (CzP) <peter.czanik(a)oneidentity.com> Balabit (a OneIdentity company) / syslog-ng upstream https://syslog-ng.com/community/ https://twitter.com/PCzanik

1 1

syslog-ng doesn't log if system date is older (in the past) than date on last shutdown
by Abhi Arora 18 Feb '20

18 Feb '20

Hi, I have one embedded device running Linux which doesn't have RTC. So it loses date and time after every halt. *uname -a:* *Linux f1 4.9.175+g0746276 #1 SMP PREEMPT Tue Jan 14 03:09:19 UTC 2020 armv7l armv7l armv7l GNU/Linux* I have observed after every reboot, my board starts with some older time and my application running in user-space corrects the system time from a timestamp saved on a file (which is updated every hour). Application also connects with some server to get latest time. I have noticed that if system date and time is less than date and time which it had at last shutdown, then syslog doesn't get any logs from my applications till it has a time atleast greater than date and time which it had at last shutdown. My source was "systemd_journal()" and I changed it to "unix-dgram("/dev/log");". However, after changing it to unix-dgram, I don't see any logs even if my system date and time are correct. *"ls -l /dev/log":> lrwxrwxrwx 1 root root 28 Sep 30 13:28 /dev/log -> /run/systemd/journal/dev-log * *This is my old /etc/syslog-ng/scl.conf* : *@include 'scl/*/*.conf'@define java-module-dir "`module-install-dir`/java-modules"* ******************** This by* *cat /etc/syslog-ng/syslog-ng.conf* *@version: 3.15## Syslog-ng configuration file, compatible with default Debian syslogd# installation. Originally written by anonymous (I can't find his name)# Revised, and rewrited by me (SZALAY Attila <sasa(a)debian.org <sasa(a)debian.org>>)# First, set some global options.options { chain_hostnames(off); flush_lines(0); use_dns(no); use_fqdn(no); owner("root"); group("adm"); perm(0640); stats_freq(0); bad_hostname("^gconfd$"); keep_hostname(yes); keep_timestamp(yes);};######################### Sources######################### This is the default behavior of sysklogd package# Logs may come from unix stream, but not from another machine.#source s_src { systemd_journal(); internal(); file("/proc/kmsg" program_override("kernel"));};# If you wish to get logs from remote machine you should uncomment# this and comment the above source line.##source s_net { tcp(ip(127.0.0.1) port(1000) authentication(required) encrypt(allow)); };######################### Destinations######################### First some standard logfile#destination d_auth { file("/var/log/auth.log"); };destination d_cron { file("/var/log/cron.log"); };destination d_daemon { file("/var/log/daemon.log"); };destination d_kern { file("/var/log/kern.log"); };destination d_lpr { file("/var/log/lpr.log"); };destination d_mail { file("/var/log/mail.log"); };destination d_syslog { file("/var/log/syslog"); };destination d_user { file("/var/log/user.log"); };destination d_uucp { file("/var/log/uucp.log"); };# This files are the log come from the mail subsystem.#destination d_mailinfo { file("/var/log/mail/mail.info <http://mail.info/>"); };destination d_mailwarn { file("/var/log/mail/mail.warn"); };destination d_mailerr { file("/var/log/mail/mail.err"); };# Logging for INN news system#destination d_newscrit { file("/var/log/news/news.crit"); };destination d_newserr { file("/var/log/news/news.err"); };destination d_newsnotice { file("/var/log/news/news.notice"); };# Some 'catch-all' logfiles.#destination d_debug { file("/var/log/debug"); };destination d_error { file("/var/log/error"); };destination d_messages { file("/var/log/messages"); };# The root's console.#destination d_console { usertty("root"); };# Virtual console.#destination d_console_all { file("/dev/tty10"); };# The named pipe /dev/xconsole is for the nsole' utility. To use it,# you must invoke nsole' with the -file' option:## $ xconsole -file /dev/xconsole [...]#destination d_xconsole { pipe("/dev/xconsole"); };# Send the messages to an other host##destination d_net { tcp("127.0.0.1" port(1000) authentication(on) encrypt(on) log_fifo_size(1000)); };# Debian onlydestination d_ppp { file("/var/log/ppp.log"); };######################### Filters######################### Here's come the filter options. With this rules, we can set which# message go where.filter f_dbg { level(debug); };filter f_info { level(info); };filter f_notice { level(notice); };filter f_warn { level(warn); };filter f_err { level(err); };filter f_crit { level(crit .. emerg); };filter f_alllevel { level(debug, info, notice, warn,err,crit,emerg) and not filter(f_daemon);};filter f_debug { level(debug) and not facility(auth, authpriv, news, mail); };filter f_error { level(err .. emerg) ; };filter f_messages { level(info,notice,warn) and not facility(auth,authpriv,cron,daemon,mail,news); };filter f_auth { facility(auth, authpriv) and not filter(f_debug); };filter f_cron { facility(cron) and not filter(f_debug); };filter f_daemon { facility(daemon) and not filter(f_debug); };filter f_kern { facility(kern) and not filter(f_debug); };filter f_lpr { facility(lpr) and not filter(f_debug); };filter f_local { facility(local0, local1, local3, local4, local5, local6, local7) and not filter(f_debug); };filter f_mail { facility(mail) and not filter(f_debug); };filter f_news { facility(news) and not filter(f_debug); };filter f_syslog3 { not facility(auth, authpriv, mail) and not filter(f_debug); };filter f_user { facility(user) and not filter(f_debug); };filter f_uucp { facility(uucp) and not filter(f_debug); };filter f_cnews { level(notice, err, crit) and facility(news); };filter f_cother { level(debug, info, notice, warn) or facility(daemon, mail); };filter f_ppp { facility(local2) and not filter(f_debug); };filter f_console { level(warn .. emerg); };######################### Log paths########################log { source(s_src); filter(f_auth); destination(d_auth); };log { source(s_src); filter(f_cron); destination(d_cron); };log { source(s_src); filter(f_daemon); destination(d_daemon); };log { source(s_src); filter(f_kern); destination(d_Gateway); };log { source(s_src); filter(f_lpr); destination(d_lpr); };log { source(s_src); filter(f_syslog3); destination(d_syslog); };log { source(s_src); filter(f_user); destination(d_user); };log { source(s_src); filter(f_uucp); destination(d_uucp); };log { source(s_src); filter(f_mail); destination(d_mail); };#log { source(s_src); filter(f_mail); filter(f_info); destination(d_mailinfo); };#log { source(s_src); filter(f_mail); filter(f_warn); destination(d_mailwarn); };#log { source(s_src); filter(f_mail); filter(f_err); destination(d_mailerr); };log { source(s_src); filter(f_news); filter(f_crit); destination(d_newscrit); };log { source(s_src); filter(f_news); filter(f_err); destination(d_newserr); };log { source(s_src); filter(f_news); filter(f_notice); destination(d_newsnotice); };#log { source(s_src); filter(f_cnews); destination(d_console_all); };#log { source(s_src); filter(f_cother); destination(d_console_all); };#log { source(s_src); filter(f_ppp); destination(d_ppp); };log { source(s_src); filter(f_debug); destination(d_debug); };log { source(s_src); filter(f_error); destination(d_error); };log { source(s_src); filter(f_messages); destination(d_messages); };log { source(s_src); filter(f_console); destination(d_console_all); destination(d_xconsole); };log { source(s_src); filter(f_crit); destination(d_console); };# All messages send to a remote site##log { source(s_src); destination(d_net); };# GentApp/GatewayAppdestination d_Gateway { file("/var/log/Gateway.log"template("$FULLDATE $FULLHOST $PROGRAM $PID [$FACILITY.$LEVEL] $MESSAGE\n") ); };filter f_Gateway { match("Gate*") or match("Gent*") or match("Notifier*") or match("Alarm*"); };* *log { source(s_src); filter(f_Gateway);filter(f_alllevel); destination(d_Gateway);} ;* Please help me in debugging the issue and fixing it.

2 2

Set log directory based on the source
by Frank DiGennaro 18 Feb '20

18 Feb '20

Hello; I'm somewhat of a newbie when it comes to syslog-ng so forgive me if the question is somewhat basic. I am running syslog-ng 3.25 on both server and clients and would like to set a variable based on the source. This is what I have: @define server-logdir "/var/log" @define client-logdir "/var/log/CLIENTS/$YEAR/$MONTH_ABBREV/$DAY/$HOST" @define logdir "" source s_local { logdir `server-logdir`; *No! ... ... }; source s_network { logdir `client-logdir`; *No! ... ... }; destination d_local0 { file( "`logdir`/local/local0.log" ); }; The goal is to set 'logdir' to either 'server-logdir' or 'client-logdir' and use it in the destination. I know there are probably several ways that this can be accomplished but I think this was will cut down on the number of lines in the configuration. So my question Is this. How do I set 'logdir' to either 'server-logdir' or 'client-logdir' in the source definition? Thanks; DiGennaro Frank DiGennaro 301-676-8193 (C) <mailto:frank@digennaro.com> frank(a)digennaro.com

3 5

[Question]: Initialisation step in syslog-ng-3.25.1
by Nitish Saboo 18 Feb '20

18 Feb '20

I am using syslog-ng-3.25.1.I am initialising syslog-ng in the following manner: int initialize_engine(const gchar* _module_path) { resolvedConfigurablePaths.initial_module_path = _module_path; app_startup(); msg_init(TRUE); [*]//resolved_configurable_paths_init(&resolvedConfigurablePaths); configuration = cfg_new(0x0302); cfg_set_global_paths(configuration); cfg_load_module(configuration, "basicfuncs"); cfg_load_module(configuration, "syslogformat"); pattern_db_global_init(); return 0; } I have assigned value to 'resolvedConfigurablePaths.initial_module_path' to provide module-path location. Do I have to add this step [*]'resolved_configurable_paths_init(&resolvedConfigurablePaths)' that is commented currently in initialize_engine method ? Thanks, Nitish

2 1