VirtualBox Shared Folder

Die VirtualBox ist eine gute Alternative zu VMware & Co, die zudem unter der GPL steht. Recht praktisch sind die "Shared Folder", mit denen man ein Verzeichnis des Gastgebes freigeben und vom Gast aus zugreifen kann. Realisiert ist das für Windows als CIFS-Freigabe. Leider bekommt man leicht eine Meldung in der Art "Fehler 67" Name nicht gefunden. Die Ursache hierfür ist sind fehlende oder falsch installierte Gasterweiterungen. Mir ist es passiert, dass ich eine Virtuelle Maschine unter Linux mit Version 1.5.0 installiert habe und dann unter MacOS X mit Version 1.4 nutzen wollte und eben diesen Fehler erhielt. Zur Lösung habe ich die Gasterweiterungen deinstalliert

• mit "regedit" im magischen "Run"-Verzeichnis das Starten der Gasterweiterungen entfernt
• kurzfristig den Grafikkartentreiber umgestellt und beim obligatorischen Reboot dann die automatische Hardwareerkennung abgebrochen habe
• die Dateien aus C:\Programme und C:\Windows\System32 gelöscht (alles mit "innoprakt" und "vbox" im Namen)

Danach kann man die restlichen Dateien entfernen und die älteren Gasterweiterungen installieren. Und schon klappt auch das

net use x: \\vboxsvr\share

Auf JBoss von Außen zugreifen

JBoss lauscht von Hause aus auf der lokalen Adresse, spricht 127.0.0.1. Will man über das Netzwerk darauf zugreifen, muss man ihn mit

run.sh -b

starten, wobei man auch

run.sh -b 0.0.0.0

angeben kann, dann akzeptiert er Verbindungen auf allen Adressen. Auf meinem Ubuntu kam es aber dazu, dass der InvokerLocator noch auf 127.0.0.1:3873 lauschte, was sich so zeigt:

> netstat -ln | grep 3873
tcp 0 0 127.0.1.1:3873 0.0.0.0:* LISTEN

bzw. auf dem Client durch diese Exception:

org.jboss.remoting.CannotConnectException: Can not get connection to server. Problem establishing socket connection for InvokerLocator [socket://127.0.1.1:3873/]

Durch sehr genaues Hinschauen merkt man, dass dort 127.0.1.1 steht, was einen dazu bringt, man in der Datei /etc/hosts nachzusehen:

127.0.1.1 ubuntu

und da hat man den Schuldigen gefunden: JBoss bestimmt den Namen, unter dem er erreichbar zu sein glaubt und lauscht nur auf dieser Adresse. Trägt man hier die richtige eigene Adresse ein, am besten mit dem kompletten Namen, dann funktioniert es auch, also beispielsweise

192.168.1.31 ubuntu.local

JDK 1.3.1 unter Feisty/Gutsy

Installiert man das Sun JDK 1.3.1 unter Ubuntu/Feisty oder Gutsy, so erhält man beim Starten folgende Fehlermeldung:

/opt/jdk1.3.1_20/bin/i386/native_threads/java: error while loading shared libraries: libstdc++-libc6.1-1.so.2: cannot open shared object file: No such file or directory

weil die entsprechende LibC nicht mehr unter diesem Namen verfügbar ist (das mit den unterschiedlichen inkompatiblen (G)LIBC-Versionen hab ich eh noch nie verstanden). Das Problem lässt sich glücklicherweise mit 3 Befehlen beheben:

sudo apt-get install libstdc++2.10-glibc2.2
cd /usr/lib
sudo ln -s libstdc++-3-libc6.2-2-2.10.0.so libstdc++-libc6.1-1.so.2

Danach klappt es auch wieder mit dem Java:

/opt/jdk1.3.1_20/bin/java -version
java version "1.3.1_20"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.3.1_20-b03)
Java HotSpot(TM) Client VM (build 1.3.1_20-b03, mixed mode)

Maven-Archiva zum Laufen bringen

Archiva erlaubt es, einen zentralen Server für JAR-Dateien aufzusetzen, der von Maven verwendet wird. Es arbeitet als Caching-Proxy, so dass die Pakete nur einmal heruntergeladen werden müssen. Ebenso können damit die intern erstellten Pakete leicht für alle Entwickler zugängig gemacht werden.

