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;

Četl jsem na idnes článek o koncertním turné U2 a říkal jsem si že bych se mohl snad na nějaký koncert dostat. No nelenil jsem a našel si nejbližší rozumný termín a místo (18.7. Berlin). A na eventim.de objednal a zaplatil lístky. Lístky mělo doručit DHL. Mám s nima dobré zkušenosti, balíky z USA většinou doručí velmi rychle(max týden, déle jsem snad nikdy nečekal).

Tentokrát se jim ale povedlo mojí zásilku poslat na druhý konec světa

5618969XXX – Detailed Report

Date Time Location Service Area Checkpoint Details
July 02, 2009 17:31 Bremen – Germany Shipment picked up
July 02, 2009 17:41 Bremen – Germany Departing origin
July 02, 2009 17:46 Bremen – Germany Processed at Bremen – Germany
July 02, 2009 19:55 Bremen – Germany Departed from DHL facility in Bremen – Germany
July 02, 2009 23:38 Leipzig – Germany Arrived at DHL facility in Leipzig – Germany
July 03, 2009 00:08 Leipzig – Germany Processed at Leipzig – Germany
July 03, 2009 03:57 Leipzig – Germany Departed from DHL facility in Leipzig – Germany
July 03, 2009 04:24 London-Heathrow – UK Transferred through London-Heathrow – UK
July 03, 2009 04:27 London-Heathrow – UK Departed from DHL facility in London-Heathrow – UK
July 03, 2009 07:10 London-Heathrow – UK Arrived at DHL facility in London-Heathrow – UK
July 03, 2009 07:58 London-Heathrow – UK Transferred through London-Heathrow – UK
July 03, 2009 07:59 London-Heathrow – UK Departed from DHL facility in London-Heathrow – UK
July 03, 2009 17:51 Barbados – Barbados Arrived at DHL facility in Barbados – Barbados
July 03, 2009 18:43 Barbados – Barbados Transferred through Barbados – Barbados
July 03, 2009 18:45 Barbados – Barbados Departed from DHL facility in Barbados – Barbados
July 04, 2009 00:19 Maiquetia – Venezuela Transferred through Maiquetia – Venezuela
July 04, 2009 00:20 Maiquetia – Venezuela Departed from DHL facility in Maiquetia – Venezuela
July 04, 2009 01:29 Panama City – Panama Arrived at DHL facility in Panama City – Panama
July 04, 2009 08:59 Miami, FL – USA Arrived at DHL facility in Miami, FL – USA
July 05, 2009 10:42 Wilmington – USA Processed at Wilmington – USA
July 05, 2009 10:42 Wilmington – USA Transferred through Wilmington – USA
July 08, 2009 07:27 Prague – Czech Republic, The Processed at Prague – Czech Republic, The
July 08, 2009 08:34 Prague – Czech Republic, The Departed from DHL facility in Prague – Czech Republic, The
July 08, 2009 09:29 Prague – Czech Republic, The Arrived at DHL facility
July 08, 2009 09:57 Prague – Czech Republic, The With delivery courier
July 08, 2009 11:47 Prague – Czech Republic, The Delivery attempted; recipient not home
July 08, 2009 23:15 Prague – Czech Republic, The Shipment delivered

Jakmile se lístky ocitli na Barbadosu bylo jasné, že je to špatně. 7.6 odpoledne jsem zavolal do DHL co s tím jsou schopni dělat, že bych byl rád aby zásilka do konce týdne dorazila.Slečna na druhé straně přislíbila že na 99% zásilka bude a možná i dříve.

Byl jsem docela překvapený, že za ani ne 24 hodinách mi volala z DHL že proběhl první pokus o doručení. Kurýra jsem si přeobjednal na 23.00 a už mám lískty doma

Koncert vypadá podle youtube videii fakt dobře….

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

Poslední dobou pořád více narážím na administrátory, kteří moc na politiku hesel a zabezpečení serverů nedbají, což je taky jeden z důvodů proč je pořád víc a víc spamu.

Pokud spammer potřebuje odeslat spoustu mailů, má v zásadě jenom pár možností.

• Má vlastní botnet (X tisíc hackutých počítačů) pod kontrolou.
• Použije nějaké nezabezpečené weby a spam pošle přes php či jiný scriptovací jazyk.
• Zjistí jméno + heslo k účtům na Vašem(a X dalších) mailserverů a pošle spam přes vás.

