UNIX for Advanced & Expert Users

There are two primary aspects to syslog. First, there are user and system defined 'logging levels' that are defined by the programmer who wrote the code. Each of these or groups of these 'logging levels' can be directed to local and remote log files (configured in syslog.conf).

Sometimes it is hard to know the user and system defined logging levels a programmer used if they have not documented this is the specific application.

What program are you using that you are trying to log?

i am using the vanilla syslogd on my FreeBSD 4.7 box.

i'm typing the command as follows:

syslogd -v -a x.x.x.x/11:syslog -a x.x.x.x/24:syslog

the network is set like this:

webramp<----->cisco 806<----->internal network (FreeBSD box)

they are in different networks. i've opened a hole in the 806 (using reflexive access lists) on UDP 514 to allow for the syslog information to pass through.

the webramp has it's own method for logging to a syslog server (just a matter of checking a box and clicking update). the 806, does it by telling it through the IOS, which most of you probably know as it is.

i've run tcpdump and i do see some messages comming from the cisco 806... but very few... and they're not being stored anywhere i can gather.

From your reply it systems you are logging a CISCO router to a syslog host, is that right?

If that is the case, you must search the CISCO documentation for how to configure logging levels and ' and set the router to log appropriately. Then, with the user (or system) defined levels, you configure syslogd.conf to direct these logfile entries to any file you want.

Here is an example of how to do this:

http://colin.bitterfield.com/Syslog_...atacenter.html

Note both the CISCO configuration and syslogd.conf configuration is in the example above. Also notice that they use local6 as the defined user logging level:

The example shows one example syslogd.conf file to match the CISCO configuration.

That is why I asked 'what is the application that is logging'... to properly configure syslog, it is necessary to consider both the logging application (in this case a CISCO device) and the logging process (in this case, syslogd, which we all knew). The critical missing information was the device or application that you are logging (a CISCO router, in this case).

Then again, maybe not.... when I reread your post I think you might be trying to log a 'webramp process'....... if that is the case, you must understand how that application uses the syslog facility.


You can get more information by a Google search with keywords: syslog CISCO configuration which yields:

http://www.google.com/search?hl=en&l...=Google+Search

okay, the issues seems to have been an incorrect ACL entry that debared access.

now /var/log/messages has being filled with information from the firewall.

however, one issue still remains, the logs are all being sent to /var/log/messages and not the other locations.

i did the following to allow the logs to be directed to other files. in my /etc/syslog.conf file i have this entry:

# external hosts (router and firewall)
!router
local7.* /var/log/router-logs
local7.alert /var/log/router-logs
local7.crit /var/log/router-logs
local7.debug /var/log/router-logs
local7.emerg /var/log/router-logs
local7.err /var/log/router-logs
local7.info /var/log/router-logs
local7.notice /var/log/router-logs
local7.warn /var/log/router-logs

i made the files ahead of time by doing a "touch router-logs"

i've scoured the man pages which are a really poor source for this information because they don't tell me how to do what i want to do here. your link about the solaris system was somewhat better, and i found something on cisco's site.

i really don't think what i've done is right because the file isn't being populated by anything.

Perhaps a stupid question:

Did you kill and restart syslogd after making configuration changes to syslogd.conf?

Also, in your syslogd.conf configuration, you only need one entry:

Code:

local7.* /var/log/router-logs

This entry takes care of all the others for local7 you have defined.


Forgot to add.... be sure that the permissions of the /var/log-router-logs are correct to allow syslogd to write to those files.

yes, i did. everytime i alter my syslog.conf i kill and restart syslogd.

the permissions on messages and router-log are the same.

i commented out the excess lines.

i'm thinking that, the following might be an issue.


*.err;kern.debug;auth.notice;mail.crit /dev/console
*.notice;kern.debug;lpr.info;mail.crit;news.err /var/log/messages


the "*.notice" second line, i'm assuming means that all notices, regardless of source, are to be sent to /var/log/messages.

unfortunately, i don't know the severity rating of the messages that the firewall is sending.

maybe you can help me out. a typical message looks like this:

Jan 20 20:19:08 <16.5> (806 hostname) id=firewall sn=(serial number of webramp) time="2003-01-20 20:19:07" fw=(some ip address) pri=5 c=256 m=38 msg="ICMP packet dropped" n=2956 src==(some ip address) dst==(some ip address) rule=0^M

again, an assumption, but i think that pri=5 means priority 5, which seems to be a notification level event with the cisco router.

if this is the case, how could i redirect only FreeBSD notifications to go to messages?

i didn't get a clear indication of how to do it in the documentation? is it local0.notice or something?

One of the issues that make syslog a bit less effective than it could be is inconsistent ways that programmers use the facility. This includes the format of the actual message. I once led a project for a major financial organization to use syslog to correlate network intrusion events. It was sometimes difficult because of the lack of standards for programmers using syslog. OK, enough of the flashback to days-gone-by and back to your situation:

I would suggest that you start simple with syslogd.conf and work your way to more complex, and carefully watch what is going on (and when things break). In other words, start with just your local7 entries in syslogd.conf and comment out all the others. Insure that is working properly first.... then uncomment one line at a time until you find the configuration conflict/problem.

Hint: Wildcards (*) in syslogd.conf

You are almost there!!!