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:

Source: Der Bode

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‚/>

Source: Der Bode

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‚/>

Source: Der Bode

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.

 

Source: Der Bode

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!

Source: Der Bode

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 :).

Source: Der Bode