Eine minimale HCL Connections (CNX) 6.5 Testinstallation ist das Ziel dieses Beitrags. Und zwar bewusst manuell, um ein Verständnis für die einzelnen Komponenten mit ihrem Zusammenspiel zu schaffen. Inzwischen habe ich mit Terraform das Anlegen & Provisionieren der VMs automatisiert, eben so die CNX Installation. Das ist sinnvoll, wenn man alles verstanden hat – was zu Beginn nicht der Fall sein wird.
Gerade zu Beginn empfiehlt sich der harte Weg. Er ist zwar aufwändiger und kostet mehr Nerven. Doch was nützt es, eine Umgebung automatisiert mit Skripten (von anderen) aufzusetzen – aber bei Problemen keine Ahnung zu haben? Um den Fokus auf das Wesentliche zu legen, wird in diesem Beitrag auf das Component Pack verzichtet. Es liefert in 6.5 ohnehin nur ergänzende Funktionen wie den Customizer, die sich auf anderem Wege realisieren lassen (z.B. JSP-Anpassungen).
Hinweis: HCL Connections 6.5 hat sein Lebensende erreicht. Zum Stand 2025 ist mindestens Version 7, besser 8 zu empfehlen. Im Wesentlichen können die Schritte für CNX 6.5 angepasst (Versionsnummern in Dateinamen usw) verwendet werden. Die Installation unterscheidet sich nur im Detail.
Benötigte Komponenten
Als Grundlage dienen die Systemanforderungen für die jeweilige Version von Connections, in diesem Beispiel ist das 6.5 CR1. Alles hier beschriebene lässt sich ähnlich mit den Nachfolgeversionen umsetzen.
CentOS als Betriebssystem
Da Connections RHEL unterstützt, verwende ich CentOS 7 als freie Alternative. Connections 6.5 ist noch nicht mit der Nachfolgeversion 8 kompatibel, wobei CentOS sich mit der Hauptversion stark verändert: Aus der stabilen Distribution ist eine Rolling Release Version geworden. Daher würde ich zu Alma Linux oder Rocky Linux wechseln, die den ursprünglichen Weg als stabile RHEL Binärkompatible Version beibehalten haben. Allerdings ist Connections 6.5 derzeit noch nicht mit RHEL 8 kompatibel, hierfür müsste man Connections 7 oder neuer verwenden.
Wichtig ist zudem ein funktionierendes DNS: Jeder Server sollte einen auflösbaren FQDN besitzen.
Datenbank
Connections unterstützt nur proprietäre Datenbanken: MSSQL, IBM DB2 und Oracle. Eine DB2-Lizenz ist in Connections inklusive, daher verwenden wir dies im Folgenden.
LDAP-Server
Connections bietet keine eigene Nutzerverwaltung. Man benötigt einen Verzeichnisdienst, aus dem die Benutzer (ggf. anhand bestimmter Kriterien) mittels TDI synchronisiert werden. In der Praxis dürfte ohnehin in den meisten Unternehmen bereits ein Active Directory oder anderer Verzeichnisdienst existieren, sodass es sich anbietet, diesen zu verwenden.
In dieser Testinstallation werden wir OpenLDAP nutzen, einen der verbreitetsten Verzeichnisdienste unter Linux.
TDI
Der IBM Tivoli Directory Integrator (kurz TDI) wird periodisch unseren Verzeichnisdienst mit der Connections-Datenbank abgleichen. Man kann alle Benutzer synchronisieren oder anhand bestimmter Kriterien (z.B. LDAP-Gruppe) filtern.
WebSphere Anwendungsserver
Der WebSphere Application Server wird genutzt, um die Java-Anwendungen von Connections zu betreiben. Auch dieses Software ist proprietär und wird über HCL von IBM lizenziert. Im Gegensatz zu kleineren Anwendungsservern wie z.B. Tomcat ist WebSphere auf größere Cluster ausgelegt. Es gibt daher grundsätzlich einen Deployment Manager, der als die Nodes verwaltet, auf denen die Anwendungen laufen. Man muss WebSphere nicht zwingend clustern, wenn dies nicht benötigt wird.
IBM HTTP Server
Ein Fork des Apache 2.2 Webservers, der mithilfe einer Erweiterung die Verbindung zu dem oder den WebSphere-Servern aufnimmt. Mithilfe einer Erweiterung kann man WebSphere-Anwendungen darauf mappen. Er übernimmt die Lastverteilung, ist allerdings kein vollwertiger Apache Webserver. So stehen beispielsweise nicht alle Module zur Verfügung.
Nginx mit Let’s Encrypt
Nginx ist ein schlanker Reverse Proxy, womit wir die automatisierten und kostenfreien Zertifikate von Let’s Encrypt nutzen können. Die Apache-Integration ist nicht mit dem IBM HTTP Server kompatibel. Der Nginx ist nicht zwingend nötig, allerdings sollte SSL eingesetzt werden. Wer etwa eine eine eigene CA im Unternehmensumfeld besitzt, der kann entsprechend selbst ein Zertifikat erstellen, signieren und es über ikeyman im IHS Store hinterlegen.
Vorbereitung
Vorbereiten der Server
Zunächst aktualisieren wir die Paketquellen und Pakete auf beiden Servern (als root):
yum updateFür den Einstieg und die erste Testinstallation würde ich die grafischen Installationsassistenten verwenden, da diese einen durch die Einrichtung leiten. Zwar stehen auch Konsolenwerkzeuge zur Verfügung, wie dies unter Linux üblich ist. Allerdings ist dies für den Einstieg aufgrund der Komplexität in meinen Augen nicht optimal. Teils benötigt man zumindest einmalig die grafischen Werkzeuge, um die notwendigen Konfigurationsdateien zu erstellen.
Damit keine vollständige Desktopumgebung installiert werden muss, kann man mit X11-Forwarding arbeiten.
yum install xorg-x11-server-Xorg xorg-x11-xauth xorg-x11-appsIn /etc/ssh/sshd_config muss zudem X11Forwarding yes und X11UseLocalhost No gesetzt sein. Bei CentOS 7 ist dies standardmäßig der Fall, für Änderungen ist ein Neustart des SSH-Daemon (systemctl restart sshd) notwendig.
Beim Kommandozeilen-Client aktiviert man X11-Forwarding mit dem Schalter -X
ssh -X user@cnx-serverWer einen anderen, grafischen Client nutzt, muss in den Einstellungen der Verbindung schauen. Bei MobaXterm kann man etwa im SSH-Reiter den Haken X11-Forwarding setzen:
CentOS bringt standardmäßig SELinux mit. Da dies von Connections nicht unterstützt wird, müssen wir es deaktivieren und anschließend neu starten:
sed -i 's/SELINUX=permissive/SELINUX=disabled/g' /etc/selinux/config
rebootAchtung: Wer dennoch eine grafische Oberfläche verwendet (etwa bei lokalen VMs), installiert durch die Gruppe etwa Firewalld mit. dies muss eben so deaktiviert werden wie SELinux (nicht von CNX unterstützt):
systemctl disable --now firewalldFür Connections und DB2 müssen entsprechend den Anforderungen noch ein paar Limits in der Datei /etc/security/limits.conf erhöht werden:
* - nproc 16384
* - nofile 65536
* - stack 10240Wir setzen dies auf beiden Servern für jeden Benutzer. Produktiv würde man dies auf die entsprechenden Nutzer von WebSphere (auch für Connections) und DB2 (Instanz-Eigentümer) einschränken. Damit dies wirksam wird, die SSH-Sitzung schließen (exit) sowie neu öffnen.
Wenn IPv6 nicht genutzt/benötigt wird, kann man es durch das setzen folgender zwei Zeilen in der Datei /etc/sysctl.conf deaktivieren:
net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1Danach die Datei mit sysctl -p neu laden. Damit es dadurch zu keinen Problemen in Kombination mit X-Forwarding unter SSH kommt, sollte in /etc/ssh/sshd_config AddressFamily inet gesetzt sein (statt any).
Download der Installationsdateien
Mittlerweile finden sich die meisten Installationsdateien in der HCL Connections Gruppe des Flexnet. Aktualisierungen (wie z.B. CR1 für 6.5) finden sich in der Connections CR Gruppe. Da manche Dateien wenig sprechend benannt sind, würde ich diese zur besseren Übersicht in folgender Ordnerstruktur organisieren:
[root@cnx65-was ~]# tree /opt/install
/opt/install
├── cnx
│ └── HCL_Connections_6.5_lin.tar
├── installation-manager
│ └── agent.installer.linux.gtk.x86_64_1.8.5000.20160506_1125.zip
├── HCL_Connections_6.5_lin.tar
├── lost+found
└── was
├── CIK2HML.zip
├── CIK2IML.zip
├── CIK2JML.zip
└── supplements
├── CIK1VML.zip
├── CIK1WML.zip
└── CIK1XML.zip
[root@cnx65-db2 ~]# tree /opt/install/
/opt/install/
└── db2
│ ├── DB2_ESE_AUSI_Activation_11.5.zip
│ └── v11.5.6_linuxx64_universal_fixpack.tar.gz
├── HCL_Connections_6.5_wizards_lin_aix.tar
IBM Installation Manager
Wird zur Installation von WebSphere benötigt, mindestens Version 1.8.5.1. Kann (noch?) nicht im Flexnet heruntergeladen werden, sondern im IBM Fix Central (IBM ID benötigt).
WebSphere
IBM WebSphere Application Server Network Deployment V8.5.5 (1 of 3) for Multiplatform Multilingual IBM WebSphere Application Server V8.5.5 Supplements (1 of 3) for Multiplatform Multilingual IBM WebSphere Application Server V8.5.5 Supplements (1 of 3) for Multiplatform Multilingual
Jeweils alle drei Zip-Dateien herunterladen.
DB2
DB2 11.5.6 FixPack 0 for Linux/x86-64 (64 bit), DB2 Universal Fix Pack IBM Db2 Enterprise Server Edition – Authorized User Single Install Option – Activation 11.5 for Linux, UNIX and Windows Multilingual
TDI
IBM Security Directory Integrator V7.2 for Linux Linux – x86-64
Connections
HCL Connections V6.5 for Linux Multilingual HCL Connections V6.5 Wizard for Linux, AIX Multilingual JDBC 3-Treiber für DB2 (nur bis DB2 Version 11.1 mitgeliefert, bei 11.5 ist nur der Nachfolger JDBC 4 dabei)
Installation der Komponenten
OpenLDAP
[root@cnx65-db2 ~]# yum install openldap-clients openldap-servers
[root@cnx65-db2 ~]# systemctl enable --now slapdFür die grundlegende Konfiguration legt eine Ldiff-Datei (hier ldap-base.ldiff) an mit folgendem Inhalt
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=u-labs,dc=de
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=admin,dc=u-labs,dc=de
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}6FPF2qA2kEFqVlO2hBZYPj4s5VLc3jK3
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcDbIndex
olcDbIndex: objectclass eq,pres
dn: olcDatabase={2}hdb,cn=config
changetype: modify
add: olcDbIndex
olcDbIndex: uid,ou,cn,mail,sn eq,pres,sub
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external, cn=auth" read by dn.base="cn=admin,dc=u-labs,dc=de" read by * none
Sowie eine zweite Datei, um die Organisation/Domäne als Objekt anzulegen (dc.ldiff). Wer möchte, kann alternativ auch eine Organisationseinheit (OU statt O) erstellen.
dn: dc=u-labs,dc=de
objectClass: dcObject
objectClass: organization
dc: u-labs
o: u-labs
dn: o=user,dc=u-labs,dc=de
objectClass: organization
o: userolcRootPW ist das Passwort eures Admin-Kontos. Den Hash kann man mit slappasswd generieren, in diesem Beispiel wurde „cnx“ verwendet. Auch das Suffix (dc=u-labs, dc=de) könnt ihr entsprechend eurer Domäne anpassen. Anschließend fügen wir die Änderungen zusammen mit ein paar Standard-Schematas ein:
[root@cnx65-db2 ~]# ldapmodify -Y EXTERNAL -H ldapi:/// -f ldap-base.ldiff
[root@cnx65-db2 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/cosine.ldif
[root@cnx65-db2 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/nis.ldif
[root@cnx65-db2 ~]# ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/schema/inetorgperson.ldif
[root@cnx65-db2 ~]# ldapadd -D "cn=admin,dc=u-labs,dc=de" -x -W -f dc.ldiffDer LDAP-Server ist damit bereit, enthält außer dem Administratorkonto aber noch keine Benutzer. Daher legen wir zumindest ein paar Testbenutzer an, mit denen man sich später an Connections anmelden kann:
dn: uid=ACapone,o=user,dc=u-labs,dc=de
changetype: add
givenName: Al
sn: Capone
telephoneNumber: 123456789
mail: ACapone@u-labs.de
facsimileTelephoneNumber: 987654321
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
uid: ACapone
cn: Al Capone
userPassword: cnx
dn: uid=mickeym,o=user,dc=u-labs,dc=de
changetype: add
givenName: Mickey
sn: Maus
telephoneNumber: 1234567890
mail: mickey@u-labs.de
facsimileTelephoneNumber: 987654321
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetorgperson
uid: mickeym
cn: Mickey Maus
userPassword: cnx[root@cnx65-db2 ~]# ldapadd -D "cn=admin,dc=u-labs,dc=de" -x -W -f users.ldiffEine Testabfrage mit ldapsearch sollte diese zwei Nutzer nun finden, wenn wir nach z.B. Personen suchen:
[root@cnx65-db2 ~]# ldapsearch -D "cn=admin,dc=u-labs,dc=de" -x -W -b "dc=u-labs,dc=de" "objectClass=person" cn
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <dc=u-labs,dc=de> with scope subtree
# filter: objectClass=person
# requesting: cn
#
# ACapone, user, u-labs.de
dn: uid=ACapone,o=user,dc=u-labs,dc=de
cn: Al Capone
# mickeym, user, u-labs.de
dn: uid=mickeym,o=user,dc=u-labs,dc=de
cn: Mickey Maus
# search result
search: 2
result: 0 Success
# numResponses: 3
# numEntries: 2DB2
DB2 bietet einen konsolenbasierten Assistenten (db2_install), der allerdings nur das absolute Minimum reduziert. Er legt keine Instanz an und startet diese auch nicht automatisch. Dies könnte man manuell ergänzend einrichten.
Alternativ kann db2_setup sowohl grafisch genutzt werden, oder über ein Response-File. Letzteres ist die praktikablere Lösung, da die grafische Variante teilweise Probleme mit sich bringt (z.B. nicht ausfüllbare Passwortfelder bei Verwendung von X-Forwarding). Das Response-File ist wie eine Konfigurationsdatei: Man gibt beispielsweise den Name der Instanz an. Anders als z.B. MySQL ist DB2 in Instanzen organisiert, in denen wiederum mehrere Datenbanken angelegt werden können. Bei vielen IBM-Programmen ist es gängig, die grafische Installation in ein Response-File aufzeichnen zu können.
Zunächst müssen folgende Abhängigkeiten installiert werden:
[root@cnx65-db2 ~]# yum install pam.i686 libaio compat-libstdc++-33.i686 libstdc++.i686 pam libaio compat-libstdc++-33 libstdc++ ksh cpp gcc gcc-c++ unzipAnschließend entpacken wir das Installationsarchiv (diese liegen bei mir immer in /opt/install):
[root@cnx65-db2 ~]# cd /opt/install/db2; mkdir extracted
[root@cnx65-db2 ~]# tar -xf v11.5.6_linuxx64_universal_fixpack.tar.gz -C extracted
[root@cnx65-db2 ~]# cd extracted/universalDas Response-File (db2.resp) mit folgendem Inhalt anlegen:
*-----------------------------------------------------
* Generated response file used by the DB2 Setup wizard
*-----------------------------------------------------
* Product Installation
LIC_AGREEMENT = ACCEPT
PROD = DB2_SERVER_EDITION
FILE = /opt/ibm/db2
INSTALL_TYPE = TYPICAL
*-----------------------------------------------
* Das properties
*-----------------------------------------------
DAS_CONTACT_LIST = LOCAL
* ----------------------------------------------
* Instance properties
* ----------------------------------------------
INSTANCE = inst1
inst1.TYPE = ese
* Instance-owning user
inst1.NAME = db2inst1
inst1.GROUP_NAME = db2inst1
inst1.HOME_DIRECTORY = /home/db2inst1
* plain: password
inst1.PASSWORD = cnx
inst1.AUTOSTART = YES
inst1.SVCENAME = db2c_db2inst1
inst1.PORT_NUMBER = 50000
inst1.FCM_PORT_NUMBER = 60000
inst1.MAX_LOGICAL_NODES = 6
inst1.CONFIGURE_TEXT_SEARCH = NO
* Fenced user
inst1.FENCED_USERNAME = db2fenc1
inst1.FENCED_GROUP_NAME = db2fadm1
inst1.FENCED_HOME_DIRECTORY = /home/db2fenc1
inst1.FENCED_PASSWORD = cnx
*-----------------------------------------------
* Installed Languages
*-----------------------------------------------
LANG = ENDies legt grundlegende Einstellungen wie Edition, Zielpfad etc. fest und erstellt eine automatisch gestartete Instanz namens db2inst1 und den Passwort cnx (entsprechend anpassen). Zusätzlich einen Fenced Benutzer. Er dient zur Ausführung von Prozeduren und soll die Sicherheit erhöhen. Gestartet wird die Installation mit db2setup und dem Schalter -r für Response-File:
[root@cnx65-db2 universal]# ./db2setup -r db2.respStandardmäßig haben wir damit eine Demo-Version installiert. Da DB2 über Connections lizenziert wird, kann man die Instanz mit der Lizenzdatei (ZIP) aus dem Flexnet aktivieren. Dafür zunächst das ZIP-Archiv entpacken:
[root@cnx65-db2 db2]# cd /opt/install/db2
[root@cnx65-db2 db2]# unzip DB2_ESE_AUSI_Activation_11.5.zipDB2 legt keine Benutzer im eigenen Rechtesystem an, sondern verwendet Betriebssystembenutzer. Am einfachsten ist es daher, zum beim installieren automatisch angelegten gleichnamigen Benutzer der Instanz zu wechseln. Mit db2licm -l kann die Lizenz geprüft werden, hier steht standardmäßig Trial nach einer frischen Installation:
[root@cnx65-db2 db2]# su - db2inst1
[db2inst1@cnx65-db2]$ db2licm -l | grep type
License type: "Trial"
[db2inst1@cnx65-db2]$ db2licm -a /opt/install/db2/ese_u/db2/license/db2ese_u.lic
LIC1402I License added successfully.
LIC1426I This product is now licensed for use as outlined in your License Agreement. USE OF THE PRODUCT CONSTITUTES ACCEPTANCE OF THE TERMS OF THE IBM LICENSE AGREEMENT, LOCATED IN THE FOLLOWING DIRECTORY: "/opt/ibm/db2/license/en_US.iso88591"
[db2inst1@cnx65-db2 ese_u]$ db2licm -l | grep type
License type: "Authorized User Single Install"Schlussendlich sollte noch Unicode aktiviert werden:
[db2inst1@cnx65-db2 Wizards]$ db2set DB2CODEPAGE=1208
[db2inst1@cnx65-db2 Wizards]$ db2stop force
06/10/2022 07:15:54 0 0 SQL1064N DB2STOP processing was successful.
SQL1064N DB2STOP processing was successful.
[db2inst1@cnx65-db2 Wizards]$ db2start
06/10/2022 07:16:00 0 0 SQL1063N DB2START processing was successful.
SQL1063N DB2START processing was successful.
[db2inst1@cnx65-db2 Wizards]$ db2set
DB2COMM=TCPIP
DB2CODEPAGE=1208
DB2AUTOSTART=YESUnd den lcuser für den Datenbankzugriff erstellen (mit root statt db2inst1 Benutzer):
[root@cnx65-db2 Wizards]# useradd -g db2inst1 lcuser
[root@cnx65-db2 Wizards]# echo "lcuser:cnx" | chpasswdTDI
Auch für den TDI legen wir wieder ein Response-File (tdi.resp) an. Der Pfad /opt/ibm/tdi/7.2 ist jeweils der anpassbare Installationspfad:
#Indicate whether the license agreement been accepted
#----------------------------------------------------
LICENSE_ACCEPTED=TRUE
#Choose Install Folder
#---------------------
USER_INSTALL_DIR=/opt/ibm/tdi/7.2
#Choose Install Set
#------------------
CHOSEN_FEATURE_LIST=JavaDocs,Examples,Server,CE,lwi,amc
CHOSEN_INSTALL_FEATURE_LIST=JavaDocs,Examples,Server,CE,lwi,amc
CHOSEN_INSTALL_SET=Typical
#Solutions Directory
#-------------------
TDI_SOLDIR_HOME=0
TDI_SOLDIR_INSTALL=0
TDI_SOLDIR_SELECT=0
TDI_SOLDIR_CWD=1
#Server Port Values
#------------------
TDI_SERVER_PORT=1099
TDI_SYSTEM_STORE_PORT=1527
TDI_REST_API_PORT=1098
TDI_MQE_SYSTEMQ_PORT=61616
#Register Server as Service
#--------------------------
TDI_REGISTER_SERVER=0
#Integrated Solutions Console Port Values
#----------------------------------------
TDI_HTTP_PORT=13100
TDI_HTTPS_PORT=13101
TDI_AM_API_PORT=13104
#AMC Service
#-----------
TDI_REGISTER_AMC=0
#Install
#-------
-fileOverwrite_/opt/ibm/tdi/7.2/maintenance/UpdateInstaller.jar=Yes
-fileOverwrite_/opt/ibm/tdi/7.2/TDI_LUM.zip=Yes
-fileOverwrite_/opt/ibm/tdi/7.2/_uninst/uninstaller.lax=YesEs folgt das Entpacken sowie die Installation mit dem Response-File:
[root@cnx65-db2 db2]# cd /opt/install/tdi; mkdir extracted
[root@cnx65-db2 tdi]# tar -xf CIS7TML.tar -C extracted
[root@cnx65-db2 tdi]# cd extracted/linux_x86_64
[root@cnx65-db2 extracted]# ./install_sdiv72_linux_x86_64.bin -f tdi.resp -i silentWebSphere
Abhängigkeiten
WebSphere benötigt folgende Abhängigkeiten:
[root@cnx65-was ~]# yum install gtk2 libXtst xorg-x11-fonts-Type1 psmiscFür die spätere Installation müssen wir den Installation Manager von IBM entpacken:
[root@cnx65-was install]# cd /opt/install/installation-manager/
[root@cnx65-was installation-manager]# unzip agent.installer.linux.gtk.x86_64_1.9.2002.20220323_1321.zip -d extracted
[root@cnx65-was installation-manager]# cd extractedZur Installation gibt es mehrere Möglichkeiten: installc -c startet den konsolenbasierten Assistenten. Dort kann man den Standard-Zielpfad (/opt/IBM/InstallationManager) ändern, wobei dies i.d.R. nicht notwendig ist. Daher kann man den Modus Silent Install verwenden. Hier genügt es, folgenden Befehl auszuführen:
[root@cnx65-was extracted]# ./install -acceptLicense --launcher.ini silent-install.ini
Installed com.ibm.cic.agent_1.9.2002.20220323_13215 to the /opt/IBM/InstallationManager/eclipse directory.Wer den IM deinstallieren möchte, findet das Skript dazu unter /var/ibm/InstallationManager/uninstall/uninstallc – dies kann direkt ausgeführt werden, ohne weitere Parameter.
WAS Installationsdateien
Entpackt werden diese mit ? als Platzhalter für den fortlaufenden Buchstabe, der als eine Art „Teildatei“ genutzt wird – allerdings anscheinend auf eigene Faust. Denn im Gegensatz zu anderen Archivformaten unterstützt ZIP keine nativen Teilarchive. Man muss daher alle Archive einzeln entpacken, dies lässt sich mit dem Platzhalter vereinfachen:
[root@cnx65-was was]# cd /opt/install/was/
[root@cnx65-was was]# unzip 'CIK2?ML.zip' -d extractedEben so wird mit dem Supplements Ordner verfahren, allerdings den Dateiname entsprechend anpassen:
[root@cnx65-was was]# cd supplements
[root@cnx65-was supplements]# unzip 'CIK1?ML.zip' -d extractedDamit ließe sich WebSphere bereits installieren, allerdings die Ursprungsversion 8.5.5.0 ohne Fixpack. Diese ist von 2013 und damit stark veraltet. Beispielsweise kommt man nicht auf die ISC, da die verwendeten kryptografischen Verfahrungen für TLS seit Jahren veraltet sind. Es macht daher Sinn, das aktuellste unterstützte Fixpack (für CNX 6.5 ist das FP 20) ebenfalls zu entpacken. Fixpacks gibt es für WebSphere selbst und die Erweiterungen im Supplements-Paket.
[root@cnx65-was ~]# cd /opt/install/was/fixpack/
[root@cnx65-was fixpack]# unzip '8.5.5-WS-WAS-FP020-part?.zip' -d was
[root@cnx65-was fixpack]# unzip '8.5.5-WS-WASSupplements-FP020-part?.zip' -d supplementsDie Installation selbst erfolgt über die Konsolenvariante des Installation Managers unter /opt/IBM/InstallationManager/eclipse/tools/imcl. Installationsdateien für den IM werden in Repositories abgelegt. Jeder soeben entpackte Ordner ist ein Repository, zu erkennen an der Datei repository.config im Wurzelverzeichnis. Mit dem Befehl listAvailablePackages können wir uns die Pakete auflisten lassen, die in einem (oder mehreren mit Komma getrennten) Pfaden zu Repositories verfügbar sind:
[root@cnx65-was ~]# /opt/IBM/InstallationManager/eclipse/tools/imcl listAvailablePackages -repositories /opt/install/was/extracted,/opt/install/was/supplements/extracted
com.ibm.websphere.ND.v85_8.5.5000.20130514_1044
com.ibm.websphere.APPCLIENT.v85_8.5.5000.20130514_1044
com.ibm.websphere.IHS.v85_8.5.5000.20130514_1044
com.ibm.websphere.PLG.v85_8.5.5000.20130514_1044
com.ibm.websphere.PLUGCLIENT.v85_8.5.5000.20130514_1044
com.ibm.websphere.WCT.v85_8.5.5000.20130514_1044Das erste Paket com.ibm.websphere.ND.v85_8.5.5000.20130514_1044 stammt aus dem WebSphere-Repository (/opt/install/was/extracted). Alle anderen aus dem Supplements-Repository (/opt/install/was/supplements/extracted), in denen der IBM HTTP Server (IHS) sowie das Plugin enthalten ist.
Installation WAS und dem Deployment Manager
Ebenfalls mit imcl kann man besagtes Paket installieren. Dafür reicht das erste Repository, da wir für WebSphere selbst das Supplements-Paket noch nicht benötigen. Allerdings macht es Sinn, den Pfad zum Fixpack-Repository mit anzugeben: Durch den Parameter -installFixes wird das Fixpack im Anschluss automatisch installiert, sodass wir kein händisches Update durchführen müssen. Die Buildnummer mit Zeitstempel aus dem Paketname (5000.20130514_1044) sind nicht nötig. Der letzte Parameter -showProgress zeigt eine Fortschrittsanzeige:
[root@cnx65-was ~]# /opt/IBM/InstallationManager/eclipse/tools/imcl install com.ibm.websphere.ND.v85 -repositories /opt/install/was/extracted,/opt/install/was/fixpack/was -acceptLicense -showProgress -installFixes recommended
25% 50% 75% 100%
------------------|------------------|------------------|------------------|
............................................................................
Installed com.ibm.websphere.ND.v85_8.5.5000.20130514_1044 to the /opt/IBM/WebSphere/AppServer directory.Das versionInfo.sh Skript sollte das entsprechende FP (hier 20, d.H. 8.5.5.20) anzeigen:
[root@cnx65-was fixpack]# /opt/IBM/WebSphere/AppServer/bin/versionInfo.sh
...
Name IBM WebSphere Application Server Network Deployment
Version 8.5.5.20
ID ND
Build Level cf202127.02
Build Date 7/8/21
Package com.ibm.websphere.ND.v85_8.5.5020.20210708_1826Zum Vergleich dazu die Installation der 8.5.5.0 ohne Fixpack (so sollte es nicht aussehen):
...
Installed Product
--------------------------------------------------------------------------------
Name IBM WebSphere Application Server Network Deployment
Version 8.5.5.0
ID ND
Build Level gm1319.01
Build Date 5/14/13
Package com.ibm.websphere.ND.v85_8.5.5000.20130514_1044Wir müssen im folgenden mindestens zwei Profile anlegen: Zunächst der Deployment Manager. Ein typischer Standardname ist Dmgr01, wobei dieser frei wählbar ist. Der Hostname wird mit dem eures WAS-Servers setzt. Die Admin-Zugangsdaten dienen für den späteren Zugriff auf die ISC.
[root@cnx65-was fixpack]# cd /opt/IBM/WebSphere/AppServer/bin
[root@cnx65-was bin]# ./manageprofiles.sh -create -profileName Dmgr01 -profilePath /opt/IBM/WebSphere/AppServer/profiles/Dmgr01 -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/management/ -cellName CnxCell -HostName cnx65-was.u-labs.de -enableAdminSecurity true -adminUserName wasadmin -adminPassword adminwas
INSTCONFSUCCESS: Success: Profile Dmgr01 now exists. Please consult /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/logs/AboutThisProfile.txt for more information about this profile.Im angegebenen Pfad sollte nun ein Profil namens Dmgr01 angelegt worden sein. Dies kann über startManager.sh im bin Ordner gestartet werden:
[root@cnx65-was bin]# cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/
[root@cnx65-was bin]# ./startManager.sh
...
ADMU3000I: Server dmgr open for e-business; process id is 8218Damit ist die ISC im Browser über https://cnx-host:9043/ibm/console erreichbar. Dort erscheint ein Zertifikatsfehler, da WAS standardmäßig ein selbst signiertes Zertifikat benutzt.
Über Erweitert kann man fortfahren und mit dem zuvor erstellten Admin-Konto (hier im Beispiel wasadmin:adminwas) sich anmelden:
Einrichtung des WAS-Nodes
Der Deployment Manager ist zur Verwaltung gedacht. Für die eigentlichen Anwendungen von Connections wird ein Node (CnxNode01) eingerichtet, in diesem Beispiel auf dem gleichen Server. Theoretisch könnte dieser aber auch auf einem anderen Host liegen.
[root@cnx65-was bin]# cd /opt/IBM/WebSphere/AppServer/bin
[root@cnx65-was bin]# ./manageprofiles.sh -create -profileName CnxNode01 -profilePath /opt/IBM/WebSphere/AppServer/profiles/CnxNode01 -templatePath /opt/IBM/WebSphere/AppServer/profileTemplates/managed -cellName CnxCell01 -HostName cnx65-was.u-labs.de -nodeName CnxNode01 -enableAdminSecurity true -adminUserName wasadmin -adminPassword adminwas
INSTCONFSUCCESS: Success: Profile CnxNode01 now exists. Please consult /opt/IBM/WebSphere/AppServer/profiles/CnxNode01/logs/AboutThisProfile.txt for more information about this profile.
Dieser neue Node CnxNode01 ist bisher allerdings nicht mit dem Deployment Manager verbunden. Um das zu ändern, wird addNode.sh ausgeführt. 127.0.0.1 ist die Adresse des Deployment Managers – hier localhost, da beide auf dem gleichen Server betrieben werden.
[root@cnx65-was bin]# ./addNode.sh 127.0.0.1 8879 -conntype SOAP -username wasadmin -password adminwas -profileName CnxNode01
ADMU0116I: Tool information is being logged in file
/opt/IBM/WebSphere/AppServer/profiles/CnxNode01/logs/addNode.log
ADMU0128I: Starting tool with the CnxNode01 profile
...
ADMU0300I: The node CnxNode01 was successfully added to the CnxCell cell.In der ISC taucht der Node nun auf:
Connections Datenbanken
Bevor Connections installiert (d.H. die Anwendungen auf WebSphere deployen) wird, müssen vorbereitend die Datenbanken angelegt werden. Dies geschieht auf dem Datenbankserver:
[root@cnx65-db2 install]# cd /opt/install
[root@cnx65-db2 install]# tar -xf HCL_Connections_6.5_wizards_lin_aix.tar
[root@cnx65-db2 install]# cd Wizards
[root@cnx65-db2 Wizards]# chmod +x dbWizard.sh jvm/linux/jre/bin/*
[root@cnx65-db2 Wizards]# chown db2inst1 . -R
[db2inst1@cnx65-db2 Wizards]$ cp samples/dbWizard_response.properties cnx-db.respIn samples/dbWizard_response.properties befindet sich eine Vorlage, aus der sich ein Response-File zur Installation erstellen lässt. Wichtig ist hier vor allem der Installationspfad zur Datenbank (dbHome), deren Administratorzugang (administrator/adminPassword) und der Pfad zur Java-Bibliothek, mit dem sich eine Verbindung zur DB2 herstellen lässt (jdbcLibPath). Aus lizenztechnischen Gründen befindet sich diese Bibliothek nicht im Lieferumfang von Connections. Auf Basis der Vorlage wird folgendes Response-File (cnx-db.resp) angelegt:
# *****************************************************************
#
# IBM Confidential
#
# OCO Source Materials
#
# Copyright IBM Corp. 2010, 2015
#
# The source code for this program is not published or otherwise
# divested of its trade secrets, irrespective of what has been
# deposited with the U.S. Copyright Office.
#
# *****************************************************************
###########################################################################
# The value can be: db2 | oracle | sqlserver
###########################################################################
dbtype=db2
###########################################################################
# The value is the instance name which your want to create your database.
###########################################################################
dbInstance=db2inst1
###########################################################################
# Specify the database installed location.
###########################################################################
dbHome=/opt/ibm/db2
###########################################################################
# The value can be: create | delete | upgrade
# create : create database.
# delete : delete database.
# upgrade: upgrade database.
###########################################################################
action=create
###########################################################################
# The feature you selected. Use "," to separate.
# The value can be: activities, blogs, communities, dogear, homepage,
# wikis, files, forum, profiles, mobile, metrics, cognos, library
# cognos and library cannot be listed in features when action=upgrade
###########################################################################
features=activities,blogs,communities,dogear,homepage,wikis,files,forum,profiles,mobile,metrics,cognos,library
###########################################################################
# Database server port used for JDBC invocation
# DB2 default is 50000
# Oracle default is 1521
# SQLServer default is 1433
###########################################################################
port=50000
###########################################################################
# Database administrator account used for JDBC invocation
# DB2 default on Windows is db2admin, on Linux/AIX is db2inst1
# Oracle default is system
# SQLServer default is sa
###########################################################################
administrator=db2inst1
###########################################################################
# Database administror password used for JDBC invocation
###########################################################################
adminPassword=cnx
###########################################################################
# JDBC library path used for JDBC invocation on SQLServer only
###########################################################################
jdbcLibPath=/opt/ibm/db2/java/db2jcc4.jar
###########################################################################
# Password is Only needed for oracle and sqlserver when creating or updating database. The password will be removed
# after finishing task for the reponse file "response\dbWizard\response.properties".
###########################################################################
homepage.password=
activities.password=
blogs.password=
dogear.password=
communities.password=
profiles.password=
wikis.password=
files.password=
forum.password=
mobile.password=
metrics.password=
cognos.password=
library.password=
pushnotification.password=
###########################################################################
# file path is only needed for sqlserver when creating or updating database, it is the
# directory where user want to store the database files.
###########################################################################
profiles.filepath=C\:\\yourPath
blogs.filepath=
dogear.filepath=
communities.filepath=
homepage.filepath=
activities.filepath=
wikis.filepath=
files.filepath=
forum.filepath=
mobile.filepath=
metrics.filepath=
cognos.filepath=
library.filepath=
pushnotification.filepath=
###########################################################################
# The value can be:
# For db2:9.7 or 10.0
# For Oracle: 10 or 11
# For sqlserver: 9.0 or 10.0
###########################################################################
dbVersion=11.5
Um damit die Installation zu starten, dbWizard.sh aufrufen:
[db2inst1@cnx65-db2 Wizards]$ ./dbWizard.sh -silent cnx-db.resp
Start the task in silent mode.
Response file is set to cnx-db.resp.
Create IBM Connections database
...Das Anlegen und Einrichten der Datenbanken dauert mindestens etwa 20 Minuten, je nach verwendeter Hardware auch länger. Am Ende sollte bei jeder Datenbank The database creation was successful in der Ausgabe stehen.
Connections TDI Konfiguration
# ToDo: Wird im GUI Assistenten des TDI abgefragt - pruefen, ob dieser Schritt per CLI notwendig ist
[root@cnx65-db2 db2]# tar -xf v11.1.4fp7_jdbc_sqlj.tar.gz
[root@cnx65-db2 jdbc_sqlj]# unzip db2_db2driver_for_jdbc_sqlj.zip
[root@cnx65-db2 jdbc_sqlj]# cp db2jcc.jar /opt/ibm/db2/java/Hierfür werden Konfigurationsdateien aus der tdisol.tar benötigt, die sich wiederum im Installationsarchiv von Connections (HCL_Connections_6.5_lin.tar) befindet. Wir entpachen dieses Archiv daher auf dem WAS-Server, da wir die anderen Dateien dort später ebenfalls benötigen. Mit rsync lässt sich die tdisol.tar nach /opt/install auf dem zweiten Server (DB2) hochladen.
[root@cnx65-was ~]# cd /opt/install/cnx
[root@cnx65-was cnx]# tar -xf HCL_Connections_6.5_lin.tar
[root@cnx65-was cnx]# rsync -azP HCL_Connections_Install/tools/tdisol.tar cnx65-db2.u-labs.de:/opt/install/Anschließend das Archiv entpacken und in den Basisodner des TDI unterhalb von /opt verschieben:
[root@cnx65-db2 install]# tar -xf tdisol.tar
[root@cnx65-db2 install]# mv TDI /opt/ibm/tdi/tdisol
[root@cnx65-db2 install]# cd /opt/ibm/tdi/tdisolIn der Datei tdienv.sh befindet sich ein Fehler: Sie referenziert standardmäßig noch auf die Vorversion 7.1.1, obwohl wir 7.2 nutzen. Daher muss man folgenden Pfad von Hand korrigieren:
export TDIPATH=/opt/IBM/TDI/V7.1.1Es folgt die grundlegende Konfiguration des TDI in profiles_tdi.properties:
source_ldap_url=ldap://localhost:389
source_ldap_search_base=o=user,dc=u-labs,dc=de
source_ldap_search_filter=(objectClass=person)
source_ldap_user_login=cn=admin,dc=u-labs,dc=de
{protect}-source_ldap_user_password=cnx
dbrepos_jdbc_url=jdbc:db2://localhost:50000/peopledb
dbrepos_jdbc_driver=com.ibm.db2.jcc.DB2Driver
dbrepos_username=db2inst1
{protect}-dbrepos_password=cnxDas genügt als Basis für ein Testsystem – jeder LDAP-Benutzer in der user Organisation wird dadurch in die Benutzerdatenbank synchronisiert. Der TDI kann aber noch deutlich mehr, wie teils auch an den weiteren Beispielen deutlich wird. Nachdem wir alle Skripte ausführbar gemacht haben, eignet sich das collect_dns.sh Skript für einen ersten Testlauf: Es sammelt alle Nutzer die auf den Filter zutreffend ein und schreibt sie in collect.dns. Dabei findet noch keine Synchronisation statt – somit testen wir vorerst nur die LDAP-Konfiguration und Verbindung. Entsprechend der Anzahl an (Test-) Benutzern auf dem LDAP-Server sollte diese Nutzer vorhanden sein, hier zwei:
[root@cnx65-db2 tdisol]# chmod +x *.sh netstore
[root@cnx65-db2 tdisol]# ./collect_dns.sh
CLFRN1280I: 20220610104053 Iterations total number: 2.
[root@cnx65-db2 tdisol]# cat collect.dns
uid=ACapone,o=user,dc=u-labs,dc=de
uid=mickeym,o=user,dc=u-labs,dc=deDer nächste Schritt ist eine vollständige Synchronisation. Hierfür muss noch das Id-Attribut in der Datei map_dbrepos_from_source.properties angepasst werden, da die Standardkonfiguration von Domino ausgeht:
guid=uid
# Statt
#guid=ibm-entryUuidWird nun die Synchronisation mit sync_all_dns.sh gestartet, holt sich der TDI die Benutzer aus dem LDAP und gleicht sie mit den Connections-Benutzern ab. Da alle Benutzer neu sind, sollten sie als hinzugefügt/modifiziert vermerkt werden:
[root@cnx65-db2 tdisol]# ./sync_all_dns.sh
...
CLFRN0037I: After synchronization, added or modified records is 2, deleted or inactivated records is 0, unchanged records 0, and failure records is 0.Connections-Anwendungen installieren
Connections selbst besteht aus mehreren Anwendungen, die auf verschiedenen Anwendungsservern (JVMs) installiert werden.
[root@cnx65-was cnx]# mkdir -p /opt/IBM/DB2/java
[root@cnx65-was cnx]# rsync -azP cnx65-db2.u-labs.de:/opt/ibm/db2/java/ /opt/IBM/DB2/javaDas Passwort des WebSphere Administratorkontos (wasadmin) darf nicht im Klartext übergeben werden. Man muss es zunächst mit imutilsc verschlüsseln. Im folgenden Beispiel geschieht dies mit unserem Beispiel-Kennwort adminwas:
[root@cnx65-was cnx]# /opt/IBM/InstallationManager/eclipse/tools/imutilsc encryptString adminwas -silent -noSplash
hyDz8CktIliBlf7Vfsj+kg==Als Grundlage für das Response-File dient HCL_Connections_Install/IM/LC.rsp. Da dies etwas unübersichtlich ist und man verschiedene Dinge mehrfach angeben muss, habe ich es etwas überarbeitet. Alle Dinge die ihr ggf. an eure Umgebung anpassen müsst, befinden sich oben in Variablen.
[root@cnx65-was cnx]# /opt/IBM/InstallationManager/eclipse/tools/imcl -input /opt/install/cnx/cnx.resp -log /var/log/cnx-install.log -acceptLicense
Installed com.ibm.connections_6.5.0.0_20191121_2323 to the /opt/HCL/Connections directory.IBM HTTP Server installieren
Insgesamt müssen drei IBM-Pakete installiert werden: IHS für den IBM HTTP Server, PLG enthält das IHS-Plugin für die Kommunikation mit WebSphere und die Toolbox (WCT) stellt Werkzeuge zur Konfiguration des Plugins bereit.
[root@cnx65-was cnx]# /opt/IBM/InstallationManager/eclipse/tools/imcl install com.ibm.websphere.IHS.v85 -repositories /opt/install/was/supplements/extracted,/opt/install/was/fixpack/supplements -acceptLicense -showProgress -installFixes recommended -properties "user.ihs.httpPort=80"
com.ibm.websphere.IHS.v85_8.5.5020.20210708_1826 wird in das Verzeichnis /opt/IBM/HTTPServer installiert.
[root@cnx65-was cnx]# /opt/IBM/InstallationManager/eclipse/tools/imcl install com.ibm.websphere.PLG.v85 -repositories /opt/install/was/supplements/extracted,/opt/install/was/fixpack/supplements -acceptLicense -showProgress -installFixes recommended
com.ibm.websphere.PLG.v85_8.5.5020.20210708_1826 wird in das Verzeichnis /opt/IBM/WebSphere/Plugins installiert.
[root@cnx65-was cnx]# /opt/IBM/InstallationManager/eclipse/tools/imcl install com.ibm.websphere.WCT.v85 -repositories /opt/install/was/supplements/extracted,/opt/install/was/fixpack/supplements -acceptLicense -showProgress -installFixes recommended
com.ibm.websphere.WCT.v85_8.5.5000.20130514_1044 wird in das Verzeichnis /opt/IBM/WebSphere/Toolbox installiert.Zwei Abhängigkeiten sind für WCT nötig:
[root@cnx65-was cnx]# yum install glibc.i686 libgcc.i686Nach der Installation wechseln wir zum IBM HTTP Server (IHS), um eine neue Schlüsseldatenbank zu erzeugen. Im Gegensatz zu Apache und anderen Webservern wird im IHS ein SSL-Modul von IBM verwendet. Dies erhält nicht direkt Zertifikat mit dem dazugehörigen privaten Schlüssel, sondern speichert beide in einer Schlüsseldatenbank. Für die Testumgebung wird eine neue Datenbank zusammen mit einem selbst signierten Zertifikat angelegt:
[root@cnx65-was cnx]# cd /opt/IBM/HTTPServer/bin
[root@cnx65-was cnx]# ./gskcapicmd -keydb -create -db /opt/IBM/HTTPServer/conf/key.db -pw cnx -stash
[root@cnx65-was cnx]# ./gskcmd -cert -create -db /opt/IBM/HTTPServer/conf/key.db -stashed -size 2048 -dn CN=cnx65-was.u-labs.de,OU=tests,C=DE -label cnx65-was.u-labs.de -default_cert yes -sig_alg SHA512WithRSA -expire 365 -ca trueStandardmäßig ist SSL im IHS deaktiviert. In der httpd.conf muss SSL daher mit dem dazugehörigen IBM-Modul aktiviert werden. Außerdem ist ein Verweis auf die soeben erstellte Datenbank nötig. An dieser Stelle kümmere ich mich auch immer gleich um die Weiterleitung, da standardmäßig der IHS beim Aufruf des Wurzel-Verzeichnis (also https://hostname.de ohne Pfad) eine Willkommensseite anzeigt. Durch die Umleitung auf /homepage erscheint stattdessen die Connections Startseite.
[root@cnx65-was cnx]# cd ../conf
[root@cnx65-was cnx]# vim httpd.conf
# Ans Ende Einfuegen
LoadModule ibm_ssl_module modules/mod_ibm_ssl.so
Listen 443
<VirtualHost *:443>
SSLEnable
RedirectMatch "^/$" "/homepage"
</VirtualHost>
KeyFile /opt/IBM/HTTPServer/conf/key.db
SSLDisable
[root@cnx65-was cnx]# ../bin/apachectl -k startAls Vorbereitung zur Verknüpfung des IHS mit WAS wird folgendes Response-File (plugin.resp) benötigt:
# https://www.ibm.com/support/knowledgecenter/SSEQTP_9.0.5/com.ibm.websphere.base.doc/ae/tins_pctcl_using.html
configType=remote
enableAdminServerSupport=true
enableUserAndPass=true
enableWinService=false
ihsAdminCreateUserAndGroup=true
ihsAdminUserID=ihsadmin
ihsAdminPassword=adminihs
ihsAdminPort=8008
ihsAdminUnixUserGroup=ihsadmin
ihsAdminUnixUserID=ihsadmin
mapWebServerToApplications=true
wasMachineHostname=cnx65-was.u-labs.de
webServerConfigFile1=/opt/IBM/HTTPServer/conf/httpd.conf
webServerDefinition=webserver1
webServerHostName=cnx65-was.u-labs.de
webServerOS=Linux
webServerPortNumber=80
# Lower seems required for proper parsing, see https://stackoverflow.com/a/60608447/3276634 - seems not having a diference, but matching the specs is always better
webServerSelected=ihs
webServerType=IHS[root@cnx65-was cnx]# cd /opt/IBM/WebSphere/Toolbox/WCT
[root@cnx65-was cnx]# ./wctcmd.sh -tool pct -createDefinition -defLocPathname /opt/IBM/WebSphere/Plugins -response plugin.resp -defLocName webserver1
...
Das Tool wurde erfolgreich ausgeführt.In meinem Ansible-Projekt kam es gelegentlich vor, dass die Admin-Konfiguration nicht sauber erstellt wurde. Um dies zu prüfen, in dessen Konfiguration nach dem Platzhalter @@AdminPort@@ suchen. Hat alles funktioniert, gibt es keine Treffer (leere Ausgabe):
[root@cnx65-was cnx]# grep @@AdminPort@@ /opt/IBM/HTTPServer/conf/admin.conf
Hinzufügen des Webservers in der ISC
System administration > Nodes > Add Node > Unmanaged node, dann OK.
Servers > Server Types > Web Servers > New, hier verwenden wir den zuvor bereits genutzten Name webserver1:
Template IHS. In Schritt 3 den zuvor angelegten Administrationsbenutzer (hier ihsadmin/adminihs) angeben
Mit Next und Finish abschließen und oben in den Nachrichten auf Save.
Zertifikat vertrauen und Plugin generieren
Da wir für die Testumgebung ein selbst signiertes Zertifikat verwenden, muss WebSphere diesem vertrauen. Dies ist wichtig, weil auch interne Kommunikation (z.B. API-Abfrage für Profildaten) stattfindet. Unter Servers > Server Types > Web servers > webserver1 > Additional Properties > Plugin-properties > Manage keys and certificates (1)> Additional Properties > Signer certificates oben auf Retrieve from port klicken und den Hostname/Port des IHS zusammen mit einem frei wählbaren Alias angeben. Mit Retrive signer information wird das Zertifikat direkt vom IHS geladen.
Um es zu speichern, unten auf OK und oben auf Save.
Danach noch mal auf Servers > Server Types > Web servers > webserver1 > Additional Properties > Plugin-properties und Copy to Web server key store directory (2).
Die Plugin-Konfiguration sollte dadurch bereits automatisch neu generiert und propagiert (auf den Server übertragen) werden:
Falls es dabei zu Problemen kommt: Auf der Webserver Übersichtsseite (Servers > Server Types > Web servers) den zuvor angelegten Server webserver1 anhaken, dann oben auf Generate Plug-in sowie anschließend Propagate Plug-in. Dann wird die Konfiguration händisch neu generiert und transferiert.
Connections URL anpassen
Wie zuvor bereits erwähnt, führt CNX selbst auch interne HTTP-Abfragen durch. Dafür kommt die in der LotusConnections-config.xml angegebene Basis-URL zum Einsatz. Diese kann man mit z.B. sed relativ leicht durch die eigene ersetzen:
[root@cnx65-was cnx]# cd /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/config/cells/CnxCell/LotusConnections-config/
[root@cnx65-was cnx]# sed -i -E 's#(href=")[^"]+"#\1http://cnx65-was.u-labs.de"#' LotusConnections-config.xml
[root@cnx65-was cnx]# sed -i -E 's#(ssl_href=")[^"]+"#\1https://cnx65-was.u-labs.de"#' LotusConnections-config.xml
[root@cnx65-was cnx]# sed -E -i 's#(interService href=")[^"]+"#\1https://cnx65-was.u-labs.de"#' LotusConnections-config.xmlSinnvoll ist außerdem, SSL zu erzwingen. Dazu setzt man in der gleichen Datei
<forceConfidentialCommunications enabled="true"/ >Cookie-Domain und LDAP-Repository in WebSphere
Unter Security > Global security > Single sign-on (SSO) in die Textbox Domain name den IHS Hostname eintragen. Alternativ kann auch die gesamte TDL mit einem vorangestellten Punkt (z.B. „.u-labs.de“ genutzt werden. Weiter unten den Haken Set security cookies to HTTPOnly to prevent cross-site scripting attacks entfernen und mit OK bestätigen:
Zum Abschluss der WebSphere-Konfiguration wird unser LDAP-Server unter Security > Global security hinzugefügt. Dazu im unteren Bereich User account repository auf Configure klicken:
- Ist der Typ des LDAP-Servers. Im Falle von OpenLDAP wird Custom verwendet. Soll ein bereits vorhandener Verzeichnisdienst zum Einsatz kommen, den Typ entsprechend anpassen (z.B. auf IBM Lotus Domino, hier wäre der DN der Base später dann „root“ – oder Microsoft Windows Active Directory).
- Host und rechts daneben den Port des LDAP-Servers. In dieser Installation läuft OpenLDAP auf dem zweiten Server zusammen mit der DB2.
- DN und Zugangsdaten eines LDAP-Benutzers, der mindestens Lesebrechtung benötigt.
- Die hier angegebenen Attribute (mehrere mit Strichpunkt; trennen) können von den Nutzern als Anmeldename verwendet werden. Mit uid;mail kann man etwa die Nutzer-Id (z.B. mickeym) oder E-Mail Adresse des Kontos in das Nutzername-Feld eintragen. Der Login funktioniert in beiden Fällen.
Nach dem Bestätigen erscheint die vorherige Seite, welche die Suchbasis des LDAP-Verzeichnisses abfragt. Ich lege meist die O/OU fest, in der die Benutzer liegen (rechts). Gerade in kleineren Umgebungen kann man auch einfach die gesamte Domäne angeben (links).
Nach einem Klick auf OK sollte in der Liste das soeben angelegte Repository LDAP1 mit dazugehöriger Suchbasis (links) erscheinen. Damit ist die LDAP-Einrichtung abgeschlossen, mit Save im oberen Kasten wird die Konfiguration auf dem Deployment Manager gespeichert.
Um die vorherigen Änderungen auf die Knoten (CnxNode01 in dieser Umgebung) zu verteilen, in der ISC auf System Administration > Nodes, dort CnxNode01 anhaken und oben Full Resynchronize.
Da Änderungen an der LDAP-Konfiguration erst nach einem Neustart des Deployment Managers greifen, stoppen und starten wir diesen:
[root@cnx65-was cnx]# /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/stopManager.sh -username wasadmin -password adminwas
[root@cnx65-was cnx]# /opt/IBM/WebSphere/AppServer/profiles/Dmgr01/bin/startManager.shBei dessen Start werden die Benutzer aus dem LDAP-Verzeichnis in WebSphere geladen. Wenn die Synchronisierung funktioniert hat, sollten die LDAP-Benutzer in der ISC unter Users and Groupe > Manage Users erscheinen:
Erster Start und Test
Vor dem ersten Test starten wir die AppServer in der ISC unter Servers > Server Types > WebSphere application servers. Dazu oben auf Select All und Start:
Nach einigen Minuten sollten alle gestartet sein und der Status auf grün stehen. Die Anzeige rechts wird nicht automatisch aktualisiert. Man kann entweder neben Status auf die Pfeile klicken, oder mit der Maus über die Symbole fahren, um den aktuellen Status abzurufen.
Da wir zuvor die Konfiguration des IHS-Plugins verändert haben, benötigt dieser ebenfalls einen Neustart.
Wichtig: Das apachectl-Kommando ist asynchron! Es sendet ein Signal zum beenden an den IHS, wartet darauf allerdings nicht. Daher ist der Befehl schnell ausgeführt und der IHS läuft danach ggf. noch einige Sekunden weiter. Man sollte daher den Stop-Befehl absetzen, einige Sekunden warten und ihn erneut (Pfeil nach oben Taste) ausführen. Erscheint hier der httpd not running Fehler, ist der IHS beendet. Andernfalls erneut einige Sekunden warten, bis man den Stop-Befehl erneut absetzt.
[root@cnx65-was cnx]# cd /opt/IBM/HTTPServer/bin
[root@cnx65-was cnx]# ./apachectl -k stop
[root@cnx65-was cnx]# ./apachectl -k stop
httpd (no pid file) not running
[root@cnx65-was cnx]#./apachectl -k startNun sollte Connections im Browser per HTTPS erreichbar sein. Da wir ein selbst signiertes Zertifikat verwenden, erscheint eine Warnmeldung. Im Firefox kann über Advanced/Erweitert und Accept the Risk and Continue/Risiko akzeptieren und fortfahren die Seite aufrufen. Sollte man natürlich nur bei selbst angelegten Testumgebungen machen, niemals bei öffentlichen/fremden Internetseiten.
Die erste Anfrage benötigt ein paar Sekunden, bis die Connections Loginseite erscheint. Dort sollte sich jeder LDAP-Nutzer anmelden können. Bei neuen Benutzern ist ein Sync über den TDI nötig, die anfangs angelegten Testbenutzer sind bereits angelegt (z.B. Mickey Mouse). Zur Anmeldung kann die Nutzer-Id (mickeym) verwendet werden, oder alternativ die E-Mail Adresse.
Dienste und Autostart
Die Komponenten WAS Deployment-Manager, Node & IBM HTTP Server sollten als Systemd-Units automatisch gestartet werden. Der TDI per Cron regelmäßig ausgeführt. Doch das genügt nicht: Selbst wenn der WebSphere-Node läuft, startet dieser nicht automatisch auch die AppServer von CNX. Dies muss händisch in dessen Policy gesetzt werden.
AppServer automatisch starten
In der ISC unter Servers > Server Types > WebSphere application servers auf jeden Server klicken, rechts Java and Process Management > Monitoring policy und Node restart state auf RUNNING stellen:
Weiteres
- Für Surveys (Umfragen) muss Edge-side-includes (ESI) in WebSphere deaktiviert werden
- Node hinzufügen, wenn man einen Cluster aus mehreren Servern erstellen möchte
- Dokumentation zur Erstellung der Datenbanken (mit Fix zur manuellen Erstellung von Community Highlights/ICEC, da diese nicht automatisch vom Wizard angelegt werden)
- Connections Testinstallation von Christoph Stöttner (ist eine ältere Präsentation aus 2011, einiges v.a. grundlegendes ist nach wie vor relevant, wenn auch der Stack natürlich veraltet ist)