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 /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, Debian supports a number of different init mechanisms.
At some later point, you might take a look at
file-rc and
runit.
Now that we've covered the basics of a system boot process, we can move on to a subject that just logically follows.
Virtual consoles
Almost all &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 (which is a boring and uneducated way to install software; use
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-xfree86
Sometimes it's also useful to see a recursive dependency listing for a package. This feature is provided by the apt-rdepends package.
To reinstall a package, use either the above dpkg -i or apt-get 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.
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,