Mysql installieren und konfigurieren

,

Einleitung mysql

Mysql ist unter Linux neben postgres das am häufigsten genutzten Datenbank-Systeme. Mysql ist als Opensource Projekt im Jahr 1994 entstanden und gehört mittlerweile zu Oracle. Obwohl es zu mysql seit geraumer Zeit auch kommerzielle Angebote gibt, ist die Datenbank-Software mysql selbst immer noch ein Opensource-Produkt. Das bedeutet, daß es von jedermann herunter geladen und genutzt werden kann.

https://de.wikipedia.org/wiki/MySQL

Homepage: https://www.mysql.com/de/

Da es nach der Übernahme von Oracle jedoch zu Konflikten zwischen dem kommerziellen Anspruch und der Opensource-Gemeinde kam, hat sich im Jahr 2012 mit mariadb ein so genannter Fork (~Abspaltung) von mysql gebildet, der wieder vollkommen quelloffen entwickelt wird und so mehr dem Opensource Gedanken entspricht.

https://de.wikipedia.org/wiki/MariaDB

Homepage: https://mariadb.org/

Im nachfolgenden Tutorial erklären wir Schritt für Schritt die Installation von mariadb auf einem Linux-Server mit Centos sowie die Absicherung und Inbetriebnahme der Datenbank-Software.

Hinweis: Wir verwenden CentOS als Basis für unsere Installation. Mysql bzw. mariadb lassen sich aber genauso auf Debian, Ubuntu und praktisch allen anderen Linux-Servern mit dem jeweiligen Paketmanager installieren. Sobald die Erst-Installation unter Linux erledigt ist, können Sie diese Anleitung dennoch Schritt für Schritt abarbeiten.

Vorüberlegungen zu mysql

Wer mysql einfach mal so ausprobieren möchte, muss sich um Geschwindigkeit von Abfragen und Performance im Allgemeinen vermutlich keine Gedanken machen.

Sofern Sie allerdings mysql produktiv einsetzen möchten, so sollten wir einige wenige Gedanken über das System-Design machen.

Hauptspeicher / RAM

In Sachen Hauptspeicher (RAM) sind praktisch alle Datenbanksysteme extrem „hungrig“. Da macht mysql keine Ausnahme. Die generelle Regel lautet: Je mehr desto beser.

Festplatten

Wer seinen mysql Server auf einer dedizierten Hardware betreibt, der tut gut daran dem mysql Dienst eine separate Festplatte zuzuweisen. Ideal sind mehrere, eher kleine Festplatten, die über ein Raid10 (Verbund aus gespiegelten Platten) an einem RAID-Controller angeschlossen sind.

Wer mysql virtuell betreibt, der sollte zumindest das mysql-Datenverzeichnis /var/lib/mysql auf einer separaten Partition einrichten. Wie das geht, zeigen wir weiter unten.

 

Linux-Server vorbereiten

Zur Vorbereitung unserer mysql Installation deaktivieren wir zuerst temporär SELinux und schalten ebenfalls den eingebauten firewalld Dienst aus.

1
Mysql01# systemctl disable firewalld

In der Datei /etc/sysconfig/selinux ändern Sie die Zeile „SELINUX=enforcing“ auf „SELINUX=disabled“

Anschließend loggen wir uns per ssh auf dem Server an und aktualisieren alle Software-Pakete mit „yum –y update“. Das dauert je nach Hardware und Internetanbindung ein paar Minuten. Anschließend rebooten Sie den Server.

Mysql auf eine separate Partition bzw. Festplatte legen

Wer wie weiter oben angesprochen mysql bzw. mariadb produktiv einsetzen möchte, der sollte das Verzeichnis /var/lib/mysql auf ein separates Filesystem legen.

In unserem (virtuellen) Beispiel haben wir eine zweite Festplatte /dev/sdb erstellt.

Auf dieser erstellen wir mit fdisk /dev/sdb die neue Partition /dev/sdb1 und speichern fdisk mit „w“ ab.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@mysql01 ~]# fdisk /dev/sdb
Welcome to fdisk (util-linux 2.23.2).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.
Device does not contain a recognized partition table
Building a new DOS disklabel with disk identifier 0x8f093467.

Befehl (m für Hilfe): n
Partition type:
p   primary (0 primary, 0 extended, 4 free)
e   Erweiterte
Select (default p): p
Partitionsnummer (1-4, default 1): 1
Erster Sektor (2048-125829119, Vorgabe: 2048):
Benutze den Standardwert 2048
Last Sektor, +Sektoren or +size{K,M,G} (2048-125829119, Vorgabe: 125829119):
Benutze den Standardwert 125829119
Partition 1 of type Linux and of size 60 GiB is set

Befehl (m für Hilfe): w
Die Partitionstabelle wurde verändert!
Rufe ioctl() um Partitionstabelle neu einzulesen.
Synchronisiere Platten.

Anschließend formatieren wir die neue Partition z.B. mit dem xfs Filesystem

1
2
3
4
5
6
7
8
9
10
[root@mysql01 ~]# mkfs.xfs /dev/sdb1
meta-data=/dev/sdb1              isize=512    agcount=4, agsize=3932096 blks
=                       sectsz=512   attr=2, projid32bit=1
=                       crc=1        finobt=0, sparse=0
data     =                       bsize=4096   blocks=15728384, imaxpct=25
=                       sunit=0      swidth=0 blks
naming   =version 2              bsize=4096   ascii-ci=0 ftype=1
log      =Internes Protokoll     bsize=4096   blocks=7679, version=2
=                       sectsz=512   sunit=0 blks, lazy-count=1
realtime =keine                  extsz=4096   blocks=0, rtextents=0

Last but not least legen wir einen Eintrag in der /etc/fstab an, damit das zusätzliche Filesystem bei einem Reboot auch ordentlich gemounted wird, bevor der mariadb bzw. mysqld Dienst startet.

Ergänzen Sie die Datei /etc/fstab um die folgende Zeile

1
/dev/sdb1       /var/lib/mysql  xfs     defaults        0 0

Anschließend legen wir den notwendigen Mountpoint (Einhängepunkt für die Partition) noch manuell an und setzen die Berechtigungen:

1
2
[root@mysql01 ~]# mkdir /var/lib/mysql
[root@mysql01 lib]# chown –R mysql.mysql /var/lib/mysql/

Mysql unter Linux installieren

Die eigentliche Installation von mariadb (bzw. mysql) übernimmt der Befehl „yum install mariadb-server mariadb“. Im Schlepptau werden ca 2 Dutzend Perl-Pakete mit installiert.

1
[root@mysql01 ~]# yum –y install mariadb mariadb-server

Nun müssen wir den Dienst mariadb noch aktivieren und anschließend starten:

1
2
3
4
[root@mysql01 ~]# systemctl enable mariadb
Created symlink from /etc/systemd/system/multi-user.target.wants/mariadb.service to /usr/lib/systemd/system/mariadb.service.
[root@mysql01 ~]# service mariadb start
Redirecting to /bin/systemctl start mariadb.service

 

Erste Anmeldung an mariadb / mysql

Um nun „interaktiv“ zu prüfen ob mariadb wirklich funktioniert, loggen wir uns einmal als Benutzer root an mariadb an.

In der Standard-Installation ist der Benutzer „root“ in mariadb/mysql bereits angelegt. Ein Passwort hat der Benutzer (noch) nicht.

Syntax: mysql –u<Benutzer> -p<Passwort>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@mysql01 ~]# mysql -uroot
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 2
Server version: 5.5.56-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]&gt; show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test               |
+--------------------+
4 rows in set (0.00 sec)

MariaDB [(none)]&gt; exit

Der Befehl “show databases” zeigt uns die bestehenden Datenbanken an. Dies sind neben der Standard-Datenbank „mysql“ die Datenbanken „information_schema“ und „performance_schema“ sowie „test“.

mysql / mariadb absichern

Im Moment kann man sich noch ganz ohne Passwort an mysql anmelden. Ebenfalls sind Anmeldungen von entfernten Rechnern über das Netzwerk möglich. Das möchten wir dauerhaft so nicht belassen.

Ein Weg mysql auf einen Rutsch deutlich sicherer zu machen ist der Aufruf der Anpassungs-Routine „mysql_secure_installation“.

Mit diesem Skript können Sie

  • Ein Passwort für den Benutzer root setzen
  • Die Test-Datenbank entfernen
  • Den Zugriff über das Netzwerk unterbinden

Beantworten Sie einfach die gestellten Fragen mit y[es] oder n[o]. Nach Abschluss des Skripts wird die mysql-Datenbank, welche die Benutzer enthält neu geladen und Sie können sich mit ihrem gerade erstellten Passwort wieder anmelden.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
[root@mysql01 ~]# mysql_secure_installation

In order to log into MariaDB to secure it, we'll need the current
password for the root user.  If you've just installed MariaDB, and
you haven't set the root password yet, the password will be blank,
so you should just press enter here.

Enter current password for root (enter for none):
OK, successfully used password, moving on...

Setting the root password ensures that nobody can log into the MariaDB root user without the proper authorisation.

Set root password? [Y/n] y
New password:
Re-enter new password:
Password updated successfully!
Reloading privilege tables..
... Success!

By default, a MariaDB installation has an anonymous user, allowing anyone to log into MariaDB without having to have a user account created for them.  This is intended only for testing, and to make the installation go a bit smoother.  You should remove them before moving into a production environment.

Remove anonymous users? [Y/n] y
... Success!

Normally, root should only be allowed to connect from 'localhost'.  This ensures that someone cannot guess at the root password from the network.
Disallow root login remotely? [Y/n] y
... Success!

