WPKG 2: Windows-Softwareverteilung einrichten

WPKG

Im letzten Artikel habe ich über meine Beweggründe geschrieben, warum ich WPKG einsetze. In diesem Artikel soll es nun praktisch werden. Wie installiert man WPKG?

Installation

Server

WPKG benötigt im Grunde keine Installation auf dem Server. Das Downloadpaket wird auf dem Server lediglich entpackt und über einen Samba-Share verfügbar gemacht:

[wpkg]
    comment = WPKG Repository
    path = /media/shares/wpkg
    valid users = %U,@"Domain Computers"
    admin users = wpkg,root
    write list = @"Domain Computers",root
    read list = @"Domain Users"
    browseable = No

Die Konfiguration erfolgt über die Datei config.xml (Auszug):

<param name='wpkg_base' value='http://wpkg:secret@$SERVERIP/wpkg' />
<param name='wpkg_base' value='http://$SERVERIP/wpkg' />
<param name='force' value='false' />
<param name='forceInstall' value='false' />
<param name='quitonerror' value='false' />
<param name='debug' value='false' />
<param name='dryrun' value='false' />
<param name='quiet' value='true' />
<param name='nonotify' value='true' />
<param name='notificationDisplayTime' value='0' />
<param name='noreboot' value='true' />
<param name='noRunningState' value='false' />
<param name='caseSensitivity' value='true' />
<param name='applyMultiple' value='false' />
<param name='noDownload' value='false' />
<param name='rebootCmd' value='standard' />
<param name='settings_file_name' value='wpkg.xml' />
<param name='settings_file_path' value='%SystemRoot%\\system32' />
<param name='noForcedRemove' value='false' />
<param name='noRemove' value='false' />
<param name='sendStatus' value='false' />
<param name='noUpgradeBeforeRemove' value='false' />
<param name='settingsHostInfo' value='true' />
<param name='volatileReleaseMarker' value='gamma' />
<param name='volatileReleaseMarker' value='delta' />
<param name='volatileReleaseMarker' value='testing' />
<param name='logAppend' value='false' />
<param name='logLevel' value='0xFF' />
<param name='log_file_path' value='\\\\$SERVERIP\\wpkg\\logs' />
<param name='logfilePattern' value='[HOSTNAME].log' />
<param name='packages_file_name' value='packages.xml' />
<param name='profiles_file_name' value='profiles.xml' />
<param name='hosts_file_name'    value='hosts.xml' />
<param name='web_packages_file_name' value='packages.xml' />
<param name='web_profiles_file_name' value='profiles.xml' />
<param name='web_hosts_file_name'    value='hosts.xml' />
<param name='sRegPath' value='SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Uninstall' />
<param name='sRegWPKG_Running' value='HKLM\\Software\\WPKG\\running' />

Was die einzelnen Zeilen bedeuten ist anhand von Kommentaren innerhalb der config.xml gut erläutert. Wichtig ist hier eigentlich nur $SERVERIP durch die IP-Adresse des Samba/WPKG-Servers zu ersetzen.

Als Interface wird wpkgExpress verwendet. Wie dies geht wird in einem weiteren Artikel erläutert.

Client

WPKG wird per Logon-Script gestartet und benötigt daher keinerlei Installation auf den Clientrechnern.

Konfiguration

WPKG ist gegliedert in Packages, Profiles und Hosts. Konfiguriert werden diese über wpkgExpress: http://$SERVERIP/wpkg/

Packages

Über Packages werden die Installationspakete definiert. Hier werden Checks und Actions definiert, welche die eigentliche Installation steuern. Ein Package ist immer einem oder mehreren Profiles zugeordnet.

Wichtig sind die Checks in einem Package, vor der Installation müssen diese "false" zurückliefern. Nach der Installation "true", andernfalls wird das Paket nicht installiert bzw. gilt die Installation als fehlgeschlagen (=> beim nächsten herunterfahren wird eine erneute Installation vorgenommen). Es ist daher im Zweifel sehr wichtig entsprechende Logikverknüpfungen in die Checks einzubauen.

Ein rudimentäres Package sieht wie folgt aus:

<package id="7zip" name="7zip" revision="9.20" priority="100" reboot="false">
  <variable name="version" value="9.20"/>
  <check type="logical" condition="or">
    <check type="file" condition="versionequalto" path="%PROGRAMFILES (x86)%\7-Zip\7z.exe" value="%version%"/>
    <check type="file" condition="versionequalto" path="%PROGRAMFILES%\7-Zip\7z.exe" value="%version%"/>
  </check>
  <install cmd="\\192.168.1.21\wpkg\software\7zip\install.bat"/>
  <upgrade cmd="\\192.168.1.21\wpkg\software\7zip\install.bat"/>
</package>

Zunächst wird id und name definiert. Diese dienen zur Identifikation des Package und sollten Bezug auf die über das Package zu installierende Software nehmen.

