Hands-on Guide to the Debian GNU / Ubuntu / Devuan GNU+Linux Operating Systems

The latest copy of this Guide can be found at . This article is part of &SL;'s practical 4-piece introductory series containing the &DKLAR-DEB;, &DKLAR-KRB;, &DKLAR-LDA; and &DKLAR-AFS;. Preface</> <mediaobject> <imageobject><imagedata fileref="images/audience.eps" format="EPS" depth="120px" scalefit="1"></> <imageobject><imagedata fileref="images/audience.eps.jpg" format="JPG" depth="120px" scalefit="1" ></> </> <para> Welcome. The following Guide should help you make the first steps with &DEB;, a Unix-like operating system. </para><para> If you encounter any unexpected problems, have patience and persistence. Unix is a colorful collection of more than 50 years of professional research and development applied to computer hardware and software, and there is a certain learning curve involved. </para><para> You need to learn the basics of Unix architectures and operating systems properly before tackling more advanced topics. </para><para> GNU/Linux has been progressing with an ever-increasing pace over the years, both technically and in widespread adoption, and it is easier than ever to download, install and start using a Linux-based operating system. Many underlying technologies have been successfully wrapped into graphical control panels, obscuring the technical workings of the system. Our goal here is to show you the technical aspects of the system and give you a level of understanding that goes far beyond graphical screens and management interfaces. </para><para> The Linux kernel and almost all other software are free ("free" as in freedom). This has allowed many projects and companies to package the Linux kernel and tens of thousands of applications in easily-installable and functional wholes called "distributions". Our distribution of choice will be Debian GNU/Linux. </para><para> Of all Linux distributions, why exactly Debian GNU? The system and community organization in &DEB; outperform all competition by a wide margin. There <emphasis>are</emphasis> some Linux distributions, Unix operating systems (such as Sun <ulink url="https://www.oracle.com/solaris">Solaris</ulink> or <ulink url="http://www.qnx.com/">QNX</ulink>) and kernels that do some <emphasis>specific</emphasis> tasks better, but &DEB; is a general-purpose winner. </para><para> (In addition to &DEB;, there are also two Debian derivatives available — &UBU; and &DEV;. &UBU; is a more desktop- or enterprise-oriented distribution, while &DEV; is a fork of &DEB; without systemd.) </para><para> Also, we see that all interesting and exciting new developments are happening in the GNU/Linux arena; just focusing on Linux and the popular technologies (i.e. the LAMP -- Linux, Apache or nginx, MySQL or PostgreSQL, and Ruby on Rails or Groovy Grails or Crystal Amber, and Git) may turn out your cool steady job and source of income. </para> <para> You should read this Guide <emphasis/after/ you successfully install some variant of the Debian GNU system to your computer (with or without the help from the &LNK18;). </> <para> The Guide is a balanced mix bewteen the administrator's and the user's guide; it is probably too broad for those who belong to either of the two extreme categories. The approach used should fit home users best — people who do have a Debian installation at hand, and want to learn and experiment. </> <para> Our end goal is that you develop the mindset to solve further problems on your own; the basic understanding and general logic matter, not the exact implementation or usage details. In most general terms, we could say we'll try to explain the principles of Unix system design, and how they work in practice using command line and text processing utilities; we will not bother describing point-and-click GUIs and menus; such documentation is available elsewhere (on say, <ulink url="http://www.gnome.org">Gnome</>, <ulink url="http://www.xfce.org">XFCE</ulink>, <ulink url="http://www.opengroup.org/cde/">CDE</ulink> or <ulink url="http://www.kde.org">KDE</> websites). </> <para> In a Debian guide, we will not hesitate to use Debian-specific features and commands, but note that most of our discussion will, at least generally, apply to other Linux or Unix systems as well. Additionally, by saying this is a beginner's guide, we definitely won't restrict ourselves to system basics; this Guide is hiding many details even experienced users would find useful or amusing. </> <para> Please read the following two sections (<xref linkend='conventions'> and <xref linkend="prereq">) carefully, as they explain some basic ideas and assumptions followed throughout the Guide. </>  <section id="conventions"> <title>Conventions Application names are specified in "command mode (such as " style, such as . In practice, this means you can write All file and directory names are given in "/etc/syslog.conf, ~/.bash_profile, or /etc/init.d/). Although not mandated by system behavior, we consistently include "/" at the end of every directory name to make directories clearly distinguishable from regular files. Also, this notation helps eliminate ambiguity in commands that accept both a filename and a directory name as an argument. Symbols that need to be replaced with your specific value use the kill -9 , "PID" should be substituted with an appropriate value. User session examples (consisting of user input and the corresponding system output) use the "screen" mode. User input is visually prefixed with "$" for user, and "#" for administrator commands. Program output is edited for brevity and has no prefix. Unix, GNU, Debian, and Linux are words that can sometimes, depending on a context, be used interchangeably. Throughout the Guide, we will be consistent and, on each occasion, use the word with the broadest scope. For instance, we would talk about the Unix command line, GNU development tools, the Debian infrastructure, and Linux process management. When a concrete system username will be needed to illustrate an example, user1 will play the role of an innocent user. You'll notice that the Guide contains many links to external resources. This can make you unhappy if you find a lot of them interesting and get distracted from this Guide. Therefore: We will always include the minimum of text, the part that is crucial to understanding the subject, directly in the Guide. External links will only provide more detailed information. As a result, it will be possible to read the Guide without following any external links. We will group all links appearing in the Guide in a separate appendix at the end of the Guide, along with descriptions. That will allow you to focus on the Guide exclusively, and think about additional resources later.

