opsi Version 4.0.5 Release Notes

Die Software von opsi ist in weiten Teilen Open Source.
Nicht Open Source sind die Teile des Quellcodes, welche neue Erweiterungen enthalten die noch unter Kofinanzierung stehen, also noch nicht bezahlt sind.
siehe auch: http://uib.de/de/opsi-erweiterungen/erweiterungen/

Der restliche Quellcode ist veröffentlicht unter der AGPLv3:

Der rechtsverbindliche Text der AGPLv3 Lizenz ist hier:
http://www.gnu.org/licenses/agpl-3.0-standalone.html

Deutsche Infos zur AGPL: http://www.gnu.org/licenses/agpl-3.0.de.html

Für Lizenzen zur Nutzung von opsi im Zusammenhang mit Closed Source Software kontaktieren Sie bitte die uib gmbh.

Die Namen opsi, opsi.org, open pc server integration und das opsi-logo sind eingetragene Marken der uib gmbh.

Kapitel 2. Übersicht der Neuerungen

Das opsi Service Releases 4.0.5 weist eine Fülle von Neuerungen und Detailverbesserungen auf. Hier eine Übersicht:

Ab opsi 4.0.5 werden (ausschließlich) folgende Distributionen als opsi-server unterstützt:
- Ubuntu: 10.04 (Lucid), 12.04 (Precise), 14.04 (Trusty)
- Debian: 6.0 (Squeeze), 7.0 (Wheezy)
- UCS 3.2
- openSUSE 12.3, 13.1
- SLES 11SP3
- RHEL 6.6, 7
- CentOS 6.5, 7

Wichtig

Der opsi-configed ab Version 4.0.5.x benötigt mindestens die Java-Version 1.7.0.

Sollten Sie opsi auf einer Betriebssystemversion einsetzen, welche oben nicht aufgeführt ist, so empfehlen wir Ihnen ein Betriebsystem-Update bevor Sie opsi v4.0.5 einspielen.

opsi Serverkomponenten:
Diverse Verbesserungen und Bugfixes in den Serverpaketen.
Neues opsi-bootimage basierend auf Ubuntu Precise / Kernel 3.15.1 mit Unterstützung für aktuelle Hardware (wie z.B Tablets), UEFI Support und Unterstützung für Linux Festplattenverschlüsselung.
Windows Netboot Produkte
- Treiberintegration per byAudit nun auch nach vendor und model des Motherboards
- Soweit sinnvoll volle UEFI/GPT Kompatibilität
- Neues Property setup_after_install zur Ablauf Automatisierung.
- Unterstützung von HP SmartArray RAID Controllern
opsi-winst / opsi-script (4.11.4.10):
- Logging jetzt nach c:\opsi.org\log\opsi-script.log
- Neue Konstanten:
  - %opsiDepotId% : Depotserver // since 4.11.4
  - %opsiTmpDir% : c:\opsi.org\tmp // since 4.11.4.3
  - %opsiLogDir% : c:\opsi.org\log // since 4.11.4.3
- Neue Funktionen zum Umgang mit key/value Paaren in Konfigurationsdateien:
  - Stringfunktion: getValueFromFile(<key string>, <file name>) //since 4.11.4.4 [W/L]
  - Stringfunktion: getValueFromFileBySeparator(<key string>,<separator string>,<file name>) //since 4.11.4.4 [W/L]
  - PatchTextFile Sektionskommandos:
  - setKeyValueSeparator <separator char> //since 4.11.4.4 [W/L]
  - setValueByKey <keystr> <valuestr> //since 4.11.4.4 [W/L]
- Encoding Funktionen (Handbuch lesen !):
  - string function reencodestr( <str> , <from>, <to> )
  - stringlist function reencodestrlist( <strlist> , <from>, <to> )
- Aktivitätanzeige:
  - Bei winbatch Sektionen mit /timeout wird der Zeitablauf bis zum Timeout über den Fortschrittsbalken angezeigt.
  - Neuer Schalter: AutoActivityDisplay = (true/false) default=false; Wenn true wird ein (marquee) Fortschrittsbalken (der Endlos durch läuft) angezeigt während des Laufs von winbatch/dosbatch Sektionen.
  - Neuer parameter für DosInAnIcon/ShellInAnIcon: /showoutput : Zeigt ein Ausgabefenster mit den Ausgaben der aufgerufenen Kommandos.
- Sonstiges:
  - saveTextFile(<list>, < filename>) //since 4.11.4.4 [W/L]
  - stringlist function shellCall( <cmd> ) ; returns the output of (sysnative) shell with cmd
  - Befehl IncludeLog jetzt mit zusätzlichen encoding Parameter
  - Neue string function: strLoadTextFile ( <filename> )
  - Neue boolsche function: LineContaining_ExistsIn( <string>, <file name> )
Sonstige Produkte:
- Fixes in swaudit
opsi-configed:
- Die (Depot-)Server Defaults der Produktproperties können jetzt über den configed gesetzt werden.
- Umfangreich überarbeitete Version: Siehe gesondertes Kapitel.
opsi Linux Unterstützung:
Siehe gesondertes Kapitel.
opsi uefi (Netboot) Unterstützung:
Siehe gesondertes Kapitel.
Images mit opsi clonezilla:
Siehe gesondertes Kapitel.
opsi Erweiterung opsi-local-image (für Schulungsräume):
Siehe gesondertes Kapitel.
opsi-setup-detector (Automatisierte Erstellung von opsi Paketen):
Siehe gesondertes Kapitel.
opsi-client-agent:
- Fixes für Windows 8.x (Loginblocker)
- property uac_level=0 führt zu keiner Änderung des UAC-Levels des Rechners
  Wir Empfehlen den Property Wert uac_level=0 als Serverdefault einzustellen. Dies kann mit Hilfe des neuen configed einfach getan werden.

Kapitel 3. Known Bugs / Known Problems

KNOWN BUGS:

openSUSE 13.1, CentOS 70:
Aufgrund des geänderten Netzwerkinterface Namensschemas wird die Netzmaske evtl. falsch ausgelesen.
opsi-clonezilla:
Das Handling von Linux Systemen (ext filesystem) funktioniert noch nicht.

KNOWN PROBLEMS:

configed:
Auf XP-Rechnern ist mit hoher Wahrscheinlichkeit die WebStart-Version nicht funktionsfähig, da sie einen Maximalspeicherbedarf von 1000 MB anmeldet, die XP-Rechner, selbst wenn der Speicher vorhanden ist, regelmäßig nicht anbieten. Wir empfehlen das opsi-Localboot-Produkt opsi-configed zu verwenden und die Produkt-Property "memory_requirement" für den Rechner z.B. auf 512 MB herabzusetzen.
opsipxeconfd:
Unter RHEL / CentOS gibt es beim Upgrade nach opsi 4.0.5 Warnungen.
opsi-linux-bootimage:
Durch Änderungen in lshw kann es sein, dass sich die von einem Rechner ausgelesene Modellbezeichnung ändert. Das kann zu unerwartetem Verhalten bei der Treiberintegration führen, falls diese auf dem Modellnamen basiert.

Kapitel 4. Samba 4

Die ersten Distributionen werden nun mit Samba 4 ausgeliefert.

Aktuell werden Ubuntu 14.04 und openSuse 13.1 mit Samba 4 Paketen ausgeliefert. Diese Pakete sind von sich aus nicht dazu geeignet ganze Domänen zu verwalten, haben aber bei den Freigaben das Verhalten von Samba 4.

In Samba 3 war es allgemein erlaubt, jede Datei oder Verzeichnis auf den Clients auszuführen. Dieses Verhalten wurde in Samba 4 komplett verändert. Nun müssen alle Dateien, die über den Share ausführbar sein sollen, auch auf der Unix-Seite das Executable-Bit setzen.

Dies stellt ein allgemeines Problem für den Betrieb von opsi dar. Es ist nicht möglich dieses Verhalten über die Rechteverwaltung von opsi zu umgehen, da dies eine komplette Überarbeitung des Rechtesystems von opsi erfordern würde. Dies ist in opsi 4 nicht möglich.

Um das Problem mit opsi 4.0 dennoch zu umgehen, gibt es zwei Möglichkeiten.

Variante 1: auf den betroffenen Freigaben kann über die Freigabenkonfiguration über die Option: admin users = @pcpatch

für jedes Mitglied der pcpatch-Gruppe (Freigaben-User) dieses Verhalten ausgehebelt werden. Diesen Fix setzt opsi schon seit längerem auch bei UCS >= 3 mit Samba 4 ein. Bei diesem Fix wird der Samba-Prozess der User mit erhöhten Rechten ausgeführt.

opsi setzt automatisch bei Samba 4 Distributionen über opsi-setup --auto-configure-samba diese Option für den opsi_depot Share. Da dieser nur readonly gemounted wird, ist das Sicherheitsrisiko relativ gering.

Variante 2: Man kann global folgende Option in der smb.conf setzen: allow general executable = True

Durch diese Option wird für alle Freigaben das Verhalten von Samba 3 wiederhergestellt.

Sollte es gewünscht sein, dass die anderen Shares von diesem Problem nicht mehr betroffen sind, kann man entweder die erste Variante für jeden Share manuell setzen oder die Option von Variante zwei global in die smb.conf setzen. Die zweite Option gilt dann aber für alle Freigaben, auch für die, die nicht von und für opsi bereitgestellt werden.

Kapitel 5. Abkündigung

In diesem Kapitel werden die Abkündigungen aufgelistet. Diese Distributionsversionen werden aus verschiedenen Gründen nicht mehr weiter von opsi unterstützt.

5.1. Abkündigung: Windows Versionen

Ab opsi v 4.0.5 werden wir die Netbootpakete für Windows Vista und Server 2008 nicht mehr weiter pflegen. Ebenso planen wir für diese Windowsversionen die Unterstützung in den Update Abo’s einzustellen. Wer hierzu Fragen oder Probleme hat möge sich bei uns melden.

Windows XP / Server 2003 ist bekanntermaßen von Microsoft nicht mehr (bzw. Windows 2003 eingeschränkt) unterstützt. Wir werden, wegen der weiten Verbreitung, diese Pakete noch eine Zeitlang pflegen. Trotzdem kündigen wir auch hier an, diese Pflege in absehbarer Zeit einzustellen und empfehlen Ihnen dringend den Wechsel auf eine neuere Windows Version (oder Linux).

5.2. Abkündigung: opsi Produkte

Ab opsi v 4.0.5 werden die opsi Produkte

ntfs-write-image
ntfs-restore-image

nicht mehr unterstützt. Diese Produkte werden in ihrer Funktionalität durch das neue Produkt opsi-clonezilla ersetzt (Siehe gesondertes Kapitel).

5.3. Abkündigung der Python 2.5 Unterstützung

Die nicht mehr mit Updates versorgte Python-Version 2.5 wird nicht mehr unterstützt. Opsi benötigt Python 2.6 oder Python 2.7.

Kapitel 6. Hinweise zur Installation

Wir empfehlen vor der Installation des Updates (sicherheitshalber) mit opsi-backup eine Sicherung Ihres Backends durchzuführen:

opsi-backup create

Die Produkte welche im Rahmen dieses Releases veröffentlicht werden, sind in etlichen Teilen voneinander abhängig. Sie sollten daher nicht versuchen nur Teile zu installieren.

Sie sollten dabei zuerst den Server updaten und danach die opsi-Produkte.

Beim Update eines bestehenden opsi-Servers kann es vorkommen, dass eine neue Version /etc/opsi/opsi.conf eingespielt werden kann und der Paketmanager Ihres Systems Sie fragt, wie vorgegangen werden soll. Falls eine solche Nachfrage kommt und Sie diese Datei nicht geändert haben, so können Sie diese Datei gefahrlos durch die neue Version ersetzen. Falls Sie die Datei geändert haben oder sich unsicher sind, verweigern Sie das Ersetzen bitte.

Wie oben beschrieben könnte ebenso eine neue Version der /etc/opsi/opsi-product-updater.conf für ein Update vorgeschlagen werden. In der neuen Version kann jetzt ein Smtp-Benutzer mit Smtp-Passwort für die Authentifizierung eingetragen werden, falls dies benötigt wird. Zudem wurde der Eintrag für die Exclude-Files entfernt (exclude = ^win* ), was dazu führen wird, dass die Windows-Netbootprodukte von der Aktualisierung nicht mehr ausgeschlossen werden.

Wir empfehlen nach dem Update die Ausführung von ``opsi-setup --set-rights``, um sicher zu stellen, dass die Berechtigungen in den verwendeten Ordnern korrekt sind. Die Ausführung des Befehls kann mehrere Minuten in Anspruch nehmen.

6.1. Hinweise zur Aktualisierung der opsi server vm Version 4.0.4

Beim Aktualisieren des opsi-depotserver Paketes kann es sein, dass Sie die Daten für das SSL-Zertifikat erneut eingeben müssen.

6.2. Hinweise zur Aktualisierung unter RHEL / CentOS

Ab Version 4.0.5 wird python-opsi keine Abhängigkeit mehr auf python-mysql haben, sondern das in den Standard-Repositories befindliche MySQL-python verwenden.

Bei der Aktualisierung von opsi kann es dadurch zu Konflikten kommen. Um das zu vermeiden, entfernen Sie bitte vorher python-mysql:

rpm -e --nodeps python-mysql

6.3. Hinweise zum Aktualisieren von opsi-Paketen

Die Installation erfordert keine besonderen Arbeiten. Sie erfolgt im Rahmen der normalen Updates ihres Servers und der opsi-Produkte.

Sie sollten dabei zuerst den Server updaten. Benutzen Sie dazu die Befehle entsprechend Ihrer Linux-Distribution.

Wir empfehlen in der Datei /etc/opsi/opsi-product-updater.conf in der Sektion [repository_uib] den Eintrag excludes wie folgt zu modifizieren, damit Sie auch Produkte bekommen welche mit win* anfangen::

excludes =

Wenn Sie die opsi-linux Produkte benötigen so hängen Sie an den dirs Eintrag:

dirs = opsi4.0/products/localboot, opsi4.0/products/netboot

den Pfad opsi4.0/products/opsi-linux an.

Wenn Sie die opsi-local-image Produkte benötigen so hängen Sie an den dirs Eintrag den Pfad opsi4.0/products/opsi-local-image an.

Danach die opsi-Produkte. Dies erledigt der opsi-product-updater:

opsi-product-updater -i -vv

Um nur Updates zu installieren:

opsi-product-updater -vv

Sollten Sie eine Multidepot Umgebung haben, so machen Sie zunächst das Upgrade auf Ihrem config-server, bevor Sie die Depots upgraden.

Falls Sie Produkt-IDs mit einer Länge von mehr als 32 Zeichen verwenden wollen und das MySQL-Backend einsetzen, so führen Sie bitte ein Update der Tabellen-Definition auf Ihrem Config-Server mittels opsi-setup durch:

opsi-setup --update-mysql

6.4. Hinweise zum Aktualisieren der Java-Runtime-Umgebung

Das Management-Interface opsi-configed benötigt jetzt eine Java Laufzeitumgebung mindestens in Version 7 bzw., wie die interne Versionszählung lautet, Version 1.7. Auf dem opsi-Server ist Java allerdings nur erforderlich, wenn Sie den opsi-configed tatsächlich auf dem Server ausführen möchten, was im Normalfall heißt, dass der Server auch über eine graphische Benutzungsoberfläche verfügen muss.

In diesem Fall müssen Sie, sofern noch das JDK 6 oder niedriger installiert ist, stattdessen das JDK 7 (oder 8) aktivieren. Für Ubuntu lauten die Befehle

apt-get remove openjdk-6-jre
apt-get remove openjdk-6-jre-lib
apt-get install openjdk-7-jre

Danach sollte

java -version

mindestens Java Version 1.7.0 anzeigen.

Kapitel 7. opsi-configed 4.0.5.

Mit einer Reihe von Maßnahmen haben wir versucht, die "user experience" des opsi-configed zu verbessern. Insbesondere wird das Umschalten zwischen verschiedenen Ansichten beschleunigt, indem Daten nach Möglichkeit vorab geladen und gecacht werden, anstatt dass sie für jede neue Ansicht vom Server angefordert werden.

Für alle Rechner, auf denen der configed laufen soll, ist zu beachten, dass mindestens die Java-Version 1.7.0 vorausgesetzt wird.

7.1. Auswahl der Depot-Server

Bei einem Wechsel auf einen anderen Depot-Server, entfällt die Notwendigkeit einen kompletten Daten-Reaload durchzuführen, d.h. beim Auswählen eines Depots werden seine Daten sofort geladen. Dazu kommen folgende Buttons:

(=+) : Alle Depots mit identischen Produkten werden ausgewählt
(++) : Alle Depots werden ausgewählt (auch mit Strg-a möglich)

Abbildung 7.1. opsi-configed: Auswahl der Depot-Server

7.2. Client-Erreichbarkeit

Der Test auf Client-Erreichbarkeit wurde erweitert, so dass er im Hintergrund ablaufen kann und das Ergebnis jeweils automatisch in der Client-Tabelle anzeigt wird. Das Feature lässt sich in der Anmeldemaske sowie per Aufrufparameter aktivieren. Default ist ein Test-Intervall von 0 min (= ausgeschaltet).

Abbildung 7.2. opsi-configed: Client erreichbar

Abbildung 7.3. opsi-configed: Client nicht erreichbar

7.3. Fehlgeschlagene Aktionen

Aus der Gruppenansicht wurde die “REPORT: FAILED” Gruppe entfernt. Als neue Möglichkeit, fehlerhafte Installationen zu suchen, gibt es unter dem Menüpunkt Auswahl die Punkte Fehlgeschlagene Aktionen bei Produkt… und Fehlgeschlagene Aktionen (heute, seit gestern, …).
Wählt man den ersten Punkt, erhält man eine Liste aller Produkte. Selektiert man ein Produkt, so werden alle Clients markiert, bei denen die Installation dieses Produktes fehlgeschlagen ist.
Wählt man z.B. Fehlgeschlagene Aktionen - heute, werden all die Clients markiert, bei denen heute mindestens ein Produkt fehlgeschlagen ist.

Abbildung 7.4. opsi-configed: Fehlgeschlagene Aktionen

opsi-configed: Fehlgeschlagene Aktionen - heute

7.4. Produkt-Defaultproperties

Um die Defaultwerte der Produkte für einzelne oder mehrere opsi-depots zu ändern, gibt es einen neuen Reiter Produkt-Defaultproperties. Dieser wird erst auswählbar, wenn man zur Depotkonfiguration (zweiter Button oben rechts) wechselt.
In der Haupttabelle werden alle Produkte mit der Produkt-Version und der Package-Version aufgelistet. Wählt man ein Produkt aus, so werden, wie aus der Client-Produktkonfiguration gewohnt, rechts oben die allgemeinen Informationen zum Produkt-Paket angezeigt. Darunter befindet sich die Auflistung aller Depots, die das ausgewählte Produkt besitzen. Die unterhalb befindliche Tabelle mit den Property-Schlüsseln und Werten ist ebenfalls bekannt aus der Client-Produktkonfiguration.

Abbildung 7.5. opsi-configed: Produkt-Defaultproperties

opsi-configed: Produkt-Defaultproperties: jEdit

Man kann ein oder mehrere Depots auswählen, um die Defaultwerte (d.h. die Depotwerte) des Produktes zu ändern. Als Voreinstellung werden alle verfügbaren Depots ausgewählt. Mit den üblichen Tastenkombinationen (Strg-a, Strg-Klick oder Shift-Klick) lassen sich mehrere bzw. alle Clients markieren.
Ist der Property-Wert ausgegraut (siehe Abbildung 7.5, „opsi-configed: Produkt-Defaultproperties“ - “gui_language”), so sind auf den ausgewählten Depots verschiedene Werte für diese Property gesetzt. Rechts neben den Depots befinden sich drei Buttons:

(=+): Markiere alle Depots mit identischen Werten
Alle Depots, die die gleichen Default-Werte haben, werden markiert.
(++): Alle Depots werden markiert.
(Weltkugel): Setze die Paket-Default-Werte
Die Original-Paket-Werte des Produkts werden für das/die ausgewählte/n Depot/s gesetzt.

Kapitel 8. opsi-linux-bootimage

Das opsi-linux-bootimage wurde komplett überarbeitet. Zunächst wurde das Bootimage auf Ubuntu 12.04 aktualisiert. Dieser Schritt war nötig, da viele Funktionen, die für die neuen Module von opsi benötigt werden, nicht mehr in Ubuntu 10.04 zur Verfügung stehen.

Somit wurden alle Teile des Bootimage auf einen neuen Stand aktualisiert.

8.1. Fallback für byAudit

opsi hat seit längerem das Feature, die Additional-Treiber-Zuweisung automatisiert über die Hardwareinventarisierung durch zu führen. Dieses Feature setzt aber voraus, dass die eingesetzte Hardware sauber vom Hersteller "branded" wurden. Bei größeren OEMs wie Dell, HP oder Fujitsu Siemens, ist das in der Regel auch der Fall.

Es kommt allerdings mittlerweile sehr oft vor, dass ganze Chargen von Hardware über kleinere Lieferanten beschafft werden. Diese haben mit dem Branding der Geräte ein Problem. Bei diesen Clients ist es sehr oft so, dass sie von der Hardware her identisch sind. Wenn man allerdings den Hersteller und das Modell des Geräts ausliest, sind diese Felder meistens leer.

In einem solchen Fall gibt es mit opsi 4.0.5 einen Fallback. Dieser wurde über das Mainboard realisiert. Dies funktioniert vergleichsweise identisch mit der eigentlichen byAudit-Treiberzuweisung, nur dass statt Hersteller und Model vom Gerät, dasselbe Verfahren mit dem Hersteller und dem Namen des Boards angewendet wird.

Kapitel 9. opsi Linux Support

9.1. Vorbedingungen für den opsi Linux Support

Technische Voraussetzungen sind opsi 4.0.5 mit den Paketständen:

Tabelle 9.1. Benötigte Pakete

opsi-Paket	Version
opsi-linux-bootimage	>= 20140805-1

Der opsi Support für Linux besteht aus einem Teil der von Anfang an Opensource ist (den Netbootprodukten) und einem kofinanzierten Teil (dem client-agenten).

Dieser opsi-linux-client-agent ist eine kofinanzierte opsi Erweiterung.
Das bedeutet, das Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an info@uib.de).
Weitere Details zum Umgang mit Modulen finden Sie im opsi manual.

9.2. Einführung

Ein Management-Werkzeug für Windows und Linux

Ziel der Erweiterung von opsi um die Unterstützung von Linux-Systemen ist die Schaffung eines Managementsystems für heterogene Umgebungen. Der Fokus liegt dabei auf der möglichst vollständigen Integration beider Welten in die gleichen Management Vorgänge und Werkzeuge.

Dies bedeutet, eine Linux-Installation wird auf die gleiche Weise angestoßen wie eine Windows-Installation. Der opsi-client-agent unter Linux basiert auf dem selben Code wie der unter Windows und ist (soweit sinnvoll) befehlskompatibel.

Linux distributionsübergreifend

Der Linux Support von opsi ist distributionsübergreifend angelegt.
Die Distributionen:

Debian
Ubuntu
OpenSuse / SLES (Suse Linux Enterprise Server)
Fedora / RHEL (RedHat Enterprise Linux)
CentOS

werden gleichwertig unterstützt.

9.3. Linux Netboot Produkte

Basis-Installation des OS per Netboot

Für die Installation eines Linux Basissystems wird zunächst per Netboot das Standard opsi-linux-bootimage gebootet (welches auch für die Windows-Installationen zum Einsatz kommt).
Von diesem Bootimage aus wird die Zielplatte partitioniert (/ und swap) und formatiert. Nun folgt die Installation des Grundsystems (mit Netz und ssh aber ohne X11). Die Abläufe dieser Grundinstallation unterscheiden sich naturgemäß zwischen den unterschiedlichen Distributionen erheblich. Gemeinsam ist, dass die Installation direkt aus den Originalpaketen der Distribution erfolgt.

Auf diese Basisinstallation können optional die opsi-Pakete installiert werden, um aus dem System einen opsi-Server (z.B. neuen Depotserver) zu machen.
Ebenfalls optional kann nun der opsi-client-agent für Linux installiert werden. Dieser ist dann für die Installation und Konfiguration weiterer Software zuständig.

Die opsi Netboot Produkte zur Linuxinstallation sind bereits als Open Source freigegeben.

Bedingt dadurch, dass die Basisinstallation aus dem Standard opsi-linux-bootimage erfolgt, gibt es distributionsabhängig unterschiedlich bestimmte Dinge, welche sich erst in der Umgebung nach dem ersten Boot des Systems konfigurieren bzw. installieren lassen. Beispiele hierfür sind die se-linux Installation bei den RedHat artigen bzw. die Konfiguration der Tastatur bei den Debian artigen. Hierfür gibt es ein Standard Localbootprodukt l-os-postinst welches diese Aufgaben übernimmt.

9.3.1. Allgemeine Properties der Linux Netboot Produkte

Die folgenden Properties finden Sie zur Steuerung der Linuxinstallation in allen Netbootprodukten:

askbeforeinst:
Soll das Starten der Installation am Client bestätigt werden müssen? (Default=true)
architecture:
Architektur Auswahl, beeinflusst die Auswahl des bootimages und die Installationsarchitektur. (Default=64bit)
system_partition_size:
Größe der Systempartition. Die Größe kann in Prozent der Festplattengröße oder als absoluter Wert (G=Gigabyte) angegeben werden. Wenn Sie einen kleineren Wert als 100% angeben, wird der verbleibende Rest als Datenpartition verwendet (wenn das Property data_partion_create = true). (Default=100%)
swap_partition_size:
Größe der Swappartition. (Default=2000M)
data_partition_create:
Verwende freien Plattenplatz zur Erstellung einer Datenpartition. (true/false). (Default=true)
data_partition_preserve:
Soll eine existierende Datenpartition erhalten werden ?
always = Installation abbrechen wenn der Erhalt einer gefundenen Partition mit dem Label data mit den angegebenen Partitionierungsdaten nicht möglich ist.
if_possible = Wird eine Partition mit dem Label data gefunden und der Erhalt dieser Partition ist gemäß der angegebenen Partionierungsdaten nicht möglich so wird die Partition gelöscht.
never = Die gesamte Partitionstabelle wird immer neu geschrieben. (Default=never)
language:
Welche Sprache / locale soll installiert werden. (Default=de)
console_keymap:
Zu installierendes Tastaturlayout. (Default=Distributionsabhängig / de)
timezone:
Welche Zeitzone soll verwendet werden?. (Default=Europe/Berlin)
root_password:
Passwort für root. (Default=linux123)
user_password:
Passwort für user. (Default=linux123)
install_opsi_server:
Installiere die opsi-server Pakete. (Default=false)
online_repository:
Repository der Distribution für die Installation. (Nicht bei SLES) (Default=Distributionsabhängig)
opsi_online_repository:
Repository der opsi-server Pakete. (Default=Distributionsabhängig)
proxy:
Proxystring (wenn benötigt) in der Form: http://<ip>:<port>. (Default='')
additional_packages:
Welche zusätzlichen Pakete sollen installiert werden? Angabe der Pakete Leerzeichen separiert. (Default='')
wget_and_execute:
Url (http) einer Datei welche am Ende der Installation geholt und ausgeführt wird. (Default='')
install_opsi-client-agent:
Installiere den Linux opsi-client-agent (Kofinanzierungsprojekt: Sie benötigen eine Aktivierung durch die /etc/opsi/modules) . (Default=false)
release:
(nur Debian und Ubuntu)
Welches Release der Distribution soll installiert werden. (Default=Distributionsabhängig)
setup_after_install:
Welche opsi Produkte sollen zum Abschluss der Betriebssysteminstallation auf setup gestellt werden. (Default=l-os-postinst)

9.3.2. Die einzelnen Netboot Produkte

Ubuntu

Die Basis Installation erfolgt per debootstrap direkt aus dem Netz.

Das Produkt hat produktiven Status.

Das Produkt ist UEFI/GPT kompatibel (getestet für release=trusty).

Es gibt für diese Produkt passende opsi-server Pakete welche über install_opsi_server=true installiert werden können.

Debian

Die Basis Installation erfolgt per debootstrap direkt aus dem Netz.

Das Produkt hat produktiven Status.

Das Produkt ist UEFI/GPT kompatibel (getestet für release=wheezy).

Es gibt für diese Produkt passende opsi-server Pakete welche über install_opsi_server=true installiert werden können.

OpenSuse