By default, MariaDB comes with a database named 'test' that anyone can access.  This is also intended only for testing, and should be removed before moving into a production environment.

Remove test database and access to it? [Y/n] y
- Dropping test database...
... Success!
- Removing privileges on test database...
... Success!

Reloading the privilege tables will ensure that all changes made so far will take effect immediately.

Reload privilege tables now? [Y/n] y
... Success!
Cleaning up...
All done!  If you've completed all of the above steps, your MariaDB installation should now be secure.
(…)

Wir prüfen  nun ob die Anmeldung als Benutzer root immer noch ohne Passwort möglich ist (Das sollte es nicht ,mehr sein).

1
2
[root@mysql01 ~]# mysql -uroot
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: NO)

Die Fehlermeldung ist ausnahmsweise einmal „positiv“ im Sinne von so gewollt. Dafür sollte die Anmeldung mit „mysql –uroot –p<ihr Passwort> klappen

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@mysql01 ~]# mysql -uroot -p
Enter password: ç hier Passwort eingeben
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 12
Server version: 5.5.56-MariaDB MariaDB Server
Copyright (c) 2000, 2017, Oracle, MariaDB Corporation Ab and others.
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
MariaDB [(none)]&gt; show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
+--------------------+
3 rows in set (0.00 sec)

Wir sehen: Die Anmeldung ist weiter mit Passwort möglich und außerdem ist die Datenbank „test“ ebenfalls verschwunden.

 

mysql / mariadb: Benutzer verwalten

Zwei administrative Aufgaben kommen beim Betrieb von mysql bzw. mariadb immer wieder vor: Neue Benutzer anlegen und von bestehenden Benutzern das Passwort zurücksetzen. Daneben gilt es „mal eben so“ eine neue Datenbank anzulegen.

Hinweis: Alle Beispiele gehen davon aus, daß Sie sich zuerst mit „mysql –uroot –p“ an mysql anmelden.

Eine neue (leere) Datenbank in mysql anlegen

Eine neue und leere Datenbank legen Sie mit dem Befehl „create database <DATENBANKNAME>;“ an.

Beispiel:

1
create database sbtest;

Der obige Befehlt erstellt die leere Datenbank „sbtest“.

Neuen Benutzer unter mysql anlegen

Die Syntax unter mysql zum Anlegen eines neuen Benutzers ist:

1
2
3
use mysql;
create user 'USERNAME'@'HOST' identified by 'PASSWORD';
flush privileges;

Username und Password ersetzen Sie mit dem echten Benutzer-Namen sowie einem möglichst sicheren Passwort. Mit „HOST“ ist dabei der Rechner gemeint, von dem aus der Anwender zugreifen darf.

Sofern hier nur der Zugriff über den Rechner erlaubt ist, auf dem mysql läuft, so verwenden Sie „localhost“ . Alternativ können Sie bei HOST auch eine IP-Adresse verwenden. Ebenso gehen normale Hostnamen, die sich über das DNS auflösen lassen.

Beispiel: Wir legen einen Benutzer mit Namen „max“ an, der von überall aus zugreifen darf. Sein Passwort lautet „Imitoguli835“.

1
2
3
use mysql;
create user 'max'@'*' identified by 'Imitoguli835';
flush privileges;

Auf Datenbanken zugreifen (dürfen)

Damit der frisch angelegte Benutzer auch das Recht hat, eine bestehende Datenbank zu bearbeiten, muss ihm mit dem „Grant“ Befehl dazu die Berechtigung erteilt werden. Die Syntax dazu lautet:

1
Grant ALL on DATABASE.TABLE TO 'USERNAME'@'HOST';

Beispiel: Wir gewähren dem Benutzer „Max“ den Zugriff auf die Datenbank „sbtest“ – aber nur wenn er sich über den mysql-Server anmeldet (also über den Localhost).

1
2
3
use mysql;
grant all on sbtest.* to 'max'@'localhost';
flush privileges;

Noch ein Beispiel: Wir gewähren unserem Testbenutzer „Max“ den Zugriff auf alle (!) Datenbanken, egal von wo aus er zugreift.

1
2
3
use mysql;
grant all on *.* to 'max'@'*';
flush privileges;

Der Befehl “flush privileges;“ schreibt alle Berechtigungen in mysql zurück und lädt die aktualisierten Berechtigungen neu. Erst danach greift das neue Rechtesystem für den gerade veränderten mysql-Benutzer.

Von einem bekannten mysql Benutzer das Passwort zurück setzen

Wenn ein Benutzer sein Passwort für mysql nicht mehr weiß, dann kann es der mysql-Administrator mit dem folgendem Befehl zurück setzen:

1
2
use mysql; update user set password=PASSWORD('NEUESPASSWORT') where User='BENUTZERNAME';
flush privileges;

Wichtig: ‚User‘ wird wirklich mit großem ‚U‘ geschrieben.

Die Begriffe „NEUESPASSWORT“ und „BENUTZERNAME“ ersetzen Sie natürlich durch ein wirklich sicheres Passwort und den echten Benutzernamen.

Mysql Benchmark

Um mysql nun ein wenig unter Last zu setzen, installieren wir den Benchmark-Test sysbench. Dafür benötigen wir allerdings zuerst das EPEL-Repository, das wir zuerst installieren.

1
2
yum –y install epel-release
yum -y install sysbench

Da sysbench eine Testdatenbank (die meistens sbtest heißt) benötigt legen wir die Datenbank „sbtest“ an und außerdem gleich einen passenden Benutzer „testdb“, der sich lokal auf dem Server an mariadb anmelden darf.

1
2
3
mysql –uroot –p –e "create database sbtest;"
mysql –uroot –p –e “grant all on sbtest.* to testdb@localhost identified by 'test123';"
mysql –uroot –p –e "flush privileges;"

Sysbench besteht in der Regel aus zwei aufeinaderfolgenden Aktionen. Im ersten Schritt (der mit ‚prepare‘ endet) werden die Tabellen und ggf. Inhalte angelegt, auf die beim eigentlichen Durchlauf des Benchmarks zugegriffen wird. Der eigentliche Benchmark-Befehlt endet auf „run“.

Was konkret wie geprüft und getestet wird, ist bei sysbench seit einiger Zeit in vordefinierten Skripten fest gelegt. Diese liegen nach der Installation von sysbench unter /usr/share/sysbench/ .

Beispiel:

Der nachfolgende erste Befehl bereitet die leere Datenbank sbtest mit 4 Tabellen vor.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
sysbench /usr/share/sysbench/oltp_common.lua  --threads=4 --mysql-host=localhost --mysql-user=testdb --mysql-password=test123 --mysql-port=3306 --tables=4 --db-driver=mysql  --table-size=100000 prepare
sysbench 1.0.9 (using system LuaJIT 2.0.4)
Initializing worker threads...
Creating table 'sbtest2'...
Creating table 'sbtest1'...
Creating table 'sbtest3'...
Creating table 'sbtest4'...
Inserting 100000 records into 'sbtest3'
Inserting 100000 records into 'sbtest1'
Inserting 100000 records into 'sbtest4'
Inserting 100000 records into 'sbtest2'
Creating a secondary index on 'sbtest1'...
Creating a secondary index on 'sbtest4'...
Creating a secondary index on 'sbtest2'...
Creating a secondary index on 'sbtest3'...

Der anschließende Aufruf startet den allgemeinen Lese/Schreiben Benchmark für 60 Sekunden und gibt alle 5 Sekunden eine Statistik aus.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
sysbench /usr/share/sysbench/oltp_read_write.lua --threads=4 --events=0 --time=60  --mysql-host=localhost --mysql-user=testdb --mysql-password=test123 --mysql-port=3306 --tables=4 --table-size=100000 --range_selects=off --db-driver=mysql --db-ps-mode=disable --report-interval=5 run
sysbench 1.0.9 (using system LuaJIT 2.0.4)
Running the test with following options:
Number of threads: 4
Report intermediate results every 5 second(s)
Initializing random number generator from current time
Initializing worker threads...
Threads started!
[ 5s ] thds: 4 tps: 164.51 qps: 2643.40 (r/w/o: 1653.13/432.57/557.71) lat (ms,95%): 95.81 err/s: 0.00 reconn/s: 0.00
[ 10s ] thds: 4 tps: 185.81 qps: 2973.73 (r/w/o: 1858.08/528.62/587.03) lat (ms,95%): 95.81 err/s: 0.00 reconn/s: 0.00
[ 15s ] thds: 4 tps: 257.17 qps: 4114.80 (r/w/o: 2571.75/764.93/778.12) lat (ms,95%): 58.92 err/s: 0.00 reconn/s: 0.00
[ 20s ] thds: 4 tps: 232.42 qps: 3718.67 (r/w/o: 2324.17/743.45/651.05) lat (ms,95%): 63.32 err/s: 0.00 reconn/s: 0.00
[ 25s ] thds: 4 tps: 256.43 qps: 4102.95 (r/w/o: 2564.34/850.91/687.69) lat (ms,95%): 55.82 err/s: 0.00 reconn/s: 0.00
[ 30s ] thds: 4 tps: 199.19 qps: 3185.91 (r/w/o: 1991.95/679.58/514.39) lat (ms,95%): 89.16 err/s: 0.00 reconn/s: 0.00
[ 35s ] thds: 4 tps: 237.75 qps: 3805.25 (r/w/o: 2377.53/823.84/603.88) lat (ms,95%): 62.19 err/s: 0.00 reconn/s: 0.00
[ 40s ] thds: 4 tps: 243.02 qps: 3888.26 (r/w/o: 2430.16/852.06/606.04) lat (ms,95%): 70.55 err/s: 0.00 reconn/s: 0.00
[ 45s ] thds: 4 tps: 234.79 qps: 3756.71 (r/w/o: 2347.94/830.78/577.99) lat (ms,95%): 63.32 err/s: 0.00 reconn/s: 0.00
[ 50s ] thds: 4 tps: 239.43 qps: 3830.93 (r/w/o: 2394.33/851.92/584.68) lat (ms,95%): 66.84 err/s: 0.00 reconn/s: 0.00
[ 55s ] thds: 4 tps: 276.78 qps: 4422.67 (r/w/o: 2763.79/995.93/662.95) lat (ms,95%): 51.94 err/s: 0.00 reconn/s: 0.00
[ 60s ] thds: 4 tps: 274.40 qps: 4396.27 (r/w/o: 2748.04/995.22/653.01) lat (ms,95%): 62.19 err/s: 0.00 reconn/s: 0.00

