Unix iTOps Tube

Monday, July 11, 2011

Installing sysv-rc-conf

The sysv-rc-conf package can be installed easily using apt-get. Here is an example.

 root@u-bigboy:~# apt-get install sysv-rc-conf 

Using sysv-rc-conf to Start Daemons at Each runlevel

With Debian / Ubuntu Linux, the update-rc.d command replaces chkconfig as the default package for modifying /etc/init.d script links. Unfortunately, the utility was written to facilitate link modification when packages are installed or removed, but is less friendly when you need to alter links for existing packages you want to keep.

Fortunately there is hope for the harried systems administrator in the form of the sysv-rc-conf package which uses an almost identical syntax to chkconfig, and has a GUI mode if you run it from the command line without any arguments. This section will show you some important tips in using sysv-rc-conf.

Final Tips on chkconfig

Remember the following:

  • In most cases, you want to modify runlevels 3 and 5 simultaneously and with the same values.
  • Don't add/remove anything to other runlevels unless you absolutely know what you are doing. Don't experiment, unless in a test environment.
  • chkconfig doesn't start the programs in the /etc/init.d directory, it just configures them to be started or ignored when the system boots up. The commands for starting and stopping the programs covered in this book are covered in each respective chapter.

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 Unix 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.  

How to Download Software

One of the most universally performed tasks by Linux systems administrators is the downloading of software. It is usually very simple to do and the most commonly used methods are covered in this section.

Getting Software Using Web-Based FTP

There are numerous Web sites that provide links to software you can download. The methodology to get the software is usually the same for all:

  • Browse the desired Web site until you find the link to the software package you need.
  • Click on the link for the desired software package.
  • Save the file to your hard drive

Some web browsers, such as Firefox, will automatically download the file to your desktop, but where is the desktop? In Linux, your desktop is usually a sub-directory named Desktop located in your home or ~ directory. Here we see that the root user's desktop already contains a downloaded RPM file.

 [root@bigboy tmp]# cd ~/Desktop/  [root@bigboy Desktop]# ls  ElectricFence-2.2.2-20.2.i386.rpm  [root@bigboy Desktop]# pwd  /root/Desktop  [root@bigboy Desktop]# 

Getting RPMs Using Command-Line Anonymous FTP

The Web based method above transparently uses anonymous File Transfer Protocol (FTP). Anonymous FTP allows you to log in and download files from a FTP server using the username anonymous or the shorter username ftp and a password that matches your e-mail address. This way anyone can access the data. Let's illustrate this with an example of using anonymous FTP to download the SSH package from download.fedora.redhat.com:

1) First we issue the FTP command targeting download.fedora.redhat.com at the command line.

[root@bigboy tmp]# ftp download.fedora.redhat.com Trying Connected to download.fedora.redhat.com ( 220 Fedora FTP server ready. All transfers are logged. Name (download.fedora.redhat.com:root): anonymous 331 Please specify the password. Password: 230 Login successful. Have fun. Using binary mode to transfer files. ftp> pwd 257 "/" ftp> ls 227 Entering Passive Mode (66,187,232,35,57,155) 150 Here comes the directory listing. drwxr-xr-x    3 ftp      ftp          4096 Oct 29 15:59 pub 226 Directory send OK. ftp> 

2) After we've logged in, we can use the help command to see what options we have at our disposal.

ftp> help Commands may be abbreviated.  Commands are:  !               cr              mdir            proxy           send $               delete          mget            sendport        site account         debug           mkdir           put             size append          dir             mls             pwd             status ascii           disconnect      mode            quit            struct bell            form            modtime         quote           system binary          get             mput            recv            sunique bye             glob            newer           reget           tenex case            hash            nmap            rstatus         trace ccc             help            nlist           rhelp           type cd              idle            ntrans          rename          user cdup            image           open            reset           umask chmod           lcd             passive         restart         verbose clear           ls              private         rmdir           ? close           macdef          prompt          runique cprotect        mdelete         protect         safe ftp>  

The commands you'll most likely use are listed in Table 6-2:

Table 6-2 FTP Commands

Command Description
binary Copy files in binary mode
cd Change directory on the FTP server
dir List the names of the files in the current remote directory
exit Bye bye
get Get a file from the FTP server
lcd Change the directory on the local machine
ls Same as dir
mget Same as get, but you can use wildcards like "*"
mput Same as put, but you can use wildcards like "*"
passive Make the file transfer passive mode
put Put a file from the local machine onto the FTP server
pwd Give the directory name on the local machine

