[gelöst] Plugin- Installation über gesonderten Installationsaufruf

[Tode]

Wenn ich ein Plugin in den Notes- Client integriere, dann habe ich ja verschiedene Möglichkeiten:

1. Direkt mit der Installation durch Anpassung des Install- Manifests (install.xml)
2. Über Eine UpdateSite- Datenbank und den Widget- Catalog per Policy
3. als gesonderte Install- Anweisung.


Die 2. läuft hier, die erste ist aus verschiedenen Gründen nicht gewünscht, und jetzt evaluiere ich die 3. auch noch. Ich weiss, ich habe mich vor längerem mal damit beschäftigt, und es nicht wirklich hinbekommen.

Hat jemand eine gute, funktionierende Anleitung, wie man in einen Notes- Client im Nachhinein per Kommandozeile ein Plugin reininstalliert?

[umi]

Hallo

evtl via dropins ?
http://www-01.ibm.com/support/docview.wss?uid=swg21428464

[Tode]

Wenn ich das richtig verstehe, werden hier die Plugins auch erst installiert, wenn Eclipse (respektive der Notes- Client) gestartet ist. Ich suche einen Weg, um das Zeug "silent" im Hintergrund zu installieren, damit es beim nächsten Client- Start da ist...

[Tode]

Ich glaube, das hier ist eher das, was ich gesucht hatte... werde berichten, ob es damit geht...

[Tode]

Hier die versprochene Rückmeldung. Mit Hilfe der "CustomizeAddon.exe" aus dem Notes- Client- Installationskit funktioniert es -nach einigen Startschwierigkeiten- ganz gut. Einziges Problem: Obwohl ich in der install.addon.xml beim feature angegeben habe, das es "shared" installiert werden soll (also nach Programme (x86)\IBM\Notes\rcp\shared), installiert die generierte MSI das Plugin immer ins Workspace- Verzeichnis des Benutzers.

Wenn ich das noch rauskriegen könnte, wäre echt genial...

So sieht im übrigen meine install.addon.xml aus:

Code

<?xml version="1.0" encoding="UTF-8"?>

<ibm-portal-composite>
	<domain-object name="com.ibm.rcp.installmanifest">
		<object-data>
			<install>
				<installfeature id="Platform.XPD" required="true">
					<requirements>
						<feature id="com.endava.jabber4notes.feature"
							version="2.11.8.298" match="compatible"
							action="install" shared="true" mergeaction="add"
							url="jar:${installer.root}/updateSite.zip!/" />
						<feature id="com.endava.jabber4notes.IMPFragmentFeature"
							version="2.11.8.298" match="compatible"
							action="install" shared="true" mergeaction="add"
							url="jar:${installer.root}/updateSite.zip!/" />
					</requirements>
				</installfeature>
			</install>
		</object-data>
	</domain-object>
</ibm-portal-composite>

dazu noch diese plugin_customization.ini, damit ich kein problem mit der Signatur habe, und die Plugin- Vorkonfiguration gleich mal mitkommt:

Code

com.ibm.notes.branding/enable.update.ui=true
com.endava.jabber4notes/jid.field=InternetAddress
com.ibm.rcp.security.update/UNTRUSTED_SIGNATURE_POLICY=ALLOW
com.ibm.rcp.security.update/TRUST_CERTIFICATE_AUTHORITIES=true

Ich weiss, eigentlich müsste ich mit sauberen Signaturen arbeiten, aber jetzt muss es erstmal laufen...

[Pfefferminz-T]

Hallo Tode, ich war mir sicher, dass ich dazu schon mal etwas beim Admincamp gesehen habe:

http://www.admincamp.de/konferenz/ac2015.nsf/bc36cf8d512621e0c1256f870073e627/44b742297db59a94c1257de1004d1fbf/$FILE/T1S1.Eclipse-Plugin-MSI%20Paket%20erstellen.pdf

Sorry für die späte Zulieferung, aber vielleicht hilft das noch weiter bzgl. der Shared-Thematik. WIr haben bei meinem aktuellen Kunden ein PlugIn eines Drittanbieters, bekommen das aber schon immer als fertiges msi und dort funktioniert die Shared-Installation.