Die Basis Installation erfolgt unter Verwendung von dem Produkt beiliegenden RPM Dateien. Von daher gibt es für jedes Release ein eigenes Produkt.

OpenSuse 12.3. Das Produkt hat produktiven Status.

Das Produkt ist nicht UEFI kompatibel.

Beachten Sie, das es für neue Releases evtl. noch keine opsi-server Pakete gibt und damit die Propertyeinstellung install_opsi_server=true zu Fehlern führen kann.

OpenSuse 13.1. Das Produkt hat produktiven Status.

Das Produkt ist nicht UEFI kompatibel .

Es gibt für diese Produkt passende opsi-server Pakete welche über install_opsi_server=true installiert werden können.

Known Bugs: Bei bestimmter Hardware (z.B. VMWare ESXi) scheiter die korrekte Vorhersage des Netzwerkinterface Namens und das Netzwerkinterface bleibt unkonfigiriert.

SLES

Die Basis Installation erfolgt unter Verwendung von dem Produkt beiliegenden RPM Dateien. Von daher gibt es für jedes Release ein eigenes Produkt.

Da das Produkt RPM’s enthält welche nicht Opensource sind, können wir es leider nicht frei zum Download anbieten. Wir können es aber unseren Kunden kostenlos zur Verfügung stellen ( → mail an info@uib.de).

Das Produkt hat produktiven Status.

Beachten Sie, das es für neue Releases evtl. noch keine opsi-server Pakete gibt und damit die Propertyeinstellung install_opsi_server=true zu Fehlern führen kann.

Das Produkt ist nicht UEFI kompatibel.

Das Produkt kennt folgende zusätzlichen Properties:

use_gpt
Wenn true wird die Festplatte (auch im MBR-BIOS Mode) mit GPT partitioniert. Hierfür wird dann auch eine Bootpartition benötigt. Wenn das Property boot_partition_size auf 0 steht wird automatisert trotzdem eine Bootpartition mit der Größe 1 GB erzeugt.
boot_partition_size
Größe der Bootpartition. Wenn 0 wird keine Bootpartition erzeugt.
kernel_modules
Leerzeichen getrennte Liste der zusätzlich zu ladenden Kernelmodule (z.B. für spezielle Festplatten Controller).
suse_register
Wenn true wird der Server online registriert. Hierzu wird die email Adresse und der Key der Registrierung in der Form email:productkey benötigt. Dieser wird abhängig von dem Hostparameter license-management.use aus dem Lizenzmanagement oder aus dem Property productkey geholt.
Wenn false muss im Property local_repositories mindestens ein geeigneter Repositoryserver angegeben werden.
productkey
email Adresse und der Key der Registrierung in der Form email:productkey (falls nicht das Lizenzmanagement verwendet wird).
local_repositories
Leerzeichen getrennte Liste von Repositories welche per zypper eingebunden werden in der Form: "http://myserver.local Description"

Das Property online_repository entfällt.

CentOS

Die Basis Installation erfolgt unter Verwendung von dem Produkt beiliegenden RPM Dateien. Von daher gibt es für jedes Release ein eigenes Produkt.

CentOS 6.5. Das Produkt ist noch in Entwicklung. Bekannte Probleme sind: die Lokalisierung.

Es gibt für diese Produkt passende opsi-server Pakete welche über install_opsi_server=true installiert werden können.

Das Produkt ist nicht UEFI kompatibel.

CentOS 7. Das Produkt ist noch nicht verfügbar.

Fedora

Die Basis Installation erfolgt unter Verwendung von dem Produkt beiliegenden RPMs. Von daher gibt es für jedes Release ein eigenes Produkt.

Fedora 20. Das Produkt hat testing Status.

Beachten Sie, das es für neue Releases evtl. noch keine opsi-server Pakete gibt und damit die Propertyeinstellung install_opsi_server=true zu Fehlern führen kann.

Das Produkt ist nicht UEFI kompatibel .

RHEL

Das produkt ist noch nicht verfügbar.

9.4. opsi-linux-client-agent

Der opsi-client-agent für Linux ist Bestandteil des Kofinanzierungsprojektes Linux Agent und derzeit kostenpflichtig.

Der opsi-client-agent für Windows besteht im Kern aus zwei Komponenten:

dem Service opsiclientd
dem Actionprocessor opsi-winst / opsi-script

Der opsi-client-agent für Linux basiert auf einer Portierung des Windows Clientagenten nach Linux.

Der opsiclientd ist im ersten Release noch nicht fertig portiert und ist deshalb zunächst durch das Programm opsiscriptstarter ersetzt, welcher die Aufgaben des opsiclientd beim Systemstart übernimmt:

Kontakt mit dem opsi-Server: Prüfen ob Aktionen gesetzt sind
Mounten des Depot Shares
Starten des Actionprocessors
Unmount des Depot Shares
Senden der Logdatei an den Server

Der Actionprocessor heißt unter Linux opsi-script und ist aus den selben Quellen gebaut wie der opsi-winst unter Windows. Damit steht unter Linux die gleiche Scriptsyntax zur Verfügung wie unter Windows. Weiterhin sind alle nicht plattformspezifischen Funktionen umgesetzt wie z.B:

File handling
String und Stringlisten Funktionen
Ausführen von externen Scripten und Programmen
Kommunikation mit dem opsi-Server
Patchen von Konfigurationsdateien

Natürlich gibt es unter Linux keine Funktionen zum Patchen der Registry, dafür aber neue linuxspezifische Funktionen wie z.B.:

getLinuxDistroType
getLinuxVersionMap

Das Logging des opsi-script ist analog zur dem des opsi-winst unter Windows.

Anders als bei Windows gibt es den opsi-script neben einer grafischen Version für die Arbeit unter X-Windows zusätzlich in einer noGUI Version für Systeme ohne grafische Oberfläche.

9.5. opsi-linux-client-agent: Pfade

Wie sich das gehört verteilt sich der linux-opsi-client-agent weitläufig:

Die Binaries:

/usr/bin/opsi-script (X11)

/usr/bin/opsi-script-nogui (ohne X11)

/usr/bin/opsiscriptstarter (vorläufiger opsiclientd Ersatz)

Die Hilfsdateien:

usr/bin/winstskin/

Die Konfigurationen:

/etc/opsi-client-agent/opsiclientd.conf (Konfiguration des opsiscriptstarter/opsiclientd)

/etc/opsi-client-agent/opsi-script.conf (in Vorbereitung)

Die Logs / Temps:

/var/log/opsi-client-agent

9.6. opsi-linux-client-agent: Known Bugs

Das kopieren von vielen Dateien von einem smb-share ist abhängig von der Samba Version fehlerhaft. Es werden nicht alle Dateien kopiert.

Workaround: Statt:

[Files_copy_netboot]
copy -s "%scriptPath%/installfiles/*" "$target$/installfiles/"

verwenden:

[ShellInAnIcon_opsi_copy_netboot]
set -x
export PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/sbin:/usr/sbin:/sbin
cd "%scriptPath%"
tar cf - installfiles | ( cd "$target$/installfiles/" ; tar xf - )

9.6.1. Beispiel Scriptteile

Unter Windows gilt für die Softwareverteilung: Die Installation von Software ist genauso wichtig wie die anschließende Konfiguration der Software.
Unter Linux stehen die meisten Pakete über die Repositories der Distribution zur Verfügung. Dadurch wird der Installationsanteil kleiner, der Konfigurationsanteil aber bleibt. Weiterhin gibt es auch Applikationen, welche nicht über die Standardrepositories verfügbar sind. Hier müssen unter Umständen zunächst weitere Repositories dem System hinzugefügt werden bzw. Installationsquellen dem Paket zugefügt werden. Wichtig ist, dass alle Installations- und Konfigurationsarbeiten zentral vom opsi-Server gesteuert und dort auch geloggt werden.

Im folgenden Beispiele für folgende Aufgaben in einem beispielhaften Script für den opsi-linux-client-agent:

Beenden wenn es nicht unter Linux läuft
Feststellen des Distributionstyps zur Entscheidung zwischen apt-get, zypper und yum
Feststellen der genauen Linux Version
Installation eines Paketes
Hinzufügen eines Repositories

Beispiel: Beenden wenn es nicht unter Linux läuft:

[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off

DefVar $OS$

set $OS$ = GetOS

if not($OS$ = "Linux")
        LogError "Wrong OS: Product: " + $ProductId$ + "is only for Linux"
        isFatalError "Wrong OS"
endif

Beispiel: Feststellen des Distributionstyps:

[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off

DefVar $distrotype$

set $distrotype$ = getLinuxDistroType

if $distrotype$ = 'debian'
        ShellInAnIcon_Upgrade_deb
else
        LogError "Wrong Distro: This Product is for Debian/Ubuntu only"
        isFatalError "Wrong distro"
endif

if not("0" = getLastExitCode)
        Message "failed ShellInAnIcon_Upgrade"
        LogError "failed ShellInAnIcon_Upgrade"
        isFatalError "failed Upgrade"
endif


[ShellInAnIcon_Upgrade_deb]
set -x
export DEBIAN_FRONTEND=noninteractive
apt-get --yes install aptitude
apt-get update
apt-get --yes dist-upgrade
exit $?

Beispiel: Feststellen der genauen Linux Version und Installation eines Paketes:

[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off

DefVar $distCodeName$
DefVar $distroName$
DefVar $distRelease$
DefVar $desktop$

DefStringList $linuxInfo$

set $linuxInfo$ = getLinuxVersionMap
set $distCodeName$ = getValue("Codename", $linuxInfo$)
set $distRelease$ = getValue("Release", $linuxInfo$)
set $distroName$  = getValue("Distributor ID", $linuxInfo$)

set $desktop$ = GetProductProperty("desktop", "kde")


if $distrotype$ = 'suse'
        if $desktop$ = "unity"
                Message " No Unity on SUSE - fallback to KDE ..."
                set $desktop$ = "kde"
        endif ; unity


        if $desktop$ = "kde"
                if ($distroName$ = 'openSUSE project')
                        ShellInAnIcon_kde_suse
                endif
                if ("SUSE LINUX" = $distroName$) and ($distRelease$ = "11")
                        ShellInAnIcon_kde_sles11
                endif
                if not("0" = getLastExitCode)
                        LogError "failed ShellInAnIcon"
                        Message "failed kde"
                        isFatalError "failed kde"
                endif
        endif ; kde
endif; suse type

[ShellInAnIcon_kde_suse]
set -x
zypper --no-gpg-checks --non-interactive install patterns-openSUSE-kde4 patterns-openSUSE-kde4_basis
zypper --no-gpg-checks --non-interactive install splashy-branding-openSUSE
exit $?

[ShellInAnIcon_kde_sles11]
set -x
zypper --no-gpg-checks --non-interactive install --auto-agree-with-licenses -t pattern kde
exit $?

Beispiel: Hinzufügen eines Repositories:

[Actions]
requiredWinstVersion >= "4.11.4.1"
ScriptErrorMessages=off

DefVar $distCodeName$
DefVar $distroName$
DefVar $distRelease$
DefVar $desktop$

DefStringList $linuxInfo$

set $linuxInfo$ = getLinuxVersionMap
set $distCodeName$ = getValue("Codename", $linuxInfo$)
set $distRelease$ = getValue("Release", $linuxInfo$)
set $distroName$  = getValue("Distributor ID", $linuxInfo$)

set $desktop$ = GetProductProperty("desktop", "kde")


if $distroName$ = 'Ubuntu'

        if $desktop$ = "cinnamon"
                set $desktopPackage$ = $desktop$
                ShellInAnIcon_ubuntu_cinnamon
                if not("0" = getLastExitCode)
                        Message "failed ShellInAnIcon_ubuntu_cinnamon"
                        LogError "failed ShellInAnIcon_ubuntu_cinnamon"
                        isFatalError "failed cinnamon"
                endif
        endif ; cinnamon
endif; ubuntu

[ShellInAnIcon_ubuntu_cinnamon]
set -x
export DEBIAN_FRONTEND=noninteractive
# we need to get the add-apt-repository command
apt-get --yes --force-yes install python-software-properties
# the cinnamon repository
add-apt-repository ppa:gwendal-lebihan-dev/cinnamon-stable
apt-get update
apt-get --yes install ubuntu-desktop
exit $?

9.7. Linux Localboot Produkte

Hier einige Lokalbootprodukte welche zum Standardumfang des opsi Linuxsupports gehören.

9.7.1. l-os-postinst

Dieses Produkt übernimmt jene Teile der Basisinstallation welche sich vom bootimage nicht korrekt ausführen lassen.

Dies ist für die unterschiedlichen Distributionen:

Fedora / CentOS:
- Installation von se-linux
Fedora:
- Installation von se-linux

Das Produkt hat eine Abhängigkeit zu dem Produkt l-system-update welches vor dem Lauf von l-os-postinst aufgerufen wird.
Das Produkt hat eine hohe Priorität, d.h. es wird vor normalen Produkten ausgeführt.

9.7.2. l-desktop

Das Produkt l-desktop installiert ein Desktop Paket auf dem Rechner.

Über das Property desktop kann der zu installierende Desktop ausgewählt werden. Dabei ist zu beachten, das nicht alle Desktops auf allen Distributionen verfügbar sind. So gibt es z.B. Unity nur unter Ubuntu. Wird ein nicht verfügbarer Desktop gewählt so wird ein Distributionsspezifischer Defaultdesktop installiert. Weiterhin haben die Desktop Pakete einen unterschiedlichen Umfang welcher abhängig von Distribution und Desktop sich auf die eigentliche Desktop Software beschränken kann oder auch Basisprodukte wie libreoffice, firefox, PDF-Reader usw. enthalten kann.

Das Property desktop hat folgende Werte:

Gnome
Default für Debian, Fedora, CentOS, RHEL
Verfügbar auf allen Distributionen.
KDE
Default für SLES, OpenSuse Verfügbar auf allen Distributionen.
Unity
verfügbar nur für Ubuntu
Cinnamon
verfügbar nur für Ubuntu
xfce4
Verfügbar auf Ubuntu, Debian, Fedora.
lxde
Verfügbar auf Ubuntu, Debian.

9.7.3. l-system-update

Dieses Produkt aktualisiert das System.

9.7.4. l-swaudit

Softwareinventarisierung auf Basis des Paketmanagers

9.7.5. l-hwaudit

Hardwareinventarisierung.
Die Hardwareinventarisierung basiert zur Zeit auf der in Python implementierten Methode wie sie auch vom bootimage verwendet wird. Dazu muß das Paket python-opsi aus dem opsi-Repository der Distribution installiert werden. Ist für die Distribution kein opsi-Repository verfügbar, so scheitert auch die Hardwareinventarisierung.

9.7.6. l-jedit

Java basierter Editor mit Syntaxhighlighting für opsi-script. Ist noch kein Java installiert, so wird dies automatisch durchgeführt.

9.8. Inventarisierung

Zur Inventarisierung werden die Daten durch den Clientagenten erhoben und an den Server gesendet. Die Hardwareinventarisierung basiert auf den schon im Bootimage implementierten Methoden.

Die Softwareinventarisierung basiert auf den Daten des Paketmanagements der verwendeten Distribution.

9.9. UEFI / GPT Unterstützung

Ab opsi v 4.0.5 sind eine zunehmende Anzahl von Linuxprodukten auch UEFI/GPT kompatibel. Details siehe hierzu in der obigen Auflistung der Netbootprodukte.

9.10. Roadmap

Die Linux Unterstützung von opsi ist neu. Das bedeutet auch, dass wir im ersten Release noch nicht alle Features verwirklicht haben.
Weitere Features werden folgen wie:

Portierung des opsiclientd nach Linux
Frei konfigurierbare Partitionierung
Logical Volume Management
Patchen von XML- und JSON-Dateien
Patchen von hierarchischen Konfigurationsdateien wie dhcpd.conf

9.11. Proxy für deb Pakete einrichten und verwenden

Eine brauchbare Anleitung zur Erstellung eines eigenen Ubuntu Proxy finden Sie hier:

http://wiki.ubuntuusers.de/Lokale_Paketquellen/Apt-Cacher-ng

http://www.gambaru.de/blog/2011/10/26/apt-cacher-ng-ein-proxy-server-fur-debian-und-ubuntu/

Kapitel 10. opsi mit UEFI / GPT

10.1. Vorbedingungen für das Arbeiten mit UEFI / GPT

Dieses Modul ist momentan eine kofinanzierte opsi Erweiterung.
Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen zu können. Das bedeutet, das Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an info@uib.de).

Technische Voraussetzungen sind opsi 4.0.5 mit den Paketständen:

Tabelle 10.1. Benötigte Pakete

opsi-Paket	Version
Netbootprodukte	>=4.0.5
opsi Server Pakete	>=4.0.5

10.2. Einführung

Neue PC’s, Tablets und Server enthalten meist ein UEFI BIOS. Häufig kann dieses in einen Legacy Mode umgestellt werden, um das bisherige Verhalten und die Unterstützung eines PXE Boots zu bekommen. Es tauchen aber auch zunehmend Geräte mit UEFI-only BIOS auf (besonders bei den Tablets). Diese lassen sich in einer bisherigen opsi Umgebung nicht per netboot verwalten.

Um auch diese Geräte in opsi integrieren bzw. die Vorteile von UEFI nutzen zu können, entwickelt die uib gmbh die opsi Erweiterung UEFI Support.

10.3. Was ist Uefi und was ist hier anders ?

UEFI steht für Unified Extensible Firmware Interface und ist der Nachfolger des klassischen PC-BIOS (auch MBR-BIOS genannt).

Für Detailierte Informationen zum Thema UEFI finden sich unten einige Links.

UEFI ist ungleich mächtiger als das herkömmliche BIOS. Im Prinzip ist UEFI ein eigenes kleines Mini-Betriebssystem. Hier sollen aber nur Punkte erwähnt werden, welche für den Systemverwalter von besonderer Bedeutung sind:

Die derzeitige (Stand Januar 2014) Umsetzung von UEFI in den BIOSen der Hardware Hersteller ist weit von dem Entfernt was man einen Standard nennen könnte. Vielmehr herrscht ein großes durcheinander wenn von einem anderen Medium geboot werden soll wie der Festplatte. UEFI und klassisches BIOS existieren teilweise Parallel, lassen sich mal einzeln deaktivieren mal nicht. UEFI ist mal mit Compatibility Support Module (CSM) implementiert mal ohne. Netboot geht oder auch nicht.
Gerade der letzte Punkt (Netboot) ist natürlich für ein strukturiertes Client Management von großer Bedeutung.
Im PC-BIOS ist das BIOS und dessen Einstellungen vom OS (in aller Regel) getrennt. D.h. BIOS Einstellungen wie z.B. die Bootreihenfolge sind statisch und können vom Betriebssystem nicht geändert werden.
Dies ist bei UEFI anders. Das Betriebssystem kann die Bootreihenfolge ändern (und macht davon in der Regel auch Gebrauch). Auch dies hat wiederum Auswirkungen auf die Anbindung der Rechner an das Clientmanagement durch den Netboot.
Das UEFI-Bios enthält einen eigenen Bootmanager der nicht nur (siehe oben) in seiner Reihenfolge durch das Betriebsystem veränderbar ist, sondern auch die Starteinträge der Betriebssysteme selbst enthält. Damit wird ein nebeneinander von Unterschiedlichen Betriebssystemen vereinfacht weil die Bootloader unterschiedlicher Betriebssysteme sich nicht mehr überschreiben.
Das UEFI BIOS ist in 32 oder 64 Bit implementiert. Damit ist dann auch die Bitigkeit des Betriebssystems vorgegeben. D.h. kein 32 Bit OS auf einem 64 Bit UEFI System.
Secureboot (von opsi noch nicht unterstützt)
Partitionierung mit GPT und zusätzliche Partitionen für die Bootloader:
- 1. Partition: EFI System Partition (ESP) 100 - 260 MByte ; VFAT
- 2. Partition: Microsoft Reserved (MSR) 32 - 128 MB; NTFS
- Ab hier kommen jetzt die eigentlichen OS Partitionen

Links :

http://de.wikipedia.org/wiki/Unified_Extensible_Firmware_Interface

10.4. Was ist anders an GPT

GPT (GUID Partition Table) ersetzen die bisherigen MBR Partitionstabellen. GPT ist Bestandteil der UEFI Spezifikation.

Wesentliche Merkmale für den Sysadmin sind:

Wegfall der 2 Terabyte Grenze (jetzt 8 Zebibyte)
Beliebig viele primäre Partitionen
Geänderte Partitionstypen / GUIDs
Neu: Partitions-GUIDs
Neu: Partitions-Attribute (Hidden, Read only, …)
Andere Werkzeuge zur Bearbeitung: gdisk

Prinzipiell lässt sich GPT auch ohne UEFI verwenden. UEFI funktioniert aber nur mit GPT. Wird UEFI verwendet, so kommen ein bis zwei zusätzliche Partitionen hinzu:

Die EFI System Partition (ESP) - hier liegen die Bootloader
MS Reserved (MSR)

Links :

http://de.wikipedia.org/wiki/GUID_Partition_Table

10.5. UEFI Boot

Im Gegensatz zu herkömmlichen BIOSen kann hier die Bootreihenfolge nicht nur für Geräte, sondern auch für unterschiedliche Bootloader auf der EFI System Partition eingetragen werden. Darüberhinaus ist diese Reihenfolge auch von einem laufenden Betriebssystem manipulierbar. Wenn Sie also den Netboot als oberste Priorität festlegen, so wird dies die erste OS-Installation nicht überleben.

10.6. UEFI Netboot

Leider unterstützen viele frühe UEFI BIOSe noch kein Netboot, aber die Unterstützung wird zunehmend besser.

Es gibt inzwischen schon eine ganze Reihe von UEFI Bootloadern (wie z.B. grub2, elilo), leider unterstützen die wenigsten davon einen Netboot.

Die uib gmbh stellt mit der opsi-Erweiterung UEFI Support eine funktionierende Unterstützung für die Anbindung eines Clients über einen UEFI-Netboot an opsi vor. Gleichzeitig erwarten wir, dass im Rahmen der technischen Weiterentwicklung diese opsi-Erweiterung in den nächsten Jahren noch deutlich umgebaut werden wird.

10.7. Opsi Unterstützung für UEFI Netboot

Die opsi Unterstützung für UEFI ist im Rahmen einer Reihe von Teilkomponenten umgesetzt:

Anpassung des netbootfähigen UEFI Bootloaders ELILO an die opsi / Client-Management Bedürfnisse.
Neuer opsipxeconfd, welcher neben Konfigurationsdateien für das bisherige PXE nun auch Konfigurationsdateien für den opsi-ELILO bereitstellt.
Bereitstellung neuer (64Bit) opsi-linux-bootimages mit den Werkzeugen für UEFI- und GPT-Management
Umbau aller Netbootprodukte zur Betriebssysteminstallation (Windows/Linux) auf die zusätzliche Unterstützung von UEFI/GPT. Hiervon sind natürlich jene Betriebssysteme ausgenommen welche von sich aus keine UEFI Unterstüztung haben.
Speicherung der Einstellung ob ein Client als UEFI Client behandelt werden soll auf dem opsi-server (clientconfig.dhcpd.filename=linux/pxelinux.cfg/elilo.efi)
Unterstützung einer Software gesteuerten Umschaltung auf UEFI-Netboot.
Soweit das BIOS dies ermöglicht (es also einen aktivierbaren Netbooteintrag im Bios gibt) wird das Label des UEFI-Netboot Eintrages des Bios auf dem opsi-server gespeichert (clientconfig.uefinetbootlabel). Dies ermöglicht es opsi-produkten gezielt für den nächsten boot das Bios auf Netboot umzustellen. Diese Technik ist in verschiedenen opsi-Produkten implementiert. Ein wichtiges Beispiel ist das Produkt opsi-uefi-netboot:
Dieses Produkt versucht das Bios auf netboot umzustellen und dann einen reboot auszulösen. Wird kein gespeichertes uefinetbootlabel gefunden oder handelt es sich nicht um einen UEFI Rechner wird nur ein reboot ausgelöst.
Diese Produkt funktioniert sowohl unter Windows wie auch unter Linux.

10.8. Installation

Alle notwendigen Pakete sind ab der opsi Version 4.0.5 automatisch installiert.

10.9. Konfiguration des DHCP Servers

Beispiel aus einer Konfiguration eines Linux isc-dhcp-server:

filename "linux/pxelinux.0";

# Das ist die UEFI Detection:
if substring (option vendor-class-identifier , 19,1 ) = "0" {
        log (info, "pxe client");
        filename "linux/pxelinux.0";
}
else if substring (option vendor-class-identifier , 19,1 ) = "6" {
        log (info, "efi32 client");
        filename "linux/pxelinux.cfg/elilo32.efi";
}
else if substring (option vendor-class-identifier , 19,1 ) = "7" {
        log (info, "efi64 client");
        filename "linux/pxelinux.cfg/elilo.efi";
}
else {
        log (info, concat ( "Unhandled vendor class Arch: ", substring (option vendor-class-identifier , 19,1 )));
}

http://docs.fedoraproject.org/en-US/Fedora/17/html/Installation_Guide/s1-netboot-pxe-config.html

10.10. Kriterien für ein gutes BIOS

Ob ein UEFI BIOS für die Anforderungen eines Client-Management-Systems wie opsi geeignet ist, hängt von verschiedenen Kriterien ab. Diese Kriterien sagen nichts über die Qualität des Gerätes als solches aus, sondern nur über seine Wartbarkeit per Netboot-Anbindung. Es geht hier also um die BIOS-Funktionen zum UEFI Netboot. Hier ein beispielhafter Vergleich :

Tabelle 10.2. Beispiele für UEFI BIOS Unterschiede

	Lenovo Twist	MS-Surface	Dell Venue 11
UEFI pur	√	√	√
UEFI + CSM	√	x	√
Legacy	√	x	√
Both	√	x	x
UEFI Netboot	√	√	√
Aktivierbarer Eintrag	√	x	√
Netboot ohne Interaktion	√	x	√

Unter Aktivierbarer Eintrag verstehen wir, das sich per Standard-Software ein Netboot für den nächsten Reboot aktivieren läßt. Netboot ohne Interaktion bedeutet, dass ein aktivierter Netboot-Eintrag beim Reboot ausgeführt wird und dazu keine Interaktion (drücken von Tastenkombinationen, F12-Taste, …) nötig sind. Sind diese Vorausetzungen gegeben, können bestimmte opsi Produkte einen Netboot auslösen. Dies ist für die automatisierung von Abläufen von großer Bedeutung. Ein Produkt in dem dies implementiert ist ist das Localbootprodukt für Windows und Linux opsi-uefi-netboot.

10.11. Technisches

Die folgenden Unterkapitel dienen als Wissensbasis zu dem händigen oder gescripteten Umgang mit UEFI / GPT. Zum Vertändnis wie opsi mit UEFI/GPT arbeitet sind sie nicht erforderlich.

10.11.1. Technisches zu UEFI

Manipulation der UEFI Bootloader Einträge passiert unter Linux mit dem Programm efibootmgr.
Liste der Booteinträge:

efibootmgr -v
BootCurrent: 000D
Timeout: 0 seconds
BootOrder: 0012,0011,000D,0010,000B,0009,0007,0008,000A,000C
Boot0000  Setup
Boot0001  Boot Menu
(..)
Boot0007* USB CD        030a2400d23878bc820f604d8316c068ee79d25b86701296aa5a7848b66cd49dd3ba6a55
Boot0008* USB FDD       030a2400d23878bc820f604d8316c068ee79d25b6ff015a28830b543a8b8641009461e49
Boot0009* ATA HDD0      030a2500d23878bc820f604d8316c068ee79d25b91af625956449f41a7b91f4f892ab0f600
Boot000D* PCI LAN       030a2400d23878bc820f604d8316c068ee79d25b78a84aaf2b2afc4ea79cf5cc8f3d3803
Boot0010* ubuntu        HD(1,800,31801,faffb7b9-bdf9-4767-b475-0b8aee68d3ac)File(\EFI\ubuntu\grubx64.efi)
Boot0011* opsitempwinpe HD(4,3c72800,7cf801,dc1cea68-a296-4fb8-a97a-263227ed86f4)File(\EFI\boot\bootx64.efi)
Boot0012* Windows Boot Manager  HD(1,800,31801,5e4ffde2-3e25-42dd-b0f7-fcb7ee5d2b20)File(\EFI\Microsoft\Boot\bootmgfw.efi)WINDOWS.........x...B.C.D.O.B.J.E.C.T.=.{.9.d.e.a.8.6.2.c.-.5.c.d.d.-.4.e.7.0.-.a.c.c.1.-.f.3.2.b.3.4.4.d.4.7.9.5.}...a................

Manipulation der UEFI Bootloader Einträge passiert unter Windows mit dem Programm bcdedit.
Liste der Booteinträge:

bcdedit /enum firmware

Start-Manager für Firmware
- - - - - - - - - - - - - - -
Bezeichner              {fwbootmgr}
displayorder            {bootmgr}
                        {99a9f9be-9a98-11e3-b22f-806e6f6e6963}
                        {11a8b97e-99df-11e3-ae5c-b888e3e3cbb4}
                        {11a8b986-99df-11e3-ae5c-b888e3e3cbb4}
Windows-Start-Manager
- - - - - - - - - - - - - - -
Bezeichner              {bootmgr}
device                  partition=\Device\HarddiskVolume1
path                    \EFI\Microsoft\Boot\bootmgfw.efi
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b971-99df-11e3-ae5c-b888e3e3cbb4}
description             Setup
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b972-99df-11e3-ae5c-b888e3e3cbb4}
description             Boot Menu
(...)
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b978-99df-11e3-ae5c-b888e3e3cbb4}
description             USB CD
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b979-99df-11e3-ae5c-b888e3e3cbb4}
description             USB FDD
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b97a-99df-11e3-ae5c-b888e3e3cbb4}
description             ATA HDD0
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {11a8b97e-99df-11e3-ae5c-b888e3e3cbb4}
description             PCI LAN
Firmwareanwendung (101fffff)
- - - - - - - - - - - - - - -
Bezeichner              {99a9f9be-9a98-11e3-b22f-806e6f6e6963}
device                  partition=X:
path                    \EFI\boot\bootx64.efi
description             opsitempwinpe

