Posts with tag Vývoj

SEO pro laiky, aneb jak dostat stránku do výsledku Google vyhledávače

Jul|22 2012

Vytvořit webovou prezentaci je dneska pomocí služeb jako webnode, netstranky nebo estranky hračkou. Zkušenější weboví developeři vytvoří stránky pomocí WYSIWYG programu, ručně nebo vybudují aplikaci i s logikou na serveru. Ať už je postup jakýkoliv, dostaneme se do stavu, kdy jsou stránky umístěny na veřejně dostupném serveru a nyní chceme na stránky nalákat návštěvníky. Následujících pár rad a informací by mohlo pomoci tomu, kdo se s tímto úkolem zatím nesetkal.

V základu se na stránky dostane člověk těmito způsoby: do prohlížeče zadá přímo adresu stránek, klikne na odkaz nebo reklamu na některém jiném webu nebo stránku vyhledá pomocí vyhledávače. Z tohoto nejvíce magická a zahalená tajemstvím je možnost poslední, kolem které se díky tomu vybudovalo celé nové odvětví, zvané SEO, neboli optimalizace pro vyhledávače. V našich podmínkách již můžeme brát v vahu pouze dva nejsilnější hráče, jsou jimi Seznam a Google, pomocí nichž vyhledává drtivá většina tuzemských potencionálních návštěvníků a ani jeden z nich bychom neměli ignorovat. Jejich cíl je jednoduchý - pro libovolnou frázi se snaží vrátit relevantní výsledky, tedy adresy, kterými jsou buďto celé weby nebo konkrétní pod-stránky.

První věcí, kterou by si začínající SEO optimalizátor měl položit, je, na které dotazy chce být mezi nalezenými výsledky. A pak se snaží všemi možnými způsoby přesvědčit vyhledávač, že právě jeho stráka je tou nejlepší, tedy nejrelevantnější. Jenže jak na to?

Jak o sobě dát vyhledávači vědět

V první řadě se o stránce musí vyhledávač nějak dozvědět. Google například nabízí celou řadu nástrojů, dostupnou pod Webmaster tools, díky které může majitel vyhledávači pomoci s indexací stránek. Sitemap, tedy XML dokument, místěný na daném webu a popisující strukturu webu, je základ, který by měl být googlu předložen, aby si mohl patřičně zaindexovat všechny pod-stránky webu.

Jinou možností, jak se Google nebo Seznam dostane na jednotlivé stránky, jsou zpětné odkazy, tedy odkazy, které směřují na danou stránku. Určitě není od věci takové odkazy vyrobit, kdy nejjednodušší je stránku zaregistrovat do nějakých katalogů stránek. Výhodou je skutečnost, že stránky s více zpětnými odkazy jsou vesměs brány jako více relevantní. Několik let zpátky byl dokonce počet zpětných odkazů nejdůležitější parametr. To se dnes již změnilo a větší důraz klademe na kvalitu stránky a webu jako takového.

Technologická kvalita stránky

V druhé řadě bychom měli stránky mít přívětivé pro roboty indexující obsah. To znamená mít čisté HTML, pokud možno bez obsahu načítaného pomocí JavaScriptu, zapomeňte na Flash, styl definujte pomocí CSS a používejte HTML tagy v jejich správném významu. Dobrou strukturu nadpisů a několik dalších měřítek kontrolují různé SEO analyzátory, kterých na webu najdeme nepřeberně. U obrázků bychom neměli zapomenout na popisky, indexační roboti zatím nejsou tak chytří, aby si obrázek sami rozpoznali.

Jak stránku vidí indexační roboti, si můžeme zkontrlovat, pokud v prohlížeči vypneme styly CSS. V tom případě by měl být na prvním místě hlavní obsah webu, potom řídící prvky, menu a případně obsah postranních banerů. Vytvořit tzv. SEO-friendly stránku opět nalezneme mnoho, pokud v prohlížeči zadáme frázi "SEO optimalizace".

Na obsahu záleží

