Eigener interner APTLY Repository Debian
Spiegel / Mirror

Paketverwaltung aptly installieren

Mit root erst einmal das System auf den neusten Stand bringen!

apt update && apt upgrade

Zusätzliche Packete installieren:

apt instal aptly bzip2 gnupg gpgv

Einen eigenen Mirror User anlegen

adduser repoadmin

Zur Schlüsselverwaltung von GPG-Schlüsseln installieren wir das Tool gpg

apt install gpg

Jetzt unbedingt mit dem neuen Mirror Benutzer anmelden!

Wir erstellen einen Schlüsselpaar

gpg --full-generate-key

– Nach der Eingabe des Befehls werden wir nach der Art des zu generierenden Schlüssels gefragt.
– Bestätigen wir die Standard-Auswahl mit Enter.
– Bestätigen auch die Frage nach der Schlüssellänge mit Enter.
– Geben die Gültigkeit des Schlüssels an, zum Beispiel 2y für die Gültigkeit von 2 Jahren 2y
– Jetzt bestätigen wir das Ablaufdatum des Schlüssels mit j.
– Geben wir den Namen des Nutzers des Schlüsselpaares ein, z.B. lokaler Repository Administrator.
– Geben wir die E-Mail-Adresse des Nutzers des Schlüsselpaares ein, zum Beispiel repoadmin@mydomain.exampl
– Jetzt geben wir einen Kommentar zum Schlüssel ein oder lassen Sie den Kommentar leer und betätigen mir Enter.
– Überprüfen wir noch einmal die Eingaben und bestätigen diese durch Eingabe von F(Fertig).
– Geben wir ein Passwort zum Schutz des privaten Schlüssels ein.
– Merken sollte man sich das Passwort gut 😉 Wir benötigen es später zum Signieren der Programmpakete.
– Wiederholen wir die Eingabe des Passwortes.
– Das Schlüsselpaar wird nun generiert.
Dies dauert je nach Umgebung mehrere Minuten lang. Währenddessen versucht gpg zufällige Daten zu sammeln. Wir können den Prozess beschleunigen, indem wir in dieser Zeit am System weiter an einem anderen Terminal arbeiten.

Danach sollten wir jetzt mit:

gpg --list-secret-keys

prüfen können ob uns die Ausgabe die Daten zum neu generierten Schlüssel anzeigt.

zum Beispiel:

/home/repoadmin/.gnupg/pubring.kbx
----------------------------------
sec   rsa3072 2020-06-30 [SC] [verfällt: 2022-08-29]
5930FFDE82FA5429A7FA268B890A45171316D124
uid        [ ultimativ ] lokaler Repository Administrator
 <repoadmin@mydomain.example>
ssb   rsa3072 2020-06-30 [E] [verfällt: 2022-08-29]

Für die Übertragung des Schlüssels ist es erforderlich, dass wir das Passwort des privaten Schlüssels eingeben. Übertragen wir den privaten Schlüssel aus dem Schlüsselbund von GnuPG2 in das Schlüsselbund von GnuPG1 mit folgendem Befehl:

gpg --export-secret-keys repoadmin@mydomain.example | gpg1--import

Exportieren wir den öffentlichen Schlüssel des Schlüsselpaares für spätere notwendige importe beim Client.
Rufen wir dazu folgenden Befehl auf:

gpg --export --armor repoadmin@mydomain.example> repoadmin-pubkey.asc

Der öffentliche Schlüssel wird in die Datei repoadmin-pubkey.asc exportiert.

Jetzt endlich, erstellen wir den eigentlichen lokalen Spiegel / Mirror

Und so soll es zum Schluss aussehen:

 

aptly mirror create -architectures=amd64 \
-filter=’Priority (required) | Priority (important) | \
Priority (standard) | openssh-server’\
-filter-with-deps=truestretch_main \
http://ftp.de.debian.org/debian/ stretch main

Selbiges erstellen wir jetzt nich zweimal aber mit Paketspiegel stretch_update und stretch_security.

Ergebnis sollten drei angelegte Mirror sein, zu überprüfen mit:

aptly mirror list

Falls wir beim Erstellen eines Paketspiegels die Fehlermeldung erhalten, dass einige Schlüssel im Schlüsselbund vertrauenswürdiger Schlüssel fehlen, dann importieren wir zuerst die fehlenden Schlüsse.

Nun aktualisieren wir alle drei angelegten Spiegel (kann lange dauern und bis zu 100GB Speicher kosten!):

aptly mirror update stretch_main
aptly mirror update stretch_updates
aptly mirror update stretch_security

Erstellen wir zu jedem Paketspiegel einen Schnappschuss.
Die Namen der Schnappschüsse werden gemäß dem folgenden Schema gewählt:
Schnappschüsse vom

• main-Paketspiegel: <Paketspiegel-Quelle>_<Version>
• updates-Paketspiegel: <Paketspiegel-Quelle>_<Datum>
• security-Paketspiegel: <Paketspiegel-Quelle>_<Datum>.

