This section describes some of the more important UNIX services, but without much detail. They are described more thoroughly in later chapters.
The single most important service in a UNIX system is provided by init. init is started as the first process of every UNIX system, as the last thing the kernel does when it boots. When init starts, it continues the boot process by doing various startup chores (checking and mounting filesystems, starting daemons, etc).
The exact list of things that init does depends on which flavour it is; there are several to choose from. init usually provides the concept of single user mode, in which no one can log in and root uses a shell at the console; the usual mode is called multiuser mode. Some flavours generalise this as run levels; single and multiuser modes are considered to be two run levels, and there can be additional ones as well, for example, to run X on the console.
Linux allows for up to 10 runlevels, 0-9, but usually only some of these are defined by default. Runlevel 0 is defined as ``system halt''. Runlevel 1 is defined as ``single user mode''. Runlevel 6 is defined as ``system reboot''. Other runlevels are dependent on how your particular distribution has defined them, and they vary significantly between distributions. Looking at the contents of /etc/inittab usually will give some hint what the predefined runlevels are and what they have been defined as.
In normal operation, init makes sure getty is working (to allow users to log in), and to adopt orphan processes (processes whose parent has died; in UNIX all processes must be in a single tree, so orphans must be adopted).
When the system is shut down, it is init that is in charge of killing all other processes, unmounting all filesystems and stopping the processor, along with anything else it has been configured to do.
Logins from terminals (via serial lines) and the console (when not running X) are provided by the getty program. init starts a separate instance of getty for each terminal upon which logins are to be allowed. getty reads the username and runs the login program, which reads the password. If the username and password are correct, login runs the shell. When the shell terminates, i.e., the user logs out, or when login terminated because the username and password didn't match, init notices this and starts a new instance of getty. The kernel has no notion of logins, this is all handled by the system programs.
The kernel and many system programs produce error, warning, and other messages. It is often important that these messages can be viewed later, even much later, so they should be written to a file. The program doing this is syslog. It can be configured to sort the messages to different files according to writer or degree of importance. For example, kernel messages are often directed to a separate file from the others, since kernel messages are often more important and need to be read regularly to spot problems.
Both users and system administrators often need to run commands periodically. For example, the system administrator might want to run a command to clean the directories with temporary files (/tmp and /var/tmp) from old files, to keep the disks from filling up, since not all programs clean up after themselves correctly.
The cron service is set up to do this. Each user can have a crontab file, where she lists the commands she wishes to execute and the times they should be executed. The cron daemon takes care of starting the commands when specified.
The at service is similar to cron, but it is once only: the command is executed at the given time, but it is not repeated.
See the manual pages cron(1), crontab(1), crontab(5), at(1) and atd(8) for more in depth information.
UNIX and Linux don't incorporate the user interface into the kernel; instead, they let it be implemented by user level programs. This applies for both text mode and graphical environments.
This arrangement makes the system more flexible, but has the disadvantage that it is simple to implement a different user interface for each program, making the system harder to learn.
The graphical environment primarily used with Linux is called the X Window System (X for short). X also does not implement a user interface; it only implements a window system, i.e., tools with which a graphical user interface can be implemented. Some popular window managers are: fvwm, icewm, blackbox and windowmaker. There are also two popular desktop managers, KDE and Gnome.
Networking is the act of connecting two or more computers so that they can communicate with each other. The actual methods of connecting and communicating are slightly complicated, but the end result is very useful.
UNIX operating systems have many networking features. Most basic services (filesystems, printing, backups, etc) can be done over the network. This can make system administration easier, since it allows centralised administration, while still reaping in the benefits of microcomputing and distributed computing, such as lower costs and better fault tolerance.
However, this book merely glances at networking; see the Linux Network Administrators' Guide http://www.linuxdoc.org/LDP/nag2/index.html for more information, including a basic description of how networks operate.
Network logins work a little differently than normal logins. There is a separate physical serial line for each terminal via which it is possible to log in. For each person logging in via the network, there is a separate virtual network connection, and there can be any number of these. [1] It is therefore not possible to run a separate getty for each possible virtual connection. There are also several different ways to log in via a network, telnet and rlogin being the major ones in TCP/IP networks. [2]
Network logins have, instead of a herd of gettys, a single daemon per way of logging in (telnet and rlogin have separate daemons) that listens for all incoming login attempts. When it notices one, it starts a new instance of itself to handle that single attempt; the original instance continues to listen for other attempts. The new instance works similarly to getty.
One of the more useful things that can be done with networking services is sharing files via a network file system. The one usually used is called the Network File System, or NFS, developed by Sun.
With a network file system any file operations done by a program on one machine are sent over the network to another computer. This fools the program to think that all the files on the other computer are actually on the computer the program is running on. This makes information sharing extremely simple, since it requires no modifications to programs.
Another popular way of sharing files is Samba http://www.samba.org. This protocol allows the sharing of files with MS Windows machines (via Network Neighbourhood). It also allows the sharing of printers across machines.
Electronic mail is the most popularly used method for communicating via computer. An electronic letter is stored in a file using a special format, and special mail programs are used to send and read the letters.
Each user has an incoming mailbox (a file in the special format), where all new mail is stored. When someone sends mail, the mail program locates the receiver's mailbox and appends the letter to the mailbox file. If the receiver's mailbox is in another machine, the letter is sent to the other machine, which delivers it to the mailbox as it best sees fit.
The mail system consists of many programs. The delivery of mail to local or remote mailboxes is done by one program (the mail transfer agent (MTA), e.g., sendmail or smail), while the programs users use are many and varied (mail user agent (MUA), e.g., pine, mutt or elm). The mailboxes are usually stored in /var/spool/mail.
Only one person can use a printer at one time, but it is uneconomical not to share printers between users. The printer is therefore managed by software that implements a print queue: all print jobs are put into a queue and whenever the printer is done with one job, the next one is sent to it automatically. This relieves the users from organising the print queue and fighting over control of the printer. [3]
The print queue software also spools the printouts on disk, i.e., the text is kept in a file while the job is in the queue. This allows an application program to spit out the print jobs quickly to the print queue software; the application does not have to wait until the job is actually printed to continue. This is really convenient, since it allows one to print out one version, and not have to wait for it to be printed before one can make a completely revised new version.
The filesystem is divided into many parts; usually along the lines of a root filesystem with /bin, /lib, /etc, /dev, and a few others; a /usr filesystem with programs and unchanging data; a /var filesystem with changing data (such as log files); and a /home filesystem for everyone's personal files. Depending on the hardware configuration and the decisions of the system administrator, the division can be different; it can even be all in one filesystem.
Chapter 4 describes the filesystem layout in some little detail; the Filesystem Hierarchy Standard covers it in somewhat more detail. [4]
| [1] | Well, at least there can be many. Network bandwidth still being a scarce resource, there is still some practical upper limit to the number of concurrent logins via one network connection. |
| [2] | These days many Linux system administrators consider telnet and rlogin to be insecure and prefer ssh , the ``secure shell'', which encrypts traffic going over the network, thereby making it far less likely that the malicious can ``sniff'' your connection and gain sensitive data like usernames and passwords. It is highly recommended you use ssh rather than telnet or rlogin. |
| [3] | Instead, they form a new queue at the printer, waiting for their printouts, since no one ever seems to be able to get the queue software to know exactly when anyone's printout is really finished. This is a great boost to intra-office social relations. |
| [4] |