Mit Ansible konnte ich mich nie anfreunden. Da war ich zu faul zu 
Wenn keiner ein Zaubertool postet, wird es wohl einfach das unattended mit der (fast) default config.
Wenn dazu jemand noch Tipps hat - gerne...
Die Dist wechseln werd ich in meinem Alter wohl nicht mehr...
Da war ich zu faul zu
Dafür sollte ein LLM tatsächlich hilfreich sein. Hab das früher auch für den Job gemacht, privat ist mir das too much und debian auto-update regelt, inklusive auto-restart. Hab auch keinen so großen Fuhrpark.
Ich möchte ja, dass auf 30-50 Servern, mit oft völlig verschiedenen Configs, möglichst schnell jeder CVS Patch, oder zumindest jedes entsprechende Paketupdate eingespielt wird.
Ich denke da diesbezüglich bzw. im Zusammenhang mit der durchaus unterschiedlichen Patchperformance (24-48h später) eher über eine eigene Package-Build-Strecke und dann eigenem Repo nach. Ziel ist patchen schneller als KI auf Basis Patch das passende Angriffswerkzeug bauen kann.
Der Punkt ist dann, dass die Distribution das selbsterstellte Package mit der eigenen Aktualisierung dann bitte wieder überschreibt, also hat das eigene Package prio 150 statt 100 default. Und dann unattended nur aus dem privat-Repo - und erst nachdem das einmal getestet wurde. Das ist quasi aber schon das Ende des Prozesses.
Wo ich noch keine Idee habe ist die klare Definition der Patchbasis.
d.h. das source-paket auf distri-Versionsstand (das ist jetzt bei Debian nicht wirklich ein Problem) oder auch einem anderen Stand (der dann zu beschaffen wär), sowie der passende Patch zum CVS. Und das zwecks Performance automatisiert - egal ob es ein Kernel, ein PHP oder sonstwas ist.
Um überhaupt zu wissen, was man tatsächlich alles braucht braucht man eine Paketinventarisierung der Server. Das dient auch dazu, nicht irgendwas zu bauen sondern in der richtigen Reihenfolge.
Wo ich noch keine Idee habe ist die klare Definition der Patchbasis.
Ich habe schon überlegt, Netcup zu bitten, ein eigenes Repo für die selbst gepatchten Pakete zu erstellen.
Einen lokalen Debian Mirror betreibt sie ja eh. Dann sowas wie "local-patches" zuzufügen, mit 150.
Die selbst gepatchten Pakete werden ja eh für den Eigengebrauch gebaut. Dann könte der Autoupdater die direkt lokal ziehen.
Ein Risiko sind dann eben die Trittbrettfahrer...
Ich denke da diesbezüglich bzw. im Zusammenhang mit der durchaus unterschiedlichen Patchperformance (24-48h später) eher über eine eigene Package-Build-Strecke und dann eigenem Repo nach. Ziel ist patchen schneller als KI auf Basis Patch das passende Angriffswerkzeug bauen kann.
[…]
Wo ich noch keine Idee habe ist die klare Definition der Patchbasis.
(Durchaus ein interessantes Thema; wenn sich mehrere Interessierte finden, kann man das ggf. in ein separates Unterforum hier verschieben.)
Aus eigener jahrelanger Erfahrung kann ich berichten, dass Punkt 1 oben ein sehr sportliches Ziel ist.
Sofern es möglich ist, immer die jeweils aktuelle stabile Debian-Version (aktuell "Trixie") zu verwenden, kann man zwar erforderliche Anpassungen etwas minimieren, aber …
Wenn man ältere Laufzeitumgebungen (bspw. Ubuntu Focal/20.04) aktualisieren will/muss, ist man nach wenigen Jahren(!) – manchmal bereits, wenn es gilt, Pakete von Ubuntu Jammy/22.04 zu übernehmen – damit konfrontiert, dass grundlegende Bibliotheken bisweilen neu "zugeschnitten" werden, d.h. man muss etwas bei Focal zusätzliche Bibliotheken dazulinken. Wenn man ("sehr") neue C-Quellcodes mit ("sehr") alten GCC-Versionen übersetzen will, kann das auch schnell ins Auge gehen; umgekehrt muss man auch die GCC-Versionen für die älteren Umgebungen aktuell halten. Auch Konfigurationsdateien (nicht nur rund um SystemD) enthalten oft subtile Änderungen.
(Wenn man meint, man muss die Pakete nur in der historischen Reihenfolge aktualisieren, wie sie bspw. auf https://snapshot.debian.org/ archiviert wurden, wird man irgendwann feststellen, dass die Paketierer hier und dort mit modifizierten Build-Umgebungen gearbeitet haben, welche sich nicht automatisch nachbauen lassen. Schon der Bau von gcc-11 für Ubuntu Focal auf Ubuntu-Quellpaketbasis war eine Qual.)
Je nach betroffener Applikation kann es ratsam sein, eigene Container dafür einzurichten, die dann natürlich auch alle einzeln mit Fixes für Basisbibliotheken versorgt werden müssen. Alles sehr zeitintensiv und eine genaue Planung erfordernd. Wenn mehrere Architekturen unterstützt werden sollen und nicht nur amd64/x86_64 wird's noch "lustiger" …
Grundsätzlich würde ich den Aussagen m_ueberall fast vollständig zustimmen.
Alles sehr zeitintensiv und eine genaue Planung erfordernd.
Entscheidend ist am Ende die Nachhaltigkeit und das Durchhaltevermögen.
Einmal schneller zu sein als die Distributoren, die das professionell machen ist nicht so schwer. Das über viele Jahre durchzuhalten ist die eigentliche Kunst. Das darf beispielsweise schon nicht daran scheitern, dass der "zuständige" Mitarbeiter gerade im Urlaub oder auf Kundenprojekt ist.
Warum ist mein Server nicht eine Stunde bevor ich bestelle schon freigeschaltet?
Ich bin ja immer noch dafür das FedEx sich blaue britische Polizeinotruf Telefonzellen besorgt, sich zu T.A.R.D.E.X umbenennt und Pakete liefert bevor sie versendet wurden!
Wird zeit für QualityLand
Wenn keiner ein Zaubertool postet, wird es wohl einfach das unattended mit der (fast) default config.
Wenn dazu jemand noch Tipps hat - gerne...
wenn es dir nur darum geht updates auf einem apt basierten OS aus zu rollen: schau dir mal den apt-dater an. solang du nicht in die tausende System gehst funktioniert der ganz gut. irgendwann skaliert der aber nicht mehr. Wird aber glaub schon seit Jahren sich mehr weiter entwickelt.
Öhm, bevor man jetzt hier anfängt, Pakete selbst zusammenzuschrauben (halte ich für nahezu unmöglich umzusetzen, erst recht automatisiert), sollte man drüber nachdenken, das OS so weit wie möglich abzuspecken (ein Paket das nicht installiert ist kann nicht ausgenutzt werden)l mit der NC Firewall abzuriegeln und Anwendungen nur per Container (z.B. Docker) laufen zu lassen.
Diese können sehr schnell und einfach aktualisiert werden. Also Server auf unattended-upgrades lassen, eine Automation bauen, die den Server zeitgesteuert neu startet (nachts) wenn nötig. Hierfür ist ein Restart Zeitpunkt für nachts bei mir definiert.
Ich habe für alle Server ein privates GitHub Repo für die Docker-Compose Files und verwende https://github.com/renovatebot/renovate , um die Tags der Container zu aktualisieren. Ein automatischer Check auf den Servern alle 10 Minuten sorgt dafür, dass bei Tag Änderungen auf GitHub die Container aktualisiert werden. D.h. Renovate sieht Änderungen, es wird ein PR dafür auf GitHub erstellt. Für unkritische Container lasse ich auto-mergen, für kritische lasse ich den PR stehen und kann ihn selbst mergen, zudem kann man auch Container (z.B. Datenbanken) ganz ausnehmen.
Zu dem Prozess gehört auch noch ein https://garethgeorge.github.io/backrest/ Backup, inklusive vorherigem Stop und Dump von Datenbankcontainern auf eine Hetzer Storage Box.
Über alle o.g. Themen werde ich morgens mittels Telegram Bot benachrichtigt.
Das Setup ist nahezu hands-off, trotzdem sicher, immer aktuell und ich bin informiert. Ich habe das mit AI entwickelt, das gehört zu meinem Standardsetup und wird automatisch so eingerichtet, wenn ich mit Claude einen neuen Server einrichte.
Auf vierzehneinhalb Seiten die selbe Domain, 87 mal für in Summe 2.349,00 € netto... steht's bei netcup derzeit so schlecht um die Finanzen? 
Auf vierzehneinhalb Seiten die selbe Domain, 87 mal für in Summe 2.349,00 € netto... steht's bei netcup derzeit so schlecht um die Finanzen?
hab es mal weitergegeben. Ein paar weitere Seiten bekommen wir bestimmt noch dazu 
hab es mal weitergegeben
Ist ansonsten auch schon mit NCSUP-1047733 reklamiert
Die Domain wollte ich eigentlich wie eine andere .online vor zwei Wochen schon wegtransferieren, der Transfer ist aber immer gescheitert - ich hatte vermutet, weil die Domain intern schon in der Verrechnung fürs renewel war oder so. Die andere die ich transferieren konnte war erst für ein paar Tage später fürs renewel vorgesehen.
Auf vierzehneinhalb Seiten die selbe Domain, 87 mal für in Summe 2.349,00 € netto... steht's bei netcup derzeit so schlecht um die Finanzen?
Sieht so aus als Dein CloudDNS schon auf das allerneuste Netcup Produkt RedundantDNS umgestellt wurde...
Hauptsache DNSSEC funktioniert 
Ich habe für alle Server ein privates GitHub Repo für die Docker-Compose Files und verwende https://github.com/renovatebot/renovate , um die Tags der Container zu aktualisieren. Ein automatischer Check auf den Servern alle 10 Minuten sorgt dafür, dass bei Tag Änderungen auf GitHub die Container aktualisiert werden. D.h. Renovate sieht Änderungen, es wird ein PR dafür auf GitHub erstellt. Für unkritische Container lasse ich auto-mergen, für kritische lasse ich den PR stehen und kann ihn selbst mergen, zudem kann man auch Container (z.B. Datenbanken) ganz ausnehmen.
Was ist von dockcheck.sh zu halten? (mag37/dockcheck auf github)
Ich hatte vor "dockcheck.sh" in meine täglichen cronjobs einzubauen und mch dann benachrichtigen zu lassen, falls es Updstes von meinen docker compose Images gibt. (Ich mache das Update dann lieber selbst, statt es automatisch zu ziehen)
Was ist von dockcheck.sh zu halten? (mag37/dockcheck auf github)
Ich hatte vor "dockcheck.sh -p -n" in meine täglichen cronjobs einzubauen und mch dann benachrichtigen zu lassen, falls es Updstes von meinen docker compose Images gibt. (Ich mache das Update dann lieber selbst, statt es automatisch zu ziehen)
Sämtliche Open Source Projekte haben ja irgendeine Art Git Repo, wo sie ihre Releases veröffentlichen. Ich habe einfach bei den Projekten, die ich nutze oder von denen ich Container im Einsatz habe, den Release Feed abboniert und bekomme die Benachrichtungen daher direkt so in die Mailbox (oder in meinen RSS Feed gespült). Da braucht es gar keine Extra Tools für. Bei Github geht das ganz einfach über Watch -> Releases.
Der Punkt ist dann, dass die Distribution das selbsterstellte Package mit der eigenen Aktualisierung dann bitte wieder überschreibt, also hat das eigene Package prio 150 statt 100 default.
Bei Debian kann man das übrigens wunderbar ohne Prioritäten in der APT-Konfiguration lösen. Die ganzen Suffixe wie -, + oder ~ haben nämlich bereits eine interne Priorität beim Vergleich der Versionsnummern. Dadurch reicht es i.d.R. das eigene Repo in die sources.list hinzuzufügen und den GPG-Public-Key (bzw. im Idealfall ein Paket das diesen beinhaltet) zu installieren.
Wenn man an eine bestehende Versionsnummer z.B. +0local1 anhängt (und nur die Zahl ganz am Ende hochzählt), kann man sich sicher sein, dass das nächste Update (bei offiziellen Paketen) als neuer erkannt wird. Das gilt auch für Backports, NMUs (Non Maintainer Uploads) und den seltenen Sonderfall von binNMUs. Sogar [E]LTS macht dann keine Probleme und überschreibt die eigenen gepatchten Pakete wieder.
Schaden würde APT-Pinning aber natürlich trotzdem nicht, ist dann halt ein zusätzliches Sicherheitsnetz.
Was ist von dockcheck.sh zu halten? (mag37/dockcheck auf github)
Ich hatte vor "dockcheck.sh" in meine täglichen cronjobs einzubauen und mch dann benachrichtigen zu lassen, falls es Updstes von meinen docker compose Images gibt. (Ich mache das Update dann lieber selbst, statt es automatisch zu ziehen)
Kann man machen, hab ich auch ge-star-red auf Github. Aber da ich eh eine Sicherheitskopie meiner compose Files in Github (privat) haben möchte, lag mir der renovate Prozess näher. Zudem finde ich das mit dem teils automatisch updaten lassen und teils selbst überprüfen top, man muss bei der manuellen Überprüfung nur den PR mergen (ein Buttonklick in der Github App) um das Update semi-manuell anzustoßen.
Sich nur benachrichtigen lassen wäre für mich viel zu manuell und würde zu lange dauern (Sicherheitsaspekt). Hast Du wirklich JEDEN TAG 24/7 Zeit, um Deine Server zu aktualisieren? Stellst Du den Wecker nachts um 4 Uhr zum manuell aktualisieren, um den Impact bei den Benutzern zu minimieren? Ich bekomme jeden Morgen ein Dossier aller Server auf Telegram, das mir den Zustand und ob neu gestartet werden musste erläutert. Das konsumiere ich innerhalb von 2 Minuten beim Frühstück und weiß dass alles läuft wie es soll.
Ja, klingt gut.
Ich habe allerdings nur eine Handvoll Container auf wenigen Servern. Und nichts wirklich kritisches dabei. (Bis auf einen)
Da kann ich das etwas lockerer angehen.
und Pakete liefert bevor sie versendet wurden!
Das kann aber auch nach hinten losgehn. S11E7. Kerblam!
