mdadm –create /dev/md123 -l1 -n1 /dev/sdc1 –force

Je to snadne kdyz vite co s tim
Dopisu clanek, ale ted to mam jenom na interni poznamky…

1 – switche musi mit povoleny multicast nebo se nikam nehnete
2 – jednodussi nez resit switche je pouzit jeden HB kabel

#formatovani gfs pro vyuziti 3 serveru

mkfs.gfs2 -p lock_dlm -t nazevclusteru:icwgfs -j 3 -J 20 /dev/msvg/icwlv

http://comments.gmane.org/gmane.linux.redhat.cluster/18009

#pro fencing je lepsi pouzit standartni ipmi nez specialitky fence_drac ci fence_drac5 kde jsou bugy

<fencedevice agent=”fence_ipmilan” auth=”md5″ ipaddr=”192.168.xxx.xxx” login=”admin” name=”idrac1″ passwd=”adminpassword”/>

CREATE DATABASE nazevdb CHARACTER SET utf8 COLLATE utf8_czech_ci;

Obnoveni ze zalohy pomoci rdiff-backup je prakticky stejne jako na linuxu.

#obnoveni celeho stromu backup

rdiff-backup.exe –restore-as-of now z:\zaloha c:\rozbalena_zaloha

#Obnoveni nektere casti – vsimnete si tech obracenych lomitek (ano, je to dulezite)

rdiff-backup.exe –restore-as-of 1D z:/zaloha/adresar1/adresar2/adresar3 c:/rozbalena_zaloha2

Pokud se pokusite pouzit zpetne lomitko skoncite s chybou

rdiff-backup.exe –restore-as-of 1D “z:\zaloha\adresar1\adresar2\adresar3 c:\rozbalena_zaloha
Fatal Error: Wrong number of arguments given.
See the rdiff-backup manual page for more information.

nebo s touhle chybou…

Fatal Error: Could not find rdiff-backup repository at z:\zaloha\adresar1\adresar2\adresar3

Jestliže potřebujete překopírovat 100GB dat po síti máte v zásadě tyhle možnosti.

• Zabalit data lokálně, přes FTP či SSH překopírovat a rozbalit.
• Nainstalovat rsync a překopírovat data
• Rozchodit NFS
• Použít tar a překopírovat data přes SSH se zabalením onfly

Věnovat se budu tomu posledně zmiňovanému, což se hodí v případech kdy nemáte na lokálním disku dostatek místa. Abyste mohli script spustit na pozadí, je potřeba nejdříve vygenerovat SSH klíč.

bluedot.cz:/# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/root/.ssh/id_dsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /root/.ssh/id_dsa.
Your public key has been saved in /root/.ssh/id_dsa.pub.
The key fingerprint is:
f3:a2:5d:27:57:50:21:72:53:d6:51:54:c5:ba:c9:01 root@hostname

Překopírujte soubor /root/.ssh/id_dsa.pub na server kam potřebujete data překopírovat.

bluedot.cz:/# scp /root/.ssh/id_dsa.pub root@vzdaleny_server:/root

Na vzdáleném serveru přidejte klíč do authorized_keys

vzdaleny_server:/# cat /root/id_dsa.pub >> /root/.ssh/authorized_keys

Náledující uložte jako copy.sh (kopíruje /home z aktuálního serveru na vzdaleny_server do /home2copy)

#!/bin/bash

tar -zcvf – /home | ssh root@vzdaleny_server tar -C /home2copy -zxf -

Spusťte a čekejte

nohup ./copy.sh &

V jakém je kopírování stavu zjistíte pomocí

tail nohup.out či tail -f nohup.out

I když máte data na raid1 poli, může dojít k tomu že Vám jeden disk vypadne a než stihnene dojet do servrovny s novým diskem a sesynchronizovat znovu pole umře Vám i druhý disk..

Teď máte tři možnosti:

• Vyhodíte data co tam byla a neřešíte to.
• Obnovíte data ze zálohy.
• Obnovíte data přímo z poškozených disků.

Jsou situace kdy jsou první dvě možnosti nepřijatelné a musíte data nějak z těch disků dostat. Já to řeším takhle.
Disk který vypadl z pole jako první je pravděpodobně více poškozen(dejme tomu že je to sda), tak ten si dám někam mimo pro případ, že se mi data z druhého disku(sdb) nepovede dostat abych měl případně zálohu, kterou můžu odvézt nějaké specializované firmě.

A jdeme obnovovat.

1. Pokuste se stanovit co s tím diskem je, tzn jestli ho vidí bios nebo v něm netypicky cvaká…atp
2. Pokud disk vidí bios jedná většinou o softwarový problém nebo lehčí poškození ploten.
3. Nabootujte z rescue CD nebo z nějaké liveCD s linuxem a zkuste poškozenou parcelu připojit do systému v readonly režimu
   

   mount -o ro,nouuid /dev/sdb1 /mnt/poskozeny_disk

4. Jestli se disk připojil bez problému, pusťte smartctl test a data překopírujte jinam
5. Jeslit se disk nepřipojí, tak se v žádném případě nesnažte o opravu klasickými nástroji jako xfs_check a xfs_repair (záleží na použitém filesystému)
6. Nainstalujte si dd_rescue
   

   apt-get install dd_rescue

7. Překopírujte kompletní image disku na nějaký nový disk- trvá to pár hodin, podle velikosti disku a míře poškození.
   

   dd_rescue /dev/sdb1 /mnt/sdc1/sda1.img

8. Opravte poškozený přímo toho .img souboru
   

   xfs_repair /mnt/sdc1/sda1.img

