Bypassing Automatic Configurations to Gain Control

As OSs have grown more complex, configurationtools have become more commonplace. The average person who uses acomputer to browse the Web, balance a checkbook, and send e-mail toAunt Mathilda doesn't want to learn about dozens of configurationfiles, their syntax, their options, and so on. Much of the earlysuccess of Apple's Macintosh derived from the fact that it providedsimple configuration tools—GUI control panels. By contrast, theMacintosh's main competitor at the time, DOS, used comparativelyhard-to-configure text files such as CONFIG.SYS and AUTOEXEC.BAT.In its early years, Linux was configured exclusively by manuallyediting its configuration files. Today, though, a variety of text-modeand GUI configuration tools exist. These tools enable you to configurea Linux system by answering a few relatively simple questions, clickingoption buttons, and so on.

Unfortunately, these automatic configuration toolsaren't perfect. They sometimes get things wrong or don't let youconfigure the features you need to set. They also vary substantiallyfrom one distribution to another,. As a result,bypassing these automatic configuration tools is often desirable oreven necessary. Once you do so, you can dig into the system'stext-based configuration files to make the changes that are hard or impossible to make with the supposedly user-friendly default tools.


The Perils of Automatic Configurations





Standard Linux installations place a set of default configuration files on the system. Most of these files reside in the /etcdirectory tree and, except in cases of severely broken installationscripts, unsupported critical hardware, or similar serious problems,the default configuration files work well enough to boot the computer.Sometimes, though, these configurations fail seriously enough to causeproblems, albeit not badly enough to prevent the system from booting.Likewise, the configuration tools provided with the distribution oftenwork well enough to get a subsystem functioning partially, but notcompletely. Sometimes these tools fail altogether. Understanding thesefailures can help you to work around them, so this summarizes four failure types:


*

Incorrect identification of hardware or of another system component






*

Incorrect configuration






*

Inflexible configuration options






*

Overzealous configuration tools






Incorrect Identification

Sometimes a configuration tool simply fails torecognize that your system has a particular hardware or softwarecomponent. If you've installed a depended-upon package without thebenefit of the package tool, this type of problem is common wheninstalling software via package managers, ." This problem is also somewhat common when dealingwith hardware configuration, particularly with older Industry StandardArchitecture (ISA) cards, very new cards, or otherwise exotic hardware.Sometimes the system recognizes that you've got a given type ofhardware, but it misidentifies the specific type. This problem can beparticularly irksome when combined with inflexibility in options, asdescribed in the upcoming section,






Some configuration tools suffer from another problem:Incomplete identification. In this case, the problem isn't that theconfiguration tool has narrowed the field of options incorrectly, it'sthat the field isn't narrowed at all. the web-based configuration tool for the Common Unix Printing System (CUPS), "Managing Printers." ,you're supposed to pick a printer port from the available options—all25 of them. (Some systems present even more options.) This particularcomputer has just two printers attached to it, and it even lacks thedevice files associated with some of the options Of course, this particular problem isn't alleviated by bypassing anautomatic configuration tool. If anything, it's made worse—you mustknow more about your available devices than you would need to know whenusing a configuration tool. Nonetheless, as the configuration tool issupposed to make things easier for new administrators, presentingconfusing or nonexistent options can be a problem.



: Some configuration tools present too many options to administrators.

As a general rule, bypassing an automaticconfiguration tool can help avoid problems with failure ofidentification by enabling you to force the issue. If the systeminsists on configuring your MegaSound audio card as a GigaSound card,you can dig into the configuration files and correct the matter. Ofcourse, doing so requires that you know where to go digging—a topicthat's covered in subsequent sections of this chapter. You must alsoknow how to correct the problem.


Incorrect Configuration

Although misidentification can be a seriousproblem, one that's just as common is incorrect configuration. Manyconfiguration files have sensitive formats—for some, a misplaced spaceor comma can spell the difference between a working configuration andone that doesn't work. As a general rule, computer programs are good atgetting such details right, but this isn't always the case.Furthermore, some configurations rely on very specific information forparticular hardware or software. For instance, you may need to passparticular options to a kernel module to get it to work, but otherkernel modules may require different options. Therefore, automaticconfiguration tools often use databases of configuration options, andif these databases are flawed, the tool may fail.






As an example, consider Samba, which handles the ServerMessage Block/Common Internet File System (SMB/CIFS) file- andprinter-sharing protocol that's common on Windows-dominated networks.Several GUI Samba configuration tools exist, the most flexible of whichis the web-based Samba Web Administration Tool (SWAT). SWAT handlesmost configurations correctly, but it corrupts a specific type ofconfiguration. Samba supports splitting configuration files into parts.The main file then uses an include directive to tell Samba to load referenced files. Unfortunately, SWAT doesn't know what to do with the includedirective. Early versions of SWAT ignored that directive. Using suchversions of SWAT, if you create a Samba configuration that relies on include and then try to modify that configuration using SWAT, you'll lose all the includereferences, which may cause subtle or not-so-subtle problems. Laterversions of SWAT merge the included file into the main file but leavethe include directive intact, which islikely to result in a working configuration; however, if you fail tonotice the change, you might make subsequent changes by hand that won'tbe implemented.






