Správa linuxového serveru: Kompilace softwaru prakticky

30.8.12

Správa linuxového serveru: Kompilace softwaru prakticky - Linux E X P R E S

Home » Články » Praxe » Správa linuxového serveru » Správa linuxového serveru: Kompilace softwaru... Předchozí kapitola

Zpět na obsah

Následující kapitola

Správa linuxového serveru: Kompilace softwaru prakticky Ačkoliv je ideální používat správce balíčků a repozitáře, které obsahují drtivou většinu toho, co budete potřebovat, někdy není jiná možnost a je třeba sáhnout ke kompilaci nějakého softwaru ze zdrojových kódů. Poslední dva díly se věnovaly kompilaci převážně z teoretického hlediska, tento díl vše ukáže na praktickém příkladě. Pondělí, 5. září 2011 | Autor Michal Dočekal | známka 1,00

Ú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: prealpha, alpha, beta a release candidate. Verze označená jako prealpha 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ž prealpha. 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í.

www.linuxexpres.cz/praxe/sprava-linuxoveho-serveru-kompilace-softwaru-prakticky

1/5

30.8.12


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. Budeteli 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áteli 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 httpd2.2.20.tar.bz2.asc

Po ověření balíček se zdrojovým kódem rozbalte:


2/5

30.8.12


tar xvf httpd2.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ř. libknihovnadev. 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áteli 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: aptget builddep apache2

Chceteli pouze rekompilovat balíček dostupný z repozitářů (nechcete jinou verzi), popřípadě chceteli si sestavit vlastní balíček a hledáte vhodný vzor, můžete použít aptsrc, 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 disablecgi: ./configure disablecgi

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/apache2.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/apache2.2.20/bin/apache2ctl.


3/5

30.8.12


make Tento příkaz provede samotnou kompilaci. Máteli 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áteli 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áteli 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 apachecustom_2.2.201_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.

Zdroje a další odkazy Předchozí kapitola

Zpět na obsah

Následující kapitola

Odkazy Pokud si chcete přečíst více o této problematice, navštivte tyto odkazy:


4/5

30.8.12


Wikipédie, Software release life cycle Web projektu Checkinstall Compiling and installing Apache Aptsrc

Přidat téma diskuse Nejsou podporovány žádné značky, komentáře jsou jen čistě textové. Více o diskuzích najdete v nápovědě. Diskuzi můžete sledovat pomocí RSS kanálu


5/5

Správa linuxového serveru: Kompilace softwaru prakticky

Recommend Documents