Archive for the ‘Keine Kategorie’ Category

Fehler in Eclipse beheben: RenderBadPicture Bug

Bei der aktuellen Version von Eclipse ist es auf meinem System urplötzlich dazu gekommen, dass die IDE nach dem Eintippen weniger Zeilen Programmcode abstürzt. Die einzige Fehlermeldung, die man erhält, ist eine Auflistung der Argumente, mit denen die abgestürzte JVM gestartet wurde.
Erst ein Blick auf die Konsole brachte mehr Licht ins Dunkel, den hier wird folgende Fehlermeldung angezeigt:

The program 'Eclipse' received an X Window System error.
This probably reflects a bug in the program.
The error was 'RenderBadPicture (invalid Picture parameter)'.
(Details: serial 43551 error_code 158 request_code 148 minor_code 7)
...

Eine Suche nach dem Stichwort RenderBadPicture förderte dann auch relativ schnell diesen Bugreport zutage. Scheinbar lädt Eclipse die falsche XULRunner-Komponente, die ihrerseits für das Rendern von HTML-Code innerhalb der IDE zuständig ist – in meinem Fall waren es scheinbar die bei Autocompletion auftauchenden Popups.

Die im Bugreport vorgeschlagene Hilfestellung hat zumindest in meinem Fall auf Anhieb funktioniert. Man muss Eclipse einfach direkt den Pfad zum zu verwendenen XULRunner mitteilen. Der Standardweg scheint zumindest im aktuellen openSUSE 11.3 über update-alternatives zu gehen, evtl. liegt hier auch das Problem.

Um Eclipse wieder ans Laufen zu bringen, muss man einfach die folgende Zeile in die eclipse.ini einfügen – allerdings erst nach der Zeile -vmargs !

-Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib/xulrunner-1.9.2/xulrunner

Und für ein 64-bit-System sieht es wie folgt aus:

-Dorg.eclipse.swt.browser.XULRunnerPath=/usr/lib64/xulrunner-1.9.2/xulrunner

Typo3 komplett für UTF-8 konfigurieren

In Typo3 gibt es verschiedene Konfigurationsparameter, um eine durchgängige Nutzung von UTF-8 als Zeichensatz zu erzwingen. Und häufig kommt es vor, dass nur einige der Parameter umgesetzt werden, während andere nicht berücksichtigt wurden. Dies kann unter Umständen zu einer inkonsistenten Installation führen.

Dieser Beitrag listet die wichtigsten Parameter gesammelt auf. Vorher noch ein wichtiger Hinweis: Diese Einstellungen sollten gesetzt werden, bevor Inhalte für die Seite angelegt werden. Anderweitig kann die Kodierung der Texte in der Datenbank von den Systemeinstellungen abweichen, dies würde nach erneutem Editieren zur Zerstörung aller nicht-ASCII-Zeichen führen.

Einstellungen in der localconf.php

Die folgenden Werte müssen in der localconf.php gesetzt werden, diese findet sich im Typo3-Root unter typo3conf/localconf.php. Die Werte können entweder direkt von Hand in der Datei gesetzt werden oder, bequemer, über das Typo3 Installtool.

forceCharset

Der Wert dieses Feldes wird von Typo3 intern für zum Setzen verschiedener Zeichensätze genutzt. Er muss auf utf-8 gestellt werden.

multiplyDBfieldSie

Da UTF-8 für jedes Zeichen nur ein Feld benötigt, muss diese Einstellung auf 1 gesetzt werden. Dies entspricht einem Feld pro Zeichen.

setDBinit

Die in diesem Feld vorhandenen Befehle werden direkt nach dem Aufbau jeder Datenbankverbindung an den DB-Server gesendet und sollen für die Nutzung der korrekte Zeichenkodierung in der Datenbankverbindung sorgen.
In der Regel sollten die folgenden beiden Befehle ausreichen:

SET NAMES utf8;
SET CHARACTER SET utf8;

UTF8filesystem