Some incorrect configurations are fairly small. These can be easy to fix—ifyou know where to look and how to fix the problem. Other tools tend tomake a real mess of things, and such problems can be tedious to correct.

Inflexible Options

Some configuration tools are just overlysimplistic—they don't support changing enough of the features of aproduct to make using the tool worthwhile. A similar problem is a toolthat doesn't allow you to override its defaults. For instance, Red Hat's sound card detection tool. After launching this tool,the system returns information about any sound card that it has found.You can click the Play Test Sound button to hear if the system hasdetected the sound card correctly. If you don't hear a sound, the toolprovides nothing in the way of options to try to correct the matter.You can't select another sound card from a list, modify driver moduleoptions, or take any other corrective measures. Your only choices atthis point are to abandon any attempt to get the sound card working orto dig into configuration files and modify them manually.


Some configuration tools provide inadequate configuration options.

Even when a device works correctly in a simplecase, it may present inadequate options for more complexconfigurations. For instance, many distributions include configurationtools that greatly simplify setting up Ethernet interfaces. Some ofthese tools, though, don't handle a second interface very well. Theymay lack any options for configuring a second interface, or they mayprovide some options but lack the finesse required to configure thesecond interface in the way that might be required for yourapplication, such as setting up the computer as a router.

Overzealous Configuration Tools

Another class of problems relates to configurationtools that are overzealous in one way or another. Typically, thesetools overwrite existing configuration files without just cause, andsometimes without asking you whether it's acceptable to do so. Onecommon source of such problems is upgrading software packages, andespecially servers and other system software. For instance, you mayhave spent hours creating the ideal Apache web server configuration.When you use rpm, apt-get,or some other tool to upgrade to the latest version, you discover thatyou've lost your changes because the replacement package included a newdefault configuration file that overwrote the original. Fortunately,both RPM and the Debian package system can mark configuration files assuch. When the system installs a package, it backs up your existingconfiguration files by renaming them with a new extension, such as .rpmsave.Nonetheless, the need to go in and swap in your own workingconfiguration file can be annoying. If a package is built incorrectly,it may lack the configuration file flag, causing your originals to belost.






Some tools change the original configurationfiles, or other aspects of a system's configuration, when you runthem—even if you don't ask for these changes to occur. For instance,Mandrake includes a package called Mandrake Security (msec),which periodically checks assorted directories for preconfigured levelsof security. If the tool finds a problem, such as too-permissivepermissions on a directory, the tool corrects the problem. Thispractice is a good one overall, but if you, as an informed andintelligent system administrator, don't want this tool changing yourdirectory permissions without warning or even notification, you mustdig into the tool's configuration and change it. Other tools might runeven when you don't ask them to do so, or they might make changesbeyond those you'd expect. For instance, it's becoming increasinglycommon for programs to try to add themselves to KDE, GNOME, and otherenvironments' menus after they're installed. This practice might befine if the tools do their jobs correctly, but sometimes they mightdelete entries for programs you've added manually, or they might createmultiple entries for themselves if they run multiple times. Suchproblems can be difficult to track down, because it might not beobvious which program made the unauthorized changes. In the end, thebest defense is to make backups of all your configuration files—bothsystem files in /etc and user configuration files, which are generally dot-files in users' home directories.

Automatic Setup Mechanisms by Distribution


Inorder to bypass default configurations or those created byconfiguration tools, you must know where to look for theseconfiguration files. All major Linux distributions place systemconfiguration files in /etc, and there arecertain commonalities beyond this detail. Each distribution'sconfiguration has unique features, though, and you must understandthese features to effectively configure your system.


Common Configuration Files

The traditional location for system configuration files in Unix-like systems is /etc,and Linux is no exception to this rule. Indeed, many obscure packages,including some that don't even ship with most distributions, install their configuration files in /etc. As a result, this directory's contents vary from one system to another, and I cannot describe every file or subdirectory it contains. The following list summarizes some of the most important files and subdirectories found in /etc on most distributions, though. Subdirectories are indicated by a trailing slash (/) in the name.



?.d/






Subdirectories holding SysV startup scripts for specific runlevels (
? is the runlevel number). May be subdirectories of rc.d or init.d.






rc.d/






Subdirectory holding SysV startup scripts, possibly in their own subdirectories. Sometimes this is a symbolic link to /etc/init.d.






samba/ or samba.d/






Subdirectory holding configuration files for the Samba file and print server package.






services






File holding mappings of names to port numbers for common servers.






shadow






Shadow password file; holds encrypted user passwords and advanced account information in a file that's readable only to root.






ssh/






Holds configuration files for the Secure Shell (SSH) login server.






sysconfig/






Contains miscellaneous system configurationfiles, such as files holding network configuration options. SysVstartup scripts typically reference these files.






X11/






