Automatisch updaten CentOS....slim?

[Yzord]

Een van de security measures die je kan nemen om je systeem up to date te houden is via een cronjob yum update uit te voeren. Dit wordt zelfs aanbvolen door CentOS zelf (https://wiki.centos.org/HowTos/OS_Protection). Maar in hoeverre is dit slim?

Waarom vraag ik dit? Ik heb ooit in het verleden een vervelende update mogen meemaken welke mijn hele server plat gooide. Dit heeft mij twee dagen gekost om uiteindelijk er achter te komen dat je niet een apt-get update moet uitvoeren als je DirectAdmin hebt draaien. Dit schijnt niet zo jofel te zijn onderling. Want DA zou afhankelijk zijn van specifieke pakketten. Sindsdien ben ik gestopt met het automatisch updaten van een server.

Maar om nu elke dag op al mijn servers een yum update te draaien begint me zo'n beetje de neus uit te hangen. Je weet wel wat er allemaal gebeurt, maar het kan soms ook best vervelend zijn. Dus dacht ik er aan om weer via een cronjob een automatische update in te stellen.

Maar voordat ik dat doe zou ik graag de (juiste) achterliggende gedachte achter de updates willen zien. Want is het zo dat ze alleen maar updates uitbrengen die compatible zijn of kan het ook zomaar zijn dat er updates worden uitgebracht die het een en het ander overhoop kan halen (zoals configs). Wat is de precieze achterliggende gedachte hier achter?

Kan ik zomaar een job instellen die een update uitvoert? Of moet je daar toch voorzichtig mee zijn?

[DJMaze]

Hangt er van af wat je allemaal ingesteld hebt staan.
Op mijn servers heb ik de /etc/my.cnf aangepast met:

code:

[client]
default-character-set=utf8mb4

[mysql]
default-character-set=utf8mb4

[mysqld]
character-set-server = utf8mb4

Bij elke mysql update veranderd yum/cpanel de 'default-character-set' met 'character-set-server' en moet ik handmatig het weer repareren.
Cpanel update dus zelf de packages (kan je uit zetten).

Een andere server zonder control panel draai ik gewoon 1x per week een update handmatig, en tot nu toe zonder problemen.
Op deze zou automatisch updaten geen probleem zijn.

Misschien gewoon per server bepalen of het nuttig is of niet?

[amx]

Ik draai op mijn eigen computer momenteel Fedora. Hiervoor Ubuntu.

Ikzelf heb de ervaring dat er wel problemen kunnen ontstaan. Ik heb een videokaart waarvoor Nvidia drivers nodig zijn. Na iedere OS update waarbij het versienummer verandert, ontbreken de videokaartdrivers in de corresponderende versiemap. Ik ga dan buiten de GUI om naar mijn homefolder en installeer de videokaartdrivers opnieuw. Na een reboot werkt het dan weer prima.

Bij Ubuntu heb ik het opgegeven na een systeemupdate en de GUI niet meer opstartte (toen Fedora geïnstalleerd).

[CAPSLOCK2000]

Het is natuurlijk een afweging tussen tussen gemak en veiligheid, die afweging kun je alleen zelf maken.
Als professioneel beheerder heb ik een hekel aan DA omdat het je gewone beheer in de weg zit, zoals je aan den lijve hebt ondervonden.

Ik heb voor zo veel mogelijk systemen een testomgeving en een productieomgeving. De testomgeving wordt automatisch gepatched. Dat doen we niet 's nachts maar juist tijdens kantooruren zodat we aanwezig zijn om problemen op te lossen als die toch optreden.

Goede monitoring is daarbij ook belangrijk zodat je onmiddellijk kan ingrijpen als het nodig is.

Om even wat concreter op je vragen in te gaan: centos is de gratis variant van RHEL en volgt RHEL nauwgezet. RHEL (en dus centos) is een stabiele distributie waarbij patches in principe compatible blijven.

[Yzord]

Even voor de goede orde, ik draai geen DA meer of enige andere console. Alles loopt via shell.

Welke monitoring adviseren jullie? Zabbix? NewRelic? heb in principe een Zabbix server en client draaien erop.

Ik ga mijn testomgeving ook maar eens voorzien van een automatische yum job. niet eens zo'n slecht idee

[Bigs]

Binnen een CentOS release kom ik eigenlijk zelden issues tegen met updates. Met release updates (bijvoorbeeld 6.5 naar 6.6) zijn er wel eens issues ontstaan door updates in bepaalde libraries waarvan de ABI toch niet 100% overeen bleek te komen. Ik weet niet of je daar in zo'n cronjob onderscheid in kan maken, anders zou je de update kunnen overslaan als er een centos-release package update in zit en jezelf notificeren zodat je die handmatig kunt doen.

Ga je automatisch rebooten na zo'n update als dat nodig is?

[ Voor 6% gewijzigd door Bigs op 05-02-2016 16:18 ]

[deadinspace]

Ik draai uitsluitend Debian, dus mijn advies is niet toegespitst op CentOS/rpm, maar misschien heb je er toch wat aan.

Ik beheer redelijk wat servers voor mijn werk, en ook nog een handvol privé-machines, en uiteindelijk was het me veel te veel werk om dat allemaal met de hand bij te houden, met als gevolg dat er ook regelmatig updates vergeten werden.

Daarom doe ik tegenwoordig vrijwel overal automatische security updates (met unattended-upgrades). Al die machines draaien Debian stable, en de automatische updates gelden alleen voor security updates, niet voor point releases (in Debian kun je daar iig onderscheid op maken).

Een alternatief is om niet automatisch te updaten, maar te mailen als er updates beschikbaar zijn. Apticron is een programma dat dat doet voor Debian. Ik ben nog aan het experimenteren met de combinatie unattended-upgrades voor het automatisch toepassen van security updates + apticron om te mailen over overige updates.

We hebben wel eens issues gehad met updates (of eigenlijk vooral: bestaande issues die getriggerd werden door updates), maar niet erg vaak. En uiteindelijk vonden we het belangrijker dat de systemen secure waren.

[Yzord]

Thanks! Bij pakket yum-cron kan ik idd aangeven welke updates ik wil hebben. Of alleen security updates of minimal update etc. etc. dus ik ga eens kijken of ik daar iets mee kan.

[Hero of Time]

Het automatisch laten toepassen van updates kan goed gaan, maar als je specifieke configuratie hebt die Yum doodleuk overschrijft dan is dat natuurlijk niet zo fijn en moet je hier op letten. Daarnaast moet je ook letten op welke repositories je hebt toegevoegd. Sommige repo's bieden geen scheiding van versies en kan je zomaar naar een nieuwe major versie gaan van bepaalde software en werkt het niet meer.

Gebruik van 'beheer' software zoals een DirectAdmin en cPanel gaan vaak stuk of slopen zelf de boel. Het lijkt in eerste instantie mooi en leuk, maar je krijgt uiteindelijk meer narigheid dan dat het werk uit handen haalt. Goed dat je dat soort rommel niet meer gebruikt.

[Bigs]

Yum overschrijft nooit configuraties. Als er al wijzigingen zijn dan worden die opgeslagen in een .rpmnew bestand.

[Rainmaker]

Enkel als je configuratie in een "herkende" directory staat. Bijvoorbeeld in /etc.

Maar het kan ook nog wel eens gebeuren dat jouw applicatie zijn configuratie in /opt/app/conf/... bewaard. In dat geval wordt je file gewoon overschreven (kun je volgens mij wel een extra check op zetten: als sum anders is dan file die origineel geplaatst is, niet overschrijven)

[ddkiller0900]

Yzord schreef op vrijdag 05 februari 2016 @ 16:09:
Even voor de goede orde, ik draai geen DA meer of enige andere console. Alles loopt via shell.

Welke monitoring adviseren jullie? Zabbix? NewRelic? heb in principe een Zabbix server en client draaien erop.

Ik ga mijn testomgeving ook maar eens voorzien van een automatische yum job. niet eens zo'n slecht idee

Wat monitoring betreft, op mijn werk gebruiken we Zabbix voor onze servers.

Binnen mijn eigen bedrijf wou een klant graag gebruik maken van Icinga. Het is vergelijkbaar met Nagios. Hiermee monitor ik onder andere of er updates beschikbaar zijn. Of alle updates automatisch uitgevoerd kunnen worden hangt vooral af van je setup. Ik doe dan ook eerst updates uitvoeren in een testomgeving en uiteraard release notes nalezen.

[powerboat]

Voor mijn virtuele ubuntu dozen doe ik van te voren eest een snapshot maken en daarna de updates uitvoeren.

Je zou dit, eventueel met een tool zoals rundeck centraal kunnen automatiseren.

Dit laatse is iets waar ik.nog mee.bezig ben.

[Bigs]

Rainmaker schreef op zondag 07 februari 2016 @ 13:27:
Enkel als je configuratie in een "herkende" directory staat. Bijvoorbeeld in /etc.

Maar het kan ook nog wel eens gebeuren dat jouw applicatie zijn configuratie in /opt/app/conf/... bewaard. In dat geval wordt je file gewoon overschreven (kun je volgens mij wel een extra check op zetten: als sum anders is dan file die origineel geplaatst is, niet overschrijven)

Ok laat ik in dat geval mijn statement wat aanpassen: Het automatisch updaten van packages uit de standaard CentOS-* repositories gaat prolbeemloos. Van EPEL staan me ook geen problemen bij. Met overige 3rd party zaken zou ik oppassen.

[DSK]

Als het over meerdere systemen gaat, is het een goed idee om te kijken naar iets als Spacewalk.

Dit zorgt ervoor dat je netjes een overzicht blijft houden van welke systemen nog updates moeten hebben en wat precies een update zal krijgen. Van uit Spacewalk zelf kun je dan ook de updates uitvoeren en opvolgen. Bijkomend voordeel is dat Spacewalk de updates in cache opslaat zodat ze slechts eenmalig moeten gedownload worden (eerste sync is wel minder prettig over het algemeen )

Automatisch laten updaten heb ik toch minder goede ervaring mee zoals overschrijven van config-files (geen .rpmnew aanmaken bijvoorbeeld) of zoals eerder al gemeld het niet meer compatible zijn met bestaande config-files van de nieuwe versies (al meegemaakt met bijvoorbeeld Apache of Varnish).

[Kees]

DSK schreef op maandag 08 februari 2016 @ 15:40:

Automatisch laten updaten heb ik toch minder goede ervaring mee zoals overschrijven van config-files (geen .rpmnew aanmaken bijvoorbeeld) of zoals eerder al gemeld het niet meer compatible zijn met bestaande config-files van de nieuwe versies (al meegemaakt met bijvoorbeeld Apache of Varnish).

Daarom draai ik Ubuntu LTS op mijn servers, die halen geen fratsen uit zoals apache2.2 updaten naar apache 2.4 waardoor je config problemen krijgt. Op die LTS servers installeer ik ook automatisch de security updates.

Daarnaast houd ik met zabbix bij welke servers updates hebben staan en die update ik 1-2 keer per week handmatig (eerst op een testomgeving, daarna met cssh op productie).

De afgelopen 5 jaar is dat nooit mis gegaan. Niet werkende configs komen alleen voor met release-upgrades, en configfiles overschrijven heb ik nog niet meegemaakt.

[init6]

Bigs schreef op zaterdag 06 februari 2016 @ 08:19:
Yum overschrijft nooit configuraties. Als er al wijzigingen zijn dan worden die opgeslagen in een .rpmnew bestand.

Dit, en enkel yum security updates draaien is nooit onverstandig. Met yum (dnf) history kan je altijd achterhalen wat er gedaan is. Als je niet default EPEL of andere externe repo's laat patchen is er geen enkel probleem.

Nog beter is het plannen van een failure. Kortom je data op een andere locatie (dan bijv je /root dir ) en het liefst gerepliceerd (backups) en je OS dmv automatisering snel te herinstalleren maken. Dingen gaan kapot, en als je 2 dagen niet zonder een systeem kan is het misschien eens een idee om naar ansible / cobbler / maas / razor / salt / cfengine / puppet / chef te kijken.

Het versionen van je infrastructuur en op deze manier uitrollen kan nooit kwaad.

[ Voor 7% gewijzigd door init6 op 15-02-2016 23:06 ]