Bulk Move Users in OpenLDAP (Skript)

Hat man ein LDAP Verzeichnis mit vielen Benutzern, dann ist einem angeraten direkt zu Beginn ein gutes, belastbares Design zu erstellen. Tut man das nämlich nicht, so hat man schnell einige hundert Benutzerkonten an falscher Stelle.

Wer dann nacharbeiten möchte, der such sich entweder gescheite Tools, oder macht es selbst. Dabei hat man eigentlich nicht viele Möglichkeiten. Im Grunde genommen geht es nur darum den DN eines Eintrages zu ändern, sodass dieser dann zum neuen Design passt.

Wenn man Beispielsweise 2000 Benutzer in einer OU hat, davon aber nur 789 zu einer bestimmten Gruppe gehörende verschieben will, so kann man das natürlich auch per Hand machen. Oder aber, man jongliert mit den vorhandnen Informationen und sichert sich gleich für die Zukunft ab, denn mit hoher Wahrscheinlichkeit wird so etwas in ähnlicher Form wieder vorkommen.

Zunächst einmal brauch man alle Benutzer einer Gruppe, und das möglichst durch Leerzeichen getrennt. Anschließend muss man sich eine LDIF zusammenschrauben die es einem ermöglicht ein Konto zu verschieben. In schnell und einfach sieht das dann so aus:

#!bin/bash
PASSWORD=STRENG_GEHEIMES_PASSWORD

for i in $(ldapsearch -x cn=G_R_U_P_P_E_N_N_A_M_E | grep memberUid | cut -f 2 -d " " | sort)
do
ldapsearch -x -s one -b ou=Users,dc=DOMAIN,dc=DE uid=$i | grep -i dn
if [ "$?" -eq "0" ]; then
echo "dn: uid=$i,ou=Users,dc=DOMAIN,dc=DE\nchangetype: moddn\nnewrdn: uid=$i\ndeleteoldrdn: 1\nnewsuperior: ou=extern,ou=Users,dc=DOMAIN,dc=DE" \
| ldapmodify -x -w $PASSWORD -D "cn=Manager,dc=DOMAIN,dc=DE" -H ldap://localhost

echo "$i wurde verschoben"
fi
done

 

Das Leben ist schön.

Windows Server 2008(R2) - externer NTP Server

Ich musste leider vor kurzem mal wieder an einem Windows Server um eine profane Aufgabe zu erfüllen. Es sollten externe NTP Server eingerichtet werden. Da der Server gleichzeitig auch ein DC war, gestaltet sich das (natürlich) schwieriger als erwartet.

Es müssen die folgenden Befele ausgfeführt werden, damit der gewünschte Server für die Abfragen genutzt wird:

net stop w32time 
w32tm /config /syncfromflags:manual /manualpeerlist:"ntp1.domaene.de,ntp2.domaene.de"
w32tm /config /reliable:yes
net start w32time

Anschließend war dann auch wieder alles gut.

 

Cloning mit dd und ssh

 Rechner von der Hardware zu virtuellen Maschinen umzufunktionieren ist ja mittlerweile eine ziemlich langweilige Aufgabe geworden. Wenn man das ganze allerdings anders herum probiert, dann braucht man zwar keine riesen Hilfsmittel, aber ein wenig Umdenken ist schon gefragt.

In diesem Beitrag  beschreibe ich, kurz und knapp, wie man aus einem eine Festplatte über das Netzwerk auf eine andere (auch gern ein Imagefile) clont.

Genutzt wird dd. Mit Hilfe von dd kann man einen Datenstrom von Blockdevices abgreifen und zum Beispiel in einer Datei speichern. Da es auf diesem Weg funktioniert, funktioniert es auch im Netzwerk mit Hilfe von SSH ziemlich einfach.

Wir greifen einfach die Daten von der Festplatte/dem Image ab

dd if=/mnt/storage/vm1234.raw

und geben es mit einer Pipe an SSH weiter

 | ssh root@111.222.333.444

wo wir es dann an die entgültige Stelle bewegen:

dd of=/dev/sda

