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:

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

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:

Linux# ssh root@<entfernter Server>

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.

#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.:

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:

ssh root@remotehost.tld „ls –la /root“

ist im Wesentlichen identisch mit:

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:

Linux# ansible <hostname> -m setup
[root@ ansible]# ansible sample.domain.tld -m setup | head -n10
sample.domain.tld | SUCCESS => {
„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:


– 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.

– 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:

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.:

– 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:

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:

– 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.:

– 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

 

Wie Sie firewalld unter Centos 7 nutzen

, ,
Passwort-Manager

firewalld ist eine komplette Firewall-Lösung, die standardmäßig auf CentOS 7 Servern verfügbar ist. Während unter Centos 6 noch iptables zum Einsatz kam, wird unter Centos 7 mit dem Dienst-Programm firewalld gearbeitet. In diesem Tutorial erklären wir, wie Sie als Linux-Administrator eine Firewall für Ihren Centos 7 Server mit firewalld einrichten und Ihnen die Grundlagen der Verwaltung der Firewall mit der firewall-cmd-Befehlszeile erklären.

Grundkonzepte in firewalld

Bevor wir anfangen, wie man das Firewall-cmd-Dienstprogramm zur Verwaltung Ihrer Firewall-Konfiguration verwendet, sollten wir uns mit einigen grundlegenden Konzepten von firewalld vertraut machen.

Zonen in firewalld

Der firewalld Dienst schützt ihren Centos 7 Server

Der firewalld Dienst schützt ihren Centos 7 Server

Der firewalld-Daemon verwaltet Gruppen von Regeln mit Elementen (bzw. Entitäten), die „Zonen“ genannt werden. Zonen sind im Wesentlichen Mengen von Regeln, die definieren, welchen Verkehr je nach dem Vertrauensniveau erlaubt werden soll, das Sie in den Netzwerken haben, mit denen Ihr Computer gerade verbunden ist. Netzwerkschnittstellen werden einer Zone zugeordnet, um das Verhalten zu bestimmen, das die Firewall zulassen soll.

Für Computer, die sich häufig zwischen Netzwerken (WLAN, Arbeit, Zuhause, …) bewegen können (wie Laptops), bietet diese Art von Flexibilität eine gute Methode, um Ihre Regeln abhängig von Ihrer aktuellen Netzwerk-Umgebung zu ändern. Sie können strenge Regeln an Orten verbieten die meisten Verkehr beim Betrieb auf einem öffentlichen WiFi-Netzwerk, während ermöglicht mehr entspannte Einschränkungen, wenn mit Ihrem Heimnetzwerk verbunden. Für einen Server sind diese Zonen nicht so wichtig, da sich die Netzwerkumgebung nur selten ändert.

Unabhängig davon, wie dynamisch Ihre Netzwerkumgebung sein mag, ist es immer noch sinnvoll, mit der allgemeinen Idee hinter jeder der vordefinierten Zonen für firewalld vertraut zu sein. Nachfolgend finden Sie die Zonen die standardmässig in firewalld vorhanden sind, In der Reihenfolge von den wenigsten vertrauenswürdigen zu den meisten vertrauenswürdigen:

  • drop: das niedrigste Vertrauensniveau. Alle eingehenden Verbindungen werden ohne Antwort abgelegt und nur ausgehende Verbindungen (vom Laptop oder Server) sind möglich.
  • block: Ähnlich wie „drop“, aber anstatt einfach nur Verbindungen zu verschieben, werden eingehende Anfragen mit einer icmp-host-deny oder icmp6-adm-deny Nachricht abgelehnt. Im Gegensatz zu oben erhält der Absender also wenigstens eine Antwort
  • public: Repräsentiert öffentliche, nicht vertrauenswürdige Netzwerke. Sie vertrauen anderen Computern nicht, sondern können ausgewählte eingehende Verbindungen von Fall zu Fall zulassen.
  • external: Externe Netzwerke für den Fall, dass Sie die Firewall als Gateway verwenden. Hier ist firewalld für NAT-Masquerading konfiguriert, so dass etwa Ihr internes Netzwerk privat aber erreichbar ist.
  • internal: Die andere Seite der externen Zone, die für den internen Teil eines Gateways verwendet wird. Die Computer sind ziemlich vertrauenswürdig und einige zusätzliche Dienste sind verfügbar.
  • dmz: Wird für Computer verwendet, die sich in einer DMZ befinden (DMZ = demilitarisierte Zone, in der Regel innerhalb eines Rechenzentrums und zwischen zwei Firewalls). Es sind nur bestimmte eingehende Verbindungen erlaubt.
  • work: Wird für PCs & Workstation verwendet. Vertraut den meisten Computer im Netzwerk. Ein paar weitere Dienste sind erlaubt.
  • home: Eine häusliche Umgebung. Es bedeutet im Allgemeinen, dass Sie die meisten anderen Computer vertrauen und dass weitere Dienste akzeptiert werden.
  • trusted: Vertraut allen Maschinen im Netzwerk. Diese offenste der verfügbaren Optionen von firewalld sollte sparsam verwendet werden.

Um die Firewall nutzen zu können, können wir Regeln erstellen und die Eigenschaften der verwendeten Zonen verändern und anschließend unsere Netzwerkschnittstellen den Zonen zuordnen.

Regelbeständigkeit von firewalld

In firewalld können Regeln als permanent oder „immediate“ (im Sinne von „sofort“) bezeichnet werden. Wenn eine Regel hinzugefügt oder geändert wird, wird standardmäßig das Verhalten der aktuell laufenden Firewall geändert und der –immediate Zusatz verwendet. Beim nächsten Stiefel werden die alten Regeln zurückgesetzt – d.h. Änderungen mit „—immediate“ sind nach einem Neustart des firewalld-Dienstes verloren

Bei den meisten Firewall-cmd-Operationen können Sie den –permanent-Zusatz nutzen, um anzugeben, dass nicht die aktuell kaufende Konfiguration gemeint ist, sondern die langfristig gespeicherte. Dies wirkt sich auf den Regelsatz aus, der beim Start von firewalld neu geladen wird. Diese Trennung bedeutet, dass Sie Regeln in Ihrer aktiven Firewall-Instanz testen und dann neu laden können, wenn es Probleme gibt. Sie können auch die –permanent-Flagge verwenden, um einen ganzen Satz von Regeln über die Zeit aufzubauen, die alle sofort angewendet werden, wenn der Reload-Befehl ausgegeben wird.

Starten von firewalld

Bevor Sie anfangen können, Firewall-Regeln mit firewalld zu erstellen, müssen wir den eigentlichen Dienst unter Centos 7 starten. Die Systemdatendatei dazu heißt firewalld.service. Wir können den Dämon für diese Sitzung starten, indem wir folgendes eingeben:

sudo systemctl start firewalld.service

 

Sie können überprüfen, ob der Service läuft und erreichbar ist:

firewall-cmd – State

Sie sehen nun, daß ihr Firewall unter Centos 7 mit der Standardkonfiguration läuft und läuft.

An diesem Punkt werden wir den Service (noch) nicht aktivieren. Die Aktivierung des Dienstes würde dazu führen, dass die Firewall beim Booten gestartet wird. Sie sollten warten, bis Sie ihre Firewall-Regeln fertig erstellt haben und außerdem Gelegenheit hatten, sie zu testen, bevor wir den Dienst beim Starten konfigurieren. So vermeiden Sie , vom Host geblockt zu werden, für den Fall dass etwas schief geht.

firewalld – Basics

Die meisten Kommandos für den firewall-Dienst werden auf der Kommando-Zeile eingegeben

Die meisten Kommandos für den firewall-Dienst werden auf der Kommando-Zeile eingegeben

Bevor wir anfangen, Änderungen vorzunehmen, sollten wir uns mit der Standardumgebung und den Regeln des Dämons vertraut machen.

Standard-Einstellungen von firewalld

Wir können sehen, welche Zone derzeit als Voreinstellung ausgewählt ist, indem Sie Folgendes eingeben:

firewall-cmd –get-default-zone

Ausgabe

public

Da wir Firewall bisher keine konkreten Befehle gegeben haben, die von der Standardzone abzuweichen, und keine unserer Schnittstellen konfiguriert ist, um Sie etwa an eine andere Zone zu binden, ist diese Zone auch die einzige „aktive“ Zone (die Zone, die den Verkehr für unsere kontrolliert Schnittstellen). Sie können das überprüfen, in den Sie folgendes eingeben:

firewall-cmd –get-active-zone

 

Ausgabe:

Public

Interfaces: eth0 eth1

Hier sehen wir, dass wir zwei Netzwerkschnittstellen (eth0 und eth1) haben, die von der Firewall  gesteuert werden. Sie werden beide derzeit nach den für die öffentliche Zone festgelegten Regeln verwaltet.

Wie können Sie nun heraus finden, welche Regeln mit der öffentlichen Zone verbunden sind? Wir können die Konfiguration der Standardzone anzeigen lassen, indem wir Folgendes eingeben:

firewall-cmd –list-all

Ausgabe

Public (Standard, aktiv)

Interfaces: eth0 eth1

sources:

services: dhcpv6-client ssh

ports:

Wir können aus der Ausgabe ableiten, dass diese Zone sowohl die Vorgabe als auch die aktive ist und dass die eth0- und eth1-Schnittstellen mit dieser Zone verbunden sind. Allerdings können wir auch sehen, dass diese Zone die normalen Operationen mit einem DHCP-Client (für IP-Adresszuweisung) und SSH (für Remote-Administration) ermöglicht.

Erforschung alternativer Zonen

Jetzt haben wir eine gute Vorstellung von der Konfiguration für die Standard- und Aktivzone. Wir können auch Informationen über andere Zonen herausfinden.

Um eine Liste der verfügbaren Zonen zu erhalten, geben Sie Folgendes ein:

firewall-cmd -get-zonen

Ausgabe

block dmz drop external home internal public trusted work

Sie können sich die spezifische Konfiguration, die mit einer Zone verbunden ist, anschauen, indem sie den Parameter –zone = in den –list-all-Befehl einfügen:

firewall-cmd – zone = home –list-all

 

Ausgabe

home

Schnittstellen:

sources:

services: dhcpv6-client ipp-client mdns samba-client ssh

ports:

Sie können alle Zonendefinitionen mit der Option –list-all-zones ausgeben. Zur besseren Lesbarkeit sollten Sie den Befehl dann mit „|less“ oder „|more“ kombinieren

firewall-cmd –list-all-zonen | less

 

Auswählen von Zonen für Ihre Netzwerk-Schnittstellen

Sofern Sie nicht Ihre Netzwerkschnittstellen anders konfiguriert haben, wird jedes Interface (also die  Schnittstelle) in die Standardzone gesetzt, wenn die Firewall gebootet wird.

Ändern der Zone einer Schnittstelle für die aktuelle Sitzung

Sie können eine Schnittstelle zwischen den Zonen während einer Sitzung übergeben, indem Sie den Parameter –zone = in Verbindung mit dem Parameter –change-interface = verwenden. Wie bei allen Befehlen, die die Firewall ändern, müssen Sie sudo verwenden.

Zum Beispiel können wir unsere eth0-Schnittstelle in die „home“ -Zone übergehen, indem wir folgendes eingeben:

sudo firewall-cmd – zone = home – change-interface = eth0

Immer wenn Sie eine Schnittstelle zu einer neuen Zone übergeben, sollten Sie sich darüber bewusst sein, dass Sie wahrscheinlich die Dienste ändern, die in Betrieb sein werden. Zum Beispiel bewegen wir uns hier in die „home“ Zone, die SSH zur Verfügung stellt. Das bedeutet, dass unsere Verbindung nicht unterbrochen werden sollten. Einige andere Zonen sind standardmäßig nicht SSH aktiviert und wenn Ihre Verbindung unter Verwendung einer dieser Zonen gekappt wird, können Sie sich nicht wieder anmelden.

Sie überprüfen, dass dies erfolgreich war, indem wir wieder nach den aktiven Zonen fragen:

firewall-cmd –get-active-zonen

 

Wenn die Firewall komplett neu gestartet wird, wechselt die Schnittstelle zur Standardzone:

sudo systemctl restart firewalld.service

firewall-cmd –get-active-zonen

Ausgabe

public

interfaces: eth0 eth1

Zone Ihrer Schnittstelle dauerhaft ändern

Mehr Sicherheit mit der richten Firewalld-Konfiguration unter Centos 7

Mehr Sicherheit mit der richten Firewalld-Konfiguration unter Centos 7

Schnittstellen werden immer auf die Standardzone zurückgesetzt, wenn sie keine alternative Zone haben, die in ihrer Centos  Konfiguration abgespeichert ist. Bei CentOS 7 sind diese Konfigurationen im Verzeichnis /etc/sysconfig/network-scripts mit Dateien des Formats ifcfg-<interface-name> definiert.

Um eine Zone für das Interface zu ändern, öffnen Sie die Datei, die mit der Schnittstelle verknüpft ist, die Sie ändern möchten. Bsp mit eth0 (erste Netzwerkkarte):

vi /etc/sysconfig/network-scripts/ifcfg-eth0

Am unteren Rand der Datei setzen Sie die ZONE = Variable auf die Zone, die Sie mit der Schnittstelle verknüpfen möchten. In unserem Fall wäre das die „home“ -Schnittstelle:

/ etc/sysconfig/network-scripts/ifcfg-eth0

ZONE = home

Speichern und schließen Sie die Datei. (:wq in vi)

Um Ihre Änderungen zu übernehmen, müssen Sie den Netzwerkdienst neu starten – anschließend das Gleiche mit dem firewalld -Dienst:

sudo systemctl restart network.service

sudo systemctl restart firewalld.service

Nachdem Ihre Firewall neu gestartet wurde, können Sie sehen, dass Ihre eth0-Schnittstelle automatisch in die „home“ gesetzt wird:

firewall-cmd –get-active-zones

Ausgabe

home

interfaces: eth0

public

interfaces: eth1

Falls dies nicht die tatsächliche Zone ist, die Sie für diese Schnittstelle verwenden möchten, so machen Sie diese Einstellung einfach wieder rückgängig und starten die beiden Dienste erneut

Einstellen der Standardzone

Wenn Sie alle Ihre Schnittstellen  in einer einzigen Zone verwalten können, ist es wahrscheinlich einfacher, die für Ihren Einsatzzweck passendste Standardzone auszuwählen und diese dann diese für Ihre Konfiguration zu verwenden.

Sie können die Standardzone mit dem Parameter –set-default-zone = jederzeit ändern. Dadurch wird sofort eine beliebige Schnittstelle geändert, die auf die Voreinstellung der neuen Zone zurückgefallen ist:

sudo firewall-cmd –set-default-zone = home

Ausgabe

home

interfaces: eth0 eth1

Festlegung von Regeln für Ihre Dienste & Anwendungen

Die grundsätzlich Art und Weise, Firewall-Ausnahmen für die Dienste zu definieren, die Sie zur Verfügung stellen möchten, ist einfach

Hinzufügen eines Dienstes zu Ihren Zonen

Die einfachste Methode ist es, die Dienste oder Ports, die Sie benötigen, den Zonen zuzuweisen, die Sie hauptsächlich verwenden. Auch hier können Sie mit der Option –get-services eine Liste der verfügbaren Dienste abrufen:

firewall-cmd -get-services

output

dhcp dhcpv6 dhcpv6-client dns ftp … (gekürzt) samba-client smtp ssh telnet tftp tftp-client vnc-server

Hinweis

Sie können weitere Einzelheiten zu jedem dieser Dienste erhalten, indem Sie ihre zugehörige XML-Datei im Verzeichnis/usr/lib/firewalld/services betrachten. Zum Beispiel ist der SSH-Service wie folgt definiert:

/usr/lib/firewalld/services/ssh.xml

<? Xml version = „1.0“ encoding = „utf-8“?>

<Service>

<Short> SSH </ short>

<Description> Secure Shell (SSH) ist ein Protokoll für die Anmeldung und Ausführung von Befehlen auf entfernten Rechnern. Es bietet sichere verschlüsselte Kommunikation. Wenn Sie planen, auf Ihre Maschine remote über SSH über eine Firewall-Schnittstelle zuzugreifen, aktivieren Sie diese Option. Sie benötigen das für diese Option installierte openssh-Serverpaket. </ Description>

<Port protocol = „tcp“ port = „22“ />

</ Service>

Sie können einen Dienst einer Zone mit dem Parameter –add-service = hinzufügen. Die Operation wirkt sich auf die Standardzone oder die Zone, die durch den Parameter –zone = angegeben wird aus. Standardmäßig wird nur die aktuelle Firewall-Sitzung angepasst. Sie können die permanente Firewall-Konfiguration anpassen, indem Sie das –permanent-Flag hinzu fügen..

Wenn wir zum Beispiel einen Webserver mit konventionellem HTTP-Verkehr betreiben, können wir diesen Datenverkehr für Schnittstellen in unserer „öffentlichen“ Zone für diese Sitzung zulassen, indem Sie Folgendes eingeben:

sudo firewall-cmd –zone = public –add-service = http

Sie können den Zusatz „–zone =“ weglassen, wenn Sie die Standardzone ändern möchten. Sie können überprüfen, ob die Operation erfolgreich war, indem Sie die –list-all- oder –list-services-Operationen verwenden:

firewall-cmd – zone = public –list-services

Ausgabe

dhcpv6-client http ssh

Sobald Sie getestet haben, dass alles so funktioniert, wie es sollte, werden Sie wahrscheinlich die permanenten Firewall-Regeln ändern, damit Ihr Service nach einem Neustart weiterhin verfügbar ist. Wir können Zonenänderung der „public“-Zone durch Eingabe durchführen:

sudo firewall-cmd –zone = public –permanent –add-service = http

Sie können überprüfen, ob dies erfolgreich war, indem Sie das –permanent-Flag zum –list-services-Vorgang hinzufügen. Sie müssen sudo für – permanent Abfragen verwenden:

sudo firewall-cmd –zone = public –permanent –list-services

Ihre „public“ Zone erlaubt nun den HTTP-Webverkehr auf Port 80. Wenn Ihr Webserver für die Verwendung von SSL/TLS konfiguriert ist, möchten Sie auch den https-Dienst hinzufügen. Wir können das in der aktuellen Session hinzufügen und die permanente Regel aktivieren bzw. speichern durch Eingabe von:

sudo firewall-cmd – zone = public –add-service = https

sudo firewall-cmd –zone = public –permanent –add-service = https

Wenn kein entsprechender Service vorhanden ist?

Die Firewall-Services, die in der firewalld-Installation enthalten sind, stellen viele der häufigsten Anforderungen für Anwendungen dar, auf die Sie Zugriff haben können. Allerdings kann es Anwendungsfälle geben, in denen diese Dienste nicht Ihren Anforderungen entsprechen.

In dieser Situation haben Sie zwei Möglichkeiten.

Öffnen eines Ports für ihre Zonen

Der einfachste Weg, um Unterstützung für Ihre spezifische Anwendung hinzuzufügen, ist, die Ports zu öffnen, die es in der entsprechenden Zone (n) verwendet. Dies ist so einfach wie die Angabe der Port- oder Port-Bereich und das zugehörige Protokoll für die Ports, die Sie öffnen müssen.

Zum Beispiel, wenn unsere Anwendung auf Port 5000 läuft und TCP verwendet, könnten wir dies in der „public“ Zone für diese Sitzung mit dem Parameter –add-port = hinzufügen. Protokolle können dabei entweder tcp oder udp sein:

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

Sie können überprüfen, dass dies mit der Anwendung –list-ports erfolgreich war:

firewall-cmd –list-Ports

Ausgabe

5000/tcp

Es ist auch möglich, einen sequentiellen Bereich von Ports zu spezifizieren, indem der Anfangs- und End-Port im Bereich mit einem Bindestrich getrennt wird. Zum Beispiel, wenn unsere Anwendung UDP-Ports 4990 bis 4999 verwendet, könnten wir diese auf „public“ durch die folgende Eingabe einstellen:

sudo firewall-cmd – zone = public –add-port = 4990-4999/udp

Nach dem Testen würden wir diese wahrscheinlich der permanenten Firewall hinzufügen wollen. Sie können das tun, indem Sie folgendes eingeben:

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

sudo firewall-cmd – zone = public –permanent –add-port = 4990-4999/udp

sudo firewall-cmd –zone = public –permanent –list-ports

Ausgabe:

4990-4999/udp 5000/tcp

 

Einen Dienst definieren

Blog kein Loch in die Centos Firewall "bohren" ...

Blog kein Loch in die Centos Firewall „bohren“ …

Bestimmte Ports für eine Zone zu öffnen ist einfach. Es kann auf Dauer aber schwierig sein, den Überblick zu behalten, welcher Port-Wert zu welchem Dienst gehört. Wenn Sie jemals einen „Service“ auf Ihrem Server ausschalten, können Sie sich vielleicht nur schwer daran erinnern, welche Ports, die geöffnet wurden, noch erforderlich sind. Um diese Situation zu entschärfen, ist es möglich, eigene Services zu definieren.

Services sind einfach Sammlungen von Ports mit einem zugehörigen Namen und einer Beschreibung. Die Verwendung von Diensten ist einfacher zu verwalten als Ports, erfordert aber etwas Vorarbeit in der Konfiguration von Centos 7. Der einfachste Weg ist das Kopieren eines vorhandenen Skripts (zu finden in/usr/lib/firewalld/services) in das Verzeichnis/etc/firewalld/services, in dem die Firewall nach Nicht-Standarddefinitionen für firewalld sucht.

Zum Beispiel könnten wir die SSH-Service-Definition kopieren, um für unsere „Beispiel“ Service-Definition wie diese zu verwenden. Der Dateiname abzüglich des .xml-Suffixes bestimmt den Namen des Dienstes in der Liste der Firewall-Dienste:

cp /usr/lib/firewalld/services/service.xml /etc/firewalld/services/beispiel.xml

Nun können Sie die Definition in der Datei, die Sie kopiert haben, anpassen:

Sudo nano /etc/firewalld/services/beispiel.xml

Zum Starten enthält die Datei die SSH-Definition, die Sie kopiert haben:

/etc/firewalld/services/beispiel.xml

<? Xml version = „1.0“ encoding = „utf-8“?>

<Service>

<Short> SSH </ short>

<Description> Secure Shell (SSH) ist ein Protokoll für die Anmeldung und Ausführung von Befehlen auf entfernten Rechnern. Es bietet sichere verschlüsselte Kommunikation. Wenn Sie planen, auf Ihre Maschine remote über SSH über eine Firewall-Schnittstelle zuzugreifen, aktivieren Sie diese Option. Sie benötigen das für diese Option installierte openssh-Serverpaket. </ Description>

<Port protocol = „tcp“ port = „22“ />

</ Service>

Der Großteil dieser Definition sind eigentlich Metadaten. Sie werden vermutlich am besten den Kurznamen für den Dienst innerhalb der <short> -Tags ändern. Dies ist ein besser lesbarer Name für Ihren Service. Sie sollten ebenfalls eine Beschreibung hinzufügen, so dass Sie mehr Informationen haben, wenn Sie den Service prüfen (und vorher nicht mehr wissen, wofür er gedacht ist).

Die einzige Ändreug, die Sie machen müssen, die tatsächlich die Funktionalität des Dienstes beeinflusst, wird wahrscheinlich die Port-Definition sein, wo Sie die Portnummer und das Protokoll identifizieren, die Sie öffnen möchten. Dies kann mehrfach angegeben werden.

Für unseren „Beispiel“ -Dienst stellen Sie sich vor, dass wir Port 7777 für TCP und 8888 für UDP öffnen müssen. Wir könnten die bestehende Definition etwas folgendermaßen  ändern:

/etc/firewalld/services/beispiel.xml

<? Xml version = „1.0“ encoding = „utf-8“?>

<Service>

<Short> Beispiel Service </ short>

<Description> Dies ist nur ein Beispiel Service. Es sollte wohl nicht auf einem realen System verwendet werden. </ Description>

<Port protocol = „tcp“ port = „7777“ />

<Portprotokoll = „udp“ Port = „8888“ />

</ Service>

Speichern und schließen Sie die Datei. Laden Sie Ihre Firewall neu, um Zugang zu Ihrem neuen Service zu erhalten:

sudo firewall-cmd – reload

Sie können sehen, dass es jetzt unter der Liste der verfügbaren Dienste ist:

firewall-cmd -get-services

Ausgabe

RH-Satellite-6 amanda-client bacula bacula-client dhcp dhcpv6 dhcpv6-client dns Beispiel ftp hochverfügbarkeit http https imaps ipp ipp-client ipsec kerberos kpasswd ldap ldaps libvirt libvirt-tls mdns mountd ms-wbt mysql nfs ntp openvpn pmcd pmproxy Pmwebapi pmwebapis pop3s postgresql proxy-dhcp radius rpc-bind samba samba-client smtp ssh telnet tftp tftp-client übertragung-client vnc-server wbem-https

Sie können diesen Service jetzt in all Ihren Zonen verwenden.

Eigene Zonen in firewalld erstellen

Während die vordefinierten Zonen für die meisten Benutzer wahrscheinlich mehr als ausreichend sind, kann es hilfreich sein, eigene Zonen zu definieren, die etwa eine andere Benennung oder Beschreibung haben.

Zum Beispiel möchten Sie vielleicht eine Zone für Ihren Webserver mit dem Namen „publicweb“ erstellen. Allerdings möchten Sie vielleicht eine andere Zone für den DNS-Dienst konfigurieren, den Sie in Ihrem privaten Netzwerk bereitstellen. Vielleicht möchten Sie eine Zone namens „privateDNS“ dafür.

Beim Hinzufügen einer Zone müssen Sie diese der permanenten Firewall-Konfiguration hinzufügen. Sie können die Definition dann erneut laden, um die Konfiguration in Ihrer laufenden Sitzung zu verwenden. Zum Beispiel könnten wir die beiden Zonen, die wir oben besprochen haben, wie folgt erzeugen:

sudo firewall-cmd –permanent –new-zone = publicweb

udo firewall-cmd –permanent –new-zone = privateDNS

Sie können überprüfen, ob diese in Ihrer permanenten Konfiguration vorhanden sind, indem Sie Folgendes eingeben:

sudo firewall-cmd –permanent –get-zonen

Ausgabe

block dmz drop external home internal privateDNS public publicweb trusted work

Wie bereits erwähnt, sind diese in der aktuellen Instanz der Firewall noch nicht verfügbar:

firewall-cmd -get-zonen

Ausgabe

block dmz drop external home internal public trusted work

Laden Sie die Firewall neu, um diese neuen Zonen zu aktivieren:

sudo firewall-cmd – reload

firewall-cmd -get-zonen

Ausgabe

block dmz drop external home internal privateDNS public publicweb trusted work

Jetzt können Sie anfangen, die entsprechenden Dienste und Ports zu Ihren Zonen zuzuordnen. Es ist normalerweise eine gute Idee, die aktive Instanz anzupassen und diese Änderungen nach dem Testen in die permanente Konfiguration zu übertragen. Zum Beispiel können Sie für die „publicweb“ -Zone die SSH-, HTTP- und HTTPS-Dienste hinzufügen:

sudo firewall-cmd – zone = publicweb –add-service = ssh

sudo firewall-cmd –zone = publicweb –add-service = http

sudo firewall-cmd –zone = publicweb –add-service = https

firewall-cmd –zone = publicweb –list-all

Ausgabe

Publicweb

(…)

Ebenso können wir den DNS-Service in unsere Zone „privateDNS“ hinzufügen:

sudo firewall-cmd – zone = privateDNS –add-service = dns

firewall-cmd –zone = privateDNS –list-all

Ausgabe

PrivateDNS

Wir könnten dann unsere Interfaces (z.B. eth0) zu diesen neuen Zonen ändern, um sie auszuprobieren:

sudo firewall-cmd – zone = publicweb – change-interface = eth0

sudo firewall-cmd – zone = privateDNS – change-interface = eth1

An dieser Stelle haben Sie die Möglichkeit, Ihre Konfiguration zu testen. Wenn diese Werte für Sie zufriedenstellen funktionieren, wollen Sie die gleichen Regeln der permanenten Konfiguration hinzufügen. Sie können das tun, indem Sie die Regeln mit dem –permanent-Flag erneut anwenden:

sudo firewall-cmd –zone = publicweb –permanent –add-service = ssh

sudo firewall-cmd –zone = publicweb –permanent –add-service = http

sudo firewall-cmd –zone = publicweb –permanent –add-service = https

sudo firewall-cmd –zone = privateDNS –permanent –add-service = dns

Sie können anschließend Ihre Netzwerkschnittstellen ändern, um automatisch die richtigen Zonen auszuwählen. Wir können etwa die eth0-Schnittstelle mit der „publicweb“ -Zone verbinden:

vi /etc/sysconfig/network-scripts/ifcfg-eth0

/etc/sysconfig/network-scripts/ifcfg-eth0

ZONE =publicWeb

Und Sie können die eth1-Schnittstelle mit „privateDNS“ verknüpfen:

vi/etc/sysconfig/network-scripts/ifcfg-eth1

/etc/sysconfig/network-scripts/ifcfg-eth1

ZONE = privateDNS

Anschließend können Sie Ihre Netzwerk- und Firewall-Services neu starten:

sudo systemctl restart Netzwerk

sudo systemctl restart firewalld

 

Überprüfen der korrekten Zuweisung  der Zone(n)

firewall-cmd –get-active-zonen

Ausgabe

PrivateDNS

interfaces: eth1

Publicweb

interfaces: eth0

So prüfen Sie, dass die entsprechenden Dienste für beide Zonen zur Verfügung stehen:

firewall-cmd –zone = publicweb –list-services

Ausgabe

Http htpps ssh

firewall-cmd –zone = privateDNS –list-services

Ausgabe

Dns

Sie haben Ihre eigenen Zonen erfolgreich eingerichtet. Wenn Sie eine dieser Zonen als Standard für andere Schnittstellen machen möchten, denken Sie daran, dieses Verhalten mit dem Parameter –set-default-zone = <ZONE> zu konfigurieren:

Sudo firewall-cmd –set-default-zone = publicweb

Aktivieren des firewalld Dienstes beim Booten

Am Anfang des Tutorials haben wir unseren Firewall-Service gestartet, aber ihn (noch) nicht aktiviert. Wenn Sie jetzt mit Ihrer aktuellen Konfiguration für den firewalld-Dienst zufrieden sind und ihn getestet haben, können Sie den Service aktivieren damit er beim nächsten Reboot des Centos 7 Servers startet.

Das erledigen Sie mit dem Kommando:

sudo systemctl enable firewalld

Wenn der Server neu gestartet wird, sollte ihre Firewall gestartet werden, deine Netzwerkschnittstellen sollten in den  von Ihnen konfigurierten Zonen gelegt werden (oder auf die konfigurierte Standardzone zurückgreifen), und die Regeln, die mit der Zone (n) verknüpft sind, werden auf die zugehörigen Schnittstellen angewendet.

Fazit zu firewalld unter Centos 7

Sie sollten nun ein gutes Verständnis dafür haben, wie Sie den firewalld-Service auf Ihrem CentOS-7-System für den täglichen Gebrauch verwalten können.

Mit dem firewalld-Dienst können Sie Wartungsregeln und Regelsätze konfigurieren, die Ihre konkrete Netzwerkumgebung berücksichtigen. Es ermöglicht Ihnen, nahtlos zwischen verschiedenen Firewall-Richtlinien durch die Verwendung von Zonen zu wechseln und gibt Ihnen bzw. Administratoren die Möglichkeit, das Port-Management in „freundlichere“ Service-Definitionen zu abstrahieren.

Sollten Sie konkrete Fragen zum Einsatz von Centos 7 oder firewalld in der Praxis haben, so stehen Ihnen die IT-Experten vom IT-Dienstleister Biteno GmbH gerne zur Verfügung.

 

Hinweis: Dieser Artikel ist eine sinngemäße Übersetzung von https://www.digitalocean.com/community/tutorials/how-to-set-up-a-firewall-using-firewalld-on-centos-7