Debian GNU software distribution

Free Software distributions, such as Debian GNU, are — as the name implies — comprised of a large number of Free Software programs. That's why, when you pick Debian GNU, you get not only a basic operating system, but a complete environment with more (much more) than 15,000 precompiled, prepackaged and ready to use software programs. Exactly how this complex job gets done in practice is a subject for itself, but the important thing is it's only possible because all of the included programs are released under one of the free, DFSG-compliant licenses (software authors using free software licenses deserve the highest respect).

For you, the end user, this means you don't need to cruise the city with an open wallet in search of proprietary software vendors and their poor products, because all the software you'll ever need is already prepared, tested and waiting for you in the Debian repositories. Debian repositories consist of a standard directory hierarchy, software packages (*.deb files), and the accompanying meta data which describes the repository contents. Repositories themselves are not tied to a particular access method or storage medium, so you can access them from almost anywhere: the Internet, LAN, local hard disks or CD-Roms.

Advanced Package Tool

Most computer environments recognize the concept of software installation, and so does Debian GNU. Computer programs that you can install are, in a packaged form, archived in Debian repositories. Before use, they need to be retrieved from the repository, installed (unpacked onto the system and registered with the software management tool) and configured.

Debian specifically has developed a very sophisticated tool for this high level package management called APT (the Advanced Package Tool) that leaves any competition far behind. Combined with an easy and straightforward configuration process, apt is surely one of the winning Debian ideas.

deb     http://ftp.CC.debian.org/debian stable main
deb-src http://ftp.CC.debian.org/debian stable main
deb http://security.debian.org/ stable/updates main

deb     http://ftp.CC.debian.org/debian testing main
deb-src http://ftp.CC.debian.org/debian testing main
deb http://security.debian.org/ testing/updates main

deb     http://ftp.CC.debian.org/debian unstable main
deb-src http://ftp.CC.debian.org/debian unstable main

Base Debian GNU installation

If you have ever tried any of the commercial Linux distributions (such as Red Hat, Mandrake or SuSE), then the first thing you'll notice about Debian is that you don't get the X Window System or a fancy desktop during the installation (although the new "d-i" installer will perform hardware auto-detection for you). In essence, you don't get any more than a minimum of system software installed.

