Home > Arbeit, Computer & Technik, WPKG > WPKG: der zweite Bericht

WPKG: der zweite Bericht

So, mittlerweile sind ein paar Wochen seit dem ersten Zwischenbericht über WPKG ins Land gegangen. Und so wird es Zeit mal über meine Praxiserfahrung zu sprechen. Eigentlich wollte ich den bereits am Mittwoch schreiben, aber durch die Geschichte mit meinem Notebook bin ich zeitlich etwas zurückgeworfen worden.

Bevor ich in die Details gehe, das Wichtigste vorweg: WPKG ist immer noch im produktiven Einsatz, ich bin mit der Software sehr zufrieden. Lediglich so manche ältere Software, die für ein Deployment vorbereitet werden muss, macht mir zu schaffen.

Vielleicht erzähle ich noch kurz etwas über die Umgebung, wo ich WPKG derzeit einsetze: Ich arbeite nebenberuflich als IT Administrator an einem Chemie-Lehrstuhl an der TU München. Die Umgebung besteht aus 29 Arbeitsplatz-Rechnern, 11 Messrechnern (angeschlossen an Messeinrichtungen), 3 Laptops und 2 Windows 2003 Servern. Also eine eher kleine Umgebung, aber es gibt für den einen Administrator (=mich) immer genügend zu tun.

Alte Situation

Um eine Workstation neu zu installieren habe ich sie bisher via PXE booten lassen und dann von einem Windows Remote Installation Services (RIS)-Server ein komplettes „Workstation“-Image ziehen lassen. Das Image habe ich zuvor von einer „Muster-Maschine“ erstellt. Der Client war somit innerhalb von einer dreiviertel Stunde fertig eingerichtet. Die Geschwindigkeit des Verfahrens ist perfekt, die Wartung der Softwareinstallation nicht. Denn will ich z.B. die neueste Firefox-Version auf die Rechner bringen muss ich entweder zu jedem Rechner laufen, dort die Installation per Hand ausführen oder ich erstelle ein neues Image und muss trotzdem bei jedem Rechner die PXE-Installation anstoßen – nicht sehr praktikabel!

Der Wechsel zu WPKG

Und genau da kommt jetzt das Software-Management mittels WPKG ins Spiel. Natürlich habe ich mir zuvor lange andere Lösungen angesehen, so z.B. unter anderem Microsoft System Management Server (SMS) 2003 und NetInstall. Microsoft SMS hatte ich sogar für kurze Zeit in der Praxis getestet. Aber alle Lösungen waren entweder zu teuer, zu kompliziert (weil zuviele Features) oder nicht flexibel genug (konnten z.B. nur msi-Pakete und exe-Dateien ausrollen, keine Skripte o.ä.)

WPKG ist da anders: klein, schlank und sogar Open-Source mit einer entsprechenden Community. Um WPKG nutzen zu können benötigt man keinen Windows-Server, lediglich ein Netzlaufwerk (das auch via Samba bereitgestellt werden kann) muss vorhanden sein. Auf den Clients selbst muss nicht unbedingt eine Software zur Nutzung von WPKG installiert sein, es genügt ein Aufruf des WPKG-Skripts auf dem Netzlaufwerk („cscript \\server\wpkg\wpkg.js /synchronize“). Trotzdem gibt es für den WPKG einen Client mit einer minimalen grafischen GUI, der einem ein bißchen Arbeit abnimmt.

Funktionsweise von WPKG

