Jakmile se v pátek objevil článek o konci prodloužené podpory operačního systému Debian Squeeze, věděl jsem, že o víkendu budou mít někteří „o zábavu postaráno“. Přesto, že jsem za poslední roky při každé vhodné příležitosti instaloval Debian Wheezy či nejnověji rovnou verzi Jessie, stále mi zbývalo ještě 10 serverů, na kterých díky Debianem prodloužené podpoře do dneška spokojeně běží verze Squeeze. Bez oficiální bezpečnostní podpory ale provozovat server se službami dostupnými přes Internet není rozumné, tudíž je na místě okamžitý upgrade tohoto již pět let starého systému. Mimochodem, odkládání upgrade na poslední chvíli nepovažuji za prokrastinaci, ale za rozumně aplikované zlaté pravidlo „nesahej na věci, které fungují“.
Připomeňme si, že Debian má upgrady rád, odjakživa je podporuje a snaží se je udělat co nejméně bolestnými. Správci balíčků i celého systému tvrdě pracují na tom, aby upgrade proběhl bez problémů, což zahrnuje nadstandardní podporu: když se například v upstreamu změní konfigurace některého programu tak, že konfigurační soubor pro starou verzi je nekompatibilní s novou (či naopak), instalační skripty v daném debianím balíčku se pokusí automaticky změnit stávající konfigurační soubor na vašem počítači tak, aby i po změně verze programu dál všechno fungovalo „samo“, bez nutnosti ručního zásahu administrátora. Samozřejmě ne vždy se to podaří, především v situaci, kdy jste provedli vlastní úpravy, se kterými si instalační skript neporadí a raději nabídne uživateli několik možností, jak danou situaci řešit.
Jak na upgrade
Proces samotného upgrade operačního systému Debian je jednoduchý, přímočarý, dobře zdokumentovaný a zahrnuje jen několik málo kroků:
- kontrola, že v systému jsou všechny balíčky na upgrade připraveny
- poslední upgrade ve „staré“ verzi operačního systému
- změna konfiguračního souboru sources.list, který určuje, odkud taháme balíčky se sofwarem
- aktualizace databáze všech dostupných balíčků
- částečný upgrade (který neodstraňuje existující ani nepřidává žádné nové balíčky, jen povyšuje verze)
- úplný upgrade (který už i odinstalovává balíčky, které kvůli závislostem mezi balíčky v nové verzi systému už nejsou k dispozici)
- restart systému zavede nové jádro (které určitě v rámci upgrade systému také přijelo) a máme hotovo
Pod uživatelem root by se předchozích sedm kroků dalo shrnout do následujících příkazů (co krok, to jeden řádek):
# dpkg --get-selections | grep 'hold$' # apt-get update && apt-get dist-upgrade # perl -i -pe 's/squeeze/wheezy/g' /etc/apt/sources.list # apt-get update # apt-get upgrade # apt-get dist-upgrade # reboot
Pokud máte v sources.list i řádek se zdrojem squeeze-lts, ten po hromadné náhradě slova „squeeze“ slovem „wheezy“ ještě fungovat nebude. Předpokládám, že LTS verze (ta s dlouhodobou podporou) se objeví až když půjde Wheezy do důchodu, což je rok po vydání Jessie, tedy 26. dubna 2016. Pokud tam máte ještě i jiné zdroje (debian backports, či úplně třetích stran), tak ty můžou během upgrade pozlobit ještě více. Proto si raději ukažme „čistý“ sources.list vhodný pro upgrade ze Squeeze na Wheezy:
deb http://ftp.cz.debian.org/debian/ wheezy main contrib non-free deb http://ftp.cz.debian.org/debian wheezy-updates main contrib non-free deb http://security.debian.org/ wheezy/updates main contrib non-free
Doporučuji navíc celou událost (minimálně kroky 5 a 6) nahrávat, aby bylo kdykoliv možné se k záznamu vrátit a přečíst si, co nám třeba uniklo odrolováním za horní okraj obrazovky:
script -t 2>~/upgrade-wheezystep.time -a ~/upgrade-wheezystep.script
Pokud máte nainstalovaný balíček apt-listchanges, tak nejen, že se důležité poznámky o změnách v balíčcích objeví na obrazovce ještě před jejich instalací, ale budou vám také zaslány mailem. To například mě docela zachraňuje, protože jsem si komplikovanější průběh upgrade jednoho serveru nenahrával, a tak až z mailů od „apt-listchanges“ zpětně zjišťuji, co všechno je jinak a co je potřeba opravit ručně.
Skutečný průběh
Pojďme se podívat na to, jak dopadl upgrade jednoho poměrně běžného LAMP serveru s poštou, který už kdysi absolvoval upgrade z Lenny na Squeeze (a možná, že ještě předtím i z verze před Lenny, to už si nepamatuji). Je možné, že následující delší popis pomůže někomu, koho upgrade na Wheezy teprve čeká. Ve zkratce pro nedočkavé: po upgrade mi nefungovala databáze, PHP, Wiki, CVS, SVN, Archivemail ani systémové logování. Navíc blbnul Amavis, trochu běžel Apache a měl jsem jen původní kernel ze Squeeze řady 2.6.x. Proč tomu tak bylo a jak to celé opravit?
Chybějící MySQL
Po upgrade systému neběžela MySQL databáze. Běžet ani nemohla, v systému vůbec nebyly přítomny balíčky mysql-server*, které tento program instalují. Ve Squeeze jsem měl (zřejmě ručně?) nainstalovaný balíček mysql-server-5.1, který ve Wheezy není, takže se v dist-upgrade fázi odinstaloval a nezůstalo mi nic. Řešením je apt-get install mysql-server. Ten si díky závislostem doinstaluje i mysql-server-5.5, což je aktuální verze pro Wheezy. A až budu upgradovat na Jessie, tak meta-balíček mysql-server zaručí, že o databázový program už znova nepřijdu.
PHP
Tohle mi docela zamotalo hlavu. Nejdříve se ale musím vrátit k situaci, kterou jsem popisoval v úvodu článku. Když během upgrade instalační skripty v balíčku chtějí nasadit novou verzi konfiguračního souboru, podívají se, jestli v něm nemám nějaké vlastní změny. A pokud ano (a já skutečně měl v /etc/php5/apache2/php.ini nějaké drobné úpravy), nabídnou mi několik možností: ponechat mou původní verzi s mými změnami, nainstalovat novou verzi od správce balíčku, porovnat obě verze, abych se mohl správně rozhodnout, atd. Zkusil jsem tedy porovnat obě verze, abych viděl, můžu-li nechat instalační skript nasadit rovnou novou verzi z balíčku, ale ouha – někdo si dal práci s tak velkými změnami v souboru php.ini, že prostým okem nebylo vůbec jasné, co všechno je tam jinak a co to udělá. Proto jsem pro jistotu zvolil „ponechat mou původní verzi konfiguračního souboru“, a tím jsem si zadělal na problémy.
Soustředil jsem se na hlášku find: neplatný argument „-delete“ u „-cmin“, která mi začala co pár minut chodit mailem. Způsoboval to skript /usr/lib/php5/sessionclean volaný z cronu, který má za úkol mazat staré PHP sezení uložené v souborech. Záhadu, proč by měl mít příkaz find jinou syntaxi parametrů na příkazové řádce ve Wheezy než ve Squeeze jsem rozluštil poté, kdy jsem zjistil, že jako hodnotu pro parametr -cmin bere výsledek volání skriptu /usr/lib/php5/maxlifetime, který má vrátit počet sekund, ale nevrátí nic. Takže se bere jako čas pro -cmin další slovo na řádce, tedy -delete. Je velká chyba se takto slepě spoléhat na návratovou hodnotu skriptu a nekontrolovat ji před použitím.
Proč se ale ze skriptu maxlifetime nevrátí nic? Je napsaný docela robustně a má výchozí hodnotu pro případ, že něco selže. Vypreparoval jsem z něj ten klíčový příkaz a pustil ho samostatně:
# php5 -c /etc/php5/apache2/php.ini -r 'print ini_get("session.gc_maxlifetime");'
Tento jednořádkový program má jednoduše vypsat konfigurační hodnotu session.gc_maxlifetime z konfiguračního souboru daného cestou za parametrem -c, ale nevypíše nic, což asi nikdo ani ve snu nečekal. Nebudu nudit čtenáře popisem další půlhodiny pátrání. Nakonec za všechno mohlo rozhodnutí ponechat původní konfigurační soubor php.ini, který ve verzi pro PHP 5.3.3 (z Squeeze) obsahoval krom jiného i volbu allow_call_time_pass_reference, což nové PHP 5.4.x (z Wheezy) rozzuřilo natolik, že zcela rezignovalo na konfigurační soubor, a tak nebylo schopno vypsat žádnou hodnotu pro gc_maxlifetime. Řešením bylo přepsat můj konfigurační soubor tím výchozím z nového balíčku PHP5, který tam na mě čekal v souboru /etc/php5/apache2/php.ini.dpkg-dist. Poté jsem do něj musel ručně doplnit své obvyklé změny (zvýšit hodnotu upload_max_filesize apod.).
Dalším zajímavým zádrhelem byla chybová hláška v PHP logu:
/usr/lib/php5/20100525/suhosin.so: cannot open shared object file: No such file or directory in Unknown on line 0
Toto je způsobeno tím, že ve Wheezy už „Suhosin“ v PHP není podporován, a proto zcela chybí balíček php5-suhosin. Ten byl odinstalován při dist-upgrade, ale jeho konfigurační soubor ve filesystému zůstal a byl automaticky vložen i do konfigurace nového PHP, které si poté stěžovalo, že sdílenou knihovnu nemůže najít a natáhnout. Řešením je smazat konfigurační soubor Suhosinu – buďto ručně, anebo uklidit po odinstalovaném balíčku pomocí apt-get purge php5-suhosin. Příkaz purge totiž maže i konfigurační soubory a další pozůstatky po balíčcích.
Poslední, leč zásadní poznámka k PHP5 ve Wheezy: správce balíčku Ondřej Surý v ChangeLogu píše, abychom se na Wheezy ani nezastavovali a rovnou upgradovali až na Debian Jessie, protože PHP řady 5.4 (která je ve Wheezy) už není PHP týmem od září 2015 podporována. Debian se sice bude snažit jakousi podporu zajistit, ale zkrátka lepší by bylo přejít až na řadu 5.6, která je oficiálně podporována ještě alespoň dva roky. Škoda jen, že Ondřej poskytuje backport PHP 5.6 pro staré Ubuntu na svém webu deb.sury.org, ale podpora pro Debian tam zatím není.
Dokuwiki
Dokuwiki používám ve verzi pro „farmu“, což je jakési rozšíření pro provoz více dokuwiki webů (na různých URL) na jedné instalaci Dokuwiki. Po upgrade na Wheezy nefungovala vůbec. Ukázalo se, že nová verze Dokuwiki vyžaduje přítomnost nových adresářů media_attic a media_meta pod adresářem data každé dokuwiki. Instalační skript tyto dva nové podadresáře vytvořil na správném místě pro jednu Dokuwiki, ale netušil nic o „farmě“, která má datové soubory jinde. Pomohlo vytvořit tyto podadresáře ručně, pak se všechny Dokuwiki rozeběhly a fungují OK.
CVS a SVN
CVS server v nové verzi, jak píší poznámky v ChangeLogu, představuje úplně nový balíček, který nově nedělá některé kroky u CVS repozitářů automaticky, ale přenáší mnoho správcovských povinností na administrátora. A navíc už vůbec nepodporuje přístup přes pserver – jediná možnost je migrovat uživatele na přístup přes SSH. To mě ještě čeká.
SVN přestal fungovat, protože něco není dobře v dynamické knihovně pro Apache2, ale tohle je zrovna jedna z informací, která mi odrolovala dřív, než jsem si ji stihl přečíst. Proto nahrávejte sezení příkazem script, já zatím celý Subversion zruším, stejně se už nepoužíval.
Archivemail
Program archivemail, který umí pěkně uklidit v poště, ve verzi ve Squeeze při každém spuštění z cronu neopomněl zmínit, že spouštět ho pod rootem je velká chyba a že už to nebude podporovat. Čtyři roky si takto dennodenně stěžoval, ale vždycky udělal svou práci dobře. Po upgrade na verzi ve Wheezy suše oznámil, že /home/bfu/mail/Trash nepatří uživateli a konec.
Soubor Trash samozřejmě patřil uživateli bfu, takže jsem chvíli nevěděl, která bije, ale nakonec mi to došlo. Řešením je pouštět archivemail pod uživatelem, jehož poštu uklízíme, což vyžaduje napsat na to drobný skript zhruba následujícího znění:
cd /home
for i in *
do
if [ -f $i/mail/Trash ]
then
su -c "archivemail --quiet --days=7 --delete --include-flagged $i/mail/Trash" $i
fi
done
Prázdný syslog
Při upgrade došlo k odinstalování balíčku sysklogd, který normálně zajišťoval logování systémových hlášek do souboru /var/log/syslog, ale v nové verzi systému už není. Ve Wheezy je potřeba nainstalovat ručně jiný program, buďto inetutils-syslogd anebo rsyslog. Nainstaloval jsem ten prvně zmíněný a syslog opět začal utěšeně narůstat.
Amavis
V syslogu, kam Amavis hlásí, co se děje, se začala objevovat chyba:
(!)WARN save_info_final: sql exec: err=1054
Řešením je přidat čtyři nové sloupce do tabulky, jak je popsáno v /usr/share/doc/amavisd-new/RELEASE_NOTES.gz a podrobněji i v dokumentech pro jednotlivé databáze.
Kernel pro Vserver
Poslední poznámka se týká kernelu. Pokud se, podobně jako já, nemůžete zbavit závislosti na (para)virtualizačním řešení zvaném Vserver, ve Wheezy budete mít problém: Debian už neposkytuje kernely, které by obsahovaly nezbytné úpravy. Proto mi také nepřijel žádný novější kernel během upgrade. Jakýmsi řešením je spolehnout se na firmu Psand, která nadále kernely pro Linux-Vserver udržuje jak pro Wheezy, tak snad brzy i pro Jessie. Stačí si přidat do /etc/apt/sources.list následující řádek:
deb http://repo.psand.net/ wheezy main
Poté můžeme nainstalovat nový kernel příkazem apt-get install linux-image-vserver-3.2-beng. No, skutečným řešením by spíš byl přechod na LXC, ale to stojí za pokus až v Jessie.
Závěrem
Odmyslíme-li si problémy vzniklé odinstalací balíků mysql-server-5.1 a sysklogd bez náhrady, a změny v nových verzích programů, které si vynutily ruční konfiguraci (Archivemail, Amavis, CVS), zůstane pouze ten problematický PHP5 upgrade. U něj si myslím, že autoři PHP byli zbytečně přísní při implementaci parseru konfiguračního souboru. Reagovat na přítomnost dnes už nepodporované konfigurační direktivy tím, že selže výpis (a zřejmě i načtení) celé konfigurace, je podle mě přehnané a zadělává na dalekosáhlé problémy. Stačilo ji přece ignorovat.
Rozhodovat se během upgrade (zvlášť pod časovým tlakem při upgrade živého systému), jestli zůstat u původního konfiguračního souboru, anebo ho přepsat tím z nového balíčku, není jednoduché. Vlastně si vybíráme, jestli ztratíme naši roky laděnou konfiguraci a program spustíme s výchozím, leč neznámým nastavením, anebo jestli uchráníme naše nastavení, ale za cenu případného znefunkčnění celé aplikace. Naštěstí zůstává po upgrade každého balíčku přítomen buďto původní soubor (s přidanou koncovkou .dpkg-old), anebo ten nový z balíčku (s koncovkou .dpkg-dist či .ucf-dist). Proto je nutné si pro skutečné dokončení upgrade systému projít všechny rozdíly mezi konfiguračními soubory a ručně přenést naše vlastní změny. Seznam souborů ke kontrole vygenerujete takto:
find /etc -name '*.ucf-dist' -o -name '*.ucf-old' -o -name '*.dpkg-old' -o -name '*.dpkg-dist'
Tak hodně zdaru při upgradech!