Jako poslední v řadě jsem si nechal v současné době určitě tu nejdůležitější oblast - obsah. Pokud budete mít perfektní HTML a mnoho zpětných odkazů, ale obsah stránek nebude nabízet nic zajímavého, návštěvníky tam buďto nedostanete vůbec nebo si je neudržíte. A tím pádem tyto stránky nejsou zajímavé ani pro vyhledávače, které se snaží nabídnout uživatelům jen to, co opravdu hledají.

Vyrábět stránky bez vědomí, co chci návštěvníkům nabídnout, je dnes spíše výjimkou a nějakou představu většinou máme. Často ale vidím spíš omezenou představu, nabízející jen nutné minimum. Vytvoříme tak stránku, která možná splní účel, ale nebude vyčnívat mezi ostatními. Například kromě kontaktních informací a stručného výčtu toho, co má návštěvník u dané instituce hledat, stránka nic dalšího neobsahuje. To určitě nestačí, aby se návštěvník na stránky vrátil, vracel se tam pravidelně nebo stránku dokonce doporučil kamarádům prostřednictvím sociálních sítí. Když už jsme u nich, nezapomeňte na stránku umístit tlačítka pro sdílení a usnadnit tak návštěvníkům sdílení stránky.

A o čem tedy psát, když mě nic nenapadá? Pište o tom, co děláte, co se daří, i nedaří. Přibližte svůj business lidem, jak probíhá pracovní den, co jste během dne pozorovali netradičního. Pište odborné články nebo články pro laiky, přidávejte fotky s komentáři. Co do formy se může jednat o trvalou statickou stránku, blog nebo krátké novinky. A v neposlední řadě se můžete inspirovat konkurenčními weby.

Čeho se držet při psaní článků

Při psaní textů bychom měli v první řadě pamatovat na cílovou skupinu, použití klíčových slov nebo frází by mělo být umírněné a přirozené, aby člověka nijak neobtěžovalo. Dlouhé texty zároveň nejsou moc oblíbené, stručnější články s kratšími větami i odstavci jsou čtivější a pozornost bychom měli věnovat i gramatice. Není většího trapasu, než hrubá chyba ve shodě podmětu s přísudkem na homepage nebo dokonce v titulku.

Berte tento článek spíše jako lehký úvod k problematice, určitě zdaleka nepokrývá nějak velkou část a další samostudium je nutností. Rada na závěr je jednoduchá - tvořte web pro lidi, ne pro vyhledávače.

Tags: Internet | Programování | Prohlížeče | Sítě | Počítače | Google | Facebook | Vývoj



Otevřená budoucnost i jinde než v IT?

Apr| 9 2012

Na přítomnost open source, tedy otevřeného a volně šířitelného zdrojového kódu jsme si již zvykli. Dokonce není tajemstvím, že se na takovém softwaru zdarma dá celkem slušně vydělat - například firma Red Hat letos na podpoře open source softwaru tržila přes miliardu dolarů. Asi nejen mě v tu chvíli napadá, jestli se tento model nedá přenést i do jiných, nejenom inženýrských, odvětví.

Výhodou otevřeného kódu je zejména tranparentnost a o to větší bezpečnost a často i kvalita aplikací, nízké náklady na provoz a díky otevřeným standardům i nízké náklady na přechod k jinému poskytovateli. Široká základna vývojářů okolo open source projektů může mít dnes stejnou tržní sílu jako ohromné korporátní společnosti. Napadá mě tedy, proč něco takového nevidíme například ve strojírenství nebo stavebnictví?

Paralela mezi softwarem a výkresem

Srovnáme-li stavební výkres, strojařský výkres nebo zdrojový kód počítačového programu, v zásadě se jedná o předpis, jak něco vytvořit. V případě zdrojového kódu na provoz potřebujeme počítač, ve strojařině frézu a ve stavebnictví cihly. Jedná se tedy vždy o nějaké médium, které potřebuje lidskou obsluhu a nějaký předpis, který je pro úspěšnost celku vždy klíčový.

