wie schaut das bei euch aus mit Sicherheitsupdates? Werden die bei euch auch auf Rechnern die sagen wir mal geschäftskritisch sind einfach eingespielt und die Daumen gedrückt oder hat jemand Erfahrungen mit gewissen Testprozedere?
Eine virtuelle Maschine oder gar ein physischer Rechner als Klon, bei welchem man die Sicherheitsupdates vorher einspielen kann und testen ob danach alles läuft, erscheint mir recht aufwendig.
Wie wäre es denn mit der Idee, auf dem jeweiligen Host ein chroot zu erstellen und darin die relevanten Applikationen zu kopieren, dann, wenn jeweils security updates anstehen, darin 'aptitude update && aptitude upgrade' auszuführen und schauen ob alles so läuft wie es soll?
Welche Haken könnte es da geben, bzw. wäre das evtl. viel aufwändiger bzw. zu ressourcenfressend auf dem Host selbst?
Oder was habt ihr da für Erfahrungen bzw. 'best practices'?
Testen vor security upgrade => in chroot?
Re: Testen vor security upgrade => in chroot?
Es kommt drauf an, was du dort für Software laufen hast. Einen allgemeingültigen Rat kann ich dir nicht geben, aber ich kann dir sagen wie ich es mache.
Meine zentral gewarteten Server haben die folgenden wichtigen Pakete samba, bind9,dhcp, squid, squid-guard, apache, webmin, ntp, mysql, cups. Es handelt sich also um typische Server für KMUs oder Schulen.
Ich betreibe solche Server seit 6 Jahren in Aussenstellen. Anfangs waren es 19 Stück, jetzt 34, die ich direkt betreue und dahinter nochmal 52, die meine configs und Updates bekommen, für die aber andere Admins hardwaremässig zuständig sind.
Und seit diesen 6 Jahren installieren wir die Updates über cron-apt nächtlich und unbeaufsichtigt ohne Probleme.
Problematisch wird es, wenn du Fremdquellen einbindest. Wenn du mehr benötigst, als dir stable bietet, dann setz dein eigenes repository auf und kopiere dir die Pakete dort hinein, nachdem du sie ausgiebig getestet hast. Eine gute Anleitung dazu gibts von Meillo hier im Wiki: http://wiki.debianforum.de/EigenesRepository
Ich kenne deine Definition von geschäftskritisch nicht. Wenn dein Job auf dem Spiel steht, wenn der zentrale Fileserver morgens für 2 Stunden still stehen sollte, dann spiel die Updates nicht automatisch ein
Ansonsten habe ich mir angewöhnt dist-upgrades in einer virtuellen Maschine durchzuspielen. Speziell Webanwendungen tendieren bei mir dazu mehr Arbeit zu machen, als ich vorher ahne (z.B. Plone).
Meine zentral gewarteten Server haben die folgenden wichtigen Pakete samba, bind9,dhcp, squid, squid-guard, apache, webmin, ntp, mysql, cups. Es handelt sich also um typische Server für KMUs oder Schulen.
Ich betreibe solche Server seit 6 Jahren in Aussenstellen. Anfangs waren es 19 Stück, jetzt 34, die ich direkt betreue und dahinter nochmal 52, die meine configs und Updates bekommen, für die aber andere Admins hardwaremässig zuständig sind.
Und seit diesen 6 Jahren installieren wir die Updates über cron-apt nächtlich und unbeaufsichtigt ohne Probleme.
Problematisch wird es, wenn du Fremdquellen einbindest. Wenn du mehr benötigst, als dir stable bietet, dann setz dein eigenes repository auf und kopiere dir die Pakete dort hinein, nachdem du sie ausgiebig getestet hast. Eine gute Anleitung dazu gibts von Meillo hier im Wiki: http://wiki.debianforum.de/EigenesRepository
Ich kenne deine Definition von geschäftskritisch nicht. Wenn dein Job auf dem Spiel steht, wenn der zentrale Fileserver morgens für 2 Stunden still stehen sollte, dann spiel die Updates nicht automatisch ein
Ansonsten habe ich mir angewöhnt dist-upgrades in einer virtuellen Maschine durchzuspielen. Speziell Webanwendungen tendieren bei mir dazu mehr Arbeit zu machen, als ich vorher ahne (z.B. Plone).
-
xdanx
- Beiträge: 473
- Registriert: 15.11.2007 22:07:42
- Lizenz eigener Beiträge: GNU General Public License
Re: Testen vor security upgrade => in chroot?
erstmal danke für deine Antwort 
aber es bleibt ja trotzdem der offene Punkt des Testens auf Regression bevor man es manuell macht
das klingt schonmal sehr beruhigend. Insbesondere wenn man noch hinzuzieht, dass ja inzwischen snapshot.debian.org auch freigegeben worden ist.ThorstenS hat geschrieben: Und seit diesen 6 Jahren installieren wir die Updates über cron-apt nächtlich und unbeaufsichtigt ohne Probleme.
das geschieht nur sporadisch, und wenn wird die Fremdquelle meistens gleich wieder auskommentiertThorstenS hat geschrieben: Problematisch wird es, wenn du Fremdquellen einbindest.
das ist trotzdem ein guter TippThorstenS hat geschrieben: Wenn du mehr benötigst, als dir stable bietet, dann setz dein eigenes repository auf und kopiere dir die Pakete dort hinein, nachdem du sie ausgiebig getestet hast. Eine gute Anleitung dazu gibts von Meillo hier im Wiki: http://wiki.debianforum.de/EigenesRepository
bei solchen Diensten hatte ich eh nicht an cron-apt gedachtThorstenS hat geschrieben: Ich kenne deine Definition von geschäftskritisch nicht. Wenn dein Job auf dem Spiel steht, wenn der zentrale Fileserver morgens für 2 Stunden still stehen sollte, dann spiel die Updates nicht automatisch ein
aber es bleibt ja trotzdem der offene Punkt des Testens auf Regression bevor man es manuell machthmm, ja an virtuelle Klone wird wohl kaum ein Weg drum herum führen...ThorstenS hat geschrieben: Ansonsten habe ich mir angewöhnt dist-upgrades in einer virtuellen Maschine durchzuspielen. Speziell Webanwendungen tendieren bei mir dazu mehr Arbeit zu machen, als ich vorher ahne (z.B. Plone).