Update auf 4.0.5 / Win-Netboot - Installationsproblem

[Synco]

Nach dem Update von Opsi 4.0.4 auf 4.0.5 inkl. Erneuerung der Windows Netbootpakete, endet die Windows 7 Installation immer mit :

Status: unknown
Report: running

Im Ergebnis wird die Windows Installation aber durchgeführt.

Unter Opsi 4.0.4, sowie den "alten" Windows-Netbootpaketen (vermutlich aus 4.0.2) haben wir für Win7 immer den Status "success" und "installed" erhalten. Ebenso für den Status opsi-client-agent.
Dieser wird nun garnicht mehr angezeigt, obwohl er installiert wurde. Lediglich opsi-winst zeigt den Status "success" und "installed".
Die Custom-Bereiche von Win7 sind unverändert gegenüber der Version 4.0.4

Ausserdem beendet sich nun die Win7 Installation, ohne dass die vorab auf setup gestellten Pakete installiert werden. Dies geschah unter 4.0.4 und den alten Win-Paketen automatisch nach der Win7-Installation.
Jetzt wird erst nach einem weiteren manuellen Reboot installiert.

Fragen:
Was/wie muss jetzt anders konfiguriert werden, damit Win7 wieder mit dem Status "success" endet?
Wie kann man das "alte" Installationsverhalten, also automatisch alle auf setup gestellten Pakete installieren, auch unter 4.0.5 erhalten?

System: Debian Wheezy 7.7

Versionen:
opsi-utils 4.0.5.6-2
opsi-configed 4.0.5.1.6-1
opsiconfd 4.0.5.2-1
python-opsi 4.0.5.15-1
opsi-depotserver 4.0.5.11-1
win7_4.0.5-4.opsi

Netboot:
Die Windows7 Installation wird mittels Opsi-Client Boot-CD vom 19.09.14 durchgeführt.

[Beebob007]

Moin,
Deinen Fehler kann ich nicht bestätigen. Bei uns geht alles....
Allerdings installieren wir per PXE und nicht per BOOT-CD.

Hast Du mal Deine unattended.xml geprüft? Vielleicht ist da ein Fehler drin?
Bist Du Dir sicher, dass er wirklich komplett mit der Installation von Win7 durch ist?
Denn ansonsten ist es ja logisch dass da kein success kommt und es nicht weiter mit den anderen Paketen geht.

[Synco]

Moin,
Die unattended.xml ist unverändert gegenüber der Opsi-Version 4.0.4 und basiert auf dem Template welches mitgeliefert wird. Mit dieser unattended.xml sind alle Clients unter 4.0.4 sauber installiert worden. Die dort eingetragenen Änderungen werden ja offensichtlich auch herangezogen.

Es sieht zumindest so aus, als ob die Windowsinstallation abgeschlossen wird. Konkrete Fehler kann ich nicht entdecken. Allerdings werden keine Pakete installiert, auch nicht ein testweise mittels der neuen Property "setup_after_install" gesetztes Paket.
Erst nach einem folgenden manuellen Reboot werden alle gesetzten Pakete installiert. Danach sieht eigentlich alles ok aus, bis auf den angezeigten Win7 Status.
Der Installationsstaus von Win7 bleibt "unknown" und "running".

Sieht eigentlich so aus, als ob irgendwo noch ein Parameter ala "reboot after install" zum triggern der Installation aller weiteren Pakete gesetzt werden müsste, der unter 4.0.4 automatisch implementiert war ?

[Synco]

Ich habe den Test-PC nochmal in Opsi gelöscht und neu angelegt sowie eine Win7 Installation angestossen.
Die Installation läuft ohne erkennbare Probleme bis
- Desktop wird vorbereitet
- automatischer Reboot
- Opsi-Fenster - verbinde mit Depotserver
- Winst Fenster startet und schliesst sofort wieder - keine Aktionen *
- Windows-Login Prompt

* hier müsste doch eigentlich die Installation der Pakete starten?