[Tode]

Vielen Dank für diesen Link... Genau so habe ich es letztendlich gemacht, aber ich habe als installfeatureid nicht die feature- ID aus dem XMl genommen, sondern "Platform.XPD", weil das so in der install-update.xml des Plugins drin war... muss mal probieren, ob das einen Unterschied macht...

Jetzt habe ich aber eine Frage: Bekommt Ihr vom Drittanbieter NUR ein msi, oder ist das ein ganzes Paket, das auch noch ein deploy- Verzeichnis, eine setup.exe, eine setup.ini und eben besagten MSI enthält? Oder andres gefragt: Kann ich nach dem beschriebenen Prozess einfach die msi nehmen und installieren, oder ist das nur die "Installationsanweisung" und ich muss den ganzen Rest mitliefern?

[Pfefferminz-T]

Da ist alles dabei... updatesite, deploy, etc.

In der install.addon.xml steht bei <installfeature id="install" id="name_nicht_platfom.XPD"...
<installfeature id> entspricht aber nicht dem <feature id>

[Tode]

Um das Ganze abzuschliessen: shared="true" hat leider keinerlei Einfluss, wenn im Feature selbst der Installationsort angegeben wird. Dieser steht in der feature.xml innerhalb der jar- Datei als

Code

colocation-affinity="com.ibm.rcp.site.anchor.user.feature"

Ändert man das auf

Code

colocation-affinity="com.ibm.rcp.site.anchor.shared.feature"

dann ändert sich der Installationsort.

Problem dabei: durch Ändern der feature.xml innerhalb des jar- files invalidiert man dessen Signatur. Man muss also das jar- file neu signieren.
Dazu per 7ZIP alle .SF und .RSA- Files aus dem Verzeichnis META-INF entfernen, einen eigenen Keystore rechnen mittels Keytool aus dem Java JDK (ggf. Schlüssel signieren lassen, wenn man nicht mit einem selbst signierten Zertifikat unterzeichnen will) und dann die Jar mittels jarsigner neu signieren.

ACHTUNG: Man muss hierzu UNBEDINGT ein JDK 1.6 benutzen, weil ab JDK 1.7 mit SHA256 signiert wird, was der Notes- Client (auch mit FP9) mit der Fehlermeldung "NoSuchAlgorithmException" bzw. "No algorithm found for 2.16.840.1.101.3.4.2.1" quitiert, der versteht laut diesem IBM Artikel (noch immer) nur SHA1 für signierte Plugins.

[Pfefferminz-T]

Danke wieder mal für die Detektivarbeit zum Ausgleich der schlechten bzw. nicht vorhandenen Dokumentation zu dem Thema!

[Tode]

Den entscheidenden Hinweis habe ich bei Stackoverflow bekommen, allerdings erst, nachdem ich einen Bounty von 200 Punkten ausgesetzt hatte.

Danach war es Trial & Error. Aber ich mache sowas gerne, ich habe wieder jede Menge gelernt, was mir in meiner weiteren Berufslaufbahn definitiv nützen wird.
Hier mal die "Lessons learned" aufgelistet, nur damit man sieht, dass sich so ein Aufwand durchaus lohnen kann:

Die folgende Auflistung ist ohne Sortierung nach Wichtigkeit o.ä. Viele der Punkte sind wahrscheinlich Allgemeinwissen, waren mir aber zu dem Zeitpunkt neu / nicht so bewusst

• jar- Files sind ganz einfach ZIP- Archive mit anderer Endung. Es braucht kein Spezielles Programm, sie zu öffnen / erstellen / bearbeiten
• Signierte jar- Files sind nicht etwa speziell modifiziert sondern enthalten schlicht einen Ordner "META-INF", der eine .SF und eine .RSA - Datei mit den Signaturen enthält.
• Mit Hilfe des Java JDK und dem darin enthaltenen keytool kann jeder ganz simpel einen Java- Keystore erstellen und mit einem self- signed- Zertifikat bestücken:
       keytool -genkey -keyalg RSA -alias cert-selfsigned -keystore cert-selfsigned.jks -storepass myP4ssword -validity 3600 -keysize 2048