Pokud se Vám stala třetí možnost, musíte dohledat jaký účet byl prolomen a tomu změnit heslo.
Typicky se zkoušejí kombinace jako admin/admin, user/user, info/info, marketing/marketing, admin,admin123456 ..atp

Abyste mohli spammera dohledat v logu, hledej informaci jako “AUTH LOGIN” ci “AUTH CRAM-MD5″ za tím následuje uživatelské jméno a heslo.Obojí je enkodováno do base64, takže budete potřebovat nějaký dekodér – např pspad nebo nějaký webový http://www.opinionatedgeek.com/dotnet/tools/Base64Decode/

Celá enkodovaná SMTP session s autentizací.

123.123.123.123 [0158] 06:09:14 <<< AUTH LOGIN
123.123.123.123 [0158] 06:09:14 >>> 334 VXNlcm5hbWU6
123.123.123.123 [0158] 06:09:14 <<< dXNlckBleGFtcGxlLm9yZw==
123.123.123.123 [0158] 06:09:14 >>> 334 UGFzc3dvcmQ6
123.123.123.123 [0158] 06:09:14 <<< c29tZXBhc3N3b3Jk
123.123.123.123 [0158] 06:09:14 >>> 235 2.0.0 Authentication successful
123.123.123.123 [0158] 06:09:14 <<< MAIL FROM: <user@example.org>
123.123.123.123 [0158] 06:09:14 >>> 250 2.1.0 <user@example.org>… Sender ok
123.123.123.123 [0158] 06:09:14 <<< RCPT TO: <otheruser@somedomain.com>
123.123.123.123 [0158] 06:09:14 >>> 250 2.1.5 <otheruser@somedomain.com>… Recipient ok; will forward

Celá dekodovaná SMTP session s autentizací.

123.123.123.123 [0158] 06:09:14 <<< AUTH LOGIN
123.123.123.123 [0158] 06:09:14 >>> 334 Username:
123.123.123.123 [0158] 06:09:14 <<< user@example.org
123.123.123.123 [0158] 06:09:14 >>> 334 Password:
123.123.123.123 [0158] 06:09:14 <<< somepass
123.123.123.123 [0158] 06:09:14 >>> 235 2.0.0 Authentication successful
123.123.123.123 [0158] 06:09:14 <<< MAIL FROM: <user@example.org>
123.123.123.123 [0158] 06:09:14 >>> 250 2.1.0 <user@example.org>… Sender ok
123.123.123.123 [0158] 06:09:14 <<< RCPT TO: <otheruser@somedomain.com>
123.123.123.123 [0158] 06:09:14 >>> 250 2.1.5 <otheruser@somedomain.com>… Recipient ok; will forward

Pak již stačí jenom změnit heslo, odstranit Vaší ip z dnsbl serverů, snadno zjistíte např na http://www.dnsbl.info

Lepší než tohle řešit je tomu předcházet.

• Zapněte politiku hesel a vyžadujde heslo minimálně o délce 6 znaků s tím že jeden z nich bude číslo
• Apelujte na uživatele ať si volí složitá hesla
• Zapněte expiraci hesel, např každých 6 měsíců
• Sledujte velikost fronty na Vašem mailserveru a nechte se notifikovat smskou nebo mailem, pokud tam bude např 100 mailů k odeslání

bluedot.cz~# mysql -u admin -p
Enter password:
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 795395
Server version: 5.0.32-Debian_7etch6-log Debian etch distribution

Type ‘help;’ or ‘\h’ for help. Type ‘\c’ to clear the buffer.

mysql> create database db;
Query OK, 1 row affected (0.00 sec)

mysql> grant all privileges on db.* to db@localhost identified by ’somepassword’;
Query OK, 0 rows affected (0.11 sec)

mysql> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.08 sec)

mysql>

Jenom v krátkosti.

- Desně nacpaný metra
- Dost drahé město jak na dopravu, stravu tak i na bydlení
- Spousta wifi sítí
- Málo kešek
- Mnoho umění, muzeií.

Co stojí za vidění.
Eiffelovka, Parc de la Villette, Mona lisa v Louvre, Notre-Dame

Kliknětě a zjistíte to

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