LPI Linux Certification in a Nutshell - BestLightNovel.com
You’re reading novel LPI Linux Certification in a Nutshell Part 33 online at BestLightNovel.com. Please use the follow button to get notification about the latest chapter next time when you visit BestLightNovel.com. Use F11 button to read novel in full-screen(PC only). Drop by anytime you want to read free – fast – latest novel. It’s great if you could leave a comment, share your opinion about the new chapters, new novel with others on the internet. We’ll do our best to bring you the finest, latest novel everyday. Enjoy
mail.*/var/log/maillog #Everybodygetsemergencymessages.
*.emerg*
#Savebootmessagesalsotoboot.log local7.*/var/log/boot.log If you examine this syslog.conf syslog.conf file, you'll see that nearly all system messages are sent to the file, you'll see that nearly all system messages are sent to the /var/log/messages /var/log/messages file via the file via the *.info *.info message selector. In this case, the asterisk directs message selector. In this case, the asterisk directs syslogd syslogd to send messages from all facilities except to send messages from all facilities except mail mail and and authpriv authpriv, which are excluded using the special none none level. The level. The /var/log/messages /var/log/messages file is the default system message destination, and you will consult it frequently for information on processes running (or failing to run) and other events on your system. In this example, the low severity level of file is the default system message destination, and you will consult it frequently for information on processes running (or failing to run) and other events on your system. In this example, the low severity level of info info is used for the is used for the messages messages file, which logs all but debugging messages. On heavily loaded servers, this may result in an unwieldy file size due to message volume. Depending upon your available disk s.p.a.ce, you may choose to save less information by raising the level for the file, which logs all but debugging messages. On heavily loaded servers, this may result in an unwieldy file size due to message volume. Depending upon your available disk s.p.a.ce, you may choose to save less information by raising the level for the messages messages file. file.
The syslogd syslogd server keeps the file handles open for all files defined in server keeps the file handles open for all files defined in /etc/syslog.conf /etc/syslog.conf. This means that the only process that can write to these files is syslogd syslogd. Do not configure your programs to write directly to these files! Instead, call a program such as logger logger, or use one of the many syslog API interfaces available for your language of choice.
The syslog service is actually made up of two processes, syslogd syslogd and and klogd klogd. Syslogd Syslogd is used to log events from user process, whereas is used to log events from user process, whereas klogd klogd is used to log events from kernel processes. They work in tandem and use the same configuration file, so you really just need to make sure they are both running: is used to log events from kernel processes. They work in tandem and use the same configuration file, so you really just need to make sure they are both running: $psax|egrep-i"(syslogd|klogd)"
2078?Ss0:04syslogd-m0 2081?Ss0:00klogd-x Client/Server Logging Syslogd also has the ability to log messages across the network. If a syslogd process is started with the also has the ability to log messages across the network. If a syslogd process is started with the -r -r option, it will listen on the network for incoming option, it will listen on the network for incoming syslogd syslogd messages. By default, messages. By default, syslogd syslogd uses UDP port 514 for this communication. A common practice is to set up one master logging server that receives all uses UDP port 514 for this communication. A common practice is to set up one master logging server that receives all syslogd syslogd messages from all clients. On the client side, you would configure the local messages from all clients. On the client side, you would configure the local syslogd syslogd service to log events locally, and to log everything to the master logging server. This would be accomplished by adding the following line to the example service to log events locally, and to log everything to the master logging server. This would be accomplished by adding the following line to the example syslog.conf syslog.conf file shown in file shown in Example16-2 Example16-2: [email protected] This means that messages matching all facilities and levels should be sent to the IP address 10.0.0.1.
You can determine whether a syslogd syslogd server is listening for remote log entries by running server is listening for remote log entries by running netstat netstat: #netstat-anp|grep-i":514"
udp000.0.0.0:5140.0.0.0:*26645/syslogd Logfile Rotation Most distributions will install a default syslog syslog configuration for you, including logging to configuration for you, including logging to messages messages and other logfiles in and other logfiles in /var/log /var/log. To prevent any of these files from growing unattended to extreme sizes, a logfile rotation scheme should be installed as well. The cron cron system issues commands on a regular basis (usually once per day) to establish new logfiles; the old files are renamed with numeric suffixes. With this kind of rotation, yesterday's system issues commands on a regular basis (usually once per day) to establish new logfiles; the old files are renamed with numeric suffixes. With this kind of rotation, yesterday's /var/log/messages /var/log/messages file becomes today's file becomes today's /var/log/messages.1 /var/log/messages.1, and a new /var/log/messages /var/log/messages file is created. The rotation is configured with a maximum number of files to keep, and the oldest logfiles are deleted when the rotation is run. file is created. The rotation is configured with a maximum number of files to keep, and the oldest logfiles are deleted when the rotation is run.
The utility that establishes the rotation is logrotate logrotate. This privileged command is configured using one or more files, which are specified as arguments to the logrotate logrotate command. These configuration files can contain directives to include other files as well. The default configuration file is command. These configuration files can contain directives to include other files as well. The default configuration file is /etc/logrotate.conf /etc/logrotate.conf. Example16-3 Example16-3 depicts a sample depicts a sample logrotate.conf logrotate.conf file. file.
Example16-3.Sample /etc/logrotate.conf file #globaloptions #rotatelogfilesweekly weekly #keep4weeksworthofbacklogs rotate4 #senderrorstoroot errorsroot #createnew(empty)logfilesafterrotatingoldones create #compresslogfiles compress #specificfiles /var/log/wtmp{ monthly create0664rootutmp rotate1 } /var/log/messages{ postrotate /usr/bin/killall-HUPsyslogd endscript } This example specifies rotations for two files, /var/log/wtmp /var/log/wtmp and and /var/log/messages /var/log/messages. Your configuration will be much more complete, automatically rotating all logfiles on your system. A complete understanding of logrotate logrotate configuration is not necessary for LPIC Level 1 Exams, but you must be familiar with the concepts involved. See the configuration is not necessary for LPIC Level 1 Exams, but you must be familiar with the concepts involved. See the logrotate logrotate manpages for more information. manpages for more information.
Examining Logfiles You can learn a lot about the activity of your system by reviewing the logfiles it creates. At times, it will be necessary to debug problems using logged information. Since most of the logfiles are plain text, it is very easy to review their contents with tools such as tail tail, less less, and grep grep.
Syslogd stores the messages it creates with the following information, separated by (but also including) s.p.a.ces: stores the messages it creates with the following information, separated by (but also including) s.p.a.ces: Date/time Origin hostname Message sender (such as kernel kernel, sendmail sendmail, or a username) Message text Typical messages will look like this: Aug318:45:16moyakernel:Part.i.tioncheck: Aug318:45:16moyakernel:sda:sda1sda2sda3 Aug318:45:16moyakernel:Freeingunusedkernelmemory:116kfreed Aug318:45:16moyakernel:AddingSwap:1044216kswap-s.p.a.ce(priority-1) In this case, moya moya is the hostname, and the messages are coming from the kernel. At any time, you can review the entire contents of your logfiles using is the hostname, and the messages are coming from the kernel. At any time, you can review the entire contents of your logfiles using less less: #less/var/log/messages You can then page through the file. This is a good way to become familiar with the types of messages you'll see on your system. To actively monitor the output to your messages file, you could use tail tail: #tail-f/var/log/messages This might be useful, for example, to watch system activity as an Internet connection is established via modem. To look specifically for messages regarding your mouse, you might use grep grep: #grep'[Mm]ouse'/var/log/messages Dec800:15:28smpkernel:DetectedPS/2MousePort. Dec810:55:02smpgpm:Shuttingdowngpmmouseservices: Often, if you are using grep grep to look for a particular item you expect to find in to look for a particular item you expect to find in /var/log/messages /var/log/messages, you will need to search all of the rotated files with a wildcard. For example, to look for all messages from sendmail sendmail, you can issue a command like this: #grep'sendmail:'/var/log/messages* Or, if you've enabled compression for the rotated logfiles: #zgrep'sendmail:'/var/log/messages* When you note problems in logfiles, look at the hostname and sender of the message first, and then the message text. In many cases, you will be able to determine what is wrong from the message. Sometimes the messages are only clues, so a broader review of your logs may be necessary. In this case, it may be helpful to temporarily turn on more messaging by using the debug level in /etc/syslog.conf /etc/syslog.conf to help yield additional information that can lead you to the problem. to help yield additional information that can lead you to the problem. On the ExamIf you're not yet familiar with syslogd syslogd, spend some time with it, modifying /etc/syslog.conf /etc/syslog.conf and directing messages to various files. An understanding of and directing messages to various files. An understanding of syslogd syslogd is critical because so many programs depend on it. It is also the first place to look when troubleshooting problems you are having with your system. is critical because so many programs depend on it. It is also the first place to look when troubleshooting problems you are having with your system. Chapter17.Mail Transfer Agent (MTA) Basics (Topic 108.3) Mail Transfer Agents (MTAs) are a crucial part of an Internet-enabled system. The delivery and sending of email has been a key part of the Internet since its inception. For the LPI 102 exam, you must be familiar with the common MTAs available on modern Linux distributions, and some basic configuration of each. MTAs are complicated programs, but the LPI 102 exam will only question you on the basics. This chapter covers Objective 3 of Topic 108: Objective 3: Mail Transfer Agent (MTA) Basics Candidates should be aware of the commonly available MTA programs and be able to perform basic forward and alias configuration on a client host. Other configuration files are not covered. Weight: 3. Objective 3: Mail Transfer Agent (MTA) Basics The four main MTAs commonly available on Linux systems are sendmail, postfix, qmail, and exim. Each has its own differences, mainly with regard to the format of configuration files. Each MTA performs the basic functions of a mail transfer agent: the sending and receiving of Internet mail. Sendmail Sendmail was one of the first MTAs used on Unix systems. It was derived from the original program "delivermail," which s.h.i.+pped with an early version of BSD Unix in 1979. Sendmail has grown over the years into quite a complicated program-as evidenced by the O'Reilly book sendmail, Fourth Edition, which weighs in at a whopping 1,312 pages-and is often quite challenging to configure correctly. That fact, combined with the history of security vulnerabilities that have plagued sendmail over the years, has caused its popularity to decrease over the last decade. Although most major Linux distributions provide a package for sendmail, none of them currently s.h.i.+p with sendmail as the default MTA. Postfix Postfix was originally designed in the late 1990s as a more secure alternative to sendmail. It shares many of the same configuration options as sendmail, but does not share any code. At the time of this writing, postfix is currently very popular in the Linux world, and is the default MTA s.h.i.+pped with the most popular Linux distributions. Qmail In response to the increasing number of security incidents involving MTAs, qmail was developed in the mid 1990s to be as secure as a mail transfer agent can be. Qmail is small, efficient, and secure, making it a popular choice for resource-strapped systems. However, qmail has not been actively developed since 1997, and its lack of support for modern options such as IPv6 has limited its usefulness. Qmail still enjoys an active following, but is not commonly seen on newer Linux distributions. Exim Exim is another example of an MTA that was developed in direct response to the security issues with sendmail. For this reason, it is essentially a drop-in replacement for sendmail. It is designed to be a general-purpose mailer for Unix-like systems, and is widely used in relatively high-volume environments. It was originally written in 1995 and still enjoys active development to this day. Exim is currently the default MTA for the Debian GNU/Linux distribution. Configuration of Sendmail The overall configuration of sendmail is beyond the scope of this book and the LPI 102 test. We will instead focus on email address aliasing and mail forwarding, in addition to monitoring logfiles and basic troubleshooting. Sendmail is a monolithic tool, with a single binary handling the sending and receiving of Internet email. For the purposes of this chapter, we will a.s.sume Simple Mail Transport Protocol (SMTP) email, but sendmail supports many other types of mail relaying. By default, sendmail will listen for an incoming SMTP connection (on TCP port 25). When a connection is received, sendmail starts the SMTP conversation and accepts the email. It checks addresses and domains for validity, honors aliasing and mail forwards, and then hands the mail off to a local delivery agent for local processing. Sendmail logs all activity through the syslog syslog service, which is normally configured to store mail-related logs in the file service, which is normally configured to store mail-related logs in the file /var/log/maillog /var/log/maillog. Here is an example of verifying a sendmail instance and sending a test mail. #netstat-anpl--tcp|grepsendmail tcp00127.0.0.1:250.0.0.0:*LISTEN 1847/sendmail:acceptingconnections #ls-l/var/spool/mail/adamh -rw-rw----1adamhmail02009-04-2401:23/var/spool/mail/adamh #echo"Thisisatestemail"|mailadamh #ls-l/var/spool/mail/adamh -rw-rw----1adamhmail6892010-02-0713:21/var/spool/mail/adamh #tail/var/log/maillog Feb713:22:42serversendmail[5387]:o17JMgbM005387:from=root, size=32,cla.s.s=0,nrcpts=1,msgid=<201002071922.o17jmgbm005387 @server="">,[email protected] Feb713:22:42serversendmail[5388]:o17JMghc005388: from= Feb713:22:42serversendmail[5387]:o17JMgbM005387:to=adamh, ctladdr=root(0/0),delay=00:00:00,xdelay=00:00:00,mailer=relay, pri=30032,relay=[127.0.0.1][127.0.0.1],dsn=2.0.0,stat=Sent (o17JMghc005388Messageacceptedfordelivery) Feb713:22:42serversendmail[5389]:o17JMghc005388: to= Thisisatestemail In this example, we verified that sendmail was listening on TCP port 25, and we used the standard Linux command mail mail to send an email address through sendmail. Sendmail saves mail to to send an email address through sendmail. Sendmail saves mail to /var/spool/mail/ /var/spool/mail/$username by default, so we saw the size of by default, so we saw the size of /var/spool/mail/adamh /var/spool/mail/adamh increase from 0 bytes to 689 bytes. Viewing this file shows us the mail header information that sendmail stores in this file, which is in "mbox" format. Finally, we saw what mail logging looks like by examining the file increase from 0 bytes to 689 bytes. Viewing this file shows us the mail header information that sendmail stores in this file, which is in "mbox" format. Finally, we saw what mail logging looks like by examining the file /var/log/maillog /var/log/maillog. The mail mail command can be used to both send mail and read mail that is stored in mbox format. The easiest way to send mail is by piping it to the command can be used to both send mail and read mail that is stored in mbox format. The easiest way to send mail is by piping it to the mail mail command, as shown in the previous example. The command, as shown in the previous example. The mail mail command has many other options, and is a useful command to have in your a.r.s.enal. This command is not sendmail-specific, and is designed to work with any standards-compliant MTA. command has many other options, and is a useful command to have in your a.r.s.enal. This command is not sendmail-specific, and is designed to work with any standards-compliant MTA. Configuration of Postfix Postfix was created as a replacement for sendmail, and therefore it maintains a mostly "sendmail-compatible" interface. In most cases, postfix can act as a drop-in replacement for sendmail, and scripts that had called sendmail directly with various command-line options will continue to work. Postfix accomplishes this by including with its distribution a program called /usr/sbin/sendmail /usr/sbin/sendmail, which exists to act as a "bridge" between calls to sendmail and the postfix utility. Because of this, many of the commands you are used to in sendmail will work with postfix: #whichsendmail /usr/sbin/sendmail #forfilein/usr/sbin/sendmail/usr/bin/mailq/usr/bin/newaliases;{echo-n "$file:"&&rpm-q--whatprovides${file};} /usr/sbin/sendmail:postfix-2.3.2-32 /usr/bin/mailq:postfix-2.3.2-32 /usr/bin/newaliases:postfix-2.3.2-32 The postfix system is made up of a number of different applications, as opposed to the monolithic nature of sendmail. The main program is /usr/lib/postfix/master /usr/lib/postfix/master, which is the daemon that listens on TCP port 25 for incoming SMTP connections and accepts mail. Other applications are listed in Table17-1 Table17-1. These applications live in /usr/lib/postfix/ /usr/lib/postfix/ unless otherwise indicated. unless otherwise indicated. Table17-1.Postfix programs Program name Description anvil Maintains statistics about client connection counts or client request rates. This information can be used to defend against clients that hammer a server with either too many simultaneous sessions or too many successive requests within a configurable time interval (hence the name "anvil"). Run by the Postfix master server. bounce Maintains per-message log files with delivery status information. Run by the Postfix master server. cleanup Processes inbound mail, inserts it into the incoming mail queue, and informs the queue manager of its arrival. discard Processes delivery requests from the queue manager that should be discarded. error Processes delivery requests from the queue manager that should be logged as errors. flush Maintains a record of deferred mail by destination. lmtp Implements the SMTP and LMTP mail delivery protocols to deliver mail. local Processes delivery requests from the queue manager that should be delivered locally. pickup Moves mail from the maildrop directory to the cleanup process. directory to the cleanup process. pipe Handles delivery of mail to an external command. proxymap Handles lookup tables between the postfix programs. qmgr Waits for incoming mail from the master server and hands it to the delivery process. qmqpd Daemon for the "Quick Mail Queueing Protocol." Designed to be a centralized mail queue for a number of hosts. This prevents having to run a full-blown mail server on each and every host. scache Maintains a shared multisession cache that can be used by the different postfix programs. showq Emulates the sendmail mailq command. command. smtp Alias for lmtp. smtpd The actual process that handles incoming mail. Can be run as a standalone process instead of being called by the master program. sp.a.w.n Postfix version of inetd. tlsmgr Handles caching of TLS connections. trivial-rewrite Handles address rewriting and domain resolving before mail is delivered. verify Email address verification. virtual Handles virtual domain name mail hosting. /usr/bin/newaliases Backward-compatible with the sendmail newaliases command. Converts the text file command. Converts the text file /etc/aliases /etc/aliases into a binary file that is parsable by postfix. into a binary file that is parsable by postfix. Configuration of Qmail Qmail is similar to postfix in that it was designed as a sendmail replacement and is a collection of smaller programs instead of one large one. The design goal behind Qmail is security, so often the smaller programs will run as lower-privileged users. Some of the more common Qmail programs are listed in Table17-2 Table17-2. Table17-2.Qmail programs Program name Description tcpserver Listens for incoming TCP connections and hands them off to the appropriate program. Similar to inetd or or xinetd xinetd. qmail-smtpd Handles incoming email. qmail-inject Injects outgoing email into the mail queue. qmail-send Delivers mail messages currently in the queue. qmail-queue Formats mail correctly and places it in the queue for delivery. qmail-lsp.a.w.n Invokes qmail-local to handle local delivery. to handle local delivery. qmail-rsp.a.w.n Invokes qmail-remote to handle remote delivery. to handle remote delivery. qmail-local Delivers email locally. qmail-remote Delivers email remotely. qmail-qmqpd Receives mail via the Quick Mail Queueing Protocol and invokes qmail-queue to put mail in the outgoing queue. to put mail in the outgoing queue. qmail-qstat Summarizes the current contents of the mail queue. qmail-qread Lists messages and recipients of emails in the outgoing queue. qmail-tcpto Lists hosts that have timed out on mail delivery attempts. qmail-tcpok Clears the host timeout list. qmail-showctl a.n.a.lyzes the current qmail configuration files and explains the setup. qmail-start A wrapper program that starts qmail-send, qmail-lsp.a.w.n qmail-lsp.a.w.n, qmail-rsp.a.w.n qmail-rsp.a.w.n, and qmail-clean qmail-clean with the appropriate user IDs so mail delivery can happen. with the appropriate user IDs so mail delivery can happen. Qmail also handles sendmail compatibility in ways similar to postfix. Qmail comes with the program /var/qmail/bin/sendmail /var/qmail/bin/sendmail, which is designed to take the same command-line options that sendmail takes and pa.s.s them to qmail. The program dot-forward dot-forward is used to read a user's is used to read a user's .forward .forward file, and the program file, and the program fastforward fastforward will read the sendmail will read the sendmail /etc/aliases /etc/aliases file. More information on qmail can be found at the file. More information on qmail can be found at the author's site. Configuration of Exim Exim, like postfix and qmail, was designed to be a sendmail replacement. Therefore, it has helper programs and supports command-line options to enable a smooth transition from sendmail. Exim is monolithic like sendmail, in that the exim program handles the acceptance of email on TCP port 25 and the delivery of mail. There are a number of helper programs that come with exim, however. Some of the more common ones are listed in Table17-3 Table17-3. Table17-3.Exim programs Program name Description /usr/bin/mailq.exim Drop-in replacement for sendmail's mailq command. command. /usr/bin/newaliases.exim Drop-in replacement for sendmail's newaliases command. command. /usr/bin/runq.exim Alias for /usr/sbin/exim. Running this command is the same as running exim q exim q. This forces a single run through the mail queue, attempting a resend on every item. /usr/lib/sendmail.exim Handles sendmail command-line options and pa.s.ses them to exim. /usr/sbin/exim The main exim binary, this process listens on TCP port 25 for incoming SMTP connections and hands incoming mail to the local delivery agent. /usr/sbin/eximstats Generates statistics from exim mainlog or or syslog syslog files. files. /usr/sbin/exiwhat Describes what the exim process is currently doing. /usr/sbin/exinext Gives specific information about retry efforts for an email address. /usr/sbin/exipick Displays individual messages from the exim mail queue.