cx

Tento uživatel doposud nenapsal žádné informace o sobě

Web: http://initd.cz

Jabber/GTalk: cx@dev-it.org


Příspěvky od cx

Tabulka oblastí GPT, jak mít moderně rozdělený disk

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.

  1. Když to nenabootuje, tím že vyndáte staré disky se to nespaví
  2. 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.

Nechci sračky v diskusích a co vy?

Zatímco kousek na jihu umírají lidé z banálních důvodů a Evropa se každým dnem blíží do ekonomické krize, kvůli které bychom nemuseli mít ani co jíst, existují malé až nevýznamné spory mezi obyčejnými lidmi, kde si jedna strana myslí, že jejich sdělení jak někdo dělá něco špatně je natolik důležité, aby doslova zasrali celou diskusi absolutně off-topic bláboly.

Jako redaktor serveru Root jsem někdy do podobných sporů vtažen. Jednoduché upozornění na překlep samozřejmě jako problém nevidím, ale když už se do mě čtenáři pouštějí drsněji stylem „si to po tom Googlu pane Štrauch aspoň přečtěte“ nebo „vraťte se do třetí třídy, protože jste určitě na několika důležitých hodinách chyběl“, dokáže to pěkně zamávat s mou chutí něco dál psát. Dnes jsem byl do takového sporu vtažen pod zprávičkou „23 nejlepších grafických karet v historii PC„, která se původně jmenovala „23 největších grafických karet v historii PC“. Podle diskuse by se mohlo zdát, že použití slova „největších“ je minimálně shodné s bratrovraždou. Snažil jsem se s diskutujícími argumentovat, ale nic víc než urážky jsem na oplátku nedostal, takže jsem titulek nakonec změnil na „nejlepších“, což sice otočilo význam špatným směrem, ale už nikdo neremcá.

Ignoranti mají v argumentaci proti mě dost munice. Co jsem udělal za posledních pár let jde vcelku jednoduše dopátrat včetně těch pár přešlapů (důležitých, ne nějaké překlep), takže kdokoli se do mě chce navážet má možnost, informace se válí všude. Na druhou stranu já v těch diskusích často nevím s kým mám tu čest. Až bych někdy řekl, že se ti lidé schovávají za bezduchou přezdívkou jen proto, aby schovali, že vlastně nemají co schovat.

Ale co, čert to vem. V prvním roce redaktorství jsem si vypěstoval punc, kterého se už jen tak nezbavím a i když napíšu 50 zpráviček v řadě bez chyby, ta chybnatá jednapadesátá všem připomene, jak je ten Štrauch vlastně k ničemu, neumí psát a už by to měl pro dobro všech vzdát. Možná neumím psát, ale asi to nebude tak hrozný, když mě ještě z Roota nevykopali.

Co mě víc mrzí jsou pak podobné komentáře na jiných serverech, kde za zprávičky nemají redaktoři ani zdaleka tolik peněz co já, pokud vůbec nějaké. Ve skutečnosti tento text píši kvůli zprávičce „Applu ve sporu se Samsungem pomohl falešný důkaz“ na serveru SvětAndroida.cz. Alena Varkočková si dovolila, napsat slovo evidence místo slova důkaz. A hned první komentář:

EVIDENCE?!? Ty už to nehul, Varkočková…

A i když už z autorů dalších komentářů nečpí ta síla a odhodlání o sobě říct, že jsou úplní kreténi, mají také něco do sebe.

Trochů kýčovité:

Evidence? Snad důkaz, ne? Tohle prznění češtiny je docela síla.

Až trapné:

Przneni cestiny je teda hnus maximalni, byt autorkou tak nevychazim z baraku.
Njn, Apple, ani se nedivim, tece jim do bot :-P

Všechny tři reakce mají něco společného, jsou zbytečné. Stačilo napsat „Máš tam chybu, evidence je důkaz“ a bylo by. Takhle jsou první tři příspěvky úplně mimo téma. Navíc se některé snaží autorku nevkusně napadnout. Pokud za tu zprávičku autorka nedostala ani korunu, pravděpodobně si příště rozmyslí, jestli ještě něco napíše. Jediné, čeho tak autoři podobných komentářů dosáhli je, že jejich oblíbený server o androidovi potenciálně přišel o jednoho z autorů a provozoval musí začít hledat nového člověka.

Na Rootu se občas snažím zlákat nové autory, kteří by napsali pár článků o tom co dělají nebo používají každý den. Šlo by o články napsané z radosti, které by toho mohly hodně nabídnout. Dobrý příklad může být třeba článek, který vyjde zítra o androidí čtečce knih iReader od Kamila Pošvice. Kamil jasně řekl, že pokud ho budou uživatelé v komentářích napadat, další článek už nenapíše a já se mu nedivím. Čtenáře asi nezměním, ale provozovatelé by se měli nad sebou zamyslet a když někdo napíše „Ty už to nehul, Varkočková“, měli by to bez pardonu smazat a nejlépe ani nepustit ven. Já sračky v diskusích nechci, vy snad jo?

Zpracování změn konfigurace na novém Roští.cz

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:

  1. Vytvoř uživatele XX
  2. Zkopíruj do jeho domovského adresáře výchozí strukturu
  3. Vytvoř databázi XX
  4. 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.

  1. Uživatel vytvořen
  2. Struktura zkopírována
  3. Databáze vytvořena
  4. 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.