pcproto.ini und REINS Mode

[j.schneider]

Am besten das Paket image-einrichtung mit dem opsi-package-manager nochmal installieren...

[Der-Matze]

Hab ich eben getestet.

Laut /var/log/opsi/package.log ist die Installation des Pakets fehlerfrei durchgelaufen.

Leider besteht das Problem weiterhin.

Daraufhin habe ich eine Kopie des entpackten Pakets image-einrichtung erstellt und es in der control Datei in xp-einrichtung umbenannt.

Danach habe ich die Abhängigkeit des Pakets 7-zip von image-einrichtung auf xp-einrichtung umbenannt.

Bootmode auf REINS gestellt und nur das Paket 7-zip im Webinterface auf "installed" gestellt.

product '7-zip' defines dependency to product 'xp-einrichtung', which is not avaliable (<string>|41)

Gut, die Länge des Namens ist es schon mal nicht...

Als nächstes habe ich den Paketnamen in einrichtung geändert, um den Bindestrich ausschließen zu können.

Gleiche Prozedur wie vorher, die Abhängigkeit von 7-Zip auf einrichtung geändert:

product '7-zip' defines dependency to product 'einrichtung', which is not avaliable (<string>|41)

Wie gesagt, das Paket image-einrichtung lässt sich über das Webinterface fehlerfrei installieren.

Setze ich dessen status im Webinterface auf not_installed und den eines beliebigen anderen Produkts das davon abhängt auf installed wird die Abhängigkeit auch korrekt aufgelöst und die image-einrichtung auf setup gesetzt.

[Der-Matze]

Um auszuschließen dass das Paket image-einrichtung spontan kaputt gegangen sein sollte habe ich die Abhängigkeit des Pakets 7-zip testweise auf das Paket ocx geändert.

product '7-zip' defines dependency to product 'ocx', which is not avaliable (<string>|41)

Anscheinend scheint es generell an den Abhängigkeiten zu scheitern, egal auf welches Paket sie auch verweisen.

Um das zu verifizieren habe ich sämtliche Abhängigkeiten des Pakets 7-zip gelöscht und siehe da:

Executing: backend_setOptions({u'addDependentProductOnClients': True}) (opsiconfd.py|758)
Executing: setProductActionRequest(u'7-zip', u'vmopsitest.tle.intern', u'setup') (opsiconfd.py|758)

So funktioniert es!

[j.schneider]

Es könnte sein, dass es ein Bug ist.
Bitte einmal die angehängte Datei herunterladen, die Endung .txt entfernen und ablegen unter:
/usr/share/pyshared/OPSI/Backend/
wenn dieses Verzeichnis nicht existiert unter:
/usr/share/python-support/python-opsi/OPSI/Backend/

Dann den opsiconfd neu starten und noch einmal probieren.
Danke!

[Der-Matze]

Sorry, konnte es gestern nicht testen.

Der Hotfix scheint zu funktionieren. Nach dem Einspielen verhält sich der REINS Mode wieder genau wie von OPSI 3.4 gewohnt.

Ich habe das Logfile vom erfolgreichen Testlauf angegehängt. Dort findet sich noch mehrmals folgende Fehlermeldung:

Opsi bad rpc error: Failed to decode rpc: Invalid control character at: line 1 column 1297701 (char 1297701) (opsiconfd.py|341)

vmopsitest.tle.intern.log

(13.28 KiB) 36-mal heruntergeladen

Danke für den Hotfix und die schnelle Bearbeitung des Problems.

MfG

[Der-Matze]

Nachtrag:

Nach etwas ausgiebigerem Testen ist mir aufgefallen dass die Abhängigkeiten leider doch nicht korrekt beachtet werden.

Bei meinem Testlauf habe ich nur das Produkt 7-zip im Webinterface auf "installed" gestellt. Dieses Produkt hängt von dem Paket image-einrichtung ab (pre-required).
Das Paket image-einrichtung hat wie bereits erwähnt selber zwei Abhängigkeiten, pcwrunas und setacl (ebenfalls pre-required).
Stelle ich den Bootmode auf REINS wird die Abhängigkeit des ersten Produktes aufgelöst, also das Paket image-einrichtung auf "setup" gestellt.
Dessen Abhängigkeiten werden allerdings nicht beachtet, d.h. pcwrunas und setacl werden nicht auf "setup" gestellt.

In einem anderen Testlauf habe ich anders als im ersten Test alle vier Produkte im Webinterface auf "installed" gesetzt.
In dem Fall werden natürlich alle Produkte im REINS Mode auf "setup" gestellt, allerdings werden dann auch hier die Abhängigkeiten nicht korrekt aufgelöst, d.h. die Installationsreihenfolge stimmt nicht. setacl und pcwruns werden nach der image-einrichtung installiert.
Das habe ich durch Anpassung der Priorität soweit in den Griff bekommen, aber das ändert ja nichts am eigentlichen Problem.
Wäre toll wenn sich das bei Gelegenheit noch mal jemand anschauen könnte.

MfG

[j.schneider]

Hallo,

wir haben gestern neue Pakete bereitgestellt.
Bitte mittels

Code: Alles auswählen

apt-get update
apt-get dist-upgrade

auf die neuen Versionen upgraden und noch einmal testen.
Über Rückmeldung würde ich mich freuen.

Gruß,
Jan Schneider

[Der-Matze]

Hallo Herr Schneider,

die neuen Pakete hatte ich bereits gestern vor dem Test eingespielt.
Nach dem Einspielen der neuen Pakete wurde der Server auch komplett neu gestartet.
Um wirklich sicher zu gehen habe ich eben noch einmal geprüft dass alle OPSI Pakete auf dem neuesten Stand sind und sämtliche Dienste neu gestartet.
Danach habe ich den Test noch einmal wiederholt, leider mit dem selben Ergebnis.
Die Installation verläuft genau so wie im oberen Posting geschildert.
Anbei auch noch mal die entsprechenden Logfiles und die .ini Datei des Rechners:

10.9.90.11.log

(11.03 KiB) 35-mal heruntergeladen

instlog.txt

(3.9 KiB) 33-mal heruntergeladen

vmopsitest.xxx.xxxxx.ini

(331 Bytes) 37-mal heruntergeladen

[j.schneider]

Hallo,

vielen Dank für das Testen!
Ich habe erneut einen Fix bereit gestellt.
Neues python-opsi Paket ist über das Repository verfügbar.

Gruß,
Jan Schneider

[Der-Matze]

Hallo Herr Schneider.

ich habe die Updates eingespielt und den obigen Test wiederholt.
Es scheinen jetzt alle Abhängigkeiten korrekt aufgelöst zu werden.
Ich werde heute mal versuchen das Ganze noch etwas genauer zu testen.
Vielen Dank für die schnelle Hilfe und die Bugfixes.

MfG