topic Re: syslog.conf question in Operating System - HP-UX

syslog.conf question

Lucy2009_1 — Thu, 07 Apr 2011 17:47:32 GMT

How to configure syslog.conf to send syslog info to a remote server, a file named /var/tmp/serverA_syslog.log on the remote server?

Re: syslog.conf question

Mel Burslan — Thu, 07 Apr 2011 17:57:20 GMT

in syslog.conf, you need to insert a line like this :

*.* @10.11.12.13

where 10.11.12.13 is your syslog server's IP address.

Regarding where this log will be placed on the remote server, is not something you can control from the client side. It needs to be handled on the remote log server. I have never needed to create a log server on my own. Hence I can not comment how. I was always asked (mostly for security purposes) to send the syslog to this black-box, but it should not be too bad. Most linux flavors nowadays come with remote log reception capability by default.

Re: syslog.conf question

Lucy2009_1 — Thu, 07 Apr 2011 18:10:08 GMT

I want to send to the remote server with a file name, not to the syslog.log on the remote server. May be I can use "local" facility but I don't know the exact syntax.

Re: syslog.conf question

Mel Burslan — Thu, 07 Apr 2011 18:29:47 GMT

rsync -av /var/adm/syslog/syslog.log remote_server:/remote/path/to/filename > /dev/null 2>&1

schedule this to run every minute or 5 minutes or 10 according to your desire from cron. It is not the live update as remote syslog server option is, but a close second to that.

if your server doesn't have rsync, you can download it from hpux software porting archive over the internet. Just google it.

Re: syslog.conf question

Raj Briden — Thu, 07 Apr 2011 18:32:22 GMT

*.debug@

Re: syslog.conf question

Lucy2009_1 — Thu, 07 Apr 2011 19:37:33 GMT

I want to know how to configure "local" to forward info to a syslog server and define a file name for the incoming message on the remote server.

Re: syslog.conf question

Matti_Kurkela — Thu, 07 Apr 2011 20:24:16 GMT

The standard HP-UX syslogd won't treat incoming remote log messages any differently from local ones, and it cannot manipulate the facility/priority codes of outgoing syslog messages.

If you're setting up a dedicated log server, it might be worthwhile to install an advanced syslog daemon (syslog-ng or rsyslog) to the log server. Most advanced syslog daemons can be configured to listen for incoming remote syslog messages only, so the syslog server's own local logging can remain unaffected, if you wish.

Advanced syslog daemons also include a more flexible configuration language: this will allow you to store log messages to different files based on which server sent it, and (at least in the case of rsyslog) even to automatically create the log file if it doesn't already exist. For the standard syslog daemon, you'll have to create the logfile first before the syslog daemon can start writing to it.

You can also filter log messages by regular expressions: if some application produces messages that are recognizable using a regexp, this will give you an easy way to file those messages to a separate file, even if the application cannot use a custom syslog facility.

If you want to get really fancy, you can set your advanced syslog daemon to output the messages to a table in a database. Sure, it's more work to set it up that way, but once you have your logs in a database, indexed by e.g. time, hostname, syslog priority, facility and/or process name, you'll have the full power of the database to help you analyze the mass of logs. For example, you can easily calculate the amount of log messages per day sent by each host. You would expect this to stay about the same if nothing is changed: for example, if some host suddenly starts to log 10x the amount it normally does, it might be worthwhile to check it out, even if the messages are not strictly errors.

(We implemented this kind of setup: after a week or so, we caught a file transfer script that was stuck in infinite loop, transferring the same file over and over because someone had left an incorrectly-named file to the transfer directory.)

Or you could use database triggers to alert you when a version number included in a particular type of log message indicates one of your hosts has a version of sendmail or sshd that has serious known bugs.

Many of these things are possible with shell scripting too; but using a database allows non-trivial searches and makes everything much easier and faster.

There are even free Web GUIs for browsing such log databases available: you don't have to learn SQL to use your log database effectively.

MK

Re: syslog.conf question

Lucy2009_1 — Thu, 07 Apr 2011 22:19:58 GMT

MK, thanks for the info. I will try that.

Re: syslog.conf question

Lucy2009_1 — Wed, 27 Apr 2011 20:00:42 GMT

thanks.