Z tohoto pohledu mi přijde, že stejně jako na zdrojovém kódu by mohli po světě spolupracovat skupiny mladých strojařů vedle zkušenějších kolegů na projektech všeho druhu a postupně tak navrhovat například model automobilu, výtahu, horské dráhy, mrakodrapu nebo pasivního rodinného domku. Dělali by to ve volném čase, v rámci školních projektů, sbírali by cenné zkušenosti a občas dostali od spokojeného zákazníka nějakou menší odměnu. Proč takový model zatím nikde nefunguje, přesto že mnoho nejen školních projektů takto zůstává zapomenuto a studenti vyjdou ze školy bez dokazatelné praxe?

Otevřenost jako obecný koncept je již propagována několika institucemi, například licence Creative Commons se již dostala do povědomí a začínají dokonce existovat weby cílené na otevřenost dat ve státní správě (Open data). Takže by se mohlo zdát, že vydat výres rodinného domku pod volnou licencí by neměl být takový problém.

Kde je hlavní problém?

Jedna velká překážka tu přeci je. V porovnání se psaním zdrojového kódu potřebujeme k vytvoření a úpravám strojařských a stavebních projektů většinou velmi drahý a specializovaný software. A nejde jen o aplikace, ale i o formáty, které by musely být naprosto transparentní, otevřené a srandardizované. Zde je problém, kterým bychom se s vidinou lepší budoucnosti měli zabývat.

Jsem celkem zvědavý, jestli se společnost někdy dostane do situace, kdy bude existovat copy-left alternativa k současnému uzavřenému modelu z pohledu právě strojařiny nebo stavařiny. S pomocí internetu a v době krize asi nebyla vhodnější příležitost se nad takovým počinem alespoň zamyslet. Komukoliv, kdy má podobný zájem, držím palce

Jak otevřenou vidíte budoucnost vy?

Tags: Open-source | Internet | Počítače | Vývoj



Aktivace "on demand" v systemd

Nov| 2 2011

Výraz bootovací sekvence vychází z dřívější implementace spouštění služeb (doby SysV a prakticky i Upstart), kdy se jednotlivé služby staticky seřadily podle priorit spouštění a init systém je při bootu spouštěl v daném pořadí, pěkně jednu po druhé. Důsledkem toho nebyla výjimkou situace, že zpoždění jedné služby mělo za následek zpoždění celého bootu, nehledě na to, že díky mnoha systémových volání se procesor během bootu často nudil a pouze čekal na nějakou I/O operaci.

Upstart sice dokázal přidat částečnou paralelizaci, nicméně závislosti mezi službami zůstaly lineární. Revoluci v tomto přináší až systemd. Jeho autoři si položili otázku, proč vlastně na sebe služby závisí a zda je skutečně potřeba mít spuštěnu celou službu, předtím, než začneme spouštět službu druhou, která na ni závisí. Zjistili, že v podstatě vše závisí na komunikačních kanálech, konkrétně socketech, dbus sběrnici, apod. Pokud dokážeme mít daný komunikační kanál k dispozici již dříve, není nutné čekat na spuštění celé služby a můžeme vesele spouštět další.

Vezměme si například službu komunikující s NetworkManagerem pomocí dbus. systemd ví, jakým komunikačním kanálem (v případě dbus object path, nicméně můžeme si místo toho představit např. unix socket) tyto dvě služby komunikují a tento kanál dopředu vytvoří. Daná služba se startuje paralelně s NetworkManagerem a může vesele zapisovat do kanálu, aniž by se jakákoliv zpráva ztratila. Až ve chvíli, kdy potřebuje z tohoto kanálu číst, dochází k případnému zastavení, což nicméně odpovídá běžnému čekání na I/O operaci.

Startování služeb pomocí systemd navíc navíc nabízí tzv. start na požádání, kdy služby nejsou spouštěny v případě, že zatím nejsou potřeba. Můžeme danou službu nadefinovat tak, že bude spouštěna až v případě, že s daným kanálem (např. socketem) začne někdo komunikovat. V tomto případě je ovšem nutné si uvědomit, že start a inicializace některých služeb trvá déle a je tedy nutné počítat s určitým zpožděním. Na druhou stranu služby jako cups, kde zpomalení v řádu sekund nehraje roli, je ideálním kandidátem na spouštění pomocí socket aktivace. Démon cups tak neběží ihned po startu systému, ale spouští se až v době, kdy chce uživatel tisknout.

