Sametime 11, keine Anmeldung möglich

[schroederk]

Hallo,

ich habe einen neuen Domino Server aufgesetzt (CentOS 8.2.2004 mit Domino 11.0.1FP2).
Darauf den Community Server und Proxy Server installiert (11.0FP2).
Leider kann ich mich am Sametime Server weder über den embedded Client (Notes Client 11.0.1FP1) noch über Web anmelden (Der Vorgang konnte nicht ausgeführt werden)
Wenn ich einen falschen Benutzernamen oder ein falsches Passwort verwende, erscheint die Meldung "Geben Sie eine gültigen Benutzernamen und ein Kennwort ein", daher scheint die Authentifizierung schonmal zu funktionieren, aber danach geht es nicht weiter.

Leider finde ich auch in den Logs im Trace-Verzeichnis (VP_TRACE_ALL=1) nichts (das übrigens im Data-Verzeichnis liegt und nicht wie in der Doku beschrieben, im Programm-Verzeichnjs)
Nett auch, dass das Kennwort in der stusers.txt im Klartext steht. Wenn der Server mal läuft kann ich damit alle Kennwörter aller Mitarbeiter auslesen. 

Im Moment vermute ich ein Problem mit dem Proxy-Server (wird der denn auch für die internen Benutzer immer benötigt?)
Denn dort steht im Log, dass der keinen Community-Server gefunden hat (There is no Sametime community Server available.) oder sich zumindest nicht mit einem verbinden kann (Unable to log in to the Sametime community server ... Error message is 8000021c)
Wobei hier der falsche (alte 8.5.3er) Sametime-Server genannt wird.
Liegt das vielleicht daran, dass beim Global-Adressbook-Eintrag von mir der alte Servername unter Kooperation und Sametime-Server steht? (Andernfalls weiß ich nicht, woher der Proxy Server die Information hat)

[Tode]

Hmm... das sind eigentlich zu viele verschiedene Fehler, um die hier in einem Post abzuhandeln...

- Wenn anmelden im Client nicht geht, kann das mit fehlendem / falschem LTPAToken oder fehlendem / falschem Internetkennwort oder falschem Hostnamen zu tun haben... das hängt davon ab, wie Du das konfiguriert hast (Client & Server)
--> Kein Proxy involviert

- Wenn anmelden im Proxy nicht geht, dann kann das an der falschen LDAP- Konfiguration des Proxies liegen oder an einem fehlenden Zugriff auf die MongoDB oder an anderem...

- Dass Proxy und Sametimeserver den ALTEN Sametime Server finden und als "zur Domäne zugehörig" identifizieren ist normal... da muss man ggf. noch Trusted IP Adressen setzen, dass das auch alles funktioniert...

[schroederk]

Ok, konzentriere ich mich erstmal auf die Webanmeldung.

Wenn ich das also richtig verstehe, dann wird für die Web-Anmeldung der Proxy-Server verwendet, für den embedded Client nicht.
Bei der Webanmeldung scheint das Passwort ja akzeptiert zu werden, da bei Eingabe eines falschen Passworts eine andere Fehlermeldung erscheint.

LDAP ist nicht konfiguriert, es soll das Domino Adressbuch genutzt werden.
In den Einstellungen (sind ja eigentlich nur die 3 Dateien: setenv.sh, stproxyconfig.xml und server.xml) war für Mongodb kein Benutzer und kein Passwort hinterlegt. Aber auch nach dem Eintragen derer keine Änderung.

In der stconfig.nsf habe ich alle unsere Domino-Server als Trusted-IPs hinterlegt.

Im Log steht im Moment nur noch sowas:

WARNING [Chuck the postman's dispatching thread.7] com.ibm.rtc.stproxy.cluster.ServerLogin.loggedOut CLFRX0011W: Unable to log in to the Sametime community server CN=ALTERSAMETIME/OU=SRV/O=Company Error message is 8000021c

[Tode]

Der Proxy versucht sich, beim ALTEN Sametime anzumelden. Du musst also am alten Sametime die IP des neuen Proxy eintragen, um die Meldung loszubekommen... Wenn Du im Personendokument einen Sametime- Server hast, dann nimmt der Proxy den... dann verwendest Du den neuen gar nicht....

Wegen MongoDB: Hast Du denn MongoDB überhaupt installiert und konfiguriert? Sonst geht der Proxy nämnlich gar nicht...

[schroederk]

Kann ich denn dem Proxy nicht sagen, dass er den neuen Sametime nehmen soll? Z.B. in meinem Personendokument den neuen Server bei Sametime eintragen?
Ich hab die IP jetzt zwar auch beim alten eingetragen, aber den muss ich dann ja auch erstmal wieder neustarten.
Ich würde gerne die neue Umgebung komplett parallel aufbauen und erst später irgendwann den alten abschalten.

Wegen MongoDB: Ja, habe ich als erstes installiert und konfiguriert. Version 4.2.9.

[schroederk]

Einen kleinen Schritt weiter bin ich jetzt. Nachdem ich auf dem alten Sametime die IP des neuen als Trusted IP eingetragen und Sametime neugestartet habe,
scheint die Anmeldung jetzt durchzulaufen.
Allerdings hängt er jetzt auf der Seite https://neuerserver.domain.de:8443/chat/conversations.
Es ist alles (Person suchen und eine neue Nachricht schreiben) ausgegraut und die "Eieruhr" (roter Kreis) läuft ewig.

Leider ohne jegliche Fehlermeldungen. Auch im Logs kann ich nichts finden.

[Tode]

Du weiss aber schon, dass aktuell MongoDB nur in Version 3.6 supported ist? Hast Du alle Schritte aus dieser Anleitung EXAKT befolgt?
Stimmen die Inhalte der dbconfig.properties auf dem Proxy?

[MaVo]

Du weiss aber schon, dass aktuell MongoDB nur in Version 3.6 supported ist?

@Tode: es scheint, dass die Systemvoraussetzungen aktualisiert wurden, wenn "HCL Sametime® 11.0 FP2 | HCL Sametime® Meetings Pre-Release 11.5 System Requirements" genutzt wird. mongodb 3.6 und höher.
https://support.hcltechsw.com/csm?id=kb_article&sysparm_article=KB0079273

[Tode]

wusste doch, dass ich das irgendwo gelesen hatte.... habe es aber beim Googeln gerade nicht mehr gefunden, und dachte deshalb ich hätte mich geirrt... Die Sache ist halt: Wenn Mongo nicht genau richtig konfiguriert ist, und im Proxy in der dbconfig.properties nicht alles richtig drin steht, dann geht der Proxy einfach nicht, weil der seinen Chat in die MongoDB speichert und aus der MongoDB lädt...

[schroederk]

Du weiss aber schon, dass aktuell MongoDB nur in Version 3.6 supported ist? Hast Du alle Schritte aus dieser Anleitung EXAKT befolgt?
Stimmen die Inhalte der dbconfig.properties auf dem Proxy?

Also eigentlich habe ich diese Anleitung befolgt und da ist die MongoDB wohl auch für 4.2 freigegeben.

In der dbconfig.properties fehlte tatsächlich der Eintrag für DOMINO_TARGET_SERVER und MONGO_USER und MONGO_PASSWORD.
Wobei MONGO_USER und MONGO_PASSWORD nach dem Neustart vom Proxy offenbar automatisch wieder zurückgesetzt wird (ebenso in der setenv.sh=

Das Verhalten hat sich mit der Korrektur des Eintrags leider nicht verändert.

MONGO_HOST=127.0.0.1
MONGO_CONNECT_TIMEOUT=1000
OFFLINE_DATABASE=MONGO
MONGO_WRITE_CONCERN_W_VAL=1
MONGO_AUTHID=c2FtZXRpbWVVc2VyLHNhbWV0aW1l
MONGO_PORT=27017
MONGO_WRITE_CONCERN_J_VAL=0
MONGO_IMG_LIMIT=20480
MONGO_DBNAME=mobileOffline
HTTP_CLIENT_TOTAL_CONNECTION=100
MONGO_USER=
DOMINO_TARGET_SERVER=stcommunity.domain.de
MONGO_GFS_CONNECT_TIMEOUT=2000
MONGO_PASSWORD=
MONGO_AUTH_DBNAME=admin
HTTP_CLIENT_MAX_CONNECTION_PER_ROUTE=20
HTTP_CLIENT_MAX_FOR_HOST=5

[schroederk]

Nachtrag: hier noch das Ergebnis von rs.conf()

rs0:PRIMARY> rs.conf()
{
        "_id" : "rs0",
        "version" : 1,
        "protocolVersion" : NumberLong(1),
        "writeConcernMajorityJournalDefault" : true,
        "members" : [
                {
                        "_id" : 0,
                        "host" : "127.0.0.1:27017",
                        "arbiterOnly" : false,
                        "buildIndexes" : true,
                        "hidden" : false,
                        "priority" : 1,
                        "tags" : {

                        },
                        "slaveDelay" : NumberLong(0),
                        "votes" : 1
                }
        ],
        "settings" : {
                "chainingAllowed" : true,
                "heartbeatIntervalMillis" : 2000,
                "heartbeatTimeoutSecs" : 10,
                "electionTimeoutMillis" : 10000,
                "catchUpTimeoutMillis" : -1,
                "catchUpTakeoverDelayMillis" : 30000,
                "getLastErrorModes" : {

                },
                "getLastErrorDefaults" : {
                        "w" : 1,
                        "wtimeout" : 0
                },
                "replicaSetId" : ObjectId("5f7ad1968fd76ab2c3dbad64")
        }
}

[schroederk]

Ich bin noch immer keinen Schritt weiter. 

Was mir bei der sametime.ini aufgefallen ist. Das Format der Datei scheint wohl DOS/Windows zu sein, denn hinter jeder Zeile steht ein "^M".
Stört das eine Linux-Installation, sollten die drin stehenbleiben oder kann das weg? (z.B. über dos2unix oder vim Befehl)

Der HCL Support ist auch involviert, übt sich aber (wie immer) im tagelangen Analysieren von Logs.

[Tode]

Wegen des "^M": Das kannst Du rauseditieren so lange Du willst... Sametime konvertiert das jedesmal wieder um, warum auch immer... ist also keine mögliche Fehlerursache...

[heini_schwammerl]

Das MongoDb Replica Set ist in meiner Konfiguration an den Hostnamen gebunden. Ich kann mich nicht mehr erinnern warum, aber es wird schon einen Grund haben warum ich das geändert habe ;-)
Eine Aktualisierung von 3.6 auf 4.2 verlief auch problemlos, wenn man mal vom Rumgezicke von MongoDb absieht wofür HCL nichts kann.

Code

"host" : "vsametime.dmz.firma.de:27017",

anstatt

Code

"host" : "127.0.0.1:27017",

Zusätzlich läuft bei mir der Proxy auf einer 2. IP Adresse aber das ist prinzipiell ohne Bedeutung.

Die  DbConfig vom Proxy bleibt dabei unspektakulär

Code

MONGO_HOST=localhost
MONGO_CONNECT_TIMEOUT=1000
OFFLINE_DATABASE=MONGO
MONGO_WRITE_CONCERN_W_VAL=1
MONGO_AUTHID=...
MONGO_PORT=27017
MONGO_WRITE_CONCERN_J_VAL=0
MONGO_IMG_LIMIT=20480
MONGO_DBNAME=mobileOffline
HTTP_CLIENT_TOTAL_CONNECTION=100
MONGO_USER=
DOMINO_TARGET_SERVER=127.0.0.1
MONGO_GFS_CONNECT_TIMEOUT=2000
MONGO_PASSWORD=
MONGO_AUTH_DBNAME=admin
HTTP_CLIENT_MAX_CONNECTION_PER_ROUTE=20
HTTP_CLIENT_MAX_FOR_HOST=5

mongodb.conf (Auszug)

Code

# network interfaces
net:
  port: 27017
  ipv6: true
  bindIp: 127.0.0.1,192.168.1.23,::1

Die 2. IP Adresse ist eine lokale DMZ IP an welcher auch der Hostnamen gebunden ist.
Sametime Proxy und der Server funktionieren seit dem letzten Fixpack vor ein paar Wochen prinzipiell. Vorher ging allerdings wenig, was mich doch ein wenig verärgert hat. Aber besser spät als nie.
Hinweis: Die Konfiguration ist nicht geeignet für einen MongoDb Server der direkt im Internet steht.
Gruß

Henning

[MaVo]

Das MongoDb Replica Set ist in meiner Konfiguration an den Hostnamen gebunden. Ich kann mich nicht mehr erinnern warum, aber es wird schon einen Grund haben warum ich das geändert habe ;-)