Holds configuration files for the X Window System (X) and some related subsystems, such as X-based login tools.






XF86Config or XF86Config-4






Main XFree86 configuration file. This file often appears in /etc/X11.






xinetd.conf and xinetd.d/






Configuration file and subdirectory for the xinetd super server.






The list is long, but even so, it doesn't present all of the configuration files and subdirectories in a typical Linux system. On the flip side, some of these files and directories aren't present on some Linux systems; for instance, if you haven't installed SSH, your system most likely won't have an /etc/ssh directory.






The /etc/inittab file is particularly critical for the system startup procedure. It defines certain processes that run constantly, such as getty or a similar program, which attaches itself to a text-mode console and runs the login program to accept text-mode logins. Just as important, inittab kicks off the rest of the startup process, through a line beginning with si. In a Red Hat system, this line is as follows:


si::sysinit:/etc/rc.d/rc.sysinit





Effectively, this line passes control of the startup process to /etc/rc.d/rc.sysinit—butthe name of this script varies from one distribution to another, asdetailed in the next few sections. Another detail set in /etc/inittab is the default runlevel—anumber that serves as a code for a particular set of default serversand other programs to run. The runlevel is set in a line that beginswith id, as in:



id:5:initdefault:





This line sets the runlevel to 5. Runlevels 0, 1, and 6 have special meanings and should never be specified in /etc/inittab.Most Linux distributions use runlevel 3 to mean a text-mode startup andrunlevel 5 to mean a GUI startup. Slackware uses 4 instead of 5 for GUIstartups, though, and Debian uses other means to determine when toperform a GUI startup.






Most Linux distributions use a startup script system borrowed from System V Unix, and hence referred to as SysV startup scripts. These scripts are stored in /etc/init.d, /etc/rc.d, or a subdirectory of one of these directories. Typically, subdirectories called rc?.d, where ?is the runlevel, hold symbolic links to the startup scripts forspecific runlevels. Within each runlevel's directory, scripts whosenames start with S are used to start a service, and those whose names start with K shut down (kill) a service when the system enters that runlevel. The upcoming section, "describes the SysV startup script naming convention in greater detail.Some distributions use major or minor variants on this system, asdetailed in the next five sections. Slackware is the most unusual ofthese variants.



Debian

