Posts with tag Internet

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



Jak uspět v open-source světě?

Oct|20 2011

Zajímavé slidy ze své nedávné prezentace zveřejnil na svém blogu [1] hacker (v dobrém slova smyslu) Lennart Poettering. Autor PulseAudia, Avahi nebo systemd sumarizuje základní rady, jakými by se měl řídit jak začínající, tak dlouholetý člen open-source komunity.

Chvilku jsem přemýšlel, jestli duplicitní slide "Don't lose yourself in details" byl záměr nebo chyba, přičemž první mi přijde pravděpodobnější. "Neztrácet čas a mysl v detailech" je totiž základem úspěchu nejen v open-source komunitě.

Přikládám pár postřehů, které se mi zdály nejzajímavější:

  • začínat malými patchi a učit se od zkušenějších, než začnete svůj vlastní projekt
  • dělat více než mluvit
  • být vděčný ale nečekat vděčnost od ostatních
  • být připraven na to, že život v meritokratické komunitě není lehký

[1] http://0pointer.de/blog/projects/hinter-den-kulissen.html

Tags: Osobní | Internet | Programování | Vývoj | Linux



Spring pad - GTD v akci

Sep|19 2011

strucna ukazka, jak lze aplikovat na gtd metodu

Tags: Osobní | Internet | Vývoj



Výkonnostní srovnání Fedora 15 s Gnome 3 a Ubuntu 11.04 s Unity

Jun| 6 2011

http://www.phoronix.com/scan.php?page=article&item=fedora15_v_ubuntu1104&num=1

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



Hrozivá statistika zabezpečení počítačů

Apr|24 2011

Dostal jsem se k tomu čistě náhodou - nejedná se o velmi reprezentativní statistiku, ale pouze o anketu na serveru computerworld.cz. O co jde? Otázka zněla: "Jak máte zabezpečen přístup k počítači?", přičemž na ní do této chvíle odpovědělo 230 čtenářů, podle zaměření portálu předpokádám především technicky založených.

A jaké byly výsledky? Použití čipových karet pro zabezpečení přístupu bylo uvedeno pouze v 1%, což nebylo překvapením. Možná o trochu zajímavější bylo použití biometrických dat v rozsahu 8%, ale vzhledem k rozšíření čtečky otisku prstů ani tohle není příliš nečekané. Co mě ale překvapilo nejvíc, bylo "žádné zabezpečení" u celých 40% a to znovu opakuji - u skupiny uživatelů, kteří jsou vesměs více než počítačově gramotní a často se dokonce jedná o lidi pracující v IT.

Pokud by většina z takových počítačů nebyla připojena k internetu, nebyl by to takový průšvih, nicméně kdo dnes nemá na počítači přístup k internetu?

Můžeme se bavit o kvalitě hesel a jejich nejlepší uložení, ale přitom útočníkům necháváme otevřená vrátka dokořán.. Přijde to jen mě nebo skutečně tolik lidí na zabezpečení naprosto kašle?

Jen pro pořádek - zbytek, tedy zhruba polovina uživatelů uvedla jako způsob svého zabezpečení heslo.

Tags: Internet | Počítače | Bezpečnost | Operační systém



Sémantický web v podání Googlu

Feb|19 2011

Budoucnost internetu se v blízké době bude s velkou pravděpodobností točit kolem sémantického webu. Pojďme se podívat na technologie nabízené Googlem, který bude bezesporu i v dalších letech jedním z leadrů nejen v této oblasti.

Základním problémem sémantického webu je problém značkování. Klasické HTML i XHTML, z nichž druhý jmenovaný se pro automatické zpracování hodí lépe kvůli striktnímu XML formátu, se sémantickým popisem dat nepočítaly. Na druhou stranu nelze z ničeho nic začít používat jiné formáty pro prezentaci dat (např. RDF).

Jedním konkrétním případem, kde se sémantický web začíná uplatňovat v praxi už dnes, jsou stránky on-line obchodů, tedy nabídka zboží. Pokud dnes přijde robot na stránku s popisem zboží, jen velmi obtížně najde relevantní informace, které by mohly být spolehlivé natolik, aby je mohl smysluplně využít. V praxi se proto od portálů žádá speciální rozhraní (většinou ve vormátu XML), kde je možno zjistit přesné informace o produktu.

Nevýhodou speciálních XML feedů je, že každý obchod si tvar XML dokumentu určuje sám, tzn. portláy musí mít tento výpis produktů v mnoha verzích, což je s přibývajícími agregátory stále pracnější. Ideální by bylo, kdyby každý parser uměl vytáhnout všechna data přímo ze stránky, která slouží primárně uživatelům. A k tomu nám idálně poslouží právě sémantický web.

Google pro službu Product Search vyvinul definice jednotlivých metadat, jako je název produktu, kategorie nebo popis. Metadata jsou rozdělena na informace o produktu, o nabídce (cena, prodejce, stav zboží) a o souhrnné nabídce (pokud produkt obsahuje několik variant). Co s těmito údaji Google udělá, je jasné. Co není jasné, jak jednotlivé části webu (tedy HMTL elementy) správně označit dannými metadaty.

Konkrétně Google nabízí hned několik možností. První možností je využít microdata, které jsou součástí HTML 5 a elementům přidají nové atributy itemscope, itemtype a itemprop.

Další možností jsou microformáty, které pro klasifikaci dat používají standardního atributu class, primárně sloužícího pro formátování pomocí CSS. Poslední možností je použití RDFa, tedy rozšíření HTML pomocí jmenných prostorů.  Všechny jsou k vidění na následující ukázce:

<!-- microdata -->
<div itemscope itemtype="http://data-vocabulary.org/Person">
Jmenuji se
<span itemprop="name">Bob Smith</span>
a moje stránky jsou na
<a href="http://www.example.com" itemprop="url">www.example.com</a>.
</div>

<!-- microformat -->
<div class="vcard">
Jmenuji se
<strong class="fn">Bob Smith</strong>
a moje stránky jsou na
<a href="http://www.example.com" class="url">www.example.com</a>.
</div>

<!-- RDFa -->
<div xmlns:v="http://rdf.data-vocabulary.org/#" typeof="v:Person">
Jmenuji se
<span property="v:name">Bob Smith</span>
a moje stránky jsou na
<a href="http://www.example.com" rel="v:url">www.example.com</a>.
</div>

Nyní tedy máme techniky, jak dát robotům možnost získat správná data bez nutnosti definovat XML feed. V českých končinách sice zatím služba nasazena není, ale není špatné vidět do budoucnosti. Z Německa, kde již sémantickým značkám Google rozumí, totiž není daleko.

Tags: Internet | Programování | Google | Facebook | Vývoj