Das Herz von WPKG ist das zentrale in JScript geschriebene „wpkg.js“, hier liegt die ganze Programmlogik. Sämtliche Konfigurationsdateien sind in XML geschrieben, deren Syntax sehr leicht zu erlernen und auch auf den Internetseiten des Projektes gut dokumentiert ist. Mit dem Parameter „/synchronize“ stößt man den Deployment Prozess auf dem Client an. WPKG prüft nun, ob der Rechnername in der host.xml auftaucht und einem oder mehreren Profilen zugeordnet ist.  Ein Profil ist eine Liste von Programmen („packages“), die auf dem Rechner installiert sein müssen. Ein Profil kann wieder von anderen Profilen abhängen.  Falls der Rechner einem Profil zugeordnet ist, werden die einzelnen Pakete auf Vorhandensein überprüft und ggf. installiert. Die Möglichkeiten einer Paketdefinition („packages.xml“) sind dabei sehr vielfältig: Man kann Prüfbedingungen (Uninstall-Schlüssel, Registry-Eintrag, Datei) einbauen, wann die Software installiert werden darf. Es können beliebig viele „Install-Actions“, also Aktionen die für die Installation notwendig sind hinterlegt werden. Ebenso können spezielle Aktionen für upgrade (also Versionsänderung) oder remove (entfernen der Software vom Client) hinterlegt werden.
Nach Abschluss aller Aktionen schreibt WPKG die aktuelle Software-Inventarliste samt Paket-Definition auf dem Client in die Datei c:\windows\system32\wpkg.xml

Ablauf des Deployments in WPKG

1. Vorbereiten der Software

Zunächst – und das ist die schwierigste und längste Arbeit – muss die gewünschte Software, die über WPKG installiert werden soll, so vorbereitet werden, dass eine Installation ohne Benutzerinteraktion möglich ist. Sollte das Programm kein Exot sein, finden sich in der hauseigenen Wiki-Datenbank von WPKG oder bei AppDeploy.com Tipps und Lösungen wie man die gewünschte Software silent bekommt. In der Regel werden Installer von InstallShield, Nullsoft u.ä. verwendet, die in der Regel auf die Standard-Schalter hören:

  • MSI-Installer:   msiexec /i <datei.msi> /qn
  • Innosetup:   <datei.exe> /verysilent
  • Nullsoft Installer:  <datei.exe /S
  • InstallShield-Exe, dass nach dem Entpacken ein MSI startet:  <datei.exe> /s /v“/qn“
  • InstallShield: <datei.exe> /s

Eine gute Übersicht über die gängisten Silent-Switsches bekommt man hier. Ein ganz nettes Programm namens Universal Silent Switch Finder (USSF) nimmt als Argument die Setup-Datei und verrät dann wie man um welchen Installer es sich handelt.

Wenn gar nichts hilft kommt man nicht darum herum, einen Vorher-Nachher Snapshot zu erzeugen. Das gelingt dem Programm WinInstall LE 2003 (diese Version ist Freeware, allerdings nur noch sehr schwer im Netz zu finden) ganz gut. Jedoch sollte man unbedingt nochmal kontrollieren, ob nicht aus versehen, Windows-Dateien mit erfasst wurden – soetwas führt später zu großen Problemen beim Ausrollen! Am Ende erzeugt WinInstall dann eine MSI-Datei, die sich auf die bereits bekannte Weise in WPKG einpflegen läßt.

2. Anlegen des Paketes in WPKG

Man kann für jedes Paket eine eigene XML-Datei anlegen, was man unbedingt tun sollte. Sonst wird es einfach zu unübersichtlich wenn alles in der einen packages.xml-Datei steht. Zur Syntax habe ich vorher bereits ein kurzes Wort darüber verloren, ich verweise hier auf die Wiki-Seite, alles andere würde den Rahmen sprengen. Wenn man zur Vorbereitung alles geklärt hatte (welche zusätzlichen Befehle sind noch notwendig, muss evtl. noch etwas angelegt/gelöscht werden) sollte der Schritt schnell von der Hand gehen.

3. Ausrollen

Jetzt muss das gerade angelegte Paket nur noch zu den entsprechenden Profilen hinzugefügt werden. Sobald nun die entsprechenden Clients das WPKG-Skript starten sollte die Software installiert werden. Sollte es zu einem Fehler kommen kann im Windows-Eventlog relativ detailiert nachgelesen werden woran es lag.

Die häufigsten Fehler bei mir waren Tippfehler (Pfad falsch geschrieben, daraufhin mault das MSI mit Fehler 1619) oder ich habe vergessen bei DOS-Befehlen wie z.B. copy/del  ein „cmd /c“ voranzustellen (sonst können die Befehle nicht gestartet werden).

WPKG-Client

