The main configuration file for syslog is
For RHEL 5 and older
For RHEL 6 and 7
Benefits of syslog
- Helps analyze the root cause for any trouble or problem caused
- Reduce overall downtime helping to troubleshoot issues faster with all the logs
- Improves incident management by active detection of issues
- Self-determination of incidents along with auto resolution
- Simplified architecture with different level of severity like error,info,warning etc
The syslog.conf file is the main configuration file for the syslogd which logs system messages on *nix Systems. This file specifies rules for logging. Every rule consists of two fields, a selector field and an action field. These two fields are separated by one or more spaces or tabs. The selector field specifies a pattern of facilities and priorities belonging to the specified action.
The selector field itself again consists of two parts, a facility and a priority, separated by a period (”.”). Both parts are case insensitive.
Kern.none, mail.info etc Here Kern = Facility None = severity or priority
The facility is one of the following keywords: auth, authpriv, cron, daemon, kern, lpr, mail, mark, news, security (same as auth), syslog, user, uucp and local0 through local7. The keyword security should not be used anymore and mark is only for internal use and therefore should not be used in applications.
Anyway, you may want to specify and redirect these messages here. The facility specifies the subsystem that produced the message, i.e. all mail programs log with the mail facility (LOG_MAIL) if they log using syslog.
user level messages
messages generated internally by syslogd
line printer subsystem
network news subsystem
local use 0 (local0)
local use 1 (local1)
local use 2 (local2)
local use 3 (local3)
local use 4 (local4)
local use 5 (local5)
local use 6 (local6)
local use 7 (local7)
The priority is one of the following keywords, in ascending order: debug, info, notice, warning, warn (same as warning), err, error (same as err), crit, alert, emerg, panic (same as emerg). The keywords error, warn and panic are deprecated and should not be used anymore. The priority defines the severity of the message
Emergency: System is unusable
Alert: Action must be taken immediately
Critical: critical conditions
Error: Error conditions
Warning: Warning conditions
Notice: Normal but significant conditions
Informational: Informational messages
Debug: Debug level messages
You can specify multiple facilities with the same priority pattern in one statement using the comma (”,”) operator. You may specify as much facilities as you want. Multiple selectors may be specified for a single action using the semicolon (”;”) separator. Remember that each selector in the selector field is capable to overwrite the preceding ones. Using this behavior you can exclude some priorities from the pattern.
Log all the critical events on your Linux machine in a separate log file inside /var/log with a name of critical.log
Append this line inside /etc/syslog.conf
Log all the kernel related messages in separate log file inside /var/log/firewall.log
# Add a new line Kern.* /var/log/firewall.log # Add a new entry at the end of the below line # Log anything (except mail) of level info or higher. # don’t log private authentication messages! # don’t log kernel related events and messages *.info;mail.none;authpriv.none;cron.none;kern.none /var/log/messages
Redirect all the error logs to a remote user root and Deepak on their terminals
# Messages of the priority alert will be directed # to the operator # *.err root,deepak
Log all the firewall warning level messages inside /var/log/firewall-warning.log
Support for Remote Logging
These modifications provide network support to the syslogd facility. Network support means that messages can be forwarded from one node running syslogd to another node running syslogd where they will be actually logged to a disk file.
The strategy is to have syslogd listen on a unix domain socket for locally generated log messages. This behavior will allow syslogd to inter-operate with the syslog found in the standard C library. At the same time syslogd listens on the standard syslog port for messages forwarded from other hosts. To have this work correctly the /etc/services file must have the following entry:
If this entry is missing syslogd neither can receive remote messages nor send them, because the UDP port can’t be opened. Instead syslogd will die immediately, blowing out an error message.
to forward ALL messages to a remote host uses the following syslog.conf entry:
# Sample syslogd configuration files to # Messages to a remote host forward all. *.* @hostname
To forward all kernel messages to a remote host the configuration file would be as follows:
# Sample configuration files to forward all kernels # messages to a remote host. kern.* @hostname