Mit beiden Programmen lassen sich Einträge erstellen, löschen, der nextboot setzen und die Reihenfolge manipulieren.

Beispiel: Eintrag für den nächsten Boot setzen:

Linux

efibootmgr /bootnext <hexId>

Windows

bcdedit /set {fwbootmgr} bootsequence <GUID>

10.11.2. Technisches GPT

GPT Partitionen kennen neue Partitionstypen. Diese sind an die bisher bekannten angelehnt. So wird aus dem Partitionstyp für NTFS 07 unter GPT 0700. Analog wird aus den Linux Partitionstypen 82 und 83 entsprechend 8200 und 8300.

Die Liste der bekannten Partitionstypen kann man sich anzeigen lassen:

# sgdisk -L
0700 Microsoft basic data  0c01 Microsoft reserved    2700 Windows RE
4100 PowerPC PReP boot     4200 Windows LDM data      4201 Windows LDM metadata
7501 IBM GPFS              7f00 ChromeOS kernel       7f01 ChromeOS root
7f02 ChromeOS reserved     8200 Linux swap            8300 Linux filesystem
8301 Linux reserved        8302 Linux /home           8400 Intel Rapid Start
8e00 Linux LVM             a500 FreeBSD disklabel     a501 FreeBSD boot
a502 FreeBSD swap          a503 FreeBSD UFS           a504 FreeBSD ZFS
a505 FreeBSD Vinum/RAID    a580 Midnight BSD data     a581 Midnight BSD boot
a582 Midnight BSD swap     a583 Midnight BSD UFS      a584 Midnight BSD ZFS
a585 Midnight BSD Vinum    a800 Apple UFS             a901 NetBSD swap
a902 NetBSD FFS            a903 NetBSD LFS            a904 NetBSD concatenated
a905 NetBSD encrypted      a906 NetBSD RAID           ab00 Apple boot
af00 Apple HFS/HFS+        af01 Apple RAID            af02 Apple RAID offline
af03 Apple label           af04 AppleTV recovery      af05 Apple Core Storage
be00 Solaris boot          bf00 Solaris root          bf01 Solaris /usr & Mac Z
bf02 Solaris swap          bf03 Solaris backup        bf04 Solaris /var
bf05 Solaris /home         bf06 Solaris alternate se  bf07 Solaris Reserved 1
bf08 Solaris Reserved 2    bf09 Solaris Reserved 3    bf0a Solaris Reserved 4
bf0b Solaris Reserved 5    c001 HP-UX data            c002 HP-UX service
ea00 Freedesktop $BOOT     eb00 Haiku BFS             ed00 Sony system partitio
ef00 EFI System            ef01 MBR partition scheme  ef02 BIOS boot partition
fb00 VMWare VMFS           fb01 VMWare reserved       fc00 VMWare kcore crash p
fd00 Linux RAID

Tatsächlich sind diese hier gezeigten Partitionstypen nur Abkürzungen für die eigentlich verwendeten GUID’s welche dem Partitionierungsschema den Namen gegeben haben.

Also: 0700 steht für Microsoft basic data und für die GUID EBD0A0A2-B9E5-4433-87C0-68B6B72699C7

Eine Liste der GUID’s findet sich z.B. bei Wikipedia:

https://de.wikipedia.org/wiki/GUID_Partition_Table#Partitionstyp-GUIDs

https://en.wikipedia.org/wiki/GUID_Partition_Table#Partition_type_GUIDs

Weiterhin kennt das Werkzeug gdisk (und sgdisk, …) eine interne Ersetzungstabelle für unbekannte Partitionstypen. So gibt es für den alten Partionstyp für vfat32 0b keine Entsprechung als 0b00. Übergibt man aber trotzdem 0b00 als Typ an sgdisk so wird ohne jede Meldung hieraus 0700. Dies passiert wohl nach der Überlegung: vfat32 - das wird schon eine Microsoft Daten Partition sein…

GPT Partitionen kennen Attribute.

Liste der z.Zt. bekannten Attribute

Wert	Beschreibung	Attributwert (sgdisk --info / diskpart gpt attribute)
nix	nix	0000000000000000
0	Systempartition (system partition)	0000000000000001
1	Verstecke die Partition vor EFI (hide from EFI)	0000000000000002
2	Legacy Bootflag (legacy BIOS bootable)	0000000000000004
60	Nur lesen (read-only)	1000000000000000
62	Versteckt (hidden)	4000000000000000
63	Nicht Einhängen (do not automount)	8000000000000000

Die attribute werden unter Linux bei sgdisk über die Option -A, --attributes unter Verwendung der Kurzform und unter Windows über diskpart mit dem Befehl gpt attributes unter Verwendung der Langform gesetzt.

Beispiele:

select disk 0
select partition 1
gpt attributes=0x0000000000000000

sgdisk -t 1:0700 --attributes 1:clear:63 --attributes 1:set:62 -p /dev/sda

Anzeigen der Partitionstabelle mit -p , --print:

sgdisk -p /dev/sda

Anzeigen der Detailinfos zu einer Partition (1) mit --info=:

sgdisk --info=1 /dev/sda

10.11.3. opsi UEFI/GPT Roadmap

UEFI 32 Bit Unterstützung
Andere netbootfähige UEFI Bootloader (grub2)
Secureboot

Kapitel 11. opsi Erweiterung opsi-clonezilla

11.1. Vorbedingungen für die opsi Erweiterung opsi-clonezilla

Technische Voraussetzungen sind opsi 4.0.3 mit den Paketständen:

Tabelle 11.1. Benötigte Pakete

opsi-Paket	Version
opsi-linux-bootimage	>= 20130207-1

bzw. opsi 4.0.5 mit den Paketständen:

Tabelle 11.2. Benötigte Pakete

opsi-Paket	Version
opsi-linux-bootimage	>= 20140805-1
opsi-clonezilla	>= 4.0.5-1

11.2. Einführung

