Skip to end of metadata
Go to start of metadata

Tools

der Debian Package Manager liefert gleich verschiedene Tools zum verwalten der Pakete:

  • apt
  • aptitude
  • tasksel
  • dselect
    and, last but not least:
  • dpkg

Für jene die es grafisch lieben sei:

  • synaptic
    empfohlen

Config

Die Haupt-Konfigurationsdatei von APT ist die apt.conf. per default existiert diese nicht, muss also bei bedarf angelegt werden.

Meine /etc/apt/apt.conf sieht folgendermaßen aus:

APT::Default-Release "stable";
APT::Cache-Limit 10000000;

ersteres bewirkt, dass in der sources.list verschiedene Quellen unterschiedlicher Entwicklungsstati eingetragen werden können (stable und testing) ohne dass zwangsweise die neuere Version genutzt wird, sondern stets stable, sofern nicht per:

aptitude -t <release> ...

etwas anderes angegeben ist!

Der zweite eintrag erlaubt es, das Informationen größerer Repositorys (oder einigen mehr als üblich) im System gecached werden!
Wer also Probleme beim

aptitude update

hat sollte dies mal versuchen (wink)

Tools

erstellen von Paketen

wer daran interessiert ist, sollte mal "checkinstall" versuchen (wink) anonsten alles weitere demnächst...
Wer Kernel-Pakete erstellen möchte, sollte mal unter Kernel kompilierung unter Debian schauen.

externes

  • eine erste Hilfestellung sollte auch der Artikel aus dem Linux Magazin geben

Paketliste sichern und wiederherstellen

dpkg --get-selections > package_list

/usr/sbin/synaptic --hide-main-window --non-interactive --set-selections-file package_file

unattended updates or upGrades

