Linux updaten van packages

[com2,1ghz]

Beste Tweakers,

Regelmatig komen er updates uit voor Linux. Echter heb ik een paar keer meegemaakt dat een update ervoor gezorgd heeft dat bepaalde programma's niet meer werken of de OS niet meer start.
Laats had ik op mijn Centos productieserver een yum update uitgevoerd waardoor het mis ging met een dependency van php-mcrypt waardoor php kapot ging.
Hiervoor moest ik compleet php opnieuw installeren met als gevolg dat alle dependencies ook opnieuw geinstalleerd moeten worden.

Ik ben er ook achter gekomen dat het niet slim is om zomaar alle packages te updaten. Hiervoor zal ik iets moeten hebben waardoor ik bepaalde packages moet excluden.

Nou ga ik langzamerhand over op virtualisatie(proxmox) en zal dit probleem een grotere rol spelen omdat Proxmox ook op linux draait en ook alle virtual machines.

Hiervoor heb ik een aantal vragen:
-Hoe kan je het beste updaten met zo weinig mogelijk risico?
-Als een update mislukt, hoe krijg je dit netjes weer werkend?
-Is het mogelijk om van te voren te zien wat er fout kan gaan bij een update?

[FireDrunk]

1- Backups
2- Backups (of snapshots, als je virtueel werkt)
3- Nee

Misschien cru, maar het is zo... Er zit altijd een risico aan updaten. Wil je echt zo min mogelijk risico lopen, moet je Debian stable gaan draaien, die hebben de beste reputatie als het gaat om stabiele upgrades.

Het geklooi met PHP is op wel meer operating systems een probleem geweest volgens mij. PHP heeft een bepaalde dependency ineens in de source meegeleverd ipv als dependency, en ik geloof dat dat niet helemaal goed ging.

Makkelijkste oplossing is gewoon een snapshot van je VM of van je filesystem maken (als je LVM gebruikt) en die terugrollen in het geval van problemen.

[ Voor 16% gewijzigd door FireDrunk op 14-05-2013 09:58 ]

[HTT-Thalan]

Wat ^^ zegt .

Ik informeer klanten dubbel, soms driedubbel over de noodzaak van backups voor élke major upgrade, omdat ik simpelweg niet kan voorspellen wat er mis zou kunnen gaan.

[CAPSLOCK2000]

Ik sluit me aan bij de vorige sprekers.
- zorg voor backups
- als het betrouwbaar moet zijn is Debian Stable de koning (als is RHEL/CentOS ook niet slecht).
- zorg voor een test-omgeving zodat je kan uitproberen wat er moet gebeuren
- ken je gereedschap, in dit geval yum, een paar rotte dependencies hoeven niet tot een herinstallatie te leiden. Als het toch nodig is dan is dat voor iemand die handig is met yum een kwestie van een paar minuten. Dit is een beete een makkelijk antwoord, alle problemen zijn op te lossen met genoeg kennis, en er zullen altijd zaken blijven die je niet kan oplossen. Uiteindelijk moet je zorgen voor backups en een testomgeving.

[com2,1ghz]

Hmm ok dan ben ik niet de enige met dit probleem. Het is ook net koorddansen als je gebruik maakt van meerdere repositories.

Maar goed, er moet dus een degelijk test/backup systeem draaien.

Ik denk ook dat ik dit probleem voor een groot deel oplos doordat ik meerdere VM's draai met minder verantwoordelijkheid. Zo had ik in de oude situatie op mijn server een CentOS installatie met apache, mysql, php, postfix en andere meuk. Er hoeft maar een mysql-server update mis te gaan en alles is meteen kapot.

Bedankt voor jullie antwoorden.

[Thralas]

com2,1ghz schreef op dinsdag 14 mei 2013 @ 11:41:
Hmm ok dan ben ik niet de enige met dit probleem. Het is ook net koorddansen als je gebruik maakt van meerdere repositories.

Met enkel distro repositories gaat er in de regel niet 'zomaar' iets stuk - package versions zijn frozen en de enige updates die je krijgt zijn bug- en secfixes. Als je zelf non-distro repositories toevoegt en je niet nagaat wat daar de gevolgen van zijn (of hoe je ongewenste side-effects voorkomt) dan zou het inderdaad best eens stuk kunnen gaan.

• Welke repositories gebruik je (op welke CentOS-versie)?
• Maak je gebruik van yum-priorities en/of includepkgs?

Waarschijnlijk heb je zelf (onbewust) de problemen veroorzaakt.

-Hoe kan je het beste updaten met zo weinig mogelijk risico?
-Als een update mislukt, hoe krijg je dit netjes weer werkend?

In de eerste plaats: een sane repository config hebben, dan gaat het zelden fout. En iets ala yum history (CentOS 6) of repackage/rollback (CentOS 5).

-Is het mogelijk om van te voren te zien wat er fout kan gaan bij een update?

Mocht er wat fout gaat qua dependencies of andere constraints, dan wordt de hele updatetransactie gewoon niet uitgevoerd. Alle andere side-effects liggen in het overgrote deel van de gevallen aan wat ik eerder beschreef.

CAPSLOCK2000 schreef op dinsdag 14 mei 2013 @ 11:06:
- als het betrouwbaar moet zijn is Debian Stable de koning (als is RHEL/CentOS ook niet slecht).

[citation needed]

[com2,1ghz]

Thralas schreef op woensdag 15 mei 2013 @ 01:05:
[...]


Met enkel distro repositories gaat er in de regel niet 'zomaar' iets stuk - package versions zijn frozen en de enige updates die je krijgt zijn bug- en secfixes. Als je zelf non-distro repositories toevoegt en je niet nagaat wat daar de gevolgen van zijn (of hoe je ongewenste side-effects voorkomt) dan zou het inderdaad best eens stuk kunnen gaan.

• Welke repositories gebruik je (op welke CentOS-versie)?
• Maak je gebruik van yum-priorities en/of includepkgs?

Waarschijnlijk heb je zelf (onbewust) de problemen veroorzaakt.

Dat ontken ik niet. Het was ook het probleem doordat ik een dependency vanuit een andere repository had geinstalleerd wat mis ging. Bleek dat de package uit die repository niet goed was.

Ik heb yum priorities geinstalleerd. Echter moet ik nog kijken hoe ik hier optimaal mee om kan gaan.
Van de volgende extra repositories maak ik gebruik van:
-Epel
-RPMForge
-In uitzonderlijke gevallen Remi

[...]

In de eerste plaats: een sane repository config hebben, dan gaat het zelden fout. En iets ala yum history (CentOS 6) of repackage/rollback (CentOS 5).

Hier ben ik ook al achter gekomen ja. Een handige functionaliteit is dit.

[...]

Mocht er wat fout gaat qua dependencies of andere constraints, dan wordt de hele updatetransactie gewoon niet uitgevoerd. Alle andere side-effects liggen in het overgrote deel van de gevallen aan wat ik eerder beschreef.


[...]

[citation needed]