/etc/fstab broken down and explained

Written by tylerburns - 2006-03-24 22:59

The /etc/fstab file is used by some programs to determine file system types and mount points. If you are new to linux, configuration files can seem cryptic and intimidating. This tutorial contains an example /etc/fstab file broken down and thoroughly explained. Keep in mind that the sample that is broken down and explained is larger than your typical /etc/fstab so that this tutorial can be applicable to a wider audience. I also included the /etc/fstab from my personal computer. EXAMPLE: 1 #device mount point file system options dump check 2 3 /dev/hda1 / reiserfs defaults 0 1 4 /dev/hdb1 /home ext2 auto,notail 1 1 5 /dev/hdc /mnt/cdrom iso9660 defaults 0 0 6 /dev/hdd /mnt/dvdrw iso9660 ro,users,noauto 0 0 7 /dev/sda1 /usr reiserfs ro, owner 0 1 8 /dev/fd0 /mnt/floppy auto user 0 0 9 /dev/hda5 swap swap defaults 0 0 10 host:/var /root/var nfs uid=0,gid=0 1 0 11 proc /proc proc proc defaults 0 0 The numbers at the beginning of each line of Advertisement the example file are for reference use of this <script></script> tutorial. If line numbers were added to an actual configuration files the result would be not being able to boot after the next shutdown and the common mount: can't find /dev/hde in /etc/fstab or /etc/mtab error message when you try to mount a file system. The first line of the example file is a comment, which is ignored by the process reading the file. Commenting lines out in linux configuration files is done by using the # character. Comments are very useful for people reading or editing the file. In fact, this whole tutorial could be contained inside a working, fully functional, /etc/fstab file if the lines containing text explaining things were commented out with #. The # character is universally used in linux configuration files to identify comments. Many distributions include a commented line at the beginning of the file to show what each column defines. As you have more than likely noticed, the /etc/fstab file is divided into columns. The first column defines the device file pointing to the device with the file system to be mounted. The second column is the mount point, or the directory where the file system can be accessed. Column number three defines the file system type used on file system being mounted. An important thing to remember about file system types is that in order for you to be able to mount and use a volume, you must have support for the file system type compiled into the kernel itself or have a kernel module for it. Kernel issues are beyond

the scope of this tutorial. The fourth column is used for mount options. Some mount options are file system specific. A chart has been included to explain common mounting options. The fifth column is the dump column. It is used by the dump utility to determine whether or not it should back up the file system being defined. A 0 means it won't be backed up, and a 1 tells dump to back it up. This document will not go into the details of the dump utility. The sixth column is the order fsck checks a file system when the system is booted. A 0 in this column indicates fsck will never check a file system. This value should be used for removable media such as CD and floppy drives. Any value greater than one tells fsck to check the file system at boot. The order they are checked is the numerical order of values assigned in this column. The second line serves no purpose other than making it easier to read by someone editing the file. Line number three in this example is technically the only line you absolutely must have, although you should never configure your system this way if you want it to be stable. You should also define a swap partition, which will be explained later. The reason this line is necessary is because it defines the root directory to be mounted when the system boots. Since other file systems are mounted in locations within the root directory, logically you won't be able to mount any file systems without a root directory defined. Mounting another file system before mounting the file system designated to have the root partition is like giving driving directions to use a road that hasn't been built yet. Line number four defines a separate partition to be used as users home directories. It is often wise to use a separate partition for home directories. It preserves user preferences and files in the case of a new installation or re-installation. Line number five defines an IDE CDROM drive, and line six defines another optical drive. Typical mount options for optical drives are user, users, noauto, ro, auto, and defaults. Defaults shouldn't be used on workstations or personal computer systems because only root will be able to mount a file system on a CD or DVD. Line seven is an example of defining a SCSI partition. Line eight defines a floppy drive. As you probably notice the file system type is auto. This means the system will attempt to automatically detect the file system type the defined device uses. The ninth of the example file defines a swap partition. While not mandatory, it is highly recommended to define a swap partition in /etc/fstab. You should ALWAYS define a swap partition. Swap partitions are nothing more than dedicated partitions used for virtual memory. It is also possible to use a file dedicated to virtual memory but it is beyond this tutorial. Virtual memory is used when the kernel or applications use up all of your systems RAM or move data there to clear space in the immensely faster system RAM for other data.

The second to last line of the example file shows an NFS mount. As you probably noticed a device file isn't specified. In the column where the device file is normally defined, the NFS server hostname and export directory are specified. The uid=0, and gid=0 tells the computer to make the group and user with the specified ids. In this example both the group and user id are 0, which is the user root and group root. Mounting file systems with specific user and group ids can be a useful security or accessibility tool. Last but not least, is the proc file system. The proc file system is a virtual file system used by the kernel to store hardware information. Some processes use it to retrieve information about hardware. If left undefined the system will use space on whatever device is mounted as the root partition. If this tutorial doesn't cover what you are looking for doesn't include what you are looking for, I am going to point you in the right direction on finding help. For file system specific mount options try looking through the mount man and info pages. To access them type man mount or info mount at any shell prompt. Another good source is the Internet. Try searching for a web page using your favorite search engine. Forums such as the one at linuxquestions.org are great places to seek help. Your local bookstore might have some good linux books. QUICK REFERENCES column breakdown: column description 1 device file 2 mount point 3 file system type 4 mount option 5 fsck order 6 dump (1= backup, 0=don't backup) common mount options: option definition auto automatically mounts at boot noauto doesn't automatically mount at boot owner only root or the owner of the device file can mount this file system user allows any user to mount a file system, only root or the user who mounted the file system can unmount it users same as user except any user can unmount it ro mounts the file system as read only defaults mounts the file system with the default options uid=x mounts the file system as user with id x (ownership)

gid=x mounts the file system as group with id x (ownership) noexec prevents the execution of files on specified device the /etc/fstab from my personal computer: # /etc/fstab: static file system information. # # proc /proc proc defaultes 0 0 /dev/hda8 / reiserfs notail 0 1 /dev/hda7 none swap sw 0 0 /dev/hdc /media/combo iso9660 defaults 0 0 /dev/hdd /media/cdrw iso9660 ro,user,noauto 0 0 /dev/fd0 /media/floppy auto rw,user,noauto 0 0 /dev/hda1 /media/windows ntfs user,ro,auto 0 0 /dev/hda6 /media/media ntfs user,ro,auto 0 0 /dev/hda5 /media/games ntfs user,ro,auto 0 0 /dev/hdb1 /media/storage ntfs user,ro,auto 0 0 Any feedback regarding this document would be appreciated as I plan to write more articles breaking down common configuration files. The following copyright notice is to keep this document free as in freedom, and price. It is also added to give credit where credit is due. COPYRIGHT MARCH 2006 by Tyler M. Burns. This document may be distributed electronically. This document may be used as a technical reference for writing other documents. Printing is authorized as long as it isn't published. This documents defines publishing as distribution of this document in exchange for money or goods. This includes but is not limited to books, magazines, and newspapers. Publishing is prohibited unless hard copy, written permission is given by the author to the person or organization wanting to publish this tutorial. Modifications are allowed as long as they are released with this copyright, which must remain unmodified. Modifications require the name and email address of the author of the original document and author(s) of modified version(s) if the modification is made to an already modified version of this document. Modified versions must note the modifications made. Publishing of modified versions require the written permission of both the original author and the author of the modification. Modifications must contain at minimum the email addresses of the author of the original documents and author(s) of modifications in the contact information section below. Failure to provide contact information for modifications will forfeit all rights to the author of the original document. In the event the author and if applicable author(s) of modification(s) do not respond to a request to publish this document, this document may not be published. Appropriate legal actions will be taken for any violation of this copyright.

Introduction

Samba can be used to allow connectivity between Linux and Windows(95,98,NT,2000). Samba can be used to share printers, share directories, connect to an NT domain, and many other useful features. However, this tutorial explains the steps involved in basic configuring Samba for file and print sharing. For more complex topics, visit the Samba website or type the command man smb.conf on a Linux machine with Samba installed. Configuring Samba is done by editing the configuration file /etc/smb.conf that is usually located under the /etc directory. Everytime you modify this file, Samba must be restarted for the changes to take effect. Basic Samba

Information Starting, Stopping, and Restarting Samba

Most Linux distributions come with scripts to start, stop, and restart Samba properly. If yours does not, use the commands under the Optional Commands column Runlevel Script Optional Command
-D and Start Samba /etc/rc.d/init.d/samba start /usr/sbin/smbd /usr/sbin/nmbd -D -TERM smbd and killall Stop Samba /etc/rc.d/init.d/samba stop killall -TERM nmbd

Restart Samba

/etc/rc.d/init.d/samba restart

killall -HUP smbd -HUP nmbd

and killall

Samba Log Files

All Samba actions such as login attempts and file transfers can be logged in the /var/log/samba directory. Under this directory the actions are logged by machine name. For example, all actions from the machine named "Morpheus" are logged in the file /var/log/samba/log.morpheus. User actions can also be logged under two files named /var/log/log.smb and /var/log/log.nmb. This is configured in the smb.conf file using the option log file. For example, to log actions by machine name use the following line:
log file = /var/log/samba/log.%m

Windows Workgroup
You can specify which Windows Network Neighborhood Workgroup your Linux machine is seen in and the description of the machine by editing the following lines in smb.conf:
workgroup = WORKGROUPNAME server string = MACHINE DESCRIPTION

Access Control

can be used to allow and deny access by IP addresses. This is done by listing IP addresses or subnets on the lines beginning with hosts allow and hosts deny. Examples: Example Explanation
smb.conf hosts allow 192.168.10.0/255.255.255.0 hosts allow 160.210 EXCEPT 160.210.24.56 hosts allow 192.168.10 192.168.20 hosts deny 130.74

Allow all hosts in the given network/netmask Allow all hosts beginning with 160.210 except 160.210.24.56 allow all hosts beginning with 192.168.10 or 192.168.20 deny all hosts beginning with 130.74

Using Samba with Windows NT 4.0 Service Pack 3 or higher

Samba can be configured to send plain-text passwords or encrypted passwords. The Microsoft SMB protocol originally used plain-text passwords. However, with Service Pack 3 or higher for Windows NT 4.0, they changed the protocol to use encrypted passwords. Samba must be configured for this to connect to Windows NT 4.0 machines. One way to do this is to modify the NT registry; however, if you choose this option all NT machines must be configured to use plain-text passwords which is time-consuming and might cause conflicts elsewhere. The easy way to handle this is to configure Samba to send encrypted passwords. This can be done with the following steps: 1. Create a separate password file for Samba based on your /etc/passwd file. This will create Samba users for every user that already exists on your system. To do this by executing the command cat /etc/passwd | mksmbpasswd.sh > /etc/smbpasswd. The script should be in the /usr/bin directory or you can get it here. 2. Make sure only root has permission to read and write to the Samba password file with the command chmod 600 smbpasswd. 3. The script does not copy the passwords. To set the Samba password for each users thus enabling their Samba accounts, use the command smbpasswd username for each user. 4. Edit the smb.conf file to include the two lines 5.
encrypt passwords = yes smb passwd file = /etc/smbpasswd Restart Samba with /etc/rc.d/init.d/smb restart

Print Sharing from Linux to Windows

[printers] comment = All Printers path = /var/spool/samba browseable = no

The following section is usually included in the sample smb.conf that allows printers defined in the /etc/printcap file to be shared. If not add/uncomment the following lines in smb.conf:

Then, just restart Samba and add the Linux printer to a Windows machine as you would any other Window's shared printer. The printer name will be the same name specified in the /etc/printcap file such as lp.

Creating a Common Share Directory for Multiple Users

