{"id":9057,"date":"2022-06-25T16:06:00","date_gmt":"2022-06-25T15:06:00","guid":{"rendered":"https:\/\/u-labs.de\/portal\/?p=9057"},"modified":"2025-12-06T16:17:49","modified_gmt":"2025-12-06T15:17:49","slug":"hcl-cnx-6-5-manuell","status":"publish","type":"post","link":"https:\/\/u-labs.de\/portal\/hcl-cnx-6-5-manuell\/","title":{"rendered":"HCL Connections 6.5 Installation: Der harte Weg"},"content":{"rendered":"

Eine minimale HCL Connections (CNX) 6.5 Testinstallation ist das Ziel dieses Beitrags. Und zwar bewusst manuell, um ein Verst\u00e4ndnis f\u00fcr 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.<\/p>\n

Gerade zu Beginn empfiehlt sich der harte Weg<\/em>. Er ist zwar aufw\u00e4ndiger und kostet mehr Nerven. Doch was n\u00fctzt 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\u00e4nzende Funktionen wie den Customizer, die sich auf anderem Wege realisieren lassen (z.B. JSP-Anpassungen).<\/p>\n

Hinweis<\/strong>: HCL Connections 6.5 hat sein Lebensende erreicht. Zum Stand 2025 ist mindestens Version 7, besser 8 zu empfehlen. Im Wesentlichen k\u00f6nnen die Schritte f\u00fcr CNX 6.5 angepasst (Versionsnummern in Dateinamen usw) verwendet werden. Die Installation unterscheidet sich nur im Detail.<\/p>\n

Ben\u00f6tigte Komponenten<\/h2>\n

Als Grundlage dienen die Systemanforderungen f\u00fc<\/a>r<\/a> die jeweilige Version von Connections, in diesem Beispiel ist das 6.5 CR1<\/a>. Alles hier beschriebene l\u00e4sst sich \u00e4hnlich mit den Nachfolgeversionen umsetzen. <\/p>\n

CentOS als Betriebssystem<\/h3>\n

Da Connections RHEL unterst\u00fctzt, 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\u00e4ndert: Aus der stabilen Distribution ist eine Rolling Release Version geworden. Daher w\u00fcrde ich zu Alma Linux oder Rocky Linux wechseln, die den urspr\u00fcnglichen Weg als stabile RHEL Bin\u00e4rkompatible Version beibehalten haben. Allerdings ist Connections 6.5 derzeit noch nicht mit RHEL 8 kompatibel, hierf\u00fcr m\u00fcsste man Connections 7 oder neuer verwenden.<\/p>\n

Wichtig ist zudem ein funktionierendes DNS: Jeder Server sollte einen aufl\u00f6sbaren FQDN besitzen.<\/p>\n

Datenbank<\/h3>\n

Connections unterst\u00fctzt nur propriet\u00e4re Datenbanken: MSSQL, IBM DB2 und Oracle. Eine DB2-Lizenz ist in Connections inklusive, daher verwenden wir dies im Folgenden.<\/p>\n

LDAP-Server<\/h3>\n

Connections bietet keine eigene Nutzerverwaltung. Man ben\u00f6tigt einen Verzeichnisdienst, aus dem die Benutzer (ggf. anhand bestimmter Kriterien) mittels TDI synchronisiert werden. In der Praxis d\u00fcrfte ohnehin in den meisten Unternehmen bereits ein Active Directory oder anderer Verzeichnisdienst existieren, sodass es sich anbietet, diesen zu verwenden. <\/p>\n

In dieser Testinstallation werden wir OpenLDAP <\/strong>nutzen, einen der verbreitetsten Verzeichnisdienste unter Linux.<\/p>\n

TDI<\/h3>\n

Der IBM Tivoli Directory Integrator<\/strong> (kurz TDI<\/strong>) wird periodisch unseren Verzeichnisdienst mit der Connections-Datenbank abgleichen. Man kann alle Benutzer synchronisieren oder anhand bestimmter Kriterien (z.B. LDAP-Gruppe) filtern. <\/p>\n

WebSphere Anwendungsserver<\/h3>\n

Der WebSphere Application Server<\/em> wird genutzt, um die Java-Anwendungen von Connections zu betreiben. Auch dieses Software ist propriet\u00e4r und wird \u00fcber HCL von IBM lizenziert. Im Gegensatz zu kleineren<\/em> Anwendungsservern wie z.B. Tomcat ist WebSphere auf gr\u00f6\u00dfere Cluster ausgelegt. Es gibt daher grunds\u00e4tzlich einen Deployment Manager, der als die Nodes verwaltet, auf denen die Anwendungen laufen. Man muss WebSphere nicht zwingend clustern, wenn dies nicht ben\u00f6tigt wird.<\/p>\n

IBM HTTP Server<\/h3>\n

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 \u00fcbernimmt die Lastverteilung, ist allerdings kein vollwertiger Apache Webserver. So stehen beispielsweise nicht alle Module zur Verf\u00fcgung.<\/p>\n

Nginx mit Let’s Encrypt<\/h3>\n

Nginx ist ein schlanker Reverse Proxy, womit wir die automatisierten und kostenfreien Zertifikate von Let’s Encrypt nutzen k\u00f6nnen. Die Apache-Integration ist nicht mit dem IBM HTTP Server kompatibel. Der Nginx ist nicht zwingend n\u00f6tig, allerdings sollte SSL eingesetzt werden. Wer etwa eine eine eigene CA im Unternehmensumfeld besitzt, der kann entsprechend selbst ein Zertifikat erstellen, signieren und es \u00fcber ikeyman im IHS Store hinterlegen.<\/p>\n

Vorbereitung<\/h2>\n

Vorbereiten der Server<\/h3>\n

Zun\u00e4chst aktualisieren wir die Paketquellen und Pakete auf beiden Servern (als root):<\/p>\n

yum update<\/code><\/pre>\n
F\u00fcr den Einstieg und die erste Testinstallation w\u00fcrde ich die grafischen Installationsassistenten verwenden, da diese einen durch die Einrichtung leiten. Zwar stehen auch Konsolenwerkzeuge zur Verf\u00fcgung, wie dies unter Linux \u00fcblich ist. Allerdings ist dies f\u00fcr den Einstieg aufgrund der Komplexit\u00e4t in meinen Augen nicht optimal. Teils ben\u00f6tigt man zumindest einmalig die grafischen Werkzeuge, um die notwendigen Konfigurationsdateien zu erstellen.<\/p>\n
Damit keine vollst\u00e4ndige Desktopumgebung installiert werden muss, kann man mit X11-Forwarding arbeiten<\/a>.<\/p>\n
yum install xorg-x11-server-Xorg xorg-x11-xauth xorg-x11-apps<\/code><\/pre>\n
In \/etc\/ssh\/sshd_config<\/strong> muss zudem X11Forwarding yes<\/strong> und X11UseLocalhost No gesetzt sein. Bei CentOS 7 ist dies standardm\u00e4\u00dfig der Fall, f\u00fcr \u00c4nderungen ist ein Neustart des SSH-Daemon (systemctl restart sshd<\/strong>) notwendig.<\/p>\n
Beim Kommandozeilen-Client aktiviert man X11-Forwarding mit dem Schalter -X<\/p>\n
ssh -X user@cnx-server<\/code><\/pre>\n
Wer einen anderen, grafischen Client nutzt, muss in den Einstellungen der Verbindung schauen. Bei MobaXterm<\/a> kann man etwa im SSH-Reiter den Haken X11-Forwarding<\/strong> setzen:<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
CentOS bringt standardm\u00e4\u00dfig SELinux mit. Da dies von Connections nicht unterst\u00fctzt wird, m\u00fcssen wir es deaktivieren und anschlie\u00dfend neu starten:<\/p>\n
sed -i 's\/SELINUX=permissive\/SELINUX=disabled\/g' \/etc\/selinux\/config\nreboot<\/code><\/pre>\n
Achtung<\/strong>: Wer dennoch eine grafische Oberfl\u00e4che verwendet (etwa bei lokalen VMs), installiert durch die Gruppe etwa Firewalld mit. dies muss eben so deaktiviert werden wie SELinux (nicht von CNX unterst\u00fctzt):<\/p>\n
systemctl disable --now firewalld<\/code><\/pre>\n
F\u00fcr Connections und DB2 m\u00fcssen entsprechend den Anforderungen noch ein paar Limits in der Datei \/etc\/security\/limits.conf<\/strong> erh\u00f6ht werden:<\/p>\n
* - nproc 16384\n* - nofile 65536\n* - stack 10240<\/code><\/pre>\n
Wir setzen dies auf beiden Servern f\u00fcr jeden Benutzer. Produktiv w\u00fcrde man dies auf die entsprechenden Nutzer von WebSphere <\/a>(auch f\u00fcr Connections<\/a>) und DB2 (Instanz-Eigent\u00fcmer) einschr\u00e4nken. Damit dies wirksam wird, die SSH-Sitzung schlie\u00dfen (exit) sowie neu \u00f6ffnen.<\/p>\n
Wenn IPv6 nicht genutzt\/ben\u00f6tigt wird, kann man es durch das setzen folgender zwei Zeilen in der Datei \/etc\/sysctl.conf<\/strong> deaktivieren:<\/p>\n
net.ipv6.conf.all.disable_ipv6 = 1\nnet.ipv6.conf.default.disable_ipv6 = 1<\/code><\/pre>\n
Danach 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<\/strong> AddressFamily inet<\/strong> gesetzt sein (statt any).<\/p>\n
Download der Installationsdateien<\/h3>\n
Mittlerweile finden sich die meisten Installationsdateien in der HCL Connections Gruppe des Flexnet<\/a>. Aktualisierungen (wie z.B. CR1 f\u00fcr 6.5) finden sich in der Connections CR Gruppe<\/a>. Da manche Dateien wenig sprechend benannt sind, w\u00fcrde ich diese zur besseren \u00dcbersicht in folgender Ordnerstruktur organisieren:<\/p>\n
[root@cnx65-was ~]# tree \/opt\/install\n\/opt\/install\n\u251c\u2500\u2500 cnx\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 HCL_Connections_6.5_lin.tar\n\u251c\u2500\u2500 installation-manager\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 agent.installer.linux.gtk.x86_64_1.8.5000.20160506_1125.zip\n\u251c\u2500\u2500 HCL_Connections_6.5_lin.tar\n\u251c\u2500\u2500 lost+found\n\u2514\u2500\u2500 was\n    \u251c\u2500\u2500 CIK2HML.zip\n    \u251c\u2500\u2500 CIK2IML.zip\n    \u251c\u2500\u2500 CIK2JML.zip\n    \u2514\u2500\u2500 supplements\n        \u251c\u2500\u2500 CIK1VML.zip\n        \u251c\u2500\u2500 CIK1WML.zip\n        \u2514\u2500\u2500 CIK1XML.zip\n\n[root@cnx65-db2 ~]# tree \/opt\/install\/\n\/opt\/install\/\n\u2514\u2500\u2500 db2\n\u2502\u00a0\u00a0 \u251c\u2500\u2500 DB2_ESE_AUSI_Activation_11.5.zip\n\u2502\u00a0\u00a0 \u2514\u2500\u2500 v11.5.6_linuxx64_universal_fixpack.tar.gz\n\u251c\u2500\u2500 HCL_Connections_6.5_wizards_lin_aix.tar\n<\/code><\/pre>\n
IBM Installation Manager<\/h3>\n
Wird zur Installation von WebSphere ben\u00f6tigt, mindestens Version 1.8.5.1. Kann (noch?) nicht im Flexnet heruntergeladen werden, sondern im IBM Fix Central (IBM ID<\/a> ben\u00f6tigt).<\/p>\n
WebSphere<\/h3>\n
IBM WebSphere Application Server Network Deployment V8.5.5 (1 of 3) for Multiplatform Multilingual\r\nIBM WebSphere Application Server V8.5.5 Supplements (1 of 3) for Multiplatform Multilingual\r\nIBM WebSphere Application Server V8.5.5 Supplements (1 of 3) for Multiplatform Multilingual<\/p>\n
Jeweils alle drei Zip-Dateien herunterladen.<\/p>\n
DB2<\/h3>\n
DB2 11.5.6 FixPack 0 for Linux\/x86-64 (64 bit), DB2 Universal Fix Pack\r\nIBM Db2 Enterprise Server Edition – Authorized User Single Install Option – Activation 11.5 for Linux, UNIX and Windows Multilingual<\/p>\n
TDI<\/h3>\n
IBM Security Directory Integrator V7.2 for Linux Linux – x86-64<\/p>\n
Connections<\/h3>\n
HCL Connections V6.5 for Linux Multilingual\r\nHCL Connections V6.5 Wizard for Linux, AIX Multilingual\r\nJDBC 3-Treiber f\u00fcr DB2<\/a> (nur bis DB2 Version 11.1 mitgeliefert, bei 11.5 ist nur der Nachfolger JDBC 4 dabei)<\/p>\n
Installation der Komponenten<\/h2>\n
OpenLDAP<\/h3>\n
[root@cnx65-db2 ~]# yum install openldap-clients openldap-servers\n[root@cnx65-db2 ~]# systemctl enable --now slapd<\/code><\/pre>\n
F\u00fcr die grundlegende Konfiguration<\/a> legt eine Ldiff-Datei (hier ldap-base.ldiff<\/strong>) an mit folgendem Inhalt<\/p>\n
dn: olcDatabase={2}hdb,cn=config\nchangetype: modify\nreplace: olcSuffix\nolcSuffix: dc=u-labs,dc=de\n\ndn: olcDatabase={2}hdb,cn=config\nchangetype: modify\nreplace: olcRootDN\nolcRootDN: cn=admin,dc=u-labs,dc=de\n\ndn: olcDatabase={2}hdb,cn=config\nchangetype: modify\nreplace: olcRootPW\nolcRootPW: {SSHA}6FPF2qA2kEFqVlO2hBZYPj4s5VLc3jK3\n\ndn: olcDatabase={2}hdb,cn=config\nchangetype: modify\nreplace: olcDbIndex\nolcDbIndex: objectclass eq,pres\n\ndn: olcDatabase={2}hdb,cn=config\nchangetype: modify\nadd: olcDbIndex\nolcDbIndex: uid,ou,cn,mail,sn eq,pres,sub\n\ndn: olcDatabase={1}monitor,cn=config\nchangetype: modify\nreplace: olcAccess\nolcAccess: {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\n\n<\/code><\/pre>\n
Sowie eine zweite Datei, um die Organisation\/Dom\u00e4ne als Objekt anzulegen (dc.ldiff<\/strong>). Wer m\u00f6chte, kann alternativ auch eine Organisationseinheit (OU statt O)<\/a> erstellen.<\/p>\n
dn: dc=u-labs,dc=de\nobjectClass: dcObject\nobjectClass: organization\ndc: u-labs\no: u-labs\n\ndn: o=user,dc=u-labs,dc=de\nobjectClass: organization\no: user<\/code><\/pre>\n
olcRootPW <\/strong>ist das Passwort eures Admin-Kontos. Den Hash kann man mit slappasswd <\/strong>generieren, in diesem Beispiel wurde „cnx“ verwendet. Auch das Suffix (dc=u-labs, dc=de<\/strong>) k\u00f6nnt ihr entsprechend eurer Dom\u00e4ne anpassen. Anschlie\u00dfend f\u00fcgen wir die \u00c4nderungen zusammen mit ein paar Standard-Schematas ein:<\/p>\n
[root@cnx65-db2 ~]# ldapmodify -Y EXTERNAL -H ldapi:\/\/\/ -f ldap-base.ldiff\n[root@cnx65-db2 ~]# ldapadd -Y EXTERNAL -H ldapi:\/\/\/ -f \/etc\/openldap\/schema\/cosine.ldif\n[root@cnx65-db2 ~]# ldapadd -Y EXTERNAL -H ldapi:\/\/\/ -f \/etc\/openldap\/schema\/nis.ldif \n[root@cnx65-db2 ~]# ldapadd -Y EXTERNAL -H ldapi:\/\/\/ -f \/etc\/openldap\/schema\/inetorgperson.ldif\n[root@cnx65-db2 ~]# ldapadd -D "cn=admin,dc=u-labs,dc=de" -x -W -f dc.ldiff<\/code><\/pre>\n
Der LDAP-Server ist damit bereit, enth\u00e4lt au\u00dfer dem Administratorkonto aber noch keine Benutzer. Daher legen wir zumindest ein paar Testbenutzer an, mit denen man sich sp\u00e4ter an Connections anmelden kann:<\/p>\n
dn: uid=ACapone,o=user,dc=u-labs,dc=de\nchangetype: add\ngivenName: Al\nsn: Capone\ntelephoneNumber: 123456789\nmail: ACapone@u-labs.de\nfacsimileTelephoneNumber: 987654321\nobjectClass: top\nobjectClass: person\nobjectClass: organizationalPerson\nobjectClass: inetorgperson\nuid: ACapone\ncn: Al Capone\nuserPassword: cnx\n\ndn: uid=mickeym,o=user,dc=u-labs,dc=de\nchangetype: add\ngivenName: Mickey\nsn: Maus\ntelephoneNumber: 1234567890\nmail: mickey@u-labs.de\nfacsimileTelephoneNumber: 987654321\nobjectClass: top\nobjectClass: person\nobjectClass: organizationalPerson\nobjectClass: inetorgperson\nuid: mickeym\ncn: Mickey Maus\nuserPassword: cnx<\/code><\/pre>\n
[root@cnx65-db2 ~]# ldapadd -D "cn=admin,dc=u-labs,dc=de" -x -W -f users.ldiff<\/code><\/pre>\n
Eine Testabfrage mit ldapsearch <\/strong>sollte diese zwei Nutzer nun finden, wenn wir nach z.B. Personen suchen:<\/p>\n
[root@cnx65-db2 ~]#  ldapsearch -D "cn=admin,dc=u-labs,dc=de" -x -W -b "dc=u-labs,dc=de" "objectClass=person" cn\nEnter LDAP Password:\n# extended LDIF\n#\n# LDAPv3\n# base <dc=u-labs,dc=de> with scope subtree\n# filter: objectClass=person\n# requesting: cn\n#\n\n# ACapone, user, u-labs.de\ndn: uid=ACapone,o=user,dc=u-labs,dc=de\ncn: Al Capone\n\n# mickeym, user, u-labs.de\ndn: uid=mickeym,o=user,dc=u-labs,dc=de\ncn: Mickey Maus\n\n# search result\nsearch: 2\nresult: 0 Success\n\n# numResponses: 3\n# numEntries: 2<\/code><\/pre>\n
DB2<\/h3>\n
DB2 bietet einen konsolenbasierten Assistenten (db2_install<\/strong>), der allerdings nur das absolute Minimum reduziert. Er legt keine Instanz an und startet diese auch nicht automatisch. Dies k\u00f6nnte man manuell erg\u00e4nzend einrichten<\/a>.<\/p>\n
Alternativ kann db2_setup <\/strong>sowohl grafisch genutzt werden, oder \u00fcber ein Response-File. Letzteres ist die praktikablere L\u00f6sung, da die grafische Variante teilweise Probleme mit sich bringt (z.B. nicht ausf\u00fcllbare 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\u00f6nnen. Bei vielen IBM-Programmen ist es g\u00e4ngig, die grafische Installation in ein Response-File aufzeichnen zu k\u00f6nnen.<\/p>\n
Zun\u00e4chst m\u00fcssen folgende Abh\u00e4ngigkeiten installiert werden:<\/p>\n
[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++ unzip<\/code><\/pre>\n
Anschlie\u00dfend entpacken wir das Installationsarchiv (diese liegen bei mir immer in \/opt\/install<\/strong>):<\/p>\n
[root@cnx65-db2 ~]# cd \/opt\/install\/db2; mkdir extracted\n[root@cnx65-db2 ~]# tar -xf v11.5.6_linuxx64_universal_fixpack.tar.gz -C extracted\n[root@cnx65-db2 ~]# cd extracted\/universal<\/code><\/pre>\n
Das Response-File (db2.resp<\/strong>) mit folgendem Inhalt anlegen:<\/p>\n
*-----------------------------------------------------\n* Generated response file used by the DB2 Setup wizard\n*-----------------------------------------------------\n*  Product Installation\nLIC_AGREEMENT = ACCEPT\nPROD = DB2_SERVER_EDITION\nFILE = \/opt\/ibm\/db2\nINSTALL_TYPE = TYPICAL\n*-----------------------------------------------\n*  Das properties\n*-----------------------------------------------\nDAS_CONTACT_LIST = LOCAL\n* ----------------------------------------------\n*  Instance properties\n* ----------------------------------------------\nINSTANCE = inst1\ninst1.TYPE = ese\n*  Instance-owning user\ninst1.NAME = db2inst1\ninst1.GROUP_NAME = db2inst1\ninst1.HOME_DIRECTORY = \/home\/db2inst1\n* plain: password\ninst1.PASSWORD = cnx\ninst1.AUTOSTART = YES\ninst1.SVCENAME = db2c_db2inst1\ninst1.PORT_NUMBER = 50000\ninst1.FCM_PORT_NUMBER = 60000\ninst1.MAX_LOGICAL_NODES = 6\ninst1.CONFIGURE_TEXT_SEARCH = NO\n*  Fenced user\ninst1.FENCED_USERNAME = db2fenc1\ninst1.FENCED_GROUP_NAME = db2fadm1\ninst1.FENCED_HOME_DIRECTORY = \/home\/db2fenc1\ninst1.FENCED_PASSWORD = cnx\n*-----------------------------------------------\n*  Installed Languages\n*-----------------------------------------------\nLANG = EN<\/code><\/pre>\n
Dies legt grundlegende Einstellungen wie Edition, Zielpfad etc. fest und erstellt eine automatisch gestartete Instanz namens db2inst1<\/strong> und den Passwort cnx<\/strong> (entsprechend anpassen). Zus\u00e4tzlich einen Fenced<\/em> Benutzer. Er dient zur Ausf\u00fchrung von Prozeduren und soll die Sicherheit erh\u00f6hen<\/a>. Gestartet wird die Installation mit db2setup<\/strong> und dem Schalter -r<\/strong> f\u00fcr Response-File:<\/p>\n
[root@cnx65-db2 universal]# .\/db2setup -r db2.resp<\/code><\/pre>\n
Standardm\u00e4\u00dfig haben wir damit eine Demo-Version installiert. Da DB2 \u00fcber Connections lizenziert wird, kann man die Instanz mit der Lizenzdatei (ZIP) aus dem Flexnet aktivieren. Daf\u00fcr zun\u00e4chst das ZIP-Archiv entpacken:<\/p>\n
[root@cnx65-db2 db2]# cd \/opt\/install\/db2\n[root@cnx65-db2 db2]# unzip DB2_ESE_AUSI_Activation_11.5.zip<\/code><\/pre>\n
DB2 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<\/strong> kann die Lizenz gepr\u00fcft werden, hier steht standardm\u00e4\u00dfig Trial<\/em> nach einer frischen Installation:<\/p>\n
[root@cnx65-db2 db2]# su - db2inst1\n[db2inst1@cnx65-db2]$ db2licm -l | grep type\nLicense type:                     "Trial"\n\n[db2inst1@cnx65-db2]$ db2licm -a \/opt\/install\/db2\/ese_u\/db2\/license\/db2ese_u.lic\nLIC1402I  License added successfully.\n\nLIC1426I  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"\n\n[db2inst1@cnx65-db2 ese_u]$ db2licm -l | grep type\nLicense type:                     "Authorized User Single Install"<\/code><\/pre>\n
Schlussendlich sollte noch Unicode aktiviert werden<\/a>:<\/p>\n
[db2inst1@cnx65-db2 Wizards]$ db2set DB2CODEPAGE=1208\n[db2inst1@cnx65-db2 Wizards]$ db2stop force\n06\/10\/2022 07:15:54     0   0   SQL1064N  DB2STOP processing was successful.\nSQL1064N  DB2STOP processing was successful.\n[db2inst1@cnx65-db2 Wizards]$ db2start\n06\/10\/2022 07:16:00     0   0   SQL1063N  DB2START processing was successful.\nSQL1063N  DB2START processing was successful.\n[db2inst1@cnx65-db2 Wizards]$ db2set\nDB2COMM=TCPIP\nDB2CODEPAGE=1208\nDB2AUTOSTART=YES<\/code><\/pre>\n
Und den lcuser f\u00fcr den Datenbankzugriff<\/a> erstellen (mit root statt db2inst1 Benutzer):<\/p>\n
[root@cnx65-db2 Wizards]# useradd -g db2inst1 lcuser\n[root@cnx65-db2 Wizards]# echo "lcuser:cnx" | chpasswd<\/code><\/pre>\n
TDI<\/h3>\n
Auch f\u00fcr den TDI legen wir wieder ein Response-File (tdi.resp<\/strong>) an. Der Pfad \/opt\/ibm\/tdi\/7.2<\/strong> ist jeweils der anpassbare Installationspfad:<\/p>\n
#Indicate whether the license agreement been accepted\n#----------------------------------------------------\nLICENSE_ACCEPTED=TRUE\n\n#Choose Install Folder\n#---------------------\nUSER_INSTALL_DIR=\/opt\/ibm\/tdi\/7.2\n\n#Choose Install Set\n#------------------\nCHOSEN_FEATURE_LIST=JavaDocs,Examples,Server,CE,lwi,amc\nCHOSEN_INSTALL_FEATURE_LIST=JavaDocs,Examples,Server,CE,lwi,amc\nCHOSEN_INSTALL_SET=Typical\n\n#Solutions Directory\n#-------------------\nTDI_SOLDIR_HOME=0\nTDI_SOLDIR_INSTALL=0\nTDI_SOLDIR_SELECT=0\nTDI_SOLDIR_CWD=1\n\n#Server Port Values\n#------------------\nTDI_SERVER_PORT=1099\nTDI_SYSTEM_STORE_PORT=1527\nTDI_REST_API_PORT=1098\nTDI_MQE_SYSTEMQ_PORT=61616\n\n#Register Server as Service\n#--------------------------\nTDI_REGISTER_SERVER=0\n\n#Integrated Solutions Console Port Values\n#----------------------------------------\nTDI_HTTP_PORT=13100\nTDI_HTTPS_PORT=13101\nTDI_AM_API_PORT=13104\n\n#AMC Service\n#-----------\nTDI_REGISTER_AMC=0\n\n#Install\n#-------\n-fileOverwrite_\/opt\/ibm\/tdi\/7.2\/maintenance\/UpdateInstaller.jar=Yes\n-fileOverwrite_\/opt\/ibm\/tdi\/7.2\/TDI_LUM.zip=Yes\n-fileOverwrite_\/opt\/ibm\/tdi\/7.2\/_uninst\/uninstaller.lax=Yes<\/code><\/pre>\n
Es folgt das Entpacken sowie die Installation mit dem Response-File:<\/p>\n
[root@cnx65-db2 db2]# cd \/opt\/install\/tdi; mkdir extracted\n[root@cnx65-db2 tdi]# tar -xf CIS7TML.tar -C extracted\n[root@cnx65-db2 tdi]# cd extracted\/linux_x86_64\n[root@cnx65-db2 extracted]# .\/install_sdiv72_linux_x86_64.bin -f tdi.resp -i silent<\/code><\/pre>\n
WebSphere<\/h3>\n
Abh\u00e4ngigkeiten<\/h4>\n
WebSphere ben\u00f6tigt folgende Abh\u00e4ngigkeiten:<\/p>\n
[root@cnx65-was ~]# yum install gtk2 libXtst xorg-x11-fonts-Type1 psmisc<\/code><\/pre>\n
F\u00fcr die sp\u00e4tere Installation m\u00fcssen wir den Installation Manager von IBM entpacken:<\/p>\n
[root@cnx65-was install]# cd \/opt\/install\/installation-manager\/\n[root@cnx65-was installation-manager]# unzip agent.installer.linux.gtk.x86_64_1.9.2002.20220323_1321.zip -d extracted\n[root@cnx65-was installation-manager]# cd extracted<\/code><\/pre>\n
Zur Installation gibt es mehrere M\u00f6glichkeiten: installc -c<\/strong> startet den konsolenbasierten Assistenten. Dort kann man den Standard-Zielpfad (\/opt\/IBM\/InstallationManager<\/strong>) \u00e4ndern, wobei dies i.d.R. nicht notwendig ist. Daher kann man den Modus Silent Install<\/em> verwenden. Hier gen\u00fcgt es, folgenden Befehl auszuf\u00fchren:<\/p>\n
[root@cnx65-was extracted]# .\/install -acceptLicense --launcher.ini silent-install.ini\nInstalled com.ibm.cic.agent_1.9.2002.20220323_13215 to the \/opt\/IBM\/InstallationManager\/eclipse directory.<\/code><\/pre>\n
Wer den IM deinstallieren m\u00f6chte, findet das Skript dazu unter \/var\/ibm\/InstallationManager\/uninstall\/uninstallc<\/strong> – dies kann direkt ausgef\u00fchrt werden, ohne weitere Parameter.<\/p>\n
WAS Installationsdateien<\/h4>\n
Entpackt werden diese mit ? als Platzhalter f\u00fcr den fortlaufenden Buchstabe, der als eine Art „Teildatei“ genutzt wird – allerdings anscheinend auf eigene Faust. Denn im Gegensatz zu anderen Archivformaten unterst\u00fctzt ZIP keine nativen Teilarchive. Man muss daher alle Archive einzeln entpacken, dies l\u00e4sst sich mit dem Platzhalter vereinfachen:<\/p>\n
[root@cnx65-was was]# cd \/opt\/install\/was\/\n[root@cnx65-was was]# unzip 'CIK2?ML.zip' -d extracted<\/code><\/pre>\n
Eben so wird mit dem Supplements<\/em> Ordner verfahren, allerdings den Dateiname entsprechend anpassen:<\/p>\n
[root@cnx65-was was]# cd supplements\n[root@cnx65-was supplements]# unzip 'CIK1?ML.zip' -d extracted<\/code><\/pre>\n
Damit lie\u00dfe 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\u00fcr TLS seit Jahren veraltet sind. Es macht daher Sinn, das aktuellste unterst\u00fctzte Fixpack (f\u00fcr CNX 6.5 ist das FP 20) ebenfalls zu entpacken. Fixpacks gibt es f\u00fcr WebSphere selbst und die Erweiterungen im Supplements-Paket.<\/p>\n
[root@cnx65-was ~]# cd \/opt\/install\/was\/fixpack\/\n[root@cnx65-was fixpack]# unzip '8.5.5-WS-WAS-FP020-part?.zip' -d was\n\n[root@cnx65-was fixpack]# unzip '8.5.5-WS-WASSupplements-FP020-part?.zip' -d supplements<\/code><\/pre>\n
Die Installation selbst erfolgt \u00fcber die Konsolenvariante des Installation Managers unter \/opt\/IBM\/InstallationManager\/eclipse\/tools\/imcl<\/strong>. Installationsdateien f\u00fcr den IM werden in Repositories<\/em> abgelegt. Jeder soeben entpackte Ordner ist ein Repository, zu erkennen an der Datei repository.config<\/strong> im Wurzelverzeichnis. Mit dem Befehl listAvailablePackages k\u00f6nnen wir uns die Pakete auflisten lassen, die in einem (oder mehreren mit Komma getrennten) Pfaden zu Repositories verf\u00fcgbar sind:<\/p>\n
[root@cnx65-was ~]# \/opt\/IBM\/InstallationManager\/eclipse\/tools\/imcl listAvailablePackages -repositories \/opt\/install\/was\/extracted,\/opt\/install\/was\/supplements\/extracted\ncom.ibm.websphere.ND.v85_8.5.5000.20130514_1044\ncom.ibm.websphere.APPCLIENT.v85_8.5.5000.20130514_1044\ncom.ibm.websphere.IHS.v85_8.5.5000.20130514_1044\ncom.ibm.websphere.PLG.v85_8.5.5000.20130514_1044\ncom.ibm.websphere.PLUGCLIENT.v85_8.5.5000.20130514_1044\ncom.ibm.websphere.WCT.v85_8.5.5000.20130514_1044<\/code><\/pre>\n
Das erste Paket com.ibm.websphere.ND.v85_8.5.5000.20130514_1044<\/strong> stammt aus dem WebSphere-Repository (\/opt\/install\/was\/extracted<\/em>). Alle anderen aus dem Supplements-Repository (\/opt\/install\/was\/supplements\/extracted<\/em>), in denen der IBM HTTP Server (IHS) sowie das Plugin enthalten ist.<\/p>\n
Installation WAS und dem Deployment Manager<\/h4>\n
Ebenfalls mit imcl <\/strong>kann man besagtes Paket installieren. Daf\u00fcr reicht das erste Repository, da wir f\u00fcr WebSphere selbst das Supplements-Paket noch nicht ben\u00f6tigen. Allerdings macht es Sinn, den Pfad zum Fixpack-Repository mit anzugeben: Durch den Parameter -installFixes<\/strong> wird das Fixpack im Anschluss automatisch installiert, sodass wir kein h\u00e4ndisches Update<\/a> durchf\u00fchren m\u00fcssen. Die Buildnummer mit Zeitstempel aus dem Paketname (5000.20130514_1044<\/em>) sind nicht n\u00f6tig. Der letzte Parameter -showProgress<\/strong> zeigt eine Fortschrittsanzeige:<\/p>\n
[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\n                 25%                50%                75%                100%\n------------------|------------------|------------------|------------------|\n............................................................................\nInstalled com.ibm.websphere.ND.v85_8.5.5000.20130514_1044 to the \/opt\/IBM\/WebSphere\/AppServer directory.<\/code><\/pre>\n
Das versionInfo.sh<\/strong> Skript sollte das entsprechende FP (hier 20, d.H. 8.5.5.20<\/strong>) anzeigen:<\/p>\n
[root@cnx65-was fixpack]# \/opt\/IBM\/WebSphere\/AppServer\/bin\/versionInfo.sh\n...\nName                  IBM WebSphere Application Server Network Deployment\nVersion               8.5.5.20\nID                    ND\nBuild Level           cf202127.02\nBuild Date            7\/8\/21\nPackage               com.ibm.websphere.ND.v85_8.5.5020.20210708_1826<\/code><\/pre>\n
Zum Vergleich dazu die Installation der 8.5.5.0 ohne Fixpack (so sollte es nicht aussehen):<\/p>\n
...\nInstalled Product\n--------------------------------------------------------------------------------\nName                  IBM WebSphere Application Server Network Deployment\nVersion               8.5.5.0\nID                    ND\nBuild Level           gm1319.01\nBuild Date            5\/14\/13\nPackage               com.ibm.websphere.ND.v85_8.5.5000.20130514_1044<\/code><\/pre>\n
Wir m\u00fcssen im folgenden mindestens zwei Profile anlegen: Zun\u00e4chst der Deployment Manager. Ein typischer Standardname ist Dmgr01, wobei dieser frei w\u00e4hlbar ist. Der Hostname wird mit dem eures WAS-Servers setzt. Die Admin-Zugangsdaten dienen f\u00fcr den sp\u00e4teren Zugriff auf die ISC.<\/p>\n
[root@cnx65-was fixpack]# cd \/opt\/IBM\/WebSphere\/AppServer\/bin\n[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\nINSTCONFSUCCESS: Success: Profile Dmgr01 now exists. Please consult \/opt\/IBM\/WebSphere\/AppServer\/profiles\/Dmgr01\/logs\/AboutThisProfile.txt for more information about this profile.<\/code><\/pre>\n
Im angegebenen Pfad sollte nun ein Profil namens Dmgr01 <\/strong>angelegt worden sein. Dies kann \u00fcber startManager.sh<\/strong> im bin Ordner gestartet werden:<\/p>\n
[root@cnx65-was bin]# cd \/opt\/IBM\/WebSphere\/AppServer\/profiles\/Dmgr01\/bin\/\n[root@cnx65-was bin]# .\/startManager.sh\n...\nADMU3000I: Server dmgr open for e-business; process id is 8218<\/code><\/pre>\n
Damit ist die ISC im Browser \u00fcber https:\/\/cnx-host:9043\/ibm\/console<\/strong> erreichbar. Dort erscheint ein Zertifikatsfehler, da WAS standardm\u00e4\u00dfig ein selbst signiertes Zertifikat benutzt. <\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
\u00dcber Erweitert<\/em> kann man fortfahren und mit dem zuvor erstellten Admin-Konto (hier im Beispiel wasadmin:adminwas) sich anmelden:<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Einrichtung des WAS-Nodes<\/h4>\n
Der Deployment Manager ist zur Verwaltung gedacht. F\u00fcr die eigentlichen Anwendungen von Connections wird ein Node (CnxNode01<\/strong>) eingerichtet, in diesem Beispiel auf dem gleichen Server. Theoretisch k\u00f6nnte dieser aber auch auf einem anderen Host liegen.<\/p>\n
[root@cnx65-was bin]# cd \/opt\/IBM\/WebSphere\/AppServer\/bin\n[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\nINSTCONFSUCCESS: Success: Profile CnxNode01 now exists. Please consult \/opt\/IBM\/WebSphere\/AppServer\/profiles\/CnxNode01\/logs\/AboutThisProfile.txt for more information about this profile.\n<\/code><\/pre>\n
Dieser neue Node CnxNode01 ist bisher allerdings nicht mit dem Deployment Manager verbunden. Um das zu \u00e4ndern, wird addNode.sh<\/strong> ausgef\u00fchrt. 127.0.0.1 ist die Adresse des Deployment Managers – hier localhost, da beide auf dem gleichen Server betrieben werden.<\/p>\n
[root@cnx65-was bin]# .\/addNode.sh 127.0.0.1 8879 -conntype SOAP -username wasadmin -password adminwas -profileName CnxNode01\nADMU0116I: Tool information is being logged in file\n           \/opt\/IBM\/WebSphere\/AppServer\/profiles\/CnxNode01\/logs\/addNode.log\nADMU0128I: Starting tool with the CnxNode01 profile\n...\n\nADMU0300I: The node CnxNode01 was successfully added to the CnxCell cell.<\/code><\/pre>\n
In der ISC taucht der Node nun auf:<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Connections Datenbanken<\/h3>\n
Bevor Connections installiert (d.H. die Anwendungen auf WebSphere deployen) wird, m\u00fcssen vorbereitend die Datenbanken angelegt werden. Dies geschieht auf dem Datenbankserver:<\/p>\n
[root@cnx65-db2 install]# cd \/opt\/install\n[root@cnx65-db2 install]# tar -xf HCL_Connections_6.5_wizards_lin_aix.tar\n[root@cnx65-db2 install]# cd Wizards\n[root@cnx65-db2 Wizards]# chmod +x dbWizard.sh jvm\/linux\/jre\/bin\/*\n[root@cnx65-db2 Wizards]# chown db2inst1 . -R\n\n[db2inst1@cnx65-db2 Wizards]$ cp samples\/dbWizard_response.properties cnx-db.resp<\/code><\/pre>\n
In samples\/dbWizard_response.properties<\/strong> befindet sich eine Vorlage, aus der sich ein Response-File zur Installation erstellen l\u00e4sst. Wichtig ist hier vor allem der Installationspfad zur Datenbank (dbHome)<\/strong>, deren Administratorzugang (administrator<\/strong>\/adminPassword<\/strong>) und der Pfad zur Java-Bibliothek, mit dem sich eine Verbindung zur DB2 herstellen l\u00e4sst (jdbcLibPath<\/strong>). Aus lizenztechnischen Gr\u00fcnden befindet sich diese Bibliothek nicht im Lieferumfang von Connections. Auf Basis der Vorlage wird folgendes Response-File (cnx-db.resp<\/strong>) angelegt:<\/p>\n
# *****************************************************************\n#\n# IBM Confidential\n#\n# OCO Source Materials\n#\n# Copyright IBM Corp. 2010, 2015\n#\n# The source code for this program is not published or otherwise\n# divested of its trade secrets, irrespective of what has been\n# deposited with the U.S. Copyright Office.\n#\n# *****************************************************************\n\n###########################################################################\n# The value can be: db2 | oracle | sqlserver\n###########################################################################\ndbtype=db2\n\n###########################################################################\n# The value is the instance name which your want to create your database.\n###########################################################################\ndbInstance=db2inst1\n\n###########################################################################\n# Specify the database installed location.\n###########################################################################\ndbHome=\/opt\/ibm\/db2\n\n###########################################################################\n# The value can be: create | delete | upgrade\n# create : create database.\n# delete : delete database.\n# upgrade: upgrade database.\n###########################################################################\naction=create\n\n###########################################################################\n# The feature you selected. Use "," to separate.\n# The value can be: activities, blogs, communities, dogear, homepage,\n# wikis, files, forum, profiles, mobile, metrics, cognos, library\n# cognos and library cannot be listed in features when action=upgrade\n###########################################################################\nfeatures=activities,blogs,communities,dogear,homepage,wikis,files,forum,profiles,mobile,metrics,cognos,library\n\n###########################################################################\n# Database server port used for JDBC invocation\n# DB2 default is 50000\n# Oracle default is 1521\n# SQLServer default is 1433\n###########################################################################\nport=50000\n\n###########################################################################\n# Database administrator account used for JDBC invocation\n# DB2 default on Windows is db2admin, on Linux\/AIX is db2inst1\n# Oracle default is system\n# SQLServer default is sa\n###########################################################################\nadministrator=db2inst1\n\n###########################################################################\n# Database administror password used for JDBC invocation\n###########################################################################\nadminPassword=cnx\n\n###########################################################################\n# JDBC library path used for JDBC invocation on SQLServer only\n###########################################################################\njdbcLibPath=\/opt\/ibm\/db2\/java\/db2jcc4.jar\n\n###########################################################################\n# Password is Only needed for oracle and sqlserver when creating or updating database.\u00a0 The password will be removed\n#\u00a0after finishing task for the reponse file "response\\dbWizard\\response.properties".\n###########################################################################\nhomepage.password=\nactivities.password=\nblogs.password=\ndogear.password=\ncommunities.password=\nprofiles.password=\nwikis.password=\nfiles.password=\nforum.password=\nmobile.password=\nmetrics.password=\ncognos.password=\nlibrary.password=\npushnotification.password=\n###########################################################################\n# file path is only needed for sqlserver when creating or updating database, it is the\n# directory where user want to store the database files.\n###########################################################################\nprofiles.filepath=C\\:\\\\yourPath\nblogs.filepath=\ndogear.filepath=\ncommunities.filepath=\nhomepage.filepath=\nactivities.filepath=\nwikis.filepath=\nfiles.filepath=\nforum.filepath=\nmobile.filepath=\nmetrics.filepath=\ncognos.filepath=\nlibrary.filepath=\npushnotification.filepath=\n###########################################################################\n# The value can be:\n#  For db2:9.7 or 10.0\n#  For Oracle: 10 or 11\n#  For sqlserver: 9.0 or 10.0\n###########################################################################\ndbVersion=11.5\n<\/code><\/pre>\n
Um damit die Installation zu starten, dbWizard.sh<\/strong> aufrufen:<\/p>\n
[db2inst1@cnx65-db2 Wizards]$ .\/dbWizard.sh -silent cnx-db.resp\nStart the task in silent mode.\nResponse file is set to cnx-db.resp.\nCreate IBM Connections database\n...<\/code><\/pre>\n
Das Anlegen und Einrichten der Datenbanken dauert mindestens etwa 20 Minuten, je nach verwendeter Hardware auch l\u00e4nger. Am Ende sollte bei jeder Datenbank The database creation was successful<\/em> in der Ausgabe stehen.<\/p>\n
Connections TDI Konfiguration<\/h3>\n
# ToDo: Wird im GUI Assistenten des TDI abgefragt - pruefen, ob dieser Schritt per CLI notwendig ist\n[root@cnx65-db2 db2]# tar -xf v11.1.4fp7_jdbc_sqlj.tar.gz\n[root@cnx65-db2 jdbc_sqlj]# unzip db2_db2driver_for_jdbc_sqlj.zip\n[root@cnx65-db2 jdbc_sqlj]# cp db2jcc.jar \/opt\/ibm\/db2\/java\/<\/code><\/pre>\n
Hierf\u00fcr werden Konfigurationsdateien aus der tdisol.tar<\/strong> ben\u00f6tigt, die sich wiederum im Installationsarchiv von Connections (HCL_Connections_6.5_lin<\/em>.tar) befindet. Wir entpachen dieses Archiv daher auf dem WAS-Server, da wir die anderen Dateien dort sp\u00e4ter ebenfalls ben\u00f6tigen. Mit rsync l\u00e4sst sich die tdisol.tar<\/strong> nach \/opt\/install<\/strong> auf dem zweiten Server (DB2) hochladen.<\/p>\n
[root@cnx65-was ~]# cd \/opt\/install\/cnx\n[root@cnx65-was cnx]# tar -xf HCL_Connections_6.5_lin.tar\n[root@cnx65-was cnx]# rsync -azP HCL_Connections_Install\/tools\/tdisol.tar cnx65-db2.u-labs.de:\/opt\/install\/<\/code><\/pre>\n
Anschlie\u00dfend das Archiv entpacken und in den Basisodner des TDI unterhalb von \/opt<\/strong> verschieben:<\/p>\n
[root@cnx65-db2 install]# tar -xf tdisol.tar\n[root@cnx65-db2 install]# mv TDI \/opt\/ibm\/tdi\/tdisol\n[root@cnx65-db2 install]# cd \/opt\/ibm\/tdi\/tdisol<\/code><\/pre>\n
In der Datei tdienv.sh befindet sich ein Fehler: Sie referenziert standardm\u00e4\u00dfig noch auf die Vorversion 7.1.1, obwohl wir 7.2 nutzen. Daher muss man folgenden Pfad von Hand korrigieren:<\/p>\n
export TDIPATH=\/opt\/IBM\/TDI\/V7.1.1<\/code><\/pre>\n
Es folgt die grundlegende Konfiguration des TDI in profiles_tdi.properties<\/strong>:<\/p>\n
source_ldap_url=ldap:\/\/localhost:389\nsource_ldap_search_base=o=user,dc=u-labs,dc=de\nsource_ldap_search_filter=(objectClass=person)\nsource_ldap_user_login=cn=admin,dc=u-labs,dc=de\n{protect}-source_ldap_user_password=cnx\n\ndbrepos_jdbc_url=jdbc:db2:\/\/localhost:50000\/peopledb\ndbrepos_jdbc_driver=com.ibm.db2.jcc.DB2Driver\ndbrepos_username=db2inst1\n{protect}-dbrepos_password=cnx<\/code><\/pre>\n
Das gen\u00fcgt als Basis f\u00fcr ein Testsystem – jeder LDAP-Benutzer in der user<\/strong> 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\u00fchrbar gemacht haben, eignet sich das collect_dns.sh<\/strong> Skript f\u00fcr einen ersten Testlauf: Es sammelt alle Nutzer die auf den Filter zutreffend ein und schreibt sie in collect.dns<\/strong>. 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:<\/p>\n
[root@cnx65-db2 tdisol]# chmod +x *.sh netstore\n[root@cnx65-db2 tdisol]# .\/collect_dns.sh\nCLFRN1280I: 20220610104053 Iterations total number: 2.\n[root@cnx65-db2 tdisol]# cat collect.dns\nuid=ACapone,o=user,dc=u-labs,dc=de\nuid=mickeym,o=user,dc=u-labs,dc=de<\/code><\/pre>\n
Der n\u00e4chste Schritt ist eine vollst\u00e4ndige Synchronisation. Hierf\u00fcr muss noch das Id-Attribut in der Datei map_dbrepos_from_source.properties<\/strong> angepasst werden, da die Standardkonfiguration von Domino ausgeht:<\/p>\n
guid=uid\n# Statt \n#guid=ibm-entryUuid<\/code><\/pre>\n
Wird nun die Synchronisation mit sync_all_dns.sh<\/strong> 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\u00fcgt\/modifiziert vermerkt werden:<\/p>\n
[root@cnx65-db2 tdisol]# .\/sync_all_dns.sh\n...\nCLFRN0037I: After synchronization, added or modified records is 2, deleted or inactivated records is 0, unchanged records 0, and failure records is 0.<\/code><\/pre>\n
Connections-Anwendungen installieren<\/h3>\n
Connections selbst besteht aus mehreren Anwendungen, die auf verschiedenen Anwendungsservern (JVMs) installiert werden.<\/p>\n
[root@cnx65-was cnx]# mkdir -p \/opt\/IBM\/DB2\/java\n[root@cnx65-was cnx]# rsync -azP cnx65-db2.u-labs.de:\/opt\/ibm\/db2\/java\/ \/opt\/IBM\/DB2\/java<\/code><\/pre>\n
Das Passwort des WebSphere Administratorkontos (wasadmin) darf nicht im Klartext \u00fcbergeben werden. Man muss es zun\u00e4chst mit imutilsc<\/strong> verschl\u00fcssel<\/em>n<\/a>. Im folgenden Beispiel geschieht dies mit unserem Beispiel-Kennwort adminwas<\/strong>:<\/p>\n
[root@cnx65-was cnx]# \/opt\/IBM\/InstallationManager\/eclipse\/tools\/imutilsc encryptString adminwas -silent -noSplash\nhyDz8CktIliBlf7Vfsj+kg==<\/code><\/pre>\n
Als Grundlage f\u00fcr das Response-File dient HCL_Connections_Install\/IM\/LC.rsp<\/strong>. Da dies etwas un\u00fcbersichtlich ist und man verschiedene Dinge mehrfach angeben muss, habe ich es etwas \u00fcberarbeitet. Alle Dinge die ihr ggf. an eure Umgebung anpassen m\u00fcsst, befinden sich oben in Variablen.<\/p>\n
[root@cnx65-was cnx]# \/opt\/IBM\/InstallationManager\/eclipse\/tools\/imcl -input \/opt\/install\/cnx\/cnx.resp -log \/var\/log\/cnx-install.log -acceptLicense\nInstalled com.ibm.connections_6.5.0.0_20191121_2323 to the \/opt\/HCL\/Connections directory.<\/code><\/pre>\n
IBM HTTP Server installieren<\/h3>\n
Insgesamt m\u00fcssen drei IBM-Pakete installiert werden: IHS f\u00fcr den IBM HTTP Server, PLG enth\u00e4lt das IHS-Plugin f\u00fcr die Kommunikation mit WebSphere und die Toolbox (WCT) stellt Werkzeuge zur Konfiguration des Plugins bereit.<\/p>\n
[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"\ncom.ibm.websphere.IHS.v85_8.5.5020.20210708_1826 wird in das Verzeichnis \/opt\/IBM\/HTTPServer installiert.\n\n[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\ncom.ibm.websphere.PLG.v85_8.5.5020.20210708_1826 wird in das Verzeichnis \/opt\/IBM\/WebSphere\/Plugins installiert.\n\n[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\ncom.ibm.websphere.WCT.v85_8.5.5000.20130514_1044 wird in das Verzeichnis \/opt\/IBM\/WebSphere\/Toolbox installiert.<\/code><\/pre>\n
Zwei Abh\u00e4ngigkeiten sind f\u00fcr WCT n\u00f6tig:<\/p>\n
[root@cnx65-was cnx]# yum install glibc.i686 libgcc.i686<\/code><\/pre>\n
Nach der Installation wechseln wir zum IBM HTTP Server (IHS), um eine neue Schl\u00fcsseldatenbank zu erzeugen. Im Gegensatz zu Apache und anderen Webservern wird im IHS ein SSL-Modul von IBM verwendet. Dies erh\u00e4lt nicht direkt Zertifikat mit dem dazugeh\u00f6rigen privaten Schl\u00fcssel, sondern speichert beide in einer Schl\u00fcsseldatenbank. F\u00fcr die Testumgebung wird eine neue Datenbank zusammen mit einem selbst signierten Zertifikat angelegt:<\/p>\n
[root@cnx65-was cnx]# cd \/opt\/IBM\/HTTPServer\/bin\n[root@cnx65-was cnx]# .\/gskcapicmd -keydb -create -db \/opt\/IBM\/HTTPServer\/conf\/key.db -pw cnx -stash\n[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 true<\/code><\/pre>\n
Standardm\u00e4\u00dfig ist SSL im IHS deaktiviert. In der httpd.conf muss SSL daher mit dem dazugeh\u00f6rigen IBM-Modul aktiviert werden. Au\u00dferdem ist ein Verweis auf die soeben erstellte Datenbank n\u00f6tig. An dieser Stelle k\u00fcmmere ich mich auch immer gleich um die Weiterleitung, da standardm\u00e4\u00dfig der IHS beim Aufruf des Wurzel-Verzeichnis (also https:\/\/hostname.de ohne Pfad) eine Willkommensseite anzeigt. Durch die Umleitung auf \/homepage <\/strong>erscheint stattdessen die Connections Startseite.<\/p>\n
[root@cnx65-was cnx]# cd ..\/conf\n[root@cnx65-was cnx]# vim httpd.conf\n# Ans Ende Einfuegen\nLoadModule ibm_ssl_module modules\/mod_ibm_ssl.so\nListen 443\n<VirtualHost *:443>\n  SSLEnable\n  RedirectMatch "^\/$" "\/homepage"\n<\/VirtualHost>\nKeyFile \/opt\/IBM\/HTTPServer\/conf\/key.db\nSSLDisable\n\n[root@cnx65-was cnx]# ..\/bin\/apachectl -k start<\/code><\/pre>\n
Als Vorbereitung zur Verkn\u00fcpfung des IHS mit WAS wird folgendes Response-File (plugin.resp) ben\u00f6tigt:<\/p>\n
# https:\/\/www.ibm.com\/support\/knowledgecenter\/SSEQTP_9.0.5\/com.ibm.websphere.base.doc\/ae\/tins_pctcl_using.html\nconfigType=remote\nenableAdminServerSupport=true\nenableUserAndPass=true\nenableWinService=false\nihsAdminCreateUserAndGroup=true\nihsAdminUserID=ihsadmin\nihsAdminPassword=adminihs\nihsAdminPort=8008\nihsAdminUnixUserGroup=ihsadmin\nihsAdminUnixUserID=ihsadmin\nmapWebServerToApplications=true\nwasMachineHostname=cnx65-was.u-labs.de\nwebServerConfigFile1=\/opt\/IBM\/HTTPServer\/conf\/httpd.conf\nwebServerDefinition=webserver1\nwebServerHostName=cnx65-was.u-labs.de\nwebServerOS=Linux\nwebServerPortNumber=80\n# 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\nwebServerSelected=ihs\nwebServerType=IHS<\/code><\/pre>\n
[root@cnx65-was cnx]# cd \/opt\/IBM\/WebSphere\/Toolbox\/WCT\n[root@cnx65-was cnx]# .\/wctcmd.sh -tool pct -createDefinition -defLocPathname \/opt\/IBM\/WebSphere\/Plugins -response plugin.resp -defLocName webserver1 \n...\nDas Tool wurde erfolgreich ausgef\u00fchrt.<\/code><\/pre>\n
In meinem Ansible-Projekt kam es gelegentlich vor, dass die Admin-Konfiguration nicht sauber erstellt wurde. Um dies zu pr\u00fcfen, in dessen Konfiguration nach dem Platzhalter @@AdminPort@@<\/strong> suchen. Hat alles funktioniert, gibt es keine Treffer (leere Ausgabe):<\/p>\n
[root@cnx65-was cnx]# grep @@AdminPort@@ \/opt\/IBM\/HTTPServer\/conf\/admin.conf\n\n<\/code><\/pre>\n
Hinzuf\u00fcgen des Webservers in der ISC<\/h4>\n
System administration > Nodes > Add Node > Unmanaged node<\/strong>, dann OK.<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Servers > Server Types > Web Servers > New<\/strong>, hier verwenden wir den zuvor bereits genutzten Name webserver1<\/strong>:<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Template IHS<\/strong>. In Schritt 3 den zuvor angelegten Administrationsbenutzer (hier ihsadmin\/adminihs) angeben<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Mit Next<\/strong> und Finish <\/strong>abschlie\u00dfen und oben in den Nachrichten auf Save<\/em>.<\/p>\n
Zertifikat vertrauen und Plugin generieren<\/h4>\n
Da wir f\u00fcr die Testumgebung ein selbst signiertes Zertifikat verwenden, muss WebSphere diesem vertrauen. Dies ist wichtig, weil auch interne Kommunikation (z.B. API-Abfrage f\u00fcr Profildaten) stattfindet. Unter Servers > Server Types > Web servers > webserver1 > Additional Properties > Plugin-properties > Manage keys and certificates <\/strong>(1)> Additional Properties > Signer certificates<\/strong> oben auf Retrieve from port <\/strong>klicken und den Hostname\/Port des IHS zusammen mit einem frei w\u00e4hlbaren Alias angeben. Mit Retrive signer information<\/strong> wird das Zertifikat direkt vom IHS geladen.<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Um es zu speichern, unten auf OK <\/strong>und oben auf Save<\/strong>.<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Danach noch mal auf Servers > Server Types > Web servers > webserver1 > Additional Properties > Plugin-properties<\/strong> und Copy to Web server key store directory <\/strong>(2).<\/strong><\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Die Plugin-Konfiguration sollte dadurch bereits automatisch neu generiert und propagiert (auf den Server \u00fcbertragen) werden:<\/p>\n
\"\"<\/a><\/figure>\n
Falls es dabei zu Problemen kommt: Auf der Webserver \u00dcbersichtsseite (Servers > Server Types > Web servers<\/strong>) den zuvor angelegten Server webserver1<\/strong> anhaken, dann oben auf Generate Plug-in<\/strong> sowie anschlie\u00dfend Propagate Plug-in<\/strong>. Dann wird die Konfiguration h\u00e4ndisch neu generiert und transferiert.<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Connections URL anpassen<\/h4>\n
Wie zuvor bereits erw\u00e4hnt, f\u00fchrt CNX selbst auch interne HTTP-Abfragen durch. Daf\u00fcr kommt die in der LotusConnections-config.xml <\/strong>angegebene Basis-URL zum Einsatz. Diese kann man mit z.B. sed relativ leicht durch die eigene ersetzen:<\/p>\n
[root@cnx65-was cnx]# cd \/opt\/IBM\/WebSphere\/AppServer\/profiles\/Dmgr01\/config\/cells\/CnxCell\/LotusConnections-config\/\n[root@cnx65-was cnx]# sed -i -E 's#(href=")[^"]+"#\\1http:\/\/cnx65-was.u-labs.de"#' LotusConnections-config.xml\n[root@cnx65-was cnx]# sed -i -E 's#(ssl_href=")[^"]+"#\\1https:\/\/cnx65-was.u-labs.de"#' LotusConnections-config.xml\n[root@cnx65-was cnx]# sed -E -i 's#(interService href=")[^"]+"#\\1https:\/\/cnx65-was.u-labs.de"#' LotusConnections-config.xml<\/code><\/pre>\n
Sinnvoll ist au\u00dferdem, SSL zu erzwingen. Dazu setzt man in der gleichen Datei<\/p>\n
<forceConfidentialCommunications enabled="true"\/ ><\/code><\/pre>\n
Cookie-Domain und LDAP-Repository in WebSphere<\/h4>\n
Unter Security > Global security > Single sign-on (SSO)<\/strong> in die Textbox Domain name<\/strong> 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<\/em> entfernen und mit OK <\/strong>best\u00e4tigen:<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
Zum Abschluss der WebSphere-Konfiguration wird unser LDAP-Server unter Security > Global security<\/strong> hinzugef\u00fcgt. Dazu im unteren Bereich User account repository<\/em> auf Configure<\/strong> klicken:<\/p>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
\n
\"\"<\/a><\/figure>\n<\/div>\n
    \n
  1. Ist der Typ des LDAP-Servers. Im Falle von OpenLDAP wird Custom<\/em> verwendet. Soll ein bereits vorhandener Verzeichnisdienst zum Einsatz kommen, den Typ entsprechend anpassen (z.B. auf IBM Lotus Domino<\/strong>, hier w\u00e4re der DN der Base sp\u00e4ter dann „root“ – oder Microsoft Windows Active Directory<\/strong>).<\/li>\n
  2. Host und rechts daneben den Port des LDAP-Servers. In dieser Installation l\u00e4uft OpenLDAP auf dem zweiten Server zusammen mit der DB2.<\/li>\n
  3. DN und Zugangsdaten eines LDAP-Benutzers, der mindestens Lesebrechtung ben\u00f6tigt.<\/li>\n
  4. Die hier angegebenen Attribute (mehrere mit Strichpunkt; trennen) k\u00f6nnen von den Nutzern als Anmeldename verwendet werden. Mit uid;mail<\/strong> 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\u00e4llen.<\/li>\n<\/ol>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Nach dem Best\u00e4tigen 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\u00e4ne angeben (links).<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    \"\"<\/a><\/figure>\n
    Nach einem Klick auf OK<\/strong> sollte in der Liste das soeben angelegte Repository LDAP1<\/strong> mit dazugeh\u00f6riger Suchbasis (links) erscheinen. Damit ist die LDAP-Einrichtung abgeschlossen, mit Save<\/strong> im oberen Kasten wird die Konfiguration auf dem Deployment Manager gespeichert.<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Um die vorherigen \u00c4nderungen auf die Knoten (CnxNode01 in dieser Umgebung) zu verteilen, in der ISC auf System Administration > Nodes<\/strong>, dort CnxNode01 <\/strong>anhaken und oben Full Resynchronize<\/strong>.<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Da \u00c4nderungen an der LDAP-Konfiguration erst nach einem Neustart des Deployment Managers greifen, stoppen und starten wir diesen:<\/p>\n
    [root@cnx65-was cnx]# \/opt\/IBM\/WebSphere\/AppServer\/profiles\/Dmgr01\/bin\/stopManager.sh -username wasadmin -password adminwas\n[root@cnx65-was cnx]# \/opt\/IBM\/WebSphere\/AppServer\/profiles\/Dmgr01\/bin\/startManager.sh<\/code><\/pre>\n
    Bei 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<\/strong> erscheinen:<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Erster Start und Test<\/h4>\n
    Vor dem ersten Test starten wir die AppServer in der ISC unter Servers > Server Types > WebSphere application servers<\/strong>. Dazu oben auf Select All<\/strong> und Start<\/strong>:<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Nach einigen Minuten sollten alle gestartet sein und der Status auf gr\u00fcn stehen. Die Anzeige rechts wird nicht automatisch aktualisiert. Man kann entweder neben Status auf die Pfeile klicken, oder mit der Maus \u00fcber die Symbole fahren, um den aktuellen Status abzurufen.<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Da wir zuvor die Konfiguration des IHS-Plugins ver\u00e4ndert haben, ben\u00f6tigt dieser ebenfalls einen Neustart.<\/p>\n
    Wichtig: Das apachectl-Kommando ist asynchron!<\/strong> Es sendet ein Signal zum beenden an den IHS, wartet darauf allerdings nicht. Daher ist der Befehl schnell ausgef\u00fchrt und der IHS l\u00e4uft danach ggf. noch einige Sekunden weiter. Man sollte daher den Stop-Befehl absetzen, einige Sekunden warten und ihn erneut (Pfeil nach oben Taste) ausf\u00fchren. Erscheint hier der httpd not running<\/strong> Fehler, ist der IHS beendet. Andernfalls erneut einige Sekunden warten, bis man den Stop-Befehl erneut absetzt.<\/p>\n
    [root@cnx65-was cnx]# cd \/opt\/IBM\/HTTPServer\/bin\n[root@cnx65-was cnx]# .\/apachectl -k stop\n[root@cnx65-was cnx]# .\/apachectl -k stop\nhttpd (no pid file) not running\n\n[root@cnx65-was cnx]#.\/apachectl -k start<\/code><\/pre>\n
    Nun sollte Connections im Browser per HTTPS erreichbar sein. Da wir ein selbst signiertes Zertifikat verwenden, erscheint eine Warnmeldung. Im Firefox kann \u00fcber Advanced\/Erweitert<\/strong> und Accept the Risk and Continue\/Risiko akzeptieren und fortfahren<\/strong> die Seite aufrufen. Sollte man nat\u00fcrlich nur bei selbst angelegten Testumgebungen machen, niemals bei \u00f6ffentlichen\/fremden Internetseiten.<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Die erste Anfrage ben\u00f6tigt ein paar Sekunden, bis die Connections Loginseite erscheint. Dort sollte sich jeder LDAP-Nutzer anmelden k\u00f6nnen. Bei neuen Benutzern ist ein Sync \u00fcber den TDI n\u00f6tig, 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. <\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Dienste und Autostart<\/h3>\n
    Die Komponenten WAS Deployment-Manager, Node & IBM HTTP Server  sollten als Systemd-Units automatisch gestartet werden. Der TDI per Cron regelm\u00e4\u00dfig ausgef\u00fchrt. Doch das gen\u00fcgt nicht: Selbst wenn der WebSphere-Node l\u00e4uft, startet dieser nicht automatisch auch die AppServer von CNX. Dies muss h\u00e4ndisch in dessen Policy gesetzt werden.<\/p>\n
    AppServer automatisch starten<\/h4>\n
    In der ISC unter Servers > Server Types > WebSphere application servers<\/strong> auf jeden Server klicken, rechts Java and Process Management > Monitoring policy<\/strong> und Node restart state<\/strong> auf RUNNING <\/strong>stellen:<\/p>\n
    \n
    \"\"<\/a><\/figure>\n<\/div>\n
    Weiteres<\/h2>\n