Debian tends to shun specialized systemadministration tools. The Debian installer, of course, places a set ofdefault configuration files in /etc, andsome packages come with scripts that ask questions to help tune aconfiguration for your system. You can also use configuration toolsthat ship with or are written for specific packages, such as SWAT; ormore general tools, such as Linuxconf (http://www.solucorp.qc.ca/linuxconf/) or Webmin (http://www.webmin.com).In general, though, when you administer Debian you do so by directlyediting the relevant configuration files; there is, therefore, no needto bypass any automatic configuration tool that might try to modifyyour changes itself.







Of course, Debian has its own unique configurationquirks. Some of Debian's notable features that differ from some or allother Linux distributions include:



System Startup Procedure Debian's /etc/inittab calls /etc/init.d/rcS as the system initialization script. This script calls the startup scripts in /etc/rcS.d and any scripts in /etc/rc.boot (the latter is intended for local startup scripts, but its use is officially discouraged). Debian's init then switches to the runlevel specified in /etc/inittab and runs /etc/init.d/rc, which runs the startup scripts in the appropriate SysV startup script directory.







Location of SysV Startup Scripts Debian places its SysV startup scripts in /etc/init.d and places links to these files for specific runlevels in /etc/rc







?.d, where ? is the runlevel number.







Runlevels and Starting X There are few differencesbetween runlevels 3–5 in Debian, except that runlevels above 3 providejust one text-mode virtual terminal. Instead of using a runlevel as acode for whether or not to start X and present an X Display ManagerControl Protocol (XDMCP) GUI login screen, Debian uses SysV startupscripts for each of the major display managers. You can set which tostart by default in the /etc/X11/default-display-manager file.







cron Debian's default cron configuration includes an /etc/crontab file that calls files in the /etc/cron.interval directories, where interval is daily, weekly, or monthly, at the stated intervals, and between 6:25 a.m. and 6:52 a.m.







Super Server Debian uses inetd by default, although xinetd is also available.







Mail Server Debian is the only major Linux distribution to use Exim as its default mail server. It's configured through /etc/exim/exim.conf.When you install Exim, the Debian package tools run a script that askssome basic questions to set up an initial Exim configuration.







Modules One of Debian's few deviations from the automatic configuration rule is that it uses a tool called update-modules to create an /etc/modules.conf file. This tool assembles files it finds in the /etc/modutils directory tree into /etc/modules.conf. The easiest way to deal with this system is to change the files in /etc/modutils or add new files to it, rather than directly editing /etc/modules.conf. Consult the update-modules man page for more details.







Network Configuration Debian uses the /etc/init.d/networking SysV startup script to start basic networking features. This script relies on variables stored in files in the /etc/network directory tree. Therefore, permanently changing some networking details requires editing these files.







Local Startup Files If you want to changesomething about the system configuration that doesn't fit well in thedefault script set, you can create a script and place it in the /etc/rc.boot directory. Debian executes scripts in this directory after running the /etc/rcS.dscripts but before running the scripts for the startup runlevel.Debian's official documentation suggests creating SysV startup scriptsand placing them in /etc/rcS.d or another SysV startup script directory, though.







As a general rule, Debian's configuration filesare straightforward to adjust if you're used to text-basedconfiguration. The SysV startup scripts work as they do on most Linuxdistributions. Local startup files are a bit odd if you're used to RedHat, Mandrake, or SuSE; however, once you put a local startup script in/etc/rc.boot, you can modify it as you like.


Mandrake

Mandrake ships with a tool called the MandrakeControl Center, which can be launched from the standard menus in KDE orGNOME or by typing drakconf in a shell. If you launch it as an ordinary user, it prompts for the rootpassword to continue. This program is a typical GUI configuration tool.It provides categories of configuration options in a list along theleft side of its window. When you click one of these categories, thetool displays a set of specific configuration tools in the right sideof the window, Click one of these tools, and it will open in the right side of thewindow or in a separate window, providing subsystem-specific options.




The Mandrake Control Center displays one or more configuration tools for each configuration category.

Mandrake also ships with a variety of more specialized configuration tools, such as the rpmdraketool for managing packages. The Mandrake Control Center can launch manyof these tools itself. Many of these tools can modify files in /etc, but you can modify these files manually if you prefer. Some Mandrake-specific details include:











System Startup Procedure Mandrake's /etc/inittab calls /etc/rc.d/rc.sysinitas the system initialization script. This script performs a largenumber of basic initialization tasks, such as mounting the devicefilesystem, setting the system clock, and so on. Mandrake's init then switches to the runlevel specified in /etc/inittab and runs the startup scripts in the appropriate SysV startup script directory by calling /etc/rc.d/rc.







Location of SysV Startup Scripts Mandrake places its SysV startup scripts in /etc/rc.d/init.d and places links to these files for specific runlevels in /etc/rc.d/rc?.d, where ? is the runlevel number.







Runlevels and Starting X Mandrake uses the dm SysV startup script to start X and an XDMCP GUI login screen. This script is called using the name S30dm in runlevel 5 (causing the display manager to start) and using the name K09dm in runlevel 3 (causing the display manager to shut down). The dm script in turn calls /etc/X11/prefdm, which reads /etc/sysconfig/desktop and uses the variable DISPLAYMANAGER to determine which XDMCP server to run.







cron Mandrake's default cron configuration includes an /etc/crontab file that calls files in the /etc/cron.interval directories, where interval is hourly, daily, weekly, or monthly, at the stated intervals. Except for the hourly run, these scripts run between 4:02 a.m. and 4:42 a.m.







Super Server Mandrake uses xinetd by default. The /etc/xinetd.conf file is the master configuration file, while /etc/xinetd.d holds files for specific servers that xinetd is to handle.







Mail Server Mandrake ships with Postfix as the default mail server. It's administered through files in /etc/postfix.







Network Configuration Mandrake uses the /etc/rc.d/init.d/network SysV startup script to start basic networking features. This script relies on variables stored in the /etc/sysconfig/network and (for PC Card devices) /etc/sysconfig/pcmcia files and files in the /etc/sysconfig/networking and /etc/sysconfig/network-scripts directories. Therefore, you must edit these files to permanently change some networking details.







Local Startup Files If you want to changesomething about the system configuration that doesn't fit in well inthe default script set, you can edit the /etc/rc.d/rc.local script. This script executes after the conventional SysV startup scripts.







Using the Mandrake Control Center can help newadministrators and those unfamiliar with Mandrake's version of Linux toconfigure some basic system features. If you launch this toolaccidentally, be sure to tell it to ignore any changes (by clickingCancel or other abort buttons), should it ask you about committing yourchanges to the system.

Red Hat

Red Hat uses a number of small configurationtools, most of which are accessible from the Server Settings, SystemSettings, and System Tools menu off of the GNOME Applications menu, These tools are also accessible from the Start Here icon on the defaultRed Hat desktop. Each of these tools provides a way to configure aspecific feature, such as the network or sound card. If you log in as anordinary user but need to administer the system, you can do so, but thetool will ask for the root password whenyou select it. The system remembers the password for a while, socalling other configuration tools soon after the first won't result ina new root password prompt.



Red Hat makes its administrative tools accessible from menus on its default desktop configuration.

Red Hat's startup procedure and configuration filelocations are quite similar to those of Mandrake. This fact shouldn'tbe surprising because Mandrake used Red Hat as its starting point and,as a result, the two distributions share a common heritage. With everynew release, though, Red Hat and Mandrake deviate more. Some of theimportant configuration files in Red Hat include:


System Startup Procedure Red Hat's /etc/inittab calls /etc/rc.d/rc.sysinitas the system initialization script. This script performs a largenumber of basic initialization tasks, such as mounting the devicefilesystem, setting the system clock, and so on. Red Hat's init then switches to the runlevel specified in /etc/inittab and runs the startup scripts in the appropriate SysV startup script directory by calling /etc/rc.d/rc.







Location of SysV Startup Scripts Red Hat places its SysV startup scripts in /etc/rc.d/init.d and places links to these files for specific runlevels in /etc/rc.d/rc?.d, where ? is the runlevel number.







Runlevels and Starting X Red Hat uses a line in /etc/inittab to start an XDMCP server, and hence X, in runlevel 5. This line calls /etc/X11/prefdm, which reads /etc/sysconfig/desktop and uses the variable DISPLAYMANAGER to determine which XDMCP server to run.







cron Red Hat's default cron configuration includes an /etc/crontab file that calls files in the /etc/cron.interval directories, where interval is hourly, daily, weekly, or monthly. Except for the hourly run, these scripts run between 4:02 a.m. and 4:42 a.m.







Super Server Red Hat uses xinetd by default. The /etc/xinetd.conf file is the master configuration file, while /etc/xinetd.d holds files for specific servers xinetd is to handle.







Mail Server Red Hat ships with sendmail as the default mail server. It's administered through files in /etc/mail.







Network Configuration Red Hat uses the /etc/rc.d/init.d/network SysV startup script to start basic networking features. This script relies on variables stored in the /etc/sysconfig/network file and files in the /etc/sysconfig/networking and /etc/sysconfig/network-scripts directories. Therefore, you must edit these files to permanently change some networking details.







Local Startup Files If you want to changesomething about the system configuration that doesn't fit in well inthe default script set, you can edit the /etc/rc.d/rc.local script. This script executes after the conventional SysV startup scripts.













For the most part, bypassing Red Hat's default orGUI-created configurations poses no special challenges; just edit therelevant configuration files by hand. If you accidentally launch a GUIconfiguration tool, select Cancel or another appropriate option to quitwithout saving the changes.


Slackware

Like Debian, Slackware doesn't rely on GUIconfiguration tools, although you can install tools such as Linuxconfor Webmin after the fact, just as with Debian. Some of Slackware'sstartup and configuration files are unusual compared to those of otherLinux distributions, which can make moving from Slackware to anotherdistribution or vice-versa a bit disorienting. Important Slackwareconfiguration files include:


System Startup Procedure Slackware's /etc/inittab calls /etc/rc.d/rc.S as the system initialization script, followed by /etc/rc.d/rc.M to initialize multiuser features. (When booting to single-user mode, Debian runs /etc/rc.d/rc.K.) Debian's init then switches to the runlevel specified in /etc/inittab, but unlike other distributions, Slackware's runlevels are controlled through single startup scripts called /etc/rc.d/rc.?, where ? is the runlevel number. In practice, the only runlevel of consequence is 4, as described next. (The rc.6 script reboots the system. A link to it, called rc.0, shuts down the system.)







Runlevels and Starting X The standard Slackwarestartup scripts boot the system into text mode. If you want to start Xand use an XDMCP login screen, change the runlevel to 4 in /etc/inittab. This action causes init to run /etc/rc.d/rc.4 on its next boot, which starts an XDMCP server. The script tries gdm first, followed by kdm and then xdm.







cron Unlike most distributions, Slackware doesn't place a crontab file in /etc; instead, it relies on the root file in /var/spool/cron/crontabs. This file runs scripts in the /etc/cron.interval directories, where interval is hourly, daily, weekly, or monthly. Except for the hourly scripts, these run between 4:20 a.m. and 4:40 a.m.







Super Server Slackware uses inetd by default, and it does not ship xinetd as an option. If you want to use xinetd, you must obtain it from another source, such as the xinetd home page (http://www.xinetd.org).







Mail Server Slackware uses sendmail as its default mail server. The configuration files are in /etc/mail.







Network Configuration Slackware uses the rc.inet1 and rc.inet2 files, both in /etc/rc.d, to initialize networking functions. The rc.inet1file initializes network interfaces and includes information such asyour IP address (if you use a static IP address), so you must edit thisfile to permanently change your network settings. The rc.inet2 file starts common network servers.







Local Startup Files If you want to changesomething about the system configuration that doesn't fit well in thedefault script set, you can add commands to the /etc/rc.d/rc.local script, which is designed for system-specific configuration changes. This script is run from the end of the /etc/rc.d/rc.M script.













As a general rule, adding servers or other automatically run programs to Slackware entails adding entries to /etc/inetd.conf or /etc/rc.d/rc.local,rather than adding SysV startup scripts, as is common with other Linuxdistributions. In principle, you could edit other startup scripts, butit's usually cleaner to keep most startup scripts as they are and makechanges to rc.local. One important exception to this rule is /etc/rc.d/rc.inet1, which holds local network configuration information.

SuSE

SuSE provides a pair of system configurationtools, YaST and YaST2. The former is text-mode, and the latter is GUI;however, they're quite similar in capabilities. I refer to themcollectively as YaST for simplicity's sake.Navigating YaST is much like navigating Mandrake's Control Center; youselect configuration tools from a hierarchical list. In YaST2 tool categories appear in the pane on the left of the window, and individual tools are on the right.




* YaST and YaST2 tools provide convenient access to many configuration options.

A few of SuSE's features are a bit odd compared to mostother Linux distributions, but they are not nearly as unusual asSlackware's files. You must be familiar with these oddities in order tomodify configurations manually. Important scripts and configurationfiles include:



System Startup Procedure SuSE's /etc/inittab calls /etc/init.d/boot as the system initialization script. This script calls the startup scripts in /etc/init.d/boot.d and the /etc/init.d/boot.local file (the latter is intended for local startup scripts—those created by the system administrator). SuSE's init then switches to the runlevel specified in /etc/inittab and runs the startup scripts in the appropriate SysV startup script directory.







Location of SysV Startup Scripts SuSE places its SysV startup scripts in /etc/init.d and places links to these files for specific runlevels in /etc/init.d/rc







?.d, where ? is the runlevel number.







Runlevels and Starting X Runlevel 3 produces atext-mode login prompt. Runlevel 5 starts an XDMCP server, andtherefore X, at boot time. SuSE does this by providing a start link to /etc/init.d/xdm in the /etc/init.d/rc5.d directory. The xdm startup script in turn uses /etc/sysconfig/displaymanager to set several variables, including DISPLAYMANAGER, which tells the system which XDMCP server to run.







cron SuSE's default cron configuration includes an /etc/crontab file that calls files in the /etc/cron.interval directories, where interval is hourly, daily, weekly, or monthly. Except for the hourly runs, these scripts run between 12:14 a.m. and 12:44 a.m.







Super Server SuSE uses inetd by default, although xinetd is also available.







Mail Server SuSE uses Postfix as the default mail server. Its configuration files reside in /etc/postfix.







Network Configuration SuSE uses the /etc/init.d/network SysV startup script to start basic networking features. This script relies on variables stored in files in the /etc/sysconfig/network directory tree. Therefore, permanently changing some networking details requires editing these files.







Local Startup Files If you want to changesomething about the system configuration that doesn't fit in well inthe default script set, you can edit the /etc/init.d/boot.local script. SuSE executes this script after running the scripts in /etc/init.d/boot.d but before running the scripts for the startup runlevel.







As with other Linux distributions that use GUIconfiguration tools, you can modify configuration files to alter thesystem as you see fit; however, the automatic tools may choke or ignoreyour changes if those changes don't conform to the standards the toolsexpect.


Implementing Manual Configurations





Whenediting configuration files, you must of course conform to thestandards of whatever files you modify. For instance, Linux startupscripts are usually written for bash. Therefore, they must use the syntax of a bash script, " In the case of distributionsthat use GUI configuration tools, it's also often important to createfiles or scripts that match those tools' expectations, lest subsequentuses of those tools create bizarre problems. You can change aconfiguration using the standard files or use local startup scripts toadd to a configuration. It's also sometimes possible to achieve thedesired results by creating or modifying individual users'configuration files.


Scripts versus Configuration Files

Quite a few Linux configuration files are actually scripts, generally written using the bash shell scripting language. Examples include whatever script init calls with the si line in /etc/inittab and SysV startup scripts. (The /etc/inittab file itself is not a bash script, though.) Scripts are typically used to launch programs, such as daemons and system configuration tools—ifconfig, insmod,and so on. Essentially, scripts leverage the power of ordinarytext-mode Linux system administration tools, using them automaticallyduring the system boot process or at other times, such as when youmanually change the runlevel. . For more detailedinformation, consult a book on bash shell scripting, such as Newham and Rosenblatt's Learning the bash Shell (O'Reilly, 1998).







Nonscript configuration files, on the other hand,simply store data that's used by other tools. For instance, the Postfixmail server uses /etc/postfix/main.cf asits configuration file. This file isn't a script, but its syntaxresembles variable assignment operations in scripts. This file containslines like this:


virtual_maps = hash:/etc/postfix/virtual
disable_dns_lookups = no





Each configuration file uses its own syntax. For instance, some use equal signs (=)to assign values to variables, but others don't. Some break the fileinto distinct sections, in which assignments or other operators applyonly to specific features of the program. Because the rules forconstructing and modifying configuration files vary from one program toanother, you should consult the program's documentation, eitherprovided with the program or in a book, third-party web page, or thelike, before modifying these programs' configuration files.






Sometimes the line between boot scripts and configuration files is blurry. For instance, most Linux distributions use files in /etc/network, /etc/sysconfig/networking, or a similar location to store variables relevant to network configuration. These files frequently lack the first-line #!/bin/bashidentification as scripts, but they're loaded by SysV or other startupscripts in order to assign values to variables that are used in thescripts' network-initialization calls. This practice enables you or thedistributions' configuration tools to modify the configuration fileswithout adjusting the sensitive SysV startup scripts.


Using Local Startup Scripts

One way to modify a system's configuration is touse local startup scripts. The preceding sections described thesescripts and their locations. In summary, these scripts are as follows:


Debian All scripts in /etc/rc.bootare local startup scripts. These scripts run after basic systeminitialization but before SysV startup scripts run. Debian'smaintainers discourage use of this directory, and instead recommendcreating genuine SysV startup scripts, possibly stored in /etc/rcS.d.







Mandrake, Red Hat, and Slackware The local startup script is /etc/rc.d/rc.local.This script runs after all the SysV startup scripts for Mandrake andRed Hat but before any runlevel-specific scripts in the case ofSlackware.







SuSE The local startup script is /etc/init.d/boot.local. This script runs after basic system initialization but before SysV startup scripts run.













One critical difference between distributions is thattheir local startup scripts run at different times—before or afterrunning the runlevel-specific SysV startup scripts. This fact can haveimportant consequences. For instance, if a SysV startup script starts aserver that must have basic networking features active, you can use alocal startup script to start networking if your distribution runs thelocal startup script before the SysV startup scripts. If the localstartup script runs after the SysV startup script, though, this may notwork or it may require you to restart the server in the local startupscript.






In a simple case, you can launch a program via a localstartup script by adding the command to the script. For instance, ifyou've added a server called bigserv toyour system by compiling source code, you might add a line like thefollowing to a local startup script in order to launch the server:


/usr/local/bin/bigserv





Of course, you can add whatever options areappropriate. If the program you call doesn't put itself into thebackground, the script will stop execution until the program exits,unless you append an ampersand (&) tothe command line. A halted startup script will halt the system bootprocess, so be sure to include this ampersand whenever necessary. Someprograms you might call will exit quickly; for instance, the playcommand will play a sound and then exit, so failure to include theampersand will delay the boot process only by however long it takes toplay the sound file you specify.


Safely Changing Existing Configuration Files

Sometimes it's desirable to alter an existingconfiguration file or startup script. Doing so is potentially risky,though. An error could result in an unbootable system or in a systemthat doesn't work as you expect. Some rules to keep in mind whenediting these files include:


Make a Backup Be sure to make a backup of the filebefore you edit it. Some editors do this automatically, but if you saveyour changes more than once, the second save may overwrite the originalbackup.







Edit the File in Linux Some other OSs, such asWindows, use different end-of-line conventions in their text editorsthan does Linux. Some configuration files are sensitive to theseconventions, so editing a file in Windows may result in a file thatdoesn't work as you expect, possibly halting the boot process.







Note Ownership and Permissions Before editing thefile, notice who owns it and what the permissions are. Be sure that theedited file has the same ownership and permissions.







Make Minimal Changes Don't change anything you don't understand, and try to change as little as possible of what you do understand.







Change Support Files, Not Core Files If a SysVstartup script or other file relies on variables loaded from anotherfile, try to edit the support file rather than the primary file. As ageneral rule, you'll be less likely to introduce serious problems ifyou edit a support file.







Test the Changes If possible, test the modifiedscript or configuration file as soon as possible. For instance, shutdown and restart a server. If you make extensive changes to startupscripts, you might even want to reboot the computer to be sure it bootscorrectly. With the changes fresh in your mind, you'll find it easierto correct problems than if you'd waited hours, days, or longer to testthem.









Creating New SysV Startup Scripts

If you add a new server or other program that shouldlaunch whenever you start the computer, the easy way to get it to runis usually to add an entry to a local startup script, as describedearlier in "Using Local Startup Scripts." SysV startup scripts existfor several reasons, though, and some of these apply even to locallycompiled programs. Most importantly, SysV startup scripts enable you toconfigure a server to run in some runlevels but not others, and tostart up and shut down using relatively simple commands—by passing thestrings start or stop to the script.






The core idea behind a SysV startup script is fairlystraightforward: It's a script to start, stop, and sometimes restart orcheck the status of a program. Most Linux distributions, though, add alot of extras to their SysV startup scripts. These extra featuresinclude a summary of the startup status for programs as they'relaunched when the system boots, storage of process IDs (PIDs) in /var/run,and so on. Unfortunately, distributions have different methods ofimplementing these extra features. If you want to use similar featuresin your own SysV startup script, you may want to create yours bystarting from an existing script. You can then replace calls to theoriginal server with calls to your own. You should peruse severalscripts to locate one that's best-suited to your modifications.






If you're willing to settle for a simpler SysV startup script, something like Listing 9.1 may fit the bill. This script starts and stops the fictitious bigserv program. Its method of stopping the server is to use killall,which kills all instances of the server. Some servers includeprovisions to store their PIDs in files. You can use this feature tostore a PID when you start a server, and to kill only that instancewhen you shut it down, if you like.


Listing 9.1: Sample SysV Startup Script

#!/bin/bash
case "$1" in
start)
/usr/local/bin/bigserv
;;
stop)
/usr/bin/killall bigserv
;;
restart)
$0 stop
$0 start
;;
esac

