Úvod
Pokud jste si nepřečetli poslední dva díly (první díl, druhý díl), doporučuji tak učinit, neboť v nich zazněly velmi podstatné informace, počínaje popisem správy softwaru v linuxových distribucích, přes různé alternativy ke kompilaci či důvody, proč je vhodné se jí snažit vyhnout, až po samotný postup a technické pozadí kompilace, které bylo představeno v minulém díle.
Stabilní, vývojová a SCM verze
Ještě před samotnou kompilací zmíním jednu věc, kterou jsem dostatečně neosvětlil v minulých dvou dílech, a sice, jaké verze softwaru jsou obvykle k dispozici a jaký je mezi nimi rozdíl. Většina FOSS projektů má něco jako stabilní vývojovou větev. Stabilní větev by měla obsahovat dostatečně otestovaný, časem ověřený kód s minimem chyb. Na server je to určitě dobrá volba.
Často je ovšem k dispozici i testovací či vývojová verze. Ta obsahuje obvykle novější vlastnosti, které zatím ještě do stabilní verze nepronikly, neboť nebyly dostatečně otestovány. Vývojové verze obsahují zpravidla řádově více chyb než jejich stabilní protějšky, přičemž některé vlastnosti ve vývojových verzích nemusí být ještě zcela funkční (nebyly zcela implementovány), popřípadě se mohou časem i zásadně měnit – na to je třeba si dávat obzvlášť pozor, zejména při aktualizacích. Vývojovým verzím je vhodné se vyhnout, pokud to jde.
V souvislosti s vývojovými verzemi je vhodné zmínit i často používané názvosloví určující aktuální stádium vývoje: pre-alpha, alpha, beta a release candidate. Verze označená jako pre-alpha je obvykle software v raném stádiu vývoje, mnohé vlastnosti ještě nejsou vůbec implementované, mnohé se mění, často i zásadně. Taková verze by na serveru neměla co dělat, jelikož může obsahovat kritické chyby vedoucí ke ztrátě dat. Stádium alpha je na tom jen o málo lépe než pre-alpha. Mnohé vlastnosti by již měly být implementovány, i když stále je pravděpodobný výskyt kritických chyb. Ledacos také nemusí fungovat správně nebo se může časem výrazně změnit. I toto stádium bych na server důrazně nedoporučil.
Stádium beta by mělo označovat dokončení všech připravovaných vlastností (ty by se již neměly měnit) a počátek testování ze strany uživatelů. Chyby jsou, přirozeně, v tomto stádiu stále očekávané. Následuje release candidate, tedy kandidát pro vydání. To už je více méně hotový produkt, ale stále se čeká na nalezení závažných chyb. Pokud nejsou nalezeny závažnější chyby během určité doby, obvykle dojde k vydání.
Poslední „verze“ softwaru, se kterou můžete přijít do styku, je snapshot ze SCM nástroje (Subversion, Git, Mercurial, apod.). Je to de facto snímek zdrojového kódu platný k určitému datu – nejčastěji se bere ten nejnovější. Jelikož pokročilé nástroje pro správu verzí softwaru (SCM) umí držet současně více větví, záleží určitě, kterou větev (branch) jste si zvolili jako zdroj (záleží ovšem také na tom, jaká pravidla vývoje jsou v rámci daného projektu v platnosti). Stabilní větev by měla mít přibližně charakter stabilního vydání, vývojová větev bude v některém z výše uvedených stavů, a její nasazení na server lze proto důrazně nedoporučit. Často se ovšem s takovou verzí setkáte, jelikož v ní bude patrně opravená nějaká nepříjemná chyba (oproti poslední vývojové verzi stažitelné z webu projektu, pokud taková je).
Výše uvedená pravidla samozřejmě podléhají tomu, jak na vývoj nahlíží vývojáři projektu, který chcete nasadit. Stabilní verze jednoho projektu může stabilitou klidně odpovídat vývojové verzi jiného. Záleží na typu projektu a na vývojářích. Obecně je vhodné se nestabilním verzím vyhnout, pokud nemáte opravdu dobrý důvod je nasadit.
Kompilace zvoleného softwaru
Software, který bude sloužit jako pokusný králík pro kompilaci, je webový server Apache, kterému se tento seriál věnoval v několika dílech. Je to pouze příklad, na kterém bude demonstrována kompilace. V žádném případě se nejedná o doporučený způsob kompilace Apache. Kromě toho, Apache určitě naleznete v repozitářích vámi používané distribuce. Budete-li chtít kompilovat právě Apache, určitě se primárně řiďte oficiální dokumentací, na kterou článek pro úplnost odkazuje.
Nahlédnutí do dokumentace
Před tím, než budete software kompilovat, doporučuji podívat se do dokumentace, ať už dokumentace na webu projektu nebo dokumentace přibalené v příslušném zdrojovém balíčku. Obvykle zde naleznete návody či případné důležité informace týkající se kompilace ze zdrojových kódů. Uvnitř balíčku hledejte soubory README a INSTALL. V případě webového serveru Apache je dokumentace dostupná online.
Získání a příprava zdrojového kódu
Vyberte si vhodnou verzi (dle rad výše) a stáhněte si příslušný balíček, obvykle je to tar.gz, i když tar.bz2 bývá menší, tedy úspornější na přenášená data. Na serveru můžete pro samotné stažení použít nástroj wget, což se určitě hodí, máte-li na stanici, ze které se vzdáleně připojujete k serveru, pomalý upload (typické pro ADSL a mobilní připojení). Můžete si také pomoci textovým prohlížečem přímo na serveru:
lynx http://httpd.apache.org/download.cgi
Jelikož je při instalaci na server vhodné dbát zvýšené opatrnosti, je třeba si po získání balíčku ověřit kontrolní součty či digitální podpisy. Opatřete si příslušné PGP klíče a ověřte podpis náležející příslušnému souboru. Zde je samozřejmě otázka, jak si opatřit PGP klíče vývojářů z opravdu důvěryhodného zdroje. Pokud se vám nechce hledat nejbližšího vývojáře, spojit se s ním, domluvit osobní setkání, ověřit jeho občanku a zaznamenat si otisk (fingerprint) jeho klíče, můžete zkusit méně bezpečnou metodu popsanou na stránkách projektu, a sice stáhnout soubor s PGP klíči vývojářů (doporučuji alespoň přes HTTPS a přímo ze serveru apache.org), importovat tyto klíče a ověřit podpis, takto:
gpg --import KEYS gpg --verify httpd-2.2.20.tar.bz2.asc
Po ověření balíček se zdrojovým kódem rozbalte:
tar xvf httpd-2.2.20.tar.bz2
Závislosti
Závislosti, ať již kompilační či běhové (vysvětlení v minulém díle) si budete muset zajistit sami (ideálně instalací příslušných balíčků, v horším případě je budete muset zkompilovat jako první). V rámci Debianu je třeba dodat, že hlavičkové soubory potřebné pro kompilaci jsou v extra balíčcích. Pokud tedy máte jako závislost nějakou komponentu, obvykle nestačí instalovat pouze balíček s binárkou komponenty (např. libknihovna), ale musíte ještě přidat balíček s příslušnými hlavičkovými soubory pro kompilaci, tedy např. libknihovna-dev.
Nejideálnějším postupem je zjistit závislosti z dokumentace, nejméně účinným způsobem je pak spouštět skript ./configure opakovaně a orientovat se dle chybových hlášek. V Debianu však existuje ještě jeden elegantní způsob, jak závislosti řešit. Máte-li vámi kompilovaný software v repozitářích (byť v jiné verzi), můžete si ušetřit práci pomocí správce balíčků – Debian totiž umožňuje kompilaci z tzv. zdrojových balíčků, a v souvislosti s tím umožňuje jednoduchým příkazem nainstalovat všechny závislosti potřebné pro kompilaci daného balíčku, takto:
apt-get build-dep apache2
Chcete-li pouze rekompilovat balíček dostupný z repozitářů (nechcete jinou verzi), popřípadě chcete-li si sestavit vlastní balíček a hledáte vhodný vzor, můžete použít apt-src, postup je naznačen v odkazech pod článkem.
configure
Následuje „svatá trojice“, tedy ./configure, make a make install. Fáze konfigurace je ta nejnáročnější na činnost správce, jelikož se obvykle nespokojíte s pouhým spuštěním skriptu ./configure, ale budete hledat ty správné volby, které daný program zkompilují s těmi správnými vlastnostmi. Mnohé vlastnosti lze totiž zahrnout nebo naopak vyřadit vhodnými parametry. Méně vlastností znamená obvykle větší bezpečnost, naopak někdy můžete mít zájem zkompilovat daný software s parametrem, který vámi zvolená distribuce při sestavování binárního balíčku ignorovala. Zde opět odkážu na dokumentaci vámi zvoleného projektu. Dokumentace Apache je nejen v tomto ohledu vskutku vynikající, viz podrobný článek o konfiguračních volbách. Kupříkladu, pokud nechcete v Apachi používat CGI, použijete volbu --disable-cgi:
./configure --disable-cgi
Nejzásadnější volbou pro ./configure je patrně --prefix, která určuje, kam se daný software nainstaluje ve fázi make install. Specifikací konkrétního adresáře můžete klidně udržovat více verzí daného softwaru najednou:
./configure --prefix=/opt/apache-2.2.20
Pokud nespecifikujete prefix, použije se výchozí volba, která závisí na tom, co zvolil příslušný vývojář. Nejčastěji je cílem /usr/local. Já však, jak naznačuje příklad výše, preferuji /opt. To ale není důležité. Důležité je, abyste měli o souborech, které se vytvoří při instalaci, přehled, a mohli pak software snadno odinstalovat nebo spolehlivě nahradit novou verzí.
Unixový software si obvykle v adresáři specifikovaném jako prefix vytvoří vlastní strukturu s adresáři bin, lib, atd., a tam umístí příslušné soubory. V mém příkladu výše byste pak ke zkompilovanému Apachi přistupovali přes /opt/apache-2.2.20/bin/apache2ctl.
make
Tento příkaz provede samotnou kompilaci. Máte-li vícejádrový či víceprocesorový server (nebo obojí), doporučuji přidat volbu -j s parametrem v podobě čísla odpovídajícímu počtu procesorů zvýšeného o jedničku. Máte-li dvouprocesorový server se čtyřmi jádry, tj. s osmi logickými procesory, zvolili byste devítku (8 jader + 1):
make -j9
V době vícejádrových a vícevláknových procesorů by byla škoda kompilovat na jednom jádře, tedy velmi, velmi pomalu v porovnání s možnostmi stroje. Na serveru, který obsluhuje klienty, je však vhodné ještě upravit prioritu kompilace. V unixových systémech se priorita nastavuje jako „niceness“ (ohleduplnost), tzn. vyšší číslo znamená nižší prioritu (větší ohleduplnost k okolí). V Linuxu má priorita meze od -20 (nejvyšší priorita) do 19 (nejnižší priorita). Pokud na kompilaci nespěcháte, devatenáctka je asi nejvhodnější:
nice -n 19 make -j9
Máte-li naopak pomalý počítač, který kompiluje příliš dlouho, a na dostatečně rychlé LAN máte k dispozici silný stroj, obraťte svou pozornost k nástroji distcc, kterým můžete propojit více počítačů a vytvořit si malý kompilační „cluster“.
Instalace
Pokud kompilace proběhne bez chyb, zbývá software nainstalovat. Dosud bylo možné všechny kroky (s výjimkou používání správce balíčků) vykonávat bez práv superuživatele. K instalaci je ovšem jeho oprávnění potřeba. Výjimkou může být situace, kdy jste použili prefix k tomu, abyste software mohli nainstalovat do adresáře, který patří aktuálnímu uživateli. V takovém případě bez obav instalujte.
Pokud software nainstalujete přímo, pomocí make install, správce balíčků o těchto souborech nebude nic vědět a nebude je moci odstranit nebo vám říci, kde jsou. Můžete si samozřejmě vytvořit balíček, který nainstalujete pomocí dpkg, ale to obvykle představuje hodně práce. Existuje však i jiná možnost - nástroj checkinstall, který se používá místo make install. Tento nástroj vám balíček na počkání balíček vytvoří:
checkinstall
Checkinstall je interaktivní program, stačí zodpovědět několik otázek, případně upravit nastavení balíčku. Poté vytvoří Checkinstall balíček obsahující váš program. Tento balíček můžete nainstalovat pomocí nástroje dpkg:
dpkg -i apache-custom_2.2.20-1_i386.deb
Checkinstall ovšem nevyplňuje závislostní vazby balíčku. Je to tedy jen polovičaté řešení – správce balíčků sice bude o vašem softwaru vědět a bude ho moci odstranit, ale nebude moci v souvislosti s ním řešit závislostní vazby. Ty si budete muset ohlídat sami.