SQL statistics:
queries performed:
read:                            140130
write:                           46750
other:                           37328
total:                           224208
transactions:                        14013  (233.52 per sec.)
queries:                             224208 (3736.38 per sec.)
ignored errors:                      0      (0.00 per sec.)
reconnects:                          0      (0.00 per sec.)

General statistics:
total time:                          60.0050s
total number of events:              14013

Latency (ms):
min:                                  3.48
avg:                                 17.12
max:                                440.18
95th percentile:                     68.05
sum:                             239970.51

Threads fairness:
events (avg/stddev):           3503.2500/12.74
execution time (avg/stddev):   59.9926/0.00

Ein Hinweis zum Schluss: Wenn Sie mit sysbench einen gänzlich anderen Performance-Test durchführen wollen, so müssen Sie zuerst die Tabellen innerhalb der Datenbank sbtest löschen. Ansonsten erhalten Sie von sysbench eine Fehlermeldung.

Das Löschen der Tabellen erfolgt mit „drop table <tablename>;“. Schneller ist es aber die ganze Datenbank „sbtest“ zu löschen und anschließend leer wieder anzulegen.

1
2
Drop database sbtest;
Create database sbtest;

Fazit zu mysql

Die Installation und erste Einrichtung von mysql ist für geübte Linux-Administratoren in wenigen Minuten erledigt und auch für Gelegenheits-Admins kein Hexenwerk. Wer durch das Tutorial auf den Geschmack gekommen ist, der sollte sich ein wenig mehr mit dem Thema Performance von mysql bzw. mariadb beschäftigen.

Wie man die Konfigurations-Datei ( /etc/my.cnf ) anpasst und so mysql weiter optimiert, erklären wir in einem weiteren Tutorial.

Hochverfügbarkeit mit Pacemaker und Corosync

, ,

Einleitung: Hochverfügbarkeit mit Pacemaker und Corosync

Mit Pacemaker und Corosync können mehrere Linux-Hosts eine einfache Form der Hochverfügbarkeit (engl. High availability, kurz HA) erreichen. So können mit Pacemaker IP-Adresse, ganze Webserver oder auch File-Systeme hoch-verfügbar gemacht werden.

Anhand einer so genannten Service-IP-Adresse beschreiben wir nachfolgend das Prinzip von Pacemaker und Corosync. Pacemaker übernimmt dabei die Verwaltung der Cluster-Resourcen. Corosync kümmert sich um die Kommunikation zwischen den Hosts.

Auf diese Weise lassen sich zum Beispiel mit einer Master-Master-Replikation von mariadb/mysql hochverfügbare Datenbank-Lösungen erstellen. Mit der OpenSource-Software glusterfs lassen sich zusammen mit Pacemaker und Corosync ganze Dateisysteme als HA-Lösung konfigurieren.

Alle nachfolgend genutzten Software-Pakete (Centos, Pacemaker und Corosnyc) sind genauso wie maysql und mariadb OpenSource Produkte.

Versuchsaufbau für Corosync und HA

Für unser nachfolgendes Tutorial erstellen wir zwei identische Linux-Hosts mit CentOS die jeweils einen Netzwerkanschluss sowie eine eigene statische IPv4-Adresse im selben IP-Subnetz haben. Die Linux-Rechner sollen anschließend eine dritte IP-Adresse (nachfolgend Service-IP genannt) erhalten, die entweder auf dem einen oder dem anderen Linux-Server „gehostet“ wird.

Ziel ist es, diese Service-IP-Adresse immer erreichbar zu haben und dennoch einen der beiden Hosts für Wartungszwecke herunter fahren zu können. Auf diese Weise kann mit einfachen Mitteln eine einfache Form der Hochverfügbarkeit erreicht werden.

Hinweis: Auch wenn wir Pacemaker und Corosync hier exemplarisch unter Centos 7 einrichten, so geht das natürlich auch auf anderen Linux-Distributionen wie debian, Ubuntu oder Redhat . Hier unterscheiden sich lediglich die Kommandos für die Installation der Pakete (apt-get bei debian).

Unser Setup für das Pacemaker Tutorial:

  • 2 CentOS 7.5 Hosts mit je einer statischen IP-Adresse
  • Host 1: testdb01, 168.0.113
  • Host 2: testdb02, 168.0.114
  • Service-IP-Adresse: 168.0.115

Für alles weitere installieren wir CentOS 7.x (z.B. auf einer Vitualisierungsplattform wie VMWare oder Proxmox). Die Linux-Hosts benötigen im produktiven Betrieb 1-2 CPU-Kerne, 2 GB RAM und 20 -30 GB an Festplatte. Wer einfach nur testen will, kommt auch mit einem CPU-Kern, 1 GB RAM und 3-4 GB HDD aus.

Wir richten pro Host die statische IP-Adresse ein und lassen mit „yum-y update“ alle Updates durchlaufen. Für alles weitere deaktivieren wir den CentOS Firewalld (systemctl disable firewalld) und deaktivieren „selinux“ ( In der Datei /etc/sysconfig/selinux ersetzen Sie das die Zeile, die mit „SELINUX“ beginnt durch SELINUX=disabled )

Installation von Corosync bzw. Pacemaker

Die Softwarepakete pacemaker, pcs und corosync müssen unter Centos auf allen Hosts installiert werden die später Mitglieder des Clusters werden. Die Installation erledigen wir mit:

1
yum -y install pacemaker pcs

In der Standard-Version werden hier gleich ca 25-30 weitere anhängige Pakete mit installiert, die für den Betrieb notwendig sind. Im Anschluss daran aktivieren wir den pcsd Dienst und starten ihn:

1
2
systemctl enable pcsd.service
systemctl start pcsd.service

Damit die unterschiedlichen Hosts bzw. die Dienste auf den Hosts mit einander sprechen können, benötigen Sie einen Benutzer mit Kennwort. Während der Installation wird automatisch ein neuer User namens „hacluster“ angelegt: Diesem geben wir nun noch ein Passwort:

1
passwd hacluster

Achten Sie darauf, daß auf beiden Hosts das Passwort für den benutzer „hacluster“ nach Möglichkeit identisch ist

Cluster Dienst einrichten

Damit die Knoten miteinander kommunizieren können, tauschen wir nun erst einmal die Authentifizierungen aus:

1
2
3
4
5
[root@testdb01 mysql<strong>]# pcs cluster auth testdb01 testdb02</strong>
Username: hacluster
Password:
testdb01: Authorized
testdb02: Authorized

Die Meldung von beiden Knoten muss “Authorized” lauten – dann kommunizieren die Hosts erfolgreich miteinander.

Cluster – alte Pacemaker Konfiguration löschen

Zur Sicherheit „zerstören“ bzw. löschen wir alle bisherigen Konfigurationen auf den beiden Hosts.

Hinweis: Bei einer brandneuen Installation ist dieser Schritt nicht nötig.

1
2
3
4
5
6
[root@testdb01 mysql]# pcs cluster destroy --all
Warning: Unable to load CIB to get guest and remote nodes from it, those nodes will not be deconfigured.
testdb01: Stopping Cluster (pacemaker)...
testdb02: Stopping Cluster (pacemaker)...
testdb02: Successfully destroyed cluster
testdb01: Successfully destroyed cluster

Neues Pacemaker Cluster erstellen.

Nun erstellen wir in neues “Cluster” aus zwei Knoten bzw. Hosts. Die Hosts heißen bei uns „testdb01“ und „testdb02“. Das Cluster selbst nennen wir „testdb. Direkt nach dem Abschicken des Befehls „pcs cluster setup“ werden zuerst die Zertifikate ausgetauscht.

Voraussetzung ist, daß die beiden Hosts sich im vorherigen Schritt (pcs cluster auth) erfolgreich gegenseitig authentifiziert haben.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
[root@testdb01 ~]# pcs cluster setup --name testdb testdb01 testdb02
Destroying cluster on nodes: testdb01, testdb02...
testdb02: Stopping Cluster (pacemaker)...
testdb01: Stopping Cluster (pacemaker)...
testdb01: Successfully destroyed cluster
testdb02: Successfully destroyed cluster
Sending 'pacemaker_remote authkey' to 'testdb01', 'testdb02'
testdb01: successful distribution of the file 'pacemaker_remote authkey'
testdb02: successful distribution of the file 'pacemaker_remote authkey'
Sending cluster config files to the nodes...
testdb01: Succeeded
testdb02: Succeeded
Synchronizing pcsd certificates on nodes testdb01, testdb02...
testdb01: Success
testdb02: Success
Restarting pcsd on the nodes in order to reload the certificates...
testdb01: Success
testdb02: Success

Konfiguration von Corosync prüfen:

Zur Sicherheit werfen wir einen Blick in die nun auf beiden Hosts vorhandene Konfig-Datei unter /etc/corosync/. Sie heißt dort „corosync.conf“

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
[root@testdb01 ~]# more /etc/corosync/corosync.conf
totem {
version: 2
cluster_name: filecluster
secauth: off
transport: udpu
}
nodelist {
node {
ring0_addr: testdb01
nodeid: 1
}
node {
ring0_addr: testdb02
nodeid: 2
}
}
quorum {
provider: corosync_votequorum
two_node: 1
}
logging {
to_logfile: yes
logfile: /var/log/cluster/corosync.log
to_syslog: yes
}

Corosync Cluster starten

Mit dem Befehlt “pcs cluster start –all” starten wir auf einem Knoten corosync auf allen zum Cluster gehörenden Hosts.

Wichtig: Das muss nur an auf einem Host/Knoten erfolgen.

1
2
3
[root@testdb01 ~]# pcs cluster start --all
testdb02: Starting Cluster...
testdb01: Starting Cluster...

Corosync und Pacemaker aktivieren und starten

Damit wir nun etwas Praktisches tun können, müssen sowohl der corosync-Dienst als auch Pacemaker aktiviert und gestartet werden.

Auf testdb01 und testdb02 führen wir also aus

1
2
3
4
systemctl enable corosync.service
systemctl start corosync.service
systemctl enable pacemaker.service
service pacemaker start

Anschließend prüfen wir den Status mit “pcs status“. Nun sollte ‚pcs status‘ etwas sinnvolles ausgeben , auch wenn noch keine Resource vorhanden ist

1
2
3
4
5
6
7
8
9
10
11
12
13
14
[root@testdb01 ~]# pcs status
Cluster name: testdb
Stack: corosync
Current DC: testdb01 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Wed Jun 13 12:50:58 2018
Last change: Wed Jun 13 12:50:55 2018 by root via cibadmin on testdb01
2 nodes configured
0 resources configured
Online: [ testdb01 testdb02 ]
No resources
Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

Wir sehen: Auf dem Knoten testdb01 sind alle drei Dienste (corosync, pacemaker und pcsd) aktiv und gestartet. Der Hinweis „no resources“ bedeutet, daß wir noch keine Resource (etwa eine IP) definiert haben.

Corosync anpassen (2 Host Szenario)

In unserem Fall von 2 Hosts mach weder ein Quorum (die Mehrheit unter den Servern) noch Stonith (Mechanismus zum „Abschiessen“ von schwächelnden Hosts) inhaltlich Sinn. Für ein Quorum bräuchten wir mindestens 3 Hosts. Mit den beiden folgenden Befehlen stellen wir sowohl das Quorum als auch stonith dauerhaft ab.

1
2
pcs property set stonith-enabled=false
pcs property set no-quorum-policy=ignore

Virtuelle Resource / Virtuelle IP anlegen

Wir möchten nun eine einfache IPv4-Adresse als einzige Resource anlegen und auf einem der beiden Hosts verfügbar machen. Mit dem folgenden Befehl wird die Service-IP für das Cluster angelegt:

1
pcs resource create &lt;Resource-Name&gt; ocf:heartbeat:IPaddr2 ip=&lt;IP-Addr&gt; cidr_netmask=&lt;Netmask&gt; op monitor interval=5s

Die Variable <Resource-Name>, <IP-Addresse> und <Netmask> ersetzen wir natürlich durch die tatsächlichen Werte.

Wichtig hierbei: Die IP-Adresse muss zum Netzwerk bzw. IP-Subnetz passen, in dem der Hosts seinen Netzwerkanschluss hat.

Wir legen nun also eine zusätzliche IP-Adresse mit dem Namen „testdb-ip“, der Nummer 192.168.0.115 sowie der Netzmaske 24 (entspricht 255.255.255.0) an, die entweder auf testdb01 oder auf testdb02 gehostet wird. Sie soll außerdem vom Cluster alle 5 Sekunden geprüft werden.

1
[root@testdb01 ~]# pcs resource create testdb-ip ocf:heartbeat:IPaddr2 ip=192.168.0.115 cidr_netmask=24 op monitor interval=5s

Anschließend prüfen wir ob die IP-Adresse auch erfolgreich vom Cluster verwaltet wird:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[root@testdb01 ~]# pcs status
Cluster name: testdb
Stack: corosync
Current DC: testdb01 (version 1.1.18-11.el7_5.2-2b07d5c5a9) - partition with quorum
Last updated: Wed Jun 13 12:52:35 2018
Last change: Wed Jun 13 12:52:32 2018 by root via cibadmin on testdb01
2 nodes configured
<strong>1 resource configured</strong>
Online: [ testdb01 testdb02 ]
Full list of resources:
 testdb-ip (ocf::heartbeat:IPaddr2): Starting testdb01

Daemon Status:
corosync: active/enabled
pacemaker: active/enabled
pcsd: active/enabled

Ergebnis: Die Resource “testdb-ip” startet direkt auf dem Host testdb01

 

Nun prüfen wir noch am Adapter nach, ob dort ebenfalls die Service-IP vorhanden ist:

1
2
3
4
5
6
7
8
9
10
[root@testdb01 ~]# ip addr
(..)
2: eth0: &lt;BROADCAST,MULTICAST,UP,LOWER_UP&gt; mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 76:f3:cc:53:fa:6b brd ff:ff:ff:ff:ff:ff
inet 192.168.0.113/24 brd 192.168.0.255 scope global noprefixroute eth0
valid_lft forever preferred_lft forever
inet <strong>192.168.0.115/24</strong> brd 192.168.0.255 scope global secondary eth0
valid_lft forever preferred_lft forever
inet6 fe80::3522:f3f3:80cd:7aae/64 scope link noprefixroute
valid_lft forever preferred_lft forever

Ergebnis: Der Netzwerkadapter eth0 hat zusätzlich zu seiner festen IP (192.168.0.113) noch die IP-Adresse 192.168.0.115 die wir vorher als Cluster-Reosurce erstellt haben.

 

Empfehlung: Um im Fehlerfall die Konfiguration von Pacemaker bzw. Corosync schnell wieder anlegen zu können, empfiehlt es sich auf einem der beiden Linux-Hosts die Befehle vom Anlegen des Clusters bis hin zu Einrichtung der Cluster-Resource(n) in einer Bash-Datei abzuspeichern.
Damit kann im Fehlerfall durch einfaches Löschen und neu Anlegen der Konfiguration sowie der Resourcen in 20 bis 30 Sekunden eine Cluster-Einrichtung erfolgen.

 

 

Verwaltung von Corosync / Pacemaker

Cluster-Resourcen manuell verschieben.

In der Praxis wechselt die IP-Adresse nur dann von einem Host, wenn der aktive Host herunter fährt oder der Corosync-Dienst angehalten wird. Möchte man die Cluster-Resource von Hand von einem Host auf den anderen verschieben, so geht das mit:

pcs resource move <resource-name> <nodename>

Beispiel:

1
pcs resource move testdb-ip testdb02

Cluster-Resource entfernen

So wie eine Cluster-Resource angelegt wird, so kann sie natürlich auch gelöscht bzw. entfernt werden:

Syntax: pcs resource delete <Resource-Name>

Bsp.:

1
pcs resource delete testdb-ip

 

Fehler / Troubleshooting von Corosync / Pacemaker /pcsd

Sofern immer ein Host online ist, sind Fehler bei Corosync/Pacemaker eher selten. Wenn doch einmal etwas nicht geht, dann empfiehlt sich folgende Vorgehensweise:

Dienste (Pacemaker/Corosync/pcsd) stoppen und neu starten

Alle relevanten Dienste stoppen:

1
service corosync stop; service pacemaker stop; service pcsd stop;

Alle relevanten Dienste starten:

1
service pcsd start; service pacemaker start; service corosync start;

Danach ermitteln Sie auf beiden Hosts einzeln mit “pcs status” ob die Hosts sich gegenseitig als “online” sehen und ob die Cluster-Resource(n) vorhanden sind.

Die harte Tour: Konfig neu anlegen.

Für den unwahrscheinlichen Fall, dass ein Fehler hartnäckiger ist, kann aus Zeitgründen die Konfiguration auch kurzerhandgelöscht und neu gestartet werden.

Dazu stoppen Sie auf beiden Hosts alle Dienste und löschen anschließend die Konfigurationsdateien auf beiden Hosts. Danach legen Sie die Konfiguration (wie oben beschrieben) neu an.

Das ist in vielen Fällen einfacher und vor allem schneller als eine langwierige Fehlersuche.

Vorgehen:

1
2
3
4
5
6
# Dienste stoppen
service corosync stop; service pacemaker stop; service pcsd stop;
# Konfig Dateien löschen
/etc/corosync/corosync.conf löschen
/etc/pacemaker -&gt; Dateien löschen.
#Ggf. Dienste deaktivieren

Danach noch mal neu aufsetzen wie oben beschrieben. (geht in der Regel schneller als eine lange Fehlersuche)

Weiterführende Infos

 

Ansible Tutorial – Einführung

, ,
Erneute Ausführung eines ansible Playbooks

Einleitung zu ansible

Ansible ist eine Software zur zentralen Verwaltung (Orchestrierung) und Administration von verteilten Servern. Die Community-Version von Ansible selbst ist als OpenSource Software im Rahmen der Linux-Administration lizenzfrei. Neben der Community-Edition von ansible gibt es vom Hersteller (Redhat) noch weitere lizenzpflichtige Editionen, die etwa ein Dashboard oder Workflows zur Verfügung stellen.