Neben der Paketbasierten (unattended) installation hatte opsi in der Vergangenheit nur eine rudimentäre Unterstützung für Image basierte Installationen. Mit der Integration der Technik des Open Source Produktes clonezilla (http://clonezilla.org/) stellen wir nun eine umfangreiche und flexible Lösung zum Umgang mit Partitions- und Plattenimages vor.

11.3. Konzept

Wir haben die clonezilla scripte mit dem opsi-linux-bootimage kombiniert. Dadurch ergeben sich folgende Vorteile:

Integration in die Steuerung durch opsi
Automatischer mount des shares zur Ablage der images
Möglichkeit der Automatisierung der Abläufe

11.4. Interaktive Abläufe

Per default läuft opsi-clonezilla im interaktiven Modus. Dieser erlaubt es einfach und bequem die Parameter für einzelne Aktionen zu bestimmen und kann aber auch als Basis für die Automatisierung dienen.

Stellen Sie das Property imageshare auf einen share, welcher vom user pcpatch mit dem dem opsi-server bekannten Passwort gemountet werden kann. Das Format für den share ist dabei //server/share (Beachten Sie die Verwendung von slashs statt backslashs). Dieser share ist üblicherweise der share opsi_images des opsi servers.
Stellen Sie das Property runcommand auf /opt/drbl/sbin/ocs-live bzw. ocs-live ab opsi 4.0.5. Dies ist der Interaktive Modus von clonezilla.
Starten Sie das Netbootprodukt.
In der ersten Maske werden Sie gefragt ob nach /home/partimg etwas gemountet werden soll. Wählen Sie Skip da dies vom bootimage schon erledigt worden ist.

Abbildung 11.1. Skip: Der über das Property 'imageshare’angegebene Ziel- / Quell-share wird vom opsi-bootimage nach /home/partimg gemountet.

Die gemounteten Partitionen werden angezeigt:

Abbildung 11.2. Gemountete Partitionen.

../images/clonezilla_existing_setting.png

In der Abfrage Expert oder Beginner bestimmen Sie ob Sie im folgenden die Defaultparameter ungefragt übernehmen (Beginner) oder diese abändern können (Expert).

Vor opsi 4.0.5 sollte die Wahl hier auf Expert fallen um in Hinblick auf die Automatisierung z.B. Rückfragen ausschalten zu können.

Ab opsi 4.0.5 können Sie auch den Beginner Modus wählen.

Abbildung 11.3. Experte oder lieber einfach ?

Nun können Sie wählen welche Operation Sie durchführen wollen. Hier werden die folgenden Operationen behandelt:

save disk
save partition
restore disk
restore partition

Abbildung 11.4. Operation wählen.

11.4.1. Interaktives savedisk im expert mode

Hier beispielhaft anhand der savedisk Operation die zusätzlichen Masken des Expertmodes.

Abbildung 11.5. Wahl der Werkzeuge (den default nutzen)

Abbildung 11.6. Durchmischtes: Hier -c abwählen um für die automation zusätzliche Rückfragen zu vermeiden.

Abbildung 11.7. Kompressionsmethode vor opsi 4.0.5 also bei bootimages ⇐ 20130207 (opsi-clonezilla_2.01-3) hier -z1 wählen. Ab opsi 4.0.5 ist dies nicht mehr nötig.

Abbildung 11.8. Check filesystem (den default skip nutzen)

Abbildung 11.9. Check the saved image (den default yes nutzen)

Abbildung 11.10. Action after cloning (den default -p true nutzen, der reboot wird vom opsi bootimage ausgelöst.)

11.4.2. Interaktives savedisk

Abbildung 11.11. Name unter dem das image der disk abgespeichert werden soll.

Abbildung 11.12. Wahl der disk von welcher das image erzeugt werden soll

Abbildung 11.13. Das resultierende Kommando. Dieses kann auch im Produktproperty runcommand verwendet werden

../images/clonezilla_savedisk_command.png

Abbildung 11.14. Fortschrittsanzeige

../images/clonezilla_savedisk_progress.png

11.4.3. Interaktives savepart

Abbildung 11.15. Name unter dem das image der partition abgespeichert werden soll.

Abbildung 11.16. Wahl der partition von welcher das image erzeugt werden soll

Abbildung 11.17. Das resultierende Kommando. Dieses kann auch im Produktproperty runcommand verwendet werden

../images/clonezilla_saveparts_command.png

Abbildung 11.18. Fortschrittsanzeige

../images/clonezilla_savepart_progress.png

11.4.4. Interaktives restoredisk

Abbildung 11.19. Wahl des diskimage welches restored werden soll

../images/clonezilla_choose_diskimage2restore.png

Abbildung 11.20. Wahl der disk auf die das image restored werden soll

../images/clonezilla_choose_restore_targetdisk.png

Abbildung 11.21. Das resultierende Kommando. Dieses kann auch im Produktproperty runcommand verwendet werden

../images/clonezilla_restoredisk_command.png

Abbildung 11.22. Rückfrage vor dem Beginn des Überschreibens der disk. Kann durch entfernen der Option -c aus dem Kommando unterdrückt werden

../images/clonezilla_restoredisk_askbeforeinst.png

Abbildung 11.23. Fortschrittsanzeige

../images/clonezilla_restoredisk_progress.png

11.4.5. Interaktives restorepart

Abbildung 11.24. Wahl des partimage welches restored werden soll

../images/clonezilla_choose_partimage2restore.png

Abbildung 11.25. Wahl der partition auf die das image restored werden soll

../images/clonezilla_choose_restore_targetpart.png

Abbildung 11.26. Das resultierende Kommando. Dieses kann auch im Produktproperty runcommand verwendet werden

../images/clonezilla_restorepart_command.png

Abbildung 11.27. Rückfrage vor dem Beginn des Überschreibens der disk. Kann durch entfernen der Option -c aus dem Kommando unterdrückt werden.

../images/clonezilla_restorepart_askbeforeinst.png

Abbildung 11.28. Fortschrittsanzeige

../images/clonezilla_restorepart_progress.png

11.5. Nichtinteraktive Abläufe

Durch Angabe des entsprechenden Kommandos im Property runcommand wird opsi-clonezilla in den nichtinteraktiven Modus versetzt.

Stellen Sie das Property imageshare auf einen share, welcher vom user pcpatch mit dem dem opsi-server bekannten Passwort gemountet werden kann. Das Format für den share ist dabei //server/share (Beachten Sie die Verwendung von slashs statt backslashs).
Stellen Sie das Property runcommand auf ein entsprechendes nicht-interaktives Kommando.

Beispiele aus den bisher gezeigten Vorgängen (ohne -c und mit --batch). Ab opsi 4.0.5 können Sie den Parameter -z1 weglassen. Dies beschleunigt die Kompression bei mehreren Prozessor Kernen:

/opt/drbl/sbin/ocs-sr --batch -q2 -j2 -rm-win-swap-hib -z1 -i 2000 -p true savedisk 2014-06-11-12-img sda
/opt/drbl/sbin/ocs-sr --batch -q2 -j2 -rm-win-swap-hib -z1 -i 2000 -p true saveparts partimg sda1
/opt/drbl/sbin/ocs-sr --batch -g auto -e1 auto -e2 -r -j2 -p true restoredisk 2014-06-11-12-img sda
/opt/drbl/sbin/ocs-sr --batch -g auto -e1 auto -e2 -r -j2 -k -p true restoreparts partimg sda1

Wenn man nun bei diesen Beispielen die imagenamen 2014-06-11-12-img bzw. partimg durch den string imagefile ersetzt, so wird dieser String jeweils durch den Wert des Properties imagefile ersetzt.

11.6. opsi-clonezilla known bugs

In der Version 4.0.5-2 mit bootimage Version 20140819-1 gibt es beim Imagen von Rechnern im UEFI Mode noch Probleme

11.7. Clonezilla Kommando Referenz

http://clonezilla.org/clonezilla-live-doc.php

http://allthatnetwork.blogspot.de/2012/10/clonezilla-ocs-sr-options.html

Clonezilla ocs-sr options

Setting the TERM as linux
/opt/drbl/sbin/ocs-sr: -h: invalid option
Usage:
To save or restore image
ocs-sr [OPTION] {savedisk|saveparts|restoredisk|restoreparts} IMAGE_NAME DEVICE
 Options for saving:

-fsck-src-part, --fsck-src-part: Run fsck interactively on the source file system before saving it.
-fsck-src-part-y, --fsck-src-part-y: Run fsck automatically on the source file system before saving it. This option will always attempt to fix any detected filesystem corruption automatically. //NOTE// Use this option in caution.
-gm, --gen-md5sum: Generate the MD5 checksum for the image. Later you can use -cm|--check-md5sum option to check the image when restoring the image. Note! It might take a lot of time to generate if the image size is large.
-gs, --gen-sha1sum: Generate the SHA1 checksum for the image. Later you can use -cs|--check-sha1sum option to check the image when restoring the image. Note! It might take a lot of time to generate if the image size is large.
-j2, --clone-hidden-data: Use dd to clone the image of the data between MBR (1st sector, i.e. 512 bytes) and 1st partition, which might be useful for some recovery tool.
-ntfs-ok, --ntfs-ok: Assume the NTFS integrity is OK, do NOT check again (for ntfsclone only)
-rm-win-swap-hib, --rm-win-swap-hib: Try to remove the MS windows swap file in the source partition.
-q, --use-ntfsclone: If the partition to be saved is NTFS, use program ntfsclone instead of partimage (i.e. Priority: ntfsclone > partimage > dd)
-q1, --force-to-use-dd: Force to use dd to save partition(s) (inefficient method, very slow, but works for all the file system).
-q2, --use-partclone: Use partclone to save partition(s) (i.e. partclone > partimage > dd).
-rescue, --rescue: Turn on rescue mode, i.e. try to skip bad sectors.
-sc, --skip-check-restorable: By default Clonezilla will check the image if restorable after it is created. This option allows you to skip that.
-z0, --no-compress: Don’t compress when saving: very fast but very big image file (NOT compatible with multicast restoring!!!)
-z1, --gzip-compress: Compress using gzip when saving: fast and small image file (default)
-z1p, --smp-gzip-compress: Compress using parallel gzip program (pigz) when saving: fast and small image file, good for multi-core or multi-CPU machine
-z2, --bz2-compress: Compress using bzip2 when saving: slow but smallest image file
-z2p, --smp-bzip2-compress: Compress using parallel bzip2 program (pbzip2) when saving: faster and smallest image file, good for multi-core or multi-CPU machine
-z3, --lzo-compress: Compress using lzop when saving: similar to the size by gzip, but faster than gzip.
-z4, --lzma-compress: Compress using lzma when saving: slow but smallest image file, faster decompression than bzip2.
-z5, --xz-compress: Compress using xz when saving: slow but smallest image file, faster decompression than bzip2.
-z5p, --smp-xz-compress: Compress using parallel xz when saving: slow but smallest image file, faster decompression than bzip2.
-z6, --lzip-compress: Compress using lzip when saving: slow but smallest image file, faster decompression than bzip2.
-z6p, --smp-lzip-compress: Compress using parallel lzip when saving: slow but smallest image file, faster decompression than bzip2.
-z7, --lrzip-compress: Compress using lrzip when saving.
-i, --image-size SIZE: Set the split image file volume size SIZE (MB). When ocs-sr is run with -x, the default SIZE is set as 2000, if without -x, we will not split it.

Three words are reserved for IMAGE_NAME, "ask_user" is used to let user to input a name when saving an image. "autoname" is used to automatically generate the image name based on network card MAC address and time. "autohostname" is used to automatically generate the image name based on hostname.

A word is reserved for DEVICE, "ask_user" could be used to let user to select the source device when saving an image.

Options for restoring:

-g, --grub-install GRUB_PARTITION: Install grub in the MBR of the disk containing partition GRUB_PARTITION with root grub directory in the same GRUB_PARTITION when restoration finishs, GRUB_PARTITION can be one of "/dev/hda1", "/dev/hda2"… or "auto" ("auto" will let clonezilla detect the grub root partition automatically). If "auto" is assigned, it will work if grub partition and root partition are not in the same partition.
-r, --resize-partition: Resize the partition when restoration finishes, this will try to fix the problem when small partition image is restored to larger partition. Warning!!! Use this carefully… Backup your data first
-k, --no-fdisk, --no-create-partition: Do NOT create partition in target harddisk. If this option is set, you must make sure there is an existing partition table in the current restored harddisk. Default is to create the partition table.
-icrc, --icrc: Skip Partclone CRC checking.
-irhr, --irhr: Skip removing the Linux udev hardware records on the restored GNU/Linux.
-ius, --ius: Skip updating syslinux-related files on the restored GNU/Linux.
-icds, --ignore-chk-dsk-size-pt: Skip checking destination disk size before creating the partition table on it. By default it will be checked and if the size is smaller than the source disk, quit.
-k1,: Create partition table in the target disk proportionally.
-k2,: Enter command line prompt to create partition table manually before restoring image.
-t, --no-restore-mbr: Do NOT restore the MBR (Mater Boot Record) when restoring image. If this option is set, you must make sure there is an existing MBR in the current restored harddisk. Default is Yes
-u, --select-img-in-client: Input the image name in clients
-e, --load-geometry: Force to use the saved CHS (cylinders, heads, sectors) when using sfdisk
-e1, --change-geometry NTFS-BOOT-PARTITION: Force to change the CHS (cylinders, heads, sectors) value of NTFS boot partitoin after image is restored. NTFS-BOOT-PARTITION can be one of "/dev/hda1", "/dev/hda2"… or "auto" ("auto" will let clonezilla detect the NTFS boot partition automatically)
-e2, --load-geometry-from-edd: Force to use the CHS (cylinders, heads, sectors) from EDD (Enhanced Disk Device) when creating partition table by sfdisk
-y, -y0, --always-restore, --always-restore-default-local: Let Clonezilla server as restore server, i.e. client will always has restore mode to choose (However default mode in PXE menu is local boot)
-y1, --always-restore-default-clone: Let Clonezilla server as restore server, i.e. client will always has restore mode to choose (The default mode in PXE menu is clone, so if client boots, it will enter clone always, i.e. clone forever)
-j, --create-part-by-sfdisk: Use sfdisk to create partition table instead of using dd to dump the partition table from saved image (This is default)
-j0, --create-part-by-dd: Use dd to dump the partition table from saved image instead of sfdisk. ///Note/// This does NOT work when logical drives exist.
-j1, --dump-mbr-in-the-end: Use dd to dump the MBR (total 512 bytes, i.e. 446 bytes (executable code area) + 64 bytes (table of primary partitions) + 2 bytes (MBR signature; # 0xAA55) = 512 bytes) after disk image was restored. This is an insurance for some hard drive has different numbers of cylinder, head and sector between image was saved and restored.
-j2, --clone-hidden-data: Use dd to clone the image of the data between MBR (1st sector, i.e. 512 bytes) and 1st partition, which might be useful for some recovery tool.
-hn0 PREFIX: Change the hostname of M$ Windows based on the combination of hostname prefix and IP address, i.e. PREFIX-IP
-hn1 PREFIX: Change the hostname of M$ Windows based on the combination of hostname prefix and NIC MAC address, i.e. PREFIX-MAC
--max-time-to-wait TIME: When not enough clients have connected (but at least one), start anyways when TIME seconds since first client connection have pased. This option is used with --clients-to-wait
-cm, --check-md5sum: Check the MD5 checksum for the image. To use this option, you must enable -gm|--gen-md5sum option when the image is saved. Note! It might take a lot of time to check if the image size is large.
-cs, --check-sha1sum: Check the SHA1 checksum for the image. To use this option, you must enable -gs|--gen-sha1sum option when the image is saved. Note! It might take a lot of time to check if the image size is large.
--mcast-port NO: Assign the udp port number for multicast restore. This is used by clonezilla server. Normally it’s not necessary to manually assign this option.

A word is reserved for IMAGE_NAME, "ask_user" is used to let user to input a name when saving an image.

A word is reserved for DEVICE, "ask_user" could be used to let user to select the source device when saving an image.

General options:

-l, --language INDEX: Set the language to be shown by index number:
[0|en_US.UTF-8]: English,
[1|zh_TW.BIG5]: Traditional Chinese (Big5) - Taiwan,
[2|zh_TW.UTF-8]: Traditional Chinese (UTF-8, Unicode) - Taiwan
[a|ask]: Prompt to ask the language index
-b, -batch, --batch: (DANGEROUS!) Run program in batch mode, i.e. without any prompt or wait for pressing enter key. //NOTE// You have to use -batch instead of -b when you want to use it in the boot parameters. Otherwise the program init on system will honor -b, too.
-c, --confirm: Wait for confirmation before saving or restoring
-d, --debug-mode: Enter command mode to debug before saving/restoring
--debug=LEVEL: Output the partimage debug log in directory /var/log/ with debug LEVEL (0,1,2… default=0)
-m, --module MODULE: Force to load kernel module MODULE, this is useful when some SCSI device is not detected. NOTE! Use only one module, more than one may cause parsing problem.
-o0, --run-prerun-dir: Run the script in the direcoty /opt/drbl/share/ocs/postrun before clone is started. The command will be run before MBR is created or saved.
-o1, -o, --run-postrun-dir: Run the script in the direcoty /opt/drbl/share/ocs/postrun when clone is finished. The command will be run before that assigned in -p or --postaction.
-w, --wait-time TIME: Wait for TIME secs before saving/restoring
--nogui: Do not show GUI of partimage, use text only
-a, --no-force-dma-on: Do not force to turn on HD DMA
-mp, --mount-point MOUNT_POINT: Use NFS to mount MOUNT_POINT as directory ocsroot (ocsroot is assigned in drbl.conf)
-or, --ocsroot DIR: Specify DIR (absolute path) as directory ocsroot (i.e. overwrite the ocsroot assigned in drbl.conf)
-p, --postaction [choose|poweroff|reboot|command|CMD]: When save/restoration finishs, choose action in the client, poweroff, reboot (default), in command prompt or run CMD
-ns, --ntfs-progress-in-image-dir: Save the ntfsclone progress tmp file in the image dir so that if cloning is in DRBL client, the progress can be check in the server (Default in to be put in local /tmp/, which is local tmpfs).
-um, --user-mode [beginner|expert]: Specify the mode to use. If not specified, default mode is for a beginner.
-v, --verbose: Prints verbose information
-d0, --dialog: Use dialog
-d1, --Xdialog: Use Xdialog
-d2, --whiptail: Use whiptail
-d3, --gdialog: Use gdialog
-d4, --kdialog: Use kdialog
-x, --interactive: Interactive mode to save or restore.

Example:

To save or restore image in client (Only that DRBL client will join, and its local partitions is NOT mounted). NOTE!!! You should run the command in DRBL client or you have to make sure the target device is NOT busy!.
To save all the data in local first IDE harddrive hda as image IMAGE1, use ntfsclone instead of partimage, and lzop compression (NOTE!!! You should run the command in DRBL client or make sure hda is NOT busy/mounted!):
ocs-sr --use-ntfsclone -z3 savedisk IMAGE1 hda
To save the data in first and second partitions in local first IDE harddrive hda as image IMAGE2, use ntfsclone instead of partimage, and lzop compression (NOTE!!! You should run the command in DRBL client, or make sure hda is NOT busy/mounted!):
ocs-sr --use-ntfsclone -z3 saveparts IMAGE2 "hda1 hda2"
To restore image IMAGE1 to local hda. grub-install will be run after cloning (image IMAGE1 is already in DRBL server. NOTE!!! You should run the command in DRBL client or make sure hda is NOT busy/mounted!):
ocs-sr -g auto restoredisk IMAGE1 hda
To restore image first and second partitions from IMAGE2 to local hda1 and hda2. grub-install will be run after cloning (image IMAGE2 is already in DRBL server. NOTE!!! You should run the command in DRBL client or make sure hda is NOT busy/mounted!):
ocs-sr -g auto restoreparts IMAGE2 "hda1 hda2"
To save disk(s)/partitition(s) as an image or restore an image to disk(s)/partitition(s) interactively, use:
ocs-sr -x

Kapitel 12. opsi Erweiterung opsi local image

12.1. Vorbedingungen für die opsi Erweiterung opsi local image

Dieses Modul ist momentan eine kofinanzierte opsi Erweiterung.
Es sind eine Reihe von Vorbedingungen nötig, um dieses Modul einsetzen zu können. Das bedeutet, dass Sie zum Einsatz eine Freischaltdatei benötigen. Diese Freischaltung erhalten Sie, wenn Sie die Erweiterung kaufen. Zu Evaluierungszwecken stellen wir Ihnen auch eine zeitlich befristete Freischaltung kostenlos zur Verfügung ( → mail an info@uib.de).

Wichtig

Diese kofinanzierte Erweiterung kann bis auf weiteres nur von der öffentlichen Hand (z.B. Schulen / Unis) erworben werden.

Technische Voraussetzungen sind opsi 4.0.3 mit den Paketständen:

Tabelle 12.1. Benötigte Pakete

opsi-Paket	Version
opsi-linux-bootimage	>= 20130207-1

12.2. Einführung

Opsi bietet eine gute Basis, um automatisiert Windows Rechner zu installieren und zu pflegen - auch und gerade, wenn es sich um heterogene Hardware handelt. Die von opsi unterstützte Technik der Paket basierten Installation ist aber nicht schnell genug, um in Schulungsräumen Rechner innerhalb von kurzer Zeit wie z.B. in einer Pause zwischen zwei Kursen wieder in einen definierten Zustand zu versetzen. Daher wird hier ein Konzept vorgestellt, bei dem die paketbasiert durchgeführte Installation lokal auf einer zweiten Partition als Imagekopie gesichert wird und von dort eine schnelle Wiederherstellung möglich ist.

Initiale Installation mit abschließender lokaler Image-Sicherung
Schnelle Wiederherstellung auf Basis unterschiedlicher Techniken
Systempflege mit abschließender lokaler Image-Sicherung
Integration von Linuxclients in das Backup/Restore Verfahren.

12.3. Konzept

Die Anforderungen edukativer Computernetze unterscheiden sich teilweise von denen anderer Netzwerke. Eine wesentliche Anforderung, die im Folgenden diskutiert wird, ist die schnelle Wiederherstellung von Rechnern in einen definierten Zustand, den Sie im Rahmen einer temporären Nutzung verloren haben. Konkret geht es um die Bereitstellung von Rechnern in schulischen Computerräumen, wobei die Problemlage auch auf kommerzielle Computerräume oder universitäre Computerpools zutrifft.

Die Wiederherstellung muss zwingend innerhalb von kurzer Zeit (15 Minuten / Große Pause) erfolgen und sollte soweit möglich einen Rechner nicht nur zurücksetzen sondern auf eine andere Basisinstallation (z.B. Win XP / Win 7 / Linux) umschalten können. Weiterhin muss es möglich sein, dass eine kontinuierliche Pflege der Systeme mit Sicherheitsupdates gewährleistet ist.

opsi ist ein Client-Management-System, das seine Stärken in der paketbasierten Installation und Pflege von Windows-Systemen hat. Dabei gibt es im Umgang mit heterogener Hardware deutliche Vorteile gegenüber rein imagebasierten Systemen. Die damit einhergehenden Installationszeiten von etwa 2 Stunden sind aber weit von den oben angegebenen Anforderungen entfernt. Imagebasierte Lösungen sind hier prinzipiell schneller. Aber auch rein imagebasierte Systeme können bei dem Versuch, für einen ganzen Klassenraum ein Image herunterzuladen, zu Netzwerkproblemen führen. Dieses Problem kann durch lokal gepufferte Images gelöst werden. Ein solcher Ansatz wird z.B. vom Linux basierten System LinBo (Quelle http://linbo.sourceforge.net/) verfolgt. Doch auch mit lokal gepufferten Images kann es, abhängig von der verwendeten Hardware (Stichwort Festplatten- Performance), zu Zeitproblemen kommen, wenn versucht wird, komplette Images innerhalb von 15 Minuten wiederherzustellen.

Eine weitere mögliche Problemlösung, das Einfrieren eines Betriebssystems und Umlenken sämtlicher Schreibzugriffe in einen externen Container, der bei einem Neustart einfach verworfen werden kann, ist eine möglicher Ansatzpunkt. Für Linux existieren Ansatzpunkte z.B. über FUSE Filesysteme. Für Windows gibt es eingeführte kommerzielle Produkte, welche sich auch über die Kommandozeile (und damit per opsi) steuern ließen. Uns sind allerdings für den Windows Bereich keine entsprechenden Open Source Produkte bekannt. Da wir aber eine Open Source Lösung schaffen wollen, findet dieser Lösungsansatz hier keine weitere Betrachtung.

Der im Folgenden untersuchte Ansatz versucht die Vorteile der jeweiligen Ansätze zu kombinieren, ihre Nachteile zu vermeiden und für eine unterschiedliche Hardware-Ausstattung (langsame / schnelle Rechner) angepasste Möglichkeiten zu bieten. Die Grundidee kann in den folgenden Stichpunkten zusammengefasst werden:

Initiale Windowsinstallation per PXE-Boot paketbasiert mit individueller Treiberintegration unter Verwendung des opsi-Linux-Bootimage
Sicherung dieser initialen Installation in einem Sicherungsimage auf einer 2. Partition auf der lokalen Festplatte des Rechners unter Verwendung des opsi-Linux-Bootimage
Schnelle Wiederherstellung der Produktiv-Installation aus dem lokalen Image unter Verwendung des opsi-Linux-Bootimage
Pflege der lokalen Installation (Sicherheitsupdates) über die opsi Softwareverteilung und Sicherung des aktualisierten Systems auf das lokale Backup-Image unter Verwendung des opsi-Linux-Bootimage

12.4. Technisches Konzept

Der Schulungsrechner wird mit einer statischen Partitionstabelle verwendet. Dabei kann entweder mit 3 oder 4 Partitionen gearbeitet werden:

Partition 1 (System)
Hier findet sich das aktuell verwendete Betriebssystem (Windows / Linux)
Die Größe dieser Partition wird bei der Partitionierung über das Produkt opsi-local-image-prepare über ein Property gesteuert.
Optional: Partition 2 (sysdata)
Hier können z.B. Anwenderdaten gespeichert werden, welche bei einem Restore nicht überschrieben werden. Die Formatierung ist NTFS.
Die Größe dieser Partition wird bei der Partitionierung über das Produkt opsi-local-image-prepare über ein Property gesteuert.
Partition 3 (winpe / swap)
Die Größe dieser Partition ist statisch auf 4GB festgelegt.
Unter Windows XP wird dies Partition nicht verwendet.
Unter NT6 (Windows 7) wird diese Partition für das bei der Installation notwendige winpe verwendet und ist im Betrieb nicht sichtbar.
Unter Linux wird diese Partition als Swap verwendet.
Partition 4 (backup)
Diese Partition dient zur Speicherung der gesicherten Images und ihrer Metadaten.
Die Größe dieser Partition ergibt sich aus dem nach Erstellung der anderen Partitionen noch vorhandenen freien Platz.

Die Netbootprodukte zur Betriebssystem Installation verwenden nur die ersten zwei oder drei Partitionen (XP nur die erste) und lassen die letzte Backup-Partition unberührt. Somit bleiben die auf der Partition 4 (backup) liegenden Images auch bei der Installation eines neuen Betriebssystems erhalten.

12.5. Komponenten

Das Paket opsi-local-image besteht aus mehreren Komponenten:

Den Netbootprodukten:

opsi-local-image-prepare
opsi-local-image-winxp
opsi-local-image-win7
opsi-local-image-win7-x64
opsi-local-image-win8
opsi-local-image-win8-x64
opsi-local-image-win81
opsi-local-image-win81-x64
opsi-local-image-ubuntu
opsi-local-image-backup
opsi-local-image-restore
opsi-local-image-delete
opsi-local-image-capture

Den Lokalbootprodukten:

opsi-local-image-backup-starter
opsi-local-image-sysprep

Einer Erweiterung der opsi Service Methoden.

12.5.1. Netboot Produkt zur Partitionierung

opsi-local-image-prepare
Erstellung der statischen Partitionierung der Festplatte für alle anderen Produkte.
Über das Property system_partition_size wird die Größe der Partition 1 angegeben (Default = 30G)
Über das Property data_partition_size wird die Größe der Partition 2 angegeben. Bei eine Größe von 0G wird keine Partition für Daten angelegt. (Default = 0G)
Über das Property start_os_installation kann ein Produkt zur Installation eines Betriebssystems ausgewählt werden, welches im Anschluß an die Partitionierung automatisch gestartet wird. Bei der Installation dieses Produkts werden beim Produkt opsi-local-image-restore die Produktproperties imagefile und imagefiles_list gelöscht, da durch die Neupartitionierung diese Daten ungültig geworden sind.

Wichtig

Verwenden Sie dieses Produkt nur zur initialen Vorbereitung der Platte. Es löscht alle gespeicherten Images.

12.5.2. Netboot Produkte zur Installation von Windows

Die Netbootprodukte zur Installation von Windows sind Abkömmlinge der opsi Standardprodukte zur Windowsinstallation. Das bedeutet konkret, dass sie bezüglich des Aufbaus und der Treiberintegration identisch sind. Entsprechende Anleitungen finden sich im opsi-getting-started Handbuch.

opsi-local-image-winxp
Installation von Windows XP. Verwendet nur die erste Partition. Administrator Passwort ist leer.
opsi-local-image-win7
Installation von Windows 7 32 Bit. Administrator Passwort = nt123.
opsi-local-image-win7-x64
Installation von Windows 7 64 Bit. Administrator Passwort = nt123.
opsi-local-image-win8
Installation von Windows 8 32 Bit. Administrator Passwort = nt123.
opsi-local-image-win8-x64
Installation von Windows 8 64 Bit. Administrator Passwort = nt123.
opsi-local-image-win81
Installation von Windows 8.1 32 Bit. Administrator Passwort = nt123.
opsi-local-image-win81-x64
Installation von Windows 8.1 64 Bit. Administrator Passwort = nt123.

Diese Produkte haben folgende opsi-local-image spezifische Properties:

backup_after_install mit dem default Wert true. Dies bedeutet in diesem Fall, dass nach der OS Installation zunächst die Anwendungssoftware installiert wird und abschließend eine Imagesicherung der Installation durchgeführt wird. Weiterhin wird der Wert vom imageFile des Produktes opsi-local-image-restore gelöscht. Dies führt dazu, dass das erstellte Backup den Namen des laufenden Netbootproduktes (z.B. opsi-local-image-win7) bekommt.
setup_after_install
Hier können ein oder mehrere Produkte angegeben werden, welche nach Abschluß der Betriebssysteminstallation auf setup gestellt werden. Dabei werden auch die Abhängigkeiten diese Produkte mit aufgelöst.

12.5.3. Netboot Produkte zur Installation von Linux

opsi-local-image-ubuntu
Installation von Ubuntu Linux 12.04/14.04 32Bit/64Bit.
Das installierte System kennt 2 user: root und user. Für root wird das im Produktproperty root_password festgelegte Passwort gesetzt (Default: linux123). Für user wird das im Produktproperty user_password festgelegte Passwort gesetzt (Default: linux123). Details der Installation werden über Produktproperties gesteuert. Die wesentlichen Produktproperties sind dabei:
- askbeforeinst:
  Soll das Starten der Installation am Client bestätigt werden müssen? (Default=true)
- architecture:
  Architektur Auswahl, beeinflusst die Auswahl des bootimages und die Installationsarchitektur. (Default=64bit)
- additional_packages:
  Welche zusätzlichen Pakete sollen installiert werden? Angabe der Pakete Leerzeichen separiert. (Default = '')
- language:
  Welche Sprache / locale soll installiert werden. (Default=de)
- console_keymap
  steuert in welches Tastaturlayout installiert wird. (Default=de-latin1-nodeadkeys)
- timezone:
  Welche Zeitzone soll verwendet werden?. (Default=Europe/Berlin)
- online_repository
  gibt an aus welchem online Repository die Pakete installiert werden sollen. Der Default ist http://de.archive.ubuntu.com/ubuntu
- proxy:
  Proxystring (wenn benötigt) in der Form: http://<ip>:<port>. (Default = '')
- backup_after_install
  (true/false) Default = true. Nach der Installation wird sofort eine Imagesicherung der Installation durchgeführt.
- setup_after_install
  Hier können ein oder mehrere Produkte angegeben werden, welche auf setup gestellt werden und somit nach Abschluß der Betriebssysteminstallation installiert werden. Dabei werden auch die Abhängigkeiten dieser Produkte mit aufgelöst.
- wget_and_execute:
  Url (http) einer Datei welche am Ende der Installation geholt und ausgeführt wird. (Default = '')
- release:
  Welches Release von Ubuntu soll installiert werden. (Default="trusty")
- install_opsi-client-agent:
  Installiere den Linux opsi-client-agent (Kofinanzierungsprojekt: Sie benötigen eine Aktivierung durch die /etc/opsi/modules) . (Default=false)

12.5.4. Netboot Produkte zum Backup und Restore

opsi-local-image-backup
Dieses Produkt sichert das aktuell auf Partition 1 installierte Betriebssystem in einer Imagedatei auf Partition 4. Als Image Namen wird der im Property gesetzte Name verwendet. Wenn dieser leer ist, so wird der Name des opsi Netbootproduktes verwendet, welcher aktuell auf installed steht (z.B. opsi-local-image-winxp). Dieser Name wird beim Produkt opsi-local-image-restore als Produktproperty imagefile gesetzt, so daß ein nachfolgender Aufruf von opsi-local-image-restore per default genau dieses Image wiederherstellt. Dieser Name wird beim Produkt opsi-local-image-restore dem Produktproperty imagefiles_list hinzugefügt. Damit enthält dieses Property die Liste aller verfügbaren Images. Weiterhin werden (für die Windows-Produkte) die aktuellen opsi-Produktstände zusammen mit dem Image gesichert, damit auch diese im Rahmen des restores wiederhergestellt werden können.
Als Sicherungsmethode wird partclone verwendet.
Properties:
- imagefile
  Name der zu erstellenden Imagedatei (default = leer = automatische Namenswahl). Der Name darf Leerzeichen aber keine Umlaute enthalten. (Im Fall von Leerzeichen werden diese intern als Unterstich behandelt. D.h. mein image = mein_image.
opsi-local-image-restore
Dieses Produkt spielt das im Produktproperty imagefile angegebene Image wieder auf der Partition 1 ein und sorgt dafür, dass es gebootet werden kann. Weiterhin werden (für die Windows-Produkte) die für das Image gesicherten opsi-Produktstände zusammen mit dem Image wiederhergestellt.
Properties:
- imagefile
  Name des Images welches restored werden soll. Der Wert dieses Properties wird automatisch durch das letzte Backup gesetzt. Die Liste der verfügbaren Images findet sich im Property imagefiles_list.
- imagefiles_list
  Liste der verfügbaren Images. Wird duch das Backup Produkt gepflegt.
- method
  Methode des Imagerestores. Mögliche Methoden sind partclone-image-restore und rsync-partclone-image. Der default ist rsync-partclone-image. Die Methode rsync-partclone-image ist nur möglich wenn sich auf der Partition 1 das Betriebsystem befindet, von dem das bei imagefile angegebene Image erstellt wurde. D.h. mit dieser Methode können kleine Änderungen rückgängig gemacht werden aber es kann kein Wechsel zwischen Betriebssystemen durchgeführt werden. Die Methode partclone-image-restore führt eine vollständige Imagekopie durch. Die Methode rsync-partclone-image steht derzeit (10.7.2013) nur für Windows (NTFS Filesystem) zur Verfügung. Wird als method rsync-partclone-image für ein Linux-Image oder für ein Image welches zu einer anderen Windows Version gehört, als die auf der produktiv Partition vorhandene, angegeben, so wird automatisch die Methode partclone-image-restore angewendet.
  Scheitert der Aufruf des Restore mit der Methode rsync-partclone-image, so wird automatisch der Restore mit der Methode partclone-image-restore weitergeführt.
  Die Methode rsync-partclone-image hat ihre Vorteile bei wenigen Änderungen auf langsamen (IDE) Platten. Bei aktuellen (SATA) Platten empfehlen wir prinzipiell die Verwendung von partclone-image-restore.
- update_and_backup
  (true/false) Default = false. Bei true wird nach dem restore dafür gesorgt, dass alle Localboot Produkte die auf dem Server in einer abweichenden Version vorhanden sind auf setup gestellt werden und das Produkt opsi-local-image-backup-starter auf once gesetzt wird. Dies führt dazu, dass alle vorhandenen Updates eingespielt und nach den Updates automatisch wieder eine Sicherung durchgeführt wird.
- setup_after_restore
  Hier können ein oder mehrere opsi-Produkte angegeben werden, welche nach dem Abschluß des Restores auf setup gesetzt werden und somit nach dem Reboot automatisch ausgeführt werden. Der Default ist das Produkt windomain zur erneuten Aufnahme des restorten Clients in die Windows Domain.
opsi-local-image-delete
Dieses Produkt löscht das im Produktproperty imagefile angegebene Image von der Backup Partition
- imagefile
  Name des zu löschenden Images (default = leer = Fehler)

12.5.5. Localboot Produkt zur Ablaufsteuerung

opsi-local-image-backup-starter
Dieses Localbootprodukt stellt das Netbootprodukt opsi-local-image-backup auf setup und rebootet den Rechner dann. Dieses Produkt hat eine sehr niedrige Priorität von -98. Dies bedeutet das alle normalen Localboot Produkte vorher abgearbeitet werden. Dies kann zu folgendem genutzt werden:
Werden für einen Rechner folgende Produkte auf setup gestellt:
Das Produkt opsi-local-image-restore
Alle Localboot Produkte die nicht aktuell sind
Das Produkt opsi-local-image-backup-starter

so führt dies zu folgendem Ablauf:

Restore des Images
Update des restoreten Betriebssystems (Alle nicht aktuellen Produkte werden aktualisiert)
Backup des upgedateten Betriebssystems

12.6. Erweiterte opsi Service Methoden

Im Rahmen dieser Erweiterung können die Rechner eines Schulungsraums in einer opsi-client Gruppe zusammengefasst werden. Um möglichst komfortable Aktionen für alle Rechner eines Schulungsraums auszulösen sind folgende Erweiterungen der opsi-service Methoden vorgesehen:

setProductActionRequestForHostGroup
Parameter: hostGroupId, productId, actionRequest
Ermöglicht für alle Mitglieder einer Gruppe (z.B. Rechner eines Schulungsraums) eine bestimmte Aktion zu starten (z.B. Restore des Images).
setProductPropertyForHostGroup
Parameter: productId propertyId propertyValue hostGroupId
Ermöglicht für alle Mitglieder einer Gruppe (z.B. Rechner eines Schulungsraums) für ein betimmtes Produkt einen Propertywert zusetzen (z.B. welches Image restored werden soll).
getPossibleImagefileValuesForHostGroup
Parameter: groupId
Liefert die Liste der Imagefile Namen, welche das opsi-local-image-backup auf allen Mitgliedern der Gruppe angelegt hat. Wenn ein bestimmtes Image (z.B. opsi-local-image-winxp) auf einem oder mehreren Rechnern nicht vorhanden ist, so ist es nicht Bestandteil der Rückgabeliste.

Diese Methoden werden zu einem späteren Zeitpunkt in die Standardpakete von opsi integriert. Bis dahin steht Ihnen in der Auslieferung eine Datei 40_groupActions.conf zur Verfügung die Sie bitte mit root Rechten nach /etc/opsi/backendManager/extend.d kopieren. Führen Sie danach aus: opsi-setup --set-rights /etc/opsi.

12.7. Abläufe

12.7.1. Initiale Installation

Über das Produkt opsi-local-image-prepare wird zunächst die notwendige statische Partitionierung erzeugt.

Abbildung 12.1. Schema: Statische Partitionierung mit opsi-local-image-prepare

Anschließend können über die Produkte opsi-local-image-winxp, opsi-local-image-win7, opsi-local-image-win7-x64 und opsi-local-image-ubuntu verschiedene Betriebssysteme mit unterschiedlicher Ausstattung an Anwendungssoftware installiert werden.

Abbildung 12.2. Schema: OS Installation mit opsi-local-image-win*

Diese werden per default nach Ihrer Installation automatisch als Image gesichert.

Abbildung 12.3. Schema: Image Backup mit opsi-local-image-backup

12.7.2. Restore eines Images

Der einfache Aufruf des Produktes opsi-local-image-restore stellt automatisch das letzte erstellte Image wieder her. Soll ein anderes Image wieder hergestellt werden, so muß dies im Property imagefile angegeben werden.

Abbildung 12.4. Schema: Image Restore mit opsi-local-image-restore

12.7.3. Update eines Images

Durch den Aufruf des Produktes opsi-local-image-restore mit der Propertyeinstellung update_and_backup = true wird das angegebene Image restored, alle Anwendungssoftware upgedated (soweit Updates auf dem Server vorhanden) und anschließend automatisch wieder eine Sicherung durch geführt.

12.7.4. Löschen eines Images

Durch den Aufruf des Produktes opsi-local-image-delete wird das im Property imagefile angegebene Image gelöscht.

12.8. Backuppartition

Die Backuppartion ist (bei MBR BIOS und ohne Datenpartition) die dritte Partition der 1. Festplatte.
Dort finden sich:

Die Datei master.log mit Informationen über alle durchgeführten Image Operationen. Diese Logdatei wird in die bootimage logs übernommen.
Die Image Verzeichnisse
Die Imageverzeichnisse haben den selben Namen wie das Image und enthalten neben dem Image noch die Metadaten des Images.
Zur Orientierung hier Beispielhaft die Größen von unterschiedlichen Imageverzeichnissen mit OS und Standardsoftware (Libreoffice, Adobereader, firefox, thunderbird, javavm, flashplayer):
opsi-local-image-ubuntu: 3.6G
opsi-local-image-winxp: 6.4G
opsi-local-image-win7: 9.4G
opsi-local-image-win7-x64: 13G

12.9. Capture Images (WIM) erstellen und verteilen

12.9.1. Capture Images (WIM) Einführung

Microsoft hat mit NT6 (also ab Vista) zur Installation ein neues Imageformat, das Windows Imaging Format (WIM) eingeführt. Ein WIM Image ist kein Platten- oder Partitionsimage sondern mehr ein Dateien und Metadaten Archiv. Eine WIM Datei kann mehrere Images enthalten. Die normale Installation eines NT6 Rechners basiert darauf, dass die setup.exe ein Image aus der Datei install.wim auspackt und dieses danach konfiguriert und mit zusätzlichen Treibern versieht.

Von einem existierender Rechner kann das Windows inclusive installierter Software und Konfigurationen ausgelesen und in Form eines WIM abgespeichert werden. Ein solches WIM kann dann wieder die Basis für neue Installationen sein.

12.9.2. Capture Images (WIM) Komponenten

Das Paket opsi-local-image besteht aus mehreren Komponenten:

Den Netbootprodukten:

opsi-local-image-capture

Den Lokalbootprodukten:

opsi-local-image-backup-sysprep
opsi-set-wim-imagenames
opsi-del-wim-images
opsi-client-agent >= Version 4.0.4.5-3

12.9.3. Capture Images (WIM) Abläufe

Erstellen des Masterrechners:
Dieser wird mit opsi-local-image als Rechner erstellt und kann dabei Software und Konfigurationen sowohl per opsi als auch von Hand bekommen.

Sysprep: Depersonalisieren des Masters:
Damit ein capture Image als Basis für eine Installation dienen kann muß es zunächst dafür vorbereitet werden. Dabei wird der Rechner depersonalisiert, d.h. Der Rechner hat danach keine Identität mehr und ist gut geeignet als Vorlage für eine Neuinstallation aber als Rechner selber kaum noch brauchbar.
Daher kann beim opsi-local-image-sysprep Produkt über Produkt Properties gesteuert werden ob vor der eigentlichen Depersonalisierung noch ein Backup angelegt werden soll:
always_backup_before_sysprep (true/false) Default=true: Startet immer ein Backup vor dem sysprep Vorgang.
abort_on_no_backup (true/false) Default=true: Prüft ob auf der Backuppartition ein Backup zu diesem Produkt vorhanden ist und bricht ab falls nicht.
Nach dem sysprep Vorgang wird üblicherweise der eigentliche capture Vorgang gestartet, der durch das netboot Produkt opsi-local-image-capture durchgeführt wird. Ob der Start automatisch durchgeführt wird entscheidet das Property:
startcapture (true/false) Default=true: Setze das Produkt opsi-local-image-capture auf setup und reboot den Rechner

Abbildung 12.5. Capture Images: Configed: opsi-local-image-sysprep

Capture: Die vorhandene Installation auslesen und zur Installation bereitstellen:
Im Rahmen dieses Mehrstufigen Prozesses wird der vorhandene Rechner ausgelesen und als WIM Image in ein vorhandenes opsi Windows Installationsprodukt integriert. Von daher gibt es naheliegender Weise ein Produktproperty über das angegeben werden kann in welches Produkt das ausgelesene Image integriert werden soll:

target_product: Name des Ziel Produktes (Default = '')

Wichtig

Dieses Property ist nicht schlau, es wird nicht überprüft ob das ausgelesene Image zum Zielprodukt passt. Sie können also ohne Fehlermeldung ein win7-32Bit Image in ein Win81-64Bit Produkt schreiben. Das sollten Sie aber nicht! Wir empfehlen die Verwendung von gesonderten Produkten, welche nur als Ziel dienen (z.B. opsi-local-image-win81-x64-capture).

Das Zielprodukt muß genauso wie ein normales Produkt zur Windows Installation vorbereitet werden. Als Zieldatei innerhalb des Zielproduktes dient die install.wim Datei (installfiles/sources/install.wim) welche auch die von Microsoft gelieferten Images enthält. Ob das ausgelese Image nun an diese Datei angehängt werden soll oder eine neue install.wim erzeugt werden soll, steuert das Property:

capture_mode (append/always_create) Default=append:

Bei append wird das neu erstellte Image an die vorhandene install.wim angehängt.

Wichtig

Enthält die install.wim schon ein Image gleichen Namens wird dieses ohne Nachfrage gelöscht. Bei always_create wird eine neue install.wim erstellt.

Die Install.wim Datei ist ein Container der mehrere Images enthalten kann. Die Images haben einen Namen und eine Beschreibung. Der Name und die Beschreibung des neu erstellten Images werden durch die folgenden Properties gesteuert:

imagename Default = ''

image_description Default = ''

Das Property start_after_capture ist ein Liste von Produkten, welche nach dem Abschluß des Capturevorgangs auf setup gestellt werden sollen. Eine gute Idee ist hier zum Beispiel opsi-local-image-restore, welches das vor dem sysprep erstellte backup wiederherstellt.

Abbildung 12.6. Capture Images: Configed: opsi-local-image-capture

Abbildung 12.7. Capture Images: Schema: sysprep

Abbildung 12.8. Capture Images: opsi-local-image-sysprep 1 : Start

Abbildung 12.9. Capture Images: opsi-local-image-sysprep 2 : Backup vor sysprep

Capture Images: opsi-local-image-sysprep 2 : Backup vor sysprepp

Abbildung 12.10. Capture Images: opsi-local-image-sysprep 3 : Deaktivierung des opsi-client-agent

Abbildung 12.11. Capture Images: opsi-local-image-sysprep 4 : Eigentlicher sysprep Vorgang

Gesteuert durch das Property startcapture kann der Capturevorgang direkt im Anschluß an das sysprep gestartet werden.
Der Capture Vorgang besteht grob aus zwei Phasen:
Der eigentliche Capture Vorgang soll durch das winpe auf der Platte durchgeführt werden. Hierfür muß dieses aber erst präpariert werden und dies ist die erste Phase:

Aktivierung des WinPE als bootbare Partition, Erstellung der nötigen bootrecords und soweit nötig die Deaktivierung von Laufwerksbuchstaben bei anderen Partitionen
Auslesen der opsi-Metadaten über Installierte Produkte auf dem Client und Speicherung dieser Daten auf dem Client in einem temporären Verzeichnis.
Einige Aufräumarbeiten auf dem auszulesenden System.
Schreiben einer Kommandodatei welches die Capturevorgänge beim nächsten WinPE start initiiert.
Bereitstellen weiterer Daten für die Abläufe im WinPE wie z.B. Liste der Produkte aus dem Property start_after_capture
Reboot des Clients

Abbildung 12.12. Capture Images: Schema: Capture 1

In der zweiten Phase startet das WinPE und führt nun den eigentlichen Capturevorgang durch. Im Detail:

Mounten des opsi_depot_rw shares damit auf diesen auch geschrieben werden kann.
Prüfen der Architektur des WinPE (32/64 Bit) und Start des opsi-script in der entsprechenden Architektur.
Herstellung der Verbindung zum opsi-webservice
Reaktivierung der Laufwerksbuchstaben
Im Falle von append mode: Überprüfen ob ein Image mit diesem Namen schon vorhanden ist und gegebenenfalls dieses löschen.
Start des Capturevorgangs. Dabei wird in Abhängigkeit der Windows Version des WinPE bei Windows 7 das Programm imagex aus dem opsi-local-image-capture Produkt verwendet. Bei Windows 8 wird das Programm dism aus dem WinPE verwendet (mit Fallback zu imagex).
Die entstandenen Logfiles werden zusammengeführt.
Überprüfung der Liste der Images im Modifizierten install.wim und setzten dieser Namensliste in das Produktproperty Imagenames des Zielproduktes, so das das neu erstellte Image auch zur Installation ausgewählt werden kann.
Setzen der Produkte aus start_after_capture auf setup.
Deaktivierung der WinPE Partition und Aktivierung der Systempartition (Windows). Bei UEFI Umstellung auf Netboot soweit möglich.
Schreiben der Logdatei zum Server. Dort wird diese an die Logdatei des opsi-local-capture bootimage Laufs angehängt.
Reboot

Abbildung 12.13. Capture Images: Schema: Capture 2

Abbildung 12.14. Capture Images: Capture: Löschen eines existierenden Images

Abbildung 12.15. Capture Images: Capture: Capture und Anhängen (Append) des neuen Images

Zum Ausrollen des erstellten Images dient das per target_product angegebene Zielprodukt. Hier wählen Sie bei imagename das erstellte Image aus und können dieses jetzt ganz normal wie eine andere Windowsinstallation installieren. D.h. sämtliche Standards wie Treiberintegration, Installation des opsi-client-agent finden genauso statt wie wenn Sie ein Original Microsoft Image ausrollen.
Ein wichtiger Punkt bleibt zu beachten: Waren auf dem Rechner von dem das Image erstellt wurde, Software per opsi installiert, so werden diese Installationsdaten bei der Installation des opsi-client-agent wieder hergestellt. Dies hat den Nebeneffekt das anders als normaler weise nicht alle Produkte die auf installed standen bevor die Installation des Betriebssystems begann nun auf setup gesetzt werden. Dieses normale Verhalten würde hier ja dazu führen, dass alle schon im Image installierten Produkte nochmal installiert werden. Daher werden in diesem Fall auch nur die Produkte installiert, welche Sie vor der Installation des Betriebssystems auf setup gestellt haben.

12.10. Erstellen eines eigenen Ubuntu Proxy

Eine brauchbare Anleitung zur Erstellung eines eigenen Ubuntu Proxy finden Sie hier:

http://wiki.ubuntuusers.de/Lokale_Paketquellen/Apt-Cacher-ng

http://www.gambaru.de/blog/2011/10/26/apt-cacher-ng-ein-proxy-server-fur-debian-und-ubuntu/

Kapitel 13. opsi Setup Detector

13.1. Einführung

Die grundsätzlichen Schritte bei der Paketierung und Verteilung einer Software sind:

Analyse des Setups und Erzeugen der Paket-Dateien auf der opsi Workbench
Packen des opsi Paketes
Installation des opsi Paketes auf dem opsi Server
Installation der Software auf den Clients

Der opsi Setup Detector ist ein opsi Werkzeug zur Unterstützung der Software-Paketierung. Von seiner grafischen Benutzeroberfläche können alle Schritte von der Auswahl der zu paketierenden Setup-Datei, über das Erstellen der Installationsverzeichnisse auf der opsi Workbench, bis zur Paketierung und Installation auf dem opsi Server durchgeführt werden. Hierzu arbeitet der Setup Detector mit dem Community Projekt opsi Package Builder zusammen. Der opsi Setup Detector erkennt beim Öffnen einer Setup-Datei, ob es sich um einen bekanneten Installer-Typ handelt und ermittelt automatisch die verfügbaren Informationen aus der Setup-Datei. Mit der Zeit wird durch weitere Erfahrungen mit verschiedenen Installer-Typen und Rückmeldungen der Benutzer die Fähigkeit der automatischen Erkennung verschiedener Setup-Typen sicher noch weiter wachsen. cd

13.2. Vorbedingungen für die Benutzung des opsi Setup Detectors

Der opsi Setup Detector läuft auf Windows Systemen ab Windows XP und ist auf dem Download-Server verfügbar als installierbares opsi-Paket: http://download.uib.de/opsi4.0/experimental/opsi-setup-detector

Falls die Pakete auch gepackt und auf dem Server installiert werden sollen, wird zusätzlich das Community Projekt opsi Package Builder benötigt, welches auf dem gleichen Windows-Rechner zu installieren ist. Weitere Informationen zum opsi Package Builder finden Sie im opsi Forum bei den opsi Community Projekten: https://forum.opsi.org/viewforum.php?f=22

Für die Erzeugung der Pakete ist ein Samba-Share mit Schreibberechtigung auf die opsi Workbench notwendig. Ausserdem ist zu beachten, dass manche Software-Pakete (z.B. manche 64 Bit Software) auch für die Integration ein entsprechendes Windows-System voraussetzen. Das heißt z.B. ein Setup für eine 64bit Windows7 Software kann eventuell nicht auf einem 32bit WindowsXP paketiert werden. Das hängt im Einzelfall ab vom Verhalten des jeweiligen Setups.

Hier nochmal die Voraussetzungen im Überblick:

Windows-Rechner ab Windows XP
opsi package Builder installieren und konfigurieren
Samba-Share mit Schreibrechten zur opsi Workbench
opsi Setup Detector installieren

13.3. Inbetriebnahme des opsi Setup Detectors

Der opsi Setup Detector ist ein mit Lazarus entwickeltes Windows-Programm, das zusätzlich einige Hilfsdateien zur Analyse spezieller Setup-Formate sowie die Vorlagen-Dateien zur Erstellung eines neuen opsi Paketes benötigt. Der opsi Setup Detector mit seinen Zusatz-Dateien ist als opsi Paket verfügbar. Nach der Installation muss noch der Samba-Share auf die opsi Workbench als Basisverzeichnis eingetragen werden und schon kann mit Datei öffnen eine Setup-Datei geöffnet werden, die dann automatisch analysiert wird.

13.3.1. Sprachunterstützung

Beim Start des Programmes wird automatisch ermittelt, unter welcher Sprache das Windows System läuft. Wenn für die Sprache xx eine passende Sprachdatei languages\opsisetupdetector.xx.po gefunden wird, wird diese verwendet. Von Haus aus unterstützt der opsi Setup Detector Deutsch und Englisch. Weitere Sprachen können recht einfach über eine entsprechend zu übersetzende Sprachdatei nachgerüstet werden.

13.3.2. Dateien des opsi Setup Detectors

Folgende Dateien sind im opsi Setup Detector Paket enthalten und werden zur Ausführung benötigt:

opsisetupdetector.exe - der opsi Setup Detector
extractMSI.cmd - Hilfsdatei zur automatischen Analyse von MSI-Dateien
MSIInfo.js - Hilfsdatei zur automatischen Analyse von MSI-Dateien
innounp.exe - Hilfsdatei zur automatischen Analyse von Inno Setup Paketen
innounp.htm - Hilfsdatei zur automatischen Analyse von Inno Setup Paketen
favicon.ico - opsi Icon
languages\ - Verzeichnis für die sprachspezifischen Komponenten
languages\opsisetupdetector.po - default Sprachdatei (Englisch)
languages\opsisetupdetector.de.po - Deutsche Sprachdatei
languages\Help.en.html - Englische Hilfe
languages\Help.de.html - Deutsche Hilfe

Zum Erzeugen der opsi Pakete werden verschiedene Vorlagen-Dateien benötigt. Diese werden dann beim Erzeugen eines neuen Paketes in die opsi Workbench kopiert und entsprechend den Einträgen des im opsi Setup Detector angezeigten Formulars gepatcht:

files2opsi\OPSI\ - Vorlagen für die Paketierung-Informationen
files2opsi\OPSI\control
files2opsi\OPSI\postinst
files2opsi\OPSI\preinst
files2opsi\CLIENT_DATA\ - Vorlagen für die opsiscripte
files2opsi\CLIENT_DATA\setup.opsiscript
files2opsi\CLIENT_DATA\uninstall.opsiscript
files2opsi\CLIENT_DATA\delsub.opsiscript
files2opsi\CLIENT_DATA\check_advanced_exitcode.opsiscript
files2opsi\CLIENT_DATA\check_inno_exitcode.opsiscript
files2opsi\CLIENT_DATA\check_installshield_exitcode.opsiscript
files2opsi\CLIENT_DATA\check_installshieldmsi_exitcode.opsiscript
files2opsi\CLIENT_DATA\check_inno_exitcode.opsiscript
files2opsi\CLIENT_DATA\check_msi_exitcode.opsiscript

13.4. Das Menü des opsi Setup Detektors

Das Menü am oberen linken Rand enthält die Punkte

Datei - (öffnet ein Untermenü, s.u.)
Hilfe - interne Hilfe aufrufen. Um die enthaltenen Links zu verwenden, kann die Hilfe-Datei %ProgramFilesDir%\opsiSetupDetector\languages\Help.de.html alternativ auch direkt in einem Browser angezeigt werden.
Info - Programm-Version anzeigen

Der Menüpunkt Datei öffnet ein Untermenü mit:

Datei öffnen und analysieren - Auswählen des zu analysiernden Setup. Dieser Menüpunkt hat die gleiche Funktion wie der Datei öffnen Button auf dem Analysiere Tab rechts unten und öffnet einen Datei Auswahl Dialog, der alle Dateien anzeigt. Der Datei Auswahl Dialog auf den jeweiligen Installer Tabs zeigt nur Dateien an mit der Endung .MSI(MSI Tab) bzw. .EXE (alle anderen Installer Tabs).
Schreibe Logdatei - Der Inhalt des Analyze Tab wird als Logdatei geschrieben. Der Name der erzeugten Datei entspricht %TEMP%\opsitmp\opsiSetupDetector.log und wird beim Erzeigen in einem Dialog angezeigt. Die Logdatei wird direkt beim Aufruf dieses Kommandos erzeugt und enthält nur die Informationen, die zum Zeitpunkt des Aufrufs im Analysiere Tab stehen.
Beenden - beendet den opsi Setup Detektor

13.5. Automatische Analyse eines Setup-Paketes

Nach dem Öffnen einer Setup-Datei mit Datei öffnen wird diese automatisch analysiert und, falls es sich um einen bekannten Installer-Typ handelt, automatisch auf den entsprechenden Tab gewechselt. Falls der Installer-Typ nicht erkannt wird, bleibt weiterhin das Analysiere Tab stehen. Auch wenn der Installer-Typ erkannt wurde, kann jederzeit auf das Analysiere Tab zurück gewechselt werden um zu sehen, was bei der automatischen Analyse gefunden wurde.

Bei der Analyse einer MSI-Datei ist bereits durch die Endung MSI bekannt, dass es sich um ein MSI-Paket handelt. Einer EXE-Datei sieht man es aber nicht an der Endung an, mit welchem Installer-Typ sie erstellt wurde. Deshalb wird die EXE-Datei vom opsi Setup Detector automatisch nach bestimmten Kennungen durchsucht. Falls die Kennung eines bekannten Installer-Typs gefunden wurde, wird direkt auf den Tab dieses Installers gewechselt. Falls kein bekannter Setup-Typ erkannt wurde, wird die Datei nach bestimmten allgemeinen Stichworten (z.B. "Installer" oder "Setup") durchsucht und die entsprechenden Zeilen werden auf dem Analysiere Tab ausgegeben. Darin können auch kryptische Passagen und bestimmte Fehlermeldungen enthalten sein, die das Setup-Programm in bestimmten Fällen, z.B. bei aufgetretenen Fehlern während der Installation, ausgeben möchte, wie z.B.:

o@dejDs@s@t@t@du@u@<v@w@w@lx@Hy@x@x{@X|@|@@@@L@x@@Inno Setup Setup Data
Das Setup hat einen schwerwiegenden Fehler erkannt und wird abgebrochen

Dies besagt aber nur, dass diese Zeichen innerhalb des Setups gefunden wurden und im Analysiere Tab angezeigt werden, da sie einem der verwendeten Suchmuster entsprechen. Oben kommt z.B. das Suchmuster "Setup" vor. Bei einem nicht automatisch erkannten Setup-Typ lässt sich in diesen Angaben eventuell ein Hinweis finden, um welchen Installer-Typ es sich handeln könnte. Alle Angaben auf dem Analysiere Tab, die eingeleitet werden von:

Analyzing: F:\<setup.exe>

und abgeschlossen werden mit:

default grep finished.

entstammen dieser automatischen Analyse und können im Normalfall unbeachtet bleiben. Falls der Setup-Typ erkannt wurde, steht dieser unterhalb von "default grep finished". Dass ein bekannter Setup Typ erkannt wurde merkt man auch daran, dass automatisch auf den entsprechenden Tab gewechselt wurde.

Je nach dem gefundenen Installer-Typ sind im Analysiere Tab noch weitere Informationen zu finden zur weiteren Analyse des Setups. Diese werden in den jeweiligen Kapiteln der entsprechenden Installer-Typen behandelt.

Der Inhalt des Analysiere Tabs wird vor einer neuen Analyse gelöscht und enthält dementsprechend nur Informationen zu dem aktuellen Setup.

13.6. Setup-EXE mit eingebettetem MSI

Bevor auf die einzelnen Installer-Typen eingegangen wird, noch ein paar allgemeine Bemerkungen zu Setup-Dateien mit eingebettetem MSI: derzeit werden Advanced Installer oder InstallShield basierte EXE-Dateien mit eingebettetem MSI erkannt. Das MSI Paket wird automatisch entpackt und die analysierten Eigenschaften im Advanced+MSI Tab bzw. InstallShield+MSI Tab sowie zusätzlich im MSI Tab angezeigt. Eine EXE-Datei mit eingebettetem MSI kann auch mehrere unterschiedliche MSI-Pakete enthalten, z.B. für unterschiedliche Windows-Versionen oder 32bit/64bit. Das Setup entscheidet dann meist je nach den System-Gegebenheiten automatisch, welches MSI-Paket ausgepackt und verwendet wird. In diesem Fall erhält man bei Analyse des Paketes mit dem opsi Setup Detector nur das für das aktuelle System, auf dem der opsi Setup Detector läuft, passende MSI-Paket. Solche EXE-Dateien haben oft eine Kommandozeilen-Hilfe, die weitere Auskunft über die enthaltenen Pakete und die Aufruf-Möglichkeiten gibt. Auch kann eine Setup-EXE eventuell je nach System oder sonstigen Eigenschaften verschiedene MST-Dateien verwenden. Kurz und gut, eine Setup.EXE kann sich je nach den Umständen unterschiedlich verhalten. In den meisten Fällen braucht man lediglich den MSI Code des eingebetteten MSI für das opsi Deinstallations-Script. Hierbei ist zu beachten, dass ein MSI-Paket für 32bit und 64bit im Normalfall einen unterschiedlichen MSI Codes enthält. Das opsi Deinstallations-Script muss dann dafür sorgen, dass es alle diese MSI Codes kennt und bei der Deinstallation handhabt. Bei solchen Paketen sollte man den opsi Setup Detector auf unterschiedlichen Plattformen laufen lassen, um alle MSI-Kennungen zu erfassen. Wenn der opsi Setup Detector ein eingebettetes MSI findet, analysiert er dieses und zeigt die Inhalte zusätzlich im MSI Tab an. Es kann dann auch das MSI Tab als Basis für das opsi Paket genommen werden, aber im Normalfall sollte man besser die EXE-Datei nehmen, da auf diese Weise schneller eine neue Version eingebunden werden kann und die EXE-Datei eventuell auch zusätzliche Dinge tut.

Bei der Analyse wird das MSI und andere Komponenten der EXE-Datei in das Verzeichnis %TEMP%\opsitmp entpackt. Zuvor wird eventueller anderer Inhalt gelöscht, so dass im Verzeichnis %TEMP%\opsitmp immer nur Dateien des aktuell zu analysierenden Setups zu finden sind.

13.7. Unterstützte Installer-Typen

Die einzelnen Installer-Typen sind sehr unterschiedlich bezüglich der Standardisierung ihrer Struktur und automatisierten Zugänglichkeit. Bei einem MSI-Paket oder einem auf Inno-Setup basierenden Setup kann eine Menge nützlicher Informationen automatisch detektiert werden, während andere Installer-Typen, wie z.B. NSIS, keine internen Informationen des Setups zugreifbar machen. In vielen Fällen bringt die automatisierte Analyse gute Ergebnisse, aber es kann auch immer wieder Fälle geben, bei denen die automatisierte Vorgehensweise nicht funktioniert oder zumindest händige Nacharbeit erfordert. Mit zunehmenden Erfahrungen beim Einsatz wird der opsi Setup Detector seine automatisierten Fähigkeiten mit der Zeit erweitern.

Da MSI-Pakete der wichtigste und am meisten verwendete Installer Typ sind, folgt nach dem Analysiere Tab der MSI Tab, danach alle weiteren Installer Typ Tabs in alphabetischer Reihenfolge.

13.7.1. Installer-Typ MSI

MSI-Dateien sind das Installations-Datenformat des Microsoft Windows Installers. Setups vom Installer-Typ MSI sind bereits an der Endung MSI als solche zu erkennen. Das Paketformat ist standardisiert, so dass der opsi Setup Detector automatisch weitere Informationen aus dem Paket auslesen und im MSI Tab, auf den automatisch gewechselt wird, anzeigen kann. Die im Analysiere Tab angezeigten Informationen sehen bei einem MSI-Paket z.B. so aus:

Analyzing MSI: F:\Setups\MSI\7-zip\7-Zip.msi

Microsoft (R) Windows Script Host, Version 5.8
Copyright (C) Microsoft Corporation 1996-2001. Alle Rechte vorbehalten.

MSI file: F:\uib\setupdetector\Setups\MSI\7-zip\7-Zip.msi
Manufacturer: Igor Pavlov
ProductName: 7-Zip 4.57
ProductVersion: 4.57.00.0
ProductCode: {23170F69-40C1-2701-0457-000001000000}
UpgradeCode: {23170F69-40C1-2701-0000-000004000000}
MSI file size is: 0,9 MB
Estimated required space is: 5,2 MB

get_MSI_info finished

Diese Informationen werden aus dem MSI-Paket gelesen und automatisch in die einzelnen Felder des MSI Tabs übernommen. Diese Angaben werden benötigt zum Patchen der opsi Installations-Scripte:

MSI Datei: Name der geöffneten MSI Datei
opsi Product ID: dies ist der Name des zu erzeugenden opsi Paketes und wird aus dem weiter unten stehenden Produkt Namen erzeugt, wobei Leerzeichen und andere ungültigen Zeichen durch ein - ersetzt werden. Die vorgeschlagene opsi Product ID kann natürlich geändert werden.
Produkt Name: der aus dem MSI Paket ausgelesene Name der zu installierenden Software. Diesen Namen möchte man wahrscheinlich im Normalfall beibehalten.
Produkt Version: die ausgelesene Version der zu installierenden Software. Auch diese Angabe möchte man wohl in vielen Fällen beibehalten. Sie darf allerdings nur Ziffern und Punkte enthalten, da sie für die Versionierung des opsi Paketes verwendet wird.
MSI Produkt Code: der aus dem Paket ausgelesene Produkt-Code, welcher für das Deinstallations-Script benötigt wird. Vorsicht: ein MSI-Paket für 32bit und 64bit hat normalerweise einen jeweils unterschiedlichen Produkt Code.
erforderlich: dieser vorgeschlagene Wert stammt nicht aus dem MSI-Paket, sondern ist geschätzt als sechsmal die Größe der MSI-Datei und sollte gegebenenfalls angepasst werden. Bei der Installation auf dem Client prüft das setup.opsiscript, ob entsprechend dieser Angabe genügend Plattenplatz vorhanden ist.
Größe MSI: die ermittelte Größe des MSI-Paketes.
MST Datei: wird im gleichen Verzeichnis (also dort, wo die MSI-Datei liegt) eine MST-Datei (Transform-Datei) gefunden, wird diese eingetragen und beim Aufruf des Setup verwendet. Gegebenenfalls kann mit dem Auswahl-Button rechts neben dem Feld eine andere MST-Datei gewählt werden oder durch Entfernen des MST Datei-Häkchens vor dem Feld die Verwendung der MST-Datei ausgeschaltet werden.
Beschreibung: In diesem Feld wird als Vorgabe der Produkt Name vorgegeben und sollte mit weiteren Hinweisen ergänzt werden, die dann als Produktbeschreibung des opsi Paketes gesetzt werden.
Lizenz pflichtig: Wenn dieses Häkchen gesetzt wird, wird beim Patchen des opsiscripts license=true gesetzt.

Im Falle einer EXE-Datei mit eingebettetem MSI wird das MSI Paket automatisch extrahiert und die gefundenen Informationen zusätzlich zum Tab der EXE-Date (Advanced+MSI oder InstallShied+MSI)ebenfalls hier im MSI Tab angezeigt.

13.7.2. Installer-Typ Advanced+MSI

Der Advanced Installer ist ein Werkzeug zur Erstellung von MSI-Paketen, die auch in EXE-Dateien eingebettet sein können. Erkennt der opsi Setup Detektor eine EXE-Datei als ein mit Advanced Installer eingebettetes MSI-Paket, wird die MSI-Datei automatisch aus der EXE-Datei extrahiert und analysiert und die gefundenen Informationen im Tab Advanced+MSI angezeigt. Die entsprechenden Informationen werden zusätzlich auch im MSI Tab eingetragen. Nähere Angaben zum MSI Tab siehe Kapitel Abschnitt 13.7.1, „Installer-Typ MSI“.

Beim automatischen Auspacken einer eingebetteten MSI-Datei wird im Analysiere Tab Folgendes angezeigt:

xxxxxxxxxxxxxxxxxxxxxxxxx
Analyzing AdvancedMSI Setup:
F:\Setups\AdvancedMSI\Phase5\phase562install.exe
Analyzing MSI from Setup
F:\Setups\AdvancedMSI\Phase5\phase562install.exe
cmd.exe /C "F:\Setups\AdvancedMSI\Phase5\phase562install.exe" /extract:e:\Temp\opsitmp\
!! PLEASE WAIT !!
!! PLEASE WAIT !! Extracting and analyzing MSI ...
!! PLEASE WAIT !!
e:\Temp\opsitmp\*.msi
Analyzing MSI: e:\Temp\opsitmp\phase5.msi

Das MSI wird in das Verzeichnis =%TEMP%\opsitmp= extrahiert und analysiert. Mit dem Ergebnis werden die Felder des Advanced+MSI Tab gefüllt:

Setup-Datei: Name der analysierten Setup-Datei
opsi Product ID: dies ist der Name des zu erzeugenden opsi Paketes und wird aus dem weiter unten stehenden Produkt Namen erzeugt, wobei Leerzeichen und andere ungültigen Zeichen durch ein - ersetzt werden. Die vorgeschlagene opsi Product ID kann natürlich geändert werden.
Produkt Name: der aus dem MSI Paket ausgelesene Name der zu installierenden Software. Diesen Namen möchte man wahrscheinlich im Normalfall beibehalten.
Produkt Version: die ausgelesene Version der zu installierenden Software. Auch diese Angabe möchte man wohl in vielen Fällen beibehalten. Sie darf allerdings nur Ziffern und Punkte enthalten, da sie für die Versionierung des opsi Paketes verwendet wird.
MSI Produkt Code: der aus dem Paket ausgelesene Produkt-Code, welcher für das Deinstallations-Script benötigt wird. Vorsicht: ein Advanced-Installer-Paket kann unterschiedliche MSI-Pakete mit unterschiedlichem MSI Produkt Code für z.B. 32bit und 64bit enthalten und es hängt vom System des Paketierungs-PCs ab, welches MSI-Paket ausgepackt und analysiert wird. Meist kann ein 64bit-Paket nicht auf einem 32bit-Rechner entpackt werden. Zur Paketierung einer 64bit-Software wird somit auch ein 64bit-Paketierung-Rechner gebraucht.
erforderlich: dieser vorgeschlagene Wert ist geschätzt als sechsmal die Größe der Setup-Datei und kann gegebenenfalls angepasst werden. Bei der Installation auf dem Client prüft das setup.opsiscript, ob entsprechend dieser Angabe genügend Plattenplatz vorhanden ist.
Dateigröße: die Größe der Setup-Datei.
Beschreibung: In diesem Feld wird als Vorgabe der Produkt Name vorgegeben und sollte mit weiteren Hinweisen ergänzt werden, die dann als Produktbeschreibung des opsi Paketes gesetzt werden.
Lizenz pflichtig: Wenn dieses Häkchen gesetzt wird, wird beim Patchen des opsiscripts $LicenseRequired$=true gesetzt.

Signatur Advanced+MSI: bei der automatischen Erkennung einer Advanced+MSI-Datei wird in der EXE-Datei gesucht nach dem Marker:

name="microsoft.windows.advancedinstallersetup

13.7.3. Installer-Typ Inno Setup

Mit Inno Setup erstellte EXE-Dateien sind weitgehend standardisiert und enthalten eine spezifische Datei mit Namen install_script.iss, die automatisch aus der EXE-Datei extrahiert und analsiert werden kann. Mit den ermittelten Informationen werden die Felder des Inno Setup Tab gefüllt und dieser angezeigt. Wenn man zurück in den Analysiere Tab klickt, sieht man ungefähr folgende Angaben:

............................................
Analyzing: F:\Setups\Inno\openssl\Win32OpenSSL_Light-1_0_0i.exe
stringsgrep started (verbose:false, skipzero:false)
found string "<description>Inno Setup</description>"
detected Inno Setup
stringsgrep completed (verbose:false, skipzero:false)
............................................
Analyzing Inno-Setup:
extract install_script.iss from F:\Setups\Inno\openssl\Win32OpenSSL_Light-1_0_0i.exe to
C:\ProgramData\opsi setup detector\INNO\Win32OpenSSL_Light-1_0_0i\install_script.iss
"E:\Program Files (x86)\opsiSetupDetector\innounp.exe" -x -a -y -d"C:\ProgramData\opsi setup detector\INNO\Win32OpenSSL_Light-1_0_0i" F:\Setups\Inno\openssl\Win32OpenSSL_Light-1_0_0i.exe install_script.iss
; Version detected: 5402
#66 install_script.iss
C:\ProgramData\opsi setup detector\INNO\Win32OpenSSL_Light-1_0_0i\install_script.iss
........
[Setup]
AppName=OpenSSL Light (32-bit)
AppVerName=OpenSSL 1.0.0i Light (32-bit)
AppPublisher=OpenSSL Win32 Installer Team
AppPublisherURL=http://www.openssl.org
AppSupportURL=http://www.slproweb.com
AppUpdatesURL=http://www.slproweb.com/products/Win32OpenSSL.html
DefaultDirName={sd}\OpenSSL-Win32
DefaultGroupName=OpenSSL
OutputBaseFilename=Win32OpenSSL_Light-1_0_0i
Compression=bzip2
........
Setup file size is: 1,9 MB
Estimated required space is: 11,1 MB
........
get_inno_info finished
Inno Setup detected

Die Informationen aus install_script.iss werden automatisch in die einzelnen Felder des Inno Setup Tabs übernommen und dann verwendet zum Patchen der opsi Installations-Scripte:

Setup-Datei: Name der analysierten Setup-Datei
opsi Product ID: dies ist der Name des zu erzeugenden opsi Paketes und wird aus dem weiter unten stehenden Produkt Namen erzeugt, wobei Leerzeichen und andere ungültigen Zeichen durch ein - ersetzt werden. Die vorgeschlagene opsi Product ID kann natürlich geändert werden.
Produkt Name: der aus install_script.iss ausgelesene Name der zu installierenden Software. Diesen Namen möchte man wahrscheinlich im Normalfall beibehalten.
Produkt Version: die ausgelesene Version der zu installierenden Software. Auch diese Angabe möchte man wohl in vielen Fällen beibehalten. Sie darf allerdings nur Ziffern und Punkte enthalten, da sie für die Versionierung des opsi Paketes verwendet wird.
Install. Verzeichnis: dies ist der Name des Verzeichnisses, in das die Software auf dem Client installiert wird. Dieses wird gebraucht zum Patchen des Deinstallations-Skriptes. Das Installations-Verzeichnis wird aus install_script.iss ausgelesen und kann in vielen Fällen direkt verwendet werden. Manchmal kann die Angabe des Installations-Verzeichnisses auch Inno Setup-spezifische Konstanten und Variablen enthalten, die in geschweiften Klammern angegeben sind. Einige der Inno Setup Variablen werden automatisch in opsi Syntax übersetzt, z.B. Es sind aber auch andere Einträge möglich. Hier ist dann händige Nacharbeit angesagt, so dass in diesem Feld nur Bezeichner stehen, die vom opsi Installer (Winst) verstanden werden. In obigem Fall wäre das z.B.: %Systemdrive%\lazarus Eventuell kann hierzu auch der install_script.iss Eintrag UninstallDisplayName ausgewertet werden. Eine Beschreibung der Inno Setup Variablen ist in der Inno Setup Hilfe zu finden, z.B. http://www.jrsoftware.org/ishelp/index.php
erforderlich: dieser vorgeschlagene Wert stammt nicht aus der install_script.iss, sondern ist geschätzt als sechsmal die Größe der Setup-Datei und sollte gegebenenfalls angepasst werden. Bei der Installation auf dem Client prüft das setup.opsiscript, ob entsprechend dieser Angabe genügend Plattenplatz vorhanden ist.
Dateigröße: die ermittelte Größe der Setup-Datei.
Beschreibung: In diesem Feld wird als Vorgabe der Produkt Name vorgegeben und sollte mit weiteren Hinweisen ergänzt werden, die dann als Produktbeschreibung des opsi Paketes gesetzt werden.
Lizenz pflichtig: Wenn dieses Häkchen gesetzt wird, wird beim Patchen des opsiscripts $LicenseRequired$=true gesetzt.

Signatur Inno Setup: bei der automatischen Erkennung einer Inno Setup-Datei wird in der EXE-Datei gesucht nach dem Marker:

<description>inno setup</description>

13.7.4. Installer-Typ InstallShield

Mit Installshield erstellte EXE-Dateien sind für eine automatisierte Analyse nicht zugänglich. Es kann lediglich automatisch erkannt werden, dass es sich um ein Installshield Setup handelt. Daher werden die vorgeschlagenen Werte aus dem Namen der Setup-Datei erstellt. Wenn diese Datei lediglich Setup.exe heißt, wird in den Feldern auch nur Setup eingetragen. Hinzu kommt noch, dass es von der jeweiligen Version des verwendeten Installshield abhängt, welche Aufruf-Parameter die Setup-Datei sowie das Deinstallations-Programm akzeptieren. Bei einem Installshield-Paket ist also weitgehend Handarbeit angesagt. Der erste Test könnte darin bestehen, die Aufrufparameter des Setup zu ermitteln, z.B. durch Setup.exe -?. Da mit InstallShield erstellte Pakete inzwischen kaum mehr reines InstallShield, sondern zunehmend interne MSI-Pakete enthalten, kommen bei der Paketierung reine InstallShield-Pakete kaum mehr vor, was den Paketierer in Zukunft von einem chronischen Sorgenkind befreit.

Wenn man zurück in den Analysiere Tab klickt, sieht man ungefähr folgende Angaben:

.....................................
Analyzing: F:\uib\setupdetector\Setups\InstallShield\viclient\VMware-viclient.exe
stringsgrep started (verbose:false, skipzero:false)
found string "InstallShield"
detected InstallShield Setup
stringsgrep completed (verbose:false, skipzero:false)
.....................................
Analyzing InstallShield-Setup:
Setup file size is: 32,1 MB
Estimated required space is: 192,6 MB
........
get_InstallShield_info finished
InstallShield Setup detected

Die einzelnen Felder des InstallShield Tab sind:

Setup-Datei: Name der analysierten Setup-Datei
opsi Product ID: dies ist der Name des zu erzeugenden opsi Paketes und wird aus dem weiter unten stehenden Produkt Namen erzeugt, wobei Leerzeichen und andere ungültigen Zeichen durch ein - ersetzt werden. Die vorgeschlagene opsi Product ID kann natürlich geändert werden.
Produkt Name: der Name der zu installierenden Software. Dieser muss evtl. händig korrigiert werden
Produkt Version: die aus dem Name der Setup-Datei ermittelte Versionsnummer muss wahrscheinlich händig korrigiert werden. Sie darf nur Ziffern und Punkte enthalten, da sie für die Versionierung des opsi Paketes verwendet wird.
Install. Verzeichnis: dies ist der Name des Verzeichnisses, in das die Software auf dem Client installiert wird. Dieses wird gebraucht zum Patchen des Deinstallations-Skriptes und muss händig eingetragen werden.
erforderlich: dieser vorgeschlagene Wert ist geschätzt als sechsmal die Größe der Setup-Datei und sollte gegebenenfalls angepasst werden. Bei der Installation auf dem Client prüft das setup.opsiscript, ob entsprechend dieser Angabe genügend Plattenplatz vorhanden ist.
Dateigröße: die ermittelte Größe der Setup-Datei.
Beschreibung: In diesem Feld wird als Vorgabe der Produkt Name vorgegeben und sollte mit weiteren Hinweisen ergänzt werden, die dann als Produktbeschreibung des opsi Paketes gesetzt werden.
Lizenz pflichtig: Wenn dieses Häkchen gesetzt wird, wird beim Patchen des opsiscripts $LicenseRequired$=true gesetzt.

Signatur InstallShield: bei der automatischen Erkennung einer InstallShield-Datei ohne eingebettetes MSI wird in der EXE-Datei gesucht nach dem Marker:

<description>InstallShield.Setup</description>

ohne dass der Marker für ein eingebettetes MSI gefunden wird. Falls auch der Marker für ein eingebettetes MSI gefunden wird, handelt es sich um ein InstallShield+MSI (s.u.).

13.7.5. Installer-Typ InstallShield+MSI

Mit InstallShield erstellte Software-Pakete enthalten meist intern eine (oder mehrere?) MSI-Dateien. Um die MSI-Datei zu extrahieren, wird ein Batch gestartet, der das Setup startet und zehn Sekunden wartet, welche MSI-Datei beim Starten ausgepackt wird. Dann wird der Setup-Task abgeschossen. Das extrahierte MSI-Paket wird dann automatisch analysiert und die Informationen in den InstallShield+MSI Tab sowie den MSI Tab geschrieben. Hier hängt es eventuell auch von der jeweiligen EXE-Datei ab, ob und wenn ja welches MSI-Paket sie auspackt. Eventuell packt sie keines aus, weil das Betriebssystem unpassend ist oder weil erst noch an der GUI eine Frage beantwortet werden muss, bevor ein MSI ausgepackt wird. Falls die automatische Extrahierung nicht klappt, sollte das MSI händig ausgepackt werden und als MSI analysiert werden. Diese Angaben können dann in den InstallShield+MSI Tab über tragen werden.

Im Analysiere Tab sind typischerweise solche Einträge zu finden:

.....................................
Analyzing: F:\Setups\Installshield-MSI\javavm\jre-6u22-windows-x64.exe
stringsgrep started (verbose:false, skipzero:false)
found strings "Installer,MSI,Database" and "InstallShield"
detected InstallShield+MSI Setup (InstallShield with embedded MSI)
found strings "Installer,MSI,Database" and "InstallShield"
detected InstallShield+MSI Setup (InstallShield with embedded MSI)
stringsgrep completed (verbose:false, skipzero:false)
.....................................
Analyzing InstallShield+MSI Setup: F:\Setups\Installshield-MSI\javavm\jre-6u22-windows-x64.exe
Analyzing MSI from InstallShield Setup F:\Setups\Installshield-MSI\javavm\jre-6u22-windows-x64.exe
cmd.exe /C E:\Program Files (x86)\opsiSetupDetector\extractMSI.cmd "F:Setups\Installshield-MSI\javavm\jre-6u22-windows-x64.exe"
!! PLEASE WAIT !!
!! PLEASE WAIT !! Extracting and analyzing MSI ...
!! PLEASE WAIT !!
e:\Temp\opsitmp\*.msi
Analyzing MSI: e:\Temp\opsitmp\phase5.msi
cmd.exe /C cscript.exe "E:\Program Files (x86)\opsiSetupDetector\msiinfo.js" "e:\Temp\opsitmp\phase5.msi"
........
Microsoft (R) Windows Script Host, Version 5.8
Copyright (C) Microsoft Corporation 1996-2001. Alle Rechte vorbehalten.

MSI file: e:\Temp\opsitmp\phase5.msi
Manufacturer: Systemberatung Schommer
ProductName: Phase 5 HTML-Editor
ProductVersion: 5.6.2.3
ProductCode: {20B1B020-DEAE-48D1-9960-D4C3185D758B}
UpgradeCode: {C63B6E47-6A28-44B6-A2C9-2BF084491FAD}
MSI file size is: 0,3 MB
Estimated required space is: 1,7 MB
........
get_MSI_info finished
Setup file size is: 15,4 MB
Estimated required space is: 92,7 MB
........
get_InstallShield_info finished
InstallShield+MSI Setup detected

Falls die automatische Extrahierung des MSI geklappt hat, werden die gefundenen Werte automatisch in den InstallShield+MSI Tab eingetragen:

Setup-Datei: Name der analysierten Setup-Datei
opsi Product ID: dies ist der Name des zu erzeugenden opsi Paketes und wird aus dem weiter unten stehenden Produkt Namen erzeugt, wobei Leerzeichen und andere ungültigen Zeichen durch ein - ersetzt werden. Die vorgeschlagene opsi Product ID kann natürlich geändert werden.
Produkt Name: der aus dem MSI Paket ausgelesene Name der zu installierenden Software. Diesen Namen möchte man wahrscheinlich im Normalfall beibehalten.
Produkt Version: die ausgelesene Version der zu installierenden Software. Auch diese Angabe möchte man wohl im Normalfall beibehalten. Sie darf nur Ziffern und Punkte enthalten, da sie für die Versionierung des opsi Paketes verwendet wird.
MSI Produkt Code: der aus dem Paket ausgelesene Produkt-Code, welcher für das Deinstallations-Script benötigt wird. Vorsicht: ein MSI-Paket kann unterschiedliche MSI Produkt Codes für z.B. 32bit und 64bit enthalten und es hängt vom System des Paketierungs-PCs ab, welches MSI-Paket ausgepackt und analysiert wird. Meist kann ein 64bit-Paket nicht auf einem 32bit-Rechner entpackt werden. Zur Paketierung einer 64bit-Software wird somit auch ein 64bit-Paketierung-Rechner gebraucht.
erforderlich: dieser vorgeschlagene Wert ist geschätzt als sechsmal die Größe der Setup-Datei und kann gegebenenfalls angepasst werden. Bei der Installation auf dem Client prüft das setup.opsiscript, ob entsprechend dieser Angabe genügend Plattenplatz vorhanden ist.
Dateigröße: die Größe der Setup-Datei.
Beschreibung: In diesem Feld wird als Vorgabe der Produkt Name vorgegeben und sollte mit weiteren Hinweisen ergänzt werden, die dann als Produktbeschreibung des opsi Paketes gesetzt werden.
Lizenz pflichtig: Wenn dieses Häkchen gesetzt wird, wird beim Patchen des opsiscripts $LicenseRequired$=true gesetzt.

Signatur InstallShield+MSI: bei der automatischen Erkennung einer InstallShield-Datei mit eingebettetem MSI wird in der EXE-Datei gesucht nach dem Marker für InstallShield und dem Marker für ein eingebettetes MSI:

<description>InstallShield.Setup</description>
...
installer,msi,database

13.7.6. Installer-Typ NSIS

NSIS Pakete zeichnen sich insbesondere dadurch aus, dass sie kompakt und schnell sind. Allerdings ist es dadurch nicht möglich, dem Paket automatisiert nähere Angaben zu entlocken. Ausser der Erkennung, dass es sich um ein NSIS-Paket handelt, können alle weiteren Informationen lediglich aus dem Namen der Setup-Datei vorgeschlagen werden. Hier ist also händige Nacharbeit angesagt.

Die Einträge im Analysiere Tab sehen typischerweise so aus:

...................................
Analyzing: F:\Setups\NSIS\7z920\7z920.exe
stringsgrep started (verbose:false, skipzero:false)
found string "Nullsoft.NSIS.exehead"
detected NSIS Setup
stringsgrep completed (verbose:false, skipzero:false)
...................................
Analyzing NSIS-Setup:
Setup file size is: 1,1 MB
Estimated required space is: 6,4 MB
........
get_nsis_info finished
NSIS (Nullsoft Install System) detected

Die Bedeutung der einzelnen Felder des NSIS Tab:

Setup-Datei: Name der analysierten Setup-Datei
opsi Product ID: dies ist der Name des zu erzeugenden opsi Paketes und wird aus dem weiter unten stehenden Produkt Namen erzeugt, wobei Leerzeichen und andere ungültigen Zeichen durch ein - ersetzt werden. Die vorgeschlagene opsi Product ID kann natürlich geändert werden.
Produkt Name: der Name der zu installierenden Software. Dieser muss evtl. händig korrigiert werden
Produkt Version: die aus dem name der Setup-Datei ermittelte Versionsnummer muss wahrscheinlich händig korrigiert werden. Sie darf nur Ziffern und Punkte enthalten, da sie für die Versionierung des opsi Paketes verwendet wird.
Install. Verzeichnis: dies ist der Name des Verzeichnisses, in das die Software auf dem Client installiert wird. Dieses wird gebraucht zum Patchen des Deinstallations-Skriptes und muss händig eingetragen werden.
erforderlich: dieser vorgeschlagene Wert ist geschätzt als sechsmal die Größe der Setup-Datei und sollte gegebenenfalls angepasst werden. Bei der Installation auf dem Client prüft das setup.opsiscript, ob entsprechend dieser Angabe genügend Plattenplatz vorhanden ist.
Dateigröße: die ermittelte Größe der Setup-Datei.
Beschreibung: In diesem Feld wird als Vorgabe der Produkt Name vorgegeben und sollte mit weiteren Hinweisen ergänzt werden, die dann als Produktbeschreibung des opsi Paketes gesetzt werden.
Lizenz pflichtig: Wenn dieses Häkchen gesetzt wird, wird beim Patchen des opsiscripts $LicenseRequired$=true gesetzt.

Signatur NSIS: bei der automatischen Erkennung einer NSIS Setup-Datei wird in der EXE-Datei gesucht nach einem der Marker:

Nullsoft.NSIS.exehead
...
Nullsoft Install System

13.8. Erzeugen eines neuen opsi Paketes

Wenn das Setup analysiert und die Felder des entsprechenden Tab gefüllt sind, kann mit dem Button Erzeuge opsi Paket (rechts unten) das neue Produkt erzeugt werden.

Achtung:

als Basisverzeichnis muss ein beschreibbarer Share auf die opsi Workbench eingetragen sein
aus Sicherheitsgründen kann ein opsi Paket nur dann neu erzeugt werden, wenn es noch nicht vorhanden ist. Falls ein bestehendes Paket überschrieben werden soll, muss zuerst das Verzeichnis von der opsi Workbench gelöscht werden.

Links neben dem Button Erzeuge opsi Paket befinden sich drei mögliche Auswahl Optionen, die sich auf die Funktion des Buttons beziehen:

opsi Paket erzeugen: falls noch nicht vorhanden, wird das Verzeichnis für das neue opsi Paket erzeugt und die entsprechenden Dateien erstellt und gepatcht. Es wird kein Paket gebaut.
opsi Paket erzeugen und opsi Packet Builder starten: wie oben werden das Verzeichnis und die Dateien erzeugt und dann zum Packen und installieren der opsi Packet Builder gestartet. Die Paket Daten werden beim Aufruf in diesen übernommen und das Paket kann gebaut und installiert werden. Danach sollte der opsi Packet Builder wieder geschlossen werden, damit er für den nächsten Aufruf neu gestartet werden kann.
erzeugen und auto -build -install -quiet: wie oben werden das Verzeichnis und die Dateien erzeugt und dann zum Packen und installieren der opsi Packet Builder gestartet. Die Paket Daten werden beim Aufruf in diesen übernommen und das Paket wird automatisch gebaut und installiert, falls die entsprechenden Häkchen gesetzt sind. Wenn z.B. das Paket nur gepackt, aber nicht installiert werden soll, kann das Häkchen bei install entfernt werden. Zusätzlich kann das Häkchen bei quiet gesetzt werden, dann werden die angewählten Funktionen automatisch ausgeführt, ohne dass die Benutzeroberfläche des opsi Packet Builders angezeigt wird. Ansonsten sollte der opsi Packet Builder dann wieder geschlossen werden, damit er für den nächsten Aufruf neu gestartet werden kann.

Zu Installation, Konfiguration und Bedienung des Community Projektes opsi Packet Builder siehe https://forum.opsi.org/viewforum.php?f=22

Kapitel 14. Sonstiges

14.1. Changelogs:

14.1.1. Changelog opsi-configed

opsi-configed (4.0.5.1.2-1) testing; urgency=low

use remoteurl instead of depotserver url for install package as well

-- rupert roeder <roeder@bonifax.uib.local>  Wed, 22 Aug 2014 09:38:22 +0200

opsi-configed (4.0.5.1.1-1) testing; urgency=low

use remoteurl instead of depotserver url

-- rupert roeder <roeder@bonifax.uib.local>  Wed, 21 Aug 2014 09:38:22 +0200

opsi-configed (4.0.5.1-1) testing; urgency=low

redesign of some data structures

-- rupert roeder <roeder@bonifax.uib.local>  Wed, 20 Aug 2014 09:38:22 +0200

opsi-configed (4.0.4.2.9-1) experimental; urgency=low

message window when heap overflow

-- rupert roeder <roeder@bonifax.uib.local>  Wed, 13 Apr 2014 09:38:22 +0200

opsi-configed (4.0.4.2.7-1) experimental; urgency=low

less fat data transmission for swaudit

-- rupert roeder <roeder@bonifax.uib.local>  Wed, 09 Apr 2014 09:38:22 +0200

opsi-configed (4.0.4.2.5-1) experimental; urgency=low

integrating accelerated swaudit into selection methods

data loading observer pattern for configed start

-- rupert roeder <roeder@bonifax.uib.local>  Mon, 01 Apr 2014 14:10:37 +0100

opsi-configed (4.0.4.2.4-1) experimental; urgency=low

activity indicator
created stub class for remote data
several data types included in stub

accelerated swaudit function

-- rupert roeder <roeder@bonifax.uib.local>  Fri, 14 Mar 2014 14:10:37 +0100

opsi-configed (4.0.4.2.3-1) experimental; urgency=low

accelerated depot switching
other depot issues fixed

gzip compression is no default

-- rupert roeder <roeder@bonifax.uib.local>  Thu, 13 Mar 2014 14:10:37 +0100

14.1.2. Changelog opsi-client-agent

opsi-client-agent (4.0.5.1-8) stable; urgency=low

opsiclientd 4.0.80
setup.ins: switch to fatal on Linux (do)
update to opsi-winst 4.11.4.10 (do)

— Erol Ueluekmen <e.ueluekmen@uib.de> Fri, 23 Sep 2014 03:09:00 +0100

opsi-client-agent (4.0.5.1-7) stable; urgency=low

opsiclientd 4.0.79

— Erol Ueluekmen <e.ueluekmen@uib.de> Fri, 25 Jul 2014 03:09:00 +0100

opsi-client-agent (4.0.5.1-6) stable; urgency=low

opsiclientd 4.0.78

— Erol Ueluekmen <e.ueluekmen@uib.de> Fri, 25 Jul 2014 03:09:00 +0100

opsi-client-agent (4.0.5.1-5) stable; urgency=low

fixes in sub_restore_productOnClient for opsi-local-image

— Detlef Oertel <d.oertel@uib.de> Fri, 25 Jul 2014 15:00:00 +0100

opsi-client-agent (4.0.5.1-4) stable; urgency=low

fixes broken gina chain if Winlogon.GinaDLL=thirdpartygina and opsi.org\opsi-client-agent] NextGina=msgina.dll setup.py fixes # 1100
for oli productOnClient restore: restore existing actionrequests=setup after json restore (do)
code cleanup (preloginloader) from uninstall (do)

— Bardo Wolf <b.wolf@uib.de> Fri, 27 Jun 2014 10:49:00 +0100

opsi-client-agent (4.0.5.1-3) stable; urgency=low

for oli productOnClient restore: in opsiServiceCall_get_productOnClient condition "actionRequest":"none" So we delete only the localboot products with no actionrequest
update to opsenssl 1.0.1h
opsi-winst 4.11.4.6
fix in setup.py fixes # 1100

— Detlef Oertel <d.oertel@uib.de> Wed, 18 Jun 2014 15:00:00 +0100

opsi-client-agent (4.0.5.1-2) stable; urgency=low

delete new opsiclientd.conf sections for combination wan/vpn with install by shutdown
for oli productOnClient restore: in opsiServiceCall_get_productOnClient condition "actionRequest":"none" So we delete only the localboot products with no actionrequest
```
-- Karsten Koepke <k.koepke@uib.de>  Thu, 13 Jun 2014 15:00:00 +0100
```

opsi-client-agent (4.0.5.1-1) stable; urgency=low ; RELEASED

added new opsiclientd.conf sections for combination wan/vpn with install by shutdown

fix in sub_restore_productOnClient (set bootmode to bkstd )

-- Miriam Michaelis <m.michaelis@uib.de>  Tue, 10 Jun 2014 15:00:00 +0100

opsi-client-agent (4.0.5-1) stable; urgency=low

changed setup.ins (delete loginblocker logfile and timeout file)
fix in sub_restore_productOnClient (use $INST_ClientId$ instead of %HostId%)

new: in property uac_value new value 0=no change (experimental)

-- Miriam Michaelis <m.michaelis@uib.de>  Tue, 29 Apr 2014 15:00:00 +0100

opsi-client-agent (4.0.4.5-4) stable; urgency=low

opsi-winst 4.11.4.4

-- Detlef Oertel <d.oertel@uib.de>  Fri, 25 Apr 2014 15:00:00 +0100

opsi-client-agent (4.0.4.5-3) stable; urgency=low

new opsiloginblocker.dll V1.2.0.5/credential provider filter (no multiple timeouts)
new opsigina.dll 1.3.0.2 (no multiple timeouts)
fix in lib directory of opsi-winst; https://forum.opsi.org/viewtopic.php?f=6&t=6142
sub_restore_productOnClient: restore productOnClient if found in c:\opsi.org\tmp (for capture image use)

opsi-winst 4.11.3.11

-- Miriam Michaelis <m.michaelis@uib.de>  Tue, 18 Mar 2014 15:00:00 +0100

opsi-client-agent (4.0.4.5-2) stable; urgency=low

opsi-winst 4.11.4.3
use of isDriveReady to disable critical-error-handler message box. (Drive not ready)
```
-- Detlef Oertel <d.oertel@uib.de>  Thu, 20 Mar 2014 15:00:00 +0100
```

opsi-client-agent (4.0.4.5-1) stable; urgency=low

new credential provider filter with fix for >= nt6.2 opsiloginblocker.dll V1.2.0.2

loginblocker logfile written to dir opsi.org\log

-- Miriam Michaelis <m.michaelis@uib.de>  Tue, 18 Mar 2014 15:00:00 +0100

14.1.3. Changelog opsi-winst

opsi-winst/opsi-script (4.11.4.10) stable; urgency=low

osparser: doAktionen: tsIncludeInsert: debug outputs for index out of range bug
osparser: LoadValidLinesFromFile : fix add loaded sub lines to FLinesOriginList to fix index out of range at tsIncludeInsert
osparser: new bool function: LineContaining_ExistsIn(<string>, <file name>)

— Detlef Oertel <d.oertel@uib.de> Wed, 01 Oct 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.9) stable; urgency=low

osfunc: StartProcess_cp: remove wrong setProgress which may lead to division by zero
osbatchgui: new var SavedBatchWindowMode
osparser: on NormalizeWinst and IconizeWinst save BatchWindowMode to SavedBatchWindowMode and set BatchWindowMode to new value. on RestoreWinst set to BatchWindowMode and mode to SavedBatchWindowMode Fixes changing the window mode by every sub section call (do_actions)

— Detlef Oertel <d.oertel@uib.de> Wed, 20 Aug 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.8) stable; urgency=low

osparser: more loggin on LLDebug2 in fileActionsMain: used source and target
osparser: more loggin on LLDebug2 in fileActionsMain: additional trim() an target

— Detlef Oertel <d.oertel@uib.de> Thu, 07 Aug 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.7) stable; urgency=low

osfunc: StartProcess_cp: if timeout is given: use Progressbar to show time progess until Timeout
new unit cCPUusage
skin.ini; new section [Activitybar]
osparser : Line Looping through append trailing '' fixes # 1116
osparser: typo double instead of doubble fixes #1117
new switch: AutoActivityDisplay = (true/false) default=false; if true shows marquee while winbatch/dosbatch
osfuncwin: RunCommandAndCaptureOut: non blocking readfile with PeekNamedPipe (so Activitybar may run in Background)
new manifest: with assemblyIdentity (needed for maquee style in Activitybar

— Detlef Oertel <d.oertel@uib.de> Wed, 23 Jul 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.6) stable; urgency=low

osmain: typo (dependenproducts) fixes #1078
osparser: typo (Windowds) fixes #1078
osconf: changed version to 4.11.4.6
osparser: fix: RegDeleteKey (https://forum.opsi.org/viewtopic.php?p=27061#p27061) #1086
osparser: set Fatal if shellbatch/execwith could not be executed. fixes #1074
osparser/oslog: new log file .history which always appends just the timestamp, name and version of the installed product.
osparser: PatchTextFile: new command: searchAndReplace <search str> <replace str> (works global and not case sensitive)
The temporary file names have now a random component in order to prevent conflicts between different instances of opsi-script. fixes #774
subsub bug fix: help to find sub sections in external sub section files (calling section as additional parameter in doAktionen)
osparser: getsublist: trim parameters before strtoint
osparser: getsublist: adjustBounds: fix for negative second parameter.

— Detlef Oertel <d.oertel@uib.de> Thu, 27 May 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.5) stable; urgency=low

unquote fix:
osparser: unquote function details moved to osfunc: opsiunquotestr function (because synautil.unquotestr is buggy: "tes’t" gives "test"
osfunc: new function opsiunquotestr
osfunc: use of opsiunquotestr in fileexists, chmod
osparser: use of opsiunquotestr in fileactionsmain
osmain: use of opsiunquotestr in getparameter
osparser: doRegistryAllNtUserDats: additional check if we can patch via HKU

— Detlef Oertel <d.oertel@uib.de> Thu, 19 May 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.4) stable; urgency=low

osfunclin: RunCommandAndCaptureOut: Log exitcode on Loglevel LLInfo
osparser: linkActionsMain: fix for index out of bound (while (i ⇐ Sektion.count)) fixes: #958
osfunc: StartProcess_cp: log error if time out is reached (inc’s error counter) fixes #506
new commands in PatchTextFile (osparser:doTextpatchMain): setKeyValueSeparator char sets Separator for key value pairs (default is =) setValueByKey keystr valuestr search exitsing key and sets the given value. If the key not exists, the key/value pair will be created below the line cursor.
osparser: scriptstopped := true on ExitWindows /ImmediateReboot and /ImmediateLogout
new function: getValueFromFile (<key string>,<file name> ) : string
new function: getValueFromFileBySeparator (<key string>,<separator string>,<file name> ) : string
new function: saveTextFile(<list>, < filename>) : bool
osparser: TuibInstScript.doAktionen: output initalized (created) fixes #974
osfunc: enhanced: TXStringList.getStringValue
osparser: produceStringlist: fix in emptylist() function

— Detlef Oertel <d.oertel@uib.de> Thu, 20 Mar 2014:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.3) stable; urgency=low

opsparser: doFileActions: fix for mixed File section modifiers
osfunc: TuibRegistry.WriteEntry: fix logging if regtype is changed: fixes #780
osfunc: wait for parent ending also if waitforprocessending is true
osfunc: FileCopyWin: use of windows.copyFile instead of fileutils.copyFile
osparser: Stingreplace with IgnoreCase for %userprofiledir% fixes #877
osparser: new constant %opsiTmpDir% (c:\opsi.org\tmp ; /tmp )
osparser: new constant %opsiLogDir% (c:\opsi.org\log ; /var/log/opsi-client-agent/opsi-script )
osparser: new command: FatalOnRuntimeError (default = false)
osparser: takeString: LogError if index out of bounds; Fatal if FatalOnSyntaxError
oslog: escape control chars
osfunc: allcopy/execdelete: handle directories with additional attributes (e.g. hidden)
osparser: new function doRegistryNTUserDat
new Registry Parameter /NTuserDat: <path to ntuser.dat>
osmain: ProcessProduct: looks before processing a product if there is still a action request
osparser: for fileExists: replace GetFileInfo by "FileExists() or DirectoryExists()"
fixes to really stop the script interpretation after isfatalerror, issuccess, issuspended
new unit opsihwbiosinfo based on tsmbios
new infomap getHWBiosInfoMap
new bool function runningOnUefi fixes #908
new bool function isDriveReady(str)
doFileActions: disable windows critical Error Message boxes (SetErrorMode(SEM_FAILCRITICALERRORS))

— Detlef Oertel <d.oertel@uib.de> Mon, 9 Dec 2013:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.2) stable; urgency=low

