[Linux] Hoe gaan jullie om met automatische updates

[Douweegbertje]

Ik heb standaard aan staan dat hij security packages mag upgraden... want security. Echter heb ik automatisch herstarten uit staan.
Mijn ervaring is dat je server dan ~3x per week herstart en dat is mij iets te gortig. Ik wil alle servers ~1x per maand herstarten op het moment dat het mij uitkomt.

Anyway.. fastforward naar gister met de volgende update:

2017-03-21 06:26:13 status installed libc6:amd64 2.19-0ubuntu6.10

En toen was het niet meer mogelijk om via PHP scripts domeinnamen te resolven totdat ik de server had herstart.

Vervolgens weer vandaag:

2017-03-22 06:27:21 status installed libc6:amd64 2.19-0ubuntu6.11

(betreft: https://security-tracker.debian.org/tracker/CVE-2015-5180)

Heel fijn, maar dit zorgde er dus voor dat er opeens functionaliteiten stuk waren en dat ik opeens een hele stack aan servers moest herstarten.

Ik ben dus zeer benieuwd hoe jullie hier mee omgaan. Wat is jullie update plan?

[Locke_]

Sowieso geen automatische updates. Ik heb een puppet server die 1x per maand op een zaterdagnacht een snapshot afdwingt van al mijn virtual servers en bij slagen daarvan de monitoring tijdelijk uitschakelt en de updates installeert. Na afloop wordt de server herstart en de monitoring weer ingeschakeld.

Ik wordt op zondagochtend getriggerd als er bepaalde applicaties of websites niet meer werken en dan is het een kwestie van snapshot terugdraaien en updates handmatig uitvoeren. Als er geen meldingen zijn, dan hoef ik enkel de snapshots te verwijderen (dit ga ik nog automatiseren).

Kost een beetje werk om op te zetten, maar kost daarna nauwelijks nog echt werk.

[Douweegbertje]

Is het zo logisch dan om automatische security updates uit te zetten? Technisch gezien kun je dan 1 maand (of afhankelijk van je interval) kwetsbaar zijn.

[Question Mark]

Wat is je grote probleem met het herstarten dan?

Als dat beschikbaarheid van services is, is dat het probleem wat je moet gaan tackelen.

[gekkie]

Douweegbertje schreef op woensdag 22 maart 2017 @ 16:41:
Ik heb standaard aan staan dat hij security packages mag upgraden... want security. Echter heb ik automatisch herstarten uit staan.
Mijn ervaring is dat je server dan ~3x per week herstart en dat is mij iets te gortig. Ik wil alle servers ~1x per maand herstarten op het moment dat het mij uitkomt.

Anyway.. fastforward naar gister met de volgende update:

2017-03-21 06:26:13 status installed libc6:amd64 2.19-0ubuntu6.10

En toen was het niet meer mogelijk om via PHP scripts domeinnamen te resolven totdat ik de server had herstart.

Vervolgens weer vandaag:

2017-03-22 06:27:21 status installed libc6:amd64 2.19-0ubuntu6.11

(betreft: https://security-tracker.debian.org/tracker/CVE-2015-5180)

Heel fijn, maar dit zorgde er dus voor dat er opeens functionaliteiten stuk waren en dat ik opeens een hele stack aan servers moest herstarten.

Ik ben dus zeer benieuwd hoe jullie hier mee omgaan. Wat is jullie update plan?

Automatisch herstarten komt nou ook weer niet zo vaak voor toch ?
(bij alles behalve kernel, libc en init packages is dat eigenlijk niet nodig, tis immers geen ms windows)

Maar goed ik heb het wel uitstaan automatisch rebooten, unattended upgrades mailt me wat er gebeurd is vroeg in de ochtend en desnoods schedule ik handmatig een rebootje.
Laptops doe ik handmatig, maar goed die draaien dan ook testing en dat heeft geen echte security updates maar soms wel wat kleine (en tijdelijke) probleempjes in package dependencies.

[Douweegbertje]

Question Mark schreef op woensdag 22 maart 2017 @ 20:06:
Wat is je grote probleem met het herstarten dan?

Als dat beschikbaarheid van services is, is dat het probleem wat je moet gaan tackelen.

Het herstarten an sich niet, wel dat het kan gebeuren als je het net even niet wilt. Het betreft ook een wat grotere stack van servers (200+) en ik wil niet dat op een random dag alles een reboot krijgt.

Hoe dan ook moet ik aanwezig zijn om achteraf te checken of alles ok is gegaan. Ik zie het liever ook als een stuk onderhouds window.

Het idee is om nu een server op te zetten, daar de updates uit te voeren inclusief wat testen om vervolgens het op de gehele stack door te voeren.

[Question Mark]

Er overigens via een topicreport terecht opgemerkt dat dit topic beter in Non-Windows Operating Systems thuishoort.

Ik verplaats hem dan ook even.

[gekkie]

Douweegbertje schreef op woensdag 22 maart 2017 @ 21:07:
[...]


Het herstarten an sich niet, wel dat het kan gebeuren als je het net even niet wilt. Het betreft ook een wat grotere stack van servers (200+) en ik wil niet dat op een random dag alles een reboot krijgt.

Hoe dan ook moet ik aanwezig zijn om achteraf te checken of alles ok is gegaan. Ik zie het liever ook als een stuk onderhouds window.

Het idee is om nu een server op te zetten, daar de updates uit te voeren inclusief wat testen om vervolgens het op de gehele stack door te voeren.

Dan wat Locke_ doet .. alleen dan wellicht wat frequenter dan 1x per maand (op basis van eigen inschatting van de ernstig en relevantie van de updates tov de impact van reboots een afweging maken). Maar dan lijkt me config management wel een must inderdaad met 200+ servers, eventueel in een paar batches afwerken in een paar dagen.

[Hero of Time]

Question Mark schreef op woensdag 22 maart 2017 @ 21:10:
Er overigens via een topicreport terecht opgemerkt dat dit topic beter in Non-Windows Operating Systems thuishoort.

Ik verplaats hem dan ook even.

Maar die is eigelijk onzin, want SWS is niet Windows only. Het gaat hier om een server en een bepaald beleid dat beheerders houden. Het past daarom net zo goed in SWS. Ik maak er wel een alias heen, want het heeft raakvlakken op beide velden.

[CAPSLOCK2000]

Thuis staat alles op volledig automatisch updaten, dat is mijn speeltuin, daar is alles wat stuk gaat een leerzame ervaring

Op m'n werk maak ik onderscheid tussen productie en niet-productie, clusters en stand-alone (en nog wat "speciale gevallen", wie heeft ze niet).

Niet-productie update alles volledig automatisch en de meeste systemen mogen (op vaste tijden) automatisch rebooten. Ze updaten en rebooten niet allemaal tegelijkertijd waardoor clusters met een beetje geluk normaal gesproken geen down-time hebben. Patchen gebeurt overdag zodat we kunnen ingrijpen als er iets mis gaat. Het gaat bijna altijd goed, en als het een keer mis gaat, dan is het maar de test-omgeving en leren we er hopelijk iets van.

De meeste productiesystemen installeren automatisch security updates. Reguliere updates en reboots worden eens per maand gedaan. Clusters worden zoveel mogelijk gespreid gedaan ('s ochtends de ene node, 's middags de andere).

Alle systemen worden regelmatige gepatched en gereboot en vrijwel allemaal tijdens kantooruren. Als het belangrijk is moet het toch dubbel worden uitgevoerd, alles kan immers stuk gaan.

We vertrouwen zwaar op goede monitoring om problemen vroegtijdig te ontdekken, liefst in de test-omgeving.

[Kees]

Op productie doe ik security updates (waaronder deze libc) automatisch. Ik heb er gelukkig geen last van gehad dat PHP niet meer wilde resolven (omdat apache niet werd gerestart), maar het zou de eerste keer in vele jaren zijn dat het mis zou zijn gegaan.

Daarnaast heb ik monitoring op het aantal updates dat beschikbaar is op de servers en zodra dat >0 is dan update ik de testservers en een uur later de productieservers, uiteraard tijdens kantooruren want daarvoor heb ik genoeg servers. Dat is ook het moment dat ik bekijk of er services gerestart moeten worden voor de automatische security updates (vrijwel nooit).

Ik heb hele slechte ervaringen met eens per maand updaten; voornamelijk dat je dan zo'n grote berg updates krijgt dat je niet meer kan achterhalen welke update er voor problemen zorgt. Daarnaast ben je dan soms een maand lang kwetsbaar voor bepaalde problemen. Dat kan en mag niet.

Neem een eenvoudig detecteerbare exploit als bashshock. Die werd bekend gemaakt en binnen een paar minuten nadat wij daarover hadden geschreven zag ik de eerste tests ervoor al op onze servers binnenkomen. En de weken daarna hebben vele duizenden mensen gekeken of onze servers kwetsbaar waren. Idemdito voor Heartbleed en andere exploits.

Ik hoef bij ssllabs ook niet vaak een nieuwe test af te dwingen, meestal staat er wel een recent gecachte versie klaar. Dus nee, updates een maand uitstellen is geen goed plan.

In totaal gaat het om zo'n 50 servers+vm's, dus updaten lukt nog vrij eenvoudig met clusterssh.

[ Voor 4% gewijzigd door Kees op 23-03-2017 09:43 ]

[Locke_]

Misschien nog even een aanvulling op wat ik eerder postte, alles wordt bepaald in de SLA die je met je klant(en) afspreekt. Ik heb een standaard maintenance window 1x per maand waarop ik zonder melding patches kan installeren op omgevingen.

Het is wel zo opgebouwd dat voor verschillende SLA's dat verschillende momenten kunnen zijn, dus het is niet per definitie zo dat alles op hetzelfde moment gaat. Alleen op dit moment is de praktijk wel zo.

Major security patches, zoals o.a. aangehaald door Kees, worden semi-handmatig gepushed (apart puppet script dat geactiveerd moet worden met enkel de specifieke patches) en worden asap maar wel in overleg met de klant geïnstalleerd (emergency maintenance).

Als je shared servers draait zul je iets van een emergency maintenance window moeten vastleggen in de SLA waardoor je zonder discussie (maar bij voorkeur wel met een aankondiging) sneller kunt patchen.