Linux Troubleshooting Bible [Electronic resources] نسخه متنی

Debian Basics

In this section you'll get a crash course in finding and managing packages, as well as a few other systems administration topics. These areas are where differences between RPM-based distributions (like Fedora and Red Hat) and Debian are most evident.

Debian Archives

All the software that is officially packaged for Debian is contained in what's termed a Debian archive. How you access that archive can vary: you may have a set of Debian CDs (which contain a copy of the archive), you may have your own local copy of the archive on a server or on your hard drive, or you may use one of the many Debian archive mirrors.

These archives are not small. There are currently some 13,000 packages in Debian, available for you to install via apt-get or one of the many other packaging front-ends (introduced below). When a package is created by a packager (also referred to as a maintainer), it gets uploaded to the Debian archive. If it isn't available in the Debian archive, thus available to you through apt-get and friends, chances are that it's a really poorly-made or poorly-maintained package (see the "Debian Archives Revisited-Official versus Unofficial" section for an exception to this rule). So if you're unable to install the package via any of the packaging front-ends, you're likely best off compiling from source. You shouldn't need to do this often, however, as so much is already available in the Debian archive.

Finding Packages

Given that all this software is available, a problem arises-how do you know the names of the packages you want? How do you find them? There are multiple ways, but we'll treat only the most common here:

tasksel, apt-cache, aptitude , and http://packages.debian.org .

Let's start with a working example. Say you want to install a bunch of packages related to a particular role. Perhaps it's a desktop machine. Go ahead and fire up the

tasksel program from your command-line.

Among the first choices should be Desktop environment. Use your arrow keys to navigate the cursor to highlight the checkbox beside that entry, and then hit the i key. This will display a longer description of the task, as well as a list of packages that will be installed if you select it. Press the Enter key to exit the information screen, and then hit either the spacebar or Enter key to actually mark the task for installation. An asterisk (*) should appear in the checkbox beside the entry.

When you've selected the tasks you want installed, press the f key to finish the task selection phase and move onto the installation phase.

While

tasksel is useful for setting up a basic system, what happens when you need a specific application that isn't already included in the task? This is where the more advanced front-ends come in.

apt-cache is part of the apt family of tools, which are described in more detail later.

apt-cache has many options, but we'll only discuss its searching functionality here (see its man page for full documentation). Let's assume that you'd like an e-mail client, and you prefer using applications that integrate well with the K Desktop Environment:

#  apt-cache search kde email
kgpgcertmanager - KDE Certificate Manager
kmail - KDE Email client
ksig - graphical tool for managing multiple email signatures
#

As you can see, our search returns three useful results. The first column lists the package name, and the rest of the line is devoted to a short description of each package. The one you're probably looking for is

kmail , which is the standard KDE e-mail client.

If, in your searching, you get more results than you can shake a stick at, you can look more closely at a package with

apt-cache show packagename . Among other things, this prints the full description of the package, the individual who maintains it and their e-mail address, the amount of hard drive space the package uses when it's installed, and the package's version.

Though

apt-cache is a great tool for finding packages, it isn't the only one.

aptitude (feel free to run

apt-cache show aptitude ) is a full-screen, full-featured package management front-end. It presents the full list of available packages in a categorized, hierarchical format. You can also tell it to change the way it sorts, filters, and displays packages, aptitude can also serve as a drop-in command-line replacement for

apt-get . For more information, see aptitude's manual, /usr/share/doc/aptitude/README (you may need to install it first, if you're using Woody).

If you prefer using a Web browser to search for packages and display their information, http://packages.debian.org/ is an excellent resource. Not only does it offer all the functionality of

apt - cache , but it also allows you to view much of the information about a package that would normally only be available to you if you installed the package. You can also search for which package(s) provide a particular file, for instance

/usr/lib/libasound.so.2 . With http://packages.debian.org/ , your searches aren't limited to the current package set that's available in the Debian tree which you installed-you can search other trees (and other architectures, like PPC) as well.

If you find a package on http://packages.debian.org/ , don't download the package file that's linked in the results page and try to install it manually. This will almost certainly result in pain and suffering. Instead, just run

