Bijhouden webserver software

[KeRsTmAnNeKe]

Waar ik werk hebben we nu 3 webservers, zijn we langzaam ingegroeid.
En aangezien ik zo'n beetje de enige ben met een beetje Linux kennis (draaien alle 3 CentOS 6) mag ik de boel bijhouden, waar ik ook in aan het groeien ben.

Maar in hoeverre is het verstandig alles bij te houden, as in, software updaten? Thuis in Windows hou ik alles goed bij, maar er draait op die servers wel wat kritischer spul, websites van wat klanten ed.

2 servers zijn managed, dus onze hostingpartij kan updates installeren als ik daarom vraag, de 3e moet ik helemaal zelf bijhouden en als er problemen zijn ben ik helemaal de lul.

Is het handig als er een nieuwe update binnen dezelfde versie (dus bv PHP 5.4.x niet PHP 5.4>5.5) deze redelijk vlot erop te zetten?

We zijn hier namelijk altijd al een beetje lui/onwetend in geweest en m'n collega's letten er eigenlijk niet op, zo hebben we 2+ jaar lang een server gehad waar volgens mij niks aan gedaan is aan updates aan PHP/MySQL/Apache enz totdat we enkele maanden geleden toch tegen wat beperkingen van PHP 5.2 gingen aanlopen, die ook al niet de meest recente versie was en toen de hele boel hebben laten updaten.

Gedoe met heartbleed laatst heeft mij toch aan het denken gezet... gelukkig was op 2 servers openssl wat ouder zodat deze er geen last van had. De 3e had wel een foute versie erop staan... welke volgens mij met een yum update verholpen is... Maar ook in dit geval krijg ik vanuit m'n collega's eigenlijk niks te horen of gewoon de vraag of er niet eens naar gekeken moet worden, zover ze er al iets van gehoord hebben.

Wat is het handigst met dit soort dingen, behalve het inhuren van iemand om de boel te beheren. Zorgen voor snelle updates, eens in de x tijd inplannen, of gewoon laten draaien zolang het blijft lopen...

[Kees]

Altijd bijhouden.

Als je een LTS draait dan zullen de updates in het algemeen niet heel veel gekke dingen veranderen, maar het is wel handig om dat te checken.

Dus update je eerst een test-server (die identiek is aan de productie servers) en kijk je of je applicatie nog werkt. Indien dat niet het geval is dan fix je je applicatie of server en zodra dat gereleased kan worden zorg je er ook voor dat je de productie omgeving bijwerkt. Verder moet je monitoring hebben die je op de hoogte houd van updates zodat je ook weet wanneer er een update beschikbaar is.

Overigens zul je (mijn ervaring is met ubuntu lts) er zeer zelden tegenaan lopen dat iets na een upgrade niet meer werkt (en in vrijwel alle gevallen over de recente jaren heen was het een library update zonder een apache restart waardoor apache ging segfaulten, wat opgelost werd met een apache restart).

Een LTS update doe je dan ook op je test-server, en ja ik zou toch wel proberen om de updates zo veel mogelijk bij te houden (kost je een half uurtje per week) want hoe langer je de updates laat ophopen, des te meer er stuk kan gaan als je eindelijk eens update.

En inderdaad, PHP upgrades moet je ook gewoon doen (en waarschijnlijk je applicatie fixen) en daar moet je gewoon tijd voor krijgen want het is best belangrijk om up to date te blijven.

[Cyphax]

Ik kan me voorstellen dat je, als je hier niet echt dagelijks mee bezig bent, op gegeven moment vergeet om te updaten als dat nodig is. Omdat ik bij ons de Debian-machines onderhoud heb ik me ingeschreven op de relevante mailinglist van Debian. Als er iets te updaten is, dan is dat een handige trigger.

Voor CentOS is er ook een mailinglist: http://lists.centos.org/mailman/listinfo/centos
Ik zou me daarop inschrijven als ik jou was.

Ik weet niet hoe CentOS omgaat met nieuwe versies. Bij Debian stable doen ze dat bijvoorbeeld niet: als je Apache 2.2 hebt, dan blijft dat ook 2.2, zodat er niet zo'n groot risico aan zit om een update door te voeren. De enige keer dat een update bij mij iets kapotmaakte was bij een update van Varnish waardoor door mijzelf gecompilede mods niet meer werkte (door het versieverschil).

[swbr]

CentOS is gecompiled uit de sources van RedHat, met niets meer dan een search/replace van RedHat naar CentOS. Beleid van RedHat is dat er binnen een major release van het OS geen compatibility issues geintroduceerd worden, in principe kun je dus vrolijk elke keer als je zin hebt een yum update draaien. Alles dat werkt op CentOS 6.0, werkt ook nog steeds op CentOS 6.5. Zo niet, dan heb je een bug te pakken.

Nou kan ik uit ervaring zeggen dat die bugs voorkomen, dus het blijft een goed plan om eerst gefaseerd te updaten, bij voorkeur over een otap straat. Als je die niet hebt, zorg dan dat je een machine hebt waarbij je productiewerk kunt simuleren maar waarbij het niet heel erg is als het kapot gaat.

