Vlákno názorů k článku
Migrace serveru z Debianu na CentOS od Sten - A opačný návod (z CentOSu nebo Red Hatu) by...

Mate pravdu jaksi oba.

Ano, u debianu je ten upgrade pohodlnejsi. Jenze taky nutnosti, pri te kadenci releasu.

Ale uvazuj situaci u RHELu - lifetime instalace dneska muze byt tak 10 let, coz je ostatne proc lidi RHEL voli pred ostatnimi distribucemi.
Po 10ti letech od instalace se software pomeni bez pochyb na tolik, ze i kdyby ten system umel neco jako apt-get update && dist-upgrade, s nejvetsi pravdepodobnosti by to vygenerovalo vetsi deprese adminum, nez kdyz se jim rovnou rekne, ze to nejde a maji si pripravit poradny migracni plan s reinstallem.

Ne, ze bych chtel RH omlouvat za "absenci" tehle featury, ale je faktem, ze ji vetsina uzivatelu jednak nepotrebuje a jednak stejne by ani nechtela pouzit.

RHEL proste miri na trochu jina prostredi, nechci rict, ze uplne na targety stylu "install&forget", ale hodne se to tomu blizi. Nainstalovat stovky serveru a muset je upgradovat az za hromadu let, je proste pro spoustu zakazniku RH jediny zpusob, jak ty servery maintainovat.
Z tohohle pohledu proste Debian zabere vic clovekohodin.

Navic pri tak dlouhe dobe supportu je hodne caste to, ze se proste za dlouhou dobu od instalace stejne radsi koupi novy hardware, na nem se pripravi nova verze produkcniho prostredi a pak se proste "prepne prepinac" mezi starym a novym prostredim. Deje se to tak ne zridka :)

Ja sem jenom chtel rict presne jak pises - ze proste major update na Debianu je v pohode.

Ano zivotni cyklus proti CentOS/RedHat je cca 3 roky - tedy polovicni az tretinovy.

Na bezny firemni server - posta, fileserver, DHCP, DNS apod apod neni problem jednou za 2-3 roky udelat update. Vypadek se pohybuje v radu minut pokud clovek nepouziva nejake velke upravy (z pohledu Squeeze na Wheezy). Pak samozrejme spotrebuje nejaky cas kontrola zda vse slape jak ma.

Tam kde nesmi byt ani par minutovy vypadek se pouzivaji technologie jako cluster atd kde vypadek jednoho stroje pro maintanance neni kritickou situaci.

Jenze ono to presne takhle prave v praxi nefunguje. Pokud Vam jde o dostupnost, tak proste stejne musite udelat nejake testovaci prostredi, kde se udela klon ostreho a pripravi se migracni plan. Z tohohle pohledu uz je lepsi si nainstalovat cisty upgradovany server(s PXE a kickstartem otazka tak 3-5minut), zmigrovat konfiguraci, ktera je stejne schovana v nejakem satellitu,pup­petu,git a podobne(a je uz to zasite v kickstartu) a pak prikrocit k migraci dat a pak to same zopakovat pro produkcni prostredi. Clovek ma alespon jistotu, ze sebou netaha nejaky balast, ktery zustal ve starych verzich a casto se to spoji s vymenou HW, protoze jeho support je vetsinou 3-4 roky.

Migrovat clustery je jeste o to slozitejsi, ze pokud je na kazdem node po upgradu jina verze clusteroveho software, tak to dela chyby. Proto se vedle postavi novy cluster a na ten se pak proste prepne produkce.

Jinak snadnost upgrade major verze mi u Redhatu prijde podobna jako u Debianu. Lisi se spis pristup spravcu obou platforem.

Ja bych si dovolil nesouhlasit, spravuji oba typy , jak Deba, tak CentOS a muzu rict, ze postupovat dle navodu, ktery jsi popsal, se v pripade narocnejsich serveru muze stat velkym zdrojem problemu, ne-li smrti serveru(OS/APP)

Jen pro priklad: mas Deba spolu s DB (Postgress, Oracle, Sybase) k tomu Apache+PHP / Tomcat s FreeTDS, ODBC connectorem. a ted udelej Tebou zminovany distupgrage ....
"Hodne stesti a pevne nervy"