apt-get install packagename . Use http://packages.debian.org/ only to help you find the names of packages; it should not be used as a download site.

Managing Packages

Now that we've discussed finding the name of the package you actually want, let's look at what having the package name actually lets you do. Since Debian serves as a central repository for all software that's built well for Debian (as opposed to other distributions where it's common to have many third-party package providers), simply knowing the name of the package lets you install it, remove it, and in some cases configure it. There's no need for lengthy URLs or a long list of download sites that must be checked manually for software updates.

Installing Packages

Let's take a look at an example session. We'll install

vim , a popular console-based text editor:

#  apt-get install vim
Reading Package Lists...
Building Dependency Tree...
The following extra packages will be installed:
libgpmg1
The following NEW packages will be installed:
libgpmg1 vim
0 packages upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 3796kB of archives. After unpacking 12.3MB will be used.
Do you want to continue? [Y/n] y
Get:1 http://http.us.debian.org stable/main libgpmg1 1.19.6-12 [45.2kB]
Get:2 http://http.us.debian.org stable/main vim 6.1.018-1 [3751kB]
Fetched 3796kB in 15s (252kB/s)
Selecting previously deselected package libgpmg1.
(Reading database ... 9047 files and directories currently installed.)
Unpacking libgpmg1 (from .../libgpmg1_1.19.6-12_i386.deb) ...
Selecting previously deselected package vim.
Unpacking vim (from .../vim_6.1.018-1_i386.deb) ...
Setting up libgpmg1 (1.19.6-12) ...
Setting up vim (6.1.018-1) ...
#

Note that apt-get told us it would be installing an extra package along with

vim . This is Debian's vaunted automatic dependency-resolution at work. Observe:

# apt-cache show vim | grep ^Depends:
Depends: libc6 (>= 2.2.4-4), libgpmg1 (>= 1.19.6-1), libncurses5
(>= 5.2.20020112a-1)
#

Though we already had appropriate versions of

libc6 and