Ansible ist seit 2012 „auf dem Markt“ und aktuell in der Version 2.4 in den meisten Linux-Distributionen wie CentOS, Ubuntu oder Debian enthalten.

Warum ansible?

Ansible gehört neben Puppet und Chef zu den bekanntesten Software-Produkten, mit denen verteilte Systeme administriert werden können. Gegenüber puppet und chef hat ansible jedoch einige Vorteile:

  • Ansible benötigt keine zentrale Komponente. Ein Rechner, um per ssh auf die zu verwaltenden Server zugreifen kann, reicht aus.
  • Der Einarbeitungsaufwand ist bei ansible deutlich geringer als bei chef oder puppet
  • Es gibt für ansible eine Vielzahl von fertigen Skripten (so genannten Playbooks), die sie meistens kostenlos (etwa bei github) herunter laden können.

Voraussetzungen für ansible

Damit ansible einwandfrei funktioniert, benötigen wir

Eine Workstation / Server

Für die tägliche Arbeit mit ansible empfiehlt sich die Installation auf einem Rechner bzw. Server, auf dem Linux installiert ist. Das kann die Workstation des Linux-Administrators oder ein anderer Rechner sein, von dem aus die zu verwaltenden Server gut zu erreichen sind.

Netzwerk

Damit ansible von der Administrations-Installation aus auf die zu verwaltenden Server zugreifen kann, müssen diese über ein Netzwerk erreichbar sein. Dabei spielt es keine Rolle, ob die Geräte über das Internet, das LAN oder ein VPN erreicht werden können.

SSH-Keys

Die Kommunikation zwischen ansible und den entfernten Hosts läuft im Wesentlichen über ssh (secure shell). Damit ansible auf dem zentralen Host ohne Passwort auf die entfernten Server zugreifen kann, muss eine SSH-Verbindung mittels Zertifikat möglich sein.(Wie diese eingerichtet wird erklären wir weiter unten)

 

Installation und Vorbereitung von ansible

Neben der Software von ansible benötigen wir nur wenig weitere Zutaten:

Die Installation von ansible erfolgt in der Regel durch den Paket-Manager der eingesetzten Linux-Distribution. Ansible selbst basiert auf der Programmiersprache python. Die dafür notwendigen Pakete werden durch den Paketmanager (yum oder apt) mit installiert.

Installation von ansible auf Centos/RedHat

Centos# yum install ansible

Installation von ansible unter Ubunti/Debian

Debian# apt-get install ansible

SSH-Key erstellen

Damit später eine passwort-lose Anmeldung auf den entfernten Rechnern möglich ist, muss einmal zentral auf dem Verwaltungs-Server ein ssh-Schlüssel erzeugt werden:

1
Linux# ssh-keygen

Die anschließend gestellten Fragen nach dem Namen (id_rsa und id_rsa.pub) sowie einer Passphrase bestätigen Sie mit Return.

Nun sind um Verzeichnis /root/.ssh/ zwei Dateien vorhanden. Die ist der geheime Teil des Schlüssels (id_rsa) sowie der öffentliche Teil des RSA-Schlüssels: id_rsa.pub (pub = public).

SSH-Key auf die entfernten Rechner kopieren

Damit eine passwortlose Anmeldung auf den entfernten Rechnern möglich ist, muss nun der öffentliche Teil des Schlüssels auf den entfernten Server kopiert werden. Das geht am einfachsten mit ssh-copyid

1
Linux# cd /root/.ssh/

Linux# ssh-copy-id -id id_rsa.pub root@<entfernter Server>
#Ersetzen Sie <entfernter Server> durch die IP oder den DNS-Namen des entfernten Servers.

Sie werden nun noch einmal das Passwort des entfernten Servers angeben müssen. Danach sollte eine SSH-Anmeldung ohne Passwort möglich sein.

Testen Sie ob die Anmeldung ohne Passwort klappt:

1
Linux# ssh root@&lt;entfernter Server&gt;

Wenn dieser Schritt gekappt hat, dann können wir mit der eigentlichen Vorbereitung von ansible loslegen

Die Konfiguration von ansible

Nach der Installation von ansible auf dem zentralen Rechner hat der Paket-Manager ein Verzeichnis für ansible unter /etc/ansible angelegt. Im Verzeichnis /etc/ansible liegen zwei elementare Dateien:

Ansible.cfg

In der Datei ansible.cfg sind die grundsätzlichen Einstellungen für ansible abgelegt.

Wichtig in der Konfig-Datei ist, daß der Pfad zu Hosts-Datei nicht auskommentiert ist. Sofern die Zeile mit ‚#‘ beginnt, entfernen Sie das ‚#‘ Zeichen.

1
#inventory      = /etc/ansible/hosts

Es empfiehlt sich, alle weiteren Einstellungen zunächst einmal so zu belassen, wie sie sind.

Hosts-datei

Ebenfalls unter /etc/ansible liegt die Datei „hosts“. (nicht zu verwechseln mit der Datei /etc/hosts).

In dieser Datei speichert ansible die Namen und Adresse der zu verwaltenden Server

Struktur der Hosts-Datei

Server und Rechner die Sie mit ansible verwalten möchten, müssen Sie an mindestens einmal in der Datei /etc/ansible/hosts eintragen.

Sofern Sie ihre zu verwaltenden Server alle gleich (im Sinne der Konfiguration) sind, können Sie diese der Reihe nach untereinander in der Hosts-Datei eintragen.

Gruppen in der Hosts-Datei

Sofern Sie Ihre Server nach bestimmten Kategorien gruppieren möchten, so tragen Sie in die Hosts-Datei den Namen ihre Gruppe in eckigen Klammern ein und führen direkt danach ihre Server nacheinander zeilenweise auf.

Bsp.:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
Server01.domain.tld
Server02.domain.tld
Testserver01.intern.local
Testserver02.intern.local
[Produktion]
Server01.domain.tld
Server02.domain.tld
[Testserver]
Tessterver01.intern.local
Testserver02.intern.local
[Webserver]
Server01.domain.tld
Testserver01.intern.local
[Datenbankserver]
Server02.domain.tld
Testserver02.intern.local

Die Gruppen können Sie später dazu nutzen, die eigentlichen Skripte von ansible gezielt nur auf eine oder mehrere Gruppen anzuwenden.

Das macht u.a. dann Sinn, wenn etwa unterschiedliche Linux-Paketmanager zum Einsatz kommen oder Sie zwischen Produktions- und Entwicklungs-Servern unterscheiden wollen.

Der Ansible Befehl

Für ansible sind im täglichen Betrieb zwei Befehle wichtig

  • ansible zum interaktiven Aufruf
  • ansible-playbook zum ausführen komplexerer Skripte

 

Interaktive Nutzung von ansible

Der Befehl „ansible“ ist hilfreich, um direkt bestimmte einmalige und meist kurze Kommandos auf einem Remote-Host abzusetzen. Insofern ähnelt ansible hier dem klassischen ssh-Kommando.

Ein Beispiel:

1
ssh <a href="mailto:root@remotehost.tld">root@remotehost.tld</a> „ls –la /root“

ist im Wesentlichen identisch mit:

1
ansible remotehost.tld  -m shell -a "ls -la /root/”

Beide Befehle listen den Inhalt des Verzeichnisses /root auf.

Im Gegensatz zu ssh können Sie aber bei ansible diesen Befehl auf mehrere Hosts anwenden – vorausgesetzt die Server sind in der /etc/ansible/hosts aufgelistet.

Bsp.:

ansible centos –m shell –a „ls –la /root“

Die obere Zeile wird simultan auf allen Server ausgeführt, die in der Gruppe “[centos]” in der Datei /etc/ansible/hosts enthalten sind.

Alle Systemparameter eines Hosts abfragen

Um etwa alle bekannten System-Parameter eines Hosts (die ansible kenn) abzufragen und auszugeben, reicht der folgende Einzeiler:

1
2
3
4
5
6
7
8
9
10
11
12
Linux# ansible &lt;hostname&gt; -m setup
[root@ ansible]# ansible sample.domain.tld -m setup | head -n10
sample.domain.tld | SUCCESS =&gt; {
"ansible_facts": {
"ansible_all_ipv4_addresses": [
"123.231.218.129"
],
"ansible_all_ipv6_addresses": [],
"ansible_apparmor": {
"status": "disabled"
},
"ansible_architecture": "x86_64",

Diese System-Informationen nennt ansible “facts” und sammelt sie bei jedem Aufruf von ansible. Auf diese ansible-facts kann später in Skripten zugegriffen werden. So ist es etwa möglich Unterscheidungen in Skripten bei unterschiedlichen Linux-Versionen oder Distributionen zu machen. Dazu gleich mehr.

Ansible Playbooks / Skripte

Ansible Skripte heißen „Playbooks“ und werden im YAML-Format erstellt und in der Regel mit der Endung .yaml abgespeichert. Neben den eigentlichen Playbooks können von ansible noch ganz normale Dateien kopiert werden. Außerdem steht mit Jinja2 eine Template-Engine zur Verfügung, mit der sie Datei-Vorlagen mit Variablen ersetzen und anschließend auf die Zielrechner kopieren können.

Hinweis: Das YAML-Format der Playbooks ist etwas tricky was die Einrückungen am Zeilenanfang anbelangt. Es empfiehlt sich daher einen Editor (z.B. Notepad++) zu verwenden, der das berücksichtigt, so daß Sie sich auf das Erstellen bzw. Anpassen des Playbooks konzentrieren können.

Mehr zur Notation von YAML in ansible finden sie in der ansible-Dokumentation.

Verzeichnis-Struktur für Ihre Skripte:

Damit Ihre Skripte später leichter zu managen sind, empfehle ich Ihnen folgende Struktur:

  • Legen Sie ein Verzeichnis für die ansible Playbooks an z.B. /root/ansible
  • Legen Sie ein weiteres Unterverzeichnis für Dateien und Templates an, die durch die Playbooks kopiert oder verändert werden sollen. /root/ansible/files

Ein einfaches ansible Playbook

Im ersten Skript bzw. Playbook verwenden wir wenige Zeilen ansible-Code um den Apache httpd-Dienst zu installieren. Kopieren Sie die nachfolgenden Zeilen in eine Datei mit dem Namen „playbook-install-httpd.yml“ ab:

1
2
3
4
5
---
- hosts: all
tasks:
- name: ensure apache is at the latest version
yum: pkg=httpd state=latest

Hinweis: Bitte beachten Sie die Anzahl der Leerzeichen bzw. Einrückungen am Anfang einer jeden Zeile.

Zur Erklärung:

In der ersten echten Zeile definieren Sie hinter „- hosts:“ zunächst auf welche Server/Rechner das Skript angewendet werden soll. In unserem Beispiel habe ich „all“ gewählt. Das ist die bei ansible bereits vordefinierte Gruppe aller Server, die in der Datei /etc/ansible/hosts enthalten sind.

Danach werden nach dem Schlüsselwort „tasks:“ die eigentlichen Zeilen mit Kommandos untereinander geschrieben.

Der Eintrag „- name:“ definiert eine Task mit einem Namen, der nach dem „:“ eingetragen ist. Hier können Sie ihren Aufgaben sinnvolle Begriffe geben, die in der späteren Ausführung der Tasks für Sie sichtbar sind.

In der letzten Zeile erfolgt dann das erste echte Kommando: Eine Installation durch den Paket-Manager „yum“. Über das ansible-Modul für yum „pkg=httpd“ (sprich: Package -> httpd) wird festgelegt, was installiert werden soll. Mit der Anweisung „state=latest“ definieren Sie, welche Version von apache Sie installieren lassen wollen.

Hinweis: Im obigen Beispiel haben wir im Skript angegeben, daß der Paketmanager yum sein soll. Daher würde dieses Skript auf Ubuntu oder Debian keinen Sinn ergeben, da hier der Paket-Manager apt heißt.

Daher wäre es für dieses Skript sinnvoll, es auf die Gruppen einzuschränken, die entweder CentOS oder Redhat installiert haben.

Ablauf des Skripts / Playbooks

Um das Playbook auf dem entfernten Host ablaufen zu lassen, geben Sie auf der Kommandozeile folgendes ein:

ansible-playbook playbook-install-httpd.yml –limit=<hostname>*

Erklärung: ansible-playbook ist der ansible-Befehl, der Playbooks im YAML-Format interpretieren und ausführen kann.

Sofern Sie die Ausführung eines Skripts auf wenige oder nur einen Host beschränken wollen, so nutzen Sie den Schalter „—limit=<hostname>*“ und geben etwa ihren Hostnamen (so wie er in der /etc/ansible/hosts eingetragen ist) ein.

Ausgabe eines Skripts bzw. Playbooks bei ansible

Ausgabe eines Skripts bzw. Playbooks bei ansible

Im Beispiel (siehe Bild) ist der Hostname mit 10.39.189.114 in der /etc/ansible/hosts eingetragen.

 

Ablauf eines Skripts

Bei allen ansible-Playbooks werden im ersten Schritt zunächst einmal die so genannten „Facts“ durch ansible gesammelt. Zu diesen Fakten gehören neben der Betriebssystem-Version unter anderem auch die Software-Stände oder die IP-Adresse des Hosts.

Anschließend werden die einzelnen Aufgaben (Tasks) der Reihe nach abgearbeitet. In der Zeile nach TASK (siehe Bild) erscheint dann lediglich die Beschreibung, die Sie in ihrem Skript nach dem Schlüsselwort „name:“ eingegeben haben.

Sofern lediglich Informatoinen von ansible erhoben werden oder wenn Aufgaben keine Veränderung nach sich ziehen, wir die Zeile GRÜN dargestellt. Sofern Änderungen vorgenommen werden, so erscheint die Ausgabezeile in GELB.
Fehler erscheinen in ROT.
Ganz zum Schluss werden im „Play Recap“ noch einmal für jeden Host.
Falls Sie ein Skript versehentlich zweimal durchlaufen lassen, so ergibt sich bei der Ausgabe folgendes Bild:

Erneute Ausführung eines ansible Playbooks

Erneute Ausführung eines ansible Playbooks

Ansible hat bei der Sammlung von Fakten festgestellt, daß die Software für den httpd-daemon (apache2) bereits in der aktuellsten Version installiert ist. Daher wird die Task mit „ok: [servername]“ quittiert und daher in Grün ausgegeben.

 

Ein Skript erweitern: Apache installieren und starten

Unser einfaches Beispiel hat nun zwar den Apache-Webserver installiert, aber noch nicht gestartet. Ein dauerhafter Start nach einem Reboot des betroffenen Servers fehlt ebenfalls.

Ebenso fehlen die für den apache sinnvollen Erweiterungen wie PHP, Python oder Perl. Mit der folgenden Erweiterung installieren wir nun die noch fehlenden Pakete, starten den apache und stellen sicher, daß nach einem Reboot der httpd-Dienst wieder startet.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
- hosts: centos
tasks:
- name: ensure apache is at the latest version
yum: pkg=httpd state=latest
- name: ensure php is at the latest version
yum: pkg=php state=latest
- name: ensure perl is at the latest version
yum: pkg=perl state=latest
- name: ensure python is latest
yum: pkg=python state=latest
- name: ensure httpd is running (and enable it at boot)
service: name=httpd state=started enabled=yes
handlers:
- name: restart httpd
service: name=httpd state=restarted

Erklärung zum Skript:

In der Hosts-Anweisung haben wir nun nur die Gruppe [centos] in der Datei /etc/ansible/hosts angesprochen. Die nachfolgenden 4 Anweisungen installieren erst den Apache, dann php und danach perl und python.

Die Anweisung „service: name=httpd state=started enabled=yes” stellt sicher, daß der httpd-daemon sofort gestartet wird und außerdem in der Systemkonfiguration (systemctl bzw. chkconfig) dauerhaft auf „on“ gesetzt wird.

Der Eintrag nach „handlers:“ bewirkt folgendes: Sofern eines der vorangegangen Kommandos eine Änderung am System vorgenommen hat, wird der httpd-Dienst neu gestartet. Sofern keines der Kommandos eine Änderung bewirkt, wird der httpd-Dienst nicht neu gestartet.

Bedingungen in Skripten

Wie oben bereits beschrieben, kann es Sinn machen, Unterscheidungen in Skripten vorzunehmen um etwa die Linux-Distribution und damit den Paketmanager zu unterscheiden.

Der folgende Auszug aus einem komplexeren Skript unterscheidet bei Centos nach der Major-Release-Version (6 oder 7) und kopiert eine unterschiedliche Datei, je nachdem ob wir eine Centos-6 oder Centos-7 Installation haben:

1
2
3
4
5
6
7
8
9
10
11
tasks:
- name: copy bareos repo file for Centos 7.x
copy: src=files/bareos7.repo dest=/etc/yum.repos.d/
when:
- ansible_distribution == "CentOS"
- ansible_distribution_major_version == "7"
- name: copy bareos repo file for Centos 6.x
copy: src=files/bareos6.repo dest=/etc/yum.repos.d/
when:
- ansible_distribution == "CentOS"
- ansible_distribution_major_version == "6"

Das Schlüsselwort „when:“ nach der eigentlichen Task definiert, unter welchen Umständen die Aufgabe (Task) durchgeführt wird.

Der eigentliche ansible Befehl „copy:“ kopiert die Datei, die nach „src“ angegeben ist in das Verzeichnis, das nach „dest=“ folgt. Hier also: „files/bareos6.repo“ bzw. „files/bareos7.repo“ nach /etc/yum.repos.d .

Variablen und Templates in Skripten verwenden

Anstatt einfach eine statische Datei vom Kontroll-Rechner auf den entfernten Hosts zu kopieren, kann auch ein Template verwendet werden. Der Unterschied zum Kopieren ist der, daß Sie beim Template Host-spezifische Änderungen an der zu kopierenden Datei bzw. dem Template vornehmen können.

Templates haben bei ansible üblicherweise die Endung .j2 . Die eigentlichen Variablen werden in Templates oder Skripten mit doppelten geschweiften Klammern eingefügt.

Bsp.:

1
2
- name: modify index.html.j2 and copy to /var/www/html
template: src=files/index.html.j2 dest=/var/www/html/index.html

Inhalt von files/index.html.j2:

1
2
3
Sie sehen den Webserver auf {{ ansible_fqdn }} .
Auf dem Server ist {{ ansible_distribution }} in der Version
{{ ansible_distribution_major_version }} installiert .

Beim Kopieren des Templates werden nun pro Host der jeweilige Hostname sowie der Name und die Nummer der Linux-Distribution ausgegeben.

Die Variablen ansible_fqdn sowie ansible_distribution und ansible_distribution_major_version werden durch ansible beim Gather-Facts Durchlauf mit Inhalt gefüllt

Eigene Variablen in Playbook und Templates

Ansible erlaubt die Definition und Verwendung eigener Variablen. Variablen sind dabei immer „Schlüsselname->Wert“-Zuweisungen. Dabei kann nicht nur ein Wert definiert werden, sondern eine Variable kann eine Liste von Werten enthalten.

Variablen können vorab im Kopf eines Playbooks definiert werden oder zur Laufzeit auf dem Host erfragt und registriert werden:

Beispiel:

1
2
3
- hosts: webservers
vars:
http_port: 80

Hier wird die Variable „http_port“ mit dem Wert „80“ belegt.

Beispiel für die Registrierung von Variablen zur Laufzeit:

– hosts: web_servers tasks: – shell: /usr/bin/foo register: foo_result ignore_errors: True

Im zweiten Beispiel wird auf dem entfernten Host der Shell-Aufruf “/usr/bin/foo” ausgeführt. Das Ergebnis wird als Variable „foo_result“ gespeichert. Die Aufgabe der Zuweisung von Wert zu Variable übernimmt das Schlüsselwort „register“. Der eigentliche Inhalt der Variable kann später weiter verwendet werden.

Hinweis: Das Programm /usr/bin/foo gibt es nicht wirklich.

Skripte in Playbooks wieder verwenden

Über include und import-Anweisungen können Sie bestehende Skripte in ihren Playbooks einbinden und so mehrfach verwenden. Ein so eingebundenes Playbook-Fragment kann wiederum beliebig viele Tasks enthalten.

Ein Beispiel.:

1
2
3
4
5
6
7
8
- hosts: all
vars:
internal_networks: [10.10.10.0, 10.20.20.0]
tasks:
- include_tasks: ansible_bareos_external_network.yml
when:  ansible_default_ipv4.network not in internal_networks
- include_tasks: ansible_bareos_internal_network.yml
when:  ansible_default_ipv4.network in internal_networks

Über das Schlüsselwort “include_tasks:” definieren Sie das Skript, das eingefügt warden soll.

Im obigen Beispiel wurde außerdem eine eigene Variable namens „internal_networks“ definiert und mit den Werten „10.10.10.0“ sowie „10.20.20.0“ vorbelegt..

Je nachdem ob die (beim Fakten-Check) ansible-Variable ansible_default_ipv4.network identisch mit einem der Einträge bei „internet_networks“ ist, wird entweder das Skript ansible_bareos_internal_network.yml oder ansible_bareos_external_network.yml ausgeführt.

Hinweis: Ein yaml-Skript, das sie über include in ein Skript einfügen, darf nur reine Task-Anweisungen enthalten. Hosts-Anweisungen sind nicht erlaubt. Die nehmen Sie im Haupt-Skript vor.

Fazit zu ansible:

Mit ansible kann sich jeder Netzwerk-Administrator mit wenig Aufwand seine eigene Sammlung an Skripten zum Systemmanagement erstellen. Vor allem die große Auswahl an bestehenden Playbooks macht es auch Einsteigern sehr leicht, mit ansible erste Erfolge zu erzielen.

Für viele Linux-Admins sind die kleinen und großen ansible-Helferlein aus dem IT-Alltag gar nicht mehr wegzudenken. Wer einmal das Konzept und die Einfachheit von ansible verstanden hat, will meist keine 20 Server mehr von Hand anpassen ;-).

Welche Erfahrungen haben Sie mit ansible gemacht? Schreiben Sie’s uns in die Kommentare. Wir freuen uns drauf.

 

Weiterführende Infos

Weitere Informationen und Sites zu ansible:

Bücher zu ansible:

Software Defined Storage mit CEPH

, , ,

Datenwachstum als Herausforderung der IT

Das stetige Wachstum der Datenmengen ist ein Problem, dem sich jede IT-Abteilung früher oder später stellen muss. Nutzen Sie ausschließlich klassische Speicherlösungen wie SAN oder NAS müssen die zur Verfügung stehenden Kapazitäten irgendwann mühsam erweitert werden. Eine solche Maßnahme hat des öfteren auch eine kurze downtime zur Folge, da nicht jede Erweiterung im laufenden Betrieb möglich ist.

Damit stellt sich bereits ein weiteres großes Problem ein. Kunden erwarten heutzutage, dass IT-Services zu 100 % an jedem Tag und zu jeder Stunde verfügbar sind. Downtimes werden immer weniger toleriert, besonders im Bereich von Rechenzentren sowie des Hostings. Eine mögliche Lösung um diese Zeiten zu minimieren oder gar völlig auszuschließen bietet beispielsweise Software Defined Storage oder kurz SDS.

Ceph geht neue Wege

Ceph Architektur

Abbildung 1
Ceph Architektur

Schwierigkeiten bei Software Defined Storage

CEPH ist aber keineswegs perfekt und bringt selbstverständlich auch Nachteile mit sich. Ein Merkmal mit dem man sich vor der Inbetriebnahme auseinandersetzen muss, sind die Latenzen die SDS im Vergleich zu Direct Attached Storage (DAS) mit sich bringt. Die erhöhte Komplexität des Software Stacks in Kombination mit den verwendeten Netzwerkverbindungen erhöhen die Latenz pro IO signifikant.

Es erweist sich als äußerst schwierig die Latenz unter den Wert von einigen Millisekunden für Schreibvorgänge zu senken. Woher diese Latenz kommt lässt sich verdeutlichen, wenn man sich die Arbeitsweise von CEPH bei Schreibvorgängen etwas genauer betrachtet (Abbildung 2).

Ein synchroner IO muss vom Client zur primären OSD gesendet werden. Die primäre OSD schickt anschließend die Anzahl konfigurierter Replikationen zu weiteren OSD’s und deren Journalen. Sobald die Repliken auf den Journalen aller OSD’s vorliegen, wird der Vorgang an die primäre OSD bestätigt. Hat die primäre OSD nun alle Bestätigungen erhalten, wird eine Bestätigung an den Client gesendet und dieser kann den nächsten IO senden. Das verdeutlicht schon weshalb es bereits zu Latenzen innerhalb des Software Stacks kommt.

SDS mit Ceph - Arhcitektur

Abbildung 2

Zusätzlich spielt auch das eingesetzte Netzwerk bei Ceph eine entscheidende Rolle. Es gilt hier zunächst unnötige Hops zu vermeiden, da jeder Hop etwa 200us Latenz mit sich bringt. Ein 10GE Netzwerk gilt hierbei als das absolute Minimum, welches Sie beim Einsatz von Ceph oder einem anderen verteilten Speichersystem verwenden sollten. Das verringert Latenzen und erhöht die Bandbreite. Eine zusätzliche Verbesserung bringt Ihnen selbstverständlich der Einsatz von RDMA, jedoch müssen hier die Kosten beachtet werden. All diese Faktoren spielen eine wichtige Rolle und müssen optimiert werden um Latenzen unter dem 2ms Level zu erhalten und dabei eine Balance zwischen Kosten und Nutzen zu finden, was natürlich nicht immer einfach ist.

 

Anforderungen an eine gute SDS Lösung

Damit Sie nach der Einführung einer SDS Lösung wie Ceph nicht enttäuscht sind, gibt es einige Punkte zu beachten. SSDs oder (Enterprise SSD oder NVME SSD) für die Journale, in denen die Schreibvorgänge gecached werden, sowie ein 10GE Netzwerk sind nach herrschender Meinung innerhalb der Ceph Community und unseren eigenen Erfahrungen ein Muss. Für die OSD’s sollten nach Möglichkeiten SAS3 HDD’s verwendet werden. Es ist auch denkbar bei Bedarf einen Teil der OSD’s rein aus SSDs zu erstellen und gesondert zur Verfügung zu stellen. Wichtig ist zudem keine RAID Arrays zu verwenden. Ceph profitiert stark von vielen unabhängigen Festplatten. Einem schwerwiegenden Datenverlust entgehen Sie zudem indem Sie mehrere Server mit möglichst vielen Festplatten (OSD’s) bereitstellen

Die CPU sollte möglichst viele Prozessor-Kerne haben, und der Arbeitsspeicher mit etwa 1-2 GB pro OSD berechnet werden um hier keinen Flaschenhals zu generieren. Der Einsatz von RDMA muss wohl überlegt sein und kommt auf den speziellen Workload an. Werden extrem niedrige Latenzen und hohe Bandbreite über 10 GE benötigt bietet es sich eventuell eher an auf ein spezielles Storage System wie GPFS, BeeGFS oder Lustre  in Kombination mit Infiniband/Omnipath zu setzen.

Fazit zu Ceph

Zusammenfassend lässt sich sagen, dass Software Defined Storage definitiv eine gute Möglichkeit darstellt, um stetig wachsende Datenbestände einfacher zu verwalten. Jedoch hat Software Defined Storage genau wie jede andere Lösung gewisse Einschränkungen denen man sich bewusst sein muss. Im modernen IT-Betrieb wird man aber nicht auf SDS verzichten können. Die mitgebrachten Vorteile wie Skalierbarkeit, einfache Erweiterung und eine sehr hohe Verfügbarkeit werden zunehmend wichtiger.

Weiterführende Links zum Thema:

7 Fakten über Linux: Ist Linux das bessere Betriebssystem?

, ,

7 interessante Fakten über Linux, die Sie nicht ignorieren sollten

Haben Sie es schon gewusst, dass die Zahl der Linux-Nutzer stetig zunimmt, während immer mehr Nutzer Windows den Rücken kehren und auf andere Betriebssysteme umsteigen? Viele prominente Experten sind sich darüber im Klaren, dass sich das OS in naher Zukunft als das Betriebssystem Nummer 1 etablieren und den Marktführer Microsoft vom Thron verdrängen wird. Die folgenden 7 Fakten über Linux sprechen für diese Behauptung:

Fakt Nummer 1: 85% der leistungsstärksten Computer der Welt basieren nicht auf Windows, sondern auf Linux

Vom niedlichen Logo sollte man sich nicht täuschen lassen. Linux ist schnell und sicher.

Vom niedlichen Logo sollte man sich nicht täuschen lassen. Linux ist schnell und sicher.

Dass die Mehrheit der aktuellen Supercomputer auf Linux-Distributionen wie Centos oder Ubuntu setzt, hat seine guten Gründe. Linux gilt als ein äußerst sicheres und stabiles Betriebssystem, das sich relativ einfach personalisieren lässt und gegen Viren- und andere Schadsoftware optimal geschützt ist. Aus diesem Grund werden moderne Supercomputer, die Menschenleben retten und komplizierte Forschungsprozesse vorantreiben, unter diversen Linux-Distributionen betrieben, während das Windowsbetriebssystem in erster Linie auf dem heimischen Desktop-Rechner oder bei Firmen im internen Netzwerk eingesetzt wird.
Übrigens: Die große Mehrheit der aktuellen Firewalls basiert auf Linux (oder BSD) als Betriebssystem. Viele davon sind außerdem als Opensource-Software frei verfügbar.

Fakt Nummer 2: Linux ist schnell

Ihnen wird das folgende Szenario sicherlich bekannt vorkommen: Sie haben sich endlich einen neuen Desktop-PC gekauft und sind davon begeistert, wie schnell alle Programme ausgeführt werden und wie flott das neu installierte Betriebssystem läuft. Mit der Zeit wird die Freude aber getrübt, so dass sich ein deutlicher Leistungsabfall deutlich macht.

Immer wieder gibt es unerwünschte Unterbrechungen am Computer durch lange Ladezeiten und es wird zudem immer mühseliger mehrere Programme gleichzeitig auszuführen. Ein Linux-System hat gegenüber Windows-Betriebssystemen einen deutlichen Vorteil: Linux wurde von Anfang an so konzipiert, dass es mit der Zeit einen nur minimalen Leistungsverlust aufweist, so dass das Betriebssystem, Programme und Spiele auch nach Jahren noch so gut laufen wie am Anfang.

Fakt Nummer 3: Mit Linux sparen Sie nicht nur Geld beim Betriebssystem, sondern auch bei der Hardware

Die Mindest-Hardwarevoraussetzungen für Microsoft Windows steigen mit jeder neuen Version des Betriebssystems aus Redmont. Aus diesem Grund müssen die meisten Nutzer schon nach kurzer Zeit, Budget in neue Hardware investieren, damit Programme und Spiele auch weiterhin reibungslos funktionieren. Bei Linux-Distributionen ist dies jedoch nicht der Fall. Computer mit Linux als Betriebssystem bleiben auch nach Jahren schnell und stabil, so dass Investitionen in neue Hardware nicht unbedingt nötig sind.

Fakt Nummer 4: Viele bekannte Unternehmen sind schon auf Linux umgestiegen

Bei Linux handelt es sich längst um kein Betriebssystem mehr, das nur von Nerds und Computerspezialisten genutzt wird. Heutzutage ist genau das Gegenteil der Fall. Viele bekannte Unternehmen und Organisationen, die auf der ganzen Welt vertreten sind, setzen immer mehr auf Linux als Betriebssystem. Unternehmen schätzen insbesondere die hohe Sicherheit und Zuverlässigkeit von Linux. Dass Linux als Betriebssystem völlig kostenlos ist, so dass Unternehmen eine Menge Kosten an unnötigen Lizenzen einsparen können, ist spielt selbstverständlich auch eine große Rolle.

Zu den bekannten Organisationen und Unternehmen gehören:

  • Siemens
  • BMW
  • Die Deutsche Post
  • Lufthansa
  • Karstadt

Fakt Nummer 5: Mit Linux können Sie sogar Ihre Computer-Probleme effektiv lösen

Sie sind sicherlich mit der folgenden Situation konfrontiert worden: Ihr PC fährt plötzlich nicht mehr hoch und Sie wissen sich nicht zu helfen. Guter Rat in dieser und ähnlichen Situationen ist teuer, denn hier kann in der Regel nur der Fachmann helfen. Bei einem Computer der mit Linux läuft, gehören solche Probleme der Vergangenheit an, denn Linux-Betriebssysteme bietet Ihnen die Möglichkeit, das System selbständig zu analysieren.

Mit einer Linux-Distribution wie Centos, Ubuntu oder Debian können Sie nicht nur die Ursachen von Fehlermeldungen ermitteln, sondern auch Daten wiederherstellen, die sonst für immer verloren wären und das sowohl bei Windows- als auch bei Linux-Systemen.

Hier sehen Sie also, welche Vorteile Ihnen Linux als Betriebssystem bietet. Es ist sogar in der Lage komplizierte Probleme zu lösen, die Microsoft seit Jahren plagen. Linux lässt sich schnell und bequem auf einem PC installieren, so dass ein Linux-Test auf jeden Fall empfehlenswert ist.

Fakt Nummer 6: Linux gilt dank seiner innovativen Architektur als eines der sichersten Betriebssysteme

Linux als Betriebssystem ist ausgesprochen sicher.

Linux als Betriebssystem ist ausgesprochen sicher.

Bei Linux handelt es sich um ein Betriebssystem, das Ihnen ein hohes Maß an Sicherheit bietet. Obwohl über 90 Prozent aller Viren und Trojaner für Windowssysteme entwickelt werden, ist dies nicht der einzige Grund, weshalb Linux so sicher ist. Bei Windows kann man versehentlich oder absichtlich sämtliche Systemdateien verändern und sogar löschen, so dass das Betriebssystem unbrauchbar wird. Bei Linux ist dies jedoch dank der intelligenten Rechteverwaltung das Löschen oder die Manipulation von wichtigen Dateien nicht gestattet. Bei jedem Versuch, grundlegende Änderungen am System vorzunehmen, muss man bei einem Linux-System ein Administrator-Kennwort (genauer: root) eingeben, so dass stets ein hohes Maß an Sicherheit gewährleistet wird.

Fakt Nummer 7: Linux ist in der Regel völlig kostenlos

Eines der wichtigsten Kriterien, warum immer mehr Unternehmen und Privatpersonen auf Linux umsteigen ist die Tatsache, dass Linux in der Regel völlig kostenlos ist und unter einer Opensource-Lizenz frei verfügbar ist. Wenn man sich den großen Funktionsumfang in Kombination mit der sehr guten Sicherheit des Systems vor Augen führt und das auch noch völlig kostenlos, ist es kein Wunder, dass dieses Betriebssystem immer beliebter wird.

Na, sind Sie neugierig geworden? Auch wenn wir noch nicht ganz daran glauben, daß Linux in naher Zukunft Windows verdrängen wird, so gibt es heute schon viele Einsatzmäglichkeiten für Linux in Unternehmen – beispielsweise als Server für Websites oder im Rechenzentrum. Gerne beraten wir Sie in Sachen Opensource und Linux. Wir freuen uns auf Ihren Kontakt.

Mehr Fakten zu Linux finden Sie bei uns im Blog und natürlich in den Tutorials zur Linux-Administration

Centos 7 – firewalld Kommandozeilen-Referenz

,

Firewalld ist unter Centos 7 und RHEL 7 die Nachfolge von iptables. Es erlaubt Linux-Administratoren, neue Sicherheitsregeln zu setzen und sie zur Laufzeit zu aktivieren, ohne bestehende Verbindungen zu trennen.Wir haben im ausführlichen Tutorial zu firewalld schon einmal die unterschiedlichen Konzepte von firewalld unter Centos 7 beleuchtet. Hier sind die wichtigsten Kommandozeilen und Optionen von firewalld:

Firewalld

# firewall-cmd –state                                            gibt an, ob firewalld läuft

# systemctl status firewalld                                 im wesentlichen das Gleiche

# systemctl restart firewall-cmd                         firewalld-Dienst neu starten

# firewall-cmd –reload                                         firewalld-Regel neu laden ohne die bestehenden Verbindungen zu unterbrechen

 

Service firewalld starten / stoppen / aktivieren

# systemctl start firewalld.service

# systemctl stop firewalld.service

# systemctl status firewalld.service

Firewalld beim Systemstart (Boot) aktivieren und starten

Um den Firewall-Dienst zu aktivieren:

# systemctl enable firewalld

Um den Firewall-Dienst zu de-aktivieren:

systemctl disable firewalld

Zonen in firewalld anzeigen lassen:

# firewall-cmd –get-default-zone

# firewall-cmd –get-active-zones

# firewall-cmd –list-all

Schnittstellen / Interfaces zu Zonen zuordnen

Um das Netzwerk-Interface eth1 zu Zone „public“ hinzu zu fügen:

# firewall-cmd –zone=public –change-interface=eth1

Services in Zonen anzeigen

Alle verfügbaren Services anzeigen

# firewall-cmd –get-services

Um etwa “samba” und “samba-client” als Dienst einer bestimmten Zone hinzuzufügen. Hinweis: Der Zusatz „–permanent” hinter dem firewall-cmd Befehl macht die Änderungen dauerhaft (persistente Speicherung), so daß die Regeländerung auch nach dem Neustart des Dienstes oder dem Re-Boot greift.

# firewall-cmd –zone=public –add-service=samba –add-service=samba-client –permanent

Um die Services einer bestimmten Zone anzuzeigen:

# firewall-cmd –zone=public –list-service

Ports in einer Zone

# firewall-cmd –list-ports

# firewall-cmd –zone=public –add-port=5000/tcp

Durchstarten von Netzwerk und firewalld-Dienst

# systemctl restart network.service

# systemctl restart firewalld.service