Die Version der Distribution lässt sich z.B. mit folgendem Befehl ermitteln.

aptly mirror show stretch_main | grep Version

Erstellen wir nun von den vorhandenen Paketspiegeln jeweils einen Schnappschuss.
Geben wir den Befehl dafür gemäß der nachfolgenden Syntax ein.

aptly snapshot create <Schnappschuss-Name> from mirror \
<Paketspiegel-Name>Beispiel

aptly snapshot create stretch_main_9.9 from mirror \
stretch_main

aptly snapshot create stretch_updates_2019-07-30 from \
mirror stretch_updates

aptly snapshot create stretch_security_2019-07-30from \
mirror stretch_security

Die soeben erstellten Schnappschüsse von den drei Paketspiegeln werden nun in einen einzigen Schnappschuss zusammengeführt – Merge.

aptly snapshot merge -latest stretch_final_2019-07-30 \
stretch_main_9.9 stretch_updates_2019-07-30 \
stretch_security_2019-07-30

Jetzt veröffentlichen wir noch den Snapshot

aptly publish snapshot -distribution=stretch \
stretch_final_2019-07-30

Nachdem aptly die nötigen Referenzen auf die Programmpakete erstellt hat, werden wir aufgefordert das Passwort zum Signieren der veröffentlichten Pakete einzugeben. Geben wir das Passwort ein, welches wir beim Erstellen des GPG Schlüsselpaares unter dem Benutzer repoadmin verwendet haben.

Abschließend muss nur noch nginx oder apache installiert werden und das Verzeichnis des Mirrors freigegeben werden -> Die Programmpakete werden im Verzeichnis /var/www/packages/public/ veröffentlicht.

Client installation

Melden wir und am Client-PC mit unserem Benutzer an.
Jetzt fügen wir den öffentlichen Schlüssel aus der Datei repoadmin-pubkey.asc in den Schlüsselbund vertrauenswürdiger Schlüssel hinzu und geben folgenden Befehl ein.

sudo apt-key add repoadmin-pubkey.asc

Ergebnis. Der Schlüssel wird in das Schlüsselbund vertrauenswürdiger Schlüssel aufgenommen

In der /etc/apt/source.conf muss nur noch der neue Mirror Server als quelle aufgenommen werden andere Quellen können nach Bedarf entfernt werden.

Apt-update danach nicht vergessen 😉

Zum Abschluss

Es macht natürlich nur Sinn einen Mirror zu nutzen wenn er auch in Intervallen aktualisiert wird.
Also am besten oben stehenden Update / Snapshot / publish (switch)  Befehle als geplanten zeitlichen cron Service ausführen.

Das geht natürlich auch fein mit Jenkins und ggf. einem Slack-Hook falls mal was schief läuft 😉

Ein kleiner Auszug aller Befehle für Distribution Buster:

sudo -u repoadmin aptly mirror update buster-main
sudo -u repoadmin aptly mirror update buster-updates 
sudo -u repoadmin aptly mirror update buster-security

sudo -u repoadmin aptly snapshot create buster-main-snapshot-$(date +%Y%m%d) from mirror buster-main
sudo -u repoadmin aptly snapshot create buster-updates-snapshot-$(date +%Y%m%d) from mirror buster-updates
sudo -u repoadmin aptly snapshot create buster-security-snapshot-$(date +%Y%m%d) from mirror buster-security


# Merge Snapshots
sudo -u repoadmin aptly snapshot merge -latest buster-final-$(date +%Y%m%d) buster-main-snapshot-$(date +%Y%m%d) buster-updates-snapshot-$(date +%Y%m%d) buster-security-snapshot-$(date +%Y%m%d)

## Nur nötig falls noch gar kein snapshot gepublished wurde, asonsten wird geswitched!
sudo -u repoadmin aptly publish snapshot -distribution=buster buster-final-$(date +%Y%m%d)

# Switch zum neuen Snapshot als Veröffentlichung
sudo -u repoadmin aptly publish switch buster buster-final-$(date +%Y%m%d)

# Grafik des Merge anlegen und veröffentlichen
sudo -u repoadmin aptly graph -output /srv/aptly/.aptly/public/graph.png

# aufräumen der alten nicht mehr benötigten snapshots
sudo -u repoadmin aptly snapshot drop buster-final-$(date +%Y%m%d --date="yesterday")
sudo -u repoadmin aptly snapshot drop buster-main-snapshot-$(date +%Y%m%d --date="yesterday")
sudo -u repoadmin aptly snapshot drop buster-updates-snapshot-$(date +%Y%m%d --date="yesterday")
sudo -u repoadmin aptly snapshot drop buster-security-snapshot-$(date +%Y%m%d --date="yesterday")

 

Durch folgende Zeile können wir eine Grafik exportieren und veröffentlichen:

sudo -u repoadmin aptly graph -output /srv/aptly/.aptly/public/graph.png