Jeder kennt das Problem im 24/7 betrieb: irgendwann wollen immer diese lästigen SecurityUpdates eingespielt werden.
Während andere Distributionen wie SuSE einen festen Cronjob und Tool dafür kennt (zypper, der sich via yast auch konfigurieren lässt) fehlt dies in Debian Umfeld.
(oder ich bin zu blöd das herauszufinden (smile)

Also, zunächst das nötige Paket installieren:

http://packages.debian.org/search?keywords=unattended-upgrades

Alles was danach konfiguriert werden muss ist folgende Datei:
/etc/apt/apt.conf.d/50unattended-upgrades

In meinem Fall sieht sie so aus:

// allowed (origin, archive) pairs
Unattended-Upgrade::Allowed-Origins {
        "Debian stable";
};

// never update the packages in this list
Unattended-Upgrade::Package-Blacklist {
//      "kernel-image";
};
Unattended-Upgrade::Mail "sysadmin@example.net";

APT::Periodic::Update-Package-Lists "1";
APT::Periodic::Download-Upgradeable-Packages "1";
APT::Periodic::Unattended-Upgrade "1";

APT::UnattendedUpgrades::LogDir "/var/log/apt";
APT::UnattendedUpgrades::LogFile "unattended-upgrade.log";

Troubleshooting

gemischte Quellen

Das arbeiten mit gemischten Quellen aus stable und testing kann mitunter aber auch zu Problemen führen!
Wenn aptitute zB mit folgender Meldung abbricht,

# aptitude update
Reading Package Lists... Error!
E: Dynamic MMap ran out of room
E: Read error - read (14 Bad address)
E: The package lists or status file could not be parsed or opened.

ist dies nicht wirklich aussagekräftig ;/

ein Aufruf vom guten alten apt-get hilft hier ggf weiter:

# apt-get update
[...]
Reading Package Lists... Error!
E: Dynamic MMap ran out of room
E: Error occured while processing sgt-puzzles (NewPackage)
E: Problem with MergeList /var/lib/apt/lists/ftp2.de.debian.org_debian_dists_testing_main_binary-i386_Packages
E: The package lists or status file could not be parsed or opened.

Denn nun sehen wir genau wo der Fehler liegt!
Also einfach in der /etc/apt/sources.list die Zeile mit dem betreffenden Listeneintrag auskommentieren und erneut

aptitude update

ausführen. Wenn zu diesem Zeiotpunkt wirklich was aus dem Testing bereich gebraucht wird, und man nicht ständig die spurces.list manuell anpassen will, kann es ja mit Apt-un2stable versuchen (wink)

Keysigning Probleme

Probleme bei Distributions-VersionsWechsel

Wenn beispielsweise lenny von stable nach oldstable wechselt, werden auch die Release-Schlüssel der Paketsignaturen getauscht.
Normalerweise kennt Debian die Distributions-Public-Keys (öffentlichen Schlüssel) über das Paket "debian-keyring"

Für historisierte Archive benötigt man das Paket "debian-archive-keyring":

$ sudo aptitude install debian-keyring debian-archive-keyring

Andernfalls bekommt man Meldungen wie:

W: GPG error: http://security.debian.org lenny/updates Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY AED4B06F473041FA
W: You may want to run apt-get update to correct these problems

Hierbei sollte man Ausgaben wie solche bekommen:

Setting up debian-archive-keyring (2010.08.28~lenny1) ...
gpg: key F42584E6: "Lenny Stable Release Key <debian-release@lists.debian.org>" not changed
gpg: key 55BE302B: "Debian Archive Automatic Signing Key (5.0/lenny) <ftpmaster@debian.org>" not changed
gpg: key 6D849617: "Debian-Volatile Archive Automatic Signing Key (5.0/lenny)" not changed
gpg: key B98321F9: public key "Squeeze Stable Release Key <debian-release@lists.debian.org>" imported
gpg: key 473041FA: public key "Debian Archive Automatic Signing Key (6.0/squeeze) <ftpmaster@debian.org>" imported
gpg: Total number processed: 5
gpg:               imported: 2  (RSA: 2)
gpg:              unchanged: 3
gpg: no ultimately trusted keys found

Dabei sieht man, das der eben noch gesuchte Schlüssel mit der Endung "473041FA" nun verfügbar ist. Ein Anschließendes

$ sudo aptitude update 

sollte nun keine (Fehler)meldung mehr ausgeben. Wenn doch, einfach weiterlesen, den dann braucht man bestimmt einen externen Schlüssel fremder Paketquellen (wink)

Fremde Quellen

Bei der Nutzung dispributionsfremder Quellen (Third-Party) wie zB http://www.backports.org erfolgt nach dem Aufruf von

  1. aptitude update

oft eine Meldung wie diese:

W: GPG error: http://www.backports.org sarge-backports Release: Die folgenden Signaturen konnten nicht geprüft werden weil der zugehörige öffentliche Schlüssel nicht zur Verfügung steht: NO_PUBKEY EA8E8B2116BA136C
W: Sie möchten vielleicht »apt-get update« aufrufen, um diese Probleme zu lösen

daher einmal:

  1. gpg --keyserver subkeys.pgp.net --recv 16BA136C
  2. gpg --export --armor 16BA136C | sudo apt-key add -

ausführen was mit folgenden Meldungen belohnt werden sollte:

gpg: Schlüssel 16BA136C von hkp Server subkeys.pgp.net anfordern
gpg: Schlüssel 16BA136C: Öffentlicher Schlüssel "Backports.org Archive Key <ftp-master@backports.org>" importiert
gpg: kein uneingeschränkt vertrauenswürdiger Schlüssel 080F3C94 gefunden
gpg: Anzahl insgesamt bearbeiteter Schlüssel: 1
gpg:               importiert: 1
gpg: kein uneingeschränkt vertrauenswürdiger Schlüssel 080F3C94 gefunden
OK

Ihr seht, ich habe zum Importieren des GPG Schlüssels lediglich die letzten 8 (Hexadezimal)stellen des Publickeys angegeben
Dieser ist eindeutig genug (wink)
^warum? darum: 8^16 == 281.474.976.710.656 (~= 281,5 Billionen) mögliche 8-Stellige Hexadezimale Schlüsselnummern, was bei einer Weltpopulation von 6,5 Milliarden Menschen es erlaubt, dass sich jeder mit 43.303 GPG-Schlüsseln eindeckt. Reicht, oder? ;D

  • No labels