Linux System Management Practices (in): syslog System Log Configuration __linux

Linux saves detailed records of events that occur in the system, which are called log files or message files. You can refer to the log file to determine the current state of the system, observe the intruder trail, and look for data related to a particular program (or event). SYSLOGD and KLOGD (monitor the Linux kernel-submitted messages) daemon is responsible for recording, sending the information generated by the system or tool, both of which are/etc/syslog.conf. When the system kernel or tool generates information, it sends the information to the SYSLOGD or KLOGD daemon by calling the relevant function. The syslogd and klogd daemon processes the whereabouts of the message according to the configuration information in the/etc/syslog.conf. A detailed description of the Syslog protocol is in RFC3164.
The Logrotate tool is used to periodically rename, compress, and post system log files, which ensures that log files do not take up too much disk space.
1, the configuration file/etc/syslog.conf:Syslog.conf is a syslogd process configuration file that will be read when the program starts, and the default location is/etc/syslog.conf. The blank lines in this configuration file and the rows that begin with "#" are ignored. The "Facility.level" section is also called a selector (seletor). One or more whitespace separators are used between the seletor and the action. It specifies a series of logging rules. The rules are formatted as follows:
Facility.level Action
The selector (Seletor) consists of the facility and level two parts, with a period (.) Connection.
(1) Facility: Specifies the device that generates the log, which can be one of the following keywords:
Keyword value interpretation
Kern 0 Kernel information, first passed through KLOGD
User 1 information generated by your program
Mail 2 e-mail-related information
Daemon 3 information related to the inetd daemon
Auth 4 certified activities reported by PAM_PWDB
Syslog 5 Information generated by the Syslog
LPR 6 information related to print services
News 7 information from the press server
UUCP 8 Information generated by UUCP (UUCP = Unix to UNIX copy)
Cron 9 information about cron and at
Authpriv 10 authentication activities including private information (such as user name)
FTP 11 Information about FTP
12-15 System Retention
Local0 ~ Local7 16-23 is used by custom programs, such as using LOCAL5 as an SSH function
Mark Syslog internal function, for generating time stamps
* Wildcard symbol for all functions except Mark
In most cases, any program can send log messages through any facility, but it is generally in accordance with established rules. For example, only the kernel can use the "Kern" facility. Note that syslog retains the number of device numbers from "local0" to "LOCAL7" to accept log information sent over remote servers and network devices. Routers, switches, firewalls, and load balancers can easily configure a separate log file for each of them.
(2) Level: Specifies the priority of the message, which can be one of the following keywords (descending order, less severity):
Keyword value interpretation
Emerg 0 System is not available
Alert 1 conditions that require immediate modification
Crit 2 (Critical) error conditions that prevent certain tools or subsystem features from being implemented
ERR 3 Block tool or error condition implemented by some subsystem features
Warning 4 Alert Information
Notice 5 common conditions of importance
Info 6 message For information
Debug 7 does not contain additional information about a function condition or problem
None (masking all messages from the specified device) has no precedence, and is typically used for scheduling errors
* All levels except None
The facility part can be multiple devices separated by commas (,), and multiple seletor can also be grouped together by semicolons (;). Note that multiple combinations of selectors, followed by the previous one, allow some precedence to be excluded from the schema. Messages at the specified level and more severity levels are operated by default, but can be modified with 2 operators. Equal to operator (=) means that only the message at this level is operated, unequal operator (!) Represents a message that ignores this level and the severity level. These two operators can be used at the same time, but "!" Must appear in front of "=".
(3) Action action: action determines where the SYSLOGD and klogd daemons send log messages. There are several options:
Normal file: Use the absolute path of the file to indicate where the log file is located, for example:/var/log/cron.
Terminal Equipment: Terminals can be/dev/tty0~/dev/tty6, or can be/dev/console.
User list: For example, the action is "root Hackbutter", which writes the message to the computer screen of user root and Hackbutter.
Remote host: The SYSLOGD daemon that sends information to other hosts on the network in the form "@hostname."
(4) syntax description of the configuration file:
* When used as a device or priority, you can match all the devices or priorities.
* Sends a message to all logged-in users when used as an action.
Multiple selectors can be in the same row and separated by semicolons, and the latter will cover the front. such as Uucp,news.crit.
When the keyword none is used as a priority, all messages from the specified device are masked.
By using the same selector and different actions, the same message can be logged to multiple locations.
The configuration lines that follow in the syslog.conf file do not overwrite the previous configuration line, and each row specifies that the actions are operated independently.
(5) The default/etc/syslog.conf content in my Ubuntu:

#/etc/syslog.conf SYSLOGD Profile # More information reference syslog.conf (5) # # The first is some standard log files, messages sent by the corresponding device # # Authentication activity AUTH,AUTHPRIV Log messages are sent to Auth.log auth,authpriv.*/var/log/auth.log # All messages for all devices except Auth and Authpriv are sent to the syslog *.*;auth,authpriv.none-/var/log/syslog # Messages from Cron and at are sent to the Cron.log #cron. */var/log/cron.log # INETD All messages sent to Daemon.log daemon.*-/var/log/daemon.log # All messages from the kernel (such as KLOGD messages) are sent to the Kernlog kern.*-/var/log/kern.log # Print Service sent to the Lpr.log lpr.*-/var/log/lpr.log # All messages sent to the Mail.log mail.*-/var/log/mail.log # User program are sent to the User.log user.*-/var/log/user.log # Mail system log records. Split into different files so that it's easier to write the script # parse these files # message info or higher level message sent to Mail.info,warn higher level message sent to Mail.warn, # ERR or higher level message sent to Mail.err Mail.info-/var/log/mail.info mail.warn-/var/log/mail.warn mail.err/var/log/mail.err # Inn News system logging: Message from news server # News.crit/var/log/news/news.crit News.err/var/log/news/news.err News.notice-/var/log/news/news.notice # Some captured log files # # The debug level messages for all devices except Auth,authpriv,news,mail are sent to debug *.=debug;/auth,authpriv.none;/news.noNe;mail.none-/var/log/debug # Info,notice of all devices except Auth,authpriv,cron,daemon,mail,news, # Warn-level messages are sent to messages info;*.=notice;*.=warn;/auth,authpriv.none;/cron,daemon.none;/Mail,news.none-/var/log/messages # The Emerg level message for all devices (which the system cannot use) is sent to all logged-in users # *.emerg * # I want some messages to be displayed on the console, but only on the Virtual Console: Daemon,mail any messages, news dangers, # errors, notification messages, debugging of any device, Information, alerts, alert messages # #daemon, mail.*;/# news.=crit;news.=err;news.=notice;/# *.=debug;*.=info;/# *.=notice;*.=warn/dev/tty8 # Named pipe/dev/xconsole is used for Xconsloe tools. In order to use it, you must take the-file option to invoke the XConsole # $ xconsole-file/dev/xconsole [...] # Note: Adjust the list below, otherwise if you have a fairly busy site, you will get mad daemon.*;mail.* ;/news.err;/*.=debug;*.=info;/*.=notice;*.=warn |/dev/xconsole