• mit dem jarsigner (ebenfalls aus dem JDK) kann man problemlos jars signen (wenn Sie nicht bereits eine Signatur enthalten, sonst hat man nacher 2 signaturen im jar, und das geht nicht:
  jarsigner" -keystore cert-selfsigned.jks -signedjar com.endava.jabber4notes.feature_2.11.8.298.jar com.endava.jabber4notes.feature_2.11.8.298_unsigned.jar cert-selfsigned
• Der Notes- Client möchte seine jar- files bitte mit JDK 1.6 signiert, denn SHA256 schluckt er in dem Kontext nicht.
• Der Ort einer Eclipse- Plugin- Installation kann sowohl durch die install.xml mittels des dort vorhandenen shared="true" als auch durch die feature.xml (innerhalb jar) mittels der dort vorhandenen colocation-affinity gesteuert werden. Letztere hat höhere Präzedenz
• Plugins / Features werden mit einer install.xxx.xml installiert. Diese wird mit der install.xml im framework\rcp\deploy gemerged und dann die dort enthaltenen Komponenten installiert / aktualisiert / entfernt
• Die einzelnen Features enthalten in den jar- Dateien separate Install- Anweisungen in der feature.xml, die die install.xml ergänzen / überschreiben kann.
• Aus einem Plugin, das man als UpdateSite vorhanden hat, kann man relativ leicht eine per MSI Installierbare Version machen mit Hilfe der CustomizeAddon.exe

[JürgenT]

Hier die versprochene Rückmeldung. Mit Hilfe der "CustomizeAddon.exe" aus dem Notes- Client- Installationskit funktioniert es -nach einigen Startschwierigkeiten- ganz gut. Einziges Problem: Obwohl ich in der install.addon.xml beim feature angegeben habe, das es "shared" installiert werden soll (also nach Programme (x86)\IBM\Notes\rcp\shared), installiert die generierte MSI das Plugin immer ins Workspace- Verzeichnis des Benutzers.

Wenn ich das noch rauskriegen könnte, wäre echt genial...

So sieht im übrigen meine install.addon.xml aus:

Code

<?xml version="1.0" encoding="UTF-8"?>

<ibm-portal-composite>
	<domain-object name="com.ibm.rcp.installmanifest">
		<object-data>
			<install>
				<installfeature id="Platform.XPD" required="true">
					<requirements>
						<feature id="com.endava.jabber4notes.feature"
							version="2.11.8.298" match="compatible"
							action="install" shared="true" mergeaction="add"
							url="jar:${installer.root}/updateSite.zip!/" />
						<feature id="com.endava.jabber4notes.IMPFragmentFeature"
							version="2.11.8.298" match="compatible"
							action="install" shared="true" mergeaction="add"
							url="jar:${installer.root}/updateSite.zip!/" />
					</requirements>
				</installfeature>
			</install>
		</object-data>
	</domain-object>
</ibm-portal-composite>

dazu noch diese plugin_customization.ini, damit ich kein problem mit der Signatur habe, und die Plugin- Vorkonfiguration gleich mal mitkommt:

Code

com.ibm.notes.branding/enable.update.ui=true
com.endava.jabber4notes/jid.field=InternetAddress
com.ibm.rcp.security.update/UNTRUSTED_SIGNATURE_POLICY=ALLOW
com.ibm.rcp.security.update/TRUST_CERTIFICATE_AUTHORITIES=true

Ich weiss, eigentlich müsste ich mit sauberen Signaturen arbeiten, aber jetzt muss es erstmal laufen...

Hallo Tode, der Call liegt schon etwas zurück. Eine Frage bzgl. der plugin_customization.ini:
Ich habe versucht die Einstellungen über eine  Security-Richtlinie vorzunehmen, diese scheinen aber nicht zu greifen (Domino10). Wenn die Einstellungen in der plugin_customization.ini funktioniert das, weißt du, wieso das mit den Richtlinien nicht funktioniert? (in der Policy in der names.nsf sehe ich, dass der Client die Werte gezogen hat, beim Installieren des Plugin kommt es aber zu einer Fehlermeldung, das dieses nicht signiert ist)

Güße
Jürgen