A journey with Vault – Teil 1

A journey with Vault – Teil 1

This entry is part of 1 in the series a journey with vault

Hello fellow blog readers!

Heute möchte ich euch auf die Reise mit Vault by Hashicorp mitnehmen.

Zunächst was ist Vault? Bei Vault handelt es sich stumpf gesagt, um einen Passwortspeicher. Vermutlich kommen da jetzt bei dem einen oder anderen Projekte wie Keypass oder Enpass in den Sinn. Die Richtung ist schon mal gut. Jedoch kennt auch jeder das Hauptproblem der oben genannten Lösungen nur zu gut.

Teamfähigkeit.

Das eine Projekt beherrscht es, andere nur teilweise oder vieleicht sogar garnicht. Frustrierend könnte man die Situation auch gerne umschreiben. Fakt ist auf jeden Fall das es sich bei Vault um eine Lösung handelt, die wirklich das Zeug dazu hat ein Teamfähiger Passwortspeicher zu sein. Wie so alles in der Welt haben Dinge leider ihren Preis. Man wird mit Teamfähigkeit gesegnet, aber Satan bestraft uns indirekt mit der Komplexität des ganzen Konstrukts, weswegen ich das Abenteuer Vault in eine kleine Serie verpacke. Genug Worte für den Einstieg, legen wir los mit dem neuen Abenteuer in der Hautprolle: Vault.

Part Uno widment sich der grundlegenden Inbetriebnahme von Vault.

Wie immer benutzte ich eine mit Vagrant provisionierte höchst aktuelle CentOS 7 Box der Marke Eigenbau mit VirtualBox als Provider.

Die Reise beginnt mit dem Download eines ZIP-Archivs welche das Vault binary enthält. Den legen wir einfach unter /tmp ab und entpacken ihn direkt nach /usr/local/bin

wget https://releases.hashicorp.com/vault/1.3.0/vault_1.3.0_linux_amd64.zip -P /tmp
unzip /tmp/vault_1.3.0_linux_amd64.zip -d /usr/local/bin
chown root. /usr/local/bin/vault

Damit das aufrufen von Vault direkt gelingt müssen wir unsere PATH Variable noch um /usr/local/bin ergänzen. Ich hab das ganze in meinem ~/.bash_profile hinterlegt:

PATH=$PATH:$HOME/bin:/usr/local/bin

Wenn alles korrekt ausgeführt wurde, können wir jetzt die Autocompletion nachziehen und anschließend die Shell neustarten:

vault -autocomplete-install
complete -C /usr/local/bin/vault vault
exec $SHELL

Um das ganze abzurunden lassen wir Vault als Daemon laufen.

Zunächst müssen wir es Vault gestatten mlock syscalls ohne der Notwendigkeit von root ausführen zu dürfen:

setcap cap_ipc_lock=+ep /usr/local/bin/vault

Danach legen wir einen nicht priviligierten Systembenutzer an, unter dem der Vault Daemon später laufen soll:

useradd --system --home /etc/vault.d --shell /bin/false vault

Jetzt kommt die systemd Unit:

touch /etc/systemd/system/vault.service

… mit folgenden Inhalt:

[Unit]
Description="HashiCorp Vault - A tool for managing secrets"
Documentation=https://www.vaultproject.io/docs/
Requires=network-online.target
After=network-online.target
ConditionFileNotEmpty=/etc/vault.d/vault.hcl
StartLimitIntervalSec=60
StartLimitBurst=3

[Service]
User=vault
Group=vault
ProtectSystem=full
ProtectHome=read-only
PrivateTmp=yes
PrivateDevices=yes
SecureBits=keep-caps
AmbientCapabilities=CAP_IPC_LOCK
Capabilities=CAP_IPC_LOCK+ep
CapabilityBoundingSet=CAP_SYSLOG CAP_IPC_LOCK
NoNewPrivileges=yes
ExecStart=/usr/local/bin/vault server -config=/etc/vault.d/vault.hcl
ExecReload=/bin/kill --signal HUP $MAINPID
KillMode=process
KillSignal=SIGINT
Restart=on-failure
RestartSec=5
TimeoutStopSec=30
StartLimitInterval=60
StartLimitIntervalSec=60
StartLimitBurst=3
LimitNOFILE=65536
LimitMEMLOCK=infinity

[Install]
WantedBy=multi-user.target