Pre-requisites To make sure you can successfully follow this guide, there are few key points we need to agree upon. Let's assume that you: installed Debian from dd if=netinst.iso of=/dev/YOUR_USB. have the network properly configured. This is important if you have a decent Internet link and want to install software directly from the Debian repositories on the Internet or your local LAN. You are given the chance to configure the network and remote software repositories during the installation. These settings then carry over to the installed system have just the base system installed (around 150 megabytes in total). To get a system like this, don't run start working with the system by logging in to the superuser account (your login name is

Overview

in memoriam, John Lions (University of New South Wales) "On our campus the UNIX system has proved to be not only an effective software tool, but an agent of technical and social change within the University."

Debian GNU software distribution &FS; distributions such as &DEB; are comprised of a large number of &FS; programs. That's why, when you pick &DEB;, you get not only a basic operating system, but a complete environment with much more than 50,000 precompiled, prepackaged and For you, the

Advanced Package Tool Most computer environments recognize the concept of Debian specifically has developed a

Configuring APT There's very little you need to do to configure your Debian package management system, but it's a critical step and you need to get it right. repository locations are defined in the file /etc/apt/sources.list and directory /etc/apt/sources.list.d/ if you have any Debian GNU CD/DVD Roms, run the complete contents of /etc/apt/sources.list could look like the following (give or take minor variations between Debian/Devuan/Ubuntu): /etc/apt/sources.list deb http://ftp. run Having configured In recent versions of Debian, you can also use

First steps around the system

Andy Bates in comp.os.linux.misc, on "intuitive interfaces", slightly defending Macs "Now I know someone out there is going to claim, 'Well then, UNIX is intuitive, because you only need to learn 5000 commands, and then everything else follows from that! Har har har!'"

Base Debian GNU installation If you have tried any of the other Linux distributions such as Ubuntu, Red Hat, Mandrake, or SuSE, you will notice that unlike them, Debian will allow you to install only the base/minimal system without any graphics (without the X Window System) and without a desktop (although the "d-i" installer will perform all hardware auto-detection for you). With &DEB; and the basic installation without an X window system, you will get a small base system with the black console and a Login: prompt on the top left. We'll move from there on. (In case you are already using a system with X Window System installed, you can press

Shell and filesystem When you log in to the system (authenticate typically with your user name and password at the shell programs. In general, shell programs serve as agents between the user and the system (accept commands, return output) and are all, in fact, more or less sophisticated programming languages. Computer software is based on files. Files live in directories (folders), which are located on virtual or physical, local or network disk partitions. In Unix, every system has a /) and serves as an entry point to the filesystem. For example, /home/user1/.profile (called .profile which resides in the directory /home/user1/. In this example, user1/ 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" for the purpose of reducing "noise" in the output. Each file in Unix belongs to one user and one user group. Additionally, there are file modes (or /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 the POSIX Access Control Lists or Role-based Access Control solutions. ACLs allow files and directories 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. However, the traditional concept that doesn't use ACLs or RBAC is still the default and offers quite surprising flexibility, rarely causing one to need to use more sophisticated permissions models. Concerning the filesystem "navigation", there's a concept of In addition, with Unix, you generally don't need to invent the directory locations for the system software you want to install. When you install software, it is automatically installed to predetermined locations. 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 /lib/, /usr/lib/, /usr/local/lib/ - shared libraries needed to support the applications /sbin/, /usr/sbin/, /usr/local/sbin/ - directories with executables that require increased permissions and are generally supposed to be run by the Superuser /tmp/, /var/tmp/ - temporary directories. Watch out here because /tmp/ is, by default, cleaned on each reboot /usr/share/doc/, /usr/share/man/ - complete system documentation /dev/ - system device files. In Unix, almost all hardware devices are represented as files somewhere under /dev/ /proc/ and /sys/- "virtual" directories which don't really exist on disk. They display state directly from the kernel and can be used to get or set Linux kernel settings Why software is installed to pre-determined locations is easy to explain: Unix and Unix filesystems allow every directory and subdirectory to be mounted to an arbitrary place — 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, &LNK3;, or In the above list of directories, you might have noticed a pattern. For example, there's bin/ directory in all of /, /usr/ and /usr/local/. Directories and files found in the root directory (/) are official distribution files and are required for the system to boot up. 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. Note, though, that 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/ later to add additional "user" software and applications. This division is, for historical reasons, still in use today, even though it has no practical use and it has not been possible to boot a regular Linux system without /usr/ for a number of years now. (Also, some even claim that it was never really in the spirit of GNU/Linux distributions to do so.) 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". (In recent times also a directory named /opt/ has been a common location for 3rd party packages to put their files in. The structure inside of it does not follow standard Unix rules, however, and is basically organized just as /opt/PROGNAME-VERSION/ with arbitrary structure beneath it.)) And there's also the share/ directory that you can see in the mentioned directories; it contains files which are hardware platform-independent and are the same on all supported architectures.

Manipulating software packages Now, recall To see what exactly is each of the programs used for, you could run apt-cache show . 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 (to exit the "pager" program apt-cache, Shift+PageUP/DOWN, less). For a list of all installed packages, run dpkg -L , such as dpkg -S , such as dpkg -S /bin/bash. To remove a package, run apt-get --purge remove . The Nowadays, there is also the base command 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 , such as Let's now make use of those programs we installed a moment ago.

Administrative account wrapper Run command always use a regular system account, and only execute specific privileged commands by using Create a non-privileged account now by running the adduser user1 command. Add it to the sudo group by running /etc/sudoers, is configured to grant admin privileges to this group's members. Alternatively, you can run echo "user1 ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers to grant admin privileges to specific user "user1". The same effect of this oneliner can also, be achieved by opening the file in a text editor, adding the line, and saving it. As a performance optimization, the Linux kernel does not re-read the list of user's groups until that user completely logs out of the system and logs in anew. If running the command Ctrl+d in all active terminals. Alternatively, you can run newgrp sudo; newgrp YOUR_GROUP. This will force the kernel to give you a shell with the group 'sudo' listed in your additional groups. To see the sudo and you will not log-in as the superuser any more. We will use sudo nano /etc/.

Unix text editors Most of Unix system configuration is kept in plain text files, so you will definitely want to pick your favourite nano now to see its simplicity for yourself. (Keep in mind that the "^" character, needed to access nano's menus, represents the Control 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. Since 2014 there has also been If you have no idea which editor to use, try using nano. Then, once later, you might get around to installing 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 (sudo nano /etc/).

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 &DEB; installation any more, we'll take a tour of system file and directory manipulation commands. (This section has turned into an action-packed bunch; let's get into the right mindset and let's roll!) To change directory, use the command echo $PWD. Try and see where each of the commands cd, cd /etc, cd .., cd ../.., and The special tilde character (cd, cd ~, cd $HOME, and cd /home/user1 would do the same thing. In addition, if user1 wanted to reach user2's home directory, he would only have to type cd ~user2. (This ability to reach user's home directory using a syntax independent of actual system setup is another winning concept in Unix). The dash($OLDPWD environment variable reposition 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 -al /etc, or ls -al / (-a is needed to make — 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 nano . Alternatively, you could use a variant of the command which is not dependent of the current working directory — nano ~/ for example. Try removing (deleting) the created files with 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 ls -al / | grep bin. The output of the ls -al / command will be piping (a special case of redirection where output is redirected to a program) is denoted by the |") 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) it first. Try say, ls -al / > /tmp/dirlisting. Note that some interesting variants are possible with this that are equal in effect, such as putting the redirection at the begnning of the line, i.e. > /tmp/dirlisting ls -al. Important thing to say is that each process started usually starts with three data streams open; they're called the standard input, standard output and standard error, identified by system "file descriptor" numbers 1, 2 and 3 respectively. This is where the ">" redirects and "|" pipes come to play — they influence those descriptors. For example, ls -al / > /tmp/dirlisting (or "1>" instead of just ">") redirects standard output from the screen into a named file; ls -al 2> /tmp/errors redirects any error output to a different file; ls -al / | grep bin redirects standard input into "grep" from a keyboard to the output of the previous command. In addition, you can of course mix these, such as ls -al / | grep bin > /tmp/stdout 2> /tmp/stderr, and, depending on the shell you use, you can use ">&" or "&>" to redirect all output (stdout and stderr) at once. In a typical, non-redirected session, the location for all three channels is /dev/tty, a "magical" file that always corresponds to your current console or terminal. 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 Some other times, you need to create an empty file. For example, try touch , > or >> . The difference is that, if the file already existed, 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 Ctrl+d on an empty line. As we've said earlier, When you type say, /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 Check system memory information with Additional and interesting programs related to system and memory status that you could install are To see a list of Note that /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 Use Ctrl+c, the generic "break" signal). Run 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 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. Let's cover some more stuff. One of them is the shell history. The commands you type, provided that they do not start with a space, are saved in shell history. The history can be viewed with Pressing There's another cool trick allowing you to correct previous line (that is, replace "- " with " -"). For example, if you typed The shell history of executed commands is saved to a history file (usually ~/.bash_history) when the shell program cleanly exits, and is thus preserved between sessions. To prevent history from being written, you can terminate the shell forcibly with Shells also support a nice model called "aliases". You can alias any text to a shorter form, and you can then access the alias, the unaliased command (in case of the same name) and append extra arguments. Here's how: you define an alias with a syntax You can see the list of defined aliases by simply typing ~/.bash_profile for the Bash shell. Note that aliases are not the only way of packing multiple or long commands in an easily-accessible shorter form — you can do the same (and more) with shell script files, in which you type commands exactly as if you were executing them on the command line. Your ~/bin/ directory is the right place for this, as the programs copied there will be automatically searched by the shell when you log in (see ~/.bash_history for how it happens). Shells also support the function called "backticks", invoked with the `` quotes. Text within backticks is executed as a separate command first, and its output is inserted in the original command, which is then executed. For example, to display current date, you can simply run Another thing to mention is searching for files and executing commands on them. Let's say you wanted to search for all MP3 files in your home directory. You'd do this with cd; find . -name '*.mp3'. The first argument to "mv `find -name '*.mp3'` /some/directory. However, most MP3 files have spaces and various non-standard characters in their names, so this command would crash and burn. Besides just not working (because it would treat "abc def" as two files, "abc" and "def"), a specially crafted filename could cause wreak and havoc. For example, part of the MP3 filename " -f " would actually be understood as the --force argument to "mv". So the first line of defense is to use "--" after "mv", which instructs the command that everything that follows is just the list of filenames, not command options. But the problem of spaces and special characters in the filename would still bite us, because the shell has a variable called "IFS" which treats spaces and newlines as separators. So to eliminate the whole issue, the proper and superior way to do this, one that is not vulnerable to file names or anything else is as follows: find -iname '*mp3' -print0 | xargs -0 mv -t /some/directory. The "-print0" option to "find" will use "\0" (the null character) as record separator; option "-0" to xargs will make xargs understand that, and xargs will then run the specified command with found filenames as arguments. Xargs would append all filenames at the end of the specified command, even honoring maximum line lengths (so you avoid the "Argument list too long" errors). If the command you're invoking does not support multiple filenames, or you want to run it on a file by file basis, pass "-n 1" option to xargs. Finally, if the filename is supposed to be inserted in the middle of the xargs command line (and not automatically at the end), use "{}" to mark the point of insertion. OK, fine. Unix programs come in many variants, and with many options (as you have been demonstrated in this section ;-). They usually have a large set of supported options and successfully interact with each other, effectively multiplying their feature lists. I've read somewhere an interesting thought — that a 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, and it is implicitly assumed you should look up their documentation (

System documentation and reference &DEB; 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 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 In Debian, each package you install creates a /usr/share/doc/PACKAGE/ directory and places at least the package. The other, very often used, part of the documentation are the system To get a feeling of [] — 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 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 If you feel you need to ask the community a question, you can either use the various IRC is your best bet to go over "runtime" issues (although on some IRC channels, there are now bots that collect logs and publish them online, and thus having the same problem as mailing lists). Install the /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 /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 &LNK5; to increase your chances of recieving useful answers.

Basic system administration tasks

Plato, 427-347 BC "The learning and knowledge that we have, is, at the most, but little compared with that of which we are ignorant."

Booting the machine; runlevels and system services The process of 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 the bootloaders are configured not to show the boot prompt. To make it appear, hold the Alt, Ctrl or Shift (depending on the bootloader!) key at the 'LILO' or 'GRUB' message (during boot, just before it continues with the 'Loading linux ....'), 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 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 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 Please note that this section describes the SysV init, and not systemd. As such, it is accurate for Devuan GNU+Linux and old Debian and Ubuntu releases, but not for newer Debian and Ubuntu versions which use systemd. 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. /etc/rcS.d/ directory — 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). &DEB; uses so called SysV (System V, read as "system five") 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). /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 &DEB; 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 &DEB; Policy) and can, of course, be run manually - you don't have to wait for /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, before switching to systemd, Debian used to support a number of different init mechanisms. At some later point, if interested you might take a look at file-rc, runit, upstart, or s6. 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 &FS; distributions ship with predefined 'virtual terminals' - completely separate text screens or consoles which are available with (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 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 We did not cover any of the X Window System (Unix graphical interface) stuff yet, but just remember that you'll need to use 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 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 /usr/share/consolefonts/ directory. The other way is to pass "vga=ask" at the GRUB boot prompt (or using 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, In case of GRUB, you would do this by editing the commented "kopt=" line in /boot/grub/menu.lst and running 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 &LNK0; page for the full list. There's also fbset command available (from the 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 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 After you tune 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) , , , and possibly .

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 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 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 used to be a variant of the traditional BSD (Berkeley Software Distribution) called On a BSD Note

Jeremy S. Anderson "There are two major products that came from Berkeley: LSD and Unix. We don't believe this to be a coincidence."

Note, however, that this is not technically correct; &LNK1; 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 /etc/rsyslog.conf. If you open it, you'll recognize a simple structure: rsyslog.conf5 man page. For both an educational example and a practical result, we're going to make two simple changes to the move the /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 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 Now, since changes to the config files are generally never automatically detected by the programs that use them, /etc/init.d/ interface, which we've talked about already. Simply run sudo invoke-rc.d rsyslog reload or sudo invoke-rc.d rsyslog restart, for the changes to take effect. (Using /etc/init.d/rsyslog reload directly as it does not depend on a particular init scheme). Even by observing the logs of a seemingly If you want to send your own messages to syslog, use the . 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 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 /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. medium-level package manager for Debian, offers some more low-level functions than Most notably, dpkg does not have any automatic package retrieval methods. To install a package with dpkg (say, package 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. 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 list/ to retrieve the list, and It's also possible to put packages on hold, meaning you don't want the system to touch them. Use Sometimes a --force-all with apt will do its best to clean up the mess). 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 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-xorg 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 install vim/testing. To upgrade the system, you usually run To remove unnecessary Debian packages (unused libraries left on the system etc.) from your system, run 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 &DEB; 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 data.tar.gz and control.tar.gz. In other words, the generic tools needed to extract .deb contents are 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 x . 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 /sbin/). The other (and easier) thing you can do is /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

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 Most common use is to run debsums to verify individual package, or debsums -s to verify all packages and only display checksum mismatches. See If you wish to change a file's checksum, you no longer need to develop your own tools to edit /var/lib/dpkg/info/ files, newer Also, two programs worth mentioning are /etc directory under revision control. To install and initialize it, run sudo aptitude install etckeeper; etckeeper init; cd /etc && git commit -am Initial. After that, you can see pending changes in /etc by cd-ing into it and running git checkout .

Shutting down the system Recall that we have mentioned and briefly explained To shut down the machine, any of 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 /etc/inittab file (run shutdown -c or say,

Interaction with system hardware

Daniel Pead "In the UNIX world, people tend to interpret `non-technical user' as meaning someone who's only ever written one device driver."

Introduction There are many computer architectures available. Most of them have a cleaner design and stronger characteristics than the On a side note, as the quote from the "Autodesk file" by John Walker in the 80s, about the PC predecessor would say:

Coming to Terms with the 8086 It's become clear that the plague called the 8086 architecture has sufficiently entrenched itself that it's not going to go away. For the last month or more, Mike Riddle, John Walker, Keith Marcelius, and Greg Lutz have been bashing their collective heads against it. The following is collected information on this unfortunate machine. I think we'd be wise to diffuse our 8086 knowledge among as many people as possible. The main reference for the 8086 is a book called, imaginatively enough, The 8086 Book published by Osborne. This is the architecture and instruction set reference, but does not give sufficient information to write assembly code (of which, more later). However, it is the starting point to understand the machine. AI will reimburse the cost of your buying this book, which is available at computer and electronic stores. I have never encountered a machine so hard to understand, one where the most basic decisions in designing a program are made so unnecessarily difficult, where the memory architecture seems deliberately designed to obstruct the programmer, where the instruction set seems contrived to induce the maximum confusion, and where the assembler is so bizarre and baroque that once you've decided what bits you want in memory you can't figure out how to get the assembler to put them there.

This list of other general-purpose architectures (besides the Intel-compatible) would include Motorola 68000 ( Nowadays, if you want to use high-end non-PC architectures, your best bet are IBM Power9 workstations available from Raptor Computing, and known as architecture "ppc64le". So, given different architectures which are not binary-compatible (that is, where programs are not compatible across The key to the problem is namely 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 The basic software element of a usable, general purpose computer is the kernel. Among the most widely known free kernels today is 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 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 Now you can understand why the authoritative people insist on calling distributions GNU/Linux instead of just I hope 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 &LNK10;, &LNK10-1; and &LNK11-1; available. &LNK11-1; (visit &LNK11;) 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 The situation today looks MUCH better than it looked 8 years ago when I first wrote this. Today Linux works on just about everything, it supports accelerated graphics and DRI (Direct Rendering Infrastructure) on all major graphics cards (nVidia and AMD/ATI), and the drivers for those cards come from the manufacturers. Not all of them are completely open about it, though, but shiny examples include companies Atheros (network cards) and ATI (after takeover by AMD) who directly talk to the Free Software developers and have opened their specifications and drivers. And good times are yet ahead! (On a side note, for a completely open graphics card design and drivers, although not usable for 3D yet, see OpenGraphics.) 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 Hardware identification techniques (As mentioned, this section is losing on practical relevance as almost all hardware is nowadays auto-detected, auto-configured and everything else auto- that you can imagine. But it's still how things work, so it's a great source of knowledge that would today be considered "old school"). 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 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 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

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 Just, don't feel lucky if you manage to load the If you don't get lucky with 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 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 cd /lib/modules/`uname -r`/. Once there, try using Note on drivers loading automatically on each boot If you load the driver using /etc/modules file. In effect, this would make the driver load on each machine boot. If you don't succeed with sudo modprobe . 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 . On systems of today, we have a mechanism called "udev" which is configured by files in /etc/udev/. For example, once the network cards are (auto)detected, their names become persistent since udev updates file /etc/udev/rules.d/70-persistent-net.rules. So that's the place to look for if you want to force or change your network card name assignments. Find more introductory information about "udev" in /usr/share/doc/udev/README.Debian.gz. 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

Network Interfaces (LAN) The machine picked for this example had two PCI network cards. Let's see how we could detect and recognize both. We will use the $ 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) Or a similar system might show: $ 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) Today, popular low-cost PC network cards probably use one of modprobe for all of those driver module names above and we'd actually get lucky, but let's be some more clever than that; let's show how we could be successful using the identification tips we gave in the previous section. If we fired up kernel/drivers/net section, we'd find both " If we opened the Web browser and searched for the identification string "http://www.google.com/linux, the first result would hint And if we did cd /lib/modules/`uname -r`/ and It's important to know that, unlike most things in Unix, network interfaces are not represented by files in the /dev/ directory (although there exists a patch for the Linux kernel which enables that); in Linux, the interfaces are simply given "virtual" names such as eth0, eth1 etc. The tool to manage network interfaces is traditionally called If you ran /etc/network/interfaces, and it defines the usual things, such as network interface IP addresses, netmasks and gateways. The interfaces5 manual page is pretty informative, but we'll provide two most common examples; simple static IP and dynamic IP (DHCP) setups. Our first interface, eth0 will be given a static IP; the other, eth1 will have a dynamic IP. /etc/network/interfaces # # Standard stuff auto lo eth0 eth1 iface lo inet loopback # # Eth0: static iface eth0 inet static address 192.168.7.3 netmask 255.255.255.0 broadcast 192.168.7.255 gateway 192.168.7.1 # # Eth1: DHCP iface eth1 inet dhcp Configuring that file and running sudo /etc/init.d/networking restart should set you on stage. In some cases you might want to change the network card's ethernet ("hardware") address. This is posible with the ifconfig eth0 down ifconfig eth0 hw ether BA:BE:BE:EF:D0:0D ifconfig eth0 up

Hard disks As we've mentioned already, hard disks are recognized and work without any special setup. (Well, not really, they too are an option in the kernel configuration, but definitely all of the usual setups include the disk and filesystem drivers out of the box). One thing that you can do, however, is check the performace of your disks (cached and raw read performance). Install hdparm, then run sudo hdparm /dev/sda to get a feeling of what disks are about. (Note: old ATA disks on older Linux systems were called "hda". The distinction between "hda" and "sda" is a leftover from times when "hda" were strictly ATA and "sda" were strictly SCSI devices). $ sudo hdparm /dev/sda /dev/sda: multcount = 16 (on) IO_support = 1 (32-bit) unmaskirq = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 1823/255/63, sectors = 29297520, start = 0 To actually measure the throughput, first make sure the system isn't busy with anything that could influence the outcome (top should report only 1 process running — and that being itself), then run sync three times (to sync, or clean memory buffers by synchronizing to the disk now), and finally, run sudo hdparm -tT /dev/. In /dev/, stands for disk type (which is s for SCSI, and h for IDE devices), and stands for "number" which is actually letters of the alphabet, starting at a. If you had an IDE disk, it would most probably be /dev/sda. Actually, it would probably be nice to explain this "numbering" scheme properly: on typical PC motherboards, there are two IDE disk connectors (primary and secondary), each accepting a 40- or 80-wire cable with two connectors (master and slave) for peripherial devices. Altogether, this makes a total of 4 disks/CD-Roms that you can attach, and according to their position, they're assigned letters /dev/sda won't do you much good; run Anyway, speaking of hdparm -tT, here's a sample output: $ sync; sync; sync; sudo hdparm -tT /dev/hda /dev/hda: Timing buffer-cache reads: 848 MB in 2.00 seconds = 424.00 MB/sec Timing buffered disk reads: 90 MB in 3.01 seconds = 29.90 MB/sec Interesting, though, how the statistics looked back in the day. Here's a modern system from February 2010: $ sync; sync; sync; sudo hdparm -tT /dev/sdc /dev/sdc: Timing cached reads: 13570 MB in 2.00 seconds = 6794.06 MB/sec Timing buffered disk reads: 278 MB in 3.02 seconds = 92.08 MB/sec Now, what can we see here? Cache performance test measures the raw throughput achieveable from system RAM. Buffered test eliminates the cache and directly measures disk's ability to read the magnetic medium. For a PC (and — Ultra ATA — 80-column cable), 30 MB/s was nice (older disks were in 15 - 25 MB/s range, but now we managed to get in the 100 MB range per disk. One traditional SCSI/Unix disk manufacturer and popular SATA manufacturer today is &LNK12;, although the quality of their SATA disks at least has dropped enormously. Altogether, I've had the best experience (quality-wise) with Western Digital disks. If your disk throughput is much worse than this, chances are that DMA (Direct Memory Access) is not enabled; check that first with sudo hdparm /dev/sda | grep dma. If it's disabled, run sudo hdparm -d1 /dev/sda and repeat the test. In any case, if you figure out any hdparm settings that boost your disk performance, you'll want to add -k1K1 to the options (to preserve settings over disk reset — something that can happen during runtime), and you'll want to save the whole line in /etc/bootmisc.sh or somewhere, to have it run on each boot. If you have two disks, putting them on separate cables (in case they're not SATA which is one disk per cable) can further improve transfer rates. Just don't rush and reposition the disk to which you installed &DEB;. If you do so, the device filename will change (from say, /dev/sda to /dev/hdc) and your system will not boot properly any more! Don't do this until you read this Guide and learn how to use rescue CDs. Actually, today you can even change disk order and partitions since most of the things target partitions by UUIDs (Unique Identifiers) and not physical position on the bus. Thumbs up for modern developments!

CD/DVD-Roms Like hard disks, PC CD-Roms typically just work out of the box. There are some commands, however, that could be used to tune their exact behavior. We could just say that the Linux kernel can drive CD-Roms in either standard IDE/ATAPI mode, or SCSI emulation. SCSI emulation was primarily used to allow Of the commands you can use with CD-Rom drives, there's Finally, the standard, low-level CD-burning application is called wodim -vv -eject FILE_NAME.iso! In case you need to create the .iso first, copy all files to one directory (the easiest, not to search for them), and then produce the .iso with genisoimage -T -U -R -l -o mycd.iso DIR_NAME.

Graphics Graphic cards arena is pretty interesting. If you know something about the evolution of PC graphics cards, you know there were a little myriad of graphic "modes" invented, each with its pros and cons, and each with a different set of graphic cards that supported it. Those "modes" have surely put a certain burden on backward-compatibility; even modern PC graphic cards like &ATI; or &NVIDIA; that probably never see a console (terminal) mode still support dozens or even hundreds of various text modes. One of those modes is the standard character terminal mode, so you won't have any problems getting to the console (text mode) on PCs. One other supported standard is the VGA mode which allows a resolution of 640x480 pixels in 256 colors. (Just by the way, it means the screen alone took 640x480x8 bits — or about 307 kilobytes — to fit in memory). Then there's VESA 2.0 which is supported by SVGATextMode (and which is quite a pain to set up) so we won't discuss it. And there's VESA 2.0 in framebuffer mode. Instead of using the card's specific instruction set, you can initialize and use the card in framebuffer/VESA mode. This was quite attractive before, when it was easier to fire up the framebuffer mode than wait for months (should I say years?) before &XFREE86; (X Window System implementation) card-specific drivers became available. VESA 2.0 framebuffers allowed for good resolutions, but they too were limited to 256 colors. Another big drawback was a completely unaccelerated display which flickered even when you were moving a 2D window around the screen. Nowadays the Linux kernel does support the hardware framebuffer acceleration for most popular card groups. Framebuffers are also a comfortable option for graphic cards that do not support native console mode (such as &APPLE;'s) or were using framebuffer by design, such as some from &SUN;. The X Window implementation used today on Linux systems is X.org. You install it and it just works; it autodetects everything and doesn't even need the config file (/etc/X11/xorg.conf). And if you have an nVidia or ATI card, a program called

Modems

Telephone-line modems (of historical interest?) First of all, we must say that there are two main types of modems: real hardware modems, and handicapped modems called Winmodems. "Hardware modems" are the usual, full-featured modems. They are sometimes also called Rockwell or Hayes-compatible modems, they are attached to serial ports, and (being Hayes-compatible) they all support the standard &LNK13;. All external modems that you attach to the computer via serial cable are "hardware modems". Of internal modems that you plug into an ISA or PCI slot on the mainboard, usually only old ones (prior to year 1998 or even older) are "hardware modems". "Winmodems", on the other hand, are once again a disastrous invention from the PC world; basically they are modems with one $5 (five dollar, at the time of invention!) chip removed, whose tasks then need to be performed by the main system processor. Winmodems are only sold as internal (and that PCI) cards, and have practically flooded the post-millenium modem market; at most "modern" computer shops, they don't even know that Winmodem is not the only type of "modem". Winmodems do not have a single technical quality or a bright idea — it's quite the opposite. Such modems need special drivers to work at all, and even then you are lucky if they support some degenerated "AT" command set. Needless to say, Winmodems are a major annoyance because all the drivers are proprietary and closed-source. The linmodems.org site is trying hard to help Winmodem owners, but it's really not worth it. Winmodems are a disgusting piece of "hardware", they smell bad, and you are better off passing them to the next lucky owner. If you can buy a real modem yourself, you're good; if you can persuade someone into swapping a real modem for your Winmodem, you're really good. In the meantime, since originally writing the Winmodems section, the manufacturers seem to have standardized on one or two chips, and basically it is possible to get Winmodems working quite comfortably. They are, of course, as crappy as they've always been, but at least the cost of set up is no longer higher than of winmodem itself. If you will be interested in connecting to ISPs, you will use the PPP protocol. If you'll want to use the modem in "terminal" mode, then the infamous If you are interested in PPP connections, you simply need to run ISP1, then running /var/log/ppp.log, we redirected messages to that file earlier in the Guide when we configured the syslog daemon. Finally, it's worth noting that /etc/ppp/peers/ and /etc/chatscripts/ (and, well, /etc/ppp/ if your ISP uses PAP or CHAP authentication method). For completness, we include a sample working configuration for a typical dial-up ISP connection. /etc/ppp/peers/provider Notice that the string should be replaced with the username you use to connect to the ISP. File /dev/ttyS represents the first COM port or, in DOS parlance, COM1 (for serial port 2, you would use /dev/ttyS1, and so on). Note that in case of internal modems, the ports would probably be /dev/ttyS2 or /dev/ttyS3; your computer does have 4 serial ports even if only one or two are available on external connectors. # This optionfile was generated by pppconfig 2.0.10. # # hide-password noauth connect "/usr/sbin/chat -v -f /etc/chatscripts/provider" debug /dev/ttyS /etc/chatscripts/provider Notice that the number should be replaced with your ISP number. Also, the string ATx3m1 is a setting you should use in most european countries — it instructs the modem not to wait for dial-tone (this can be set from the Provider -> Advanced -> Modeminit). # This chatfile was generated by pppconfig 2.0.10. # Please do not delete any of the comments. Pppconfig needs them. # # ispauth PAP # abortstring ABORT BUSY ABORT 'NO CARRIER' ABORT VOICE ABORT 'NO DIALTONE' ABORT 'NO DIAL TONE' ABORT 'NO ANSWER' ABORT DELAYED # modeminit '' ATx3m1 # ispnumber OK-AT-OK ATDT /etc/ppp/pap-secrets and need to be replaced with the actual values you use for authentication with the ISP, of course. (none) * password Mentioned Debian PPP tools are definitely superior to any "ad-hoc" programs that you would employ, but wvdial is worth mentioning because it can do a lot of auto-detection (basically, all you need to know to use wvdial is your ISP phone number, user name and password). After installation, run sudo wvdialconf /etc/wvdial.conf to create the configuration file. Then, running wvdial should establish the connection. As usual, a working /etc/wvdial.conf is provided for completeness. /etc/wvdial.conf , and need to be replaced with the actual values you use for authentication with the ISP, of course. /dev/modem is a symbolic link to the modem device (wvdial should detect it all). If it does not, and /dev/ttyS0 were the real port (modem attached to the first serial port, or COM1 in DOS parlance), you'd create the symlink manually by running sudo ln -sf /dev/ttyS0 /dev/modem. Additionally, the l0m0 part of the "init string" makes the modem speaker quiet during both dialling and the duration of the connection. [Dialer Defaults] Modem = /dev/modem Baud = 115200 Init1 = ATZ Init2 = ATx3l0m0 S0=0 #Init3 = ATI 5 Phone = If

Cable modems Cable modems first need to be connected to the computer by an ethernet (LAN) or USB cable. If you're using the cable modem to connect to your ISP, then the ISP probably provided DHCP server on their side. In other words, you can simply define the interface to pick up the configuration from a DHCP server. Your /etc/network/interfaces file should simply look like this: auto eth0 iface eth0 inet dhcp It's useful to know that ISPs match your ethernet card hardware address before giving you the connection details and finally access. But sometimes you're forced to change your hardware ethernet address; for example, your card might get destroyed by a lightning, or your machine breaks down and you need to replace the card or temporarily move the modem to another computer. Calling the ISP to change your hardware address is sometimes not an option — they're suspicious when you call, or it takes a while for their changes to take effect. Fortunately however, in Linux, it is possible to manually change the hardware address of your network card. You can't write the address to the card's memory permanently though (you need to repeat it on each reboot), but that doesn't affect its usefulness. For a real example, please see .

ADSL modems ADSL modems also arrive in ethernet or USB cable versions. ADSL modems usually work using the PPPoE (PPP over Ethernet) protocol. To make your life real easy, install pppoe, pppoeconf and pppstatus packages. If your modem is connected and turned on, pppoe -A should find at least one PPPoE provider "on air". This is very simple and should be done at the beginning to minimize problems with pppoeconf. If you see no providers listed by pppoe -A, then something's wrong. In newer Debian installations, In the next step, you should read /usr/share/doc/pppoeconf/ to read a well-written ADSL introduction and practical HOW-TO. Running pppoeconf and following the instructions from the mentioned documentation file should be enough that you configure your ADSL modem. Once you do it, you can connect using

Mice (console) Besides in the X Window System (which will be covered separately), you can also use mouse in your text consoles. That is, by the way, very convenient, because you can simply select text with the LMB (Left Mouse Button) and paste with the MMB (Middle Mouse Button). The traditional program handling console mice is called gpm, run sudo gpmconfig to configure it. The device file to use is /dev/psaux for PS/2 port mice, /dev/ttyS for serial, and /dev/usb/mouse for USB (where is a number dependent on the port assigned, starting at 0). Of protocol types, many exist and many are supported; on PCs, the "auto-sensing" autops2 is the best (and default) choice. Repeat protocol is a convenient way to let gpm handle mice, and "repeat" events on file /dev/gpmdata so that other applications (such as X Window System) could use the same events. This, however, is not necessary since nowadays they can both open the mouse file directly. You can start, stop or restart the gpm daemon by invoking, for example, sudo /etc/init.d/gpm restart. And again, gpmconfig does no magic, it simply modifies /etc/gpm.conf which I provide for completeness. /etc/gpm.conf # /etc/gpm.conf - configuration file for gpm(1) # # If mouse response seems to be to slow, try using # responsiveness=15. append can contain any random arguments to be # appended to the commandline. # # If you edit this file by hand, please be aware it is sourced by # /etc/init.d/gpm and thus all shell meta characters must be # protected from evaluation (i.e. by quoting them). # # This file is used by /etc/init.d/gpm and can be modified by # /usr/sbin/gpmconfig. # # PS/2 Mouse example device=/dev/psaux responsiveness= repeat_type= type=autops2 append="" sample_rate=

Audio cards The Linux audio drivers story is quite interesting. Traditionally, Linux used the Open Sound System (OSS) architecture. It was written by guys who ran their own company and wanted to make money on audio drivers, and only contributed old or uncommon drivers to the Linux kernel tree. This was, as you might guess, pretty unfortunate, so the folks got together to rewrite the audio system and get rid of the hog. The result was ALSA - Advanced Linux Sound Architecture. ALSA is the default sound system in the Linux kernel 2.6 series.

Digital cameras Some of the digital cameras were (or still are) supported directly by the Linux kernel, allowing you to mount their memory cards as the usual disks. One other, and more common way, is to use user-space drivers for the cameras. The GNU gphoto2 --port usb: --get-all-files --camera "Kodak DC3400" Another common trick these days is to plug the memory card in some universal reader device and then mount it as a standard disk. This way it's also possible to upload files to the card even if the camera itself doesn't support uploading (so you can't use

Printers Traditionally, printing in Unix was done by the BSD lp or lpr stand for Line Printer, although printing is all but limited to line/matrix printers, of course). Afterwards, /etc/printcap, describing printers' capabilities. Probably the three most relevant printing-related commands are With PostScript printers it's quite easy. With PC printers, as always — the things are a little different. To overcome printing problems, (primarily on GNU/Linux PCs, but on other Unices as well), CUPS — Common Unix Printing System — was developed, and it's what we are going to use. Let's first install it: $ sudo apt-get install cupsys cupsys-{bsd,client} foomatic-db foomatic-filters-ppds By default, CUPS listens on &LNK14;. Visit the page with your web browser, and you'll be able to perform printer administration tasks from quite an usable web GUI. The username and password you're asked for are "root", and root's password. For details on supported printers and the drivers you can use, surely visit &LNK15;. CUPS can also be configured directly, just using config files in /etc/, but that is out of the scope of this Guide. Here's what I wrote years ago in this section: "Printer setup is still unnecessarily too hard to get right, but hopefully things will get better." Well, things have surely changed for the better. Almost all printers are nowadays recognized by Cups (auto-detection finds them and the drivers exist). What's more, if you're using a modern desktop, such as &GNOME;, &XFCE; or &KDE;, or a more "out of the box" oriented flavor of Debian, such as Ubuntu, there's a great chance the printer will be automatically recognized and installed with the appropriate driver

Unix software technologies; constituent pieces and underlying concepts

William Safire "Knowing how things work is the basis for appreciation, and is thus a source of civilized delight."

Introduction In the section above, , we've explained what does the system do to get from a power-on to some usable state. By now, you should have also learned how to log in, of course, and wander around the system a little. The system you see, however, is very much "alive", it's not just a collection of commands and files waiting to be ran or read. Those "live" parts (or subsystems) are crucial to Unix and account for a lot of what Unix stands for. We are about to poke around the neighborhood and meet the crowd.

System Login Under the term system login, we assume an action of verifying one's credentials, setting up access rights, and letting users proceed with their computer session. Exactly how does that session looks like, depends on the actual service requested and the type of the users' client software. In general, users are given individual accounts, to which they can log-in. There are two main groups of accounts: System accounts - accounts that are registered on a system level, usually in files /etc/passwd, /etc/group and /etc/shadow. Mentioned files form the traditional Unix users authentication scheme, although such information can also be kept at various databases, for example in so-called directories which consist of key:value pairs and are optimized for massive read-only access ( LDAP). System accounts are service-independent and deeply rooted in Unix philosophy. One of their key values is full accountability in terms of dates and times of access, performed actions and system resources used. Typical examples are the accounts you use to access all telnet, SSH and FTP services. Those "real" accounts will be of our primary concern, and we shall refer to them as system accounts or simply accounts. Virtual accounts - accounts that are not registered on a system level, and instead live in service-specific databases. Those databases could be based on files or LDAP behind the scenes as well, but because virtual account solutions are popular for simplicity and ad-hoc setup (except for few notable implementations), most of them today seem to live in MySQL databases. Typical examples of virtual accounts in use are various Web shops, Web memberships, mailing list membership or "inventions" like e-mail-over-web. Virtual accounts have also been fairly popular in setups where users do access their e-mail using proper protocols, but only have "virtual mailboxes" on the servers instead of real accounts. As we've mentioned, virtual accounts are mostly service-dependent and are, lacking any formality in both design and implementation phase, inherently inconvenient to account for. Instead of re-using the established system infrastructure, applications must handle virtual users in their own ways. In addition, instead of performing tasks under the appropriate system accounts' privileges, such applications run under a single username, further complicating any deeper access control and usage statistics. We see how the computing word around us has changed over the past 10 years (for better or worse). Almost everything is nowadays in some form of virtual accounts, this is virtual, that is virtual, everything is virtual! Actually, this is too funny — here's what I wrote about virtual accounts in this Guide back in 2002: "Virtual accounts are a disaster (except, again, for few notable fiels of use and implementations) and have blossomed since 1995 onwards, the period that was characterized by the advent of 'personal computers' and the disappearance of all technical correctness from the civil sector."

Console login Probably the most straight-forward way to log-in to the system is to sit between keyboard and chair, and log-in at the local system's console prompt. In general, a variant of the getty program will be listening on the consoles to receive your authentication info. Debian default, /sbin/getty, was spawned by /sbin/init. /sbin/init, in turn, took its configuration from the already-mentioned /etc/inittab file. There are many getty variants available (try running apt-cache search --names-only getty for example) but "getty" has also been established as a kind of a generic name for the whole class. It's interesting to note that getty reads in the initial username and password, and pulls out of the deal by passing control onto the /bin/login program. The question is, however, what happens if you type in a wrong username or password (or do not authenticate successfully for some other reason)? Since getty is out of the game, the login program itself will serve you with another prompt, although it will look exactly the same as the original getty one. Only if you fail to authenticate for a couple of times in a row, or terminate your session, will /bin/login close down and (thanks to init) /sbin/getty be respawned ("started again") to wait for new logins. Determining who's behind the login prompt; <command>/sbin/getty</> or <command>/bin/login</>? If you press getty. Otherwise, such as if there is a timeout first, you're talking to /bin/login.

The 'login' shell Supposing you manage to authenticate successfully and the getty or login programs let you through, what happens next? Well, before we can answer that, you first need to get familiar with your entry in the /etc/passwd file. There are many ways to retrieve it; you could open the file in a text editor and search for your username, you could run grep $USER /etc/passwd, and you could run getent passwd $USER. The last variant is suggested as it can work with arbitrary user authentication scheme. A sample entry might look like this: $ getent passwd $USER user1:x:1000:1000:Mirko,,,:/home/user1:/bin/bash Fields 6, 7 and 8 specify users' &LNK2; information, their home directory, and the default shell. Generally, after you have been authenticated, the software spawns the specified shell for you and changes to your home directory. Since Unix sites and users often configure their environment, there's are global tuning files available, /etc/profile and /etc/environment (the first is an executable script, the other is a collection of KEY=VALUE pairs and does not exist by default). The bash shell also reads /etc/bash.bashrc and possibly other /etc/bash* files (if configured to include them). After the site-wide configuration files are honored, the shell reads its corresponding user-specific dotfiles at startup. Again, in case of the bash shell, those are ~/.bash_profile or ~/.bashrc. At this point, it is important to learn the difference between login- and non-login shells. Login shells are the special case where users are at the other end of a connection (instead of a batch script file or another program) and use the terminal interactively. When you log-in to the system using telnet or SSH, you're given a login shell. Login shells read ~/.bash_profile, which should contain settings relevant for interactive work (command aliases, prompt display, etc.). All other shells are non-login shells. The root user does not read /etc/profile file and, by Debian convention, its dotfile is ~/.profile instead of ~/.bash_profile (but this is in no way enforced - if ~/.bash_profile was present, it would take precedence). We could mention that the "shell language" was standardized by POSIX, so any shell files that are not bashisms. And indeed, there's a strong movement present in Debian to free the maintainer scripts of all non-POSIX-compliant constructs. Following the analogy, your root user's ~/.profile file should be written with POSIX sh standard in mind. Korn Shell (ksh) Programming page for additional information. It is also useful to note that the shell does not use any secret techniques to read the dotfiles; it evaluates them in the context of the existing process using the source or . (a dot) command. When those "startup" tasks are performed, the system shows the command prompt and is ready to accept commands.

Account login regulation Since most of the accounts on your machine will be used locally, by yourself, there's no reason to let people log in remotely, right? You could be interested in giving your friends access, but that's a different issue — you would give them their own accounts and take some basic precautions before opening the system to the World. This is all pretty hard to explain right now, because it already touches that magic World of Unix security, which is so broad and deverse that any immediate commentary on it would distract us noticeably, even if we ignored the "intuitive" thinking and stuck to formal definition. So anyway, as we concluded we don't want people logging in remotely, edit file /etc/security/access.conf, read short introductory text included in the file, and add something like this to the end: -:root user1 user2:ALL EXCEPT LOCAL The above would deny access to root, user1 or user2, except from the localhost. Settings in the /etc/security/access.conf file are honored because the PAM subsystem can be configured to read them, as we'll just see explained in the next section.

Pluggable Authentication Modules (PAM) So far, you should have understood that, in Unix, there are many data protocols (FTP, HTTP, telnet, IRC, ...) and their implementations (vsftpd, Apache, telnetd, dancer-ircd, ...). Since most of the services require user authentication, it becomes obvious that supporting all kinds of authentication in every service would be hard, require a lot of manual and repetitive work, and be error-prone. On top of that, implementations would most probably end up being inconsistent, having different interpretations of "standard", and contain suble, hard-to-find bugs. Fortunately, computer science is old enough that people came about to spot the problem, and think about eventual remedies. The idea that &SUN; came up with was a generic Pluggable Authentication Module layer, or simply — PAM. Generally, each service makes a straightforward call to PAM and expects a Yes or No type of answer. This allows for one size fits all approach in client software; to perform all authentication work, simply invoke PAM and don't worry. Even though PAM only returns a positive or a negative final answer, one could suppose that PAM uses more sophisticated techniques in reaching this boolean (Yes/No) conclusion. And indeed it is so. Each service drops a piece of its PAM configuration to PAM config files. That configuration can request arbitrary authentication steps to be performed, combined and stacked in any order (including either-or variants). There's also a default which you can use to handle multiple services with the same config file. For example, you could configure PAM to authenticate the user if either his retinal scan matches the database, or he posseses both the correct RSA private key and a one-time password. And supporting arbitrary other authentication scheme becomes as easy as writing a PAM module to handle the specific method. There are three main PAM implementations in use today: Solaris PAM used by the Solaris OS, Linux-PAM used by all Linux "distributions", and OpenPAM used by BSD-derived systems. Linux-PAM is also the PAM implementation used by Debian. One very unfortunate fact is that, while PAM itself provides a standardized API even for requesting additional input from the user (which is quite a feat), it does not standardize the logging interface. Some Linux-PAM modules do not log at all, and those that do are not forced to consistency by formal methods. This is such a critical omission that it consequently puts PAM practice in a completely different light. The solution to the PAM logging problem, however, came unexpectedly. Sebastien Tricaud added &PRELUDE; support to PAM 0.79, so PAM can now consistently report all the action to the Prelude manager.

System task schedulers Computers do one thing well - they happily execute highly-repetitive tasks that you could never complete yourself in a reasonable amount of time (let alone the boredness experienced along the way). From that perspective, it's obvious that every serious operating system should have a way to schedule tasks for execution at some later, future time, or in a repetitive (periodic) fashion. The "pioneering" work in automated schedulers was done by a chief of an IBM-powered farm (with crops, animals and all), back in the 1970's. He reduced three 8-hour shifts to two 8-hour shifts, replacing the third person (ho had practically nothing to do but run one system command at 3:00 am) with a timer-powered Lego block that would drop from a height onto the Return key. Unix systems today have two schedulers available — Generic NQS.

At As you might conclude from the command name, /usr/share/doc/at/timespec. For example, you could try echo "echo Hello, World" | at now + 1 minute. In a minute, you should see "Hello, World" in your mailbox. The example supplied the command "in place", but this is Unix so you can also save the set of commands to execute in a file (say, at -f cmds.at now + 1 minute. You can view pending jobs by running

Cron In essence, cron configuration file consists of each task defined in its own line. In turn, each line consists of 5-field time specification, and the task to execute. The first five fields indicate minutes, hours, days of month, months, and days of week. Here are a couple of examples to clarify the subject: # Run each minute * * * * * /usr/local/bin/syscommand # Run every 15 minutes 0,15,30,45 * * * * /usr/local/bin/syscommand # Run every 15 minutes, enhanced specification */15 * * * * /usr/local/bin/syscommand # Run every 2 hours * */2 * * * /usr/local/bin/syscommand # Run once every hour in period from 8:00 am to 3:00 pm 0 8-15 * * * /usr/local/bin/syscommand Cron configuration file is interesting. Make sure you read

System crontab As usual, &DEB; contains crontab in the base system. There's a number of great things going on on the system, even when you've installed nothing but the minimal setup. &DEB;'s system crontab file is (would you guess?) /etc/crontab. You can see that, in between the time specification and the command to execute, this specific file accepts the Unix username to run the task as. (While this itself is convenient and easy to look into, you can of course specify a different username in the command specification as well). Furthermore, you see that &DEB; prepared /etc/cron.*/ directories where both you and packages' postinstall scripts can simply drop tasks to execute. For example, if you want to execute once a day, just drop a script to /etc/cron.daily/. If, on the other hand, you want to exactly control the time, drop a file in /etc/cron.d/, where crontab config files are expected (or, if you must, edit /etc/crontab directly).

Users' crontab System users can also have their crontabs. All you have to do as a system user, is to run Besides running crontab . Administrators can allow or forbid system users to use crontab; look for cron.allow and cron.deny in the crontab manpage.

Inet Meta Daemon Inetd is yet another interesting concept but it needs a little general introduction first. As you might or might not know, Unix Following the above logic, it became meaningful to have a specialized server that only listens for client connections, and then forks the appropriate daemons to handle actual requests. The result is the Inet Meta Daemon. Inetd, however, did not have a shining security record, and it became too inflexible and slow for today's standards. In addition, Inet needed non-transparent support in every server program, so no wonder it slowly got out of mainstream Unix. But we still mention Inetd here for numerous reasons; it's an important part of Unix, it's still being useful for particular applications, and it can be easily overlooked when trying to increase overall network security of your system. There are a few Inetd implementations, but the default used by &DEB; is the openbsd-inetd variant. (Previously, Debian used the implementation from the venerable NetKit, still available as package /etc/inetd.conf and you should disable all the unnecessary services in it — probably all there are — and call the usual sudo invoke-rc.d openbsd-inetd reload.

E-Mail Debian uses an extensive e-mail system based on the Exim mailer. See packages Exim is to elaborate to cover here. What's important is that at installation time, it asks you a couple questions and in most cases configures a basic, working email server on the machine. From that point on, it's easy (or "easier") to implement your modifications or setup requirements. The upside is that, being the Debian default, it got all related Debian packages to work with it out of the box, so you can get many additional programs, such as greylistd (greylisting implementation — one of spam prevention methods) or mailman (mailing lists manager) to work with it with no or minimal effort on your part. To get a grip on Exim, see documentation at Exim.org. To get a grip on Debian packaging and file layout, see /usr/share/doc/exim4/README.Debian.gz.

Tcp Wrappers To restrict access to our systems and services, we can use packet-level and application-level solutions. Packet-level solutions are usually called We can, however, control access on an application level too. Application-level control can be implemented using proxies (content-based), TCP Wrappers (source/destination-based), custom methods, or a combination of those. As the section title says, we're going to take a look at TCP Wrappers here. Basically, TCP Wrappers serve as a generic application-level access control mechanism, and were first developed by Vietse Venema. TCP Wrappers were most useful in combination with Inetd, but have been since integrated into a number of standalone services. When a packet reaches the system (and the corresponding service listening for requests), all the application has to do is call for a TCP Wrappers check. Based on connection details (remote IP, remote username, destination service etc.), TCP Wrappers pass or deny requests. At that point, the application either continues with the client authentication (username/password mostly), or closes the connection. Tcp Wrappers are a standard part of Debian. For more information see and manual pages. TCP Wrappers can also serve as an example of professional programming practices — they come with a set of additional programs developed to conveniently test your configuration files and hypothetical connections; see and manual pages. To deny all services to remote addresses, make sure the file /etc/hosts.allow is empty, and put this in /etc/hosts.deny: ALL: ALL EXCEPT LOCAL 127.0.0.1: DENY For more information (including on how to trigger system commands upon incomming requests) read and manual pages. Please Note: Tcp Wrappers and a firewall have very little in common; the level at which the allow/deny decision takes place is fundamentally different. With a firewall, it happens on a lowest, packet level: the packet targeted at say, an FTP port, could be dropped by the firewall as soon as it gets received by the network hardware and processed by the operating system's network layer — it would never reach the FTP daemon. With TCP Wrappers, the packet does reach its destination (Inetd, or a standalone service). The validity check must be explicitly called for by the handling application, and is usually performed before the server forks ( Today, one of the most known uses of the TCP Wrappers is via the /etc/hosts.deny. When that happens, the client will see connection error: ssh_exchange_identification: Connection closed by remote host. The IP will be expired from the list after a while automatically. (On a side note, your first line of defense on SSH is to deny direct root logins using "PermitRootLogin no" in /etc/ssh/sshd_config. Denyhosts will then take care of the rest).

Conclusion Congratulations on following through the Guide. I initially wrote it in 2002, and things have changed enormously since then. However, better understanding and deeper knowledge always have a value, and with Linux — maybe even more so today then they've had before. I hope you enjoyed this Guide showing a brief "mix of everything"!

Glossary of terms</> <glossentry id=unix> <glossterm>UNiplexed Information and Computing System</> <acronym>Unix, UNICS</> <glossdef> <para> Speaking of the name Unix, it was intended as a pun on an earlier system called "Multics" (Multiplexed Information and Computing Service). </> <para> In earlier versions of this document, I used to say that Unix was a common name for a group of superior operating systems which shared most of the key design ideas. While there was nothing wrong with that statement, I went to search the Internet for some more formal explanations: </> <para> Short introduction on the <ulink url="http://www.ugu.com/">UGU</> site says: </para> <blockquote> <para> Unix - /yoo'niks/ Plural "Unices". An interactive time-sharing operating system invented in 1969 by Ken Thompson after Bell Labs left the Multics project, originally so he could play games on his scavenged PDP-7. Dennis Ritchie, the inventor of C, is considered a co-author of the system. </> </> <para> Similar and more detailed description from <ulink url="http://searchsolaris.techtarget.com">searchSolaris</>: </> <blockquote> <para> Unix is an operating system that originated at Bell Labs in 1969 as an interactive time-sharing system. Ken Thompson and Dennis Ritchie are considered the inventors of Unix. The name (pronounced YEW-nihks) was a pun based on an earlier system, Multics. In 1974, Unix became the first operating system written in the C language. Unix has evolved as a kind of large freeware product, with many extensions and new ideas provided in a variety of versions of Unix by different companies, universities, and individuals. </> <para> Partly because it was not a proprietary operating system owned by any one of the leading computer companies and partly because it is written in a standard language and embraced many popular ideas, Unix became the first open or standard operating system that could be improved or enhanced by anyone. A composite of the C language and shell (user command) interfaces from different versions of Unix were standardized under the auspices of the IEEE as the Portable Operating System Interface (POSIX ). In turn, the POSIX interfaces were specified in the X/Open Programming Guide 4.2 (also known as the "Single Unix Specification" and "Unix 95"). Version 2 of the Single Unix Specification is also known as Unix 98. The "official" trademarked Unix is now owned by the The Open Group, an industry standards organization, which certifies and brands Unix implementations. </> </blockquote> </glossdef> </glossentry> <glossentry id="gnulinux"> <glossterm>Free Software, GNU and Linux</> <glossdef> <para> <mediaobject> <imageobject> <imagedata fileref="images/rmstallman.jpg"> </> <imageobject> <imagedata fileref="images/rmstallman.eps"> </> <imageobject> <imagedata fileref="images/rmstallman.gif"> </> </> Richard Stallman, a MIT hacker, started an initiative to create a completely free operating system (free as in <emphasis /freedom/). Among other things, his decision was based on frustrations and problems he saw in non-disclosure agreements. They once prevented his colleague from giving him the source code for a laser printer driver (Stallman wanted to include automatic paper-jam notification features). </> <para> Highly motivated to do The Right Thing (tm), he later quit the job at MIT (so they couldn't possibly claim copyright on his work) and, in 1984, started the <ulink url="http://www.gnu.org">GNU</> ("Gnu's Not Unix") project, whose goal was to protect freedom and supply users with full-featured free software packages for their computers. GNU is a wonderful philosophy that could surely affect non computer-related areas as well. </> <para> You can see the <ulink url="http://groups.google.com/groups?selm=771%40mit-eddie.UUCP">original Stallman's announcement</> from Sep 27, 1983 / 10:35:59 PST in the excellent <ulink url="http://groups.google.com">Google Groups</> archive! </> <para> GNU developers have re-written all the necessary Unix system tools and utilities, released them as Free Software (under the GNU GPL licence), and they only needed a kernel to accomplish the initial goal. </> <para> Independently, in 1991, Linus Torvalds (from the Helsinki University) announced his first public release of the kernel he was working on - Linux. He was a student back then, and wanted to create a cheap alternative to high-priced Unix systems, which would run on PC (i386) compatible machines. Combining the Linux kernel and the GNU tools, the free GNU/Linux system became a reality. Linus wrote the kernel from scratch ("from zero") and it was one of the first free Unix-like variants which, supported by the great GNU community and their software, got the Free Software movement really going (from the general-public perspective, not technically, of course). </> <para> All the way back in 1994, Peter van der Linden wrote the following in his excellent book, titled “Expert C Programming; Deep C Secrets” (ISBN 0-13-177429-8): </para> <blockquote> <para> The Free Software Foundation is a unique organization founded by ace MIT hacker Richard Stallman. By the way, we use “hacker” in the old benevolent sense of “gifted programmer”; the term has been debased by the media, so outsiders use it to mean “evil genius”. Like the adjective <emphasis>bad</>, “hacker” how has two opposing meanings, and you have to figure it our from the context. </> <para> Stallman's Free Software foundation was founded on the philosophy that software should be free and freely available to all. FSF's charter is “to eliminate restrictions on copying, redistribution, understanding and modification of computer programs” and their ambition is to create a public-domain implementation of Unix called GNU (it stands for “GNU's Not Unix”. Yes, really). </> <para> Many computer science graduate students and others agree with the GNU philosophy, and have worked on software products that FSF packages and distributes for free. This pool of skilled labor donating their talent has resulted in some good software. One of the FSF's best products is the GNU C compiler family. gcc is a robust, agressive optimizing compiler, available for many hardware platforms and sometimes better than the manufacturer's compiler. </> </blockquote> <para> However, there were other efforts, such as those by the BSD people who still had problems with the licensing issues and copyrights, but they have rewritten all the parts in question and released free BSD variants: <ulink url="http://www.freebsd.org">FreeBSD</>, <ulink url="http://www.netbsd.org">NetBSD</> and <ulink url="http://www.openbsd.org">OpenBSD</>. </> <para>  Open Source OSS, OSI Open Source is a somewhat newer term which was generally accepted to help promote Free Software in commercial environments. It relies only on practical benefits of open source code (quality, reliability, cost of maintenance) and has no greater philosophy behind it. More information can be found at the Open Source Initiative website. It is therefore important to know the disctinction between the two. Important! Read more about the Free Software, Open Source and the correct interpretation of the word free on the Debian's What Does Free Mean? page. It is interesting to mention that Linux is a monolithic kernel and shares many ideas with its Unix counterparts. However, the GNU people have a different vision of how kernels should look like and they are working on The Hurd microkernel. Debian GNU/Hurd port is in progress, and you can see the current status or download the software from the Debian GNU/Hurd port page. Monolithic and microkernels are fundamentally different, and there's been much of debate if microkernels would ever prove useful in real-life application. Linus Torvalds, for example, is constantly bashing microkernel operating systems ("just say NO to drugs, and maybe you won't end up like The Hurd people"). Alan Cox, the former maintainer Linux production tree kernel maintainer, who has more sympathies for The Hurd, once said that The Hurd was more about Richard Stallman's idea about how a system should work to promote community than about high perfomance OS design. Technically, The Hurd and microkernels in general do offer many advantages over the traditional Unix kernels; those interested in getting more information should see hurd-paper.html and hurd-talk.html (for The Hurd), or the QNX website (for the proprietary, mature, microkernel-based Unix). Let's quote something from the official &LNK6; page:

Debian was begun in August 1993 by Ian Murdock, as a new distribution which would be made openly, in the spirit of Linux and GNU. Debian was meant to be carefully and conscientiously put together, and to be maintained and supported with similar care. It started as a small, tightly-knit group of Free Software hackers, and gradually grew to become a large, well-organized community of developers and users. Since many people have asked, Debian is pronounced 'deb ee n'. It comes from the names of the creator of Debian, Ian Murdock, and his wife, Debra. Debian is produced by nearly one thousand developers spread around the world who volunteer in their spare time. Few of the developers have actually met in person. Communication is done primarily through e-mail (mailing lists at lists.debian.org) and IRC (#debian channel at irc.debian.org). The Debian Project is an association of individuals who have made common cause to create a free operating system. This operating system that we have created is called Debian GNU/Linux, or simply Debian for short. An operating system is the set of basic programs and utilities that make your computer run. At the core of an operating system is the kernel. The kernel is the most fundamental program on the computer and does all the basic housekeeping and lets you start other programs. Debian systems currently use the Linux kernel. Linux is a completely free piece of software started by Linus Torvalds and supported by thousands of programmers worldwide. However, work is in progress to provide Debian for other kernels, primarily for the Hurd. The Hurd is a collection of servers that run on top of a microkernel (such as Mach) to implement different features. The Hurd is free software produced by the GNU project. A large part of the basic tools that fill out the operating system come from the GNU project; hence the names: GNU/Linux and GNU/Hurd. These tools are also free. Of course, the thing that people want is application software: programs to help them get what they want to do done, from editing documents to running a business to playing games to writing more software. Debian comes with over 8710 packages (precompiled software that is bundled up in a nice format for easy installation on your machine) - all of it free. It's a bit like a tower. At the base is the kernel. On top of that are all the basic tools. Next is all the software that you run on the computer. At the top of the tower is Debian - carefully organizing and fitting everything so it all works together. You may be wondering: why would people spend hours of their own time to write software, carefully package it, and then give it all away? The answers are as varied as the people who contribute. Some people like to help others. Many write programs to learn more about computers. More and more people are looking for ways to avoid the inflated price of software. A growing crowd contribute as a thank you for all the great free software they've received from others. Many in academia create free software to help get the results of their research into wider use. Businesses help maintain free software so they can have a say in how it develops - there's no quicker way to get a new feature than to implement it yourself! Of course, a lot of us just find it great fun. Debian is so committed to free software that we thought it would be useful if that commitment was formalized in a written document. Thus, our &LNK7; was born.