3) By using the Web browsing feature on the Web site ahead of time, I know that the Fedora Core 2 RPMs are located in the pub/fedora/linux/core/2/i386/os/Fedora/RPMS/ directory and will use the cd command to change my directory to there. We can use the ls command to get a listing of files in this directory.

ftp> cd pub/fedora/linux/core/2/i386/os/Fedora/RPMS/ 250 Directory successfully changed. ftp> ls open* 227 Entering Passive Mode (66,187,232,35,58,3) 150 Here comes the directory listing. ... ... -rw-r--r--   ... ... 184281 Oct 28 23:29 openssh-3.6.1p2-34.i386.rpm ... ... 226 Directory send OK. ftp> 

4) Next we get the file we need and place it in the local directory /usr/rpm. The hash command will print "#" hash signs on the screen during the download.

ftp> hash Hash mark printing on (1024 bytes/hash mark). ftp> lcd /usr/rpm Local directory now /usr/rpm ftp> get openssh-3.6.1p2-34.i386.rpm  local: openssh-3.6.1p2-34.i386.rpm remote: openssh-3.6.1p2-34.i386.rpm  227 Entering Passive Mode (66,187,232,35,58,25)  150 Opening BINARY mode data connection for openssh-3.6.1p2-34.i386.rpm (184281 bytes).  ###################################################################################################################################################################################  226 File send OK.  184281 bytes received in 3.41 secs (53 Kbytes/sec)  ftp> 

Note: You can also use wildcards to download the RPMs you need using the mget command. You'll be prompted for each of the matching RPM files. In the next example, we just aborted this download by typing n.

ftp> mget openssh-3.6* mget openssh-3.6.1p2-34.i386.rpm? n ftp> 

5) Finally we use the exit command to leave FTP.

ftp> exit 221 Goodbye. root@bigboy tmp]# 

Getting Software Using wget

The wget command can be used to download files quickly when you already know the URL at which the RPM is located. This is especially convenient if you are logged into your Linux box from another machine running a Web browser. You can browse the download site for the RPM you need, right click on the desired link and select copy shortcut (Windows) or Copy Link Location (Linux). After you have done this, you can then select your SSH/telnet/Linux Terminal login window and type in the command wget URL. Here is an example downloading a DHCP update from Fedora.

[root@bigboy tmp]# wget http://linux.stanford.edu/pub/mirrors/fedora/linux/core/2/i386/os/Fedora/RPMS/dhcp-3.0pl2-6.16.i386.rpm --17:38:36--  ftp://linux.stanford.edu/pub/mirrors/fedora/linux/core/2/i386/os/Fedora/RPMS/dhcp-3.0pl2-6.16.i386.rpm            => `dhcp-3.0pl2-6.16.i386.rpm.5' Resolving linux.stanford.edu... done. Connecting to linux.stanford.edu[]:21... connected. Logging in as anonymous ... Logged in! ==> SYST ... done.    ==> PWD ... done. ==> TYPE I ... done.  ==> CWD /pub/mirrors/fedora/linux/core/2/i386/os/Fedora/RPMS ... done. ==> PASV ... done.    ==> RETR dhcp-3.0pl2-6.16.i386.rpm ... done. Length: 529,890 (unauthoritative)   100%[===============================>] 529,890      889.12K/s    ETA 00:00   17:38:36 (889.12 KB/s) - `dhcp-3.0pl2-6.16.i386.rpm.5' saved [529890]   [root@bigboy tmp]#

Where to Get Commonly Used Packages

There are three commonly used sources for packages; distribution CDs; packages manually downloaded via a browser, File Transfer Protocol (FTP) client, or the wget utility; and automated downloads. Each of these methods is introduced here, but is covered in greater detail in sections to follow.

Packages on Your Installation CDs

Installing from your distribution CDs is usually easier than having to download files from a remote Web site, but they are never up to date for very long. We discuss using this method in more detail later.

Manually Downloaded Packages

The two most common ways of getting packages are by manually using FTP or a Web browser. Table 6-1 lists some common download sites that can be used. Remember to match the RPM to the distribution and version of Linux your system is running.

Table 6-1 Popular Package Download Sites

