Category Archives: administrace

CentOS a vydávání aktualizací

Dnes jen krátce, ale za to se zajímavým odkazem.

Pokud jste uživateli distribuce CentOS, určitě jste si všimli, že vydávání aktualizací minor verzí se oproti RHELu pořád zpožďuje. Vývojáři se snaží alespoň hotfixy a security aktualizace distribuovat přes Continuous Release repozitář. Proč se vývoj táhne vysvětluje v maillistu Johnny Hughes. Ve zkratce: hledejte za tím rozdělení RHELu do několika skupin (Server, Workstation, ...), kde ve stejných skupinách jsou různé balíčky, a zpřísnění politiky pro sdílení některých souborů/balíčků.

A tak se z CentOS "přebalovačů" stávají opravdoví vývojáři..

MySQL: unauthenticated user

Nedávno jsem narazil na zajímavý problém: MySQL na jednom nepříliš vytíženém serveru začalo vracet chybu Too many connections, i když z počet spojení běžně stačí s rezervou. Po chvilce pátrání jsme s programátorem zjistili, že jednou za čas se tam objeví spousta připojení ze vzdáleného (legitimního) serveru označená jako "unauthenticated user". Výpis MySQL procesů byl pak plný takovýchto řádek:

| 263718676 | unauthenticated user | 10.0.0.2:51896 | NULL    | Connect     |   NULL | login  | NULL |

Po chvilce pátrání jsem zjistil, že nejde o útok - ani nevíte jaká je to po pár zkušenostech úleva. Chyba byla ve špatné komunikaci s DNS servery, které dostatečně rychle neodpovídaly.

MySQL se DNS serverů dotazuje téměř při každém uživatelském loginu (používá sice nějakou vnitřní cache, ale asi to není žádná bomba). Využívají se k tomu funkce gethostbyaddr(), pomocí které se zeptá, jaký záznam na této IP vězí. Potom nasadí gethostbyname() a porovná vrácenou IP adresu s původní (více rozepsané je to v dokumentaci). Jednoduché a účinné do okamžku, kdy se zhorší komunikace právě s DNS servery. Nabízejí se dvě možnosti, jak to vyřešit:

  • Použijte přepínač --skip-name-resolve. Hodí se hlavně v případě, že dopředu nevíte, odkud se k serveru klienti připojují. S použitím ale musíte upravit všechny záznamy pro povolené uživatele, tak aby ve sloupci Host byly jen IP adresy nebo 'localhost'.
  • Zapište záznamy s klienty do /etc/hosts souboru. Funkce gethostbyaddr() i gethostbyname() se nejdříve podívají právě do tohoto souboru než aby se dotazovaly jiných serverů. Tato možnost se hodí, pokud máte pár jen statických klientů.

Třeba to někomu pomůže..

LVM v RAID poli s kickstart

Anaconda při instalaci CentOS 6 pomocí kickstart souboru trpí zvláštním nešvarem: při rozdělení disků pro použití LVM může zahlásit chybu new lv is too large to fit in free space (celý výpis chyby); i když to není pravda. Kde je problém?

Začnu tím, jak chci mít disky rozděleny:
Mějme dva identické disky, které budou v softwarovém RAIDu 1 (mirroring), rozděleny budou na ~250MB /boot a zbytek pro LVM, ve kterém bude swap a /. Podle dokumentace jsem začal s tímto:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
# initialize and partitioning
clearpart --all --initlabel
part raid.11    --size=256      --asprimary  --ondrive=sda
part raid.12    --size=1 --grow              --ondrive=sda
part raid.21    --size=256      --asprimary  --ondrive=sdb
part raid.22    --size=1 --grow              --ondrive=sdb
 
# RAID
raid /boot      --fstype ext4   --device md0    --level=RAID1 raid.11 raid.21
raid pv.01      --fstype ext4   --device md1    --level=RAID1 raid.12 raid.22
 
# LVM
volgroup sysvol pv.01
logvol swap     --vgname=sysvol --fstype=swap   --size=8192        --name=swap
logvol /        --vgname=sysvol --fstype=ext4   --size=1 --grow    --name=root

Což skončilo chybou výše zmíněnou, která je už samozřejmě nahlášená v Bugzille. Po chvilce pročítání problému jsem zjistil, že Anaconda ignoruje parametr --grow a nedokáže si velikost disku vypočítat. Bere tak velikost oddílu pro LVM jako 1MB; a tam se 8GB, které tam cpeme pro swap nevejde. Heuréka.

Dočasné řešení (dokud nevyjde CentOS s aktualizovanou instalačkou) je tedy používat velikost raid oddílu větší než je součet logických svazků (např.: 9000 > 8192 + 1):

3
4
5
6
part raid.11    --size=256      --asprimary  --ondrive=sda
part raid.12    --size=9000 --grow           --ondrive=sdapart raid.21    --size=256      --asprimary  --ondrive=sdb
part raid.22    --size=9000 --grow           --ondrive=sdb

Red Hat Certified System Administrator

Dobrá věc se podařila a už jsem RHCSA. Najdete mě pod čílem 111-122-990.

Red Hat Certified System Administrator logo

Napadlo mě, že bych mohl, v případě, že si najdu čas (a byl by zájem), zde na blogu publikovat "jak na to" k jednotlivým okruhům (a spojit to třeba s kategorií "Základy administrátora"). Ještě si to nechám projít hlavou; nějaké poznámky můžete zatím najít na samotné speciální stránce

Fedora 15 & systemd: co zdržuje bootování

Chcete-li si zkontrolovat, co nejdéle trvá při startu vašeho systému a podle toho si bootování odladit, použijte utilitku systemd-analyze. Jedná se (nejen) o náhradu Bootchart, který jste mohli znát z klasického startu pomocí init. A co systemd-analyze umí?

Používám nijak neodladěný systém na notebooku, proto nabíhání chvilku chvilku trvá (cca 31 sekund), což mě ale díky bezvadně funkčnímu uspávání nebolí. Michal Schmidt na Fedora 15 Release Party ukázal, že po úpravách zkrouhnul boot na cca 3 sekundy.

Čas:

$ systemd-analyze time
Startup finished in 1433ms (kernel) + 15086ms (initrd) + 21817ms (userspace) = 38337ms

Textový výpis:

$ systemd-analyze blame
  6452ms udev-settle.service
  6153ms systemd-vconsole-setup.service
  4699ms fedora-readonly.service
  4416ms fedora-sysinit-hack.service
  3752ms media.mount
  3644ms remount-rootfs.service
  3585ms systemd-remount-api-vfs.service
  3112ms hwclock-load.service
  2922ms systemd-sysctl.service
 (...)

Grafický výstup:

Vygeneruje grafický svg výstup, který není nepodobný výstupu z výše zmíněného bootchart.

$ systemd-analyze plot > ~/plot.svg

systemd-analyze plot