make 4.11.4 working under windows
osencoding: searchencoding: new methode to read encoding
osinteractivegui: opendialog knows now *.ins and *.opsiscript
new string function reencodestr(str, from, to)
new stringlist function reencodestrlist(strlist, from, to)
new stringlist function shellCall( cmd ) ; returns the output of (sysnative) shell with cmd
getipByName now uses resolveip at linux
http://msdn.microsoft.com/en-us/library/windows/desktop/dn302074%28v=vs.85%29.aspx
fix: use of sysnative with winbatch

— Detlef Oertel <d.oertel@uib.de> Mon, 23 Sep 2013:15:00:00 +0200

opsi-winst/opsi-script (4.11.4.1) stable; urgency=low

splitted project to opsi-script and opsi-script-nogui
splitted unit osmain to osmain and osinteractivegui
changed unit names: * wi* → os*
fixed: Feature 491 : real origin file and line number on syntax error (also on included parts)
new unit osencode which contain encoding functions known encodings are:
UTF-8 utf8
UTF-8BOM utf8bom
Ansi ansi
CP1250 cp1250
CP1251 cp1251
CP1252 cp1252
CP1253 cp1253
CP1254 cp1254
CP1255 cp1255
CP1256 cp1256
CP1257 cp1257
CP1258 cp1258
CP437 cp437
CP850 cp850
CP852 cp852
CP866 cp866
CP874 cp874
CP932 cp932
CP936 cp936
CP949 cp949
CP950 cp950
ISO-8859-1 iso8859-1
ISO-8859-2 iso8859-2
KOI-8 koi8
UCS-2LE ucs2le
UCS-2BE ucs2be
fixed: Bug 554 : includelogtail calls reencode
command IncludeLog has now an optional 3rd parameter sourceEncoding which may be auto, system or a valid encoding.
nearly all loadfromfile now with reencode
script encoding can now be given with for example encoding=utf8
loglevel of if/else/endif changed to LLinfo (6) fixes 539
loglevel of setLoglevel changed to LLinfo (6) fixes 535
new command IsSuspended interupts script execution and leave productOnClient unchanged Feature #614
shellbatch output is now captured
fix in linux getprocesslist: output now: short binary name;pid;user;full command line

