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
Clients vor unerwünschten Veränderungen schützen
Re: Clients vor unerwünschten Veränderungen schützen
Moin,
aktuell soweit ich weis nicht, wäre aber ein interessantes Feature was ich bei uns auch gut gebrauchen könnte.
Gruß
Tobias
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
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
VG
Rupert
Zuletzt geändert von r.roeder am 11 Feb 2019, 08:23, insgesamt 2-mal geändert.
opsi support - uib gmbh
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
For productive opsi installations we recommend maintainance + support contracts which are the base of opsi development.
Wondering who's using opsi? Have a look at the opsi map: http://opsi.org/opsi-map/.
Re: Clients vor unerwünschten Veränderungen schützen
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.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
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
Genau aus diesem Grund finde ich das Feature auch nicht gut.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.
Wir handhaben das so: es werden nur zu festen Tagen Updates eingespielt und das muss vorher auch per Rundmail angekündigt werden.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
Somit liegt die Verantwortung nicht bei uns in der IT wenn auf die Ankündigung keine Rückmeldung erfolgt.
Warum unterteilst du die Rechner im OPSI nicht auch in solche Gruppen? Damit wäre der Aufwand beim Deployment auch geringer.tobias hat geschrieben: Es gibt halt Clients mit hohem Automatisierungsgrad (Office PC) und Clients da terminiere ich das sehr genau mit dem Laborbeauftragten (LaborPC).
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?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.
VG
Re: Clients vor unerwünschten Veränderungen schützen
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.Wir handhaben das so: es werden nur zu festen Tagen Updates eingespielt und das muss vorher auch per Rundmail angekündigt werden.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
Somit liegt die Verantwortung nicht bei uns in der IT wenn auf die Ankündigung keine Rückmeldung erfolgt.
Im Laborbereich wird wirklich jeder einzelne PC manuell geupdated und vorher abgesprochen Rundmails von der IT, seien wir mal ehrlich, liest eh niemand
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.Warum unterteilst du die Rechner im OPSI nicht auch in solche Gruppen? Damit wäre der Aufwand beim Deployment auch geringer.tobias hat geschrieben: Es gibt halt Clients mit hohem Automatisierungsgrad (Office PC) und Clients da terminiere ich das sehr genau mit dem Laborbeauftragten (LaborPC).
Doch das geht schon - schön ist die Lösung trotz dem nicht.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?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.
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
Das sit nicht so ganz unwahr, aber dann ist man wenigstens auf der sicheren Seitetobias hat geschrieben: Rundmails von der IT, seien wir mal ehrlich, liest eh niemand
Du siehst im config editor doch den Timestamp wann sich der client zuletzt zurückgemeldet hat.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.
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.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
Nicht wenn der OPSI-Client deaktiviert istDu siehst im config editor doch den Timestamp wann sich der client zuletzt zurückgemeldet hat.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.
Ich mag diese Vermischung von Software-Paketen & OPSI-Funktionspaketen nicht.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.Wenn man dann noch für die einzelnen opsi-client events eine option "ignore-blocklist" implementiert, könnte man das ganz gut realisieren.
Das geht leider immer zu Lasten der Übersicht und hat eher einen Workaround Charakter.