libncurses5 installed (they're included in the base installation), we did not have

ligpmg1 installed. Because the

vim package is well-built and declares its requirements, apt-get is able to install every package required to use

vim , and in an automated manner no less. This isn't as unique as it once was.

apt-rpm is now included in several distributions, as is

yum . Both apt-rpm and yum are relatively new, but they provide users of Fedora and Red Hat with similar functionality to the Debian tools they were modeled after.

What's most important is that the packages themselves are of high quality. They must properly declare their relationships to other packages-whether they require another package (Depends :), whether another package can't be installed at the same time as the one you're installing (Conflicts :), and so on. Additionally, it's important that all the packages follow the same policies and conventions. It doesn't help if the package you're trying to install depends on the package

vim6 , but the

vim package you have installed is named

vim . This is also why it's important to stick with packages from the standard Debian archives.

However, should you for some reason need to work with a

.deb file manually (.deb is the underlying package file format), you can do so:

#  dpkg -i /var/cache/apt/archives/vim_6.1.018-1_i386.deb
(Reading database ... 9926 files and directories currently installed.)
Preparing to replace vim 6.1.018-1 (using .../vim_6.1.018-1_i386.deb) ...
Unpacking replacement vim ...
Setting up vim (6.1.018-1) ...
#

Notice that the output of this command looks strikingly similar to some of the output in our

apt-get install invocation. This isn't surprising, because

apt-get (and every other packaging front-end in Debian) just calls

dpkg to handle the onerous task of unpacking the package, moving the new files in place, and running any pre- and post-installation scripts which are required.

For more information, refer to the

dpkg and

apt-get man pages. They're pretty complete and should answer any questions you might have.

Removing Packages

Removing packages is a pretty easy task. Just use the

apt-get remove command, like so:

# apt-get remove vim
Reading Package Lists...
Building Dependency Tree...
The following packages will be REMOVED:
vim
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get OB of archives. After unpacking 12.2MB will be freed.
Do you want to continue? [Y/n]
(Reading database ... 9926 files and directories currently installed.)
Removing vim ...
dpkg - warning: while removing vim, directory '/etc/vim' not empty so not
removed.
#

See how only

vim was removed, and not

libgpmg1 as well?

apt-get can install additional packages automatically, but it doesn't try to remove them automatically. This behavior is considered dangerous, as the packaging system really doesn't know whether you're using a package for some other reason.

aptitude has the ability to automatically track which packages were installed manually. See the aptitude manual (/usr/share/doc/aptitude/README ) for an in-depth look at this excellent tool.

You can also use

dpkg to remove packages. In fact, sometimes you must use

dpkg . Only

dpkg allows you to force package removals. Take a look at

dpkg removing a package:

# dpkg -r vim
(Reading database ... 9926 files and directories currently installed.)
Removing vim ...
dpkg - warning: while removing vim, directory '/etc/vim' not empty so not
removed.
#

Again, you see that this output was included in the

apt-get remove run. You might have noticed that

dpkg issues a warning: It claims that

/etc/vim isn't empty and thus can't be removed. Take a look and see if there really is anything in

/etc/vim :

# ls /etc/vim
gvimrc vimrc
#

Here you see two configuration files. They weren't deleted as part of the package removal, which brings us to our next topic, configuration file handling.

Configuration File Handling

This is another area where people coming from Fedora or Red Hat might be thrown for a loop. Debian is almost zealous in its attitude about configuration files. They are sacrosanct. If any package tromps on a user's configuration, that package is tarred and feathered and beaten to a bloody pulp.

That's only a slight exaggeration. Configuration file handling is a very serious topic when it comes to Debian maintainers and their users. Briefly:

A package may not blindly overwrite a configuration file that was put in place by the administrator before the package was installed.

Any changes the administrator makes to a configuration file must be preserved, for instance when the package is being upgraded.

Removing a configuration file is considered a change to that configuration file, and as such must be preserved.

Unless the administrator explicitly says "remove the configuration files for this package," they are to be left in the filesystem.

We've seen that simply removing a package doesn't also remove its configuration files. Our example package, vim, has two configuration files left, /etc/vim/gvimrc and

/etc/vim/vimrc . Let's use the

dpkg -purge command to get rid of them:

# dpkg --purge vim
(Reading database ... 9056 files and directories currently installed.)
Removing vim ...
Purging configuration files for vim ...
# ls /etc/vim
#

As you can see, the configuration files have been removed. Now the packaging system, for all intents and purposes, thinks that

vim has never been installed. Now take a look at what happens when you install a brand new package, but you already have a configuration file in place:

#  ls /etc/vim/vimrc
ls: /etc/vim/vimrc: No such file or directory
#  echo test > /etc/vim/vimrc
#  ls /etc/vim/vimrc
/etc/vim/vimrc
#  apt-get install vim
Reading Package Lists...
Building Dependency Tree...
The following NEW packages will be installed:
vim
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 0B/3/51kB of archives. After unpacking 12.2MB will be used.
Selecting previously deselected package vim.
(Reading database ... 9053 files and directories currently installed.)
Unpacking vim (from .../vim_6.1.018-1_i386.deb) ...
Setting up vim (6.1.018-1) ...
Configuration file '/etc/vim/vimrc'
==> File on system created by you or by a script.
==> File also in package provided by package maintainer.
What would you like to do about it ? Your options are:
Y or I : install the package maintainer's version
N or 0 : keep your currently-installed version
D    : show the differences between the versions
Z    : background this process to examine the situation
The default action is to keep your current version.
*** vimrc (Y/I/N/O/D/Z) [default=N] ?

Here we are, at one of the standard Debian configuration file handling prompts. According to the package management system, this file is on the system because either we created it (and we did, that's what the

echo command was for). It's also in the package we're trying to install.

At this point we have a number of options. We can say, "yes, don't worry about my configuration file, go ahead and overwrite it." We can say, "no, do not install the new configuration file, the one I have is fine." The

D option is particularly useful on upgrades. The

D option lets you see the differences between the current configuration file, and the one the package offers. The

Z option is also generally useful; it drops you into a shell so you can more closely examine the situation. Perhaps you'll edit the current version of the configuration file before proceeding with the installation. Perhaps you'll make some minor changes to the new version, and then replace the old version with it. The possibilities are endless, as you're able to do pretty much whatever you like.

You will get similar prompts in other situations, but you will not get such a prompt when you remove a configuration file. Remember, removing a configuration file is considered a change to that configuration file, and it's a major one. Anyway, back to the configuration file prompt. Go ahead and press the

Y key at the prompt to install the new configuration file to complete the installation, and then observe the results:

# apt-get remove vim
Reading Package Lists...
Building Dependency Tree...
The following packages will be REMOVED:
vim
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get OB of archives. After unpacking 12.2MB will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 9926 files and directories currently installed.)
Removing vim ...
dpkg - warning: while removing vim, directory '/etc/vim' not empty so not
removed.
#  ls /etc/vim/vimrc
/etc/vim/vimrc
#  rm /etc/vim/vimrc
#  ls /etc/vim/vimrc
ls: /etc/vim/vimrc: No such file or directory
#  apt-get install vim
Reading Package Lists...
Building Dependency Tree...
The following NEW packages will be installed:
vim
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get OB/3751kB of archives. After unpacking 12.2MB will be used.
Selecting previously deselected package vim.
(Reading database ... 9056 files and directories currently installed.)
Unpacking vim (from .../vim_6.1.018-1_i386.deb) ...
Setting up vim (6.1.018-1) ...
# ls /etc/vim/vimrc
ls: /etc/vim/vimrc: No such file or directory
#