Für die Clients gibt es auch einen Dienst/GUI (GUI kann abgeschaltet werden), der lokal installiert, bei jedem Starten oder Herunterfahren des PCs sich mit dem WPKG-Server verbindet, das Skript startet, die Software installiert und am Ende die Verbindung wieder trennt. Der Vorteil des WPKG Clients, sind die vielen Einstellungsmöglichkeiten. Beispielweise kann ich einstellen, dass die Anmeldung verzögert wird, damit WPKG Software installieren kann (es erscheint dann ein schicker Screen, wo der Benutzer auf die Aktivität hingewiesen wird). Das schöne ist, dass dieser Service keine Ressourcen verschlingt, da er sich nach seiner Aktivität wieder beendet.

In eigener Sache: Die Einstellung, dass der Hinweis erscheint, dass gerade WPKG läuft, habe ich aber deaktiviert, weil dieser Hinweis beim Starten des PCs immer gleich erschienen ist, auch wenn nichts zu tun war. (solange der WPKG-Client nämlich im Hintergrund wurstelt, blendet er das ein) Damit die Benutzer nicht wahnsinnig werden oder komische Fragen stellen, habe ich den Screen abgeschalten. Sollte irgendwann der Dialog nur noch erscheinen wenn tatsächlich Software installiert wird, blende ich ihn wieder ein.

Neue Situation

Seit ich WPKG produktiv einsetze, wird über RIS nur noch das Basis-Betriebssystem einschließlich WPKG-GUI-Client verteilt. Sobald der Rechner nun hochfährt beginnt die Software-Installation über WPKG. Dabei werden 62 Programme/Pakete über WPKG installiert, 28 davon sind Spezial-Programme, die wohl eher nicht am normalen Privat-PC genutzt werden. Weitere Programme sind bereits in Planung.

Ein Problem, dass ich hatte, als ich soviele Programme auf einmal installiert habe war, dass InstallShield-Programme plötzlich nicht mehr sauber installiert wurden (Fehlermeldungen, teilweise wurde das Programm aber von WPKG als installiert erkannt obwohl es nicht installiert war). Das ganz habe ich durch Reboots nach einigen Programmen gelöst. (d.h. in regelmäßigen Abständen füge ich ein reboot=true in die package-Definition ein) – seitdem läufts.

Mein Addon: Startmenü-Manager(linkmanager)

Gerade bei vielen installierten Programmen wird das Startmenü schnell unübersichtlich. Aus diesem Grund ist es nötig eine gewisse Struktur hineinzubekommen, beispielsweise sämtliche Audio/Video Player in einen Unterordner „Audio Video“, sämtliche Office-Software in einen Ordner „Office“ usw.

Zunächst lasse ich mit einem WPKG-Package (sehr hohe Priorität, damit es vor allen anderen Installationen ausgeführt wird) die Ordnerstruktur des Startmenüs anlegen. (über ein VBS-Skript).

Jetzt muss ich nur noch die entsprechende Software-Installation dazu bekommen, den Link im entsprechenden Unterordner abzulegen. Manche Installer erlauben diese Einstellung durch einen zusätzlichen Parameter, die meisten Programme allerdings nicht. Falls es ein MSI ist, kann mit dem MSI-Editor Orca von Microsoft (gibts im Ressource Kit) die entsprechenden Shortcuts verbiegen. Für alle anderen Fälle habe ich mir einen kleinen „Link-Manager“ in VBS gebastelt, der im Anschluss an die jeweilige Programminstallation die Links korrigiert.

Folgende Parameter akzeptiert mein VBS-Programm:

  • link-manager link <link-target> <file> [working-directory]
    Erstellt eine Verknüpfung im Startmenü, das link-target wird relativ zum Startmenü-Ordner angegeben. Die Angabe des Working-Directory ist optional.
  • link-manager del-link <link-target>
    Löscht den Link aus dem Startmenü
  • link-manager folder <path-to-folder> <new-location>
    verschiebt ein Startmenü-Ordner innerhalb des Startmenüs. (Manche Programme legen ganze Ordner mit vielen Links ab). Bsp. link-manager folder „Corel Draw“ „Grafik Design\Corel Draw“
  • link-manager del-folder <folder>
    entfernt einen Ordner aus dem Startmenü
  • link-manager create-folder <folder>
    legt einen Ordner im Startmenü an
  • link-manager sleep <sekunden>
    wartet eine angegebene Zeit. ist eigentlich nicht Aufgabe des link-managers, habe ich aber für eine Installation gebraucht…

