In dieser Einführung zu IPv6 erklären wir daher nicht nur den Unterscheid zwischen IPv4 und IPv6 sondern zeigen außerdem wie IT-Administratoren die neuen IPv6 Adressen sinnvoll nutzen können.

Jeder Server, jedes Smartphone das mit dem Internet verbunden ist, benötigt zur Kommunikation eine IP (Internet Protokoll) Adresse. Dabei sind die TCP/IP-Adressen für Computer-Netzwerke das, was Nummernschilder für ein Auto sind. Sie identifizieren einen Host-Computer eindeutig und ermöglichen es erst, dass die Datenkommunikation zwischen den richtigen Partner stattfinden kann.

Das Problem mit IPv4-Adressen im Internet

Seit der Einführung des Internets Anfang der 1990er Jahre wurden an Firmen, Internet-Provider und z.T. an Privathaushalte IPv4-Adressen vorgegeben. Diese Nummern im Format 123.231.123.254 werden aus Ziffer (0 bis 9) gebildet und bilden einen so genannten Adressraum vom maximal 2^32 Adressen.

2^32 Adressen sind ca. 4,3 Milliarden, wovon ca. 3,7 Milliarden tatsächlich genutzt werden können. Das hört sich nach viel an – ist es aber letztlich nicht. Wenn man bedenkt, dass heute 8-9 Milliarden Menschen auf der Erde leben und in den Industrieländern viele Menschen deutlich mehr als ein Gerät besitzen, mit dem Sie im Internet sind, dann relativiert sich die Zahl von 4,3 Mrd. IPv4-Adressen recht schnell. Die Anzahl von IPv4 Adressen ist schlicht zu wenig um noch alle Geräte der Welt mit IP-Adressen zu versorgen.

Dieser Umstand wurde bereits 1999 von der IETF (Internet Engineering Task Force) erkannt und man veröffentlichte die Erweiterung des IP-Adressraums für das Internet auf die nächste Generation von IP-Adressen: IPv6 war geboren

Warum IPv6

Der Hauptgrund von IPv4 auf IPv6 zu wechseln ist der massiv vergrößerte Adressraum, den IPv6 Adressen abbilden können. Bereits im Jahr 1999 wurde von der IETF ein maximaler Adressraum von 2^128 Bit vorgesehen. Statt 2^32 IPv4-Adressen können mit IPv6 nun 2^128 Adressen abgebildet werden.

Das sind 340,282,366,920,938,463,463,374,607,431,768,211,456 Adressen (Sextillionen = 3,4·1038)

Damit könnte theoretisch jedes Sandkorn auf der Erde eine eigene, eindeutige IPv6-Adresse erhalten.

Wie ist eine IPv6 Adresse aufgebaut?

Eine IPv6 Adresse wird nicht mehr in der dezimalen Schreibweise von IPv4 ausgedrückt, sondern hexadezimal. Eine IPv6 Adresse kann also aus den Ziffern 0 bis 9 und den Buchstaben A bis F bestehen. Dabei besteht eine IPv6 Adresse aus 8 Blöcken zu je 4 Hexadezimalen-Zahlen.

Eine Beispiel-Adresse sieht demnach so aus:

2001:0db8:1234:5678:90ab:cdef:1111:ffff

Schreibweisen von IPv6 Adressen

IPv6 Adressen sind aufgrund des größeren Adressraums deutlich länger als ihre Vorgänger IPv4. Daher gibt es für die Schreibweise von IPv6 Adressen die Möglichkeit diese verkürzt darzustellen.

  • Führende Nullen eines Blocks (Die Bereiche zwischen zwei „:“ Zeichen) können immer weg gelassen
  • Zwei oder mehr aufeinander folgende 0er-Bereiche können als zwei Doppelpunkte „::“ dargestellt werden. Dies ist innerhalb einer IPv6 Adresse aber nur einmal erlaubt, da die Adresse sonst nicht mehr eindeutig wäre.
  • Die Buchstaben A bis F sollen klein geschrieben werden (also a,b,c,d,e,f).

Die Beispiel-Adresse 2001:0db8:0000:0000:0123:0000:0000:0adf kann demnach wie folgt gekürzt werden:

  • 2001:db8::123:0:0:adf

Die führenden Nullen entfallen in allen Blöcken und der dritte und vierte Block mit jeweils :000: werden als „::“ dargestellt. Der sechste und siebte Block werden jeweils als :0: dargestellt.

Ebenso wäre richtig:

  • 2001:db8:0:0:123::adf

Hier würde im Gegensatz zum ersten Beispiel der „::“ Block die letzten beiden :000: Blöcke ersetzen.

Nicht richtig wäre folgende Darstellung:

  • 2001:db8::123::adf

Diese Darstellung ist falsch, da die IPv6 Adresse nicht mehr eindeutig ermittelt werden kann. Die Notation „::“ darf daher in einer IP-Adresse nur einmal vorkommen.

Subnetze im IPv6 Adressbereich

Unter IPv4 wurden Subnetze meist in der Regel in der Form 192.168.0.0/24 dargestellt. Die Subnetzmaske (hier /24) definierte dabei die maximal Anzahl von Hosts (=Computern) in einem Subnetz. Daran hat sich bei IPv6 an sich nichts geändert – lediglich die Subnetze werden größer.

Die Empfehlung bzw. Vorgabe der Vergabestellen für IP-Adressen im Internet sind so genannte Prefixe von /64. Das bedeutet, daß der kleinste an eine Endanwenderfirma vergebene IP-Adressbereich bereits 9,223,372,036,854,775,807 Adressen umfasst.

Als Beispiel: 2001:db8:1234:abcd:: /64

Die nutzende Firma hätte dann die Adressen von 2001:db8:1234:abcd:0000:0000:0000:0001 bis 2001:db8:1234:abcd:ffff: ffff: ffff: ffff zur Verfügung.

Eine einzelne IPv6-Adresse kann mit dem Anhang „/128“ als einzelne Adresse dargestellt werden.

Bsp.: 2001:db8::123:0:0:adf /128

Diese Darstellung entspricht der Notation von 192.168.1.1/32 im IPv4 Schema.

Besonderheiten von IPv6

Mit der Einführung und Nutzung von IPv6 ergeben sich gleichzeitig einige Änderungen gegenüber IPv4.

Kein NAT mehr unter IPv6