To narrate the above session, the first thing we did was remove

vim . We then confirmed that its configuration file

/etc/vim/vimrc was still in place. We then removed it (for demonstration purposes), and confirmed it was gone. Then we installed

vim again, and confirmed that our configuration file was still gone. You should now be asking, "How do I get that configuration file back?!" Good question, and here's the trick:

# dpkg --force-confmiss -i/var/cache/apt/archives/vim_6.1.018-1_i386.deb
(Reading database ... 9926 files and directories currently installed.)
Preparing to replace vim 6.1.018-1 (using .../vim_6.1.018-1_i386.deb) ...
Unpacking replacement vim ...
Setting up vim (6.1.018-1) ...
Configuration file '/etc/vim/vimrc', does not exist on system.
Installing new config file as you request.
# ls /etc/vim/vimrc
/etc/vim/vimrc
#

As you can see, we needed to use the underlying

dpkg tool with a forceful option to restore the configuration file. In this case, we used the

-force-confmiss option. This tells

dpkg to ignore any missing configuration files, and act as if they weren't removed. The package's new version of the configuration file will be installed instead.

You can also

purge the package-that will also tell dpkg that any future installations should be done as if the package had never been installed:

#  apt-get remove vim
Reading Package Lists...
Building Dependency Tree...
The following packages will be REMOVED:
vim
0 packages upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
Need to get OB of archives. After unpacking 12.2MB will be freed.
Do you want to continue? [Y/n] y
(Reading database ... 9926 files and directories currently installed.)
Removing vim ...
dpkg - warning: while removing vim, directory '/etc/vim' not empty so not
removed.
#  ls /etc/vim
gvimrc vimrc
#  rm /etc/vim/vimrc
#  ls /etc/vim
gvimrc
#  dpkg --purge vim
(Reading database ... 9056 files and directories currently installed.)
Removing vim ...
Purging configuration files for vim ...
#  apt-get install vim
Reading Package Lists...
Building Dependency Tree...
The following NEW packages will be installed:
vim
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get OB/3751kB of archives. After unpacking 12.2MB will be used.
Selecting previously deselected package vim.
(Reading database ... 9053 files and directories currently installed.)
Unpacking vim (from .../vim_6.1.018-1_i386.deb) ...
Setting up vim (6.1.018-1) ...
#  ls /etc/vim
gvimrc vimrc
#

Configuring Packages with debconf