Bevor wir den Daemon starten können, müssen wir ein paar Verzeichnisse sowie eine Konfigurationsdatei anlegen:
mkdir -pv /etc/vault.d/
mkdir -pv /usr/local/share/vault/data/
chown -R vault. /usr/local/share/vault/

touch /etc/vault.d/vault.hcl

Meine Konfigurationsdatei ist als Beispielhaft anzusehen. Sie behinhaltet das nötigste um den Vault Server grundsätzlich starten zu können. Diese sollte entsprechend an das eigene Szenario angepasst werden und unbedingt mit Zertifikaten ausgestattet sein!

storage "file" {
path = "/usr/local/share/vault/data"
}

ui = true

listener "tcp" {
address = "172.28.128.25:8200"
tls_disable = "true"
}

api_addr = "http://172.28.128.25:8200"
cluster_addr = "http://172.28.128.25:8201"

systemd neuladen und den Vault Daemon starten:

systemctl daemon-reload
systemctl start vault

Wenn uns alles geglückt ist, sollten wir unter der Adresse des Servers, mit Angabe des Ports 8200 nun die UI von Vault vorfinden. Damit geht es nun in der Bildstrecke weiter:

Das wars für den ersten Teil der Serie, im zweiten Teil werden wir uns den Aufbau von Vault genauer anschauen und uns der integration von SSH widment. Vault bietet nämlich viele Integrationsmöglichkeiten mit denen sich am Ende die Authentifizierung von sämtlichen Dienste Zentralisiert über Vault steuern lassen. Bis dahin wünsche ich wie immer viel Spass beim Basteln!

Photo from: https://devopscube.com/setup-hashicorp-vault-beginners-guide/

Max Deparade
Max Deparade
Consultant

Max ist seit Januar als Consultant bei NETWAYS und unterstützt tatkräftig unser Professional Services Team. Zuvor hat er seine Ausbildung zum Fachinformatiker für Systemintegration bei der Stadtverwaltung in Regensburg erfolgreich absolviert. Danach hat der gebürtige Schwabe, der einen Teil seiner Zeit auch in der Oberpfalz aufgewachsen ist ein halbes Jahr bei einem Managed Hosting Provider in Regensburg gearbeitet, ehe es ihn zu NETWAYS verschlagen hat. In seiner Freizeit genießt Max vor allem die Ruhe, wenn...

Text-Utils unter Linux – Wer kennt sie?

Bei aller Automatisierung, Systemmanagement oder Cloud und Log-Management  ist oben genannte Frage berechtigt.
Ich persönlich, stelle als Support-Engineer immer wieder fest, wie wichtig das eine oder andere Text-Util von Linux auf der Kommandozeile ist, deswegen möchte ich hier mal ein paar  Text-Utils und Anwendung vorstellen:

cat & split
Erklärung: Hier wird eine 100MB große Datei angelegt, die in 14MB große einzelne Dateien zerlegt wird und danach wieder zusammengefügt wird.
dd if=/dev/urandom of=test1.big count=100 bs=1M
split -b14m test1.big
cat x?? > test2.big
md5sum test.big test2.big

tac
Erklärung: Hier wird einen Liste der letzten installierten Pakete ausgeben und anschließend herumgedreht, damit das letzte installierte Paket unten in der Liste steht.
rpm -qa --last | tac

cut
Erklärung: Hier werden die ersten 25 Bytes aus Logfile messages vom Seiten-Anfang herausgeschnitten, setzt man das Minus vor die Zahl wird alles nach den 25 Byte herausgeschnitten
cut -b25- /var/log/messages | sort

cut & paste
Erklärung: Ausschneiden von Textausschnitte aus einer Datei, in einzelne Dateien kopiert und dann wieder zusammen in eine Datei zusammengeführt.
cut -d: -f1-3 /etc/passwd > spalte1-3
cut -d: -f4- /etc/passwd > spalte4-7

Wieder  zusammensetzen
paste -d: spalte1-3 spalte4-7

sort mit du
Erklärung: Hier wird mit du (disk usage) die Größe der Verzeichnisse ausgegeben und sortiert
du -mx / | sort -n
Hier ist der Beitrag Disk Usage (du) von mir, wenn jemand das Tool noch nicht kennen sollte.
Noch ein Beispiel:
sort -t : -k 3n /etc/passwd
Erklärung: Hier werden die User in der passwd nach der id sortiert aufsteigend sortiert, Trenner ist der Doppelpunkt.

column
Erklärung: Hier werden die IP-Routen schön in Spalten angezeigt um die Lesbarkeit zu verbessern.
ip r s | column -t

pr
Erklärung: Hier wird die Ausgabe des Textes zur besseren Lesbarkeit oder zum Ausdrucken aufbereitet und mit Seitenzahl angezeigt
wget -q -O - www.gnu.org/licenses/gpl-3.0.txt | pr | less

Alle Text-Utils können noch mehr, dazu bitte die Man-Pages zu Gemüte ziehen, oder vielleicht unsere Linux-Schulung im Bereich Trainings buchen.

In diesem Sinne Viel Spaß beim ausprobieren!

Johannes Carraro
Johannes Carraro
Support Engineer

Bevor Johannes bei NETWAYS anheuerte war er knapp drei Jahre als Systemadministrator in Ansbach tätig. Seit Februar 2016 verstärkt er nun unser Managed Services Team als Systems Engineer. In seiner Freizeit spielt Johannes E-Gitarre in einer Metalband, bastelt an Linux Systemen zuhause herum und ertüchtigt sich beim Tischtennisspielen im Verein, bzw. Mountainbiken, Inlinern und nicht zuletzt Skifahren.

SSH – Der Schlüssel zum Erfolg

Seal of ApprovalOder wie man das meiste aus SSH herauskitzelt.

SSH wird von den meisten Sysadmins genutzt, aber selten so wie es genutzt werden sollte.
Die meisten Administratoren verwenden das folgende Kommando Tag ein Tag aus.

ssh-keygen -t rsa -b 4096 -C "dummy_user@fqdn_dummy.com"

Zerlegen wir das Kommando mal in seine Einzelteile und versuchen zu verstehen was diese eigentlich tun.

Der Parameter '-t' gibt an welchen Key-Typ wir rsa/dsa/ecdsa/ecdsa-sk/ed25519 erstellen wollen. Hierbei wird von kleineren RSA-Keys unter 4096 Bits inzwischen abgeraten. DSA ist als unsicher deklariert und sollte auch seit Version 7 von OpenSSH auch nicht verwendet werden. ECDSA ist wegen der NSA ggf. problematisch zum nachlesen hier. So bleibt nur ED25519 welchen ich bei meiner täglichen Arbeit kaum sehe. Dies sollte aber heutzutage der De-Facto-Standard-Key sein, mit dem das obige Kommando aufgerufen wird.

'-b' für die Bits welche verwendet werden sollen. Wenn nun an dieser Stelle die Frage aufkommt mit welcher Bits-Anzahl ED25519 erstellt werden sollte, sei gesagt dass dieser eine festgelegte Länge hat und damit diesen Parameter ignoriert.

'-C' steht für Comment und dieser kann beliebig sein. Zumeist wird hier aber zur besseren Nachvollziehbarkeit von den Admins dieser Welt das Pattern Username@Hostname verwendet, damit man sehen kann für wen dieser Key erstellt wurde.

Im obigen Beispiel fehlt der Parameter '-N' welcher für new_passphrase bzw. das Passwort steht, wenn man den fehlenden Parameter '-N' mit "" ohne Zeichenkette angibt erhält man einen passwortlosen, privaten SSH-Schlüssel. Zusätzlich wird ein öffentlicher Schlüssel erstellt.

Verbessern wir das obige Kommando: ssh-keygen -t ed25519 -N'' -C 'dummy_user@fqdn_dummy.com'

Der Output des Beispiels:

ssh-keygen -t ed25519 -N'' -C'dummy_user@fqdn_dummy.com'
Generating public/private ed25519 key pair.
Enter file in which to save the key (/root/.ssh/id_ed25519): /root/.ssh/dummy
Created directory '/root/.ssh'.
Your identification has been saved in /root/.ssh/dummy.
Your public key has been saved in /root/.ssh/dummy.pub.
The key fingerprint is:
SHA256:14RQXbFyQCtEZfnGN8O7hV4h9hAEY0SYQN9Y0+9TRp8
root@fqdn_dummy.com The key's randomart image is:
+--[ED25519 256]--+
|      .oooO%O+o. |
|        .==o== ..|
|         oo.+o*.o|
|           + *+E=|
|        S . o.=+*|
|         .    .=o|
|             . .+|
|              .. |
|                 |
+----[SHA256]-----+
[root@fqdn_dummy.com .ssh]# ll
total 8
-rw-------. 1 root root 464 Nov 14 22:45 dummy
-rw-r--r--. 1 root root 108 Nov 14 22:45 dummy.pub

Damit hätten wir einen Standard-SSH-Schlüsselpaar, welches zumeist in den Unternehmen vergessen wird, wenn Mitarbeiter das Unternehmen verlassen oder die Abteilungen wechseln und auch durch automatisierte Deployments wird es oft als Karteileiche liegen gelassen.

Wie wäre es wenn wir ablaufende SSH-Schlüsselpaare hätten, welche nach einer gewissen Zeit ablaufen und zwar von selbst?

Was vielen nicht bewusst ist, ist dass dies SSH eigentlich schon von ganz allein kann, nur nutzt es kaum jemand.

Beginnen wir mit dem ersten Schritt und generieren uns eine CA (Certificate Authority).

ssh-keygen -t ed25519 -N '' -C 'ca' -f ca

Da diese CA unser Dreh- und Angelpunkt ist bedarf es Achtsamkeit, damit diese nie in falsche Hände gelangt.

Dank dieser CA können wir nun Zertifikate von Hosts und Benutzern signieren.

Als Beispiel nehmen wir einen Benutzer 'test' welcher sich per SSH an den Host namens ColdMoon anmelden soll.

Wir brauchen also für beide Zertifikate und einen SSH Schlüssel.

Bevor wir es vergessen müssen wir unsere vorher erstellte CA auf unserem SSH Server in der sshd_config als 'TrustedUserCAKeys /etc/ssh/ca.pub' eintragen.

Nun nehmen wir von unserem Benutzer 'test' auf seinem Laptop und den dort bereits erstellten öffentlichen Schlüssel mit dem wir ihm begrenzten Zugriff auf unsere Infrastruktur geben wollen in diesem Fall unser Rechner ColdMoon.

Im Vorfeld haben wir schon den Benutzer auf dem Rechner angelegt, und der Kollege 'test' hat uns seinen öffentlichen Schlüssel per Email geschickt.
Von unserem Vorgesetzten wissen wir das der Kollege 'test' nur 1 Woche ein Praktikum bei uns vornimmt und danach das Unternehmen wieder verlässt.

Auf gehts wir erstellen einen zeitlich begrenzten Zugang:

ssh-keygen -s ca -I Azubi_auf_Zeit -n test -V +1w -z 1 test.pub
Signed user key test-cert.pub: id "Azubi_auf_Zeit" serial 1 for test valid from 2019-11-13T09:00:00 to 2019-11-20T09:00:00

Das Resultat dieses Kommandos ist das wir ein signiertes 'test-cert.pub' erhalten mit eine Lebenszeit von 1 Woche.
Dieses senden wir umgehend unseren Praktikanten zu mit dem Hinweis das er sich mit dem folgenden Kommando nun an dem Rechner ColdMoon anmelden kann.

ssh -i ~/.ssh/test -i ~/.ssh/test-cert.pub test@ColdMoon -v

Ich habe mal den Verbose-Schalter genommen um zu zeigen wie das Zertifikat sich dann gegen ColdMoon anmeldet.

...
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Next authentication method: publickey
debug1: Offering public key: test ED25519 SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password
debug1: Offering public key: test ED25519-CERT SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Server accepts key: test ED25519-CERT SHA256:4A3ab2/7dq0klERi9IevmSnTZd7dkOuuP8yrWCZ24gI explicit
debug1: Authentication succeeded (publickey).
Authenticated to 192.168.242.67 ([192.168.242.67]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Requesting authentication agent forwarding.
debug1: Sending environment.
debug1: Sending env LC_CTYPE = UTF-8
Last login: Thu Nov 14 11:00:14 2019 from 192.168.242.225
[test@coldmoon ~]$

Die Authentifizierung wird nun die gesamte Woche lang funktionieren in der der Praktikant Zugriff auf dem Rechner braucht, danach weil es nur zeitlich begrenzt ist nicht mehr. Damit ist für den Praktikanten kein Zugriff auf unserer Infrastruktur mehr möglich. Dies funktioniert auch mit anderen Hosts oder Services, welchen man nur für einen Zeitraum einen begrenzten Zugriff per SSH geben möchte.

Der Parameter '-V' gibt den Validity_Interval an, also den Zeitraum der Gültigkeit, und der Parameter '-z' eine Serialnumber, welche von uns frei gewählt werden kann.

Dies kann mit den üblichen Systemmitteln automatisiert werden oder per Ansible/Puppet auch auf Systeme verteilt werden.
Schöner ist es noch wenn es ohne viel manuelle Arbeit geht. Dies zeige ich in meinem nächsten Blogpost welcher Vault aus dem Hause Hashicorp zeigt.

Gruss

David

David Okon
David Okon
Support Engineer

Weltenbummler David hat aus Berlin fast den direkten Weg zu uns nach Nürnberg genommen. Bevor er hier anheuerte, gab es einen kleinen Schlenker nach Irland, England, Frankreich und in die Niederlande. Alles nur, damit er sein Know How als IHK Geprüfter DOSenöffner so sehr vertiefen konnte, dass er vom Apple Consultant den Sprung in unser Professional Services-Team wagen konnte. Er ist stolzer Papa eines Sohnemanns und bei uns mit der Mission unterwegs, unsere Kunden zu...
Windows Passwort mit Linux zurücksetzen

Windows Passwort mit Linux zurücksetzen

Falls ihr mal euer Windows Passwort vergessen habt, ein Freund euch fragt, Zugriff auf eine Dubiose Festplatte zu erhalten aber das System mit einem User und einem Passwort geschützt ist, dann wird euch das Tool chntpw sicherlich nützlich sein. Mit diesem Tool ist es möglich, über eine Live-Distribution von Linux (Lubuntu, Sabayon Linux, Peppermint OS, Fuduntu, Linux Mint usw.) Informationen der Benutzer zu bearbeiten, löschen oder zurückzusetzen. Ich werde für den Vorgang ein Live-Ubuntu verwenden um euch zu zeigen, wie einfach das ist.

Bootet Ubuntu vom USB-Stick und wählt “Try Ubuntu” aus. Im Desktop angekommen, müssen wir noch eine Einstellung aktivieren um Aktualisierungen der Anwendungen zu erhalten.


Wir setzen einen Haken bei “Von der Ubuntu-Gemeinschaft betreute freie und quelloffenne Programme (universe)”, schließen das Fenster und wählen Neu laden.
Nun gehen wir ins Terminal und aktualisieren.

Loggt euch gleich als root user ein um gewissen Berechtigungen aus dem Weg zu gehen. Mit chntpw ist es nicht möglich, bestehende Passwörter auszulesen.

$ sudo apt update && apt upgrade

Nun installieren wir das Tool chntpw:

$ sudo apt install chntpw

Jetzt suchen wir noch unsere Windows-Partition die wir mounten möchten (Partition auf der unsere Benutzer verwaltet werden).

$ sfdisk -l

Wir können daraus schließen, dass unsere Windows Festplatte als /dev/sda angegeben wird und die Partition die wir suchen /dev/sda2 ist. Um die Partition zu mounten, erstellen wir dazu noch ein Verzeichnis namens /Microsoft. Dann mounten wir unsere Festplatte, und wechseln in das eben erstellte Verzeichnis. Hier können wir die Ordnerstruktur einer Windows-Installation erkennen.

Falls die Partition nicht gemountet werden kann, weil unser Windows den Status “hibernate” besitzt, müssen wir erst in den abgesicherten Modus und von dort aus sauber herunterfahren.

Jetzt wechseln wir in das Verzeichnis Windows//System32/config/ und sehen uns die Einträge der Security Account Manager (SAM) Datenbank an. Uns werden alle Benutzer und deren Gruppe angezeigt in der sie sich befinden, ob ein Passwort gesetzt ist und das Konto eventuell gesperrt wurde.

$ sudo chntpw -l SAM

Nun kommt das Tool chntpw zum Einsatz, indem wir das Kommando $ sudo chntpw -i SAM ausführen. Wir landen im Main Interactive Menu, wo wir nun auswählen was genau wir anstellen möchten.
Edit user data and passwords (1) ist der Reiter den wir brauchen werden um die Benutzerdaten zu ändern.

Wir werden aufgefordert eine RID (Relative ID) einzugeben. Ich habe schon etwas vorbereitet und einen chntpw-Benutzer erstellt, dessen Passwort niemals verfällt und der Gruppe Administratoren angehört.
In meinem Falle ist die RID 3ea.

Uns wird angezeigt, wie viele fehlerhafte Logins wir hatten, wie oft wir uns bereits mit unserem Konto angemeldet haben und unsere Benutzereigentschaften. Das User Edit Menu ploppt weiter unten auf und wir können zwischen 5 Optionen wählen, was wir denn gerne mit unseren credentials anstellen möchten. Ich werde mein vorhandenes Passwort löschen und den Status blank wählen. (Option Nr. 1). Danach landen wir wieder in der Übersicht unserer Benutzerkonten.

Wie man schwer erkennen kann, ist in dem Reiter Lock nun *BLANK* gesetzt und es exisitiert für dieses Konto kein Passwort mehr. Wir verlassen das User Edit Menu mit der Eingabe von “q” und kehren zum Main Interactive Menu zurück, bei dem wir noch einmal “q” eingeben und gefragt werden, ob wir speichern möchten. Selbstverständlich bestätigen wir und speichern unsere Änderungen mit “y”.

Geschafft!
Bei der nächsten Anmeldung mit dem bearbeiteten Konto, werden wir nicht mehr nach einem Passwort gefragt. Wir können nun ein neues Passwort setzen.

 

Aleksander Arsenovic
Aleksander Arsenovic
Junior Consultant

Aleksander macht eine Ausbildung zum Fachinformatiker für Systemintegration in unserem Professional Service. Wenn er nicht bei NETWAYS ist, schraubt er an seinem Desktop-PC rum und übertaktet seine Hardware. Er ist immer für eine gute Konversation zu haben.

Einmal lokaler Mirror? Kommt sofort!

RPM Logo

Wer mich kennt, weiß dass ich gerne zu großen umfangreichen Lösungen neige. Daher ist meine bevorzugte Lösung für einen lokalen Mirror Katello, aber es gibt auch Situationen in denen man nur eine Version ohne Staging braucht. Beispiel aus dieser Woche ein “Icinga 2”-Satellite in China, der einfach nicht die Pakete von packages.icinga.com beziehen möchte. Auf seinem übergeordneten Satelliten in Singapur hat noch alles gut funktioniert und auch die Kommunikation zwischen beiden funktioniert auch gut. Also ist nach kurzer Überlegung der Plan gefasst, es soll ein lokaler Mirror her von dem in China installiert werden soll.

Um den Mirror aufzusetzen, setze ich auf die Kommandos reposync und createrepo, welche recht schnell installiert sind und keine Konfiguration benötigen.

yum install -y yum-utils createrepo

Mit reposync kann nur ein bereits konfiguriertes Repository gespiegelt werden. Da in diesem Fall auf beiden Systemen die gleiche Betriebssystemversion installiert ist, für mich kein Problem und es kann gleich weitergehen. Auch ist auf dem Satelliten bereits ein Webserver installiert um Icinga Web 2 als separates Webinterface für die asiatischen Kollegen anzubieten, also auch hier kein Handlungsbedarf. Der Mirror ist also schnell aufgesetzt.

mkdir -p /var/www/html/repo
reposync -r icinga-stable-release -p /var/www/html/repo/ -n
createrepo /var/www/html/repo/icinga-stable-release

Die Optionen bei reposync sind mit -r die Repository-ID aus der Yum-Konfiguration, -p das Zielverzeichnis und -n um nur die jeweils neuste Version herunterzuladen. reposync lädt allerdings nur die Pakete herunter und legt sie in der entsprechenden Struktur ab ohne die benötigten Metadaten. Diese werden dann mit createrepo erzeugt und schon kann mit der neu zur Verfügung gestellten URL das Repository eingebunden werden.

In vielen Fällen ist dies ausreichend, aber hier noch ein paar Tipps wenn es dann doch etwas mehr sein darf.

  • Zum regelmäßigen Updaten einfach die beiden Kommandos reposync und createrepo in einem Cronjob hinterlegen.
  • Ein Repository kann noch weitere Metadaten enthalten, beispielsweise die comps.xml mit Gruppeninformationen. Diese wird durch der Option --downloadcomps von reposync mit heruntergeladen und im aktuellen Arbeitsverzeichnis abgelegt. Bei createrepo wird diese wiederum mit -g comps.xml eingebunden.
  • Die Errata-Informationen können nicht mit reposync heruntergeladen werden, aber beispielsweise yum list-sec lädt diese lokal in den Cache. Kopiert man die updateinfo.xml dann aus dem Repository-Cache in /var/cache/yum/ in das synchronisierte Repository und führt modifyrepo /var/www/html/repo-id/repodata/updateinfo.xml /var/www/html/repo-id/repodata aus, wird diese Teil der Metadaten.
  • Sollen Repositories für ein anderes Betriebssystem zur Verfügung gestellt werden, kann eine Konfiguration erstellt werden, die aber nicht aktiv ist, also enabled=0 enthält. Bei reposync kann dann mit --enablerepo repo-id das Repository nur für die Synchronisation aktiviert werden.

Ich hoffe dieser kleine Artikel hilft dem ein oder anderen. Wem das schnelle einfache Repository nicht genug ist, der kann auch versuchen mit rsync einen vollständigen Mirror aufzusetzen oder mit Katello sogar ein Staging einbauen, damit Updates erst in Entwicklung und Test laden bevor sie in Produktion vielleicht Probleme verursachen. Bei letzterem unterstützen gerne ich oder ein Kollege im Rahmen eines Foreman-Consultings.

Dirk Götz
Dirk Götz
Principal Consultant

Dirk ist Red Hat Spezialist und arbeitet bei NETWAYS im Bereich Consulting für Icinga, Puppet, Ansible, Foreman und andere Systems-Management-Lösungen. Früher war er bei einem Träger der gesetzlichen Rentenversicherung als Senior Administrator beschäftigt und auch für die Ausbildung der Azubis verantwortlich wie nun bei NETWAYS.

Hot Backups mittels Xtrabackup

Wie Markus in seinem letzten Blogpost schon beschrieben hat, hatte er die zweifelhafte Ehre ein Backup einer verhältnismäßig großen MySQL-Datenbank (MariaDB) zu machen. Das große Problem bei ihm war allerdings, dass das Kopieren auf Dateiebene eine Downtime der Datenbank voraussetzte und somit der laufende Betrieb eingestellt werden musste. Man legt sozusagen die Datenbank auf Eis und deshalb nennt man dieses Verfahren auch Cold Backup (Offline Backup). Dies war zumindest meine Schlussfolgerung zur Namensgebung…

Als wissensdurstiger Azubi bei NETWAYS wollte ich wissen ob es vielleicht eine Möglichkeit gibt, ein Backup einer MySQL-Datenbank während  des laufenden Betriebes zu machen. Bei meinen Recherchen bin ich letztlich auf ein heiß diskutiertes Thema gestoßen. Wie der Name schon sagt, auf das “heiße”, sogenannte Hot Backup (Online Backup). Bei diesem Backupverfahren ist es möglich während des laufenden Betriebes einer MySQL-Datenbank ein Backup zu erstellen und somit eine Downtime der Datenbank zu vermeiden. Das Online Backup kann somit mehrmals am Tag durchgeführt werden, des Weiteren ist es deutlich schneller als das Offline Backup. Allerdings birgt ein Hot Backup auch ein gewisses Risiko, da im Gegensatz zum Cold Backup, weiter Daten in die Datenbank geschrieben werden und diese somit nicht im Backup enthalten wären. Das wäre aber im Ernstfall (Ausfall der Datenbank) zu verschmerzen, da somit beispielsweise womöglich nur Daten der letzten paar Stunden und nicht von einem ganzen Arbeitstag verloren wären.

Im Folgenden zeige ich anhand eines kleinen Beispiels, wie so ein Hot Backup vonstatten geht. Das Tool meiner Wahl ist Xtrabackup von Percona. Xtrabackup kann ein Hot Backup erstellen indem es sich die sog. crash-recovery Funktion von InnoDB-Datenbanken zu Nutze macht. Die Installation von Xtrabackup ist in der Dokumentation hervorragend beschrieben.

Zunächst benötigt man einen Datenbankuser mit folgenden Rechten:
mysql> CREATE USER 'backupuser'@'localhost' IDENTIFIED BY 'SuperGeheim!';
mysql> GRANT BACKUP_ADMIN, PROCESS, RELOAD, LOCK TABLES, REPLICATION CLIENT ON *.* TO 'backupuser'@'localhost';
mysql> GRANT SELECT ON performance_schema.log_status TO 'backupuser'@'localhost';

Der nächste Schritt ist ein Backup anzustoßen:
$ xtrabackup --backup --user=backupuser --password=SuperGeheim! --target-dir=/var/test_backup
“–target-dir”: In diesem frei zu wählenden Ordner werden die Backups gespeichert.

Man kann bei der Ausgabe sehr gut erkennen, dass Xtrabackup sich die sog. LSN (Log Sequence Number) “merkt” und ab diesem Zeitpunkt die Tabellen der Datenbank sperrt sowie alle weiteren Schreiboperationen “puffert”. Nach dem Kopieren der Daten werden die Tabellen wieder frei gegeben und der Betrieb ab der “gemerkten” LSN wieder aufgenommen:
190829 10:27:43 >> log scanned up to (146090017)
xtrabackup: Generating a list of tablespaces
190829 10:27:43 [01] Copying ./ibdata1 to /var/test_backup/ibdata1
190829 10:27:44 [01] ...done
190829 10:27:44 >> log scanned up to (146090017)
190829 10:27:44 Executing FLUSH NO_WRITE_TO_BINLOG TABLES...
190829 10:27:44 Executing FLUSH TABLES WITH READ LOCK...
190829 10:27:44 Starting to backup non-InnoDB tables and files
[...]
[...]
190829 10:27:46 Finished backing up non-InnoDB tables and files
190829 10:27:46 Executing FLUSH NO_WRITE_TO_BINLOG ENGINE LOGS...
xtrabackup: The latest check point (for incremental): '146090233'
xtrabackup: Stopping log copying thread.
.190829 10:27:46 >> log scanned up to (146090233)
190829 10:27:46 Executing UNLOCK TABLES
190829 10:27:46 All tables unlocked
190829 10:27:46 Backup created in directory '/var/test_backup'
190829 10:27:46 [00] Writing /var/test_backup/backup-my.cnf
190829 10:27:46 [00] ...done
190829 10:27:46 [00] Writing /var/test_backup/xtrabackup_info
190829 10:27:46 [00] ...done
xtrabackup: Transaction log of lsn (146086198) to (146090233) was copied.
190829 10:27:46 completed OK

Wenn das Backup erfolgreich war und man dieses wieder einspielen will, muss man dieses zuvor “vorbereiten”. Da die kopierten Daten womöglich nicht mit den aktuellen Daten übereinstimmen:
$ xtrabackup --prepare --target-dir=/var/test_backup

Hat man ein InnoDB: Shutdown completed; log sequence number 146093758
190829 10:45:05 completed OK!
erhalten, lässt sich das Backup wiederherstellen

ACHTUNG: Es müssen beim Wiederherstellen alle Daten aus /var/lib/mysql/ gelöscht werden. Hierbei sollte man sehr aufpassen, ansonsten kann es zum kompletten Datenverlust führen!!!

Um das “vorbereitete” Backup einzuspielen, muss der MySQL (MariaDB) Dienst gestoppt sein (was bei einem Ausfall sowieso der Fall sein dürfte). Der nächste Schritt wäre den Benutzer der Daten anzupassen und den Dienst erneut zu starten:
$ systemctl stop mariadb.service
$ rm -rf /var/lib/mysql/*
$ xtrabackup --move-back --target-dir=/var/test_backup
$ chown -R mysql:mysql /var/lib/mysql/
$ systemctl start mariadb.service

Als Fazit kann man sagen, dass sich Hot Backups sehr lohnen, aber auch ein gewisses Risiko beherbergen können. Cold Backups sind dazu im Gegensatz sehr “starr” und können nur während einer Downtime durchgeführt werden. Sie bieten jedoch die höhere Chance auf Datenkonsistenz und sind deutlich einfacher zu handhaben. Empfehlenswert ist es auf jeden Fall sich eine geeignete Datensicherungsstrategie aus beiden Varianten zu überlegen, bei der man zum Beispiel am Ende des Tages ein Cold Backup und während der Geschäftszeiten mehrere Hot Backups macht.

Philipp Dorschner
Philipp Dorschner
Junior Consultant

Philipp hat im September 2017 seine Ausbildung zum Fachinformatiker gestartet. Er hat sogar schon eine Ausbildung im Gepäck und zwar zum technischen Assistenten für Informatik. Danach hat hat er sein Abi nachgeholt und anschließend begonnen Wirtschaftswissenschaften zu studieren. Da sein Herz während des Studiums ständig nach technischen Inhalten geschrien hat, wechselte er zu Verfahrenstechnik. Aber auch dieses Studium konnte Ihn nicht erfüllen, weshalb er sich für die Ausbildung bei NETWAYS entschieden hat, "back to the...