Network Adress-Translation (NAT) wird unter IPv4 dazu verwendet, bestimmte Netzwerk-Subnetze wie 192.168.0.0/16 oder 10.0.0.0/8 als private Netze zu definieren, die nicht im Internet geroutet werden. Die Firewalls und Router der betroffenen Firmen mussten also den IPv4 Datenverkehr zwischen dem internen Netz und dem Internet übersetzen.

Damit war es möglich den Adressbereich von IPv4 länger zu nutzen. Im Umkehrschluss wurde damit aber die Ende-zu-Ende Kommunikation von zwei Knoten im Internet praktisch unmöglich.

Technisch ist NAT mit IPv6 Adressen zwar immer noch möglich. Es sollte aber unbedingt vermieden werden, schließlich gibt es ja keinen Mangel mehr an individuellen IPv6-Adressen.

ICMP muss möglich sein – auch aus dem Internet

Damit die Ende-zu-Ende-Kommunikation zwischen allen Endgeräten im Internet funktioniert, muss das ICMP (Internet Control Message Protocol), etwa ein „ping“,  von allen IPv6-Adressen aus möglich sein. Kurz gesagt: IPv6 basiert darauf, dass auch interne IPv6-Adressen von extern aus pingbar sind.

Für Firewall-Administratoren ergeben sich daraus ganz neue Anforderungen. Waren Sie in der Vergangenheit gewohnt, ihre Firewall von der WAN-Seite (WAN=Wide Area Network, i.d.R. das Internet) abzuschotten, so sollten Sie unter IPv6 ihre Firewall zumindest für ICMP-Pakete öffnen.

DHCPv6 und Router Advertisments (RA)

Wie auch bei IPv4 so ist es auch beim Nachfolger IPv6 möglich Endgeräten dynamisch IP-Adressen über den Dienst DHCP zuzuweisen. Im Gegensatz zu DHCP unter IPv4 fehlt dem DHCPv6 aber (absichtlich) der Default-Gateway. Diese unter IPv4 obligatorische Pflichtangabe des Ausgangs aus dem eigenen Subnetz übernimmt unter IPv6 der Dienst Router Advertisments (RA).

Sobald auf einer Firewall (z.B. opnsense oder pfsense) oder einem Host ein Netzwerk-Interface IPv6 „spricht, so muss dann neben dem DHCPv6 Dienst der RA-Dienst aktiviert werden, damit Clients, die ihre IPv6-Adresse über DHCP erhalten, über welchen Weg sie den Rest des eigenen Netzwerks oder des Internets erreichen

Neighbor Discovery Protokoll (NDP) statt ARP

Unter IPv4 diente das „Adress Resolution Protocoll“ (ARP) dazu eine IP-Adresse eindeutig einer MAC-Adresse (der physischen Hardware Adresse eines PCs) zuzuordnen.

Bei IPv6 übernimmt diese Rolle das Neighbor Discovery Protocoll (NDP). Dieser Dienst ist bei den allermeisten Geräten die IPv6 unterstützen aktiv, sobald eine IPv6 Adresse eingetragen oder über DHCPv6 bezogen wurde.

AAAA Records im DNS

Damit die Kommunikation für Endanwender im Internet beherrschbar ist, arbeiten Browser und andere Software-Produkt in der Regel nicht mit IP-Adressen sondern mit besser verständlichen Namen. Der Dienst hinter diesem Namensregister lautet Domain Name System, kurz DNS. Hier werden Namen zu IP-Adressen gespeichert.

Bei der Kommunikation im Web wird dann aus www.wikipedia.de die IPv4 Adresse 134.119.24.29 . Dies ist ein so genannter A-Record.

Damit nun auch IPv6 Adressen im DNS gespeichert werden können, wurde mit IPv6 der AAAA-Record (gesprochen: tripple „Ä“) im DNS eingeführt. Damit können einem Namen im DNS neben dem bestehenden A-Record für seine IPv4-Adresse zusätzlich eine IPv6-Adresse mit gegeben werden.

Wer also mit nslookup die Adresse www.google.de abfragt, der erhält sowohl die Ipv4 als auch die IPv6 IP-Adresse als Antwort:

Name:    www.google.de

Addresses:    2a00:1450:4016:80a::2003

172.217.21.99

Besondere IPv6 Adressen

So wie es bei IPv4 besondere Netze für die private Nutzung oder Localhost-Adressen gibt, so gibt es auch bei IPv6 einige spezielle (Sub-)Netze, die gesondert behandelt werden:

Die Localhost Adresse in Ipv6:

Die klassische Localhost-Adresse lautet für IPv6 ::1/128. Oder ausführlich: 0000:0000:0000:0000:0000:0000:0000:0001 /128 .

Die IPv6 Adresse „::1 /128“ ist das Equivalent zu 127.0.0.1 in IPv4.

Reservierte Netze

Einige Netze oder Prefixe werden seitens der IANA gar nicht vergeben. So ist etwa 2000:: /3 für den Global Unicast reserviert. Daneben sind noch weitere /3 Prefixe (also Subnetze) global reserviert.

Ebenfalls nicht produktiv nutzbar ist das Netz 2001:0db8:: /32. Adressen die mit 2001:db8: beginnen werden in der Regel nur zu Dokumentations- und Demonstrations-Zwecken verwendet (siehe dazu auch rfc3849 der IETF).

URL-Notation von IPv6-Adressen

Wer eine über IPv6 erreichbare URL im Browser über die IP-Adresse aufrufen möchte, muss sich eine neue Notation für den Aufruf der URL einprägen. Damit der Browser die IPv6 von einer IPv4 Adresse unterscheiden kann, lautet der Aufruf:

http://[IPv6:Port]/

Die IPv6-Adresse wird also in eckige Klammern gesetzt. Die Verwendung eines Ports ist optional. Mit einer kompletten IPv6-Adresse sieht das dann z.B. so aus:

http://[2001:db8::123:0:0:adf :7344]/

Parallelbetrieb von IPv4 und IPv6

Wer nun in seinem Netzwerk IPv6 IP-Adressen einführen möchte, der muss nicht sofort alle IPv4 Adressen löschen. Ganz im Gegenteil.

Praktisch alle Betriebssysteme von PCs, Servern und Smartphones bieten seit geraumer Zeit die Möglichkeit sowohl eine IPv4 als auch eine IPv6 Adresse pro einzelnem Gerät zu vergeben. Das bildet den Grundstein für den parallelen Betrieb von IPv4 und IPv6 nebeneinander.

