Best Practice Patchmanagement mit OPSI
Best Practice Patchmanagement mit OPSI
Hi,
unter anderem soll OPSI ja auch bestehende Software Patchen.
Wie führt ihr das durch? Schnürt ihr für jeden Patch ein neues Paket? dadurch würde ja die Software Liste mit der Zeit ziemlich voll.
Eine extra Patch Funktion gibt es ja nicht (wäre übrigens mal ne gute Idee)
Beispiel Adobe Flash Player oder Java Updates die ja sehr häufig kommen für jedes Update nen neues OPSI Paket?
Wie läuft das bei einem Abo? Da ist ja unter anderem Flash dabei.
Gruß
Tobias
unter anderem soll OPSI ja auch bestehende Software Patchen.
Wie führt ihr das durch? Schnürt ihr für jeden Patch ein neues Paket? dadurch würde ja die Software Liste mit der Zeit ziemlich voll.
Eine extra Patch Funktion gibt es ja nicht (wäre übrigens mal ne gute Idee)
Beispiel Adobe Flash Player oder Java Updates die ja sehr häufig kommen für jedes Update nen neues OPSI Paket?
Wie läuft das bei einem Abo? Da ist ja unter anderem Flash dabei.
Gruß
Tobias
Re: Best Practice Patchmanagement mit OPSI
Abo: haben wir noch nicht kann ich nix dazu sagen ...tobias hat geschrieben:Hi,
unter anderem soll OPSI ja auch bestehende Software Patchen.
Wie führt ihr das durch? Schnürt ihr für jeden Patch ein neues Paket? dadurch würde ja die Software Liste mit der Zeit ziemlich voll.
Eine extra Patch Funktion gibt es ja nicht (wäre übrigens mal ne gute Idee)
Beispiel Adobe Flash Player oder Java Updates die ja sehr häufig kommen für jedes Update nen neues OPSI Paket?
Wie läuft das bei einem Abo? Da ist ja unter anderem Flash dabei.
Gruß
Tobias
selbstgebrautes :
(immer aktuellste Version überschreibt im Depot die letzte)
Firefox -> aktuelle version z.B. 8.0, 7.0.1 etc. -> ein Paket
Firefox old stable -> z.B. 3.6.x -> ein Paket
Adobe Flash-Player -> 11.x -> ein Paket, keine alten Versionen wg. Sicherheitslücken.
Adobe Reader 10.1.x -> Paket für Win7 und WinXP
Adobe Reader 9.4.6 -> Paket für Win2000
Java 6.29 -> WinXP, Win7 -> ein Paket
Java 6.22 -> Win2000 -> ein Paket
von allen älteren Versionen werden immer die .opsi Pakete eine Zeitlang aufbewahrt bis man sicher ist daß man sie nicht mehr braucht ...
hth
MH
Re: Best Practice Patchmanagement mit OPSI
ich kann ja einfach ein neues Paket einspielen aber da habe ich dann keine Übersicht welche Clients noch die alte Version haben.
Eine Art Patchmanagement Funktion mit Slave Paketen und Masterpaketen würde an dieser stelle Sinn machen. Also eine Funktion Pakete zu schnüren die automatisch auf Setup gesetzt werden wenn Paket X auf Client Y auf Installed gesetzt ist.
Am besten mit eigener Übersicht. z.B. Rechtsklick auf Paket "Show Patch Packages" und dann sieht man eine Liste mit sämtlichen verfügbaren Updates für dieses Produkt.
Natürlich sollte es auch Patches geben die nicht automatisch installiert werden und natürlich Clients die automatische Updates nicht bekommen (ja die gibts leider ....) und man sollte für einen Client ein Update auf "Ignore" setzen können also das er das Update nicht bekommt (andere Updates aber weiterhin automatisch)
Wär das nicht ne potentielle kofinanziete Erweiterung?
Gruß
Tobias
Eine Art Patchmanagement Funktion mit Slave Paketen und Masterpaketen würde an dieser stelle Sinn machen. Also eine Funktion Pakete zu schnüren die automatisch auf Setup gesetzt werden wenn Paket X auf Client Y auf Installed gesetzt ist.
Am besten mit eigener Übersicht. z.B. Rechtsklick auf Paket "Show Patch Packages" und dann sieht man eine Liste mit sämtlichen verfügbaren Updates für dieses Produkt.
Natürlich sollte es auch Patches geben die nicht automatisch installiert werden und natürlich Clients die automatische Updates nicht bekommen (ja die gibts leider ....) und man sollte für einen Client ein Update auf "Ignore" setzen können also das er das Update nicht bekommt (andere Updates aber weiterhin automatisch)
Wär das nicht ne potentielle kofinanziete Erweiterung?
Gruß
Tobias
Re: Best Practice Patchmanagement mit OPSI
Moinsens,
Wenn Du also auf einem Rechner noch Firefox 7.0 drauf hast und im Paket schon Version 8.0 ist, dann kannst Du das im configed sehen.
Ansonsten machen wir es auch nicht anders, wie schon beschrieben. Alte Versionen einer Software sollten wegen geschlossener Sicherheitslücken nicht mehr angeboten werden.
Gruß
Thomas_H
Na doch: Du änderst doch auch vor den Neupacken des Produktes im Verzeichnis OPSI die control-Datei und schreibst die neue Versionsnummer. Und für jeden Client wird im Verzeichnis /var/lib/opsi/config/audit eine Datei angelegt (<rechnername.sw>) in welcher die Versionsnummern aufgelistet sind.tobias hat geschrieben:ich kann ja einfach ein neues Paket einspielen aber da habe ich dann keine Übersicht welche Clients noch die alte Version haben.
Wenn Du also auf einem Rechner noch Firefox 7.0 drauf hast und im Paket schon Version 8.0 ist, dann kannst Du das im configed sehen.
Ansonsten machen wir es auch nicht anders, wie schon beschrieben. Alte Versionen einer Software sollten wegen geschlossener Sicherheitslücken nicht mehr angeboten werden.
Gruß
Thomas_H
Kennst Du schon die WIKI für OPSI-Scripte? Fertige Installationsscripte bekommen und ablegen unter OPSI-Wiki
Aus dem Glashaus : UIB bietet auch Schulungen und Supportverträge für Opsi an.
Aus dem Glashaus : UIB bietet auch Schulungen und Supportverträge für Opsi an.
Re: Best Practice Patchmanagement mit OPSI
Ja schon natürlich tausche ich die Pakete gelegentlich gegen neue aus. Das ändert aber nur den Status für Neuinstallationen sprich alle neuinstallierte Rechner die neu mit dem Produkt versorgt werden bekommen auch das neue.Thomas_H hat geschrieben:Moinsens,
Na doch: Du änderst doch auch vor den Neupacken des Produktes im Verzeichnis OPSI die control-Datei und schreibst die neue Versionsnummer. Und für jeden Client wird im Verzeichnis /var/lib/opsi/config/audit eine Datei angelegt (<rechnername.sw>) in welcher die Versionsnummern aufgelistet sind.tobias hat geschrieben:ich kann ja einfach ein neues Paket einspielen aber da habe ich dann keine Übersicht welche Clients noch die alte Version haben.
Wenn Du also auf einem Rechner noch Firefox 7.0 drauf hast und im Paket schon Version 8.0 ist, dann kannst Du das im configed sehen.
Ansonsten machen wir es auch nicht anders, wie schon beschrieben. Alte Versionen einer Software sollten wegen geschlossener Sicherheitslücken nicht mehr angeboten werden.
Gruß
Thomas_H
Alte Installationen werden eben nicht gepatched. Und jedes mal Deinstallation und Neuinstallation ist ja auch nicht Sinn der Sache.
Außerdem wird das Update so nicht automatisch "Deployed" ich muss erst alle Rechner auswählen die die entsprechende Software überhaupt installiert haben. Beispiel die Adobe Creative Suite hat eben nicht jeder Rechner drauf sondern nur eine Hand voll. Somit wäre ein System welches automatisch erkennt das das Masterpaket Adobe CS5 auf Client PC1, PC2, PC10 .... installiert ist und die Slavepakete 1,2 und 3 automatisch auf Setup setzt.
Ich installiere ja auch nicht Windows neu weil es am Dienstag nen Patch gegeben hat und ich baue dafür auch nicht extra neue Installationsmedien das mache ich 1-2x im Jahr anschließend Patched der WSUS die Rechner dann automatisch.
Re: Best Practice Patchmanagement mit OPSI
Hi!
Der Opsi-Product-Updater macht genau das was Du willst. Du installierst am Server ein neues Paket, und der Product-Updater setzt es für dich bei allen clients, auf denen es installiert ist auf setup (mal in der OPSI Doku nachschauen).
Gruß
Kathrin
Der Opsi-Product-Updater macht genau das was Du willst. Du installierst am Server ein neues Paket, und der Product-Updater setzt es für dich bei allen clients, auf denen es installiert ist auf setup (mal in der OPSI Doku nachschauen).
Gruß
Kathrin
Re: Best Practice Patchmanagement mit OPSI
Hi,
vielleicht hier noch der Hinweis auf weitere Möglichkeiten, die sich in der Praxis etabliert haben:
1.) Pakete bauen und normal mit
einspielen. Auf ausgesuchte Testsysteme manuell einspielen und das Paket testen. Wenn das Paket für gut befunden wurde, kann man das ganze durch nochmaliges einspielen "Scharfschalten":
oder
Die Schalter bewirken automatisch auf setup/update stellen des Pakets beim Einspielen. (Natürlich wo das Paket auf installed steht).
2.) opsi-admin ist auch hier dein Freund und Helfer, hier ein Beispiel mit Firefox:
Dieser Aufruf bewirkt genau das was gewünscht ist.
3.) Auswahl definieren im configed, da kann man einen Filter setzen, der einem die Clients filtert, die den aktuellen Softwarestand nicht haben. Diese kann man alle gemeinsam bearbeiten.
Weiterhin noch der Hinweis auf die Update-Skript Mechanik (bitte unbedingt in der Doku nachlesen, bevor diese Methode angewendet wird, da man erst die Funktionsweise verstehen muss.) Oder sich auf einer Schulung genau erklären lassen, wie das ganze funktioniert.
Ich möchte hier vielleicht auch noch mal darauf hinweisen, dass man opsi nicht mit WSUS vergleichen sollte. WSUS hat eine ganz andere Arbeitsweise als opsi. Dort kann man zum Beispiel nicht beeinflussen, wann die Clients letztendlich Ihre Updates ziehen und ob Sie sich diese überhaupt ziehen. Weiterhin ist opsi ein Werkzeug, welches dem Administrator die Freiheiten lässt, selber zu entscheiden, wie, wann und auf welche Weise Updates auf den Clients landen.
Vielleicht hilft das bei der Diskussion ja weiter
vielleicht hier noch der Hinweis auf weitere Möglichkeiten, die sich in der Praxis etabliert haben:
1.) Pakete bauen und normal mit
Code: Alles auswählen
opsi-package-manager -i <paket.opsi>
Code: Alles auswählen
opsi-package-manager -iS <paket.opsi>
Code: Alles auswählen
opsi-package-manager -iU <paket.opsi>
2.) opsi-admin ist auch hier dein Freund und Helfer, hier ein Beispiel mit Firefox:
Code: Alles auswählen
opsi-admin -d task setActionRequestWhereOutdated setup firefox
3.) Auswahl definieren im configed, da kann man einen Filter setzen, der einem die Clients filtert, die den aktuellen Softwarestand nicht haben. Diese kann man alle gemeinsam bearbeiten.
Weiterhin noch der Hinweis auf die Update-Skript Mechanik (bitte unbedingt in der Doku nachlesen, bevor diese Methode angewendet wird, da man erst die Funktionsweise verstehen muss.) Oder sich auf einer Schulung genau erklären lassen, wie das ganze funktioniert.
Ich möchte hier vielleicht auch noch mal darauf hinweisen, dass man opsi nicht mit WSUS vergleichen sollte. WSUS hat eine ganz andere Arbeitsweise als opsi. Dort kann man zum Beispiel nicht beeinflussen, wann die Clients letztendlich Ihre Updates ziehen und ob Sie sich diese überhaupt ziehen. Weiterhin ist opsi ein Werkzeug, welches dem Administrator die Freiheiten lässt, selber zu entscheiden, wie, wann und auf welche Weise Updates auf den Clients landen.
Vielleicht hilft das bei der Diskussion ja weiter
opsi support - uib gmbh
For productive opsi installations we recommend support contracts.
http://www.uib.de
For productive opsi installations we recommend support contracts.
http://www.uib.de
Re: Best Practice Patchmanagement mit OPSI
Super danke für die Antworten das hat auf jedenfall schonmal weitergeholfen !!!
Die "Macht" die OPSI-Admin und auch der Paket-Manager haben war mir gar nicht so bewusst.
Die "Macht" die OPSI-Admin und auch der Paket-Manager haben war mir gar nicht so bewusst.