Once you've created a SysV startup script, you shouldstore it in the SysV startup script directory for your distribution,such as /etc/rc.d/init.d for Mandrake orRed Hat. If you want the server to start or stop automatically when youboot or change runlevels, you must then create links to the originalfile in the runlevel-specific SysV startup script directories, such as /etc/rc.d/rc?.d for Mandrake and Red Hat. These links' names should start with S if you want the server to start or Kif you want the server to stop in that runlevel. Filenames alsoconventionally include a two-digit sequence number. For instance, tostart the bigserv server, you might have a startup script link called S67bigserv and a shutdown link called K23bigserv in another runlevel directory. The runlevel management tools automatically pass a start parameter to files whose names begin with S and stop to those whose names begin with K.The sequence number determines the order in which the scripts run. Forsome packages, this isn't terribly important; but for others it is. Forinstance, most servers should start after the network or networkingscript runs, and they should be shut down before that script is run forshutting down the network in runlevels 0, 1, and 6. Each distributionuses its own set of sequence numbers, so you should study thesesequences before inserting a new script into the sequence.

Bypassing and Overriding Configuration Files

Sometimes you may want to bypass or override astartup script or configuration file. In some cases, the easiest way todo this is to delete, rename, or move the file. For instance, removinga SysV startup script or its link in a relevant runlevel prevents thatscript from running. In this way, you can disable a server when thesystem starts. One potential risk to such actions is that automaticconfiguration tools may add the file back, particularly if you merelymodified a link.