So haben etwa Windows-Server seit der Version 2003 und PCs seit Windows XP die Möglichkeit sowohl eine Ipv4 als auch eine IPv6 Adresse zu vergeben. Auch die meisten Hersteller von Switches und Routern haben IPv6 schon vor langer Zeit in ihre Geräte integriert.

Wer also ein aktuelles Betriebssystem hat und aktuelle Netzwerk-Hardware nutzt, der kann in der Regel IPv6-Adressen eingeben und verwalten.

Migration von IPv4 zu IPv6

Um nun schrittweise die eigene Infrastruktur für IPv6 fit zu machen, sollten IT-Administratoren sich zunächst um die Zuweisung eines statischen /64 Präfixes kümmern. Diesen erhalten Sie in der Regel von ihrem ISP (Internet Service Provider).

Hinweis: Kunden des IT-Dienstleisters Biteno GmbH erhalten im für Services im Rechenzentrum der Biteno einen /64 Präfix aus unserem Netzabschnitt 2a06:fbc0:: /29 der uns von der europäischen Vergabe-Agentur RIPE zugewiesen wurde.

Im zweiten Schritt gilt es dann – wie auch schon bei IPv4 – allen Servern und statischen Geräten eine feste IPv6 Adresse zu vergeben.

Endgeräte, die von Anwendern genutzt werden, erhalten dann ihre IPv6 Adresse über DHCPv6 in Kombination mit dem weiter oben beschriebenen Router Advertisments.

Da Umstellungen bzw. Einführungen von IPv6 im Unternehmen nicht einmal nebenbei erfolgen können, empfiehlt es sich, zunächst die Hilfe eines erfahrenen Consultants eines IT-Dienstleisters in Anspruch zu nehmen.

IPv6 testen

Wer heute einmal probehalber testen möchte, ob sein Endgerät schon mit IPv6 kommuniziert, kann das auf den folgenden Seiten testen:

Auf dem eigenen PC/Notebook kann man die eigene IPv6 Adresse mit dem Befehlt “ipconfig /all” ermitteln. Das Ergebnis sieht dann z.B. so aus:

IPv6 Konfiguration auf dem eigenen PC/Notebook

IPv6 Konfiguration auf dem eigenen PC/Notebook

Fazit zu IPv6

Bei IPv6 müssen IT-Administratoren einige wichtige Besonderheiten wie den Wegfall von NAT oder die besondere Schreibweise von IPv6-Adressen “lernen” und verstehen. Sobald diese Neuigkeiten verdaut sind, steht dem produktiven Betrieb der eigenen IT-Infrastruktur mit IPv6 aber nichts mehr im Wege.

Active Directory an Office 365 anbinden

Immer mehr Firmen nutzen auf Basis von Microsoft Azure den Cloud Service Microsoft Office 365. Dabei wird neben dem klassischen Office Produkt (bspw. Office 2016) jedem lizenzierten Benutzer ein Postfach auf Basis von Microsoft Exchange zur Verfügung gestellt. Das ist insofern praktisch, da es auch kleinen Unternehmen mit wenigen Postfächern ermöglicht Microsoft Exchange in Anspruch zu nehmen.

Neben Office 365 haben die meisten Firmen aber nach wie vor lokale Windows-Installationen in Betrieb, für die sie ein Active Directory zur Verwaltung der Benutzer und deren Rechte einsetzen. Der IT-Administrator steht anschließend vor der Aufgabe, daß an zwei Stellen Benutzer verwaltet werden müssen: Einmal im lokalen Active Directory und ein zweites Mal innerhalb des Office 365 Mandanten (engl. Tenant). Das ist insofern unschön, da jeder Benutzer dann einmal im Active Directory als auch in Office 365 gepflegt und verwaltet werden muss.

Microsoft Azure Directory Connect (bzw. Azure Directory Sync) löst dieses Problem, in dem das lokale Active Directory des Unternehmens mit dem Mandanten von Office 365 so verbunden wird, daß die angelegten Benutzer weiterhin nur an einer Stelle verwaltet werden müssen.

Voraussetzungen für den Directory Sync mit Azure

Damit die Synchronisation zwischen Active Directory und Office365 einwandfrei funktioniert, müssen einige Voraussetzungen erfüllt sein:

  • Eigentlich selbstverständlich: Ein Office 365 Mandant muss für die Firma angelegt und vorhanden sein.
  • Die Installation der Synchronisations-Software selbst muss auf einem Member Server innerhalb des Active Directory erfolgen. Die Installation auf einem Domain Controller ist zwar prinzipiell möglich wird aber nicht empfohlen.
  • Der Server auf dem Azure Directory Sync installiert wird, muss ein 64-bit Betriebssystem haben(Windows 2008 R2, Windows Server 2012 oder 2016)
  • Auf dem Server sollten min 70 GB Platz vorhanden sein. Als Mindestanforderung für den Hauptspeicher gibt Microsoft 4 GB RAM an.
  • Ein administrativer (d.h. privilegierter) Account im lokalen Active Directory
  • Ein administrativer Account im Office 365 Tenant (Mandant) bei Microsoft Azure

Eine gern übersehene Voraussetzung für die  erfolgreiche Verbindung zur Office 365 ist, daß die interne Domain des Active Directory (im Internet) routing-fähig ist.

In anderen Worten: keine domain.local oder .intra sondern „domain.com“ oder „domain.de“. Sofern Sie eine (bereits seit Jahre) bestehende interne Domain in ihrem AD haben, die auf eine nicht routing-fähige Endung hört (bspw. *.local), so kann mit einem so genannten Benutzerprinzipalname-Suffix dieser „Fehler“ behoben werden. Mehr dazu am Ende.

Hinweis: Was mit Azure AD Sync nicht geht

Der Wunsch manches Firmenchefs oder IT-Verantwortlichen zum Trotz: Das kostenfreie Verzeichnis von Benutzern bei Office 365 ersetzt nicht ein echtes Active-Directory im eigenen Rechenzentrum bzw. in den Räumen des eigenen Unternehmens. Mit dem reinen Office 365 kann man also keine lokalen Benutzer am heimischen PC authentifizieren.

Wer also den Wunsch nach einer vereinfachten Verwaltung von Computern und Ressourcen im Unternehmens-eigenen Windows Netz hat, der kommt auch weiterhin nicht um ein funktionierendes Active Directory herum.

