Novell Data Synchronizer

LogoBlogDie letzten Tage hatten es in sich. Einmal war ich immer mal wieder mit dem Bug von Kaspersky Antivirus beschäftigt, andererseits traten an einigen z.T. elementaren Diensten unserer Umgebung Fehler auf. Eines der Probleme betraf den Novell Data Synchronizer über den wir Mail-, Kontakt- und Kalendersynchronisation zwischen unserem Mailserver (Groupwise 2012) und mobilen Endgeräten (in erster Linie Androiden, 1 iPhones, 1 Blackberry) realisieren. Nach einem technisch begründeten Neustart des entsprechenden Servers lief die Synchronisation mit 2 Endgeräten nicht mehr und – viel auffälliger – die HTTP-Seite zur Verwaltung des Synchronizers liess sich nicht mehr aufrufen. Der Browser meldete einen SSL-Fehler und eine Prüfung des Status der Komponenten des Data Synchronizers per rcdatasync -status ergab, dass der webadmin nicht geladen wurde. Sein Status war das allseits beliebte unused.

 
Serverneustart und Neustart der Synchronisation per rcdatasync -restart brachten keine Veränderung. Eine Überprüfung der Log-Datei des Webadmin (/var/log/datasync/webadmin/server.log) machte den Fehler deutlich: der vom Webadmin verwendete Port 8120 war durch einen anderen Dienst blockiert. netstat -patune | grep 8120 zeigte, dass eine Instanz des Webservers diesen Port benutzte. Da diese Instanz keine große Bedeutung in unserer Umgebung besitzt wurde sie per kill beendet und der Webadmin liess sich per Kommando rcdatasync-webadmin start aufrufen und der Zugriff per Webkonsole war wieder problemlos möglich.
 
Status im „grünen“ Bereich 😉
 
Hier zeigte sich dann auch der Fehler mit den beiden Endgeräten, der sich per Neustart der Konnectoren und einer neu initiierten User-Synchronisation problemlos beheben liess.
 
Novell hat übrigens in einem TID alle für den Data Synchronizer, Filr, Groupwise 2012 und 8, Groupwise Mobile Server, Messenger und Vibe OnPrem relevanten IP-Ports aufgelistet. Wieder einmal vorbildliche Dokumentation. Zum schnellen Auffinden hier der Link zum Dokument …

Kaspersky Antivirus sorgt für höchste Sicherheit ;-)

LogoBlogSeit Jahren setzen wir in der Firma Kaspersky Antivirus auf den Windosen ein. Bisher immer zur vollsten Zufriedenheit. Seit gestern sorgt das Stück Software für Aufregung und – für mich – für Arbeit. Einige Rechner mit Windows 7 32bit werkelnd, hatten plötzlich keine Netzverbindung mehr. Auffallend war, dass nicht das Fehlen der gemappten Netzlaufwerke moniert wurde, sondern die fehlende Internetverbindung …

 
Am ersten Rechner stellte ich fest, dass die Treiberdatei tcpip.sys von Kaspersky als mit einem Trojaner infiziert eingestuft und in die Quarantäne gestellt wurde. Dummerweise ist die tcpip.sys aber die Treiberdatei für das „Internetprotokoll“ TCP/IP – wie der Name ja eigentlich schon verrät. Ohne das diese Treiberdatei geladen wird funktionieren alle auf TCP/IP beruhenden Verbindungen nicht mehr, sprich also heute sämtliche Netzverbindungen sind tot.
 
Mit einigen Handständen habe ich am ersten Rechner das Problem selbstständig gelöst – hätte ja sein können, dass am ersten Rechner die tcpip.sys tatsächlich korrumpiert worden ist. Als weitere Nutzer mit der selben Fehlermeldung kamen, zweifelte ich an der Massivität dieser Infektion, denn ein solcher Fall war mir in den vergangenen 7 Jahren in unserer an sich recht gut abgesicherten Umgebung bisher nicht untergekommen.
 
Nach einiger Internetrecherche dann des Rätsels Lösung: Kaspersky hatte durch ein fehlerhaftes Update dafür gesorgt das an den betroffenen Rechnern ein Höchstmass an Sicherheit erreicht wurde. Keine Netzverbindung heisst ja erst einmal, dass sämtliche Bedohungen von Aussen keine Chance haben, den entsprechenden Rechner zu infizieren … 🙂
 
Bei Kaspersky findet man inzwischen einen Workaround um das Problem zu beheben und hier in unserer Umgebung hat er sogar funktioniert …

Updates – ownCloud-Client und neptune-sysctl-config

Neben dem Update auf WordPress 3.7 gab es in der vergangenen Woche noch ein paar Änderungen des Systems. Als erstes wurde ein neuer ownCloud-Client veröffentlicht. Version ist nunmehr 1.4.2. Es handelt sich um ein Bugfix-Release, dieses Mal wurde neben dem Client selbst auch die zu Grunde liegende osync aktualisert. Changelog findet ihr hier. Die Installation wird empfohlen.

 
Daneben gab es wieder einige kleinere Updates beim Betriebssystem und wieder liess sich auf dem Heimrechner die neptune-sysctl-config nicht installieren. Mir ist immer noch unklar woran das liegen könnte. Mit Hilfe des von mir in diesem Artikel beschriebenen Workarounds konnte das Problem dann doch noch gelöst werden …