Aug 12 2009

Není RAID jako RAID – díl 1. Úvod

Tag: HW Tunning,Linux,RAIDJens @ 21:00

Tímto článkem bych chtěl odstartovat sérii několik článků, které budou věnovány diskovým polím RAID a konfiguraci souborového systému (filesystému) v Linuxu vzhledem k maximálnímu výkonu, dostatečné bezpečnosti a minimální ceně. V seriálu se zaměřím především na softwarový RAID vytvořený pomocí utility mdadm, jeho konfiguraci na úrovni fyzických disků a operačního systém, budou popsány metodiky testování a jednotlivé testy, kterým se bude daná konfigurace testovat. Dalším aspektem bude i výběr souborového systému a jeho nastavení – zde se bude volit mezi systémy ext3, ReiserFS a XFS.

Nebude zde popisovat základní typy RAIDu, to už udělali dávno jiní a lépe, viz třeba česká stránka na Wikipedii o RAID, nebo ještě lépe anglická Wikipedia a RAID a mnoho dalších. Zaměřím se spíše na konkrétní konfigurační postupy a testy, na základě kterých bude možné vybrat konkrétní variantu pro konkrétní aplikaci – tou aplikací bude v našem případě databázový server MySQL, jehož výkonnost je mimo jiné silně spjata s výkonem souborového systému úložiště tabulek a dočasných souborů.

Hardwarový RAID

Hardwarový RAID je speciální kus hardware, který umožní vašemu počítači konfigurovat a spravovat diskové pole bez nutnosti instalace jakýkoliv ovladačů a zcela nezávisle na operačním systému.
Hardwarový RAID lze definovat takto:

  • má vlastní speciální procesor a vlastní paměť (ta může být navíc zálohována speciální baterií pro případ výpadku napájení),
  • je naprosto nezávislý na ovladačích a operačním systému, pro operační systém se tváří jako jeden disk (případně více disků v případě konfigurace více logických RAID svazků),
  • jeho cena je typicky dosti vysoká a pohybuje se v našich končinách na spodní hranici kolem 10 tisíc Kč.

Pokud vám tedy někdo bude tvrdit, že jeho deska za 4 000 Kč má hardwarový RAID, tak se tomu můžete klidně zasmát, protože je to zcela jistě nesmysl. Současné desky totiž mají pouze jednoduchou RAID utilitu na definici RAID pole, nicméně bez ovladačů a operačního systému z toho opravdové diskové pole nikdy nedostanete. Navíc ovladače pro takovéto „fake RAIDy“ existují pouze pro Windows a to často ještě v podivné kvalitě. Integrovaný RAID přímo na desce tedy není nic jiného než marketingový tah a podvod na uživatele, kteří problému příliš nerozumí a jsou ochotní připlatit za něco, co dostanou pouze při splnění speciálních požadavků. Navíc v případě problému s ovladačem takovéhoto RAIDu se vám diskové pole rozpadne, v lepším případě přijdete o data, v horším pak ani do systému nenabootujete.

Opravdový hardwarový RAID je však sofistikovaný kus hardware, který obsahuje vlastní procesor pro výpočet paritních dat (které jinak počítá CPU), zajišťuje rozložení výkonu v rámci zvolené úrovně RAID na fyzické disky. Dále řeší sestavení, obnovu a rozšiřování diskového pole v případě přidání fyzického disku, případně v případě výpadku či havárie havarují disků atd. Dále obsahuje speciální paměť – takzvanou „read/write cache”, do které jsou ukládán data před fyzickým zápisem na disky v případě zápisu (operační systému si tak myslí, že data jsou skutečně zapsána na disku a posílá další, kdežto oni jsou ve skutečnosti pouze v rychlé paměti a zapíší se až v okamžiku, kdy má „fyzický disk volno“ – toto je velmi jednoduše řečeno, celé je to mnohem sofistikovanější a podstatně složitější) a v případě čtení jsou zde uloženy před-načtené bloky dat, u kterých se předpokládá že o ně systém požádá v rámci čtení většího bloku dat. Takováto vyrovnávací paměť řadiče je obvykle v rozmezí 64MB512MB a často bývá zálohována speciální baterií (obvykle volitelná komponenta řadiče), která je schopna data ve vyrovnávací paměti udržet i v případě výpadku napájení. To znamená, že data jsou po celou dobu v paměti udržována a v momentě kdy je počítač znovu spuštěn, řadič zajistí jejich zapsání na disk (ještě před zavedením systému).