[myshare] comment = Share for John and Sam path = /usr/share valid users = john sam public = no writable = yes printable = no create mask = 0765

You can create a share directory more than one user has permission to view. This is similar to a Linux/Unix group definition. The best way to explain this is to show an example:

This shares the directory /usr/share for only the users john and sam. It is writable which means both john and sam have write permissions to the shared directory. Any files/directories created in the shared directory will have the permission 0765.

Connecting to a Samba Machine in Linux

smbclient //MACHINENAME/sharename

To connect to a Samba machine (Windows or Linux running Samba) from the command line, execute the command (replace MACHINENAME and sharename with the appropriate values) If you want to pass a different username to the Samba Server, execute the command (replace username with your username).
smbclient //MACHINENAME/sharename -U username

If a password is associated with the username, you will be prompted for it. Once you are authorized by the SMB protocol, you will be at a smb: \> prompt. This is similar to an ftp session where get, put, pwd, ls, etc. can be used to navigate. Type help for a list of commands.

Configuring Windows Machines

Connect to a Linux machine running Samba the same way you connect to any Windows machine - browse through Network Neighboorhood or Windows Explorer entering a password if required. Note: Windows 95/98 only prompts for a password and assumes the Windows Login name as the username. You need to either create a user on your Linux box with your Windows Login or create a Windows Login with the same username on your Linux machine. Optionally, you can have the Windows Login and password for Windows 95/98/NT/2000 be the same as your Linux Samba username and password and it will not prompt for a password. Obviously, this is a security issue if others have access to your system. Your call.

Official Website

Samba Website

What's Related

Cable Modem Configuration Dial-up Networking Configuration using Red Hat netcfg Dial-up Networking Configuration using KDE's Kppp ipchains Configuration - Network Connection Sharing Network Configuration Using the Command Line Network Configuration Using Red Hat netcfg Network Configuration Using Red Hat linuxconf Network Configuration Using SuSE YaST Squid Proxy Server Configuration Samba Configuration - Linux / Windows Connectivity

Introduction This documentation describes the setup of the IPSec-protocol in Linux with the help of FreeS/WAN respectively OpenSwan. The installation and configuration of the WLAN-card is explained under Linux Network Configuration. The wireless network of the University of Freiburg uses the protocol IPSec. It replaces the usual IP protocol with an encrypted protocol. FreeS/WAN (OpenSwan) is a free implementation of this protocol in Linux. For old kernels (2.2 and 2.4) a patch is needed, kernel 2.6 has a native IPSec-stack and thus no patch is needed. Most recent distributions contain FreeS/WAN or OpenSwan in some way, therefore the installation usually proceeds smoothly. OpenSwan should be preferred, since development of FreeS/WAN has been discontinued. FreeS/WAN final release is 2.06. If a kernel with IPSec-support and FreeS/WAN including the x.509 patch or OpenSwan is already installed and a certificate has been created and downloaded, you can continue directly with the setup section. Remark: In SuSE 7.2 the kernel needs to be patched in order to work. An errorcorrected version must be installed. This is also true for Mandrake kernels up to version 2.4.6 .

Installing FreeS/WAN Users of OpenSwan should continue reading at the OpenSwan Installation section. FreeS/WAN consists of 2 components: some kernel modules several userspace-programs for configuration The userspace-programs are already provided by some distributions. In this case the corresponding packages just have to be installed. For all other distributions FreeS/WAN has to be installed, which is rather simple.

For the kernel modules, a new kernel must usually be compiled, since it has to be equipped with the corresponding patches. Remark: This documentation won't explain how to compile or patch a kernel for a specific distribution. This is explained sufficiently in each particular distribution. Furthermore this would go far beyond the limits of this documentation. Linux Distributions with FreeS/WAN Packages The following distributions already contain the package FreeS/WAN: Debian SuSE Mandrake CorelLinux Gentoo

In SuSE 7.2 FreeS/WAN is unfortunately installed incorrectly. An error-corrected version must be used. Altogether the kernel, the modules and the freeswan package have to be installed. The freeswan package in Mandrake is also installed incorrectly. Here, mandrake kernel 2.4.6 or better must be used. It is unknown whether or not Mandrake uses the newest version of FreeS/WAN, so we basically recommend installing a new kernel. It is also unknown which version of FreeS/WAN is used by CorelLinux. Therefore we also recommend installing FreeS/WAN on your own. For Debian both the kernel-patch-freeswan and the freeswan packages have to be installed. Next step is to compile the kernel. The most comfortable way to achieve this is by using "make-kpkg". In Gentoo the USE flags crypt and x509 must be set and a kernel containing FreeS/WAN must be installed with the corresponding super-freeswan or freeswan package. Installing FreeS/WAN from source Except for Debian/sid or Gentoo no other distributions are known, which provide regular current updates for FreeS/WAN. Therefore in most cases an installation directly from the current source code is recommended. First, the correct version of the kernel-sources has to be installed. For this either kernel-sources from kernel.org or those, which were delivered with the distributions may be used. In SuSE you have to pay attention to use the original Linux kernel, not the SuSE kernel. This has the disadvantage that several modules (e.g. lmsensors) are unavailable. They can be installed later if needed. Unfortunately the SuSE kernel already contains a wrong version of FreeS/WAN and thus can't be used. In Debian, the tool "make-kpkg" should be used Debian because it achieves a major part of the work.

In Redhat the kernel-sources can be used directly. If someone has experiences with other distributions, please share them with us.

