How to "drop" a message, effectively skipping further processing and not logging it?
In the cases where there are frequent messages that are known to be trivial and not desired to be seen, I have always dumped them to a "/dev/null" rule like this below on the sender. I would really like to get rid of the modification of /dev/ file permissions, as I find it the opposite of good security to have the syslog daemon modifying files that need to be accessible for many things to work right. This also clashes with things like udev and cfengine, which exist TO properly set perms and maintain files. Is there any way other than this to keep a message from being sent to another host or a file? If not, is there any way to tell syslog-ng NOT to modify the state of a file, just to send data TO it? That, or an internal "drop" stop-processing built-in destination would be extremely useful. Existing things I've tried (/dev/null and fake localhost UDP target)and problems I'm having with them, any suggested workarounds? ( clients running syslog-ng 1.6.5 ) ### conf: destination null { file("/dev/null" owner(root) group(root) perm(0666) dir_perm(0666) create_dirs(no)); }; log { source(src); filter(f_getty_serial_err); destination(null); flags(final); }; # error: 2007-09-06T12:21:33-07:00 hostname [syslog.err] syslog-ng[9467]: Changing permissions on special file /dev/null ### This requires setting the perms correctly, since syslog-ng INSISTS for "security reasons" on modifying/setting the perms of any file it writes to.. and so I write drop rules for the "Changing permissions on special file" errors :) I've tried to work around this by logging to a localhost UDP blackhole that should avoid this, but am having issues with that: ### conf: destination net-blackhole { udp("127.0.0.1" port(666) localip(127.0.0.1)); }; log { source(src); filter(f_getty_serial_err); destination(net-blackhole); flags(final); }; # error: 2007-09-06T13:18:00-07:00 deathstar1401 [syslog.err] syslog-ng[25010]: io.c: do_write: write() failed (errno 111), Connection refused 2007-09-06T13:18:00-07:00 deathstar1401 [syslog.err] syslog-ng[25010]: Connection broken to AF_INET(127.0.0.1:666), reopening in 60 seconds ### pcap: 13:14:59.404524 IP (tos 0x0, ttl 64, id 31643, offset 0, flags [DF], length: 110) 127.0.0.1.51170 > 127.0.0.1.666: [bad udp cksum dfe5!] UDP, length: 82 13:15:59.855390 IP (tos 0x0, ttl 64, id 46755, offset 0, flags [DF], length: 110) 127.0.0.1.51230 > 127.0.0.1.666: [bad udp cksum a8e4!] UDP, length: 82 13:16:59.658501 IP (tos 0x0, ttl 64, id 61705, offset 0, flags [DF], length: 110) 127.0.0.1.51237 > 127.0.0.1.666: [bad udp cksum 9be4!] UDP, length: 82 ### It looks from the error like syslog-ng thinks it is using TCP... since UDP syslog has no connection/handshake at either the IP or application protocol level I don't know why it is having any connection errors. The packets are being successfully sent, and a netcat listen shows that they're perfect... Even an ICMP PORT UNREACHABLE shouldn't have any effect on the sending process. Any thoughts on what's going on here? Thanks, /eli
Hello,
Is there any way other than this to keep a message from being sent to another host or a file? If not, is there any way to tell syslog-ng NOT to modify the state of a file, just to send data TO it? That, or an internal "drop" stop-processing built-in destination would be extremely useful.
Simply remove all destinations from the log section and use flags(final) will do the trick. 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.
Geller, Sandor (IT) wrote:
Hello,
Is there any way other than this to keep a message from being sent to another host or a file? If not, is there any way to tell syslog-ng NOT to modify the state of a file, just to send data TO it? That, or an internal "drop" stop-processing built-in destination would be extremely useful.
Simply remove all destinations from the log section and use flags(final) will do the trick.
Don't I feel daft... I recall trying that a couple years ago, but had errors I don't seem to have resolved before deciding to just write to /dev/null. I must've botched the syntax and thought that you HAD to have a destination in a log line! Thanks for the suggestion. Cheers, /eli
participants (2)
-
Eli Stair
-
Geller, Sandor (IT)