Následuje ukázka jednoduché služby předpovědi počasí. Služba bude naslouchat na portu 8289 a přijímat requesty ve formátu YYYY-MM-DD. Odpovědí bude předpověď počasí na tento den. Pokud chceme takovou službu vytvořit a používat se systémem Upstart nebo obdobným init systémem, musíme do serveru implementovat minimálně:

  • funkci pro zpracování dotazů a vrácení výsledku
  • démonizaci (obdobný proces v mnoha aplikacích = duplicita kódu)
  • inicializaci socketu pro komunikaci
  • navázání tohoto socketu na port 8289
  • vytváření procesů pro jednotlivé requesty pro zajištění paralelního zpracování dotazů
  • vytvoříme init script například zkopírováním základu z jiné služby (duplicita kódu)

Často si chceme být navíc jisti, že pokud náš démon spadne, bude vždy znova spuštěn, takže vytvoříme chůvičku -- jednoduchý program, který obalí našeho démona, hlídající jeho případný kolaps.

Pomocí systemd je situace značně jednodušší. Pokud nám stačí podpora systemd, necháme si socket vytvořit jím a přesměrujeme stdin/stdout na tento socket.

Seznam kroků, které budeme muset implementovat, se tedy změní na:

  • funkci pro zpracování dotazů a vrácení výsledku
  • dotaz přečteme z stdin a odpověď zapíšeme do stdout
  • vytvoříme unit soubory pro službu (12 řádků) a unit soubor pro socket (8 řádků)

systemd se umí postarat o znovu-spuštění démona v případě pádu (pokud si to přejeme), vytvořený socket správně naváže na port a v našem případě (služba se spouští rychle) spustí novou instanci procesu pro každé příchozí spojení na daném socketu. systemd si démonizační proces obstará sám a program je navíc implementován pro běh na popředí, což umožňuje snadnější ladění.

Pokud vynecháme funkci, která zpracovává dotazy a vrací do odpovědi, celý program je velmi jednoduchý:

char req[BUFFSIZE], resp[BUFFSIZE];
/* get requests and leave when request = q|quit */
while (fgets(req, sizeof(req) - 1, stdin) != NULL)
{
  if (strncmp(req, "q", 1) == 0 || strncmp(req, "quit", 4) == 0)
    return;
  process_request(req, resp);
  printf(resp);
  fflush(stdout);
}

Unit soubory jsou při instalaci ukládány v /lib/systemd/systme. Adresář /etc/systemd/system slouží pro unit soubory, které jsou lokálně upraveny, stačí jen zkopírovat unit soubor z /lib do /etc a nový soubor bude po reloadu systemd démona upřednostněn. Konfigurace služby pro démona uvedeného výše může být následující:

[Unit]
Description=Forecast daemon
After=syslog.target network.target
Requires=forecastd.socket

[Service]
ExecStart=/home/hhorak/Dropbox/forecastd
StandardInput=socket
StandardOutput=socket
StandardError=syslog

[Install]
WantedBy=multi-user.target
Also=forecastd.socket

Konfigurace socketu pro výše uvedenou službu potom bude následující:

[Unit]
Description=Forecast Daemon Socket

[Socket]
ListenStream=8289
Accept=yes

[Install]
WantedBy=sockets.target

Po provedení systemctl daemon-reload a spuštění socketu pomocí systemctl start forecastd.socket, můžeme pomocí netstat -a | grep 8289 vidět, že systém naslouchá na portu 8289. Pokud se například programem telnet připojíme k danému portu, systemd spustí program forecastd, se kterým můžeme komunikovat jako s démonem.

Tags: Internet | Programování | Vývoj | Linux | Fedora | Operační systém



Běžná práce se systemd

Oct|26 2011

Stejně jako v předchozích variantách service managerů existuje i v systemd program, pomocí kterého se služby spouští, zastavují, restartují nebo se načítá jejich konfigurace za běhu. Pro tyto a další úkony slouží aplikace systemctl:

Spuštění služby, pokud již běží, nic se neděje:

systemctl start mysqld.service

Zastavení služby, pokud je již zastavena, nic se neděje:

systemctl stop mysqld.service