After the kernel-sources have been installed (usually in the folder /usr/src/linux) the FreeS/WAN sources must be installed (usually in the folder /usr/src/freeswan). The sources are available at freeswan.org. Pay attention to installing at least version 1.96, or a newer one if possible. Additionally, the x509-patch is needed, which is available at strongsec.com. Some distributions also provide IPSec source code-packages, which partly already contain the x509-Patch. In this case it is recommended to use the provided packages for compiling (e.g. Debian-package kernel-patch-freeswan) to simplify matters. Before compiling FreeS/WAN, the kernel should be compiled and installed. Documentations on how to do this can be found for each particular distribution, resp. in the kernel-HOWTO at tldp.org. Next, FreeS/WAN should be installed, which can easily be done with "make oldgo" in the FreeS/WAN source folder. Further documentation is available at freeswan.org. After the new kernel has been installed, FreeS/WAN should work. This is visible as one of the messages when booting. When booting is finished, these messages can subsequently be viewed with the command "dmesg". It is recommended to deactivate the ipsec auto-start during system booting because it's sufficient to start it when inserting the PCMCIA-Card (with the configuration-files of the PCMCIA-Instructions it is already set this way). This way it is possible to avoid unnecessary trouble with other network connections. This can be accomplished by deleting the links in the corresponding Runlevel-Folder. [top]

OpenSwan Installation Users of FreeS/WAN should continue reading at the Setup section. To use OpenSwan with kernel 2.6, you simply have to fetch the sourcecode from openswan.org. Compiling and installing the userspace tools via "make programs" and "make install" should be enough, no kernel-patch is needed since it uses the kernels native IPSec-stack. Further, "setkey" from the ipsec-tools package is needed, which can be obtained at ipsec-tools.sf.net. Most distributions meanwhile come along with OpenSwan packages, they can also be used. Pay attention to use a recent version (we've tested it with 2.2.0).

Setup

Now the only remainder is the IPSec-setup. This requires two steps that should be almost identical for FreeS/WAN and OpenSwan. First a configuration has to be created, secondly a x.509v3 certificate has to be installed. IPsec Configuration In order to configure IPSec some data files must be edited. /etc/ipsec.secrets must contain the following (besides these entries the file should contain nothing but comments): /etc/ipsec.secrets : RSA key.pem "<CERTIFICATE-PASSWORD>"

Furthermore the data file /etc/ipsec.conf must be modified. Here too, no other entries should exist than the ones listed below, except if other IPSec-connections exist. But this case isn't explained any further, since it has nothing to do with the WLAN of the university... (alternatively the data file can also be downloaded at ipsec.conf): /etc/ipsec.conf # /etc/ipsec.conf - Free/Openswan IPsec configuration file for the # MobilePools-WLAN at the Faculty for Applied Sciences, University of Freiburg # uncomment the following line for Free/Openswan version 2 and above # version 2.0 config setup interfaces=%defaultroute klipsdebug=none plutodebug=none # delete the following two lines for Free/Openswan Version 2 and above plutoload=%search plutostart=%search conn mopo-connection keyingtries=1 authby=rsasig # uncomment the following line for Openswan > 2.3.0 # esp=aes128-sha1 right=10.1.0.2 rightsubnet=0.0.0.0/0 left=%defaultroute leftrsasigkey=%cert auto=start

rightrsasigkey=%cert # uncomment the next line for FreeS/WAN >= 2.0 or SuSE 9.0 # leftcert=cert.pem # replace by your account-name used to generate your certificate leftid=<ACCOUNT>@informatik.uni-freiburg.de rightid=root@ipsec.wlan.informatik.uni-freiburg.de compress=yes keylife=4h # uncomment the rest for FreeS/WAN >= 2.0 #conn clear # auto=ignore # #conn clear-or-private # auto=ignore # #conn private-or-clear # auto=ignore # #conn private # auto=ignore # #conn block # auto=ignore # #conn packetdefault # auto=ignore #

Here the corresponding name of the login-account at the Faculty of Applied Sciences has to be replaced at "leftid=<ACCOUNT>@informatik.uni-freiburg.de". If somebody still uses FreeS/WAN prior to version 1.96 (can be figured out with"ipsec --version") some further configuration needs to be done. For more information please view Heiko Oberdiek's mail to the mailing list! For FreeS/WAN (OpenSwan) version 2.0 and newer (resp. SuSE 9.0) only a few minor details in ipsec.conf must be adjusted. Precisely the following points: the first row must contain the following entry: version 2.0 (this doesn't count for SuSE 9.0) the rows containing plutoload and plutostart must be deleted completely (this doesn't count for SuSE 9.0). Since FreeS/WAN 2.0 there are so-called policy groups, which should be deactivated. View the example ipsec.conf. (this doesn't count for SuSE 9.0) One row containing leftcert=cert.pem must be added and the data file cert.pem has to be created to replace the data file x509.cert.der (this also counts for SuSE 9.0) OpenS/WAN >= 2.3.0 requires a line esp=aes128-sha1 to be added.