Vollständig sieht das dann so aus:

 

dd if=/mnt/storage/vm1234.raw | ssh root@111.222.333.444 dd of=/dev/sda 

Auf diesem Weg kann man dann ziemlich einfach die Daten einer Festplatte/eines Images durch das Netz an einen anderen Ort bewegen, um dort dann zum Beispiel seinen neuen Rechner in Betrieb zu nehmen.

Geholfen hat:

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

samba4 Openldap Backend

Es ist schon ein kleines Trauerspiel. Da begleitet mich Samba mindestens genau so lange durch meinen Linux/Unix Alltag wie die Erkenntnis, dass ein XClient getrennt von einem Server läuft und dann bemerkt man im langen Wechsel von Version 3 zu 4 doch einen erheblichen Hipster-Beigeschmack.

Die Rede ist davon, dass noch bei Samba3 wunderbare Bücher zu finden waren. Werke die nicht nur die Technik, sondern auch Charakter beschrieben und mitgebracht haben. Auf diesem Wege wurde man tief in die Möglichkeiten und Werkzeuge eingeführt, welche sich hier bieten. Mit Samba4 ist hiervon kaum noch die Rede. Klar, Microsoft ist im Boot und ich finde es sehr löblich, dass hierdurch die Schritte der Entwicklung vereinfacht wurden. Doch der Beigeschmack, wenn man sich die Topics des LPI anschaut und noch mehr wenn man ein Buch oder Informationen sucht ist ein wenig Bitter.

So erging es mir auch bei meinem Bestreben einen Samba4 Server als neuen Fileserver bereitzustellen, welcher seine Benutzer gegen ein OpenLDAP authentifiziert. Insgesamt kein reisen Hexenwerk möchte man meinen. Verschafft man sich einen Überblick indem man im Netz sucht und auf Erfahrungsberichte hofft, so wird man schnell enttäuscht. Die Rede ist immer wieder "der Aufwand lohnt nicht!" oder "Migration zu Samba Active Directory"... Sorry, dass ist nicht das was ich will. Ich will weder einen Nameserver auf meinem Fileserver laufen lassen, noch will ich meinen vorhandenen Stamm auf selben migrieren und alle Dienste umbauen. Ich will einfach nur einen Dateiserver haben der tut, was ein Dateiserver tut. Nur eben neuer und vielleicht ein wenig besser.

Lange Rede kurzer Sinn. Fündig geworden bin ich nicht. Die Tägliche Unruhe lies mich auch keine klaren Tage damit verbringen die Manpages auf eventuelle Fallstricke hin zu untersuchen. Also habe ich zunächst einmal gebaut, was ich so bauen konnte. Als dann eine ruhige Minute kam und die Muse stieg, warf ich beherzt den Debug-Modus an und kam recht schnell auf eine mögliche Ursache.

Die Lokale Domänen-SID des Samba, welche durch das Eintragen der OpenLDAP Daten in der Konfiguration einen Zugriff auf das Verzeichnis ermöglichte stimmte nicht mit der bestehenden Domäne überein. Das schien der Grund zu sein, weshalb eine Authentifizierung fehlschlägt.