— Detlef Oertel <d.oertel@uib.de> Tue, 30 Jul 2013:15:00:00 +0200

opsi-winst/opsi-script (4.11.4) stable; urgency=low

port to Linux
removed logginig via syslog
%opsiDepotId%
changed unit names:
wisynth → osparser
wibatch → osbatchgui
wimain → osmain
wifunc → osfunc
wiwin32 → osfuncwin2
new string function: getLinuxDistroType
new stringlist function: getLinuxVersionMap

— Detlef Oertel <d.oertel@uib.de> Tue, 30 Apr 2012:15:00:00 +0200

14.1.4. Changelog windows netboot products

windows (4.0.5-4) stable; urgency=low

update opsisetuplib.py
debug for winpe partition size bug
change partition (size/start/end) calculation to fix partition size bug (uib#2014101510000015)
property imagename now: editable: True

— Detlef Oertel <d.oertel@uib.de> Thu, 16 Oct 2014:15:00:00 +0200

windows (4.0.5-3) stable; urgency=low

update opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Tue, 23 Sep 2014:15:00:00 +0200

windows (nt6) (4.0.5-2) stable; urgency=low

update opsisetuplib.py
hpsa support

— Detlef Oertel <d.oertel@uib.de> Thu, 04 Sep 2014:15:00:00 +0200

windows (nt5) (4.0.5-2) stable; urgency=low

fix at $oem$ sub directories in opsi and custom directory

-- detlef oertel <d.oertel@uib.de>  Mon, 04 Nov 2014 16:01:53 +0200

windows (4.0.5-1) stable; urgency=low

new property setup_after_install (do)
create_driver_links.py: do not extract buildIn-drivers from winpe
do not change UAC
update opsisetuplib.py
sort disks
reread changed from sfdisk to partprobe

small fix in sfdisk execution

-- erol ueluekmen <e.ueluekmen@uib.de>  Fri, 18 Jul 2014 12:01:53 +0200

windows (4.0.4-3) stable; urgency=low

use of opsisetuplib.py
Swapoff all to avoid disk in use

copy of winpe_uefi removed

-- detlef oertel <d.oertel@uib.de>  Fri, 11 Apr 2014 16:01:53 +0200

windows (4.0.4-2) stable; urgency=low

UEFI / GPT enabled

-- detlef oertel <d.oertel@uib.de>  Tue, 25 Feb 2014 16:01:53 +0200

14.1.5. Changelog linux netboot products

Debian

debian-4.0.5-4 stable; urgency=low

update opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Tue, 23 Sep 2014:15:00:00 +0200

debian-4.0.5-3 testing; urgency=low

update opsipreparelib.py
update opsisetuplib.py
hpsa support

— Detlef Oertel <d.oertel@uib.de> Thu, 04 Sep 2014:15:00:00 +0200

debian-4.0.5-2 testing; urgency=low

localization fixes
locale-gen fixes
automatic release extension for (base-) opsi_online_repository
add opsi repository only if install_opsi_server
for squeeze 32 debiankernel = "linux-image-686"
more timezones

— Detlef Oertel <d.oertel@uib.de> Tue, 26 Aug 2014:15:00:00 +0200

debian-4.0.5-1 stable; urgency=low

added lvm
needs opsi 4.0.5 bootimage
new property use_logical_volumes
added HD-encryption
new property encrypt_logical_volumes (will set use_logical_volumes to True)
new property encrypt_password
need bootimage >= 20140704
more keymaps
property setup_after_install default now: "l-os-postinst"

— Detlef Oertel <d.oertel@uib.de> Mon, 23 Jun 2014:15:00:00 +0200

debian-4.0.4-4 stable; urgency=low

use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)
use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Fri, 20 May 2014:15:00:00 +0200

