Berühmt, berüchtigt, digital – was sind eigentlich Hacker?

,

In der öffentlichen Wahrnehmung sitzen sie in dunklen Stuben vor ihrem Computer. Sie lehnen in schwarzen Hoodies über ihrem Laptop und prellen Unschuldige um ihr Erspartes: Hacker. Doch was steckt tatsächlich hinter dem Computerhacker. Wie verschaffen sie sich Zugriff auf Rechner und Netzwerke und sind Hacker wirklich immer Kriminelle?

Hier geht es um den Begriff des Hackers, die Definition und die wichtigsten Persönlichkeiten. Und natürlich auch um die gängigsten Klischees und deren Entkräftung.

Der Computer gehört nicht zwangsläufig zum Hacker

Klischeebild eines Hackers

Der Begriff des Hackens hat inzwischen seine ursprüngliche Bedeutung in der Popkultur fast schon zurückgewonnen. Bei kreativen Lösungen und beim Tüfteln spricht man vom HackenZopfgummis als Kabelsortierer etwa sind ein Life-Hack.

Entsprechend ist der Begriff des Hackens auch älter als der des Computerhackers. Es geht beim Hacken eher darum, kreative Lösungen zu finden und Probleme zu lösen. Das können kleinere Probleme des Alltags sein, aber eben auch Sicherheitslücken in Programmen und Websites. Der Begriff ist eigentlich gleich mehrfach neutral besetzt, auch moralisch.

Hacker früher und heute

In den 1950er Jahren fanden Hacker dann im Computer ein neues Tool. Sie suchten sich Wege, die Programme und die Technik auszuloten. Mit der Einführung der Vernetzung und der Verbreitung des PC in Haushalten in den 1980er Jahren gewannen Hacker und die gesamte Hackerszene zunehmend an Bedeutung.

Durch das Sammeln privater Nutzer- und Bankdaten, das Aufbrechen von Sicherheitsmechanismen und das Knacken von Datenbanken von Websites oder Phishing bekam der Begriff eine negative Konnotation. Dabei ist der Sammelbegriff für diese Form der Internetkriminalität und den Cyber-Terrorismus eigentlich Cracker.

Phishing, Mal- und Ransomware – die kriminellen Methoden der Cracker

Hacker

Ein Hacker ist nicht zwangsläufig kriminell

In der Hackerszene ist man darauf bedacht, den Begriff des Hackers von dem des Crackers deutlich zu trennen. Angelehnt an den klassischen Western ist im Englischen auch von „White Hats“ und den böswilligen „Black Hats“ die Rede.

So sind es eben Cracker, die mit verschiedenen Formen der Cyberkriminalität versuchen, auf Computer von Nutzern Zugriff zu erhalten. Dies kann verschiedene Formen annehmen. Mal geht es nur darum, blanken Schaden anzurichten. In solchen Fällen werden Anhänge verschickt, welche Computer mit einem Virus infizieren und eine Nutzung unmöglich machen.

Solche Malware kann aber auch nach sensiblen Informationen wie Bankdaten oder persönlichen Fotos suchen oder aber den Computer als Geisel nehmen. Ransomware übernimmt den Rechner und macht eine Nutzung unmöglich, es sei denn der Nutzer zahlt ein Lösegeld.

Auch Phishing-Versuche wie falsche Warnungen zu Konten, Kreditkarten, PayPal oder Phishing-Versuche (wie der nigerianische Prinz) werden oft landläufig als Hacking bezeichnet. Allerdings sind solche Taktiken eher verpönt.

In der Hackerethik ist die verbreitete Sichtweise, dass ein Eindringen (auch böswilliges) in geschlossene Systeme so lange in Ordnung ist wie kein Schaden angerichtet wird.

Hacker und ihr Nutzen für Unternehmen

Große Unternehmen setzen auf Hacker. Start Ups wie Facebook und Google veranstalten regelmäßig sogenannte Hackathons. Hier probieren die Programmierer sich in langen Sessions aus und lassen ihre Kreativität arbeiten.

Auch im Sicherheitsbereich braucht die Industrie Hacker, ansonsten werden Sicherheitslücken am Computer oder in einem Programm eben erst dann bemerkt, wenn es zu spät ist. Wird eine Lücke frühzeitig entdeckt (entweder intern oder durch vergleichsweise harmlose Hacks), so kann sie geschlossen werde, ehe es wirklich zu spät ist.

Denn durch böswillige Hacks wie die massenhafte Erbeutung von Kreditkartendaten bei Sony, Brute Force-Attacken gegen Apples iCloud oder die vorgebliche Akquise von Nutzerdaten der Datingseite Ashley Madison können Unternehmen in ernsthafte Schwierigkeiten geraten. Mit dem Verlust des Kundenvertrauens geht schließlich auch ein finanzieller Verlust einher. Alleine deswegen sind „gesunde“ Hacks auch im wirtschaftlichen Interesse von Unternehmen.

Sind Hacker eine Gefahr für die moderne Informationswelt?

Hacking kann auch sinnvoll sein

Eine große Gefahr, die derzeit am Computer entsteht, und wirklich massive Auswirkungen auf unsere Informationslandschaft und die westliche Demokratie hat, hat mit Hacks nicht einmal etwas zu tunCyberangriffe wie die koordinierten Desinformationskampagnen vor den US-Wahlen fallen nicht unter die Kategorie Hacking. Plattformen wie Facebook und Twitter wurden nicht gehackt, sondern wie vorgesehen genutzt und so missbraucht.

Organisationen wie der deutsche CCC (Chaos Computer Club) haben sich sogar einer sehr deutlichen Ethik verschrieben. Und diese steht eigentlich im Sinne einer besseren Informationskultur und des Datenschutzes der Nutzer: weniger Überwachung, dafür mehr Information und Archivierung durch Verbreitung.

Die Entstehung von „Open Source“

Bereits in den 80ern entwickelte sich in den USA eine Open Source-Kultur, welche quelloffene Programme erstellte. Oder aber die Quellcodes von Programmen veröffentlichte. Daraus entstanden etwa die Betriebssysteme Linux, die Variante Ubuntu, die Photoshop-Alternative GIMP oder Open Office. Die Öffnung des zugrunde liegenden Codes ermöglichte es der Community, beständig Verbesserungen vorzunehmen und entzog die Programme einer zentralisierten Kontrolle. Zudem kann man Lücken und Fehler im Code schneller finden und ausmerzen.

Auch im Sinne einer Software-Archivierung ist die „Erbeutung“ von Programmen relevant, diese Form der Piraterie ist oftmals die einzige Möglichkeit der Erhaltung. Wenn Unternehmen ältere Programmversionen aus ihrem Angebot nehmen, verschwinden diese inzwischen ganz. Ohne physische Medien geht so ein Teil der Informationsgesellschaft verloren. Hacking und Piraterie sind hier – wenn auch nicht legal – die einzigen Wege eines schlüssigen Informationsverzeichnisses.

Hacking auf staatlicher Ebene

Die Guy Fawkes-Maske verbinden viele mit Hackern

Auch auf staatlicher Ebene werden indes Hacker eingesetzt, Deutschland zog mit einer Cyber-Initiative der Bundeswehr vor einigen Jahren erst etwas spät nach. Der Cyber-Terrorismus stellt eine reale Gefahr dar, die im großen Stile sensible Daten erbeuten kann und Infrastruktur wie Stromnetze gefährdet.

Staaten wie Nordkorea stehen seit längerem im Verdacht, durch Hacking an Bitcoin-Börsen eine unauffällige Finanzquelle zu unterhalten. Auch Russland unterhält mehrere Divisionen der Cyber-Kriegsführung. Die Gefahr ist also durchaus real, typisch für den Hacker und die klassische Ethik der Freiheit ist dies allerdings nicht.

Dies hat seit einigen Jahren sogar zu einer besonderen Kategorie unter Hackern geführt, den sogenannten Hacktivists. Diese Mischung aus Hackern und Aktivisten nutzen nichtautorisierte Zugriffe auf Systeme, um auf Missstände und Gefahren hinzuweisen oder gegen illegale Aktivitäten (auch von Regierungen) aufmerksam zu machen.

Die „Namen“ der Szene – einige der größten Hacker

Ein Bild, das immer wieder mit Hackern assoziiert wird, ist der Mann mit der Guy Fawkes-Maske, der am Rechner sitzt. Die Maske erlangte durch den Film „V for Vendetta“ Berühmtheit in der Popkultur und ist ein Symbol des Putsches, historisch bedingt durch den Kanonenpulverplot gegen das britische Parlament.

Die Maske steht außerdem in Verbindung zur Gruppe Anonymous, die seit den frühen 2000ern vage organisiert für soziale Gerechtigkeit steht bzw. stand. Anonymous sind eher digitale Whistleblower, die sich vor Jahren einen Streit mit Scientology lieferten.

Beispiele einzelner bekannter Hacker

Die meisten Hacker bleiben anonym

Einer der Urväter des Hackings ist der US-Amerikaner Kevin Mitnick, in den frühen 80ern hackte er sich ins nordamerikanische Verteidigungsnetzwerk NORAD, später verkaufte er Sicherheitslücken an Meistbietende.

Ein klassisches Beispiel für einen „White Hat“ ist der Amerikaner Adrian Lamo, der aufgrund seiner minimalistischen Ausrüstung und seines Auftretens mit nichts als einem Rucksack auch obdachloser Hacker genannt wurde. Lamo manipulierte etwa Presseartikel und kontaktierte seine Opfer, bisweilen beseitigte er den von ihm zugefügten Schaden sogar.

Deutlich gefährlicher wurde es etwa im Falle des Hackers ASTRA. Ein griechischer Mathematiker, dessen Identität nie öffentlich wurde, erbeutete Software und Datensätze zu Waffentechnologien, die er verkaufte – 2008 wurde er allerdings verhaftet.

Kein System ist sicher

Hacker rein moralisch zu beurteilen ist zu kurz gegriffen. Die teils legale, teils illegale und teils in der Grauzone befindliche Arbeit am Computer ist ein komplexes Feld. Deswegen sollte Hacking keinesfalls auf CyberkriminalitätPhishing und Trojaner reduziert werden.

Vielmehr geht es bei dem Begriff des Computerhackers – ohne Wertung – um die kreative Ausnutzung von Sicherheitslücken, Schwachstellen und Exploits (also ausnutzbaren Fehlern). Diese Denkweise ist, solange kein Schaden entsteht, wichtig für die Softwareoptimierung und die Sicherheit jedes Einzelnen am Computer.

Doch natürlich ist Hacking ein stetes Spannungsfeld zwischen Lausbubenstreich, Freiheitsstreben, böswilligen Angriffen und koordiniertem Aktivismus. Aber so ist dies natürlich nicht nur beim Computerhacking, sondern bei allen kreativen Strategien, die neue Prozesse zu erkunden suchen.

OPSI installieren

,

Einleitung – Software-Verteilung

Software-Installation bzw. Verteilung auf PCs wird in vielen Netzwerken immer noch nach der „Turnschuh“-Methode gemacht. Ein Administrator läuft an den betroffenen Rechner, installiert die gewünschte Software per CD/DVD oder USB-Stick. In den besseren Fällen erfolgt die manuelle Installation remote über Teamviewer oder andere Fernwartungs-Software. – Alles in allem ist die manuelle Installation von Software bzw. Ganzen PCs oder Notebooks vor allem aus zeitlichen Gesichtspunkten nicht effizient.

Besser wäre es einen PC möglichst vollautomatisch zu installieren. Gleiches gilt natürlich für die nachträgliche Installation von Software auf Windows-PCs. Wie lange bräuchte wohl ein IT-Administrator um auf 30 Endgeräten die Aktualisierung der Java-Runtime, des Adobe Acrobat Readers oder einer anderen Software die auf praktisch jedem Endgerät vorhanden ist?

Die Lösung für diesen Zeitfresser sind Software-Tools, die die Inventarisierung und Software-Verteilung im Idealfall vollautomatisch übernehmen. Zum Glück existieren neben kommerziellen Systemen wie SCCM von Microsoft, PDQ-Deploy oder DeskCenter auch Opensource-Kandidaten aus der Gruppe der Software-Deployment-Tools. Eines davon – OPSI (kurz für Open PC Server Integration) – möchten wir heute vorstellen.

OPSI ist Opensource und wird von der deutschen Firma UIB aus Mainz entwickelt. Da OPSI zur Benutzung nicht lizenziert werden muss, kommt die Software oft bei öffentlichen Verwaltungen (Behörden, Schulen, etc.) vor. Aber auch kleinere mittelständische Firmen nutzen OPSI um PCs zu installieren und Software auszurollen.

Was kann OPSI

Der Leistungsumfang von OPSI ist durchaus ansehnlich. Mit dem Software-Deployment-Tool kann der IT-Administrator die folgenden Aufgaben erledigen:

  • Betriebssystem-Installationen (via PXE-Boot oder Boot-CD)
  • Software-Installationen – in der Regel als „Silent“ oder unattended Installation
  • De-Installationen und Updates bestehender Software
  • Betriebssystem-Updates
  • Konfigurationen von Endgeräten (bspw. Domain-Beitritt) etwa in der Registry
  • Inventarisierung von Software und Hardware

Interessant ist hierbei, daß über die Skript-Sprache von OPSI ganz normale cmd Befehle von Windows im Kontext eines Administrators ausgeführt werden können. Damit kann bspw. mit wenigen Zeilen Code etwa die Windows Firewall ein- oder ausgeschaltet werden.

Konzept der Softwareverteiling mit OPSI

OPSI besteht aus einem Linux-Server, auf dem neben mysql (bzw. mariadb) noch Samba installiert sein muss. Der eigentliche Verteilungsmechanismus erfolgt vom Server aus über einen in Java geschriebenen Client, vom den aus der IT-Administrator die Software-Pakete auf die Notebooks und PCs der Anwender verteilt. Auf den Endgeräten muss ein Agent als Dienst für OPSI installiert sein.

