|
|
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.
| Note |
When you've been using an RPM-based distribution like Fedora or Red Hat for years, your first instinct when you want to install a piece of software is likely to be to hit www.rpmfind.net/ and look for an RPM to download. RESIST THIS URGE. |
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.
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.
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.
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) ... #
| Note |
We just used the dpkg command for the first time. Roughly, this is equivalent to the rpm command Red Hat users may already be familiar with. dpkg's role in a Debian system is much the same as rpm's role in a Fedora or Red Hat system. However, use of dpkg directly in Debian is frowned upon unless you're careful and know what you're doing, as we provide other tools (such as apt-cache and apt-get) that are intended for direct use. |
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 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. #
| Caution |
Please read the dpkg man page before you force a package removal, as this command can be quite dangerous. |
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.
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 #
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:
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.
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-files/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-files/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-files/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.
| Tip |
Use debsums -q to list only errors and warnings, instead of telling you about every file that's perfectly all right. |
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.
Table C-1 provides a comparison between some of the most commonly used Debian and Red Hat commands.
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.
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.
| Web Resource |
Managing the symlinks in the Debian SysV init directories is documented in detail as part of the Debian Reference Manual, and is available on-line at www.debian.org/doc/debian-policy/ch-opersys.html#s-sysvinit. |
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.
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.
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.
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/installation.html.
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.
|
|
|