The commercial Linux companies have set, would you guess it, their commercial interests as a priority, and the whole auto detection and out of the box ideas are there just to make their products more appealing on the market. Those companies have played, do play, and will be playing positive roles in both the acceptance and development of free software (most notably the latest PC hardware drivers), but their systems are far from the best one could get. Commercial systems tend to sacrifise technical correctness in favor of met deadlines (and do so many times along their product's life), and provide a pretty poor learning or professional platform.

Debian, on the other hand, is a non-profit organization that sticks to it's original manifesto and can easily afford itself the luxury of pursuing technical excellence before "market time". For those and other reasons that will come to surface along our journey, you'll see that Debian does things the way things should be done even if you, lacking the in-depth knowledge, don't see the killer point at first.

Finally, when you get to understand how close to the hardware a Unix user is, and how simple (even trivial) it is to perform hardware configuration in Debian, you'll laugh at anyone who judges or picks Linux distributions to use based on the amount of out of the box auto detection and fancy graphics.

With Debian GNU, all you get out of the box is a minimal installation and a black console Login: prompt. We'll move from there on.

Shell and filesystem

When you log in to the system (authenticate typically with your user name and password at the Login: prompt), you'll be confronted with a text command line, something that might remind you of DOS, but that's where their similarity ends (so don't bother with inappropriate comparisons). What you are actually seeing is bash, one of the popular shell programs. In general, shell programs serve as agents between the user and the system (accept commands, return output) and are all, infact, more or less sophisticated programming languages.

Computer software is based on files. Files live in directories (not folders), which are located on virtual or physical, local or network disk partitions. In Unix, every system has a root partition which is mounted (think "associated") as the root directory (denoted by /) and serves as an entry point to the filesystem. For example, /home/mirko/.profile (called the pathname, absolute path, or full path) tells there's a file named .profile which resides in the directory /home/mirko/. In this example, mirko/ is obviously a subdirectory of home/, and home/ is a subdirectory of / — the root directory.

Files beginning with a dot (such as .profile from just above) are called dotfiles. They usually contain configuration settings for various programs and are — as such — considered of secondary interest and usually omitted in directory listings. It's the magic dot (.) at the beginning that makes them "invisible", but only for the purpose of not adding noise to the output, and definitely not in hope of "hiding" files.

Each file in Unix belongs to one user and one user group. Additionally, there are file modes (or file permissions) that control which operations are allowed to file's owner, file's group, and everyone else. The only directories that regular system users can modify are their home directory (usually /home/USERNAME) and system temporary directories (/tmp and /var/tmp).

Unix filesystem permissions

Although, in the traditional concept, a file or directory belongs to one user and one group, various advancements have become available over time. Most notably, these include Access Control List and Role-based Access Control solutions. ACLs allow files (and directories, of course) to have potentially different permissions for every system user or group. RBAC systems allow users to be assigned "roles", and thus granted access to role-related files. It's important to note, however, that the traditional concept — although trivial in principle — offers extraordinary flexibility and whole-heartedly satisfies all general needs.

Concerning the filesystem "navigation", there's a concept of current directory which tells the active (working) position in the filesystem. You can discover the working directory at any time by typing pwd in your shell. When you log in to the system and the shell starts up, it drops you to your home directory — that is thus your starting point.

In addition, with Unix, you generally don't need to invent the directory locations for the system software you want to install. Software is installed to pre-determined locations, which is a superior scheme. Some of the directories you need to know about are:

• /home - users' home directories

• /etc - system-wide configuration files

• /bin, /usr/bin, /usr/local/bin - directories with executable files (that is, programs you can run). bin comes from binary, not a dust bin

• /lib, /usr/lib, /usr/local/lib - shared libraries needed to support the applications

• /sbin, /usr/sbin, /usr/local/sbin - directories with executables supposed to be run by the Superuser

• /tmp, /var/tmp - temporary directories, watch out as /tmp is, by default, cleaned out on each reboot

• /usr/share/doc, /usr/share/man - complete system documentation

• /dev - system device files. In Unix, hardware devices are represented as files

• /proc - "virtual" directory (it doesn't really exist on the disk) containing files through which you can query or tune Linux kernel settings

Why software is installed to pre-determined locations is easy to explain: Unix and Unix filesystems allow seemingly standard directories and subdirectories to be mounted to completely different places — local disk partitions, network partitions, or RAM disks, to name a few.

When you need to manage location of files and directories with finer granularity, then Unix symbolic and hard links, GNU Stow, or dpkg-divert come to play (but they're all advanced concepts that we'll yet return to).

In the above list of directories, you might have noticed a pattern. For example, there's bin/ directory in all /, /usr/ and /usr/local/. Directories and files found in the root directory (/) are all official distribution files (those from Debian GNU or other packages, depending what Unix are we talking about), and infact those that are essential for the system to boot up. This is kind of a historic leftover, from times when systems were booted using the "root" tape, and then had another, "user" tape mounted on /usr/. This technique is, for its usefulness, still used today with all properly set-up Unix systems (well, except maybe the Hurd, if you consider it being part of the same league). Directories and files in /usr/ are also official distribution files, but are not essential for the system to boot up. A large majority of software belongs to this group. Finally, directories in /usr/local/ contain locally installed software (which does not come from the official Operating System distribution), hence the separate location and name "local". There's also the share/ directory that you can see floating around; it contains files which are hardware platform-independent and are the same on all supported architectures.

Manipulating software packages

Now, recall apt we mentioned some paragraphs above. As you're left with a minimal system, you need to install few packages to make your Unix life easier. Let's start by typing and executing apt-get install less sudo man-db manpages in your shell.

To see what exactly is each of the programs used for, you could run apt-cache show PACKAGE NAMES. If the output scrolls out of your screen too fast, help yourself with the Shift+PageUP/DOWN keys. If the retrieveable area is still too small, run the command with a buffer: apt-cache show PACKAGE NAMES | less (to exit the "pager" program less, you press q). Anyhow, it will soon become pretty obvious what the above programs are used for, but don't let that prevent you from picking up the implicitly presented tips (apt-cache, Shift+PageUP/DOWN, less).

For a list of all installed packages, run dpkg -l. To see a list of files installed by specific packages, run dpkg -L PACKAGE NAMES, such as dpkg -L sysvinit. To find out which package does a file belong to, run dpkg -S FULLPATH, such as dpkg -S /bin/bash.

To remove a package, run apt-get --purge remove PACKAGE NAMES. The --purge switch deletes the eventual program config files (which are normally left on the system) as well as the program itself.

Sometimes it's not that easy to guess package names, so you'll need to search for them (based on key words). To do so, use apt-cache search KEY WORDS, such as apt-cache search console ogg player.

Let's now make use of those programs we installed a moment ago.

Administrative account wrapper

Run command id to determine your user name. You should see the UID 0 (unique User ID zero) and the username root. Unix traditionally maintains the concept of a superuser or root, a special account with UID 0, who is free to perform any administration tasks. This is a little different in practice with Linux because it uses a lot more flexible capabilities mechanism, but the principle stays the same. Logging in as root is strongly discouraged, so we will now see how to avoid it. You will always use a regular system account, and only execute specific privileged commands by using a sudo program that will serve as a wrapper for administrative commands.

Create a non-privileged account now by running the adduser mirko command. Once you've done that, run echo "mirko ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers. The sudo system is the administrative wrapper we mentioned, and it'll grant mirko the privilege to run any command with root privileges.

Having done that, log out completely (by exiting all shells, which means typing logout, exit, or pressing Ctrl+d in all active terminals). Then log back in under the newly created, non-privileged username.

To see the sudo system at work, run id; it should tell mirko is your active user ID. Then run sudo id, and see how the id program is ran with root privileges. You will use sudo and you will not log-in as the superuser any more.

We will use sudo extensively; to edit system configuration files for example, you will use sudo nano FILENAME.

Unix text editors

Most of Unix system configuration is kept in plain text files, so you'll definitely want to pick your favourite text editor (out of a little myriad available ones). You could start with joe, nano or pico (nano is probably the best, as it is included in the base Debian GNU system). These editors are simple and their common keystrokes are listed at the bottom of the screen. Try running nano now to see its simplicity for yourself. (Keep in mind that the "^" character, needed to access nano's menus, represents the Control / Ctrl key on your keyboard.)

The category of professional text editors, however, is reserved for the two old rivals - Richard Stallman's GNU Emacs and Bram Moolenaar's Visual IMproved (or the old traditional vi). Apart from having ultra fast keystrokes, macros, abbreviations, editing modes, syntax highlighting and keyword completion, Vim can literally solve it's way out of a maze (take a look at /usr/share/doc/vim/macros/maze/ once). Another vi's advantage is it's installed on about every Unix system you can think of. References to the relevant Vim tutorial pages are given at the end of the Guide.

If you have no idea which editor to use, try using nano. Then, once later, you might get around to installing Vim and running vimtutor to learn its basics. But don't take this as a joke; Unix is about text (lots of text, even if you'll probably prefer GUIs at first), and learning Vim or GNU Emacs is an absolute necessity.

So invoke sudo update-alternatives --config editor now, and select your favourite text editor of the moment. (Once selected, this editor will be invoked when the generic editor command is run).

From now on, we'll assume you know how to open a file, change it and save the changes back to disk.

Basic system commands

You can't start wandering around the Unix system without being introduced to the basic available commands first. Now that you're using an unprivileged account and can't ruin your Debian GNU installation any more, we'll take a tour of system file and directory manipulation commands.

To change directory, use the cd command. Run few variants of it and verify current directory with pwd or echo $PWD. Try and see where each of the commands cd /etc, cd -, cd .., cd $OLDPWD, cd ../.., and cd ~ positiones you.

The special tilde character (~) in file names expands to the home directory of the user invoking the command. For user mirko, cd ~ and cd /home/mirko would be equivalent. In addition, if mirko wanted to reach ante's home directory, he would only have to type cd ~ante. (This ability to reach user's home directory using a syntax independent of actual system setup is another winning concept in Unix).

The dash(-) and the $OLDPWD environment variable do the same thing; they re-position you to the previous working directory. Running the command multiple times would cycle between two most recently used paths.

You can check out the contents of a directory with the ls (list) command; try ls, ls -al /etc, or ls -al / (-a is needed to make ls display the dotfiles — those that start with a dot and are considered "hidden", remember? -l displays the output in list format).

Create new files in your home directory using a text editor — use cd to reposition to your home directory and then run say, nano test. Alternatively, you could use a variant of the command which is not dependent of the current working directory — nano ~/test for example. Try removing (deleting) the created files with rm. Create directories with mkdir, delete them with rm -r or rmdir.

Briefly note that the previous examples used your keyboard as the input and your monitor as the output device. It's important to understand that Unix can redirect such data streams to arbitrary locations (files, pipes, printers, network sockets and more). For example, run ls -al / | grep bin. The output of the ls -al / command will be piped or redirected to the next command, grep, which will filter the input and only display lines which contain the string "bin". This piping (a special case of redirection, where output is redirected to a program) is, you guess it, denoted by the pipe ("|") character.

If you'd like to redirect the output of a command to a file (instead of to the next command, as the above pipe would do), use the > or >> redirects; the difference is the double >> appends content to a file without truncating (erasing, roughly) it first. Try say, ls -al / > /tmp/dirlisting.