Toto vše je schopen hardwarový RAID bez potřeby jakéhokoliv operačního systému nebo ovladače. Operační systém pak vidí celé diskové pole jako fyzický disk a není třeba žádných speciálních aplikací na jeho inicializaci a správu. Takovýto řadič se pak stává na operačním systému zcela nezávislý a je možné ho provozovat bez nutnosti podpory ovladačů od výrobce hardware.

Softwarový RAID

Do této kategorie patří tedy i řadiče pevných disků, které si na hardwarový RAID pouze hrají (a zdá se, že výrobcům těchto předražených „akcelerátorů“ tento trik poměrně vychází) a ve skutečnosti vyžadují speciální ovladače, které instaluje do operačního systému – nazývají se „fake RAID”. Bez nich vám diskové pole fungovat nebude a utilita, která se spouští typicky po ukončení BIOSu počítače tak slouží pouze k tomu, abyste do operačního systému poslali informaci o tom, jak by měl váš RAID vypadat.

Jedná se tedy konkrétně o řadiče/čipsety dodávané přímo na základní desce:

  • Intel: (jižní můstky) ICH7R, ICH8R, ICH9R a ICH10R
  • nVidia: (čipsety) nForce4, nForce 500, nForce 600
  • AMD: (jižní můstky) SB450 (čipsety Radeon Xpress 200, Radeon Xpress 1150), SB600 (čipsety AMD 480/570/580)

Dále se pak prodávají speciální karty (to už je však opravdu vrchol zlodějiny a podvodů na neznalé), především od firmy Adaptec (Adaptec jim říká „HostRAID”), které jsou jakési „hardwarové akcelerátory“ pro RAID pole – které však bez OS a speciálních ovladačů nefungují nebo pouze částečně, přičemž jejich cena je poměrně vysoká.

Jedná se konkrétně o tyto produkty:

  • Adaptec 1220SA (cca 1700 Kč),
  • Adaptec 1225SA (cca 1500 Kč),
  • Adaptec 1420SA a 1430SA (cca 3000 Kč),
  • Adaptec 2405 (cca 6-7 tis. Kč !!!)
  • Adaptec 2410SA a 2420SA (cca 7-8 tis. Kč !!!)

Další softwarové RAIDy, které se však vydávají za RAIDy hardwarové naleznete například na stránce Linux SATA RAID FAQ.

mdadm

Základem softwarového RAIDu pro Linux je utilita mdamd (dříve mdctl), která je součastí linuxového jádra od verze 2. Ta vytváří v systému „md“ (multiple devices) zařízení, které se skládají z jednotlivých blokových zařízení (především fyzických disků a jejich oddílů — /dev/hda, /dev/sda atd.). Tato utilita umí vytvářet (bez potřeby jakéhokoliv „fake RAIDu”) RAID 0, RAID 1, RAID 4, RAID 5, RAID 6 a RAID 10 (a další speciální režimy: LINEAR, MULTIPATH a FAULTY).

Další díly seriálů se budou věnovat především práci s utilitou mdamd, popíšu v nich jednotlivé použitelné režimy RAID pro dosažení našeho cíle (maximálnímu výkon, dostatečná bezpečnost a minimální cena), jejich konfiguraci a sestavení na konkrétním hardware pro který budeme diskové pole optimalizovat. To je pro dnešek vše, můžete se těšit na další pokračovaní, které na sebe nedá dlouho čekat.


Aug 06 2009

Upgrade databáze a použití LAST_INSERT_ID()

Tag: MySQL,PHP,Zend FrameworkJens @ 10:40

Při vytváření nových verzí/revizí nějaké aplikace (ať již pomocí subversion či jiného nástroje) je často vhodné a někdy i potřebné aktualizovat strukturu databáze (přidání nových tabulek, sloupců, atd.) případně aktualizovat data (číselníky, systémové hodnoty) v databázi tak, aby nová změna v kódu byla kompatibilní se změnou struktury či dat v databázi (pro úplnost pouze doplním, že článek je napsán pro databázi MySQL 5.x).

