Mohlo by se zdát, že tento článek přichází s křížkem po funuse, protože bezpečnostní podpora Debianu Lenny včera skončila. Z reakcí na webu je ale jasné, že ne všichni už upgradovali na Squeeze, protože se bojí případných problémů. Já jsem také na poslední chvíli absolvoval víkendový „upgrade maraton“ a rozhodl jsem se tu zveřejnit své poznámky. Snad někomu pomůžou vyhnout se největším potížím.
Upgradoval jsem deset serverů, z toho pět bylo běžných LAMP, tři byly s Javou, Tomcatem a PostgreSQL a pár dalších bylo jen hostitelů pro virtuály. Většina strojů je se SATA disky, jen jeden IBM xSeries 225 má SCSI disky.
Při upgrade (prováděném na dálku přes SSH) jsem se striktně držel návodu k upgrade v poznámkách k vydání Debianu. Pro ilustraci zkráceně předvedu jednotlivé kroky:
Kontrola stavu balíků (co je ve stavu Hold nebude upgradováno):
# dpkg --audit # dpkg --get-selections | grep hold # aptitude search "~ahold"
Záloha důležitých souborů (konfigurační soubory a databáze balíčků):
# dpkg --get-selections "*" > ~/Lenny-curr-pkgs.txt # cp -p /var/lib/apt/extended_states ~/ZALOHA-Lenny-extended_states # GZIP=--best tar czf ~/ZALOHA-Lenny.tgz /etc/ /var/lib/dpkg/
Úprava zdroje balíčků a obnovení databáze:
# perl -i -pe 's/lenny/squeeze/g' /etc/apt/sources.list # apt-get update
A nyní už slavnostně první část upgrade systému:
# script -t 2>~/upgrade-squeeze1.time -a ~/upgrade-squeeze1.script # apt-get upgrade # apt-get install linux-image-flavor # apt-get install udev # reboot
Pokud první fáze dopadne dobře a systém znovu nabootuje, následuje druhá fáze.
# script -t 2>~/upgrade-squeeze2.time -a ~/upgrade-squeeze2.script # apt-get dist-upgrade
V systému navíc nejspíš zůstalo pár již nepotřebných balíčků, které mohou zbytečně zavazet (viz níže). V tuto chvíli už by mělo být zřejmé, že systém po upgrade funguje dobře, takže již nepotřebné balíčky můžeme odstranit
# apt-get autoremove
No a teď už konečně ty zážitky a překvapení z víkendu:
Asynchronní scanování SCSI
Reboot na konci první fáze upgrade byl vždy nesmírně napínavý, protože servery při bootu kontrolovaly filesystémy (jelikož uplynuly věky od poslední kontroly), takže jsem čekal desítky minut a někdy i hodiny nevěda, jestli se server ještě někdy ozve. Většina se nakonec ozvala, ale zmíněný IBM xSeries se odmlčel natrvalo.
Při osobní návštěvě v serverovně jsem zjistil, že systém stojí v shellu initrd, když předtím vyhlásil nemožnost sestavit RAID pole – a to už zhruba o 20 sekund dřív, než kernel doskenoval SCSI sběrnici. Jelikož šlo pole sestavit pomocí mdadm --assemble /dev/md0 a normálně pokračovat v bootu, myslel jsem, že stačí chvíli pozdržet boot, aby se pole stihlo sestavit. Na to je kernel parametr bootdelay, ale ani když jsem do něj zadal absurdně velké hodnoty, nepomáhalo to. Nakonec jsem vygoogloval jiné řešení, a to zapnutí synchronního scanování SCSI sběrnice. To jde vnutit kernelu třeba parametrem při zavádění, který se hodí do /etc/default/grub.
GRUB_CMDLINE_LINUX="scsi_mod.scan=sync"
Zřejmě tedy mezi 2.6.26 (Lenny) a 2.6.32 (Squeeze) došlo k implementaci/zapnutí asynchronního scanování SCSI. Znamenalo to pro mě velký zážitek (a slušný downtime), před kterým mě oficiální dokumentace nevarovala.
SW RAID konfigurace
Všiml jsem si, že se ve Squeeze změnil formát konfiguračního souboru pro SW RAID /etc/mdadm/mdadm.conf. Neváhal jsem proto ani vteřinku a vygeneroval jsem nový:
# /usr/share/mdadm/mkconf > /etc/mdadm/mdadm.conf
V jednom případě jsem si všiml, že mkconf na jednom stroji přihodil na konec souboru řádek “spares=1”, ale neměl jsem čas to řešit. Když mě dnes ráno čekal v poště mail, že v poli chybí spare disk, šel jsem se tam podívat a nic nechybělo – přegeneroval jsem tedy konfigurační soubor stejným příkazem a voilá, už tam řádek “spares=1” nebyl, takže už žádné disky chybět nebudou.
Snažím se nezapomínat zapsat konfiguraci SW RAID pole i do ramdisku:
# update-initramfs -k all -u
To mi pořád brblalo, že nemůže najít ramdisky od kernelů 2.6.22 a ještě starších, tak jsem hledal, až jsem našel adresář /var/lib/initramfs-tools/, kde byly odkazy na dávno neexistující kernely. Promazal jsem to a byl klid.
Zmizení MySQL serveru
Ačkoliv normálně apt-get dist-upgrade nainstaluje nové verze všech existujících balíčků, tak nový MySQL server se mi nenainstaloval automaticky ani na jedné LAMP konfiguraci (zato se na většině automaticky odinstaloval jeho předchůdce mysql-server-5.0). Výsledkem byly nefunkční weby. Zajímavá chyba v upgrade procesu! Pomohlo ruční instalování správného balíku:
# apt-get install mysql-server-5.1
Noční můra PostgreSQL
Přestože jsem si od minula (upgrade Etch na Lenny) pamatoval, že PostgreSQL umí při upgrade pěkně potrápit, a připravoval jsem se na to celkem poctivě, skončil jsem dvakrát s úplně nefunkční databází. Ta je totiž mezi verzemi 8.3 (Lenny) a 8.4 (Squeeze) nekompatibilní a musí se při upgrade zkonvertovat. Ovšem při upgrade se zároveň odinstaluje postgres-8.3 a nainstaluje verze 8.4, která si okamžitě vytvoří svoji prázdnou databázi. Člověk ale potřebuje běžící verzi 8.3, aby dokázal upgradovat samotnou databázi na verzi 8.4.
Trvalo mi X hodin (X>5), než jsem to dal dohromady ze záloh, s pomocí downgrade PostgreSQL na verzi z Lenny (naštěstí mohou být obě verze nainstalovány zároveň), s magií okolo pg_dumpall, pg_restore, psql, potížemi se zjišťováním standardního charsetu a dalšími čáry-máry. Přitom normálně to jde (má jít) takto jednoduše:
# pg_dropcluster 8.4 main --stop # pg_upgradecluster 8.3 main # pg_dropcluster 8.3 main
Jabber server
Jabber server jsem ještě dohromady nedal. Starý XML konfigurační soubor měl 40 kB a data uživatelů byla v jednotlivých souborech. Ten nový z jabberd1.4 má 60 kB a je se starým nekompatibilní. Data uživatelů jsou navíc uložena v databázi. Přemýšlím, jestli by programátoři měli jít do pekla za to, že neřeší zpětnou kompatibilitu konfigurace svých aplikací ani její automatickou konverzi, pokud už mají nutkání dělat takové změny. Ručně editovat 60 kB XML a hledat v něm rozdíly oproti tomu 40kB je poněkud časově náročné. Kdyby to aspoň byl obyčejný plaintext klíč=hodnota, pak by měl tak 50 řádků místo 1100.
Grub2
Debian Squeeze přichází se zavaděčem Grub2 ve verzi 1.98. Ze samého nadšení z nového balíčku grub2 a veden tendenci uklízet staré nepotřebné věci jsem odinstaloval balíček grub, což smazalo i grub-pc, který vlastně obsahuje ten Grub2 ( grub a grub2 jsou jen dummy balíčky). Naštěstí jsem si toho všiml včas (ještě před rebootem), a tak jsem rychle nainstaloval grub2, který zase zpátky přitáhl i grub-pc. Někdy je lepší neuklízet a nemazat staré věci tak rychle/zbrkle.
S přechodem na Grub2 souvisí i skript upgrade-from-legacy-grub, který se má zavolat až poté, co se vyzkouší, že boot zřetězený přes starý Grub funguje i s Grub2. Překvapením pro mě bylo, že se tento skript dá zavolat opakovaně, a pokaždé se hezky zeptá, na které disky chci zavaděč zapsat. Protože používám RAID1 nad diskovými oddíly, došlo mi, že /dev/md0 mu tam dávat nemusím, a tak jsem tam zadal jen všechny /dev/sdX. Každopádně je dobré po ověření funkčního grub2 smazat starý /boot/grub/menu.lst*:
# upgrade-from-legacy-grub # rm -f /boot/grub/menu.lst*
Přechod na dependency based boot
Na všech strojích mi při upgrade selhal automatický přechod na závislostmi řízený start systému. V drtivé většině za to mohly zapomenuté iniciační soubory ( /dev/rc?.d/* nalinkované z /dev/init.d/*). Zkuste následující příkazy, které vám vypíší všechny balíčky, které jsou sice odinstalované, ale pořád ještě drží konfigurační a jinak vytvořené soubory v systému:
# dpkg -l | awk '/^rc/{print $2}'
Pokud nepomohlo odinstalování nepotřebných balíčků a smazání jejich konfiguračních souborů, tak byl zádrhelem vždy balíček libdevmapper1.02. Na něj platil jeho upgrade na verzi 1.02.1. Následuje „miniskript“, který upgraduje libdevmapper, smaže všechny konfigurační soubory dávno odinstalovaných balíčků (pozor, smaže opravdu všechno!) a znovu se pokusí o přechod na závislostmi řízený start systému:
# apt-get install libdevmapper1.02.1
# dpkg -l | awk '/^rc/{print $2}' | xargs apt-get -y purge
# dpkg-reconfigure sysv-rc
Na jednom serveru jsem musel upravit svůj vlastní skript /etc/init.d/enhydra (používaný pro start TAS, Together Application Server – dříve Enhydra Application Server) tak, aby byl připraven na závislostní zavádění. Jednoduše jsem mu přidal hlavičku, kterou jsem zkopíroval ze zavaděče Apache2 a nepatrně upravil (přidal jsem tam jen závislost na databázi):
#! /bin/sh ### BEGIN INIT INFO # Provides: enhydra # Required-Start: $local_fs $remote_fs $network $syslog $named postgresql # Required-Stop: $local_fs $remote_fs $network $syslog $named postgresql # Default-Start: 2 3 4 5 # Default-Stop: 0 1 6 # X-Interactive: true # Short-Description: Start/stop enhydra app server ### END INIT INFO
Locales
Při bootu jsem si všiml zmínky o tom, že /etc/environment se už nepoužívá, že si mám raději dát dohromady locales. Takže se stačí do toho souboru mrknout, jaký jazyk jsem pro systém preferoval doteď (většinou prázdný, sem tam angličtinu, výjimečně češtinu) a pak to stejně (nebo lépe) zadat při konfiguraci locales. Stejně jsem si přidával UTF-8 varianty angličtiny a češtiny, kde jsem je ještě neměl. Na jednom stroji jsem je dokonce neměl nainstalované, takže kompletní set příkazů pro přechod je:
# apt-get install locales # dpkg-reconfigure locales # rm -f /etc/environment
Úklid s rozumem
To uklízení starých nepotřebných konfiguračních souborů neexistujících balíčků se mi nesmírně zalíbilo a začal jsem ho provádět s nadšením na všech strojích – až do chvíle, než jsem si smazal kompletní logy všech webserverů. To jsem totiž před lety při přechodu na apache2 chtěl ponechat jeho logy ve /var/log/apache, jak byl webalizer zvyklý, a tak jsem tehdy smazal adresář /var/log/apache2 a apache2 jsem jen nasymlinkoval na apache.
Všechno fungovalo do chvíle, než jsem výše zobrazeným miniskriptem zavolal apt-get purge apache, což zrušilo i celý adresář /var/log/apache se všemi logy z apache2. Zbyl mi jen symlink ukazující nikam… Fakt se to s tím úklidem nemá přehánět.
Skutečná konfigurace systému
Výše jsem popsal hrubý přechod od jedné verze Debianu k druhé. Během celé instalace se systém zastavuje a hlásí, kdykoliv narazí na rozdíly v konfiguračních souborech původního a nového balíčku. Bohužel ne všechno se dá změnit automaticky, a tak si uživatel musí vybrat, jestli ponechá stávající verzi (obvykle se svými úpravami), anebo riskne novou verzi od správce balíčku. Většinou jsem volil „ponechat stávající“ s tím, že jsem si poznačil jméno souboru, ke kterému se ještě musím vrátit a podrobně prostudovat, v čem se nová verze konfiguračního souboru liší a případně ty změny zavést ručně do své verze – to bude ještě dost práce. Původní konfigurace obvykle funguje jakž-takž, jen ten Jabber mě tentokrát nechal zcela na holičkách…
Závěr
Debian je univerzální a mocný operační systém, který je kromě široké podpory 11 architektur a téměř 30 tisíc softwarových balíčků proslulý svou politikou vydávání stabilních verzí až v momentu, kdy jsou opravdu stabilní. Vydání pak obsahuje i bezpečný a vyladěný přechod od jedné verze systému k druhé. Přestože se z výše uvedených zážitků může zdát, že přechod mezi verzemi není triviální a že by se to dalo ještě zlepšit, jsem s Debianem rád. Konec konců se takto divoce upgraduje jen jednou za pár let…
ČLÁNKY DO MAILU