Übrigens: Der Active Directory Sync muss schon aus Firewall-Gründen ein Push Mechanismus sein, der also vom bestehenden AD aus eine Synchronisation zu Office 365 hin anstößt. Wollte man aus Office 365 heraus einen Sync betreiben (was aber eben nicht geht), so müsste die Firewall des Unternehmens „aufgebohrt“ werden. Das ist aber in 99% aller Fälle weder gewollt noch sinnvoll.

Klappt der Sync denn auch?

Um bei der ersten – hoffentlich erfolgreichen Synchronisation direkt in Office 365 prüfen zu können, ob der Abgleich der Konto einwandfrei funktioniert, haben wir in unserem Active Directory einen Test-Benutzer angelegt, für den es in unserem Office 365 Mandanten noch kein Konto gibt.

In unserem Beispiel habe ich den Anwender „Peter Testmann“ angelegt und ihm ein Passwort vergeben.

Wichtig dabei. Das Feld E-Mail sollte ausgefüllt sein. Es wird später für die Synchronisation und eindeutige Zuordnung benötigt.

Installation von Azure Directory Sync

Nach dem wir nun alle Voraussetzungen geprüft haben und die Kontodaten der beiden notwendigen Accounts (einmal Office365 und einmal Admin aus dem lokalen Active Directory) beisammen haben, können wir auch loslegen.

Das Azure Directory Sync Tool kennt bei zwei Installationsarten:

  • Express und
  • Benutzerdefiniert mit angepassten Einstellungen

Die Express-Installation des Sync-Tools erfragt im wesentlichen „nur“ die Zugangsdaten der beiden Accounts für Office 365 und das lokale AD. Wer mehr Kontrolle über die Einrichtung und die Definition der Synchronisation haben möchte, sollte unbedingt die angepasste Einrichtung wählen. Im nachfolgenden beschreibe ich die benutzer-definierte Installation des Tools.

Starten der Installatoin von Azure Directory Sync

Starten der Azure AD Installation

Starten der Azure AD Installation

Zunächst laden wir das Programmpaket für den Directory Sync herunter:

https://www.microsoft.com/en-us/download/details.aspx?id=47594

Die Installation starten Sie als Administrator mit einem Doppelklick, akzeptieren die Lizenzbedingungen und klicken anschließend unten rechts auf „Weiter“.

 

 

Erforderliche Komponenten für Azure Directory Sync

Die erforderlichen Bestandteile des AC Sync

Die erforderlichen Bestandteile des AC Sync

In der nächsten Maske, können Sie folgende Dinge ändern:

– anderer Installationsort (Default: „C:\Program Files\Microsoft Azure AD Sync“)

– ein bestehender SQL Server (sonst wir ein SQL Express installiert)

– bestehender Account in der AD

– benutzerdefinierte Synchronisierungsgruppen Gruppen (statt Administratoren, Benutzer etc.)

 

Sofern Sie eine der Optionen anpassen möchten, setzen Sie den entsprechenden Haken.

Anschließend klicken Sie unten rechts auf „Installieren“.

 

Azure Sync: Benutzeranmeldung

Die Optionen für „Benutzeranmeldung“ steuert, wie im zukünftigen Sync die Passwörter synchronisiert werden.

Standardmäßig ist die „Kennworthashsynchronisierung“ ausgewählt. Dabei werden die verschlüsselten Hash-Werte der Passwörter vom lokalen AD nach Office 365 übertragen – umgekehrt allerdings nicht.

Für die meisten Anwendungsfälle wird dies allerdings vollkommen ausreichen.

Wer seinen Anwendern die Möglichkeit eines Single-Sign-On (SSO) zur Verfügung stellen möchte, der setzt ganz unten den Haken bei „Einmaliges Anmelden aktivieren“.

Anschließend klicken Sie wieder unten rechts auf „Weiter“.

Sync: Mit Azure AD verbinden

In der nächsten Maske geben Sie die Zugangsdaten eines administrativen Benutzers ihres Office 365 Mandanten an.

Bspw.: admin@<ihr-mandant>.onmicrosoft.com

Bei „Kennwort“ tragen Sie das Passwort ein.

 

Azure Sync: Verzeichnisse verbinden

Azure mit dem lokalen active Directory verbinden

Sofern Ihr Kennwort richtig war, erscheint nun die folgende Übersicht:

Als Verzeichnistyp sollte „Active Directory“ ausgewählt sein.

Darunter können Sie im Dropdown „Gesamtstruktur“ das Verzeichnis auswählen, das Sie synchronisieren möchten.

Klicken Sie dazu auf den günen Button „Verzeichnis hinzufügen“.

 

 

 

Danach sollte die Maske so aussehen:

Klicken Sie nun wieder unten rechts auf „Weiter“.

 

 

 

AD-Gesamtstrutkturkonto in der lokalen Domain

In der Übersicht „AD-Gesamtstrukturkonto“ werden Sie nun nach dem weiter oben erwähnten administrativen Account aus ihrem Active-Directory gefragt.

Dabei können Sie wählen ob für die Synchronisation ein neues Konto in ihrem AD angelegt wird oder ob Sie einen bestehenden Account (AD-Konto) nutzen möchten.

Ich empfehle hier das Programm ein neues AD-Konto anlegen zu lassen. Das dann angelegte Konto sollte wirklich nur zum Zweck der Synchronisierung verwendet werden.

Achtung: Um ein Konto durch das Sync-Tool anlegen zu lassen, müssen Sie um Feld „Benutzername des Unternehmensadministrators“ den Namen des Admin-Kontos in der Form „DOMAIN\Benutzer“ angeben. Das darunter liegende Feld für das Passwort war in unserem Fall mit der Maus nicht zu erreichen. Nur mittels TAB und „blindem“ Eingeben klappte es dann doch. – Klicken Sie anschließend auf „OK“.

Azure AD-Anmeldekonfiguration

In der nun folgenden Maske „Azure AD-Anmeldungskonfiguration“ legen Sie fest, welches Feld aus ihrem Active-Directory genutzt wird, um sicher zu stellen, dass Benutzer eindeutig sind.

Gemeint ist hier der so genannte „User Principal Name“ (kurz UPN). Sie sollten diesen den Wert auf „userPrincipalName“ belassen.