debian-4.0.4-3 stable; urgency=low

removed property use_raid1 (now always false)
removed property blockAlignment (now always true)

— Detlef Oertel <d.oertel@uib.de> Fri, 02 May 2014:15:00:00 +0200

debian_4.0.4-2 testing; urgency=low

retry on debootstrap
merged with ubuntu-4.0.4-2
use opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Mon, 17 Mar 2014:15:00:00 +0200

debian_7.02 testing; urgency=low

merged with ubuntu-4.0.4

— Detlef Oertel <d.oertel@uib.de> Tue, 10 Dec 2013:15:00:00 +0200

debian_6-5 testing; urgency=low

merged with ubuntu-12.0.4-5

— Detlef Oertel <d.oertel@uib.de> Mon, 22 Apr 2013:15:00:00 +0200

debian-4.0r3-1 testing; urgency=low

initial (J.Schneider ?) 13.5.2009

Ubuntu

ubuntu-4.0.5-7 testing; urgency=low

removed end-of-life releases (quantal,raring,saucy)
fix: create /etc/default/locale
fix: extend /etc/environment wit PATH

— Detlef Oertel <d.oertel@uib.de> Wed, 22 Oct 2014:15:00:00 +0200

ubuntu-4.0.5-6 testing; urgency=low

update opsisetuplib.py
code cleanup

— Detlef Oertel <d.oertel@uib.de> Mon, 22 Sep 2014:15:00:00 +0200

ubuntu-4.0.5-5 testing; urgency=low

update opsipreparelib.py
update opsisetuplib.py
hpsa support

— Detlef Oertel <d.oertel@uib.de> Thu, 04 Sep 2014:15:00:00 +0200

ubuntu-4.0.5-4 testing; urgency=low

added release lucid
localization fixes
locale-gen fixes
automatic release extension for (base-) opsi_online_repository
add opsi repository only if install_opsi_server
more timezones

— Detlef Oertel <d.oertel@uib.de> Tue, 26 Aug 2014:15:00:00 +0200

ubuntu-4.0.5-3 stable; urgency=low

property setup_after_install default now: "l-os-postinst"

— Detlef Oertel <d.oertel@uib.de> Fri, 15 Aug 2014:15:00:00 +0200

ubuntu-4.0.5-2 stable; urgency=low

added HD-encryption
new property encrypt_logical_volumes (will set use_logical_volumes to True)
new property encrypt_password
need bootimage >= 20140704

— Detlef Oertel <d.oertel@uib.de> Mon, 23 Jun 2014:15:00:00 +0200

ubuntu-4.0.5-1 stable; urgency=low

added lvm
needs opsi 4.0.5 bootimage
new property use_logical_volumes

— Detlef Oertel <d.oertel@uib.de> Wed, 4 Jun 2014:15:00:00 +0200

ubuntu-4.0.4-5 stable; urgency=low * added lvmClearVolumeGroups() * use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h) — Detlef Oertel <d.oertel@uib.de> Fri, 20 May 2014:15:00:00 +0200

ubuntu-4.0.4-4 stable; urgency=low

removed property use_raid1 (now always false)
removed property blockAlignment (now always true)

— Detlef Oertel <d.oertel@uib.de> Fri, 02 May 2014:15:00:00 +0200

ubuntu-4.0.4-3 testing; urgency=low

added trusty thar (14.04)
retries at debootstrap
use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Tue, 18 Mar 2014:15:00:00 +0200

ubuntu-4.0.4-2 UNRELEASED; urgency=low

needs now opsi linux bootimage version: 20140118
removed 64bit opsi-linux-bootimage and kernel from package
modified pxetemplate for new bootimage support
small fix in ubuntu.py
SERVER_DATA removed
fixed postinst
UEFI/GPT Support

new property setup_after_install

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Fri,  07 Feb 2014:01:00:00 +0200

ubuntu-4.0.4-1 experimental; urgency=low

needs now opsi linux bootimage version: 20131021
added 64bit opsi-linux-bootimage
new property: release
install linux-image after grup
additional run of update-grub
debootstrap script for saucy (copy from raring)
pkgdetails for all releases

removed property desktop

-- Detlef Oertel <d.oertel@uib.de>  Tue,  24 Sep 2013:15:00:00 +0200

ubuntu-12.0.4-8 experimental; urgency=low

new property: proxy

dirtyhack in ubuntu.py: Devicefile not found by creating swap

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Wed,  21 Aug 2013:11:00:00 +0200

ubuntu-12.0.4-7 testing; urgency=low

new property: install_opsi-client-agent
integration of the Linux opsi-client-agent 4.0.3.2-1

some more ' --force-yes'

-- Detlef Oertel <d.oertel@uib.de>  Mon,  1 Jul 2013:15:00:00 +0200

ubuntu-12.0.4-6 testing; urgency=low

timeout (1000 seconds) on debootstrap call

-- Detlef Oertel / Erol Ueluekmen <info@uib.de>  Tue,  18 June 2013:15:00:00 +0200

ubuntu-12.0.4-5 testing; urgency=low

remove property: delete_partition_table (always/if_needed/never) (default=always)
new property: data_partition_preserve (always/if_possible/never) (default=never)
integrated 64bit opsi-linux-bootimage
- version 20130427
- kernel 3.6.11
- python-opsi 4.0.3.2-1
added architecture productProperty
added 32 / 64 Bit Support (installs 64 Bit System if started from 64 Bit bootimage)
added UEFI/GPT Support

minimum disk size changed to 5GB

-- Detlef Oertel / Erol Ueluekmen <info@uib.de>  Tue,  30 Apr 2013:15:00:00 +0200

ubuntu-12.0.4-4 testing; urgency=low

added desktop cinnamon. Will be installed on top of a unity
added property wget_and_execute
user now in sudo group

fixes in unity and xfce installation

-- Detlef Oertel <d.oertel@uib.de>  Thu,  03 Apr 2013:15:00:00 +0200

ubuntu-12.0.4-3 testing; urgency=low

fit to partition scheme for opsi-image-local-(backup/restore)

-- Detlef Oertel <d.oertel@uib.de>  Fri,  04 Jan 2013:15:00:00 +0200

ubuntu-12.0.4-2 testing; urgency=low

update ubuntu.py to opsi 4.0.2-3 standard

-- Detlef Oertel <d.oertel@uib.de>  Mon,  17 Dec 2012:15:00:00 +0200

ubuntu-12.0.4-1 testing; urgency=low

update to 12.04

-- Detlef Oertel <d.oertel@uib.de>  Fri,  14 Dec 2012:15:00:00 +0200

ubuntu-8.0.4-3 testing; urgency=low

changing source var to opsi_depot share (no more install)

-- Detlef Oertel <d.oertel@uib.de>  Fri,  14 Dec 2012:15:00:00 +0200

ubuntu-8.0.4-2 testing; urgency=low

initial (J.Schneider ?) 13.5.2009

openSUSE

opensuse13-1_13.01-6 stable; urgency=low

fix repo URI ; fixes #1220
update opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Tue, 21 Oct 2014:15:00:00 +0200

opensuse13-1_13.01-5 stable; urgency=low

update opsipreparelib.py
update opsisetuplib.py
hpsa support
code cleanup

— Detlef Oertel <d.oertel@uib.de> Fri, 26 Sep 2014:15:00:00 +0200

opensuse13-1_13.01-4 testing; urgency=low

use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h)
code cleanup
new property: setup_after_install
new property: wget_and_execute

— Detlef Oertel <d.oertel@uib.de> Mon, 28 Jul 2014:15:00:00 +0200

opensuse13-1_13.01-3 testing; urgency=low

UUID for storage devices
added lvmClearVolumeGroups()
removed property use_raid1 (now always false)
removed property blockAlignment (now always true)
use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Tue, 20 May 2014:15:00:00 +0200

opensuse13-1_13.01-2 UNRELEASED; urgency=low

needs now opsi linux bootimage version: 20140118
removed 64bit opsi-linux-bootimage and kernel from package
modified pxetemplate for new bootimage support
SERVER_DATA removed
fixed postinst
fix install opsi server
UEFI/GPT Support
new property setup_after_install

— Detlef Oertel <d.oertel@uib.de> Tue, 18 Feb 2014:15:00:00 +0200

opensuse13-1_13.01-1 stable; urgency=low

port from opensuse12-3

— Detlef Oertel <d.oertel@uib.de> Tue, 9 Dec 2013:15:00:00 +0200

opensuse12-3_12.03-5 stable; urgency=low

fix repo URI ; fixes #1220
update opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Tue, 21 Oct 2014:15:00:00 +0200

opensuse12-3_12.03-4 stable; urgency=low

update opsipreparelib.py
update opsisetuplib.py
hpsa support
code cleanup

— Detlef Oertel <d.oertel@uib.de> Fri, 26 Sep 2014:15:00:00 +0200

opensuse12-3_12.03-3 testing; urgency=low

UUID for storage devices
added lvmClearVolumeGroups()
removed property use_raid1 (now always false)
removed property blockAlignment (now always true)
use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)
use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Tue, 20 May 2014:15:00:00 +0200

opensuse12-3_12.03-2 testing; urgency=low

needs now opsi linux bootimage version: 20140118
removed 64bit opsi-linux-bootimage and kernel from package
modified pxetemplate for new bootimage support
SERVER_DATA removed
fixed postinst
fix install opsi server
UEFI/GPT Support
new property setup_after_install

— Detlef Oertel <d.oertel@uib.de> Tue, 18 Feb 2014:15:00:00 +0200

opensuse12-3_12.03-1 stable; urgency=low

port from opensuse (version now part of name because rpms included)

— Detlef Oertel <d.oertel@uib.de> Tue, 9 Dec 2013:15:00:00 +0200

opensuse-12.03-2 experimental; urgency=low

minimal rpms

— Detlef Oertel <d.oertel@uib.de> Tue, 26 Sep 2013:15:00:00 +0200

opensuse-12.03-1 experimental; urgency=low

update to 12.03

— Detlef Oertel <d.oertel@uib.de> Tue, 24 Sep 2013:15:00:00 +0200

opensuse-10.03-1 experimental; urgency=low

initial (J.Schneider ?) 13.5.2009

sles11sp3

sles11sp3-11.3-10 stable; urgency=low

update opsisetuplib.py

— Detlef Oertel <d.oertel@uib.de> Tue, 23 Sep 2014:15:00:00 +0200

sles11sp3-11.3-9 stable ; urgency=low

fix in mount boot partition
hpsa support

— Detlef Oertel <d.oertel@uib.de> Tue, 09 Sep 2014:15:00:00 +0200

sles11sp3-11.3-8 stable ; urgency=low

use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)
removed property use_raid1 (now always false)
removed property blockAlignment (now always true)
added lvmClearVolumeGroups()
suse_register with --no-refresh

— Detlef Oertel <d.oertel@uib.de> Wed, 20 Aug 2014:15:00:00 +0200

sles11sp3-11.3-7 stable ; urgency=low

needs now opsi linux bootimage version: 20140118
removed 64bit opsi-linux-bootimage and kernel from package
modified pxetemplate for new bootimage support
small fix in ubuntu.py
SERVER_DATA removed
fixed postinst
UEFI/GPT Support
new property setup_after_install
add install of kernel-firmware
rename grub.cfg to grub.conf

— Detlef Oertel <d.oertel@uib.de> Mon, 20 Jan 2014:15:00:00 +0200

sles11sp3-11.3-6 experimental; urgency=low

new product property: kernel_modules

— Detlef Oertel <d.oertel@uib.de> Wed, 15 Jan 2014:15:00:00 +0200

sles11sp3-11.3-5 experimental; urgency=low

create fstab and menu.lst with uuid instead of /dev/sda

— Detlef Oertel <d.oertel@uib.de> Thu, 09 Jan 2014:15:00:00 +0200

sles11sp3-11.3-4 experimental; urgency=low

some more logging
fix: local repositories
use different grub.cfg on unixDevicePath

— Detlef Oertel <d.oertel@uib.de> Wed, 18 Dec 2013:15:00:00 +0200

sles11sp3-11.3-3 experimental; urgency=low

fix: user softwareLicenseKey only if suse_register=true
update to bootimage 20131209

— Detlef Oertel <d.oertel@uib.de> Thu, 12 Dec 2013:15:00:00 +0200

sles11sp3-11.3-2 experimental; urgency=low

sles.py fixes: syntax error
added proxy handling
added productProperties suse_register and local_repositories

— Erol Ueluekmen <e.ueluekmen@uib.de> Tue, 29 Oct 2013:10:00:00 +0200

sles11sp3-11.3-1 experimental; urgency=low

port from opensuse package
property productkey for suse_register

— Detlef Oertel <d.oertel@uib.de> Tue, 28 Oct 2013:15:00:00 +0200

centos65

centos65_6.5-3 testing; urgency=low

added lvmClearVolumeGroups()
use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Tue, 05 Aug 2014:15:00:00 +0200

centos65_6.5-2 testing; urgency=low

retries at base installation
use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)
new property setup_after_install
removed properies use_raid1 (always false) and block_alignment (always true)

— Detlef Oertel <d.oertel@uib.de> Mon, 28 Apr 2014:15:00:00 +0200

centos65_6.5-1 experimental; urgency=low

port from redhat65

— Detlef Oertel <d.oertel@uib.de> Mon, 3 Feb 2014:15:00:00 +0200

Fedora 20

fedora_20_20-4 stable; urgency=low

added lvmClearVolumeGroups()
removed property use_raid1 (now always false)
removed property blockAlignment (now always true)
use opsipreparelib.py (is symbolic link: use opsi-makeproductfile -h)
new property setup_after_install
new property wget_and_execute
32Bit support

— Detlef Oertel <d.oertel@uib.de> Tue, 20 May 2014:15:00:00 +0200

fedora_20_20-3 stable; urgency=low

retries at base installation
use opsisetuplib.py (is symbolic link: use opsi-makeproductfile -h)

— Detlef Oertel <d.oertel@uib.de> Tue, 22 Apr 2014:15:00:00 +0200

fedora_20_20-1 stable; urgency=low

port from opensuse13-1

— Detlef Oertel <d.oertel@uib.de> Mon, 23 Dec 2013:15:00:00 +0200

14.1.6. Changelog opsi-local-image

opsi-local-image-backup

opsi-local-image-win* (4.0.5.1-3) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-backup (4.0.5.1-2) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-backup (4.0.5.1-1) stable; urgency=low

new property setup_after_install

disk sorting

-- detlef oertel <d.oertel@uib.de>  Thu, 10 Jul 2014 16:01:53 +0200

opsi-local-image-backup (4.0.4.3-1) stable; urgency=low

opsisetuplib.py update

code cleanup

-- detlef oertel <d.oertel@uib.de>  Wed, 28 May 2014 16:01:53 +0200

opsi-local-image-backup (4.0.4.3-1) stable; urgency=low

use of opsisetuplib.py

remove action requests from poc store

-- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-backup (4.0.4.2-1) stable; urgency=low

uefi / gpt support

Showing a progress bar when creating a backup.

-- detlef oertel <d.oertel@uib.de>  Mon, 30 Dec 2013 16:01:53 +0200

opsi-local-image-backup (4.0.4.1-1) stable; urgency=low

Handles imagefile names with spaces (internal as _)
fix: stores always the correct netboot product name
- detlef oertel <d.oertel@uib.de> 16 Dec 2013

opsi-local-image-backup (4.0.3.2-1) stable; urgency=low

Now works also with 4 partitions
- detlef oertel <d.oertel@uib.de> 01 Aug 2013

opsi-local-image-backup (4.0.3-4) stable; urgency=low

internal syntax fix: fix image list
use partclone with --dev-to-dev instead of --clone
- detlef oertel <d.oertel@uib.de> 25 Jun 2013

opsi-local-image-backup (4.0.3-3) experimental; urgency=low

internal syntax fix: initialize goon
- detlef oertel <d.oertel@uib.de> 11 Apr 2013
```
opsi-local-image-backup (4.0.3-2) experimental; urgency=low
```
new product property imagefile
- detlef oertel <d.oertel@uib.de> 12 Mar 2013

opsi-local-image-backup (4.0.3-1) experimental; urgency=low

initial
- detlef oertel <d.oertel@uib.de> 15 Oct 2012

opsi-local-image-capture

opsi-local-image-capture (4.0.5.1-5) stable; urgency=low

disabled all calls of ShellInAnIcon_copylog

-- detlef oertel <d.oertel@uib.de>  Tue, 29 Jul 2014 16:01:53 +0200

opsi-local-image-win* (4.0.5.1-4) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-capture (4.0.5.1-3) stable; urgency=low

delete c:\tmp before capture

delete c:\drv before capture

-- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-capture (4.0.5.1-2) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-capture (4.0.5.1-1) stable; urgency=low

removed property capture_architecture
rewmoved property imagefilename
removed retry by sdfisk --re-read replaced by partprobe
code cleanup
fix gpt hidden winpe partition
windows partition before reboot and unhide while pe run (PE have to be c:)
auto detect drive letter for windows partition (may be different on existence of CD or other partitions)
fall back from dism to imagex if dism fails
uefi: switch back to uefi netboot (for e.g. opsi-local-image restore)
```
-- detlef oertel <d.oertel@uib.de>  Tue, 15 Jul 2014 16:01:53 +0200
```

opsi-local-image-capture (4.0.4.4-2) stable; urgency=low

fixes in setup.py
special winst64.exe with ssl
removed use of property capture_architecture

rewmoved use of property imagefilename

-- detlef oertel <d.oertel@uib.de>  Fri, 20 Jun 2014 16:01:53 +0200

opsi-local-image-capture (4.0.4.4-1) stable; urgency=low

switch back to PE based capture

modified winst32 with network connection

-- detlef oertel <d.oertel@uib.de>  Thu, 5 Jun 2014 16:01:53 +0200

opsi-local-image-capture (4.0.5.1-1) stable; urgency=low

opsisetuplib.py update
needs opsi 4.0.5 bootimage
new property: netboot_product

new property: capture_architecture

-- detlef oertel <d.oertel@uib.de>  Wed, 28 May 2014 16:01:53 +0200

opsi-local-image-capture (4.0.4.3-2) stable; urgency=low

use opsi_depot and opsi_depot_rw (samba4 executable bit problem) #* experimental: call winst32.exe #* new property: netboot_product

new property: capture_architecture

-- detlef oertel <d.oertel@uib.de>  Mon, 28 Apr 2014 16:01:53 +0200

opsi-local-image-capture (4.0.4.3-1) stable; urgency=low

use of opsisetuplib.py
Swapoff all to avoid disk in use

remove action requests from poc store

-- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-capture (4.0.4.2-1) stable; urgency=low

initial: created from opsi-local-image-backup

-- detlef oertel <d.oertel@uib.de>  Wed, 26 Mar 2014 16:01:53 +0200

opsi-local-image-delimage

opsi-local-image-win* (4.0.5.1-3) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-delimage (4.0.5.1-2) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Thu, 24 Jul 2014 16:01:53 +0200

opsi-local-image-delimage (4.0.5.1-1) stable; urgency=low

update of opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Tue, 22 Jul 2014 16:01:53 +0200

opsi-local-image-delimage (4.0.4.3-1) stable; urgency=low

use of opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-delimage (4.0.4.2-1) stable; urgency=low

uefi / gpt support

-- detlef oertel <d.oertel@uib.de>  Fri, 31 Jan 2014 16:01:53 +0200

opsi-local-image-delimage (4.0.4.1-1) stable; urgency=low

Handles imagefile names with spaces (internal as _)
- detlef oertel <d.oertel@uib.de> 16 Dec 2013

opsi-local-image-delimage (4.0.3.2-1) stable; urgency=low

Now works also with 4 partitions
- detlef oertel <d.oertel@uib.de> 01 Aug 2013

opsi-local-image-delimage-4.0.3.1-2 testing; urgency=low

fix in type call

— Detlef Oertel <d.oertel@uib.de> Wed, 08 Apr 2013:15:00:00 +0200

opsi-local-image-delimage-4.0.3.1-1 testing; urgency=low

initial

— Detlef Oertel <d.oertel@uib.de> Wed, 13 Mar 2013:15:00:00 +0200

opsi-local-image-prepare

opsi-local-image-win* (4.0.5.1-3) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.5.1-2) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.5.1-1) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Tue, 22 Jul 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.3-4) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Tue, 17 Jun 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.3-3) stable; urgency=low

start_os_installation editable: True

-- detlef oertel <d.oertel@uib.de>  Wed, 28 May 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.3-2) stable; urgency=low

code cleanup
system_partition_size editable: True

data_partition_size editable: True

-- detlef oertel <d.oertel@uib.de>  Tue, 27 May 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.3-1) stable; urgency=low

use of opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.2-3) stable; urgency=low

fix: Create backup partition: start is boundaryM + partgapM
library: createPartitionEx and createFilesystemEx with success test

smaller partGap : 64 M

-- detlef oertel <d.oertel@uib.de>  Wed, 26 Mar 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.2-2) stable; urgency=low

swapoff all before partitioning

code cleanup

-- detlef oertel <d.oertel@uib.de>  Thu, 27 Feb 2014 16:01:53 +0200

opsi-local-image-prepare (4.0.4.2-1) stable; urgency=low

uefi / gpt support

-- detlef oertel <d.oertel@uib.de>  Mon, 30 Dec 2013 16:01:53 +0200

opsi-local-image-prepare (4.0.4.1-1) stable; urgency=low

rename to 4.0.4.1-1

added win81 products

-- detlef oertel <d.oertel@uib.de>  Fri, 20 Dec 2013 16:01:53 +0200

opsi-local-image-prepare-4.0.3.2-1 testing; urgency=low

#267 Weitere Partitionsgrößen in "opsi-local-image-prepare"
new property: data_partition_size ; Default = 0G = partition will not be created
Now works also with 4 partitions

— Detlef Oertel <d.oertel@uib.de> Wed, 01 Aug 2013:15:00:00 +0200

opsi-local-image-prepare-4.0.3.1-1 testing; urgency=low

rename from opsi-local-image-repartition
added ProductProperty: start_OS_installation
added sleeps and 'sfdisk re-read’s and retrries to avoid timing problems after create partition

— Detlef Oertel <d.oertel@uib.de> Wed, 13 Feb 2013:15:00:00 +0200

opsi-local-image-repartition-4.0.3.1-1 testing; urgency=low

initial

— Detlef Oertel <d.oertel@uib.de> Wed, 13 Feb 2013:15:00:00 +0200

opsi-local-image-restore

opsi-local-image-win* (4.0.5.1-3) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-restore (4.0.5.1-2) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-restore (4.0.5.1-1) stable; urgency=low

opsisetuplib.py update (new function setNextUefiBoot())
removed retry by sdfisk --re-read replaced by partprobe

fix: set next uefiboot via setNextUefiBoot()

-- detlef oertel <d.oertel@uib.de>  Tue, 15 Jul 2014 16:01:53 +0200

opsi-local-image-restore (4.0.4.3-2) stable; urgency=low

opsisetuplib.py update
retry by sdfisk --re-read
fix: IndexError

try / except at restoring ntfs ACLs