Eine Fehlermeldung findet sich im opsiconfd-log:

Code: Alles auswählen

[5] [Dec 12 11:46:57] -----> Executing: productOnDepot_getIdents(u'dict', {'depotId': u'opsi.fqdn.de', 'productType': u'LocalbootProduct', 'productId': u'opsi-winst'}) (JsonRpc.py|125)
[5] [Dec 12 11:46:57] -----> Executing: productOnClient_updateObjects([<ProductOnClient clientId 'pc0000.fqdn.de', productId 'opsi-winst', installationStatus 'installed', actionRequest 'None'>]) (JsonRpc.py|125)
[4] [Dec 12 11:46:57] Failed to set rights for path '/var/lib/opsi/config/clients/pc0000.fqdn.de.ini': [Errno 1] Operation not permitted: '/var/lib/opsi/config/clients/pc0000.fqdn.de.ini' (File.py|284)

Code: Alles auswählen

/var/lib/opsi/config/clients# ls -l |grep pc0000
-rw-rw---- 1 adminuser pcpatch 2425 Dez 12 11:46 pc0000.fqdn.de

Auszug aus dem Inhalt von pc0000.fqdn.de

Code: Alles auswählen

[netboot_product_states]
win7 = unknown:none

[win7-state]
actionprogress = running
actionresult = none
modificationtime = 2014-12-12 11:27:01
producttype = NetbootProduct

Im clientconnect log finde ich:

Code: Alles auswählen

[6] [Dec 12 11:48:18] [ event processing gui_startup  ] Setting config value depot_server.url   (Config.pyo|200)
[4] [Dec 12 11:48:18] [ event processing gui_startup  ] Refusing to set empty value for config value 'url' of section 'depot_server'   (Config.pyo|204)

[ueluekmen]

Hi,

die Rechte des File-Backends scheinen nicht richtig zu sein. Kann es sein, dass du die Dateien manuell editierst? Wenn ja, solltest du das nicht tun. Dann kommen solche komischen Konstellationen zusammen.

Führe mal bitte:

Code: Alles auswählen

opsi-set-rights

aus. Und versuche noch mal zu starten.

[Synco]

Danke für die Rückmeldung!

Kann es sein, dass du die Dateien manuell editierst?

Bewusst bestimmt nicht! Welche würden das denn sein?

Ich werde nach "opsi-set-rights" nochmal testen und Rückmeldung geben.

[Synco]

Nach dem Ausführen von "opsi-set-rights" habe ich den Test-PC erneut neu angelegt und eine Win7-Installation gestartet. Die Fehlermeldung bez. der Dateirechte im opsiconfd-log ist verschwunden. Am Ergebnis hat sich leider nichts geändert.

Auszug aus der pc0000.fqdn.de.ini

Code: Alles auswählen

[netboot_product_states]
win7 = unknown:none

[win7-state]
actionprogress = running
actionresult = none
modificationtime = 2014-12-15 07:41:14
producttype = NetbootProduct

Die Rechte unter /var/lib/opsi/config/clients sind durch "opsi-set-rights" verändert worden:

Code: Alles auswählen

root@opsi:/var/lib/opsi/config/clients# ls -l pc0000.fqdn.de.ini
-rw-rw---- 1 opsiconfd pcpatch 2424 Dez 15 08:01 pc0000.fqdn.de.ini

Die Dateirechte vorher :

Code: Alles auswählen

-rw-rw---- 1 adminuser pcpatch

ergeben sich aus dem Anlegen der Clients mittels

Code: Alles auswählen

opsi-admin -d method host_createOpsiClient

als "adminuser" auf der Konsole.

/etc/group

Code: Alles auswählen

pcpatch:x:992:adminuser
opsiadmin:x:1001:opsiconfd,adminuser

Noch irgend eine Idee?

[Synco]

