Fedora iTOps Tube

Monday, July 11, 2011

Using chkconfig to Improve Security

A default Fedora installation automatically starts a number of daemons that you may not necessarily need for a Web server. This usually results in your system listening on a variety of unexpected TCP/IP ports that could be used as doors into your system by hackers.

The screen output of the netstat -an command below shows a typical case. Some ports are relatively easy to recognize. TCP ports 25 and 22 are for mail and SSH, respectively, but some others are less obvious. Should you use the chkconfig command and the scripts in the /etc/init.d directory to shut these down permanently?

 [root@bigboy tmp]# netstat -an Active Internet connections (servers and established) Proto Recv-Q Send-Q Local Address           Foreign Address State tcp    0    0*     LISTEN tcp    0    0*     LISTEN tcp    0    0*     LISTEN tcp    0    0*     LISTEN tcp    0    0*     LISTEN tcp    0    0 :::22            :::*          LISTEN udp    0    0* udp    0    0* udp    0    0* udp    0    0* udp    0    0* ... ... [root@bigboy tmp]#  

For example, how do you know which startup script is responsible for TCP port 111? The answer is to use the lsof command which lists all open, or actively used, files and can be given additional options to extend its scope to include the TCP/IP protocol stack.

In the next examples we see that TCP ports 111 and 32769, and UDP port 123 are being used by the portmap, xinetd and ntp daemons respectively. The portmap daemon is required for the operation of NFS and NIS, topics that are covered in Chapters 29, "Remote Disk Access with NFS", and 30, "Configuring NIS". portmap also has many known security flaws that makes it advisable to be run on a secured network. If you don't need any of these three applications, it's best to shut down portmap permanently. NTP, which is covered in Chapter 24, "The NTP Server", is required for synchronizing your time with a reliable time source, and may be necessary. A number of network applications are reliant on xinetd, as explained in Chapter 16, "Telnet, TFTP, and xinetd", and it might be required for their operation:

 [root@ bigboy tmp]# lsof -i tcp:111 COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME portmap 1165  rpc    4u  IPv4   2979       TCP *:sunrpc (LISTEN) [root@ bigboy tmp #   [root@bigboy tmp]# lsof -i tcp:32769 COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME xinetd  1522 root    5u  IPv4   2764       TCP probe-001:32769 (LISTEN) [root@bigboy tmp]#   [root@bigboy root]# lsof -i udp:123 COMMAND  PID USER   FD   TYPE DEVICE SIZE NODE NAME ntpd    1321  ntp    4u  IPv4   3390       UDP *:ntp ... ... [root@bigboy root]# 

In some cases it's tricky to determine the application based on the results of the lsof command. In the example below, we've discovered that TCP port 32768 is being used by rpc.statd, but there is no rpc.statd file in the /etc/init.d directory. The simple solution is to use the grep command to search all the files for the string rpc.statd to determine which one is responsible for its operation. We soon discover that the nfslock daemon uses it. If you don't need nfslock, then shut it down permanently.

 [root@bigboy tmp]# lsof -i tcp:32768 COMMAND    PID    USER   FD   TYPE DEVICE SIZE NODE NAME rpc.statd 1178 rpcuser    6u  IPv4   2400       TCP *:32768 (LISTEN) [root@bigboy tmp]# ls /etc/init.d/rpc.statd ls: /etc/init.d/rpc.statd: No such file or directory [root@bigboy tmp]# grep -i statd /etc/init.d/* /etc/init.d/nfslock:[ -x /sbin/rpc.statd ] || exit 0 ... ... [root@bigboy tmp]# 

