lists@grounded.net wrote on 03/07/2008 08:44 :

What does the default syslog-ng installation use, tcp or udp? The

I'm not sure about a default, however in our configuration we have: source src_udp { udp(ip(x.x.x.x) port(514)); }; source src_tcp { tcp(ip(x.x.x.x) port(514) max-connections(250) tcp-keep-alive(yes)); }; So in this case our server listens on port 514/udp and on 54/tcp, on the specified IP address (x.x.x.x). I don't look after the firewalls, however I'm fairly certain that they use UDP by default. That's certainly how we're receiving the logs.

netscreen can't seem to reach the syslog-ng server but it can reach my other linux syslog servers.

Is there a blockage in the network somewhere? Our NetScreen's log via their management interface, so the log server has a presence on both the management and production networks. (So we actually have two sets of the 'source ...' lines above in the config - one for an IP on the production network and one for an IP on the management network.) Phil

�source src_udp { udp(ip(x.x.x.x) port(514)); }; �source src_tcp { tcp(ip(x.x.x.x) port(514) max-connections(250) �tcp-keep-alive(yes)); �};

Can't seem to get this to work, syslog-ng won't start but then, I'm new to it so am sure I'm just not getting it right. �

�So in this case our server listens on port 514/udp and on 54/tcp, on the

The netgear can send in either udp or tcp, I prefer udp but either way, it's not able to receive from the netscreen using defaults at least.

�Is there a blockage in the network somewhere? �Our NetScreen's log via �their management interface, so the log server has a presence on both the

Not that I know of. If I turn syslog-ng off and fire up syslog, the logging begins just fine and all goes to /var/log/netscreen in my case. Mike

Hi,

I got it going again and now see that the firewall is connected to syslog-ng. Thing is, where are the logs going? Nothing seems to be showing up in /var/log which seems to be the default location for logs.

Please, could you at least show your config? There is no default syslog-ng config. You should either write your own or copy one of the example configs from the tarball and customise it. Without seeing your actual config we're not able to help you, really. Also it would be quite useful for syslog-ng newbies to read the included reference guide for getting familiar with syslog-ng. BTW if you're concerned about logging then you shouldn't use UDP at all. Regards, Sandor -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.

Hi,

You know, sometimes you can read everything there is but just getting a little hands on opens all the doors to learning from there. I know the basics of linux syslog and have seen various examples of configurations but I've not figured out the config recipe method yet.

Well, syslogd and syslog-ng are quite different animals...

?

...

?BTW if you're concerned about logging then you shouldn't use ?UDP at all.

I would not be looking at logging if I was concerned about logging on either TCP or UDP. Not sure what you mean by this?

UDP is lossy, especially with syslog where the sender won't see that the logs are getting lost on the network. Use TCP if you can. The config below looks like a converted syslogd config. I'm putting in comments and syslogd-style equivalents, maybe this helps.

more /etc/syslog-ng.conf options { sync (0); time_reopen (10); log_fifo_size (1000); long_hostnames (off); use_dns (no); use_fqdn (no); create_dirs (no); keep_hostname (yes); };

source s_sys { file ("/proc/kmsg" log_prefix("kernel: ")); unix-stream ("/dev/log"); internal(); udp(ip(0.0.0.0) port(514)); };

So syslog-ng listens on udp only. When some of your devices use TCP then adding tcp(port(514)); would be useful, although it might clash with legacy rsh

destination d_cons { file("/dev/console"); }; destination d_mesg { file("/var/log/messages"); }; destination d_auth { file("/var/log/secure"); }; destination d_mail { file("/var/log/maillog" sync(10)); }; destination d_spol { file("/var/log/spooler"); }; destination d_boot { file("/var/log/boot.log"); }; destination d_cron { file("/var/log/cron"); }; destination d_kern { file("/var/log/kern"); }; destination d_mlal { usertty("*"); };

filter f_filter1 { facility(kern); }; filter f_filter2 { level(info..emerg) and not (facility(mail) or facility(authpriv) or facility(cron)); }; filter f_filter3 { facility(authpriv); }; filter f_filter4 { facility(mail); }; filter f_filter5 { level(emerg); }; filter f_filter6 { facility(uucp) or (facility(news) and level(crit..emerg)); }; filter f_filter7 { facility(local7); }; filter f_filter8 { facility(cron); };

#log { source(s_sys); filter(f_filter1); destination(d_cons); }; log { source(s_sys); filter(f_filter1); destination(d_kern); };

kern.* -/var/log/kern

log { source(s_sys); filter(f_filter2); destination(d_mesg); };

*.info;mail.none;authpriv.none;cron.none /var/log/messages

log { source(s_sys); filter(f_filter3); destination(d_auth); };

authpriv.* -/var/log/secure

log { source(s_sys); filter(f_filter4); destination(d_mail); };

mail.* -/var/log/maillog

log { source(s_sys); filter(f_filter5); destination(d_mlal); };

*.emerg *

log { source(s_sys); filter(f_filter6); destination(d_spol); };

uucp.*;news.crit -/var/log/spooler

log { source(s_sys); filter(f_filter7); destination(d_boot); };

local7.* -/var/log/boot.log

log { source(s_sys); filter(f_filter8); destination(d_cron); };

cron.* -/var/log/cron As you can see for example the 'debug' level/priority isn't logged for a lot facilities. So the question is which facility/ facilities your netscreen is using. You can get this info from the first few bytes of the packets, the facility/priority information is enclosed within angle brackets. Regards, Sandor -------------------------------------------------------- NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.