Verwaltung mehrerer Produktversionen mit gleicher ProduktID möglich ?

[slotty]

Hallo miteinander.

Ich möchte mehrere Versionen eines Localboot-Produktes auf dem OPSI-Server vorhalten. Bislang bin ich davon ausgegangen, dass die Versionsnummer als Unterscheidungsmerkmal herangezogen wird und die ProduktID gleich sein kann. Nach mehreren Versuchen mit unterschiedlichen Versionsnummern bei gleicher ProduktID, bei dem anschließend immer nur die zuletzt installierte Version auf dem Server war, zweifele ich nun daran.

Mache ich was falsch, oder existiert das von mir erwartete Feature so nicht ?

Gruß

[feltel]

Das Feature gibt es so im OPSI leider (noch) nicht. Aktuell ist immer nur die Version auf dem OPSI verfügbar, die zuletzt installiert wurde (via opsi-package-manager oder z.B. über den opsiPackageBuilder). Das was zählt ist die Produkt-ID und nicht die Versionsnummer. Es kann also auf nem OPSI keine zwei Pakete firefox mit unterschiedlichen Versionsständen geben. Man könnte tricksen, indem man je gewünschter Version ein separates Paket mit eigener Produkt-ID baut, was aber mehr als unschön ist.

[slotty]

Vielen Dank für die zwar schnelle aber leider nicht zufrieden stellende Antwort.

Wird dann wohl auf unterschiedliche ProduktIDs hinauslaufen.

[panisch]

Was du alternativ noch mahcen kannst ist das ganze über ProductPropertys zu machen und dann in deinem Installationsscript je nach übergebener Version eine andere Installation anstarten..

Das ganze kannst du dann aber wahrscheinlich nicht wirklich gut auswerten, zumindest hab ich dafür bisher keine schöne Variante gefunden..

[n.wenselowski]

Hi,

Grundidee ist, dass immer die neueste Version installiert wird - wieso will ich auch veraltete Software verteilen?

Die beiden von panisch und feltel beschriebenen Varianten sind funktionierende Workarounds.


Gruß

Niko

[slotty]

Hi,

@panisch
Das habe ich mir auch schon überlegt. Dies bedeutet aber leider, dass man in der SW-Übersicht für den Client nicht mehr sieht welche Version er besitzt. Denn Properties werden dort ja wohl nicht angezeigt, oder liege ich da falsch?

@n.wenselowski
Vom Prinzip her richtig. Allerdings kam es hier auch schon vor, dass mit einer Java Aktualisierung auf einigen Rechner spezielle Anwendungen nicht mehr liefen. Dann ist es natürlich schön, wenn man ohne weiteres auf einen alten aber funktionierenden Stand zurück wechseln kann, und dies nicht für alle Rechner machen muss.
Soll ja auch schon vorgekommen sein, dass manche Software-Versionen auf einigen Betriebssystemen liefen und auf anderen nicht. So ist das nun einmal in heterogenen Umgebungen.
Aus meiner Sicht hätte es durchaus Charme, wenn nicht nur die ProduktID sondern zusätzlich auch die Versionsnummer als Unterscheidungsmerkmal dienen würde. Und die Reaktion auf meine Frage zeigt mir, dass ich damit anscheinend nicht alleine bin.

Dennoch, Hut ab, OPSI gefällt mir sehr gut und bietet wirklich viele Möglichkeiten. Sehr gute Arbeit.

[SisterOfMercy]

Also an idea: uninstall older versions with the uninstall supplied with that version.
This should be something that is an option per package, not globally. Some software isn't very nice, so you have to include a plethora of uninstall options in your uninstall script.

Let's say you have a particular piece of software, it is packaged with the nsis installer. However, it does not honour the /D option. So your uninstall script might get bigger each year:

Code: Alles auswählen

	Set $UninstallProgram64$ = "%ProgramFiles64Dir%\boringprogram 2013\uninst.exe"
	if FileExists($UninstallProgram64$)
		comment "Uninstall program found, starting uninstall"
		Winbatch_uninstall_64
		sub_check_exitcode
	endif

	Set $UninstallProgram64$ = "%ProgramFiles64Dir%\boringprogram 2014\uninst.exe"
	if FileExists($UninstallProgram64$)
		comment "Uninstall program found, starting uninstall"
		Winbatch_uninstall_64
		sub_check_exitcode
	endif
	
	Set $UninstallProgram64$ = "%ProgramFiles64Dir%\boringprogram 2015\uninst.exe"
	if FileExists($UninstallProgram64$)
		comment "Uninstall program found, starting uninstall"
		Winbatch_uninstall_64
		sub_check_exitcode
	endif

Of course this isn't that big of a deal unless the software supplier starts making changes to the installer, so you need to have multiple Winbatch sections because of the changes in the uninstaller, aaaargh!

[ueluekmen]

Hi,

wie immer sind wir gerne bereit darüber zu diskutieren. Das wir nur die productId als Unique ansehen hat einfache Gründe. In der Multidepotumgebung ist es durchaus möglich, dass mehrere Versionen eines Pakets parallel existieren. Und das überforder schon den einen oder anderen, der mehrere Depots hat.

Wenn wir das generell einführen würden, dann müsstest du dafür sorgen, dass bei jedem Update die alten Versionen manuell deinstalliert werden. Ansonsten sammelst du Revisionen von diesen Paketen. Wie wäre in so einem Fall der Usecase für setup setzen? Soll dann der configed einfach mehrere productIds zeigen? Was passiert, wenn mehrere von diesen auf setup gesetzt werden? Wer entscheidet, welches wann abgearbeitet wird?