As a rule of thumb, applications listening only on the loopback interface (IP address are usually the least susceptible to network attack and probably don't need to be stopped for network security reasons. Those listening on all interfaces, depicted as IP address, are naturally more vulnerable and their continued operation should be dependent on your server's needs. I usually shutdown nfs, nfslock, netfs, portmap, and cups printing as standard practice on Internet servers. I keep sendmail running as it is always needed to send and receive mail (see Chapter 21, "Configuring Linux Mail Servers", for details). Your needs may be different.

Remember to thoroughly research your options thoroughly before choosing to shut down an application. Use the Linux man pages, reference books and the Internet for information. Unpredictable results are always undesirable.

Shutting down applications is only a part of server security. Firewalls, physical access restrictions, password policies, and patch updates need to be considered. Full coverage of server and network security is beyond the scope of this book, but you should always have a security reference guide on hand to guide your final decisions.

Turn On sendmail Again

To reactivate sendmail, we can use chkconfig once more, but with the on argument. Start sendmail again to get it running immediately, not just after the next reboot.

 [root@bigboy tmp]# chkconfig sendmail on [root@bigboy tmp]# chkconfig --list | grep mail sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off [root@bigboy tmp]# service sendmail start Starting sendmail: [  OK  ] Starting sm-client: [  OK  ] [root@bigboy tmp]# 

Double-check that sendmail Will Not Start Up

We can then use chkconfig to double-check our work.

 [root@bigboy tmp]# chkconfig --list | grep mail sendmail 0:off 1:off 2:off 3:off 4:off 5:off 6:off [root@bigboy tmp]# 

Switch Off sendmail Starting Up in Levels 3 and 5

The chkconfig command with the --level switch indicates that some action needs to be done at the runlevels entered as its values. The first argument in the command is the package you want to affect and the second defines whether you want it on or off. In this case we want sendmail not to be started when entering runlevels 3 and 5:

 [root@bigboy tmp]# chkconfig --level 35 sendmail off [root@bigboy tmp]# 

By not specifying the runlevels with the --level switch, chckconfig will make the changes for runlevels 3 and 5 automatically:

 [root@bigboy tmp]# chkconfig sendmail off 

Because the intention is to permanently shutdown sendmail permanently, we might also have to stop it from running now.

 [root@bigboy tmp]# service sendmail stop Shutting down sendmail: [  OK  ] Shutting down sm-client: [  OK  ] [root@bigboy tmp]# 

Using chkconfig to Start Daemons at Each runlevel

As stated earlier, the chkconfig command can be used to adjust which applications start at each runlevel. You can use this command with the --list switch to get a full listing of packages listed in /etc/init.d and the runlevels at which they will be on or off:

 [root@bigboy tmp]# chkconfig --list keytable 0:off 1:on  2:on  3:on 4:on  5:on 6:off atd      0:off 1:off 2:off 3:on 4:on  5:on 6:off syslog   0:off 1:off 2:on  3:on 4:on  5:on 6:off gpm      0:off 1:off 2:on  3:on 4:on  5:on 6:off kudzu    0:off 1:off 2:off 3:on 4:on  5:on 6:off wlan     0:off 1:off 2:on  3:on 4:on  5:on 6:off sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off netfs    0:off 1:off 2:off 3:on 4:on  5:on 6:off network  0:off 1:off 2:on  3:on 4:on  5:on 6:off random   0:off 1:off 2:on  3:on 4:on  5:on 6:off ... ... 

chkconfig Examples

You can use chkconfig to change runlevels for particular packages. Here we see sendmail will start with a regular startup at runlevel 3 or 5. Let's change it so that sendmail doesn't startup at boot.

Use Chkconfig to Get a Listing of sendmail's Current Startup Options

The chkconfig command can be used with grep to determine the run levels in which sendmail will run. Here we see it will run at levels 3 and 5.

 [root@bigboy tmp]# chkconfig --list | grep mail sendmail 0:off 1:off 2:off 3:on 4:off 5:on 6:off [root@bigboy tmp]# 

The service command

Some operating systems such as Fedora and Redhat also come with the shortcut service command which allows you to control daemons with the "start", "stop" and "restart" keywords, but with less typing. Here are some quick, intuitive examples of doing this:

 [root@bigboy ~]# service httpd start [root@bigboy ~]# service httpd stop [root@bigboy ~]# service httpd restart 

The service command also has the "status" keyword which will provide a brief report on what the daemon is doing.

 [root@bigboy ~]# service httpd status httpd (pid 6135 6133 6132 6131 6130 6129 6128 6127 1561) is running... [root@bigboy ~]# 

Restarting a Daemon

Daemons usually only read their configuration files when they are started, therefore if you edit the file, you have to restart the daemon for the new settings to become active. This can be done with the keyword "restart":

 root@u-bigboy:~# /etc/init.d/apache restart  * Restarting apache 1.3 web server...    ...done. root@u-bigboy:~# 

Don't worry about configuring your daemons. Later we'll be covering some commonly used daemons and will discuss them with ample examples.

Stopping a Daemon

Daemons can be stopped by specifying its script filename followed by the keyword "stop":

 root@u-bigboy:~# /etc/init.d/apache stop  * Stopping apache 1.3 web server...    ...done. root@u-bigboy:~# 

Starting a Daemon

If a startup script exists in the /etc/init.d directory, then its daemon can be started by specifying its filename followed by the keyword "start" as seen here:

 root@u-bigboy:~# /etc/init.d/apache start  * Starting apache 1.3 web server...    ...done. root@u-bigboy:~# 

Starting and Stopping Daemons

A simple definition of a daemon is a programs that runs unattended even when nobody is logged into your system. Common examples of daemons are the syslog daemon which receives system error messages and writes them to a log file; the apache or httpd daemon that serves web pages to Internet web browsers and thesendmail daemon that places email it receives into your inbox.

The startup scripts I have been mentioning in the /etc/init.d directory govern the activation of daemons that were installed with some of your Linux packages. The commands to start and stop them are universal.

Root Password Recovery

Sometimes you might forget the root password, or the previous systems administrator may move on to a new job without giving it to you. To do this, follow these steps:

  1. Go to the VGA console and press Ctrl-Alt-Del. The system will then shut down in an orderly fashion.
  2. Reboot the system and enter single-user mode.
  3. Once at the command prompt, change your password. Single user mode assumes the person at the console is the systems administrator root, so you don't have to specify a root username.
  4. Return to your default runlevel by using the exit command.

Reverting To Your Default runlevel From Single User Mode

The exit command forces the system to exit runlevel 1 and revert to the default runlevel for the system. You can also use the init command (for example init 3 and init 5) to alter this default behavior:

 bash-2.05b# exit INIT: Entering runlevel: 3 ... ... ... Fedora Core release 2 (Tettnang) Kernel 2.6.8-1.521 on an i686 bigboy login: 

Entering Single-user Mode At The Grub Splash Screen

You can enter single user mode directly after turning on the power to your system. The steps to do this are listed below.

1. Power on your system. Wait for the "Grub loading" message to appear and, depending on your Linux distribution, get ready to hit either any key or the ESC key to enter the grub boot menu.

 Grub loading, please wait ... Press ESC to enter the menu 


 Grub loading, please wait ... Press any key to enter the menu 

2. You will then get grub's main menu which will display a list of available kernels. Use the arrow keys to scroll to your desired version of the kernel and then press e for "edit".

 Fedora Core (2.6.18-1.2239.fc5smp) Fedora Core (2.6.18-1.2200.fc5smp) 

3. The kernel's boot menu will appear. Use the arrow keys to scroll to the "kernel" line and then press e for "edit".

 root (hd0,0) kernel /vmlinuz-2.6.18-1.2239.fc5smp ro root=LABEL=/ initrd /initrd-2.6.18-1.2239.fc5smp.img 

4. A grub edit prompt will appear. Use the arrow keys to move to the end of the line and add the word "single" to the end, separated by a space. Change

 grub edit> kernel /vmlinuz-2.6.18-1.2239.fc5smp ro root=LABEL=/ 


 grub edit> kernel /vmlinuz-2.6.18-1.2239.fc5smp ro root=LABEL=/ single 

5. Press enter to save your changes, and then b for "boot". 6. The system will continue to boot, but will go straight to the root # prompt without first asking for a username and password.

Switching to Single-user Mode

When the system is running normally, this can be done by using the init command to enter runlevel 1. It is best to do this from the console, because if you do it from a remote terminal session you'll be logged out.

 [root@bigboy root]# init 1 ... ... bash-2.05b# 

Unfortunately, this gives no prior warning to users, and the shutdown command doesn't have a single-user mode option. This can be overcome by running the shutdown command with a delay in minutes as the only argument.

 [root@bigboy tmp]# shutdown 1  Broadcast message from root (pts/0) (Sat Nov  6 13:44:59 2004):  The system is going DOWN to maintenance mode in 1 minute!  Broadcast message from root (pts/0) (Sat Nov  6 13:45:59 2004):  The system is going down to maintenance mode NOW!  ... ... bash-2.05b# 

Entering Single-user Mode

Some activities require you to force the system to log off all users, third-party applications and networking so that only the systems administrator has access to the system from the VGA console. A typical scenario is the addition of a new hard disk, as mentioned in Chapter 27, "Expanding Disk Capacity", or the troubleshooting of a failed boot process.

Another reason is the recovery of your root password.

Reboot The System

You can also use the init command to reboot the system immediately by entering runlevel 6.

 [root@bigboy tmp]# init 6  

The "reboot" command has the same effect, but it also sends a warning message to all users.

 [root@bigboy tmp]# reboot  Broadcast message from root (pts/0) (Sat Nov  6 12:39:31 2004):  The system is going down for reboot NOW! [root@bigboy tmp]# 

More graceful reboots can be done with the shutdown command using the -r switch and specifying a delay, which in this case is 10 minutes.

 [root@bigboy root]# shutdown -ry 10  Broadcast message from root (pts/0) (Sat Nov  6 13:26:39 2004):  The system is going DOWN for reboot in 10 minutes!  Broadcast message from root (pts/0) (Sat Nov  6 13:27:39 2004):  The system is going DOWN for reboot in 9 minutes! ... ... ... Broadcast message from root (pts/0) (Sat Nov  6 13:36:39 2004):  The system is going down for reboot NOW! 

Halt/Shut Down The System

The init command will allow you to change the current runlevel, and for a shutdown, that value is 0. Here is an example:

 [root@bigboy tmp]# init 0 

Fedora also has a shutdown command which can also be used to the same effect. It often prompts you as to whether you are sure you want to execute the command, which can be avoided with the -y switch. The -h switch forces the system to halt, and the first argument tells it how long to wait before starting the procedure, in this case 0 minutes. You can also specify shutting down at a specific time of the day; please refer to the man pages for details. Another advantage of the shutdown command is that it warns people that the shutdown is going to occur.

 [root@bigboy tmp]# shutdown -hy 0  Broadcast message from root (pts/0) (Sat Nov  6 13:15:27 2004):  The system is going down for system halt NOW! [root@bigboy tmp]#

System Shutdown and Rebooting

It is usually not a good idea to immediately power off your system when you are finished using it. This can cause files that are being updated to become corrupted, or worse, you could corrupt the filesystem directory structure. Linux has a number of ways to gracefully shut down and reboot your system which will be outlined in this section.

Get a Basic Text Terminal Without Exiting the GUI

There are a number of ways for you to get a command prompt when running a Linux GUI. This can be important if you need quick access to commands or you are not familiar with the GUI menu option layout.

Using a GUI Terminal Window

You can open a GUI-based window with a command prompt inside by doing the following:

  • Click on the Fedora logo button in the bottom left hand corner of the screen.
  • Click on Systems Tools and then Terminal

Using Virtual Consoles

By default, Linux runs six virtual console or TTY sessions running on the VGA console. These are defined by the mingetty statements in the /etc/inittab file. The X terminal GUI console creates its own virtual console using the first available TTY that is not controlled by mingetty. This makes the GUI run as number 7:

  • You can step through each virtual console session by using the Ctl-Alt-F1 through F6 key sequence. You'll get a new login prompt for each attempt.
  • You can get the GUI login with the sequence Ctl-Alt-F7 only in run level 5, or if the GUI is running after launching startx.

Getting a GUI Console

Manual Method: You can start the X terminal GUI application each time you need it by running the startx command at the VGA console. Remember that when you log out you will get the regular text-based console again.

 [root@bigboy tmp]# startx 

Automatic Method: You can have Linux automatically start the X terminal GUI console for every login attempt until your next reboot by using the init command. You will need to edit your initdefault variable in your /etc/inittab file, as mentioned in the preceding section to keep this functionality even after you reboot.

 [root@bigboy tmp]# init 5 

When the CPU capacity or available memory on your server is low or you want to maximize all system resources, you might want to operate in text mode runlevel 3 most of the time, using the GUI only as necessary with the startx command.

Servers that double as personal workstations, or servers that might have to be operated for an extended period of time by relatively nontechnical staff, may need to be run at runlevel 5 all the time through the init 5 command. Remember you can make runlevel 5 permanent even after a reboot by editing the /etc/inittab file.

Determining the Default Boot runlevel

The default boot runlevel is set in the file /etc/inittab with the initdefault variable. When set to 3, the system boots up with the text interface on the VGA console; when set to 5, you get the GUI. Here is a snippet of the file (delete the initdefault line you don't need):

 # Default runlevel. The runlevels used by RHS are: # 0 - halt (Do NOT set initdefault to this) # 1 - Single user mode # 2 - Multiuser, without NFS (The same as 3, if you do not have networking) # 3 - Full multiuser mode # 4 - unused # 5 - X11 # 6 - reboot (Do NOT set initdefault to this) #  id:3:initdefault:                         # Console Text Mode id:5:initdefault:                         # Console GUI Mode  

Note the following:

  • Most home users boot up with a Windows like GUI (runlevel 5)
  • Most techies will tend to boot up with a plain text-based command-line-type interface (runlevel 3)
  • Changing initdefault from 3 to 5, or vice-versa, has an effect upon your next reboot. See the following section on how to get a GUI login all the time until the next reboot.
  • Of course, don't set the initdefault value to 6 or your system will constantly reboot. Setting it to 0 will never allow it to start

The Fedora Boot Process

Learning how Linux boots up is critical. When you have this information you can use it to alter the type of login screen you get as well as which programs start up. Read on for the details.

The Linux Boot Sequence

You might remember when you installed Linux that the installation process prompted you for a list of partitions and the sizes of each in which your filesystems would be placed.

When allocating disk space for the partitions, the first sector, or data unit, for each partition is always reserved for programmable code used in booting. The very first sector of the hard disk is reserved for the same purpose and is called the master boot record (MBR).

When booting from a hard disk, the PC system BIOS loads and executes the boot loader code in the MBR. The MBR then needs to know which partitions on the disk have boot loader code specific to their operating systems in their boot sectors and then attempts to boot one of them.

Fedora Linux is supplied with the GRUB boot loader which is fairly sophisticated and therefore cannot entirely fit in the 512 bytes of the MBR. The GRUB MBR boot loader merely searches for a special boot partition and loads a second stage boot loader. This then reads the data in the /boot/grub/grub.confconfiguration file, which lists all the available operating systems and their booting parameters. When this is complete, the second stage boot loader then displays the familiar Fedora branded splash screen that lists all the configured operating system kernels for your choice.

Note: In some operating systems, such as Debian / Ubuntu, the /boot/grub/grub.conf file may also be referred to by the name /boot/grub/menu.lst.

Figure 7-1 shows a typical grub.conf file for a system that can boot both Fedora Linux and Windows 2000. This structure of this file is discussed in Chapter 33, "Modifying the Kernel to Improve Performance".

Figure 7-1 Sample grub.conf file

 default=0 timeout=10 splashimage=(hd0,0)/grub/splash.xpm.gz title Fedora Core (2.6.8-1.521)         root (hd0,0)         kernel /vmlinuz-2.6.8-1.521 ro root=LABEL=/         initrd /initrd-2.6.8-1.521.img title Windows 2000       rootnoverify (hd0,1)       chainloader +1 

When Linux begins to boot with its kernel, it first runs the /sbin/init program, which does some system checks, such as verifying the integrity of the file systems, and starts vital programs needed for the operating system to function properly. It then inspects the /etc/inittab file to determine Linux's overall mode of operation or runlevel. A listing of valid runlevels can be seen in Table 7-1.

Table 7-1 Linux Runlevels

Mode Directory Run Level Description
1/etc/rc.d/rc1.dSingle-user mode
2/etc/rc.d/rc2.dNot used (user-definable)
3/etc/rc.d/rc3.dFull multi-user mode (no GUI interface)
4/etc/rc.d/rc4.dNot used (user-definable)
5/etc/rc.d/rc5.dFull multiuser mode (with GUI interface)

Based on the selected runlevel, the init process then executes startup scripts located in subdirectories of the /etc/rc.d directory. Scripts used for runlevels 0 to 6 are located in subdirectories /etc/rc.d/rc0.dthrough /etc/rc.d/rc6.d, respectively.

Here is a directory listing of the scripts in the /etc/rc.d/rc3.d directory:

 [root@bigboy tmp]# ls /etc/rc.d/rc3.d ...    ...    K75netfs      K96pcmcia    ...    ... ...    ...    K86nfslock    S05kudzu     ...    ... ...    ...    K87portmap    S09wlan      ...    ... ...    ...    K91isdn       S10network   ...    ... ...    ...    K92iptables   S12syslog    ...    ... ...    ...    K95firstboot  S17keytable  ...    ... [root@bigboy tmp]# 

As you can see, each filename in these directories either starts with an "S" which signifies the script should be run at startup, or a K, which means the script should be run when the system is shutting down. If a script isn't there, it won't be run.

Most Linux packages place their startup script in the /etc/init.d directory and place symbolic links (pointers) to this script in the appropriate subdirectory of /etc/rc.d. This makes file management a lot easier. The deletion of a link doesn't delete the file, which can then be used for another day.

The number that follows the K or S specifies the position in which the scripts should be run in ascending order. In our example, kudzu with a value 05 will be started before wlan with a value of 09. Fortunately you don't have to be a scripting/symbolic linking guru to make sure everything works right because Fedora comes with a nifty utility called chkconfig while Debian / Ubuntu uses the update-rc.d command to do it all for you. This is explained later.

Updating Your Perl Modules

Upgrading or updating your modules to the latest version can also be done using the perl command line utility like this.

 [root@bigboy tmp]# perl -MCPAN -we 'CPAN::Shell->install(CPAN::Shell->r)' 

This is a simple process, but make sure you have internet connectivity first.

Automatic Installation of Perl Modules

Modules can be installed automatically using the perl utility but you must first install the prerequisite ncftp and perl-CPAN package to download the packages from CPAN.

 [root@bigboy tmp]# yum -y install ncftp perl-CPAN 

After the package installed you can use the following perl command to enter the CPAN utility.

 perl -MCPAN -e shell 

The first time it is run, Perl will prompt you for a number of configuration options. In most cases the defaults will be sufficient. After the initial setup is complete you will have a cpan> command prompt


Installation of modules can then be done with the install command followed by the name of the module. In this example we install the Mail::Audit module using the CPAN utility.

 [root@bigboy tmp]# perl -MCPAN -e shell Terminal does not support AddHistory.  cpan shell -- CPAN exploration and modules installation (v1.7602) ReadLine support available (try 'install Bundle::CPAN')  cpan> install Mail::Audit CPAN: Storable loaded ok LWP not available CPAN: Net::FTP loaded ok Fetching with Net::FTP:   ftp://archive.progeny.com/CPAN/authors/01mailrc.txt.gz ... ... ... Installing /usr/share/man/man3/Mail::Audit::MAPS.3pm Appending installation info to /usr/lib/perl5/5.8.8/i386-linux-thread-multi/perllocal.pod   /usr/bin/make install  -- OK  cpan> exit Terminal does not support GetHistory. Lockfile removed. [root@bigboy tmp]# 

The exit command allows you to return to the Linux command prompt and your Perl module should be fully installed.

Manual Installation of Perl Modules

Most of the commonly used Perl modules can be downloaded from the CPAN website. The installation steps are straightforward.

1. Browse the CPAN website, identify the module package you need and then download it using a utility such as wget.

 [root@bigboy tmp]# wget http://www.cpan.org/authors/id/M/MA/MARKOV/MailTools-1.74.tar.gz --15:07:36--  http://www.cpan.org/authors/id/M/MA/MARKOV/MailTools-1.74.tar.gz            => `MailTools-1.74.tar.gz' Resolving www.cpan.org... Connecting to www.cpan.org||:80... connected. HTTP request sent, awaiting response... 200 OK Length: 47,783 (47K) [application/x-tar]  100%[===================================>] 47,783       100.88K/s               15:07:38 (100.51 KB/s) - `MailTools-1.74.tar.gz' saved [47783/47783]  [root@bigboy tmp]# 

2. Extract the file from the package with the tar command.

 [root@bigboy tmp]# tar -xzvf MailTools-1.74.tar.gz  MailTools-1.74/ MailTools-1.74/t/ ... ... ... MailTools-1.74/ChangeLog MailTools-1.74/MANIFEST [root@bigboy tmp]# 

3. Enter the newly created directory with the same name as the TAR file, and install the module with the following commands.

  • perl Makefile.PL
  • make
  • make test
 [root@bigboy tmp]# cd MailTools-1.74 [root@bigboy MailTools-1.74]# perl Makefile.PL Checking for Net::SMTP...ok Checking for Net::Domain...ok Checking for IO::Handle...ok Checking if your kit is complete... Looks good Writing Makefile for Mail [root@bigboy MailTools-1.74]# make cp Mail/Cap.pm blib/lib/Mail/Cap.pm cp Mail/Mailer/rfc822.pm blib/lib/Mail/Mailer/rfc822.pm ... ... ... Manifying blib/man3/Mail::Util.3pm Manifying blib/man3/Mail::Address.3pm [root@bigboy MailTools-1.74]# make test PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" t/*.t t/extract.....ok                                                              ... ... ... All tests successful. Files=7, Tests=95,  2 wallclock secs ( 1.28 cusr +  0.29 csys =  1.57 CPU) [root@bigboy MailTools-1.74]#  

Your Perl module installation should now be complete.

Note: The output of the perl Makefile.PL command will tell you whether there are any other required modules. You can either install them all manually, running the risk of having to install more prerequisite modules for these prerequisite modules, or you can use automated updates which will be covered next.

Installing Perl Modules

Even if you don't know how to program in Perl, you may find yourself having to install Perl modules to get some of your software packages to work.

Modules can be installed manually by downloading the TAR files from www.cpan.org, the primary Perl module site. The disadvantage is that this method doesn't automatically install any prerequisite modules you may need. Another disadvantage, though small is that the perl module names usually have a double colon (::) in their names, but the installation TAR file in which this module resides won't have the colons in its name. For example version 1.74 of the Mail::Tools module has the file name MailTools-1.74.tar.gz.

Modules can also be installed automatically using the perl command. We will cover both methods in this section.

Installing Software Using tar Files

Another popular software installation file format is the tar file, which can frequently be obtained from the Web sites of software developers, and online software libraries such as www.sourceforge.net.

The Linux tar command is used to archive files and typically have a .tar file extension in the file name. These files are also frequently compressed in the gzip format, and when they do, their file extensions will end with .tar.gz or .tgz. The commands to extract the data from either type are similar. When a tar file is uncompressed, the command to extract the data is tar -xvf filename.tar. When the archive is compressed, the command to use is tar -xzvf filename.tar.gz.

The tar file installation process usually requires you first to uncompress and extract the contents of the archive in a local subdirectory, which frequently has the same name as the tar file. The subdirectory will usually contain a file called README or INSTALL, which outlines all the customized steps to install the software.

Here are the initial steps to take to install tar-based software:

1) Issue the tar command to extract the files.

[root@bigboy tmp]# tar -xvzf linux-software-1.3.1.tar.gz linux-software-1.3.1/ linux-software-1.3.1/plugins-scripts/ ... ... ... linux-software-1.3.1/linux-software-plugins.spec [root@bigboy tmp]# 

This creates a subdirectory with the installation files inside.

[root@bigboy tmp]# ls linux-software-1.3.1  linux-software-1.3.1.tar.gz [root@bigboy tmp]# 

2) Use the cd command to enter the subdirectory and follow the directions listed in the INSTALL and README files:

[root@bigboy tmp]# cd linux-software-1.3.1 [root@bigboy linux-software-1.3.1]# ls COPYING    install-sh   missing                 plugins depcomp    LEGAL        mkinstalldirs           plugins-scripts FAQ        lib          linux-software.spec     README Helper.pm  Makefile.am  linux-software.spec.in  REQUIREMENTS INSTALL    Makefile.in  NEWS                    subst.in [root@bigboy linux-software-1.3.1]# 

Software installation with tar files can be frustrating, frequently requiring the installation of other supporting tar files, each with its own customized installation commands. RPMs, with the single standardized command format, are usually easier to use and may be the better method to use for newer Linux users.  

Remember The Following Yum Facts

  • yum does its updates using TCP port 80 for http:// update URLs and uses passive FTP for ftp:// update URLs in /etc/yum.conf. This will have importance for your firewall rules.
  • More details on configuring yum can be obtained by running the man yum.conf command.
  • yum runs automatically each day. The cron file is located in /etc/cron.daily/.
  • Don't limit yourself to the default yum.conf URLs because they can become overloaded with requests and make yum perform poorly. 
  • Example of a yum Package Installation

    Here is a sample installation of an individual package using yum. In this case the RPM installed is the net-snmp-utils package:

    [root@bigboy tmp]# yum -y install  net-snmp-utils Repository updates-released already added, not adding again Repository base already added, not adding again Setting up Install Process Setting up Repo:  base repomd.xml          100% |=========================| 1.1 kB     00:00 Setting up Repo:  updates-released repomd.xml          100% |=========================|  951 B     00:00 Reading repository metadata in from local files base      : ############################################ 2622/2622 primary.xml.gz      100% |=========================|  88 kB     00:00 MD Read   : ################################################## 229/229 updates-re: ################################################## 229/229 Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package net-snmp-utils.i386 0:5.1.2-11 set to be installed --> Running transaction check   Dependencies Resolved Transaction Listing:   Install: net-snmp-utils.i386 0:5.1.2-11 Downloading Packages: net-snmp-utils-5.1.2-11.i 100% |===================| 6.2 MB     00:48 Running Transaction Test Finished Transaction Test Transaction Test Succeeded Running Transaction Installing: net-snmp-utils 100 % done 1/1   Installed: net-snmp-utils.i386 0:5.1.2-11 Complete! [root@bigboy tmp]# 

    Keeping Your System current with Yum

    You can make the installed RPM packages on your system up to date with the latest patches using the yum update command. When used without listing any packages afterwards, yum will attempt to update them all. The yum update package-name command updates only a particular RPM package.

    It is always advisable to use yum after installing Linux to make sure the latest versions of software are installed for the sake of improved security and functionality. Here is an example of output of what to expect with yum updating your system.

    [root@bigboy tmp]# yum update Gathering header information file(s) from server(s) Server: Fedora Core 2 - i386 - Base Server: Fedora Core 2 - i386 - Released Updates Finding updated packages Downloading needed headers Resolving dependencies Dependencies resolved I will do the following: [install: kernel 2.4.22-1.2166.nptl.i686] [update: samba-client 3.0.2-7.FC1.i386] [update: binutils] ... ... ... Is this ok [y/N]: y Getting samba-client-3.0.2-7.FC1.i386.rpm samba-client-3.0.2-7.FC1. 100% |=========================| 128 kB    05:01 ... ... ... Running test transaction: Test transaction complete, Success! glibc-common 100 % done 1/127 glibc 100 % done 2/127 Stopping sshd:[  OK  ] Starting sshd:[  OK  ] bash 100 % done 3/127 mozilla-nspr 100 % done 4/127 sed 100 % done 5/127 ... ... ... Completing update for pango  - 65/127 Completing update for samba-client  - 66/127 Completing update for binutils  - 67/127 ... ... ... Completing update for XFree86-font-utils  - 127/127 Kernel Updated/Installed, checking for bootloader Grub found - making this kernel the default Installed:  kernel 2.4.22-1.2166.nptl.i686 Updated:  pango 1.2.5-4.i386 samba-client 3.0.2-7.FC1.i386 binutils XFree86-Mesa-libGLU 4.3.0-55.i386 initscripts [root@bigboy tmp]# 

    Note: If you don't want to be prompted to install the files use the yum with the -y switch.

    How to Automate yum

    As of Fedora Core 6 the yum daemon has been named yum-updatesd, whereas in the past it was just called yum. To get yum started, select the commands that match your OS version:

    1) Use the chkconfig command to get yum configured to start at boot:

     [root@bigboy tmp]# chkconfig yum-updatesd on   [root@bigboy tmp]# chkconfig yum on  

    2) Use the service command to instruct the /etc/init.d yum script to start/stop yum after booting

    [root@bigboy tmp]# service yum-updatesd start [root@bigboy tmp]# service yum-updatesd stop  [root@bigboy tmp]# service yum start [root@bigboy tmp]# service yum stop 

    Creating Your Own yum Server

    An obvious advantage of using yum is that you can use it to update a yum server at your office with the same directory structure of the mirror download sites on the Fedora Web site. The full set of steps to do this is beyond the scope of this book, but there are some factors you should consider before doing this.

    A small desktop PC with about five to six gigabytes of free disk space per distribution should be sufficient to start with for a dedicated small business yum server. Large RPMs are about twenty-five megabytes in size, and they are updated infrequently, so your network load should be minimal on average with an update once or twice a week per server. In large server farms you may want to use a more robust system that can handle many more clients, but before doing so, get trend data for its network load to help your final decision. The configuration of the MRTG graphing tool is covered in Chapter 22, " Monitoring Server Performance".

    When established, you can then configure all your Fedora servers to use this local yum server for all updates which will significantly reduce your Internet congestion and the associated bandwidth costs.

    yum clients can access the yum server using either FTP or HTTP requests. If you need help in setting these up, Chapter 15, "Linux FTP Server Setup", discusses Linux FTP servers and Chapter 20, "The Apache Web Server", covers the Apache Web server for HTTP requests.

    Note: When setting up an HTTP based yum server, you'll need to enable the viewing of directory structures so that it will be easy for someone to use his or her Web browser to navigate down the directories to double check the location of the yum files. 

    How to Automate yum

    Older versions of yum could be configured to run in the background as a daemon that was simple named yum that used a unified yum.conf file for all its configuration data. Newer versions use the yum-updatesd daemon instead. This uses the /etc/yum/yum-updatesd.conf configuration file which governs update frequency, the types of files to be downloaded and whether they should be automatically installed using the yum command.

    To get yum started, select the commands that match your OS version:

    1. If using a newer version of Fedora / Redhat, make sure the yum-updatesd package is installed.

    [root@bigboy tmp]# yum –y install yum-updatesd  

    2. Use the chkconfig command to get yum configured to start at boot:

    [root@bigboy tmp]# chkconfig yum-updatesd on  [root@bigboy tmp]# chkconfig yum on 

    3. Use the service command to instruct the /etc/init.d yum script to start/stop yum after booting

    [root@bigboy tmp]# service yum-updatesd start [root@bigboy tmp]# service yum-updatesd stop   [root@bigboy tmp]# service yum start [root@bigboy tmp]# service yum stop 

    Note: Updating packages could cause programs written by you to stop functioning especially if they rely on the older version's features or syntax. The yum daemon will do updates automatically; the yum-updatesd daemon won't do this unless the yum-updatesd.conf file has been updated as shown here:

    # # File: /etc/yum/yum-updatesd.conf #  [main] do_update = yes 

    Configuring yum

    The configuration parameters that affect all packages and all yum server URLs are stored in the [main] section of the /etc/yum.conf file. You generally don't need to edit this file, but it can be useful in listing packages that you don't want yum to update.

    # # File: /etc/yum.conf #  [main] exclude=kernel perl 

    In this example the kernel and perl packages are excluded.

    Configuring /etc/yum.repos.d Repository Files

    The /etc/yum.repos.d directory has files defining where yum should look on the Internet to find the latest Linux updates. For most common tasks you won't need to modify these files at all. If you want to know how these files affect your system, then continue reading! The configurations for each RPM repository are located in individual configuration files with the .repo file extension. This directory will be populated with files for your Linux distribution's most important repositories. You can also add your own custom files for repositories containing non-standard RPM packages. These files will have the following format:

    [repositoryid] name=Some name for this repository baseurl=url://path/to/repository/ 

    The [repositoryid] is an identifier that is unique to all files in the directory and can only be one word long and is often given a name that reflects the function of the repository. For example, you may have a fedora-updates.repo file that contains a [updates], and [updates-source] sections that refer to URLs for updates of regular RPMs and source RPMs. You can create your own repository files using popular repository sites. The easiest way to determine the exact URLs to use as the baseurl parameter is to go to the http://fedora.redhat.com/download/mirrors.html Web site to get a listing of alternative download sites. Browse the listed sites to find the correct locations of the RPM files in the /updates or /fedora-version URL branches. Make sure that baseurl points to a URL with a /repodata sub-directory beneath it as this sub-directory contains files with instructions for yum to use in doing its updates. Be careful, this sub-directory can be located within the RPM directory or one level above them. Also remember to make the [repositoryid] in your .repo file unique to all other files.

    Note: yum accepts the use of variables in the configuration file. The $releasever variable refers to the current version of Fedora Core running on your server and the $basearch variable maps to the base architecture of your server which is determined automatically. Here is an example of the use of these variables.

    [repository-name] name=Fedora Core $releasever - $basearch - Base baseurl=http://url.com/fedora/core/$releasever/$basearch/os/ 

    Note: It is probably best to select yum update sites that use HTTP instead of FTP. There are a number of reasons for this. FTP firewall rules are more difficult to implement than HTTP, outbound HTTP access to the Internet is often already allowed in offices, and web servers are less likely to have connection limits imposed on them, unlike FTP servers, which often have limits on the number of user logins. Note: You can list multiple URLs in a baseurl statement like this and yum will try them all. If you use multiple baseurl statements in each section then yum may act strangely, frequently only selecting the last one in the list.

    baseurl=url://server1/path/to/files/         url://server2/path/to/files/         url://server3/path/to/files/  

    Note: You can also place all your [repositoryid] sections in the yum.conf file. This was the methodology used in some older versions of yum.

    Note: The yum utility can be configured to match the downloaded RPMs against checksum files to help protect against file corruption and malicious forgeries. This is set using the gpgcheck variable in the .repo files. Checks are done when the value is set to 1, when set to 0, they are disabled. Here is an example:

    # # File: example.repo # gpgcheck=1 gpgkey=http://URL/example.key 

    Repositories will sometimes provide you with the URL for their checksum files and it is a good idea to take advantage of them. This is a valuable feature. 

    Automatic Updates with yum

    The yum automatic RPM update program comes as a standard feature of Fedora Core. It has a number of valuable features:

    • You can configure the URLs of download sites containing the RPM repositories you need. This provides the added advantage of you choosing the most reliable sites in your part of the globe.
    • yum makes multiple attempts to download RPMs before failing.
    • yum automatically figures out not only the RPMs packages that need updating, but also all the supporting RPMs. It then installs them all.

    Note: Updating packages could cause programs written by you to stop functioning especially if they rely on the older version's features or syntax. 

    Which RPMs Will Start Up At Boot Time?

    The best way to view and configure which RPMs will start at boot time is by using the chkconfig command with the --list switch. A more detailed explanation will be provided in Chapter 7, "The Linux Boot Process", which covers the Linux boot process.

    Uninstalling RPMs

    The rpm -e command will erase an installed package. The package name given must match that listed in the rpm -qa command because the version of the package is important.

    [root@bigboy tmp]# rpm -e package-name 

    Listing Files Associated with RPMs

    Sometimes you'll find yourself installing software that terminates with an error requesting the presence of a particular file. In many cases the installation program doesn't state the RPM package in which the file can be found. It is therefore important to be able to determine the origin of certain files, by listing the contents for RPMs in which you suspect the files might reside.

    Listing Files for Already Installed RPMs

    This can be useful if you have to duplicate a working server that is already in a production environment. Sometimes the installation of an application fails on the new server due to the lack of a file that resides on the old one. In this case you need to know which RPM on the old server contains the file.

    You can use the -ql qualifier to list all the files associated with an installed RPM. In this example we test to make sure that the NTP package is installed using the -q qualifier, and then we use the -ql qualifier to get the file listing.

    [root@bigboy tmp]# rpm -q ntp ntp-4.1.2-0.rc1.2 [root@bigboy tmp]# rpm -ql ntp /etc/ntp /etc/ntp.conf /etc/ntp/drift /etc/ntp/keys ... ... ... /usr/share/doc/ntp-4.1.2/rdebug.htm /usr/share/doc/ntp-4.1.2/refclock.htm /usr/share/doc/ntp-4.1.2/release.htm /usr/share/doc/ntp-4.1.2/tickadj.htm [root@bigboy tmp]# 

    Listing Files in RPM Files

    Sometimes you make a guess and download what you think is the RPM with the missing file. You can use the -qpl qualifier to list all the files in an RPM archive to make sure before installing it:

    [root@bigboy updates]# rpm -qpl dhcp-3.0pl1-23.i386.rpm /etc/rc.d/init.d/dhcpd /etc/rc.d/init.d/dhcrelay /etc/sysconfig/dhcpd /etc/sysconfig/dhcrelay ... ... ... /usr/share/man/man8/dhcrelay.8.gz /var/lib/dhcp /var/lib/dhcp/dhcpd.leases [root@bigboy updates]# 

    Listing the RPM to Which a File Belongs

    You might need to know the RPM that was used to install a particular file. This is useful when you have a suspicion about the function of a file but are not entirely sure. For example, the MySQL RPM uses the /etc/my.cnf file as its configuration file, not a file named /etc/mysql.conf as you'd normally expect. The following example confirms the origin of the /etc/my.cnf file.

    [root@zippy tmp]# rpm -qf /etc/my.cnf mysql-3.23.58-9 [root@zippy tmp]# 

    How to List Installed RPMs

    The rpm -qa command will list all the packages installed on your system

    [root@bigboy tmp]# rpm -qa perl-Storable-1.0.14-15 smpeg-gtv-0.4.4-9 e2fsprogs-1.27-9 libstdc++-3.2-7 audiofile-0.2.3-3 ... ... ... [root@bigboy tmp]# 

    You can also pipe the output of this command through the grep command if you are interested in only a specific package. In this example we are looking for all packages containing the string ssh in the name, regardless of case (-i means ignore case)

    [root@bigboy tmp]# rpm -qa | grep -i ssh openssh-server-3.4p1-2 openssh-clients-3.4p1-2 openssh-askpass-gnome-3.4p1-2 openssh-3.4p1-2 openssh-askpass-3.4p1-2 [root@bigboy tmp]# 

    Note: You could use the rpm -q package-name command to find an installed package because it is much faster than using grep and the -qa switch, but you have to have an exact package match. If you are not sure of the package name and its capitalization, the latter method is probably more suitable. 

    RPM Installation Errors

    Sometimes the installation of RPM software doesn't go according to plan and you need to take corrective actions. This section shows you how to recover from some of the most common errors you'll encounter.

    Failed Dependencies

    Sometimes RPM installations will fail giving Failed dependencies errors which really mean that a prerequisite RPM needs to be installed. In the next example we're attempting to install the MySQL database server application, which fails because the mysql MySQL client RPM, on which it depends, needs to be installed beforehand:

    [root@bigboy tmp]# rpm -Uvh mysql-server-3.23.58-9.i386.rpm error: Failed dependencies:         libmysqlclient.so.10 is needed by mysql-server-3.23.58-9         mysql = 3.23.58 is needed by mysql-server-3.23.58-9 [root@bigboy tmp]# 

    Installing the MySQL client also fails because it requires the perl-DBD-MySQL package.

    [root@bigboy tmp]# rpm -Uvh mysql-3.23.58-9.i386.rpm error: Failed dependencies:         perl-DBD-MySQL is needed by mysql-3.23.58-9 [root@bigboy tmp]# rpm -Uvh perl-DBD-MySQL-2.9003-4.i386.rpm error: Failed dependencies:         libmysqlclient.so.10 is needed by perl-DBD-MySQL-2.9003-4 [root@bigboy tmp]# 

    Strangely enough, the installation of the perl-DBD-MySQL package fails because it needs the mysql client package. To get around this problem you can run the rpm command with the --nodeps option to disable dependency checks. In the next example we install the MySQL client ignoring dependencies, followed by successful installation of perl-DBD-MySQL and mysql-server.

    [root@bigboy tmp]# rpm -Uvh --nodeps mysql-3.23.58-9.i386.rpm Preparing...        ####################### [100%]    1:mysql          ####################### [100%] [root@bigboy tmp]# rpm -Uvh perl-DBD-MySQL-2.9003-4.i386.rpm Preparing...        ####################### [100%]    1:perl-DBD-MySQL ####################### [100%] [root@bigboy tmp]# rpm -Uvh mysql-server-3.23.58-9.i386.rpm Preparing...        ####################### [100%]    1:mysql-server   ####################### [100%] [root@bigboy tmp]# 

    Note: If all the installation RPMs are located in the same directory, the rpm command can automatically install all the prerequisite RPMs using the --aid option. One of the advantages of using the yum facility is that you don't have to worry about this dependency process as much because the dependency RPMs are always downloaded and installed automatically also.

    Signature Keys

    Fedora digitally signs all its RPM files, so it's best to import their public encryption key beforehand so that the RPM installation program will be able to verify the validity of the RPM file.

    This is usually done automatically in newer versions of Fedora, but will need to be done manually in legacy versions. The manual method uses the rpm command as seen in the next example, but locate the key files first as their locations can vary between Fedora distributions. It is a good idea to import both the RedHat and Fedora keys:

    [root@bigboy tmp]# locate RPM-GPG-KEY /usr/share/rhn/RPM-GPG-KEY /usr/share/rhn/RPM-GPG-KEY-fedora [root@bigboy tmp]# rpm --import /usr/share/rhn/RPM-GPG-KEY [root@bigboy tmp]# rpm --import /usr/share/rhn/RPM-GPG-KEY-fedora [root@bigboy tmp]# 

    If you don't install the keys you'll get a DSA signature warning that alerts you to the fact that the RPM file might be bogus:

    [root@bigboy tmp]# rpm -Uvh dhcp-3.0pl2-6.16.i386.rpm warning: dhcp-3.0pl2-6.16.i386.rpm: V3 DSA signature: NOKEY, key ID 4f2a6fd2 Preparing...           #################################### [100%]    1:dhcp              #################################### [100%] [root@bigboy tmp]# 

    It is always good to install the key files. If they are not there, the RPMs will install with only a warning message. If the RPM's digital signature doesn't match that in the key file, the rpm installation program also alerts you and fails to install the RPM package at all:

    [root@bigboy tmp]# rpm -Uvh dhcp-3.0pl2-6.16.i386.rpm error: dhcp-3.0pl2-6.16.i386.rpm: V3 DSA signature: BAD, key ID 4f2a6fd2 error: dhcp-3.0pl2-6.16.i386.rpm cannot be installed [root@bigboy tmp]# 

    Signatures are therefore useful because they help protect you against tampered and otherwise corrupted RPMs being installed. 

    How to Install Source RPMs

    Sometimes the packages you want to install need to be compiled in order to match your kernel version. This requires you to use source RPM files:

    • Download the source RPMs or locate them on your CD collection. They usually have a file extension ending with (.src.rpm)
    • Run the following commands as root:

    Compiling and installing source RPMs with Fedora can be done simply with the rpmbuild command

    [root@bigboy tmp]# rpmbuild --rebuild filename.src.rpm 

    Here is an example in which we install the tacacs plus package.

    [root@bigboy rpm]# rpmbuild --rebuild tac_plus-4.0.3-2.src.rpm Installing tac_plus-4.0.3-2.src.rpm Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.61594 + umask 022 + cd /usr/src/redhat/BUILD + cd /usr/src/redhat/BUILD + rm -rf tac_plus-4.0.3 + /usr/bin/gzip -dc /usr/src/redhat/SOURCES/tac_plus-4.0.3.tgz + tar -xvvf - ... ... ... + umask 022 + cd /usr/src/redhat/BUILD + rm -rf tac_plus-4.0.3 + exit 0 [root@bigboy rpm]# 

    The compiled RPM file can now be found in one of the architecture subdirectories under /usr/src/redhat/RPMS directory. For example, if you compiled an i386 architecture version of the RPM it will placed in the i386 subdirectory.

    You will then have to install the compiled RPMs found in their respective subdirectories as you normally would.