forum.opsi.org

Hallo,

wir sind am überlegen, o.g. Extension zu ordern, zur Zeit testen wir, bisher durchaus positiv.

Dabei ist von unser Geschäftsführung folg. "Feature" angefragt worden:
Die WAN/VPN Extension wird im Hintergrund selbst tätig. Nun stellt sich die Frage, ob der Administrator dies mit einem Verfallsdatum deaktivieren kann?
Warum? Manche Laptops gehen mal ins Ausland und sollen das limitierte Datenpaket nicht strapazieren ...
Idealerweise den Client vom Administrator von "Updates bis zum Datum XXX ausnehmen" und danach ohne Zutun wieder Updates ausführen.
In der GUI kann ich dies nicht finden? liegt hoffentlich nicht an mir Wenn man die benötigten Parameter kennt, kann man vielleicht hintenrum ein schlaues Skript schreiben, welches auf dem Server den/die opsiclientd-Parameter ändert und am Datum X dies (per Scheduler atd) wieder rückgängig macht ...

Hat jemand vielleicht einen Hinweis für mich?

Mit besten Grüßen,
Walter Laub

wla hat geschrieben:Hallo,

wir sind am überlegen, o.g. Extension zu ordern, zur Zeit testen wir, bisher durchaus positiv.

Dabei ist von unser Geschäftsführung folg. "Feature" angefragt worden:
Die WAN/VPN Extension wird im Hintergrund selbst tätig. Nun stellt sich die Frage, ob der Administrator dies mit einem Verfallsdatum deaktivieren kann?

Nein.

Allerdings passiert ja nur etwas , falls der opsi-server erreichbar ist.

wla hat geschrieben: Warum? Manche Laptops gehen mal ins Ausland und sollen das limitierte Datenpaket nicht strapazieren ...
Idealerweise den Client vom Administrator von "Updates bis zum Datum XXX ausnehmen" und danach ohne Zutun wieder Updates ausführen.
In der GUI kann ich dies nicht finden? liegt hoffentlich nicht an mir Wenn man die benötigten Parameter kennt, kann man vielleicht hintenrum ein schlaues Skript schreiben, welches auf dem Server den/die opsiclientd-Parameter ändert und am Datum X dies (per Scheduler atd) wieder rückgängig macht ...

Hat jemand vielleicht einen Hinweis für mich?

Mit besten Grüßen,
Walter Laub

Eine elegante Lösung sehe ich adhoc nicht.

Mögliche Workarounds:
- "hintenrum" versuchen, dass die Clients aus dem Ausland "nie" den opsi-server erreichen.
- PCkey sichern und temporär ändern. Das liesse sich wohl relativ leicht von uns implementieren - falls es wirklich sinnvoll ...

Gruss
Bardo Wolf

ok, ich denke das Problemchen ist richtig angekommen.

Dass der Client den Server aus dem Ausland erreicht ist nicht wirklich schlimm, dies macht ja nicht viel Traffic, er sollte anhand der Parameter für opsiclientd aber merken, dass Updates für ihn temporär untersagt sind.

Das Szenario ist folgendes:
- Laptop im Ausland unterwegs
- Benutzer baut Verbindung via OpenVPN auf
- opsiclientd nimmt Kontakt zum Server auf und ladet vorgesehene Updates (dies mit Verfallsdatum unterbinden zu können wäre ideal!!!)
Dies kann nur der Hersteller vernünftig implementieren.
Ich könnte mir vorstellen, dass dies auch für andere Anwender eine sinnvolle Option wäre.

Ein Workaround für uns, könnte folg. aussehen:
Welche Parameter genau müsste ich setzen um Updates beim Start UND beim Tunnelaufbau zu unterbinden? PCKey wurde erwähnt, eizige Möglichkeit? Wenn ja, wie lese ich ihn via Skript aus bzw. kann ihn ändern (es langt ja, wenn ich immer z.B. ein Zeichen anhänge oder ähnlich)?
Dies könnte ich, wie erwähnt, in ein Skript packen, welches als Argument den Client und das Verfallsdatum erhält und den/die Parameter umsetzt und sogleich über den atd einen Job absetzt der das ganze nach dem Verfallsdatum rückgängig macht!

Du könntest auch bei dem betroffenen Client den Hostparameter abschalten so das er nix mehr cached.
Das kannst du auch über OPSI Pakete realisieren.

Paket 1 Schaltet die WAN/VPN Option für den Client aus
Paket 2 Schaltet es wieder an

Die kannst du beide gleichzeitig auf Setup setzen, da Paket 2 dann ja erst wieder ausgeführt wird wenn der PC wieder direkte Verbindung zum OPSI Server hat und ein event_gui_startup erfolgreich sein kann.
Denn beim Hochfahren ist normalerweise ja keine Verbindung zum OPSI Server verfügbar wenn man nicht im LAN ist.
Über den Software Kiosk kannst du den Leuten dann ermöglichen das sogar selber auszuführen.

Hi,

http://download.uib.de/opsi4.0/products ... 0.1-1.opsi

http://download.uib.de/opsi4.0/products ... 0.1-1.opsi

gruß
d.oertel

Danke für die Vorschläge! Mir gefällt jedoch die Option, ein Verfallsdatum mitzugeben, ohne auf das Mitwirken des Benutzers angewiesen zu sein, er muss es nur in Auftrag geben.

Vielleicht will sich jemand zu folg. Vorschlag äußern. Ich habe dies bereits simuliert, sollte funktionieren, ich will ein kleines Skript dafür schreiben.
bash-Skript opsi-client-inactivate [client-name] [bis wann]
Das Skript bearbeitet die Datei /etc/opsi/pckeys (sichert sie natürlich vor jeder Änderung).
Erst wird die Existenz des [client-name] geprüft und die Gültigkeit des Datums [bis wann]. Das Datum muss passen und darf nicht zuweit in der Zukunft liegen (Parameter im Skript, 30 Tage?).
Passt dies alles, dann wird in der Datei pckeys, einfach das Verfallsdatum an den Key hinten angehängt (und der Key passt erstmal nicht mehr).
Das gleiche bash-Skript opsi-client-inactivate --check|-c
Aufgerufen manuell oder normalerweise täglich über crontab durchforstet die Datei /etc/opsi/pckeys nach manipulierten Keys die über dem Verfallsdatum sind und macht das ganze rückgängig.

Über Kommentare oder Verbesserungsvorschläge freue ich mich!

dürfte genau solange funktionieren, wie du das Filebackend verwendest
Sobald du das MySQL kaufst (wenn du ein paar mehr Clients hast macht das Sinn - bessere Performance) oder das MySQL Modul freigegeben wird, wird es so nicht mehr funktionieren bzw. du musst es anpassen damit es in der DB eingetragen wird.

Läuft aber prinzipiell aufs selbe hinaus.
Deine Variante deaktiviert den Client komplett bis das Datum abgelaufen
Meine Variante deaktiviert den Client nur, wenn er Extern ist und beim Systemstart keine Verbindung zum OPSI Server hat - ist er zurück wird es automatisch wieder eingeschaltet.

Vorteil:
- Steuerbar über Configed als Paket
- Kein kompletter Kontrollverlust über den Client (OnDemand weiterhin möglich)
- Anwender KANN es auch selber einschalten über den SoftwareKiosk

Wie du es am Ende machst ist dir überlassen

Hallo Tobias,

Du hast Recht bzgl. des Filebackend und auch der Vorteile Deiner Lösung. Ich hatte dies erst anders verstanden, nun aber nochmal nachgedacht.

Zwei Fragen noch dazu:
1. Sind dies die Pakte die d.oertel verlinkt hat? Wenn nein, würdest Du mir Deine senden?
2. Die Funktion ist mir jedoch immer noch nicht ganz klar. Dies funktioniert doch nur, wenn die Benutzer nur sporadisch das Firmennetz verlassen.
Wir haben OpenVPN Benutzer, die nur ganz selten in der Firmenzentrale sind und normalerweise aus Ihrem Homeoffice arbeiten (und somit kein event_gui_startup erhalten). D.h. ein event_gui_startup kommt manchmal erst nach Monaten zustande, wenn der Benutzer den Laptop in der Zentrale hochfährt. Trotzdem soll er (nur) im Ausland deaktiviert sein.
Klappt so nicht, oder verstehe ich's nicht richtig? Noch eine Idee? Vielleicht ein Paket, welches mit dem Windows Taskscheduler was anstellt ...

Danke.

Grüße
Walter

wla hat geschrieben:Hallo Tobias,

Du hast Recht bzgl. des Filebackend und auch der Vorteile Deiner Lösung. Ich hatte dies erst anders verstanden, nun aber nochmal nachgedacht.

Zwei Fragen noch dazu:
1. Sind dies die Pakte die d.oertel verlinkt hat? Wenn nein, würdest Du mir Deine senden?

Ja sind genau die. Bzw. ich habe andere - meine Eventkonfiguration ist aber nicht vergleichbar mit der Originalen.

2. Die Funktion ist mir jedoch immer noch nicht ganz klar. Dies funktioniert doch nur, wenn die Benutzer nur sporadisch das Firmennetz verlassen.
Wir haben OpenVPN Benutzer, die nur ganz selten in der Firmenzentrale sind und normalerweise aus Ihrem Homeoffice arbeiten (und somit kein event_gui_startup erhalten). D.h. ein event_gui_startup kommt manchmal erst nach Monaten zustande, wenn der Benutzer den Laptop in der Zentrale hochfährt. Trotzdem soll er (nur) im Ausland deaktiviert sein.
Klappt so nicht, oder verstehe ich's nicht richtig? Noch eine Idee? Vielleicht ein Paket, welches mit dem Windows Taskscheduler was anstellt ...

Da hast du recht. Ich ging es davon aus das es sich um Dienstreisende handelt die nach der Reise wieder im Betrieb sind....
Tasksheduler wäre natürlich ne Möglichkeit. Ne andere Möglichkeit (so will ich das demnächst auch für bei Windows Updates realisieren) ist für Auslandsreisen ein zusätzliches VPN Profil von welchem man den OPSI Server und unseren WSUS nicht erreichen kann damit ist das Problem "extern" behoben.
Das Traffic Problem haben wir nämlich auch ...

Hi,

zum deaktivieren des opsiclientd würde ich folgendes machen:
C:\Program Files (x86)\opsi.org\opsi-client-agent\uninst\deactivate.cmd
bzw.
C:\Program Files (x86)\opsi.org\opsi-client-agent\uninst\activate.cmd


gruß
d.oertel