Distribution Location
Redhat http://www.redhat.com/


Fedora ftp://download.fedora.redhat.com/pub/fedora/linux/core/

http://download.fedora.redhat.com/pub/fedora/linux/core/ http://www.rpmfind.net/

Debian http://packages.debian.org
Ubuntu http://packages.ubuntu.com

Note: With Fedora you can also download packages from the download.fedora.redhat.com site. Start your search in the /pub/fedora/linux/core/ directory and move down the directory tree. If you're new to FTP, don't worry, it's explained later.

Automated Package Download

The disadvantage of manual downloads is that the packages often won't install unless certain prerequisite packages have been installed beforehand. This can lead to the download and installation of several packages which can become tedious.

All the major Linux distributions have automated download and update utilities. For example, Fedora uses yum and Ubuntu and Debian use apt. These are all covered in greater detail in sections to follow.

Installing Linux Software

You'll frequently need to install additional software on your Linux server that you didn't think you'd need when you first installed the operating system. This could be because of new business requirements for additional packages or the need to install new administrative tools to make your job easier.

When Linux developers create their software they typically bundle all the executable and data files into a single file that is often called a "package" file. Package files have different formats and contain different control files that determine where the rest of the files should be placed, the permissions they should have and a list of prerequisite packages that are required for the package to function correctly. Some of this information may also be stored in a database on your system by the package management software used to install the software and is used to speed up some of the administrative functions of the package manager.

Redhat, Centos and Fedora Linux software is primarily available in RedHat Package Manager (RPM) files. Regular RPM package files are used for installations in which the kernel, or master program, hasn't been customized in any way. This is the usual scenario for most departmental servers. Source RPMs are used when the kernel has been customized to add or drop support selectively for various devices or features for the sake of performance or functionality. The procedure for installing source RPMs involves recompiling source code to fit the needs of these kernel customizations. This makes life easier for the software developer who wrote the package as he or she now has only to create a single package to support all types of customizations. Both package types use standardized commands for installing the software contained inside making RPMs relatively easy to use.

Debian and Ubuntu versions of Linux use the Debian Package format in which the filenames all end with ".deb". It is for this reason that they are frequently called DEB files.

Software developers who want to use a universally recognizable file format across all flavors of Linux also will make their products available as TAR packages. TAR packages are generally more difficult to work with than RPM packages because the archived files within them may or may not need to be compiled and the commands to install the software may vary from package to package. Instructions are usually contained within a file inside the TAR package to help guide the installation.

The Perl programming language is often used by Linux software developers to create their programs. Perl relies on the presence of certain libraries, or "modules", to work correctly and many Linux distributions install Perl with only the most commonly used ones. There will be times when you will be required to install additional prerequisite Perl modules prior to the installation of your packages. Knowledge of how to install Perl modules is a valuable component of a Linux systems administrators' skill set.

This chapter focuses on the RPM and DEB formats, which are used by a majority of installed distributions. There are smaller sections on TAR packages and Perl modules near the end to cover these less frequently used, but important software installation tools. 

Simple syslog Security

One of the shortcomings of a syslog server is that it doesn't filter out messages from undesirable sources. It is therefore wise to implement the use of TCP wrappers or a firewall to limit the acceptable sources of messages when your server isn't located on a secure network. This will help to limit the effectiveness of syslog based denial of service attacks aimed at filling up your server's hard disk or taxing other system resources that could eventually cause the server to crash.

Remember that regular syslog servers listen on UDP port 514 and syslog-ng servers rely on port 514 for both UDP and TCP. Please refer to Chapter 14, "Linux Firewalls Using iptables", on Linux firewalls for details on how to configure the Linux iptables firewall application and Appendix I, "Miscellaneous Linux Topics", for further information on configuring TCP wrappers


The more recent syslog-ng application combines the features of logrotate and syslog to create a much more customizable and feature rich product. This can be easily seen in the discussion of its configuration file that follows.

The /etc/syslog-ng/syslog-ng.conf file

The main configuration file for syslog-ng is the /etc/syslog-ng/sylog-ng.conf file but only rudimentary help on its keywords can be found using the Linux man pages.

[root@bigboy tmp]# man syslog-ng.conf 

Don't worry, we'll soon explore how much more flexible syslog-ng can be when compared to regular syslog. 

Simple Server Side Configuration for Remote Clients

Figure 5-1 has a sample syslog-ng.conf file and outlines some key features. The options section that covers global characteristics is fully commented, but it is the source, destination and log sections that define the true strength of the customizability of syslog-ng.

Figure 5-1 A Sample syslog-ng.conf File

options {            # Number of syslog lines stored in memory before being written to files           sync (0);            # Syslog-ng uses queues           log_fifo_size (1000);            # Create log directories as needed           create_dirs (yes);            # Make the group "logs" own the log files and directories           group (logs);           dir_group (logs);            # Set the file and directory permissions           perm (0640);           dir_perm (0750);            # Check client hostnames for valid DNS characters           check_hostname (yes);            # Specify whether to trust hostname in the log message.           # If "yes", then it is left unchanged, if "no" the server replaces           # it with client's DNS lookup value.           keep_hostname (yes);            # Use DNS fully qualified domain names (FQDN)            # for the names of log file folders           use_fqdn (yes);           use_dns (yes);            # Cache DNS entries for up to 1000 hosts for 12 hours           dns_cache (yes);           dns_cache_size (1000);           dns_cache_expire (43200);          };   # Define all the sources of localhost generated syslog # messages and label it "d_localhost" source s_localhost {           pipe ("/proc/kmsg" log_prefix("kernel: "));           unix-stream ("/dev/log");           internal(); };   # Define all the sources of network generated syslog # messages and label it "d_network" source s_network {           tcp(max-connections(5000));           udp(); };  # Define the destination "d_localhost" log directory destination d_localhost {            file ("/var/log/syslog-ng/$YEAR.$MONTH.$DAY/localhost/$FACILITY.log"); };  # Define the destination "d_network" log directory destination d_network {           file ("/var/log/syslog-ng/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log"); };  # Any logs that match the "s_localhost" source should be logged # in the "d_localhost" directory  log { source(s_localhost);       destination(d_localhost); };  # Any logs that match the "s_network" source should be logged # in the "d_network" directory   log { source(s_network);        destination(d_network); }; 

In our example, the first set of sources is labeled s_localhost. It includes all system messages sent to the Linux /dev/log device, which is one of syslog's data sources, all messages that syslog-ng views as being of an internal nature and additionally inserts the prefix "kernel" to all messages it intercepts on their way to the /proc/kmsg kernel message file.

Unlike a regular syslog server which listens for client messages on UDP port 514, syslog-ng also listens on TCP port 514. The second set of sources is labeled s_network and includes all syslog messages obtained from UDP sources and limits TCP syslog connections to 5000. Limiting the number of connections to help regulate system load is a good practice in the event that some syslog client begins to inundate your server with messages.

Our example also has two destinations for syslog messages, one named d_localhost, the other, d_network. These examples show the flexibility of syslog-ng in using variables. The $YEAR, $MONTH and $DAY variables map to the current year, month and day in YYYY, MM and DD format respectively. Therefore the example:


refers to a directory called /var/log/syslog-ng/2005.07.09 when messages arrive on July 9, 2005. The $HOST variable refers to the hostname of the syslog client and will map to the client's IP address if DNS services are deactivated in the options section of the syslog-ng.conf file. Similarly the $FACILITY variable refers to the facility of the syslog messages that arrive from that host.

Using syslog-ng in Large Data Centers

Figure 5-2 has a sample syslog-ng.conf file snippet that defines some additional features that may be of interest in a data center environment.

Figure 5-2 More Specialized syslog-ng.conf Configuration

options {            # Number of syslog lines stored in memory before being written to files           sync (100); };   # Define all the sources of network generated syslog # messages and label it "s_network_1" source s_network_1 {           udp(ip( port(514)); };  # Define all the sources of network generated syslog # messages and label it "s_network_2" source s_network_2 {           udp(ip( port(514)); };  # Define the destination "d_network_1" log directory destination d_network_1 {           file ("/var/log/syslog-ng/servers/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log"); };  # Define the destination "d_network_2" log directory destination d_network_2 {           file ("/var/log/syslog-ng/network/$YEAR.$MONTH.$DAY/$HOST/$FACILITY.log"); };  # Define the destination "d_network_2B" log directory destination d_network_2B {           file ("/var/log/syslog-ng/network/all/network.log"); };  # Any logs that match the "s_network_1" source should be logged # in the "d_network_1" directory  log { source(s_network_1);       destination(d_network_1); };  # Any logs that match the "s_network_2" source should be logged # in the "d_network_2" directory  log { source(s_network_2);       destination(d_network_2); };  # Any logs that match the "s_network_2" source should be logged # in the "d_network_2B" directory also  log { source(s_network_2);       destination(d_network_2B); }; 

In this case we have configured syslog to:

  1. Listen on IP address as defined in the source s_network_1. Messages arriving at this address will be logged to a subdirectory of /var/log/syslog-ng/servers/ arranged by date as specified by destination d_network_1. As you can guess, this address and directory be used by all servers in the data center.
  2. Listen on IP address as defined in the source s_network_2. Messages arriving at this address will be logged to a subdirectory of /var/log/syslog-ng/network/ arranged by date as specified by d_network_2. This will be the IP address and directory to which network devices would log.
  3. Listen on IP address as defined in the source s_network_2. Messages arriving at this address will also be logged to file /var/log/syslog-ng/all/debug.log as part of destination d_network_2B.This will be a single file to which all network devices would log. Server failures are usually isolated to single servers whereas network failures are more likely to be cascading involving many devices. The advantage of searching a single file is that it makes it easier to determine the exact sequence of events.
  4. As there could be many devices logging to the syslog-ng server, the sync option is set to write data to disk only after receiving 100 syslog messages. Constant receipt of syslog messages can have a significant impact on your system's disk performance. This option allows you to queue the messages in memory for less frequent disk updates.

Now that you have an understanding of how to configure syslog-ng it's time to see how you install it.

Installing syslog-ng

You can install syslog-ng using one of two methods depending on your version of Linux.

Using RPM Files

The syslog-ng and rsyslog packages cannot be installed at the same time. You have to uninstall one in order for the other to work. Here's how you can install syslog-ng using RPM package files. 1. Uninstall rsyslog using the rpm command. There are some other RPMs that rely on rsyslog so you will have to do this while ignoring any dependencies with the –nodeps flag.

[root@bigboy tmp]# rpm -e --nodeps rsyslog 

2. Install syslog-ng using yum.

[root@bigboy tmp]# yum -y install syslog-ng 

3. Start the new syslog-ng daemon immediately and make sure it will start on the next reboot.

[root@bigboy tmp]# chkconfig syslog-ng on [root@bigboy tmp]# service syslog-ng start Starting syslog-ng: [  OK  ] [root@bigboy tmp]# 

Your new syslog-ng package is now up and running and ready to go!

Using tar files

The most recent syslog-ng and its companion eventlog tar files can be downloaded from the www.balabit.com website. The installation procedure is straightforward, but you will need to have the Linux gcc C programming language compiler preinstalled to be successful. Here are the steps.

1. Download the tar files from the BalaBit website. In this case we have browsed the website beforehand and know the exact URLs to use with the wget command.

[root@zippy tmp]# wget http://www.balabit.com/downloads/syslog-ng/2.0/src/eventlog-0.2.5.tar.gz --12:34:17--  wget http://www.balabit.com/downloads/syslog-ng/2.0/src/eventlog-0.2.5.tar.gz            => `eventlog-0.2.5.tar.gz' ... ... ...  12:34:19 (162.01 KB/s) - `eventlog-0.2.5.tar.gz' saved [345231]  [root@zippy tmp]# wget http://www.balabit.com/downloads/syslog-ng/2.0/src/syslog-ng-2.0.0.tar.gz --12:24:21--  wget http://www.balabit.com/downloads/syslog-ng/2.0/src/syslog-ng-2.0.0.tar.gz            => ` syslog-ng-2.0.0.tar.gz' ... ... ...  12:24:24 (156.15 KB/s) - ` syslog-ng-2.0.0.tar.gz' saved [383589]  [root@zippy tmp]# 

2. Install the prerequisite glib libraries.

[root@zippy tmp]# yum -y install glib  

3. Using the tar command we extract the files in the pre-requisite eventlog archive and then use the configure; make and make install commands to install them correctly. Pay special attention to the output of the configure command to make sure that all the pre-installation tests are passed. If not, install the packages the error messages request and then start again.

[root@zippy tmp]# tar -xzf eventlog-0.2.5.tar.gz [root@zippy tmp]# cd eventlog-0.2.5 [root@zippy eventlog-0.2.5]# ./configure checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes ... ... ... [root@zippy eventlog-0.2.5]# make Making all in utils make[1]: Entering directory `/tmp/eventlog-0.2.5/utils' sed -e "s,_SCSH_,/usr/bin/scsh," make_class.in >make_class ... ... ... [root@zippy eventlog-0.2.5]# make install Making install in utils make[1]: Entering directory `/tmp/eventlog-0.2.5/utils' make[2]: Entering directory `/tmp/eventlog-0.2.5/utils' ... ... ... make[2]: Leaving directory `/tmp/eventlog-0.2.5' make[1]: Leaving directory `/tmp/eventlog-0.2.5' [root@zippy eventlog-0.2.5]#  

4. The next step is to install the prerequisite glib package on your system.

[root@zippy eventlog-0.2.5]# yum -y install glib 

5. Some environmental variables also need to be set prior to the installation of the syslog-ng files.

[root@zippy eventlog-0.2.5]# PKG_CONFIG_PATH=/usr/local/lib/pkgconfig/ [root@zippy eventlog-0.2.5]# export PKG_CONFIG_PATH  

6. Using the tar command we extract the files in the pre-requisite syslog-ng archive and then use the configure, make clean, make and make install commands to install them correctly. In this case we the --sysconfdir directive with the configure command to make sure syslog-ng searches for its configuration file in the /etc directory. Once again, pay close attention to the pre-installation tests that the configure command executes.

[root@zippy eventlog-0.2.5]# cd /tmp [root@zippy tmp]# tar -xzf syslog-ng-2.0.0.tar.gz [root@zippy tmp]# cd syslog-ng-2.0.0 [root@zippy syslog-ng-2.0.0]# make clean [root@zippy syslog-ng-2.0.0]# ./configure --sysconfdir=/etc checking for a BSD-compatible install... /usr/bin/install -c checking whether build environment is sane... yes ... ... ... [root@zippy syslog-ng-2.0.0]# make; make install Making all in src make[1]: Entering directory `/tmp/ syslog-ng-2.0.0/src' ... ... ... [root@zippy syslog-ng-2.0.0]#  

7. The installation has template init.d/syslog-ng scripts and syslog-ng.conf files in the contribs/ directory.

[root@zippy syslog-ng-2.0.0]# ls contrib/ fedora-packaging  init.d.RedHat-7.3      init.d.SuSE Makefile.in       rhel-packaging         syslog-ng.conf.HP-UX syslog-ng.vim     init.d.HP-UX           init.d.solaris      Makefile          README                 syslog2ng            init.d.RedHat     syslog-ng.conf.RedHat  init.d.SunOS Makefile.am       relogger.pl            syslog-ng.conf.doc   syslog-ng.conf.SunOS [root@zippy syslog-ng-2.0.0]#  

8. Copy the versions for your operating system to the /etc/init.d and /etc , /etc/logrotate.d , /etc/sysconfig directories. The /etc/syslog-ng/ directory needs to be created beforehand. Redhat and Fedora installations have their own subdirectories contrib/.

[root@zippy syslog-ng-2.0.0]# mkdir /etc/syslog-ng/ [root@zippy syslog-ng-2.0.0]# cp contrib/fedora-packaging/syslog-ng.init \    /etc/init.d/syslog-ng [root@zippy syslog-ng-2.0.0]# cp contrib/fedora-packaging/syslog-ng.conf \    /etc [root@zippy syslog-ng-2.0.0]# cp contrib/fedora-packaging/syslog-ng.sysconfig \    /etc/sysconfig/syslog-ng [root@zippy syslog-ng-2.0.0]# cp contrib/fedora-packaging/syslog-ng.logrotate \    /etc/logrotate.d/syslog-ng 

Remember that you may want to customize your syslog-ng.conf file.

9. Change the permissions on your new /etc/inid.d/syslog-ng file.

[root@zippy syslog-ng-2.0.0]# chmod 755 /etc/init.d/syslog-ng 

10. You need to be careful. The init.d script may refer to a syslog-ng binary file that's in an incorrect location. Find its true location and edit the script.

[root@zippy syslog-ng-2.0.0]# updatedb [root@zippy syslog-ng-2.0.0]# locate syslog-ng | grep bin /usr/local/sbin/syslog-ng [root@zippy syslog-ng-2.0.0]# vi /etc/init.d/syslog-ng ... #exec="/sbin/syslog-ng" exec="/usr/local/sbin/syslog-ng" ... :wq [root@zippy syslog-ng-2.0.0]# 

11. Next create the /etc/syslog-ng directory for the configuration files and the /var/log/syslog-ng directory for the log files.

[root@zippy syslog-ng-2.0.0]# chkconfig syslog off [root@zippy syslog-ng-2.0.0]# chkconfig syslog-ng on [root@zippy syslog-ng-2.0.0]# service syslog stop Shutting down kernel logger: [  OK  ] Shutting down system logger: [  OK  ] [root@zippy syslog-ng-2.0.0]# service syslog-ng start syslog-ng: unrecognized service [root@zippy syslog-ng-2.0.0]#  

12. The sample syslog-ng.conf file in Figure 5-1 was configured to have all directories owned by the group logs. This user group needs to be created and any users that need access to the directories need to added to this group using the usermod command. In this case the user peter is added to the group and the groups command is used to verify success.

[root@zippy tmp]# groupadd logs [root@zippy tmp]# usermod -G logs peter [root@zippy tmp]# groups peter peter: users logs [root@zippy tmp]# usermod -G logs peter 

13. You can now configure syslog-ng to start on the next reboot with the chkconfig command and then use the service command to start it immediately. Remember to stop the old syslog process beforehand.

[root@zippy tmp]# service syslog stop Shutting down kernel logger: [  OK  ] Shutting down system logger: [  OK  ] [root@zippy tmp]# chkconfig syslog off [root@zippy tmp]# chkconfig syslog-ng on [root@zippy tmp]# service syslog-ng start Starting system logger: [  OK  ] Starting kernel logger: [  OK  ] [root@zippy tmp]# 

14. Now, your remote hosts should log begin logging to the /var/log/syslog-ng directory. According to our preliminary configuration file, there should be sub-directories categorized by date inside it. Each of these sub-directories in turn will have directories beneath them named after the IP address and/or hostname of the various remote syslog clients and will contain files categorized by syslog facility. In this example we see that the 2005.07.09 directory as received messages from three hosts,, and localhost.

[root@zippy tmp]# ls /var/log/syslog-ng/ 2005.07.09 [root@zippy tmp]# ll /var/log/syslog-ng/2005.07.09/ drwxr-x---  2 root  logs  4096 Jul  9 17:01 192-168-1-1.my-web-site.org drwxr-x---  2 root  logs  4096 Jul  9 16:45 192-168-1-99.my-web-site.org drwxr-x---  2 root  logs  4096 Jul  9 23:24 LOGGER [root@zippy tmp]# ls /var/log/syslog-ng/2005.07.09/localhost/ cron.log  kern.log  local7.log  syslog.log [root@zippy tmp]# 

Using syslog-ng your system can now be used as a much more customizable tool to help troubleshoot devices attached to your network. Each day syslog-ng will automatically create new sub-directories to match the current date and at the end of each calendar quarter the files will be moved to a special archive directory containing all the data for the previous three months. This archived data can then be periodically deleted as needed. For very large deployments, or for better searching and correlation capabilities, it is possible to send the output of syslog-ng to a SQL type database. This is beyond the scope of this book, but it is a worthwhile feature to keep in mind.

Configuring syslog-ng Clients

Clients logging to the syslog-ng server don't need to have syslog-ng installed on them, a regular syslog client configuration will suffice.

If you are running syslog-ng on clients, then you'll need to modify your configuration file. Let's look at Example 5-1 – Syslog-ng Sample Client Configuration.

Example 5-1 - Syslog-ng Sample Client Configuration

source s_sys {    file ("/proc/kmsg" log_prefix("kernel: "));    unix-stream ("/dev/log");    internal(); };  destination loghost {     udp("loghost.linuxhomenetworking.com");  };  filter notdebug {     level(info...emerg);  };  log {     source(local);    filter(notdebug);    destination(loghost);  }; 

The s_sys source comes default in many syslong-ng.conf files, we have just added some additional parameters to make it work. Here the destination syslog logging server is defined as loghost.linuxhomenetworking.com. We have also added a filter to the log section to make sure only the most urgent messages, info level and above (not debug), get logged to the remote server. After restarting syslong-ng on your client, your syslog server will start receiving messages.