Onderwerp: Unified Management... meningen gevraagd!

Beste WHT'ers,

Iedereen met (grotere) aantallen servers loopt er wel tegen aan, software upgrades, version management etc.

Nu word het merendeel van onze servers (vooral shared hosting servers met DirectAdmin) beheerd door onze eigen nocd. Een NOC daemon die communiceert met de noc servers, status informatie uitwisselt.. monitoring, batch execution (van die perl bots killen...). Via die daemon kunnen we ook commando's distribueren enz. blabla you get the picture.

Nu waar ik zelf persoonlijk een beetje moe van werd , is dat *telkens* wanneer er b.v. een upgrade uitkomt voor SpamAssasin / ClamAV / phpMyAdmin (Jezus the pain..) je dus op *ELKE* server moet inloggen, alles gaat upgraden om vervolgens tot 4 uur snachts ./configure *opts* && make && make install zit te tikken voordat je alle 30 bakken gehad hebt

Nu is dit via onze nocd een groot deel opgelost, we kunnen nu scripts inschieten voor elke server en dus het hele process automatiseren en we krijgen netjes een mailtje smorgens in de mailbox met de output als alles goed is gegaan (of een smsje if not..)

Maar nu zat ik het volgende bedenken, is het allicht beter om te werken via packages (.rpm, .deb enz) Dus een apt/yum repository aan te maken en dan via een simpele cronjob of iets dergelijks elke nacht alle updates e.d. binnen te laten halen en te installeren?

Mijn vraag is dus; Hoe gaan jullie om met patch-management / version-management? Distribueren jullie de updates lekker ouderwets via ./configure's en handen maatwerk of word het centraal geregeld voor e.o.a. package manager?

Graag jullie input!

Vroeger veel via manueel compilen gedaan, nu gentoo, freebsd of debian. Alles via de packaging systemen.

Weinig tot geen problemen om zo scripts over meerdere servers te runnen voor updates. Gewoon eerst testen op een dev-machine en een aantal maal door laten draaien.

Oorspronkelijk geplaatst door luser

Vroeger veel via manueel compilen gedaan, nu gentoo, freebsd of debian. Alles via de packaging systemen.

Weinig tot geen problemen om zo scripts over meerdere servers te runnen voor updates. Gewoon eerst testen op een dev-machine en een aantal maal door laten draaien.

Hmm, aan dergelijke oplossingen zat ik ook al te denken. Het nocd systeem via ./configure werkt nu wel lekker. Mijn opzet voor packaging was om dan b.v. een dev machine in te richten met een aantal VM's (b.v. dev-fc3, dev-fbsd) en daarop packages te builden aangezien het aantal distro's erg verschilt qua servers. ..

Maar nu zat ik het volgende bedenken, is het allicht beter om te werken via packages (.rpm, .deb enz) Dus een apt/yum repository aan te maken en dan via een simpele cronjob of iets dergelijks elke nacht alle updates e.d. binnen te laten halen en te installeren?

Daar zijn die packagemanagers voor he. Zo doe ik het iig. Via Centos. Op 1 server testen voordat de rest de job in gaan. Bijvoorbeeld op donderdag via cron de servers updaten... dan vlak van tevoren op 1 server testen.

Voor de standaard packages gebruiken de we standaard yum.
Voor de overige dingen maken we onze eigen .rpm's welke in onze eigen repos komt. Deze wordt ook door yum gebruikt en zal bij een update deze packages dan ook meenemen.

Net zoals hier boven dus al beschreven wordt. Wij laten de updates alleen niet automatisch snachts gaan omdat we eerst apart willen testen.