Sometimes you can edit a startup script to have it use a different configuration file than is the default. For instance, the -s option to smbd and nmbd(two programs that together compose Samba) specifies the configurationfile. It's not used in most SysV startup scripts for Samba, but youcould add it if you wanted to move the Samba configuration files tosome location other than the default for your distribution.






Sometimes it's possible to use a local startupscript to modify the actions of earlier startup scripts. For instance,if your system is obtaining a bizarre hostname from a Dynamic HostConfiguration Protocol (DHCP) server at boot time, you can overridethat setting by using the hostname command in a local configuration file—







ifthe local configuration file runs after the startup script that callsyour DHCP client. If not, you may need to locate that startup scriptand modify it so that it doesn't accept the DHCP server's hostname orso that the script includes a call to hostname itself.

Creating User-Specific Configurations

Some configurations can be customized forindividual users. Most of these settings relate to user-level programs,such as window managers, text editors, and web browsers. Theseconfigurations almost invariably reside in files or directories in theusers' home directories, typically named after the program in question,but with a dot (.) at the start of the name to hide it from view unless you use the -a option to ls. For instance, the configuration file for the NEdit editor is ~/.nedit.Most of these files contain highly application-specific options, so youmust consult the programs' documentation to learn more about them. Someof these programs also use system-wide defaults, often stored in /etc. These defaults may be copied to the user-specific files or may provide defaults that the user-specific files may override.







