Seite wählen

NETWAYS Blog

Einfaches und schnelles Erstellen und Verteilen von Dateisystemimages

In Vorbereitung auf unsere anstehenden Schulungstermine für Puppet und SLA, stelle ich heute die Software Clonezilla vor, mit der einfach und performant Images erstellt und über das Netzwerk verteilt und eingespielt werden können.
Clonezilla bedient sich dabei mehrerer Projekte und fasst diese unter einem Dach mit einer Konfigurationsoberfläche zusammen:

Somit bietet Clonezilla den Vorteil mit nahezu jedem gebräuchlichen Dateisystem zusammenarbeiten zu können, was bei der Einzellösung Partimage, beispielsweise nicht der fall ist, da NTFS nur experimentell unterstützt wird.
Ebenfalls hat das Team um Clonezilla eine LiveCD bereitgestellt, mit der ohne Installation ein bestehendes System auf lokale Datenträger oder Netzwerkfreigaben wie Samba, NFS oder SSH gesichert werden können. Die Menüführung ist dabei selbsterklärend.
Um die Images auf einzelnen Maschinen zurückzusichern, bietet sich ebenfalls die LiveCD von Clonezille an. Sollte jedoch die Anforderung bestehen über Multicast mehrere Geräte zurückzusichern, so muss man zu der CloneZilla Server Edition greifen. Die Server Edition kann dann in Verbindung mit DRBL den Clients einen PXE Boot anbieten, worüber dann automatisiert das Image zurückgespielt wird.
Auf der Projektseite von Clonezilla befinden sich zusätzlich auch sehr gute Dokumentationen und Beispiele für den praktischen Einsatz.
Das Team von DRBL hat auf seiner Prokeltseite zusätzlich ein Live System erstellt , welches ebenfalls CloneZilla ServerEdition beinhaltet. Diese LiveCD kann genutzt werden um schnell und ohne großen Konfigurationsaufwand eine laufende CloneZilla Umgebung zu bekommen.

ispCP: Einfaches Control Panel zur Webserververwaltung

Für viele Anwender ist das Anlegen von Apache-vhosts oft eine kryptische Angelegenheit, da man sich durch einige Zeilen Anweisungen der Apache-Syntax durchwühlen muss und der Dienst den Start wegen Fehler verweigert. Oder man möchte mehrere Kundenwebsites auf einem großen System bequem verwalten, Mail-Konten anlegen und zuweisen, Domainadressen vergeben oder um bei ca. 100 Kunden nicht den Überblick zu verlieren.
Genau für solche Szenarien eignet sich die freie und offene Software ispCP Omega, ein Fork aus dem nicht mehr aktiven VHCS Projekt. ispCP besticht durch seine gute Bedieneroberfläche und dem Funktionsumfang. So ist es beispielsweise möglich, Benutzer in verschiedene Rollen zu unterteilen wie „Administrator“, „Reseller“ und „User“ und ihnen auch gezielt bestimmte Berechtigungen zuzuweisen oder zu entziehen.
Die Installation wird über ein Installationsskript und den von ispCP bereitgestellten Dokumentationen sehr einfach vollzogen und es ist binnen weniger Minuten fertig.
Scheut man eine Versuchsinstallation, so kann man sich auf der Projektseite auch gern an den Online-Demos austoben und ispCP auf Herz und Nieren überprüfen.
Wir haben bei einem Kunden ispCP erfolgreich im Einsatz und stießen auf großen Zuspruch seinerseits. Ebenfalls haben wir ispCP in einem Cluster aus zwei Nodes im produktiven Betrieb und sogar die Installation vollkommen automatisiert in Puppet abgebildet.
ispCP wird schon seit einiger Zeit sehr aktiv entwickelt und steht aktuell in der stabilen Version 1.0.7 bereit. Wer gern schon jetzt einen Blick auf die neuen Features der kommenden Version werfen möchte, dem sei die Entwicklerversion 1.1.0 Beta empfohlen.

Backporting – Quick and a bit dirty

Oftmals steht man vor der Problematik, dass man auf seinem Produktivsystem eine aktuellere Version von einem Programm benötigt als sie bereits im Repository der stabilen Ausgabe von Debian vorhanden ist. Für solche Problemfälle gibt es das Backports-Projekt, indem aber natürlich auch nicht alle Pakete enthalten sind, da nur selektiv einzelne Pakete aus dem neuen „testing“-Zweig von Debian gegen ein Stable-Environment gebaut werden.
Häufig werden dann die benötigten Programme in aktueller Version selbst übersetzt und somit aus der Paketverwaltung ausgekoppelt, was das Einspielen von Updates erschwert.
Der direktere Weg ist selbst sich Pakete zu backporten. Dies hat folgende Vorteile:

  • Integration in die Paketverwaltung (Vereinfachung beim Einspielen von Updates oder einem Upgrade)
  • durch die Maintainer an das Debian-System angepasst
  • einfache Weitergabe und Verteilung auf mehreren Systemen

