Seite 1 von 1

Clients vor unerwünschten Veränderungen schützen

Verfasst: 01 Feb 2019, 09:48
von PS-Profi
Hallo Community,

besteht eigentlich die Möglichkeit, Clients davor zu schützen, dass unerwünscht Pakete installiert/aktualisiert/gelöscht werden? Wir hatten nun erneut den Fall, dass ein Client versehentlich Pakete erhalten hat. Ideal wäre eine Art "Schreibschutz" der Client vor Änderungen bewahrt, es sei denn der Admin hebt diese Limitation auf.

Besten Dank
PS
Profi ;-)

Re: Clients vor unerwünschten Veränderungen schützen

Verfasst: 10 Feb 2019, 12:23
von tobias
Moin,

aktuell soweit ich weis nicht, wäre aber ein interessantes Feature was ich bei uns auch gut gebrauchen könnte.


Gruß
Tobias

Re: Clients vor unerwünschten Veränderungen schützen

Verfasst: 10 Feb 2019, 21:35
von r.roeder
ich habe den Punkt noch nicht. Es geht um die Verhinderung der "unbefugten" Installation von opsi-Paketen? Aber eine Installation kann doch ohnehin nur ein Admin starten - solange der Admin sie nicht explizit zur user-veranlassten Installation freigegeben hat

VG
Rupert

Re: Clients vor unerwünschten Veränderungen schützen

Verfasst: 10 Feb 2019, 21:52
von tobias
r.roeder hat geschrieben:ich haben den Punkt noch nicht. Es geht um die Verhinderung der "unbefugten" Installation von opsi-Paketen? Aber kann doch ohnehin nur ein Admin starten - solange der Admin sie nicht explizit zur user-veranlassten Installation freigegeben hat

VG
Rupert
Das schon, aber auch Admins sind nicht Fehlerfrei und es gibt ja auch die Möglichkeit über den opsi-package-updater produkte, die auf einem client installiert sind, wieder auf setup zu setzen wenn eine neue version im repository vorhanden war.
Es gibt aber durchaus Clients, auf denen ich aus verschiedenen Gründen darauf angewiesen bin, dass es beim aktuellen Stand bleibt.

Ich denke da z.B. in meinem Fall an Labor PCs die z.B. eine ganz spezielle Version von Software XYZ benötigen weil das der Anlagenbauer so vorschreibt.
Oder ich arbeite mit dem "Timer event" und der Rechner startet auf einmal während einer Messung neu, weil der reboot timer abgelaufen ist => Messung hinüber

Es gibt halt Clients mit hohem Automatisierungsgrad (Office PC) und Clients da terminiere ich das sehr genau mit dem Laborbeauftragten (LaborPC).
Wir deaktivieren aktuell auf solchen Clients den OPSI-Client-Agent komplett. Das hat natürlich den Nachteil, das ich den Client komplett abhänge und auch aus der Ferne nicht wieder aktivieren kann.


Gruß
Tobias

Re: Clients vor unerwünschten Veränderungen schützen

Verfasst: 11 Feb 2019, 11:21
von AlexB
tobias hat geschrieben:Das schon, aber auch Admins sind nicht Fehlerfrei und es gibt ja auch die Möglichkeit über den opsi-package-updater produkte, die auf einem client installiert sind, wieder auf setup zu setzen wenn eine neue version im repository vorhanden war.
Genau aus diesem Grund finde ich das Feature auch nicht gut.
tobias hat geschrieben: Oder ich arbeite mit dem "Timer event" und der Rechner startet auf einmal während einer Messung neu, weil der reboot timer abgelaufen ist => Messung hinüber
Wir handhaben das so: es werden nur zu festen Tagen Updates eingespielt und das muss vorher auch per Rundmail angekündigt werden.
Somit liegt die Verantwortung nicht bei uns in der IT wenn auf die Ankündigung keine Rückmeldung erfolgt.
tobias hat geschrieben: Es gibt halt Clients mit hohem Automatisierungsgrad (Office PC) und Clients da terminiere ich das sehr genau mit dem Laborbeauftragten (LaborPC).
Warum unterteilst du die Rechner im OPSI nicht auch in solche Gruppen? Damit wäre der Aufwand beim Deployment auch geringer.
tobias hat geschrieben: Wir deaktivieren aktuell auf solchen Clients den OPSI-Client-Agent komplett. Das hat natürlich den Nachteil, das ich den Client komplett abhänge und auch aus der Ferne nicht wieder aktivieren kann.
Du könntest das doch einfach über den Client-Agent Service regeln und den deaktivieren. Den kannst du ja auch remote bearbeiten. Oder ist das nicht möglich?

VG

Re: Clients vor unerwünschten Veränderungen schützen

Verfasst: 11 Feb 2019, 13:58
von tobias
tobias hat geschrieben: Oder ich arbeite mit dem "Timer event" und der Rechner startet auf einmal während einer Messung neu, weil der reboot timer abgelaufen ist => Messung hinüber
Wir handhaben das so: es werden nur zu festen Tagen Updates eingespielt und das muss vorher auch per Rundmail angekündigt werden.
Somit liegt die Verantwortung nicht bei uns in der IT wenn auf die Ankündigung keine Rückmeldung erfolgt.
Uii, ne das wäre mir ehrlich gesagt zu viel Aufwand, Office PCs bekommen ihre Updates wenn wir sie freigeben da hat sich einfach niemand zu beschweren und das Sicherheits Niveau in dem Bereich muss halt deutlich höher sein.
Im Laborbereich wird wirklich jeder einzelne PC manuell geupdated und vorher abgesprochen ;) Rundmails von der IT, seien wir mal ehrlich, liest eh niemand :mrgreen:

tobias hat geschrieben: Es gibt halt Clients mit hohem Automatisierungsgrad (Office PC) und Clients da terminiere ich das sehr genau mit dem Laborbeauftragten (LaborPC).
Warum unterteilst du die Rechner im OPSI nicht auch in solche Gruppen? Damit wäre der Aufwand beim Deployment auch geringer.
Wie gesagt, ich terminiere jeden einzelnen Sonderrechner mit dem Labor beauftragten und auch da jedes einzelen Software Paket. Da bringen mir Gruppen leider nicht so viel.
tobias hat geschrieben: Wir deaktivieren aktuell auf solchen Clients den OPSI-Client-Agent komplett. Das hat natürlich den Nachteil, das ich den Client komplett abhänge und auch aus der Ferne nicht wieder aktivieren kann.
Du könntest das doch einfach über den Client-Agent Service regeln und den deaktivieren. Den kannst du ja auch remote bearbeiten. Oder ist das nicht möglich?
Doch das geht schon - schön ist die Lösung trotz dem nicht.
Ich sehe z.B. nicht wann sich der OPSI-Client das letzte mal gemeldet hat, die Clients sehen also aus wie Karteileichen.
Manche Pakete wie z.B. SW-Audit dürfen von mir aus trotz dem laufen und es wäre viel einfacher und charmanter das ganze über OPSI zu steuern.

Ich könnte mir vorstellen, das ein Black-/Whitelisting eine gute Lösung wäre, wobei ein Whitelisting das Blacklisting "überschreiben" kann.
Dann könnte ich sagen Blacklist:"*" (also alle Pakete geblockt), Whitelist:"swaudit". Das würde bedeuten, wird swaudit auf Setup gesetzt kann es trotz der Blacklist "installiert" werden.

Wenn man dann noch für die einzelnen opsi-client events eine option "ignore-blocklist" implementiert, könnte man das ganz gut realisieren.

Re: Clients vor unerwünschten Veränderungen schützen

Verfasst: 11 Feb 2019, 14:26
von AlexB
tobias hat geschrieben: Rundmails von der IT, seien wir mal ehrlich, liest eh niemand :mrgreen:
Das sit nicht so ganz unwahr, aber dann ist man wenigstens auf der sicheren Seite :lol:
Doch das geht schon - schön ist die Lösung trotz dem nicht.
Ich sehe z.B. nicht wann sich der OPSI-Client das letzte mal gemeldet hat, die Clients sehen also aus wie Karteileichen.
Du siehst im config editor doch den Timestamp wann sich der client zuletzt zurückgemeldet hat.
Wenn man dann noch für die einzelnen opsi-client events eine option "ignore-blocklist" implementiert, könnte man das ganz gut realisieren.
Ich würde das einfach über ein extra Paket mit max Prio regeln, welches immer ausgeführt wird und alle anstehenden Installationen automatisch zurücksetzt. Sollte ja recht einfach über die opsiservicecall Funktion gehen.

Re: Clients vor unerwünschten Veränderungen schützen

Verfasst: 11 Feb 2019, 15:10
von tobias
Doch das geht schon - schön ist die Lösung trotz dem nicht.
Ich sehe z.B. nicht wann sich der OPSI-Client das letzte mal gemeldet hat, die Clients sehen also aus wie Karteileichen.
Du siehst im config editor doch den Timestamp wann sich der client zuletzt zurückgemeldet hat.
Nicht wenn der OPSI-Client deaktiviert ist ;)
Wenn man dann noch für die einzelnen opsi-client events eine option "ignore-blocklist" implementiert, könnte man das ganz gut realisieren.
Ich würde das einfach über ein extra Paket mit max Prio regeln, welches immer ausgeführt wird und alle anstehenden Installationen automatisch zurücksetzt. Sollte ja recht einfach über die opsiservicecall Funktion gehen.
Ich mag diese Vermischung von Software-Paketen & OPSI-Funktionspaketen nicht.
Das geht leider immer zu Lasten der Übersicht und hat eher einen Workaround Charakter.