Otázka je, jak tuto změnu provést tak, aby jsme při aktualizaci projektu na příslušnou revizi měli k dispozici i aktuální verzi databáze. Jedním z jednodušších řešení je, že spolu s commitem upraveného kódu (například nějakého modelu) commitneme i skript, který po aktualizaci projektu na příslušnou revizi spustíme a tím zajistíme upgrade databáze.

Tento skript může mít různé podoby, buď ho můžeme napsat přímo v PHP a nebo v případě jednodušší aktualizace použijeme pouze několik SQL příkazů. Nedávno jsem zrovna řešil poměrně jednoduchý problém, bylo třeba přidat skript do databáze šablonu i s jednou jazykovou mutací — to znamená: přidat jeden řádek do tabulky sablona a jeden řádek do tabulky sablona_mutace. Jelikož je však při definici ID šablon i mutací použit extra typ AUTO_INCREMENT, tak vložení druhého řádku s mutací bude záviset na ID vloženého řádku šablony. V SQL skriptu nemůžu přímo ID definovat, protože v době kdy se bude skript (upgrade) provádět může mnou vybrané ID šablony už být použito, proto je potřeba nechat sloupec NULL a MySQL vloží vlastní ID dle hodnoty AUTO_INCREMENT tabulky.

Řešením tohoto problému je použití funkce LAST_INSERT_ID(), po vložení řádku šablony definujeme cizí klíč ID šablony v řádku mutace právě pomocí této funkce. Výsledek by pak mohl vypadat nějak takto:

INSERT INTO sablona (id, nazev, kategorie, datum)
    VALUES (NULL, 'Neuskutečněná schůzka', 'system', NOW());

INSERT INTO sablona_mutace (id, sablona_id, jazyk_id, telo)
   VALUES (NULL, LAST_INSERT_ID(), 1, 'Schůzka ne neuskutečnila ...');

Takto jednouše by mohl vypada SQL skript, PHP skript kterým by jste udělali to samé například v Zend_Frameworku by mohl vypadat přibližně takto:

...
$sablona = array(
  'nazev' => 'Neuskutečněná schůzka',
  'kategorie' => 'system',
  'datum' => new Zend_Db_Expr('NOW()'),
);
$sablona_id = Sablona::getInstance()->insert($sablona);

$mutace = array(
  'sablona_id' => $sablona_id,
  'jazyk_id' => 1,
  'telo' => 'Schůzka ne neuskutečnila ...',
);
$mutace_id = SablonaMutace::getInstance()->insert($mutace);
...

Poznámka k PHP příkladu: modely jsou potomky třídy Zend_Db_Table a jsou vytvořeny jako singleton; hodnoty sloupce kategorie a jazyk_id v příkladu jsou magic konstanty což není úplně programátorsky čisté — je to pouze pro jednoduchost příkladu.


Jul 23 2009

YQL a IP lokátor

Tag: WebJens @ 14:20

Včera vyšel na Zdrojáku poměrně zajímavéhý článek o Yahoo Query Language. Vlastnosti technologie Open Data Tables se zdají být velmi užitečné a to například pro IP lokaci adresy — pomocí jednoduchého YQL dotazu: SELECT * FROM ip.location WHERE ip=’147.229.176.19′ lze získat přesnou odpověď ve formě XML. Stačí si už jen přečíst podmínky použití API a zmíněnou technologii někam implementovat :)

