Debian

From HerzbubeWiki
Jump to navigation Jump to search

This page collects information about the Debian project and the Debian operating system. The information has been gathered from various debian.org resources and is mainly of interest to me because I am not a DD (see glossary) and therefore not terribly familiar with some terms and resources.


General references

On this wiki


External


On a Debian system

  • Debian FAQ : Install package debian-faq, the actual documents are then placed under /usr/share/doc/debian/FAQ


Glossary

APT
Advanced Packaging Tool
BTS
Bug Tracking System
DAM
Debian Account Manager. DD that manages account creation and removal. The DAM has the final decision over an application.
d-i
Debian Installer
DD
Debian Developer
DDP
Debian Documentation Project
DebConf
Refers either to the yearly held Debian Conference, or to the Debian Configuration Management System. See DebianPackageManagement for details about the latter.
Distribution
A different name for a release (see there)
DPL
Debian Project Leader
DPM
Debian Package Manager
ITP
Intent To Package (WNPP related). Someone has found an interesting piece of software and would like to create a Debian package from this software.
NM
New Maintainer
NMU
Non-Maintainer Upload (details see here)
PTS
Package Tracking System
RC
Release Critical, as in "RC bugs"
Release
The main releases of Debian have the symbolic names "stable", "testing" and "unstable". Symbolic names refer to moving targets, for instance "stable" may refer to Debian release 6, 7 or 8, depending on when you make the reference. When an actual release is made it is given not only a version number (6, 7, 8, ...), but also a codename so that people can refer to the release using that codename. So far all codenames were taken from Pixar movies. For instance, "jessie" refers to release 8.x. Also see the Releases section further down on this page.
RFA
Request For Adoption (WNPP related). The current maintainer of a package is asking for someone else to maintain the package.
RFH
Request For Help (WNPP related). The current maintainer of a package needs help in maintaining the package.
RFP
Request For Package (WNPP related). Someone has found an interesting piece of software and would like someone else to create a Debian package from this software.
sid
Permanent codename for the unstable release of Debian. Can also be seen as an acronym for "still in development".
WNPP
Work-Needing and Prospective Packages


Releases

List of current releases. The 3 main releases, or distributions, of Debian are:

stable
At the time of writing, this release is named "sarge" and carries the version number v3.1r0
testing
At the time of writing, this release is named "etch"; in time it will become the new stable release
unstable
This release is always named "sid"; packages migrate from here into testing


In addition, there are also the following distributions:

oldstable
This refers to the distribution just from before stable; at the time of writing, this would be "woody"
experimental
This distribution is used for packages which are still being developed, and with a high risk of breaking your system. Note that this is not a complete distribution and therefore needs to be used in conjunction with "stable", "testing" or "unstable"
foo-backports
"foo" must be replaced with the name of a stable release, e.g. "jessie-backports". Backports are packages taken from the next Debian release (i.e. "testing"), adjusted and recompiled for usage on Debian stable. Because the package is also present in the next Debian release, a stable+backports system can easily be upgraded once the next Debian release comes out.


A release can also have sub-sections:

updates
Security updates
volatile
Packages that aim at fast moving targets, such as spam filtering and virus scanning; Updating volatile packages of a release should be absolutely painless as those package updates do not normally contain any functional changes
volatile-sloppy
Same as volatile, but for package updates that may include functional changes or might be otherwise painful


Testing vs. unstable

  • There is an automatism at work that moves packages from unstable to testing after a certain amount of time.
  • I have not yet researched how this automatism works, but I have seen this useful site that answers the question "Why is package X not in testing yet?"


Also see


Package management programs

Introduction

As a system administrator I am interacting with Debian's package system on various levels (e.g. command line, interactive), using a number of programs that often manage only a small part of the overall system (e.g. bare-bones package installation; install a package including dependency resolution; manipulate the DebConf database; etc.). This section enumerates the programs that I know about and briefly outlines their responsibilities, without going into too much detail. A more in-depth discussion of each program's usage, configurations and possible pitfalls can be found on a separate wiki page.

Without doubt the most important program - or at least the one that I most frequently use - is aptitude. It is followed by dpkg, in those cases where i need to perform a lower-level task.


dpkg

Basic package management operations are performed by the command line utility dpkg.

  • dpkg knows how to install and uninstall .deb packages
  • dpkg controls the package database
  • dpkg detects package dependencies and conflicts, but it does not know how to resolve them - that job is delegated to more advanced tools
  • dpkg does not know where to obtain packages, it can only install .deb package files that are already located somewhere in the filesystem


apt-get / apt-cache

The command line utility apt-get is a more advanced tool than dpkg.

  • It detects package dependencies and conflicts and knows how to resolve most of these problems
  • It "knows" where to obtain .deb package files because its configuration includes a definition of package sources (typically FTP or HTTP mirrors)
  • It uses dpkg to install and uninstall packages


apt-cache can be used to search and manipulate the APT package cache. It is also a command line utility.


For more information about APT, see http://www.debian.org/doc/manuals/apt-howto/index.en.html


dselect

dselect is a console-based, menu-driven interactive front-end for dpkg.

  • It is not very user friendly, let alone intuitive
  • dselect often has problems resolving package dependencies and conflicts; it is easily possible to get into a situation that can only be resolved by using apt-get on the command line
  • I very strongly recommend using aptitude over dselect !!!
  • Unfortunately, some official Debian docs (notably the APT HOWTO) mention dselect but not aptitude - at least that was the case when I started using Debian in 2003, which is why I fell into the trap of using dselect


aptitude