Henning, vermutlich wegen diesem KB Artikel 
HCL Sametime 11 clients fail when MongoDB host is not configured correctly on the Community server

When MonogDB is deployed to a different host than the Community and the REPLICA_SET has the wrong hostname for the MongoDb server, the following symptoms will be reported by HCL Sametime 11 clients.

• Webclients using /chat will not see messages sent or received.  History may load on login, but messages after that will not be seen.
• HCL Sametime 11 Mobile Clients will not log in successfully.  There will be a long delay attempting to login, before any error is returned.

The above scenarios suggest Persistent Chat, specifically the connection to MongoDB, is not working correctly.  One common reason for this is  the MongoDB replication configuration is providing a hostname that is incorrect or unresolvable by the Community or Sametime Proxy servers.

[schroederk]

Ich meine, dass ich am Anfang den Hostnamen drinstehen hatte und da gab es Probleme beim Start von Sametime, dass der Host nicht gefunden wurde. Möglicherweise, weil ich da noch nicht die mongodb.conf hatte. Ich hatte dann auf 127.0.0.1 zurückgestellt und damit startete Sametime.

Jetzt bekomme ich aber die Konfiguration nicht mehr geändert.

Code

cfg = rs.conf()
cfg.members[0].host = "meinedomain.de:27017"
rs.reconfig(cfg)

