Before you can configure the more advanced parts of your system, it's a good idea to learn how the system is organized and what commands can be used to search for files and programs. It's also good to know if you need to compile a custom kernel and what the steps for doing that are. This chapter will familiarize you with system organization and configuration files. Then, you can move on to configuring the more advanced parts of the system.
It's important to understand how a Linux system is put together before diving into the various configuration aspects. A Linux system is significantly different from a DOS or Windows system (or even a Macintosh), but these sections will help you get acquainted with the layout so that you can easily configure your system to meet your needs.
The first noticeable difference between Slackware Linux and a DOS or Windows system is the filesystem. For starters, we do not use drive letters to denote different partitions. Under Linux, there is one main directory. You can relate this to the C: drive under DOS. Each partition on your system is mounted to a directory on the main directory. It's kind of like an ever-expanding hard disk.
We call the main directory the root directory, and it's denoted with a single slash (/). This concept may seem strange, but it actually makes life easy for you when you want to add more space. For example, let's say you run out of space on the drive that has /home on it. Most people install Slackware and make one big root drive. Well, since a partition can be mounted to any directory, you can simply go to the store and pick up a new hard drive and mount it to /home. You've now “grafted” on some more space to your system. And all without having to move many things around.
Below, you will find descriptions of the major top level directories under Slackware.
Essential user programs are stored here. These represent the bare minimum set of programs required for a user to use the system. Things like the shell and the filesystem commands (ls, cp, and so on) are stored here. The /bin directory usually doesn't receive modification after installation. If it does, it's usually in the form of package upgrades that we provide.
Files that are used by the Linux Loader (LILO). This directory also receives little modification after an installation.
Remember that all drives have to be mounted to a directory on the main root directory? Well, /cdrom is provided as a mount point for your CD-ROM drive.
Everything in Linux is treated as a file, even hardware devices like serial ports, hard disks, and scanners. In order to access these devices, a special file called a device node has to be present. All device nodes are stored in the /dev directory. You will find this to be true across many UNIX-like operating systems.
This directory holds system configuration files. Everything from the X Window configuration file, the user database, to the system startup scripts. The system administrator will become quite familiar with this directory over time.
Linux is a multiuser operating system. Each user on the system is given an account and a unique directory for personal files. This directory is called the user's “home” directory. The /home directory is provided as the default location for user home directories.
System libraries that are required for basic operation are stored here. The C library, the dynamic loader, the ncurses library, and kernel modules are among the things stored here.
When the system boots, the filesystems are checked for any errors. If errors are detected, the fsck program is run to see if any can be corrected. The corrected parts of the filesystem are written to the /lost+found directory.
This directory is provided as a temporary mount point for working on hard disks or removable drives.
Optional software packages. The idea behind /opt is that each software package installs to /opt/<software package>, which makes it easy to remove later. Slackware distributes some things in /opt (such as KDE in /opt/kde), but you are free to add anything you want to /opt.
This is a unique directory. It's not really part of the filesystem, but a virtual filesystem that provides access to kernel information. Various pieces of information that the kernel wants you to know are conveyed to you through “files” in the /proc directory. You can also send information to the kernel through some of these “files”. Try doing cat /proc/cpuinfo.
The system administrator is known as “root” on the system. root's home directory is kept in /root instead of /home/root. The reason is simple. What if /home was a different partition from / and it could not be mounted? root would naturally want to log in and repair the problem. If his home directory was on the damaged filesystem, it would make it difficult for him to log in.
Essential programs that are run by root and during the system bootup process are kept here. Normal users will not run programs in this directory.
The temporary storage location. All users have read and write access to this directory.
This is the big directory on a Linux system. Everything else pretty much goes here, programs, documentation, the kernel source code, and the X Window system. This is the directory to which you will most likely be installing programs.
System log files, cache data, and program lock files are stored here. This is the directory for frequently-changing data.
You should now have a good feel for which directories contain what on the filesystem. The next section will help you find specific files easily, so you don't have to do it by hand.
You now know what each directory holds, but it still doesn't really help you find things. I mean, you could go looking through directories, but there are quicker ways. There are four main file search commands available in Slackware.
The first is the which(1) command. which is usually used to locate a program quickly. It just searches your PATH and returns the first instance it finds and the directory path to it. Take this example:
$ which bash /bin/bash |
From that you see that bash is in the /bin directory. This is a very limited command for searching, since it only searches your PATH.
The whereis(1) command works similar to which, but can also search for man pages and source files. A whereis search for bash should return this:
$ whereis bash bash: /bin/bash /usr/bin/bash /usr/man/man1/bash.1.gz |
This command not only told us where the actual program, but also where the online documentation is stored. Still, this command is limited. What if you wanted to search for a specific configuration file? You can't use which or whereis for that.
The find(1) command will search for anything. I want to search the entire system for the default xinitrc file on the system.
$ find / -name xinitrc ./var/X11R6/lib/xinit/xinitrc |
find will take a while to run, since it has to traverse the entire root directory tree. And if you run this command as a normal user, you will probably get permission denied error messages for directories that only root can see. But find found our file, so that's good. If only it could be a bit faster...
The locate(1) command searches the entire filesystem, just like the find command can do, but it searches a database instead of the actual filesystem. The database is set to automatically update at 4:40AM, so you have a somewhat fresh listing of files on your system. You can manually run updatedb(1) to update the locate database (before running updatedb by hand, you must first su to the nobody user). Here's an example of locate in action:
$ locate xinitrc # we don't have to go to the root /var/X11R6/lib/xinit/xinitrc /var/X11R6/lib/xinit/xinitrc.fvwm2 /var/X11R6/lib/xinit/xinitrc.openwin /var/X11R6/lib/xinit/xinitrc.twm |
We got more than what we were looking for, and quickly too. With these commands, you should be able to find whatever you're looking for on your Linux system.
The system initialization files are stored in the /etc/rc.d directory. Slackware uses the BSD-style layout for its initialization files. Each task or runlevel is given its own rc file. This provides an organized structure that is easy to maintain.
There are several categories of initialization files. These are system startup, runlevels, network initilization, and System V compatibility. As per tradition, we'll lump everything else into an “other” category.
The first program to run under Slackware besides the Linux kernel is init(8). This program reads the /etc/inittab(5) file to see how to run the system. It runs the /etc/rc.d/rc.S script to prepare the system before going into your desired runlevel. The rc.S file enables your virtual memory, mounts your filesystems, cleans up certain log directories, initializes Plug and Play devices, loads kernel modules, configures PCMCIA devices, sets up serial ports, and runs System V init scripts (if found). Obviously rc.S has a lot on its plate, but here are some scripts in /etc/rc.d that rc.S will call on to complete its work:
This is the actual system initialization script.
Loads kernel modules. Things like your network card, PPP support, and other things are loaded here. If this script finds rc.netdevice, it will run that as well.
Probes for and configures any PCMCIA devices that you might have on your system. This is most useful for laptop users, who probably have a PCMCIA modem or network card.
Configures your serial ports by running the appropriate setserial commands.
Looks for System V init scripts for the desired runlevel and runs them. This is discussed in more detail below.
After system initialization is complete, init moves on to runlevel initialization. A runlevel describes the state that your machine will be running in. Sound redundant? Well, the runlevel tells init if you will be accepting multiuser logins or just a single user, whether or not you want network services, and if you will be using the X Window System or agetty(8) to handle logins. The files below define the different runlevels in Slackware Linux.
Halt the system (runlevel 0). By default, this is symlinked to rc.6.
Multiuser startup (runlevel 4), but in X11 with KDM, GDM, or XDM as the login manager.
Reboot the system (runlevel 6).
Startup in single user mode (runlevel 1).
Multiuser mode (runlevels 2 and 3), but with the standard text-based login. This is the default runlevel in Slackware.
Runlevels 2, 3, and 4 will start up the network services. The following files are responsible for the network initialization:
Created by netconfig, this file is responsible for configuring the actual network interface.
Runs after rc.inet1 and starts up basic network services.
Starts up AppleTalk services.
Starts up the Apache web server.
Starts up Windows file and print sharing services.
Starts up the news server.
System V init compatibility was introduced in Slackware 7.0. Many other Linux distributions make use of this style instead of the BSD style. Basically each runlevel is given a subdirectory for init scripts, whereas BSD style gives one init script to each runlevel.
The rc.sysvinit script will search for any System V init scripts you have in /etc/rc.d and run them, if the runlevel is appropriate. This is useful for certain commercial software packages that install System V init scripts and scripts for BSD style init.
The scripts described below are the other system initialization scripts. They are typically run from one of the major scripts above, so all you need to do is edit the contents.
If enabled, this script will scan for a CD-ROM in a drive and mount it under /cdrom if it finds one.
Starts up general purpose mouse services. Allows you to copy and paste at the Linux console.
Starts up the Intel Binary Compatibility support. This is only needed if you plan on running programs compiled on SCO UNIX, or other commercial Intel UNIX flavors. It is not needed to run Linux programs.
Loads the custom screen font for the console.
Contains any specific startup commands for your system. This is empty after a fresh install, as it is reserved for local administrators. This script is run after all other initialization has taken place.
To enable a script, all you need to do is add the execute permissions to it with the chmod command. To disable a script, remove the execute permissions from it. For more information about chmod, see the section called Permissions in Chapter 9.