Damit bekommt man jedes Programm in eine saubere Startmenü-Struktur!

Hier ist der Code meines Link-Managers. (ich bin nicht sehr stolz auf das Programm, es ist eher ein Quick&Dirty Code, aber er funktioniert)

set args = WScript.Arguments
if args.Count=0 then wscript.quit
rootFolder="C:\Dokumente und Einstellungen\All Users\Startmenü\Programme\"
 
 
'  USAGE   link-manager folder <path-to-folder> <new-location>
' new-location is relativ zum Startmenü Pfad
if args(0)="folder" then
  Set objFSO = CreateObject("Scripting.FileSystemObject")
  if objFSO.FolderExists(rootFolder & args(2)) then
    objFSO.DeleteFolder rootFolder & args(2), True
  end If
  objFSO.MoveFolder rootFolder & args(1) , rootFolder & args(2)
end if
 
 
'  USAGE   link-manager link <link-target> <file> [working-directory]
if args(0)="link" then
  Set WshShell = Wscript.CreateObject("Wscript.Shell")
  Set oShellLink = WshShell.CreateShortcut(rootFolder & args(1))
  if args.count>3 then oShellLink.WorkingDirectory = args(3)
  oShellLink.TargetPath = args(2)
  oShellLink.Save
  Set oShellLink = Nothing
end if
 
 
' USAGE   link-manager del-link <link-target>
if args(0)="del-link" then
  Set objFSO = CreateObject("Scripting.FileSystemObject")
  Set f1 = objFSO.GetFile(rootFolder & args(1))
  f1.Delete
end if
 
 
' USAGE   link-manager del-folder <folder>
if args(0)="del-folder" then
  Set objFSO = CreateObject("Scripting.FileSystemObject")
  Set f1 = objFSO.GetFolder(rootFolder & args(1))
  f1.Delete
end if
 
 
'USAGE link-manager create-folder <folder>
if args(0)="create-folder" then
  Set objFSO = CreateObject("Scripting.FileSystemObject")
  objFSO.CreateFolder(rootFolder & args(1))
end if
 
 
' USAGE link-manager sleep <sekunden>
if args(0)="sleep" then
 wscript.sleep(1000*args(1))
end if

Was noch verbessert/getan werden muss

Soweit läuft alles. Dennoch kann man hier und das das Projekt bzw. die Nutzung verbessern. Ich werde mir ab Oktober (da habe ich den Kopf wieder etwas freier) das Webinterface ansehen. Mit Hilfe des Webinterfaces kann man kann bequem die XML-Konfigurationsdateien editieren und das ganze Software-Deployment steuern. Das Web-Interface scheint aber derzeit nicht gewartet zu werden. Im Wiki des Projekts ist davon zu lesen, dass Maintainer gesucht werden. Ich könnte mir gut vorstellen das Interface aufzupolieren.

Der nächste Punkt ist, dass man kein zentrales Reporting hat. Ich weiß nicht ob die Software XY auf allen gewünschten Clients auch tatsächlich installiert wurde oder ob es einen Fehler gab. (normalerweise sollte es zwar keinen Fehler geben, aber trotzdem wäre es gut zu wissen). Toll wäre es natürlich wenn die Reporting-Daten direkt in das Web-Interface kommen, so dass ich bequem sehen kann, ob alle Maschinen planmäßig installiert sind. Zudem könnte man das Ganze mit einer CMDB koppeln….

Was ich noch sagen wollte

Wer Hilfe zu WPKPG braucht, Fragen hat oder auch sonst ne coole Idee oder ein nettes Addon hat darf mich gern kontaktieren (am besten als Kommentar unter diesen oder einen anderen WPKG-Beitrag in dem Blog).

