Red Hat Linux 8.
Red Hat Linux 8.0: The Official Red Hat Linux Reference Guide Copyright © 2002 by Red Hat, Inc. Red Hat, Inc. 1801 Varsity Drive Raleigh NC 27606-2072 USA Phone: +1 919 754 3700 Phone: 888 733 4281 Fax: +1 919 754 3701 PO Box 13588 Research Triangle Park NC 27709 USA rhl-rg(EN)-8.0-Print-RHI (2002-08-14T22:29-0400) Copyright © 2002 by Red Hat, Inc. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, V1.
Table of Contents Introduction....................................................................................................................................... vii 1. Changes To This Manual .................................................................................................... vii 2. Finding Appropriate Documentation .................................................................................viii 2.1. Documentation For First-Time Linux Users...........................................
6.4. Runlevels............................................................................................................ 103 6.5. Fonts................................................................................................................... 105 6.6. Additional Resources ......................................................................................... 106 II. Security Reference ................................................................................................................
III. Network Services Reference .................................................................................................... 157 12. Network Scripts .............................................................................................................. 159 12.1. Network Configuration Files............................................................................ 159 12.2. Interface Configuration Files ........................................................................... 159 12.3.
IV. Appendixes ................................................................................................................................ 267 A. General Parameters and Modules .................................................................................... 269 A.1. Specifying Module Parameters ......................................................................... 269 A.2. CD-ROM Module Parameters........................................................................... 270 A.3.
Introduction Welcome to the Official Red Hat Linux Reference Guide. The Official Red Hat Linux Reference Guide contains useful information about your Red Hat Linux system. From fundamental concepts, such as the structure of the Red Hat Linux file system, to the finer points of system security and authentication control, we hope you will find this book to be a valuable resource. This guide is for you if you want to learn a bit more about how your Red Hat Linux system works.
viii Introduction Note Although this manual reflects the most current information possible, you should read the Red Hat Linux Release Notes for information that may not have been available prior to our documentation being finalized. The Release Notes can be found on the Red Hat Linux CD #1 and online at the following URL: http://www.redhat.com/docs/manuals/linux 2. Finding Appropriate Documentation You need documentation that is appropriate to your level of Linux expertise.
Introduction ix • An explanation of how Linux works — While delving into the most arcane aspects of the Linux kernel is not necessary, it is a good idea to know something about how Linux is put together. This is particularly important if you have been working with other operating systems, as some of the assumptions you currently hold about how computers work may not transfer from that operating system to Linux.
x Introduction 2.1.3. Beginning Linux Books • Red Hat Linux for Dummies, 2nd Edition by Jon "maddog" Hall; IDG • Special Edition Using Red Hat Linux by Alan Simpson, John Ray and Neal Jamison; Que • Running Linux by Matt Welsh and Lar Kaufman; O’Reilly & Associates • Red Hat Linux 7 Unleashed by William Ball and David Pitts; Sams The books suggested here are excellent primary sources of information for basic knowledge about a Red Hat Linux system.
Introduction xi displayed in a different style on their own (such as filenames). In these cases, they are considered to be part of the command, so the entire phrase will be displayed as a command. For example: Use the cat testfile command to view the contents of a file, named testfile, in the current working directory. filename Filenames, directory names, paths, and RPM package names are represented this way.
xii Introduction button on a GUI screen or window This style indicates that the text will be found on a clickable button on a GUI screen. For example: Click on the Back button to return to the webpage you last viewed. computer output When you see text in this style, it indicates text displayed by the computer on the command line. You will see responses to commands you typed in, error messages, and interactive prompts for your input during scripts or programs shown this way.
Introduction xiii Important If you modify the DHCP configuration file, the changes will not take effect until you restart the DHCP daemon. Caution Do not perform routine tasks as root — use a regular user account unless you need to use the root account for system administration tasks. Warning If you choose not to partition manually, a server installation will remove all existing partitions on all installed hard drives.
xiv Introduction 6.1. We Need Feedback! If you find an error in the Official Red Hat Linux Reference Guide, or if you have thought of a way to make this manual better, we’d love to hear from you! Please submit a report in Bugzilla (http://bugzilla.redhat.com/bugzilla) against the component rhl-rg. Be sure to mention the manual’s identifier: rhl-rg(EN)-8.0-Print-RHI (2002-08-14T22:29-0400) If you mention the manual’s identifier, we will know exactly which version of the guide you have.
System Reference
Chapter 1. File System Structure 1.1. Why Share a Common Structure? An operating system’s file system structure is its most basic level of organization. Almost all of the ways an operating system interacts with its users, applications, and security model are dependent upon the way it stores its files on a storage device. It is crucial for a variety of reasons that users, as well as programs, be able to refer to a common guideline to know where to read and write files.
Chapter 1. File System Structure 1.2.1. FHS Organization The directories and files noted here are a small subset of those specified by the FHS document. Check the latest FHS document for the most complete information. 1.2.1.1. The /dev Directory The /dev directory contains file system entries which represent devices that are attached to the system. These files are essential for the system to function properly. 1.2.1.2.
Chapter 1. File System Structure 19 1.2.1.6. The /proc Directory The /proc directory contains special "files" that either extract information from or send information to the kernel. Due to the great variety of data available within /proc and the many ways this directory can be used to communicate with the kernel, an entire chapter has been devoted to the subject. For more information, please see Chapter 2. 1.2.1.7. The /sbin Directory The /sbin directory is for executables used only by the root user.
Chapter 1. File System Structure that are not designed to be directly utilized by users or shell scripts. The libexec directory contains small helper programs called by other programs, sbin is for system administration binaries (those that do not belong in /sbin), share contains files that are not architecture-specific, src is for source code, and X11R6 is for the X Window System (XFree86 on Red Hat Linux). 1.2.1.9.
Chapter 1. File System Structure |||||+- ||||- 21 named nis opt preserve run spool |- anacron |- at |- cron |- fax |- lpd |- mail |- mqueue |- news |- rwho |- samba |- slrnpull |- squid |- up2date |- uucp |- uucppublic |- vbox |- voice tmp tux www yp System log files such as messages and lastlog go in /var/log. The /var/lib/rpm directory also contains the RPM system databases. Lock files go in /var/lock, usually in directories particular for the program using the file.
Chapter 1. File System Structure The /var/spool/up2date/ directory contains files used by Red Hat Update Agent, including RPM header information for the system. This location may also be used to temporarily store RPMs downloaded while updating your system. For more information on Red Hat Network, see the Red Hat Network website at https://rhn.redhat.com/. Another location specific to Red Hat Linux is the /etc/sysconfig/ directory. This directory stores a variety of configuration information.
Chapter 2. The proc File System The Linux kernel has two primary functions: to control access to physical devices on the computer and to schedule when and how processes interact with these devices. The /proc/ directory contains a hierarchy of special files which represent the current state of the kernel — allowing applications and users to peer into the kernel’s view of the system.
Chapter 2. The proc File System 24 When viewing different virtual files in the /proc/ file system, you will notice some of the information is easily understandable while some is not human-readable. This is in part why utilities exist to pull data from virtual files and display it in a useful way. Some examples of such applications are lspci, apm, free, and top. Note Some of the virtual files in the /proc/ directory are only readable by the root user. 2.1.2.
Chapter 2. The proc File System 25 Running the apm -v command on such a system results in output similar to this: APM BIOS 1.2 (kernel driver 1.16) AC on-line, no system battery For systems which do not use a battery as a power source, apm is able do little more than put the machine in standby mode. The apm command is much more useful on laptops. For example, the following output is from the command cat /proc/apm on a laptop running Red Hat Linux while plugged into a power outlet: 1.16 1.
Chapter 2. The proc File System 26 • processor — Provides each processor with an identifying you will only see a 0. number. If you only have one processor, — Authoritatively tells you the type of processor you have in the system. If your computer is an Intel-based system, simply place the number in front of "86" to determine the value. This is particularly helpful if you are wondering about the architecture of an older system such as the 586, 486, or 386.
Chapter 2. The proc File System 27 The other difference is that block devices can send and receive information in blocks of a size configured per device. Character devices send data with no preconfigured size. For more information about devices see /usr/src/linux-2.4/Documentation/devices.txt. 2.2.5. /proc/dma This file contains a list of the registered ISA direct memory access (DMA) channels in use. A sample /proc/dma files looks like this: 4: cascade 2.2.6.
Chapter 2. The proc File System 28 The first column signifies whether the file system is mounted on a block device. Those beginning with nodev are not mounted on a device. The second column lists the name of the file systems supported. The mount command cycles through these file systems when one is not specified as an argument. 2.2.9. /proc/interrupts This file records the number of interrupts per IRQ on the x86 architecture.
Chapter 2. The proc File System 29 2.2.10.
Chapter 2. The proc File System 30 2.2.12. /proc/isapnp This file lists Plug and Play (PnP) cards in ISA slots on the system. This is most often seen with sound cards but may include any number of devices. A /proc/isapnp file with Soundblaster entry in it looks similar to this: Card 1 ’CTL0070:Creative ViBRA16C PnP’ PnP version 1.0 Product version 1.
Chapter 2. The proc File System 31 2.2.14. /proc/kmsg This file is used to hold messages generated by the kernel. These messages are then picked up by other programs, such as /sbin/klogd. 2.2.15. /proc/ksyms This file holds the kernel exported symbol definitions used by the module tools to dynamically link and bind loadable modules.
Chapter 2. The proc File System 32 2.2.18. /proc/mdstat This file contains the current information for multiple-disk, RAID configurations. If your system does not contain such a configuration, then your /proc/mdstat file will look similar to this: Personalities : read_ahead not set unused devices: none This file remains in the state above unless you create a software RAID or md device.
Chapter 2. The proc File System • MemFree — The amount of physical RAM, in kilobytes, left unused by the system. • MemShared versions. • Buffers 33 — Unused with 2.4 and higher kernels but left in for compatibility with earlier kernel — The amount of physical RAM, in kilobytes, used for file buffers. • Cached — The amount of physical RAM, in kilobytes, used as cache memory. • Active — The total amount of buffer or page cache memory, in kilobytes, that is in active use. • Inact_dirty available.
Chapter 2. The proc File System 34 (0). The final column states if the module can unload itself automatically after a period without use (autoclean) or if it is not being utilized (unused). Any module with a line containing a name listed in brackets ([ or ]) tells you that this module depends upon another module to be present in order to function. 2.2.22.
Chapter 2. The proc File System 35 2.2.25. /proc/pci This file contains a full listing of every PCI device on your system. Depending on the number of PCI devices you have, /proc/pci can get rather long. An example from this file on a basic system looks similar to this: Bus 0, device 0, function 0: Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge (rev 3). Master Capable. Latency=64. Prefetchable 32 bit memory at 0xe4000000 [0xe7ffffff].
Chapter 2. The proc File System 36 2.2.26. /proc/slabinfo This file gives information about memory usage on the slab level. Linux kernels greater than 2.2 use slab pools to manage memory above the page level. Commonly used objects have their own slab pools. The following is a portion of a typical /proc/slabinfo virtual file: slabinfo - version: 1.
Chapter 2. The proc File System 37 2.2.28. /proc/swaps This file measures swap space and its utilization. For a system with only one swap partition, the output of /proc/swap may look similar to this: Filename /dev/hda6 Type partition Size 136512 Used 20024 Priority -1 While some of this information can be found in other files in the /proc/ directory, /proc/swap provides a snapshot of every swap filename, type of swap space, the total size, and the amount of this space that is in use (in kilobytes).
Chapter 2. The proc File System 38 These directories are called process directories, as they are named after a program’s process ID and contain information specific to that process. The owner and group of each process directory is set to the user running the process. When the process is terminated, its /proc/ process directory vanishes. Each process directory contains the following files: • cmdline — This file contains the command issued when starting the process.
Chapter 2. The proc File System 39 4. Number of pages are code 5. Number of pages of data/stack 6. Number of pages of library 7. Number of dirty pages — The status of the process in a more readable form than stat or statm.
Chapter 2. The proc File System 40 So, for example, a system with a USB bus but no USB devices connected to it has a /proc/bus/usb/ directory containing several files: total 0 dr-xr-xr-x -r--r--r--r--r--r-- 1 root 1 root 1 root root root root 0 May 0 May 0 May 3 16:25 001 3 16:25 devices 3 16:25 drivers The /proc/bus/usb/ directory contains files that track the various devices on any USB buses, as well as the drivers required to use them.
Chapter 2. The proc File System 41 2.3.5. /proc/ide/ This directory holds information about IDE devices on the system. Each IDE channel is represented as a separate directory, such as /proc/ide/ide0 and /proc/ide/ide1. In addition, a drivers file is also available, providing the version number of the various drivers used on the IDE channels: ide-cdrom version 4.59 ide-floppy version 0.97 ide-disk version 1.
Chapter 2. The proc File System 42 • model — The model name or number of the device. — A collection of current parameters of the device. This file usually contains quite a bit of useful, technical information.
Chapter 2. The proc File System • dev_mcast • igmp 43 — Displays the various Layer2 multicast groups each device is listening to. — Lists the IP multicast addresses which this system joined. • ip_fwchains — • ip_fwnames If ipchains are in use, this virtual file reveals any current rule. — If ipchains are in use, this virtual file lists all firewall chain names. • ip_masquerade — • ip_mr_cache — • ip_mr_vif Provides a table of masquerading information under ipchains.
Chapter 2. The proc File System megaraid directories are present, as those two drivers are being utilized. The files in each of the directories typically contain IO address range, IRQ, and statistics for the particular SCSI controller using that driver. Each controller can report a different type and amount of information. The Adaptec AIC-7880 Ultra SCSI host adapter’s file in this example system produces the following output: Adaptec AIC7xxx driver version: 5.1.20/3.2.
Chapter 2. The proc File System 45 controller is communicating with the CD-ROM at 20 megabytes per second, while the tape drive is only connected at 10 megabytes per second. 2.3.9. /proc/sys/ The /proc/sys/ directory is different from others in /proc/ because it not only provides information about the system but also allows you to make configuration changes to the kernel. This allows the administrator of the machine to immediately enable and disable kernel features.
Chapter 2. The proc File System 46 Note Any configuration changes you make using the echo command will disappear when the system is restarted. To make your configuration changes take effect at the time the system is booted, see Section 2.4. The /proc/sys/ directory contains several subdirectories controlling different aspects of a running kernel. 2.3.9.1. /proc/sys/dev/ This directory provides parameters for particular devices on the system.
Chapter 2. The proc File System • dentry-state — 47 Provides the status of the directory cache. The file looks similar to this: 57411 52939 45 0 0 0 The first number reveals the total number of directory cache entries, while the second number displays the number of unused entries. The third number tells the number of seconds between when a directory has been freed and when it can be reclaimed, and the fourth measures the pages currently requested by the system.
Chapter 2. The proc File System 48 processes are stored in non-swappable kernel memory. Any increase in msgmax would increase RAM requirements for the system. • msgmnb — Sets the maximum number of bytes in a single message queue. The default is 16384. • msgmni — Sets the maximum number of message queue identifiers. The default is 16. • osrelease — Lists the Linux kernel release number. This file can only be altered by changing the kernel source and recompiling.
Chapter 2. The proc File System • threads-max value of 2048. 49 — Sets the maximum number of threads to be used by the kernel, with a default • version — Displays the date and time the kernel was last compiled. The first field in this file, such as #3, relates to the number of times a kernel was built from the source base. The random directory stores a number of values related to generating random numbers for the kernel. 2.3.9.4.
Chapter 2. The proc File System 50 • icmp_echo_ignore_all and icmp_echo_ignore_broadcasts — Allows the kernel to ignore ICMP ECHO packets from every host or only those originating from broadcast and multicast addresses, respectively. A value of 0 allows the kernel to respond, while a value of 1 ignores the packets. • ip_default_ttl — Sets the default Time To Live (TTL), which limits the number of hops a packet may make before reaching its destination.
Chapter 2. The proc File System 51 — Sets various values concerned with the kernel swap-out daemon, kswapd. This file has three values: • kswapd 512 32 8 The first value sets the maximum number of pages that kswapd will attempt to free in a single attempt. The larger this number, the more aggressively the kernel can move to free pages. The second value sets the minimum number of times that kswapd attempts to free a page.
Chapter 2. The proc File System 52 pty_master pty_slave pty_master /dev/vc/0 /dev/ptmx /dev/console /dev/tty unknown /dev/ptm /dev/ttyp /dev/pty /dev/vc/0 /dev/ptmx /dev/console /dev/tty /dev/vc/%d 128 3 2 4 5 5 5 4 0-255 0-255 0-255 0 2 1 0 1-63 pty:master pty:slave pty:master system:vtmaster system system:console system:/dev/tty console The /proc/tty/driver/serial file lists the usage statistics and status of each of the serial tty lines.
Chapter 2. The proc File System 53 2.5. Additional Resources Below are additional sources of information about /proc/. 2.5.1. Installed Documentation Most of the best /proc/ documentation is available on your system. • /usr/src/linux-2.4/Documentation/filesystems/proc.txt limited, information about all aspects of the /proc/ directory. • /usr/src/linux-2.4/Documentation/sysrq.txt options. — Contains assorted, but — An overview of System Request Key • /usr/src/linux-2.
Chapter 2.
Chapter 3. Boot Process, Init, and Shutdown An important and powerful aspect of Red Hat Linux is the open method it uses for starting and stopping the operating system. During boot time, Red Hat Linux loads programs in a specific and configurable order. Once booted, you are free to change the configuration files controlling the boot process as well as the configuration files for the programs started at boot-time.
Chapter 3. Boot Process, Init, and Shutdown Once loaded, the BIOS tests the system, looks for and checks peripherals and then locates a valid device with which to boot the system. Usually, it first checks any floppy drives and CD-ROM drives present for bootable media, then it looks to the system’s hard drives. The order of the drives searched for booting can often be controlled with a setting in BIOS.
Chapter 3. Boot Process, Init, and Shutdown 57 If you need to alter the command line arguments to the kernel, see Chapter 4. For information on changing the runlevel at the GRUB or LILO prompt, see Section 3.5. Once the second stage boot loader has determined which kernel to boot, it locates the corresponding kernel binary in the /boot/ directory. The proper binary is the /boot/vmlinuz-2.4.x-xx file that corresponds to the boot loader’s settings.
Chapter 3. Boot Process, Init, and Shutdown Next, the init command sets the source function library, /etc/rc.d/init.d/functions, for the system. This spells out how to start or kill a program and how to determine the PID of a program. The init program starts all of the background processes by looking in the appropriate rc directory for the runlevel specified as default in /etc/inittab. The rc directories are numbered to corresponds to the runlevel they represent. For instance, /etc/rc.d/rc5.
Chapter 3. Boot Process, Init, and Shutdown 59 S40atd -> ../init.d/atd S45pcmcia -> ../init.d/pcmcia S55sshd -> ../init.d/sshd S56rawdevices -> ../init.d/rawdevices S56xinetd -> ../init.d/xinetd S60lpd -> ../init.d/lpd S75keytable -> ../init.d/keytable S80isdn -> ../init.d/isdn S80sendmail -> ../init.d/sendmail S85gpm -> ../init.d/gpm S90canna -> ../init.d/canna S90crond -> ../init.d/crond S90FreeWnn -> ../init.d/FreeWnn S90xfs -> ../init.d/xfs S95anacron -> ../init.d/anacron S95firstboot -> ../init.
Chapter 3. Boot Process, Init, and Shutdown After the init command has progressed through the appropriate rc directory for the runlevel, the /etc/inittab script forks a getty process for each virtual console (login prompts) allocated to the runlevel. Runlevels 2 through 5 get all six virtual consoles, while runlevel 1 (single user mode) gets only one and runlevels 0 and 6 get none.
Chapter 3. Boot Process, Init, and Shutdown 61 The init.d directory contains the scripts used by the init command when controlling services. Each of the numbered directories represent the six default runlevels configured by default under Red Hat Linux. For more information on runlevels, see Section 3.6. The default runlevel is listed in /etc/inittab.
Chapter 3. Boot Process, Init, and Shutdown them to quickly move in and out of their custom configuration without disturbing the normal set of features at the standard runlevels. If your machine gets into a state where it will not boot due to a bad /etc/inittab or will not let you log in because you have a corrupted /etc/passwd or if you have simply forgotten your password, you can boot into single-user mode.
Chapter 3. Boot Process, Init, and Shutdown 3.7.1.
Chapter 3. Boot Process, Init, and Shutdown • vncservers • xinetd It is possible that your system may be missing a few of them if the corresponding program that would need that file is not installed. Next, we will take a look at each one. 3.7.1.1. /etc/sysconfig/amd The /etc/sysconfig/amd file contains various parameters used by amd allowing for the automounting and automatic unmounting of file systems. 3.7.1.2.
Chapter 3. Boot Process, Init, and Shutdown 65 3.7.1.5. /etc/sysconfig/clock The /etc/sysconfig/clock file controls the interpretation of values read from the system clock. Earlier releases of Red Hat Linux used the following values (which are deprecated): • CLOCKMODE= value , where value is one of the following: • GMT — Indicates that the clock is set to Universal Time (Greenwich Mean Time). • ARC — Indicates the ARC console’s 42-year time offset is in effect (for Alpha-based systems only).
Chapter 3. Boot Process, Init, and Shutdown 3.7.1.9. /etc/sysconfig/gpm The /etc/sysconfig/gpm file is used to pass arguments to the gpm daemon at boot time. The gpm daemon is the mouse server which allows mouse acceleration and middle-click pasting. For more information about what parameters you can use in this file, type man gpm. By default, it sets the mouse device to /dev/mouse. 3.7.1.10. /etc/sysconfig/harddisks The /etc/sysconfig/harddisks file allows you to tune your hard drive(s).
Chapter 3. Boot Process, Init, and Shutdown 67 3.7.1.14. /etc/sysconfig/init The /etc/sysconfig/init file controls how the system will appear and function during the boot process.
Chapter 3. Boot Process, Init, and Shutdown 3.7.1.16. /etc/sysconfig/iptables Like /etc/sysconfig/ipchains, the /etc/sysconfig/iptables file stores information used by the kernel to set up packet filtering services at boot time or whenever the service is started. You should not modify this file by hand unless you are familiar with how to construct iptables rules. The simplest way to add rules is to use the /usr/sbin/lokkit command or the gnomelokkit graphical application to create your firewall.
Chapter 3. Boot Process, Init, and Shutdown 69 For example: KEYTABLE="us". The files that can be used as keytables start in /usr/lib/kbd/keymaps/i386 and branch into different keyboard layouts from there, all labeled file .kmap.gz. The first file found beneath /usr/lib/kbd/keymaps/i386that matches the KEYTABLE setting is used. 3.7.1.19. /etc/sysconfig/kudzu The /etc/sysconfig/kuzdu allows you to specify a safe probe of your system’s hardware by kudzu at boot time.
Chapter 3. Boot Process, Init, and Shutdown 3.7.1.21. /etc/sysconfig/named The /etc/sysconfig/named file is used to pass arguments to the named daemon at boot time. The named daemon is a Domain Name System (DNS) server which implements the Berkeley Internet Name Domain (BIND) version 9 distribution. This server maintains a table of which hostnames are associated with IP addresses on the network.
Chapter 3. Boot Process, Init, and Shutdown 71 3.7.1.24. /etc/sysconfig/ntpd The /etc/sysconfig/ntpd file is used to pass arguments to the ntpd daemon at boot time. The ntpd daemon sets and maintains the system clock to synchronize with an Internet standard time server. It implements version 4 of the Network Time Protocol (NTP). For more information about what parameters you can use in this file, point a browser at the following file: /usr/share/doc/ntp version /ntpd.
Chapter 3. Boot Process, Init, and Shutdown 3.7.1.28. /etc/sysconfig/redhat-config-users The /etc/sysconfig/redhat-config-users file is the configuration file for the graphical application, User Manager. Under Red Hat Linux 8.0 this file is used to filter out system users such as root, daemon, or lp. This file is edited by the Preferences => Filter system users and groups pulldown menu in the User Manager application and should not be edited by hand.
Chapter 3. Boot Process, Init, and Shutdown 73 3.7.1.33. /etc/sysconfig/squid The /etc/sysconfig/squid file is used to pass arguments to the squid daemon at boot time. The squid daemon is a proxy caching server for Web client applications. For more information on configuring a squid proxy server, use a Web browser to open the /usr/share/doc/squid! version " / directory (replace # version $ with the squid version number installed on your system).
Chapter 3. Boot Process, Init, and Shutdown It may contain the following: % & , where % value & is set to something like "1:fred", to indicate that a VNC server should be started for user fred on display :1. User fred must have set a VNC password using vncpasswd before attempting to connect to the remote VNC server. • VNCSERVERS= value Note that when you use a VNC server, your communication with it is unencrypted, and so it should not be used on an untrusted network.
Chapter 3. Boot Process, Init, and Shutdown 75 3.8. Shutting Down To shut down Red Hat Linux, issue the shutdown command. You can read the shutdown man page for complete details, but the two most common uses are: /sbin/shutdown -h now /sbin/shutdown -r now You must run shutdown as root. After shutting everything down, the -h option will halt the machine, and the -r option will reboot. Non-root users can use the reboot and halt commands to shutdown the system while in runlevels 1 through 5.
Chapter 3.
Chapter 4. Boot Loaders Before Red Hat Linux can run on a system, it must be started by special program called a boot loader. The boot loader program usually exists on the system’s primary hard drive or other media device and is responsible for loading the Linux kernel its required files, or, in some cases, other operating systems into memory. 4.1. Boot Loaders and System Architecture Each system architecture which can run Red Hat Linux uses a different boot loader.
Chapter 4. Boot Loaders The boot process used by other operating systems may differ. For example, Microsoft’s DOS and Windows operating systems, as well as various other proprietary operating systems, are loaded using a chain loading boot method. Under this method, the MBR simply points to the first sector of the partition holding the operating system. There it finds the files necessary to actually boot that operating system.
Chapter 4. Boot Loaders 79 The following command installs GRUB to the MBR of the master IDE device on the primary IDE bus, alos known as the C drive: /sbin/grub-install /dev/hda The next time you boot the system, you should see the GRUB graphical boot loader menu before the kernel loads. 4.4. GRUB Terminology One of the most important things to understand before using GRUB is how the program refers to devices, such as hard drives and partitions.
Chapter 4. Boot Loaders 4.4.2. File Names When typing commands to GRUB involving a file, such as a menu list to use when allowing the booting of multiple operating systems, it is necessary to include the file immediately after specifying the device and partition. A sample file specification to an absolute filename is organized as follows: . ( type-of-device /-. / .
Chapter 4. Boot Loaders 81 4.5.1. Menu Interface If GRUB was automatically configured by the Red Hat Linux installation program, this is the interface shown by default. A menu of operating systems or kernels preconfigured with their own boot commands are displayed as a list, ordered by name. Use the arrow keys to select an option other than the default selection and press the [Enter] key to boot it. Alternatively, a timeout period is set, so that GRUB will start loading the default option.
Chapter 4. Boot Loaders The following is a list useful commands: • boot — Boots the operating system or chain loader that has been previously specified and loaded. 0 file-name 1 — Loads the specified file as a chain loader. To grab the file at the first sector of the specified partition, use +1 as the file’s name. • chainloader • displaymem — Displays the current use of memory, based on information from the BIOS. This is useful to determine how much RAM a system has prior to booting it.
Chapter 4. Boot Loaders 83 4.7.1. Special Configuration File Commands The following commands can only be used in the GRUB menu configuration file: 7 normal-color 897 selected-color 8 — Allows for the set up specific colors to be used in the menu, where two colors are configured as the foreground and background. Use simple color names, such as red/black. For example: • color color red/black green/blue 7 • default times out.
Chapter 4. Boot Loaders This file would tell GRUB to build a menu with Red Hat Linux as the default operating system, set to autoboot it after 10 seconds. Two sections are given, one for each operating system entry, with commands specific to this system’s disk partition table. Note Note the default is specified as a number. This refers to the first title line GRUB comes across. If you want windows to be the default, change the default= value to 1.
Chapter 4. Boot Loaders 85 4.8.2. LILO vs. GRUB In general, LILO works similarly to GRUB except for three major differences: • It has no interactive command interface. • It stores information about the location of the kernel or other operating system it is to load on the MBR. • It cannot read ext2 partitions. The first point means the command prompt for LILO is not interactive and only allows one command with arguments.
Chapter 4. Boot Loaders label=linux initrd=/boot/initrd-2.4.0-0.43.6.img read-only root=/dev/hda5 other=/dev/hda1 label=dos This example shows a system configured to boot two operating systems: Red Hat Linux and DOS. Here is a deeper look at a few of the lines of this file: • boot=/dev/hda tells LILO to install itself on the first hard disk on the first IDE controller. • map=/boot/map locates the map file. In normal use, this should not be modified. • install=/boot/boot.
Chapter 4. Boot Loaders 87 In this command, replace number with either the number of the runlevel you wish to boot into (1 through 5), or the word single. If you are using GRUB as your boot loader, follow these steps: • In the graphical GRUB boot loader screen, select the Red Hat Linux boot label and press [e] to edit it. • Arrow down to the kernel line and press [e] to edit it. • At the prompt, type the number of the runlevel you wish to boot into (1 through 5), or the word single and press [Enter].
Chapter 4.
Chapter 5. Users and Groups Control of users and groups is a core element of Red Hat Linux system administration. Users can be either people, meaning accounts tied to physical users, or logical users, meaning accounts which exist for specific applications to use. Both types of users have a unique User ID (UID) and Group ID (GID). Groups are logical expressions of organization. Groups tie users together, giving them permissions to read, write, or execute files.
Chapter 5.
Chapter 5. Users and Groups 91 User UID GID Home Directory Shell postfix 89 89 /var/spool/postfix /bin/true privoxy 100 101 /etc/privoxy pvm 24 24 /usr/share/pvm3 /bin/bash Table 5-1. Standard Users 5.3. Standard Groups In Table 5-2, you will find the standard groups set up by the installation program. Groups are stored on Red Hat Linux in the /etc/group file.
Chapter 5. Users and Groups Group GID Members rpm 37 rpm utmp 22 wnn 49 ntp 38 nscd 28 apache 48 mysql 27 mailnull 47 smmsp 51 rpc 32 xfs 43 gdm 42 rpcuser 29 nfsnobody 65534 ident 98 radvd 75 sshd 74 postgres 26 squid 23 named 25 pcap 77 wine 66 mailman 41 netdump 34 ldap 55 postdrop 90 postfix 89 privoxy 101 pvm 24 Table 5-2. Standard Groups 5.4.
Chapter 5. Users and Groups 93 User Private Group Every user has a primary group; the user is the only member of that group. umask = 002 Traditionally, on UNIX systems the umask is 022, which prevents other users and other members of a user’s primary group from modifying a user’s files. Since every user has their own private group in the UPG scheme, this "group protection" is not needed. A umask of 002 will prevent users from modifying other users’ private files. The umask is set in /etc/profile.
Chapter 5. Users and Groups chown -R root.emacs /usr/lib/emacs/site-lisp Now, it is possible to add the proper users to the group with gpasswd: /usr/bin/gpasswd -a : username ; emacs Allow the users to actually create files in the directory with the following command: chmod 775 /usr/lib/emacs/site-lisp When a user creates a new file, it is assigned the group of the user’s default private group.
Chapter 5. Users and Groups 95 • The utilities will work properly whether shadowing is enabled or not. • The utilities have been slightly modified to support Red Hat’s user private group scheme. For a description of the modifications, see the useradd man page. For more information on user private groups, turn to Section 5.4. • The adduser script has been replaced with a symbolic link to /usr/sbin/useradd. • The tools in the shadow-utils package are not Kerberos, NIS, hesiod, or LDAP enabled.
Chapter 5.
Chapter 6. The X Window System While the heart of Red Hat Linux is the kernel, for many users, the face of the operating system is the graphical environment provided by the X Window System, also called simply X. This chapter is an introduction to the behind-the-scenes world of XFree86, the open-source implementation of X provided with Red Hat Linux. 6.1.
Chapter 6. The X Window System 6.2. XFree86 Red Hat Linux 8.0 uses XFree86 version 4.2 as the base X Window System, which includes the various necessary X libraries, fonts, utilities, documentation, and development tools. Note Red Hat no longer provides the older XFree86 version 3 server packages.
Chapter 6. The X Window System 99 Device Specifies information about the video card used by the system. You must have at least one Device section in your configuration file. You may have multiple Device sections in the case of multiple video cards or multiple settings that can run a single card. The following options are required or widely used: — Specifies the bus location of the video card.
Chapter 6. The X Window System InputDevice Configures an input device such as a mouse or keyboard used to submit information into the system using the XFree86 server. Most systems have at least two InputDevice sections, keyboard and mouse. Each section includes these two lines: • Driver — Tells XFree86 the name of the driver to load to use the device. — Sets the name of the device, usually the name of the device followed by a number, starting with 0 for the first device.
Chapter 6. The X Window System 101 — Lists the vertical refresh range frequencies supported by the monitor, in kHz. These values are used as a guide by the XFree86 server so that it will know whether to use a particular Modeline entry’s values with this monitor. • VertRefresh Screen Binds together a particular Device and Monitor that can be utilized as a pair and contain certain settings. You must have at least one Screen section in your configuration file.
Chapter 6. The X Window System For more information, refer to the XF86Config man page. To review the current configuration of your XFree86 server, type the xset -q command. This provides you with information about the keyboard, pointer, screen saver, and font paths. 6.3. Desktop Environments and Window Managers The configuration of an XFree86 server is useless until accessed by an X client that will use it to display a program using the hardware controlled by the X server.
Chapter 6. The X Window System 103 to work in that environment to commonly integrate and be used in new ways, such as permitting drag-and-drop behavior with text. GNOME is the default desktop environment for Red Hat Linux, using the GTK2 base widget toolkit and miscellaneous other widgets that extend the base functionality. KDE, another desktop environment, uses a different toolkit called Qt.
Chapter 6. The X Window System xmodmap utility to configure the keyboard. The Xresources files are read to assign specific preference values to particular applications. After setting these options, the xinitrc script executes all scripts located in the /etc/X11/xinit/xinitrc.d/ directory. One important script in this directory is xinput, which configures settings such as the default language to use and the desktop environment to start from (/etc/sysconfig/desktop).
Chapter 6. The X Window System 105 When the user finishes an X session on the default display (:0) and logs out, the /etc/X11/xdm/TakeConsole script runs and reassigns ownership of the console to the root user. The original display manager, which continued running after the user logged in, takes control by spawning a new display manager. This restarts the XFree86 server, displays a new login window, and starts the entire process over again.
Chapter 6. The X Window System • clone-self — Decides if the font server will clone a new version of itself when the client- limit is hit. By default, this option is on. Set it to off to disable this feature. • default-point-size — Sets the default point size for any font that does not specify this value. The value for this option is set in decipoints. The default of 120 corresponds to 12 point fonts. — Specifies a list of resolutions supported by the XFree86 server.
Chapter 6. The X Window System 107 6.6. Additional Resources Much more can be said about the XFree86 server, the clients that connect to it, and the assorted desktop environments and window managers. Advanced users interested in tweaking their XFree86 configuration will find these additional sources of information useful. 6.6.1. Installed Documentation — Briefly describes the XFree86 architecture and how to get additional information about the XFree86 project as a new user.
• Chapter 6. The X Window System KDE 2.0 Development by David Sweet and Matthias Ettrich; Sams Publishing — Instructs beginning and advanced developers in how to take advantage of the many environment guidelines required to built QT applications for KDE.
Security Reference
Chapter 7. Pluggable Authentication Modules (PAM) Programs which give privileges to users must properly authenticate each user. For instance, when you log into a system, you provide your username and password, and the log in process uses this username and password to verify your identity. Pluggable Authentication Modules (PAM) allows the system administrator to set authentication policies for PAM-aware applications without having to recompile authentication programs.
Chapter 7. Pluggable Authentication Modules (PAM) The next four sections will describe the basic format of PAM configuration files and how they use PAM modules to perform authentication for PAM-aware applications. 7.3. PAM Modules There are four types of PAM modules used to control access to services. These types correlate to different aspects of the authorization process: — These modules are used to authenticate the user by, for example, asking for and checking a password.
Chapter 7. Pluggable Authentication Modules (PAM) 113 7.3.2. Creating Modules New PAM modules can be added at any time, and PAM-aware applications can then use them. For example, if you create a one-time-password creation method and write a PAM module to support it, PAM-aware programs can immediately use the new module and password method without being recompiled or otherwise modified.
Chapter 7. Pluggable Authentication Modules (PAM) A newer control flag syntax allowing for even more control is now available for PAM. Please see the PAM docs located in the /usr/share/doc/pam-version-number/ directory for information on this new syntax. 7.5. PAM Module Paths Module paths tell PAM where to find the pluggable module to be used with the module type specified. Usually, it is provided as the full path to the module, such as /lib/security/pam_stack.so.
Chapter 7. Pluggable Authentication Modules (PAM) 115 This line causes the user to be asked for a password and then checks the password using the information stored in /etc/passwd and, if it exists, /etc/shadow. The pam_unix.so module automatically detects and utilizes shadow passwords, stored in /etc/shadow, to authenticate users. Please refer to the Section 5.5 for more information on shadow passwords. The argument nullok instructs the pam_unix.so module to allow a blank password.
Chapter 7. Pluggable Authentication Modules (PAM) #%PAM-1.0 auth auth auth auth auth required required required sufficient required /lib/security/pam_nologin.so /lib/security/pam_securetty.so /lib/security/pam_env.so /lib/security/pam_rhosts_auth.so /lib/security/pam_stack.so service=system-auth First, pam_nologin.so checks to see if /etc/nologin exists. If is does, no one can log in except for root. auth required /lib/security/pam_securetty.so The pam_securetty.
Chapter 7. Pluggable Authentication Modules (PAM) 117 7.8.1. Device Ownership When a user logs into a machine under Red Hat Linux, the pam_console.so module is called by login or the graphical login programs, gdm and kdm. If this user is the first user to log in at the physical console — called the console user — the module grants ownership of a variety of devices normally owned by root. The console user owns these devices until the last local session for that user ends.
Chapter 7.
Chapter 8. TCP Wrappers and xinetd Controlling access to network services can be a challenge. Firewalls are useful for controlling access in and out of a particular network, but they can be difficult to configure. TCP wrappers and xinetd control access to services by hostname and IP addresses. In addition, these tools also include logging and utilization management capabilities that are easy to configure. 8.1.
Chapter 8. TCP Wrappers and xinetd 120 specifically given access to the service in hosts.allow are allowed to access the service. In addition, all rules in each file take effect from the top down. Any changes to these files take effect immediately, so restarting services is not required. 8.2.1. Formatting Rules All access control rules are placed on lines within hosts.allow and hosts.deny, and any blank lines or lines that start with the comment character (#) are ignored.
Chapter 8. TCP Wrappers and xinetd 121 Caution The KNOWN, UNKNOWN, and PARANOID wildcards should be used very carefully, as a disruption in name resolution may make prevent legitimate users from gaining access to a service. The access control language also contains a powerful operator, EXCEPT, which allows separate lists to be combined within the same rule line. When EXCEPT is used between two lists, the first list applies unless an entry from the second list matches an entity covered by the first list.
Chapter 8. TCP Wrappers and xinetd 122 special file or email an administrator. Below is an example of a booby trap in the hosts.deny file which will write a log line containing the date and client information every time a host from the the IP range 10.0.1.0 to 10.0.1.255 attempts to connect via Telnet: in.telnetd: 10.0.1.: spawn (/bin/echo ‘date‘ %c >> /var/log/telnet.log) & Another feature of using shell commands is support for expansions.
Chapter 8. TCP Wrappers and xinetd 123 instances of this service is under a particular threshold, and any other rules specified for that service or all xinetd services are followed. Once the target service is brought up for the connecting client, xinetd goes back to sleep, waiting for additional requests for the services it manages. 8.3.1. xinetd Configuration Files The xinetd service is controlled by the /etc/xinetd.conf file, as well as the various servicespecific files in the /etc/xinetd.d/ directory.
Chapter 8. TCP Wrappers and xinetd 124 • EXIT — Logs the exit status or termination signal of the service. (log_on_success) • HOST — Logs the remote host’s IP address. (log_on_failure and log_on_success) • PID — Logs the process ID of the server receiving the request. (log_on_success) — Records information about the remote system in the case the service cannot be started. Only particular services, such as login and finger, may use this option.
Chapter 8. TCP Wrappers and xinetd 125 8.3.1.3. Access Control within xinetd Users of xinetd services can choose to use the TCP wrapper host access control files (/etc/hosts.allow and /etc/hosts.deny), provide access control via the xinetd configuration files, or a mixture of both. Information concerning the use of TCP wrapper host access control files can be found in Section 8.2. This section will discuss using xinetd to control access to services.
Chapter 8. TCP Wrappers and xinetd 8.3.1.4. Binding and Port Redirection The service configuration files for xinetd also support binding the service to an IP address and redirecting incoming requests for that service to another IP address, hostname, or port. Binding is controlled with the bind option in the service configuration files and links the service to one IP address on the system. When used, the bind option only allows requests for the proper IP address to access the service.
Chapter 8. TCP Wrappers and xinetd 127 8.4. Additional Resources Additional information concerning TCP wrappers and xinetd is available on system documentation and on the Web. 8.4.1. Installed Documentation The bundled documentation on your system is a good place to start looking for additional TCP Wrappers, xinetd, and access control configuration options. F G — Contains a README file that discusses how TCP wrappers work and the various hostname and host address spoofing risks that exist.
Chapter 8.
Chapter 9. SSH Protocol SSH™ allows users to log into host systems remotely. Unlike rlogin or telnet SSH encrypts the login session, making it impossible for intruders to collect clear-text passwords. SSH is designed to replace older, less secure terminal applications used to log into remote systems, such as telnet or rsh. A related program called scp replaces older programs designed to copy files between hosts, such as ftp or rcp.
Chapter 9. SSH Protocol 9.1.1. Why Use SSH? Nefarious computer users have a variety of tools at their disposal to disrupt, intercept, and re-route network traffic in an effort to gain access to your system. In general terms, these threats can be categorized as follows: • Interception of communication between two systems — In this scenario, the attacker can be somewhere on the network between the communicating entities, copying any information passed between them.
Chapter 9. SSH Protocol 131 Both SSH protocol versions 1 and 2 add layers of security with each of these layers providing its own type of protection. 9.3.1. Transport Layer The primary role of the transport layer is to facilitate safe and secure communication between the two hosts at the time of and after authentication.
Chapter 9. SSH Protocol Servers can be configured to allow different types of authentication, which gives each side the optimal amount of control. The server can decide which encryption methods it will support based on its security model, and the client can choose the order of authentication methods to attempt from among the available options. Thanks to the secure nature of the SSH transport layer, even seemingly insecure authentication methods, such as a host-based authentication, are safe to use.
Chapter 9. SSH Protocol 133 • ssh_host_key.pub — The RSA public key used by the sshd daemon for version 1 of the SSH • ssh_host_rsa_key — The RSA private key used by the sshd daemon for version 2 of the SSH protocol. protocol. • ssh_host_rsa_key.pub protocol. — The RSA public key used by the sshd for version 2 of the SSH User-specific SSH configuration information is stored in the user’s home directory within the ~/.
Chapter 9. SSH Protocol 9.5.2. Port Forwarding With SSH you can secure otherwise insecure TCP/IP protocols via port forwarding. When using this technique, the SSH server becomes an encrypted conduit to the SSH client. Port forwarding works by mapping a local port on the client to a remote port on the server. SSH allows you to map any port from the server to any port on the client; the port numbers do not need to match for it to work.
Chapter 9. SSH Protocol 135 9.6. Require SSH for Remote Connections For SSH to be truly effective in protecting your network connections, you must stop using all insecure connection protocols, such as telnet and rsh. Otherwise, a user’s password may be protected using ssh for one log in only to be captured when he logs in again using telnet.
Chapter 9.
Chapter 10. Kerberos Kerberos is a network authentication protocol created by MIT which uses secret-key cryptography — obviating the need to send passwords over the network. By authenticating using Kerberos, unauthorized users trying to intercept passwords on the network are effectively thwarted. 10.1. Advantages of Kerberos Most conventional network systems use password-based authentication schemes.
Chapter 10. Kerberos 10.3. Kerberos Terminology Like any other system, Kerberos has its own terminology to define various aspects of the service. Before learning how the service works, it is important to learn the following terms. ciphertext Encrypted data. plain text Unencrypted, human-readable data. client An entity on the network (a user, a host, or an application) that can get a ticket from Kerberos.
Chapter 10. Kerberos 139 ticket A temporary set of electronic credentials that verify the identity of a client for a particular service. Ticket Granting Service (TGS) A server that issues tickets for a desired service which are in turn given to users for access to the service. The TGS usually runs on the same host as the KDC Ticket Granting Ticket (TGT) A special ticket that allows the client to obtain additional tickets without applying for them from the KDC. 10.4.
Chapter 10. Kerberos Note Kerberos depends on certain network services to work correctly. First, Kerberos requires approximate clock synchronization between the machines on the network. Therefore, a clock synchronization program should be set up for the network, such as ntpd. Also, since certain aspects of Kerberos rely on the Domain Name Service (DNS), be sure that the DNS entries and hosts on the network are all properly configured.
Chapter 10. Kerberos 141 KDC from kerberos.example.com to the name of your Kerberos server. By convention, all realm names are uppercase and all DNS hostnames and domain names are lowercase. For full details on the formats of these files, see their respective man pages. 4. Create the database using the kdb5_util utility from a shell prompt: /usr/kerberos/sbin/kdb5_util create -s The create command creates the database that will be used to store keys for your Kerberos realm.
Chapter 10. Kerberos Once you have completed the steps listed above, the Kerberos server should be up and running. Next, we will set up a Kerberos client. 10.7. Configuring a Kerberos 5 Client Setting up a Kerberos 5 client is less involved than setting up a server. At minimum, install the client packages and provide each client with a valid krb5.conf configuration file. Kerberized versions of rsh and rlogin will also require some configuration changes. 1.
Chapter 10. Kerberos 143 10.8.1. Installed Documentation J K — The Kerberos V5 Installation Guide and the Kerberos V5 System Administrator’s Guide in PostScript and HTML formats. You must have the krb5-server RPM package installed. • /usr/share/doc/krb5-server- version-number J K — The Kerberos V5 UNIX User’s Guide in PostScript and HTML formats. You must have the krb5-workstation RPM package installed. • /usr/share/doc/krb5-workstation- version-number 10.8.2. Useful Websites • http://web.mit.
Chapter 10.
Chapter 11. Tripwire Tripwire data integrity assurance software monitors the reliability of critical system files and directories by identifying changes made to them. Tripwire configuration options include the ability to receive alerts via email if particular files are altered and automated integrity checking via a cron job. Using Tripwire for intrusion detection and damage assessment helps you keep track of system changes.
Chapter 11. Tripwire 1. Install Tripwire and customize the policy file. Install the tripwire RPM (Section 11.2). Then, customize the sample configuration and policy files (/etc/tripwire/twcfg.txt and /etc/tripwire/twpol.txt respectively) and run the configuration script, /etc/tripwire/twinstall.sh. For more information, see Section 11.3. 2. Initialize the Tripwire database.
Chapter 11. Tripwire 147 2. If the CD-ROM does not automatically mount, type the following command: mount /mnt/cdrom 3. Verify that the tripwire RPM is on the CD-ROM by typing: ls /mnt/cdrom/RedHat/RPMS/ | grep tripwire If the RPM is on the CD-ROM, this command will display the package name. If the RPM is not on the CD-ROM, the shell prompt will return. In this case, you will need to check CD 3 and, possibly, CD 1 of the Red Hat Linux 8.
Chapter 11. Tripwire • EDITOR — Specifies the text editor called by Tripwire. The default value is /bin/vi. — If set to true this variable configures Tripwire to wait as long as possible before prompting the user for a password, thereby minimizing the amount of time the password is in memory. The default value is false. • LATEPROMPTING — If set to true this variable configures Tripwire to report if a file within a watched directory changes and not to report the change for the directory itself.
Chapter 11. Tripwire 149 Warning For security purposes, you should either delete or store in a secure location any copies of the plain text /etc/tripwire/twpol.txt file after running the installation script or regenerating a signed configuration file. Alternatively, you can change the permissions so that it is not world readable. 11.3.3. Run the twinstall.sh Script As the root user, type /etc/tripwire/twinstall.sh at the shell prompt to run the configuration script. The twinstall.
Chapter 11. Tripwire an initial integrity check. This check should be done prior to connecting the computer to the network, and putting it into production. For instructions on doing this see Section 11.5. Once Tripwire is configured to your satisfaction, you are free to place the system into production. 11.5. Running an Integrity Check By default the Tripwire RPM adds a shell script called tripwire-check to the /etc/cron.daily/ directory. This will automatically run an integrity check once per day.
Chapter 11. Tripwire Database file used: Command line used: 151 /var/lib/tripwire/some.host.com.
Chapter 11. Tripwire /bin/arch -rwxr-xr-x root (0) /bin/ash -rwxr-xr-x root (0) /bin/ash.
Chapter 11. Tripwire 153 Important It is important that you change only authorized integrity violations in the database. All proposed updates to the Tripwire database start with an [x] before the file name, similar to the following example: Added: [x] "/usr/sbin/longrun" Modified: [x] "/usr/sbin" [x] "/usr/sbin/cpqarrayd" If you want to specifically exclude a valid violation from being added to the Tripwire database, remove the x. To accept any files with an x beside them as changes.
Chapter 11. Tripwire Then type the following command to create a new database using the updated policy file: /usr/sbin/tripwire --init To make sure the database was correctly changed, run the first integrity check manually and view the contents of the resulting report. See Section 11.5 and Section 11.6.1 for more on doing these tasks. 11.8.1. Tripwire and Email You can configure Tripwire to send an email to one or more accounts if a specific type of policy is violated.
Chapter 11. Tripwire 155 Since the configuration file does not not alter any Tripwire policies or files tracked by the application, it is not necessary to regenerate the Tripwire database. 11.10. Tripwire File Location Reference Before working with Tripwire, you should know where important files for the application are located. Tripwire stores its files in a variety of places depending on their role.
Chapter 11. Tripwire /etc/tripwire/tw.pol The active Tripwire policy file is an encrypted file containing comments, rules, directives, and variables. This file dictates the way Tripwire checks your system. Each rule in the policy file specifies a system object to be monitored. Rules also describe which changes to the object to report and which to ignore. System objects are the files and directories you wish to monitor. Each object is identified by an object name.
Network Services Reference
Chapter 12. Network Scripts Using Red Hat Linux, all network communications occur between configured interfaces and physical networking devices connected to the system. The different types of interfaces that exist are as varied as the physical devices they support. The configuration files for network interfaces and the scripts to activate and deactivate them are located in the /etc/sysconfig/network-scripts/ directory.
Chapter 12. Network Scripts configure them. These files are usually named ifcfg- X name Y , where of the device that the configuration file controls. X name Y refers to the name 12.2.1. Ethernet Interfaces One of the most common interface files is ifcfg-eth0, which controls the first network interface card or NIC in the system. In a system with multiple NICs, you will also have multiple ifcfg-eth files, each one with a unique number at the end of the file name.
Chapter 12. Network Scripts 161 • yes — This device should be activated at boot-time. • no — This device should not be activated at boot-time. Z • PEERDNS= answer • [ , where Z answer [ is one of the following: yes — Modify /etc/resolv.conf if the DNS directive is set. If you are using DCHP, then yes is the default. • no — Do not modify /etc/resolv.conf. • SRCADDR= address , where • USERCTL= answer , where Z packets.
Chapter 12. Network Scripts • yes — This interface will allow pppd to initiate a connection when someone attempts to use it. • no — A connection must be manually established for this interface. \ ] , where interface will disconnect itself. • IDLETIMEOUT= value \ value ] is the number of seconds of idle activity before the \ ] , where \ string ] is the initilization string passed to the modem device. This option is primarily used with SLIP interfaces.
Chapter 12. Network Scripts 163 Warning Never edit the loopback interface script, /etc/sysconfig/network-scripts/ifcfg-lo, by hand. Doing so can prevent the system from operating correctly. An infrared interface allows information between devices, such as a laptop and a printer, to flow over an infrared link which works in a similar way to an Ethernet device except that it commonly occurs over a peer-to-peer connection.
Chapter 12. Network Scripts The two interface control scripts are ifdown and ifup and are symbolic links to scripts in the /sbin/ directory. When either of these scripts are called, they require a value of the interface to be specified, such as: ifup eth0 Determining IP information for eth0... done. At that point, the /etc/rc.d/init.d/functions and /etc/sysconfig/networkscripts/network-functions files are used to perform a variety of tasks. See Section 12.4 for more information.
Chapter 12. Network Scripts 165 The most common network functions file is network-functions, located in the /etc/sysconfig/network-scripts/ directory. This file contains a variety of common IPv4 functions useful to many interface control scripts, such as contacting running programs that have requested information about changes in an interface’s status, setting host names, finding a gateway device, seeing if a particular device is down or not, and adding a default route.
Chapter 12.
Chapter 13. Firewalls and iptables Linux comes with advanced tools for packet filtering — the process of controlling network packets as they enter, move through, and exit the network stack within the kernel. Pre-2.4 kernels relied on ipchains for packet filtering and used lists of rules applied to packets at each step of the filtering process. The introduction of the 2.
Chapter 13. Firewalls and iptables • OUTPUT — This chain applies to packets sent out via the same network interface which received the packets. • FORWARD — This chain applies to packets received on one network interface and sent out on another. The built-in chains for the nat table are as follows: • PREROUTING — This chain alters packets received via a network interface when they arrive. • OUTPUT — This chain alters locally-generated packets before they are routed via a network interface.
Chapter 13. Firewalls and iptables 169 packets. For this reason, you must be sure to place the rule designed to catch a particular packet in the rule that will actually see the packet. The advantage is that you now have more control over the disposition of each packet. If you are attempting to block access to a particular website, it is now possible to block access attempts from clients running on hosts which use your host as a gateway.
Chapter 13. Firewalls and iptables 170 13.3.2. Structure Many iptables commands have the following structure: d e d efd iptables [-t table-name ] command chain-name option-1 parameter-n option-n d ehd eid e egd parameter-1 e \ In this example, the d table-name e option allows the user to select a table other than the default filter table to use with the command.
Chapter 13. Firewalls and iptables 171 Caution Be aware of which option (-A or -I) you are using when adding a rule. The order of the rules can be very important when determining if a particular packet applies to one rule or another. Make sure when adding a rule to the beginning or end of the chain that it does not affect other rules in that chain. — Lists all of the rules in the chain specified after the command.
Chapter 13. Firewalls and iptables iptables man page for more information on these and other targets, including rules regarding their use. You may also direct a packet matching this rule to a user-defined chain outside of the current chain. This allows you to apply other rules against this packet, further filtering it with more specific criteria. If no target is specified, the packet moves past the rule with no action taken.
Chapter 13. Firewalls and iptables 173 Like many other options, using the exclamation point character (!) after --tcp-flags reverses the effect of the match option, so that the second parameter’s flags must not be set in order to match. • --tcp-option — Attempts to match with TCP-specific options that can be set within a particular packet. This match option can also be reversed with the exclamation point character (!). 13.3.5.2.
Chapter 13. Firewalls and iptables 174 • INVALID — The matching packet cannot be tied to a known connection. • NEW — The matching packet is either creating a new connection or is part of a two-way connection • not previously seen. RELATED — The matching packet is starting a new connection related in some way to an existing connection. These connection states can be used in combination with one another by separating them with commas, such as -m state --state INVALID,NEW.
Chapter 13. Firewalls and iptables • 175 --log-prefix — Places a string before the log line when it is written. Accepts up to 29 characters after the --log-prefix option. This is useful for writing syslog filters for use in conjunction with packet logging. • --log-tcp-options — Any options set in the header of a TCP packet is logged • --log-tcp-sequence — Writes the TCP sequence number for the packet in the log.
Chapter 13. Firewalls and iptables 176 system’s version of this file. This allows you to quickly distribute sets of iptables rules to many different machines. Important If you distribute the /etc/sysconfig/iptables file to other machines, you must type /sbin/service iptables restart for the new rules take effect. 13.5. Additional Resources See the sources below for additional information on packet filtering with iptables. 13.5.1.
Chapter 14. Apache HTTP Server The Apache HTTP Server is a robust, commercial-grade open source Web server developed by the Apache Software Foundation (http://www.apache.org). Red Hat Linux 8.0 includes the Apache HTTP Server version 2.0 as well as a number of server modules designed to enhance its functionality. The default configuration file installed with the Apache HTTP Server works without alteration for most situations.
Chapter 14. Apache HTTP Server A more complete list complete list of changes can be found online at http://httpd.apache.org/docs-2.0/. 14.1.2. Packaging Changes in Apache HTTP Server 2.0 Under Red Hat Linux 8.0 the Apache HTTP Server package has been renamed. Also, some related packages have been renamed, deprecated, or incorporated into other packages.
Chapter 14. Apache HTTP Server 179 it to suit; however, some parts of the file have changed more than others and a mixed approach is generally the best. The stock configuration files for both version 1.3 and version 2.0 are divided into three sections. The goal of this guide is to suggest what is hopefully the easiest route. If your httpd.
Chapter 14. Apache HTTP Server 14.2.1.2. Server-pool Size Regulation In Apache HTTP Server 2.0, the responsibility for accepting requests and dispatching child-processes to handle them has been abstracted into a group of modules called Multi-Processing Modules (MPMs). Unlike other modules, only one module from the MPM group can be loaded by the Apache HTTP Server because an MPM module is responsible for basic request handling and dispatching. There are three MPM modules that ship with version 2.
Chapter 14. Apache HTTP Server 181 lines for modules packaged in their own RPMs (mod_ssl, php, mod_perl, and the like) are no longer necessary as they can be found in the relevant file in the /etc/httpd/conf.d/ directory. • LoadModule • The various HAVE_XXX definitions are no longer defined. 14.2.1.4. Other Global Environment Changes The following directives have been removed from Apache HTTP Server 2.0’s configuration: • ServerType — The Apache this directive irrelevant.
Chapter 14. Apache HTTP Server 14.2.2.2. Logging The following logging directives have been removed: • AgentLog • RefererLog • RefererIgnore However, agent and referrer logs are still available using the CustomLog and LogFormat directives. For more on this topic, refer to the following documentation on the Apache Software Foundation’s website: • http://httpd.apache.org/docs-2.0/mod/mod_log_config.html#customlog • http://httpd.apache.org/docs-2.0/mod/mod_log_config.html#logformat 14.2.2.3.
Chapter 14. Apache HTTP Server 183 For more on this topic, refer to the following documentation on the Apache Software Foundation’s website: • http://httpd.apache.org/docs-2.0/mod/core.html#errordocument 14.2.3. Virtual Hosts Configuration The contents of all v VirtualHost w containers should be migrated in the same way as the main server section as described in Section 14.2.2.
Chapter 14. Apache HTTP Server 14.2.4.1. The mod_ssl Module The configuration for mod_ssl has been moved from httpd.conf into the file /etc/httpd/conf.d/ssl.conf. For this file to be loaded, and hence for mod_ssl to work, you must have the statement Include conf.d/*.conf in your httpd.conf as described in Section 14.2.1.3. ServerName directives in SSL virtual hosts must explicitly specify the port number. For example, the following is a sample Apache HTTP Server 1.
Chapter 14. Apache HTTP Server 185 14.2.4.3. The mod_include Module The mod_include module is now implemented as a filter (see Section 14.2.4 for more on filters) and is therefore enabled differently. For example, the following is a sample Apache HTTP Server 1.3 directive: AddType text/html .shtml AddHandler server-parsed .shtml To migrate this setting to Apache HTTP Server 2.0, use the following structure: AddType text/html .shtml AddOutputFilter INCLUDES .
Chapter 14. Apache HTTP Server Action dbmmanage command (Apache 1.3) Equivalent htdbm command (Apache 2.
Chapter 14. Apache HTTP Server 187 14.2.4.6. The mod_python Module The configuration for mod_python; has been moved from httpd.conf into the file /etc/httpd/conf.d/python.conf. For this file to be loaded, and hence for mod_python; to work, you must have the statement Include conf.d/*.conf in your httpd.conf as described in Section 14.2.1.3. 14.2.4.7. PHP The configuration for PHP has been moved from httpd.conf into the file /etc/httpd/conf.d/php.conf.
Chapter 14. Apache HTTP Server Note Red Hat, Inc. does not ship FrontPage extensions as the Microsoft™ license prohibits the inclusion of these extensions in a third party product. To find out more about FrontPage extensions and the Apache HTTP Server, refer to http://www.rtr.com/fpsupport/. 14.4. Starting and Stopping httpd The the httpd RPM installs the /etc/rc.d/init.d/httpd Bourne script, which is accessed using the /sbin/service command.
Chapter 14. Apache HTTP Server 189 Note If you are running the Apache HTTP Server as a secure server, you will be prompted for the secure server’s password after the machine boots, unless you generated a specific type of server key file. For information about setting up an Apache HTTP Secure Server see the chapter titled Apache HTTP Secure Server Configuration in the Official Red Hat Linux Customization Guide. 14.5. Configuration Directives in httpd.
Chapter 14. Apache HTTP Server 14.5.3. PidFile PidFile names the file where the server records its process ID (pid). Your Web server is set to record its pid in /var/run/httpd.pid. 14.5.4. ScoreBoardFile The ScoreBoardFile stores internal server process information, which is used for communication between the parent server process and its child processes. Red Hat Linux uses shared memory to store the ScoreBoardFile, the default of /etc/httpd/logs/apache_runtime_status is only used as a fallback. 14.
Chapter 14. Apache HTTP Server 191 Your server’s default MinSpareServers is 5; your server’s default MaxSpareServers is 20. These default settings should be appropriate in most situations. You should not increase the MinSpareServers to a large number. Doing so will create a heavy processing load on your server even when traffic is light. 14.5.10. StartServers StartServers sets how many server processes are created upon startup.
Chapter 14. Apache HTTP Server 14.5.15. LoadModule LoadModule is used to load in Dynamic Shared Object (DSO) modules. More information on the the Apache HTTP Server’s DSO support, including exactly how to use the LoadModule directive, can be found in Section 14.7. Note, the load order of the modules is no longer important with Apache HTTP Server 2.0. See Section 14.2.1.3 for more information about Apache HTTP Server 2.0 DSO support. 14.5.16.
Chapter 14. Apache HTTP Server 193 14.5.19. Group The Group directive is similar to the User. The Group sets the group under which the server will answer requests. The default Group is apache. 14.5.20. ServerAdmin ServerAdmin should be the email address of the Web server’s administrator. This email address will show up in error messages on server-generated webpages, so users can report a problem by sending email to the server administrator. ServerAdmin is set by default to root@localhost.
Chapter 14. Apache HTTP Server Using Directory tags, the DocumentRoot is defined to have less rigid parameters, so that HTTP requests can be served from it. The cgi-bin directory is set up to allow the execution of CGI scripts, with the ExecCGI option. If you need to execute a CGI script in another directory, you will need to set ExecCGI for that directory.
Chapter 14. Apache HTTP Server 195 14.5.27. Allow Allow specifies which requester can access a given directory. The requester can be all, a domain name, an IP address, a partial IP address, a network/netmask pair, and so on. Your DocumentRoot directory is configured to Allow requests from all meaning everyone has access. 14.5.28. Deny Deny works just like Allow, but you are specifying who is denied access. Your DocumentRoot is not configured to Deny requests from anyone by default. 14.5.29.
Chapter 14. Apache HTTP Server 14.5.32. CacheNegotiatedDocs By default, your Web server asks proxy servers not to cache any documents which were negotiated on the basis of content (that is, they may change over time or because of the input from the requester). If you set CacheNegotiatedDocs to on, you are disabling that function and proxy servers will be allowed to cache documents. 14.5.33. UseCanonicalName UseCanonicalName is set by default to on.
Chapter 14. Apache HTTP Server 197 other words, after a reverse lookup is performed, a forward lookup is performed on the result. At least one of the IP addresses in the forward lookup must match the address from the first reverse lookup. Generally, you should leave HostnameLookups set to off, because the DNS requests add a load to your server and may slow it down. If your server is busy, the effects of HostnameLookups will be noticeable. HostnameLookups are also an issue for the Internet as a whole.
Chapter 14. Apache HTTP Server authuser If authentication was required, this is the username with which the user identified herself. Usually, this is not used, so you will see a - in its place. [date] The date and time of the request. "request" The request string exactly as it came from the browser or client. status The HTTP status code which was returned to the browser or client. bytes The size of the document.
Chapter 14. Apache HTTP Server 199 See Section 14.5.59 and Section 14.5.23 for instructions on how to execute CGI scripts in directories other than the cgi-bin. 14.5.45. Redirect When a webpage is moved, Redirect can be used to map the old URL to a new URL. The format is as follows: Redirect /path/foo.html http://new_domain/path/foo.html So, if an HTTP request is received for a page which used to be found at http://your_domain/path/foo.
Chapter 14. Apache HTTP Server 14.5.49. AddIcon AddIcon tells the server which icon to show in server generated directory listings for certain file types or for files with certain extensions. For example, your Web server is set to show the icon binary.gif for files with .bin or .exe extensions. 14.5.50. DefaultIcon DefaultIcon names the icon to show in server generated directory listings for files which have no other icon specified. The unknown.
Chapter 14. Apache HTTP Server 201 14.5.56. AddLanguage AddLanguage associates filename extensions with specific content languages. This directive is mostly useful for content negotiation, when the server returns one of several documents based on the client’s language preference as set in their browser. 14.5.57.
Chapter 14. Apache HTTP Server 14.5.61. MetaDir MetaDir specifies the name of a directory where your Web server should look for files containing meta information (extra HTTP headers) to include when serving documents. 14.5.62. MetaSuffix MetaSuffix specifies the filename suffix for the file that contains meta information (extra HTTP headers), which should be located in the MetaDir directory. 14.5.63.
Chapter 14. Apache HTTP Server 203 # Deny from all # Allow from .your_domain.com # /Location Again, you must fill in .your_domain.com. 14.5.66. ProxyRequests If you uncomment the IfModule tags surrounding the ProxyRequests directives, your Apache HTTP Server will also function as a proxy server. You will also need to load the mod_proxy module. For instructions on how to load in modules, see Section 14.7. 14.5.67.
Chapter 14. Apache HTTP Server Note Any name-based virtual hosts you set up will only work with non-secure HTTP connections as you cannot use name-based virtual hosts with a secure server. If you need to use virtual hosts with a secure server, you will need to use IP address-based virtual hosts. If you are using name-based virtual hosts, uncomment the NameVirtualHost configuration directive and add the correct IP address for your server after NameVirtualHost.
Chapter 14. Apache HTTP Server 205 14.6. Default Modules The Apache HTTP Server is distributed with a number of modules.
Chapter 14. Apache HTTP Server A sample LoadModule line looks like this: LoadModule access_module modules/mod_access.so If you add or delete modules from http.conf, you must reload or restart Apache, as covered in Section 14.4. If you have your own module, you can add it to the httpd.conf file so that it is compiled in and loaded as a DSO. For this you need have the httpd-devel package installed because it contains the include files, the header files, and the APache eXtenSion (apxs) application.
Chapter 14. Apache HTTP Server 207 The configuration directives for your secure server are contained within virtual host tags in the /etc/httpd/conf.d/ssl.conf file. If you need to change anything about the configuration of your secure server, you will need to change the configuration directives inside the virtual host tags. By default, both the secure and the non-secure Web servers share the same DocumentRoot.
Chapter 14. Apache HTTP Server 14.9. Additional Resources To learn more about the Apache HTTP Server, refer to the following resources. 14.9.1. Useful Websites • http://httpd.apache.org — The official website for the Apache Web server with documentation on all the directives and default modules. • http://www.modssl.org — The official website for mod_ssl. • http://www.apacheweek.com — A comprehensive online online weekly about all things Apache. 14.9.2.
Chapter 15. Email Email is one of the most widely used services on the Internet. Red Hat Linux offers many ways to serve and access email, whether you are a desktop user or a system administrator. This chapter looks at popular email protocols that are in use today and some of the programs designed to deal with email. 15.1. Protocols Email, like other network services, uses a variety of protocols.
Chapter 15. Email the message on the email server after it has been successfully transferred to the client’s system, though this can usually be changed. To connect to a POP server, the email client opens a TCP connection to port 110 on the server. At the time the connection is made, the POP server sends the POP client a greeting, after which the two machines send each other commands and responses specified in the protocol.
Chapter 15. Email 211 particular mail server using the VRFY command or expand a mailing list using the EXPN command. Email can also be relayed between two SMTP servers, if both systems permit such activity. Unlike IMAP and POP, the SMTP protocol does not require authentication. This means that SMTP servers can allow anyone on the Internet to use your system to send or relay mail to large lists of recipients. It is this characteristic of SMTP that makes spam possible.
Chapter 15. Email Many of the larger and more complex MUAs can also be used to send email. However, this action should not be confused with the actions of a true MTA. In order for users not running their own MTA to move outbound messages off of their machine and onto a remote machine for delivery, they must use a capacity in the MUA that transfers the message to an MTA they are authorized to use.
Chapter 15. Email 213 which grew out of an earlier email delivery system called Delivermail, quickly became the standard as the email began to expand and become widely used. 15.3.2. Purpose and Limitations It is important to be aware of what Sendmail is and what it can do for you as opposed to what it is not. In these days of monolithic applications that fulfill multiple roles, you might initially think that Sendmail is the only application you need to run an email server within your organization.
Chapter 15. Email For example, if you want all email addressed to any domain.com account to be delivered to , you need to add a line similar to the one below to the virtusertable file: @domain.com bob@otherdomain.com Then, to add this new information to the virtusertable.db file, execute makemap hash /etc/mail/virtusertable /etc/mail/virtusertable as root. This will create a new virtusertable.db containing the new configuration. 15.3.4.
Chapter 15. Email 215 In this situation, the sendmail server needs to masquerade the machine names on the company network so that their return address is user@bigcorp.com instead of user@devel.bigcorp.com. To do this, add the following lines to /etc/mail/sendmail.mc. FEATURE(always_add_domain)dnl FEATURE(‘masquerade_entire_domain’) FEATURE(‘masquerade_envelope’) FEATURE(‘allmasquerade’) MASQUERADE_AS(‘bigcorp.com.’) MASQUERADE_DOMAIN(‘bigcorp.com.’) MASQUERADE_AS(bigcorp.
Chapter 15. Email 15.3.6. Using Sendmail with LDAP Using the Lightweight Directory Access Protocol (LDAP) is a very quick and powerful way to find specific information about a particular user from a much larger group. For example, you could use an LDAP server to look up a particular email address from a common corporate directory by a user’s last name.
Chapter 15. Email 217 15.4.1. Fetchmail Configuration Options Although it is possible to pass all options on the command line necessary to check for email on a remote server when executing Fetchmail, using a .fetchmailrc file is much easier. All of your configuration options go in the .fetchmailrc file, but you can override them at the time Fetchmail is run by specifying that option on the command line. A user’s .
Chapter 15. Email While you can set up your .fetchmailrc file manually, it is much easier to let the included fetchmailconf program do it for you. However, when testing new configurations, it is usually easier to edit the .fetchmailrc file directly. As expected with a program that services such a mature network service as email and uses so many protocols, Fetchmail contains many different global, server, and local options.
Chapter 15. Email 219 ¨ max-number-bytes © — Allows you to specify that only messages below a particular size may be retrieved. This option is useful with slow network links, when a large message will take too long to download. • limit ¨ © • password ’ password ’ — ¨ © Specifies the password to be used for this user. • preconnect " command " — Tells Fetchmail ing messages for this user. ¨ © • postconnect " command " — Tells ing messages for this user.
• --quit Chapter 15. Email — Quits the Fetchmail daemon process. More commands and .fetchmailrc options can be found on the fetchmail man page. 15.5. Procmail Procmail allows you to filter email as it is received from a remote email server, or placed in your spool file on a local or remote email server. It is powerful, gentle on system resources, and widely used. Procmail, commonly referred to as a Local Delivery Agent (LDA), plays a small role in delivering email to be read by an MUA.
Chapter 15. Email 221 Many environment variables are not used by most Procmail users, and many of the more important environment variables are already defined a default value. Most of the time, you will be dealing with the following variables: • DEFAULT — Sets the default mailbox where messages that do not match any recipes will be placed. The default DEFAULT value is the same as $ORGMAIL. — Specifies additional rc files containing more recipes for messages to be checked against.
Chapter 15. Email A thorough explanation of regular expressions is beyond the scope of this chapter. The structure of Procmail recipes is more important, and useful sample Procmail recipes can be found at various places on the Internet, including http://www.iki.fi/era/procmail/links.html. The proper use and adaptation of the regular expressions found in these recipe examples depends upon an understanding of Procmail recipe structure.
Chapter 15. Email 223 To ensure that the action on this last previous matching recipe was successfully completed before allowing a match on the current recipe, use the a flag instead. • B — Parse the body of the message and look for matching conditions. — Use the body in any resulting action, such as writing the message to a file or forwarding it. This is the default behavior. • b — Generate a carbon copy of the email.
Chapter 15. Email • $— Refers to a variable set earlier in the rc file. This is usually used to set a common mailbox that will be referred to by various recipes. • | — The pipe character tells Procmail to start a specific program to deal with this message. and } — Constructs a nesting block, used to contain additional recipes to apply to matching messages.
Chapter 15. Email 225 :0: * ^(From|CC|To).*tux-lug tuxlug Any messages sent from the tux-lug@domain.com mailing list will be placed in the tuxlug mailbox automatically for your MUA. Note that the condition in this example will match the message if it has the mailing list’s email address on the From, CC, or To lines. Procmail can also be used to block spam, although this is not a good long-term solution for junk mail.
Chapter 15. Email 15.6.2. Secure Email Servers Offering SSL encryption to IMAP and POP users on the email server is almost as easy. Red Hat Linux also includes the stunnel package, which is an SSL encryption wrapper that wraps around standard, non-secure network traffic for certain services and prevents interceptors from being able to "sniff" the communication between client and server.
Chapter 15. Email 227 µ ¶ — Contains a full list of Fetchmail features in the FEATURES file and an introductory FAQ document. • /usr/share/doc/fetchmail- version-number µ ¶ — Contains a README file that provides an overview of Procmail, a FEATURES file that explores every program feature, and an FAQ file with answers to many common configuration questions.
Chapter 15. Email • Removing the Spam: Email Processing and Filtering by Geoff Mulligan; Addison-Wesley Publishing Company — A volume that looks at various methods used by email administrators that use established tools, such as Sendmail and Procmail, to manage spam problems. • Internet Email Protocols: A Developer’s Guide by Kevin Johnson; Addison-Wesley Publishing Company — Provides a very thorough review of major email protocols and the security they provide.
Chapter 16. Berkeley Internet Name Domain (BIND) Today, the Internet and almost all local networks depend upon a working and reliable Domain Name Service (DNS), which is used to resolve names of systems into IP addresses and vice versa. In order to facilitate DNS on your network, a nameserver is required to translate these names into the IP addresses necessary to make the connection. In addition, a nameserver can translate IP addresses back into a system’s name, commonly called a reverse lookup.
Chapter 16. Berkeley Internet Name Domain (BIND) When looking at how a FQDN is resolved to find the IP address that relates to a particular system, you must read the name from right to left, with each level of the hierarchy divided by dots (.). In this example, the com defines the top level domain for this FQDN. The domain name is a sub-domain under com, with sales as a sub-domain under domain. The name furthest left in a FQDN is the hostname, identifying a particular machine.
Chapter 16. Berkeley Internet Name Domain (BIND) 231 The /etc/named.conf file must be free of errors in order for named to start. While some erroneous options are not considered critical enough to stop the server, any errors in the statements themselves will prevent the named service from starting. Warning Do not manually edit the /etc/named.conf file or any files in the /var/named/ directory if you are using the Bind Configuration Tool.
Chapter 16. Berkeley Internet Name Domain (BIND) When used with other /etc/named.conf statements and their options, acl statements can be very useful in ensuring the proper use of your BIND nameserver as in this example: acl black-hats { 10.0.2.0/24; 192.168.0.0/24; }; acl red-hats { 10.0.1.0/24; }; options { blackhole { black-hats; }; allow-query { red-hats; }; allow-recursion { red-hats; }; } This named.conf contains two access control lists black-hats and red-hats.
Chapter 16. Berkeley Internet Name Domain (BIND) 233 • allow-recursion — Similar to allow-query, except it applies to recursive queries. By de- • directory — Changes the named working directory to something other than the default, /var/named. • forward — Controls how forwarding occurs, if the forwarders option contains valid IP ad- fault, all hosts are allowed to perform recursive queries on the nameserver. dresses designating where to send requests.
Chapter 16. Berkeley Internet Name Domain (BIND) statements are listed is important, as the first view statement that matches a particular client’s IP address is used. See Section 16.4.2 for more information about the view statement. Á Â — Specifies particular zones for which this nameserver is authoritative.
Chapter 16. Berkeley Internet Name Domain (BIND) 235 nameservers use only few of them. The following zone statements are very basic examples that can be used in a master-slave nameserver relationship. The following is an example of a zone statement for the primary nameserver hosting domain.com: zone "domain.com" IN { type master; file "domain.com.zone"; allow-update { none; }; }; In the statement, the zone is identified as domain.
Chapter 16. Berkeley Internet Name Domain (BIND) For example, a zone file may contains the following line: $ORIGIN domain.com At this point, any names that are used in resource records and do not end in a trailing dot (.) will have this domain name added to them. So, in other words, when the zone record is read by the nameserver, the first line below will be interpreted as the second line: ftp ftp.domain.com. IN IN CNAME CNAME server1 server1.domain.com.
Chapter 16. Berkeley Internet Name Domain (BIND) 237 over others. The MX resource record with the lowest É preference-value Ê is preferred over the others, but you can set multiple email servers with the same value to distribute email traffic between them. The É email-server-name Ê may be a hostname or FQDN, as long as it points to the correct system. IN IN MX MX 10 20 mail.domain.com. mail2.domain.com. In this example, the first mail.domain.com email server is preferred to the mail2.domain.
Chapter 16. Berkeley Internet Name Domain (BIND) Seconds Other Time Units 60 1M 1800 30M 3600 1H 10800 3H 21600 6H 43200 12H 86400 1D 259200 3D 604800 1W Table 16-1. Seconds compared to other time units The following example illustrates the form an SOA resource record might take when it is configured with real values. @ IN SOA dns1.domain.com. hostmaster.domain.com.
Chapter 16. Berkeley Internet Name Domain (BIND) 239 In this example, standard directives and SOA values are used. The authoritative nameservers are set to be dns1.domain.com and dns2.domain.com, which have A records that tie them to 10.0.1.2 and 10.0.1.3, respectively. The email servers configured with the MX records point to server1 and server2 via CNAME records. Since the server1 and server2 names do not end in a trailing dot (.), the $ORIGIN domain is placed after them, expanding them to server1.
Chapter 16. Berkeley Internet Name Domain (BIND) address to be reversed and ".in-addr.arpa" to be included after them. This allows the single block of IP numbers used in the reverse name resolution zone file to be correctly attached with this zone. 16.3. Using rndc BIND includes a utility called rndc which allows you to use command line statements to administer the named daemon, locally, or remotely. The rndc program uses the /etc/rndc.
Chapter 16. Berkeley Internet Name Domain (BIND) 241 16.3.1.2. /etc/rndc.conf You need to add the following lines to /etc/rndc.conf if rndc is to automatically use the keys specified in /etc/named.conf.
Chapter 16. Berkeley Internet Name Domain (BIND) • stats • stop — Dumps the current named stats to the /var/named/named.stats file. — Stops the server gracefully, saving any dynamic update and IXFR data before exiting. Occasionally, you may want to override the default settings in the /etc/rndc.conf file. The following options are available: • -c Û • -p Û configuration-file /etc/rndc.conf. port-number than the default 953.
Chapter 16. Berkeley Internet Name Domain (BIND) 243 16.4.2. Multiple Views Through the use of the view statement in /etc/named.conf, BIND allows you to configure a nameserver to answer queries for some clients in a different way than it answers them for others. This is primarily used to deny particular types of DNS queries from clients outside of your network, while allowing those same queries from clients on the local network.
• Chapter 16. Berkeley Internet Name Domain (BIND) Remember to place dots (.) in zone files after all FQDNs and omit them on hostnames. The dot denotes a fully qualified domain name. If the dot is omitted, then named will place the name of the zone or the $ORIGIN value after the name to complete it. • If you are having problems with your firewall blocking connections from your named program to other nameservers, you may need to edit its configuration file.
Chapter 16. Berkeley Internet Name Domain (BIND) • 245 http://www.redhat.com/mirrors/LDP/HOWTO/DNS-HOWTO.html — Covers the use of BIND as a resolving, caching nameserver or the configuration of various zone files necessary to serve as the primary nameserver for a domain. 16.6.3.
Chapter 16.
Chapter 17. Network File System (NFS) NFS (Network File System) exists to allow hosts to mount partitions on a remote system and use them as though they were local file systems. This allows files to be organized in a central location, while providing the functionality of allowing authorized users continuous access to them. Two versions of NFS are currently in use. NFS version 2 (NFSv2), which has been around for several years, is widely supported by various operating systems.
Chapter 17. Network File System (NFS) permitted or prevented access to the NFS server. For more information on configuring access controls with TCP wrappers, see Chapter 8. After the client is allowed past TCP wrappers, the NFS server refers to its configuration file, /etc/exports, to determine whether the client has enough privileges to mount any of the exported file systems. After granting access, any file and directory operations are sent to the server using remote procedure calls.
Chapter 17. Network File System (NFS) 100005 100003 100003 100021 100021 100021 3 2 3 1 3 4 tcp udp udp udp udp udp 1106 2049 2049 1028 1028 1028 249 mountd nfs nfs nlockmgr nlockmgr nlockmgr The -p option probes the portmapper on the specified host or defaults to localhost if no specific host is listed. Other options are available from the rpcinfo man page. From the output above, various NFS services can be seen running.
Chapter 17. Network File System (NFS) 17.2.1. /etc/exports The /etc/exports file is the standard for controlling which file systems are exported to which hosts, as well as specifying particular options that control everything. Blank lines are ignored, comments can be made using #, and long lines can be wrapped with a backslash (\). Each exported file system should be on its own line. Lists of authorized hosts placed after an exported file system must be separated by space characters.
Chapter 17. Network File System (NFS) 251 However, be careful when using wildcards with fully qualified domain names, as they tend to be more exact than you would expect. For example, the use of *.domain.com as wildcard will allow sales.domain.com to access the exported file system, but not bob.sales.domain.com. To match both possibilities, as well as sam.corp.domain.com, you would have to provide *.domain.com *.*.domain.com.
Chapter 17. Network File System (NFS) The ã options ä area specifies how the file system is to be mounted. For example, if the options area states rw,suid on a particular mount, the exported file system will be mounted read-write and the user and group ID set by the server will be used. Note, parentheses are not to be used here. For more mount options, see Section 17.3.3. 17.3.2.
Chapter 17. Network File System (NFS) 253 This line states that any directory a user tries to access under the local /home directory (due to the asterisk character) should result in an NFS mount on the server.domain.com system within its exported /home file system. The mount options specify that each /home directory NFS mounts should use a particular collection of settings. For more information on mount options, including the ones used in this example, see Section 17.3.3. 17.3.3.
Chapter 17. Network File System (NFS) 17.4.1. Host Access NFS controls who can mount an exported file system based on the host making the mount request, not the user that will actually use the file system. Hosts must be given explicit rights to mount the exported file system. Access control is not possible for users, other than file and directory permissions.
Chapter 17. Network File System (NFS) 255 • fstab — Gives details for the format of the /etc/fstab file used to mount file systems at • nfs — Provides detail on NFS-specific file system export and mount options. • exports — Shows common options used in the /etc/exports file when exporting NFS file system boot. systems. 17.5.2.
Chapter 17.
Chapter 18. Lightweight Directory Access Protocol (LDAP) Lightweight Directory Access Protocol (LDAP) is a set of open protocols used to access centrally stored information over a network. It is based on the X.500 standard for directory sharing, but is less complex and resource intensive. For this reason, LDAP is sometimes referred to as X.500 Lite. Like X.500, LDAP organizes information in a hierarchal manner using directories.
Chapter 18. Lightweight Directory Access Protocol (LDAP) • Updated C API — Improves the way programmers can connect to and use the application. • LDIFv1 Support — Full compliance with the LDAP Data Interchange Format (LDIF) version 1. • Enhanced Stand-Alone LDAP Server — Includes an updated access control system, thread pooling, better tools and much more. 18.2.
Chapter 18. Lightweight Directory Access Protocol (LDAP) • ldapsearch 259 — Searches for entries in the LDAP directory using a shell prompt. — Deletes entries from an LDAP directory by accepting input via user input at the terminal or via a file. • ldapdelete With the exception of ldapsearch, each of these utilities is more easily used by referencing a file containing the changes to be made rather than typing a command for each entry you wish to change in an LDAP directory.
Chapter 18. Lightweight Directory Access Protocol (LDAP) 18.3. LDAP Terminology An entry is one unit in an LDAP directory. Each entry is identified by its unique Distinguished Name (DN). Each entry has attributes, which are pieces of information directly associated with the entry. For example, an organization could be an LDAP entry. Attributes associated with the organization might be its fax number, its address, and so on. People can also be entries in the LDAP directory.
Chapter 18. Lightweight Directory Access Protocol (LDAP) 261 — This is the configuration file for the slapd daemon. See Section 18.4.1 for more information about this file. • /etc/openldap/slapd.conf Note If the nss_ldap package is installed, it will create a file named /etc/ldap.conf. This file is used by the PAM and NSS modules supplied by the nss_ldap package. See Section 18.7 for more information about this configuration file. 18.4.1. slapd.
Chapter 18. Lightweight Directory Access Protocol (LDAP) Tip If you are using the slapadd command-line tool locally to populate the LDAP directory, using the rootpw directive is not necessary. 18.4.2. The /etc/openldap/schema/ Directory The /etc/openldap/schema/ directory holds LDAP definitions, previously located in the slapd.at.conf and slapd.oc.conf files. All attribute syntax definitions and objectclass definitions are now located in the different schema files.
Chapter 18. Lightweight Directory Access Protocol (LDAP) 263 The basic steps for creating an LDAP server are as follows: 1. Install the openldap, openldap-servers, and openldap-clients RPMs. 2. Edit the /etc/openldap/slapd.conf file to reference your LDAP domain and server. Refer to Section 18.4.1 for more information on how to edit this file. 3.
Chapter 18. Lightweight Directory Access Protocol (LDAP) 18.7.2.2. On the Clients, Edit /etc/ldap.conf and /etc/openldap/ldap.conf On all client machines, both /etc/ldap.conf and /etc/openldap/ldap.conf need to contain the proper server and search base information for your organization. The simplest way to do this is to run the authconfig application and select Use LDAP on the the User Information Configuration screen. You can also edit these files by hand. 18.7.2.3.
Chapter 18. Lightweight Directory Access Protocol (LDAP) Existing name service Is LDAP running? Script to Use /etc flat files yes migrate_all_online.sh /etc flat files no migrate_all_offline.sh NetInfo yes migrate_all_netinfo_online.sh NetInfo no migrate_all_netinfo_offline.sh NIS (YP) yes migrate_all_nis_online.sh NIS (YP) no migrate_all_nis_offline.sh 265 Table 18-1. LDAP Migration Scripts Run the appropriate script based on your existing name service.
Chapter 18. Lightweight Directory Access Protocol (LDAP) 18.8.3. Related Books • Implementing LDAP by Mark Wilcox; Wrox Press, Inc. • Understanding and Deploying LDAP Directory Services by Tim Howes et al.
Appendixes
Appendix A. General Parameters and Modules This appendix is provided to illustrate some of the possible parameters available for some common hardware device drivers1. In most cases, these additional parameters are unnecessary, since the kernel may already be able to use the device without them. You should only use the settings provided in this appendix if you are having trouble getting Red Hat Linux to use a particular device or you need to override the system’s default parameters for the device.
Appendix A. General Parameters and Modules Note Only use one method, and not both, when loading a module with particular parameters. Caution When a parameter has commas, make sure you do not put a space after a comma. A.2. CD-ROM Module Parameters Note Not all of the CD-ROM drives that are listed are supported. Please check the Hardware Compatibility List on Red Hat’s website at http://hardware.redhat.com to make sure your CD-ROM drive is supported.
Appendix A. General Parameters and Modules 271 Hardware Module Parameters ISP16, MAD16, or Mozart sound card CD-ROM interface (OPTi 82C928 and OPTi 82C929) with Sanyo/Panasonic, Sony, or Mitsumi drives isp16.o isp16=io_port,IRQ,dma, drive_type OR isp16_cdrom_base=io_port isp16_cdrom_irq=IRQ isp16_cdrom_dma=dma isp16_cdrom_type=drive_type Mitsumi CD-ROM, Standard mcd.o mcd=io_port,IRQ Mitsumi CD-ROM, Experimental mcdx.
Appendix A. General Parameters and Modules Note Most newer Sound Blaster cards come with IDE interfaces. For these cards, you do not need to use sbpcd parameters; only use hdX parameters. A.3. SCSI parameters Hardware Module Adaptec 28xx, R9xx, 39xx aic7xxx.o 3ware Storage Controller 3w-xxxx.o NCR53c810/820/720, NCR53c700/710/700-66 53c7,8xx.o Parameters AM53/79C974 (PC-SCSI) Driver AM53C974.o Most Buslogic (now Mylex) cards with "BT" part number BusLogic.
Appendix A. General Parameters and Modules Hardware Module ACARD ATP870U PCI SCSI Controller atp870u.o Compaq Smart Array 5300 Controller cciss.o Compaq Smart/2 RAID Controller cpqarray.o 273 Parameters Compaq FibreChannel Controller cpqfc.o Domex DMX3191D dmx3191d.o Data Technology Corp DTC3180/3280 dtc.o DTP SCSI host adapters (EATA/DMA) PM2011B/9X ISA, PM2021A/9X ISA, PM2012A, PM2012B, PM2022A/9X EISA, PM2122A/9X, PM2322A/9X, SmartRAID PM3021, PM3222, PM3224 eata.
Appendix A. General Parameters and Modules Hardware Module Parameters NCR SCSI controllers with 810/810A/815/ 825/825A/860/875/876/895 chipsets ncr53c8xx.o ncr53c8xx=option1:value1, option2:value2,... OR ncr53c8xx="option1:value1 option2:value2..." Pro Audio Spectrum/Studio 16 pas16.o PCI-2000 IntelliCache pci2000.o PCI-2220I EIDE RAID pci2220i.o IOMEGA PPA3 parallel port SCSI host adapter ppa.o Perceptive Solutions PSI-240I EIDE psi240i.o Qlogic 1280 qla1280.o Qlogic 2x00 qla2x00.
Appendix A. General Parameters and Modules 275 Configuration Example Future Domain TMC-800 at CA000, IRQ 10 controller_type=2 base_address=0xca000 irq=10 Table A-4. SCSI Parameters Configuration Examples A.4. Ethernet Parameters Hardware Module Parameters 3Com 3c501 3c501.o 3c501=io_port,IRQ 3Com 3c503 and 3c503/16 3c503.o 3c503=io_port,IRQ OR 3c503 io=io_port_1,io_port_n irq=IRQ_1,IRQ_n 3Com EtherLink Plus (3c505) 3c505.
Appendix A. General Parameters and Modules Hardware Module Crystal SemiconductorCS89[02]0 cs89x0.o EtherWORKS DE425 de4x5.o TP/COAX EISA, DE434 TP PCI, DE435/450 TP/COAX/AUI PCI DE500 10/100 PCI Kingston, LinkSys, SMC8432, SMC9332, Znyx31[45], and Znyx346 10/100 cards with DC21040 (no SROM), DC21041[A], DC21140[A], DC21142, DC21143 chipsets Parameters de4x5=io_port OR de4x5 io=io_port de4x5 args=’ethX[fdx] autosense=MEDIA_STRING’ D-Link DE-600 Ethernet Pocket Adapter de600.
Appendix A. General Parameters and Modules 277 Hardware Module Parameters Intel EtherExpress 16 (i82586) eexpress.o eexpress=io_port,IRQ OR eexpress io=io_port irq=IRQ options= 0x10 10base T half duplex 0x20 10base T full duplex 0x100 100base T half duplex 0x200 100baseT full duplex SMC EtherPower II 9432 PCI (83c170/175 EPIC series) epic100.o Racal-Interlan ES3210 EISA es3210.o ICL EtherTeam 16i/32 EISA eth16i.
Appendix A. General Parameters and Modules Hardware Module MiCom-Interlan NI5010 ni5010.o NI5210 card (i82586 Ethernet chip) ni52.o NI6510 Ethernet ni65.o IBM Olympic-based PCI token ring olympic.o AMD PCnet32 and AMD PCnetPCI pcnet32.o SIS 900/701G PCI Fast Ethernet sis900.o SysKonnect SK-98XX Gigabit sk98lin.o SMC Ultra and SMC EtherEZ ISA ethercard (8K, 83c790) smc-ultra.o SMC Ultra32 EISA Ethernet card (32K) smc-ultra32.o Sun BigMac Ethernet sunbmac.
Appendix A. General Parameters and Modules 279 Hardware Module Parameters WD8003 and WD8013-compatible Ethernet cards wd.o wd=io_port,IRQ,mem, mem_end OR wd io=io_port irq=IRQ mem=mem mem_end=end Compex RL100ATX-PCI winbond.o Packet Engines Yellowfin yellowfin.o Table A-5.
Appendix A.
Index Apache configuration directive, 200 AddIconByEncoding Symbols .fetchmailrc, 217 global options, 218 server options, 218 user options, 218 .procmailrc, 220 /dev directory, 18 /etc directory, 18 /etc/exports, 250 /etc/fstab, 251 /etc/named.conf (See BIND) /etc/pam.conf, 111 (See Also PAM) /etc/pam.
B Basic Input/Output System (See BIOS) Berkeley Internet Name Domain (See BIND) BIND additional resources, 244 installed documentation, 244 related books, 245 useful websites, 244 common mistakes, 243 configuration files, 230 /etc/named.
DefaultIcon, 200 DefaultType, 196 Deny, 195 Directory, 193 DirectoryIndex, 195 DocumentRoot, 193 ErrorDocument, 202 ErrorLog, 197 ExtendedStatus, 192 for cache functionality, 203 for SSL functionality, 204 Group, 193 HeaderName, 200 HostnameLookups, 196 IfDefine, 192 IfModule, 196 Include, 191 IndexIgnore, 200 IndexOptions, 199 KeepAlive, 190 KeepAliveTimeout, 190 LanguagePriority, 201 Listen, 191 LoadModule, 192 Location, 202 LockFile, 189 LogFormat, 197 LogLevel, 197 MaxClients, 191 MaxKeepAliveReque
changing, 206 changing shared, 207 DoS (See Denial of Service) DoS attack (See Denial odf Service attack) drag and drop, xiii drivers (See kernel modules) DSOs loading, 205 E e-mail (See email) EFI shell definition of, 55 (See Also boot process) ELILO, 60, 77 email, 209 additional resources, 226 installed documentation, 226 related books, 227 useful websites, 227 Fetchmail, 216 Procmail, 220 program classifications, 211 protocols, 209 IMAP, 209 POP, 209 SMTP, 210 security, 225 clients, 225 servers, 22
useful websites, 87 boot process, 77 changing runlevels with, 81, 86 commands, 81 configuration file /boot/grub/grub.conf, 83 structure, 83 definition of, 77 features, 78 installing, 78 interfaces, 80 command line, 81 menu, 81 menu entry editor, 81 order of use, 81 menu configuration file, 82 commands, 83 role in boot process, 56 terminology, 79 devices, 79 files, 80 root filesystem, 80 grub.
K KDE, 102 (See Also XFree86) KeepAlive Apache configuration directive, 190 KeepAliveTimeout Apache configuration directive, 190 Kerberos additional resources, 142 installed documentation, 143 useful websites, 143 advantages of, 137 and PAM, 140 clients set up, 142 definition of, 137 disadvantages of, 137 how it works, 139 Key Distribution Center (KDC), 139 server set up, 140 terminology, 138 Ticket Granting Service (TGS), 139 Ticket Granting Ticket (TGT), 139 kernel role in boot process, 57 kernel mod
(See Also LILO) Listen Apache configuration directive, 191 LoadModule Apache configuration directive, 192 Location Apache configuration directive, 202 LockFile Apache configuration directive, 189 log files common logfile format, 197 LogFormat Apache configuration directive, 197 LogLevel Apache configuration directive, 197 lspci, 35 M Mail Delivery Agent, 212 Mail Transfer Agent, 211 Mail User Agent, 211 Master Boot Record (See MBR) (See MBR) master nameserver (See BIND) MaxClients Apache configuration
(See kernel modules) non-secure Web server disabling, 207 ntsysv, 62 (See Also services) O objects, dynamically shared (See DSOs) OpenLDAP (See LDAP) OpenSSH, 129 (See Also SSH) configuration files for, 132 Options Apache configuration directive, 194 Order Apache configuration directive, 194 P packet filtering (See iptables) PAM additional resources, 117 installed documentation, 117 useful websites, 117 advantages of, 111 configuration files, 111 control flags, 113 definition of, 111 Kerberos and, 14
/proc/uptime, 37 /proc/version, 37 additional resources, 53 installed documentation, 53 useful websites, 53 changing files within, 24, 45, 52 files within, top-level, 24 introduced, 23 process directories, 37 subdirectories within, 37 viewing files within, 23 Procmail, 220 additional resources, 226 configuration, 220 recipes, 221 delivering, 222 examples, 224 flags, 222 local lockfiles, 223 non-delivering, 222 special actions, 223 special conditions, 223 programs running at boot time, 60 proxy server,
(See Also LDAP) slappasswd command, 258 (See Also LDAP) slave nameserver (See BIND) slurpd command, 258 (See Also LDAP) SSH protocol, 129 authentication, 131 configuration files, 132 connection sequence, 130 features of, 129 insecure protocols and, 135 layers of, 130 channels, 132 transport layer, 131 port forwarding, 134 requiring for remote login, 135 security risks, 130 X11 forwarding, 133 SSL directives, 204 StartServers Apache configuration directive, 191 startx, 103 (See Also XFree86) structure c
additional resources, 156 installed documentation, 156 useful websites, 156 applications, 155 tripwire, 155 tripwire-check, 150 twadmin, 153, 154, 155 twinstall.sh, 155 twprint, 150, 151, 155 configuration files, 155 database file, 155, 155 key files, 155 modifying, 147 report files, 155, 155 signing of, 154 tw.cfg, 155, 155 tw.pol, 155, 155 twcfg.txt, 155 twpol.
X X (See XFree86) X Window System (See XFree86) X.500 (See LDAP) X.
Colophon The Official Red Hat Linux manuals are written in DocBook SGML v4.1 format. The HTML and PDF formats are produced using custom DSSSL stylesheets and custom jade wrapper scripts. Marianne Pecci created the admonition graphics (note, tip, important, caution, and warning). They may be redistributed with written permission from Marianne Pecci and Red Hat, Inc.. The Red Hat Linux Product Documentation Team consists of the following people: Sandra A.