Restart a podmíněný restart služby; drůhý z uvedených bude proveden pouze pokud služba běží, tedy nespustí zastavenou službu, jako by to udělal první z nich:

systemctl restart mysqld.service
systemctl try-restart mysqld.service

Znovu-načtení konfigurace:

systemctl reload mysqld.service

Spouštět službu na defaultních runlevelech po startu:

systemctl enable mysqld.service

Nespouštět službu automaticky po startu:

systemctl disable mysqld.service

Zjištění, zda je služba automaticky spouštěna po startu:

systemctl is-enabled mysqld.service

Přepnutí do runlevelu 3:

systemctl isolate multi-user.target
systemctl isolate runlevel3.target

Přepnutí do runlevelu 5:

systemctl isolate graphical.target
systemctl isolate runlevel5.target

Výpis všech služeb a jejich stavů:

systemctl list-units

Znovu-načtení konfigurace démona, důležitý krok po úpravě unit souborů:

systemctl daemon-reload

Pro zpětnou kompatibilitu systemd podporuje i dřívější způsob provádění těchto operací - tedy pomocí programů service, chkconfig apod., nicméně preferovaná je novější varianta.

Pokud jste si vyzkoušeli například příkaz systemctl enable, všimli jste si, že systemd hojně pracuje se symbolickými odkazy. Například instalace služby po startu znamená přidání symbolického odkazu na příslušný service file do adresáře cíleného runlevelu, který končí příponou "target". Pokud pochopíte tento celkem jednoduchý princip, nic vám nebrání vytváření vlastních symbolických odkazů manuálně, tedy bez programu systemctl.

Jak ze systemd dostat více informací

Pokud se dostanete tak daleko, že bude te upravovat nějakou službu, například její unit soubor, případně vytvářet službu novou, bude se vám hodit trochu ukecanější systemd. To v GRUBu zařídíme přidáním následujících parametrů do příkazu načtení jádra:

systemd.log_level=debu systemd.log_target=kmsg

v případě GRUB 2 můžeme nastavit proměnnou v souboru /etc/default/grub:

GRUB_CMDLINE_LINUX="systemd.log_target=kmsg systemd.log_level=debug"
Tags: Programování | Počítače | Vývoj | Linux | Fedora | Operační systém



Démonizace po startu a zrychleni bootování

Oct|25 2011

V jednom z předešlých dílů seriálu jsem se zmínil o PID a PPID nově spuštěných procesů. Pokud spouštíme démona, chceme ho vyvázat ze stromu procesů, aby nebyl nijak ovlivněn procesem, který ho spustil. Tomu říkáme démonizace, přičemž je dobré změnit i aktuální pracovní adresář a ignorovat signály týkajicí se práce v terminálu. Ukázkovou démonizaci můžeme vidět na následujícím kódu, který je vypůjčen z implementace lighttpd, jednoduchého http serveru.

signal(SIGTTOU, SIG_IGN);
signal(SIGTTIN, SIG_IGN);
signal(SIGTSTP, SIG_IGN);
if (0 != fork()) exit(0);

if (-1 == setsid()) exit(0);

signal(SIGHUP, SIG_IGN);

if (0 != fork()) exit(0);

if (0 != chdir("/")) exit(0);

Jak vidíme, klasická démonizace navíc obsahuje tzv. double-fork, tedy celkem dvakrát se spouští nový proces se všemi důsledky pro výkon. Rodičovský proces vždy končí s návratovým kódem 0, což je již na první pohled neefektivní z hlediska výkonu (uvědomme si, kolikrát se daná procedura provádí během jednoho bootu), ale také nám dost znesnadňuje kontrolu inicializace démona. V mnoha případech je totiž načítání konfigurace a další inicializační činnost prováděna až v démonizovaném procesu.

Pokud inicializace selže, démon není spuštěn, nicméně rodičovský proces při démonizaci již vrátil nulový návratový kód, tedy hlásil úspěšné spuštění. Tento problém je většinou pomíjen a je pouze na init systému, aby si pomocí pid souboru dohledal, že efektivní proces daného démona již neběží a zaujal příslušná opatření.

