[Frage] eigenes Repository - Automatisches Update

[irmgard24]

Hallo

ich betreibe mehrere Server und suche eine Möglichkeit, diese automatisch mit Updates zu versorgen.

Es sollten nicht alle Server gleichzeitig upgedatet werden, falls es unerwartete Probleme nachdem Update auftreten. ( z.B.: Mailserver startet nicht mehr )

Deshalb will ich unterschiedliche Repository aufsetzen die Server dementsprechend zuordnen:
A_Repository - für Testserver
B_Repository - für Produktiv Server Gruppe 1
C_Repository - für Produktiv Server Gruppe 2

Ablauf:
Wenn alle Testserver nachdem Update ohne Fehler laufen, wird das B_Repository mit den Updates ausgestattet.
Somit werden die Server aus der Gruppe 1 mit den Updates versorgt.
Wenn alle Server von der Gruppe 1 ohne Fehler laufen, wird das C_Repositiy mit den Updates ausgestattet.
Somit werden die Server aus der Gruppe 2 mit den Updates versorgt.

Für die Automatische Installation verwendet ich unattended-upgrades.

Frage:
Wie synce ich die Repositorys?

Oder bin ich auf dem falschen Weg?

Wie wurdet Ihr das machen?
Gibt es dazu noch bessere Möglichkeiten?

Danke


Grüße Irmgard

[cosinus]

Wie wurdet Ihr das machen?

Ich hab auf jeder Debian-Kiste apticron installiert. Einmal pro Tag wird apticron ausgeführt und schaut nach Updates, das Ergebnis wird mir dann per E-Mail mitgeteilt. Da sieht man sehr gut welche Pakete auf welcher Kiste ein Update benötigen - dieses spiele ich dann manuell auch idR auf jedem Server ein.

Oder gehts dir auch darum, dass die Updates nicht doppelt und drei fach von jeder Kiste aus dem inet geladen werden? Falls ja, da könnte apt-cacher hilfreich sein.

[MSfree]

Deshalb will ich unterschiedliche Repository aufsetzen die Server dementsprechend zuordnen:
A_Repository - für Testserver
B_Repository - für Produktiv Server Gruppe 1
C_Repository - für Produktiv Server Gruppe 2

Ein eigenes Repository ist gar nicht nötig, es gibt Debian Snapshots für jeden Tag in der Vergangenheit. Siehe auch hier: https://snapshot.debian.org/

Du könntest also den Testserver am normalen, täglich aktualisierten Repository betreiben. B und C Repositories köntnest du einfach auf einen der Snapshots setzten.

[irmgard24]

Danke @MSfree + @cosinus

Debian Snapshots hört sich gut an, ich muss dazu aber immer wieder die apt sources.list anpassen ( mit dem aktuellen Datum).
Somit erfolgt die Updates nicht mehr automatisch.

apt-cacher schaue ich mir an.

Wie kann ich sonst Repository syncen, damit ich die Updates selber in der Hand habe.

Danke

[MSfree]

Debian Snapshots hört sich gut an, ich muss dazu aber immer wieder die apt sources.list anpassen ( mit dem aktuellen Datum).
Somit erfolgt die Updates nicht mehr automatisch.

Die Anpassung läßt sich doch automatisieren.

Wenn du meinst, daß dein Testsystem OK ist, kannst du eine sources.list für den aktuellen Tag (sktripgesteuert) erstellen und auf die beiden Produktivsysteme kopieren. Da du ja unattended Updates fahren willst, würde spätestens ein Tag nach dem Kopieren der sources.list das Upgrade auf den Produktivsystemen erfolgen.

[cosinus]

Wie kann ich sonst Repository syncen, damit ich die Updates selber in der Hand habe.

Wann nach Updates geschaut und wann die installiert werden hast du doch eh schon komplett selbst in der Hand. Linux ist nicht Windows
Richte doch mal erstmal auf der Testkiste apticron ein und lass dir den Bericht per Mail zustellen - apticron selbst schau nur nach den Updates aber installiert nichts.

