fighting for truth, justice, and a kick-butt lotus notes experience.

Upgrading to Traveler 8.5.3 Upgrade Pack 1 - Trouble Shooting

 Juli 11 2012 02:19:42 PM
Seit dem 26.Juni 2012 steht ja bekanntlich die neue Traveler Version 8.5.3 UP 1 (a.k.a Traveler HA) bereit und einige Mutige haben inzwischen ihre Server aktualisiert.
Bei mir haben sich nun einige Kunden gemeldet und sind vor das Problem gelaufen, das das Upgrade zwar erfolgreich installiert werden konnte, aber entweder der Traveler Task nicht mehr gestartet werden konnte oder die Devices nicht mehr synchronisieren konnten.

Im Folgenden möchte ich einmal zusammenstellen, was Ursache für die bei mir bisher gemeldeten Probleme sein kann und eine mögliche Lösung aufzeigen:

1.
Fehlermeldung auf der Console und Devices synchronisieren nicht mehr:

HTTP JVM: Error occurred while loading Servlet (traveler)
HTTP JVM: java.lang.ClassNotFoundException: traveler: traveler


Generell muß man einmal im Hinterkopf behalten, das mit Traveler 8.5.3 UP 1 sich die Software-Architektur im Hintergrund grundlegend geändert hat.

Bisher kommunizierte das Endgerät über den HTTP-Task mit einem Servlet, daher auch die Zugriffs-URL https://hostname/servlet/traveler, das im "alten" Domino Servlet Container betrieben wurde. Traveler 8.5.3 UP1 verwendet nun nicht mehr das klassische Servlet, sondern ein OSGI-Plugin, welches über https://hostname/traveler angesprochen wird.
Damit die bereits installierten Devices mit der alten URL weiterhin noch synchronisieren können, richtet der Installer beim Upgrade automatische eine URL Ersetzungsregel ein, die die eingehende URL /servlet/traveler nach /traveler umsetzt.
Fehlt diese Regel und  es greift ein Traveler Device noch über die alte URL zu kommt es zu dieser Meldung.

Drei Dinge sind nun zu prüfen:

a. Prüfen, ob im Domino Directory des Traveler Servers, die obige URL-Ersetzungsregel vorhanden ist. Wenn nicht vorhanden, dann manuell erstellen.

Details sind hier zu finden: Traveler Wiki: Manually configuring the HTTP server

Warum wurde nun die URL-Ersetzungsregel nicht angelegt?

b. Die Ursache für die fehlende Regel kann daran liegen, das der Traveler Server keine lokalen Schreibrechte auf das lokale Names.nsf hat.

c. Der Notes.ini Eintrag NTS_AUTO_CONFIG vor dem Erststart war auf false gesetzt. In diesem Fall wird ebenfalls keine URL-Ersetzungsregel angelegt.


2.
Installation ist durchgelaufen, aber der Traveler Server Task startet nicht.

Auf der Console sieht man, lediglich:

Lotus Traveler: Server starting...

Lotus Traveler: Server stopping...

Lotus Traveler: Server stopped.


Oder:

HTTP JVM: Traveler: Exception during init: com.lotus.sync.util.ComponentNotStartedException: Configuration parameter NTS_HOST_IP_ADDR must have a valid value


Ursache hierfür kann die lokale Namensauflösung oder ein System mit mehreren gebundenen IP-Adressen sein. Für diesen Fall gibt es den Notes.ini-Eintrag NTS_HOST_IP_ADDR.
Dieser sollte immer die lokale IP-Adresse des Traveler Servers beinhalten. Als Beispiel: NTS_HOST_IP_ADDR = 192.168.100.127  (default = "").

3. SSL funktioniert nicht mehr nach dem Update des Servers


Nach dem Update des Servers konnten sich Endgeräte nicht mehr mit dem Traveler Server verbinden, obwohl alle Tasks gestartet werden konnten. Nach Sichtung der Umgebung stellte sich heraus, das mit dem Update der Eintrag im Serverdokument für den SSL Key File Name überschrieben und der Default-Name keyfile.kyr eingetragen wurde.

Image:Upgrading to Traveler 8.5.3 Upgrade Pack 1 - Trouble Shooting

Das auf dem Server befindliche Keyfile heißt aber anders. Wir haben uns die Mühe gemacht und das Backup vom Vortag wiederhergestellt und es war eindeutig, das der Eintrag durch das Update geändert wurde.
Nach Hinterlegung des richtigen Dateinamens lief der Traveler Server auch wieder.

4. Geduld mitbringen, da der erste Start des Traveler Server Tasks bis zu einer Stunde dauern kann.


Während des ersten Starts des Traveler Server nach der Update Installation wird die Derby Datenbank defragmentiert & das DB Schema erweitert.
Je nach Größe der alten Derby Datenbank (& somit Anzahl der konfigurierten Devices) kann die Defragmentierung und die Migration des Derby Datenbankschemas länger dauern.

Es ist nicht ungewöhnlich, das dies mehr als eine Stunde dauert. Hier hilft einfach nur Geduld und das Update in einem kommunizierten Wartungsfenster durchzuführen.


Archive