-- detlef oertel <d.oertel@uib.de>  Wed, 28 May 2014 16:01:53 +0200

opsi-local-image-restore (4.0.4.3-1) stable; urgency=low

use of opsisetuplib.py

do not use PE partition as swap (for reusing PE by capture)

-- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-restore (4.0.4.2-2) stable; urgency=low

raise exception if there is no meta data file

-- detlef oertel <d.oertel@uib.de>  Mon, 25 Mar 2014 16:01:53 +0200

opsi-local-image-restore (4.0.4.2-1) stable; urgency=low

uefi / gpt support

Showing a progress bar when restoring a backup.

-- detlef oertel <d.oertel@uib.de>  Mon, 30 Dec 2013 16:01:53 +0200

opsi-local-image-restore (4.0.4.1-1) stable; urgency=low

Fix: failover from rsync to image if rsync fails
replace all not allowed image name chars with "_"
- detlef oertel <d.oertel@uib.de> 16 Dec 2013

opsi-local-image-restore (4.0.3.2-2) stable; urgency=low

Fix: timeout increased from 100 to 1000
- detlef oertel <d.oertel@uib.de> 20 Sep 2013

opsi-local-image-restore (4.0.3.2-1) stable; urgency=low

Now works also with 4 partitions
- detlef oertel <d.oertel@uib.de> 01 Aug 2013

opsi-local-image-restore (4.0.3-7) stable; urgency=low

fix: method rsync-restore temporary activated again
partclone-image-restore uses now partclone.<fs> --dev-to-dev instaed of partclone.restore
mount for rsync uses mount.ntfs instead of imagemount
should be use d with backups from opsi-local-image-backup >= 4.0.3-4
- detlef oertel <d.oertel@uib.de> 27 June 2013

opsi-local-image-restore (4.0.3-6) stable; urgency=low

fix: method rsync-restore temporary removed due to ntfs access rights problems and security risks
- detlef oertel <d.oertel@uib.de> 27 June 2013

opsi-local-image-restore (4.0.3-5) experimental; urgency=low

fix: exclude symbolic links from rsync-restore use tar file instead should be use d with backups from 4.0.3-4
- detlef oertel <d.oertel@uib.de> 24 June 2013

opsi-local-image-restore (4.0.3-4) stable; urgency=low

fix undefined myvalues in line 571
- detlef oertel <d.oertel@uib.de> 17 June 2013

opsi-local-image-restore (4.0.3-3) stable; urgency=low

property method has now "rsync-partclone-image" as default
new property setup_after_restore
- detlef oertel <d.oertel@uib.de> 17 Apr 2013

opsi-local-image-restore (4.0.3-2) experimental; urgency=low

fix: set partition type and bootflag
- detlef oertel <d.oertel@uib.de> 12 Mar 2013

opsi-local-image-restore (4.0.3-1) experimental; urgency=low

initial
- detlef oertel <d.oertel@uib.de> 15 Oct 2012

opsi-local-image-sysprep

opsi-local-image-sysprep (4.0.5.1-1) stable; urgency=low

deactivate opsi-client-agent before sysprep

set uefi netboot before reboot if a netboot product is activated

-- detlef oertel <d.oertel@uib.de>  Tue, 15 Jul 2014 16:01:53 +0200

opsi-local-image-sysprep (4.0.4.3-1) stable; urgency=low

more features

-- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-sysprep (1.0-1) testing; urgency=low

Initial version based on opsi-sysprep

-- d.oertel <d.oertel@uib.de> Wed, 26 Mar 2014 16:39:34 + 0100

opsi-local-image-win*

opsi-local-image-win* (4.0.5.1-6) stable; urgency=low

fix at $oem$ sub directories in opsi and custom directory

-- detlef oertel <d.oertel@uib.de>  Mon, 04 Nov 2014 16:01:53 +0200

opsi-local-image-win* (4.0.5.1-5) stable; urgency=low

update opsisetuplib.py

update pci.ids, usb.ids

-- detlef oertel <d.oertel@uib.de>  Mon, 29 Sep 2014 16:01:53 +0200

opsi-local-image-win* (4.0.5.1-3) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Fri, 25 Jul 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.5.1-2) stable; urgency=low

update opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Tue, 24 Jul 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.5.1-1) stable; urgency=low

diskpart.txt is now gpt aware
no delete of opsi directory in PE via cleanup
create_driver_links.py: do not extract buildIn-drivers from winpe (eu)

code cleanup: no dual disk (ever only first disk)

-- detlef oertel <d.oertel@uib.de>  Fri, 3 Jul 2014 10:01:53 +0200

opsi-local-image-win7 (4.0.4.3-3) stable; urgency=low

opsisetuplib.py update

-- detlef oertel <d.oertel@uib.de>  Wed, 28 May 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.4.3-2) stable; urgency=low

fix in setup_after_install

-- detlef oertel <d.oertel@uib.de>  Thu, 22 May 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.4.3-1) stable; urgency=low

use of opsisetuplib.py
property imagename now editable
Swapoff all to avoid disk in use

lvmClearVolumeGroups() to avoid disk in use

-- detlef oertel <d.oertel@uib.de>  Fri, 28 Mar 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.4.2-2) stable; urgency=low

syntax fix

-- detlef oertel <d.oertel@uib.de>  Thu, 27 Feb 2014 16:01:53 +0200

opsi-local-image-win7 (4.0.4.2-1) stable; urgency=low

uefi / gpt support

-- detlef oertel <d.oertel@uib.de>  Mon, 30 Dec 2013 16:01:53 +0200

opsi-local-image-win7 (4.0.4.1-2) stable; urgency=low

UCS 3.2 Errata 4 fix: mount share from PE with valid domain: shareusername via webservice from clientconfig.depot.user
```
-- detlef oertel <d.oertel@uib.de>  Thu, 16 Jan 2014 16:01:53 +0200
```

opsi-local-image-win7 (4.0.4.1-1) stable; urgency=low

new product property setup_after_install: list of products which will be switched to setup with dependencies
if backup_after_install is true, the product property imageFile of opsi-local-image-backup will be set to '' (empty)

— detlef oertel <d.oertel@uib.de> 16 Dec 2013

opsi-local-image-win7 (4.0.3.2-1) stable; urgency=low

Now works also with 4 partitions

— detlef oertel <d.oertel@uib.de> 01 Aug 2013

opsi-local-image-win7 (4.0.3-2) stable; urgency=low

better error messages on wrong partition table

-- uib GmbH <info@uib.de>  Wed, 17 Apr 2013 13:30:20 +0000

opsi-local-image-win7 (4.0.3-1) experimental; urgency=low

changed to match opsi-local-image standard

-- uib GmbH <info@uib.de>  Wed, 13 Feb 2013 13:30:20 +0000

opsi-local-image-ubuntu

opsi-local-image-ubuntu (4.0.5.1-1) stable; urgency=low

ports from the 4.0.5 ubuntu product
trusty now default release
more keymaps

property setup_after_install default now: "l-os-postinst"

-- detlef oertel <d.oertel@uib.de>  Mon, 11 Aug 2015 16:01:53 +0200

opsi-local-image-ubuntu (4.0.4.3-1) stable; urgency=low

use of opsisetuplib.py

-- detlef oertel <d.oertel@uib.de>  Mon, 07 Apr 2014 16:01:53 +0200

opsi-local-image-ubuntu (4.0.4.2-1) stable; urgency=low

uefi / gpt support

-- detlef oertel <d.oertel@uib.de>  Mon, 30 Dec 2013 16:01:53 +0200

opsi-local-image-ubuntu32 (4.0.4.1-1) stable; urgency=low

new product property setup_after_install: list of products which will be switched to setup with dependencies
if backup_after_install is true, the product property imageFile of opsi-local-image-backup will be set to '' (empty)

— detlef oertel <d.oertel@uib.de> 16 Dec 2013

opsi-local-image-ubuntu32 (4.0.3.2-2) stable; urgency=low

fix for 4 Partions (3rd part may be with label swap or winpe

— detlef oertel <d.oertel@uib.de> 24 Sep 2013

opsi-local-image-ubuntu32 (4.0.3.2-1) stable; urgency=low

Now works also with 4 partitions

— detlef oertel <d.oertel@uib.de> 01 Aug 2013

opsi-local-image-ubuntu32_4.0.3-3 stable; urgency=low

fixes in desktop installation of xfce and unity
desktop cinnamon added

— uib GmbH <info@uib.de> Mon, 1 Jul 2013 13:30:20 +0000

opsi-local-image-ubuntu32_4.0.3-2 stable; urgency=low

better error messages on wrong partition table

— uib GmbH <info@uib.de> Wed, 17 Apr 2013 13:30:20 +0000

opsi-local-image-ubuntu32_4.0.3-1 testing; urgency=low

changes to match opsi-local-image standard

— Detlef Oertel <d.oertel@uib.de> Fri, 01 Feb 2013:15:00:00 +0200

14.1.7. Changelog python-opsi

python-opsi (4.0.5.15-1) experimental; urgency=low

Patching sudoers: allow using service when no TTY present

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 22 Oct 2014 14:30:24 +0200

python-opsi (4.0.5.14-1) experimental; urgency=low

10_opsi.conf: New methods getHardwareAuditDataCount and getSoftwareAuditDataCount
DHCPD backend: Fix logging problem caused by string / unicode mixup.
OPSI.System.Posix.getServiceNames: Prefer "systemctl" over "service" to have a solution that flawlessly works on CentOS 7.

OPSI.System.Posix.locateDHCPDInit: Added search via getServiceNames

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 22 Oct 2014 12:23:35 +0200

python-opsi (4.0.5.13-1) experimental; urgency=low

OPSI.System.Posix.Distribution: stripping the distribution attribute.

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 14 Oct 2014 15:34:21 +0200

python-opsi (4.0.5.12-1) experimental; urgency=low

More work on OPSI.System.Posix.getSambaServiceName

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 08 Oct 2014 14:50:17 +0200

python-opsi (4.0.5.11-2) experimental; urgency=low

Dropping python-simplejson as dependency because it is Pythons stdlib as json since Python 2.6
```
-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 08 Oct 2014 11:43:34 +0200
```

python-opsi (4.0.5.11-1) experimental; urgency=low

MySQL-backend: lower log-level for messages regarding transactions

Posix: added Methods getServiceNames and getSambaServiceName

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 06 Oct 2014 15:58:24 +0200

python-opsi (4.0.5.10-1) stable; urgency=low

DHCPD.py: small fix in restarting dhcp-service

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Wed, 01 Oct 2014 16:54:50 +0200

python-opsi (4.0.5.9-1) stable; urgency=low

opsi-setup: changed restarting services over service calls instead of using init-scripts directly.
```
-- Erol Ueluekmen <e.ueluekmen@uib.de>  Wed, 01 Oct 2014 16:14:13 +0200
```

python-opsi (4.0.5.8-2) testing; urgency=low

python-crypto requirement modified for sles to python-pycrypto

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Mon, 29 Sep 2014 10:13:17 +0200

python-opsi (4.0.5.8-1) testing; urgency=low

FileBackend raises Exception if getRawData method is called.

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Tue, 23 Sep 2014 15:16:56 +0200

python-opsi (4.0.5.7-1) experimental; urgency=low

Preferring ldaptor over OPSI.ldaptor

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 10 Sep 2014 13:36:47 +0200

python-opsi (4.0.5.6-2) experimental; urgency=low

rpm-based packages: require python-pyasn1

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 09 Sep 2014 16:55:20 +0200

python-opsi (4.0.5.6-1) experimental; urgency=low

Fix for certificate creation on SLES11SP3

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 25 Aug 2014 15:26:42 +0200

python-opsi (4.0.5.5-1) testing; urgency=medium

setProductActionRequestWithDependencies: added optional force parameter, to set dependend products even if they are installed
```
-- Erol Ueluekmen <e.ueluekmen@uib.de>  Sat, 23 Aug 2014 02:37:20 +0200
```

python-opsi (4.0.5.4-3) testing; urgency=low

Also build on Ubuntu 10.04

-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 22 Aug 2014 17:28:08 +0200

python-opsi (4.0.5.4-2) experimental; urgency=low

40_groupActions.conf: _getClientsOnDepotByHostGroup get correct clients.

Debian: call dh --with python2

-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 22 Aug 2014 17:18:16 +0200

python-opsi (4.0.5.3-2) experimental; urgency=low

SLES: Require libmagic1 for working python-magic

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 19 Aug 2014 12:55:00 +0200

python-opsi (4.0.5.3-1) experimental; urgency=low

Fix termination of KillableThread on newer Pythons

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 11 Aug 2014 14:09:02 +0200

python-opsi (4.0.5.2-7) experimental; urgency=low

RHEL / CentOS: Depending on MySQL-python instead python-mysql

openSUSE / SLES: Fix depending on wrong version number for python-newt

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 06 Aug 2014 12:10:08 +0200

python-opsi (4.0.5.2-5) experimental; urgency=low

Dependencies for RHEL / CentOS 6 fixed and cleaned up .spec.

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 06 Aug 2014 11:20:25 +0200

python-opsi (4.0.5.2-4) experimental; urgency=low

Re-Enabling dependency on python-ldaptor.

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 16:39:12 +0200

python-opsi (4.0.5.2-2) experimental; urgency=low

Possible to build with python-support again.

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 14:35:00 +0200

python-opsi (4.0.5.2-1) experimental; urgency=low

fix in write method for backendConfigFiles

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Sun, 03 Aug 2014 03:26:28 +0200

python-opsi (4.0.5.1-2) experimental; urgency=low

Using dh_python2

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 30 Jul 2014 17:38:00 +0200

python-opsi (4.0.5.1-1) experimental; urgency=low

New module: OPSI.Util.Task.Sudoers
70_dynamic_depot.conf: Latency algorythm does even work if pinging a depot results in a timeout.
OpsiBackupArchive: Avoid hanging in an endless loop when running backupMySQLBackend and stderr gets spammed with the same message
DHCPD Backend: Trying to read the address of an client from the DHCPD configuration file if it can’t be resolved via DNS.
Certificate Creation: Using 2048 bit instead of 1024
small fix in getOpsiHostKey method
configed: direct access for mysql-backend users
forceUrl method don’t convert value to lower
OpsiBackupArchive: get path to mysqldump via which
Speeding up backend_getInterface, getArgAndCallString, objectToHtml, objectToBeautifiedText
New module: OPSI.Util.Task.ConfigureBackend.ConfigurationData
Added possibility to disable pigz in opsi.conf
SQL-Backends: Improved speed of query creation
Do not fail on removing installed products if the directory contains filenames with unicode characters
OPSI.System.Posix: Fixing reread partiontable problem with new bootimage
OPSI.System.Windows: Added setLocalSystemTime and getServiceTime in backend
Driverintegration: Fallback for byAudit to check if mainboard integration is possible.
OPSI.System.Posix: initializing bytesPerSector attribute in Harddisk class constructor
OPSI.Util.Repository: workarround timing problem after reconnect network adapter
```
-- Erol Ueluekmen <e.ueluekmen@uib.de>  Thu, 28 Jul 2014 23:51:00 +0200
```

14.1.8. Changelog opsipxeconfd

opsipxeconfd (4.0.5.3-6) experimental; urgency=low

Removal on RHEL/CentOS should not fail anymore.

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 09 Sep 2014 16:21:06 +0200

opsipxeconfd (4.0.5.3-5) experimental; urgency=low

RPM: Fix problems with macro syntax.

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 09 Sep 2014 15:04:12 +0200

opsipxeconfd (4.0.5.3-4) experimental; urgency=low

RHEL/CentOS: Only removing the daemon in postun

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 09 Sep 2014 14:21:31 +0200

opsipxeconfd (4.0.5.3-3) experimental; urgency=low

RHEL/CentOS: fixing problems on uninstall

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 09 Sep 2014 12:30:07 +0200

opsipxeconfd (4.0.5.3-2) experimental; urgency=low

Fix for logrotate under SLES11SP3

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 25 Aug 2014 11:36:03 +0200

opsipxeconfd (4.0.5.3-1) experimental; urgency=low

Fix in modules handling

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Thu, 07 Aug 2014 01:45:00 +0200

opsipxeconfd (4.0.5.2-1) experimental; urgency=low

Fix in custom pxeConfTemplate-file handling.

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Mon, 04 Aug 2014 16:09:14 +0200

opsipxeconfd (4.0.5.1-3) experimental; urgency=low

Support for building with python-support added again.

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 14:48:15 +0200

opsipxeconfd (4.0.5.1-2) experimental; urgency=low

Changed build system to dh_python2

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 30 Jul 2014 17:33:46 +0200

opsipxeconfd (4.0.5.1-1) experimental; urgency=low

Correctly stopping the service on non-SUSE machines on upgrade/uninstall

uefi support

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Tue, 08 Jul 2014 11:59:08 +0200

14.1.9. Changelog opsiconfd

opsiconfd (4.0.5.2-1) experimental; urgency=low

Info page: display the correct percentage if calls failed
Statistics: display correct result-length if returned type is dict
Info page: Show more info about threads if possible

RHEL / CentOS 7 and Fedora: Fix logrotate configuration

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 20 Oct 2014 09:38:46 +0200

opsiconfd (4.0.5.1-7) experimental; urgency=low

Fix for newer logrotate-versions not applied on SLES because 11SP3 provides an updated version that can handle su directive
```
-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 19 Aug 2014 16:41:48 +0200
```

opsiconfd (4.0.5.1-6) experimental; urgency=low

Suggesting only on SLES, not everyone.

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 13 Aug 2014 16:27:34 +0200

opsiconfd (4.0.5.1-5) experimental; urgency=low

python-rrdtool is not required but suggested.

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 13 Aug 2014 16:14:13 +0200

opsiconfd (4.0.5.1-4) experimental; urgency=low

Lowering required debhelper version for building Ubuntu 10.04

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 14:25:31 +0200

opsiconfd (4.0.5.1-3) experimental; urgency=low

Re-enabling build dependency python-support for older distros.

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 13:59:27 +0200

opsiconfd (4.0.5.1-2) experimental; urgency=low

Using dh_python instead of python-support

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 30 Jul 2014 17:29:48 +0200

opsiconfd (4.0.5.1-1) experimental; urgency=low

Improved info page render speed.
Info page: show additional information about running threads

Info page: display human-readable time at thread information

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 10 Jun 2014 12:36:13 +0200

14.1.10. Changelog opsi-utils

opsi-utils (4.0.5.6-2) experimental; urgency=low

Suse: listing /etc/opsi as directory

-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 10 Oct 2014 16:49:48 +0200

opsi-utils (4.0.5.6-1) experimental; urgency=low

[ Erol Ueluekmen ]
* opsi-package-manager: new option --set-file-level added.

[ Niko Wenselowski ]
* RPM: changing the specfile to avoid conflicts

-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 10 Oct 2014 16:38:07 +0200

opsi-utils (4.0.5.5-1) testing; urgency=low

opsi-newprod: Fix missing newlines in postinst/preinst

-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 29 Aug 2014 12:04:51 +0200

opsi-utils (4.0.5.4-1) experimental; urgency=low

opsi-newprod correctly copies the contents of the template-directory

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 13 Aug 2014 11:31:53 +0200

opsi-utils (4.0.5.3-2) experimental; urgency=low

Fix for reading the home dir.

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 11 Aug 2014 15:53:58 +0200

opsi-utils (4.0.5.3-1) experimental; urgency=low

opsi-admin: Added another try on reading the users home directory.

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 05 Aug 2014 17:02:03 +0200

opsi-utils (4.0.5.2-2) experimental; urgency=low

Make building with Fedora possible.

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 04 Aug 2014 15:53:19 +0200

opsi-utils (4.0.5.2-1) experimental; urgency=low

opsi-product-updater: small bugfix

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Sun, 03 Aug 2014 03:35:50 +0200

opsi-utils (4.0.5.1-1) experimental; urgency=low

opsi-newprod: New feature -t: Copy files from a template directory
opsi-package-manager: Now able to use -t when extracting
opsi-product-updater: Support for smtpuser and smtppassword to be able to use it with systems that require authentication.
opsi-product-updater: Support for SMTP connections that use STARTTLS
Debian: Recommend mysql-client as it is useful when creating backups
opsi-makeproductfile: new option --no-pigz to disable pigz usage
opsi-package-manager: Product properties are sorted by name when installing a product with "-p ask".
opsi-product-updater: Fix handing over the temp directory when installing a package.
opsi-product-updater: ProductPackageFile now uses setting "tempDir"
opsi-product-updater: Added inherit ProductProperties from Master-Repository
opsi-product-updater: Stops if unknown parameter is given on start

opsi-product-updater: Limit updates to specific package with "-p"

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Fri, 26 Jul 2014 00:03:13 +0200

14.1.11. Changelog opsi-linux-bootimage

opsi-linux-bootimage (20140919-2) stable; urgency=medium

small fix in spec file

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Wed, 01 Oct 2014 00:56:26 +0200

opsi-linux-bootimage (20140919-1) testing; urgency=medium

fixing netbios nameresolution
advice for screen -x possibility added

workarround for scanning devices on HP Smart Array Controller

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Fri, 19 Sep 2014 10:03:09 +0200

opsi-linux-bootimage (20140819-1) experimental; urgency=medium

lshw updated to B.02.17

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Tue, 19 Aug 2014 02:10:29 +0200

opsi-linux-bootimage (20140811-1) experimental; urgency=medium

IA-32Emulation for 64 bit bootimage

Added opsi-utils to package dependencies

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Tue, 12 Aug 2014 12:50:47 +0200

opsi-linux-bootimage (20140729-1) experimental; urgency=low

Posix.py: Fix for unrecognized partition table Fix for readRotational method
```
-- Erol Ueluekmen <e.ueluekmen@uib.de>  Tue, 30 Jul 2014 01:47:48 +0200
```

opsi-linux-bootimage (20140725-1) experimental; urgency=low

updated pigz to ver 2.3.1
updated sfdisk to ver 2.25
added fixed bytesPerSector problem in Posix.py

modprobe patched for bootimage

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Thu, 25 Jul 2014 10:21:05 +0200

opsi-linux-bootimage (20140717-1) experimental; urgency=low

Bases on Ubuntu Precise (12.04)
kernel 3.15.1
python-opsi 4.0.5.1

uefi-support added

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Fri, 04 Jul 2014 14:53:13 +0200

14.1.12. Changelog opsi-depotserver

opsi-depotserver (4.0.5.11-1) experimental; urgency=low

Only fetching the Samba init command if configuring Samba

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 22 Oct 2014 13:40:03 +0200

opsi-depotserver (4.0.5.10-3) experimental; urgency=low

Debian-based postinst: Avoid problems with arguments possibly not executed by opsi-setup
```
-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 21 Oct 2014 13:40:03 +0200
```

opsi-depotserver (4.0.5.10-2) experimental; urgency=low

Red Hat-familiy: added requirement samba-client for current distros

-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 17 Oct 2014 14:24:41 +0200

opsi-depotserver (4.0.5.10-1) experimental; urgency=low

Providing a default for the name of the Samba service

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 08 Oct 2014 14:54:13 +0200

opsi-depotserver (4.0.5.9-1) experimental; urgency=low

Fix for creating the service command

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 08 Oct 2014 12:08:26 +0200

opsi-depotserver (4.0.5.8-1) experimental; urgency=low

Getting the Samba service name does not depend on files in /etc/init.d

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 08 Oct 2014 11:01:50 +0200

opsi-depotserver (4.0.5.7-1) stable; urgency=low

opsi-setup: changed restarting services over service calls instead of using init-scripts directly.
```
-- Erol Ueluekmen <e.ueluekmen@uib.de>  Wed, 01 Oct 2014 15:26:16 +0200
```

opsi-depotserver (4.0.5.6-3) experimental; urgency=low

Removed automatic update of mysql-backend.

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 08 Sep 2014 12:37:51 +0200

opsi-depotserver (4.0.5.6-2) testing; urgency=medium

small fix in postinst routine of package.

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Sat, 23 Aug 2014 04:44:07 +0200

opsi-depotserver (4.0.5.6-1) experimental; urgency=medium

--auto-configure-samba fix for executebit problem even if opsi_depot-Shareconfig already exists.
```
-- Erol Ueluekmen <e.ueluekmen@uib.de>  Sun, 17 Aug 2014 13:42:03 +0200
```

opsi-depotserver (4.0.5.5-1) experimental; urgency=low

--auto-configure-dhcpd does not fail on missing file

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 11 Aug 2014 17:31:12 +0200

opsi-depotserver (4.0.5.4-1) experimental; urgency=low

Workaround for getopt not correctly reading in JSON objects.

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 05 Aug 2014 12:29:21 +0200

opsi-depotserver (4.0.5.3-1) experimental; urgency=low

Renewing a certificate automatically sets rights on file

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 05 Aug 2014 10:39:18 +0200

opsi-depotserver (4.0.5.2-1) experimental; urgency=low

Fix in samba4 detection

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Sun, 03 Aug 2014 00:56:54 +0200

opsi-depotserver (4.0.5.1-1) experimental; urgency=low

Using OPSI.Util.Task.ConfigureBackend.MySQL
Samba4 Fix
RHEL / CentOS: Running --auto-configure-dhcp grants rights to opsi administrator group on /etc/dhcp
Create configuration item "clientconfig.dhcpd.filename" on update

Using OPSI.Util.Task.ConfigureBackend.ConfigurationData

-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 30 May 2014 11:48:09 +0200

14.1.13. Changelog opsi-atftp

opsi-atftp (0.7.dfsg-4) stable; urgency=medium

debian/compat added

--enable-debug added

-- Erol Ueluekmen <e.ueluekmen@uib.de>  Sat, 23 Aug 2014 04:26:11 +0200

14.1.14. Changelog opsi4ucs

opsi4ucs (4.0.5.5-4) experimental; urgency=low

Using newer version of Debhelper

-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 24 Oct 2014 11:50:09 +0200

opsi4ucs (4.0.5.5-3) experimental; urgency=low

Changed filename of Configed icon

-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 24 Oct 2014 10:47:20 +0200

opsi4ucs (4.0.5.5-2) experimental; urgency=low

UCS 3.2: Integration in administration overview page

-- Niko Wenselowski <n.wenselowski@uib.de>  Thu, 23 Oct 2014 14:55:31 +0200

opsi4ucs (4.0.5.5-1) experimental; urgency=low

Only fetching the Samba init command if configuring Samba

-- Niko Wenselowski <n.wenselowski@uib.de>  Wed, 22 Oct 2014 13:51:46 +0200

opsi4ucs (4.0.5.4-2) experimental; urgency=low

Make use of OPSI.System.Posix.getSambaServiceName

Changed Samba4 detection to work on all UCS 3.x

-- Niko Wenselowski <n.wenselowski@uib.de>  Fri, 17 Oct 2014 14:57:54 +0200

opsi4ucs (4.0.5.3-1) experimental; urgency=low

99opsi4ucs.inst: fix detection of Samba 4 and also work on UCS 3.2

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 15 Sep 2014 14:01:49 +0200

opsi4ucs (4.0.5.2-1) experimental; urgency=low

--auto-configure-dhcpd does not fail on missing file

-- Niko Wenselowski <n.wenselowski@uib.de>  Mon, 11 Aug 2014 17:33:00 +0200

opsi4ucs (4.0.5.1-1) experimental; urgency=low

Using OPSI.Util.Task.ConfigureBackend.MySQL
Create configuration item "clientconfig.dhcpd.filename" on update
Using OPSI.Util.Task.ConfigureBackend.ConfigurationData
Renewing a certificate automatically sets rights on file

Workaround for getopt not correctly reading in JSON objects.

-- Niko Wenselowski <n.wenselowski@uib.de>  Tue, 05 Aug 2014 10:51:18 +0200

14.1.15. Changelog opsi-swaudit

swaudit (4.0.5-1) stable; urgency=low

Fix writing to long entries in sub_create_hash4 by adding to all string values something like "name="+strPart($name$,"1","99")
codecleanup

changelog to control file

-- detlef oertel <d.oertel@uib.de>  Fri, 01 Aug 2014 15:00:00 +0100

 [[opsi-405-releasenotes-misc-changelogs-opsi-template]]
==== Changelog opsi-template

opsi-template (4.0.5-1) stable; urgency=low

setup*.*: fix: ALLUSERS=1
require opsi-winst 4.11.4
Set $LogDir$ = "%opsiLogDir%"
all renamed from *.ins to *.opsiscript
moved 64bit, 3264bit, short (with include) and delsub for multi msi to subfolders

new property dummy_prop

-- detlef oertel <d.oertel@uib.de>  Mon, 03 Nov 2014 16:01:53 +0200