KategorienArbeit, Computer & Technik, WPKG Tags:
  1. Andreas
    24. August 2008, 13:12 | #1

    Hi,

    danke für dein ausführlicher Erfahrungsbericht. Die Idee mit dem Linkmanager ist sicherlich toll. Wäre nett, wenn du das Skript hier oder im Wiki anhängen würdest. 🙂

    btw: Mir ist aufgefallen, dass das Thema webinterfache bereits in der ML besprochen wird:

    http://lists.wpkg.org/pipermail/wpkg-users/2008-August/

  2. Andreas
    24. August 2008, 13:35 | #2

    Habe noch eine Anmerkung zu den einzelnen Dateien: wpkg.js, wrapper.js, config.xml

    Die aktuelle wpkg Version WPKG-1.1.0-M6 wurde zum Teil zwischenzeitlich gefixt.

    Die gefixte Dateien können entsprechend heruntergeladen werden unter:
    http://wpkg.svn.sourceforge.net/viewvc/wpkg/wpkg/current-development/

  3. admin
    25. August 2008, 11:25 | #3

    Hi,

    ich habe das Skript jetzt in diesen Artikel nachträglich eingefügt. Für das WPKG-Wiki muss ich ihn noch etwas modifizieren, da er momentan nur mit einer deutschen Windows-Version funktioniert (wegen dem festverdrahteten Pfad zum Startmenü)

    Ich habe die Mailinglist abonniert, aber komm derzeit gar nicht zum Lesen. Stimmt, da wird derzeit überlegt ein neues Web-Interfaces zu bauen. Mal schaun wie weit die Pläne bis Oktober gekommen sind. Falls es bis dahin schon eine Entwicklung gibt, beteilige ich mich daran, falls nicht werde ich wohl früher oder später ein eigenes bauen…

    Was hast Du mit Deinem zweiten Post hier gemeint? Gab es ein Security-Fix? Was hat sich an der SVN-Version 1.1.0-M6 getan?

  4. Andreas
    25. August 2008, 12:11 | #4

    Hi,

    ich denke ich hatte mit dem 7-Zip Paket genau das Problem gehabt (Revision 27):

    http://wpkg.svn.sourceforge.net/viewvc/wpkg/wpkg/current-development/CHANGES?view=log

    Nach dem Austausch der Dateien wpkg.js und config.xml war das Problem behoben. Genauer kann ich es leider nicht beschrieben.

  5. Andreas
    15. Oktober 2008, 07:53 | #5

    Hi,

    ich war neugierig ob du dich wie von dir angekündigt mit dem Thema Webinterface beschäftigt hast. Auf der ML ist seit dem Thread im August in dieser Hinsicht nichts mehr gemeldet worden. Danke für deine Antwort.

  6. admin
    15. Oktober 2008, 17:15 | #6

    Hi,

    ich bin gerade dabei meine To-Do-Liste abzuarbeiten, deswegen habe ich mir noch keine Gedanken gemacht. Da aber in Mailingliste nichts mehr neues kommt, werde ich ein eigenes Webinterface schreiben bzw. das bestehende „aufpolieren“.
    Zu dem Thema habe ich gerade einen neuen Blog-Eintrag geschrieben…

    Viele Grüße
    Markus

  7. Hans
    19. März 2015, 16:04 | #7

    Hallo ich teste zur Zeit WPKG und schaffe die Verbindung zwischen Client und Server leider nicht.

    Wenn ich cscript \\SERVER\WPKG\wpkg.js starte am Client kommt eine Fehlermeldung Die Software Instalation ist Fehlgeschlagen.

    Quelle: http://michaelellerbeck.com/2008/12/19/chapter-1-wpkg-install/

    Muss man an der Datei wpkg.js etwas ändern? Ich möchte nur das ich eine Software überhaupt auf einen Client installieren kann.

    Meine Vorgehensweise: Ordner anlegen (WPKG kopieren) Freigabe erstellen.
    Änderung in den .XML Dateien (Hosts, profiles und packages) + Clientinstallation

    Wäre für Ratschläge oder Info´s sehr Dankbar.

  8. Hans
    19. März 2015, 17:14 | #8

    Fehlermeldung: Die Software-Installation ist fehlgeschlagen (Clientseitig)

    Das Stylesheet ist möglicherweise leer, oder es ist kein wohlgeformtes XML-Dokument.

  1. Bisher keine Trackbacks