Random Number Generators in virtuellen Maschinen

Blockierendes /dev/random

Benötigt ein Prozess auf einem Linux Server eine Zufallsquelle, dann kann er hierfür auf die unter Linux Betriebssystemen üblichen Quellen /dev/random und /dev/urandom zurückgreifen. Hier gibt es einen wesentlichen Unterschied: random blockiert, wenn es keine hinreichend zufälligen Werte mehr liefern kann. Die Quelle urandom hingegen liefert weiter Werte, jedoch sind diese mit abfallender Entropie weniger zufällig.

Virtualisierte Server verfügen in der Regel nicht über Hardwareresourcen, welche sich eignen würden, um zufällige Startwerte für einen Zufallsgenerator zu bilden (beispielsweise ein Trusted Platform Modul, TPM). Auf Grund dessen erschöpft sich der Entropiepool hier sehr schnell und /dev/random liefert keine Werte mehr. Dies kann dann, wie in JDBC Zugriff auf Oracle-Datenbank scheitert mit I/O-Fehler: Connection reset (1) beschrieben, auch dazu führen, dass zwei Applikationen nicht verschlüsselt miteinander kommunizieren können.

Weiterlesen

JDBC Zugriff auf Oracle-Datenbank scheitert mit I/O-Fehler: Connection reset

Warum komme ich plötzlich nicht mehr an die Datenbank?

Mit einer unserer Java-Anwendungen hatten wir plötzlich ein unerklärliches Zugriffs-Problem auf die darunter liegende Oracle Datenbank. Nach der Installation der Anwendung auf einer neuen Virtuellen Maschine scheiterte jeder JDBC-Zugriff auf die Datenbank mit dem Fehler:

java.sql.SQLRecoverableException: I/O-Fehler: Connection reset

obwohl der Datenbank Server selbst nicht verändert wurde. Wir konnten den Fehler mit einer einfachen Test Klasse repoduzieren und es wurde schnell klar, es liegt weder an der Anwendung, noch am Datenbank-Server.

Weiterlesen

Upgrade einer Jenkins-Landschaft

Wir setzen schon seit langem erfolgreich Jenkins ein, allerdings war unsere benutzte Jenkins-Umgebung veraltet. Jenkins selber und die Slaves liefen noch mit JDK6 und die Jenkins-Version war 1.456. Also „sehr“ alt. Schon das Einspielen neuer Plugins war im Prinzip unmöglich, weil diese in der Regel auf Java7 basierten. Mengenmäßig haben wir 20 Jenkins Slaves mit 27 Projekten und 200 Jobs. Die Projekte sind in unterschiedlichen Zuständen (gerade erst aufgesetzt, mitten in der Entwicklung, kurz vor der Release oder Wartungsmodus). Der normale Projektablauf sollte durch die Umstellung nicht behindert werden.

Wir haben uns entschieden, keine schleichende Migration zu machen, sondern komplett auf eine neue Jenkins-Version zu setzen und dabei gleich die JDK Version zu aktualisieren.

Weiterlesen