Grundlage bietet zunächst eine chroot-Umgebung, damit das System, auf dem Gearbeitet wird nicht „zugemüllt“ wird durch diverse dev-Pakete. Das Anlegen eines chroots ist recht einfach und geschieht mit debootstrap (muss als root ausgeführt werden)

root@localhost:~# mkdir chroot_squeeze
root@localhost:~# debootstrap squeeze chroot_squeeze/ http://ftp.de.debian.org/debian
I: Retrieving Release
I: Retrieving Packages
....

Wenn debootstrap die Umgebung gebaut hat, kann mit chroot chroot_squeeze/ /bin/bash in das chroot gewechselt und ohne Gefahr gearbeitet werden. Weiterer großer Vorteil ist, dass wenn was schief geht und das System „zerschossen“ wird, man den chroot-Ordner einfach löscht und neu anlegt.
In der chroot-Umgebung sollten zunächst die /etc/apt/sources.list angepasst und um die Source-Quellen erweitert werden. Empfehlenswert ist es zunächst ersteinmal komplett den stable-Zweig von Debian zu verwenden, um die Build-Dependencies von den Stable-Paketen zu installieren. Hintergrund ist, dass so schon einmal der Großteil der benötigten Pakete installiert wird und später schneller und gezielter die fehlenden Abhängigkeiten aufgelöst werden können.

root@localhost:~# chroot chroot_squeeze/ /bin/bash
root@localhost:/# cd ~
root@localhost:~# mkdir icinga ; cd icinga
root@localhost:~/icinga# apt-get build-dep icinga
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
....

Bei diesem Durchlauf sollten keine Fehler bzgl. Abhängigkeiten auftreten. Anschließend kann der Source-Eintrag in der /etc/apt/sources.list auf testing, unstable oder experimental geändert werden, je nachdem aus welcher Quelle man ein Paket benötigt. Anschließend erneut apt-get build-dep ausführen. Wenn hier Abhängigkeitsprobleme auftreten muss versucht werden diese Aufzulösen. In einigen Fällen kann es bedeuten, dass man zunächst andere Pakete backporten muss, damit die Abhängigkeiten der neuen Version stimmen. In unserem Beispiel von Icinga ist das jedoch nicht der Fall.
Es werden nun die Quellen mittels apt-get source icinga geholt und im Anschluss die Version mittels dch -v angepasst. Hierbei sollte man die Versionierung nehmen, wie sie auch beim Backports.org Projekt genutzt wird (paketname-1.0.2-2~xyz60+1 – genaueres ist aus backports.org zu entnehmen).

root@localhost:~/icinga# vi /etc/apt/sources.list
root@localhost:~/icinga# apt-get update
root@localhost:~/icinga# apt-get build-dep icinga
...
root@localhost:~/icinga# apt-get install devscripts #hier ist dch enthalten
root@localhost:~/icinga# cd icinga-1.4.1
root@localhost:~/icinga/icinga-1.4.1# dch --bpo

Nun öffnet sich ein Editor, der einem gleich die changelog Datei anbietet. Hier sollten noch Name und Email-Adresse angepasst werden und ggf. noch die Distribution (squeeze-backports, squeeze-backports-netways ..)
Nach dem Speichern kann das Paket mittels dpkg-buildpackage gebaut werden. Es kann sein, dass hier ebenfalls noch einmal Abhängigkeiten bemängelt werden, die man anschließend versuchen müsste aufzulösen, was jedoch aktuell und in unserem Beispiel nicht der Fall sein sollte.

root@localhost:~/icinga/icinga-1.4.1# dpkg-buildpackage
dpkg-buildpackage: setze CFLAGS auf Standardwert: -g -O2
dpkg-buildpackage: setze CPPFLAGS auf Standardwert:
dpkg-buildpackage: setze LDFLAGS auf Standardwert:
...

Ist der Build-Prozess erfolgreich durchgelaufen, liegen im übergeordneten Ordner die fertigen Debian-Pakete inklusive Quellpakete, welche dann in ein eigenes Repository hochgeladen werden können (bspw reprepro).
Ich möchte noch einmal darauf hinweisen, dass es unter unglücklichen Umständen (sehr große Versionssprünge und Abhängigkeitsprobleme) eine etwas umfangreicheres Unterfangen sein kann, ein Paket zurückzuportieren. Jedoch erntet man dafür die Vorteile und kann seine Ergebnisse mit anderen teilen.

Debian Web-Updateverwaltung mit Updian