Maar als je daadwerkelijk systemen beheert die vanaf het internet bereikbaar zijn, zorg dan alsjeblieft dat je wat training krijgt, of dat er iemand in je team komt met verstand van zaken, anders kom je vroeg of laat in de problemen.

[KeRsTmAnNeKe]

Een identieke testserver erbij ga ik niet voor elkaar krijgen, hoewel dat wel het meest ideale is. Eigenlijk red ik het dan niet met 1, omdat ondanks dat alle 3 de servers CentOS draaien er toch wat verschillen in zitten (32bit/64bit bij ene provider en andere uhm... nog anders qua hardware en pakketten).

Wel zijn er 2 managed, nu weet ik niet hoever de voorwaarden gaan, maar als die partij de boel update lijkt het me dat ze ook (deels?) verantwoordelijk zijn voor een goede werking daarvan, losstaand van onze eigen spullen. Ervaring leert overigens dat ze snel en goed reageren als er wat aan de hand is, dus dat is wel fijn.

We draaien overigens 90% Wordpress/Magento sites, zo goed als allemaal de laatste versie (die houden we wel vrij goed bij), dus verwacht er niet zo snel issues mee. Ook daar mist overigens een heel testtraject, updates en aanpassingen gebeuren op de live sites ... want testen is maar 'irritant'.

Blijft nog de 3e server over, waar ik zelf aan de bak zal moeten. Toch eens uitzoeken hoe yum precies werkt en wat daar aan mogelijkheden is mbt backups/recovery voor het geval er iets mis gaat.

Keer training of misschien een externe erbij halen lijkt me overigens nog steeds handig, mede om ook eens goed in de diverse configs te kunnen duiken en te begrijpen hoe en wat daar en de boel te kunnen optimaliseren, maarja, dat kost geld.

Ik heb/we hebben hier in ieder geval nog wel wat te leren en professionaliseren.

[CyBeR]

Cyphax schreef op donderdag 01 mei 2014 @ 13:37:
Ik weet niet hoe CentOS omgaat met nieuwe versies. Bij Debian stable doen ze dat bijvoorbeeld niet: als je Apache 2.2 hebt, dan blijft dat ook 2.2, zodat er niet zo'n groot risico aan zit om een update door te voeren. De enige keer dat een update bij mij iets kapotmaakte was bij een update van Varnish waardoor door mijzelf gecompilede mods niet meer werkte (door het versieverschil).

CentOS is wat dat betreft hetzelfde als Debian stable: in principe blijven packages binnen een release dezelfde versie, tenzij dat écht niet anders kan. Tussen versies (y in x.y) wordt wel wat geupdate maar conservatief.

Al mijn dozen zijn Debian en daar heb ik zelfs automatische security updates aanstaan. (En ik heb de debian-security mailing lijst in m'n inbox dus ik zie aangekondigd worden wat er vervolgens 's nachts geupdate wordt.)

[Cyphax]

CyBeR schreef op donderdag 01 mei 2014 @ 17:49:
[...]


CentOS is wat dat betreft hetzelfde als Debian stable: in principe blijven packages binnen een release dezelfde versie, tenzij dat écht niet anders kan. Tussen versies (y in x.y) wordt wel wat geupdate maar conservatief.

Ah, ik had al zo'n vermoeden.

Al mijn dozen zijn Debian en daar heb ik zelfs automatische security updates aanstaan. (En ik heb de debian-security mailing lijst in m'n inbox dus ik zie aangekondigd worden wat er vervolgens 's nachts geupdate wordt.)

Die debian-security-mailinglist heb ik ook een subscription op nadat ik doorkreeg hoe je het beste een Debian-server kan bijhouden. Dat was 1 van de beste tips die kreeg.

[ddkiller0900]

Als ik jou was zou ik proberen om een kloon te maken van minstens 1 van je servers en deze virtueel te draaien als testserver op bv. je eigen computer. Neem aan dat je geen budget krijgt om nog een extra server ergens neer te zetten. Op deze manier kan je dan toch updates installeren in een afgeschermde omgeving voordat je de productie omgeving update.

[himlims_]

hi kerel :W

draaien hier alle servers op debian of gentoo maar 90% is debian

webservers bijwerken doen we niet heeel veel; draaien stabiele release, en als er serieus lek/probleem gevonden wordt patchen we dat meestal wel.

hoewel voor vele linux beheerders/gebruikers taboe; vind ik webmin erg plezierig voor beheer/bijwerken

[daft_dutch]

ddkiller0900 schreef op woensdag 07 mei 2014 @ 06:46:
Als ik jou was zou ik proberen om een kloon te maken van minstens 1 van je servers en deze virtueel te draaien als testserver op bv. je eigen computer.

Een makkelijke manier in linux remote een disk te clonen (en er een VM van maken) kan met een combinatie van netcat en dd.

http://www.iphouse.com/bl...to-clone-a-linux-machine/

[Blokker_1999]