aptitude is a console-based, menu-driven interactive front-end for APT

  • It is quite intuitive and user-friendly (it even has an undo feature)
  • It is extremely clever when it comes to resolving package dependencies and conflicts; in complex conflict situations you can examine multiple solutions to resolve the conflict before you choose one solution
  • I have used aptitude for over a decade, and it has never let me down in even the hairiest situations (typically when I was running a system on testing and had to update libperl to a new version)


synaptic

synaptic is a GUI front-end for APT. I currently have no experience with this tool, as I do all the administration over an SSH terminal.


System administration

/etc/alternatives

If several packages provide a program that fullfils the same function on a system, that function is made accessible in the file system under a generic name (e.g. /usr/bin/editor). Debian's alternatives system is then used to select the actual package/program that will provide the desired functionality.

The "magic" of the alternatives system is made possible through a chain of symbolic links. If we look at, for instance, /usr/bin/editor: 

zapmama2:~# ls -l /usr/bin/editor
lrwxrwxrwx 1 root root 24 2009-06-11 20:41 /usr/bin/editor -> /etc/alternatives/editor
zapmama2:~# ls -l /etc/alternatives/editor
lrwxrwxrwx 1 root root 17 2009-06-11 13:05 /etc/alternatives/editor -> /usr/bin/vim.tiny
zapmama2:~# ls -l /usr/bin/vim.tiny
-rwxr-xr-x 1 root root 630340 2008-10-18 02:12 /usr/bin/vim.tiny

An alternative may consist of multiple links that need to be changed together: For instance, not only the editor program needs to be changed, but also the editor man page.

Usually the debconf system is responsible for setting up alternatives, when packages are installed, removed or updated. Alternatives are in "automatic" mode when they are first introduced to the system. In this mode, the debconf system makes sure that the alternative with the highest priority is selected. When the system administrator begins to make manual changes, the alternative moves into "manual" mode, which means that debconf no longer makes automatic choices and it will no longer be the highest-priority-alternative that becomes selected.

To switch between alternatives, use the program update-alternatives. For details, see the program's man page.


Bug tracker

Report a new bug

To report a new bug, either use the reportbug utility on the command line of the Debian system (recommended by Debian), or send an email to the Debian bugtracker (preferred by me). Everything is explained in detail here: 

http://www.debian.org/Bugs/Reporting

Procedure:

  • Send an email to submit@bugs.debian.org
  • The subject of the message will be used as the title of the bug
  • The body of the message must begin with a couple of "pseudo-headers" that tell the bugtracker which package the bug report refers to; example
Package: lprng
Version: 3.8.28dfsg.1-1.1
  • The rest of the body (possibly separated by an empty line from the pseudo-headers) contains the actual bug report


Reply/add comment to an existing bug

For instance, to reply or add a comment to bug report 12345:

  • Send an email to 12345@bugs.debian.org


Watch an existing bug

The following page details how to "watch" an existing bug report for changes: 

http://www.debian.org/Bugs/Developer#subscribe

For instance, to watch bug 12345:

  • Send an email to 12345-subscribe@bugs.debian.org; subject and body are ignored, so should be empty
  • Wait for the confirmation message sent back by the bugtracker
  • Reply to the confirmation message to prove that you own the subscribing email adress

Unsubscribing works along the same principle, just send an email to 12345-unsubscribe@bugs.debian.org.


System upgrades

This is a general procedure how I perform Debian system upgrades.

  • Go to https://www.debian.org/releases/, find and open the release notes for the target Debian version + target platform (e.g. Debian 11 (bullseye), 64-bit PC).
  • I read the following sections in the release notes before I start doing anything:
    • Section "What's new in the distribution?". Browse through this section to catch potential big new stuff.
    • Section "Issues to be aware of for <name>". This is the most important section of the release notes - read through it carefully to get an impression of noteworthy details that could become a problem during the upgrade. Also obsolete packages and known bugs are listed here. Make notes and plan accordingly!
  • Methodically go through the section "Upgrades from Debian <n>".
    • This section contains the general procedure how to perform the system upgrade. It has many detailed notes of things which I usually forget between releases, so it is vital to read through this carefully.
    • Update to the latest point release of the current Debian version
    • Clean up any pending stuff according to the release notes
    • Once everything is ready for the upgrade, perform a backup of some files that are not covered by the regular BackupSolution. When I performed the upgrades from buster => bullseye => bookworm, these were
      • /var/lib/dpkg
        • This is a folder that contains a lot of files, so backing the folder up as a .zip or .tar archive is most efficient: cd /; tar -cpv -f /tmp/var-lib-dpkg.tar var/lib/dpkg
      • /var/lib/apt/extended_states
      • The output of dpkg --get-selections "*" (quotes are important)
      • /var/lib/aptitude/pkgstates
    • After the system upgrade
      • Migrate PostgreSQL databases to the new cluster. See the PostgreSQL wiki page for details. Note that some applications may continue to work if their database is on the old cluster, but other packages may not (e.g. Zabbix).
      • Because MySQL/MariaDB does not operate with clusters, for them no such migration is necessary.
      • Perform an upgrade of each application's database.
        • Notable applications that need an upgrade: mediawiki, davical, roundcube.
        • Zabbix automatically upgrades its database
        • Bugzilla is completely custom-installed and is not affected by the Debian upgrade
      • Add 99-pelargir.ini to the newest PHP configuration, e.g. under /etc/php/8.2/apache2/conf.d/99-pelargir.ini. See the Apache wiki page for details.
      • Try to get rid of obsolete packages, also purge any packages that were auto-removed. Ideally when finished the section "Obsolete and Locally Created Packages" in aptitude should contain only a single package: The old Linux kernel.
      • Clean up leftover configuration files in /etc
Retrieved from "https://wiki.herzbube.ch/index.php?title=Debian&oldid=7048"