Damit ist die Langform der Anmeldung in der Form benutzer@domain.tld (also etwa: mark.testmann@beispiel.de“ gemeint

Wichtig: Setzen Sie hier bitte den Haken unten bei „Ohne Abgleich aller UPN-Suffixe …“ und klicken anschließend auf „Weiter“.

 

 

Azure Sync: Filtern von Domänen und Organisationseinheiten

In der Maske „Filtern von Domänen und Organisationseinheiten“ können Sie detailliert festlegen, was Sie genau synchronisiert haben wollen.

Es empfiehlt sich in jedem Fall die Benutzer (Users) zu synchronisieren. Ob Sie weitere Elemente synchronisieren möchten, muss jeweils in Ihrem Anwendungsfall entschieden werden.

Klicken Sie nach dem Anhaken der für Sie passenden Kreuze unten rechts auf „Weiter“.

 

 

Active Directory Sync: Ihre Benutzer werden eindeutig identifiziert

In der nun folgenden Maske „Ihre Benutzer werden eindeutig identifiziert“ können Sie vom Standard abweichende Einstellungen angeben, wo und wie das Sync-Tool sicherstellt, dass die Zuordnung von AD-Benutzern zu Office 365 Accounts korrekt erfolgt.

Sofern Sie ihre AD-Benutzer nur einmal angelegt haben, sollten Sie die Einstellungen im Standard so belassen:

Oben: „Benutzer werden nur ein Mail in allen Verzeichnissen dargestellt“.

Unten: „..Quellanker durch Azure verwalten lassen“.

Sofern Sie davon abweichen sollten Sie sowohl oben (im AD) und unten (in Office 365) einen Feld mit möglichst identischem Inhalt wählen – etwa die E-Mail Adresse (da diese immer eindeutig sein muss).Klicken Sie anschließend wieder unten rechts auf „Weiter“.

 

Directory Sync: Benutzer und Geräte filtern

In der Maske „Benutzer und Geräte filtern“ können Sie entscheiden ob Sie ein Alle Benutzer ihres Active Directory synchronisieren lassen möchten, oder ob Sie eine bestimmte Organisationseinheit (engl. OU) innerhalb ihres Directory auswählen.

Wenn Sie etwa mit Subdomains arbeiten, so können Sie hier die für ihren Anwendungsfall passende OU auswählen.

Klicken Sie anschließend wieder auf Weiter.

 

Azure Sync: Optionale Features

In der vorletzten Eingabemöglichkeit „Optionale Features“ können Sie folgende Einstellungen vornehmen:

Anpassungen zur Synchronisierung von Microsoft-Exchange und öffentlichen Ordnern von MS-Exchange.

Hinweis: Diese Option erscheint nur, wenn Sie vorher bereits einen Exchange Server in ihrem Active Directory in Betrieb haben.

Sofern Sie weiter oben die Standard-Option „Kennworthashsynchronisierung“ aktiviert haben, ist diese bereits angekreuzt und ausgegraut.

Klicken Sie nun noch einmal unten rechts auf Weiter.

 

Azure Active Directory Sync: Bereit zur Konfiguration

Herzlichen Glückwunsch: Sie sind nach diesem Options-Marathon auf der finalen Maske angelangt.

Sofern Sie den Haken bei „Starten Sie den Sychronisierungsvorgang, nach dem die Konfiguration abgeschlossen wurde“ gesetzt lassen, wird direkt nach der Installation des Tools der erste Abgleich zwischen dem Active Directory und ihrem Office 365 Mandanten erfolgen.

 

Klicken Sie (diesmal wirklich zum letzten Mal) unten rechts auf den grünen Button „Installieren“.

 

Sie erhalten die allerletzte Maske als Bestätigung, was nun synchronisiert wird.

Klicken Sie unten rechts auf „Beenden“.

 

 

 

 

 

Klappt die Synchronisation mit Azure Active Directory Sync?

Wenn nun alles richtig funktioniert hat, dann sollten wir den eingangs angelegten Testbenutzer „Peter Testmann“ in Office 365 wieder finden.

Um das zu prüfen loggen Sie sich mit einem administrativen Benutzer unter https://portal.office.com ein und klicken dort anschließend auf => Admin => Users => Active Users

Im Screenshot können Sie erkennen, dass „Peter Testmann“ erfolgreich angelegt wurde.

Melden Sie sich nun wieder von Office 365 ab. Anschließend melden Sie sich direkt wieder unter https://portal.office.com an. Diesmal nutzen Sie allerdings die Zugangsdaten ihres Testbenutzers aus dem lokalen Directory ihres Unternehmens.

Sie sollten sich nun mit dem Benutzernamen und dessen Passwort aus dem lokalen Active-Directory bei Office 365 anmelden können.

Troubleshooting und FAQ

Frage: Meine interne Active Directory Domain  hat eine Endung die im Internet nicht routing-fähig ist (z.B. domain.local) . Wie kann ich trotzdem meine bestehende Domain mit Office 365 verwenden?

Antwort: Sie müssen vor der Installation des Directory Sync ein zusätzliches Benutzerprinzipalnamen-Suffix (zu Deutsch: Domain-Endung) für ihre Domain anlegen.

Das geht so:

Auf einem Domain Controller ihrer internen AD öffnen Sie die Management-Konsole für Active Directory Domänen und Vertrauensstellungen. Im obersten Ast (oberhalb ihrer Domain) klicken Sie mit der rechten Maustaste auf „Active Directory-Domänen und –Vertrauensstellungen“ und dann auf Eigenschaften. Fügen Sie nun im Feld „Alternative Benutzerprinzipalnamen-Suffixe“ eine Routing-fähige Endung hinzu.

Bsp.: Wenn ihre bisherige AD-Domain „domain.local“ heißt, dann gehen Sie hier „domain.com“ oder „domain.de“ ein –also alles nach dem @ . Speichern Sie die Veränderungen mit „OK“ ab.

Bei der Anlage bzw. Bearbeitung eines Benutzerkontos können Sie anschließend statt der Endung @domain.local auch die gerade eingegebene Domain-Endung auswählen, die dann später bei Office 365 zur Anmeldung verwendet werden kann.

Wählen Sie dazu rechts neben dem Feld „Benutzeranmeldename“ die gewünschte Domain-Endung aus. Im Beispiel rechts wurden zwei zusätzliche Domain-Endungen vergeben.

Fazit:

Trotz des etwas länglichen Installations-Dialog bei der ersten Einrichtung von Azure Active Directory Sync kann man ein bestehendes Active Directory relativ einfach an Office 365 anbinden. Auf diese Weise erspart man sich die doppelte Administration der Benutzer (und ihrer Passwörter)  und kann so das vorhandene Directory komfortable zur Benutzer-Administration in beiden Welten verwenden.

Quellen:

Links

https://docs.microsoft.com/de-de/azure/active-directory/connect/active-directory-aadconnect-get-started-custom

Bücher:

Das über 1000 Seiten dicke Buch „Microsoft Office 365 – das umfassende Handbuch“ ist Nachschlagewerk und Einführung in einem.

https://www.amazon.de/Microsoft-Office-365-Administratoren-Deutschland/dp/383624473X/ref=pd_lpo_sbs_14_t_0?_encoding=UTF8&psc=1&refRID=AXJX91RQWZAXF5MWKBNJ

 

 

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&gt; 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.

Einleitung: Hochverfügbarer Samba-Server

Je größer eine Firma bzw. deren Infrastruktur wird, desto unwahrscheinlicher ist es, daß man einen einzelnen Host im laufenden Betrieb updaten oder gar herunter fahren kann. Für den sicheren Systembetrieb ist es aber wesentlich, daß aktive Komponenten regelmässig gewartet bzw. aktualisiert werden können. Im Zuge von Updates und Wartung ist sehr häufig ein Reboot des betroffnene Servers notwendig. Leider geht mit Reboots einher, dass Anwender nicht auf die IT-Dienste des Servers zugreifen können.

In diesem Tutorial werden wir einen Ausfallsicherer Samba-Server mit LVM, Gluster-FS sowie Pacemaker/Corosync einrichten und konfigurieren.

Konzeptioneller Ansatz

Um selbstverständliche Dienste wie Windows-Freigaben (etwa für Team-Laufwerke oder andere Shares) ausfallsicher und mit hoher Verfügbarkeit zu gestalten, braucht es an sich nur 3-4 wesentliche Komponenten:

  • 2 identische Hosts
  • Ein oder mehrere gespiegelte Dateisysteme sowie einen Mechanismus zur Synchronisierung der Daten
  • LVM zur nahtlosen Erweiterung des Storage-Bereichs
  • 100%-ige Erreichbarkeit eines der beiden Hosts über eine Cluster-IP-Adresse
  • Samba für die Freigabe(n)

Wirklich wichtig für die nahezu 100-prozentige Verfügbarkeit ist, daß die beiden Hosts sich praktisch nichts teilen, was immer online sein muss.

Beispiel: Wenn wir das File-System mit den Freigaben auf eine zentrale Storage (Storage-SAN oder NAS) legen würden, so hätten wir einen Teil des Systems nur einmal vorrätig, so daß beim Fehlen dieses Bestandteils das Gesamt-System nicht mehr funktionieren würde. Das zentrale Storage wäre ein großer (und meist teurer) „Single Point of Failure“ (SPoF)

Daher: Die beiden Hosts werden also als exakte Klone voneinander betrachtet. Sie teilen sich nichts – zumindest nichts physisches. Dieses Prinzip des „shared nothing“ erreichen wir durch den Einsatz der Opensource-Software Gluster-FS, das das Dateisystem spiegelt.

Die einzige Ressource die entweder auf dem einen oder dem anderen Host vorhanden ist, ist die Cluster-IP (oder Service-IP) die mit Pacemaker/Corosync immer auf einem aktiven Host vorhanden ist und sich im Ernstfall binnen Sekunden auf den jeweils anderen Host übertragen läßt

Um das Dateisystem der beiden Hosts später auch im laufenden Betrieb erweitern zu können, legen wir die Partition mit den Dateien mittels LVM (logical volume manager) unter Linux an.

Voraussetzungen

Für alles Folgende setzen wir zwei identische (virtuelle) Server mit CentOS7 voraus. Diese sollten in etwa die gleichen Ressourcen in Bezug auf RAM und CPU haben. In Sachen Festplatten bzw. Partitionen sollten die beiden Hosts identisch sein. Dabei spielt es keine wirkliche Rolle ob die Linux-Hosts physische Server oder wie in unserem Fall virtuelle Server sind.

Für unser Beispiel nehmen wir an, daß die Linux-Server folgendermaßen heißen:

1
2
3
4
5
10.51.137.245   gstest01.itsc.local     gstest01

10.51.137.246 gstest02.itsc.local     gstest02

10.51.137.247 fileserver.itsc.local    fileserver

Diese drei  Zeilen kommen in die /etc/hosts Datei.

Vorbereiten der Partitionen

Wir bereiten also 2 identische Hosts mit Minimal-Installation unter Centos 7 jeweils auf /dev/sda vor. Außerdem brauchen die Hosts ein zweites File-system /dev/sdb das in etwa identisch groß sein sollte

Im ersten Schritt legen wir mit „parted“ und „fdisk“

Schritt 1: Mit Parted und fdisk Partition anlegen:

1
2
parted /dev/sdb
mklabel -> gpt

Anschließend legen wir eine Partition /dev/sdb1 unter /dev/sdb an und wählen als Partitionstyp “LVM”.

1
2
fdisk /dev/sdb
fdisk -&gt; partition anlegen und Typ 31 auswählen

Schritt 2: Volume Group und LVM anlegen

Wir legen nun zuerst ein „physical volume“ und anschließend eine Volume Group unter LVM an.

Mit dem folgenden Schritt erstellen wir auf der Partition /dev/sdb1 eine Volume Group mit Namen „storagevg“

1
vgcreate storagevg /dev/sdb1

Schritt 3: Das eigentliche Logical Volume anlegen

1
lvcreate --name storage01 --size 198G storagevg

Der obige Befehl legt auf der Volume Group “storagevg“ das logische Volume „storage01“ mit 198 GB Speicher an.

Schritt 4: Formatieren und Einbinden des LVM

Unser frisch erstelltest LV heißt nun also „/dev/storagevg/storage01“. Auf diesem erstellen wir nun ein XFS_Dateisystem:

1
mkfs.xfs /dev/storagevg/storage01

Damit wir das Filesystem später auch nutzen können, legen wir den Mountpoint bzw. das Verzeichnis „/data“ an und mounten das LVM anschließend.

1
2
3
mkdir /data

mount /dev/storagevg/storage01 /data

 

Damit das Filesystem auch nach dem nächsten Reboot wieder unter /data eingeängt wird, tragen wir folgenden Zeile in der /etc/fstab ein.

1
/dev/storagevg/storage01 /data xfs defaults 0 0

Installation von glusterfs unter CentOS 7

Damit wir später unsere identischen Partitionen auch synchron halten können, benötigen wir ein Gluster-Filesystem. Dafür installieren wir die folgenden Pakete unter Centos:

1
2
3
yum -y install epel-release yum-priorities centos-release-gluster

yum -y install glusterfs-server

 

Anschließend aktvieren wir den Dienst und starten ihn

1
2
3
systemctl enable glusterd.service

systemctl start glusterd.service

Zur Sicherheit schauen wir uns den Status an

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
[root@gstest01 ~]# glusterfsd --version

glusterfs 3.12.9

#

# status prüfen

[root@gstest01 ~]# gluster peer probe gstest02

peer probe: success.

# Status teil 2

[root@gstest01 ~]# gluster peer status

Number of Peers: 1

Hostname: gstest02

Uuid: b8fb70b5-fa46-4b11-aaf7-c5697ca3d6da

State: Peer in Cluster (Connected)

Gluster-FS Volume erstellen

MIt dem folgenden Befehl erstellen wir nun ein Dateisystem “storage01” innerhalb von Gluster-FS, dass auf den Hosts gstest01 und gestest02 jeweils physisch unter /data liegt. Der Parameter „replica 2“ bedeutet, dass wir faktisch eine Spiegelung erstellen.

1
2
3
[root@gstest01 ~]# gluster volume create storage01 replica 2 transport tcp gstest01.itsc.local:/data gstest02.itsc.local:/data force

volume create: storage01: success: please start the volume to access data

Das eigentliche Volume unter Gluster-FS muss nun noch auf einem (!) der beiden Hosts gestartet werden. Das erledigt der Befehl:

1
2
3
4
5
6
7
#gluster volume start <volume-name>

&nbsp;

[root@gstest01 ~]# gluster volume start storage01

volume start: testvol: success

[root@gstest01 ~]#

Glusterfs client installieren und mounten

Damit das gerade erstellte Gluster-Filesystem auch nutzbar wird, muss es auf beiden Hosts auch gemountet werden.

Hinweis: Bei der Installation des Gluster-FS- Servers ist der Gluster-FS client bereits mit enthalten.

1
yum -y install glusterfs-client

Anschließend legen wir ebenfalls auf beiden Hosts das Verzeichnis “/datastore” als Mountpoint an:

1
mkdir /datastore

Nun können wir das angelegte synchronisierte Verzeichnis /datastore auf jedem der Hosts mounten:

1
mount.glusterfs gstest01:/storage01 /datastore

 

Damit der Mount auch wieder nach einem Reboot da ist, nehmen wir den Befehl in die /etc/rc.d/rc.local auf.

1
2
3
4
5
6
7
vi /etc/rc.d/rc.local

#einfügen: /usr/sbin/mount.glusterfs gstest01:/storage01 /datastore

chmod +x /etc/rc.d/rc.local

systemctl enable rc-local

Achtung wichtig: Bitte achten Sie unbedingt darauf, daß jeder Host das „eigene“ FileSystem mounted.

Also auf host „gstest01“:

1
/usr/sbin/mount.glusterfs gstest01:/storage01 /datastore

… und auf dem Host „gstest02“

1
/usr/sbin/mount.glusterfs gstest02:/storage01 /datastore

Zur Sicherheit rebooten wir nacheinander jeden Host einmal. Wenn danach das File-System und der gluster service wieder online sind, dann haben wir erfolgreich ein synchrones Filesystem mit Gluster-FS erstellt

Beim Wechsel  bzw. Reboot kommt nun noch ein etwas nerviger Timeout . Während dieser Zeit kommt der verbliebene Host nicht wirklich schnell in die Puschen. Dies kann allerdings mit einem einfachen Einstellen des Timeouts von Gluster-FS erledigt werden.

1
2
3
gluster volume info storage01

gluster volume set storage01 network.ping-timeout 10

Gluster-FileSystem testen

Wenn Sie nun das Gluster-Filesystem testen möchten, so legen Sie auf dem Host gstest01 im Verzeichnis /datastore eine Datei an. Diese sollte nach wenigen Augenblicken auf gstest02:/datastore auftauchen. Änderungen die Sie nun auf gstest02:/datastore an der Datei vornehmen, werden wiederum sofort nach gstest01:/datastore übertragen.

 

Ausfallsicherheit mit Corosync und pacemaker:

Damit wir von Clients nun noch permanent auf Samba zugreifen können, benötigen wir eine dritte, virtuelle IP-Adresse. Über diese IP bzw. den dazu passenden DNS-Namen greifen später die Benutzer auf das hoch verfügbare Samba-Verzeichnis zu. Dafür erstellen wir mit Corosync und Pacemaker folgende Konfiguration.

Wie auch für Gluster-FS sollten die beiden Hostnamen und IP-Adressen in der jeweiligen /etc/hosts auf beiden Nodes enthalten sein. Das können wir an dieser Stelle überspringen, da wir das schon weiter oben erledigt haben.

Schritt 1: Installation von Corosync und Pacemaker / pcs

Auf beiden Hosts installieren wir nun noch Pacemaker und Corosync:

1
2
3
yum  -y install pacemaker pcs
systemctl enable pcsd.service
systemctl start pcsd.service

Während der Installation  wird ein neuer User namens „hacluster“ angelegt: Diesem geben wir ein Passwort und merken es uns gut. Am besten gleich in die IT-Dokumentation schreiben….

1
passwd hacluster

(auf beiden Hosts – jeweils identisches Passwort…)

Schritt 2: Einrichtung von  Pacemaker

Hinweis: Der nachfolgende Linux-Befehl ist nur auf einem der beiden Knoten notwendig. Dazu geben Sie das Passwort des Benutzers „hacluster“ von weiter oben ein

[root@gstest01 ~]# pcs cluster auth gstest01 gstest02

1
2
3
4
5
pcs cluster auth gstest01 gstest02
Username: hacluster
Password:
gstest02: Authorized
gstest01: Authorized

 

1
2
3
4
[root@gstest01]# pcs cluster setup --name cluster01 gstest01 gstest02
Destroying cluster on nodes: gstest01, gstest02...
gstest01: Success
gstest02: Success

Schritt 3: Pacemaker Cluster starten

Als letzten Schritt starten wir nun das Pacemaker Cluster. Auch dies wird nur auf einem der beiden Server erledigt:

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

Schritt 4: Corosync und Pacemaker aktivieren

Damit die Dienste auch nach einem Reboot wieder starten, aktivieren wir sie mit systemctl:

1
2
systemctl enable corosync.service
systemctl enable pacemaker.service

Schritt 5: Stonith und Quorum deaktivieren

Ein Cluster-Quorum und Stonith machen in der Regel erst ab 3 Hosts Sinn. Für unser 2-Server Setup sind sie nicht hilfreich. Daher deaktivieren wir sie:

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

 

Schritt 6: Virtuelle Service IP einrichten

Mit dem folgenden Befehl wird die Service-IP-Adresse für das Cluster angelegt. Die Ressource heißt hier “samba-ip” und hat die Adresse 10.51.137.247 (mit der Netzmaske 255.255.254.0)

1
pcs resource create samba-ip ocf:heartbeat:IPaddr2 ip=10.51.137.247 cidr_netmask=23 op monitor interval=5s

Schritt 7: Testen und Reboot

Mit “pcs status” können Sie jederzeit auf beiden Hosts ermitteln, wo die Service-IP-Adresse gerade läuft:

pcs status

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[root@gestest01 ~]# pcs status
Cluster name: cluster
Stack: corosync
Current DC: gstest02 (version 1.1.18-11.el7_5.3-2b07d5c5a9) - partition with quorum
Last updated: Tue Jul 10 16:49:05 2018
Last change: Tue Jul 10 12:56:42 2018 by root via crm_resource on gstest01
2 nodes configured
1 resource configured
Online: [gstest01 gstest02]

Full list of resources:
samba-ip    (ocf::heartbeat:IPaddr2):       Started - gstest02

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

Um die Funktion der Cluster-IP-Adresse zu testen, rebooten wir nun den Server, auf dem die aktuelle Cluster-IP sich gerade befindet. Wenn alles richtig konfiguriert wurde, so wird beim Shutdown des aktiven Servers die Service/Cluster-IP automatisch von Pacemaker und Corosync auf den zweiten Host übertragen. Testen können Sie das mit einem „ping“ von einem Windows-Host auf die Cluster-IP:

1
ping –t 10.51.137.247

Installation von Samba

Zu guter Letzt installieren wir noch auf beiden Servern Samba als Dienst.

1
yum  -y install samba samba-client samba-common

Die  Datei /etc/samba/smb.conf passen Sie nun noch an Ihre Bedürfnisse an.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
[global]
workgroup = WORKGROUP
security = user
guest account = nobody
map to guest = bad user
passdb backend = tdbsam
#load printers = yes
cups options = raw

[datastore]
path = /datastore
guest ok = yes
guest only = yes
guest account = nobody
browseable = yes

Wie man für Samba die Datei /etc/samba/smb.conf so anpasst, daß sie mit personalisierten Benutzern zugreifen können, beschreiben wir in einem weiteren Tutorial hier im Blog.

 

Samba Dienste aktivieren und starten

Die beiden nachfolgenden Befehle aktivieren die für Samba notwendigen Dienste smb und nmb:

1
2
systemctl enable smb.service
systemctl enable nmb.service

Abschließend starten Sie die beiden Linux-Dienste:

1
2
systemctl restart smb.service
systemctl restart nmb.service

 

Firewalld für Samba anpassen

Sofern Sie unter Centos7 den firewalld-Dienst aktiviert haben, so sollten Sie die Zugriffe per SMB-Protkoll erlauben. Das erledigt der folgende Befehl:

1
2
firewall-cmd --permanent --zone=public --add-service=samba
firewall-cmd --reload

 

Nun sollte von erlaubten Clients aus bzw. mit dem passenden Passwort der der Zugriff auf \\<hostname>\datastore möglich sein. Wer einen anderen Share-Namen möchte, ändert das entsprechend in der smb.conf.

Damit wir nun noch einen „schönen“ Namen für unsere Service-IP im Share-Namen nutzen können, erstellen wir einen entsprechenden Host-Eintrag im DNS – bspw. „fileserver“ für die Cluster-IP 10.51.137.247 aus unserem Beispiel von oben.

Damit können nun Anwender über den Freigabe-Namen \\fileserver\datastore auf ihre Dateien von nun an mit 99,99% Verfügbarkeit zugreifen.

 

 

 

Weiterführende Links zum Thema

 

Fazit zum hochverfügbaren, ausfallsicheren Samba-Server

Wer die Kosten für die doppelten Ressourcen nicht scheut, kann mit den kostenfreien OpenSource-Produkten Pacemaker, Gluster-FS, LVM und Samba und einer Stunde Arbeit die Verfügbarkeit seiner IT-Services erheblich steigern.

Auch wenn das hier gezeigte Beispiel im echten Leben von Anwendern und IT-Verantwortlichen nicht so kritisch gesehen wird, so bleibt doch immerhin in der obigen Konstellation die Möglichkeit etwa Updates und Wartungsarbeiten während der normalen Arbeits- und Nutzungszeit durch den IT-Administrator durchführen zu lassen – anstatt dafür immer wieder Nachtschichten einlegen zu müssen.

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.

Einleitung: Hochverfügbarkeit mit Pacemaker und Corosync

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

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

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

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

Versuchsaufbau für Corosync und HA

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

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

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

Unser Setup für das Pacemaker Tutorial:

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

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

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

Installation von Corosync bzw. Pacemaker

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

1
yum -y install pacemaker pcs

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

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

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

1
passwd hacluster

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

Cluster Dienst einrichten

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

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

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

Cluster – alte Pacemaker Konfiguration löschen

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

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

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

Neues Pacemaker Cluster erstellen.

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

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

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

Konfiguration von Corosync prüfen:

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

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

Corosync Cluster starten

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

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

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

Corosync und Pacemaker aktivieren und starten

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

Auf testdb01 und testdb02 führen wir also aus

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

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

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

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

Corosync anpassen (2 Host Szenario)

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

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

Virtuelle Resource / Virtuelle IP anlegen

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

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

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

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

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

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

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

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

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

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

 

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

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

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

 

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

 

 

Verwaltung von Corosync / Pacemaker

Cluster-Resourcen manuell verschieben.

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

pcs resource move <resource-name> <nodename>

Beispiel:

1
pcs resource move testdb-ip testdb02

Cluster-Resource entfernen

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

Syntax: pcs resource delete <Resource-Name>

Bsp.:

1
pcs resource delete testdb-ip

 

Fehler / Troubleshooting von Corosync / Pacemaker /pcsd

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

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

Alle relevanten Dienste stoppen:

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

Alle relevanten Dienste starten:

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

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

Die harte Tour: Konfig neu anlegen.

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

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

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

Vorgehen:

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

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

Weiterführende Infos