Sofern das verwendete Dateisystem UTF-8-Zeichen unterstützt, werden bspw. für den Upload auch Dateinamen mit Umlauten unterstützt. Dies sollte insbesondere bei Unix-System auf true gesetzt werden.

Gesammelte Einstellungen der localconf.php

Alternativ zum Setzen der Einstellungen über das Install-Tool kann auch der folgende Abschnitt direkt in die localconf.php kopiert werden:

$TYPO3_CONF_VARS['SYS']['UTF8filesystem'] = '1';
$TYPO3_CONF_VARS['BE']['forceCharset'] = 'utf-8';
$TYPO3_CONF_VARS['SYS']['setDBinit'] = 'SET NAMES utf8;'.chr(10).'SET CHARACTER SET utf8;';
$TYPO3_CONF_VARS['SYS']['multiplyDBfieldSize']=1;

Einstellungen in TypoScript

Zusätzlich sollten noch ein paar Einstellungen im Template der Seite gemacht werden. Der folgende Codeausschnitt sollte möglichst im Root-Template der Seite gesetzt werden:

config{
  additionalHeaders = Content-Type:text/html; charset=utf-8
  metaCharset = utf-8
}

VMware Server: Sound in Alsa

Seit einiger Zeit hatte ich das Problem, dass die Sound-Ausgabe vom VMware-Server (Version 1.0.X) nicht mehr zufriedenstellend funktioniert.

Symptomatisch dabei ist, dass es manchmal klappt und manchmal nicht. Hintergrund des Problems ist, dass der VMware Server die Audio-Ausgabe über das Open Sound System (OSS) realisiert, welches in den meisten Linux-Distributionen schon länger durch die Advanced Linux Sound Architecture abgelöst wurde.

Sobald der VMware Server für ein Gastsystem Sound ausgeben soll, versucht er, exklusiven Zugriff auf das OSS-Device /dev/dsp zu erhalten – das scheitert sobald eine andere Anwendung bereits exklusiven Zugriff auf das Device erhalten hat.

Sehen kann man das, sobald der Server sich den exklusiven Zugriff einmal gesichert hat mit folgendem Kommando:

# lsof /dev/dsp
COMMAND     PID USER   FD   TYPE DEVICE SIZE  NODE NAME
vmware-vm 21335 root   29w   CHR   14,3      12544 /dev/dsp

Problemlösung

Abhilfe schafft in solchen Fällen die ALSA OSS compatibility library  aoss aus dem Alsa-Paket (unter OpenSuSE bspw. zu finden im Paket alsa-oss). Wird diese per LD_PRELOAD vor dem eigentlichen Programmstart geladen leitet sie die entsprechenden Wrapper-Zugriffe um.

Als weitere Alternative gibt es das Programm aoss, das die gleiche Funktionalität bietet.

Zunächst muss man das Programm, welches den Zugriff auf /dev/dsp öffnet lokalisieren. In unserem Fall ist es /usr/lib/vmware/bin/vmware-vmx. Zunächst nennt man es um:

mv /usr/lib/vmware/bin/vmware-vmx /usr/lib/vmware/bin/vmware-vmx.org

Das ursprüngliche Programm wird nun durch ein vorgeschaltetes Skript ersetzt, welches die libaoss lädt und dann vmware-vmx aufruft. Dazu einfach die Datei /usr/lib/vmware/bin/vmware-vmx neu erzeugen, mit einem Texteditor öffnen (bspw. vi /usr/lib/vmware/bin/vmware-vmx) und folgenden Inhalt einfügen:

#!/bin/bash
LD_PRELOAD=libaoss.so exec /usr/lib/vmware/bin/vmware-vmx.org $@

Jetzt kann man die virtuelle Maschine (neu) starten und erhält hoffentlich wieder Sound.

Hinweise

  • Da der VMware Server nur als 32Bit-Paket vorhanden ist müssen auch Anwender mit x86_64-System das 32Bit-Paket von aoss installieren.

Typo3: Animiertes TMENU mit Hilfe der Mootools

