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.