Bei der Installation bin ich über mehrere Probleme gestolpert:

Port ändern
Der Port steht in der Datei apps/archiva/conf/application.xml; diese Datei existiert erst nach dem Auspacken der JAR-Datei, was beim ersten Start passiert.

Authentisierung notwendig
Archiva wollte unbedingt Benutzername und Passwort haben. Nachdem ich im User Management dem Guest die Rolle Global Repository Observer gab, ging es auch ohne.

Keine Downloads
Archiva wollte partout keine Pakete runterladen. Nachdem ich bei beiden Proxy Connectors der Whitelist ein **/** hinzugefügt hatte, ging es.


Jetzt kämpfe ich nur noch damit, dass das Eclipse-Plugin die Einstellungen ignoriert und direkt auf das central-Repository zugreift.

Umlaute mit Kopete und ICQ

Schon länger hat mich geärgert, dass mein Kopete bei ICQ die Umlaut als chinesische Zeichen darstellt. Da ich gerade in Bahrain auf den verspäteten Flieger warte, habe ich Zeit gefunden, nach einer Lösung zu suchen; und diese war überraschend einfach: in den Zugangs-Einstellungen zu ICQ die "Standardkodierung für Nachrichten" auf "ISO-8859-15" stellen.

Cisco VPN client unter Linux

Viele Unternehmen verwenden den Cisco VPN Client, um den verschlüsselten Zugriff auf ihr Netzwerk zu erlauben. Es gibt hierfür zwar einen Linux-Client, aber den hab ich nicht zum Laufen gebracht. Viel besser ist VPNC von den Jungs aus Kaiserslautern, das beim aktuellen Ubuntu enthalten ist.

Die Installation gestaltet sich sehr einfach: zuerst mit dem mitgelieferten Programm pcf2vpnc die .PCF-Datei konvertieren:

/usr/share/vpnc/pcf2vpnc vpn.pcf > vpn.conf

und dann den Zugang starten, wobei der vollständige Pfad zur Konfigurationsdatei angegeben werden muss:

sudo vpnc $PWD/vpn.conf

Wer die Passwörter nicht jedes Mal eintippen will, kann sie auch in der Konfigurationsdatei hinterlegen:

Xauth username Benutzername
Xauth password Passwort

Sehr praktisch sind auch die Optionen Target network und DNSUpdate: damit kann man das VPN auf bestimmte IPs oder IP-Bereiche einschränken sowie das Umstellen des DNS verhindern:

Target networks 192.168.1.17/32 192.168.2.0/24
DNSUpdate no

Richtig konfiguriert hat man damit eine reine Punkt-zu-Punkt-Verbindung zu den Zielrechnern und hat nicht mehr die Einränkungen eines deaktivierten "Allow Local LAN Access".

Derby und OutOfMemoryError

Nachdem ich heute wieder mal mehrere Stunden im Derby rumgewühlt habe, hab ich Folgendes zum Derby-Cache gefunden:

"Derby autotunes the database pagesize. If you have long columns, the default pagesize for the table is set to 32K. Otherwise, the default is 4K."

"long columns" sind beispielsweise VARCHAR(32000). Die Standard-Cachegröße ist 1.000 Pages, damit belegt Derby konkret 32MB für seinen Cache, nicht schlecht wenn man bedenkt, dass die JVM standardmäßig nur 64MB hat. Die Folge ist oftmals diese Fehlermeldung:

Exception in thread "main" java.sql.SQLException: Java exception: 'Java heap space: java.lang.OutOfMemoryError'.

Netterweise ist dieser Satz nicht bei den entsprechenden Konfigurationsoptionen - dort steht "Default: 4096" - sondern auf der Seite "Performance trade-offs of large pages". Da guckt man natürlich nicht direkt rein, wenn man die Seitengröße gar nicht ändern will.

Zum Ändern der Seitengröße muss man diese Properties beim Programmstart setzen (hier mit den Standardwerten), wobei die Seitengrölße vor einem CREATE TABLE bzw. CREATE INDEX bereits gesetzt sein muss.

System.setProperty("derby.storage.pageCacheSize", "1000");
System.setProperty("derby.storage.pageSize", "4096");

geht natürlich auch über -Dderby.storage.pageCacheSize=1000 bzw. -Dderby.storage.pageSize=4096 beim Aufruf der JVM.