Ich bin nun zur Version 4.0.4 zurückgekehrt (virtuellen Maschinen sei dank) und alles funktioniert wieder einwandfrei.
Winst sagt nun nicht mehr "keine Aktionen notwendig", sondern startet wie gewohnt die Installation des opsi-client-agent. Danach kommt ein Reboot und die gesetzten Pakete werden sauber installiert.

[FloSchu]

Hallo zusammen,

alles schön und gut, dass ihr so einfach auf Version 4.0.4 zurückkehren konntet. Wir können das leider nicht so einfach, und haben exakt das gleiche Problem. Allerdings ist es bei mir nicht eine Windows 7 Installation, sondern eine Windows 2008 R2 Server - Installation. Da dies die erste Betriebssysteminstallation nach dem Update auf 4.0.5 ist, dachte ich dass es lediglich an der Installation des Servers liegt, weil Windows sich da vielleicht anders verhält.

Es wäre toll, wenn das Problem weiter verfolgt werden würde...
- Versucht habe ich bis jetzt, das win2008-r2-Opsipaket auf dem Server zu deinstallieren und neu zu installieren. Die PE-Umgebung habe ich dafür nochmal neu angelegt. Bei der unattend.xml wurde bei uns lediglich das Admin-Passwort und der Admin Logon Count verändert. Dies ist aber nicht das Problem.

- Löschen und Neu-Anlegen des Opsi-Clients bringt nichts. Das Ergebnis bleibt, dass er mir "running" und "unknown" bei der OS-Installation anzeigt, und lediglich Winst als installierte Applikation anzeigt, obwohl der opsi-client ebenfalls installiert ist.

- Obwohl sich Client und Server anpingen können, kann der Opsi-Server kein on-demand-event auslösen, da er angeblich die IP-Adresse nicht auflösen kann, was nicht stimmt, da die entsprechende IP in der Clientliste steht.

- Um ein bessere Fehlereinschränkung zu gewährleisten wollte ich dass Logging des Clients vom Defaultwert 5(?) auf 8 setzen. Dies habe ich, wie es ebenfalls in der Dokumentation steht, in der opsiconfd.conf auf dem Client selbst geändert. Interessanterweise wird dies vom opsi-client selbst überhaupt nicht beachtet. Sowohl die an den Server gesendeten Logs, als auch die Logdatei auf dem Client bleiben auf dem Default-Logging-Wert.

- Allgemeine Fehler wie Firewall oder fehlende Rechte können auch ausgeschlossen werden. Das opsiconfd-Protokoll ist in den Firewall-Regeln eingetragen, und die nötigen Rechte auf die vorhandenen Ordner sind auch gesetzt. Ich versuche jetzt irgendwie das Logging doch noch anzupassen um eventuell mehr herausfinden zu können... Sollte das funktionieren, werde ich mich nochmal melden...

So, zum Schluss noch ein paar Versionsangaben

Depot-Server: Ubuntu 12.04.5 LTS Precise Pangolin
opsi-winst 4.11.4.12-1
opsi-configed 4.0.5.1.8-1
opsi-client-agent 4.0.5.2-2
win2008-r2 4.0.5-5
Das Bootimage ist vom 19.09.2014 (Version 2)

opsiconfd 4.0.5.2-1
python-opsi 4.0.5.15-1
opsi-depotserver 4.0.5.11-1
opsi-utils 4.0.5.6-2

Viele Grüße

[ueluekmen]

Hi,

das Windows Netboot-Produkt wird erst nach der Clientagent Installation auf success gesetzt. Weil erst dann sichergestellt ist, dass die Installation auch wirklich funktioniert hat.

Im Regefall kommt es zu dieser Situation meistens dadurch, dass Treiberprobleme mit der Netzwerkkarte bestehen. Was auch manchmal passiert, ist dass das postinst-Verfahren nicht sauber anläuft.

Schau mal bitte auf dem Rechner im Verzeichnis: C:\tmp ob du die Logs: opsi-client-agent.log und die postinst.log siehst. Wenn ja, sieht man was in diesen Logs?