Java druckt nicht unter Ubuntu 7.10

Versucht man unter Ubuntu 7.10 aus einem Java-Programm etwas heraus zu drucken, so erhält man auf den meisten Systemen diese Exception:

java.lang.NullPointerException: null attribute
at sun.print.IPPPrintService.isAttributeValueSupported(IPPPrintService.java:1147)
at sun.print.ServiceDialog$OrientationPanel.updateInfo(ServiceDialog.java:2121)
at sun.print.ServiceDialog$PageSetupPanel.updateInfo(ServiceDialog.java:1263)

die Ursache hierfür ist die Drehbarkeit der Seite in CUPS v1.3. Hierbei wird beim Modus "automatisch" ein Nullpointer zurückgegeben, mit dem die aktuelle Java-Version noch nichts anfangen kann:

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6633656

Damit man trotzdem drucken kann, muss man entweder

• die Seitendrehung von "automatisch" auf einen festen Wert stellen
• CUPS auf eine ältere Version umstellen

Da bei meinem Drucker die erste Option nicht ging, hab ich die zweite realisiert. Hierzu musste ich zuerst in der Datei /etc/apt/sources.list Feisty als Quelle angeben:

deb http://de.archive.ubuntu.com/ubuntu/ feisty main restricted

Dann in der Datei /etc/apt/preferences - die ich neu erstellen musste - folgenden Eintrag machen:

Package: cupsys
Pin: version 1.2.8-*
Pin-Priority: 1001

Danach kann man mit

sudo apt-get update
sudo apt-get upgrade

die Version von CUPS auf die ältere deaktualisieren und das Drucken klappt wieder.

Sprache bei Ubuntu/Gutsy ändern

Ich sag's ja, wenn man Windows-Administratoren Linux-Maschinen installieren lässt: bei der Installation "Englisch" als Sprache ausgewählt! Klar, unter Windows macht man das so, damit man die Updates früher bekommt, bzw. damit Dritt-Software überhaupt funktioniert. Also die Sprache umstellen. Der altbekannte Weg

sudo dpkg-reconfigure localeconf

funktionierte unter Feisty, aber unter Gutsy nicht mehr. Hier muss man händisch die Datei

/etc/default/locale

Folgendes eintragen:

LANG="de_DE.UTF-8"

noch das Sprachpaket installieren:

sudo apt-get install language-pack-de

dann das altbewährte

sudo dpkg-reconfigure locales

und schon hat man nach einem Relogin alles auf Deutsch. Genauer beschrieben ist es hier:

http://wiki.ubuntuusers.de/Spracheinstellungen

nVidia Netzwerkkarten, Hibernate/Suspend und fehlende Netzwerkkonfiguration

Ich habe einen nVidia Corporation CK8S Ethernet Controller auf meinem Asus Board. Nach einem Suspend erhält die Karte keine IP-Adresse mehr. Den Grund dafür liefert ein dmesg:

0000:00:05.0: Invalid Mac address detected: 71:4a:28:d8:11:00
Please complain to your hardware vendor. Switching to a random MAC.

Bzw ein ifconfig, der nach jedem Suspend/Resume-Zyklus eine neue Netzwerkkarte (eth1, eth2 usw) anzeigt.

Aha: nach jedem Resume wechselt die MAC-Adresse, woraufhin mein Ubuntu von einer neuen Netzwerkkarte ausgeht. Ein Blick in /etc/udev/rules.d/70-persistent-net.rules zeigt auch das ganze Ausmaß der Katastrophe: viele Einträge mit unterschiedlichen MAC-Adressen. Laut einem Forums-Post handelt es sich hier um "reversed IP-address", was man im BIOS abstellen kann. Wer keine entsprechende Option findet, oder wie ich keine Lust hat, den Rechner neu zu starten, der stellt seine Netzwerkkonfiguration von MAC-Adresse auf PCI-Adresse um: die korrekte PCI-Adresse steht in der dmesg-Ausgabe; alternativ kann man auch die Ausgabe von lspci für die Netzwerkkarte verwenden und "0000:" davor schreiben (wer hat schon mehrere PCI-Busse installiert?). Dann passt man die Datei

/etc/udev/rules.d/70-persistent-net.rules

an, indem man den Eintrag

SUBSYSTEM=="net", DRIVERS=="?*", ATTRS{address}=="00:11:d8:28:4a:71", NAME="eth0"

durch

SUBSYSTEM=="net", DRIVERS=="?*", ID=="0000:00:05.0", NAME="eth0"

ersetzt, wobei natürlich die passende ID einzutragen ist. Danach klappt es dann auch mit dem Netzwerk nach einem Resume.

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.