Frontrange

Debian Server mit enteo v6 ausrollen

Dirk Eisenberg — Sun, 09 Aug 2009 23:43:17 GMT

Für verschiedene Experimente brauchte ich die Möglichkeit mit v6 einen Debian Server auszurollen. Die Anforderungen waren wie folgt:

- Es soll für die SW Installation der debian eigene Paket-Manager apt verwendet werden.
- Für das unbeaufsichtigte Ausführung der Setups soll preseed zum Einsatz kommen

Die Posts werden sich rund um diese Anforderung drehen und folgende Themen erläutern

Teil 1: Basis OS Image + Change Root environment
Teil 2: Installation von Software via apt und preseed
Teil 3: Einen Debian Server in das Active Directory aufnehmen

Teil 1:

Die Überlegung eine Basis Image eines Debian-System auszurollen und die Software Installation dann via change root (chroot) Umgebung zu realisieren liegt dem ganzen System zu grunde.

Schritt 1: Ganz zu Beginn muss neben der v6 Installation die hier nicht beschrieben werden soll, manuell ein Basis Debian System installiert werden. Hierzu startet man am besten vom Visitenkarten-Image und wählt beim TaskSel alle Rollen bis auf das Basis-System ab. In meinem Fall wird davon ausgegangen das die gesamte Netzwerk-Konfiguration via DHCP erledigt wird. Ausgenommen hiervor ist lediglich der Hostname, welcher später im Rahmen der Nachkonfiguration gesetzt wird.

Schritt 2: Ist die Installation durchgeführt, kann diese um den ein oder anderen Aspekt bereinigt werden. Hierbei ist durchaus ein Blick in das Verzeichnis /etc/udev/rules.d zu werden und auszuschließen das beim nächsten System die Netzwerkkarte nicht zu eth1 wird. Im zuge dieser Arbeiten kann auch das Root-Passwort auf einen zufälligen Wert gesetzt werden. Die ein oder andere Software darf je nach Anwendungsfall hier schon mitinstalliert werden, bei mir ist das der SSH-Server um im Fehlerfall remote das halbfertige System warten zu können.

Schritt 3: Das fertig anonymisierte System wird herunter gefahren und der Computer wenn nicht schon via AutoInsert passiert in v6 angelegt. Danach kann auf diesem PC direkt eine Policy "TrueImage Capture" erstellt werden. Hierdurch wird das Plattenimage gespeichert und kann später wieder verwendet werden.

Schritt 4: Zur proben sollte das eben erzeugt Acronis-Image einmal auf einen anderen PC zurück gespielt werden. Klappt das auch kann man direkt zum nächsten Schritt übergehen.

Schritt 5: Um jetzt Software auf das System zu bringen bleibt nur dsa BootEnvironment in Ermangelung eines aktiven Linux-Clients. Da das ganze mit dem Debian-Installer apt passieren soll, brauchen wir eine chroot-Umgebung. Hierzu wird also folgendes PreOsAction-Package erzeugt:

# Init
echo "Starting the post processing in our change root environment"

# mount the os partition
mount /dev/sda1 /mnt

# download the postprocessing file
echo " downloading config..."
wget http://YOURMPSERVER:8080/pscript/global.sh
wget http://YOURMPSERVER:8080/pscript/%OSD.COmputerName%.sh

# move it to the right pos
mv global.sh /mnt/global.sh
mv %OSD.COmputerName%.sh /mnt/current.sh

# adjust the execution rights
chmod 700 /mnt/global.sh
chmod 700 /mnt/%OSD.COmputerName%.sh

# set the environment
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/bin:/sbin
export PATH

OSDComputerName=%OSD.COmputerName%
export OSDComputerName

# perform the chroot command
echo " performing actions..."
chroot /mnt /global.sh

# after this we will umount everything
echo " cleaning environment"
rm -f /global.sh
rm -f /current.sh

umount /mnt

