forum.opsi.org

Hallo,

wir haben heute das Paket "javavm" des Update-Abos auf unseren Clients verteilt. Leider gab es bei mehreren Probleme bei der Installation.
Im Schritt "Deinstall" bleibt es bei einigen Clients hängen und fragt bei anderen nach dem Aufenthaltsort von MSI Paketen.

Desweiteren können Clients nach der Installation bestimmte Java-Entwickleranwendungen wie Tomcat oder Eclipse nicht mehr starten.
Daher ist das Paket bei uns leider nicht zu verteilen.

Ggf. würde das Überspringen der Deinstallation aller älteren Java-Versionen das Problem beseitigen. Gibt es eine Möglichkeit das Paket so umzustellen (per optionale Produkkonfiguration), dass lediglich eine Installation durchgeführt wird ohne ältere Versionen zu deinstalleiren?
Es werden hier unter anderem auch Software eingesetzt, die eine bestimmte Java-Version zur Ausführung benötigen. Eine Deinstallation würde in dem Fall auch nur zu Probleme führen.

Mit freundlichen Grüßen
M.Lesniowski

Guten Morgen, ich habe auch weiterhin Probleme mit der Installation Java aus dem Update Abo. Haben Sie es vlt auch temporär die Installation per Hand probiert?
So konnten unsere Nutzer zumindestens arbeiten.

Anbei verweise ich nochmals auf meine Thread. Nur das es sich bei uns um andere Programme handelt. viewtopic.php?f=7&t=4576
Ich hoffe Xane, es ist ok wenn ich mich hier dranhänge. Für Hilfe wäre ich immer noch dankbar.

Mit freundlichen Grüßen.

S.Hommen

Hallo,

vorab ein paar allgemeine Anmerkungen:

Bugreports, Anregungen und Änderungswünsche zum Standard-Abo nehmen wir hier im Forum oder auch per Mail an info<at>uib.de entgegen. Eine schnellere Antwort bekommt man in jedem Falle, wenn man einen unserer Supportverträge hat, die wir jedem ans Herz legen, der opsi produktiv einsetzt.

Wenn man opsi in einer "gewachsenen" Struktur einführt um Standards durchzusetzen oder zu erreichen, so ist mit Seiteneffekten zu rechnen.

Das gleiche gilt bei der Verwendung unseres Standard-abos in einer gewachsenen Struktur.

Mit den Produkten im Standard-Abo werden verschiedene Paket auf aktuellen Stand gebracht.

Spezielle Anmerkungen zum Javavm-Paket:

Wie in der Doku zum Paket beschrieben wird per default versucht "Patch-in-place" Installationen (die eine andere MSI-ID als "static" Installationen haben), zu deinstallieren

Das javavm-Paket beinhaltet die Oracle Jre in den Versionen 1.6.x und 7.x
( Für Jre 1.6.x ist das Ende der "Public Updates" für in 2013 angekündigt, http://www.oracle.com/technetwork/-
java/eol-135779.html )
Die Oracle JRE wird dabei mit "Patch-in-place configuration" installiert (seit jre 1.6.0_10 )
http://www.oracle.com/technetwork/java/ ... 37694.html
Vor der Installation werden bestehen "Patch-in-place" Jre-Versionen 1.6.x und 7.x deinstalliert.
• Vorhandene Oracle JRE mit "Static configuration" werden nicht deinstalliert.
• Eventuell vorhandene Oracle JRE (version 1.6.0 - version 1.6.7) werden deinstalliert, es sei denn Sie werden explizit
über die property "keepversion" ausgeschlossen.

Xane hat geschrieben:Hallo,

wir haben heute das Paket "javavm" des Update-Abos auf unseren Clients verteilt. Leider gab es bei mehreren Probleme bei der Installation.
Im Schritt "Deinstall" bleibt es bei einigen Clients hängen und fragt bei anderen nach dem Aufenthaltsort von MSI Paketen.

Von daher scheint hier eine Nicht-standard "Patch-inPlace" Installation vorzuliegen - muesste man aber genauer pruefen

Xane hat geschrieben:
Desweiteren können Clients nach der Installation bestimmte Java-Entwickleranwendungen wie Tomcat oder Eclipse nicht mehr starten.
Daher ist das Paket bei uns leider nicht zu verteilen.

Muss man sich genauer ansehen, warum dies so ist.

Xane hat geschrieben: Ggf. würde das Überspringen der Deinstallation aller älteren Java-Versionen das Problem beseitigen.