Wer kennt das nicht: Man betreibt viele Server oder virtuelle Maschinen und immer wieder purzeln Updates herein, welche man dann per Hand einspielen darf. Dafür gibt es viele Lösungen, die einem die händische Arbeit abnehmen. Heute möchte ich gern eine auf Debian-Systeme zugeschnittene Variante vorstellen.
Es handelt sich dabei um die Software Updian, ein kleines Tool, welches in PHP geschrieben wurde.
Das Grundprinzip ist schnell erklärt. Updian prüft via SSH die Server, welche es in seiner Liste vorfindet, ob Updates über apt-get verfügbar sind. Dabei wird im Vorfeld die Paketliste aktualisiert. Das Ergebnis wird im Webfrontend dargestellt und man kann selektiv Server zu einer Update-Queue hinzufügen, welche dann abgearbeitet wird. Alle Operationsschritte, also das Sammeln der Informationen, ob Updates verfügbar sind und das Abarbeiten der Queue werden über einen eigenen Cronjob ausgeführt.
Zusätzlich bietet Updian eine „Multi-SSH“ Funktion, welche es erlaubt einen Befehl auf allen Systemen auszuführen.
Wenn der Benutzer es möchte, dann kann Updian auch eine E-Mail versenden, wenn es bei einem Prüfungsdurchlauf feststellt, dass Updates verfügbar sind.
Aber kommen wir nun zur Einrichtung von Updian:
Updian ist recht genügsam und es benötigt lediglich die Pakete php5, php5-cli und einen Webserver, der PHP unterstützt.
root@localhost:~# apt-get install apache2 php5 php5-cli
Die Installation von Updian selbst ist relativ unspektakulär. Auf der Projektseite findet man ein Debian-Paket vor, von dem ich aber auf Grund des Alters abrate (seit 2009 wurden keine Änderungen mehr an der Software getätigt). Statt dessen empfehle ich das .tar.gz-File herunterzuladen und im DocumentRoot vom Apache zu entpacken.
root@localhost:/var/www# wget http://www.robhost.de/updian/updian_v0.2.tar.gz
root@localhost:/var/www# tar xvfz updian_v02.tar.gz

Nach dem Entpacken sollte ein Ordner „updian“ vorhanden sein, indem alle Files liegen. Diesen Ordner sollte man dem Benutzer www-data zuordnen, da Updian in dem Ordner selbst Schreibrechte benötigt.
root@localhost:/var/www# chown -R www-data updian/
Updian bietet eine eigene Konfigurationsdatei (config.php), welche man seinen Wünschen anpassen kann.
Im nächsten Schritt wird ein Benutzer angelegt, welcher die Überprüfung der Systeme durchführt, quasi mit dem der Cronjob ausgeführt wird.
root@localhost:/var/www# adduser updian
Lege Benutzer »updian« an ...
.
.
Geben Sie ein neues UNIX-Passwort ein:
.
.
root@localhost:/var/www#

Anschließend benötigen wir einen SSH-Key, den wir auf den Systemen verteilen können, damit sich Updian ohne Passwortabfrage verbinden kann. Bei der Frage nach einem Kennwort oder Passphrase bitte nur die Entertaste drücken, da wir diesen nicht gebrauchen können.

root@localhost:/var/www# su - updian
updian@localhost:~# ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/updian/.ssh/id_dsa): [ENTER]
Created directory '/home/updian/.ssh'.
Enter passphrase (empty for no passphrase): [ENTER]
Enter same passphrase again: [ENTER]
Your identification has been saved in /home/updian/.ssh/id_dsa.
Your public key has been saved in /home/updian/.ssh/id_dsa.pub.
The key fingerprint is:
00:00:00:00:00:01:00:10:00:00:00:a0:00:00:00:00 updian@localhost
The key's randomart image is:
+--[ DSA 1024]----+
| ..oooEoo|

Damit unsere Systeme den Key auch kennen, muss er noch kopiert werden. Dies geht am Besten auf folgendem Wege:
updian@localhost:~# ssh-copy-id -i ~/.ssh/id_dsa.pub root@remoteserver

Damit regelämßig die Queue abgearbeitet wird und die Überprüfung auf Updates statt findet, müssen noch die entsprechenden Cronjobs angelegt werden. Hierbei empfiehlt es sich die datei /etc/crontab zu bearbeiten und folgende Zeilen hinzuzufügen:
0 8 * * * updian php /var/www/updian/cron_collect.php > /dev/null 2>&1
0 9 * * * updian php /var/www/updian/cron_updates.php > /dev/null 2>&1

In dem genutzten Beispiel wird täglich um 8 Uhr überprüft, ob Updates vorhanden sind und täglich 9 Uhr die Queue abgearbeitet.
Jetzt kann man Updian bekannt geben, welche Server es überprüfen soll. Das geht ganz einfach über das Web-GUI unter dem Punkt „Servers“, dazu ein Bild:

Nun überprüft Updian im festgelegten Intervall (Cronjob) ob Updates verfügbar sind und benachrichtigt einen, sofern man dies auch eingestellt hat.
Wenn Updian feststellt, dass es Updates hat, so zeigt es das in der Startseite „Home“ an, wo man auch die Möglichkeit hat, einzelne oder alle Server zur Update-Queue hinzuzufügen. Mit einem Klick auf den Servernamen kann man einsehen welche Pakete in einer neuen Version vorliegen.

Ein wichtiger Hinweis noch zum Schluss! Der Entwickler stuft Updian noch als Beta ein und weist auch darauf explizit hin. Bisher konnten wir im alltäglichen Betrieb keine Fehler erkennen und es hat sich in der Praxis bei vielen Systemen bewährt.

Druckauftrag an zwei Drucker senden

Gelegentlich kommt es vor, dass man vor der Aufgabe steht mehrere Dokumente in doppelter Ausführung zu drucken und das am besten noch in einer farbigen und in einer monochromen Ausgabe. Oft bedeutet das viel manuelle Arbeit, da jeweils der Druckauftrag für die farbige Fassung und für die schwarz/weiße gestartet werden muss.
Hierfür gibt es jedoch Abhilfe und verschiedene Lösungsansätze. Wer schon nach Software gesucht hat, welche das Verteilen eines Druckauftrages an zwei Drucker realisieren kann, ist bestimmt auf das Programm PrintMulti gestoßen. PrintMulti ist ein sehr mächtiges Tool, man hat viele Einstellungsmöglichkeiten und ist für Clientbetriebssysteme kostenfrei erhältlich, jedoch ist der Konfigurationsaufwand nicht ohne. Deswegen möchte ich hier eine Alternative vorstellen welche aus einer Kombination von Foxit-PDF Reader, CutePDF und einem AutoIT 3 Skript besteht.
Grundlage dafür bot mir aus dem AutoIT Forum ein Beitrag mit Codebeispiel, der schon fast dem entsprach, was ich in die Tat umsetzen zu versuchte. Die Funktionsweise ist schnell und einfach erklärt.
Es wird das zu druckende Dokument als PDF mittels CutePDF (oder anderen PDF-Exporten) ausgegeben und an einen bestimmten Ort abgelegt. Das AutoIT Skript schaut nach, ob neue Dateien vorhanden sind, wenn ja werden diese in einen Archivorder verschoben und umbenannt (aktuelles Datum+Uhrzeit) und im Anschluss mit FoxitPDF der Druckauftrag für beide Drucker gestartet. Zwar ist dies nicht die eleganteste Lösung, jedoch funktioniert sie in der Praxis recht gut und hat einen geringeren Einrichtungsaufwand als PrintMulti. Im Anschluss noch der Quelltext des AutoIT Skripts:
[code]
$ordner = "C:\PDFs\"
$archiv = "C:\druck\"
$foxit = "C:\Programme\Foxit Software\Foxit Reader\Foxit Reader.exe"
$drucker1 = "Drucker 1"
$drucker2 = "Drucker 2"
While 1
Sleep(1000)
$file = FileFindFirstFile($ordner & "*.pdf")
If $file <> -1 Then Print()
FileClose($file)
WEnd
Func Print()
While 1
$pdffile = FileFindNextFile($file)
$neuname = @YEAR & @MON & @MDAY & @HOUR & @MIN & @SEC & @MSEC
If @error Then ExitLoop
FileMove($ordner & $pdffile, $archiv & $neuname & ".pdf")
While 1
Sleep(100)
If FileExists($archiv & $neuname & ".pdf") Then
ExitLoop
EndIf
WEnd
RunWait(‚"‘ & $foxit & ‚" /t "‘ & $archiv & $neuname & ‚.pdf" $drucker1‘)
RunWait(‚"‘ & $foxit & ‚" /t "‘ & $archiv & $neuname & ‚.pdf" $drucker2‘)
WEnd
EndFunc ;==>Print
[/code]
In den Variablen $drucker1 und $drucker2 kann man die Druckernamen, welche auf dem System vorhanden sind definieren. Natürlich kann man auch die Drucker selber umbenennen. Wichtig hierbei ist, dass die Drucker direkt von dem Client angesprochen werden und nicht über eine Samba Freigabe. Die Ordner „druck“ und „PDFs“ müssen manuell angelegt werden und natürlich schreibende sowie auch lesende Zugriffsrechte für die jeweiligen Nutzer haben.
(Picture by glasseyes view)
Edit TA (13.12.2017):
@Sascha hat in den Kommentaren das Skript hergenommen, aktualisiert und um eine Funktion erweitert: Fächerauswahl!
Unbedingter Lesebefehl!