Ironischer Weise findet man mit diesen Informationen dann auch Gleichgesinnte (http://lapsz.eu/blog/2013/09/04/standalone-samba-server-with-ldap-authentication/). Somit war mein "Problem" dann auch kein Problem mehr und wir konnten uns alle lieb haben. Seit dem arbeitet fröhlich der Samba als lokaler (neuer) Fileserver im Netzwerk und wartet auf all die Tollen Verbindungen.

Berechenbare Individualität - Frohe Weihnachten

Ich bin vermutlich nicht der einzige, der sich den zwängen der Gesellschaft nicht entziehen kann, ohne das gleich ein Konflikt mit mehreren leibgewonnenen Menschen entfacht wird.

Also stürze ich mich ins Netz und lasse der Empathie gepaart mit Einfallslosigkeit freien Lauf. Dabei habe ich natürlich das große "A" nicht ignoriert und bin gleich auf eine tolle Darstellung meiner Feststellung gestoßen, dass wir alle doch nicht so individuell sind wie wir es uns immer gern einreden.

undefined

undefined

undefined

Habt ihr es entdeckt? Nein? Es geht darum, das die Geschenke zwischen "Gern geschenkt", "Oft gewünscht" und "Bestseller" kaum variieren. Nun mag man sagen, dass die Menschen einfach bekommen, was sie sich wünschen. Doch auch hierbei schließt sich der Kreis. denn es lässt sich verdammt noch einmal vieles unserer vermeintlich individuell gestalteten Charakter vorhersagen, systematisieren und damit auch nutzen. 

Gute Chefs nutzen es, Mentalisten nutzen es und ja, auch social Engineers nutzen es. Ich selbst stehe total darauf, da es vieles einfacher gestaltet, wenn man akzeptieren kann, dass Dinge so sind wie sind sind anstatt sie aufgrund von Bauchschmerzen oder so weg zu reden, damit wir uns als tolle Menschen verstehen.

Frohe Weihnachten und viel Spaß beim entspannen wenn man sich eingestehen kann, das auch man selbst ziemlich "normal" im Sinne der "Systematisierbarkeit" ist.

KVM Migrate Skript

Es wäre gelogen wenn ich sagen würde, das ich "immer wieder" in die Situation gelange KVM Hosts zu bearbeiten oder zu migrieren. Dennoch ist KVM ein toller Hypervisor der sowohl Spaß macht, als auch interessante Features mit sich bringt und gleichzeitig vom Handling her den Eindruck vermittelt vieles noch handhaben zu können, auch wenn es mal zu dicken Schwierigkeiten kommt.

Daher habe ich für mein Setup ein Skript gebastelt, welches mir die Konfigurationen (XML - Daten) der eingerichteten virtuellen Maschinen mittels virsh exportiert um im falle eines Ausfalls die Maschinen wieder rekonstruieren zu können (mit wirsch define oder wirsch create).

Wichtig dafür ist natürlich das es ein externes Medium gibt auf dem die Daten gespeichert werden können. In meinem Fall ist es ein zentrales FreeNAS Storage.

Wenn man noch zwischen unterschiedlichen Linux Distributionen hin- und her switched hat man unter umständen das Problem, dass bestimmte Maschine types nicht vorhanden sind oder andere Werte angepasst werden müssen. Dazu nutze ich einfach "sed" das mir unter die Arme greift.

Als Ergebnis habe ich mittels Cron alle voll Stunde frische Konfigurationsdateien die ich einfach auf einem anderen KVM Host importieren kann.

Mit Hilfe meines Skript kann ich nun mit Hilfe von Parametern sowohl alle virtuellen Maschinen an ohne Angabe eines Parameters an einen in "CONFIGDESTDIR" definiertenOrt speichern, oder diesen angeben.

  • Alle Konfigurationen im Pfad speichern der im Skript angegeben ist
    • kvm-export.sh
  • Alle Konfigurationen im Pfad speichern der als Parameter angegeben wird
    • kvm-export.sh export /PATH/TO/NEW/STORAGE

Beim Import verhält es sich ein wenig anders. Hier kann ich zusätzlich noch eine bestimmte Maschine angeben

  • Alle Konfigurationen im Pfad speichern der im Skript angegeben ist
    • kvm-export.sh
  • Alle Konfigurationen im Pfad speichern der als Parameter angegeben wird
    • kvm-export.sh import /PATH/TO/NEW/STORAGE
  • Eine bestimmte Maschine importieren
    • kvm-export.sh import /PATH/TO/NEW/STORAGE
#!/bin/bash
CONFIGDESTDIR=/PATH/TO/STORAGE/

if [ "$1" == "export" ]; then
if [ -z "$2" ]; then
echo "Konfigurationen werden nach $CONFIGDESTDIR exportiert!";
else
CONFIGDESTDIR=$2
echo "Konfigurationen werden nach $CONFIGDESTDIR exportiert!";
fi

if [ -d $CONFIGDESTDIR ]; then
echo "Exportverzeichnis ist vorhanden.";
else
echo "Exportverzeichnis ist nicht vorhanden und wird angelegt!";
mkdir $CONFIGDESTDIR;
fi

for i in $(virsh list --all | sed '1,2d' | awk '{print $2}')
do
VMNAME=$(basename $i .xml)
virsh dumpxml --migratable $VMNAME > $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/\/usr\/bin\/kvm/\/usr\/libexec\/qemu-kvm/" $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/machine='pc-1.1'/machine='pc-i440fx-rhel7.0.0'/" $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/machine='pc-0.12'/machine='pc-i440fx-rhel7.0.0'/" $CONFIGDESTDIR/$VMNAME.xml;
sed -i "s/type='vmvga'/type='vga'/" $CONFIGDESTDIR/$VMNAME.xml;
done
fi
if [ "$1" == "import" ]; then
if [ -z "$2" ]; then
echo "Konfigurationen werden aus $CONFIGDESTDIR importert!";
else
CONFIGDESTDIR=$2
echo "Konfigurationen werden aus $CONFIGDESTDIR importert!";
fi
if [ -d $CONFIGDESTDIR ]; then
echo "Importverzeichnis ist vorhanden.";
else
echo "Importverzeichnis ist nicht vorhanden!";
exit;
fi
if [ -z "$3" ]; then
echo "Es werden alle Maschinen importiert!";
for i in $(ls $CONFIGDESTDIR/*.xml)
do
echo "Definiere Maschine $i";
virsh define $i;
echo "Richte Autostart ein fuer: $i";
virsh autostart $i;
done
else
echo "Definiere Maschine $3";
virsh define $CONFIGDESTDIR/$3;
echo "Richte Autostart ein fuer: $3";
virsh autostart $CONFIGDESTDIR/$3;
fi
fi

Wenn FreeNAS nicht replizieren will, hilft ein einfaches "python /usr/local/www/freenasUI/tools/autorepl.py" auf die Sprünge!

lsof -i | cut -f 1 -d " " | sort | uniq Und Du weißt was läuft!

Mac El Capitan SIP (rootless) horror

Es ist mir schon immer ein Rätzel gewesen, weshalb alle Welt verrückt nach "Internet-Security-Suiten" zu sein scheint. Jedenfalls gibt es einen riesigen Markt dazu und Endbenutzer vermuten einen persönlichen Bodyguard dahinter.

Ganz falsch ist das zwar nicht. Allerdings muss man auch ehrlich sein und zugeben, dass ein Bodyguard nichts macht, wenn der Chef sich dämlich verhält.

Wie dem auch sei: Für Firmen und Rechner macht es durchaus Sinn seine Daten und Zugriffe gegen potentielle Gefährdungen zu schützen - ich sehe das wie ein "Vier-Augen-Prinzip". Dumm ist es nur, wenn hierbei die Software nicht mit Spielt.

Mittlerweile ist es für mich die erste Anlaufstelle den Virenscanner bei Problemen zu deaktivieren um zu schauen, ob sich das gewünschte Verhalten einstellt. Zuletzt habe ich diverse Lösungen auf meinem Mac  ausprobiert und wunderte mich über deren "Nichtfunktionieren". Es stellte sich heraus, das Apple mit El Capitan eine (sinnvolle) Erweiterung integriert hat, welche sich SIP (System Integrity Protection) - oder kurz rootless - nennt.

Diese scheint jedoch - wie vieles das man "mal eben so" integriert den Anbietern von Drittsoftware einiges an Schwierigkeiten zu bereiten. Zumindest ist das Netz ziemlich voll davon.

Abhilfe schafft folgendes:

  1. Rechner in den Recovery-Modus booten (CMD+R)
  2. Terminal Starten
  3. csrutil disable eintippen
  4. Neustarten.

Sicherlich ist das nicht die tollste aller Lösungen, aber wenn es nicht anders geht, dann geht es nicht anders.

Über die selben Schritte kann man es auch wieder aktivieren - nur eben mit einem csrutil enable zum Schluss.

 

Quellen:

Migration von LVM zu qemu

Es gibt viele Wege die nach Rom führen. Das gilt auch in Landschaften für virtuelle Infrastrukturen. Was einem heute noch gefallen mag, ist morgen nicht mehr praktisch.

Wie in vielen Dingen ist es bei Lösungen unter Linux nicht gegeben, dass man ein oder zwei Wege zur Auswahl hat, sondern mehrere. In vielen fällen wird geraten VMs auf LVM (Logical Volume Manager) Basis mit RAW Festplatten auszustatten. Das ist in sofern richtig, dass weniger Abstraktionsschichten auch bedeuten dass es weniger zu verwalten gibt und daher auch meist schneller ist.

Im Vergleich zu dem KVM (qemu) eigenen QCow2 Format gibt es seit jeher Messungen, Messungen, Diskussionen und Vergleiche was denn nun das beste sei. Ich denke, das ab einem gewissen Grad an vorhandener Grundleistungen die Zahlen kaum noch das reale Empfinden bei der Arbeit mit den Maschinen widerspiegeln - gesonderte Ausnahmen selbstverständlich aussen vor.

Allerdings hat man mit Images auf Dateibasis den Vorteil der Flexibilität auf seiner Seite. Mitnehmen, verschieben, zwischen den Maschinen migrieren - alles langweilig, weil einfach.

Wenn man nun diesen Weg gehen möchte, muss das, was bisher als logical  Volume vorlag in ein Image umgewandelt werden. Dazu habe ich mir dieses einfach Skript überlegt und getestet. Wichtig ist, dass alle umzuwandelnden Disks in einer Volumegroup liegen. Hat man sich für eine Namenskonventions der Laufwerke entschieden kann diese nachträglich eingebaut werden. Will man die Dateien und Laufwerke manuell angeben kann das Skript ebenfalls sehr einfach angepasst werden.

 

#!/bin/bash

VGNAME=/dev/name-der-volumegroup

STORE=/mnt/

CONVFORMAT=qcow2

 for i in $(ls /dev/$VGNAME/);

do

qemu-img convert -p -O $CONVFORMAT VGNAME/$i $STORE/$i.qcow2;

done

 

Sobald alles durchgelaufen ist, hat man seine Images unterhalb des Verzeichnisses, dass in der Variablen $STORE angegeben ist. 

Natürlich kann man noch 1000 Features einbauen. Für mich hat es allerdings gereicht um eine Umgebung für den Umzug vorbereiten zu können.

Wichtig: Nach der Umwandlung die Konfiguration der virtuellen Maschine anpassen, sodass die neue Festplatte genutzt wird. Das passiert üblicher Weise in der Datei /etc/libvirt/qemu/VMNAME.xml 

<disk type='file' device='disk'>
<driver name='qemu' type='qcow2' cache='none'/>
<source file='PFAD-ZUM-IMAGE.qcow2'/>

Firefox / Iceweasel Tabs beim beenden speichern

Eine der unsinnigsten Entwicklungen im Internetzeitalter war die Einführung und anschließende Abschaffung der Funktion, dass die geöffneten Browsertabs beim Beenden gespeichert werden.

Zunächst wirkte es für mich ungewohnt, als mein Browser da weitermachte, wo ich aufgehört habe. Nachdem ich allerdings den Weitblick erkannte, den die Entwickler an den Tag gelegt hatte, freute ich mich sehr über die Funktion. Sie ist nützlich und ermöglicht einen tollen Workflow.

Da nun jedoch ein Kniff notwendig ist, um diese tolle Funktion wieder zu aktivieren, teile ich das folgende Video, was ganz nett erklärt wie man über die Adresse "about:config" die Variable "browser.showQuitWarning" auf "true" setzt.

 

Linux KVM LVM Volume auf Qcow2 konvertieren

Wenn man seine virtuelle Infrastruktur mit KVM betreibt, so hat man es nicht leicht. Viele Möglichkeiten und eine fast besser als die andere. Perfomantes LVM RAW Device für die Festplatten gegenüber dem flexiblem QCow2 zum mitnehmen und leichten ablegen/bewegen der Images.

Im grunde genommen spielt es vermutlich kaum eine rolle welche der vielen Möglichkeiten man für sich entdeckt - die Einfachheit hat auch hier wieder eine Lösung für den Fall das man sich mittendrin anders entscheidet.

Wenn man beispielsweise seine VM von einem Debian mit LVM/RAW auf ein CentOS mit QCow2 umziehen möchte, so geht das folgendermaßen:

  1. Image der LVM VM: qemu-img convert -O qcow2 /dev/{VOLUMEGROUP}/{LVMDEVICE} /{PATH-TO-STORAGE}/{VM-NAME}.qcow2
  2. Transfer des Image auf den neuen Hypervisor: scp -v /{PATH-TO-STORAGE}/{VM-NAME}.qcow2 root@NEUERHYPERSIOR:/STORAGE/
  3. Transfer der Konfiguration auf den neuen Hypervisor: scp -v /etc/libvirt/qemu/{VM-NAME}.xml root@NEUERHYPERSIOR:/etc/libvirtd/qemu/{VM-NAME}.xml 
  4. Anpassen der Konfiguration auf dem neuen Hypervisor:
    1. <emulator>/usr/bin/kvm</emulator> ändern zu <emulator>/usr/libexec/qemu-kvm</emulator>
    2. <type arch='x86_64' machine='pc-1.1'>hvm</type> ändern zu <type arch='x86_64' machine='pc-i440fx-rhel7.0.0'>hvm</type>

    3. <driver name='qemu' type='raw'/> ändern zu <driver name='qemu' type='qcow2'/>
    4. <source dev='/dev/{VOLUMEGROUP}/{LVMDEVICE}'/> ändern zu <source dev='{PATH-TO-STORAGE}/{VM-NAME}.qcow2'/>

Grundsätzlich empfiehlt es sich nicht allzu viele Sonderlocken einzubauen und sich möglichst nah am Standard zu bewegen, damit die kompatibilitäten innerhalb der Systeme gegeben sind.

Happy migrating!

Erste Schritte in Ansible

In meinem vorherigen Beitrag habe ich erwähnt, wie cool ich Ansible finde. Dabei hab ich wohl nicht genug erwähnt, wie logisch und dennoch verspätet die Entwicklung kam. Mich fragt ja keiner…

Nun gut, da Ansible das logische nächste Level des Qualitätsbewussten, Keep it stupid and simple Administrator ist, ist es nur plausible dass man damit beginnt es zu benutzen.

In Ansible dreht sich alles um das zu verwaltende Inventar. Dieses wird in einer „hosts“ Datei definiert. Das coole daran: wenn man unterwegs in verschiedenen Netzwerken ist, kann man diese Datei zum Beispiel für jeden Kunden eigens definieren. In der Hosts Datei wird im einfachsten Falle einfach eine Liste mit Rechnernamen und IP-Adressen geführt.

Rechner1
192.168.2.189
weibserver.domain.com

und schon kann es los gehen.

Auf allen Adressen im Inventar kann man direkt nach dem einpflegen schon so genannten Ad-Hoc Kommandos absetzen. Also Kommandos auf der Shell welche auf den entfernen Rechner ausgeführt werden.

ansible all -a „ifconfig eth0“

würde in einem solchen Fall dafür sorgen, dass die Ausgabe des Kommandos „ifconfig eth0“ auf dem entfernen Rechner ausgeführt wird und man das Ergebnis ausgegeben bekommt.

An dieser Stelle hat man mit Ansible schon ein mächtiges Werkzeug, denn es gibt einen ganzen Eimer voller Module, die schon implementiert sind und daher fast keine Wünsche offen lassen. Angefangen vom einfachen Ausführen von Kommandos, über das kopieren von Dateien bis hin zum Ansprechen von Diensten, Programmen und Funktionen (List der Ansible Module).

Wer jetzt noch nicht überzeugt ist, dass Ansible die Erfüllung von Adminträumen ist, der soll doch bitte Windows benutzen :).

Home ← Ältere Posts