Wie man unschwer erkennen kann, passieren 3 Dinge. Es wird eine Datei herunter geladen, die Änderungen für alle Clients durchführt, es wird eine spezifische Dateien für den Client herunter geladen um pro PC ein anderes Set von Software installieren zu können. Das ganze wird dann noch so aufbereitet das die Dateien auch in der chroot-Umgebung ausgeführt werden.

An diesem Punkt ist man in der Lage alles mit dem Debian-System zu machen worauf man Lust hat. Das komplette enteo Paket als auch die beiden Shell-Scripte findet man hier zum Download.

Bei Fragen und Anregungen einfach einen Kommentar hinterlassen.

enteo v6 - Multi Target Policy

Dirk Eisenberg — Wed, 24 Jun 2009 21:12:55 GMT

Im Rahmen meiner verschiedenen Kundenbesuche werde ich ab und an mit einer sich wiederholenden Frage konfrontiert: Wie kann ich einen sauberen Compliance-Bar erzeugen wenn ich die Software über verschiedene Gruppen zuweisen muss?

Der scheinbar offensichtlichste Weg ober ein Policy-Objekt je Gruppe (eine Zuweisung pro Gruppe) führt hier nicht zum Ziel. Viel einfacher lässt sich das Thema via Multi-Target-Policy-Objekte erreichen. Hierbei handelt es sich um normale enteo v6 Policy-Objekte die aber nicht ein spezifisches Ziel haben (OU, Gruppe oder Computer) sondern eine Liste von Zielen. Dies kann erreich werden, in dem der Eigenschaften-Dialog einer Policy via Kontext-Menu aufgerufen wird. Hinter dem Reiter "Ziele" verbirgt sich die Liste aller Ziele.

Leider ist diese leistungsfähige Feature nicht so sehr bekannt wie es sein sollte. Als Hintergrund hierzu sollte man wissen das enteo v6 nur Multi-Target-Policy-Objekte kennt und der Sonderfall eine Policy mit nur einem Target ist. Die Policy auf nur ein Target hat eben nur ein Element in seiner Target-Liste und kenn jederzeit um weitere Elemente wie oben beschrieben erweitert werden.

Einen Pferdefuß gibt es natürlich auch hier und diese möchte ich nicht verheimlichen: Installations-Parameter können nur an Policy und Policy-Instance verändert werden und somit nicht per Target spezifisch konfiguriert werden. Kommt diese Anforderung hinzu, muss wieder der Weg über mehrere Policy-Objekte gewählt werden oder die Parameter werden an jeder einzelnen Policy-Instance spezifisch konfiguriert.

new on twitter

Dirk Eisenberg — Wed, 24 Jun 2009 21:02:12 GMT

Neben den v6 Artikeln in meinem Blog habe ich mir vorgenommen ab und an in twitter kleine Status-Meldungen zu unserem Produkt abzugeben. Wer spass daran hat einfach unter http://www.twitter.com/deisenbe !

enteo v6 - Package Library

Dirk Eisenberg — Sat, 20 Jun 2009 17:49:25 GMT

Ich habe mich heute entschlossen nach und nach meine privaten v6 Pakete, die ich so gebaut habe und bauen werden frei zur Verfügung zu stellen. Jeder der also interesse an ein paar enteo scripts hat, kann diese inklusive einer Beschreibung wie die entsprechenden Original-Sources zu intergrieren sind hier abrufen:

http://www.dirk-eisenberg.de/DEI/Projects.html

Rückmeldungen zu Problemen oder Fehlern sowie andere Kritik und Anregungen sind herzlich willkommen.

enteo v6 - Status von Policyinstanzen im eScript steuern

Dirk Eisenberg — Sat, 01 Nov 2008 20:06:34 GMT

