I have a cisco firewall that's currently syslogging to /var/log/firewall . /var's getting tight on space, so I created /opt/log, gave it the same perms and ownership, then altered my /etc/syslog.conf file to write to /opt/log/firewall, and restarted syslog. No new files were being written to /opt/log and nothing was being written to /var/log either. So, I changed everything back and it's logging to /var/log again.

My question is, besides syslog.conf, is there anything that would keep me from syslogging to somewhere other than /var/log?

Thanks in advance...

without wishing to dodge the question and reinvent the wheel, if you want nothign more than standard syslogging for the system and remote switches, i'd really really recommend changing to use syslog-ng instead, it's really simple to drop in replace syslogd and the configuration iso so simple when you're adding network syslog sources and such, and can do nice things like automatically archiving files into /host/yy/mm/dd/ things...

Acid,

Thanks for the response, but for now I'd like to fix what I have, if it's possible.

Some thoughts:

If the firewall program does its logging through syslog, then the answer is no. (By the way, you can verify that logging is going through syslog by running lsof and seeing which process is writing to /var/log/firewall). Assuming, as seems to be the case, that syslog is doing the logging, you might need to create the initial log file /opt/log/firewall, so you may need to touch it and subsequently chown and chmod it to whatever it should be (i.e. to whatever the permissions currently are on /var/log/firewall).

I just tried touching the files (firewall and firewall.1) and gave them the same perms as the files in /var/log. No dice. I ran an lsof and grepped for syslog, and while it was set to log to /opt/log, there was no entry for syslog in the output.

So, I took a look at the messages log, and here's what I found:

kernel: audit(1187013097.609:0): avc: denied { append } for pid=4900 exe=/sbin/syslogd name=firewall dev=dm-4 ino=1343490 scontext=root:system_r:syslogd_t tcontext=rootbject_r:usr_t tclass=file
syslog: syslogd shutdown succeeded

By the looks of it, selinux was preventing the syslogd daemon from writing to the file. I tried changing the enforcement level to permissive, and disabled, with no luck, but as far as I can tell the system needs to be rebooted to reset selinux. It's a production box, so I don't know when that will be. I'll be sure to update this post when I find out.

Good work. Thanks for posting the solution.