Allerdings kam es hier auch schon vor, dass mit einer Java Aktualisierung auf einigen Rechner spezielle Anwendungen nicht mehr liefen.

Mit diesen Problem stehst du nicht alleine da. Wir haben das auch des öfteren, dass es Software gibt, die auf eine aktuelle Java 1.4 oder 1.5 aufsetzen. Mal davon abgesehen, dass ich die Software aus Prinzip nicht verwenden würde, wissen wir, dass diese Entscheidung nicht bei den Admins liegt. In so einem Fall würde ich die Abhängigkeit in das Produkt von der eigentlichen Software mitpacken, da du diese Abhängigkeit nur dann brauchst, wenn diese Software installiert wird. Und kannst dich dann auch speziell in diesem Paket um die Deinstallation der Abhängigkeit kümmern. Wenn die Software eigentlich nicht installiert werden muss (Webstart oder dergleichen) würde ich trotzdem ein Pseudo-Paket für die Software erstellen.

[pandel]

Wenn wir das generell einführen würden, dann müsstest du dafür sorgen, dass bei jedem Update die alten Versionen manuell deinstalliert werden. Ansonsten sammelst du Revisionen von diesen Paketen. Wie wäre in so einem Fall der Usecase für setup setzen? Soll dann der configed einfach mehrere productIds zeigen? Was passiert, wenn mehrere von diesen auf setup gesetzt werden? Wer entscheidet, welches wann abgearbeitet wird?

Wenn ich da mal einhaken darf... Bei der Anwenderumfrage 2014/2015 habe ich genau zu diesem Thema einen ziemlich langen Absatz unter "was wäre wünschenswert" hinterlassen, mit einer Beschreibung, wie das logisch gehen könnte.

Ich mach's nochmal in Kurzform, hoffe es ist verständlich:

-> Softwarepakete werden inkl. Versionsnummer in einzelne Release (->Paket-Bündel) verpackt, Release bekommen eine <Major>.<Minor> Kennung
-> Softwareanforderungen (setup/uninstall) immer aus einem einzelnen, definierten Release "xx.yy" heraus
-> Client bekommt zusätzlich zur Software eine Eigenschaft "Release", die bereits bei seiner Erstanlage angegeben wird und über die gesamte "Lebenszeit" zeigt, auf welchem Releasstand er gerade steht / dieses Release kann natürlich durch einen Releasewechsel geändert werden

=> das hat zur Folge, dass es problemlos möglich wäre, bestimmte Paketabhängigkeiten geschlossen zu halten, Releaseupdates ganzer Maschinengruppen rein auf Basis der Releasekennung durchzuführen (Bspw. "Alle Maschinen mit Release xx.yy sollen auf xx+1.yy gehoben werden" => völlig egal welche und wieviele konkreten Produkte enthalten sind, die Maschine bekommt sie verpasst - bspw. beim Upgrade: Deinstallation auf Basis Release xx.yy und Installation auf Basis xx+1.yy)

Na klar sammelst du dann Revisionen von Paketen, vor allem, wenn die Inst./Deinst. Routinen je nach Version unterschiedlich laufen, aber das ist doch unproblematisch.

Und was die Anzeige im configed anbelangt: da sich eine Maschine grundsätzlich auf einem bestimmten Releasestand befindet, wird auch immer nur eine ProduktID inkl. Version angezeigt (innerhalb von opsi selber würde ich eh zu einer völlig eigenen, internen Paketkennung wechseln, und nicht das verwenden, was "wir" Endanwender beim Paketbau da so alles reinhacken - dann könnte man auch ein Release total einfach aus den internen Paketnummern in einer hübschen Ansicht zusammenklicken)

Was Depots angebelangt "reicht" eigentlich eine Übersicht, in der man definiert, welches Release auf welchem Depot oder Depotgruppe verfügbar sein soll, damit hat sich die Verteilung dann auch direkt geregelt...

[larsg]

Wie wäre in so einem Fall der Usecase für setup setzen? Soll dann der configed einfach mehrere productIds zeigen? Was passiert, wenn mehrere von diesen auf setup gesetzt werden? Wer entscheidet, welches wann abgearbeitet wird?

Im Prinzip reicht doch einfach, die Spalte mit der Versionsnummer als Dropdownfeld zu definieren, so dass man die gewünschte Version auswählen kann.

Reihenfolge der Installation wird ggf. wie jetzt auch mit den Abhängigkeiten (welche auch auf Versionsangabe erweitert werden müssten) und Prioritäten geregelt.

Alternativ wäre auch bei Multi-Versions-Paketen eine Erweiterung der Zeile im ConfigEd mittels einer +-Schaltfläche am Anfang der Zeile möglich, so dass in der Hauptzeile die Versionsnummer leer bleibt, und darunter dann die Zeilen mit den verfügbaren Versionen eingeblendet werden.

So wie man es aus Access mit verknüpften Tabellen kennt :p

Die Meta-Daten rechts werden dann jeweils entsprechend der ausgewählten Version angezeigt.

Auf dem Depot könnte man die Struktur nach Versionsnummern in Unterordner verteilen.


#Edit: Wenn, dann sollte es m.E. auch möglich sein, mehrere Versionen parallel zu installieren. Java beispielsweise muss sogar je nach Konstellation mit verschiedenen Versionen installiert werden. Mit der oben beschriebenen Ansicht im ConfigEd sollte das aber machbar sein?!

Das damit keine Konflikte auftreten, dafür müssen die Skriptbauer selbst sorgen. Ist ja so wie es jetzt läuft auch nicht anders.