Názory k článku
Upgrade Debianu Lenny na Squeeze: praktické zkušenosti

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 :(

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 ;)

Cau
Toto by melo bohate stacit

http://archive.debian.org/debian/README

Zapomně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...

Dovecot změnil syntaxi modulu sieve.

Ve firmě jsem řešili upgrady cca 100 Ubuntu desktopů z 7.10 na 8.04 LTS a potom na 10.04 LTS a v zásadě to bylo bez problémů (jen na lokalitách byl problém s rychlostí linky ... ;-) )

vlastně šlo jen spuštění "do-release-upgrade" ;-)

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.

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?

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ě.

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?

"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í.

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.

=======
Nevím, co je to upstream a v zásadě mě to nezajímá.
=======

Ale to by mělo, pokud se chceš aspoň trochu orientovat.

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-free

b) 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 grub

f) 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.con­f.d/90recommen­ds
APT::Install-Recommends "false";

* /etc/sysctl.d/lo­cal.conf
net.ipv6.conf­.all.disable_ip­v6 = 1
kernel.printk = 3 4 1 3

Vzhledem 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 :)

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ěco

Vypínat IPv6 mi přijde úplně divné, vždyť už za 4 měsíce tu máme IPv6 den!

OK, ten one liner se nepovedl a nekdo by ho mohl vzit vazne.

Firmwaru je vic, viz firmware-bnx2, firmware-qlogic, ...

Vetsina provideru nepodporuje ipv6 a vypnutim se predejde ruznym problemum. O rozsireni ipv6 v lokalnich sitich (a serverech v LAN) nemluve.

> Vetsina provideru nepodporuje ipv6 a vypnutim se predejde ruznym problemum.

V tom pripade je potreba prudit sveho ISP kdy zavede IPv6, idealne tak jednou tydne.

Posledna vec preco som pouzival Lennyho bola verzia PHP.
V Lenny je PHP 5.2.6-1 a v Squeeze 5.3.3-7 Na servery prevadzkujem zopar webou ktore potrebujem aby dozili. Je nejaky jednoduchy sposob ako zostat pri verzii 5.2 ?

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.

A proc je problem upgrade PHP? Zmeni se akorat config(ktery nemusite prepsat), jinak je tusim akorat par funkci hozeno jako deprecated

Vzhledem k deprecated funkci "register globals" muzou nekteri "php programatori" nadavat. Ostatni by melo byt bez problemu.

Mě docela nepříjemně zaskočila změna syntaxe výjimek. Obsahují jiný počet argumentů a přeci jen při větší aplikaci to může být docela problém. Takže ono to není jen pár deprecated věcí...

Jasně, nechte si tam PHP 5.2; on už vám ten server časem začne někdo administrovat!

Jednoduchý způsob je nainstalovat aktuální Centos 5, kde s PHP 5.2 vydržíte až o 2017 :-)

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/squ­irrelmail/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/pos­tgrey
POSTGREY_OPTS="--inet=127.0.0.1:10023"

#/etc/postfix/ma­in.cf
check_policy_ser­vice inet:127.0.0.1:10023,

Pěkný den.
j.z.

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...

jsem jedinej, kdo provadi upgrade kompletni reinstalaci - tj. fresh instalaci z CD/DVD ? Prijde mi to jako prasecina upgradovat formou popsanou v clanku - tj. zmenit repo a prehrat binarky novejma verzema - imho musi v systemu zustat hodne smeti ze starejch verzi

U Debianu je to funkcni a to i dlouhodobe. Spousta lidi uspesne provozuje unstable, ktery se meni kazdy den. Treba ja mam jeden unstable asi 8 let. Pri zmene hardware jsem vzdy udelal dump/restore a jel jsem dal.

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

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.

Už jsem to říkal níže - po dobře provedeném upgrade v systému žádný balast nezůstane. Resp. nebude ho více než v nově nainstalovaném systému.

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.

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

Vy pracujete 365 dni v roce? Kazdopadne je to jedno, delejte to podle sebe, hadat se s vama nebudu a presvedcovat take ne.

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.

Pořiďte si Fedoru a budete mít rozm*danej systém každýho půl roku :-)

Vod toho snad mame rhel nebo centos ne? Nainstaluejs a 5 let facha.

tak jsem dnes upgradoval a vše funguje!

Ja upravou sources.list a apt-get "upgradoval" Damn Small Linux -> Debian

Debian zvladne i downgrade.