sowieso zou ik niet nalaten om een oplossing te zoeken en toch updates te installeren. Je mag niet vergeten dat enterprise distributies hoofdzakelijk security patches uitbrengen en dat de meeste updates dus te maken hebben met beveiliging wat niet onbelangrijk is voor een bedrijf. Reacties komen vaak pas als het te laat is.

[Ramon]

Ik zou ook updates gaan installeren. In het ergste geval gaat het misschien 1/10 keer mis en zijn er wat sites stuk. Dan fix je die. Dat is een stuk minder erg voor je reputatie als dat je site of database gehackt wordt.

Overigens zou ik ook kijken of het mogelijk is om die derde unmanaged server te vervangen voor dezelfde managed server als die andere twee, zulke uitzonderingen zijn killing en als alle servers hetzelfde zijn wordt het allemaal een stuk makkelijker. Wil je daar serieus mee aan de slag en ook goede testing gaan doen, dan zou je Puppet kunnen gebruiken om de configuratie van je server te doen. Op die manier kan je 3 identieke servers neerzetten en kan je ook op je ontwikkelomgeving een VM draaien die identiek is aan je server om goed te kunnen testen.

[Compizfox]

Tja, dat bepaalt eigenlijk al de keuze van je distributie en updatekanaal.

Ik ben zelf erg bekend met Debian, dus gebruik die distributie even als voorbeeld.

Als je graag altijd de nieuwste versies wilt hebben (voor de nieuwste features), dan pak je Debian Testing (of nog 'erger', sid). Je krijgt dan regelmatig nieuwe versies van je packages, en ook major updates (bijvoorbeeld Apache 2.2 --> 2.4). In theorie is het mogelijk dat een update iets sloopt, al komt dat echt nauwelijks voor bij Testing.

De meeste mensen/bedrijven die iets kritisch draaien, pakken daarom geen Testing of Sid maar Stable. Dat is een kanaal waarbij je eigenlijk alleen security-updates en bugfixes krijgt, en geen grote updates.

Bij alle kanalen is het wel de bedoeling dat je altijd de updates bijhoudt, maar de keuze van het kanaal bepaalt hoeveel en wat voor soort updates je krijgt. Met andere woorden: in plaats van 'gematigd' packages updaten, moet je juist meer aandacht besteden aan het kiezen van je distributie of updatekanaal binnen die distributie, en dat goed bijhouden qua updates.

[ Voor 12% gewijzigd door Compizfox op 11-05-2014 15:11 ]

[Thulium]

Wat ik je aan kan raden voor wat training (adviezen en tips hoe je met je servers om kunt gaan heb je nu al meer dan voldoende), ga naar de bieb en haal een boek over LPIC-1 (Linux Professional Institute Certification) en lees dat op je gemak door.

Je kunt het afsluiten met 2 examens (LPIC 101 en 102), maar dat is niet noodzakelijk als je alleen voor jezelf wat meer kennis over Linux wilt hebben.

Mocht je serieuzer aan de slag willen met Linux, dan zijn alle HR-mensen (en collega's maar die kijken meestal verder dan papiertjes ) altijd erg blij als je RHCE bent (Red Hat Certified Engineer), maar dat vergt wel de nodige voorbereidingen en parate kennis (je moet namelijk praktijkexamens maken, geen flauwe multiplegok vragen inkliederen).

[Verwijderd]

Ik gebruik apticron op mijn (debian) linux servers, Die stuurt me een email als er updates zijn. Met cron-apt kun je zelfs automatisch updaten, maar ik zet dat niet op productie servers in.
Een testserver draait er al wel een tijdje op, geheel probleemloos. Maar ik review liever eerst alvorens te updaten.

Geen idee trouwens of dat op Centos ook werkt.

[Hero of Time]

Ik weet dat met een gecentraliseerde reposerver zoals Spacewalk het mogelijk is om updates te pushen naar de machines. Spacewalk gebruiken wij op werk icm CentOS. Spacewalk kan ook gewoon in sync blijven en grote veranderingen of fixes (zoals de recente openssl heartbleed) mailen.

[Compizfox]

Verwijderd schreef op zaterdag 17 mei 2014 @ 16:12:
Ik gebruik apticron op mijn (debian) linux servers, Die stuurt me een email als er updates zijn. Met cron-apt kun je zelfs automatisch updaten, maar ik zet dat niet op productie servers in.
Een testserver draait er al wel een tijdje op, geheel probleemloos. Maar ik review liever eerst alvorens te updaten.

Geen idee trouwens of dat op Centos ook werkt.

CentOS gebruikt niet het Debian package management, dus nee.

[8088]

Verwijderd schreef op zaterdag 17 mei 2014 @ 16:12:
Geen idee trouwens of dat op Centos ook werkt.

yum check-update | mail -s "updates" iemand@domein

Unattended updates zou ik inderdaad niet aanraden.

[d1ng]

Op CentOS heb je yum-cron. Even op "CHECK_ONLY=yes" zetten, "MAILTO" veld aanpassen en je krijgt 's nachts een mooi mailtje als er updates zijn.