Daheim auf dem Sofa sitzend habe ich mich eben geärgert das wegen meiner unschönen Netzwerkkonfiguration ich nach jeder OSD Installation den DNS Server auf meinen DC umbiegen muss. Das warum soll hierbei mal keine Rolle spielen. Wenn man also so einen v6 Server sein eigen nennt kann man diesen Schritt ja auch gleich automatisieren.

Folgendes wollte ich mit meinem Script erreichen:

1. Es ist überall einsetzbar und auf jede Netzwerkverbindung anwendbar
2. Tritt ein Fehler auf weil netsh.exe Probleme hat die Einstellungen zu setzen soll die Policyinstanz auf rot gehen
3. Der aufgetretene Fehler soll im LastComment-Feld der Policyinstanz sichtbar sein

Um 1. zu realisieren kommen in enteo v6 nur Installationsparameter in Frage. Daher nutze ich einen Parameter in dem der Name der entsprechenden Netzwerkverbindung steht und einen zweiten in dem die neue DNS-Server-Adresse steht. Diese beiden Installationsparameter müssen bei Zuweisung änderbar markiert werden da man sonst je jedesmal das Paket anfassen muss wenn man einen neuen Wert vergeben möchte.

Um 2. zu realisieren kommt der ab enteo v6.2 zur Verfügung gestellte Befehl ExecuteEx in Betracht. Mit diesem Kommando kann der Rückgabe-Wert eines Prozesses in eine eScript Variable geschrieben werden. Hat man mal den Rückgabewert in einer Variable kann mit Hilfe der "If" Struktur und dem ebenfalls neuen Kommando ExitProcEx die Installation als "failed" markiert werden.

Um jetzt noch 3. realisieren zu können, kann dem Kommand ExitProcEx ein Kommentar mitgegeben werden. In diesem Kommentar wird die Fehlercode-Variable aufgelöst.

HIER findet sich das exportierte Paket für alle die es mal ausprobieren wollen. Das Beispiel hat nicht den Ansprach die besten Lösung für das Wechseln von DNS-Adresse zu sein. Es soll viel mehr zeigen wie man mit den in enteo v6.2 zur Verfügung gesellten Mitteln den Compliance-Status seiner Policyinstanz beeinflussen kann. Viele externe Installer und Tools geben über diesen Mechanismus Fehlercodes zurück die ausgewertet können.

enteo v6 - Part 2 - CMDB Eigenschaften verwenden

Dirk Eisenberg — Sat, 19 Apr 2008 15:46:39 GMT

Ich bekommen immer mal wieder anfragen wie man von einem enteo v6 Objekt wie dem Computer Parameter auslesen kann und diese im Skript verwendet werden. Vor einiger Zeit habe ich dazu mal einen Artikel im enteo-Forum gepostet. Dieser beschreibt nicht nur wie man die Properties ausliest, sondern wie mit Hilfe eines enteo Scripts verschiedene Werte gesetzt werden können.

>> Viel Spass mit dem Artikel <<

enteo v6 - Part 1 - Klassifizierung von Befehlen

Dirk Eisenberg — Sun, 06 Apr 2008 17:54:07 GMT

Im ersten Teil der enteo Reihe möchte ich ein Feature genau beschreiben was hier und da vielleicht in Vergessenheit geraten ist. Die Möglichkeit Befehle in der enteo Script-Sprache zu klassifizieren gibt es schon sehr lange. Ich glaube die Funktion wurde mit dem NT-Support in das Produkt aufgenommen. Wozu braucht man das aber nun und wie funktioniert es:

Wozu:

Oftmals darf der angemeldete Benutzer nicht viel am System verändern aber das Logon-Verhalten des Benutzer steuert eigentlich indirekt die Installation. Daher gibt es die Möglichkeit Aufgaben an einen Dienst zu delegieren und somit Änderungen die administrative Rechte benötigen durchzuführen.

Wie:

(Fast) Jeder Befehl lässt sich im Scrip-Editor klassifizieren. Hierfür stehen folgende Möglichkeiten zur Verfügung:

immer ausführen
maschinenbezogen
maschinenbezogen per Service
userbezigen
userbezigen per Service

Für die Bewertung wann welche Klassifizierung verwendet wird, ist wichtig die Trennung zwischen Benutzerteil und Maschinenteil zu verstehen. Jedes enteo Script besteht immer aus einem Benutzer und Maschinenteil, egal ob man das sieht oder nicht. Bei der Installation des Paketes muss jetzt entschieden werde, welche Befehle ausgeführt werden müssen. Es gibt die Möglichkeit das Befehle im Rahmen des Maschinenteils oder im Rahmen des Benutzerteils ausgeführt werden. Diese Entscheidung muss entweder der Service-Installer oder der Auto-Installer, wobei der Service-Installer nur die Maschinenteile installieren kann und keine Benutzerteile da es ja keinen angemeldetet Benutzer gibt. Also wann wird nun was ausgeführt:

immer ausführen:

wird durch den ServiceInstaller oder den AutoInstaller ausgeführt
wird während der Installation des Benutzerteils als auch des Maschinenteils ausgeführt
wird im Kontext des jeweiligen Installers ausgeführt

maschinenbezogen:

wird durch den ServiceInstaller oder den AutoInstaller ausgeführt
wird nur während der Installation des Maschineteils ausgeführt
wird im Kontext des jeweiligen Installers ausgeführt

maschinenbezogen per Service:

wird durch den ServiceInstaller oder den AutoInstaller ausgeführt
wird nur während der Installation des Maschinenteils ausgeführt
wird im Kontext des Services ausgeführt

userbezogen:

wird nur durch den AutoInstaller ausgeführt
wird nur währned der Installation des Benutzerteils ausgeführt
wird im Kontext des AutoInstallers ausgeführt

userbezogen per Service:

wird nur durch den AutoInstaller ausgeführt
wird nur währned der Installation des Benutzerteils ausgeführt
wird im Kontext des Service ausgeführt

Das folgende Beispiel soll das Verhalten verdeutlichen. Ein skript bestehend aus:

MsgBox("Immer ausführen")
MsgBox("Workstationbezogen")
MsgBox("Userbezogen")

wird wie folgt ausgeführt wenn es nocht nicht installiert ist:

Der Benutzer meldet sich an alos muss der Maschinen und der Benutzerteil installiert werden. Es ist ja noch nichts auf dem Client ausgeführt wurden. Es erscheinen also alle 3 Message-Boxen auf dem Bildschirm des Benutzers.

Nach dieser Installation würde sich Benutzer 2 anmelden:

Der Benutzer meldet sich an, wobei jetzt nur noch der Benutzerteil des neuen Benutzers installiert werden muss. Der Maschinenteil ist ja schon auf dem System. Also erscheinen 2 Message-Box auf dem Desktop des Benutzers (MsgBox("Immer ausführen") und MsgBox("Userbezogen")).

Mit diesem Wissen kann man jetzt mal die Wirkung RegLoad-Befehl erforschen, insbesondere wenn dieser auf "Immer ausführen" steht und sowohl Teile in HKEY_CURRENT_USER als auch HKEY_CURRENT_MACHINE verändert. Fragen dazu dürfen gerne als Kommentar gestellt werden.

enteo v6

Dirk Eisenberg — Sun, 06 Apr 2008 17:41:13 GMT

Ich habe lange überlegt ob ich in diesem Block auch die Produkte meines Arbeitgebers einbeziehen soll und habe mich diese Woche dafür entschieden. Dabei geht es nicht um Werbung für die enteo Produktlinie sondern um interessante Funktionen die dem ein oder anderem Admin das Leben erleichtern werden. Ich werde in unregelmäßigen Abständen interessante Thema aus der enteo Produktfamilie herausgreifen und hoffentlich wertvolle Tips geben. Das ersetzt aber nicht die Schulung, den Support und das enteo Support-Forum.