Do what you have to do
Linux
Tabulka oblastí GPT, jak mít moderně rozdělený disk
16. Zář
K narozeninám jsem dostal krásný 2TB pevný disk a když jsem na něj přesunoval svoji volume group, rozhodl jsem se pro dva zdánlivě banální kroky, které povedou k modernizaci úložného subsystému na mém desktopu.
Prvním krokem byla změna souborového systému u 800 GB velkého oddílu, což si vyžádalo vytvoření oddílu nového a celonoční běh utilitky cp. Druhý krok už nebyl tak snadný a mohla za to kromě smůly také má zbrklost. No chtěl jsem místo tabulky oddílů v MBR [použít GPT](http://cs.wikipedia.org/wiki/GUID_Partition_Table).
Věděl jsem, že Linux GPT podporuje a tam s ním nebudou problémy. Také jsem zjistil, že můj GRUB2 se s GPT také kamarádí, ale byl tu obrovský otazník kolem BIOSu. Použil jsem tedy kapku inteligence a řekl si, že BIOS nedělá nic jiného, než že spustí kód v prvním sektoru na disku a je mu vcelku jedno co tam je, prostě to běží. To byla správná úvaha, ale moje víra se začala hroutit poté, co jsem bez jednoho ze starých disků nenabootoval. Pokud tedy máte stejnou konfiguraci disků jako jsem měl já, tedy:
- 500 GB – 2 partišny, první boot, druhá LVM
- 320 GB – 2 partišny, první prázdná, druhá LVM
- 320 GB – 2 partišny, první prázdná, druhá LVM
Měli byste se řídit dvěma pravidly.
- Když to nenabootuje, tím že vyndáte staré disky se to nespaví
- Když je poškozený FS na boot partišně, měli byste více zkoumat proč a ne jen mávnout rukou
Ukázalo se totiž, že GPT je malinko komplikovanější, než MBR, ale abych nepředbíhal. GPT může koexistovat spolu s MBR, protože začíná na první sektoru a končí na 34. Dále je pak ještě druhá kopie na konci a to posledních 34 sektorů. Proti MBR to je fakt pořádná oblast k mapování zbytku disku, takže s GPT padají omezení, které MBR mělo, jako třeba maximálně 2 TB velké oddíly (u 2,5 TB disků už v mém případě problém) a nebo pouze 4 primární oddíly.
A tady je kámen úrazu. GPT funguje jinak, není to jen hloupá mapa disku a pokud z něj chcete bootovat, potřebujete malý oddíl, klidně menší než 1 MB a dát mu flag bios_grub. Do něj se přesune GRUB při své instalaci a pak můžete z disku nabootovat. Co se v té oblasti nachází nechám na vás, protože dnes už nemám sílu něco zjišťovat. Na této partišně nesmí být nic jiného, jako třeba /boot v mém případě, o který jsem také přišel.
MBR vedle GPT zůstává a obsahuje jednu velkou oblast s flagem GPT. Je možné částečně synchronizovat MBR oblast s GPT pomocí utilitky gptsync, ale neměl jsem tu odvahu. Je to užitečné hlavně z toho důvodu, že pak můžete pracovat s diskem i v systémech, které to nepodporují nebo použít třeba stařičké LILO nebo postarší GRUB1.
Pokud vás zajímá, jestli je možné z MBR přejít na GPT, tak ano, ale pouze za podmínky, že máte dost volného prostoru na konci a na začátku disku. Obráceně to jde také, ale zase jste omezeni čtyřmi primárními oddíly. O přesunu z jedné tabulky do druhé a vůbec o GPT napsal hodně (ale opravdu hodně) [Rod Smith na svém webu]( http://www.rodsbooks.com/gdisk/). Pokud trochu ovládáte angličtinu, neměli byste mít s jeho texty problémy. V nich se dozvíte všechno co jste chtěli či nechtěli o MBR a GPT vědět a poznáte nástroj gpart, který vám pomůže převést teorii do praxe.
GPT je podporované v Linuxu už dlouho a nové distribuce s ním nebudou mít problém. O Windows to platí také, konkrétně od Vist. Není důvod se ho bát, ale není dobré si s ním hrát nad existujícími daty
Mě se nakonec přesun 900 GB na nový disk povedl a jsem rád, že to mám za sebou. Mé velké dík mají vývojáři LVM, protože mi výměnu disku hodně ulehčilo.
Python hosting Roští.cz: optimalizace a opravy bugů
4. Kvě
Za poslední dva měsíce se příchod nových uživatelů na Roští.cz prakticky nezměnil a zůstal u „občas se někdo objeví“, ale na pozadí se toho stalo hodně. Už jsem jen krůček od toho, abych uvolnil administraci na Roští.cz pod nějakou svobodnou licencí a tím doufám oslovím další vývojáře, hlavně ze zahraničí. Poslední překážkou je uzavřená šablona, na které je administrace postavená. S každou instancí administrace je potřeba licenci zaplatit (20 USD) a samozřejmě je nekompatibilní s open source licencemi. Kdybyste někdo měl pod stolem nějakou hezkou šablonu, o kterou byste se chtěli podělit, určitě dejte vědět, moc by to pomohlo. Já nejsem zrovna dobrý kodér ani grafik.
Konec čekání
Kód administrace byl ještě včera večer dost chaoticky uspořádán, pokud šlo o provádění nějakých akcí v operačním systému serveru. Různé snahy udělat z administrace nástroj pro správu mnoha serverů způsobily, že v každé části se spouštěly příkazy pod rootem jinak. Když má jedna aplikace spravovat více serverů, potřebuje na každém z nich občas spustit nějaký program (přidání uživatele, vytvoření adresářové struktury pro emailovou schránku apod.), proto je potřeba nějak zařídit, aby admin mohl, pokud možno jednoduše, spustit nějaký program na libovolném spravovaném serveru.
Spouštění čehokoli pod rootem je bezpečnostní riziko a to je mě nenechalo v klidu prakticky u ničeho co jsem navrhl a ani teď z toho nejsem odvázaný. Chvilku jsem bezpečnost řešil přes sudo, kde bylo povoleno pár programů, které mohly být daným účtem (pod kterým běžel admin) spuštěny, ale nakonec má administrace k ruce roota každého spravovaného serveru bez omezení. Touto oblastí si ještě nejsem zcela jist, takže se na ní zaměřím v dalších týdnech. Pravdou je, že na serveru se musí občas něco spustit a každá bezpečnostní vychytávka bude komplikovat další vývoj.
V některých místech se používalo SSH, ale ukázalo se to být zbytečně komplikované. Někde se navíc na serveru spouštěly různé programy pouze přes subprocess, takže ovládání více serverů nemělo šanci. Nakonec jsem se rozhodl na každý spravovaný server umístit malý pythoní skript, který spustí HTTP server a administrace pomocí POST požadavků posílá co chce spustit. HTTP server vrací JSON s tím, jak to dopadlo. Python má velmi pěknou implementaci HTTP serveru a urllib se postaralo o klientskou část. Zatím se pro komunikaci nepoužívá zabezpečený protokol, ale to se snad brzy změní. Nejraději bych si šifrování řešil sám přes nějaký klíč a nenechával to na HTTPS.
Wiki
Během dubna byla spuštěna wiki, kterou najdete na wiki.rosti.cz. Jsou tam informace ke všem funkcím, které jsou v administraci a mohly by dělat problémy. Navíc tam je vysvětlení, jak je hostován Python, jak PHP apod. Určitě stojí za to si ji prostudovat. Wiki je založená na projektu Dokuwiki. Kromě technického popisu tam dávám delší zprávy, které se na Twitter nevešly.
Díky wiki zmizelo z administrace těch pár textů, které tam byly a nahradily je odkazy právě na wiki. Snad se mi podaří spojit wiki a administrace ještě trochu těsněji. Tímto krokem si nejsem úplně jistý, nemám ho promyšlený, ale myšlenka, že z administrace dostanu delší texty, které pak nebudu muset překládat do angličtiny byla lákavá.
Nové disky a Debian
Koncem března a začátkem dubna jste mohli zaznamenat tři výpadky, z nichž dva byly dost dlouhé, asi dvouhodinové. Roští je momentálně postaveno na jednom serveru, který obstarává téměř všechny služby a pak na druhém, který drží zálohy. Na prvním serveru byl od jeho koupi pouze jeden disk (nebyla šance to ovlivnit) a ten se začal někdy v březnu cukat, resp. se na něm objevilo 32 vadných sektorů. Situaci bylo potřeba řešit a navíc se do všeho tlačila nutná aktualizace Ubuntu 9.10, kterému končila na konci dubna podpora.
Rozhodl jsem se s výměnou disku provést i aktualizaci, resp. přejít na Debian. Krom toho, že Ubuntu je prakticky nemožné nainstalovat nad LVM+RAID, tak Canonical bere rok a půl dlouhou podporu jenom jako řádek textu ve svých prospektech. Na serveru bylo několik bezpečnostních chyb, které byly v upstreamu opraveny, ale do Ubuntu 9.10 se oprava nikdy nedostala. Debian 6.0 byl ještě čerstvý a teploučký, až se z něj kouřilo, navíc verze balíčků jsou velmi podobné těm, které jsou v Ubuntu 9.10, takže přechod nebyl vůbec žádný problém a za dvě hodiny byl stroj připraven.
Druhý výpadek byl způsoben doplněním druhého disku do RAIDu a měl asi 30 minut. Mezi těmito výpadky se objevil ještě jeden, který byl způsoben zvýšenou aktivitou jednoho webu a jeho komunikace s MySQL databází. Na nějaký útok to nevypadalo, ale i tak to odnesl Apache. Stalo se to v sobotu ráno a Apache nejel asi dvě hodiny.
I kvůli tomuto problému jsem na server nahodil monitoring Icinga. Krom toho, že jsou hlídány služby, tak vím i o výpadcích jednotlivých webů. Vzhledem k menším problémům, které se objevily u uWSGI, se Icinga ukázala jako užitečný nástroj.
Během změny operačního systému došlo i k nahrazení daemona Jabberd2 daemonem Prosody. Důvodů bylo několik, ale těmi hlavními je jednodušší správa a rychlejší vývoj. Pro klienty to znamená, že se někdy v adminu dočkají funkce Jabber serveru ke své doméně. To je možné už teď, ale pouze po odeslání požadavků na technickou podporu.
Po přechodu na Debian byla administrace vylepšena o podporu uWSGI a také podporu odděleného statického obsahu od aplikace. To serveru trochu odlehčilo. i když to ještě zdaleka ne všichni používají. uWSGI přineslo lepší podporu pro virtualenv, což je pythoní virtuální prostředí. Všechno je popsané na wiki, ale ve zkratce si mohou klienti přes SSH vytvořit prostředí přesně s těmi moduly, které chtějí. Navíc se kvůli reloadu aplikace nemusí reloadovat celý Apache. U mod_wsgi se reload prováděl pomocí změny mtime u souboru s WSGI handlerem. To občas nefungovalo jak mělo, hlavně když jste se na serveru pokoušeli vyvíjet a něco se pokazilo.
Fraggo.net
První společnost, která použila administraci z Roští.cz na své servery, je Fraggo.net. Zatím administrace spravuje jeden server, ale další dva se k němu brzy připojí. Hlavní důvodem této volby, byla podpora jazyka Python. Doufám, že až bude administrace uvolněna pod svobodnou licencí, tak si ji oblíbí a hlavně ji vylepší další firmy i jednotlivci. K tomu, ale ještě povede dlouhá cesta.
Pokud máte zájem o zdrojové kódy, určitě se ozvěte.
Co se plánuje
Roští.cz ještě mladý hosting a ještě není úplně bez chyby, ale zatím má tento rok lepší dostupnost než centrum.cz
Každopádně bych teď rád udělal druhou vlnu propagace Roští a během následujících dvou, třech měsíců pořídil další server, který by si vzal na sebe weby a databáze a monitoring s e-maily by zůstal tam kde je. Jinak další zásahy do serveru nejsou plánovány a nemělo by tak docházet k žádným výpadkům.
V kratším časovém úseku se pak dočkáte podpory IPv6, která je teď číslo jedna, administrace trochu zAJAXovatí a nějaké vylepšení čeká hostování DNS záznamů.
Pokud ještě nemáte svůj Pythoní hosting, tak na Roští.cz ho dostanete.
Novinky na Roští.cz za únor a plány na březen
3. Bře
Za únor jsem si vytyčil asi tři dny, kdy jsem se naplno věnoval vývoji pro Roští.cz a podařilo se mi vyřešit několik nepříjemností, se kterými se uživatelé v administraci setkávali. Také něco přes týden běžela na Roští.cz akce python hostingu zdarma.
Python hosting zdarma
Cílem akce bylo se zviditelnit a určitý úspěch tu byl. Celkově se registrovali tři noví uživatelé, z nichž dva si nahodili nějaký web. O akci se mi podařilo procpat zprávičku na server zdrojak.root.cz, což mělo menší úspěch, než jsem původně čekal, ale Roští.cz zaujala asi stovka lidí, což se neúspěchem nazvat nedá.
Fakturace
Fakturační systém už je nějaký čas integrovaný do administrace, ale uživatelé k němu ještě nemají přístup, což se změní během března. Chci ovšem mluvit o tom, že všechno potřebné pro automatické vydávání faktur je už naprogramované a otestované, takže ti co se zajímali o tom, kdy budou moci konečně zaplatit, se dočkají. Mě to vyřeší spoustu starostí, tak se sám těším, až to bude hotové.
Databáze
To čeho si uživatelé stoprocentně všimnou, je nová správa databází. Ta je teď udělaná mnohem lépe a bezpečněji a hlavně funguje spolehlivě. Navíc si teď mohou uživatelé určit heslo ke každé jednotlivé databázi. Starší databáze jsou dostupné, ale už ne z administrace. Moc jich nebylo, tak jsem se s importem neobtěžoval a parametry je možné měnit buď přes SSH nebo v PHPMyAdminu. Ve starém systému pro správu databází byli uživatelé nuceni to dělat stejně. Díky bohu za to, že to už je pryč.
Request systém – podpora více serverů
To nejdůležitější za celý únor jsem napsal hned na začátku. Jde o request systém postavený na MongoDB. Akce, které vyžadují zásah na serveru, vygenerují request, který si pak daný server stáhne a provede. Funguje to pěkně, odděluje to administraci od práv roota a až se mi podaří vyřešit načítání obsahu uživatelského adresáře, nebude nic bránit tomu, aby administrace mohla spravovat neomezené množství serverů. Vzhledem k tomu, že se hostované weby probouzejí k životu, bude to za chvíli potřeba.
Jako bonus dostali uživatelé reload tlačítko ke svým webům. Když něco změní ve zdrojovém kódu, mohou restart aplikace teď nově řešit tímto způsobem.
Během tohoto roku bych rád nabídl také možnost spravovat v administraci samostatný server pro daného uživatele. Je to funkce, kterou jsem plánoval už od začátku a už se nemůžu dočkat, až bude implementovaná.
Testy
Důležitou informací pro uživatele jsou testy, které se teď nacházejí v některých částech administrace. Sice se s nimi uživatelé nesetkají, ale určitě poznají že tu nějaké jsou.
Nyní se stává, že když přidám do administrace nějaké funkce a ty fungují v pořádku, ukáže se, že to ovlivnilo jiné části, které nefungují. Když se k tomu dostane uživatel, vrátí mu administrace chybu 500 a na e-mail mi přijde trackback. Chybu se mi zatím vždy podařilo vyřešit během pár desítek minut, ale to je spíše o štěstí, že jsem měl možnost se jí věnovat. Každopádně než uživatel vůbec napsal na podporu, dostal vysvětlující e-mail s omluvou.
Tomuhle chci rozhodně zabránit a jelikož nemám sílu testovat po každé změně všechno, rozhodl jsem se přidat pár testů a tím riziko minimalizovat. Django to má dobře vyřešené a rozhodně v této oblasti podává pomocnou ruku. Doufám, že s dalšími chybami 500 se už uživatelé nesetkají.
Django 1.3
Začátkem března přejde administrace na Django 1.3. Sice ještě není stabilní, ale chyby už nejsou kritického charakteru, takže není proč zůstávat u verze 1.2, když 1.3 nabízí tolik skvělých novinek. Django 1.3 bude samozřejmě na serveru nainstalované, ale ještě než se tak stane, dostane se do administrace volba verze. Nechci, aby vám weby přestaly fungovat když se rozhodnu zrovna něco aktualizovat. Výchozí Django bude minimálně dva měsíce ještě 1.2.
V souvislosti s tímto uvažuji, že doplním do administrace podporu pro virtualenv. Mnoho uživatelů by to určitě ocenilo.
uWSGI a spawn-fcgi
Začal jsem testovat uWSGI na homepage rosti.cz a výsledky jsou úžasné. Web jen o dost svižnější než s mod_wsgi z Apache. uWSGI mají uživatelé k dispozici po podání požadavku na technickou podporu, ale snad se mi podaří ji v březnu doplnit i do administrace. Časem pak budou všechny weby migrovány na uWSGI, ale toho se zatím bát nemusíte.
Spawn-fcgi je podobné jako uWSGI, ale pro PHP. Vzhledem k povaze PHP by nahození spawn-fcgi přineslo nižší náklady na provoz PHP aplikací. Nyní se platí za každou nahozenou PHP aplikaci, protože pro každou běží vlastní interpretr PHP. Se spawn-fcgi by běžel jenom jednou pro všechny PHP aplikace uživatele a tím by se mohla cena ustálit na 60 kč, ať už je aplikací kolik chce.
uWSGI a spawn-fcgi budou chtít nějakého hezkého jednoduchého proces manažera a to momentálně brání jejich nasazení. Takže snad v březnu, momentálně tu jsou důležitější věci na předělání.
IPv6
IPv6 adresu má server už svého nahození a některé služby na ní naslouchají (pošta, SSH, FTP, …), ale Apache ne. V březnu tedy plánuji nasadit do administrace checkbox, kde si bude moci uživatel vybrat, jestli má web běžet na ipv6.example.com nebo rovnou na example.com a nebo úplně bez IPv6. Musí se to zkombinovat ještě s DNS, ale nikoho rozhodně nebudu nutit k tomu či onomu řešení.
Závěr
Abych to shrnul, v únoru se mi podařilo odstranit největší bolesti administrace a v březnu budu pokračovat těmi menšími. Určitě se máte na co těšit.
Zpracování změn konfigurace na novém Roští.cz
22. Led
Velmi důležitou funkcí nové administrace pro Roští.cz bude managování mnoha serverů najednou a to mě postavilo před tři možné cesty vývoje. Určitě chci, abyste si uživatel mohl vybrat server podle jeho schopností. Bude si moct klidně pronajmout kousek výkonu serveru na sdíleném hostingu, kde se spolu s jeho webem bude krčit dvacítka dalších a na projekt, který bude potřebovat 100% dostupnost, stabilitu i maximální výkon, si pořídí vlastní virtuální nebo fyzický server.
S touto myšlenkou jsem si hrál už u současné administrace, ale narazil jsem na sdílení informací mezi servery, konkrétně reloadování jednotlivých služeb. Není problém nastavit Postfix, aby bral údaje z databáze, ale pro Apache je potřeba vygenerovat konfigurační soubory a pak ho reloadovat. Už samotné reloadování není nic, co bychom chtěli dělat každých deset minut, ale větším problém se ukázala být komunikace mezi serverem a administraci. U lokálního stroje se správně nastavilo sudo, případně se použil cron a nějaké signální soubory. U vzdáleného stroje se muselo použít SSH a autentizace s klíči.
Udržovat na serverech klíče k dalším serverům není zrovna bezpečné a navíc se mi ani nezdá myšlenka, že by se mělo z jednoho bodu sahat do všech serverů. To je také důvod, proč současná administrace nenabízí managování více serverů, i když ho na pozadí podporuje.
Na novou administraci jsem se rozhodl použít MongoDB, která je proti Postgresu menší, nepodporuje zbytečné fičury a hlavně jde jednoduše replikovat mezi více serverů. Proti Redisu má nějaké užitečné funkce navíc a drží si data bez problémů na disku. Také jeho výkon je někde jinde. MongoDB nevadí, když mu pošlu stovku dotazů, ochotně vrátí výsledek během okamžiku. Ve skriptu se navíc data načítají mnohem pohodlněji než z SQL centrické databáze.
Proto jsem se přiklonil k řešení, kdy se změny mezi fyzickou konfigurací serveru a hodnotami v databázi nesynchronizují a ani se nevykonávají hned po zadání, ale uživatel uloží do databáze požadavek a daemon na daném serveru ho vykoná a vloží do databáze výsledek. Takže když uživatel chce vytvořit nový web, uloží se do databáze parametry tohoto webu (kde, kdy, čí, co, kolik, …) a zároveň se vytvoří požadavky směrované k jednomu konkrétnímu serveru:
- Vytvoř uživatele XX
- Zkopíruj do jeho domovského adresáře výchozí strukturu
- Vytvoř databázi XX
- Vytvoř konfigurační soubor pro Apache/Nginx/…
Daemon na daném serveru bude pravidelně kontrolovat co čeká ve frontě a když narazí na požadavky pro sebe, začne je plnit a doplní je o výsledeky.
- Uživatel vytvořen
- Struktura zkopírována
- Databáze vytvořena
- Konfigurační soubor vytvořen
V databázi budou vždy informace potřebné k tomu, aby se daná struktura dala vytvořit (pro případ velmi kritického selhání), ale daemon nebude muset číst celou konfiguraci z databáze, zjišťovat co se změnilo a pak podle toho reagovat. Je pravda, že by někdy mohlo dojít k určitým nekonzistencím, ale to jedině při zásahu admina.
Odlehčené Roští.cz
20. Led
Možná jste si všimli, že se snažím prorazit s pythoním hostingem. V minulosti mě poháněla hlavně ideologie, kdy jsem chtěl, aby na našem trhu byl cenově dostupný pythoní hosting. Teď už na to mám ale jiný pohled a krom Pythonu začnu víc propagovat i PHP. Přitom bych rád přinesl něco nového a jelikož vás sem chodí už docela dost, připravil jsem si anketu.
Extrémní konkurencí pro Pythoní hostingy jsou cloudové služby jako VirtualMaster nebo RackSpace. Jsou to služby, které vám velmi levně dají do ruky virtuální server s měnitelnými parametry. Pokud máte trochu znalosti Linuxu/*BSD, dáte si server dokupy za hodinu a dělá přesně to co chcete, navíc za 200 kč tam odhostujete 4 Django weby, které mají dají dohromady tisíce stránek za den. Proto hostingy v dnešní době ztrácejí smysl, zvlášť ty nové.
Pořád tu ale zůstává skupina vývojářů, kteří nechtějí řešit nějaký linuxový server a jediné co chtějí je co nejrychleji hodit web online. Bohužel ti asi nebudou masivně používat Python a zůstanou věrni PHP. Asi budu muset spolknout svůj odpor a prostě to PHP začít procpávat víc.
Takže začnu tím, že Roští.cz jak je zůstane, jen bude současný stav schovaný víc na pozadí. O svoje weby, o administraci nepřijdete. Pro nové zákazníky ale chystám něco nového, co bych sám používal. Chci pořízení hostingu udělat co nejjednodušší, to samé platby a jeho administraci. Minimalizovat počet možností a nabízet web a e-mail jako dvě rozdílné služby. Zůstanu také věrný myšlence co web to jedna aplikace a tedy jedna platba. Web + fórum + bugzilla na samotných poddoménách bude bráno jako tři weby. U Pythonu to je logický krok, u PHP už méně, ale i tak bych to s tímto modelem rád zkusil. Navíc bude základní hosting PHP i Pythonu zdarma. Jedinou podmínkou bude malá ikonka.
Určitě většina z vás nějaký ten hosting využívá nebo si managujete vlastní server, zkuste mi odpovědět v následující anketě, jak na tom jste:
Registrace domén je dost nevděčná činnost a vyžaduje mnoho práce, proto bych se tomu milerád vyhnul, na to tu jsou jiné firmy. Takže musím vymyslet něco jiného, čím oslovit náhodné kolemjdoucí. Kartu bych rád vsadil na zdvojení všeho co by mohlo selhat. Replikovaná databáze, online záloha statických dat a proxy server, který by rozhazoval provoz mezi dva servery, případně jeden bral jako primární a druhý jako zálohu. Tak jako tak, problém by měl pocítit uživatel jen na několik sekund, než si loader všimne, že je něco špatně.
Další výhodou by mělo být outsourcování serverů. Amazon, RackSpace, VirtualMaster jsou firmy, které mají servery zmáknuté, tak proč toho nevyužít. Momentálně běží Roští.cz na dvou fyzických serverech, které by zůstaly, ale další rozšíření by šlo mimo ně. Výhod je hned několik, bylo by možné nahodit nový virtuální server během minut tím nahradit případný nefunkční a zamezit tak výpadkům webů. Navíc by si mohl zákazník zaplatit vlastní server, ale spravovat ho známou administrací. Mám připravené skripty, které si vše sami nainstalují a postarají se i o přesun webu z jednoho serveru na druhý nebo ze zálohy na druhý a ty se už nemohou dočkat, až poběží na ostro.
A nakonec bych rád nabídl služby v angličtině a expandoval za hranice naší kotliny. Tam asi najdu víc zájemců o Python než u nás a pokud budou servery rozházené po světě, neměl by v tom být problém. Placení budu realizovat přes PayPal a tak nebude problém ani s převodem peněz.
Tolik k Roští.cz pro rok 2011.
MythTV: moje cesta za bednou
11. Led
Byl jsem požádán, abych sepsal své zkušenosti s mým malým MythTV backendem. Pro ty co netuší, tak MythTV je open source domácí multimediální centrum. Má spoustu pluginů, umí ovládat i termostat nebo osvětlení domu, ale mě šlo hlavně o televizi, což je taky jeho hlavní činnost. MythTV je rozděleno na frontend a backend a to je také hlavní důvod, proč jsem do něj šel. Na domácím serveru se všemi tunery se umístí backend a na všechny počítače, notebooky a cokoli na čem může běžet linux se umístí frontend. Komunikace mezi nimi pak samozřejmě běží po ethernetu nebo i WiFině. Super je, že frontend nemusí být jen MythTV samo, ale je možné na něj napíchnout i XBMC. Pokud XBMC znáte, dáte mi za pravdu, že to je to nejhezčí, co můžete na multimedia nasadit.
Ale zpět k mé krabici. Původně jsem měl plán koupit DVB-T kartu do USB a připojit ji do už existujícího domácího serveru, který slouží jako úložiště pro multimedia a pro zálohy několika serverů. Krabici jsem pořídil za necelou tisícovku z Alzy. Disponuje jedním 3.5″ slotem, slotem na malou mechaniku a zdrojem. No nic moc, ale jako síťové úložiště super. Jako základní desku jsem použil starou mini-ITX desku s Celeronem na 1200 MHz s pasivním chlazením za 800 kč.
Jenže s potřebou televize jsem začínal potřebovat i PCI slot na desce. Z DVB-T tu totiž chytáme jen první multiplex a jedinou možností je satelit. Jenže USB satelitní karty stojí víc než jsem byl ochoten dát. Jedna DVB-S karta mi ležela v šuplíku. Sehnal jsem ji v akci za necelé pětikilo. Jde o klasiku SkyStar 2. Bedna mi to ovšem neumožňovala a tak po dlouhém přemýšlení bylo jasno. Mám všechno krom bedny, takže seženu bednu. Vítězem se stala tato malá zrůda z OKComputers. Původně jsem chtěl tuhle krásku od Thermaltake, ale nebyla skladem. Výhodou je možnost umístění dvou disků a mechaniky, takže vlastně třech disků.
Paměť jsem dostal od sdružení Třešnovec.net, kde se starám o páteřní síť. Je to 512 MB RAM modul co zůstal z jednoho routeru. Není to žádný zázrak, ale víc jak 256 MB stejně nepotřebuju. Pokud jde o diskový prostor, tak 1 TB disk už jsem měl a bratr k Vánocům dodal další 1.5 TB. V tomto okamžiku už nic nechybělo a když vše dorazilo, stačilo to sešroubovat a spustit. Výsledek vypadá takto:
Krabice šlape jak má, už přes tři týdny. Musím říct, že je trochu hlasitější jak její starší kolegyně s menším ventilátorem, ale to moc neřeším, vždycky jde strčit někam na půdu.
O Mini-ITX se zajímám už dlouho, takže bych tu měl ještě pár poznatků na toto téma. Jde o desky, kde je prakticky vždy jen jeden PCI slot, ze kterého jdou občas udělat dva (ale to neplatí vždy). To nakonec znamená, že nemůžete použít víc jak jednu DVB kartu do PCI. Dá se to dohánět přes USB, ale připlatíte si. Navíc najít kvalitní DVB-T tuner do USB je peklo. Dnes už jsou tyto desky po hardwarové stránce fakt vymazlené a cena není nějak extra vysoká. Většinou v nich najdeme Intel Atom a když si připlatíme, tak i nějakou lepší grafickou kartu od firma NVIDIA. Tu bych být vámi volil, pokud chcete používat krabici i jako frontend k televizi. MythTV i XBMC podporují akceleraci dekódování videa přes VDPAU, což tuto desku vystřelí v multimediálním výkonu mnohem výš, než budeme potřebovat.
Pokud budete chtít více tunerů a navíc DVB-S, zapomeňte na Mini-ITX a volte klasickou bednu s klasickou základní deskou a klasickým procesorem, bohužel teď jiná možnost není a nevypadá to, že by měla být. Rozdíl ve spotřebě bude razantní. Osazená Mini-ITX krabice si vezme 40 W, u klasické krabice budete rádi za 100 W.
O softwarové stránce věci si povíme příště.
OpenVPN: přístup z nebezpečného internetu do bezpečné sítě
28. Lis
Čtrnáct dní zpátky jsem dostal hezkou zakázku, jejíž cílem bylo vytvořit router, který by se připojil do nějaké sítě na jednom portu a na druhém portu by se připojilo PC a data z tohoto PC by jela přes vzdálenou síť. V technickém jazyce se tedy připojí router do nějaké sítě, vytvoří se tunel do vzdálené sítě někde ve firmě a všechno připojené na ostatní porty a případně přes WiFi, by šlo přes tuhle síť.
Výhody jsou zjevné. Může existovat síť s velmi restriktivním firewallem, která pustí maximálně SSH, poštu a všechno související s připojeními jdoucími ze vnitřku sítě a zároveň je možné přístup do sítě z venku, aniž by hrozilo nějaké odposlouchávání komunikace. Já jsem se rozhodl OpenVPN nahodit i u sebe, abych měl přístup k routerům, celé síti Třešňovec.net a také přístup k domácímu routeru, kde mám právě ten restriktivní firewall.
První krůčky s OpenSSL
Podle zadání k tomu mělo sloužit OpenVPN. To si hraje převážně na certifikáty a klíče, ale lze nějakým způsobem dodat i autentizaci. O té ale někdy jindy, certifikáty jsou víc než dostatečné, ale také trochu komplikované, proto to shrnu do několika bodů:
- Je potřeba kořenový certifikát certifikační autority (vás) + jeho klíč
- Je potřeba certifikát pro OpenVPN server + jeho klíč
- Je potřeba certifikát pro každého uživatele + jeho klíč
- Je potřeba Diffie–Hellman klíč
Poslední zmiňovaný slouží pravděpodobně pro vytvoření zabezpečeného spojení dvou neznámých stran, viz. Wikipedia. Ten se ale moc neplete, mnohem větší nepořádek jsem měl při vytváření certifikátu certifikační autority (v tomto případě mě) a pak udržet u sebe klíč a certifikát. Pro samotnou službu i pro uživatele je totiž potřeba zvláštní pár certifikát+klíč a jelikož některé návody jsou různě zmatené, rozhodl jsem se to sepsat postupně.
Nejdříve je potřeba nainstalovat a nakonfigurovat OpenSSL. Instalaci nechám na vás a když už u toho budete, nainstalujte i OpenVPN, Na /etc/ssl/openssl.cnf se už podíváme společně. V něm je potřeba upravit jeden řádek a to:
-
dir = /etc/ssl/rosti
Napište tam něco rozumného, nemusí to být zrovna rosti. Je dobré zůstat uvnitř /etc/ssl a taky se podívejte, jestli nechcete změnit něco dalšího, třeba výchozí počet dní platnosti certifikátu :
-
default_days = 730
Nebo třeba politiku povinných údajů o certifikátu (firma, jméno, email atd.). To se dělá pomocí
-
policy = policy_anything
A já zvolil policy_anything. Vlastnosti jednotlivých politik lze najít trochu níže, mělo by to být jasné na první pohled.
Adresář s certifikáty
Teď je potřeba vytvořit adresář, kde budeme pracovat s certifikáty. To uděláme třeba tímto způsobem:
-
export SSLDIR=/etc/ssl/rosti
-
mkdir -p $SSLDIR/certs
-
mkdir -p $SSLDIR/crl
-
mkdir -p $SSLDIR/newcerts
-
mkdir -p $SSLDIR/private
Ještě doplníme dva soubory, kde v jednom je uložené číslo posledního vydaného certifikátů a v druhém seznam vydaných certifikátů.
-
echo 01 > $SSLDIR/serial
-
touch $SSLDIR/index.txt
Vydáváme certifikáty
Teď přišel čas vytvořit certifikáty. Správně stačí, když si vytvoříte svůj certifikát certifikační autority a pak přijímáte požadavky od uživatelů, z nichž vygenerujete certifikát (podepíšete klíčem jejich request). Většinou ovšem jste certifikační autorita i uživatel v jedné osobě, takže si to ukážeme celé. Tento postup se dá použít i pro další služby. Uživatelé si pak do systému/prohlížeče importují certifikát vaší certifikační autority a podepsané certifikáty vašich jednotlivých služeb pro ně začnou být věrohodné.
Začneme certifikátem certifikační autority.
-
cd $SSLDIR
-
openssl req -new -x509 -nodes -out cacert.pem -keyout private/cakey.pem -days 1098
Až budete vyplňovat jednotlivé údaje, do COMMON NAME dejte něco rozumného, třeba vaše jméno, organizaci, atd. Tím by byl pár certifikát+klíč vytvořen a je můžeme přejít na certifikát pro OpenVPN na serveru. Jak již bylo řečeno, musíme nejdříve vytvořit request a ten pak podepsat klíčem certifikační autority.
-
openssl req -new -nodes -out request.pem -keyout key.pem -days 1098
-
openssl ca -in request.pem -out opevpn.crt
Teď hlavně pár odsuneme k OpenVPN, aby se nám nepletl a smázneme request.
-
mv opevpn.crt /etc/openvpn/
-
mv key.pem /etc/openvpn/
-
rm request.pem
Pro server bude ještě potřeba vygenerovat DH klíč:
-
openssl dhparam -out dh1024.pem 1024
A ten přesuneme také
-
mv dh1024.pem /etc/openvpn/
Vydáváme certifikáty pro jednotlivé uživatele
Jediné co z pohledu certifikátů zbývá, je rozdat certifikáty uživatelům. Ti většinou request nepošlou nebo jde o nás, takže tak jako tak začneme s ním:
-
openssl req -new -nodes -out clientrequest.pem -keyout clientkey.pem -days 1098
-
openssl ca -in clientrequest.pem -out client.crt
Všechny soubory začínající client odsuneme zase někam bokem. Requesty můžeme smazat a clientkey.pem a client.crt umístíme na klientskou stanici společně s cacert.pem, tedy s certifikátem certifikační autority. Všimněte si také, že soubory serial a index.txt se změnily.
Konfigurace OpenVPN na serveru
Pokud vás certifikáty neodradily, tak už máme víceméně vyhráno. OpenVPN je docela jednoduché na konfiguraci. Instancí serveru může běžet víc, init skript s tím počítá a spouští pro každý konfigurační soubor jednu instanci OpenVPN. Konfiguační soubory jsou umístěné v /etc/openvpn/ a za konfigurační soubor se považuje vše co končí na .conf. Tady je příklad:
-
root@misha:/etc/openvpn# ls
-
dh1024.pem houstinet.conf key.pem update-resolv-conf vpnserver.crt
V houstinet.conf se pak nachází:
# Jde o server mode server # TLSkový server tls-server # Klienti se napíchnout na zařízení tun (je tedy nutné mít spravně nastavené routování v síti, případně NAT) dev tun # Lokální adresa serveru local 89.111.104.70 port 1194 proto udp # Nastavení routování na straně serveru push "route 10.1.3.16 255.255.255.240 89.111.104.65" # Brána pro routování, pravděpodobně u klienta push "route 89.111.104.65" # DNS server pro klienta push "dhcp-option DNS 8.8.8.8" # Vynutit, aby provoz u klienta šel vždy přes tento tunel push "redirect-gateway" #Cesty ke klíčům a certifikátům ca /etc/ssl/rosti/cacert.pem cert /etc/openvpn/vpnserver.crt key /etc/openvpn/key.pem dh /etc/openvpn/dh1024.pem # Využitelný IP rozsah server 10.1.3.16 255.255.255.240 # Další parametry viz. dokumentace comp-lzo persist-tun persist-key verb 4
Pokud je váš konfigurační soubor na místě, stačí už jen restartovat OpenVPN a jedna strana tunelu je na světě.
-
/etc/init.d/openvpn restart
Konfigurace OpenVPN u klienta
Konfigurace klienta není o moc složitější. Opět je potřeba nainstalovat OpenVPN. Dále pak ke klientovi bezpečně přesunout klíč (správně by neměl cestovat) a certifikát jak klienta tak certifikační autority. Jakým způsobem to nechám na vás, ideální je SSH.
Konfigurační soubor pak vypadá takto:
#Jde o klienta, takže vyplníme kam se připojit remote 89.111.104.70 # že jde o TLS tls-client # připíchneme lokální síť přes tun dev tun pull proto udp port 1194 # Cesty k certifikátům a klíči ca /etc/openvpn/cacert.pem cert /etc/openvpn/client.crt key /etc/openvpn/clientkey.pem mute 10 comp-lzo verb 4
Co jsem nevysvětlil najdete v moc pěkné dokumentaci. Pokud nechcete nastavovat routování, použíjte místo tun tap, ale přijde mi to komplikovanější jak na straně konfigurace (je potřeba vytvořit bridge), tak na straně firewallu.
Ve skriptu pro firewall nezapomeňte povolit forwarding:
-
echo 1 > /proc/sys/net/ipv4/ip_forward
Jestli jsem někde něco minul, nebo vám něco podle tohoto návodu nebude fungovat, napište to do diskuse. Balíčky rozhodně instalujte z repositáře vaší distribuce. Ty co se nacházejí na openvpn.net, obsahují hrozně moc bordelu.
Android je svobodný operační systém!
26. Lis
Už jsem vzdal pokusy o diskusi s uživateli komentující mé články. Jak někde naťuknu téma svoboda, Android a chytré telefony, jsem nepochopen a diskutující se rozdělí do třech táborů, kde každý obsahuje tu svou volbu. Některé komentáře byly k věci, vysvětlili to co jsem v článku jen pohladil, ale některé byly úplně mimo. Korunu všem nasadil tento:
je to skoda, ze mame takove pekne hardware jako jsou dnesni telefony
a cpe se do toho vsude android. mnohem radeji bych v tom videl klasicke
linuxove distro s X-window a nejakym odpovidajicim desktopem.
mel bych zdrojaky, mel bych k tomu poradny pristup a nemusel cekat
kdo jake ROM s androidem vytvori pro ostatni.
Tak aby bylo jasno. Android je „svobodnější“ než linuxové jádro samo. Je šířen pod licencí Apache 2.0 a GPLv2. Jakým způsobem jsou licence rozdělený to si už najděte sami, ale po softwarové stránce je Android svobodný tak moc, že ho výrobci mohou vzít, udělat s ním cokoli, vrazit ho do telefonů a komunitě mohou maximálně zamávat z dvacátého patra.
Snažil jsem se vždycky psát, že díky tomuto se Android rozšířil, díky tomuto ho máme teď v kapse za rozumné peníze a další a další zařízení přicházejí. Zároveň ale dodávám, že přílišná svoboda škodí po komunitní stránce. Máme našlapané telefony, se kterými se dá dělat cokoli, jen se nedá dostat do Linuxu, který leží pod tím vším nablýskaným balastem. Ano, Android je jen API mezi Linuxem a uživatelskými programy. Co není v API, jakoby neexistovalo a tak je na Googlu co všechno do API zahrne. A ptáte se, co že to ten chudák Linux vespod, který všechno nese? To je jen prostředek, levný způsob jak se postarat o hardware, ale je lepší ho schovat.
Já mám Androida rád, používám ho a ještě dlouhou dobu ho používat budu. Zároveň se ale budu dostávat pod jeho čepičku a využívat služeb, které Google neplánoval a které vyžadují větší moc nad telefonem. Běžnému smrtelníkovi stačí telefon, který volá a má cool aplikace, mě stačí telefon, který si můžu upravit. Nechci telefon, který má to co nepotřebuji, to co ho zpomaluje a to co se plete. Nakonec totiž člověk zjistí, že telefon na míru je rychlejší a efektivněji se s ním pracuje.
Nebudu tu rozebírat motivaci výrobců a komunity, o to jsem se snažil v odkazovaném článku. Chci těmito pár řádky říci, že Android je svobodný operační systém, který běží převážně na uzavřeném hardwaru. Dalo by se přímo říct, že je ve vězení a na nás je ho odtamtud dostat.
LinuxAlt 2010 – neděle
8. Lis
Ještě že už je konec, jak jsem dorazil domů, padnul jsem do křesla a neměl sílu si ani udělat večeři. Plně chápu unavené obličeje organizátorů. Neděle byla trochu klidnější než sobota, ale přednášky držely úroveň předcházejícího dne. Snažil jsem se vás na Twitteru co nejvíce spamovat s tím zajímavým a celkový souhrn, který jsem načal včera, dnes dokončím.
Ráno bylo podobně pekelné jako to předešlé. Bydleli jsme s @pxjava v Chrlicích, ukázalo se, že to je krapet z ruky a rozkopané Brno zrovna nepomáhalo. Naštěstí nebyl moc provoz, takže malé bloudění jsme si mohli dovolit. Ke snídani jsme měli dva tousty a čaj v nějaké kavárně u kolejí. Po snídani jsme nabrali Liberix family gang a odfrčeli na přednášku mistra @krcmar. Ten opět prezentoval pomocí Prezi, což znamenalo, že jeho ChromedBird zobrazoval tweety s jeho twitter name ochotně na plátně. Dnes toho začali využívat i jiní, takže o srandu bylo postaráno.
V jeden okamžik použil @krcmar jako příklad nezabezpečeného přihlášení @rootcz. Má sice pravdu, ale mohl raději použít konkurenci
Pak popisoval různé útoky na síť a tady musím doplnit, že s některými si poradí jen malinko inteligentní switch, takže u všech to nepůjde. Zajímavou informací bylo, že nějaký jeho kamarád zkoušel podvrhovat certifikáty na nějaké síti a 40000 lidí s klidem podvržený certifikát odkliklo a pokračovali dál. Pouhých dvanáct postup přerušilo, což si vysvětluji spíše tím, že během toho jim spadlo IE nebo se stala podobná věc. Musím také dodat, že můj táta, když viděl poprvé hlášku o neplatném certifikátu, tak volal a ptal se co se děje, takže říkat, že SSL je k ničemu je trochu nadhodnocené.
Následovala hláška, která zabila celé dopoledne. Jeden posluchač přivedl @krcmar na myšlenku, že by každý den mohli dávat fingerprinty v televizi. Dokonce sem mi to podařilo náhodou natočit na moje Hero.
Druhou přednáškou bylo MythTV a tentokrát trochu líznuté vývojem. No Hello World bych tímhle stylem dělal hodinu, i kdybych měl návod krok za krokem, takže pluginy do MythTV ode mě nečekejte. Jinak na vývoj stačí umět Qt4 a C++ a trochu se seznámit s MythTV API. Tahle přednáška mě donutila oživit moje MythTV. Backend se na domácím serveru hřeje dost dlouho bez karty, kterou jsem musel dát pryč kvůli přechodu na MiniITX, ale pořídím si USB TV kartu a pojedu na tu. Přednáška byla moc hezky připravená, autor zmiňoval i její zajímavý původ. I když hned z kraje řekl, že MythTV doma nepoužívá (nebo jsem špatně poslouchal?), tak s MythTV se seznámil při psaní nějaké eseje (?) na ovládání domu přes televizi ve Velké Británii. Shodou okolností jsem včera měl možnost vyzkoušet bratrovo MythTV, který ho používá opravdu místo televize. Má to postavené na Gentoo a všechno tam šlape jako hodinky včetně IR dálkového ovládání. Svoji návštěvou nás poctil i Petr Stehlík, toho možná znáte ze seriálů na @rootcz jak o MythTV, tak o jiných tématech s tím souvisejících včetně praktického dekódování DVB-S.
Nějaké kontextové tweety:
byCx Adam Štrauch #LinuxAlt MythTV, centrum se vsim HW a daty, kam se pripojuji ostatni zarizeni
byCx Adam Štrauch #LinuxAlt MythTV umi vynechavat pri nahravani reklamy
pxjava Michal Hořejšek Pry MythTV nema plugin pro CSFD. To ale neni pravda.
#LinuxAlt
A video, kde se předvádí rozhraní MythTV.
Na oběd jsme původně plánovali jít do hospody, kde jsme včera večeřeli. Kdo by ale čekal, že v neděli nejedou a tak jsme skončili opět u toho příjemného pána z předchozího dne. Naštěstí si nás vzala nějaká slečna a ta věděla jak se má chovat a jedli jsme během chvilky. Během čekání a oběda padla řeč o startssl.com. To je certifikát zdarma, ač ověřovaný podle e-mailu. V nabídce jsou i placené aplikace, no mrkněte sami, já jen poslouchal. Každopádně ověřování u certifikátů, které to vyžadují funguje tak, že se necháte zkontrolovat nějakým věrohodným člověkem, který je ověřen dvěma nezávislými dalšími lidmi a vlastní nějaký placený certifikát. U nás je pár takových v Praze a Petr Stehlík, jako zdroj nových vizí, vyrazil do Prahy, kde si sjednal schůzku s těmito pány s tím, že založí novou ověřovací komunitu na Moravě. Když se vrátil domů, tedy po nějakých 300 km, tak zjistil, že sice je ověřený dvěma nezávislými ověřovateli, ale musí ještě koupit placený certifikát. Jeho sen rozjet StartSSL komunitu se tím rozplynul a Morava dostala tímto obrovskou ránu.
Cestou zpět bylo vidět, že je @krcmar unavený, protože už si na babu s nikým před vstupem nehrál. Na řadě byla přednáška o N900, Maemo, MeeGo a Mer. Byla přesunuta a nahradila Vývoj multiplatformních aplikací jejíž přednášející nedorazil. I když byl ze začátku @xmlich02 trochu nervózní a přednáška měla takový chaotický směr, velmi mě pobavila i poučila. Přednášet a u toho hrát Angry Birds tam nikdo ještě nezkoušel a jde to. Bylo nám předvedeno třeba MeeGo na Nokii N900, bohužel spadlo, než mohl přednášející dokončit druhou větu. Pokračovalo představování různého hardwaru a nestíhal jsem sledovat jakého, ale ten telefon s TV outem mě zaujal. MeeGo nám bylo ukázáno i na IBM ThinkPad. Tuto situaci ale nedokážu popsat tak jako následující fotografie.
Během přednášky přišla řeč i na Maemo, což byla asi hlavní náplň, takže nemůže chybět video.
Maemo umí věci podobně jako Android. Tím mám na mysli sdílení dat na různých službách, přehazování dat mezi aplikacemi apod. Nicméně mi přišlo Maemo dost těžkopádné. Nevím, asi nedokážu ocenit opravdový linuxový operační systém pro mobilní telefony.
Také nám byla oznámena novinka, že bylo založeno občanské sdružení Openmobility, které se bude starat o portál s odbornými články z oblasti mobilních telefonů.
Kontextové tweety:
vpavlin Václav Pavlín Hrát Airport na #n900 a prezentovat najednou očividně není nic snadného #Linuxalt @xmlich02
byCx Adam Štrauch Placené aplikace na Maemo (?) šli dříve (teď už prý možná ne) nainstalovat přes apt-get i bez zaplacení #LinuxAlt
byCx Adam Štrauch #LinuxAlt Háčkování N900 – video přehrané na přednášce http://www.youtube.com/watch?v=D9zicb-bo48
byCx Adam Štrauch #LinuxAlt Maemo umí rozpoznávat obličeje i tam kde nejsou
byCx Adam Štrauch #LinuxAlt Včera proběhla první fáze založení občanského sdružení Openmobility – http://www.openmobility.cz/
Liskni_si Tomas Janousek OpenOffice.org on N900 — http://store.lisk.in/tmp/07112010727.jpg #linuxalt
Následovala inspirativní přednáška o správě hromady serverů. Tam nám byly představeny nástroje cobbler, puppets a func . Nejvíce mě zaujal puppets a cobbler. Bohužel mě přednáška dost zmáhala a kombinace tmy a hodně klidného prostředí místnosti E105 mě uspávala. Func umí efektivně upravovat konfiguraci několika již jedoucích serverů, cobbler slouží na instalaci serverů po síti, s čímž souvisí jedna moc veselá historka, viz tweet:
byCx Adam Štrauch #LinuxAlt o Cobbleru z publika „jsem to pustil v siti, kolegyne restartovala windowsy a najednou tam mela linux“
A nakonec Puppets umí nakonfigurovat server od píky. Přednášející věděl o čem mluví, zmíněné nástroje používal a rozuměl jim, ale bohužel ho strčili do špatné místnosti. V té druhé běželo Ubuntu 10.10, kde jak jsem slyšel, neřekl Vojta Trefný nic zásadně nového, takže tohle byla lepší volba.
Pak následovalo představení obecně prospěšné společnosti Liberix, kde mě Vlastimil Ott zrovna neokouzlil, zvlášť když začal na návrhy protiargumentovat, ale o tomto tématu se ještě zmíním, až si s ním vyměním pár e-mailů. Už z diskuse na konci LinuxAltu mi bylo jasné, že do Liberixu nevidím.
Návštěvníci si zvláštní prezentace také všimli:
anydot Přemysl Hrubý Prezentace Liberixu je nějaká oboustranně vyhrocená… #LinuxAlt
Poslední přednáška byla Vinotéka Wine od @hroncok. Seznámil nás třeba s instalací Firefoxu do Wine. S průběhem vás seznámí následující tweet.
byCx Adam Štrauch #LinuxAlt Tak úvod do Wine sice o IE, ale ukázka na Firefoxu
Pomocí wine prefixů neboli lahví nám ukázal, jak se dá provozovat několik Firefoxů v různých barvách a nakonec doplnil i návod, kterým se dají změnit barvy Wine aplikací do barev GTK. To aby lépe zapadly do systému.
pxjava Michal Hořejšek Co se @hroncok honi hlavou, ze nastavuje pozadi ovladacich prvku na ruzovou? #LinuxAlt
Pak tu bylo nakousnutí spuštění viru pod Wine, ale k němu snad ani nedošlo, jen jsme byli upozorněni, že máme zakázat ve winecfg přístup k našim datům.
Po skončení přednášky se vybrali hodnotící papíry, z nichž se o pár minut později vybrali výherci jako v předchozím dni. Tentokrát jsem nic nevyhrál, takže jsem se se rozloučil s lidmi, které jsem cestou ven potkal a s @pxjava jsme se vydali domů.
Nakonec nezbývá než poděkovat organizátorům za super víkend a za rok se budu těšit znovu. Tentokrát si vyberu nějaké více linuxové téma a budu opět přednášet, slibuji
martinjanda Martin Janda Diky vsem poradatelum a prednasejicim. #linuxalt byla prijemna akce. Neco jsem se priucil, obcas jsem se zasmal… jeste jednou diky
patriktech Patrik Pomichal som doma z #linuxalt, dakujem organizatorom za fajn akciu, o rok so mnou iste opat pocitajte. Takujem aj @vpsfree bolo skvele
vallpaper Ondřej Cvacho Tak jsme se vrátili z #LinuxAlt bylo to fajn!
white_kate Kate the Unreal :] tak, doma.. #linuxalt se mi moc líbíl, parádní akce a plno zábavy, díky :] za rok se uvidíme zas!:)
vesp vesp Ikdyž jsem utekl trochu dříve,i já jsem sepsal něco ze svého pohledu na konferenci #linuxalt http://www.openfree.cz/konference-linuxalt-2010
adiky Adelka Doma ze super akce! Srandy kopec, skvělý přednášky …
Příští rok snad znovu, po třetí! #linuxalt
pxjava Michal Hořejšek Doma po vybornem #LinuxAlt.
Více info na hash tagu #LinuxAlt.