Vybrané limity použití:

  • max. 100 000 volání YQL na jeden přístupový API klíč,
  • max. 1000 volání na jednu IP do struktury /v1/public/* za hodinu,
  • max. 10 000 volání na jednu IP do struktury /v1/yql/* za hodinu.

Jul 04 2009

Firefox 3.5 se ukončí při zavření poslední záložky

Tag: WebJens @ 15:00

Firefox 3.5 přišel s několika vylepšeními při práci se záložkami. Nevím však, jestli chování, které způsobuje ukončení celého Firefoxe v případě zavření poslední záložky (namísto zobrazení prázdné záložky) lze považovat za vylepšení.

Mě osobně toto hodně vadí a uvítal bych i možnost toto nastavit přímo v nastavení Firefoxe (záložka „Tabs“ v nastavení je stejně poloprázdná). Bohužel to tam zatím nenajdete, jediná možnost je použití about:config (do adresního řádku) a najít hodnotu browser.tabs.closeWindowWithLastTab a změnit ji na false.

A když už jsme u těch „záložkových novinek“ Firefoxu 3.5, znáte jeho novou fíčuru Tab tearing? (přetahovaní záložek) — umožnuje záložku vytáhnout mimo okno Firefoxe a vytvořit tím tak zcela nové okno, funguje to i na opak: okno Firefoxe lze přetáhnout do jiného okna Firefoxe a vytvořit tím tak novou záložku. Podívejte se na video, jak to funguje …


Jun 30 2009

PHP 5.3, Firefox 3.5, Debian 5.0.2, PDT 2.1

Tag: ZprávičkyJens @ 21:20

Začalo léto, polovina roku je pryč a vývojáři všeho druhy se zřejmě chystají na dovolenou :) a dokončují co mohou. Konec června a začátek července charakterizuje uvolnění spoustu důležitých verzí softwaru pro vývoj webových aplikací.

  • PHP 5.3.0 – začněme tím nejdůležitějším a nejaktuálnějším, dnes (30.6.2009) byla oficiálně vydána dlouho očekávaná a významná verze PHP 5.3.0, která přináší především podporu jmenných prostorů (namespaces), late static binding (u statické metody lze mimo jiné určit, kterou třídou je vyvolána) a lambda (anonymní) funkce a uzávěry.
  • Firefox 3.5 – další, opět velmi podstatná a aktuální událost je dnešní vydání „nového“ Firefoxu ve verzi 3.5, který přináší některá podstatná vylepší v práci s pamětí (menší paměťové nároky jsou u firefoxe evergreen:), zrychlený JavaScript (použití enginu TraceMonkey), anonymní prohlížení. Jednou z nejvíce očekávanou novinkou je však podpora některých elementů (audio, video) nově vznikající specifikace HTML 5.
  • Debian GNU/Linux 5.0.2 – další aktualizace se týká aktuální stable verze Debianu (Lenny), jedná se tedy již o druhé opravné vydání (vydáno 27.6.2009) a opravuje klasicky několik bugů a bezpečnostních chyb, více viz oficiální oznámení.
  • PHP Development Tools Project 2.1 – a posledním vydáním (26.6.2009) uzavírá vývojové prostředí PDT 2.1 postavené na platformě Eclipse — obsahuje mimo jiné podporu pro PHP 5.3 a namespaces. Z mé osobní zkušenosti je však PDT od verze 2.0 poměrně zabugované a nepřenáší žádné větší vylepšení za které by stálo přejít z podstatně svižnější verze 1.3

Jun 29 2009

Nastavení PHP pro větší bezpečnost

Tag: PHPJens @ 23:30

O tom, jak zvýšit bezpečnost PHP aplikací již bylo napsáno moc a moc. Prvním a základním pravidel je filtrování vstupů uživatelů, na toto téma již bylo popsáno nepřeberné množství přístupů a naprogramováno spousty knihoven, které dělají téměř vše za vás. Druhým, neméně důležitým aspektem je konfigurace PHP direktiv, ať již v přímo v php.ini nebo pomocí ini_set(...) či v htaccessu. To, na jaké direktivy by jste se měli zaměřit především, se pokouší odpovědět i PHP Security Consortium ve svém projektu PhpSecInfo.

PhpSecInfo

PhpSecInfo se zaměřuje na řadu klíčových direktiv, které jsou z hlediska bezpečné konfigurace PHP důležité, doporučuje jejich nastavení, popisuje důvody proč je nastavit tak a tak a poskytuje vám přehlednou aplikaci v PHP na to, aby jste si sami mohly vyzkoušet nastavení vašeho serveru či virtualhostu.

Pojďme se blíže na jednotlivé testy a k nim odpovídající direktivy podívat (seznam testů je řazen abecedně, nikoliv podle důležitosti):

  • allow_url_fopen
    - defaultně on, doporučená hodnota off
    - v případě že je povoleno, může skript používat funkce file_get_contents(), include(), require(), … na vzdálené soubory, což může způsobit vložení závadného kódu z cizího serveru pokud správně neošetříte vstupy
    - více o allow_url_fopen direktivě/testu
  • allow_url_include
    - defaultně 0, doporučená hodnota 0
    - podobný problém jako allow_url_fopen
    - více o allow_url_include direktivě/testu
  • display_errors
    - defaultně on, doporučená hodnota na produkčním serveru off
    - vhodné mít zapnuté při ladění a vývoji, na produkčním serveru se doporučuje vypnout
    - více o display_errors direktivě/testu
  • expose_php
    - defaultně on, doporučená hodnota off
    - rozhodně vypnout vždy, umožňuje potenciálnímu útočníkovi zjistit relativně přesně verzi PHP na serveru a na základě toho využít potencionální bezpečnostní chyby
    - více o expose_php direktivě/testu
  • file_support
    - v tomto případě se nejedná o konfigurační direktivu ale pouze název testu, který ověřuje zda vaše verze PHP obsahuje opravu problému zranitelnosti v knihovně cURL
    - více o file_support testu
  • file_uploads
    - defaultně on, v případě že ve vaší aplikaci nahrávání souborů nepoužíváte, doporučuje se nastavit off
    - více o file_uploads direktivě/testu
  • force_redirect
    - defaultně on, doporučená hodnota on
    - direktiva, která se používá pouze v případě že spouštíte PHP přes CGI, na některých web serverech vypnutá (IIS)
    - více o force_redirect direktivě/testu
  • group_id
    - nejedná se o direktivu PHP ale proměnou skriptu, tato proměnná definuje ID skupiny systému pod kterým je PHP skript spuštěn a tento test upozorňuje na možné riziko spuštění skriptu privilegovaným/systémovým uživatelem
    - více o group_id testu
  • magic_quotes_gpc
    - defaultně on, doporučená hodnota off
    - velice známá a v minulosti často diskutovaná direktiva – je-li direktiva zapnuta, pak budou všechny vstupní proměnné _GET, _POST, _COOKIE (a možná i některé další) escapovány pomocí addslashes
    - direktiva magic_quotes_gpc byla přídána především pro zabránění SQL injection, nicméně později se ukázalo, že funkce addslashes není zcela dostačující pro některé speciální případy a proto se musí používat speciální escapovací funkce v závislosti na použité databázi, spoléhat tedy na „auto-escapování“ není dobré a proto se doporučuje direktivu nezapínat
    - více o magic_quotes_gpc direktivě/testu
  • memory_limit
    - maximální povolená hodnota paměti, kterou může PHP skript alokovat – doporučenou hodnotu těžko definovat, obecně čím méně tím lépe nicméně je třeba brát v úvahu „žravost“ některých knihoven typu Zend Framework, které si s pamětí starosti nedělají a alokují co mohou
    - více o memory_limit direktivě/testu
  • open_basedir
    - tato direktiva by měla nahradit safe_mod, který je zlem vždy a všude – direktiva open_basedir definuje, do kterých adresářů na fyzickém filesystému se PHP skripty dostanou a kam už ne
    - v případě hostingového serveru nebo serveru s více uživateli, je správně nastavený open_basedir nezbytnost
    - více o open_basedir direktivě/testu
  • post_max_size
    - defaultně 8 MB, doporučená hodnota 256 K
    - definuje jakou maximální velikost dat lze odeslat PHP skriptu pomocí metody POST – doporučená hodnota je zde poměrně nízká a lze o ni dosti polemizovat, vždy je třeba zvážit potřeby aplikace, příliš vysoká hodnota může znamenat možnost DoS útoku na server
    - více o post_max_size direktivě/testu
  • register_globals
    - defaultně off, doporučená hodnota off
    - tuto direktivu snad není třeba ani popisovat – jedná se o historický pozůstatek z divokých dob PHP, zakázat vždy a všude – více o register_globals direktivě/testu
  • save_path
    - tato direktiva (přesněji session.save_path) definuje cestu, kde se budou ukládat data uživatelských session – cesta by měla být mimo strukturu kořene webu (document root) a měla by mít vhodně nastavená oprávnění (aby si session nemohli číst ostatní uživatelé systému)
    - více o save_path direktivě/testu
  • upload_max_filesize
    - definuje jakou maximální velikost dat lze odeslat PHP skriptu pomocí nahrávacího (upload) formuláře – doporučená hodnota musí vycházet z potřeb konkrétní aplikace, obecně čím méně tím lépe
    - více o upload_max_filesize direktivě/testu
  • upload_tmp_dir
    - definuje cestu, kde se ukládají dočasně soubory, které jsou nahrávány na server pomocí formuláře – podobně jako direktiva save_path by měla být tato cesta mimo strukturu kořene webu a měla by mít vhodně nastavená oprávnění
    - více o upload_tmp_dir direktivě/testu
  • user_id
    - nejedná se o direktivu PHP ale proměnou skriptu, tato proměnná definuje ID uživatele systému pod kterým je PHP skript spuštěn a tento test upozorňuje na možné riziko spuštění skriptu privilegovaným/systémovým uživatelem
    - více o file_uploads testu

Popsané výchozí nastavení se vždy nemusí shodovat v vašim výchozím nastavení, některé distribuce a operační systémy a některé verze PHP si nastavují tyto hodnoty různě.

Před nastavením dané proměnné je vždy také třeba zvážit, zda bude server či VirtualHost pro více projektů/uživatelů. Důležité je také zvážit, jestli nasazení omezujících pravidel v podobě změn PHP direktiv neovlivní současné projekty na serveru, které by se pak museli předělat vzhledem ke změně nastavení. Proto je vhodné použít kombinaci jak globálních nastavení v php.ini, tak lokálních pomocí ini_set(...) či htaccessu.

Závěr

Bohužel, projekt PhpSecInfo už je přes dva roku opuštěn (poslední verze je z 2007/04/06) a těžko říci, zda kdy bude ještě aktualizován. Myslím že je to škoda, protože stále vznikají nové a nové hrozby, přidávají se nové konfigurační direktivy (a některé se ruší) a pro začínajícího ale i pokročilého administrátora mohl být projekt dobrým zdrojem informací a inspirace.


May 16 2009

Nový kabát Google Webmaster Tools

Tag: Web,ZprávičkyJens @ 13:00

Služba Google Webmaster Tools (old) pomalu přechází na nový vzhled: Google Webmaster Tools (new). V tuto chvíli je stále k dispozici i stará verze, ve které se mě kupodivu zobrazuje více věcí ve stejné záložce než v nové. Nové rozmístění navigačních prvků mě více připomíná ovládávání Google Analytics a nějak zvlášť mě nenadchlo, ale asi je to to zvyku.

Google Webmaster Tools new design

Jako zajímavá novinka v novém vzhledu mě přijde zobrazovaní relevantních odkazů „Téma nápovědy„, které vedou do nápovědy Google, podle toho, ve které sekci se zrovna nacházíte.

Google Webmaster Tools new design


May 10 2009

BASH: escapovaní podtržítka mezi proměnnými

Tag: LinuxJens @ 01:30

Při vytváření jednoho SHELLového skriptu jsem narazil na jeden zajímavý problém, mám dvě proměnné, potřebu je zřetězit a mezi ně dát podtržítko a předhodit je jako parametr nějaké utilitě. Jelikož však většinou používám double quotes tak mě to s tím podtržítkem nemohlo projít, protože BASH si myslí, že je to celé i s podtržítkem proměnná, ona není definována a tak ji přiřadí null.

#!/bin/bash

NAME="hubert"
TIMESTAMP=`date +%F_%H%M%S`

echo "$NAME_$TIMESTAMP" # vypise pouze $TIMESTAMP bez $NAME: 2009-05-10_011835

Toto nefunguje, protože BASH zcela logicky bere $NAME_ jako proměnnou, problém ale je, že toto: "$NAME_$TIMESTAMP" taky nefunguje, výsledek je lomítko ve výsledném stringu, asi takto: hubert_2009-05-10_011835.

Takže malý příklad, ja to tedy funguje:

#!/bin/bash

PRED="jens"
POST="killer"

echo "$PRED_$POST"  # killer
echo '$PRED_$POST'  # $PRED_$POST
echo $PRED_$POST    # killer
echo ""

echo "$PRED_$POST" # jens_killer
echo $PRED_$POST   # jens_killer

Myslel jsem si, že BASH je jednoduchý a jasný, ale je to horší jak Céčko s makrama a pointrama :) Mám je ještě moc co učit!

A na závěr strašně zajímavé čtení na dobrou noc (četl jsme to několikrát a vždy tam najdu něco nového:): Advanced Bash-Scripting Guide: Special Characters.


May 07 2009

SSH autentizace pomocí klíčů bez hesla

Tag: LinuxJens @ 20:00

Tento článek v rychlosti popisuje SSH autentizaci mezi jednotlivými stroji pomocí dvojice soukromý/veřejný klíč. Nejedná se o nic nového ani převratného, akorát to vždycky zapomenu a tak si to raději napíšu sem, ať vím, kde hledat příště.

Scénář

Dva stroje, jeden franta (192.168.1.1) a druhý hubert (192.168.1.3) a chci se mezi nimi připojovat jednoduše tak, že nepotřebuji žádné heslo — tedy stačí zadat pouze franta:~# ssh hubert a jsem tam (klíče kopíruji pouze pro uživatele root na obou strojích). Stejně tak se chci připojit z huberta na frantu. Žádná parafráze, žádné heslo.

Předpoklad

Nainstalovaný SSH server na obou strojích:

# apt-get install ssh

a v souboru /etc/ssh/sshd_config povolenu autentizaci pomocí klíčů (je to defautlní nastavení Debianu):

RSAAuthentication yes
PubkeyAuthentication yes

Postup

  1. Vytvoření dvojice klíčů na obou strojích, nejdříve hubert (na pořadí nezáleží):
    hubert:~# ssh-keygen
    Generating public/private rsa key pair.
    Enter file in which to save the key (/root/.ssh/id_rsa):
    Enter passphrase (empty for no passphrase):
    Enter same passphrase again:
    Your identification has been saved in /root/.ssh/id_rsa.
    Your public key has been saved in /root/.ssh/id_rsa.pub.
    The key fingerprint is:
    xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx root@hubert
    The key's randomart image is:
    ...
    
    a franta to samé, na všechny otázky stačí stisknout <enter>
  2. Přenesení veřejných klíčů jednotlivých strojů na jejich protějšky:
    Klíč z huberta na frantu:

    hubert:~# scp .ssh/id_rsa.pub root@franta:~/hubert_rsa.pub
    root@franta's password:
    id_rsa.pub                                                                  100%  393     0.4KB/s   00:00
    
    a klíč z franty na huberta to samé:
    franta:~# scp .ssh/id_rsa.pub root@hubert:~/franta_rsa.pub
    root@hubert's password:
    id_rsa.pub                                                                  100%  393     0.4KB/s   00:00
    
    Při tomto přesunu budete naposledy potřebovat autentizaci pomocí hesla.
  3. Zapsání veřejného klíče huberta do autentizačního souboru franty a naopak:
    franta:~# cat hubert_rsa.pub >> .ssh/authorized_keys
    hubert:~# cat franta_rsa.pub >> .ssh/authorized_keys

Závěr

V tuto chvíli by již autentizace měla vzájemně fungovat, takže stačí jen vyzkoušet:

franta:~# ssh hubert
Linux hubert 2.6.26-2-amd64 #1 SMP Fri Mar 27 04:02:59 UTC 2009 x86_64
...
hubert:~#

Stejně tak, jako přihlašování přes SSH bude fungovat bez hesla i kopírování přes SCP.


May 06 2009

mdadm: RebuildStarted event na Debianu

Tag: Debian,HW Tunning,LinuxJens @ 21:30

Na několikati Debianích strojích, které mám možnost spravovat jsem si až nedávno všiml velmi pozoruhodného úkazu — každou první neděli v měsíci okolo prvním hodiny ráno vyletí zatížení stroje na poměrně vysoké hodnoty, přičemž převažují především iowaity. V zápětí jsem zjistil že to má nastarost softwarový RAID a démon mdadm, který právě v tuto dobu spouští „kontrolu“ softwarového diskového RAIDu — utilita checkarray.

Příčinu jsem našel v souboru /etc/cron.d/mdadm:

#
# cron.d/mdadm -- schedules periodic redundancy checks of MD devices
#
# Copyright © martin f. krafft <madduck@madduck.net>
# distributed under the terms of the Artistic Licence 2.0
#

# By default, run at 00:57 on every Sunday, but do nothing unless the day of
# the month is less than or equal to 7. Thus, only run on the first Sunday of
# each month. crontab(5) sucks, unfortunately, in this regard; therefore this
# hack (see #380425).
57 0 * * 0 root [ -x /usr/share/mdadm/checkarray ] && [ $(date +%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet

Předpokládal bych, že tato utilita „nějak“ zkontroluje příslušný MD oddíl a v případě zjištění nedostatků, spustí jeho synchronizaci. Realita je však jiná, na všech strojích spustila tato utilita kompletní synchronizaci všech oddílů.

May  3 00:57:01 localhost /USR/SBIN/CRON[22337]: (root) CMD ([ -x /usr/share/mdadm/checkarray ] && [ $(date +%d) -le 7 ] && /usr/share/mdadm/checkarray --cron --all --quiet)
May  3 00:57:02 localhost kernel: [141056.924658] md: data-check of RAID array md0
May  3 00:57:02 localhost kernel: [141056.924663] md: minimum _guaranteed_  speed: 1000 KB/sec/disk.
May  3 00:57:02 localhost kernel: [141056.924666] md: using maximum available idle IO bandwidth (but not more than 200000 KB/sec) for data-check.
May  3 00:57:02 localhost kernel: [141056.924670] md: using 128k window, over a total of 97659008 blocks.
May  3 00:57:02 localhost kernel: [141056.926736] md: delaying data-check of md1 until md0 has finished (they share one or more physical units)
May  3 00:57:02 localhost kernel: [141056.928064] md: delaying data-check of md2 until md1 has finished (they share one or more physical units)
May  3 00:57:02 localhost kernel: [141056.928070] md: delaying data-check of md1 until md0 has finished (they share one or more physical units)
May  3 00:57:02 localhost mdadm[2769]: RebuildStarted event detected on md device /dev/md0
...

Nevím jestli je možné, že za měsíc provozu libovolného stroje se MD svazky tak rozhodí, že je třeba provést pravidelnou synchronizaci, ale přijde mě minimálně divné, že se to dělej na všech vzájemně nezávislých strojích měsíc co měsíc — vždy kompletní synchronizace pro všechny svazky.

May  3 00:57:02 localhost mdadm[2769]: RebuildStarted event detected on md device /dev/md0
May  3 01:00:02 localhost mdadm[2769]: Rebuild20 event detected on md device /dev/md0
May  3 01:04:02 localhost mdadm[2769]: Rebuild40 event detected on md device /dev/md0
May  3 01:07:02 localhost mdadm[2769]: Rebuild60 event detected on md device /dev/md0
May  3 01:10:02 localhost mdadm[2769]: Rebuild80 event detected on md device /dev/md0
May  3 01:12:11 localhost mdadm[2769]: RebuildStarted event detected on md device /dev/md1
May  3 01:12:11 localhost mdadm[2769]: RebuildFinished event detected on md device /dev/md0
May  3 01:18:11 localhost mdadm[2769]: Rebuild20 event detected on md device /dev/md1
May  3 01:24:11 localhost mdadm[2769]: Rebuild40 event detected on md device /dev/md1
May  3 01:30:11 localhost mdadm[2769]: Rebuild60 event detected on md device /dev/md1
May  3 01:36:11 localhost mdadm[2769]: Rebuild80 event detected on md device /dev/md1
May  3 01:41:31 localhost mdadm[2769]: RebuildStarted event detected on md device /dev/md2
May  3 01:41:31 localhost mdadm[2769]: RebuildFinished event detected on md device /dev/md1
May  3 01:48:31 localhost mdadm[2769]: Rebuild20 event detected on md device /dev/md2
May  3 01:54:31 localhost mdadm[2769]: Rebuild40 event detected on md device /dev/md2
May  3 02:02:31 localhost mdadm[2769]: Rebuild60 event detected on md device /dev/md2
May  3 02:09:31 localhost mdadm[2769]: Rebuild80 event detected on md device /dev/md2
May  3 02:18:00 localhost mdadm[2769]: RebuildFinished event detected on md device /dev/md2, component device mismatches found: 128

Z výsledku logu přitom jasně vyplýva, že problém byl nalezen pouze na svazku md3, ale všechny ostatní byly v pohodě.

Proto doporučuji, pokud používate mdadm a váš stroj poskytuje nějakou důležitou službu, jejíž chod by mohlo omezit přílišné zatížení systému v době synchronizace, tuto kontrolu vypnout a spouštět příkazem /usr/share/mdadm/checkarray --cron --all --quiet raději ručně v době, kdy vám to více vyhovuje.


« Předchozí stránkaDalší stránka »