Tam, kde by nesprávný návratový kód znamenal větší potíže, je potřeba vytvořit IPC komunikaci mezi novým procesem a původním rodičem, což přináší další nemalé zásahy do kódu démona. Využít můžeme například dbus nebo komunikaci pomocí socketů, nicméně asi cítíme, že to všechno by bylo docela zbytečné, pokud bychom měli lepší způsob, jak se vyvázat z terminálu, resp. od rodičovského procesu.

systemd a démonizace

Nejnovější implementace procesu init spatřilo světlo světa v roce 2010 a jmneuje se systemd. Označení init systém vychází z historického označení systémů sysvinit, proto se pokusím nadále používat obecného označení systémový manažer a manažer služeb (system and service manager).

systemd dokáže používat i starší skripty používané pro Upstart nebo System V. Nicméně pro plné využití je doporučeno vytvořit nativní konfigurační soubory, tzv. Unit files.

Zkusme vzít například lighttpd, jednoduchou implementaci http démona. Ten používá ukázkovou démonizaci pomocí double-fork metody. systemd dokáže takovou implementaci vzít bez změn a díky své vnitřní logice pozná hlavní proces od rodičovského (v tomto případě zůstane běžící pouze jeden, přičemž rodičovské jsou ukončeny). Tento proces potom stráží a případně restartuje službu, pokud hlavní proces neočekávaně skončí. Nativní Unit file pro lighttpd se zachovanou démonizací i s definicí konfiguračního souboru pro démona vypadá následovně:

[Unit]
Description=Lightning Fast Webserver With Light System Requirements
After=syslog.target network.target

[Service]
Type=forking
PIDFile=/var/run/lighttpd.pid
EnvironmentFile=-/etc/sysconfig/lighttpd
ExecStart=/usr/sbin/lighttpd -f /etc/lighttpd/lighttpd.conf

[Install]
WantedBy=multi-user.target

Všimněme si typu služby "forking", která právě definuje, že démon používá démonizaci pomocí double-fork. systemd nicméně dovoluje (a dokonce doporučuje, pokud je to možné) používat spouštění bez démonizace, tedy pouze v jednom procesu. lighttpd démon nám dovoluje spuštění na popředí pomocí přepínače -D, kdy se démonizace neprovede a můžeme tak démona snáze ladit. V případě systemd můžeme tento mód použít a místo "forking" definovat službu jako "simple", což je výchozí hodnota, takže to nemusíme do Unit souboru vůbec uvádět. Výsledný soubor tedy bude vypadat následovně:

[Unit]
Description=Lightning Fast Webserver With Light System Requirements
After=syslog.target network.target

[Service]
PIDFile=/var/run/lighttpd.pid
EnvironmentFile=-/etc/sysconfig/lighttpd
ExecStart=/usr/sbin/lighttpd -D -f /etc/lighttpd/lighttpd.conf

[Install]
WantedBy=multi-user.target

Čeho jsme docílili? Tak zejména systemd nemusí zjišťovat, který proces je výkonný pomocí pid souboru nebo jiného mechanizmu, protože je ve skutečnosti spuštěný všehovšudy pouze jeden proces. Zároveň neprovádíme démonizaci, což znamená ušetření určitého výpočetního času.

Jednoduché je i reportování či případné ukončení služby a správné vrácení návratové hodnoty v případě, že inicializace démona neproběhne v pořádku. A v neposlední řadě si můžeme (pokud by systemd byl používán na všech systémech, které používají našeho démona) ušetřit čas při programování a ladění démona. Při spuštění se o veškerou démonizaci postará systemd.

Tags: Programování | Počítače | Vývoj | Linux | Fedora | Operační systém



Co je to proces init a jaká je jeho historie

Oct|24 2011

První z krátké série článků o systémech init, spouštění procesů a moderním způsobu programování démonů. Nejprve se pojďme podívat, co je to init proces a co se musí stát, než se spustí koncová aplikace - například server databáze mysql.