Um ein dynamisches Menü zu erstellen, welches auch bei abgeschaltetem Javascript zuverlässig funktioniert habe ich mich für eine Kombination aus TMENU und das Slide-Plugin der Mootools entschieden.
Da mich das ganze eine Zeit lang beschäftigt hat veröffentliche ich es an dieser Stelle, vielleicht spart das dem ein oder anderem ein wenig Zeit.
Zunächst zur Konfiguration des TMENU: Ich habe mich für ein 2-stufiges Menü entschieden (mein Hauptmenü auf der linken Seite), wobei die erste Stufe sowohl für die Navigation (direkter Klick auf den Link) als auch für das Ein- und Aufklappen (Klick neben den Link) zuständig ist. Das mag für den ein oder anderen gewöhnungsbedürftig erscheinen. Deswegen habe ich zusätzliche eine Funktion eingebaut, die das Obermenü der aktuellen Seite aufgeklappt lässt.

Der zugehörigt TypoScript-Code

tpl.menu_1=HMENU
 #1. Ebene: Textmenü
 tpl.menu_1.1=TMENU
 tpl.menu_1.1{
 #Immer alle Menülevel anzeigen (sonst kein Sliding möglich)
 expAll=1
 #Blur deaktiviert
 noBlur=1
 #"Normale" Menüeinträge (die H3-Einträge sind fürs Sliden da)
 NO.allWrap=<h3>|&nbsp;&nbsp;</h3><div>
 #Hiermit wird der richtige CSS-Style für den Link konfiguriert
 NO.ATagParams=
 #Das gesamte Menü mit Untereinträgen hierrein verpacken
 NO.wrapItemAndSub=<div>|</div></div>
 #XHTML-Konformität
 NO.stdWrap.htmlSpecialChars=1
 #Angewählte Menüeinträge (nur andere Klassen und IDs vergeben)
 ACT=1
 ACT.allWrap=<h3 id="menuHeadAct">|&nbsp;&nbsp;</h3><div id="menuBlockAct">
 ACT.ATagParams=
 ACT.wrapItemAndSub=<div>|</div></div>
 ACT.stdWrap.htmlSpecialChars=1
 }

 #2. Ebene: Ebenfalls Textmenü
 tpl.menu_1.2=TMENU
 tpl.menu_1.2{
 noBlur=1
 NO.ATagParams=
 NO.stdWrap.htmlSpecialChars=1
 ACT=1
 ACT.ATagParams= id="menuItemAct"
 ACT.stdWrap.htmlSpecialChars=1
 }

Soweit so gut, basierend auf dem Code den Typo nun für das Menü erzeugt können wir ein kleines Javascript erstellen, welches die Slide aktiviert. Sollte jemand kein Javascript aktiviert haben wird das Menü einfach komplett ausgeklappt angezeigt und eine Navigation ist problemlos möglich.

Das zugehörige Javascript-Code

(davor UNBEDINGT die Mootools einbinden)

//Effekt erst laden wenn das Dokument fertig aufgebaut ist
window.addEvent('domready',function(){
 //Die jeweiligen Boxen pro Kategorie
 var menuGroup=$$('div.mainMenuGroup');
 //Das aktuelle Oberelement, falls existent
 var selected=$('menuBlockAct');
 selected=(selected)?selected.getParent():false;
 //Für jedes Oberelement wird eine Box/Gruppe eingefügt
 menuGroup.each(function(elem){
 var toggler=elem.getElement('h3');
 var menuBlock=toggler.getNext();
 //Der eigentliche Effekt wird hier bestimmt
 var fx=new Fx.Slide(menuBlock,{duration: 300,transition: Fx.Transitions.Cubic});
 //Alle Gruppe die nicht aktiv sind werden versteckt
 if(selected!=elem) fx.hide();
 //Dem Toggler wird ein onClick()-Event zugeordnet
 toggler.addEvent('click', function(){
 fx.toggle();
 });
 });
 //Für schönere Scrolleffekte zusätzlich benutzen
 new SmoothScroll();
});

Schlußwort

Mit diese Code wird lediglich das Menü durch Typo3 generiert, die entsprechenden Anweisungen im Stylesheet muss man natürlich noch extra hinzufügen. Ausserdem ist obiges Menü auf vertikales Ein- und Ausfahren. Wer lieber ein horizontal scollendes Menü haben möchte kann den folgenden Code benutzen:

//Der eigentliche Effekt wird hier bestimmt
var fx=new Fx.Slide(menuBlock,{mode: 'horizontal', duration: 300,transition: Fx.Transitions.Cubic});

Sony Ericsson K800i und IMAP idle

Diese Kurz-Howto richtet sich an all diejenigen, die ein Sony Ericsson K800i (oder ähnliche Modelle) besitzen und es gerne als Pushmail-Client nutzen würden.

Unter Pushmail versteht man, dass der Client (in diesem Fall das Handy) vom Server einen Hinweis erhält, sobald neue Nachrichten auf dem Server für den Client vorhanden sind. Damit wird man umgehend über neue Mails informiert und muss diese nicht umständlich in Intervallen oder gar manuell abfragen.

Achtung: Je nach Datentarif kann dieses Verfahren sehr hohe Folgekosten haben. In den meisten Fällen dürfte das bei Zeittarifen der Fall sein, denn das Handy ist konstant mit dem Server verbunden (also läuft der Zeitzähler beim Mobilfunkanbieter dauerhaft). Deswegen unbedingt vorher abklären, dass man den “richtigen” Datentarif hat.

Vorraussetzungen

Das K800i (und sicher einige baugleichen Modelle) hat einen Pushmail-Client bereits integriert. Dieser nutzt bei IMAP-Servern das Idle-Kommando. D.h. dass er die ganze Zeit dem Mailserver meldet, dass er noch da ist aber momentan keine Requests hat (Idle eben).
Der Server erkennt nun die offene Verbindung und meldet dem Mailclient neue Mails, sobald die bei ihm eintreffen.

Normalerweise meldet der Mailclient automatisch, sobald er einen Idle-fähigen IMAP-Server erkennt und bietet an, das Feature zu aktivieren.

Mein Problem war allerdings, dass ich eine TLS/SSL-Verschlüsselung genutzt habe und die Option dauerhaft deaktiviert blieb.

Des Rätsels Lösung

Nach einigen Überlegungen ist mir aufgefallen, dass das Handy das selbstsignierte Zertifikat bei jedem Mailabruf als “unsigniert” anmahmt. Das passiert auch bei einigen größeren Mailanbietern, deren Root-Zertifikat nicht im Zertifikatsspeicher vom K800i vorhanden ist.

Deswegen muss man das eigene Mailserver-Zertifikat herunterladen und auf das K800i schieben. Das geht bspw. gut per Bluetooth (Download per Internet ist wohl auch möglich).

1. Schritt: Zertifikat holen

Man kann das Zertifikat bspw. in Base64-Encoding nutzen. Das sieht dann exemplarisch so aus:

-----BEGIN CERTIFICATE-----
ABCD..................
.............................
....................1234
-----END CERTIFICATE-----

Wenn man bspw. den Mailserver Dovecot nutzt, findet man das Zertifikat standardmäßig unter /etc/ssl/certs/dovecot.pem.

Wichtig: Man benötigt auch den Header und den Footer (die —Teile)!

2. Zertifikat übertragen

Das ganze speichert man dann in einer Datei. Sofern man das Zertifikat per Bluetooth übertragen möchte MUSS die Datei die Endung .cer haben, sonst erkennt das Telefon die Datei nicht als Zertifikat.

Tipp: Unter KDE nutzt man hierfür bequem kbluetooth und schiebt die .cer-Datei auf den Datei-Push-Dienst.

Das Handy sollte nun fragen, ob man das Zertifikat nutzen möchte. Das bejaht man natürlich.

3. Mailaccount konfigurieren

Sofern noch nicht geschehen konfiguriert man jetzt den Mailaccount und geht dann einmal auf Senden + Empfangen in der Inbox. Jetzt sollte man automatisch gefragt werden, ob man Pushmail nutzen möchte.

Falls man nicht gefragt wird sollte man die Option jetzt unter den erweiterten Einstellungen finden und aktivieren können.

Hinweise/Bemerkungen

Wenn man mit der Konfiguration Probleme hat, sollte man als erstes testen, ob es ohne Verschlüsselung geht. Falls nicht hat man wahrscheinlich das Pech, keinen IMAP-Idle-fähigen Server zu besitzen.

Auch wenn es ohne Verschlüsselung problemlos geht, sollte man doch das bisschen Extra-Arbeit investieren und die Verschlüsselung einschalten – Sicher ist sicher ;)

Einrichten eines SSL-VHost unter Apache 2

In vielen Fällen ist der Einsatz von SSL sinnvoll, beispielsweise beim Zugang zu internen Administrationsseiten wie phpMyAdmin. Für solche Zwecke braucht man kein teures SSL-Zertifikat erwerben, man erstellt sich einfach sein eigenes.
Aber auch für andere Dienste wie Kundenlogins sollte man besser eine verschlüsselte Verbindung nutzen. Hier ist es ratsam, auf ein kostenpflichtiges Zertifikat zurückzugreifen, da der Nutzer sonst von unverständliche Warnhinweise abgeschreckt wird.

Die folgende Anleitung erklärt, wie man einen Apache2 mit mehreren virtuellen Hosts so konfiguriert, dass er einen zusätzlichen verschlüsselten VHost bereitstellt.

Noch ein paar Hinweise vorm Start:

  • Ein SSL-Host benötigt eine eigene IP-Adresse (respektive einen eigenen Port, falls man auch nicht-standard Ports nutzen möchte) und lässt sich somit NICHT mit NameVirtualHost kombinieren. Hintergrund: Die Informationen, welcher Host abgerufen werden soll sind bereits verschlüsselt, daher muss das Zertifikat zu diesem Zeitpunkt bereits passen.
  • Apache muss mit mod_ssl kompiliert/installiert sein. Dazu muss ausserdem OpenSSL vorhanden sein.
  • Im folgenden wird davon ausgegangen, dass die Apache2-Konfiguration in /etc/apache2 vorliegt (und dort gesplittet in Unterdateien und -ordner). Falls dem nicht so ist muss man die entsprechenden Pfade einfach anpassen, bspw. /etc/httpd/httpd.conf

Erzeugen des Zertifikats

Zunächst müssen wir für den künftigen Host die benötigten Keys und Zertifikate erstellen. Dazu erstellt man ein leeres Verzeichnis und wechselt dorthin. Idealerweise sollte das Verzeichnis nicht von anderen Benutzern lesbar sein.
Exemplarisch könnte das als Root so gehen:

mkdir /root/cert
cd /root/cert

Jetzt erstellen wir zunächste den privaten Server-Key, mit dem der Server die Request ver- und entschlüsseln kann.
Dazu dient das folgende Kommando:

openssl genrsa -des3 -rand: datei1:datei2 -out server.key 1024

Hinweise:

  • Für die meisten Fälle sollte man das -des3 weglassen, da der Schlüssel sonst mit einer Passphrase verschlüsselt wird. Das ist zwar etwas unsicherer, doch ansonsten muss man bei jedem Apache-Start die Passphrase eingeben.
  • Die Angabe von -rand datei1:…:dateiX ist optional und erzeugt “zufälligere” Schlüssel. Man sollte sie also nach Möglichkeit verwenden, bspw so:
    -rand /var/log/messages:/var/log/apache2/access_log

Jetzt sollte man eine Datei namens server.key im Verzeichnis vorfinden. Damit bewaffnet erzeugt man nun einen sogenannten “Certificate Signing Request”.
Falls man ein unterschriebenes Zertifikat erwerben möchte muss man diese Datei anschließend an den Dienstleister versenden.
Der folgende Befehl erzeugt den Request:

openssl req -new -key server.key -out server.csr

ACHTUNG: Jetzt werden einem mehrere Fragen beantwortet, die man mehr oder weniger wahrheitsgetreu beantworten kann. Wichtig ist dabei nur die Frage nach dem Common Name (CN). Dieser spiegelt die Domain wieder, für die das Zertifikat gültig sein soll. Bei Falscheingaben wird man hinterher mit Fehlermeldungen seitens des Browser bestrafft.
Für die Adresse https://test.com/ gibt man hier bspw. test.com ein, falls der SSL-Host unter https://www.test.com/ lauschen soll nimmt man www.test.com.

Der nächste Schritt ist nur dann relevant, wenn man sich für ein selbstsigniertes Zertifikat entschieden hat.
Dann muss man sich mit folgenden Befehl ein selbstsigniertes Zertifikat erzeugen (welches dann im Browser zuerst einen Fehler anzeigt):

openssl x509 -req -in server.csr -signkey server.key -out server.crt -days X

Die Option -days X gibt dabei die Anzahl der Tage an, die das Zertifikat gültig ist. Mittels -days 365 erhält man bspw. ein Zertifikat, welches ein Jahr lang gültig ist.

Konfiguration von Apache

Die erzeugten Datei sollte man am besten nur für Root lesbar machen, insbes. dann wenn man den server.key nicht verschlüsselt hat.

chmod 400 server.*

Jetzt verschiebt man sie am besten in ein geeignetes Verzeichnis, unter SuSE bspw. so:

mv server.key /etc/apache2/ssl.key/
mv server.crt /etc/apache2/ssl.crt/
mv server.csr /etc/apache2/ssl.csr/

Auf anderen Systeme gibt es ähnliche Verzeichnisse.

Anschließend kann man sich um die Einrichtung des neues SSL-VHost kümmern. Wo diese Konfiguration stehen muss ist sehr unterschiedlich von der verwendeten Distribution, bei gesplitteten Konfigurationen könnten man bspw. eine eigene Datei in /etc/apache2/vhosts.d anlegen, alternativ kann man auch direkt in die httpd.conf schreiben.
Die folgende Konfiguration stellt ein Beispiel dar, welches man an geeigneter Stelle in die Konfiguration einbinden und an seine eigenen Gegebenheiten anpassen kann:

#Nur benutzen, falls SSL-Modul geladen ist
<IfModule mod_ssl.c>
  #Ggf. noch folgenden 2 Zeilen einkommentieren, falls nicht bereits vorhanden
  #Listen *:443
  #NameVirtualHost *:443
  <VirtualHost *:443>
    #Einschalten von SSL
    SSLEngine on
    #Pfad zu Zertifikat und Key (anpassen!)
    SSLCertificateFile /etc/apache2/ssl.crt/server.crt
    SSLCertificateKeyFile /etc/apache2/ssl.key/server.key
    #IE-Problem mit SSL beheben (optional)
    SetEnvIf User-Agent ".*MSIE.*" nokeepalive ssl-unclean-shutdown
    #Server-Basiskonfiguration (wie bei anderen VHosts auch)
    ServerName test.com
    DocumentRoot /srv/www/default
    #Weitere Optionen für Directory etc. einfach hier einfügen
  </VirtualHost>
</IfModule>

Anschließend kann man Apache neu starten und sollte nun auf der IP unter Port 443 (Standardport) einen SSL-Host laufen haben.
Falls das nicht der Fall ist sollte man als erstes die <IfModule>-Anweisung entfernen und es dann nochmal probieren. Auch sollte man sicherstellen, dass die Konfiguration auch eingebunden wird.

Schlusswort

Mit obiger Anleitung sollte es in kurzer Zeit möglich sein, einen SSL-VHost zu erstellen. Allerdings sind die Pfade und Konfigurationsdateien in alle Distributionen unterschiedlich, weswegen man ggf. viel anpassen muss.

Return top