Need Assstnce Wth Syslog-NG Conf to Accept Remote syslg data

I’m trying to get my SLES 11 SP 1 server to accept a remote syslog stream from another system but I’m not having any luck and could really use some help. For explanations sake, let’s say that the remote system has an IP address of and the SLES server’s interface has an IP address of

Also, I’m running AppArmor but I have both the syslogd and syslog-ng default AppArmor profiles in complain mode, so even if apparmor events were being generated, they would still be allowed and just logged to the audit.log.

I have a rule (two actually; one for tcp and one for udp) in the Suse Firewall (under the custom rules) to allow tcp 514 (and udp 514) to come in through the firewall from I have the -r option set in the syslog.conf file (I did this using the YaST /etc/sysconfig editor. Using that editor, under System → Logging → SYSLOGD_PARAMS, I entered


and under SYSLOG_NG_PARAMS I put in

source s_tcp {tcp(ip( port(514)); };

From the books that I have, that is all that should be required. Tell syslogd to accept remote connections, punch a hole through the firewall on that port, and tell syslog-ng to accept the remote source syslog stream (from what IP address and on what port). Now, using tcpdump, I’ve verified that the syslog stream is getting to the SLES server on port 514. But when I use the YaST log viewer to look in the audit.log file, I don’t see any of the remote syslog stream data in there. So, either I’ve configured something wrong or there is some other service (other than syslog) using port 514 and it is interfering with the process or when syslog-ng gets the remote data, it is not storing it in the audit.log file (either it isn’t storing it at all, but just rejecting it, or it is storing it in some other file I don’t know about). The source sending the stream is sending it to facility local2 on Since I’m not all that familiar with how the facilities work, maybe that is where my problem is coming from.

I could really use some help.

Have you looked in /var/log to see if it’s logging to a different

fgrep "10.1.1" /var/log/*

Cheers Malcolm °¿° (Linux Counter #276890)
SUSE Linux Enterprise Desktop 11 (x86_64) Kernel 3.0.13-0.27-default
up 15:23, 2 users, load average: 0.01, 0.04, 0.05
CPU Intel i5 CPU M520@2.40GHz | Intel Arrandale GPU

As Malcolm suggested, maybe the log isn’t going where you think it is. I have a bunch of SLED machines which write a copy of their log to a SLES machine. If you’re still having trouble, the following might help, which is taken from my notes on how I set it up.

On the SLES machine:

Add this to the end of /etc/syslog-ng/syslog-ng.conf

source from_network { internal(); udp(ip("") port(514)); }; destination from_network { file("/var/log/network/$YEAR/$MONTH/$HOST/log" owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes) ); }; log { source(from_network); destination(from_network); };
Restart syslog

$ service syslog restart

Add a firewall rule to allow UDP access to port 514. (I do this with a custom rule because the SLES machine has a public IP address and I want to ensure the connections only come a certain range of IP addresses.)

On the SLED machines:

Add this to the end of /etc/syslog-ng/syslog-ng.conf

destination hostname_of_server { udp("hostname_of_server" port (514)); }; log { source(src); destination(hostname_of_server); };

$ service syslog restart $ echo "hello world" | logger

On the SLES box you should now have a copy of the machine’s log in the file /var/log/network/year/month/date/hostname/log

Evidently I also needed a destination line and a log line to get things working. Your first three lines of code, with some modifications, did the trick.

I got rid of most of this:

destination from_network { file("/var/log/network/$YEAR/$MONTH/$HOST/log"
owner(root) group(root) perm(0600) dir_perm(0700) create_dirs(yes) ); };

and changed it to this:

destination from_network { file("/var/log/audit/audit.log"); };

But when I tried to change the ip address in the source line from to, I got all sorts of error messages. So I had to put it back to and just depend on the firewall rule to restrict where the data can come from. But those first three lines you provided made all the difference.