[irmgard24]

Linux ist nicht Windows

und das ist gut so!

Die Anpassung läßt sich doch automatisieren.

Wenn du meinst, daß dein Testsystem OK ist, kannst du eine sources.list für den aktuellen Tag (sktripgesteuert) erstellen und auf die beiden Produktivsysteme kopieren. Da du ja unattended Updates fahren willst, würde spätestens ein Tag nach dem Kopieren der sources.list das Upgrade auf den Produktivsystemen erfolgen.

Sorry, habe ich nicht erwähnt. Ich habe teilweise keinen Zugriff mehr auf die Server, da diese hinter div. Firewall auf der Welt verteilt sind.
Somit kann ich die Source.list nicht mehr bearbeiten.

@Cosinus
Stimmt ich kann die Update selber bestimmen, es muss aber die Möglichkeit geben, damit die Server keine Updates mehr installieren, falls es ein Problem gibt.

Somit komme ich wohl um eigene Repositorys nicht rum...

[cosinus]

Ich verstehe dich nicht so richtig...
Autoupdates hast du aus. Wie also soll der Server die Updates installieren wenn du das selbst nicht anstößt? Du installierst die Updates erst auf deiner Testkiste. Wenn alles ok ist, dann updatest du die anderen Server. Und wenn du selbst nichts machst, macht Debian eben keine Updates.

Oder meist du was anderes?

[irmgard24]

Ich verstehe dich nicht so richtig...
Autoupdates hast du aus. Wie also soll der Server die Updates installieren wenn du das selbst nicht anstößt? Du installierst die Updates erst auf deiner Testkiste. Wenn alles ok ist, dann updatest du die anderen Server. Und wenn du selbst nichts machst, macht Debian eben keine Updates.

Oder meist du was anderes?

Auto Update sind auf allen Servern an.

Die Updates werden erst installiert, wenn die Updates auf dem Repository zu Verfügung steht.