Some applications also log their health to a specific log file, which is not controlled by the syslog.conf file. such as file/var/log/apache2/access.log, catalogue/var/log/apache2,/var/log/cups,/VAR/LOG/GDM,/var/log/mysql,/var/log/samba, etc.
After the/etc/syslog.conf is modified, the Syslog service can be restarted using the service syslog restart, and sudo/etc/init.d/sysklogd restart is used in Debian/ubuntu. View the latest records in the log file available Tail-f/var/log/messages.
2, logging information to the remote Linux server:Logging your system information to a remote server will be a good security measure. If you log information about all of your company's servers to a centralized syslog server, this will facilitate you to manage the events that occur in each server. This can also make masking errors and malicious attacks more difficult because malicious deletion of individual log files cannot occur at the same time on the log server, especially when you restrict user access to the log server.
Configure the Syslog server: By default, Syslog does not accept remote client information, and to activate it, the/etc/sysconfig/syslog file needs to be modified in Redhat/fedora, Syslogd_ The-r option is added to the options parameter to allow logging of remote machine information. In Debian/ubuntu, you modify the syslogd parameters in the/etc/default/syslogd file, or you can edit the Syslog startup script/etc/init.d/sysklogd directly and define the SYSLOGD parameters as "-r". Restart the Syslog service after the modifications are completed.
Configure client: The Syslog server can now accept syslog information. You also have to set up remote Linux clients to send information to the server. Assume that the client host name is Smallfry and can be implemented by editing the/etc/hosts file.
(1) Determine the IP address and valid domain name of the remote server.
(2) Add a description of the remote server in the/etc/hosts file of the client flight: IP address full domain name server name "Alias", such as 192.168.1.100 bigboy.my-site.com Bigboy Loghost, This sets an alias Loghost for the server host Bigboy.
(3) Edit the client's/etc/syslog.conf file so that the syslog information can be sent to your new set of log server Loghost.
*.debug @loghost
*.debug/var/log/messages
Reboot the Syslog service, and your machine will now send all the "debug" level and above level information to both the server Bigboy and the local file/var/log/messeges. You can do a simple test to see if the syslog server is receiving your information. For example, restart the LPD printer daemon and see if you can see the relevant log messages on the server.
3, the configuration file/etc/logrotate.conf:It is a general configuration file for Logrotate. You can use it to set which log file is recycled and how often it is reused. The cycle parameters can be set weekly (weekly) or per day (daily). The rotate parameter defines how many log file backups are retained, and the Create parameter specifies that a new empty log file be created after each round of loops. The default/etc/logrotate.conf content in my Ubuntu is:

# More details refer to "Man logrotate" # Weekly circular update log file weekly # Keep 4 copies of log files, if log files are logfile, their backup # is logfile.0~logfile3 rotate 4 # After each round of loops create a new Blank log file Create # If you want to compress the log file, uncomment the following #compress # Some software packages that use syslog will put log rotation information in this directory, so include it in INCLUDE/ETC/LOGROTATE.D # No packages have wtmp or btmp, we will rotate here/var/log/wtmp {Missingok # If the log file is missing, use the next and do not send any error messages monthly # rotation cycle is the monthly create 0664 root utmp # When creating a new log file, the permission is 0664, the owner is root, the group is utmp rotate 1}/var/log/btmp {Missingok monthly create 0664 root utmp rotate 1} # System-specific logs can be Configure here

    Note in the Debian/ubuntu system, the/ETC/CRON.DAILY.SYSKLOGD script will read the/etc/syslog.conf file and rotate all the set log files according to it. So, for general system logs, you don't have to repeat the settings in the/ETC/LOGROTATE.D folder. Because it does not run once in 24 hours in the/etc/cron.daily folder. In the Fedora/redhat system, this script is replaced by/etc/cron.daily/logrotate, and it does not read the syslog configuration file. So you have to set it up in/ETC/LOGROTATE.D. The
    logrotate settings will not take effect until you use the LOGROTATE-F command. If you want logrotate to read only specific profiles instead of all, run the configuration file name as a logrotate parameter, such as Logrotate-f/etc/logrotate.d/syslog. If you have a high level of access to your Web pages, the log files will become unusually large. You can compress the log file by editing the logrotate.conf file to add the compression option compress. These log files will be compressed with gzip, and all files will have a. gz extension. It is still easy to view the contents of these files, as you can quickly display their contents on the screen with the Zcat command. One disadvantage of the
    syslog server is that it does not filter out messages from bad sources. Therefore, when your server is in an insecure network, it is a wise move to use TCP wrappers software or firewalls to limit acceptable sources. This will help limit the effectiveness of the denial of service attack, which is designed to fill your server's hard disk or add additional system resources, which could eventually cause the server to crash.
    now uses an increasingly broad syslog-ng program that combines the features of Logrotate and syslog to provide users with more customization capabilities and richer functionality. If you want to use it, you can go to www.balabit.com to download the installation, its configuration file is/etc/syslog-ng/syslog-ng.conf.