Die revision gibt die Version des Packages selbst an, verändert sich die Revision wird die Installation des Package erneut durchgeführt: [[http://wpkg.org/Execute_once_/_always]], in der Regel wird dann die upgrade-Anweisung ausgeführt.

Über priority kann die Reihenfolge von Installationen beeinflusst werden, ohne Dependencies nutzen zu müssen. So macht es z.B. Sinn zunächst Firefox und erst anschließend das Adobe Flashplugin zu installieren. Ein höherer Wert wird bevorzugt installiert.

Der Parameter reboot gibt an, ob nach der Installation ein Neustart des Rechners erforderlich ist. notify hat keinerlei Auswirkung, da der Client mit /nonotify installiert wurde.

Anschließend wird eine Variable für die Versionsnummer des zu installierenden Programms erzeugt. Dies ist nicht zwingend notwendig, da der Wert aber im weiteren Verlauf des Package mehrfach benutzt wird (checks), ist es aber sinnvoll. Die Versionsnummer ergibt sich aus dem Wert Dateiversion des jeweiligen Programms. Der Wert kann über "Eigenschaften/Details" (Rechtsklick auf die entsprechende Datei) abgefragt werden.

Damit ein Package nicht bei jedem Start eines Rechner die entsprechende Software erneut installiert ist es notwendig über check die derzeit installierte Version (sofern vorhanden) zu prüfen. Alternativ kann execute auf Once gesetzt werden, dann kann die Installation über die Revision gesteuert werden, dies ist jedoch unsauber. (Normalerweise wird anhand der Datei c:\windows\system32\wpkg.xml geprüft, ob eine Software bereits installiert ist, so sollte diese auch ohne Checks nicht erneut installiert werden. Wenn es jedoch während einer Installation zu einem Fehler kommt passiert dies (bis zu einem fehlerfreien Lauf), ohne Checks, u.U. dennoch.)

Ein check ist sehr flexibel, es können anstatt auf Dateien z.B. auch Registry-Werte für eine Überprüfung genutzt werden: [[http://wpkg.org/Packages.xml#Check_conditions_.2F_check_type]]

Bei den Regeln ist zu beachten, dass der Erfolg der Installation ebenfalls anhand der check-Regeln überprüft wird. Gibt man also als Check less than bei einer Versionsprüfung an schlägt diese nach der Installation fehl. Es sollte also immer greaterorequal bzw. lessorequal verwendet werden. In der Regel ist greaterorequal das Mittel der Wahl, so bleiben manuell installierte neuere Versionen eines Programms unangetastet.

Wenn die revision erhöht wird, wird unabhängig von den Checks ein Upgrade für das Package durchgeführt.

Da auf 64-Bit-Systemen Programme in unterschiedlichen Verzeichnissen abgelegt werden, ist ein or-Check auf beide möglichen Verzeichnisse notwendig. Alternativ kann ein Registry-Wert genutzt werden.

Abschließend werden die Befehle (cmd) zur Installation (install) bzw. zum Aktualisieren (upgrade) sowie ggf. zur Deinstallation (uninstall) angegeben.

Weitere Informationen zur Erstellung von Packages finden sich im WPKG-Wiki: [[http://wpkg.org/Packages.xml]], desweiteren finden sich im WPKG-Download einige sehr umfassende Beispiele.

Batchfiles

Oftmals erfordern Installationen verschiedene Aufrufe oder Installationspakete für 32-/64-bit-Systeme, hier bietet es sich an eine Batchdatei zu verwenden, da hier der Check auf 32-/64-bit sehr einfach, anhand der Umgebungsvariablen ProgramW6432, erfolgen kann und das Package somit übersichtlicher bleibt:

@echo off

if defined ProgramW6432 (
    REM do 64bit stuff
    msiexec /qn /norestart /i \\$SERVERIP\wpkg\software\7zip\7z920-x64.msi
) else (
    REM do 32bit stuff
    \\$SERVERIP\wpkg\software\7zip\7z920.exe /S
)

Die Batchdatei kann dann als Installationsquelle im Paket vermerkt werden.

Packages ohne Checks

Es ist auch möglich Packages ohne Checks zu verwenden. Hierbei wird im Package der Execute-Parameter auf once gesetzt. WPKG führt dann beim ersten Aufruf des Package den Install-Befehl aus. Ändert sich die Revision des Package wird der Upgrade-Befehl ausgeführt.

Dieses Verfahren erleichtert die Verwaltung der Softwareverteilung enorm, da keine Dateiversion/-größen etc. ausgelesen und im Package hinterlegt werden müssen. Allerdings geht WPKG dann immer von einer erfolgreichen Installation aus. Es sollte daher anhand einer Softwareliste geprüft werden, ob noch alte Versionen einer Software im Umlauf sind. Auch hierzu in einem späteren Artikel mehr.

Profiles

Über Profiles wird festgelegt, welche Packages auf welchen Hosts installiert werden sollen, indem einem Profile die gewünschten Packages zugeordnet werden. Profiles können voneinander abhängig sein.

Weitere Informationen zu Packages gibt es im WPKG-Wiki: [[http://wpkg.org/Profiles.xml]]

Hosts

Über Hosts werden Profiles einem bestimmten Rechner zugeordnet. Einem Host können auch mehrere Profile zugeordnet werden. Der Name eines Hosts entspricht immer dem jeweiligen Rechnernamen.

Weitere Informationen zu Hosts gibt es im WPKG-Wiki: [[http://wpkg.org/Hosts.xml]]

Testing

Alle Pakete müssen vor dem Ausrollen getestet werden, hierzu kann ein Profile test dienen, in diesem können dann Testrechner (z.B. Virtuelle Maschinen) eingebunden. In der Regel reicht es dann aus den Test über cscript \\$SERVERIP\wpkg\wpkg.js /synchronize /debug auszuführen. (Der WPKG-Client muss hierzu nicht installiert sein, wohl aber der Windows Scripting Host.)

Unter \\$SERVERIP\wpkg\logs\ werden, durch die oben genannte Config, entsprechende Logfiles erzeugt, sollte dies nicht der Fall sein wurde in das Windows-Eventlog geschrieben.

Tags: imported