Running Linux phần 10 pdf

Chapter 16. The World Wide Web and Electronic Mail 527 16.2.1.1 A word about DNS Before setting up Postfix, you should understand that if your system is going to receive mail from others across the Internet, the DNS for your domain has to be configured correctly. DNS is discussed in Chapter 15. Let's assume for this discussion that you are configuring a host called halo in the domain example.org and that you have a user account michael on your system. Regardless of how you want to receive mail, your host halo.example.org must have a DNS A record that maps its hostname to its IP address. In this example your email address is going to be either michael@halo.example.org or michael@example.org. If you want to use the first form, configuring the DNS A record is enough for messages to reach you. If your system is going to receive all mail for example.org (michael@example.org), the domain should have a DNS MX record pointing to your host halo.example.org. If you are configuring the DNS for your domain yourself, make sure you read the documentation to understand how it works; otherwise, speak to your DNS administrator or ISP about routing mail to your system. Postfix frequently uses DNS in its normal operation, and it uses the underlying Linux libraries to perform its DNS queries. Make sure your system is configured correctly to perform DNS lookups (see Section 15.2.1.6 in Chapter 15). Postfix usually has to find an MX record to make its deliveries. Don't assume that if Postfix reports a DNS problem with an address, and you find that the domain resolves correctly, that email delivery should succeed. If Postfix reports a problem, you can be almost certain there is a problem. 16.2.1.2 Installing Postfix Although prepackaged distributions are available, you may want to build the package yourself if you want to use any of the add-on libraries or functions that are not included in your distribution. You might also want to get the latest version to obtain a new feature that has not yet been included in your distribution. Before you install Postfix, be aware that it includes the three commands /usr/bin/newaliases, /usr/bin/mailq, and /usr/sbin/sendmail that are normally used by Sendmail. Postfix provides replacements that work with the Postfix system rather than with Sendmail. You should rename your existing Sendmail commands so that the Postfix installation doesn't overwrite them in case you ever want to use the original Sendmail binaries again: # mv /usr/bin/newaliases /usr/bin/newaliases.orig # mv /usr/bin/mailq /usr/bin/mailq.orig # mv /usr/sbin/sendmail /usr/sbin/sendmail.orig Postfix uses Unix database files to store its alias and lookup table information. You must, therefore, have the db3 libraries installed on your system before building Postfix. These libraries are contained within the db3-devel RPM package or the Debian libdb3 package. If you are not using a package manager, you can obtain them directly from Sleepycat Software (http://www.sleepycat.com/). If you are using RPM, execute the following command to see if the necessary libraries have been installed on your system: Chapter 16. The World Wide Web and Electronic Mail 528 # rpm -qa | grep db3-devel db3-devel-3.2.9-5 You should see a line similar to the second line in the preceding command that displays the db3-devel package with a version number. If rpm returns nothing, you must install the libraries before installing Postfix. On Debian, you can use dpkg to see if the libraries are installed. # dpkg -l libdb3 If you download a prepackaged Postfix, use your package manager (described in Chapter 7) to install it. If you download the source postfix-1.1.11.tar.gz, move that file to a suitable directory (such as your home directory) to unpack it. The numbers in the name of the file represent the version of this release. Your file may have different numbers depending on the current release when you download it. Follow this basic procedure to build Postfix. Note that you'll have to be the root user to create the user and group and to install the package. 1. Rename your Sendmail binaries as described earlier. 2. Create a user account called postfix and a group called postdrop. See Section 5.7 for information on setting up accounts and groups. 3. Run gunzip on the compressed file to produce a file named postfix-1.1.11.tar. 4. Execute: tar -xvf postfix-1.1.11.tar to unpack the source into a directory called postfix-1.1.11. 5. Move to the directory created when you unpacked the file. You'll find a file called INSTALL with detailed instructions about building your Postfix system. In most cases, building Postfix should be as simple as typing make in the directory. 6. If your build completes without any errors, type make install to install Postfix on your system. You should be able to accept all the defaults when prompted by the installation script. After installation, you will have Postfix files in the following directories: /usr/libexec/postfix This directory contains the various Postfix daemons. Postfix uses a split architecture in which several discrete programs handle separate tasks. The master daemon is started first. It deals with starting other programs as they are needed. For the most part, you don't need to worry about any of the programs here. Stopping and starting Postfix is handled with the postfix command found in the /usr/sbin directory. Chapter 16. The World Wide Web and Electronic Mail 529 /etc/postfix Typically this directory contains dozens of Postfix configuration files, but only master.cf and main.cf and a few lookup tables are used by Postfix. The rest of the files are examples that document the various parameters used for configuration. The master.cf file controls the various Postfix processes. It includes a line for each component of Postfix. The layout of the file is described by comments in the file itself. Usually, you shouldn't have to make any changes to run a simple Postfix installation. The main.cf file is the global SMTP configuration file. It includes a list of parameters set to one or more values using the format: parameter = value Comments are marked with a hash mark (#) at the beginning of the line. You cannot put comments on the same line as parameters. Commented lines can begin with whitespace (spaces or tabs), but they must appear on lines by themselves. Multiple values for parameters can be separated by either commas or whitespace (including newlines), but if you want to have more than one line for a parameter, start the second and subsequent lines with whitespace. Values can refer to other parameters by preceding the parameter name with a dollar sign ( $ ). Here's an example of an entry that includes comments, multiple lines, and a parameter reference: # Here are all the systems I accept mail from. mynetworks = $myhostname 192.168.75.0/24 10.110.12.15 /usr/sbin All the Postfix commands are located in /usr/sbin and have names starting with post. There are commands to create index files, manage the mail queue and otherwise administer your Postfix system. The postfix command, which is used to stop and start Postfix (described later), is found here. /var/spool/postfix The Postfix queue manager is an important component of the Postfix system that accepts incoming email messages and arranges with other Postfix components to deliver them. It maintains its files under the /var/spool/postfix directory. The queues it maintains are shown next. Postfix provides several tools to manage the queues, such as postcat, postsuper, and mailq, but you might also use the usual Linux commands, such as find and cat to inspect your queue. /var/spool/postfix/incoming All incoming messages, whether from over the network or sent locally. Chapter 16. The World Wide Web and Electronic Mail 530 /var/spool/postfix/active Messages that the queue manager is delivering or preparing to deliver. /var/spool/postfix/deferred Messages that could not be delivered immediately. Postfix will attempt to deliver them again. /var/spool/postfix/corrupt Messages that are completely unreadable or otherwise damaged and not deliverable. They are stored here for you to look at if necessary to figure out the problem. This queue is rarely used. /usr/local/man Postfix installs documentation in the form of manpages on your system. The documentation includes information on command-line utilities, daemons, and configuration files. As mentioned earlier, Postfix also installs replacements for /usr/bin/newaliases, /usr/bin/mailq, and /usr/sbin/sendmail. 16.2.1.3 Postfix configuration Before you start Postfix for the first time, you have to make sure that the aliases table is formatted correctly and that a few of the critical configuration parameters are set correctly for your system. Historically Sendmail has used the file /etc/aliases to map one local username to another. Postfix continues the tradition. The /etc/aliases file is a plain-text file that is used as input to create an indexed database file for faster lookups of aliases on your system. There are at least two important aliases on your system that must be set in your /etc/aliases file. If you have been running Sendmail on your system, these aliases are probably already set correctly, but make sure your file has entries for root and postmaster pointing to a real account that receives mail on your system. Once you have verified the aliases, execute the command newaliases to rebuild the index file in the correct format for Postfix. The /etc/postfix/main.cf file contains many parameters, but there are just a few important ones that you should verify before starting Postfix; we'll explain these in this section. If you installed Postfix from a prepackaged distribution, these parameters might already be set correctly. It's also possible that the Postfix defaults work for your system, but edit your /etc/postfix/main.cf file to make sure. myhostname This is the fully qualified hostname for your system. By default, Postfix uses the name returned by the gethostname function. If this value is not fully qualified, and you have not set this parameter, Postfix will not start. You can check it by executing the Chapter 16. The World Wide Web and Electronic Mail 531 command hostname. It's probably a good idea to specify your fully qualified hostname here explicitly: myhostname = halo.example.org mydomain Specifies the domain name for this system. This value is then used as the default in other places. If you do not set it explicitly, Postfix uses the domain portion of myhostname. If you have set myhostname as shown previously and example.org is correct for your system, you do not have to set this parameter. mydestination Specifies a list of domain names for which this system should accept mail. In other words, you should set the value of this parameter to the domain portions of email addresses for which you want to receive mail. By default, Postfix uses the value specified in myhostname. If you are setting up your system to accept mail for your entire domain, specify the domain name itself. You can use the variables $myhostname and $mydomain as the value for this parameter: mydestination = $myhostname $mydomain myorigin This parameter is used to append a domain name to messages sent locally that do not already include one. For example, if a user on your system sends a message with only the local username in the From: address, Postfix appends this value to the local name. By default, Postfix uses myhostname , but if your system is handling mail for the entire domain, you might want to specify $mydomain instead: myorigin = $mydomain Some Linux distributions that already include Postfix configure it to use procmail by default. procmail is a separate mail delivery agent (MDA) that can filter and sort mail as it makes deliveries to individual users on your system. If you need the features it provides, you should study the procmail documentation carefully to understand how it interacts with Postfix. For many systems, which don't filter mail for users at the MTA level, procmail is an unnecessary additional layer of complexity because Postfix can also make local deliveries and provide some of the same functions. Your distribution might be configured to use procmail in either the mailbox_command or mailbox_transport parameters. If you want Postfix to handle local deliveries directly, you can safely comment out either of these parameters in your /etc/postfix/main.cf file. 16.2.1.4 Starting Postfix Once you have verified the important configuration parameters described earlier and rebuilt your aliases index file, you are ready to start Postfix. As the superuser, execute: postfix start You can stop Postfix by executing: Chapter 16. The World Wide Web and Electronic Mail 532 postfix stop Whenever you make changes to either of Postfix's configuration files, you must reload the running Postfix image by executing: postfix reload Once you have Postfix running, all the users on your system should be able to send and receive email messages. Any of your applications that depend on Sendmail should still work, and you can use the sendmail command as you always did. You can pipe messages to it from within scripts and execute sendmail -q to flush the queue. The native Postfix equivalent for flushing the queue is postfix flush . Options to Sendmail that deal with it running as a daemon and setting queue delays do not work because those functions are not handled by the sendmail command in Postfix. All the Postfix options are set in its two configuration files. Many parameters deal with the Postfix queue. You can find them in the manpage for qmgr(8). 16.2.1.5 Postfix logging After starting or reloading Postfix, you should check the log to see if Postfix reports any problems. (Most Linux distributions use /var/log/maillog, but you can also check the file /etc/syslog.conf to be sure.) You can see Postfix's most recent messages by running the command tail /var/log/maillog. Since Postfix is a long-running process, it's a good idea to check the log periodically even if you haven't been restarting it. You can execute the following to see if Postfix has reported anything interesting while running: egrep '(reject|warning|error|fatal|panic):' /var/log/maillog In general, Postfix keeps you informed of what is going on with your system by logging lots of good information to syslogd. On Linux syslogd uses synchronous writes by default, which means that after every write to the log file, there is also a sync to force everything in memory to be written to the disk. Therefore, the performance of Postfix (and other processes) can suffer. You can change this default by preceding the name of the log file with a hyphen in /etc/syslog.conf. Your entry in syslog.conf for mail logging should look like the following: mail.* -/var/log/maillog Be sure to have syslogd reread its configuration file after you make any changes. You can execute killall -HUP syslogd to reinitialize it. 16.2.1.6 Running Postfix on system startup Because of Postfix's compatibility with Sendmail, if you have your system configured to start Sendmail at system initialization, more than likely Postfix will start correctly when your system boots. However, system shutdown will probably not work correctly. Most Linux distributions shut down Sendmail by locating a process called sendmail and then killing that process. The Postfix processes, while in many ways compatible with Sendmail, do not run under the name sendmail, so this shutdown fails. Chapter 16. The World Wide Web and Electronic Mail 533 If you would like your system to shut down cleanly, you should create your own rc script for Postfix, as described in Chapter 5. The commands you need to include in your script to start and stop Postfix are exactly the same as those you execute on the command line, postfix start and postfix stop. Here's an example of a basic script to get you started. You may want to review other rc scripts on your system to see if you should add more system checks or follow other conventions and then make your adjustments to this example: #!/bin/sh PATH="" RETVAL=0 if [ ! -f /usr/sbin/postfix ] ; then echo "Unable to locate Postfix" exit 1 fi if [ ! -f /etc/postfix/main.cf ] ; then echo "Unable to locate Postfix configuration" exit 1 fi case "$1" in start) echo -n "Starting Postfix: " /usr/sbin/postfix start > /dev/null 2>1 RETVAL=$? echo ;; stop) echo -n "Stopping Postfix: " /usr/sbin/postfix stop > /dev/null 2>1 RETVAL=$? echo ;; restart) echo -n "Restarting Postfix: " /usr/bin/postfix reload > /dev/null 2>1 RETVAL=$? echo ;; *) echo "Usage: $0 {start|stop|restart}" RETVAL=1 esac exit $RETVAL Place this script in /etc/rc.d/init.d or /etc/init.d, depending on your Linux distribution. Then make the appropriate symlinks in each of the rc N .d directories for each runlevel in which Postfix should start (see Section 5.3.2). For example, if you want to have Postfix start at runlevels 3 and 5 and stop at runlevels 0 and 6, create symlinks like those that follow for RedHat. For Debian the rc N.d directories are directly below /etc: # cd /etc/rc.d/rc3.d # ln -s /init.d/postfix S97postfix # cd /etc/rc.d/rc5.d # ln -s /init.d/postfix S97postfix # cd /etc/rc.d/rc0.d # ln -s /init.d/postfix K97postfix # cd /etc/rc.d/rc6.d # ln -s /init.d/postfix K97postfix Chapter 16. The World Wide Web and Electronic Mail 534 If you create a Postfix rc script, you should configure your system not to start Sendmail at startup. 16.2.1.7 Postfix relay control The default installation allows any system on the same subnet as yours to relay mail through your mail server. If you want to override the default, you can set the parameter mynetworks to be a list of hosts or networks that you trust to relay mail through your system. You can specify a list of IP addresses or network/netmask patterns, and any connecting SMTP client that matches will be allowed to relay mail. You can list network or IP addresses that reside anywhere. So, for example, if you want to be able to relay mail through your home Postfix system from your work machine, you can specify the IP address of your machine at work in your home Postfix configuration. Here's an example that allows mail from the local subnet (192.168.75.0/28) and a single host located elsewhere: mynetworks = 192.168.75.0/28 10.150.134.15 If you want to allow relaying for mobile users that do not have static IP addresses, you have to use some kind of SMTP authentication mechanism. Postfix can work with SASL Authentication (which requires that Postfix be compiled with additional libraries, and that users' client software be specially configured) and pop-before-smtp (which requires a POP server running on the same system to first authenticate users). It is important not to open relay access to anyone except users you trust. In the early days of the Internet, open relays were commonplace. Unfortunately the current prevalence of spam has precluded that kind of freedom. If your MTA is not protected, you leave yourself and other Internet systems vulnerable to abuse. Spammers constantly scan for open relays, and if you place one on the network, it is only a matter of time before it will be found. Fortunately, the default Postfix installation behaves correctly. However, if you make lots of changes to your Postfix configuration (especially in setting up antispam controls, ironically), you may inadvertently open yourself up to relay abusers. If you want your own Postfix installation to relay mail through another MTA, specify the IP address of the relay server using the relayhost parameter. Postfix normally figures out where to deliver messages on its own, based on the destination address. However, if your system is behind a firewall, for example, you may want Postfix to hand off all messages to another mail server to make the actual delivery. When you specify a relay server, Postfix normally performs a DNS query to obtain the mail exchanger (MX) address for that system. You can override this DNS lookup by putting the hostname in square brackets: relayhost = [mail.example.org] 16.2.1.8 Additional configurations The configuration described here creates a simple Postfix installation to send and receive messages for users on your system. But Postfix is an extremely flexible MTA with many more configuration options, such as hosting multiple virtual domains, maintaining mailing lists, blocking spam, and virus scanning. The manpages, HTML files, and sample Chapter 16. The World Wide Web and Electronic Mail 535 configuration files that come with Postfix contain a lot of information to guide you in the more advanced configurations. 16.2.2 Getting the Mail to Your Computer with Fetchmail If your provider stores your mail for you until you fetch it, and you do not want to use your mailer to download the mail, you need a program that retrieves the mail from your provider's computer. There are a lot of programs for doing this; we will discuss fetchmail here briefly because it is both robust and flexible and can handle both POP3 and IMAP. You can get fetchmail from your friendly Linux archive; chances are that your distribution carries it, too. In case you download a source distribution of fetchmail, unpack, build, and install it according to the installation instructions. At the time of this writing, the current version is 5.9.13. You can control fetchmail's behavior via both command-line options and a configuration file. It is a good idea to first try to fetch your mail by passing the necessary information on the command line, and when this works, to write the configuration file. As an example, let's assume that my provider is running the POP3 protocol, that my username there is joeuser, and that my password is secret . The hostname of the machine where the POP3 server is running is mail.isp.com. I can then retrieve my mail with the following command: fetchmail protocol POP3 username joeuser mail.isp.com fetchmail then asks me for my password and, after I specify it correctly, retrieves the mail waiting for me and passes it on to my MTA for further delivery. This assumes that a SMTP server is running on port 25 of my machine, but this should be the case if I have set up my MTA correctly. While you are experimenting with fetchmail, it might be a good idea to also specify the option — keep. This prevents fetchmail from deleting the messages from your POP3 account. Normally, all messages are deleted from your provider's hard disk once they are safely stored on your own machine. This is a good thing because most providers limit the amount of mail you can store on their machines before retrieving them, and if you don't delete the messages after fetching them, you might reach this limit quite quickly. On the other hand, while testing, it is a good idea to be on the safe side and use — keep so as not to lose any mail. With the aforementioned options to fetchmail, you should be able to get your mail in most cases. For example, if your provider uses the newer IMAP protocol, simply specify IMAP in the command line instead of POP3 . If your provider has some unusual setup, you might need one of the other options that the fetchmail(1) manual page tells you about. Once you are satisfied with the download process, you can write a fetchmail configuration file in order not to have to enter all the options each time you use the command. This configuration file is called .fetchmailrc and should reside in your home directory. Once you are done editing it, make sure it has the permission value 0600 so that nobody except yourself can read it because this file might contain your password: Chapter 16. The World Wide Web and Electronic Mail 536 chmod 0600 ~/.fetchmailrc The full syntax of the configuration file is detailed in the fetchmail manpage, but in general you need only very simple lines that start with poll. To specify the same data as on the command line in the previous example, but this time include the password, put the following line into your configuration file: poll mail.isp.com protocol pop3 username joeuser password secret Now you can run fetchmail without any parameters. Since fetchmail already knows about your password from the configuration file, it will not prompt you for it this time. If you want to play it safe while testing, add the word keep to the poll line. Using fetchmail with a configuration file has one additional advantage: you can fetch mail from as many mailboxes as you want. Just add more poll lines to your .fetchmailrc, and fetchmail happily retrieves your mail from one server after the other. When and how you run fetchmail depends on your connection to the Internet. If you have a permanent connection or a cheap, flat rate, you might want to have fetchmail invoked by cron at a suitable interval (like once an hour). However, if your Internet connection is nonpermanent (dial-up) and costly, you might want to choose to run fetchmail by hand whenever you actually want to fetch and read your mail so as to minimize your Internet connection time. Finally, if you are using PPP for dialing in to your Internet service provider, you might want to invoke fetchmail from the ip-up script, which is invoked as soon as an Internet connection is made. With this setup, when you browse a web page and your computer dials up your provider, your mail is fetched automatically. 16.2.3 Other Email Administrative Issues In this section we describe tasks, services, and some additional utilities involved in managing your electronic mail system. You should normally use only one Internet host to get all your mail. It is possible to use a more complex arrangement, but this is frowned upon because of the possibility of setting up loops — virtual Sargasso Seas of lost network information. Loops can route mail in circles, passing over and over through the same machines until they "time out" by exceeding the limit on the number of machines they can pass through. 16.2.3.1 Registering an address If you want to get your mail directly from the Internet, you need to register an Internet domain name for your system. Please see Section 16.2.1.1 for more information about this. 16.2.3.2 Mail system maintenance You should set up a cron task to occasionally check the mail queue (usually /var/spool/mqueue) and force an attempt to deliver mail that wasn't previously delivered for some reason. Mail can be queued because a host is temporarily unreachable, or a filesystem is full, or for myriad other little reasons. cron is discussed in Section 8.2. [...]... designers are in control, so dynamic content is what we are going to talk about in this chapter Linux is — you guessed it — an excellent platform for serving dynamic content A bazillion web sites serving dynamic content are already running on Linux today; this is one of the foremost application areas where Linux excels Dynamic content can be achieved by two entirely different ways of programming: server-side... filtering, which are described later in this chapter 17.2.2 Top 10 Things You Should Never Do We've made the claim that security is mostly common sense, so what is this common sense? In this section we summarize the most common security mistakes (There aren't actually 10 items in this list, but there are enough to merit the use of the common "top 10" phrase.) Consistently avoiding them all is harder work... software on your system fairly current That Linux kernel 1.2 system you have running in the corner that's been reliably serving your printers for years might be a great subject at cocktail parties, but it's probably a security incident waiting to happen Keeping the software on your system up-to-date helps ensure that all bug and security fixes are applied Most Linux distributions provide a set of packages... daemons running on your system If you absolutely need a service running on your machine (such as the X server!), find ways of preventing connections to that service from unwanted hosts For example, it might be safest to allow ssh connections only from certain trusted hosts, such as from machines in your local network In the case of the X server and X font server, which run on many desktop Linux machines,... selecting Tools Message Filters This concludes our discussion of using email on Linux As you can see, many options, from simple to sophisticated, are available to help you administer and digest the daily flood of email messages 541 Chapter 17 Basic Security Chapter 17 Basic Security In this chapter we'll discuss basic Linux system security Security is unfortunately a topic of ever-growing importance,... sections we'll describe netfilter and some simple configurations as examples 17.4.1 netfilter Basics netfilter is implemented in Linux kernels 2.4.0 and newer The primary tool for manipulating and displaying the filtering tables is called iptables and is included in all current Linux distributions The iptables command allows configuration of a rich and complex set of firewall rules and hence has a large... automatically SuSE Linux For a simple, albeit not as flexible, configuration, run yast2 and select the firewall configuration module Security&Users Firewall Otherwise: 1 Edit /etc/sysconfig/SuSEfirewall2 This file is thoroughly documented 2 If necessary, define custom filter rules in /etc/sysconfig/scripts/SuSEfirewall2custom This requires deeper knowledge about how firewalls work on Linux 3 Start the... -A INPUT -m state state NEW -m tcp -p tcp -s 192.168.1/24 \ dport 21 -j ACCEPT # ACCEPT new incoming FTP connections from spaghetti.vpizza.com, # which has IP address 10. 21.2.4 iptables -A INPUT -m state state NEW -m tcp -p tcp -s 10. 21.2.4 \ dport 21 -j ACCEPT # ACCEPT new incoming FTP connections from *.vpizza.com # They have two networks: 172.18.1.0 and 172.25.3.0 iptables -A INPUT -m state ... There are some very basic things you can do to protect a Linux system from the most basic security risks Of course, depending on your configuration, the ways in which you will be using your system, and so forth, they might be more involved than the simple setup described here In this section we briefly cover the basic mechanisms to secure a Linux system from the most common attacks — this is the basic... ubiquitous for implementing these techniques This combination is so common nowadays that it even has received a phony acronym: LAMP, which is short for Linux- Apache-MySQL-PHP We have been talking about the Apache web server already, and this whole book is about Linux, so what we have left to talk about here are the latter two packages — MySQL and PHP — as well as how the four go together In order to get a . reference: # Here are all the systems I accept mail from. mynetworks = $myhostname 192.168.75.0/24 10. 110. 12.15 /usr/sbin All the Postfix commands are located in /usr/sbin and have names starting. of Postfix's configuration files, you must reload the running Postfix image by executing: postfix reload Once you have Postfix running, all the users on your system should be able to send. problems. (Most Linux distributions use /var/log/maillog, but you can also check the file /etc/syslog.conf to be sure.) You can see Postfix's most recent messages by running the command