Názory k článku Upgrade Debianu Lenny na Squeeze: praktické zkušenosti
-
Prvy? :P (neregistrovaný)
Dakujem pekne za clanok.
Dobre a vhodne upozornenia a rady.Dakujem velmi pekne
Napriek peknemu zaveru - "Debian je super a chyby mu odpustime" - nie celkom suhlasim. Teda odpustam aj aj a dakujem vsetkym, co sa na tom podielaju, ale ...
Iste dokopy som (komunite) Debianu nedal takmer nic, dokonca som na cas prebehol k Ubuntu (kajucne sa vraciam spat - este aj na DTP), uznavam, ze je to zadara a (zvacsa) v spica kvalite = drz hubu - tiez suhlasi, ale predsa.(rock)stable Debian, best distro a ... taketo chyby??
To async SCSI a obe SQL su "neodpustitelne" (aj tak migrujem spat na Debian, ale ...)
Vsetko ostatne sa da odpustit - ale taketo 3 zavazne chyby, kt. vyzaduju skuseneho admina - a najlepsie v kombinacii s predposerou. Nie kazdy ma KVM a servery do 50km - a aj keby ...
A okrem toho jedna sa o upgrade z (v podstate beznych) HW a SW konfiguracii z rockstable na rockstable - 2 roky po vydani!
Keby to bol nejaky tyzden po - na neobvyklej konfiguracii - OK, sme ludia ... ale toto??
Dost ma to sklamalo. :( -
R (neregistrovaný)
Problem so SCSI a SW RAIDom som mal aj v Lenny. Riesil som to upravou skriptu mdadm v initramfs (/etc/initramfs-tools/scripts/local-top/mdadm) - ten som skopiroval z initramfs a riadky "$MDADM --assemble --scan --run --auto=yes blabla" som uzavrel do nekonecneho "while !" so sleepom na 5 sekund.
Ocakaval som, ze to bude v Squeeze vyriesene :(
-
Druhy (neregistrovaný)
Prevadzkuje niekto i386/amd64 mirrory aj oldstable a old-oldstable?
Len pre "zabavu" by som si xcel prejst upgrade nasho beziaceho v podstate nepouzivaneho serveru etch-lenny-squeeze-wheezy.Nasledne aj tak pojde HW na predaj za par supiek a data sa presunu na novy HW, nove HDD a nove disky.
Ale budem mat chvilku v praci a chcel by som sa zabavit takto - ci nemate nejake tipy ...
Vopred dakujem ;)
-
Petr StehlíkZlatý podporovatelZapomněl jsem zmínit ještě dvě zajímavé drobnosti:
1) webalizer si stěžuje, že chybí /usr/share/GeoIP. Pomůže ruční instalace "geoip-database". Je to hlášený bug v Debianu, vyřešený je asi až pro Squeeze+1.
2) phpmyadmin ve Squeeze požaduje vlastní databázi. Odhlédnu-li od tohoto IMHO přemrštěného požadavku, tak Debianní průvodce instalací se sice snaží novou databázi pro phpmyadmin vytvořit, ale v několikátém kroku to selže (tuším to chtělo tu ještě neexistující databázi upgradovat). Takže phpmyadmin nejede a já zvažuju, že ho bez milosti nahradím českým jednoduchým (ve smyslu nevyžadujícím vlastní databázi) Adminerem. Zatím mě od toho odrazuje jen fakt, že Adminer není ve Squeeze, takže bych neměl případné bezpečnostní updaty bez starostí.
Jinak si ctění čtenáři asi všimli, že ty systémy upgraduju už mnoho verzí, takže se tam naskládaly určité historické věci (zbytky od kernelů 2.6.18 apod.). I to je jakási známka kvality Debianu, že to jde "tak dlouho" jen upgradovat. Čistý reinstall jsem nedělal už mnoho verzí, v systému jsou adresáře vytvořené i v minulém tisíciletí...
Mimochodem, na jaře mě čeká upgrade jednoho serveru s Ubuntu 10.10, na 12.04 LTS budu muset jít celkem přes tři upgrady, tak to bude velmi zajímavé srovnání, nakolik se s tím popere Ubuntu...
-
A.S. Pergill (neregistrovaný)
protože Debian 6 (instalovaný z orig. DVD) byl naprosto nepoužitelný (nejelo video na celou obrazovku a zvuk poskakoval jako poškrábaná gramodeska, ale v nepravidelných intervalech, což je snad subjektivně ještě horší). Takže mě těší, že nejsem sám, kdo má se šestkou negativní zkušenosti.
Prostě vývojáři by si měli odvyknout vrtat do těch funkcí systému, které jsou v pořádku, a jen opravovat chyby nebo přidávat funkce nové. "Nesnažte se opravovat něco, co funguje", to je stará vojenská zásada (a je vidět, že těm mladším ta vojna chybí, jako bravu drbání).
Sám nevím, jestli si nechám ten Debian 6 nainstalovat odbornou firmou, nebo jestli přejdu na jinou distribuci. Na chalupovém počítači, který je off line (protože tam nemáme internet) si nejspíš nechám pětku. -
jc (neregistrovaný)
Drtiva vetsina tech "problemu" souvisi s vetsimi zmenami v upstreamu. Jak si predstavujes, ze se vyvojari "nebudou nevrtat ve funkcnich vecech"? Ze budou vytvaret forky ke vsemu software, kde se zmeni neco funkcniho? A co kdyz se to zmeni proto, aby to fungovalo na jinem hw (zacneme kernelem)? Hodis pres palubu nove nebo stare uzivatele?
-
A.S. Pergill (neregistrovaný)
Nevím, co je to upstream a v zásadě mě to nezajímá. Zajímá mě to, že věci, které jely na předchozí verzi, na nové nejedou. A pokud tyhle věci jedou jen na nějakém hypernovém hw, tak jednak nemají inzerovat, že systém jede na všem od 386 nahoru včetně, jednak to mají mít vyřešeno (třeba jádrem kompatibilním se starším železem - o žádnou vykopávku se přitom nejedná, PC staré cca 5 roků).
A vrtání ve funkčních věcech?:
XMMS: použitelnost asi na úrovni Winampu; XMMS2 naprosto nefunkční šmejd, z něhož se nedá dostat žádný tón = upgradováno do naprosté nefunkčnosti
Audacious: použitelnost dtto jako původní XMMS; Audacious2 méněcenný šmejd, který řadu zvukových formátů, bezproblémově přehrávaných předchozí verzí, kriplí = upgradováno do výrazně snížené funkčnosti (a naprosto žádná funkce nepřibyla)
Jakmile vidím novou verzi čehokoli, tak se děsím, o kolik bude zase horší než ta původní. A že bych byl příjemně překvapen, to se stává jen výjimečně. -
jc (neregistrovaný)
Debian je distribuce, to neni vsespolek milionu vyvojaru. Upstream je prave oznaceni vyvojaru, ktery software vytvareji (obvykle nezavisle na distribuci).
At chcete nebo ne, kapacity vyvojaru jsou omezene a kapacity lidi, co pripravuji balicky take. Nemaji k dispozici vsechny konfigurace hw ani sw. Nektere kombinace ani nejsou mozne. Presto odvadeji vybornou praci, ktera casto neni vubec videt ocima uzivatele.
Co takhle bugreporty - hledal jsi? Nebo zakladal vlastni?
-
A. S. Pergill (neregistrovaný)
"kapacity jsou omezené ..."
Proto říkám: Nevrtat do toho, co funguje. Funkčnost pod předchozí verzí = není to nějaká "nemožná" HW konfigurace. Pokud upgrade nezajišťuje základní funkčnost OS = pryč s tím.
U těch problémů se zvukem a videem šlo zřejmě o pomrvení někde v jádře, protože nejely ani na sobě nezávislé programy (nepoužívající stejné knihovny). Pravděpodobně by bylo možné to vyřešit kompilací nového jádra - ale to popírá smysl existence distribucí. -
jc (neregistrovaný)
Snazil jsem se vysvetlit, ze to nejde nevrtat se. Kazdy zivy software se nejak vyviji a soucasti vyvoje jsou jak male evolucni zmeny tak vetsi prepis kodu.
Kdyz se to vezme z pohledu packagera (distribuce), je nekdy na hranici lidskych moznosti udrzet funkcni/bezpecne verze i v ramci jednoho cyklu distribuce natoz dele. Pokud ti vadi cyklus Debianu, vyber si jinou distribuci.
Kdyby se dlouhodobe "nevrtali", nebyl by Linux&spol vubec pouzitelny.
-
jc (neregistrovaný)
a) menit sources prikazem:
perl -i -pe 's/lenny/squeeze/g' /etc/apt/sources.list
silne nedoporucuju. Dost casto tam budete mit postaru volatiles a novy zdroj se jmenuje jinak (updates). Ja pouzivam:
deb http://ftp.cz.debian.org/debian squeeze main contrib non-free
deb http://ftp.cz.debian.org/debian squeeze-updates main contrib non-free
deb http://security.debian.org/ squeeze/updates main contrib non-freeb) s postgresem jsem nikde problemy nemel, muze to byt neco lokalniho
c) jak jsem psal v konfere, s bootovanim jsem problem nemel (asi 35 stroju od xen virtualu po blady bootujici z pole)
d) u jabber serveru chybi co to je za jabber server
e) ja zustal u grub1, staci jeste pred dist-upgrade spustit:
apt-get install grub-legacy
dpkg -P grubf) na slucovani zmen konfigu se hodi vimdiff;
Par dalsich tipu:
* kontrolovat firmwary (nektere se ve squeeze oddelily do samostatnych baliku) a reboot nechat na konec upgrade
* je dobre zkontrolovat obsoletes baliky a pripadne je zrusit nebo nahradit alternativou
* /etc/apt/apt.conf.d/90recommends
APT::Install-Recommends "false";* /etc/sysctl.d/local.conf
net.ipv6.conf.all.disable_ipv6 = 1
kernel.printk = 3 4 1 3Vzhledem k poctu baliku, ktere muze mit clovek nainstalovany, by reseni vsech moznych problemu bylo na knizku. Takze je treba byt pri upgrade pripraven na vsechno a neztracet koncentraci :)
-
Petr StehlíkZlatý podporovatel
Ten perl byl jen na ukázku, samozřejmě studuju /etc/apt/sources.list a sources.list.d/ podrobně, ruším staré backports atd. Nechtěl jsem to v článku rozepisovat, tak jsem jen vymyslel ten one-liner abych ilustroval nutnost změny sources.list.
Ten PostgreSQL je něco u mě lokálního, jiní s tím problém nemají, ale mě to dostalo na dvou strojích ze tří, takže to stálo za zmínku.
Jabber je jabberd14 a ani po dalších 6 hodinách zápasu mi není jasné, co na mě zkouší. Zřejmě to nějak souvisí s IPv6 a linux-vservers, každopádně to není chyba konfigurace, protože i se stock konfigurací rozumně upravenou to hlásí, že port 5222 je již obsazen.
Na jiném serveru (bez virtualizace, s funkční IPv6) jsem ho rozjel hned, takže to bude skutečně nějak souviset s tím konkrétním systémem, ale nemám čas pátrat dál, koneckonců to může běžet i na tom mém druhém serveru.
Díky za doplnění těch dalších obecných tipů, zvlášť ta zmínka o nutnosti instalace "firmware-linux" balíčku (který při povolených non-free zdrojích přitáhne i firmware-linux-nonfree, díky čemuž fungují například síťové karty) byla velmi důležitá a z článku mi vypadla.
Vypínat Recommends je teda už na zvážení, já to třeba řešívám pro každý jednotlivý balíček při instalaci:
apt-get --without-recommends install něcoVypínat IPv6 mi přijde úplně divné, vždyť už za 4 měsíce tu máme IPv6 den!
-
jc (neregistrovaný)
Ve squeeze funguji PHP baliky z Lennyho, ktere ale uz nejsou podporovane a nove objevene chyby nebudou opravovane. Mozna by sly implantovat baliky z nejake podporovane verze Ubuntu. Nebo kompilovat vlastni, na php.net ale u pisou:
5.2.14: This release marks the end of the active support for PHP 5.2. Following this release the PHP 5.2 series will receive no further active bug maintenance. Security fixes for PHP 5.2 might be published on a case by cases basis. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.
5.2.15: This release marks the end of support for PHP 5.2. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3.
5.2.16 (prosinec 2010): This release marks the end of support for PHP 5.2. All users of PHP 5.2 are encouraged to upgrade to PHP 5.3. ... To prepare for upgrading to PHP 5.3, now that PHP 5.2's support ended, a migration guide available...
Dalsi 5.2.x releasy nejsou.
-
Baťoh (neregistrovaný)
Zdravím,
můj upgrade probíhal "docela" hladce, pominuli nefunkční ssl v Apachi (zjevně nějaký zdup ve starých konfiguračních souborech, boť apache spadne a nezapíše ani zbla do logu...), nutnost ručně instalovat MySQL 5.1 a zrušené konfigurace, vč. uživatelských dat u Squirrelu (důrazně doporučuji předem zazálohovat "/var/lib/squirrelmail/data/" a "/etc"). Pokud mohu subjektivně soudit, je to jedna v méně příjemných aktualizací distra od doby D3. Nicméně na Debina nenechám dopustit :).Co jsme tady neviděl a možná to někomu pomůže, je nutnost ručního nastavení greylistingového skriptu postgrey a postfixu. Ve staré konfiguraci je port 60000, v nové 10023. Příslušné soubory je nutno upravit do následující podoby:
#/etc/default/postgrey
POSTGREY_OPTS="--inet=127.0.0.1:10023"#/etc/postfix/main.cf
check_policy_service inet:127.0.0.1:10023,Pěkný den.
j.z. -
Petr StehlíkZlatý podporovatel
Včera večer jsem dělal mail server a SquirrelMail proběhl úplně hladce bez ztráty uživatelských dat. Dnes jsem si všiml, že se rozbila čeština - na disku jsou data uživatelů uloženy v ISO Latin2, a SquirrelMail je teď zobrazuje jako kosočtverce s otazníčkem...
-
ET (neregistrovaný)
jasny, nepochybuju o tom ze dist-upgrade je funkcni, jen se mi to nezamlouva a vzdy instaluju odznova ( a jsem rad, ze nejsem sam, ale ze jsme s Queegem500 dva :)
PS: ten dist-upgrade mi prijde jako kdyz nainstalujes na server lennyho a pak pres nej (bez formatu disku) nainstalujes squeeze
-
Kepi (neregistrovaný)
Nevidím jediný důvod proč instalovat server znovu a neupgradovat ho. Debian je vynikající právě v tom, že s takovými věcmi nejsou problémy.
Když pominu mysql (tam bohužel neumím být slušný, protože vypínat db při upgrade mi příjde jako idiocie), tak navíc dokážete celý upgrade udělat za běhu bez přerušení běhu služeb a pak jen relativně krátký výpadek na reboot (a případný check disků).
Chápu, že pokud má někdo doma svůj počítač nebo malý servřík, může ho to bavit a instalace nové distribuce může být zábava. Pokud spravuji sto různě konfigurovaných severů, nová instalace nedává naprosto žádný smysl.
-
ET (neregistrovaný)
ten duvod je "cistota instalace" - v systemu nezustane zadnej balast
"Pokud spravuji sto různě konfigurovaných severů, nová instalace nedává naprosto žádný smysl." - imho. pokud uz ma nekdo ~100 stroju, tak by nemel byt problem poridit/pujcit jeden docasny, na nej provest cistou instalaci, premigrovat sluzby a stary server po uspesny migraci smazat/preinstalovat - jak je videt (clanek by asi jinak nevznikl), tak upgrade neni vzdy bezproblemovy
ocividne je to otazka nazoru, zustavam u cisty instalace, instalacim zdar
-
orm (neregistrovaný)
Je vidět, a nemyslím to zle, že jste ~100 serverů nikdy nespravoval, protože váš navrhovaný postup je možná teoreticky možný, ale v praxi nerealizovaelný. Těch ~100 serverů byste vaším způsobem upgradoval min. rok, reálně možná i více, nemluvě o tom, že jsou nějaké služby vazané na veřejnou ip adresu serveru, takže váš postup postupné migrace by stejně nešel použít.
-
ET (neregistrovaný)
mno tak jeste naposled a necham toho :]
"Je vidět, a nemyslím to zle, že jste ~100 serverů nikdy nespravoval"
100 najednou sem jich opravdu nikdy nespravoval, nejvic sem jich mel "pod rukama" ~50 a vsechny vzdy ciste nainstalovany uvedenou metodou (vetsinou RHEL) - pokud preinstalovavate server ~3.5dny (365 / 100 serveru), pak nezbyva nez Vam doporucit zustat u dist-upgrade, existuji i zpusoby jak instalaci zautomatizovat a v pripojeni nove nainstalovaneho serveru s premigrovanymi sluzbami na novou ip taky nevidim problem (a verte nebo ne, uz jsem takto migroval...)
co jsem koukal na google, tak problemy s dist-upgrade proste obcas jsou a (jak uz jsem psal) tento clanek je toho dukazem - a ze mate serveru 100+ neni zadna omluva, proc to nedelat poradne !
u me na serverech proste bordel nebude, instalacim zdar
-
Queeg 500 (neregistrovaný)
Já tedy instaluju vždy zásadně od znova, na novém distru postupně (subsystém po subsystému, služba po službě) vše rozjedu a odzkouším a poté přejdu. Spoléhat se na to, že ňáký skripty správně pochopí mé netriviální dělení disku, custom kernel a initrd a že nějaké skripty správně vytvoří konfigy pro nové verze SW (které se můžou dost lišit) na základě mých starých konfigů... to se mi opravdu nechce.
Je to nicméně hlavně o tom, jak se kdo dívá na kritické/produkční služby. Nebo taky o důvěru ve stroje obecně. Znám lidi, co distupgrade dělaj zásadně za jedne večet na všech serverech a "prošlo" jim to jak ze Etch na Lenny, tak z Lenny na Squeeze. Ono když server bootuje, tak se vážný nedostatky doladí v řádu dnů a ty lehčí v řádů měsíců... Já budu ale i tak dál instalovat od znova a do produkce pouštět až věci, které někdo připravil a otestoval.
-
Debian na to myslí a když nemyslí, tak se na to většinou přijde. Zrovna včera jsem dostal bugreport k src:cyrus-imapd-2.4.
Smetí nezůstává a když jo, tak je to chyba balíčku.
Když víte, co děláte, tak se dají s .deb dělat i takové čachry, že jsem "upgradoval" Ubuntu <něco> na Debian squeeze a server(y) to v klidu přežil(y) včetně rebootu. Vyžadovalo to ovšem trochu netriviální práce v /etc, ale jinak v zásadě nenastal žádný větší problém.
-
Grumpa (neregistrovaný)
Autor by si odpustil řadu chyb, kdyby striktně postupoval podle oficiálního návodu na upgrade. Takto je tento článek spíš o zbrklosti autora, než o skutečných potížích s upgrade. :-)
Například zmiňovaná PostgreSQL se upgraduje opravdu hladce, nesmíte si ovšem "apt-get autoremove" spustit dříve, než je vše opravdu hotovo.
Já ve fázi dist-upgrade raději volil interaktivní spuštění aptitude a upgradoval po částech. To je jediný můj rozdíl oproti oficiální dokumentaci.
Hodně štěstí!
ČLÁNKY DO MAILU