9. Připojte image do systému.
   

   mount -o loop,ro,nouuid /mnt/sdc1/sda1.img /mnt/poskozeny_sda1

10. Pokud proběhlo vše OK, máte svoje data;)

Celé tohle řešení má ale i své nevýhody.

• Výpadek v řádu několika hodin.
• V případě že se Vám obnova nepovede, obnova bude ve specializované firmě dost drahá.

Nainstalovat a spravovat linuxový server zvládne každé béčko, kvalita administrátora se ukáže až ve chvíli kdy přijdou problémy s výkonem neb případnými výpadky. Obecně lze každý tento problém řešit dvěmi cestami :

Cesta první, na první pohled jednodušší = Peníze.
Nestíhá Vám server, no co koupíte nový, přemigrujete data a můžete se vrátit ke své oblíbené činnosti.Ano, momentální problém to pravděpodobně vyřeší. Pokud ale budete po šéfovi chtít peníze na nový server každé dva měsíce, tak Vás asi brzo vykopne.

Cesta druhá, složitější = Optimalizace
Jako první je potřeba zjistit, kde je problém. Modelová situace, máte webový server na kterém beží následující služby :
apache 2.x, php5.2.x, mysql5.x, mailserver s uživateli v mysql,ftp s ssl.

Přehled otevřených portů

21/tcp open ftp
22/tcp open ssh
25/tcp open smtp
80/tcp open http
110/tcp open pop3
143/tcp open imap
993/tcp open imaps
995/tcp open pop3s
3306/tcp open mysql

Všechny data jsou uložena na sw raid1 poli, postaveném ze dvou 250gb sata disků wd-re.
Uživatelé si stežují že jim některé weby jedou pomalu, hlavně ty co používají mysql.

Vyhledejte co dělá problémy,
1 – zkontrolujte jestli Vám jeden disk nevypadl z pole
2 – zapněte logování špatně napsaných dotazů v my.cnf
3 – v apache2.conf zapněte server-status a kontrolujte requesty
4 – přes iostat -x 1 monitorujte stav disků
5 – zkontrolujte výkyvy v návštěvnosti webů, umístěných na serveru.
Co může zbůsobit takovýhle náhlý pokles výkonu ?

Například jedno phpbb fórum v defaultní instalaci bez antispamové ochrany.

Pokud jste na nic nepřišli aplikujte první cestu, kupte nové disky(nebo nový server, to je na Vás.) a přesuňte na ně mysql databáze.

Postfix – celá fronta

 postsuper -d ALL

Postfix – vybranou část podle odesílatele či příjemce

#!/bin/bash

# $7=odesilatel, $8=prijemce

mailq | tail +2 | grep -v ‘^ *(’ | awk ‘BEGIN { RS = “” }
{ if ($7 == “user@example.com”) print $1 } ‘ | tr -d ‘*!’ | postsuper -d

Pro qmail použijte projekt QmHandle

Qmail – smazat celou frontu

./qmHandle -D

Qmail - smazat jen část fronty podle předmětu

 ./qmHandle -S text predmetu

Dneska ráno jsem potřeboval otestovat mailbox, který se choval jinak při vybírání přes IMAP a
jinak při výběru přes POP3. Na vině byla nakonec quota.

Ve windows spustíte telnet přes Start -> Spustit -> telnet

Otevřeme spojení

 open

Zadejte pop3 server se kterým se chcete spojit i s číslem portu

 bluedot.cz 110

Objeví se hlášení o spojení

+OK dovecot ready

Nyní už můžete zadávat příkazy.
Nejdříve uživatelské jméno a heslo. Po každém zadání Vám POP3 server vrátí buď +OK  nebo nějakou chybu.

USER uzivatelske jmeno
PASS heslo

Nyní jste už v mailboxu (pokud tedy nedošlo k nějaké chybě)

STAT  - odpovědí je počet zpráv a velikost v bytech
LIST - seznam všech emailů
RETR 3 - zobrazí email s pořadovým číslem 3
DELE 3  - smaže email s pořadovým číslem 3
QUIT - ukončí spojení s email serverem.

Další info o pop3 najdete ve wikipedii nebo přímo v RFC1939

U všech serverů se hodí vědět kolik celkem proteklo dat přes kterou síťovou kartu.
K počítání přenesených dat používám vnstat.

V debianu snadno nainstalujete příkazem

apt-get install vnstat

A vytvoříte databázi pro síťovou kartu.

vnstat -u -i eth0

Stačí počkat 5 minut a máte k dipozici první údaje.
Příklad měsíčních přenosů na tomto serveru.

bluedot:~# vnstat -m
eth0

month rx | tx | total
————————+—————+—————
Aug ‘06 33,459 MB | 159,718 MB | 193,177 MB
Sep ‘06 30,545 MB | 128,827 MB | 159,373 MB
Oct ‘06 34,168 MB | 197,330 MB | 231,499 MB
Nov ‘06 31,311 MB | 271,926 MB | 303,237 MB
Dec ‘06 31,921 MB | 291,091 MB | 323,013 MB
Jan ‘07 26,313 MB | 198,691 MB | 225,005 MB
Feb ‘07 56,194 MB | 276,093 MB | 332,287 MB
Mar ‘07 32,034 MB | 217,255 MB | 249,289 MB
Apr ‘07 38,956 MB | 243,583 MB | 282,539 MB
May ‘07 39,967 MB | 231,630 MB | 271,598 MB
Jun ‘07 34,139 MB | 189,878 MB | 224,018 MB
Jul ‘07 32,835 MB | 219,557 MB | 252,392 MB
————————+—————+—————
estimated 34,407 MB | 230,071 MB | 264,478 MB