In ipsec.conf which is provided in the download-section, this additional entry already exists and is commented out. Furthermore the rows which are supposed to be deleted are already provided with comments. Installing the x.509v3 Certificate After a certificate has been created and downloaded in the certificate management it has to be prepared for its use in Linux (current IPSec-Implementations unfortunately don't support keys in PKCS12-format yet). For this purpose the program OpenSSL is needed. It is available in all common Linux distributions. With the help of these OpenSSL-commands the corresponding certificates and the private key are extracted from the PKCS12-certificate: conversion commands for the PKCS12 certificate openssl pkcs12 -in cert.p12 -clcerts -nokeys -out /etc/ipsec.d/cert.pem openssl pkcs12 -in cert.p12 -cacerts -nokeys -out /etc/ipsec.d/cacerts/root.pem openssl pkcs12 -in cert.p12 -nocerts -out /etc/ipsec.d/private/key.pem

Therefore the chosen password must be entered - for the last command, three times. Next the x509-cetificate must be extracted from the data file cert.pem for version 2.0 of FreeS/WAN and older. This works the following way: extracting the x509-certificate openssl x509 -inform PEM -in /etc/ipsec.d/cert.pem -outform DER -out /etc/x509cert.der

For FreeS/WAN version 2.0 and above the file cert.pem has to be copied into the folder /etc/ipsec.d/certs. Now everything should work. Depending on the way the PCMCIA package was installed FreeS/WAN is started automatically or must be started with "/etc/init.d/ipsec start", repectively the path where the init-scripts can be found in your distribution. Then an interface ipsec0 should exist (netstat -i) and the default-route should lead across this

4.2. Boot process, Init and shutdown

4.2.1. Introduction
One of the most powerful aspects of Linux concerns its open method of starting and stopping the operating system, where it loads specified programs using their particular configurations, permits you to change those configurations to control the boot process, and shuts down in a graceful and organized way. Beyond the question of controlling the boot or shutdown process, the open nature of Linux makes it much easier to determine the exact source of most problems associated with starting up or shutting down your system. A basic understanding of this process is quite beneficial to everybody who uses a Linux system. A lot of Linux systems use lilo, the LInux LOader for booting operating systems. We will only discuss GRUB, however, which is easier to use and more flexible. Should you need information about lilo, refer to the man pages and HOWTOs. Both systems support dual boot installations, we refer to the HOWTOs on this subject for practical examples and background information.

4.2.2. The boot process

When an x86 computer is booted, the processor looks at the end of the system memory for the BIOS (Basic Input/Output System) and runs it. The BIOS program is written into permanent read-only memory and is always available for use. The BIOS provides the lowest level interface to peripheral devices and controls the first step of the boot process. The BIOS tests the system, looks for and checks peripherals, and then looks for a drive to use to boot the system. Usually it checks the floppy drive (or CD-ROM drive on many newer systems) for bootable media, if present, and then it looks to the hard drive. The order of the drives used for booting is usually controlled by a particular BIOS setting on the system. Once Linux is installed on the hard drive of a system, the BIOS looks for a Master Boot Record (MBR) starting at the first sector on the first hard drive, loads its contents into memory, then passes control to it. This MBR contains instructions on how to load the GRUB (or LILO) boot-loader, using a pre-selected operating system. The MBR then loads the boot-loader, which takes over the process (if the boot-loader is installed in the MBR). In the default Red Hat Linux configuration, GRUB uses the settings in the MBR to display boot options in a menu. Once GRUB has received the correct instructions for the operating system to start, either from its command line or configuration file, it finds the necessary boot file and hands off control of the machine to that operating system.

4.2.3. GRUB features

This boot method is called direct loading because instructions are used to directly load the operating system, with no intermediary code between the boot-loaders and the operating system's main files (such as the kernel). The boot process used by other operating systems may differ slightly from the above, however. For example, Microsoft's DOS and Windows operating systems completely overwrite anything on the MBR when they are installed without incorporating any of the current MBR's configuration. This destroys any other information stored in the MBR by other operating systems, such as Linux. The Microsoft operating systems, as well as various other proprietary operating systems, are loaded using a chain loading boot method. With this method, the MBR points to the first sector of the partition holding the operating system, where it finds the special files necessary to actually boot that operating system. GRUB supports both boot methods, allowing you to use it with almost any operating system, most popular file systems, and almost any hard disk your BIOS can recognize. GRUB contains a number of other features; the most important include:

GRUB provides a true command-based, pre-OS environment on x86 machines to allow maximum flexibility in loading operating systems with certain options or gathering information about the system. GRUB supports Logical Block Addressing (LBA) mode, needed to access many IDE and all SCSI hard disks. Before LBA, hard drives could encounter a 1024cylinder limit, where the BIOS could not find a file after that point. GRUB's configuration file is read from the disk every time the system boots, preventing you from having to write over the MBR every time you change the boot options.

A full description of GRUB may be found by issuing the info grub command or at the GRUB site. The Linux Documentation Project has a Multiboot with GRUB MiniHOWTO.

4.2.4. Init
The kernel, once it is loaded, finds init in sbin and executes it. When init starts, it becomes the parent or grandparent of all of the processes that start up automatically on your Linux system. The first thing init does, is reading its initialization file, /etc/inittab. This instructs init to read an initial configuration script for the environment, which sets the path, starts swapping, checks the file systems, and so on. Basically, this step takes care of everything that your system needs to have done at system initialization: setting the clock, initializing serial ports and so forth.

Then init continues to read the /etc/inittab file, which describes how the system should be set up in each run level and sets the default run level. A run level is a configuration of processes. All UNIX-like systems can be run in different process configurations, such as the single user mode, which is referred to as run level 1 or run level S (or s). In this mode, only the system administrator can connect to the system. It is used to perform maintenance tasks without risks of damaging the system or user data. Naturally, in this configuration we don't need to offer user services, so they will all be disabled. Another run level is the reboot run level, or run level 6, which shuts down all running services according to the appropriate procedures and then restarts the system. Commonly, run level 3 is configured to be text mode on a Linux machine, and run level 5 initializes the graphical login and environment. More about run levels in the next section, see Section 4.2.5. After having determined the default run level for your system, init starts all of the background processes necessary for the system to run by looking in the appropriate rc directory for that run level. init runs each of the kill scripts (their file names start with a K) with a stop parameter. It then runs all of the start scripts (their file names start with an S) in the appropriate run level directory so that all services and applications are started correctly. In fact, you can execute these same scripts manually after the system is finished booting with a command like /etc/init.d/httpd stop or service httpd stop logged in as root, in this case stopping the web server. Special case Note that on system startup, the scripts in rc2.d and rc3.d are usually executed. In that case, no services are stopped. There are only services that are started. None of the scripts that actually start and stop the services are located in /etc/rc<x>.d. Rather, all of the files in /etc/rc<x>.d are symbolic links that point to the actual scripts located in /etc/init.d. A symbolic link is nothing more than a file that points to another file, and is used in this case because it can be created and deleted without affecting the actual scripts that kill or start the services. The symbolic links to the various scripts are numbered in a particular order so that they start in that order. You can change the order in which the services start up or are killed by changing the name of the symbolic link that refers to the script that actually controls the service. You can use the same number multiple times if you want a particular service started or stopped right before or after another service, as in the example below, listing the content of /etc/rc5.d, where crond and xfs are both started from a linkname starting with "S90". In this case, the scripts are started in alphabetical order.
[jean@blub /etc/rc5.d] ls K15httpd@ K45named@ K16rarpd@ K46radvd@ K20nfs@ K61ldap@ K20rstatd@ K65identd@

S08ipchains@ S08iptables@ S09isdn@ S10network@

S25netfs@ S26apmd@ S28autofs@ S30nscd@

S85gpm@ S90crond@ S90xfs@ S95anacron@

K20rusersd@ K20rwalld@ K20rwhod@ K25squid@ K34yppasswdd@

K74ntpd@ K74ypserv@ K74ypxfrd@ K89bcm5820@ S05kudzu@

S12syslog@ S13portmap@ S14nfslock@ S17keytable@ S20random@

S55sshd@ S95atd@ S56rawdevices@ S97rhnsd@ S56xinetd@ S99local@ S60lpd@ S80sendmail@

After init has progressed through the run levels to get to the default run level, the /etc/inittab script forks a getty process for each virtual console (login prompt in text mode). getty opens tty lines, sets their modes, prints the login prompt, gets the user's name, and then initiates a login process for that user. This allows users to authenticate themselves to the system and use it. By default, most systems offer 6 virtual consoles, but as you can see from the inittab file, this is configurable. can also tell init how it should handle a user pressing Ctrl+Alt+Delete at the console. As the system should be properly shut down and restarted rather than immediately power-cycled, init is told to execute the command /sbin/shutdown -t3 -r now, for instance, when a user hits those keys. In addition, /etc/inittab states what init should do in case of power failures, if your system has a UPS unit attached to it.
/etc/inittab

On most RPM-based systems the graphical login screen is started in run level 5, where /etc/inittab runs a script called /etc/X11/prefdm. The prefdm script runs the preferred X display manager, based on the contents of the /etc/sysconfig/desktop directory. This is typically gdm if you run GNOME or kdm if you run KDE, but they can be mixed, and there's also the xdm that comes with a standard X installation. But there are other possibilities as well. On Debian, for instance, There is an initscript for each of the display managers, and the content of the /etc/X11/default-displaymanager is used to determine which one to start. More about the graphical interface can be read in Section 7.3. Ultimately, your system documentation will explain the details about the higher level aspects of init. The /etc/default and/or /etc/sysconfig directories contain entries for a range of functions and services, these are all read at boot time. The location of the directory containing system defaults might be somewhat different depending on your Linux distribution. Besides the graphical user environment, a lot of other services may be started as well. But if all goes well, you should be looking at a login prompt or login screen when the boot process has finished. Other procedures We explained how SysV init works on x86 based machines. Startup procedures may vary on other architectures and distributions. Other systems may use the BSD-style init, where startup files are not split up into multiple /etc/rc<LEVEL>.d directories. It might also be possible that your system uses /etc/rc.d/init.d instead of

/etc/init.d.

4.2.5. Init run levels

The idea behind operating different services at different run levels essentially revolves around the fact that different systems can be used in different ways. Some services cannot be used until the system is in a particular state, or mode, such as being ready for more than one user or having networking available. There are times in which you may want to operate the system in a lower mode. Examples are fixing disk corruption problems in run level 1 so no other users can possibly be on the system, or leaving a server in run level 3 without an X session running. In these cases, running services that depend upon a higher system mode to function does not make sense because they will not work correctly anyway. By already having each service assigned to start when its particular run level is reached, you ensure an orderly start up process, and you can quickly change the mode of the machine without worrying about which services to manually start or stop. Available run levels are generally described in /etc/inittab, which is partially shown below:

# # inittab #

This file describes how the INIT process should set up the system in a certain run-level.

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

Feel free to configure runlevels 2 and 4 as you see fit. Many users configure those runlevels in a way that makes the most sense for them while leaving the standard runlevels 3 and 5 alone. This allows 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 file (or if you have simply forgotten your password), boot into single-user mode.

No graphics? When you are working in text mode because you didn't get presented a graphical login screen on the console of your machine, you can normally switch to console 7 or up to have a graphical login. If this is not the case, check the current run level using the command who -r. If it is set to something else than 5, chances are that the system does not start up in graphical mode by default. Contact your system administrator or read man init in that case. Note that switching run levels is done preferably using the telinit command; switching from a text to a graphical console or vice versa does not involve a run level switch. The discussion of run levels, scripts and configurations in this guide tries to be as general as possible. Lots of variations exist. For instance, Gentoo Linux stores scripts in /etc/runlevels. Other systems might first run through (a) lower runlevel(s) and execute all the scripts in there before arriving at the final runlevel and executing those scripts. Refer to your system documentation for more information.

4.2.5.1. Tools
The chkconfig or update-rc.d utilities, when installed on your system, provide a simple command-line tool for maintaining the /etc/init.d directory hierarchy. These relieve system administrators from having to directly manipulate the numerous symbolic links in the directories under /etc/rc[x].d. In addition, some systems offer the ntsysv tool, which provides a text-based interface; you may find this easier to use than chkconfig's command-line interface. On SuSE Linux, you will find the yast and insserv tools. For Mandrake easy configuration, you may want to try DrakConf, which allows among other features switching between run levels 3 and 5. In Mandriva this became the Mandriva Linux COntrol Center. Most distributions provide a graphical user interface for configuring processes, check with your system documentation. All of these utilities must be run as root. The system administrator may also manually create the appropriate links in each run level directory in order to start or stop a service in a certain run level.

4.2.6. Shutdown
UNIX was not made to be shut down, but if you really must, use the shutdown command. After completing the shutdown procedure, the -h option will halt the system, while -r will reboot it.

The reboot and halt commands are now able to invoke shutdown if run when the system is in runlevels 1-5, and thus ensure proper shutdown of the system,but it is a bad habit to get into, as not all UNIX/Linux versions have this feature. If your computer does not power itself down, you should not turn off the computer until you see a message indicating that the system is halted or finished shutting down, in order to give the system the time to unmount all partitions. Being impatient may cause data loss.

Packaging software with RPM, Part 1

Using RPM on Red Hat Linux 7.1

Docum Level: Introductory

E p

D o re Ja n

Using X to do m

Dow Exp

Rate th

Hel this

Dan Poirier (poirier@us.ibm.com), Software engineer, IBM 01 Nov 2001

RPM is a widely used tool for delivering software for Linux. Users can easily install an RPM-packaged prod article, the first in a series, IBM software engineer Dan Poirier shows you how to use RPM to package simpl Red Hat Linux 7.1 system.

RPM (Red Hat Package Manager) is the most common software package manager used for Linux distribu it allows you to distribute software already compiled, a user can install the software with a single command.

RPM is the designated install tool of the Linux Standard Base version 1.0.0. And eight of the top 10 Linux di RPM based (see the "Comparison of Linux Distributions" at distrowatch.com listed in Resources later in this some distributions that don't use RPM normally, like Debian, have tools available to convert RPMs to their o RPM is also the best choice for packaging software to be used on Linux by anyone other than developers.

Whether you've developed the software yourself, or you want to help an open source project by contributing build an RPM package from it, this article will help you get started. Future articles in this series, by the way, topics like building RPMs without having to be the root user, patching the software before building it, runnin install and uninstall, and running scripts when other packages are installed or uninstalled. A simple case I'll start with a simple case, using mostly RPM default values. Then I'll add a few optional features.

An RPM software package begins with a program in source form, ready to compile. Rather than creating a to chosen to use the GNU Indent program (see Resources).

Indent builds pretty easily under Linux. With the indent-2.2.6.tar.gz file in the current directory, all you do is

Building indent manually

$ $ $ $ $ tar xzf indent.2.2.6.tar.gz cd indent-2.2.6 ./configure make make install

This probably looks familiar if you've built many open source projects. The unpack; ./configure; make; sequence is typical of software that uses GNU's autoconf tools. Because this is so common, most of what I de indent will work with few changes for many other open source projects.

I'll assume for now you're using Red Hat 7.1. Later in this article, I'll give some suggestions for using RPM o distributions.

On Red Hat 7.1, be sure you have installed the rpm-build package before you continue. To check, run rp build. You should see something like rpm-build-4.0.2-8 (the version might be different). If instead, you s rpm-build is not installed, you'll need to install it from your Red Hat install CDs. Making a basic RPM package To build an RPM package, you need to write an input file for RPM, called a spec file, which tells RPM how package your software. To write a spec file: 1. 2. 3. 4.

Create the file indent-1.spec as shown below. You can name it anything and put it anywhere; RPM do Log in as root Copy the indent-2.2.6.tar.gz file to /usr/src/redhat/SOURCES. Run rpm -ba indent-1.spec, changing indent-1.spec to the name you used.

First spec file: indent-1.spec

Summary: GNU indent Name: indent Version: 2.2.6 Release: 1 Source0: %{name}-%{version}.tar.gz License: GPL Group: Development/Tools %description The GNU indent program reformats C code to any of a variety of formatting standards, or you can define your own. %prep %setup -q %build ./configure make %install make install %files %defattr(-,root,root) /usr/local/bin/indent %doc /usr/local/info/indent.info %doc %attr(0444,root,root) /usr/local/man/man1/indent.1 %doc COPYING AUTHORS README NEWS

You should see RPM unpack the tar file, compile it, and install it. On Red Hat 7.1, the working directory wil

/usr/src/redhat/BUILD.

At the end, RPM will create two RPM files. A source RPM file will be created in /usr/src/redhat/SRPMS/ind 1.src.rpm, and a binary RPM file in /usr/src/redhat/RPMS/i386/indent-2.2.6-1.i386.rpm.

The source RPM file is a simple bundling of your spec file and all the source and patch files that were using package. If you choose to distribute this, other people can use it to easily rebuild your software. The binary R contains only the compiled software and information on how to install it. What RPM does Here's a summary of what RPM does when you run rpm -ba filename.spec:

Read and parse the filename.spec file Run the %prep section to unpack the source code into a temporary directory and apply any patches Run the %build section to compile the code Run the %install section to install the code into directories on the build machine Read the list of files from the %files section, gather them up, and create binary and source RPM file Run the %clean section to remove the temporary build directory

What's in the spec file

The spec file has several sections. The first is unlabeled; the other sections start with lines like %prep and %bu

Headers The first (unlabeled) section defines a variety of information in a format something like the headers of an e-m
Summary Name

is a one-line description of the package.

is the base name of the package, and Version is the version number of the software. Release is the ver the RPM itself -- if you fix a bug in your spec file and release a new RPM of the same version of the softwar increase the release number.
License Group

should give some indication of the licensing terms (such as "GPL", "Commercial", "Shareware").

identifies the type of software; programs that try to help people manage their RPMs will usually list th group. You can see a list of the groups used by Red Hat in the file /usr/share/doc/rpm-4.0.2/GROUPS (assum installed RPM version is 4.0.2). You are not restricted to those group names, though.
Source0, Source1,

etc. name the source files (usually tar.gz files). %{name} and %{version} are RPM macr to the rpm name and version defined in the headers, so in this case, Source0 gets set to indent-2.2.6.tar.

Don't include any paths in your Source statements. RPM will look for the source files in /usr/src/redhat/SOU default. Copy or link your source files there. (To make spec files as portable as possible, you should avoid em assumptions about your own development machine's paths. Other developers can tell RPM to look in other d

source files without having to modify your spec file.) Description The next section starts with the %description line. You should provide a longer description of the software anyone using rpm -qi to query your package will see. You can explain what the package does, describe any additional configuration instructions, etc. Shell scripts The next few sections are shell scripts embedded in the spec file.
%prep

is responsible for unpacking the package. In the most common case, you can just use the %setup macr the right thing, unpacking the source tar files under the build directory. Adding the -q option just reduces the
%build

should compile the package. The shell script is run from the software package's subdirectory, in the i directory in our case, so often this is a simple as running make.
%install

should install the package on the build system. This might be as simple as make install, but usu complicated. I'll explain below. File list
%files

lists the files that should be bundled into the RPM, and optionally sets permissions and other informa

Within %files, you can use %defattr once to define the default permissions, owner, and group; in this exam %defattr(-,root,root) will install all the files owned by root, using whatever permissions they were foun RPM bundled them up from the build system. You can override the owner and permission on individual files with %attr(permissions,user,group). You can include multiple files per line in %files.

You can tag files by adding %doc or %config to the line. %doc tells RPM that this is a documentation file, so installs the package using --excludedocs, this file will not be installed. You can also list file names under % paths, and RPM will look for the files in the build directory and include them in the RPM file, to be installed /usr/share/doc/%{name}-%{version}. It is a good idea to include files like README and ChangeLog as tells RPM that this is a configuration file. During upgrades, RPM will attempt to avoid overwriting carefully modified configuration with an RPM-packaged default configuration file.
%config

Warning: If you list a directory name under %files, RPM will include every file under that directory. This is what you want, especially for directories like /bin. Back to top

Avoiding problems with the simple case

There are several problems with the most basic spec file. One of the biggest is that you end up doing a real in product on your build system. This might be a test version of the software that you don't want in production o system.

RPM can handle this with a feature called the build root. The idea is to set up your spec file to copy all the in dummy directory tree, starting at the build root; then RPM gets the files from there.

This requires some support from the software package, though. In the case of many GNU software packages, indent, defining DESTDIR when you make install will add the value of DESTDIR on the front of all the ins

Note that you don't want to use ./configure --prefix=$RPM_BUILD_ROOT. That would build the entire pa assumption that the final location of its files was the build root. It might not matter for indent, but any progra locate its installed files at runtime would fail, because when your RPM is finally installed on a user's system, under the build root anymore -- that's just a temporary directory on your build system. See the updated file indent-2.spec as shown below.

Second spec file: indent-2.spec

Summary: GNU indent Name: indent Version: 2.2.6 Release: 2 Source0: %{name}-%{version}.tar.gz License: GPL Group: Development/Tools BuildRoot: %{_builddir}/%{name}-root %description The GNU indent program reformats C code to any of a variety of formatting standards, or you can define your own. %prep %setup -q %build ./configure make %install rm -rf $RPM_BUILD_ROOT make DESTDIR=$RPM_BUILD_ROOT install %clean rm -rf $RPM_BUILD_ROOT %files %defattr(-,root,root) /usr/local/bin/indent %doc /usr/local/info/indent.info

%doc %attr(0444,root,root) /usr/local/man/man1/indent.1 %doc COPYING AUTHORS README NEWS

Explanation of changes First, we increased our Release number. Don't forget to do this anytime you edit your spec file.

We've added BuildRoot to the header, to tell RPM that this is where the files will be temporarily installed du We've used a couple of RPM macros here instead of assuming a particular location for temporary files. On R {_builddir} ends up as something like /usr/src/redhat/BUILD. We also need to tell indent to install there. RPM helps us by defining a shell variable RPM_BUILD_ROOT with build root, so we just pass this in as the value of DESTDIR when we make install.

We've also added lines to %install and %clean to clean up the build root before we start installing (just in cas we're done. %clean is a script that gets run at the end of the RPM building, if everything works, so that your don't hang around forever. Finally, in %files, notice that we do not include the BuildRoot on the fronts of the paths here. Use the "real" look for the files under the build root because you included the BuildRoot definition. What happens this time

If you watch closely, everything should work the same until RPM gets to the install part. Then the files will n directly in /usr/local/bin, for example, but instead in /usr/src/redhat/BUILD/indent-root/usr/local/bin.

If you examine the final binary RPM file (with rpm -qlp indent-2.2.6-2.i386.rpm), you'll see that the b been removed by RPM. If you install the RPM, the files will end up in their proper directories, such as /usr/lo Back to top

Using RPM on other Linux distributions

If you are using a different Linux distribution, RPM might have some different built-in paths. For example, i certainly will not look in /usr/src/redhat for source files! To determine what paths your installation of RPM e --showrc and look to see how the following are defined: _sourcedir Where RPM looks for source files (tar files, etc.) _srcrpmdir Where RPM puts new source RPM files

_rpmdir Where RPM will put new binary RPM files (in an architecture-specific subdirectory)

Some of these are defined in terms of other variables; if you see, for example, %{_topdir}, then look for the _topdir and so forth. Back to top

What's next

I hope this introduction to packaging your software with RPM proves helpful to you. For related reading, see below. In future articles in this series, we'll cover these topics:

Building RPMs without having to be the root user Patching the software before building it Running scripts during install and uninstall Running scripts when other packages are installed or uninstalled

Back to top

Resources

Source for files described in this article: o indent-1.spec o indent-2.spec

The RPM Web site has pointers to many useful resources. The RPM e-mail list is a good place to ask

See which Linux distributions are RPM based in the "Comparison of Linux Distributions" at distrowa RPM-based distributions include Red Hat, SuSE, Mandrake, TurboLinux, and Caldera. Get the GNU Indent program.

Maximum RPM is a book about using RPM. It has become quite outdated, but an effort is now under

it.

The RPM HOWTO is also getting somewhat dated. It covers some of the same ground as this article.

Eric S. Raymond's Software Release Practice HOWTO document is not specific to RPM or Linux. It good tips on releasing software in a way that makes it easy for users to use and programmers to contr improvements.

The Free Software Foundation is the source for GNU Indent and many other useful software package

Get the IBM Developer Kit for Linux, Java 2 edition, version 1.3 or the IBM Software Evaluation Ki Browse more Linux resources on developerWorks.

Browse more Open source resources on developerWorks.