You've seen what happens when you change or remove a configuration file. The next point is how to actually configure packages. Though Debian doesn't have a central application that can be used to configure the system, like Fedora and Red Hat do, many Debian packages use

debconf , Debian's configuration framework. Individual packages can contain

debconf scripts that prompt the user for information, and then create a default configuration file based upon the answers it received.

When a package uses

debconf , the package provides a consistent and well-defined method of configuration. When you install or upgrade a package that uses debconf, the packaging system (specifically

debconf ) may display one or more questions for you to answer. You can decide what sorts of questions you'd like to answer; if you want, you can avoid all but the most critical questions. If you're a control freak like me, you can opt to answer even the lowest-priority questions.

An example of a critical

debconf question can be found in the

passwd package, which is responsible for setting the default system passwords at installation. In its

debconf script, passwd asks for the root password, and this is a critical-priority question for obvious reasons. Also in the

passwd package is a low-priority question regarding whether passwords should be stored separately from the username database. Roughly speaking, critical-priority questions must be answered by the user or the system will be nonfunctional or severely broken. Low-priority questions are those that have safe defaults and are only of interest to those who basically want to see every knob and have a chance to twiddle them. So taking our

passwd package as an example, it's not safe to have a default root password, or anybody can use it to gain administrator access on the machine. However, there are very few reasons for keeping the password database merged with the username database, so it's safe to assume that the user wants them separate.

Though debconf is primarily useful as it asks questions automatically during package installation, you can also reconfigure a package later by invoking the

dpkg-reconfigure command. (dpkg-reconfigure is part of the

debconf package, so be sure that

debconf is installed before you try to use it.) For example, to reconfigure the

debconf package itself, issue the following command:

# dpkg-reconfigure debconf

When you invoke a package's

debconf configuration in this manner, it will assume that you wish to see every question again. If you want to override this behavior, you can use

dpkg-reconfigure 's -p option:

# dpkg-reconfigure -p critical debconf

The available priorities, as of this time of writing, are low, medium, high, and critical. Priorities are inclusive, so if you've opted to see all low-priority questions, you'll also see all medium-, high-, and critical-priority questions. If a package doesn't have any questions to ask, you will simply be returned to your prompt.

debconf has numerous interfaces available, as you can see in

debconf 's own configuration. As of this writing, Debian/stable has GNOME, readline (console line-based), dialog (console full-screen), and editor interfaces. The next Debian/stable release (Sarge) will add a K Desktop Environment interface.

Other Basic dpkg Commands

Now that you know how to install and remove packages, and how to work with their configuration files, let's take a look at some of the other commonly used commands for examining packages.

The first thing you might want to do is list packages. You can use

dpkg -l without supplying a package name to get a list of all your packages. Unlike the various apt-related commands, which will tell you a great deal about any package which is either installed or available for installation, dpkg only knows about packages which you've installed or removed-similar to

rpm . Observe the output:

# dpkg -l vim
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-/image/library/english/10027_Unpacked/
Failed-config/Half-installed
| / Err?=(none)/Hold/Reinst-required/X=both-problems (Status, Err:
Uppercase=bad)
|| /Name               Version            Description
+++-==================-==================-======================================
ii vim                 6.1.018-1          Vi IMproved - enhanced vi editor
#

dpkg -l will list packages you have installed, as well as some information about each package. The first column is the status column. In the example, we see that vim is fully-installed (the

ii indicates this). Let's remove vim again, and then look at our package system database:

# dpkg -r vim
(Reading database ... 6944 files and directories currently installed.)
Removing vim ...
dpkg - warning: while removing vim, directory '/etc/vim' not empty so not
removed.
#  dpkg -l vim
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-/image/library/english/10027_Unpacked/
Failed-config/Half-installed
| / Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
|| /Name            Version        Description
++-================-==============-===========================================
rc vim              6.1.018-1      Vi IMproved - enhanced vi editor
#

The output is the same, except that the first column now shows

rc rather than

ii . This stands for "removed, but configuration files remain." Remember, removing packages doesn't automatically get rid of their configuration files. You must purge the package, explicitly telling dpkg that it's okay to nuke your configuration files, as in the following code:

# dpkg -- purge vim
(Reading database ... 6074 files and directories currently installed.)
Removing vim ...
Purging configuration files for vim ...
#  dpkg -l vim
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-/image/library/english/10027_Unpacked/
Failed-config/Half-installed
| / Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
|| /Name               Version             Description
+++-==================-===================-====================================
pn vim                 <none>              (no description available)
#

Now

dpkg doesn't know anything about versions and descriptions, all it knows is that the package's status is

pn , in other words, "purged, not installed." You can run

dpkg -l without any arguments at all to list all the packages that it's aware of.

Next you may want to take a look at the files that make up a package. Supplying

-L to

dpkg tells it to list package contents.

# dpkg -L libgpmgl
/.
/usr
/usr/lib
/usr/lib/libgpm.so.1.19.6
/usr/share
/usr/share/doc
/usr/share/doc/libgpmg1
/usr/share/doc/libgpmg1/copyright
/usr/share/doc/libgpmg1/changelog.gz
/usr/share/doc/libgpmg1/changelog.Debian.gz
/usr/lib/libgpm.so.1
#

dpkg -L is a pretty simple command. It lists any files that the package contains which dpkg knows about.

You can use

dpkg -I to examine a package file that you've downloaded (via

apt-get , not manually, if possible):

# dpkg -I /var/cache/apt/archives/sudo_1.6.6-1.1_i386.deb
new debian package, version 2.0.
size 134728 bytes: control archive= 2213 bytes.
33 bytes,     2 lines      conffiles
508 bytes,    12 lines     control
1124 bytes,   18 lines     md5sums
1852 bytes,   66 lines   * postinst              #!/usr/bin/perl
159 bytes,    7 lines    * postrm                #!/bin/sh
325 bytes,    12 lines   * prerm                 #!/bin/sh
Package: sudo
Version: 1.6.6-1.1
Section: admin
Priority: optional
Architecture: i386
Depends: libc6 (>= 2.2.4-4), libpam0g (>=0.72-1), libpam-modules
Installed-Size: 248
Maintainer: Bdale Garbee <bdale@gag.com>
Description: Provides limited super user privileges to specific users.
Sudo is a program designed to allow a sysadmin to give limited
root privileges to users and log root activity. The basic philosophy is
to give as few privileges as possible but still allow people to get their
work done.
#

This gives much of the same information as the

apt-cache show command, shown earlier, as well as some information about any packaging scripts embedded in the package.

Another common operation is determining which file belongs to which package. You can use

dpkg 's

-S option for this:

#   dpkg -S /etc/crontab
cron: /etc/crontab
#

If you want to check the integrity of the packages you have installed, you'll need to install an additional package called debsums. After you've installed it, feel free to run the debsums command.

Upgrading Your Installation

Upgrading your Debian installation is as simple as installing a package. In the example below, I just finished installing a Debian 3.0 Woody system from a CD. I've made sure the system can connect to the Internet, so we know it will be able to contact the Debian archive. I first run

apt-get update , which freshens the local database of available packages using Debian's archives:

#  apt-get update
Get:1 http://ftp.us.debian.org stable/main Packages [1774kB]
Get:2 http://non-us.debian.org stable/non-US/main Packages [44.5kB]
Get:3 http://security.debian.org stable/updates/main Packages [181kB]
Get:4 http://non-us.debian.org stable/non-US/main Release [102B]
Get:5 http://non-us.debian.org stable/non-US/main Sources [18.7kB]
Get:6 http://non-us.debian.org stable/non-US/main Release [104B]
Get:7 http://security.debian.org stable/updates/main Release [110B]
Get:8 http://ftp.us.debian.org stable/main Release [95B]
Get:9 http://ftp.us.debian.org stable/main Sources [729kB]
Get:10 http://ftp.us.debian.org stable/main Release [97B]
Fetched 2748kB in 11s (?50kB/s)
Reading Package Lists... Done
Building Dependency Tree... Done
#

Then, I run

apt-get to see what's in the upgrade and to start the upgrade:

#  apt-get -u upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be upgraded
perl-base
1 packages upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
Need to get 496kB of archives. After unpacking 102kB will be freed.
Do you want to continue? [Y/n] y
Get:1 http://security.debian.org stable/updates/main perl-base 5.6.1-8.6
[496kB]
Fetched 496kB in 3s (126kB/s)
(Reading database ... 6065 files and directories currently installed.)
Preparing to replace perl-base 5.6.1-8.3 (using .../perl-base_5.6.1-
8.6_i386.deb) ...
Unpacking replacement perl-base ...
Setting up perl-base (5.6.1-8.6) ...
#

In my case, there was only one package (perl-base ) available for upgrade. This is a fresh installation, with almost nothing installed. On a production machine, you can expect to see more upgrades. If you only want to upgrade a single package, just

apt-get install packagename . You can actually supply multiple package names, if you'd like, to either install or upgrade more than one package at a time.

If you're running Debian/stable, you want go through this upgrading process about once a day, just to be sure that your installation is up-to-date with respect to any security issues. If you're running Sid, you will likely also want to upgrade once a day-but in this case, the upgrade will include many new versions of packages which are unrelated to any security vulnerabilities.

As mentioned earlier, automatically removing packages is generally considered a bad idea. As such, if an upgrade requires a package to be removed (for instance, if it's been replaced by another), you need to use a different form of the

apt - get command. Instead of

apt - get upgrade , use

apt-get dist-upgrade .

The

-u option, incidentally, tells

apt - get to show us what it will be doing. This will be the default for the next Debian release (and already is the default, for people using Sid), but if you're still using Woody you should remember to add it.

Should you wish to stop a package from being upgraded, you can inform

dpkg and the

apt family of tools to put that package on hold, as shown in this example:

# echo perl-base hold | dpkg --set-selections
# apt-get -u upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages have been kept back
perl-base
0 packages upgraded, 0 newly installed, 0 to remove and 1 not upgraded.
#

Note that I put

perl-base on hold, and now apt-get won't upgrade it. There are any number of reasons why you don't want to upgrade a particular package-for instance, perhaps you have compiled your own version and don't wish its files to be overwritten. The following example shows the commands to allow the package to be upgraded:

# echo perl-base install | dpkg -set-selections
#  apt-get -u upgrade
Reading Package Lists... Done
Building Dependency Tree... Done
The following packages will be upgraded
perl-base
1 packages upgraded, 0 newly installed, 0 to remove and 0 not
upgraded.
Need to get OB/496kB of archives. After unpacking 102kB will be freed.
Do you want to continue? [Y/n]

apt - get is perfectly willing to upgrade that package, now that I've told the package subsystem that it's allowed to do so.

Debian Commands: Quick Reference

Table C-1 provides a comparison between some of the most commonly used Debian and Red Hat commands.

Managing Runlevels

Another big difference between Debian and RPM-based distributions is the runlevel system. The default runlevel in Debian is 2, not 5 as it is in Fedora and Red Hat. This isn't to say that you don't get a GUI by default in Debian. You don't, but it's not because you're in runlevel 2.

By default, runlevels 2 through 5 in Debian are all identical. If you have a graphical login manager installed, it will be run regardless of which of those runlevels you're in. I've seen many a new Debian user go through the relatively onerous task of switching the default runlevel to 5, only to find that it changed absolutely nothing.

You can customize those runlevels to do whatever you'd like (include emulating Red Hat's default runlevel setup), but they all start out identical.

Enabling and Disabling Services

Another stumbling point is Debian's lack of

chkconfig . Personally, I find this irritating as well. Debian has

update-rc.d that can be used to set the runlevels a particular service starts in, but it's meant primarily for packages to use automatically, and isn't particularly easy for an administrator to use.

The easiest way to manage runlevels in Debian is to simply add and remove symlinks from the

/etc/rc[2-5].d/ directories manually. I agree, it's a pain.

On the other hand, you're not forced to use symlinks to control which services start and stop-you can instead use a simple, plain configuration file.

Alternative Init Systems

