Ubuntu Lucid LTS Server auf Oneiric Updaten

Geschrieben von everflux am Dezember 10th, 2011

Manchmal möchte man gerne ein Update von einer LTS Version auf eine nicht-LTS Version machen, z.B. um  neuere Pakete nutzen zu können. Der „übliche“ Weg dazu, den man in vielen Blogs und Foren findet, ist „sudo do-release-update -d“, welches auf die aktuellste Developer („d“) Version aktualisiert.
Das ist solange kein Problem, wie keine „echte“ Entwicklerversion bereitsteht, dann sind Entwicklerversion und letzte Release-Version nämlich identisch und man erhält das gewünschte Ergebnis. Möchte man aber derzeit beispielsweise von Ubuntu Lucid auf Oneiric umstellen, und wählt das development Update an, so wird in der Tat auf die Entwickler Version Precise Pangolin aktualisiert. Höchstwahrscheinlich auf einem Server nichts, was man nur für aktuellere Pakete tun möchte.

Die Alternative: In /etc/update-manager/release-upgrades aendert man die Zeile
Prompt=lts
auf
Prompt=normal
und startet anschließend ganz normal „sudo do-release-upgrade“. Der Upgrade Prozess von Lucid auf Oneiric verlaeuft dann ueber die Zwischenschritte „Update auf Maverick“ und „Update auf Natty“.

Ubuntu HDMI (kein) Sound

Geschrieben von everflux am Oktober 14th, 2011

Seit meinem neuen Computer (und Ubuntu Oneric) ist mein zweiter Monitor per HDMI Kabel angeschlossen. Das Problem: Per HDMI ist neben Bild- auch ein Tonausgabegerät und wird als Default Device verwendet. Damit ist dann teilweise nichts zu hören – offenbar ist das jedoch Anwendungsabhängig.

Als Lösung habe ich mir pragmatisch ein virtuelles pulseaudio device eingerichtet, dass auf alle Geräte den Sound dann ausgibt. Dazu installiert man sich das Paket „paprefs“

sudo apt-get install paprefs

und starte diese („paprefs“). Auf dem Reiter „simultaneous output“ (im englischen) kann dann ein virtuelles Gerät aktiviert werden, dass die Ausgabe auf alle Geräte weiterleitet.

Ubuntu Oneiric: Netbeans Master-Passwort / Keyring Integration

Geschrieben von everflux am Oktober 14th, 2011

Schon in frühen Beta Versionen von Ubuntu 11.04 / Oneiric hat Netbeans mich ständig nach einem „Master Password“ gefragt, mit dem gespeicherte Passwörter von Netbeans gegen unbefugten Zugriff verschlüsselt werden.

Das ist nervig, denn bisher ging es auch ohne – dabei nutzt Netbeans die von modernen Betriebssystemen bereitgestellte native Infrastruktur um Passwörter zu speichern. (z.B. Keychain auf dem Mac, Gnome-Keyring o.ä.) Normalerweise funktioniert das auch – aber seit Gnome 3 hat sich da offenbar etwas geändert.

Debuggen kann man die Netbeans Keyring Integration indem man folgende Option in der etc/netbeans.conf zu den netbeans_default_options ergaenzt:

-J-Dorg.netbeans.modules.keyring.level=0

Anschließend sieht man in ~/.netbeans/7.0/var/log/messages

FINE [org.netbeans.modules.keyring.kde.KWalletProvider]: application exit with code 2 for commandString: [qdbus, org.kde.kwalletd, /modules/kwalletd, org.kde.KWallet.isEnabled]; errVal: Service 'org.kde.kwalletd' does not exist.
FINE [org.netbeans.modules.keyring.gnome.GnomeProvider]
java.lang.UnsatisfiedLinkError: Unable to load library 'gnome-keyring': libgnome-keyring.so: cannot open shared object file: No such file or directory
at com.sun.jna.NativeLibrary.loadLibrary(NativeLibrary.java:163)
at com.sun.jna.NativeLibrary.getInstance(NativeLibrary.java:236)
at com.sun.jna.Library$Handler.<init>(Library.java:140)
at com.sun.jna.Native.loadLibrary(Native.java:379)
at org.netbeans.modules.keyring.gnome.GnomeKeyringLibrary.<clinit>(GnomeKeyringLibrary.java:62)
[catch] at org.netbeans.modules.keyring.gnome.GnomeProvider.enabled(GnomeProvider.java:88)
at org.netbeans.api.keyring.Keyring.provider(Keyring.java:72)
at org.netbeans.api.keyring.Keyring.save(Keyring.java:109)
at org.netbeans.modules.j2ee.deployment.impl.ServerRegistry$5.run(ServerRegistry.java:731)
at org.openide.util.RequestProcessor$Task.run(RequestProcessor.java:1424)
at org.openide.util.RequestProcessor$Processor.run(RequestProcessor.java:1968)