Všechny spuštěné aplikace, tedy procesy, jsou označeny číslem zhruba od 1 do 32000, kterému říkáme PID (process ID) a jednoznačně daný proces identifikuje. Tato čísla jsou většinou přiřazována postupně a až na jednu výjimku nezáleží, jaké číslo daný proces má. Tou jedinou výjimkou je proces init, proces, který je vždy označen PID 1 a který spouští ostatní. Spuštěné procesy poté mohou spouštět další procesy a vzniká tak strom procesů, které jsou propojeny tzv. PPID (parent process ID). PPID tedy udává, který proces byl tím, který daný proces spustil.

Všichni démoni, tedy ne-interaktivní aplikace, které běží na pozadí, mají většinou PPID 1, tedy nejsou závislé na žádném jiném procesu. Jak lze z obyčejného programu udělat démona (někde můžeme vidět výraz démonizace procesu) si povíme v některém z následujících článků.

Narozdíl od živočišné říše jsou rodičovské procesy umírají (rozumněj končí) zpravidla později než jejich potomci a jsou navíc povinní přebrat od svých potomků závěť - v tomto případě návratový kód, aby se z nich nestaly zoombie. To jen pro úplnost.

Co se děje při startu systému?

Asi nás nepřekvapí, že kromě kromě operačních systémů máme nainstalovaný bootloader, tedy program, který ví o všech systémech na daném počítači. V případě linuxu také ví o všech verzích kernelu a dovoluje nám mezi těmito verzemi vybírat. Je umístěn na části disku zvaném MBR (Master Boot Record) a dnes nejpoužívanější implementace jsou GRUB a LILO.

Pak tu máme samotný kernel, který je základem operačního systému a funguje jako prostředník mezi uživatelskými aplikacemi a operacemi jádra (například práce s pamětí, systémová volání, přepínání kontextu úloh apod.). Bootloader má za úkol především nahrát do paměti kernel a většinou i ramdisk, zvaný initrd, pomocí kterého jsou do paměti již v raném startu k dispozici všechny kritické moduly jádra. Nakonec samotný kernel spustí.

Potom je tu další prostředník, tentokrát mezi uživatelskými aplikacemi a kernelem samotným - init systém. V podstatě se již jedná o běžnou aplikaci, spouštěnou s rootovskými právy. Ta má za úkol kontrolovat své potomky, přebírat jejich návratové hodnoty, posílat jim signály (například HUP pro znovunačtení konfigurace), znovu spouštět aplikace (pokud byly ukončeny nečekaně) a v neposlední řadě řídit, který proces se při startu systému spustí dříve a který později. Zejména k poslední bod nás bude zajímat v dalších částech tohoto seriálu.

No a nakonec tu máme aplikace, z nichž si pro mé demonstrace vyberu démona databáze mysql. Ty mohou spouštět další procesy, ale zárověň mohou vyžadovat, aby již jiné procesy byly spuštěny předtím, než jsou sami spuštěny. Například démon mysqld žádá, aby byl již aktivní syslog (démon starající se o logování různých zpráv na systémové úrovni).

Zároveň často chceme, aby byly při neočekávaném ukončení znovu spuštěny - démon databázového serveru je pro tento požadavek ideální kandidát, přesto, že zrovna v tomto případě nenecháváme tuto kotrolu na init systému, nýbrž se o kontrolu běhu stará pomocný skript mysql_safe, který je součástí démona mysqld.

Historie INIT systémů

System III byl prvním init systémem vypuštěným na veřejnost firmou AT&T v roce 1982 a byl součástí operačního systému UNIX 3.0. Následovan byl o rok později verzí s označením System V, zkráceně často SysV nebo sysvinit. Tento systém při spouštění přečte soubor /etc/inittab, ve kterém je definována cesta k init systému a defaultní runlevel.

Zde mi dovolte malou odbočku, vysvětlujicí pojem runlevel. Runlevel si můžeme představit jako množinu služeb (aplikací) které mají být spuštěny. Jednotlivé runlevely jsou zpravidla označeny číslem 1 až 6, přičemž 6 paradoxně znamená reboot. Runlevel 1 potom zařídí spuštění jen nejzákladnějších služeb pro použití systému v jednouživatelském režimu. Uživatel je přihlášen jako root a tento mód se používá zpravidla v nouzových režimech, například v případě, že zapomenete root heslo.