Sometimes you want the output to appear on both the screen, and saved in a file. This is Unix and it's easily done: ps aux | tee /tmp/ps-aux.listing. We can mention that, in a same way, the output can be "duplicated" to another console (yours or, subject to access permissions, one belonging to a different user). For those who wonder how to get the output on a printer, let's just say ps aux | lp is enough once the printer is configured.

Some other times, you need to create an empty file. For example, try touch test2, > test2 or >> test2. The difference is that, if the file already existed, touch would just update it's modification time, while the single redirection symbol would truncate it as well. Some people also use echo > test2 but they don't figure their file isn't exactly empty — it is of size 1 byte and contains 1 ASCII character which represents "newline" (this happens due the echo command appending a newline to the end, unless -n option is given to it).

You now know four command line methods to create a file; try testing your friends' knowledge.

To save a copy of your interactive (user input-output) session in a file named typescript, just run script. To finish the typescript, just exit the shell (by say, pressing Ctrl+d on an empty line. As we've said earlier, Ctrl+d is a standard combination for "End of Input").

When you type say, ls, an instance of the /bin/ls program becomes a process (a running program). We'll cover processes thoroughly in a separate chapter but, for the moment, let's just say the program you run is assigned a unique process ID (the PID), it starts running on the processor (the CPU) and competes for the processor time with other running programs. To see your current processes, run ps. To see a complete list of processes on the system, run ps aux. When the job is complete, the corresponding process terminates, and the PID number is reclaimed to the pool (On Linux, the process table contains 32768 available entries). For an interactive process monitor, see top.

Check system memory information with free. If you get into total/free memory mathematics, just keep in mind a lot of used memory is not a bad thing and it doesn't mean your system is wasting it; we'll discuss this later in the Guide.

Additional and interesting programs related to system and memory status that you could install are sysstat, memstat and htop.

To see a list of mounted filesystems, their mount points and mount options, simply run mount. To see disk usage statistics, run df.

Note that mount only reads a file, /etc/mtab, and "prettifies" it a little before display. In turn, /etc/mtab should contain content that is essentially the same as /proc/mounts, but this is not always the case (for example, if /etc/ was mounted read-only at time when mount wanted to update the file). Unless you're really adventureous, you won't happen to see output from the mount command being incorrect, but remember that only /proc/mounts tells the definite truth.

Now, let's say you wanted to execute commands uptime, free and df at once. You could do this simply by running uptime; echo; free; echo; df. (It is the semicolon ";" important here, echo command without arguments only serves to produce empty lines in between).

Use w or who to see the list of current system users. Run last -20 to see last 20 logins to the system. If you'd like an interactive variant of w (in the top fashion), use a general purpose watch command: watch -n 1 w (finish by pressing Ctrl+c, the generic "break" signal). watch is pretty interesting, by using quotes, you could run watch -n 1 'uptime; echo; free; echo; df' as well.

Run uname -a to see the most general system information - the hardware and kernel types and versions. For the run time statistics, run uptime; the program reports the current time, time since the machine boot (the machine uptime), the number of users logged in and the load (processor usage) averages for the last 1, 5 and 15 minutes.

To bring the idea to yet another level, let's say you had a complex chain of commands saved in a file, and wanted to execute the whole file at once (in "batch" mode, as people would say). This is, of course, easily doable with the piping principle mentioned above. Let's first run echo -e "uptime; echo\nfree; echo\ndf" > commands to create our "batch" file. (Additionally, run cat commands to see how the file really looks like and to understand the effect of the newline character \n). To "batch-execute" it, all we would have to do is run cat commands | sh, or sh < commands, or just sh commands. What's more, if you set an executable bit on the batch file (chmod +x commands) and added an appropriate "shebang" line to the file (by opening it and inserting #!/bin/bash at the top), you could run it by invoking ./commands or, more generally, /path/to/commands.

Unix programs come in many variants. They usually have a large set of supported options and successfully interact with each other, effectively multiplying their feature lists. Actually, somewhere I read an interesting thought — that an Unix program can be considered successful if it becomes used in situations never predicted by its author. All of the programs I mentioned above are crucial to Unix and are successful. Their full potential greatly exceeds basic usage examples we provided.

System documentation and reference

Debian GNU is a free and open system. All the issues that might pose a problem for you are already documented and explained somewhere. Surely a milestone in your Unix experience is learning where those information sources are, how to interpret their contents, and generally, how to help yourself in predicted and unpredicted situations without someone handholding you.

Unix documentation is extensive and easily available. Most of it is written by the software authors themselves (and not by the nearest marketing department) so you actually have the privilege of communicating to the authors' themselves. The pool of people who write Free Software programs and documentation includes a large community of technology professionals.

The process starts with yourself reading the provided documentation to see what do the software authors have to say to you, and to pick a little of their mindset. Debian pays special attention to the documentation; if it's not available from the upstream (original) author, then the Debian developers write the missing pieces themselves.

In Debian, each package you install creates a /usr/share/doc/PACKAGE/ directory and places at least the changelog files there. The directory in addition often contains the INSTALL, README and other upstream files which are sometimes irrelevant for you, as the tasks described there have already been performed by the Debian developers (but the rest of the notes, of course, still provide good information about the program). What you definitely are looking for are Debian-specific notes (in README.Debian files). This is the first place you visit for more information about a package. It is not uncommon that Debian packages see an enormous "added value" from maintainer-provided README files and practical recipes. Sometimes, if the documentation is big, a standard naming convention is followed and the documentation is distributed in a separate PACKAGE-doc package.

The other, very often used, part of the documentation are the system manual pages, accessible with the man and info commands. Man follows the traditional Unix manpage approach while info is the GNU-style texinfo collection. Man pages are sorted by volumes or sections which include user commands, system calls, subroutines, devices, file formats, games, misc and system administration topics. The man and info systems don't read each other's manual pages, but coexist peacefully on your system, mostly in a way that the info pages are ignored by your part. One of the reasons for this, in my opinion, is the very annoying info user interface (unless you're accustomed to GNU Emacs — then you'd describe the feeling as normal). To remedy the problem a little, try installing the alternative pinfo browser (sudo apt-get install pinfo).

To get a feeling of manpages, try running man mkdir. You'll notice all manpages follow a pretty standard structure; they often include NAME, SYNOPSIS (Usage), DESCRIPTION, AUTHOR, BUGS, COPYRIGHT and SEE ALSO sections. The specific mkdir page you opened tells you that all program options (those starting with "-" or "--") are optional (denoted by angle brackets — [] — in the synopsis line), but at least one directory name to create is mandatory (required). In some manpages, mandatory options are enclosed in <less/greater-than> symbols (like <-s size>).

See the man ps or pinfo ls commands. It is absolutely necessary to develop the habit of reading manpages. Whenever we mention a system command or a config file, we implicitly expect you to skim through its manpage. Novices have trouble understanding the manual pages; even though all the information they want to learn is right there, in the manpage, they have a hard time connecting heads to tails. If you happen to have this problem, keep reading — and given enough material you'll naturally come to understanding!

Sometimes you only want a general and short, one-line description of a program. See whatis cp or whatis df du. If you're looking for a particular functionality but don't know the actual command name, try using apropos. As it searches for manpages that satisfy any of the key words you enter, it tends to return large sets of results, so restrict your searches to a single keyword, like apropos usage or apropos rename (or ideally, run man apropos and learn how to specify search mode).

If you feel you need to ask the community a question, you can either use the various mailing lists (MLs) or the "real time" Internet Relay Chat (IRC). Probably a few mailing lists exist for about any program or project you may have a question about, but the mailing lists are not suitable for informal discussion and amateur help requests (to be correct, no one says they're not — but in a few years time, you surely won't appreciate Google or AltaVista first linking your name to such content).

IRC is your best bet to go over "runtime" issues. Install the ircii package, simply run irc and join the Debian channel by typing /join #debian once you're connected to the server. There are always hundreds of people present on the channel; if your questions are meaningful and don't require people to answer in essays, they'll probably be helpful to you. Spend time on the channel, learn from other people's questions and answers, and don't add to the channel noise. Exit ircii by typing /quit. Mind you, the sole possibility of presenting your question before the technically proficient audience is a great privilege and, of course, you must follow some minimum of the protocol: it's not required that you are familiar with the subject (if that was the case, you wouldn't be asking a question in the first place), but do read Eric Raymond's How to Ask Questions the Smart Way to increase your chances of recieving useful answers.

Booting the machine; runlevels and system services

The process of booting a machine starts with the computer loading system BIOS (or PROM, on Unix architectures) code from a known and fixed address in memory. Once that is done, BIOS tries to run user-specified code which is usually a bootloader (the thing that lets you choose the Operating System you want to boot).

In most common scenarios, you have Grub (Ground Unified Boot Loader) or LILO (Linux LOader) installed as the bootloader. Both Grub and LILO accept parameters on the command line, but in Debian LILO has been configured (in default configuration) not to show the LILO boot prompt. To make it appear, hold the Alt key at the 'LILO' message (during boot, just before it continues with the 'Loading linux ....' message), and you'll be able to pass arbitrary parameters to the kernel. For Grub, this is achieved by pressing "e" to edit entry, then "e" to edit the "kernel" line, and "b" to boot.

You can play and pass anything to the kernel via this command line; it won't cause harm unless you happen to choose a name that some part of the system actuall uses, such as acpi, mem, root, hda or panic. Your value will be visible in file /proc/cmdline later when the system boots.

After the kernel is loaded, it will start the init program which is the first process started on almost all Unix systems (as such, it has a PID of 1), and is active as long as the system is running.

As soon as the kernel initializes the keyboard driver, you will be able to pause terminal output by pressing Ctrl+s. This will allow you to stop boot messages scrolling and peacefully examine the output on the screen. Ctrl+q will have the effect of "releasing" the terminal. Keep in mind that you can always use this trick in a terminal (it's not related to the boot-up phase), and the Scroll Lock key on your keyboard has the same effect as Ctrl+s/Ctrl+q.

And then, in relation to init, we come to system runlevels. Runlevels are simply agreed states of the machine. Entering a runlevel means starting some services (while stopping others) to make sure the system looks as it is specified by the corresponding runlevel. init first executes tasks defined in the /etc/rcS.d/ directory — the Single-user runlevel. It then enters the default Debian GNU runlevel 2 and — consequently — executes the tasks defined in the /etc/rc2.d/ directory. (Note that other Linux distributions mostly use runlevel 3 as their default; runlevel 2 is the same as 3, but doesn't start any of the X Window System stuff).

Debian GNU uses System V init system by default. It means that runlevels are represented as directories (/etc/rc?.d/), and directories consist of symbolic links to files in the "main" /etc/init.d/ directory; here's an example:

$ ls -la /etc/rc2.d/ | cut -b 57-
...
S20net-acct -> ../init.d/net-acct
S20openldapd -> ../init.d/openldapd
S20postgresql -> ../init.d/postgresql
...

The 'S' prefix starts a service, while 'K' stops it (for the given runlevel). The numbers determine the order in which the scripts are run (0 being the first).

init then excutes local scripts from /etc/rc.boot/ and performs the rest of init tasks specified in /etc/inittab (in older versions, /etc/bootmisc.sh was also ran). At that point, the system is booted, you see the Login: prompt, and life is great even more than usual.

Debian GNU provides a convenient tool to manage runlevels (to control when services are started and shut down); it's called update-rc.d and there are two commonly used invocation methods:

# update-rc.d -f cron remove
# update-rc.d cron defaults

The first line shows how to remove the cron service from startup; the second sets it back. Cron is very interesting, it's a scheduler that can automatically run your tasks at arbitrary times (even when the machine is completely unattended, of course). It definitely deserves some paragraph in this Guide and indeed, we'll get back to it later.

So, all files in /etc/init.d/ share a common invocation syntax (which is defined by Debian GNU Policy) and can, of course, be run manually - you don't have to wait for init to call them. All system services have their init scripts in the /etc/init.d/ directory (which are usually named after the services themselves), and which accepts generic arguments. Let's see an example:

# ls -al /etc/init.d/s* | cut -b 55- 
/etc/init.d/sendsigs
/etc/init.d/setserial
/etc/init.d/single
/etc/init.d/skeleton
/etc/init.d/sudo
/etc/init.d/sysklogd

# /etc/init.d/sysklogd stop
Stopping system log daemon: syslogd.

# /etc/init.d/sysklogd start
Starting system log daemon: syslogd.

# /etc/init.d/sysklogd invalid
Usage: /etc/init.d/sysklogd {start|stop|reload|restart|force-reload|reload-or-restart}

	Please Note:
	A generic init.d script template, /etc/init.d/skeleton, can be used as a starting point for your own scripts. For elements that do not require a full-fledged startup script, see files /etc/init.d/bootmisc.sh and /etc/rc.local. On a side note, Debian supports a number of different init mechanisms. At some later point, you might take a look at file-rc and runit.

Now that we've covered the basics of a system boot process, we can move on to a subject that just logically follows.

Virtual consoles

Almost all Free Software distributions ship with predefined 'virtual terminals' - completely separate text screens or consoles which are available with left Alt + F1-F6 keystrokes (only about 6 consoles are enabled by default). Keep in mind that it is also possible to use command-line method to switch between the consoles (see the chvt command) and that you can open new consoles automatically (from scripts or otherwise) with the open command. Some proprietary Unices use the Ctrl + Alt + 1-6 combination (standard numeric keys instead of Function keys).

To enable more virtual consoles than what you get by default, run sudo editor /etc/inittab and add more lines like those:

5:23:respawn:/sbin/getty 38400 tty5
6:23:respawn:/sbin/getty 38400 tty6

[You can see which fields have to be incremented]. For changes in that file to take effect, exit the text editor and type telinit q.

If you create more than 12 consoles, you won't be able to access them with left Alt (since the last F key you have is 12), so use Right Alt key to reach consoles 13 - 24. You can also use Alt + left_arrow or Alt + right_arrow to cycle through open consoles. Alt + Print_Screen key switches between two last used virtual consoles.

We did not cover any of the X Window System (Unix graphical interface) stuff yet, but just remember that you'll need to use Ctrl+Alt instead of just Alt to switch from an X window to the console.

The deallocvt command frees memory still associated with virtual terminals which are no longer in use [by applications, not you of course], although this is probably not so important nowadays due to insane amounts of RAM in personal computers.

Some more useful stuff that you can do with the consoles include changing the VGA font size. This can be quickly achieved by running something like consolechars -f lat1-08, where the available fonts are in the /usr/share/consolefonts/ directory.

The other way is to run lilo -R 'linux vga=ask' ; reboot, upon which the system will reboot and you'll be given an option to specify the font size (size of 6 is small and fine). This line above would set up LILO parameters only for just the next boot (linux vga=ask). So when you find a nice VGA mode, you should edit /etc/lilo.conf and make it permanent there:

image=/vmlinuz
label=Linux
read-only
# Just add the line below
append="vga=X"

[X is replaced with the actual value you like, 6 for example]. Then, run lilo to apply changes (not forgetting sudo, of course).

It's also possible to drive the console in the high-resolution VESA mode, but that's quite tricky to set up and doesn't justify for inclusion in our Guide.

Furthermore, if you see the penguin in the upper left corner of your screen while the system is booting, or the console text pointer is a blinking rectangle (instead of just a blinking underscore), then you are using a "framebuffer" graphics mode. In that case, there are more screen modes available to you, but they are just not listed in the boot-time selection menu; see the table on the Framebuffer HOWTO page for the full list. There's also fbset command available (from the fbset package) to control the framebuffer behavior.

In most simple terms, framebuffers directly map a portion of RAM memory onto the graphics display device. The amount of memory occupied equals horizontal resolution * vertical resolution * bits per pixel. All you need to do in order to draw to the screen then, is modify appropriate locations in RAM. Even though this framebuffer idea is very nice (and framebuffers play much more important role on other architectures than they play on PCs), and even though framebuffers can be really fast, they never gained much popularity on GNU/Linux PCs. They are generally too hard to tune properly, and the Linux framebuffer documentation is terribly poor (the best startup point is the Programming Linux Games book by John R. Hall, Loki software). However, since all VESA2 cards support framebuffers, during one period (from year 1998 to 2001, rougly) framebuffers were often used to run X graphical interfaces on graphics cards for which no free software drivers existed yet; they were slow and all (of course, because they didn't employ any acceleration techniques), but still allowed to run displays with normal resolution and color depths (opposite to the also-supported VGA mode, but which only allowed a 640x480 resolution in 16 colors). Nowadays, framebuffers are mostly used in Operating System installation programs that hope to achieve greater compatibility on a wide range of hardware.

Besides the mentioned font size, you can also change font types. Install the fonter package and you will be able to edit and create your own fonts by running fonter, or use some of the standard ones you get:

$ consolechars -f /usr/share/fonter/crakrjak.fnt
$ consolechars -f /usr/share/fonter/elite.fnt
$ consolechars -f iso01.f16

Also nice to know is that you can easily change the mapping of keyboard keys. To see current keyboard mappings, simply run dumpkeys > keymap; editor keymap.

After you tune the keymap file to your needs, load it back with the loadkeys ./keymap command.

To see just how great the console is, run the loadkeys program, and type the following in its prompt:

string F1 = "Hello, World!"
[Ctrl+d]

Then just press the F1 key to see the consequences.

Note that this is not the best you can do with the console, it's just a small collection of quick and useful tricks to show you the direction to look into. If you're interested in more console tricks, take a look at (some of) setterm(1), stty(1), tput(1), tset(1) and possibly tic(1).

System messages and log files

Unix systems have a standard message logging interface, and all programs can freely use it. Besides having the advantage of being unified and easily parseable by the log monitoring programs, syslog messages offer a very convenient way to manually monitor overall system status and learn a lot about the system in general.

There are many actual implementations available but they're all commonly known as syslog daemons (daemon = server). In essence, each message contains the facility (category) and priority (importance) information (along with the message text itself, of course). The facilities (message categories) recognized are auth, authpriv, cron, daemon, ftp, kern, lpr, mail, mark, news, syslog, user, uucp or local0 - local7, and the priorities are debug, info, notice, warning, err, crit, alert or emerg.

Messages can be generated by all the kernel, computer programs or system users. When the message reaches the syslog daemon, it is:

• prepended with date, time and source information,

• matched against the syslog config file rules, and

• distributed accordingly. Common actions include writing messages to log files or named pipes, echoing to all (or selected) users' consoles, or forwarding to another computer.

The default Debian syslog daemon is a variant of the traditional BSD (Berkeley Software Distribution) syslogd and it consists of the sysklogd and klogd packages (where klogd listens for kernel messages).

	On a BSD Note
	"There are two major products that came from Berkeley: LSD and Unix. We don't believe this to be a coincidence."   --Jeremy S. Anderson   Note, however, that this is not technically correct; morons.org say LSD is not a Berkeley product (it's from Sandoz), and J.S.Anderson is an anonymous, but the quote is still widely cited and worth mentioning.

So, following the consistent naming scheme, the sysklogd config file resides in /etc/syslog.conf. If you open it, you'll recognize a simple structure: selectors (facility.severity pairs) associated with actions (output destinations). For the rest of the config file details, see the syslog.conf(5) man page.

For both an educational example and a practical result, we're going to make two simple changes to the syslog configuration file:

• move the ppp (Point-to-Point Protocol) messages to a separate config file, /var/log/ppp.log, and

• make all messages also appear on one of our text consoles (for easy log monitoring).

To accomplish our first goal, simply run echo "local2.* TAB /var/log/ppp.log" >> /etc/syslog.conf (where you replace "TAB" with the actual Tab character by pressing Ctrl+v, Tab). As the pppd logs to facility local2, it'll redirect all messages (regardless of the severity) to a separate file.

For the second part, run echo "*.* TAB /dev/tty12" >> /etc/syslog.conf. That rule will output a copy of every message to your 12th console — /dev/tty12. That console should be empty and unused by other software, but note that technically you can have both a valid login console and syslog messages on the same terminal; the output would just clutter up eventually. To clear it up, you could use Ctrl+l, the standard "clear screen" key combination.

Now, since changes to the config files are generally never automatically detected by the programs that use them, we need to tell the syslog daemon to reload its configuration. We will use the standard /etc/init.d/ interface, which we've talked about already. Simply run sudo /etc/init.d/sysklogd reload or sudo /etc/init.d/sysklogd restart, for the changes to take effect.

Even by observing the logs of a seemingly idle (inactive) system, you'll see there actually are periodic jobs ran by the cron daemon (system scheduler). Besides that, try running any privileged command (something as simple as sudo ls) and switch to your 12th console to see how it gets logged.

If you want to send your own messages to syslog, use the logger program (part of the bsdutils package). Try running logger -i -p user.info -- This is a test message.

If you are planing to use the X graphical interface, switching to the 12th console might not be the most convenient way to monitor system messages; your monitor or an LCD display needs to adjust to new pixel frequency every time you switch console; it takes a second or two to do that and it starts getting annoying after the initial amusement. It is possible to solve that by making the frequencies match, but that's out of the scope of this Guide. Our solution to the problem will consist of running X applications such as root-tail instead, which monitor log files and print messages to your root window (the X background).

To round up the section, we could just mention that all the log files are usually kept under the /var/log/ directory, and all of the messages you watched appear on your 12th console were also saved in one (or even more) of those files. You could figure out the purpose of each log file by seeing /etc/syslog.conf.

Particularly interesting is the /var/log/dmesg file - it keeps a copy of the messages that scrolled by at system boot time. You can also use the dmesg command, but instead of the bootup messages, it will display the last few kilobytes of kernel messages (which might or might not be the same as /var/log/dmesg contents, depending on the activity the system saw in the meantime).

Actually, newer systems also sport the bootlog daemon that takes proper care of saving bootup messages. If bootlog is enabled in the /etc/default/bootlogd file, complete boot log will be saved to /var/log/boot.

Deeper look at the Debian package tools

Earlier in the Guide, we mentioned some of the truly basic package management commands along with their most used options. However, Debian offers much wider range of packaging-related tools.

dpkg, the medium-level package manager for Debian, offers some more low-level functions than apt-get, and roughly corresponds to the rpm command on RPM-based (Red Hat Package Manager) Linux distributions.

Most notably, dpkg does not have any automatic package retrieval methods. To install a package with dpkg (say, package vim), you would first have to download the .deb package yourself and then run something like dpkg -i vim_6.0.093-1.deb. dpkg doesn't even check for dependencies, so in this example, package vim could be unpacked but its configuration would be delayed until you first install all the packages it depends on (which is a boring and uneducated way to install software; use apt-get). dpkg is, however, still indispensable for lower-level management and definitely worth the tour.

dpkg -r vim would remove the package if there are no installed programs that depend on it. Configuration files for the package (those listed as conffiles in the package control files) are left on the system. dpkg --purge vim would remove vim along with configuration. dpkg --configure --pending would configure all pending packages (for example, those that were left waiting for processing after an unsuccessful dpkg run).

Sometimes it's useful to copy the package list from one machine to the other, and get all the same software installed on the other system (or simply keep a list somewhere for future reference). Use dpkg --get-selections > list to retrieve the list, and dpkg --set-selections list; apt-get dselect-upgrade later to load the list and trigger installation.

It's also possible to put packages on hold, meaning you don't want the system to touch them. Use echo vim hold | dpkg --set-selections. To make it available for upgrading again, run echo vim install | dpkg --set-selections.

Sometimes a dpkg action can't be performed because of missing dependencies, duplicate files or something like that. Use the --force-all with dpkg to ignore the problem and continue. This option can be used everywhere with dpkg but it often leads to package database corruption (specifically, version mismatches) and total dependency chaos. If you later plan to use apt-get, never use this option as it instantly breaks apt (you can, however, try apt-get -f install and apt will do its best to clean up the mess).

dpkg-reconfigure can be used to reconfigure debconf-enabled packages (those which use debconf to ask questions and get answers about the local configuration). Use dpkg-reconfigure vim to reconfigure vim. dpkg-reconfigure debconf would reconfigure debconf itself. You can choose between a few types of interactive or non-interactive package configuration modes. Non-interactive mode is very useful if you are performing mass or automated installations.

Tip

Sometimes (due to a bug in a specific package's debconf interface), you won't be able to successfuly configure the package; this is very likely to happen from time to time if you use the Debian unstable tree. Common example would be 'Accept' buttons which don't actually accept any input, or text fields which are (again, by mistake) always considered empty. A possible hack solution for this kind of problem is to reconfigure debconf to non-interactive, then configure the problematic package and finally reconfigure back to some sort of interactive mode. Packages have matured over the years though, and we couldn't remember any relevant occurrences of this problem.

	Tip
	You will most probably be using this command to reconfigure the X Window System every now and then, so just remember this command, which is the elegant Debian-specific way to deal with the configuration: dpkg-reconfigure xserver-xfree86

Sometimes it's also useful to see a recursive dependency listing for a package. This feature is provided by the apt-rdepends package.

To reinstall a package, use either the above dpkg -i or apt-get --reinstall install PACKAGE NAMES. To install the specific version or branch of a package, run apt-get install vim=6.0.093-1 or apt-get install vim/testing.

To upgrade the system, you usually run apt-get update; apt-get upgrade. To upgrade only specific packages, run apt-get install PACKAGE NAMES or debfoster -u PACKAGE NAMES.

grep-dctrl is another tool in the stash. It can answer questions such as "What is the Debian package foo?", "Which version of the Debian package vim is now current?", "Which Debian packages does John Doe maintain?", "Which Debian packages are somehow related to the Scheme programming language?", and "Who maintains the essential packages of a Debian system?". See its manual page for more information.

To remove unnecessary Debian packages (unused libraries left on the system etc.) from your system, run debfoster or deborphan.

dpkg-repack package provides us with a tool to bundle installed packages back into the .deb format. If any changes have been made to the package while it was unpacked (such as files in /etc modified), the new package would, of course, inherit the changes. This utility makes it easy to copy packages from one computer to another, or to recreate packages that are installed on your system, but no longer available elsewhere.

Use dpkg-divert to override a package's version of a specific file. You could use it to override some package's configuration file, or whenever some files (which aren't marked as 'conffiles' in the Debian package) need to be preserved by dpkg when installing a newer version of the package. In addition to (or instead of) dpkg-divert, you can use dpkg-statoverride to override ownership and permissions (and suid bits, of course) of installed files. Using this technique, you could also allow program execution only to a restricted user group.

---

Debian package files format

Even though Debian GNU packages are best manipulated using appropriate Debian package tools, it's quite useful to be introduced to their internal "constitution".

Debian package files (.deb files) need no special tools to be manipulated; they are simple ar archives consisting of two files: data.tar.gz and control.tar.gz. In other words, the generic tools needed to extract .deb contents are ar, tar and gzip, and are all present on just about every Unix system.

To extract package data, run dpkg -x package.deb /tmp/PACKAGE. To extract package control section, run dpkg -e package.deb.

If you have no dpkg at your disposal, you can extract the data section using ar to extract the data tarball, and tar/gzip to unpack it: ar x package.deb data.tar.gz; tar zxf data.tar.gz. The same way, you can extract the control.tar.gz section.

Please Note:

You might need to use the above procedure in practice if, while upgrading gnu libc package, you do something silly and end up in half-installed state with no /sbin/ldconfig command (so all of the "heavier" programs start refusing to run). If that's why you are reading this, then one solution is to unpack the libc6 package manually and copy the ldconfig command back in place (to /sbin/). The other (and easier) thing you can do is temporarily create an empty /sbin/ldconfig file which would simply return success: # echo "#!/bin/sh" > /sbin/ldconfig # chmod 755 /sbin/ldconfig This way, however, you need to add --force-overwrite switch when you go reinstalling libc, such as dpkg -i --force-overwrite libc6*.deb.

Useful extra packages

Two useful programs worth mentioning are vrms and popularity-contest. vrms notifies you of non-free packages installed on your system (ideally, there should be none!). popularity-contest produces weekly package usage statistics (frequency of use, etc.) and anonymously e-mails them to Debian, thus automating part of the feedback from the user base. The statistics are, for example, used to decide on the distribution of Debian GNU packages on CD-Roms.

Monitoring installed files for correctness

Each Debian package inserts control information into the package database (/var/lib/dpkg/ directory). One of the values are MD5 sums of all installed files (File "sums", "MAC"s or "digests" are results of a one-way function — MD5 in our case — and uniquely identify file contents). When the file digest is compared to a previous good value from the database, we can immediately notice if the file contents (and contents alone, not other attributes like mode or ownership) have been changed, either as a consequence of legal system operation, software/hardware bug, or a successful break-in).

For packages that do not have MD5 sums already generated (there are few cases), the sums can be generated directly at your site, during installation. (Debconf will present you with an appropriate question when you install debsums.)

Most common use is to run debsums PACKAGE to verify individual package, or debsums -s to verify all packages and only display checksum mismatches. See debsums man page for more information on available options and possible use.

If you wish to change a file's checksum, you no longer need to develop your own tools to edit /var/lib/dpkg/info/PACKAGE.md5sums files, newer debsums packages ship with the debsums_gen command.

Shutting down the system

Recall that we have mentioned and briefly explained runlevels above. In Unix, system halt (shutdown) is simply runlevel 0, system reboot is runlevel 6.

To shut down the machine, any of shutdown -h now, halt, poweroff or init 0 will do. To reboot the system, shutdown -r now, reboot or init 6 are okay. Additionally, you can also use Ctrl+Alt+Del (in the console) to reboot, and this behavior is controlled by the /etc/inittab file (run init q to reload the file if you change it). Sometimes you want to cancel the ongoing shutdown; you can do it as long as your console is active. In that case, run shutdown -c or say, init 2.

Introduction

First of all, it's important to know that there are many computer architectures available. Most of them have a cleaner design and stronger characteristics than the nowadays-standard Intel-compatible Personal Computer, and a number of them were in existence before the PC was "invented".

This list of other general-purpose architectures (besides the Intel-compatible) would include Motorola 68000 (m68k), Sun Microsystems Sparc (sparc), Digital Equipment Alpha (alpha), Motorola/IBM PowerPC (ppc or powerpc), Silicon Graphics/DEC MIPS (mips and mipsel), Intel IA-64 (ia64) and AMD 64 (amd64). This list is by no means complete, it's only a random selection of architectures already supported by Debian GNU.

So, given different architectures which are not binary-compatible (that is, where programs are not compatible across architecture bounds), how do you get the same software running on all of them? We are, of course, interested in re-using existing applications — those that have a tradition, more features, and more hours in production than anything we would be able to create ourselves. The key to the problem is namely porting; changing existing code base in a way that it makes provisions for the new target platform (at places where any specific handling is necessary). Given proper education, writing portable software is easy; porting ("behaving" existing software), however, can be a source of great despair — sometimes you first have to deal with unacceptably poor programming practices and missed design, before you even come to portability issues.

Let's see what would you have to do if you had a completely usable but new architecture, for which no high-level kernels and application programs were developed yet. (We can't take the PC architecture for a typical porting example because that special case would include time-travel and hardware in form of shotguns.)

The first step in getting software run on our hypothetic architecture would come down to porting an existing Operating System kernel (first piece implemented in software and not hardware), so that the kernel is able to recognize basic system components and initialize hardware-dependent subsystems. When we'd get that done, we'd have to write kernel drivers to support additional hardware, such as network, audio and graphic cards, or your custom boards. Modern kernels support Loadable Kernel Modules (LKMs) which you can load into the kernel at runtime, so this task would not be as pressing as if you had to put everything in a single kernel image — but nevertheless, the system is not very usable without it.

Once we'd get the above done, we'd have to get the build-chain (development tools) supported for a platform, or we wouldn't be able to get any user applications running. (In reality, this step would probably be more to the top of the list.) And once we'd have all that done, there would still be more work waiting for individual software programs. We'd have to try compiling them (converting to a binary, machine-runnable form) on new hardware. Depending on how much portability issues the original authors addressed themselves, this could be an easy, difficult or impossible task. Sometimes doing a complete rewrite (and avoding other design mistakes the original authors made) is easier than insisting on code base that was written by poor programmers, or at time when no standardized portability techniques were widespread.

To sum up, there's much more to programming that just the physical position of sitting in front of a computer and punching letters. (Even though we all probably know a person or two who seem to be using their existence to prove the contrary).

When you get to understand the basics of computer hardware, Unix will start looking like the only reasonable and natural extension to hardware, and its concepts and design elements will be easy to understand.

Operating system kernels

As we've mentioned in the Introduction, a basic software element of an usable, general purpose computer is the kernel. Among the most widely known free kernels today is Linux, made by Linus Torvaldsen and first released in 1991. Linux is an extraordinary thing in a true meaning of the word; you can find Linus' USENET post from October 5, 1991 in the Google Groups' 20 Year Usenet Timeline. Another excellent site, ComputerHope, maintains a record of Linus saying "Hello everybody out there using minix - I'm doing a (free) operating system (just a hobby, won't be big and professional like gnu) for 386(486) AT clones."

Nowadays, many (or all) Free Software bundles sold by various companies are commonly called Linux distributions. As the name implies, of course, they contain the Linux kernel, but that is only a tiny piece of the complete bundle. In addition to the kernel, bundles contain loads of Free Software packages which have been ported and compiled for your platform, and have been pre-configured to work nicely with other packages from the "bundle".

A variety and freedom of choice always existed in the Free Software applications arena. For example, if there were 10 usable (not even popular, just usable) music player or web server programs in existence, chances are you'd find all of them already packaged and waiting for installation in your Debian package archive (and probably in majority of the Linux distributions as well). Kernels, however, have a completely different story. Today, Linux is by far the most popular Free Software kernel. Other kernels (such as FreeBSD or NetBSD) are getting up to speed, but they have a life of their own and are based on a different license, not GNU GPL.

Now you can understand why the authoritative people insist on calling distributions GNU/Linux instead of just Linux. "Linux" identifies the kernel flavour (since now you know there are many, not just Linux), and "GNU" identifies the so-called userland (collection of user and system software, mostly the parts crucial for any Unix to be usable). Kernel is only a tiny part, what you actually "feel" when you use the system is the "spirit" of the userland - behavior of basic commands and tools. Omitting "GNU" from the name is ignorant behavior; GNU/Linux should be called GNU/Linux, at least in writing.

I hope you will understand that most of the things you'll appreciate in "Linux" will actually be standard and decades old Unix features that have nothing to do with the Linux kernel itself.

Now, fitting the section title and this introduction together, we can reach the expected conclusion — since Debian is aiming to be an universal Operating System, it offers the choice of kernels!

Yes, that's right! Besides the most widely known Debian GNU/Linux, there are also FreeBSD, NetBSD and The Hurd available. The Hurd (visit The Hurd Wiki) microkernel itself is still in development and not ready for use in production, but NetBSD and FreeBSD are mature kernels, and the usability of their Debian ports should increase rapidly. (Currently the main issue with *BSD kernels and Debian is getting the kernels play along with GNU userland instead of the expected BSD). Just for the record, Linux 2.6 kernel series seems to outperform the rival cavalry on just about every test performed (at least according to Gregory McGarry and Felix von Leitner), but the BSD people are coming up with no-less smarter ideas and valuable features.

In practice, this means that you'll be able to choose any hardware platform (machine type and architecture) and any of the supported kernels that best match your exact needs, while from the user perspective it will always be Debian with no visible and incompatible differences!

Kernel drivers

Free Software kernels come with all supported drivers already included in the kernel source packages. Loading or unloading a driver for any piece of hardware is an instant, one-command action.

Free Software drivers are often better than their proprietary counterparts (paradoxically, since the proprietary drivers were made by the hardware manufacturers themselves). The only notable exceptions to this rule happen when the manufacturers keep their hardware internals secret and don't publish openly accessible specifications, so the technical people can't easily find their way with the piece of hardware (but this is easy to deal with — don't buy such products and you will directly communicate the message to the manufacturers, in the only language that they understand without thinking twice).

So in general, when the hardware is supported, the whole process of integrating it into your system consists of loading appropriate kernel or user-space drivers, performing any necessary configuration tasks, and making sure the hardware configures itself automatically on each system boot.

To save you the trouble, we will present an introduction to the general hardware identification techniques, then provide a series of sections describing different kinds of hardware and giving actual instructions how to properly integrate them in your system.

Note that this chapter will be losing on importance, as new Debian installers perform the autodetection well, and nowadays there are generally no manual steps required to set up drivers on commodity hardware.

We are going to provide the general techniques for identifying system hardware here, because you'll use them in all of the following hardware sections.

In general, to identify system hardware, you run less /var/log/dmesg. That will display most general and low-level information, such as system and processor type, available memory, attached hard disks, etc. This is all pretty nice, but does not help you in identifying unknown hardware because those lines are written only after the appropriate drivers are loaded (and if that was the case, you wouldn't be trying to identify those devices).

Since (as we just said above) the basic components such as mainboards, processors and hard disks are recognized without special setup on your part, you'll be interested in identifying the rest of the hardware — that would mostly be "attachable" devices such as PCI and AGP cards, serial or parallel adapters and USB gadgets. To do so, run lspci (pciutils package) and lsusb (usbutils package).

Note that the ID strings returned by above utilities will be your starting point in finding out the name (or names) of the drivers that support your specific devices. Free software drivers usually target chipsets instead of each device model of each vendor separately. For example, many old ISA network cards (from different manufacturers) worked with the ne2000 driver. Nowadays, most network cards work using drivers 8139too, 8139cp, via-rhine or e100. That said, most of the time you will not be interested in searching for the exact identification strings as reported by lspci or lsusb, but only look at them for clues about chipset names (and those can also be easily read from the chip labels, if you can take the cards out of the computer and look at them).

Driver name identification techniques

So when you find some hardware ID strings, you'll want to search for the appropriate driver names. There are few approaches to this; you can run sudo modconf and try to locate your ID string in the list. If you find the device in the list, press Enter and try to load the driver module (you almost can't make a mistake at this step — if you pick a wrong module, it simply won't load successfully and you'll be able to try a different one). If you find the right one using modconf, the tool will do all the necessary steps by itself and you'll have the hardware configured.

Just, don't feel lucky if you manage to load the dummy module. The whole purpose of that module is to only pretend as if the device was there, so obviously it won't do you much good in practice.

If you don't get lucky with modconf, simply open your Web browser application and look up your identification string (say, "Realtek Semiconductor RTL-8139") on http://www.google.com/linux. In the results returned, you should learn the name of the driver to support the specific hardware. The ID string I used in this example belongs to a network card, and directly the first result returned by Google would tell you the appropriate NIC (network card) driver name is 8139too.

Finally, since the drivers are kept on your hard disk as normal files, the third way to learn the correct driver name includes visiting the modules directory and doing some manual file snoop & search operation there. To enter the correct directory, simply run cd /lib/modules/`uname -r`/. Once there, try using cd, ls and find commands to get some results. Again, using the above "Realtek Semiconductor RTL-8139" for example, running find . -iname '*8139*' in the modules directory should give you a hint right away.

Note on drivers loading automatically on each boot

If you load the driver using sudo modconf, then modconf will also take care of adding the driver name to /etc/modules file. In effect, this would make the driver load on each machine boot. If you don't succeed with modconf, then after finding out the driver name, you'll have to load it manually using sudo modprobe DRIVER_NAME. You'll also want to add the driver name to /etc/modules to make it load on every boot; you can do that by running echo DRIVER_NAME | sudo tee /etc/modules.

Ok, those few simple hints are enough that we can move on to practical hardware setup scenarios.

Common hardware setup and performance; guidelines and practical examples

$ lspci | grep Ethernet
00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139 (rev 10)
00:12.0 Ethernet controller: VIA Technologies, Inc. Ethernet Controller (rev 74)

$ lspci | grep Ethernet
0000:00:0f.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
0000:00:12.0 Ethernet controller: VIA Technologies, Inc. VT6102 [Rhine-II] (rev 74)