Auch das muesste man zunächst prüfen.

Xane hat geschrieben: Gibt es eine Möglichkeit das Paket so umzustellen (per optionale Produkkonfiguration), dass lediglich eine Installation durchgeführt wird ohne ältere Versionen zu deinstalleiren?

Ich persönlich halte dies für keine gute Idee, wir werden dies aber bei Gelegenheit nochmals intern diskutieren.

Eine Alternative ist es zumindest zum Test, unser Abo-Paket sich jeweils nach eigenen Bedürfnissen neu zu paketieren

Xane hat geschrieben: Es werden hier unter anderem auch Software eingesetzt, die eine bestimmte Java-Version zur Ausführung benötigen. Eine Deinstallation würde in dem Fall auch nur zu Probleme führen.

Mit freundlichen Grüßen
M.Lesniowski

Hier würde ich versuchen mit "static-"Installationen zu arbeiten,

Gruss
Bardo Wolf

Hallo,

erstmal vielen Dank für die aufschlussreiche Antwort.
Wir versuchen bei der Notwendigkeit bestimmter Java-Versionen diese als static Installation erneut zu installieren. Was uns nun auffällt ist, dass mit dem aktuellen Javapaket nur noch Java 7 installiert werden kann. Da wir jedoch noch Software einsetzen, die eine Java Runtime in der Version 6 erfordert, können wir das Paket somit nicht auf diesen Rechnern verteilen.
Wäre es möglich, entweder die Auswahl der zu installierenden Java-Version zu ermöglichen oder zusätzlich eine dritte Option einzubauen die erkennt, ob eine Java Installation in Version 6 und/oder 7 bereits auf dem Rechner existiert und diese aktualisiert? Ein mögliches Szenario wäre ein Client, auf dem sowohl Java 6 als auch Java 7 eingesetzt wird, Java 7 als Standard eingerichtet und Java 6 für die Software, die Java 6 voraussetzt. Die Option würde sowohl Java 6 als auch Java 7 auf den aktuellsten Stand bringen. Dies wäre, zumindest in unserer Infrastruktur, optimal und mich gegebenenfalls wäre eine solche Funktion auch bei anderen Infrastrukturen von Interesse.

Gruß

Michael

Hi,

vielleicht hilft das ja weiter:
you will find a java 1.6.0.45 opsi Product at
https://download.uib.de/abo/standard/opsi4/unsupported/

gruß

d.oertel

Guten Tag,

auch ich teste gerade das JavaVM Update-Paket.
Bei uns ist es auch immer das Problem, dass eine Deinstallation einer alten Version nicht funktioniert.
Ich habe mit den "Uninstall"-Schlüssel in der Registry angesehen, der im subdel.ins abgefragt wird. Dieser weist auf vielen Rechnern mehrere Versionen auf. Installiert ist tatsächlich jedoch nur 1 Version.

In meinem konkreten Beispiel war es so:
opsi versuchte immer die Version 1.6_39 zu deinstallieren. Auf dem System war jedoch nur die Version 1.6_45 installiert.

Ich kann mir dann so helfen, dass ich in der Datei "jre6uninstallstrings.ins" alle Versionen herausnehme, welche nicht geprüft werden sollen. Dann wird einfach keine Deinstallation durchgeführt und gut. Diese Änderung müsste dann jedoch bei jedem neuen Update gemacht werden. OK, soweit est einmal kein Problem.
Ich fände jedoch glücklicher, wenn man einen Timeout bei der Deinstallation einbauen könnte, nach dessen Ablauf die Deinstallation abbricht und mit der Installation fortgefahren wird. Dies wäre dann nützlich, wenn z.B. wie bei mir alte Registry-Schlüssel im Unistall-Schlüssel sind, die Versionen jedoch nicht mehr.
Geht das irgendwie?
Ich hatte auch überlegt die Registry aller meiner Systeme über opsi aufzuräumen, indem alle alten, nicht gewünschten Uninstall-Schlüssel in der Regisry gelöscht werden. Wird jedoch ein Schlüssel für eine Version gelöscht, kann diese nicht mehr über die Softwaresteuerung von Windows deinstalliert werden. Bedeutet keine gute Lösung.

Mit der Deaktivierung der Prüfung der alten Versionen durch Löschung in der "jre6uninstallstrings.ins" ist für mich erst einmal praktikabel denke ich.
Trotzdem fände ich einen etwas robusteren Umgang mit nicht mehr vorhandenen Version glücklicher.

Beste Grüße
Roland