Monitoring Linux Software Raid with Nagios

Udgivet den oktober 26, 2012 af mike

Download the check_md_raid script (http://exchange.nagios.org/directory/Plugins/Uncategorized/Operating-Systems/Linux/check_md_raid/details and upload it to the server you want to monitor in the following location:

root@nagios ~/plugins # scp check_md_raid root@backup:/usr/lib/nagios/plugins/
root@backup's password: 
check_md_raid                                                                 100%  782     0.8KB/s   00:00

Rediger nrpe.cfg på den maskine du ønsker at overvåge:

root@backup /etc/nagios # vim nrpe.cfg

og tilføj flg. linie:

command[check_md]=/usr/lib/nagios/plugins/check_md_raid

og genstart nrpe

root@backup ~ # /etc/init.d/nagios-nrpe-server restart
Stopping nagios-nrpe: nagios-nrpe.
Starting nagios-nrpe: nagios-nrpe.

Inden vi går videre vil jeg lige tjekke at det virker:

root@nagios ~ # /usr/lib/nagios/plugins/check_nrpe -H backup -c check_md
OK - Checked 3 arrays.

Så langt så godt, det virker jo. Derefter skal vi tilføje en service definition for vores md-tjek på nagios serveren, således at tjekket fremover kører automatisk:

root@nagios ~ # vi /etc/nagios-plugins/config/nrpe.cfg

og tilføjer flg:

define command{
        command_name    check_md
        command_line    /usr/lib/nagios/plugins/check_nrpe -H '$HOSTADDRESS$' -c check_md -u # -w 30
}

og til sidst:

root@nagios ~ # vi /etc/nagios/conf.d/backup3.cfg

og tilføj:

define service{
        use                     generic-service  
        host_name               backup 
        service_description     Software Raid
        check_command           check_md
        }

Genstart nagios:

root@nagios ~ # /etc/init.d/nagios3 restart
Restarting nagios3 monitoring daemon: nagios3
.

og på webinterfacet kan jeg nu se at testen er kørt, med success:

Hvis nu det var første gang jeg lavede det her ville jeg selvfølgelig gå ud og hive et par diske ud af maskinen og se hvad der skete, så det bør du selvfølgelig også gøre så du ved hvordan det opfører sig i tilfælde af et reelt nedbrud.

Men jeg stoler på det her, for jeg har testet det mange gange før, så jeg stopper her 😉

Udgivet i Knowledge Base, Linux, Networking, Old Base | Skriv en kommentar

Synkronisering af filer i et cluster med Csync2

Udgivet den oktober 20, 2012 af mike

Jeg har tidligere brugt GlusterFS til den slags, men Gluster er en af de tunge drenge … særligt når vi har med web-content o.l. at gøre, desuden vil jeg gerne udnytte det at jeg har flere diske at sende data fra fuldt ud, derfor har jeg eksperimenteret lidt med Csync2 som er et bidirektionelt filsynkroniserings værktøj.

Det er brugbart til f.eks. at holde et webdir i sync på tværs over et cluster, men det er ikke statefull nok til at holde nogen former for dynamiske data, det tager typisk et til fem minutter fra en fil rammer disken på en node før den når de andre.

Jeg vil designe et system med to noder og bagefter vil jeg så tilføje en tredie node for yderligere redundans.

Først installerer jeg csync2 på begge maskiner:

root@node1:~# apt-get -y install openbsd-inetd csync2
root@node2:~# apt-get -y install openbsd-inetd csync2

Rediger filen /etc/csync2.cfg, på node1, den er typisk helt tom og skal skrives fra bunden. Min ser således ud:

group cluster
{
         host node1;
         host node2;

         key /etc/csync2_ssl_cert.key;
         include /var/www;

         auto none;
}

File skal være ens på begge noder, ligesom du skal huske at oprette /var/www

root@node1:~# mkdir /var/www
root@node2:~# mkdir /var/www

I /etc/hosts på begge maskiner sætter du dine servere op således:

192.168.10.11 node1.cluster.com  node1
192.168.10.12 node2.cluster.com  node2

Dette skyldes at csync2 skal kunne nå de andre server blot ved deres short-name “node1”. Nu skal der oprette SSL Certifikater, det er næsten automatiseret, følgende skal gøres påkun den ene node, angiv ikke “common” name og ligeledes skal der ikke angive password, blot tryk enter. Dernæst skal filerne distribueres til de andre maskiner:

root@node1:~# csync2 -k /etc/csync2.key
root@node1:~# openssl genrsa -out /etc/csync2_ssl_key.pem 1024
root@node1:~# openssl req -new -key /etc/csync2_ssl_key.pem -out /etc/csync2_ssl_cert.csr
root@node1:~# openssl x509 -req -days 600 -in /etc/csync2_ssl_cert.csr -signkey /etc/csync2_ssl_key.pem -out /etc/csync2_ssl_cert.pem

Kopier nøglerne og onfig over på den anden node:

root@nod12:~# scp /etc/csync2* root@node2:/etc

Hvis der ligger nogle filer i e af mapperne bør du kopierer dem inden du går videre:

scp -r /var/www/* root@node2:/var/www

Dernæst skal Csync2 køres løbende, det koster ikke vildt mange resourcer at køre og derfor er der, såfremt dit directory ikke er for stort, intet problem i at køre hvert 5. minut. Jeg har prøvet en gang med en million filer, det tog 3 minutter at løbe igennem. Jeg vil dog her til mine tests have den endnu navere og sætter den derfor til at købe hvert minut:

root@node1:~# crontab -e
*/5 * * * *     /usr/sbin/csync2 -x
root@node2:~# crontab -e
*/5 * * * *     /usr/sbin/csync2 -x

Genstart nu inetd på begge maskiner:

root@node1:~# /etc/init.d/openbsd-inetd restart
root@node2:~# /etc/init.d/openbsd-inetd restart

Og så er det tid til at teste:

root@node1:/var/www# watch ls -l

Og så opretter vi nogle filer på den anden node:

root@node2:/var/www# touch test_a.txt
root@node2:/var/www# touch test_b.txt

Og vente så et par min og se dine nye filer komme til syne i det andet vindue 🙂

Udgivet i Knowledge Base, Linux, Old Base | Skriv en kommentar

Logging af ./mysql queries til en tekst-fil

Udgivet den oktober 17, 2012 af mike

Det er ikke rocket science, man det er rart at have ved hånden når man har brug for det 😉

mysql> tee /tmp/dump.log
Logging to file '/tmp/dump.log'
mysql> show processlist;
+-------+----------+-----------+----------+---------+------+-------+------------------+
| Id    | User     | Host      | db       | Command | Time | State | Info             |
+-------+----------+-----------+----------+---------+------+-------+------------------+
| 11348 | ndoutils | localhost | ndoutils | Sleep   |    0 |       | NULL             |
| 11350 | root     | localhost | NULL     | Query   |    0 | NULL  | show processlist |
+-------+----------+-----------+----------+---------+------+-------+------------------+
2 rows in set (0.00 sec)

og:

root@nagios ~ # cat /tmp/dump.log 
mysql> show processlist;
+-------+----------+-----------+----------+---------+------+-------+------------------+
| Id    | User     | Host      | db       | Command | Time | State | Info             |
+-------+----------+-----------+----------+---------+------+-------+------------------+
| 11348 | ndoutils | localhost | ndoutils | Sleep   |    0 |       | NULL             |
| 11350 | root     | localhost | NULL     | Query   |    0 | NULL  | show processlist |
+-------+----------+-----------+----------+---------+------+-------+------------------+
2 rows in set (0.00 sec)

mysql> quit

😀

Hvis du er lidt glemsom og gerne vil have en reminder til hvilke queries du har fyret af:

# cat /root/.mysql_history 
tee /tmp/dump.log
show processlist;

Hvis du har brug for et lidt mere struktureret udtræk, så er her et andet blogindlæg, “Save MySQL query results into a text or CSV file”! ( http://www.tech-recipes.com/rx/1475/save-mysql-query-results-into-a-text-or-csv-file/ )

Udgivet i Knowledge Base, Linux, Old Base, SQL | Skriv en kommentar

Central styring af flere maskiner i et cluster (SSH Pubkey’s + Bash Script)

Udgivet den oktober 10, 2012 af mike

Når man administrere flere maskiner kan det ofte være nødvendigt at scripte sig ud af nogle opgaver, og der kan være behov for at disse scripts skal logge ind på andre servere automatisk, men derudover kan du også bruge SSH nøgler til selv at logge ind med. Det er meget brugt i professionelle UNIX miljøer, primært fordi det er nemt, men sikkerheden er faktisk også højere.

Typisk vil man sætte passphrase på sin private-key hvis man bruger den interaktivt, men i det her eksempel gør vi det, netop fordi vi vil kunne bruge det i vores scripts.

Jeg er ved at skrive en artikel til DKUUG hvori vi bygger et redundant hosting setup, og derfor er jeg igang med at sætte et cluster op i mit lab. Maskinerne hedder:

* Master.lab.mikjaer.com
* Vps1.lab.mikjaer.com
* Vps2.lab.mikjaer.com
* Vps3.lab.mikjaer.com

Master serveren skal have adgang til at udføre kommandoer på vps1-vps3, derfor starter vi med at logge ind på vps1, og oprette en nøgle:

root@master:~# ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/root/.ssh/id_rsa): <enter>
Created directory '/root/.ssh'.
Enter passphrase (empty for no passphrase): <enter>
Enter same passphrase again: <enter>
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:
cd:2f:21:73:1f:be:25:0a:71:db:5d:4f:bf:e6:8c:bf root@vps1
The key's randomart image is:
+--[ RSA 2048]----+
|                 |
|                 |
|                 |
|         o       |
|        S * .   o|
|         * B o oo|
|        . o * o o|
|         . o +o..|
|          . ..+E.|
+-----------------+

Nu kan root@master.lab.mikjaer.com’s hhv. offentlige og private nøgle ses i /root/.ssh

root@master:~# ls -l /root/.ssh/
total 8
-rw------- 1 root root 1679 Oct 10 12:23 id_rsa
-rw-r--r-- 1 root root  391 Oct 10 12:23 id_rsa.pub

og vi skal nu have indholdet af id_rsa.pub over på de andre maskiner og lægge dem i filen /root/.ssh/authorized_keys hvormed vi giver rettighed til at personer eller maskiner der anvender “id_rsa” som nøgle, til at logge ind som root på destinationsmaskinen.

Såfremt at lab1-3 er nyinstalleret, hvilket de er i dette tilfælde, kan nøglen installeres således: (gentages selvsagt for hver vps)

root@master:~# cat /root/.ssh/id_rsa.pub | ssh root@vps3.lab.mikjaer.com mkdir /root/.ssh \&\& cat \>/root/.ssh/authorized_keys
The authenticity of host 'vps3.lab.mikjaer.com (109.202.159.63)' can't be established.
RSA key fingerprint is 41:26:9c:3d:3f:a6:1e:8b:e5:35:84:a0:81:47:a6:bc.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'vps3.lab.mikjaer.com,109.202.159.63' (RSA) to the list of known hosts.
root@vps3.lab.mikjaer.com's password:

For at teste kan vi lige hurtigt køre:

root@master:~# ssh root@vps3.lab.mikjaer.com uptime
 12:43:47 up 14 min,  0 users,  load average: 0.00, 0.00, 0.00

og se at det virker 😉

Sidste skridt er nu at installere mit cluster-script på master serveren, så vi nemt kan sende den samme kommando til alle serverne i clusteret:

root@master:~# ssh root@vps3.lab.mikjaer.com uptime
 12:43:47 up 14 min,  0 users,  load average: 0.00, 0.00, 0.00
#!/bin/bash

NODES="vps1.lab.mikjaer.com vps2.lab.mikjaer.com vps3.lab.mikjaer.com"

help ()
{
        echo "Copyright (c) 2004-2012 Mikjaer ApS, released as it under the BSD License"
        echo ""
        echo Usage: ./cluster.sh do \[command\]
        exit -1
}

docmd ()
{
        for f in $NODES
        do
                echo $f:
                ssh -t root@$f "${*}"
        done
}

if [ -z $1 ] ; then
        help
fi

if [ $1 = "do" ]; then
        docmd "${*:2}"
else
        help
fi

Scriptet er måske lidt overkill, men tilgengæld er der plads til at man kan udvide det med flere funktioner.Gem scriptet som cluster.sh og tester scriptet:

root@master:~# chmod 755 cluster.sh 
root@master:~# ./cluster.sh do uptime
vps1.lab.mikjaer.com:
 12:54:49 up 1 min,  0 users,  load average: 0.00, 0.00, 0.00
vps2.lab.mikjaer.com:
 12:54:49 up 1 min,  0 users,  load average: 0.00, 0.00, 0.00
vps3.lab.mikjaer.com:
 12:54:49 up 1 min,  0 users,  load average: 0.00, 0.00, 0.00

Et andet lækker lille twist er at hvis udelukkende vi bruger den her kommando til at administrere clusteret med nu kan vi faktisk lave en retsvisende log over hvilke kommandoer der har kørt på det:

#!/bin/bash

NODES="vps1.lab.mikjaer.com vps2.lab.mikjaer.com vps3.lab.mikjaer.com"

help ()
{
        echo "Copyright (c) 2004-2012 Mikjaer ApS, all rights reserved"
        echo ""
        echo Usage: ./cluster.sh do \[command\]
        exit -1
}

docmd ()
{
        for f in $NODES
        do
                echo $f:
                ssh -t root@$f "${*}" | tee output.tmp
        done

        echo `date` : ${*} : `cat output.tmp` >> cluster.log
        rm output.tmp
}

if [ -z $1 ] ; then
        help
fi

if [ $1 = "do" ]; then
        docmd "${*:2}"
else
        help
fi

Det ser sådan her ud:

root@master:~# cat cluster.log 
Wed Oct 10 12:59:48 UTC 2012 : uptime : 12:59:48 up 6 min, 0 users, load average: 0.00, 0.00, 0.00
Wed Oct 10 13:00:01 UTC 2012 : uptime : 13:00:01 up 6 min, 0 users, load average: 0.00, 0.00, 0.00

😉

Udgivet i Knowledge Base, Linux, Old Base | Skriv en kommentar

Sikring af SSH på Debian vha. DenyHost

Udgivet den oktober 8, 2012 af mike

DenyHost er et lille program der kører i baggrunden og holder øje med hvor mange mislykkedes ssh forsøg maskinen modtaget, og hvis den modtager for mange fra den samme IP Adresse blokeres denne adresse simpelthen.

Det er ikke særligt svært at sætte op, men nu sider jeg og skal installere det på en lang række maskiner så jeg tænkte at jeg lige ville bruge lejligheden til at få skrevet et blogindlæg om det 😉

Først:

# apt-get install denyhosts

og nu virker det faktisk, lad os teste:

# ssh lab01.mikjaer.com
lab01:~# ssh server -l root
root@server's password: 
Permission denied, please try again.
root@server's password: 
Permission denied, please try again.
root@server's password: 
Permission denied (publickey,password).
lab01:~# ssh server -l root
root@server's password: 
Permission denied, please try again.
root@server's password: 
Permission denied, please try again.
root@server's password: 
Permission denied (publickey,password).
lab01:~# ssh server -l root
ssh_exchange_identification: Connection closed by remote host

Efter relativt få forsøg bliver forbindelsen blokeret og vi får ikke længere lov at forsøge os frem, så langt så godt, men jeg kunne godt tænke mig at blive informeret når det sker, derfor retter jeg i /etc/denyhosts.conf: (Tilpas flg. værdier)

ADMIN_EMAIL = root@localhost
SMTP_HOST = smtp.eksempel.dk
SMTP_FROM = DenyHosts <nobody@server>

Herefter:

# /etc/init.d/denyhosts restart

Gentag nu ovenstående test (slet ip adressen på din server i /etc/hosts.deny for at fjerne den tidligere opnåede spærring). Det skulle gerne resultere i en mail som denne:

Added the following hosts to /etc/hosts.deny:

208.254.58.144 (mobismtp.vls-global.com)
218.77.120.142 (unknown)
209.165.131.61 (osscszibscnvm-2.gci.net)
109.75.21.200 (as1.navacom.de)
77.76.109.119 (77-76-109-119.static.unassigned.as8607.net)
93.189.94.179 (pixeliastudio.siliconpeople.net)
116.58.221.96 (116-58-221-96.net-infinity.net)
1.234.20.21 (unknown)
192.168.0.212 (lab1.mikjaer.com)

Det sidste, men absolut ikke ubetydelige, er muligheden for at synkronisere dine indstillinger med denyhost’s egen database over angrebsadresser, rediger igen /etc/denyhosts.conf, og udkommenter flg. linie:

SYNC_SERVER = http://xmlrpc.denyhosts.net:9911

Playing the waiting game … hvis du går ud og laver en kop kaffe og venter 10-20 minutter, så kan du i /var/log/denyhosts se noget lign.:

2012-10-08 22:47:46,188 - sync        : INFO     sent 2 new hosts
2012-10-08 22:47:46,188 - sync        : ERROR    [Errno 2] No such file or directory: '/var/lib/denyhosts/sync-timestamp'
2012-10-08 22:47:46,526 - sync        : INFO     received 0 new hosts

Hvilket viser at kommunikation med sync-serveren fungerer, og du kan nu tjekke indholdet af /var/lib/denyhosts/sync-timestamp og konkludere at filen nu ér oprettet, og dermed ikke er “Not found” næste gang sync kører.

Lidt senere:

2012-10-08 22:52:47,171 - sync        : INFO     received 20 new hosts
2012-10-08 22:52:47,172 - denyhosts   : INFO     received new hosts: ['175.184.20.235', '180.153.148.20', '61.155.178.242', '117.21.208.26', '222.68.193.150', '50.63.141.243', '159.226.43.35', '115.124.104.71', '199.201.126.83', '75.117.157.193', '212.250.207.123', '183.203.15.239', '81.169.170.213', '190.146.233.184', '88.191.123.49', '182.140.140.7', '12.43.112.222', '122.155.7.225', '202.117.3.104', '94.142.233.169']

Evt. verificer i /etc/hosts.deny at ip adresserne er oprettet i filen, det er den hos mig.

Ergo virker det!

Nu har du ikke blot taget et vigtigt skridt for at sikre dig selv, men også hjulpet til med at beskytte andre ved automatisk at indmelde angrebsforsøg til de centrale servere.

En sidste ting du kan gøre, hvis du vil undgå at risikere at lukke dig selv ude er at whiteliste din egen ip adresse, tilføj flg. til /etc/hosts.allow:

ALL: 10.20.30.40

Happy hacking 😉

Udgivet i Knowledge Base, Linux, Networking, Old Base | Skriv en kommentar

Fjernmapning af netværk

Udgivet den september 22, 2012 af mike

Jeg har fået en opgave hos en kunde hvor kunden ikke har styr på hvilke servere der sider i hvilke stik i switchen i sit datacenter, hvilket vi har behov for hvis vi skal kunne løse opgaven, derfor kommer det til at foregå remote.

Switchen på stedet er en DLINK DGS-12010-48

telnet x.x.x.x
Trying x.x.x.x...
Connected to x.x.x.x.
Escape character is '^]'.
DGS-1210-48 login: admin
Password: 

DGS-1210-48>

Det er en semi-intilligent switch, udemærket til access switch, dog lidt begrænset i funktioner, men hvis ikke man har behovet er det jo ligemeget. Heldigvis kan den give os svar på hvilke mac adresser der sider i hvilke porte, havde switchen været et nummer størrere ville jeg have forventet at den også kunne gøre det på IP Niveau, men here we goes:

DGS-1210-48> debug info
% sgementation fault log file :

File doesn't exist !!! 
% ARP table : 

Address          Hardware Address   Type  Interface  Mapping  
-------          ----------------   ----  ---------  -------  
10.0.0.1    00:00:5e:00:01:0a  ARPA  vlanMgmt   Dynamic   
10.0.0.2    5c:5e:ab:d2:ea:f0  ARPA  vlanMgmt   Dynamic   
10.0.0.3    f8:c0:01:18:ea:f0  ARPA  vlanMgmt   Dynamic   
10.0.0.23   00:1b:78:2e:a1:b0  ARPA  vlanMgmt   Dynamic   
10.0.0.25   00:1f:29:c5:10:22  ARPA  vlanMgmt   Dynamic   
10.0.0.32   00:1b:78:2e:a1:b0  ARPA  vlanMgmt   Dynamic   

% MAC table : 

Vlan    Mac Address         Type     Ports
----    -----------         ----     -----
1       00:00:5e:00:01:0a   Learnt   Gi0/48   
1       00:0c:29:0a:bc:4a   Learnt   Gi0/1    
1       00:0c:29:17:0e:d5   Learnt   Gi0/1    
1       00:0c:29:43:17:a7   Learnt   Gi0/1    
1       00:0c:29:49:e6:8e   Learnt   Gi0/1    
1       00:0c:29:77:43:8c   Learnt   Gi0/1    
1       00:0c:29:88:96:73   Learnt   Gi0/1    
1       00:0c:29:88:96:7d   Learnt   Gi0/1    
1       00:0c:29:93:42:af   Learnt   Gi0/1    
1       00:0c:29:ad:4d:9f   Learnt   Gi0/1    
1       00:0c:29:b5:42:84   Learnt   Gi0/1    
1       00:0c:29:b5:b1:21   Learnt   Gi0/1    
1       00:0c:29:b8:25:44   Learnt   Gi0/1    
1       00:0c:29:ca:a2:9b   Learnt   Gi0/1    
1       00:0c:29:e4:e7:4a   Learnt   Gi0/1    
1       00:0c:29:ed:23:26   Learnt   Gi0/1    
1       00:16:3e:00:00:11   Learnt   Gi0/5    
1       00:16:3e:02:74:63   Learnt   Gi0/5    
1       00:16:3e:3e:ec:db   Learnt   Gi0/5    
1       00:16:3e:3e:ec:dc   Learnt   Gi0/5    
1       00:16:3e:3e:ec:dd   Learnt   Gi0/5    
1       00:16:3e:3e:ec:dd   Learnt   Gi0/5    
1       00:16:3e:3e:ec:de   Learnt   Gi0/5    
1       00:1b:78:2e:a1:b0   Learnt   Gi0/48   
1       00:1b:78:35:1a:fc   Learnt   Gi0/7    
1       00:1b:78:96:8f:6e   Learnt   Gi0/9    
1       00:1b:78:96:8f:70   Learnt   Gi0/23   
1       00:1b:78:9b:43:0c   Learnt   Gi0/21   
1       00:1b:78:9c:0f:50   Learnt   Gi0/48   
1       00:1c:c4:5e:32:1c   Learnt   Gi0/48   
1       00:1c:c4:5e:32:1e   Learnt   Gi0/48   
1       00:1e:4f:03:51:cc   Learnt   Gi0/48   
1       00:1f:29:c5:10:22   Learnt   Gi0/3    
1       00:1f:29:c5:b3:fa   Learnt   Gi0/19   
1       00:26:2d:00:5f:aa   Learnt   Gi0/5    
1       00:c0:b7:22:0b:44   Learnt   Gi0/48   
1       00:c0:b7:7e:5c:6b   Learnt   Gi0/46   
1       2a:60:bc:5a:bc:6a   Learnt   Gi0/3    
1       46:b9:f9:dc:a5:01   Learnt   Gi0/3    
1       5c:5e:ab:d2:ea:f0   Learnt   Gi0/48   
1       5e:0a:2e:dc:f7:15   Learnt   Gi0/48   
1       6e:08:07:9e:47:c0   Learnt   Gi0/3    
1       7e:af:a6:d5:79:63   Learnt   Gi0/3    
1       98:4b:e1:0b:15:c4   Learnt   Gi0/1    
1       98:4b:e1:0b:15:cc   Learnt   Gi0/17   
1       9e:b6:b0:3e:0c:3a   Learnt   Gi0/3    
1       b8:a3:86:82:f6:f7   Learnt   Gi0/48   
1       f8:c0:01:18:ea:f0   Learnt   Gi0/48   

Total Mac Addresses displayed: 47

Som du kan se er der en fin liste over hvilke MAC adresser der kan nåes igennem hvilke porte, og jeg har tænkt mig at bruge en lokal servers arp tabel til at koble dem sammen med nogle ip adresser og den vej igennem finde ud af hvilke maskiner der sider i hvilke porte

Udgivet i Knowledge Base, Networking, Old Base | Skriv en kommentar

Bonding af Interfaces

Udgivet den august 25, 2012 af mike

Som en del af en opgave fra en kunde skal jeg sætte en Cisco Switch og nogle servere op med hver 4x1GBit netkort, dvs. vi skal til at bonde interfaces på både Cisco’en og Debian maskinen, og da det gik op for mig at jeg ikke har skrevet særlig mange indlæg om netværk så syntes jeg det var passende at lave et blogindlæg om det.

Mit første skridt var at køre en baseline test mellem tre maskiner via ét interface, bare for at have styr på hvor meget/lidt vi kan smide igennem, jeg installerede iperf på begge maskiner:

# apt-get install iperf

Og satte en af maskinerne op som server:

root@a:~# ifconfig intl0 10.0.0.2 up
root@a:~# iperf  -s -B 10.0.0.2

Og fyrede en test af ved samtidig at udføre flg. kommando på begge maskiner: (hvis du skal bruge talene til at dokumentere noget for nogen er du selvfølgelig nødt til at automatisere den del)

root@b:~# iperf -t 60 -i 5 -c 10.0.0.2
root@c:~# iperf -t 60 -i 5 -c 10.0.0.2

Resultatet, aflæst på serveren:

[  4] local 10.0.1.1 port 5001 connected with 10.0.1.3 port 52463
[  5] local 10.0.1.1 port 5001 connected with 10.0.1.2 port 38061
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  3.40 GBytes    486 Mbits/sec
[  5]  0.0-60.0 sec  3.21 GBytes    460 Mbits/sec

Afslører et samlet throughput på 946Mbit/sec hvilket er ganske udemærket for et 1000Mbit/sec netkort, det vi opnår med bonding er at switchen sender hver forbindelse gennem hver sit netkort.

Nu vil jeg prøve at sætte et bond op på min server:

# apt-get install ifenslave-2.6

Derefter flg. opsætning i /etc/network/interfaces:

auto bond0
iface bond0 inet static
        address 10.0.1.1
        netmask 255.255.255.0
        slaves intl0 intl1
        mtu 1500
        bond_xmit_hash_policy layer2+3
        bond_lacp_rate slow
        bond-mode 802.3ad
        bond-miimon 100
        bond-downdelay 200
        bond-updelay 200

Derefter skal din switch opsættes til at tillade 802.3ad / Link Aggregation Control Protocol (LACP), på min kundes Cisco Switch gøres det således:

Switch#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
Switch#interface range GigabitEthernet 0/37, gigabitEthernet 0/38
Switch#channel-group 1 mode active
Switch(config-if-range)#end

Så up’er jeg interfacet på serveren: (alle interfaces der indgår i bondet skal være down inden du up’er bondet)

root@a# ifup bond0

Og hvis du tjekker på switchen nu (evt. skal du vente på at switch-portene kommer op, alt. afh. din opsætning) kan du se at linket er oppe:

Switch#show interfaces port-channel 1 | include line protocol
Port-channel1 is up, line protocol is up (connected)

Igen starter jeg iperf på serveren og lader den lytte på bondet’s ip:

root@a# iperf  -s -B 10.0.1.1
------------------------------------------------------------
Server listening on TCP port 5001
Binding to local address 10.0.1.1
TCP window size: 85.3 KByte (default)
------------------------------------------------------------

og på to af maskinerne starter jeg, igen samtidig, en klient. Hvilket efter et lille minutstid afslører at begge mine klienter uden problemer henter med i snit 941Mbit/sec hver.

[  4] local 10.0.1.1 port 5001 connected with 10.0.1.2 port 46741
[  5] local 10.0.1.1 port 5001 connected with 10.0.1.3 port 52468
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  6.58 GBytes    941 Mbits/sec
[  5]  0.0-60.0 sec  6.58 GBytes    941 Mbits/sec

Altså alt i alt 1882Mbit/s … lad os se hvad der sker hvis vi gentager eksperimentet fra 3 maskiner:

[  4] local 10.0.1.1 port 5001 connected with 10.0.1.4 port 53140
[  5] local 10.0.1.1 port 5001 connected with 10.0.1.2 port 46742
[  6] local 10.0.1.1 port 5001 connected with 10.0.1.3 port 52469
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  3.44 GBytes    493 Mbits/sec
[  5]  0.0-60.0 sec  3.16 GBytes    453 Mbits/sec
[  6]  0.0-60.0 sec  6.57 GBytes    940 Mbits/sec

Igen lander vi på omkring 1800Mbit/s, og vi kan se at to af vores forbindelser har fået lov at dele det ene netkort mens den tredie har fået frit spil, det viser os, som forventet, at vi ikke kan “dele” en forbindelse op over flere netkort, men vi kan fordele forbindelserne mellem de forskellige netkort.

LACP med 4 Porte

Vi har fået besked på at bonde alle 4 porte i serverne, så det gør vi her:

I /etc/network/interfaces tilføjer jeg de sidste netkort:

slaves intl0 intl1 intl2 intl3

og kører:

# ifdown bond0 && ifup bond0

og på switchen:

Switch#conf t
Switch(config)#interface range GigabitEthernet 0/31, GigabitEthernet 0/32, GigabitEthernet 0/33, GigabitEthernet 0/34
Switch(config-if-range)#channel-group 2 mode active
Switch(config-if-range)#end

Desværre har jeg kun 3 testmaskiner til rådighed, med testen herfra giver også et ret konsistent mønster:

root@a:~# iperf -s
------------------------------------------------------------
Server listening on TCP port 5001
TCP window size: 85.3 KByte (default)
------------------------------------------------------------
[  4] local 10.0.1.1 port 5001 connected with 10.0.1.2 port 35807
[  5] local 10.0.1.1 port 5001 connected with 10.0.1.10 port 38533
[  6] local 10.0.1.1 port 5001 connected with 10.0.1.3 port 52477
[ ID] Interval       Transfer     Bandwidth
[  4]  0.0-60.0 sec  6.58 GBytes    941 Mbits/sec
[  5]  0.0-60.0 sec  6.58 GBytes    941 Mbits/sec
[  6]  0.0-60.0 sec  6.58 GBytes    941 Mbits/sec

Jeg tør næsten væde med at når vi får en 4. maskine på og teste med så får vi 941Mbit/sec mere igennem 😉

Håber du kan bruge det her til noget.

Udgivet i Knowledge Base, Linux, Networking, Old Base | Skriv en kommentar

Lav din egen webbrowser på 15 minutter

Udgivet den august 17, 2012 af mike

Tidligere idag skulle jeg genstarte vores skærm på væggen (en skærm der for det meste viser at alle vores servere, kunder, køleanlæg, switche og mailkøer har det godt) fordi den længe havde været lidt langsom til at opdatere, det viste sig efterfølgende at den var 4-5 minutter om at starte Firefox, et hurtigt kig på top viste at den var begyndt at swappe helt vildt … hvilket selvfølgelig giver fornuftig mening taget i betragtning at den kun har 512mb ram og kører både apache og nogle forskellige værktøjer til at streame lyd.

Nuvel, det endte ud med at jeg flækkede en webbrowser sammen med Webkit i Python, det tog 15-20 min at få til at spille, først:

apt-get install python-webkit

Derefter opretter jeg filen browser.py i mit homedir:

#!/usr/bin/env python

import gtk, webkit

window = gtk.Window()
window.set_position(gtk.WIN_POS_CENTER)
window.set_size_request(1024,768)

browser = webkit.WebView()
browser.open("http://www.eksempel.dk");
window.add(browser);

window.show_all()

gtk.main()

Vores maskine er skjult bag en reol hvor der hverken sider mus eller keyboard på, så jeg arbejdede på den via ssh, derfor skulle jeg lige sætte DISPLAY variablen, og selvfølgelig tildele execute rettighed på scriptet:

# export DISPLAY=localhost:0
# chmod 755 browser.py 
# ./browser.py

Webkit understøtter Javascript og vores dashboard kører faktisk hurtigere på webkit end i Firefox, og den starter på 1-2 sekunder nu og kører i fuldskærm uden at blinke … noget vi havde store problemer med at få Firefox til. 🙂

Udgivet i Knowledge Base, Linux, Networking | Skriv en kommentar

MySQL multimaster replikation med Galera

Udgivet den juli 26, 2012 af mike

Multimaster replikation er når en eller flere database servere er koblet sammen og ændringer på en vilkårlig maskine effektueres på samtlige. Metoden beskrevet i dette indlæg er basseret på en tredieparts patch til MySQL og jeg vil demonstrere hvordan man laver det simplest mulige setup, nemlig et setup hvor vi kun benytter to servere.

Først starter jeg med mine to nyinstallerede maskiner lab1.mikjaer.com og lab2.mikjaer.com og installere lidt software på dem begge:

wget https://launchpad.net/codership-mysql/0.8/0.8.2/+download/mysql-server-wsrep-5.1.57-0.8.2-amd64.deb
wget https://code.launchpad.net/galera/0.8/0.8.2/+download/galera-0.8.2-amd64.deb

apt-get -y install libdbi-perl libdbd-mysql-perl mysql-client-5.1 libmysqlclient16 mysql-common libplrpc-perl libnet-daemon-perl vim

dpkg -i galera-0.8.2-amd64.deb mysql-server-wsrep-5.1.57-0.8.2-amd64.deb

Derefter starter vi begge MySQL servere og laver nogle basale adgangsindstillinger før vi starter replikatoren:

/etc/init.d/mysql start

/usr/bin/mysql_secure_installation   

mysql -pPASSWORD -e "SET wsrep_on = OFF; grant all on *.* to 'root'@'%' identified by 'PASSWORD';"

/etc/init.d/mysql stop

Efter kommando nr 2 bliver du guidet igennem MySQL opsætningen, husk og vælg et sikkert password, brug det samme på begge maskiner og anvend samme pasword i kommando nr 3 istedet for de to steder hvor der står PASSWORD.

Nu skal vi ha MySQL til at lytte på internettet efter indkomne forbindelser, rediger /etc/mysql/my.cnf og kommenter flg. linie ud (det betyder at sætte et #-mærke i starten af linie):

bind-address           = 127.0.0.1

Du kan evt. teste forbindelsen, du skal fra en prompt på lab1 kunne forbinde til lab2 og vica versa:

root@lab1:~# mysql -pPASSWORD -h lab2.mikjaer.com -e "select 5+5\G"
*************************** 1. row ***************************
5+5: 10
root@lab2:~# mysql -pPASSWORD -h lab1.mikjaer.com -e "select 5+5\G"
*************************** 1. row ***************************
5+5: 10

Som du kan se virkede det udemærket, og vi kan nu gå videre med at sætte replikering op, stop mysql på begge servere:

root@lab1:~# /etc/init.d/mysql stop
root@lab2:~# /etc/init.d/mysql stop

Derefter redigerer du /etc/mysql/conf.d/wsrep.cnf og sætter flg. værdier ind de rigtige steder (de er spredt lidt ned igennem filen)

wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_sst_auth=root:PASSWORD

og på den første server(lab1), i samme fil:

wsrep_cluster_address="gcomm://"

og på den anden(lab2):

wsrep_cluster_address="gcomm://192.168.0.10"

Her er det selvfølgelig lab1’s ip adresse jeg har brugt, slutteligt starter jeg begge servere igen:

root@lab1:~# /etc/init.d/mysql start
Starting MySQL database server: mysqld.
root@lab2:~# /etc/init.d/mysql start
Starting MySQL database server: mysqld.

Herefter skulle replikering gerne køre, her er testen fra mit test-setup:

root@lab1:~# mysql -pPASSWORD -e "show databases";
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
+--------------------+
root@lab2:~# mysql -pPASSWORD -e "create database foobar;";
root@lab1:~# mysql -pPASSWORD -e "show databases";
+--------------------+
| Database           |
+--------------------+
| information_schema |
| foobar             |
| mysql              |
+--------------------+
root@lab1:~# mysql -pPASSWORD -e "create database foobar2;";
root@lab2:~# mysql -pPASSWORD -e "show databases";
+--------------------+
| Database           |
+--------------------+
| information_schema |
| foobar             |
| foobar2            |
| mysql              |
+--------------------+

Et klassisk “ingen-ting-her-ingen-ting-der-scenario” 😉

Håber i kan bruge det … og hvis i overvejer at smide det i produktion så læs lige manualen først 🙂

Udgivet i Knowledge Base, Linux, Old Base, SQL | Skriv en kommentar

MySQL multimaster replikation med Galera

Udgivet den juli 26, 2012 af Brian Lund Klint 
Multimaster replikation er når en eller flere database servere er koblet sammen og ændringer på en vilkårlig maskine effektueres på samtlige. Metoden beskrevet i dette indlæg er basseret på en tredieparts patch til MySQL og jeg vil demonstrere hvordan man laver det simplest mulige setup, nemlig et setup hvor vi kun benytter to servere.

Først starter jeg med mine to nyinstallerede maskiner lab1.mikjaer.com og lab2.mikjaer.com og installere lidt software på dem begge:


wget https://launchpad.net/codership-mysql/0.8/0.8.2/+download/mysql-server-wsrep-5.1.57-0.8.2-amd64.deb
wget https://code.launchpad.net/galera/0.8/0.8.2/+download/galera-0.8.2-amd64.deb

apt-get -y install libdbi-perl libdbd-mysql-perl mysql-client-5.1 libmysqlclient16 mysql-common libplrpc-perl libnet-daemon-perl vim

dpkg -i galera-0.8.2-amd64.deb mysql-server-wsrep-5.1.57-0.8.2-amd64.deb
 Derefter starter vi begge MySQL servere og laver nogle basale adgangsindstillinger før vi starter replikatoren: 
/etc/init.d/mysql start

/usr/bin/mysql_secure_installation   

mysql -pPASSWORD -e "SET wsrep_on = OFF; grant all on *.* to 'root'@'%' identified by 'PASSWORD';"

/etc/init.d/mysql stop
 Efter kommando nr 2 bliver du guidet igennem MySQL opsætningen, husk og vælg et sikkert password, brug det samme på begge maskiner og anvend samme pasword i kommando nr 3 istedet for de to steder hvor der står PASSWORD. Nu skal vi ha MySQL til at lytte på internettet efter indkomne forbindelser, rediger /etc/mysql/my.cnf og kommenter flg. linie ud (det betyder at sætte et #-mærke i starten af linie): 
bind-address           = 127.0.0.1
 Du kan evt. teste forbindelsen, du skal fra en prompt på lab1 kunne forbinde til lab2 og vica versa: 
root@lab1:~# mysql -pPASSWORD -h lab2.mikjaer.com -e "select 5+5\G"
*************************** 1. row ***************************
5+5: 10
root@lab2:~# mysql -pPASSWORD -h lab1.mikjaer.com -e "select 5+5\G"
*************************** 1. row ***************************
5+5: 10
 Som du kan se virkede det udemærket, og vi kan nu gå videre med at sætte replikering op, stop mysql på begge servere: 
root@lab1:~# /etc/init.d/mysql stop
root@lab2:~# /etc/init.d/mysql stop
 Derefter redigerer du /etc/mysql/conf.d/wsrep.cnf og sætter flg. værdier ind de rigtige steder (de er spredt lidt ned igennem filen) 
wsrep_provider=/usr/lib/galera/libgalera_smm.so
wsrep_sst_auth=root:PASSWORD
 og på den første server(lab1), i samme fil: 
wsrep_cluster_address="gcomm://"
 og på den anden(lab2): 
wsrep_cluster_address="gcomm://192.168.0.10"
 Her er det selvfølgelig lab1's ip adresse jeg har brugt, slutteligt starter jeg begge servere igen: 
root@lab1:~# /etc/init.d/mysql start
Starting MySQL database server: mysqld.
root@lab2:~# /etc/init.d/mysql start
Starting MySQL database server: mysqld.
 Herefter skulle replikering gerne køre, her er testen fra mit test-setup: 
root@lab1:~# mysql -pPASSWORD -e "show databases";
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
+--------------------+
root@lab2:~# mysql -pPASSWORD -e "create database foobar;";
root@lab1:~# mysql -pPASSWORD -e "show databases";
+--------------------+
| Database           |
+--------------------+
| information_schema |
| foobar             |
| mysql              |
+--------------------+
root@lab1:~# mysql -pPASSWORD -e "create database foobar2;";
root@lab2:~# mysql -pPASSWORD -e "show databases";
+--------------------+
| Database           |
+--------------------+
| information_schema |
| foobar             |
| foobar2            |
| mysql              |
+--------------------+
 Et klassisk "ingen-ting-her-ingen-ting-der-scenario" ;-) Håber i kan bruge det ... og hvis i overvejer at smide det i produktion så læs lige manualen først :-)
Udgivet i Knowledge Base, Mysql | Skriv en kommentar