Z.B:
A_Repository wird mit den aktuellen Updates gefüttert.
Die Update werden auf den Server aus der Gruppe Test installiert ( sources.list = deb http://test_repo.xxx.xxx/debian bullseye main non-free contrib )

Wenn alles funktioniert hat, wird das B_Repository mit den Updates gefüttert.
Die Update werden auf den Server aus der Gruppe Produktiv Server 1 installiert ( sources.list = deb http://gruppe1_repo.xxx.xxx/debian bullseye main non-free contrib )

Wenn alles funktioniert hat, wird das C_Repository mit den Updates gefüttert.
Die Update werden auf den Server aus der Gruppe Produktiv Server 2 installiert ( sources.list = deb http://gruppe2_repo.xxx.xxx/debian bullseye main non-free contrib )

So war meine Idee.

Nur wenn die Update auf dem Repository, werden die Updates automatisch installiert.

Ich muss man "nur" die Repository pflegen.

Oder gibt es was einfacheres?

[heisenberg]

Mir scheint Dein Ansatz (@irmgard24) sinnvoll zu sein.

Einfach einen Mirror per ftpsync [1] aufsetzen. Debian Mirror werden 4 Mal am Tag aktualisiert. Ich synchronisiere meinen Mirror ca. 1 Stunde danach. (3:30,9:30,15:30,21:30, CET). Der Mirror braucht derzeit ~ 600 GB für die Architekturen amd64 und i386.

Daneben kannst Du ja zwei weitere interne Mirror konfigurieren, die Du zeitversetzt lokal synchronisierst (rsync). Wichtig wird sein, dass die Mirrors möglichst immer nahezu 100% zuverlässig in konsistentem Zustand sind. D. h. die Version ist zwar egal, aber es sollte z. B. nicht vorkommen, dass ein Mirror nur halb synchronisiert ist und da noch Pakete fehlen. (Dann würden die Upgrades bei den Nutzern des Repos fehlschlagen.) Das ftpsync Script kümmert sich korrekt darum - weil es die Paketlisten von der Synchronsation ausschließt und erst nach der Synchronisation selbst neu erzeugt. Lokal kann man das so machen, dass man Verzeichnisse erst unter anderem Namen synchronisiert (z. B. verzeichnis.in-progress) und nach Abschluß der Synchronsation dann die Verzeichnisse umbenennt.

Beispiel:

Code: Alles auswählen

mkdir -p mirror-copy.in-progress

# das hier dauert mitunter ein paar Minuten
rsync -a mirror-upstream/. mirror-copy.in-progress/.

# das hier geschieht quasi instantan
mv mirror-copy mirror-copy.old
mv mirror-copy.in-progress mirror-copy

# Verzeichnis vorbereiten für den nächsten Mirror-Vorgang,
# so dass beide Verzeichnisse (mirror-copy und mirror-copy.in-progress) 
# den gleichen Stand haben.
mv mirror-copy.old mirror-copy.in-progress
rsync -a mirror-copy/. mirror-copy.in-progress/.

Dann das Ganze auf mehrere Webserver-VHosts aufgeteilt und dann hast Du Deine Mirror in verschiedenen Stages:

• upstream.debian.company.com (=1:1 Debian-Mirror für Testserver, A bei Dir)
• canary.debian.company.com (= Produktivserver Gruppe 1, B bei Dir, Canary = Metapher für ein Frühwarnsystem [2])
• stable.debian.company.com (= alle Server bzw. Produktivserver Gruppe 2. C bei Dir)

Snapshots und Deduplikation

Grundsätzlich könnte man da auch mit Dateisystemsnapshots (ZFS:ja / btrfs: Status laut Doku ok, aber keine eigenen Erfahrungen damit) arbeiten um Platz zu sparen; aber mir wäre das zu kompliziert. Da habe ich lieber X Mal 600 GB rumliegen und es ist dafür einfach. Falls der Platz wichtig ist, würde ich dann lieber Deduplizierung aktivieren (braucht ordentlich RAM!, ca. 5 GB pro 1 TB Daten [3]). 5 GB Zusatz-RAM für einen Debian-Mirror finde ich jetzt vernachlässigbar. D. h. das ZFS für den Debian-Mirror sollte dediziert nur für diese Daten erzeugt und genutzt werden.

Auf der anderen Seite kann man das ja auch mal mit Snapshots durchspielen. Vielleicht funktioniert das auch gut.

[1] https://www.debian.org/mirror/ftpmirror
[2] Metapher: Kanarienvogel und Kohleminen: WP:Kanarienvogel/Bergbau
[3] truenas.com: ZFS Deduplication

[cosinus]

Ach du willst das so steuern...sry da hab ich keine Erfahrung mit.
Ich hab es lieber wenn ich mehr Kontrolle hab, dafür muss ich dann aber auch selbst tätig werden also entsprechend auf jeden Server per SSH rauf und dann das Update durchführen. Den Reboot musst du doch eh planen bei Kernel- und systemd-Updates, oder nicht?

[irmgard24]

Mir scheint Dein Ansatz (@irmgard24) sinnvoll zu sein.

Einfach einen Mirror per ftpsync [1] aufsetzen. Debian Mirror werden 4 Mal am Tag aktualisiert. Ich synchronsiere meinen Mirror ca. 1 Stunde danach. (3:30,9:30,15:30,21:30, CET). Der Mirror braucht derzeit ~ 600 GB für die Architekturen amd64 und i386.

Danke für deinen Tipp, werde mal das Thema so umsetzen!

[heisenberg]

Schreibe gerne auch nochmal Informationen zum weiteren Verlauf dieser Aufgabe und was Du da ggf. noch für Erkenntnisse gewinnst.

[irmgard24]

[UPDATE]

Repository sind wie beschrieben und die ersten Server ziehen die Updates darüber... Sieht sehr gut aus!