Nachdem ich sichergestellt habe, dass die Library installiert ist:

sudo apt-get install libgnome-keyring0
Reading package lists... Done
Building dependency tree
Reading state information... Done
libgnome-keyring0 is already the newest version.

bleibt die Frage: Wieso findet Netbeans die gesuchte Library nicht? Die Lösung: Die Gnome Keyring Library ist nur noch mit einem anderen Dateinamen verfügbar, mit angehängter „0“. Das gab es zwar früher schon immer, dass die Libraries ohne Versionsnummer (oder was das ist) lediglich ein Symlink auf die „echte“ Library waren, aber immerhin gab es die. (Da gibt es bestimmt einen guten Grund und viel Logik für, dass das abgeschafft wurde – mir erschließt sich das jedoch nicht.)
Der simple Work-Around ist daher:

sudo ln -s /usr/lib/libgnome-keyring.so.0 /usr/lib/libgnome-keyring.so

und danach funktioniert Netbeans wieder tadellos. Also gab es offenbar keine inkompatiblen API Änderungen, sondern „lediglich“ eine Änderung des Library-Namens. Ob das ein Ubuntu/Debian Paketierungsproblem ist, oder ab Gnome 3 einfach die neue Marschrichtung, kann ich nicht sagen.

Update: Ich hab dazu ein Bug im Netbeans Issuetracker aufgemacht. Wer voten möchte – gerne: http://netbeans.org/bugzilla/show_bug.cgi?id=203735

Oneiric update auf VM Gast bricht ab

Geschrieben von everflux am Oktober 14th, 2011

Wer einen KVM/VM Gastsystem dass mit „vmbuilder“ erstellt wurde auf Ubuntu Oneiric updaten möchte wird möglicherweise diese unschöne Überraschung erleben:


A fatal error occurred

Please report this as a bug and include the files
/var/log/dist-upgrade/main.log and /var/log/dist-upgrade/apt.log in
your report. The upgrade has aborted.

Ein Blick in die genannten Logdateien hilft weiter:

2011-10-14 08:39:47,147 DEBUG creating statefile: '/var/log/dist-upgrade/apt-clone_system_state.tar.gz'
2011-10-14 08:39:56,877 DEBUG lspci failed: [Errno 2] No such file or directory
2011-10-14 08:39:56,920 DEBUG lsb-release: 'natty'
2011-10-14 08:40:00,162 ERROR not handled exception:
Traceback (most recent call last):

Da schlägt der Aufruf von „lspci“ fehl. Das Paket ist in dem per vmbuilder unter lucid erstellten System nicht installiert, und wurde auch bei den nachfolgenden Updates nicht als Dependency deklariert und somit nicht installiert.
Installiert man das Paket kurzerhand selbst

sudo apt-get install pciutils

funktioniert danach das Update auf den ersten Blick auch fehlerfrei.

Firefox/Chrome, Office: Paste plain text (ohne Formatierung)

Geschrieben von everflux am Oktober 13th, 2011

Inzwischen sind wysiswg-Editoren wie TinyMCE oder der (seit Version 4 obligatorische) Rich Text Editor im Confluence Wiki on vogue.

Manchmal möchte man sich jedoch nur Inhalte ohne Formatierungen von einer anderen Webseite/Wikiseite oder einem Dokument übernehmen. Bisher war meine „Lösung“ dazu, den Text in gedit oder einem anderen reinen Texteditor einzufügen und dann wieder dort heraus zu kopieren. Etwas umständlich – da gibt es aber eine Lösung für:

In Google Chrome,  Chromium, Firefox und OpenOffice/LibreOffice gibt es dafuer ein Shortcut: Mittels STRG-SHIFT-V (bzwl. ctrl-shift-v) wird ohne Formatierung eingefuegt.

Lediglich AdblockPlus User und Confluence User haben ein Problem: Genau das Kürzel wird bereits verwendet. In Adblock Plus kann dies nicht über die GUI deaktiviert werden, sondern muss über „about:config“ fuer den Schlüssel „extensions.adblockplus.sidebar_key“ umgestellt werden. Nach einem Neustart von Firefox funktioniert es dann wie gewünscht.

Ubuntu Oneiric: Latex Papierformat

Geschrieben von everflux am Oktober 7th, 2011

In Ubuntu Oneiric hat sich ein Patch eingefunden, der dafuer sorgen soll, dass das Papierformat nicht zu A4 im Default wird. Das sorgte bei mir dafuer, dass auch Dinge, die eigentlich A4 werden sollten im US-Letter Format als PDF generiert wurden.

Die Loesung dafuer sieht so aus, dass man entweder mit den Kommandos \pdfpageheight und \pdfpagewidth das Ausgabeformat korrekt setzt, oder ein Package verwendet, dass sich bereits darum kuemmert. Das ist Beispielsweise das „geometry“ Paket: \usepackage{geometry}

Wenn man eigene Vorlagen verwendet, kann man das Geometrie Paket so einbinden: \RequirePackage{geometry}

Archiv mit gpg verschlüsseln und mit lzma komprimieren

Geschrieben von everflux am August 21st, 2011

Ich verwende zur Datensicherung ein selbst gebautes Script und brenne die Daten danach auf Bluray Medien zur externen Hinterlegung.
Bisher habe ich dazu in etwa folgenden Aufruf verwendet:

tar -v --label="tkruse-home" -l -c -p --totals --ignore-failed-read ... | gpg --compress-algo bzip2 --cipher-algo AES256 -z 9 -c

Nun komprimiert bzip2 ja nicht besonders gut im Verhältnis zum dafür erforderlichen Aufwand (und die Dekomprimierung ist langsam). Leider unterstützt GPG von Haus aus lediglich bzip2 und zlib, nicht den von mir favorisierten lzma Algorithmus. (Der kommt bei 7zip auch zum Einsatz und sorgt für die gute Kompressionsrate.)
Jedoch ist bei modernen Linux Distributionen wie Debian und dem darauf basierenden Ubuntu auch das Kommandozeilentool „lzma“ verfügbar. Dies kann in guter alter Unix Manier als Filter eingesetzt werden, lediglich gpg muss dann noch beigebracht werden, keine eigene Komprimierung einzusetzen. Dies geschieht wenn man als „Algorithmus“ einen der Werte „none“ oder „uncompressed“ verwendet.
Der Aufruf sieht dann so aus:

tar -v --label="tkruse-home" -l -c -p --totals --ignore-failed-read ... | lzma -c -z -9 | gpg --compress-algo none --cipher-algo AES256 -c

Leider unterstützt das lzma Tool derzeit (2011) noch kein multithreading (im Gegensatz zu 7zip), so dass keine Parallelität auf multi-core Maschinen ausgenutzt werden kann.

Im Gegensatz zu anderen Backup Lösungen hat meine Lösung den Nachteil kein inkrementelles Backup zu unterstützen, die Backup Datei hat keine Redundanz gegen defekte Blöcke und als Ausgabe kommt lediglich eine große Datei heraus, die anschließend gesichert werden muss. Für mich reicht das – für einen normalen Anwender ist es vermutlich nicht das Mittel der Wahl.

Subversion diff grafisch anzeigen: meld

Geschrieben von everflux am Juli 26th, 2011

Änderungen an LaTeX Dokumenten lassen sich sehr komfortabel ansehen, wenn die Dokumente in einem Versionskontrollsystem wie Subversion verwaltet werden.

Subversion hat dazu das „diff“ Kommando, jedoch gibt dies lediglich Änderungen auf der Kommandozeile aus. Schöner wäre ja eine grafische Übersicht. Dazu kann man Subversion per „–diff-cmd“ auch ein Programm angeben, dass die Ausgabe aufbereiten bzw. anzeigen soll. Leider funktioniert das mit meinem lieblings-Diff-Viewer, „meld“ nicht wie erwartet.

Meld selber kann jedoch direkt aufgerufen werden und kuemmert sich dann darum, ein Diff zu erstellen und dies auch anzuzeigen. Dazu gibt man lediglich im Working-Directory

meld .

ein. Der Punkt ist wichtig, damit wird ab dem aktuellen Verzeichnis nach Änderungen gesucht. Nun sieht man die Dateien, die geändert sind, und kann diese in meld anklicken. Ubuntu und Debian User können meld bei Bedarf per sudo apt-get install meld installieren, sollte dies noch nicht geschehen sein.

Jenkins, Java: java.net.SocketTimeoutException: Accept timed out

Geschrieben von everflux am Juli 25th, 2011

Lange gesucht, doch gefunden:

ERROR: Aborted Maven execution for InterruptedIOException
java.net.SocketTimeoutException: Accept timed out

Jenkins (bzw. Hudson) bricht dann mit dieser Fehlermeldung den Build Prozess ab:

java.net.SocketTimeoutException: Accept timed out
	at java.net.PlainSocketImpl.socketAccept(Native Method)
	at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:408)
	at java.net.ServerSocket.implAccept(ServerSocket.java:462)
	at java.net.ServerSocket.accept(ServerSocket.java:430)
	at hudson.maven.AbstractMavenProcessFactory$SocketHandler$AcceptorImpl.accept(AbstractMavenProcessFactory.java:167)
	at hudson.maven.AbstractMavenProcessFactory.newProcess(AbstractMavenProcessFactory.java:221)
	at hudson.maven.ProcessCache.get(ProcessCache.java:231)
	at hudson.maven.MavenModuleSetBuild$RunnerImpl.doRun(MavenModuleSetBuild.java:668)
	at hudson.model.AbstractBuild$AbstractRunner.run(AbstractBuild.java:429)
	at hudson.model.Run.run(Run.java:1374)
	at hudson.maven.MavenModuleSetBuild.run(MavenModuleSetBuild.java:467)
	at hudson.model.ResourceController.execute(ResourceController.java:88)
	at hudson.model.Executor.run(Executor.java:145)
Finished: ABORTED

Beheben über advanced und dort in die MAVEN_OPTS hinzufügen:

-Djava.net.preferIPv4Stack=true

Anschließend sollte der Build wieder korrekt funktionieren. Alternativ kann man dies auch als globale Environment Variable setzen, das Problem wird mehrere Java Anwendungen betreffen und nicht nur den CI Server.

SSL Problem mit Java 7

Geschrieben von everflux am Juli 25th, 2011

Nachdem ich (wie im vorherigen Artikel beschrieben) nun OpenJDK / Java 7 selber kompiliert habe, habe ich mich auf die Suche nach dem SSL Problem gemacht, dass ich mit Jameica/Hibiskus habe. (No offense, ich find es leichter OpenJDK zu übersetzen oder anzupassen als Jameica und Hibiskus zu bauen… praktischerweise bringt OpenJDK auch Netbeans Projektdateien mit, so dass es ein Klacks ist, das Projekt mit Netbeans zu verwenden.)

Nachdem ich folgenden Patch geschrieben habe habe:

diff -r 9b8c96f96a0f src/share/classes/sun/security/ssl/SSLContextImpl.java
--- a/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jun 27 13:21:34 2011 -0700
+++ b/src/share/classes/sun/security/ssl/SSLContextImpl.java	Mon Jul 25 19:30:11 2011 +0200
@@ -871,7 +871,7 @@
                 }
             } catch (CertPathValidatorException cpve) {
                 throw new CertificateException(
-                    "Certificates does not conform to algorithm constraints");
+                    "Certificates does not conform to algorithm constraints", cpve);
             }
         }
     }

ist jetzt auch zu sehen, was die Ursache fuer den SSL Fehler ist:

Caused by: java.security.cert.CertPathValidatorException: Algorithm constraints check failed: MD2withRSA
	at sun.security.provider.certpath.AlgorithmChecker.check(AlgorithmChecker.java:200)
	at sun.security.ssl.AbstractTrustManagerWrapper.checkAdditionalTrust(SSLContextImpl.java:870)
	... 21 more org.kapott.hbci.manager.HBCIUtils.log(HBCIUtils.java:1052)

OpenJDK kommt übrigens ohne Root Zertifikate daher, so dass man sich nicht über einen solchen Dialog wundern sollte:

Nachdem man die Exception genauer ansieht, ist man auch etwas schlauer geworden: Irgendein Zertifikat ist mit einem nicht mehr als sicher geltenden Algorithmus signiert. Das der Apobank selbst ist es offensichtlich jedoch nicht, also muss die gesamte Zertifikatskette untersucht werden.
Hier habe ich etwas Shell-Magie und das OpenSSL Kommandozeilentool verwendet:

openssl s_client -showcerts -connect hbcibanking.apobank.de:443 < /dev/null | awk -v c=-1 '/-----BEGIN CERTIFICATE-----/{inc=1;c++} inc {print > ("cert-" c ".pem")}/---END CERTIFICATE-----/{inc=0}'; for i in cert-?.pem; do openssl x509 -noout -serial -subject -issuer -in "$i"; done

Danach finden sich alle Zertifikate in cert-1.pem, cert-2.pem usw., die Ausgabe der Seriennummern, Subject und Issuer sah bei mir so aus:

serial=4FCD4C50631D3BB4C747A319E816AD5D
subject= /C=DE/ST=NRW/L=Duesseldorf/O=Deutsche Apotheker- und Aerztebank/OU=Terms of use at www.verisign.com/rpa (c)05/CN=hbcibanking.apobank.de
issuer= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
serial=254B8A853842CCE358F8C5DDAE226EA4
subject= /O=VeriSign Trust Network/OU=VeriSign, Inc./OU=VeriSign International Server CA - Class 3/OU=www.verisign.com/CPS Incorp.by Ref. LIABILITY LTD.(c)97 VeriSign
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
serial=70BAE41D10D92934B638CA7B03CCBABF
subject= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority
issuer= /C=US/O=VeriSign, Inc./OU=Class 3 Public Primary Certification Authority

Nun müssen alle Zertifikate untersucht werden:

openssl x509 -text -in cert-0.pem

Und entsprechend für die anderen Zertifikate in der Kette. Ich wurde dann bei dem dritten Zertifikat fündig:

tkruse@charix:~$ openssl x509 -text -in cert-2.pem
Certificate:
Data:
Version: 1 (0x0)
Serial Number:
70:ba:e4:1d:10:d9:29:34:b6:38:ca:7b:03:cc:ba:bf
Signature Algorithm: md2WithRSAEncryption
Issuer: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority
Validity
Not Before: Jan 29 00:00:00 1996 GMT
Not After : Aug 1 23:59:59 2028 GMT
Subject: C=US, O=VeriSign, Inc., OU=Class 3 Public Primary Certification Authority

Ein „betagtes“ altes VeriSign Zertifikat das mit MD2 und RSA signiert wurde. Auch wenn der MD2 Signaturalgorithmus noch nicht gebrochen ist, gibt es einige Angriffe, die dazu geführt haben, dass MD2 seit 2009 nicht mehr in OpenSSL verwendet wird.
Was heißt das nun für das konkrete SSL Problem? Die ApoBank wird sich eh um Januar 2012 herum spätestens ein neues SSL Zertifikat besorgen. Dann sollte der Spuk zu ende sein. Besser wäre es allerdings wenn die betroffenen Anbieter ihre SSL Zertifikate jetzt erneuern – es geht schließlich um Online Banking!
Und wieso fällt das erst seit Java 7 auf? Seit Java 7 ist offenbar die Möglichkeit neu hinzugekommen die Algorithmen zu prüfen oder wurde geändert. Eigentlich sollte seit Java 6u17 bereits MD2 nicht mehr unterstützt werden, zumindest gibt es einen entsprechenden Eintrag in den Release notes: http://www.oracle.com/technetwork/java/javase/6u17-141447.html.


http://everflux.de/
Copyright © 2007, 2008 everflux. Alle Rechte vorbehalten. All rights reserved.