Two classes of user configuration files are particularly important. The first is shell configuration files, such as ~/.bashrc. They are essentially just shellscripts. Typically, you use them to set environment variables andaliases.







Another type of important configuration file is an X startup file. The most common of these files are listed here:



~/.xinitrc X uses this file when you type startx from a text-mode login.







~/.xsession The XDisplay Manager (XDM) XDMCP server uses this file. The KDE DisplayManager (KDM) and GNOME Display Manager (GDM) XDMCP servers may alsouse this file if you select an appropriate login option.







~/.vnc/xstartup This file is the Virtual Network Computing (VNC) X startup file,













These files are usually bashscripts, and they typically launch programs the user wants to run whenfirst logging in. The most important line in these files is usually thelast line or at least something very near to the last line. This linelaunches the X

window manager, which placesdecorative and functional borders around windows, including the titlebar and the borders that enable you to resize windows. Instead of acall to a window manager, the script may launch a desktop environment,which includes a window manager and other helpful tools.







X startup scripts may include calls to other programsbeyond window managers or desktop environments. For instance, if youwant to launch an xterm when you log in,you would include a line that calls this program prior to the windowmanager call. Such calls typically end in ampersands (&)to launch the program in the background; otherwise, the script willstop executing until the program terminates. The call to the windowmanager, by contrast, lacks this feature; this way, the script doesn'tcontinue executing until you exit from the window manager. After thatpoint, X shuts down or your XDMCP server's login window reappears. Onoccasion, an X login script includes a few lines after the windowmanager call. These lines may clean up temporary files, play a logoutsound, or what have you. Listing 9.2 shows a typical X login file. This file launches an xterm and plays a login sound before launching the IceWM window manager. (IceWM manages the xterm, even though the xterm was launched first.) When the user exits from IceWM, the system plays a logout sound.


Listing 9.2: Typical X Login File

#!/bin/bash
xterm &
play ~/sounds/login.wav &
icewm
play ~/sounds/logout.wav &

Welan, This is fantastic! It is the explanation I have been looking for for years.
Thank you SO much.