Gesperrter Login bei fehlerhaftem opsi-Paket/Setuproutine

[wla]

opsiclientd 4.0.76
opsi-winst 4.11.3.6

Wie geht man hier am besten vor um dem vorzubeugen?
Die Installationen sollen jedoch wie vorgesehen beim Hochfahren stattfinden! Man braucht aber eine Hintertür um aus einer festgefahrenen Installation aussteigen und arbeiten zu können. Am besten nicht einfach einloggen, sondern erst Abbrechen der Installation und dann einloggen.

Im Moment ist bei unserer Testinstallation (alles Win7, 64 Bit Clients) keine Möglichkeit da, abzubrechen.
Wir haben mit folg. Parametern (aus Doku) via Webinterface/Hostparameter/opsiclientd erfolglos versucht ein Abbrechen zu ermöglichen:
opsiclientd.action_user_cancelable = 20
opsiclientd.action_warning_time = 5
Wobei dies laut meinem Verständnis kein Abbrechen, sondern ein "Verschieben" der Installation wäre - funktioniert aber leider auch nicht, es gibt keinen Schalter irgendwo etwas abzubrechen.

[tobias]

Es gibt für den Benutzer keine Möglichkeit eine bereits gestartete Installation abzubrechen.
Du musst deine Scripte so bauen, dass ein Fehler möglichst nicht auftritt.

Bin aber auch schon länger dafür eine Methode zu implementieren die den WINST + die von diesem gestarteten dienste (sofern erkennbar) killen kann.

Die beiden von dir genannten Parameter sind dafür gedacht wenn Produktaktionen per WAN/WPN event, oder timer event .... zu starten ..... während ein Benutzer angemeldet ist.
Damit dieser die Installation bei Bedarf verschieben kann.
Wenn eine Aktion bereits gestartet ist gibt es keine Möglichkeit diese abzubrechen.

Wenn du diese Abfrage auch beim Systemstart haben willst, musst du Hostparameter mit diesen Namen anlegen:

Code: Alles auswählen

opsiclientd.event_gui_startup.action_user_cancelable = 20
opsiclientd.event_gui_startup.action_warning_time = 5

[wla]

Hallo Tobias,

danke vielmals, funktioniert nun.
Damit kann der Benutzer wenigstens durch einen Reset eine fehlerhafte Installationsroutine unterbrechen und beim Hochfahren Abbrechen drücken und dann Arbeiten.

Bist Du beim Hersteller angestellt? Zwei Sachen sind mir aufgefallen:
- die geänderten opsiclientd-Parameter werden erst beim übernächstenmal aktiv - es werden also erst die Installationen gemacht und anscheinend erst danach neue Parameter übernommen. Wäre nicht der umgekehrte Fall "erst neue Parameter übernehmen, neu einlesen (berücksichtigen) und dann Installationen ausführen" besser?
- die beiden Parameter stehen nicht in der Doku

Grüße
Walter

[tobias]

Hallo Tobias,

danke vielmals, funktioniert nun.
Damit kann der Benutzer wenigstens durch einen Reset eine fehlerhafte Installationsroutine unterbrechen und beim Hochfahren Abbrechen drücken und dann Arbeiten.

Bist Du beim Hersteller angestellt? Zwei Sachen sind mir aufgefallen:

Nö, bin auch nur OPSI-Anwender

- die geänderten opsiclientd-Parameter werden erst beim übernächstenmal aktiv - es werden also erst die Installationen gemacht und anscheinend erst danach neue Parameter übernommen. Wäre nicht der umgekehrte Fall "erst neue Parameter übernehmen, neu einlesen (berücksichtigen) und dann Installationen ausführen" besser?

Ja das geht auch nicht anders, da der Client die Daten vom Server zieht und diese erst nach einem Neustart des Opsi-Clientd's greifen.

- die beiden Parameter stehen nicht in der Doku

Doch stehen sie nur allgemeiner geschrieben da die event Konfiguration des opsi-clients sehr komplex ist können natürlich nicht alle möglichen varianten aufgelistet werden.
Du könntest genauso gut diese Abfrage auch für das on_demand event einschalten. Schaut dann so aus:
opsiclientd.event_on_demand.action_user_cancelable = 20

[wla]

Danke für die Erläuterungen.

- die geänderten opsiclientd-Parameter werden erst beim übernächstenmal aktiv - es werden also erst die Installationen gemacht und anscheinend erst danach neue Parameter übernommen. Wäre nicht der umgekehrte Fall "erst neue Parameter übernehmen, neu einlesen (berücksichtigen) und dann Installationen ausführen" besser?

Ja das geht auch nicht anders, da der Client die Daten vom Server zieht und diese erst nach einem Neustart des Opsi-Clientd's greifen.

Hm, dies ist mir schon klar. Aber: erst Daten vom Server ziehen, Neu einlesen und dann erst Installationen ausführen - es wird anscheinend erst installiert.
Ansonsten könnte man sofort, z.B. nach den geänderten Parameters bzgl. Verschieben der Installation, die Installationen verschieben. Es funktioniert erst beim zweiten Mal.

[tobias]

Danke für die Erläuterungen.

- die geänderten opsiclientd-Parameter werden erst beim übernächstenmal aktiv - es werden also erst die Installationen gemacht und anscheinend erst danach neue Parameter übernommen. Wäre nicht der umgekehrte Fall "erst neue Parameter übernehmen, neu einlesen (berücksichtigen) und dann Installationen ausführen" besser?

Ja das geht auch nicht anders, da der Client die Daten vom Server zieht und diese erst nach einem Neustart des Opsi-Clientd's greifen.

Hm, dies ist mir schon klar. Aber: erst Daten vom Server ziehen, Neu einlesen und dann erst Installationen ausführen - es wird anscheinend erst installiert.
Ansonsten könnte man sofort, z.B. nach den geänderten Parameters bzgl. Verschieben der Installation, die Installationen verschieben. Es funktioniert erst beim zweiten Mal.

Das Stimmt schon hast du recht kann aber nur UIB was dran ändern
Was glaube ich fehlt ist eine OPSI Methode im Opsiclientd dies machen könnte.
Irgendwann hatte ich sowas glaube ich schonmal vorgeschlagen.

[d.oertel]

Hi,

das sofortige übernehmen der Parameter ist nicht so einfach, da der opsiclientd mit den lokalen Parametern startet
und dann (schon so initialisert) zum Server Kontakt aufnimmt und dann erst erfährt das nun andere Parameter gelten sollen. Im Moment werden die geänderten Parameter dann für den nächsten Start abgelegt.

gruß
d.oertel