Ostatní označení runlevelů se liší v různých distribucích, ale pokud se budu držet Fedory a jí podobným, runlevel 3 spustí víceuživatelské prostředí v textovém terminálu a runlevel 5 potom víceuživatelské prostředí v grafickém prostředí (KDE, Gnome apod.). Něco jako jednouživatelské prostředí v grafickém režimu nedává smysl a proto jsou runlevely 2 a 4 nepoužívány. Jako praktická ukázka nám může posloužit výše zmíněná aplikace mysqld (démo databázového serveru mysql). Tohoto démona tedy dává smysl spouštět na runlevelech 3 a 5.

Po malé odbočce zpět k init systému sysvinit. Aby systém věděl, která binárka se má spouštět a jak s ní komunikovat, bylo navrženo jednoduché rozhraní. Pro každou službu je vytvořen skript, který rozumí parametrům start, stop, restart, reload apod. Skript samotný potom volá samotnou aplikaci s potřebnými parametry, zasílá jí signály nebo někdy i načítá konfiguraci.

Skripty všech služeb jsou uloženy v /etc/rc.d a symbolické odkazy jsou potom umístěny v /etc/rc1.d až /etc/rc6.d, kde čísla značí jednotlivé runlevely. V těchto adresářích najdeme soubory pojmenované například S23NetworkManager, S08iptables nebo S24cups. 'S' znamená start, dvojmístné číslo potom slouží ke správnému pořadí spouštěných služeb. Služba s nižším číslem je vždy spuštěna dříve, než služba s vyšším číslem.

V praxi to tedy vypadá takto:

/etc/rc3.d/S23NetworkManager -> /etc/init.d/NetworkManager

a spuštění démona provedeme buďto:

# /etc/init.d/NetworkManager start

nebo pomocí speciální utility:

# service NetworkManager start

V devadesátých létech se tedy nacházíme ve stavu, kdy existují stovky služeb se svými SysV skripty, které buďto spravuje vývojář dané služby nebo vývojáři dané distribuce. Samozřejmě se objevují návrhy, že by bylo dobré implementovat spouštění služeb jiným, pokročilejším způsobem, umožňujícím například paralelní start služby, opožděné spuštění až v době, kdy je služba opravdu potřeba a nebo jen jednodušší zápis než stále dokola opakovat téměř totožné bashové skripty.

Problém ovšem byl, že v tu dobu již existují stovky služeb, které mají nějakým způsobem definovány své skripty. Potom není jednoduché všechny skripty jen tak přepsat pro systém nový. A naopak není možné nasadit nový systém, pokud pro něj nebudou napsány nové konfigurační soubory, nahrazující SysV skripty. Klasický problém vejce a slepice tedy brzdil vývoj v oblasti init systémů dlouhá léta.

V roce 2006 přišla implementace Upstart, založená na asynchronním spouštění služeb pomocí událostí a která mohla být nasazena zejména díky možnosti používat SysV skritpy. Pokud jste se setkali s výrazem LSB init skripty, vězte, že se jedná pouze o mírně upravené SysV init skritpy podle standardu LSB. LSB tedy standardizovalo to, co System V implementoval. Pomocí relativně malých úprav umožnil Upstart asynchronní spouštění více služeb najednou, aniž by se muselo vždy čekat na dokončení startu předcházející služby. Od pouhého spouštění aplikací se Upstart rozrostl o komunikaci pomocí dbus a správu spouštění úloh v daných intervalech, což dříve prováděl démon cron.

Jen čtyři roky na to spatřila světlo světa implementace od německého vývojáře Lennarta Poetteringa a dalších, která se jmenuje systemd. Ta umožňuje plně paralelní start služeb při startu, přidává aktivaci služeb pomocí socketů nebo dbus a přidává monoho pokročilých optimalizací. Stejně jako Upstart umožňuje využívat sysv init skripty, což byla podmínka, díky které bylo vůbec možné přemýšlet o nasazení v reálné distribuci. Místo skriptů ale již doporučuje služby definovat pomocí nativních konfiguračních souborů, které jsou značně jednodušší, nicméně přináší některé problémy. O systemd si blíže povíme v dalším článku z této mini série.

Tags: Programování | Vývoj | Linux | Fedora | Operační systém