There's a solid following of people who enjoy the use of the file-rc package. It's not currently available to Woody users, but will be included in Sarge. Instead of using a symlink tree in

/etc/rc*.d/ , it allows you to control runlevel information via a simple file, /etc/runlevels.conf . It's a pretty decent alterative to symlink-style management. Thanks to

update-rc.d , packages that automatically add symlinks will instead add lines to that configuration file.

Graphical Administration Systems

Debian doesn't have any centralized set of GUI administration tools. About the closest Debian has is

debconf . Since Debian places such a high priority on preserving user/administrator changes to configuration files, most Debian users are quite comfortable using them.

If you wish to have a nice front-end to common system configuration tasks, feel free to explore the

webmin packages.

webmin is a Web-based configuration/administration system that many people like. It's pretty complete, and does a much better job at preserving any manual changes you've made to configuration files when compared to most other such centralized configuration tools.

You can get a list of available

webmin modules by running

apt-cache search webmin -the list isn't reproduced here as it's quite long. The

webmin package itself installs a basic set of

webmin modules, and you can install more manually if you'd like. After you've installed the

webmin package, you can read the quick startup guide, available in

/usr/share/doc/webmin/ README.Debian .

Package Conventions

Because Debian's archive is so complete, because it contains virtually every piece of software that a user might want, and because we apply very strict policies and standards to packages, there's a lot you can find out if you simply know the package's name.

Many packages provide a Debian-specific README file, which often provides a quick startup guide. This is available as

/usr/share/doc/packagename/README.Debian or

/usr/share/doc/packagename/README.Debian.gz .

Change logs for the software can be found in

/usr/share/doc/packagename/changelog.gz and/or

/usr/share/doc/packagename/changelog.Debian.gz (if the latter exists, it documents Debian-specific changes).

http://packages.debian .

org /packagename allows you to view all sorts of data about the package, without needing to install it.

Debian Archives Revisited-Official versus Unofficial ArchivesSo far in this appendix, I've been doing my best to impress upon you the importance of using the standard Debian archives. There are many reasons to do this, but there are times when using an unofficial archive is warranted. The two main reasons would be installing more up-to-date packages on a Debian/stable system, and installing patent-encumbered software.

Feel free to open up

/etc/apt/sources.list in your favorite editor. My file looks like this:

# cat /etc/apt/sources.list
deb http://ftp.us.debian.org/debian/ stable main
deb-src http://ftp.us.debian.org/debian/ stable main
deb http://non-us.debian.org/debian-non-US stable/non-US main
deb-src http://non-us.debian.org/debian-non-US stable/non-US main
deb http://security.debian.org/ stable/updates main
#

Yours should look quite similar, though it won't be identical. Each line that starts with

deb refers to an archive that houses binary packages (what you get when you

apt-get install something), and each line that starts with

deb-src refers to an archive that houses the sources for those binary packages (which can be downloaded via

apt-get source packagename ). The two different lines are often identical after that initial difference, as most archives host both binaries and sources. After the initial component of the line (either

deb or

deb-src ) comes the archive's URL. This is a standard URL that refers to the location of the archive. Following the URL are one or more space-separated components which refer to which parts of the archive you're interested in.

I have two unofficial archives to recommend. They're both run by people I know, and in my experience the quality of the packages are acceptable, typically as good as what you'll find in the standard Debian archives (unlike most unofficial archives out there).

If you're running a Debian/stable installation, but you desperately need a newer version of a package than what is available in that tree, and you aren't willing to upgrade to Sid, then I would suggest http://www.backports.org/ . Instructions on its usage are available at www.backports.org/installationl .

If you want to use mplayer (a popular media player) or any mp3 encoders (which are patent-encumbered in countries which have weak patent offices), you can use Christian Marillat's archive, available at

deb ftp://ftp.nerim.net/debian-marillat/ dist main . (Substitute the

dist appropriate for your installation:

stable, unstable , or

testing . Note that the various components of the line are separated by spaces.) You can also check http://marillat.free.fr/ ; that's where Christian posts news about his archive.