Wie auch bei kommerziellen Deployment-Produkten muss zunächst aus der Installations-Datei des jeweiligen Software-Herstellers ein „Paket“ zur automatischen Installation erstellt werden. Diese Paketierung erfolgt bei OPSI in einer Skript-ähnlichen Sprache.

Voraussetzungen

Um OPSI zu testen oder produktiv zu nutzen, benötigt man lediglich einen einfachen Linux-Server. Opsi funktioniert unter allen wesentlichen Linux-Distributionen (Debian, Ubuntu, RHEL, SLES, CentOS, etc.). Für Interessierte stellt der Hersteller UIB auch noch eine fertige virtuelle Maschine für VMWare oder Hyper-V zur Verfügung. Diese kann bereits mit nur einer CPU und 1 GB RAM betrieben werden.

Wer OPSI produktiv einsetzen möchte, sollte eher 2 CPUs und 2-4 GB RAM veranschlagen. Die Größe des Festplatte richtet sich je nach Kundensituation nach

  • Der Anzahl an Endgeräten (diese werden in einer mysql Datenbank gespeichert)
  • Der Summe der Software-Pakete, die später auf der lokalen Freigabe /var/lib/opsi/repository liegen.

Insbesondere die Software-Pakete benötigen Platz. Wer also ein ansehnliches Arsenal an Software hat, die automatisch verteilt werden soll, sollte hier großzügig Plattenplatz einplanen. Hier bietet sich die Installation einer eigenen Partition unter LVM für das Verzeichnis /var/lib/opsi an.

 

Für alles weiter unten Beschriebene nutzen wir ein aktuelles und frisch installiertes CentOS 7 System. Auf diesem haben wir zur Vereinfachung selinx unter /etc/sysconfig/selinux deaktiviert und den firewalld-Daemon deaktiviert. Das Centos selbst bringen wir mit „yum –y update“ und einem Reboot auf den aktuellen Stand.

Installation von OPSI

Der OPSI-Server sollte unbedingt eine statische IP-Adresse erhalten. In unserem Fall hat der Host die IP 10.42.136.89 aus unserem Testnetz.

Wichtig: Hostname und IP müssen einwandfrei im DNS aufzulösen sein. Wer auf Nummer sicher gehen möchte, der trägt in die /etc/hosts Datei die eigene IP und den Hostnamen ein:

1
10.42.136.89 opsiserver2.intern.local

 

Im Test störte dabei noch die per dhcp vergebene IPV6 Adresse. Diese deaktivieren wir wie folgt:

vi /etc/sysctl.conf => dort einfügen

1
2
3
net.ipv6.conf.all.disable_ipv6 = 1

net.ipv6.conf.default.disable_ipv6 = 1

anschließend

1
sysctl -p

Vorbereiten der Installation von OPSI

Zum Betrieb braucht OPSI zwingend eine SQL-Datenbank – hier mariadb – und SAMBA für die Dateifreigaben. Daher installieren wir die Pakete Samba und mariadb:

1
yum -y install mariadb-server samba

Anschließend starten und aktivieren wir Samba, NMB und mariadb

1
2
3
4
5
6
7
8
9
10
11
systemctl start smb.service

systemctl start nmb.service

systemctl start mariadb.service

systemctl enable smb.service

systemctl enable nmb.service

systemctl enable mariadb.service

Mariadb sichern wir anschließend noch ab, setzen ein root-Password für die mysql-Datenbank und unterbrinden außerdem den Zugriff von extern per mysql. Eine ausführliche Anleitung zur Installation von mysql bzw. mariadb finden Sie bei uns im Blog.

1
mysql_secure_installation

Zur Abwärtskompatibilität sollte noch folgendes in die Datei /etc/my.cnf im Abschnit [mysqld] eingefügt werden:

1
sql_mode=NO_ENGINE_SUBSTITUTION

Danach starten wir mysqld bzw. mariadb einmal neu

1
Service mariadb restart

Last but not least installieren wir 5 kleine Helferlein, damit wir gleich OPSI richtig herunter laden und installieren können.

1
yum -y install wget mlocate net-tools yum-utils sysstat

OPSI Installation

Die eigentliche Installation von OPSI erfolgt durch das Herunterladen eines Repositories und dem anschließenden Installieren von zwei Opsi-Paketen, die ihrerseits gut zwei Dutzend Software-Pakete nach sich ziehen.

1
2
3
4
5
6
7
8
9
cd /etc/yum.repos.d/

wget https://download.opensuse.org/repositories/home:uibmz:opsi:4.1:stable/CentOS_7/home:uibmz:opsi:4.1:stable.repo

yum makecache

yum –y install opsi-server opsi-configed

yum –y install opsi-windows-support

Hinweis: Bei den obigen Befehlen werden Sie zwischendurch aufgefordert einen „GPG-Schlüssel 0xD8361F81“ zu importieren. Bestätigen Sie dies mit „j“.

OPSI für den ersten Einsatz konfigurieren

Opsi wird mit wenigen Befehlen für den Einsatz vorbereitet:

1
[root@opsiserver2> opsi-setup --configure-mysql

In der sich öffnenden Maske lassen Sie die ersten beiden Zeilen so wie sie sind. Geben Sie bei “Database admin password“ das root-Passwort des mysql-Benutzers root ein. (Das sollten sie weiter oben bei mysql_secure_installation eingegeben haben).

Sofern Sie das mysql-Passwort des neuen mysql-Benutzers „opsi“ mit setzen möchten, so geben Sie ein entsprechendes neues Passwort in der letzten Zeile ein. Der mysql-Benutzer „opsi“ mit diesem Passwort wird anschließend automatisch angelegt.

Tippen Sie mit der TAB-Taste solange bis SIe auf das Feld “OK” gelangen und drücken Return/Enter.

Die eigentliche Konfiguration von OPSI wird mit dem folgenden Befehl erstellt:

1
2
3
4
5
6
7
8
9
[root@opsiserver2 ~] opsi-setup --init-current-config

(...)

Mit dem folgenden Befehl werden alle notwendigen Berechtigungen gesetzt:

[root@opsiserver2 ~] opsi-setup --set-rights

(...)

Danach werden die beiden Services “opsiconfd” sowie “opsipxeconfd” neu gestartet

1
2
3
[root@opsiserver2 ~] systemctl restart opsiconfd

[root@opsiserver2 ~] systemctl restart opsipxeconfd

Der folgende Befehlt bereitet die für OPSI notwendige Samba-Konfiguration vor.

1
opsi-setup --auto-configure-samba

Anschließend sollten die Samba-Dienste neu gestartet werden:

1
2
3
systemctl restart smb.service

systemctl restart nmb.service

Last but not least benötigt OPSI noch zwei Benutzer (pcpatch und „adminuser“) und passende Berechtigungen

1
opsi-admin -d task setPcpatchPassword

Anschließend legen wir einen neuen Benutzer namens “adminuser” an.

1
useradd -m -s /bin/bash adminuser

Wir vergeben nun Passwörter für Unix:

1
passwd adminuser

Ebenso ein Passwort für Samba für den Benutzer „adminuser“

1
smbpasswd -a adminuser

 

Zum Schluss wird die Gruppenmitgliedschaft für den Nutzer „adminuser“ eingerichtet und getestet. Dies erfolgt mit:

1
usermod -aG opsiadmin adminuser

Der getent-Befehl sollte dann so etwas ausgeben wie:

1
2
3
[root@opsi01 ~] getent group opsiadmin

opsiadmin:x:1001:opsiconfd,adminuser

Alle User, die Software packen (opsi-makepackage), installieren (opsi-package-manager) oder Konfigurationsdateien manuell bearbeiten wollen, müssen zusätzlich in der Gruppe pcpatch sein. Daher fügen wir den neuen Benutzer „adminuser“ der Gruppe pcpatch hinzu:

1
usermod -aG pcpatch adminuser

Anschließend lassen wir OPSI noch zwei Dinge anapssen:

1
2
3
opsi-setup --patch-sudoers-file

opsi-set-rights

Zu guter Letzt starten wir den OPSI-Dienst einmal neu

1
systemctl restart opsiconfd.service

Damit haben wir die eigentliche Installation von OPSI geschafft.

DHCP für OPSI einrichten

OPSI benötigt an sich keinen eigenen DHCP-Server zur reinen Software-Paketverteilung. Lediglich eine funktionierende Namensauflösung mit DNS ist erforderlich. Wer aber mit PXE (Preboot Execution Environment) ganze Betriebssystem-Installationen auf „nackten“ Endgeräten vornehmen möchte, der muss zumindest die PXE-Boot Option mit einem dhcp-Server vornehmen.

Das geht entweder mit einem bestehenden dhcp-Server in dem die next-Server Option passend eingetragen wird. Oder man installiert auf dem OPSI-Server einen dhcp-Dienst, der PCs und Notebooks das PXE-Boot-Image übermittelt, wenn Sie neu installiert werden sollen.

Die gleiche Konfiguration funktioniert übrigens auch mit einer pfsense Firewall und dort aktiviertem dhcpd-Dienst. Hier muss im Abschnitt „Network Boot“ die IP-Adresse des OPSI-Servers im Feld „Next Server“ eingegeben werden. In das Feld „Default Bios file name“ wird „linux/pxelinux.0“ eingetragen

Übrigens: Mit OPSI lassen sich nicht nur Windows 7,8 sowie Windows 10 installieren. Auch die Server-Betriebssysteme Windows 2008 R2, 2012 und Windows 2016 Server lassen sich mit OPSI von der Pike auf installieren.

OPSI Pakete herunter laden.

Um die öffentlich verfügbaren Vorlagen und fertigen Software-Pakete zu nutzen, müssen diese einmalig aus dem Internet herunter geladen werden. Das erledigen Sie mit dem folgenden Befehl „opsi-package-updater“.

Achtung: das dauert je nach Internet-Anbindung zwischen 15 und 30 Minuten – an einer dünnen DSL-Leitung auch gerne länger:

1
opsi-package-updater -v install

Eine bestehende Installation aktualisieren Sie mit:

1
opsi-package-updater -v update

 

Mit der OPSI-Konsole starten

Für den Aufruf der Konsole von OPSI benötigen Sie eine aktuelle Java Runtime (Version 1.8) und einen Browser. Um nun OPSI zu nutzen und die Verwaltungs-Oberfläche aufzurufen, öffnen Sie einen Browser und rufen die nachfolgende URL auf:

Die Java/Web-Konsole von Opsi

Die Java/Web-Konsole von Opsi

https://<servername oder IP>:4447/configed.jnlp

Die Zertifikatswarnung bestätigen Sie. Anschließend wählen Sie die oberste Option „opsi configuration editor (java web start)“ oder direkt über https://<servername oder IP>:4447/configed.jnlp . Es öffnet sich eine Java-Anwendung, die einige Sekunden braucht bis sie vollständig geladen ist. In der anschließenden Maske geben Sie den Admin-User „adminuser“ als Benutzer ein und das vorhin für den Benutzer „adminuser“ vergebene Passwort.

Die Übersicht der Verwaltungskonsole von OPSI sieht dann wie folgt aus. Hier gibt es allerdings im Moment noch nicht viel zu sehen – es fehlen noch die Laptops und PCs.

OPSI-Client Agent einrichten

OPSI Client auf dem PC installieren

OPSI Client auf dem PC installieren

Das Salz in der Suppe jeder Software-Verteilung sind neben den Software-Paketen die Clients (also PCs und Notebooks) die in den Genuss der installierten Software kommen sollen.

Damit Software-Pakete via OPSI auf den Clients automatisch installiert werden können, benötigt jeder PC einen OPSI-Client. Dieser muss einmal installiert werden und stellt anschließend die Verbindung zwischen PC und OPSI-Server her.

Es gibt dabei zwei Möglichkeiten, wie der OPSI-Client installiert werden kann:

  • Vom PC aus über die Freigabe \\<opsiserver>\opsi_depot
  • Vom OPSI-Server aus über die c$ Freigabe des Clients

Installation des Agenten über die „Opsi_depot“ Freigabe

Dazu verbinden Sie von dem PC, den Sie in Opsi einbinden möchten die OPSI-Freigabe \\<opsiserver>\opsi_depot mit einem freien Laufwerksbuchstaben auf dem PC.

Dort wechseln Sie ins Verzeichnis opsi-client-agent und führen die Datei „service_setup.cmd“ aus. Sobald das abgeschlossen ist, rebooten Sie den PC.

1
C:\Users\&gt;net use z: \\opsiserver2\opsi_depot /user:pcpatch

Geben Sie das Kennwort für „pcpatch“ ein, um eine Verbindung mit „opsiserver2“ herzustellen:

1
2
3
4
5
6
7
Der Befehl wurde erfolgreich ausgeführt.

C:\Users\&gt; z:

Z:\&gt;cd opsi-client-agent

Z:\opsi-client-agent&gt;service_setup.cmd (return)

Nach der eigentlichen Installation wird noch der Zugang zu OPSI benötigt. Dazu muss interaktiv am Client der Benutzername (bspw. pcpatch oder adminuser) sowie das dazu passende Passwort eingegeben werden.

Achtung: Direkt danach bootet der PC ohne weitere Rückfragen.

Hinweis: Das Skript „service_setup.cmd“ kann auch mit dem Parameter /u aufgerufen werden und verhält sich dann fast „silent“.

 

Nach dem Reboot sollte der PC mit seinem Clientnamen in der OPSI GUI auftauchen.

Installation des OPSI-Agenten vom Server aus

Mit dem Befehl „opsi-client-agent“ aus dem Verzeichnis „/var/lib/opsi/depot“ können Sie auch vom Server aus einen PC aufnehmen. Voraussetzung ist das Vorhandensein der Datei winexe.exe . Außerdem benötigt der PC eine offene c$ Freigabe. Außerdem brauchen sie ein Benutzerkonto auf dem PC sowie das Passwort dazu.

In unseren Tests hakte es bei der Vorgehensweise deutlich öfter als bei der Installation vom PC aus.

Der Vollständigkeit halber:

1
2
3
[root@] cd /var/lib/opsi/depot/opsi-client-agent

[root@] ./opsi-deploy-client-agent -u boehmichen -p --h

 

Mit OPSI Software automatisiert auf dem PC installieren

Mit OPSI ein Software-Paket auf den Client installieren

Mit OPSI ein Software-Paket auf den Client installieren

Auch wenn in der nackten Installation von OPSI kaum fertige Pakete für Windows vorhanden sind, kann man doch zumindest das Paket zur Hardware-Inventarisierung sowie das für die Software-Inventarisierung installieren.

Um grundsätzlich eine vorhandene Software als Paket zu installieren muss man

– Den Client links auswählen (1)

– Im Reiter „Produktkkonfiguration“ (2) die gewünschte SW auswählen.

– In der Spalte „Angefordert“ (3) der jeweiligen Zeile der Software „Setup“ auswählen (4) – das ist relativ klein geschrieben.

– Anschließend die Zeile nochmal auswählen (1) und rechts-Klick -> Speichern (2)

– Danach kann ebenfalls mit einem Rechts-Klick die „On demand“ (3) Installation starten (Alternativ: booten)

 

Sofern ein Benutzer angemeldet ist, erscheint nur wenige Sekunden danach beim Anwender ein kleines Popup. Danach startet die jeweilige Installation.

 

Sofern kein Benutzer angemeldet ist, so startet die anstehende Software-Installation oder Software-Änderung nach dem nächsten Reboot vor der ersten Anmeldung

 

Schritt 2 der Software-Zuweisung: Speicher und Starten

Schritt 2 der Software-Zuweisung: Speicher und Starten

 

Für den Administrator ist direkt nach der Installation durch ein erneutes Laden der Daten vom OPSI Server sichtbar, ob die Installation erfolgreich war. Falls ja, wird die Versions-Nummer der Software in grün in der betreffenden Zeile angezeigt.

Wer jetzt auf den Geschmack gekommen ist, der sollte nach Möglichkeit den OPSI-Agenten automatisiert per Group-Policy auf den betroffenen Rechnern einrichten.

OPSI – weitere Schritte

Die eigentliche Arbeit besteht bei OPSi wie auch allen anderen Software-Deployment Tools darin, die genutzte Software zu paketieren und testen.

Um diese anstehenden Aufgaben zu vereinfachen, werden bei OPSI zwei Software-Produkte zur Verfügung gestellt. Dies sind zum einen eine Analyse-Software für bestehende *.exe oder MSI-Installer und eine weitere mit der die eigentliche Paketierung und Veröffentlichung erfolgt.

Der OPSI Setup Detector analysiert bestehende MSI und EXE-Installer

Der OPSI Setup Detector analysiert bestehende MSI und EXE-Installer

Der „opsi Setup Detector“ ermittelt aus bestehenden Installern möglichst viele Informationen um anschließend eine möglichst automatische und Bediener-lose Installation zu ermöglichen.

Mit dem OPSI Package Builder werden die Software-Installationen paketiert.

Mit dem OPSI Package Builder werden die Software-Installationen paketiert.

Mit dem  „Opsi Package Builder“ können IT-Administratoren mit relativ wenig Aufwand die Paketierung der notwendigen Software selbst vornehmen.

Ebenso ist es natürlich möglich bestehende, fertige paketierte (freie) Software aus öffentlichen Repositories herunter zu laden und in den eigenen OPSI Server zu integrieren.

An dieser Stelle sei der Hinweis auf das öffentliche Wiki bzw. das Forum von OPSI für die weitere Lektüre erlaubt.

Mehr Infos zu Opsi

Opsi an sich ist sehr gut dokumentiert. Allein die Doku zur Erst-Installation umfasst fast 100 Seiten. Die Dokumentation zur Paketierung ist ebenfalls mehr als ausführlich.

Darüber hinaus finden sich bei Youtube (https://www.youtube.com/watch?v=KW5J3Ymw9NQ&feature=youtu.be ) einige kurze Videos, die interessierten IT-Entscheidern den ersten Überblick erleichtern:

Wer sich intensiver mit OPSI auseinander setzen möchte, dem rate ich zuerst zur Lektüre des „OPSI Getting Started“ PDF . Dort wird nicht nur die Installation von OPSI beschrieben. Im zweiten Teil wird auch exemplarisch beschrieben, wie eine Software-Paketierung abläuft und welche Schritte man als IT-Administrator durchführen muss um eigene bzw. lizenzierte Software zu paketieren.

Im eigentlichen Handbuch zu OPSI 4.1 wird auf knapp 400 Seiten sehr ausführlich erläutert, wie die Verwaltung der PCs sowie Software mit OPSI funktioniert. Die OPSI-Skript-Sprache zur Paketierung selbst ist ebenfalls mit einem separaten über 200 Seiten langen PDF ausführlich dokumentiert.

Fazit zu Opsi

OPSI macht als Software-Verteilungs-System einen sehr robusten und mittlerweile auch ausgereiften Eindruck. Geübte Admins mit Basis-Linux-Kenntnissen sollten in wenigen Stunden in der Lage sein, ein funktionierendes Test-System zu installieren und zu nutzen. Wie hoch der tatsächliche Nutzen im Tagesgeschäft ist, hängt natürlich von Fall zu Fall von der Diversität der eingesetzten Software ab.

IT-Admins, die Netze mit mehr als 30 PCs verwalten, sollten auf jeden Fall OPSI einmal testen. Es lohnt sich.

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.

Ceph deep scrub error beheben

, ,

Ceph deep scrub error beheben

Wer Ceph produktiv betreibt, wird im Laufe der Zeit immer mal wieder einen „unhealthy“ Zustand des Clusters erleben. Solange es sich dabei um eine noch harmlose „Ceph Warning“ geht, ist der gesunde Zustand des Clusters oft schnell wieder erreicht. Oft sogar ganz von alleine ohne ein Zutun des Linux-Administrators.

Doch was tun wenn „plötzlich“ ein echter Fehler auftritt? Mit „ceph health detail“ erfahren wir auf einen Blick, was das Cluster macht. In unserem konkreten Fall war Ceph ohne Vorwarnung auf unserem frisch installierten Proxmox Cluster in einen „Health Error“ gewechselt.

root@pve02:/var/log/ceph# ceph health detail
HEALTH_ERR 129254/2436848 objects misplaced (5.304%); 1 scrub errors; Possible data damage: 1 pg inconsistent
OBJECT_MISPLACED 129254/2436848 objects misplaced (5.304%)
OSD_SCRUB_ERRORS 1 scrub errors
PG_DAMAGED Possible data damage: 1 pg inconsistent
pg 4.41 is active+remapped+inconsistent+backfill_wait, acting [0,10]

In Folge einer neu eingebauten Platte ergaben sich eine überschaubare Menge (5,3%) von Placement Groups (pg), die nun nicht mehr richtig verteilt waren. In einer normalen Ceph Umgebung wäre das Thema in wenigen Stunden von alleine erledigt gewesen.

Im konkreten Fall haben wir aber eine Placement Group, die ein echtes Problem hat: PG 4.41.

Diese PG liegt sowohl auf OSD.0 als auch OSD.10 – zu erkennen an [0,10] -> hier werden die OSD Nummern aufgelistet.

Ceph deep scrub error analysieren

Um das Problem genauer zu analysieren loggen wir uns also per ssh auf den jeweiligen ceph hosts an auf  denen die osds liegen bzw. die OSD-Prozesse laufen. Pro Ceph-OSD liegt unter /var/log/ceph ein einzelnes Log-File. Wir schauen uns nun genau das Logfile des OSD-Prozesses an, der von Ceph selbst in der obigen Meldung ausgegeben wird.

Pve02# cd /var/log/ceph
(host mit osd.10)
cat ceph-osd.0.log | grep -i 4.41
-> viel output -> suche nach „error“ oder „fail“
=> kein Ergebnis

Da der erste Host keinen Fehler anzeigt, muss also die andere potentielle OSD, auf der die Placement Group liegt, ein Problem haben. Wie loggen uns also auf dem Host ein  auf dem die OSD.0 liegt

root@pve01# cd /var/log/ceph
root@pve01:/var/log/ceph# cat ceph-osd.10.log | grep -i 4.41
(…)
2018-06-21 20:05:48.793010 7fc78b0f3700  0 log_channel(cluster) log [DBG] : 4.41 deep-scrub starts
2018-06-21 20:06:23.380373 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 shard 0: soid 4:823a7476:::rbd_data.2862f74b0dc51.0000000000006060:head candidate had a read error <== Hier beginnt das Problem
2018-06-21 20:07:04.032674 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 deep-scrub 0 missing, 1 inconsistent objects
2018-06-21 20:07:04.032681 7fc78b0f3700 -1 log_channel(cluster) log [ERR] : 4.41 deep-scrub 1 errors
2018-06-21 20:18:38.424228 7fc7830e3700  4 rocksdb: (Original Log Time 2018/06/21-20:18:38.424147) [/home/builder/source/ceph-12.2.5/src/rocksdb/db/memtable_list.cc:383] [default] Level-0 commit table #451: memtable #1 done

Dem Logfile nach liegt also auf der OSD.10 vermutlich das Problem.

 

Lösungsansatz zur Behebung des Deep Scrub Error

Wir entfernen temporär die OSD.10 aus dem Cluster und „zwingen“ Ceph die Placement Groups neu zu verteilen. Die Lösung dabei ist höchst einfach:

Befehl: ceph osd out osd.<OSD_ID>

 

root@pve01:/var/log/ceph# ceph osd out osd.10
root@pve01:/var/log/ceph# ceph osd df
ID CLASS WEIGHT  REWEIGHT SIZE   USE   AVAIL  %USE  VAR  PGS
8   hdd 1.81929  1.00000  1862G  485G  1377G 26.05 0.80  51
9   hdd 1.81929  1.00000  1862G  677G  1185G 36.38 1.12  72
10   hdd 1.63730        0      0     0      0     0    0  52
11   hdd 1.63730  1.00000  1676G  534G  1142G 31.86 0.98  57
12   hdd 1.81929  1.00000  1862G  479G  1383G 25.76 0.79  51

 

Nun ist die OSD 10 ist raus und 52 Placement Groups müssen verschoben bzw. neu auf die restlichen Platten verteilt werden. Mit „ceph –w“ können wir den laufenden Status des Ceph Clusters permanent überwachen. Dort kann man nach einigen Minuten auch anhand der sich verkleinernden Prozentzahl hochrechnen, wie lange der Umverteilungs-Vorgang noch dauern wird.

Weitere Infos zum Deep Scrub Error

 

Proxmox Virtual Environment – PVE

,

Proxmox Virtual Environment (kurz PVE) ist eine auf Debian-Linux und KVM basierende Virtualisierungs-Plattform zum Betrieb von Gast-Betriebssystemen. Proxmox ist frei verfügbar – kommerzieller Support kann über den Hersteller (Fa. Proxmox Server Solutions GmbH in Wien) erworben werden.

Proxmox benötigt, um im Verbund (Cluster) stabil zu laufen mindestens 3 physische Server.

Homepage von Proxmox: https://www.proxmox.com/de/

Vorteile von Proxmox:

Gegenüber Hyper-V, VMWare, Openstack oder Cloudstack hat Proxmox einige Vorteile auf Lager:

  • Proxmox läuft auf fast jeder x86-Hardware
  • Die Installation ist in weniger als 5 Minuten pro Host erledigt
  • Proxmox kann ab 3 Servern Hochverfügbarkeit abbilden.
  • Es fallen keine Lizenzkosten an da Proxmox OpenSource ist und der Hypervisor auf KVM basiert

Gegenüber den bekannten Cloud-Plattformen wie VSphere, Openstack oder Cloudstack hat Proxmox noch den Vorteil, dass die Verwaltungs-GUI auf den Virtualisierungs-Hosts mit läuft. Somit sind keine zusätzlichen Hosts für Administration oder das Management des Clusters notwendig

Einschränkungen von Proxmox:

Proxmox verwendet für das Management des Clusters corosync. Corosync kann maximal 32 Knoten verwalten bzw. steuern. D.h. die maximale Anzahl an Hosts für Virtualisierung und Storage beträgt bei einem Proxmox Cluster 32 physische Server.

Installation von Proxmox

Bevor Sie Proxmox nutzen können, sollten Sie sich das aktuelle ISO-Image bzw. den ISO-Installer unter https://www.proxmox.com/de/downloads/category/iso-images-pve herunterladen.

Es empfiehlt sich das Image entweder auf eine DVD oder besser auf einen USB-Stick (min. 1 GB groß) zu ziehen. Für das Aufspielen auf einen Stick eignet sich z.B. die Software Etcher. (Download: https://etcher.io/)

Voraussetzungen / Mindest-Anforderungen

Um Proxmox stabil zu betreiben, sollten folgende Anforderungen erfüllt sein

  • 3 Hosts bzw. physikalische Server
  • Zentrale Storage (wenn VMs live verschoben werden sollen) – etwa Ceph oder NFS
  • Auf den Hosts, die Virtualisierung anbieten, müssen in der CPU zur Virtualisierung die VT Erweiterung aktiviert sein.

Wichtig: Wenn im laufenden Betrieb später virtuelle Maschinen live verschoben werden sollen, muss die Benennung der Netzwerk-Interfaces (NIC) auf den Hosts gleich sein.

Das Standard-Interface für den internen LAN-Anschluss heißt „vmbr0“. Ein externes Interface sollte „vmbr1“ benannt werden.

Sofern Disk-Images von virtuellen Maschinen zentral – z.B. über Ceph – abgespeichert werden, so sollten 10G-Switche eingesetzt werden. Die an das 10G-Netzwerk angeschlossenen Proxmox-Hosts benötigen selbstverständlich mindestens einen 10G-Netzwerkanschluss.

Vorbereitung:

Hostnamen und IP-Adressen der Proxmox-Hosts lassen sich nachträglich nur schwer ändern. Bevor Sie mit der Installation starten, sollten Sie die Hostname und die (internen) IP-Adressen der zu installierenden Hosts festlegen:

HostnameIP-AdresseNetzmaskePasswort
pvehost0110.20.30.1/24
Pvehost0210.20.30.2/24
Pvehost0310.20.30.3/24

 

Proxmox

Begrüßungsbildschirm von Proxmox

Installation des ersten Servers

Booten Sie den ersten Server von der DVD bzw. ihrem USB-Stick. Sofern das ISO-Image korrekt erkannt wurde, begrüßt Sie Proxmox mit dem folgenden Bildschirm:

Klicken Sie auf „Install Proxmox VE“. Im nächsten Screen müssen Sie lediglich die Lizenzbedingungen von Proxmox bestätigen. Klicken Sie anschließend rechts unten auf „Next“.

Auswahl der Boot-Partition

Auf der folgenden Seite wählen Sie bei „Target Harddisk“ ihre Boot-Partition aus, auf der Proxmox gleich installiert wird. Bei einer Standard-Installation auf physischer Hardware wird die erste Festplatte in der Regel „/dev/sda“ heißen.

Hinweis: Die Festplatte wird vor der Installation partitioniert, d.h. alle Daten auf der Partition werden gelöscht.

 

Länder- und Tastaturauswhl

Nachfolgend wählen Sie das Land und das Tastaturlayout für Ihren Server und klicken wieder auf „Next“.

 

In der nächsten Maske setzen Sie bei (1) das Passwort für den root-Account fest und tragen unter (2) eine E-Mail Adresse ein.

Passwort und Email-Adresse

Hinweis: Die E-Mail muss valide sein. Fake-Emails funktionieren nicht.

 

Weitere Festlegungen

In der letzten Maske legen Sie unter (1) das interne Netzwerk-Interface fest.

Hinweis: Da Server in der Regel mehrere NICs haben, prüfen Sie bitte vorher, welcher NIC zu welchem Anschluss gehört

Unter (2) tragen Sie den vollständigen Hostnamen (fqdn, inkl. Domain) ein. In (3) kommt die IP-Adresse rein und darunter die Netzmaske, der Gateway und DNS-Server.

Wenn Sie anschließend auf „Next“ klicken, startet die eigentliche Installation von Proxmox. Der Installationsvorgang von Proxmox dauert je nach Hardware zwischen 3 und 5 Minuten pro Host.

Sobald der Installationsvorgang erfolgreich beendet wurde, werden Sie aufgefordert, den neu installierten Host zu rebooten. Entfernen Sie den USB-Stick bzw. die DVD und rebooten Sie den Host.

Sie können sich für die meisten nachfolgenden Aufgaben nun über das Web mit ihrem neuen Host verbinden: https://<IP>:8006/

Erstellung der Cluster-Config auf dem ersten Host

Damit Sie später einen weiteren, bzw. mindestens zwei weitere Hosts in ihr Proxmox-Cluster aufnehmen können, müssen Sie zunächst eine Cluster-Konfiguration erstellen. Loggen Sie sich dazu auf dem gerade installierten Host ein.

Wichtig: Diese Einrichtung des Clusters können Sie nur genau einmal machen.

(Entweder über ssh oder die Web-GUI -> Server (links) -> Shell (rechts)

Screenshot des einzugebenden Kommandos

Geben Sie folgendes Kommando ein:

1
root@pvehost01:  pvecm create &lt;clustername&gt; # ersetzen Sie “clustername” durch den Namen ihres Clusters.

 

Prüfen Sie den Status des neu erstellten Clusters mit dem Befehl:

root@pvehost01:~# pvecm status

 

Die Ausgabe sollte in etwa ähnlich wie das Folgende aussehen:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
Quorum information
------------------
Date:             Wed Jan 17 17:50:12 2018
Quorum provider:  corosync_votequorum
Nodes:            1
Node ID:          0x00000001
Ring ID:          1/4
Quorate:          Yes
Votequorum information
----------------------
Expected votes:   1
Highest expected: 1
Total votes:      1
Quorum:           1
Flags:            Quorate

Membership information
----------------------
Nodeid      Votes Name
0x00000001          1 10.20.30.1 (local)

Installation weiterer Server

Jeden weiteren Server installieren Sie so wie den ersten Server. (selbstverständlich mit einem anderen Hostnamen und einer unterschiedlichen IP-Adresse).

Sobald die Installation fertig ist, loggen Sie sich auf dem zweiten Server ein und melden den neuen Host am bestehenden Cluster an. Dazu verwenden Sie als Ziel-IP-Adresse im folgenden Kommando die IP eines Hosts, der bereits im Cluster Mitglied ist.

Geben folgendes Kommando ein: pvecm add <IP-des-ersten-Hosts>

Bsp.:

1
2
3
4
5
6
7
8
9
10
11
12
13
root@pvehost02:~# pvecm add 10.20.30.1
The authenticity of host '10.20.30.111 (10.20.30.1)' can't be established.
&lt;…&gt;
Are you sure you want to continue connecting (yes/no)? yes
root@10.20.30.1's password:
copy corosync auth key
stopping pve-cluster service
backup old database
waiting for quorum...OK
generating node certificates
merge known_hosts file
restart services
successfully added node 'pvehost02' to cluster.

Prüfen des Cluster-Status’

Den Status des 2-Knoten-Clusters prüfen Sie wieder mit “pvecm status”:

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
root@pvehost02:~# pvecm status
Quorum information
------------------
Date:             Wed Jan 17 17:59:36 2018
Quorum provider:  corosync_votequorum
Nodes:            2
Node ID:          0x00000002
Ring ID:          1/8
Quorate:          Yes

Votequorum information
----------------------
Expected votes:   2
Highest expected: 2
Total votes:      2
Quorum:           2
Flags:            Quorate

Membership information
----------------------
Nodeid      Votes Name
0x00000001          1 10.20.30.1
0x00000002          1 10.20.30.2 (local)

Wichtig ist hier der Eintrag Expected Votes und Total Votes. Diese beiden Werte (hier „2“) sollten identisch sein.

Übersicht über die Proxmox-Web-GUI

Sobald der erste Host im Netz aktiv ist, können Sie sich über die Web-GUI am Cluster anmelden. Grundsätzlich ist die Anmeldung an jedem Host über die folgende URL möglich:

https://<IP>:8006/ ; ersetzen Sie die IP durch die IP eines Hosts bzw. dessen Hostnamen.

GUI Übersicht

Als Benutzernamen verwenden Sie „root“ und das Passwort, das Sie während der Installation eingegeben haben.

Die Elemente der GUI

Links oben: (1) Auswahl der Ansicht für die linke Baumstruktur

Links: (2) Baumstruktur (Server, Pools)

Oben Mitte (3): Suchfunktion

Rechts: Anzeige oder Bearbeiten eines Elements (Datacenter, Host, Gast). Innerhalb des Fensters ist wiederum links eine Leiste für die Befehle (4), um das jeweilige Objekt (Cluster, Host, Gast) zu verändern. (5)

Rechts oben: (6) Kommando-Buttons zum Erstellen von VMs/Containern

Unten: (7) Status-Leiste

Die Elemente der GUI

In der Standard-Übersicht des so genannten Rechenzentrums bzw „Datacenters“ sehen Sie den Status aller Knoten, sowie die CPU, RAM (Hautpspeicher) und Storage-Auslastung des gesamten Clusters.

Um in Proxmox ein Element (Host, Gast oder das Cluster) zu verändern, klicken Sie zunächst links auf das Element (2), das Sie verändern oder ansehen möchten. Anschließend bearbeiten Sie die Einstellung in der Menüleiste des Elements (4).

Konfiguration des Proxmox – Clusters für den Betrieb

Um das Cluster für den echten Betrieb mit Hosts vorzubereiten, müssen nun noch die zentralen Ablagen für ISO-Images bzw. Templates sowie die Speicherung der virtuellen Festplatten der Gast-Betriebssysteme eingerichtet werden. Ebenso benötigen wir ein Verzeichnis, in das Datensicherungen (Backups) und Snapshots der virtuellen Maschinen gespeichert werden können.

Hinweis: Proxmox kann selbstverständlich die Templates und Maschinen-Images lokal auf dem jeweiligen Proxmox-Host speichern. Dann könnten die virtuellen Maschinen aber nicht im laufenden Betrieb verschoben werden.

Unterstützte Speicher von Proxmox

Speicherarten

Neben der lokalen Speicherung (in der Regel LVM) unterstützt Proxmox die folgenden Speicherarten

  • Verzeichnis(se)
  • LVM
  • LVM thin
  • NFS
  • GlusterFS
  • iSCSI
  • RBD (Ceph), von Proxmox gemangt
  • RBS (Ceph), externes Cluster
  • ZFS
  • ZFS über iSCSI

 

Hinweis zu Ceph: Proxmox unterstützt Ceph nicht nur sehr gut. Ceph kann auch über Proxmox selbst installiert und verwaltet werden. Im Gegensatz zur reinrassigen Ceph-Installation ist die Verwaltung von Ceph in Proxmox selbst (Option RBD(PVE)) auch für nicht Linux-Administratoren gut zu erledigen, da sie durch den Hersteller von Proxmox etwas vereinfacht wurde.

Generell können nicht alle Storage-Formen auf allen Speicher-Arten abgespeichert werden. Was genau auf welchen Storage-Arten abgespeichert werden kann, entnehmen Sie der folgenden Übersicht:

StorageDisk-ImageISO-ImageContainer TemplateVZ-BackupsContainer
Verzeichnisxxxxx
LVMXX
LVM-ThinXX
NFSxxxxx
iSCSI
GlusterFSXXXX
RBD (PVE)XX
RBD (external)XX
ZFS iSCSI
ZFSXX

 

Templates-Verzeichnis einrichten

In unserem Test-Cluster fügen wir nachfolgend ein Template-Verzeichnis für ISO-Images auf NFS-Basis hinzu. Das NFS-Verzeichnis kann dabei auf einem auf einem Proxmox-Host, einem anderen Linux-Server oder auch auf einer NAS liegen.

Sie benötigen:

  • Die IP-Adresse bzw. den Hostnamen des NFS-Servers
  • Den Namen der NFS-Freigabe

Templates-Verzeichnis Schritt für Schritt einrichten 1

Um das zentrale Verzeichnis für die Templates einzurichten, klicken Sie oben auf Datacenter (1) und anschließend im rechten Menü auf Storage (2) und danach auf hinzufügen (3) und wählen „NFS“ aus.

Templates-Verzeichnis Schritt für Schritt einrichten 2

In der darauffolgenden Maske tragen Sie unter (1, ID) einen möglichst sprechenden Namen für ihr Verzeichnis ein.

In (2) kommt die IP-Adresse (alternativ. Der Hostname) und unter (3) der Pfad des NFS-Exports. Bei Inhalt (4) wählen Sie „Container Template“. Achten Sie darauf, daß keine weiteren Inhalte ausgewählt sind. Sofern Sie die Templates nur bestimmten Servern zur Verfügung stellen wollen, können Sie das unter (5) einstellen. Klicken Sie zum Erstellen auf „Hinzufügen.“

Templates-Verzeichnis Schritt für Schritt einrichten 3

Um den Inhalt des Speicher-Orts anzuschauen, klicken Sie links in der Struktur-Leiste auf einen der Proxmox-Hosts und dort auf ihr neu angelegtes Verzeichnis (hier: ISO-Images (1)). Anschließend auf Inhalt (2). Über den Button Hochladen (3) können Sie jedes ISO-Image (bspw. eine DVD oder CD mit einem Windows oder Linux-Betriebssystem) hochladen. Die Images können Sie später den virtuellen Maschinen als DVD-Laufwerksinhalt bereitstellen.

ToDo Laden Sie nun ein ISO-Image in den Speicherbereich für Templates hoch. Zum Testen können Sie etwa ein Image von CentOS oder anderen Linux-Distributionen nutzen. Diese sind kostenfrei. Selbstverständlich geht auch jedes Image einer Windows-Installations-CD/DVD.

Speicher für Disk-Images einrichten

Auf die gleiche Weise wie für die Templates richten Sie nun einen Speicherort für die Disk-Images der virtuellen Maschinen ein. Hier werden die virtuellen Festplatten der Gast-Betriebssysteme abgelegt.

Speicher für Disk-Images einrichten

Hinweis: Auf die Disk-Images (also die virtuellen Festplatten) greifen die Gäste permanent zu. Im Gegensatz zu den Templates, sollte der dieser Speicherort sowohl über schnelle Festplatten und eine sehr gute Netzwerk-Anbindung verfügen.

Wir fügen nun (als Beispiel) einen Speicherpool für Ceph als Ort für Disk-Images hinzu. Klicken Sie zunächst ganz oben links wieder auf Datacenter, anschließend auf Storage und danach auf „Hinzufügen“.

Vergeben Sie wieder einen sprechenden Namen für Ihren Speicherort (1) und wählen hier im Fall von Ceph (2) den passenden Pool aus. Über die Auswahl bei Inhalt (3) legen Sie fest, was hier gespeichert werden darf. In unserem Fall ist das „Disk-Image“.

Speicher für Datensicherungen einrichten

Speicher für Datensicherung einrichten

Der Speicherort für Datensicherungen muss nicht extrem schnell sein. Hier benötigen Sie in der Regel jedoch ein hohes Volumen, je nachdem wie viele Snapshots und Datensicherungen sie von den virtuellen Gästen erstellen möchten.

Die Vorgehensweise ist identisch mit der Einrichtung des Template- bzw. Disk-Image-Speicher. Sie können unter „Verzeichnis“, NFS und GlusterFS wählen. Achten Sie lediglich darauf, daß Sie als Speicherinhalt „VZDump Backup file“ auswählen.

Einrichten eines zweiten Netzwerk-Interfaces für die Hosts

Damit die virtuellen Maschinen später auch ins Internet kommunizieren können, benötigt jeder Proxmox-Host eine entsprechende Netzwerk-Schnittstelle.

Während der Installation wurde automatisch das logische Interface „vmbr0“ angelegt (vmbr steht für virtual maschine bridge). Das Interface vmbr0 zeigt in aller Regel in ein geschütztes, internes Netzwerk. Sofern Sie für VMs direkten Kontakt zum Internet herstellen möchten, müssen Sie zuerst jedem Proxmox-Host ein entsprechendes Interface hinzufügen, über das später die VMs ins Internet können.

Um gleich das logische Interface „vmbr1“ zu erstellen, müssen Sie zunächst den Namen des physischen Netzwerk-Interfaces auf ihrem Proxmox-Server ermitteln. Dazu klicken Sie wieder zuerst auf den Host (1), anschließend auf Shell (2) und geben dort folgendes ein:

Einrichten eines zweiten Netzwerk-Interfaces 1

Proxmox# ip link show

In der nachfolgenden Auflistung beginnen die physischen Schnittstellen bei Debian-Linux mit „en“. In unserem Beispiel heißen die beiden NICs „ens1f0“ und „ens1f1“.

Weiter unten in der Auflistung können Sie erkennen, daß das logische Interface vmbr0 bereits angelegt ist.

Dazu klicken Sie zuerst auf den Host (1), anschließend auf (2) Netzwerk und danach auf „Erstellen“. Wählen Sie anschließend „Linux Bridge“.

Einrichten eines zweiten Netzwerk-Interfaces 2

Einrichten eines zweiten Netzwerk-Interfaces 3

In der folgende Maske benennen Sie das Interface (hier: vmbr1) (1) und vergeben bei (2) eine IP-Adresse sowie die dazu passende Subnetzmaske (2). Den Gateway (3) lassen Sie frei. Unter (4) tragen Sie das physische Netzwerk-Interface ein, das Sie gerade in der Shell identifiziert haben.

Wiederholen Sie die Schritte zur Erstellung des Interfaces „vmbr1“ auf allen Proxmox-Hosts, die direkt ins Internet (oder ein anderes Netz) Zugriff haben sollen.

Hinweis: Nach dem Erstellen des Netzwerk-Interfaces „vmbr1“ müssen sie den Proxmox-Host noch rebooten, damit Proxmox die (bis jetzt) inaktive Netzwerk-Konfiguration zu aktiven Konfiguration macht.

 

Linux-Profis können folgendermaßen vorgehen:

1
2
3
4
Pve# cd /etc/network
Pve# cp interfaces intefaces.save
Pve# cp interfaces.new interfaces
Pve# ifup vmbr1

Proxmox Admin Einführung

Die überwiegende Mehrzahl aller administrativen Aufgaben kann über die Web-Oberfläche erledigt werden. Hier sind die wichtigsten davon:

Virtuelle Maschinen erstellen 1

Virtuelle Maschine(n) erstellen

Um eine neue virtuelle Maschine zu erstellen, klicken Sie oben rechts auf „Create VM“ oder links im Struktur-Baum auf den Host und dann im Kontext-Menü auf „Create VM“. Auf Deutsch heißt der Befehl „Erstelle VM“. Es öffnet sich ein Assistent, der Sie durch die Einrichtung führt.

Unter Knoten wählen Sie den Proxmox-Host, auf dem die VM gestartet werden soll. Die VM ID (2)ist eine von Proxmox vergebene eindeutige ID für den Gast. Unter (3) geben Sie der neuen virtuellen Maschinen einen Namen. Klicken Sie anschließend unten rechts auf „vorwärts“ bzw. „next“

Virtuelle Maschinen erstellen 2

VM erstellen 3

Im Reiter „OS“ legen Sie fest, ob die VM ein DVD-Laufwerks-Inhalt bekommt und wählen diesen unter (1) aus. Bei (2) legen Sie fest, welcher VM-Typ als Gast laufen wird. Zur Auswahl stehen „Linux“, Windows und Solaris.

Sofern Sie ein Windows-Betriebssystem installieren möchten, so wählen Sie im Dropdown „Version“ die passende Version aus.

 

Laufwerk definieren

Laufwerk definieren

Im nächsten Schritt legen Sie den Speicherort und die Größe der ersten Festplatte für die neue VM fest:

Mit (2) definieren sie welcher Treiber bzw. welches Bussystem für den Gast emuliert werden soll. Unter (3) wählen Sie den Storage-Bereich aus. Bei (4) definieren Sie die Anfangsgröße der Festplatte in GB.

Hinweis: Festplatten in Proxmox können Sie später noch vergrößern – nicht jedoch verkleinern.

CPU festlegen

CPU festlegen

Im Reiter CPU legen Sie die Anzahl der Sockets und Cores für die VM fest. Die Anzahl der nutzbaren Kerne ist hinterher das Produkt aus Sockets x Cores. (Mathematisch: Sockets mal Cores)

RAM / Hauptspeicher festlegen

RAM festlegen

Im Reiter „Speicher“ legen Sie den Hauptspeicher der VM fest. Sie können dabei eine fixe Speichergröße (1) in MB festlegen (Im Bild sind es 4 GB). Alternativ legen Sie mit einem Klick auf (2) einen dynamischen Bereich fest.

Wie die Zuweisung im Detail in KVM bzw. Proxmox erfolgt ist hier sehr gut beschrieben: https://pve.proxmox.com/wiki/Dynamic_Memory_Management

Netzwerk-Interfaces zuweisen

Netzwerk-Interfaces zuweisen

Im letzten Schritt legen Sie fest, über welches Interface die VM nach außen hin verbunden wird.

Wählen Sie bei (1) den Bridged Mode. Hier können Sie die vorher definierten logischen Interfaces vmbr0 oder vmbr1 auswählen.

Ebenso ist es möglich NAT (Network Adress Translation) auszuwählen oder gar keine Netzwerkkarte zur Verfügung zu stellen.

Bei Modell (2) wählen Sie die NIC-Modellart, die Proxmox emulieren soll. Unter (3) können Sie außerdem eine MAC-Adresse vergeben, sofern Sie das z.B. für einen PXE-Boot oder dhcp benötigen.

Einstellungen bestätigen

Einstellungen bestätigen und VM erstellen

Im letzten Schritt sehen Sie eine Übersichts-Maske, in der Sie nun noch einmal alle Einstellungen kontrollieren können, bevor die virtuelle Maschine wirklich erstellt wird.

Sofern Sie noch Änderungen vornehmen möchten, so klicken Sie auf den entsprechenden Reiter und passen Ihre Einstellungen an.

Sobald Sie auf „Abschließen“ klicken, wird die neue VM erstellt. Das kann je nach Hardware und Größe einen Moment dauern.

Weitere Hardware hinzufügen.

Sie können jeder virtuellen Maschine später noch weitere Ressourcen hinzufügen. Etwa weitere Festplatten oder ein weiteres Netzwerk-Interface.

Virtuelle Maschine starten

Um die neu erstellte VM zu starten, klicken Sie zuerst (1) auf die neue VM. Anschließend können Sie die virtuelle Maschine entweder im Kontext-Menü der VM (2) starten oder oben rechts (3).

Virtuelle Maschine starten

Auf die virtuelle Konsole des Gastes wechseln

Um in die Konsole der frisch erstellen Maschine zu wechseln, klicken Sie auf „Konsole“ im Menü der VM.

Im Bildschirmbereich (3) neben dem Menü (2) können Sie nun mit Tastatur und Maus die virtuelle Maschine so steuern, als würden Sie vor einer physischen Hardware stehen.

Auf die virtuelle Konsole des Gastes wechseln

VM bedienen

VM anhalten / herunter fahren / stoppen

Eine virtuelle Maschine sollten Sie nach Möglichkeit über das installierte Betriebssystem herunterfahren. Sofern das nicht möglich ist, können Sie die VM auch „hart“ ausschalten.

Außerdem haben Sie die Möglichkeit die VM im laufenden Betrieb anzuhalten.

VM löschen

Sie können eine virtuelle Maschine nur löschen, wenn Sie ausgeschaltet bzw. herunter gefahren ist. Wählen Sie dazu links die VM aus und klicken anschließend oben rechts (2) auf „Mehr“ und dann auf löschen. (3)

Virtuelle Maschine löschen

Das Löschen bestätigen

Bevor Sie in Proxmox eine VM löschen können, müssen Sie das Löschen durch die manuelle Eingabe der 3-stelligen Maschinen-ID bestätigen. Erst danach wird die VM gelöscht.

Wichtig: Mit der VM werden auch automatisch alle verbundenen Festplatten physisch entfernt.

Verwaltung von Proxmox

Pools anlegen und verwenden

Pools anlegen und verwenden

Pools dienen in Proxmox dazu, virtuelle Maschinen zu gruppieren. In der linken „Struktur“-Spalte können neben der Ansicht für Hosts und Storage noch Pools angezeigt werden.

Um eine VM einem Pool zuzuweisen haben Sie zwei Möglichkeiten:

Bei der Anlage des Gastes in Proxmox können Sie im Reiter „General“ (Allgemein) den Pool direkt auswählen. Wenn Sie den Pool erst später erstellt haben oder die VM in einen Pool verschieben möchten, gehen Sie so vor:

Wählen Sie in der linken Spalte den Pool (1) , aus und klicken dann (2) auf Mitglieder. Klicken Sie auf (3) Hinzufügen und wählen Sie „Virtuelle Maschine“.

Sofern Sie später einzelnen Virtuellen Maschinen spezielle Storage-Bereiche zur Verfügung stellen wollen, so können Sie einzelnen Pools auch dedizierte Storage-Bereiche zur Verfügung stellen.

Hinweis: Eine VM kann keinem oder nur einem Pool zugewiesen werden. Eine Mehrfach-Mitgliedschaft einer VM zu Pools geht nicht.

Migration eines Gast-Systems von einem Host zum anderen.

Mit Proxmox können Sie laufende Gast-Systeme (virtuelle Maschinen) von einem Proxmox-Host zu einem anderen verschieben.

Die Voraussetzungen dafür sind:

  • Der Gast hat nur Cluster-weite Resourcen (Festplatte muss von beiden Proxmox-Hosts aus erreichbar sein).
  • Keine lokalen CD-Templates
  • Die Proxmox-Hosts haben gleich lautende Netzwerk-Interfaces (bspw. vmbr0 oder vmbr1)

Sofern diese Voraussetzungen gegeben sind, ist die Migration im laufenden Betrieb mit einem Klick möglich:

Migration eines Gast-Systems 1

Klicken Sie links (1) auf die VM, die Sie zu einem anderen Host migrieren möchten. Im Kontext-Menü (2) klicken Sie auf „Migration“. Alternativ können Sie oben rechts (3) die Migration starten.

Migration eines Gast-Systems 2

Wählen Sie im folgenden Menü den Ziel-Host und bestätigen Sie den Start der Migration.

Im Anschluss daran öffnet sich ein Log-Fenster, in dem Sie direkt den Verlauf der Migration beobachten können.

Bei einer Migration wird zunächst auf dem Ziel-Host ein identischer KVM Prozess angelegt. Diesem werden alle wesentlichen Werte der VM (CPU, RAM, HDD) übergeben. Anschließend wird der Inhalt des Hauptspeichers transferiert.

Migration eines Gast-Systems 3

Im konkreten Beispiel hat das Verschieben einer VM weniger als 10 Sekunden gedauert.

Massen-Migration

Massen-Migration

Über den Menü-Punkt „Bulk Migrate“ können mit einem Klick alle virtuellen Maschinen eines Proxmox-Hosts auf einen anderen verschoben werden. Das ist vor allem dann praktisch, wenn ein Proxmox-Hosts nach Updates neu gestartet werden soll.

Je nach Menge der virtuellen Maschinen und der Größe der VMs kann dieser Vorgang einige Minuten bis hin zu einer halben Stunde dauern.

Wichtig: Es wird bei der Massenmigration immer nur eine VM auf einmal migriert. Das Verschieben der VMs passiert also nacheinander.

Auf die Shell eines Proxmox-Hosts aufschalten

Neben den üblichen Wegen sich per ssh auf einen Proxmox-Host aufzuschalten, können Sie sich über die Web-GUI auf jeden Host direkt in die Shell aufschalten.

Container auf Basis von Templates erstellen

Proxmox ist von Hause aus in der Lage Container statt virtueller Maschinen zu betreiben. Für die Container-Technologie gibt es eine Vielzahl von fertigen Templates, mit deren Hilfe in wenigen Klicks eine fertige Anwendung installiert werden kann. Die vorhandenen Templates in Proxmox basieren auf Turnkey Linux. https://www.turnkeylinux.org/

Beispiele hierfür sind neben den klassischen Linux-Betriebssystemen Anwendungen wie WordPress, Apache, Magento und viele weitere.

Um einen Container zu erstellen, müssen sie zunächst das Template aus dem Internet herunter laden. Die Dateien für Container werden zusammen mit den ISO-Images gespeichert. Sie benötigen also keinen zusätzlichen Speicherort für Container-Templates.

Container-Template herunterladen

Container-Template herunter laden

Template auswählen

Klicken Sie in der linken Spalte auf das Speicherverzeichnis für ISO-Images (1), anschließend auf Content (2) und danach auf Templates.

Wählen Sie aus der Liste das gewünschte Template aus und klicken Sie auf „Download“.

Der Download benötigt je nach Größe und Internetanbindung einige Augenblicke bis er zur Verfügung steht.

Container installieren

Die Erstellung eines Containers ist ähnlich wie die Erstellung einer virtuellen Maschine. Klicken Sie oben rechts auf „Create CT“. Es öffnet sich wie bei den VMs ein Dialog, den Sie nun schrittweise durcharbeiten.

Container installieren 1

Unter (1) wählen Sie den Host, auf dem der Container gleich gestartet wird. Geben Sie ihrem neuen Container (3) einen Namen und weisen ihn ggf. einem Pool zu (4).

Container installieren 2

Im Gegensatz zu einer VM benötigt der Container ein Passwort von Ihnen, das Sie (5) zweimal identisch eingeben. Im nächsten Schritt wählen Sie das zu installierende Container-Template aus.

 

Container installieren 3

Die Einstellungen zu „Root Disk“, CPU und Memory sind fast identisch wie bei der Erstellung einer virtuellen Maschine.

Container installieren 4

Im Reiter Netzwerk müssen Sie die vollständige IP-Adresse in der Form „x.x.x.x/y“ eingeben – wobei x.x.x.x für die IP und y für die Netzwerk-Maske steht.

 

Container installieren 5

Im Reiter DNS geben Sie den Namen ihrer Domain an (z.B. test.local) und mindestens einen DNS-Server. Bestätigen Sie danach die Einstellungen. Im Anschluss wir die VM erstellt.

Starten Sie nun den Container mit einem Klick auf „Start“.

Danach wird das Filesystem des Containers erstellt und das Container-Image darauf kopiert.

Der eigentliche Container-Inhalt wird nun vom Turnkey-Template aus erstellt. Dieser Vorgang ist von Anwendung zu Anwendung unterschiedlich. Der Installations- und Konfigurationsaufwand wird nur beim ersten Boot durchgeführt. Nach der Installation bzw. Konfiguration kann der Container wie eine virtuelle Maschine benutzt werden.

Am Ende der Turnkey-Installation werden Sie in der Regel gefragt ob Sie Security-Updates der Software durchführen möchten. Sofern Sie eine bestehende Internet-Verbindung haben, sollten Sie dies tun, um die frisch installierte Software direkt zu aktualisieren.

Vorteil: Die manuelle Installation größerer Webanwendungen wie Magento dauert von Hand schon gerne einmal 1-2 Stunden. Mit Turnkey können Sie die Installation von Magento in 5-10 Minuten (je nach Hardware) fertig stellen.

Container löschen

Damit Sie einen Container löschen können, fahren Sie ihn zunächst herunter. Anschließend löschen Sie ihn über Mehr(More) -> Remove und geben zur Sicherheit noch die VM-ID ein.

Anbindung von Proxmox an LDAP / Active Directory

Proxmox kann über ein LDAP-Server oder ein bestehendes Active Directory die Authentifizierung vornehmen. Das bedeutet, daß in einer AD angelegte Benutzer mit Ihrem Passwort verifiziert werden.

Eine Automatische Prüfung (wie etwa bei der pfsense Firewall) auf eine Gruppenmitgliedschaft gibt es bei Proxmox nicht. Die Benutzernamen müssen also einmal lokal im Proxmox Cluster angelegt werden und einer Administrations-Gruppe zugewiesen werden.

Anbindung von Proxmox an LDAP

Wie Sie eine AD mit Proxmox verbinden, beschreiben wir nachfolgend:

Klicken Sie auf Datacenter -> Permissions -> Authentifizierung -> Add:

Tragen Sie bei (1) den Kurznamen Ihrer AD ein. Bei Domain (2) fügen Sie den „langen“ Namen Ihre Domain ein. Bei Server (3) tragen Sie die IP-Adresse des ersten Domain-Controllers des Active Directory ein. Bei Fallback-Server kommt die IP des zweiten Domain-Controllers rein.

Name vergeben

Als nächstes erstellen Sie eine Gruppe und geben ihr einen sprechenden Namen:

Klicken Sie auf Datacenter -> Permissions -> Groups -> Add

Rechte zuweisen

Nun weisen wir der neu erstellten Gruppe Rechte zu.

Klicken Sie auf Datacenter (1) -> Permissions (2) -> Add (4); wählen Sie anschließend Group Permission (4)

 

Administrative Rechte zuweisen

Im letzten Schritt weisen wir der Gruppe der „AD-Administratoren“ administrative Rechte zu. Dazu geben Sie bei (1) den Pfad „/“ ein. Damit erhält die Gruppe „AD-Administratoren“ Zugriff auf das gesamte Cluster.

Durch die Auswahl der Rolle „Administrator“ erhält anschließend die Gruppe AD-Administratoren administrative Reche im gesamten Cluster von Proxmox.

Benutzername anlegen

Damit sich nun ein echter Anwender, der in der Active Directory Domain bereits existiert, in Proxmox anmelden kann, muss der Benutzername noch in Proxmox angelegt werden.

Dazu klicken Sie auf Datacenter -> Permissions -> User -> Add

Geben Sie dem Benutzer den exakt gleichen Namen wie im AD.

Als Realm wählen Sie die das AD-Realm aus (2) und unter (3) die vorher angelegte Gruppe (3).

Bei der nächsten Anmeldung wählen Sie dann als Realm nicht mehr „Linux PAM standard authentication“ sondern ihr Active Directory aus.

Betrieb von Promox

Cluster-Übersicht / Cluster Status

Die Übersicht und Auslastung des Clusters sieht man als IT-Administrator auf einen Blick, wie die Auslastung und Belastung des Clusters ist.

..-> Datacenter -> Summary

Cluster Status

Unter (1) sehen Sie auf einen Blick, (grüner Haken) ob alles in Ordnung ist. Sofern einer der Hosts (engl. Nodes) offline sein sollte, so sehen Sie das unter (2) rechts oben. In der Zeile Guests sehen Sie wie viele virtuelle Maschinen angelegt und aktiv sind. Das gleiche auf der rechten Seite (4) für Container.

Um unteren Bereich „Resources“ sehen Sie über alle Hosts hinweg, wieviel CPU, RAM und Speicher-Kapazität sie insgesamt zur Verfügung haben und wieviel davon benutzt werden.

Wenn Sie etwas weiter runter scrollen, sehen Sie außerdem in der Zeile „Nodes“ die Auslastung aller einzelnen Cluster-Mitglieder.

Auslastungen der einzelnen Cluster Mitglieder

Neben der CPU- und RAM-Auslastung wird Ihnen hier auf einen Blick die Betriebszeit (Uptime) eines jeden Proxmox-Hosts angegeben.

Monitoring von Proxmox-Servern

Proxmox-Hosts lassen sich als Linux-Hosts mit Debian wie jeder andere Host mit Linux (etwa Centos) per icinga2 überwachen. Die folgenden Prozesse sind auf einem frisch installierten Cluster-Mitglied aktiv und sollten überwacht werden:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
root@b65k-pve03:/dev/pve# ps axu | grep -i pve
root      1779  0.0  0.4 317788 74260 ?        Ss   Jan02  13:44 pve-firewall
root      1790  0.2  0.4 308956 78840 ?        Ss   Jan02  54:13 pvestatd
root      1811  0.0  0.6 527352 110292 ?       Ss   Jan02   0:14 pvedaemon
www-data  1863  0.0  0.6 535024 112060 ?       Ss   Jan02   0:14 pveproxy
root     22263  0.0  0.4 325644 81796 ?        Ss   Jan13   0:55 pve-ha-lrm
root     22326  0.0  0.5 326096 82524 ?        Ss   Jan13   0:27 pve-ha-crm
root     22886  0.0  0.6 537652 104360 ?       S    Jan13   0:04 pvedaemon worker
root     22887  0.0  0.6 537652 104392 ?       S    Jan13   0:04 pvedaemon worker
root     22888  0.0  0.6 537452 104104 ?       S    Jan13   0:04 pvedaemon worker
www-data 22898  0.0  0.6 545416 107000 ?       S    Jan13   0:04 pveproxy worker
www-data 22899  0.0  0.6 545188 106292 ?       S    Jan13   0:04 pveproxy worker
www-data 22900  0.0  0.6 545172 106288 ?       S    Jan13   0:04 pveproxy worker
root     27863  0.0  0.0  89900   160 ?        Ssl  06:25   0:01 /usr/sbin/pvefw-logger

 

Die Linux-Prozesse einer lauenden virtuellen Maschine beginnen mit “ /usr/bin/kvm”. Den aktuellen Bestand an kvm-Prozessen ermittelt man mit „qm list“:

1
2
3
4
root@b65k-pve02:/dev/pve# qm list
VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
100 Test01               running    4096              32.00 11772
101 Test03               running    2048              32.00 11874

Sofern einzelne KVM-Prozesse statisch an einen Host gebunden sind, kann man diese natürlich wieder mit icinga2 überwachen.

Datensicherung von Proxmox

Datensicherung der virtuellen Maschinen

Damit Sie eine regelmäßige Datensicherung der virtuellen Maschinen im laufenden Betrieb erstellen können, müssen Sie auf Snapshots zurückgreifen. Bei der Erstellung eines Snapshots schreibt Proxmox die aktuellen Daten der VM in eine zusätzliche Datei weiter. Dadurch wird die bestehende Disk-Datei „statisch“ und kann gesichert werden.

Als Sicherungsverzeichnis kommt das weiter oben eingerichtete zentrale Backup-Verzeichnis in Frage. Mit dem Befehl “vzdump” kann auf jedem Host ein Dump der auf diesem Host laufenden VMs erstellt werden.

Pve# vzdump –all –dumpdir /mnt/backup –mode snapshot

Wichtig dabei: Damit alle virtuellen Maschinen des Proxmox-Clusters gesichert werden, muss der oben genannte Job auf allen (!) Proxmox-Hosts regelmässig laufen.

Am besten fügen Sie die obige Befehlszeile in die crontab jedes Proxmox-Hosts ein und starten die Datensicherung automatisch nachts um 2.00 Uhr.

0 2 * * * /usr/bin/vzdump –all –dumpdir /mnt/pve/proxmox-backup –mode snapshot

Datensicherung der Proxmox-Konfiguration

Die eigentliche Konfiguration des Proxmox-Clusters sowie die Cluster-Konfiguration von corosync liegt unter /etc/pve . Die Summe der Dateien ist nur wenige KiloByte groß.

Updates von Proxmox-Servern

Proxmox-Server werden (als Debian-Linux) über den Paketmanager “apt” aktualisiert.

Wichtig: Bei Updates von Proxmox sollten Sie immer alle (!) Hosts eines Clusters auf einen einheitlichen Software.-Stand bringen.

Vorgehen bei Updates:

apt-get update # damit wird die Paket-Liste bzw. das Repository aktualisiert

apt-get upgrade # führt den eigentlichen Updates von Paketen durch.

Hinweis: Das Update von apt können Sie zentral mit ansible machen.

 

Anschließend rebooten Sie den betroffenen PVE-Hosts nachdem Sie vorher die virtuellen Maschinen auf einen anderen PVE-Host verschoben haben. Zur Sicherheit schauen Sie bitte vorher auf dem PVE-Host nach, ob alle VMs verschoben wurden.

Bsp.: Mit ‚qm list‘ erhalten Sie die Liste aller vorhandenen virtuellen Gäste auf einem Proxmox Host:

1
2
3
4
5
6
7
8
root@agppve01:~# qm list
VMID NAME                 STATUS     MEM(MB)    BOOTDISK(GB) PID
107 Biteno-piwik01       running    4096              65.00 9165
108 Biteno-piwik02       running    4096              65.00 35251
109 Win2008R201          stopped    2048              32.00 0
110 Win2008R202          stopped    2048              42.00 0
112 bareos.itsc.local    running    4096             130.00 35893
113 ob02.biteno.com      running    4096              64.00 21796

 

Wichtig: Starten Sie immer nur einen Proxmox-Host auf einmal neu. Nach dem Reboot kontrollieren Sie, die Linux-Version und ob das Cluster wieder vollzählig ist.

Nach dem Reboot:

Kontrollieren Sie die Linux-Kernel-Version mit „uname –a“

root@agppve01:~# uname -a

Linux agppve01 4.13.13-1-pve #1 SMP PVE 4.13.13-31 (Mon, 11 Dec 2017 10:00:13 +0100) x86_64 GNU/Linux

Gelb markiert ist die Kernel-Version von Linux.

 

Kontrollieren Sie den Status des Clusters mit dem Befehl „pvecm status“.

Die nachfolgende Übersicht zeigt das Cluster im Zustand, daß 4 Knoten im Cluster angemeldet sind und ihren Dienst tun.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
root@agppve09:~# pvecm status
Quorum information
------------------
Date:             Wed Jan 17 10:05:57 2018
Quorum provider:  corosync_votequorum
Nodes:            4
Node ID:          0x00000003
Ring ID:          4/416
Quorate:          Yes
Votequorum information
----------------------
Expected votes:   4
Highest expected: 4
Total votes:      4
Quorum:           3
Flags:            Quorate
(…)

In der Zeile „Nodes“ erkennen Sie, wieviele Hosts gerade online sind. Die Zeile „Quorum“ zeigt, die Mindest-Anzahl der Hosts, die online sein müssen.

Im nachfolgenden Beispiel erkennen Sie, daß nur 3 Hosts online sind. Die Anzahl bei „Total Votes“ ist 3 (statt vorher 4). Das entspricht der Mindest-Menge an „Stimmen“ im Cluster, die nicht unterschritten werden sollte.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
root@agppve09:~# pvecm status
Quorum information
------------------
Date:             Wed Jan 17 10:09:23 2018
Quorum provider:  corosync_votequorum
Nodes:            3
Node ID:          0x00000003
Ring ID:          5/420
Quorate:          Yes
Votequorum information
----------------------
Expected votes:   4
Highest expected: 4
Total votes:      3
Quorum:           3
Flags:            Quorate
Membership information
----------------------
Nodeid      Votes Name
0x00000005          1 10.20.30.62
0x00000003          1 10.20.30.69 (local)
0x00000001          1 10.20.30.224

Migration von virtuellen Maschinen zu Proxmox

Nachfolgend beschreibe ich die funktionierenden Wege, einen virtuellen Gast von einem anderen Hypervisor zu Proxmox zu migrieren. Das kann Hyper-V, VMware oder ein anderes KVM-basiertes System wie Openstack oder Cloudstack sein.

Die Grundlage einer (erfolgreichen) Migration ist in der Regel ein lesbares Image der virtuellen Festplatte. Die Migrationswege beschreiben daher in der Regel wie ein Disk-Image von einer Plattform und der dort bevorzugten Speicherform zu Proxmox kopiert und konvertiert werden kann.

Proxmox verwendet zum Speichern von Disk-Images entweder das Format „qcow2“ oder ein so genannte „Raw“-Device.

Migration von VMWare zu Proxmox

  • Virtuelle Maschine auf VMWare runter fahren und beenden
  • Identifizieren Sie die Disk-Dateien auf dem VMWare-Server sowie den Pfad dazu
  • Kopieren Sie die Dateien auf den Proxmox-Host

Vom Proxmox-Host aus:

Pve# cd /<ihr-pfad-in-dem-sie-platz-haben/

Pve# scp root@<VMWare-IP>://vmfs/volumes/<PFAD/*flat* .

Legen Sie eine neue virtuelle Maschine auf dem Proxmox-Host an, auf den Sie das Maschinen-Image kopiert haben. Achten Sie dabei darauf, daß Sie die Festplatte als „lokale“ Festplatte auf dem Proxmox-Host anlegen. Notieren Sie sich außerdem bitte die 3-stellige VM-ID.

Wichtig – Achten Sie auf folgende Punkte:

  • Die neue virtuelle Festplatte muss zur Bus-Architektur passen (bspw. „IDE“ )
  • Die neue virtuelle Festplatte muss mindestens so groß oder größer als die zu importierende Festplatte sein.
  • Erstellen Sie die Festplatte als lokale Festplatte

Kopieren Sie die Festplatte mit dem Linux-Befehl „dd“. Wechseln Sie in das Verzeichnis, in der das VMWare-Flatfile der Platte liegt.

Ersetzen Sie den Dateinamen des VMWare-Images (Endung: vmdk) durch den echten Dateinamen. Prüfen Sie außerdem bitte vorher ob unter /dev/pve/* auch ihre neu angelegten Proxmox-Images für ihre virtuelle Maschine liegen.

dd if=<alter-hostname>flat.vmdk of=/dev/pve/vm-<disk-id>disk-1

Migration von Hyper-V zu Proxmox

Fahren Sie die virtuelle Maschine unter Hyper-V herunter. Kopieren Sie anschließend das Disk-Image (*.vhd) von Hyper-V auf den Proxmox-Host.

Die notwendige Konvertierung (Umwandlung) des Hyper-V Diskimages machen sie wie folgt:

1
Pve# qemu-img convert win2008r2-1.vhd -O qcow2 win2008r2-1.qcow2

https://forum.proxmox.com/threads/migrate-hyper-v-machine-to-proxmox-kvm.13969/

Eine Übersicht der von Anwendern erfolgreich getesteten Migrationswege gibt es auf der Proxmox-Homepage.
https://pve.proxmox.com/wiki/Migration_of_servers_to_Proxmox_VE

Fazit zu Proxmox:

Für mittelständische Unternehmen und Rechenzentrumsbetreiber ist Proxmox eine gute Alternative zu den Platzhirschen OpenStack, VMWare oder Hyper-V. Mit der intuitiven Oberfläche nimmt Proxmox auch eingefleischten Windows-Admins die Angst vor Linux.

Für erfahrene Linux-Administratoren bietet Proxmox mit der Integration von Ceph und anderen Speichertechnologien alle Möglichkeiten moderene Konzepte wie „Software defined Storage“ im eigenen Unternehmen sicher und stabil einzusetzen.

Bareos Einführung – Online-Backup

, ,
Die Anmeldemaske von Bareos

Einleitung zu Bareos

Bareos ist neben Backup-PC und Bacula eines der populärsten Programme aus der OpenSource-Community um entfernte Server zu sichern. Wer die Software Bacula zur Sicherung auf Platte oder Tape (Bandlaufwerk) im Rahmen der Linux-Administration schon eingesetzt hat, wird sich in Bareos schnell zurecht finden.
Im nachfolgenden Tutorial zu Bareos gehen wir der Reihe nach die Schritte durch, die zur Installation und Konfiguration von Bareos notwendig sind. Außerdem fügen wir exemplarisch einen Windows-Client und einen Linux-Client hinzu.

Im zweiten Tutorial zu Bareos behandeln wir die notwendigen Anpassungen in der Konfiguration, wenn Sie Bareos mit sehr vielen Clients nutzen möchten.
Bareos ist ein so genannter Fork von Bacula, das bereits seit über 10 Jahren als Online-Backup bekannt ist. Seit 2012 entwickeln mehrere Software-Entwickler Bareos auf Basis von Bacula weiter. Hauptgrund war die schleppende Weiterentwicklung von Bacula

Das Konzept von Bareos

Bareos besteht wie Bacula aus 3 Diensten:

  • Der Storage Daemon (bareos-sd) – dieser Dienst verwaltet den Speicher, auf denen Backups gespeichert werden. Das können Festplatten oder Tape-Drives sein.
  • Der Filedaemon von bareos (bareos-fd) übernimmt auf jedem Client die Aufgabe, die Dateien des Clients zum zentralen Storage Daemon zu schicken.
  • Der Bareos-Director (bareos-dir) ist die zentrale Komponente, über die der Netzwerk-Administrator Backup-Clients anlegt, Backup-Jobs definiert oder Restores vornehmen kann.

Der Storage-Daemon sowie der Director werden typischerweise auf einem Linux-Server installiert. Der Bareos-Filedaemon muss auf jedem zu sichernden Client installiert werden. Es existieren dazu Programm-Pakete für Windows (ab Windows 2008 Server bzw. Windows 7) sowie für alle gängigen Linux-Distributionen (CentOS, Redhat, Ubuntu, Debian, SuSE Linux, …) sowie Univention (Version 4).

Vorteile von Bareos

Durch die Verteilung des Programms auf drei Dienste kann Bareos relativ gut skalieren. D.h. es ist möglich, den Director und den Storage-Daemon auf getrennten Servern laufen zu lassen.

Gegenüber Bacula hat Bareos noch den angenehmen Vorteil, daß es von Haus aus eine Weboberfläche mitbringt, über die Jobs gestartet oder Restores vorgenommen werden können.
Bareos unterscheidet sich sowohl von Backup-PC als auch bacula, daß hinter Bareos mittlerweile eine deutsche GmbH sitzt, die von einigen ambitionierten Software-Entwicklern geführt wird. Hier können Firmen im Zweifel auch kostenpflichtigen IT-Support für Bareos einkaufen.

Voraussetzungen für Bareos

Damit Bareos einwandfrei funktioniert, benötigen wir

  • Einen zentralen Server mit ausreichend Speicherplatz als Zuhause für den Bareos-Director
  • Mysql auf dem zentralen Bareos-Director
  • Netzwerk-Verbindungen zu allen zu sichernden Clients (internes LAN, Internet oder via VPN) auf den Ports 9102, 9103 und 9104

Im konkreten Fall platzieren wir den Bareos-Server zentral im internen LAN der Firma so daß er von dort problemlos mit allen internen Servern per TCP/IP kommunizieren kann.
Für die Kommunikation mit verteilten Clients im Internet richten wir (weiter unten) auf der pfsense ein 1:1 NAT ein und erlauben von extern den Zugriff auf Port 9102.

Empfehlung für das Hardware-Sizing bzw. Setup von Bareos

Im Test ist eine virtuelle Maschine mit 4 GB RAM und 4 Kernen ausreichend. Für das Betriebssystem (Centos 7) reichen in der Regel 50 -100 GB.
Wieviel Plattenplatz für die zu sichernden Rechner notwendig ist, hängt von deren Größe sowie der Vorhaltezeit für Backups ab. Dazu unten bzw. im zweiten Teil des Tutorials mehr.
Im konkreten Beispiel starten wir mit 10 TB Speicher, die über eine separate virtuelle Festplatte via LVM (wichtig!) zur Verfügung gestellt wird.

Besonderheiten von Bareos

Um Bareos auszuprobieren sollten Sie den Hostnamen des zentralen Bareos-Servers auf „bareos“ eingestellt lassen. Der Name „bareos“ für den Hostnamen ist an unzähligen Stellen in den Konfigurations-Dateien von Bareos versteckt. Hier lohnt sich die Umbenennung (meiner Meinung nach) erst, wenn man größere Installationen von Bareos mit verteilten Diensten einrichten möchte.

Damit die Clients mit dem zentralen Bareos-Server kommunizieren können muss sowohl für den Bareos-Director der Hostname des Clients als auch für den Client der Hostname von Bareos (bareos) per DNS auflösbar sein.

Dazu richten Sie am besten im DNS einen entsprechenden Eintrag ein. Wer Bareos nur mal eben auf zwei Geräten testen möchte, kann selbstverständlich den passenden Eintrag auch in der /etc/hosts auf Linux bzw. unter c:\windows\system32\drivers\etc\hosts anlegen.

Installation und Vorbereitung von Bareos

Wir nutzen zur Installation von Bareos eine Centos 7 Standard-Installation. Die Root-Partition bekommt 45 GB. Das Verzeichnis /var/lib/mysql erhält eine separate Partition mit 25 GB.
Zusätzlich erstellen wir eine große, zweite Festplatte mit 10 TB, die wir später mittels LVM unter /var/lib/bareos hängen. Unter /var/lib/bareos speichert Bareos in der Standard-Konfiguration die einzelnen Volumes ab, auf denen die gesicherten Daten gespeichert werden.

Hinweis: Für einen Test reicht sicherlich deutlich weniger Platz unter /var/lib/bareos.
Für die Installation sind die folgenden Schritte notwendig:

  1. Bareos-Repository für Centos 7 herunterladen
  2. Bareos, Mysqld(bzw. Mariadb) sowie das Bareos-Webui installieren
  3. Datenbank mit Hilfe von 3 fertigen Skripten erstellen
  4. Dienste (Bareos und httpd) starten
  5. Web-User anlegen

Die Schritte im Einzelnen:

Bareos-Repositiory herunterladen

Mit dem nachfolgenden Snippet/Skript laden Sie automatisch das richtige Repository für yum herunter:

1
2
3
4
5
6
7
8
#
DIST=CentOS_7
DATABASE=mysql
yum -y install wget
# add the Bareos repository
URL=http://download.bareos.org/bareos/release/latest/CentOS_7
wget -O /etc/yum.repos.d/bareos.repo $URL/bareos.repo
#

Bareos, Mysqld und Bareos-Webui installieren

Direkt danach können wir mit einem Befehl alle notwendigen Programme installieren

1
yum -y install bareos bareos-database-mysql bareos-webui mariadb-server

Mariadb/Mysqld anpassen / Datenbanken erstellen

1
2
3
4
systemctl enable mariadb
systemctl start mariadb
mysql_secure_installation
#(Fragen mit “y” beantworten und neues Passwort für mysql Benutzer root vergeben)
1
2
3
4
5
6
vi ~/.my.cnf
#insert:
[client]
host=localhost
user=root
password=&lt;root mysql-Passwort&gt;

Danach rufen wir die 3 SQL-Skripte auf, die alle notwendigen Datenbanken sowie Tabellen für Bareos erstellen:

1
2
3
/usr/lib/bareos/scripts/create_bareos_database
/usr/lib/bareos/scripts/make_bareos_tables
/usr/lib/bareos/scripts/grant_bareos_privileges

Ergebnis:

1
2
3
4
5
6
7
8
9
[root@bareos01 ~]# /usr/lib/bareos/scripts/create_bareos_database
Creating mysql database
Creating of bareos database succeeded.
[root@bareos01 ~]#     /usr/lib/bareos/scripts/make_bareos_tables
Making mysql tables
Creation of Bareos MySQL tables succeeded.
[root@bareos01 ~]#     /usr/lib/bareos/scripts/grant_bareos_privileges
Granting mysql tables
Privileges for user bareos granted ON database bareos.

Bareos Dienst und Apache starten

Mit den nachfolgenden Befehlen starten wir die vier Dienste. Die letzten 4 stellen sicher, daß die 4 Dienste auch nach einem Reboot wieder automatisch gestartet werden.

1
2
3
4
5
6
7
8
systemctl start bareos-dir
systemctl start bareos-sd
systemctl start bareos-fd
systemctl start httpd
systemctl enable bareos-dir
systemctl enable bareos-sd
systemctl enable bareos-fd
systemctl enable httpd

Web-Konfiguration

Die Konfiguration von Bareos für das Web-Interface liegt unter /etc/httpd/conf.d/bareos-webui.conf . Hier müssen Sie an sich nichts tun.
Wer zum Testen auf die Firewall bzw. iptables verzichtet, stellt den Firewall folgendermaßen aus:

1
2
systemctl disable firewalld
service firewalld stop

Zu guter Letzt legen wir noch einen Benutzer namens “admin” für die Web-Gui von Bareos an.

1
2
3
bconsole
configure add console name=admin password=test123 profile=webui-admin
quit

Danach können Sie sich unter http://<IP>/bareos-webui/ mit dem Usernamen „admin“ sowie dem Passwort „test123“ anmelden.
Abbildung: Anmeldemaske von Bareos

Die Anmeldemaske von Bareos

Die Anmeldemaske von Bareos

 

Vorbereitung für Backups

Damit Sie nun auch tatsächlich Backups und Restores durchführen können, müssen wir noch wenige Anpassungen am Bareos-Director vornehmen:

FileSets anlegen.

Damit Bareos weiß was es sichern soll, muss für Linux und Windows jeweils eine Definition für ein so genanntes FileSet angelegt werden. Dazu erstellen Sie unter „/etc/bareos/bareos-dir.d/fileset“ die Datei LinuxAll.conf. In ihr ist enthalten welche FileSysteme unter Linux gesichert werden sollen:

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
FileSet {
Name = "LinuxAll"
Description = "Backup all regular filesystems, determined by filesystem type."
Include {
Options {
Signature = MD5 # calculate md5 checksum per file
One FS = No     # change into other filessytems
FS Type = btrfs
FS Type = ext2  # filesystems of given types will be backed up
FS Type = ext3  # others will be ignored
FS Type = ext4
FS Type = reiserfs
FS Type = jfs
FS Type = xfs
FS Type = zfs
FS Type = vzfs
}
File = /
}
Exclude {
File = /var/lib/bareos
File = /var/lib/bareos/storage
File = /proc
File = /tmp
File = /var/tmp
File = /.journal
File = /.fsck
}
}

Das Gleiche machen wir analog für Windows. Hier erstellen Sie eine Datei mit dem Namen WindowsAllDrives.conf im selben Verzeichnis:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
FileSet {
Name = "WindowsAllDrives"
Enable VSS = yes
Include {
Options {
Signature = MD5
Drive Type = fixed
IgnoreCase = yes
WildFile = "[A-Z]:/pagefile.sys"
WildDir = "[A-Z]:/RECYCLER"
WildDir = "[A-Z]:/$RECYCLE.BIN"
WildDir = "[A-Z]:/System Volume Information"
Exclude = yes
}
File = /
}
}

Die nachfolgenden Job-Definitionen verwenden gleich die eben angelegten FileSets.

JobDefinitionen anlegen

Wechseln Sie nun ins Verzeichnis „/etc/bareos/bareos-dir.d/jobdefs“ und legen dort die Standard-Job-Definition für Linux-Clients an. In dieser generellen Job-Definition wird zentral eingestellt, welches FileSet verwendet wird, wie oft und wohin gesichert wird.
Erstellen Sie dazu für alle Linux-Rechner die Datei DefaultLinux.conf

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
JobDefs {
Name = "DefaultLinux"
Type = Backup
Level = Incremental
FileSet = "LinuxAll"                     # selftest fileset                            (#13)
Schedule = "WeeklyCycle"
Storage = File
Messages = Standard
Pool = Incremental
Priority = 10
Write Bootstrap = "/var/lib/bareos/%c.bsr"
Full Backup Pool = Full                  # write Full Backups into "Full" Pool         (#05)
Differential Backup Pool = Differential  # write Diff Backups into "Differential" Pool (#08)
Incremental Backup Pool = Incremental    # write Incr Backups into "Incremental" Pool  (#11)
}

Das Gleiche machen wir für Windows-Clients. Hier legen wir im gleichen Verzeichnis die Datei DefaultWindows.conf an:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
JobDefs {
Name = "DefaultWindows"
Type = Backup
Level = Incremental
FileSet = "WindowsAllDrives"
Schedule = "WeeklyCycle"
Storage = File
Messages = Standard
Pool = Incremental
Priority = 10
Write Bootstrap = "/var/lib/bareos/%c.bsr"
Full Backup Pool = Full                  # write Full Backups into "Full" Pool         (#05)
Differential Backup Pool = Differential  # write Diff Backups into "Differential" Pool (#08)
Incremental Backup Pool = Incremental    # write Incr Backups into "Incremental" Pool  (#11)
}

Die Definitionen zu Pools, Volumes und Storage lassen Sie für den Moment so wie sie sind.

Zeitpläne für Backups / Schedules

Zur Sicherheit prüfen Sie noch, ob der Zeitplan für die Backups auch an Ort und Stelle ist.
Dazu wechseln Sie ins Verzeichnis „/etc/bareos/bareos-dir.d/schedule“ .
Dort sollen Sie die Datei WeeklyCycle.conf vorfinden. Diese hat den Inhalt:

1
2
3
4
5
6
Schedule {
Name = "WeeklyCycle"
Run = Full 1st sat at 21:00                   # (#04)
Run = Differential 2nd-5th sat at 21:00       # (#07)
Run = Incremental mon-fri at 21:00            # (#10)
}

Sie haben nun alle grundsätzlichen Vorbereitungen abgeschlossen, um gleich mit wenigen Handgriffen den ersten Client in ihr neues Bareos-System aufzunehmen.

Einen Windows Client einrichten

Zur Installation eines Windows-Client (ab Windows 2008 Server oder Windows 7) laden Sie sich auf dem zu sichernden Server die für das Betriebssystem passende Windows-Datei herunter.
Extern: http://download.bareos.org/bareos/release/16.2/windows/

Die Installation starten Sie wie gewohnt mit einem Doppelklick auf die Exe-Datei des Bareos-Installers.

Der Windows-Installer für den Bares-Client unter Windows

Der Windows-Installer für den Bares-Client unter Windows

Standardmäßig ist bei der Windows-Installation lediglich der File-Daemon-Dienst angehakt. Sofern Sie den PC/Server lediglich sichern möchten, ist das auch vollkommen ausreichend.
Die beiden unteren Haken benötigen Sie nur, wenn Sie auf einer Windows-Maschine den Bareos-Director bzw. den Bareos-Storage-Daemon installieren möchten.
Klicken Sie anschließend auf „Next“.

Die richtigen Einstellungen für Bareos unter Windows

Die richtigen Einstellungen für Bareos unter Windows

In der nachfolgenden Maske müssen Sie mindestens bei (1) und (4) den Hostnamen ändern.
Der Reihe nach:
Bei (1) tragen Sie den vollständigen DNS-Hostnamen (fqdn) des Rechners ein auf dem Sie gerade Bareos installieren. Über den einzutragenden DNS-Namen muss der Bareos-Director den Client übers Netz erreichen können.
Die Zeile (2) „Director Name“ mit dem Eintrag „bareos-dir“ lassen Sie so wie sie ist. Ausnahme: Sie haben Ihren Director anders genannt. Dann passen Sie das hier an.
In der Zeile (3) finden Sie das von Bareos vorgeschlagene Passwort. Da es sich hier um ein willkürlich gewähltes Passwort handelt, können Sie das so lassen wie es ist. Das Passwort des Clients wird lediglich zur Kommunikation zwischen Client und Server verwendet. Sie selbst müssen es sich nicht merken.
Bei „Network Address“ (4) geben Sie wieder den vollständigen DNS-Hostnamen (fqdn) des Rechners ein auf dem Sie gerade Bareos installieren.
Klicken Sie nun auf „next“ und speichern Sie bitte unbedingt den Inhalt der letzten Maske ab:

Die fertige Konfig-Datei für den Windows Client von Bareos

Die fertige Konfig-Datei für den Windows Client von Bareos

Die 7 Zeilen Code der Konfiguration speichern Sie am besten zunächst auf dem Rechner unter c:\Install ab.

Bekanntmachen des Windows-Clients im Director

Wichtig: Damit der zentrale Bareos-Director den zu sichernden Client kennt, müssen Sie den Inhalt dieser Datei (inkl. Passwort-String) an der folgenden Stelle abspeichern:
Bareos# cd /etc/bareos/bareos-dir.d/client
Bareos# vi itsc40.itsc.local.conf # Inhalt einfügen, abspeichern
Hinweis: Die Datei muss die Endung *.conf haben. Zur besseren Übersicht empfehle ich die Datei wie den Hostnamen plus die Endung „.conf“ zu nennen. Im Beispiel also „itsc40.itsc.local.conf“.

Erstellen eines Backup-Jobs für den Windows-Client

Der Client ist nun zwar im Director bekannt, allerdings werden noch keine Backups durchgeführt. Eine Backup-JobDefinition für den Windows-Client erstellen Sie folgendermaßen:
Bareos# bconsole

1
2
*configure add job name=itsc40.itsc.local.job client=itsc40.itsc.local jobdefs=DefaultWindows
*quit

Mit dem obigen Befehl erstellen Sie für den Client mit Namen “itsc40.itsc.local” einen Job mit Namen “itsc40.itsc.local.job” und der JobDefinition, die unter “DefaultWindows” abgespeichert ist.

1
2
3
4
5
6
7
8
*configure add job name=itsc40.itsc.local.job client=itsc40.itsc.local jobdefs=DefaultWindows
Created resource config file "/etc/bareos/bareos-dir.d/job/itsc40.itsc.local.job.conf":
Job {
Name = itsc40.itsc.local.job
Client = itsc40.itsc.local
JobDefs = DefaultWindows
}
quit

Rein technisch wird dabei von Bareos eine Text-Datei unter „/etc/bareos/bareos-dir.d/job/“ mit dem Namen itsc40.itsc.local.job.conf abgespeichert. In dieser Datei wird lediglich die Zuordnung von Job-Definition zu Client vorgenommen.

Starten des Backup-Jobs für den Windows-Client

Der Backup-Job wird nun zur nächsten Gelegenheit (siehe Konfiguration) starten. Sofern Sie den Backup-Job sofort laufen lassen möchten, so tun Sie das wie folgt:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Bareos# bconsole
*run job=itsc40.itsc.local.job
Using Catalog "MyCatalog"
Run Backup job
JobName:  itsc40.itsc.local.job
Level:    Incremental
Client:   itsc40.itsc.local
Format:   Native
FileSet:  WindowsAllDrives
Pool:     Incremental (From Job IncPool override)
Storage:  File (From Job resource)
When:     2018-01-03 16:54:57
Priority: 10
OK to run? (yes/mod/no): y
Job queued. JobId=345

Wenn Sie den Status des Backup-Jobs prüfen möchten, so können Sie das entweder in der Web-Gui machen oder über die bareos-Konsole mit dem Kommando „messages“:

1
2
3
4
5
6
7
Bareos# bconsole
*messages
03-Jan 16:54 bareos-dir JobId 345: No prior Full backup Job record found.
03-Jan 16:54 bareos-dir JobId 345: No prior or suitable Full backup found in catalog. Doing FULL backup.
03-Jan 16:55 bareos-dir JobId 345: Start Backup JobId 345, Job=itsc40.itsc.local.job.2018-01-03_16.54.58_36
03-Jan 16:55 bareos-dir JobId 345: Using Device "FileStorage" to write.
quit

Einen Linux-Client einrichten

Installation von Bareos auf Centos

Für Centos müssen Sie zuerst das passende Repository für Bareos herunterladen und nach /etc/yum.repos.de kopieren.

1
2
3
4
yum -y install wget
wget -O /etc/yum.repos.d/bareos-centos7.repo http://download.bareos.org/bareos/release/latest/CentOS_7/bareos.repo
yum -y install bareos-fd
systemctl enable bareos-fd

Hinweis: Für Centos 6 wählen Sie bitte „wget -O /etc/yum.repos.d/bareos-centos6.repo http://download.bareos.org/bareos/release/latest/CentOS_6/bareos.repo“

Die Installation auf Debian / Proxmox

Auf Debian ist bareos bereits in den Standard-Repositories enthalten. Daher können Sie direkt über apt-get den bareos-filedaemon installieren:

1
2
apt-get install bareos-filedaemon
systemctl enable bareos-filedaemon

Linux-Client auf dem Director einrichten

Damit nun der neue Linux-Rechner auch dem Bareos-Director bekannt gemacht wird, müssen wir folgendes auf dem zentralen Bareos-Director ausführen.

1
2
3
bareos# bconsole
*configure add client name=&lt;CLIENT&gt; address=&lt;IP/FQDN&gt; password=&lt;SOME_PASSWORD&gt;
*quit

Hinweis: Ich empfehle beim Client-Namen und bei der Adresse jeweils den FQDN des zu sichernden Servers zu verwenden.
Anmerkung: Die Anlage eines Client in der Web-Gui ist (bis jetzt) leider nicht möglich.

Linux-Client anlegen in der Konsole von Bareos

Linux-Client anlegen in der Konsole von Bareos

Beispiel:

1
2
3
4
5
6
7
8
9
10
11
12
*configure add client name=skisp02.veryhost.de address=skisp02.veryhost.de password=geheim123
Exported resource file "/etc/bareos/bareos-dir-export/client/skisp02.veryhost.de/bareos-fd.d/director/bareos-dir.conf":
Director {
Name = bareos-dir
Password = "[md5]576aa4c2e8948b2a10d21617d3a84085"
}
Created resource config file "/etc/bareos/bareos-dir.d/client/skisp02.veryhost.de.conf":
Client {
Name = skisp02.veryhost.de
Address = skisp02.veryhost.de
Password = geheim123
}

Bareos legt nun die Client-Datei, die Sie gleich auf den Linux-Client kopieren unter „/etc/bareos/bareos-dir-export/client/<clientname>/bareos-fd.d/director/ ab.
Die dort abgelegte Datei „bareos-dir.conf“ kopieren Sie auf den Linux-Client in das Verzeichnis
/etc/bareos/bareos-fd/director
Anschließend starten Sie den bareos-FileDaemon neu.

1
Client# service bareos-fd restart

Backup-Job für den Linux-Server anlegen

Damit anschließend auch wirklich täglich Backups erstellt werden, benötigen wir wie beim Windows-Client auch eine Job-Definition. Diese erstellen Sie ebenfalls über die Bareos-Konsole:

1
2
3
Bareos# bconsole
*configure add job name=&lt;fqdn&gt;.job client=&lt;fqdn&gt;jobdefs=DefaultLinux
quit

Wenn Sie nun nichts weiter tun, dann wird der Backup-Job entsprechend der Backup-Konfiguration während der folgenden Nachstunden starten. Wenn Sie den Backup-Job sofort starten lassen möchten, dann geben Sie folgendes ein:

1
2
Bareos# bconsole
*run job=&lt;clientname&gt;.job

Beantworten Sie die abschließend Frage mit “y“ und schon startet der Backup-Job.

Den Backup-Job für den Linux-Client starten

Den Backup-Job für den Linux-Client starten

Anmerkung:
Sofern einmal eine Job-Definition für einen Client angelegt ist und der Backup-Job läuft, können Sie alle weiteren Aktionen in der Web-Oberfläche von Bareos durchführen.

Fazit zu Bareos

Bareos ist mit einigen kleinen Hürden ein sehr brauchbares Tool zur Sicherung von verteilten Rechnern. Vor allem die Web-Oberfläche macht es den Netzwerk-Admins sehr leicht, die täglichen Jobs für Backup und Restore im Blick zu haben.
Welche Anpassungen Sie an Bareos für eine flächendeckende Nutzung mit vielen Clients vornehmen sollten, behandeln wir im zweiten Teil des Tutorials zur Bareos.

Weiterführende Infos zu Bareos

Weitere Informationen und Sites zu Bareos Online-Backup:

Da Bareos immer noch in viele Einstellung identisch mit Bacula ist, hilft an einigen Stelle auch die Doku von Bcula weiter: Hompage von Bacula
Bücher zu Bacula bzw. Bareos: