LDAP Backupskript

Betreibt man einen LDAP Server, so will man sicherlich das ein oder andere Mal eine Sicherung machen. Ich möchte das ganz oft und da die Daten in der Regel ziemlich klein sind, kann ich das dann auch.

Dazu habe ich mir ein Skript gebaut, welches die Arbeit für mich erledigt. Es wird immer der komplette LDAP-Baum in eine LDIF Datei gesichert, sodass ich im Zweifelsfall alles schnell wieder rekonstruieren kann.

#!/bin/bash
DATE=`date +%Y%m%d-%H%M%S`
DST=/PATH/TO/BACKUP/
DEBUG=1
LDIF=SLAPBACKUP-$DATE.ldif

if [ $DEBUG -eq 1 ]

then
echo /usr/sbin/slapcat -l $DST$LDIF
/usr/sbin/slapcat -l $DST$LDIF 2>/dev/null
else
/usr/sbin/slapcat -l $DST$LDIF 2>/dev/null
fi

find $DST -type f -mmin +60 -name "*.ldif" -exec bzip2 {} \;
find $DST -type f -mtime +14 -name "*.bz2" -exec rm -f {} \;

exit 0

Dieses Skript rufe ich dann mittels Crontab alle Stunde auf und sichere mir so kontinuierlich den Zustand des Verzeichnisses. Abgelegt wird immer eine neue Datei mit Zeitstempel. Ältere Dateien werden komprimiert und nach 60 Tagen gelöscht.

So mag ich das.

S/MIME Zertifikat für die Emailverschlüsselung

Da ja grade technisch so ziemlich alles den Bach runter geht (ein wenig dramatisch, aber nahe dran) will vielleicht der ein oder andere seine Emails verschlüsseln. Aktuell beschäftige ich mich ein wenig mit S/MIME ist finde es ziemlich einfach nachvollziehbar.

Es funktioniert ähnlich zu SSL im Browser. Man braucht ein Zertifikat. Dieses wiederum sollte maximal vertrauenswürdig und daher vielleicht sogar von einer öffentlichen Stelle ausgestellt werden.
Komodo bietet ein solches Zertifikat an:https://www.instantssl.com/ssl-certificate-products/free-email-certificate.html 

Geht alle da drauf, schafft euch ein Zertifikat an und nutzt es in jeder erdenklichen Form für die Emailverschlüsselung/Signierung!

Unter Mac ist noch ein kleiner Schritt notwendig, damit man das erstellte Zertifikat dann auch auf dem iPhone oder sonst wie nutzen kann. Man muss aus der Schlüsselverwaltung heraus einen Export im PKCS12 Format machen. Andernfalls fehlt der private Schlüssel - was ziemlich doof ist.

Diese Datei schickt man sich dann einfach an sein Handy und import es. Anschließend kann man schnell und einfach in den Einstellungen die gewünschten Optionen aktivieren um zum Beispiel jede ausgehende Email zu signieren.

Einfach oder?

 


‪#‎SMIME‬ ‪#‎Encryption‬ ‪#‎Verschlüsselung‬ ‪#‎IT‬ ‪#‎Security‬ ‪#‎Cert‬

Bonding Netzwerk mit CentOS - the easy Way

Eigentlich ist es recht einfach. Man möchte zwei oder mehr Netzwerkkarten zu einer logischen Verbindung vereinen um beispielsweise eine höhere Ausfallsicherheit zu haben. Traditionell hat sich dazu der Begriff "Bonding" eingebürgert. Um ein solches Bonding einzurichten reicht natürlich nicht ein einheitlicher Weg. Ich mag es bekanntlich einfach und beschreibe hier den Weg, welchen ich unter CentOS Linux gehe.

Zuerst einmal muss man sich vor Augen halten, dass es sich bei einem Bonding um eine Softwarelösung handelt. Dementsprechend ist der Kernel bei einem Linux-System damit beschäftigt den gewünschten Modus umzusetzen. Eine ganz nette Übersicht findet sich hier.

In meinem Fall habe ich mich für die Ausfallsicherheit entschieden. Konkret verbinde ich zwei Netzwerkkarten logisch zu einer. Und weil das nicht reicht, setze ich noch eine Bridge drauf, um virtuelle Maschinen/Container direkt ins Netzwerk hängen zu können.

Um ein Bonding zu haben, benötigt man lediglich die folgenden Schritte auf einem CentOS 7.x System:

 

1. Laden des notwendigen Bondingmodul: 

modprobe --first-time bonding

2. Anlegen einer neuen Bonding-Konfiguration unter /etc/sysconfig/network-scripts/ifcfg-bond0

DEVICE=bond0
NAME=bond0
TYPE=Bond
BONDING_MASTER=yes
IPADDR=192.168.1.150
PREFIX=24
ONBOOT=yes
BOOTPROTO=none
BONDING_OPTS="mode=1 miimon=100"

Wichtig hierbei ist, dass man sich ein wenig mit den unterschiedlichen Modi beschäftigt hat, welche einem das Bonding bietet:

Bonding Modus Bedeutung
0 Round-robin - es werden sequentiell die Datenpakete über die hinzugefügten Slaves verschickt. So erreicht man Ausfallsicherheit und Lastenverteilung.
1 Active-backup- Hierbei ist nur ein Netzwerksalve aktiv und alle anderen stehen auf Standby. Es wird auf Ausfallsicherheit gepocht.
2 XOR - Ausfallsicherheit und Lastenverteilung durch XOR Verknüpfung von Sende und Zieladresse (Macadressbasiert).
3 Broadcast - Fehlertoleranz durch einfaches versenden aller Daten auf allen angebundenen Netzwerkkarten.
4 IEEE 802.3ad dynamische Link Aggregation. Benötigt Unterstützung durch den Switch.
5 Adaptive Sende Lastenverteilung anhand der aktuellen Auslastung eines Salzes. Bei Ausfall übernimmt einer der Salmes die Mac-Adresse des anderen.
6 Adaptive Lastenverteilung anhand der aktuellen Auslastung eines Salzes. Bei Ausfall übernimmt einer der Salmes die Mac-Adresse des anderen.

3. Einbinden der zu nutzenden Netzwerkkarten mittels Konfigurationsdatei:

...
BOOTPROTO="none"
...
ONBOOT="yes"
MASTER=bond0
SLAVE=yes

Diese Zeilen müssen in der jeweiligen Datei unter /etc/sysconfig/network-scripts eingefügt bzw. ergänzt werden. Damit wird die Netzwerkkarte(n) bei einer erneuten Initialisierung dem Bonding zugeordnet.

4. Neustart der Netzwerkverbindung

systemctl restart network

5. Kontrolle der Verbindungen:

cat /proc/net/bonding/bond0

Dieser Schritt kann natürlich für eine beliebige Anzahl an Bonding-Verbindungen durchgeführt werden. Um nun Netzwerkadressen und Werte zu verändern braucht es nur noch das Bondinginginterface zu verändern. Nicht mehr die einzelnen Netzwerkkarten.

Was mich an dieser Lösung so glücklich macht ist die Autonomie und Einfachheit der zu Konfigurierenden Schritte. Ich kann mir Bonding-Templates definieren, welche ich dann einfach auf ein System deploye und anschließend Netzwerkkarten zuordne.

 

Seiten im Internet, die geholfen haben:

Smart Status per SNMP Monitoren

Wer Server betreibt möchte in der Regel seine Ruhe haben (ausgenommen Windows Administratoren, die haben immer was zu tun). Damit das so ist, gilt es an einen Punkt zu kommen, an dem ein "Status Quo" erreicht ist. Diesen Status gilt es dann zu halten.

Nun kann man zu Fortuna beten oder sich ein Monitoring einrichten. Dienste und Co lassen sich in der Regel ziemlich einfach beobachten und dementsprechend prüfen. Bei der Hardware sieht es zumeist anders aus. Wer nun denkt das man aufwendige Agenten installieren muss und sonst welche Bemühungen zu betreiben hat, damit man an die Daten kommt liegt einfach falsch. Natürlich kann man mit einem Agenten eine ganze Menge machen. Wenn man das aber nicht will oder gar die gewünschte Funktion nicht gegeben ist, dann braucht man die Möglichkeit den ohnehin vorhandenen SNMP-Server um die gewünschten Werte zu erweitern.

In meinem Fall wollte ich wissen wie es den eingebauten Festplatten geht. Zunächst reicht mir erst einmal der HEALTH-Status des S.M.A.R.T. Will man mehr ist das aber auch kein großes Problem.

Wenn man seinen RAID-Controller ordentlich installiert hat, so kann man sich beliebige Ausgaben zusammenbauen. Zunächst einmal muss aber herausgefunden werden, was da so geht.

Ich wollte erst einmal wissen welche Festplatten an dem Controller hängen.

smartctl --scan
/dev/sda -d scsi # /dev/sda, SCSI device
/dev/bus/0 -d megaraid,8 # /dev/bus/0 [megaraid_disk_08], SCSI device
/dev/bus/0 -d megaraid,9 # /dev/bus/0 [megaraid_disk_09], SCSI device
/dev/bus/0 -d megaraid,10 # /dev/bus/0 [megaraid_disk_10], SCSI device
/dev/bus/0 -d megaraid,11 # /dev/bus/0 [megaraid_disk_11], SCSI device
/dev/bus/0 -d megaraid,14 # /dev/bus/0 [megaraid_disk_14], SCSI device
/dev/bus/0 -d megaraid,15 # /dev/bus/0 [megaraid_disk_15], SCSI device

Mit diesen Informationen schaue ich nun, wie es der jeweiligen festplatte geht:

smartctl -H /dev/sda -d megaraid,8 | grep -i health
SMART overall-health self-assessment test result: PASSED

Damit kann ich nun schon beginnen mein Monitoring aufzubauen. Dazu gebe ich in die /etc/snmp/snmpd.conf folgende Inhalte hinzu:

exec smart-sda1a /bin/sh -c "/usr/sbin/smartctl -H /dev/sda -d megaraid,8 | grep -i health

Nun gehe ich weiter zu meinem Icinga und erstelle zunächst einen Checkcommand:

define command {
command_name snmpsmarthealth
command_line /usr/lib/nagios/plugins/check_snmp -H $HOSTADDRESS$ -C public -o $ARG1$ -r $ARG2$
}

 In der jeweiligen Host-Konfiguration erstelle ich nun einen Service, welcher mir abbildet, was ich zu prüfen gedenke

define service {
use snmp-service
host_name SERVERNAME
service_description HDD 1 Health
check_command snmpsmarthealth!iso.3.6.1.4.1.2021.8.1.101.2!PASSED!
}

 

snmpsmarthealth Aufruf meines Checkcommands
! Trennzeichen
iso.3.6.1.4.1.2021.8.1.101.2 Jeweiliges Unterverzeichnis des SNMP Baums
PASSED Zu suchender Begriff

Das Ganze wiederhole ich nun für sämtliche lokal ausgeführten Kommandos des zu überwachenden Servers.

wie komme ich denn nun zu den komischen SNMP-Tailbäumen mit den merkwürdigen Zahlen? Im Zweifelsfall starte ich dazu einen Suchlauf mittels snmpwalk

snmpwalk -c public -v 2c SERVERNAME | grep -i BEGRIFF DEN ICH ERWARTE

 

Nun kann ich alles Monitoren, was ich will oder benötige. Ohne Agenten, ohne viele Plugins. Das Leben ist so einfach!

Seiten die mir geholfen haben:

http://www.bitbull.ch/wiki/index.php/Simple_way_to_read_SMART_status_from_harddisk_via_SNMP

Mit Ansible die Landscahft aktualisieren

Das Ansible für mich der logische nächste schritt nach der Shell ist, sobald es um die Verwaltung von Servern geht, habe ich vielleicht hier und da schon mal durchblicken lassen. Der Hintergrund ist einfach:

  • Es sollte ein Anliegen sein wiederkehrende Arbeitsschritte systematisch gleich durchzuführen
  • Es sollte ein Anliegen sein die zu erledigenden Aufgaben transparent zu halten
  • Es sollte ein Anliegen sein seine Arbeiten reproduzierbar auf andere Systeme anwenden zu können
  • Es macht einfach Spaß, wenn man sich nicht mehr mit dem quatsch der unterschiedlichen Systeme befassen zu müssen.

Mit Ansible Playbooks habe ich als Systemverwalter die Möglichkeit meine Schritte in einfacher Art und Weise (fast schon stenografisch) nieder zuschreiben und so einen Ablauf zu skizzieren, welche Arbeiten/Schritte/Rahmenbedingungen auf dem von mir zu verwaltenden System durchgeführt/vorhanden sein sollen.

Ansible selbst kümmert sich dann um die Abstraktion zum System hin, auf dem ich dann letztendlich die Skizze ausführe.

Wenn ich nun eine gewachsene Landschaft mit unterschiedlichen Linux-Distributionen habe, kann Ansible mir helfen diese aktuell zu halten. Das einfache Playbook dazu sieht wie folgt aus:

---
- hosts: all:!switche:!windows
user: root
gather_facts: true

tasks:
- name: apt update
action: apt update_cache=yes
when: ansible_distribution == "Ubuntu" or ansible_distribution == "Debian"

- name: apt upgrade
action: apt upgrade=dist force=yes
when: ansible_distribution == "Ubuntu" or ansible_distribution == "Debian"

- name: yum upgrade
action: yum name=* state=latest
when: ansible_distribution == "CentOS"

- name: dnf upgrade
action: yum name=* state=latest
when: ansible_distribution == "Fedora"

Wenn ich dieses Playbook nun auf meine Landschaft loslasse:

ansible-playbook playbooks/linux-upgrade.yml

 spielt es keine Rolle mehr, ob die Eingesetzte Distribution ein Debian, Ubuntu, Fedora oder CentOS ist. Alle werden mit den eigenen Paketmanagern aktualisiert

Home ← Ältere Posts