Service

Oracle 12 auf AIX und die fehlenden Runtime Symbol Definitions

Beim Upgrade von Oracle Datenbanken sollte man beachten, dass hierfür eine Abhängigkeit zum AIX Service „iocp“ bedient werden muss. Ansonsten starten zum Beispiel listener, sqlplus oder auch abhängige Scripte wie mopatch nicht (da diese ebenfalls sqlplus nutzen).

So meldet sich sqlplus zum Beispiel mit dem folgenden Fehler und verweigert die Arbeit – Pfade und Environment stimmen natürlich 🙂

sapserver:orasap 29> ./sqlplus
Could not load program sqlplus:
rtld: 0712-001 Symbol CreateIoCompletionPort was referenced
      from module /oracle/SAP/121/lib/libttsh12.so(), but a runtime definition
            of the symbol was not found.
rtld: 0712-001 Symbol GetMultipleCompletionStatus was referenced
      from module /oracle/SAP/121/lib/libttsh12.so(), but a runtime definition
            of the symbol was not found.
rtld: 0712-002 fatal error: exiting.
sapserver:orasap 30> ldd sqlplus
sqlplus needs:
         /oracle/SAP/121/lib/libsqlplus.so
         /usr/lib/libc.a(shr_64.o)
         /usr/lib/libpthreads.a(shr_xpg5_64.o)
         /unix
         /oracle/SAP/121/lib/libttsh12.so
         /usr/lib/libcrypt.a(shr_64.o)
         /oracle/SAP/121/lib/libons.so
         /usr/lib/libdl.a(shr_64.o)
         /usr/lib/libc.a(aio_64.o)
         /usr/lib/libodm.a(shr_64.o)
         /usr/lib/libperfstat.a(shr_64.o)
         /usr/lib/libcfg.a(shr_64.o)
         /usr/lib/liblvm.a(shr_64.o)
         /usr/lib/libcorcfg.a(shr_64.o)
         /usr/lib/libsrc.a(shr_64.o)
sapserver:orasap 31>

Bei dem Aufruf von mopatch äußert sich das ganze verwirrender weise sogar so: [Read more…]

Zertifikate mit OpenSSL erstellen (Debian OpenSSL Bug)

Aus gegebenem Anlass habe ich mal zur Sicherheit das Zertifikat von Wesselonline neu erstellt. Da die Debian basierten Distributionen ja unter Umständen über einen Fehler in dem OpenSSL Paket angreifbar sind gab’s natürlich sehr zeitnah ein Update der betroffenen Programmpakete. Das Update allein nützt aber nichts, da ja die erstellten Zertifikate in der Regel noch in Benutzung sind und somit relativ leicht ausgehebelt werden können.

Recht vereinfacht lässt sich das so erklären: Bei der Erzeugung der Schlüssel werden mehrere zufällige Zahlen dazu benutzt, einen besonders einzigartigen Schlüssel zu erstellen, der durch die Nutzung von Unbekannten entsprechend sicher ist. Kennt man jedoch das Erstellungsverfahren und die Unbekannten, dann kann man einen erstellten Schlüsselcode berechnen. Die betroffenen OpenSSL Versionen haben leider einen solches Verhalten an den Tag gelegt. Als zufällige Zahlen haben die Pakete nur noch die Prozess-IDs mit einbezogen. Diese sind 15 bit groß und erlauben somit max. 32768 Prozesse oder verschiedene IDs auf einem unixartigen System (also auch Linux). Eine Zahl von 0 bis 32767 wurde also zur Schlüsselerstellung benutzt. Ergo braucht man max. 32768 (2^15) Versuche einen Schlüssel zu brechen. Und das ist durchaus machbar…

Also schnellstmöglich das Update einspielen:

apt-get update && apt-get upgrade -q -y

und anschließend neue Zertifikate erstellen. Die neuen Zertifikate kann man sehr schön zentral unter /etc/ssl/private/ ablegen. Das zentrale Ablegen der Schlüssel hat den Vorteil, dass mehrere verschiedene Dienste auf die Schlüssel zugreifen können ohne das man ihn in diverse Verzeichnisse linken oder gar kopieren müsste. Eine Änderung des Schlüssels würde also direkt nach dem Neustart der entsprechenden Dienste wie Postfix, Dovecot, Apache… etc. greifen.

[Read more…]