Ich erhalte die Fehlermeldung:

No host described in new configuration 2 for replica set rs0 maps to this node.

[schroederk]

Hmm... nach einem

Code

use admin
db.shutdownServer()

und einem anschließenden

Code

service mongod start

konnte ich jetzt den Host problemlos ändern 

[schroederk]

Am Anmelde-Problem hat sich aber leider nichts geändert.
Der Support von HCL hängt sich aktuell am Web SSO Token auf.

In der sametime.ini folgendes eingetragen:

Code

ST_TOKEN_TYPE=LtpaToken Sametime^M
ST_ORG_NAME=^M

Und im Globalen Adressbuch in meinem Personendokument den Eintrag bei Sametime-Server entfernt (da stand der noch aktive alte Sametime-Server drin).

Community-Server und Proxy neugestartet, aber auch keine Änderung.


 

[heini_schwammerl]

Also der LTPA Eintrag ist ja normalerweise eher unspannend. Ich hänge meinen mal an
und meine Sametime.ini (gekürzt)

Code

# Sametime configuration file
[AuthToken]
STAuthenticationMethod=0
 
[Config]
ST_COMMUNITY_ID=Augsburg
VP_SECURITY_LEVEL=7000
VPMX_CAPACITY=20000
VPS_IGNORE_UNKNOWN_CLIENT_IP=1
[...]
VP_PRIV_SYM=1
ClusterGroupAffinity=Isolation
VPS_PREFERRED_LOGIN_TYPES=14C4,14C3,14C2,14C1,14B6,14B4,14B2,14AF,14AD,14A2,14A0,1454,1453,1452,1451,1443,143F,143E,143D,143C,
143B,143A,1439,1438,1437,1436,1435,1434,1312,1311,130F,130E,130D,130C,130B,130A,1308,1306,1304,12A2,129D,129C,129B,129A,122B,122A
ST_BRANDING_INFO=standard
EnableUnyteHomepageUI=1
ST_JAVA_LIB_PATH=/opt/hcl/domino/notes/11000000/linux
IMOnly=0
STOFFLINE_MSGS_EXCLUDE_CLIENT_TYPES=100A,101A,1200,1431,1432,1434,1435,1437,143E,143F
ST_CL_MONGODB=1
VP_ONLY_SINGLE_LOGIN_ALLOWED=0
VP_NEWER_LOGIN_WINNER=1
[...]
# ST_CONFIG_XML=/local/notesdata/StCommunityConfig.xml
HTMLRootDirectory=/local/notesdata/domino/html
ConfigurationHost=vsametime.dmz.company.de
VPS_LOCALHOST=vsametime.dmz.company.de
[...]
# 2020-01-07 HH eingefügt
VPS_NAME=CN=Sametime/OU=Srv/O=Company
ConfigurationPort=8080
SametimeCluster=CN=Sametime/OU=Srv/O=Company
SametimeDirectory=/local/notesdata
Locale=de
 
SametimeEventServerPort=9092
[...]
VPMX_SINGLE_IP_PORT=80,443,563
ST_CONFIG_XML=/local/notesdata/StCommunityConfig.xml
[...]
[ST_BB_NAMES]
ST_CHAT_DATABASE=mongodb
NWAY_PRIMARY_KEY=OrigSId
FLEXNET_URL=
ST_CHAT_LOG=mongodb
ST_AUTH_TOKEN=notes
[...]

In der stconfig.nsf
In den CommunityServices Einstellungen das Chat Logging Flag auf relax

Ansonsten muss man leider vermutlich das Debugging erhöhen und dann mal schauen was er unter /local/notesdata/trace
so alles erzählt.
Die von Dir erwähnten Einträge sind bei mir auf den ersten Blick gar nicht vorhanden.
Gruß

Henning

[schroederk]

Ich habe Deine Sametime.ini mit meiner verglichen und folgende Unterschiede festgestellt:

ST_COMMUNITY_ID=
ConfigurationPort=80
locale=en

Könnten diese tatsächlich mein Problem verursachen?