Jabber Voice Calls mit Psi in Ubuntu 10.04

Jabber/XMPP kennt die sogenannte „Jingle“ Erweiterung, sie macht es möglich mit dem Gegenüber nicht nur zu Schreiben sondern auch zu Reden. Google Talk unterstützt dies schon seit langer Zeit, in anderen Clients ist es aber noch relativ Neu und von vielen noch nicht bemerkt worden.

Unter Linux gibt es mehrere Clients die die Funktion beinhalten: Psi, Pidgin, Empathy und (sehr wahrscheinlich) noch weitere.

Ich selbst benutze Psi und Pidgin. Pidgin ist ein Multimessanger der vieles kann, bei Jabber aber ein paar Lücken hat (die aber normal nicht stören) und Psi ist ein reiner Jabberclient der mit sehr vielen Funktionen aufwarten kann.

Pidgin unterstützt Voice und Video, Psi im Moment nur Voice. Um Voice nutzen zu können, wird „psimedia“ benötigt, welches zwar über die Paketverwaltung leicht zu Installieren ist, aber (bei Ubuntu) nicht funktioniert.

Wenn man jemanden Anruft stürzt Psi ab, kommentarlos. Startet man Psi über die Kommandozeile stürzt es mit folgendem Fehler ab:

psi: symbol lookup error: /usr/lib/psi/plugins/libgstprovider.so: undefined symbol

Das Problem liegt im psimedia Paket und wurde auch behoben, in den Ubuntu Repositories ist aber eine zu alte Version.

Eine neuere Version hat Debian in ihren Repos:

Hier einfach die für deine Architektur benötigte Version herunter laden (auf die Versionsnummer achten)

Wenn man gerade schon am manuellen Aktualisieren ist: Die Psi Version in Ubuntu ist auch veraltet (0.13, aktuell ist 0.14) und kann genauso ersetzt werden (muss man aber nicht, psimedia funktioniert auch mit der Alten), genauso hier herunterladen.

Nach dem Download einfach Installieren (Doppelklick auf die datei 😉 ).

Diese Meldung wegklicken, wenn die Version in den Repos neuer wäre müsste man nichts von Hand machen

Nun kann man im Psi mittels Rechtsklick auf einen Kontakt den Punkt „Voice Call“ auswählen, in dem kleinen Fenster auf „Call“ klicken und schon Telefoniert man.

Bei Pidgin funktioniert es von Anfang an, man muss nichts dafür tun. Aber wie immer: Es gibt Dinge die kann Pidgin besser und es gibt Features, die nur Psi hat. Genau diese benötige ich von Zeit zu Zeit.

P.S.: Psi unterstützt Anrufe auch auf anderen Plattformen, bringt dort aber alle benötigten Bibliotheken direkt mit.

RAW Thumbnails unter Gnome

Ordneransicht ohne Thumbnails

Da ich meine Fotos meistens im Rohdatenformat mache (bei Nikon hat dies die Endung .NEF) konnte mir Nautilus (der Dateimanager von Gnome) bisher keine Thumbnails anzeigen.

Dies machte das Sortieren deutlich schwerer als es eigentlich sein muss.

Abhilfe schafft ein kleines Plugin: gnome-raw-thumbnailer, unter Ubuntu einfach mit apt-get (oder den grafischen Werkzeugen) installieren, Nautlis neu starten (z.b. mit killall nautilus && nautilus) und einen Ordner mit Bildern im Rohdatenformat öffnen.

Ordner mit funktionierendem RAW Thumbnailer

Das Plugin liest die (im RAW) eingebettete Vorschau aus und nimmt diese als Thumbnail. Rotiert wird das Thumbnail zwar nicht was aber verzichtbar ist.

Zu dem Projekt gibt es noch eine kleine Webseite: http://gnome-raw-thumb.sourceforge.net/

http://gnome-raw-thumb.sourceforge.net/

Der Facebook „Like“ button

Man sieht ihn immer häufiger, den Facebook „Gefällt mir“ Button auf Webseiten.

Facebook ist in letzter Zeit des öfteren in den Nachrichten gewesen, u.a. wegen Datenschutzumstellungen und ihren Mitgliederdaten, woraufhin haben einige Mitglieger das Netzwerk verlassen haben bzw. viele andere von einem Beitritt absehen

Doch „nutzen“ viele Facebook ohne es zu wissen. Einerseits durch den Abgleich von Kontaktdaten, selbst man selbst nichts damit zu tun hat gleichen manche Freunde ihr Adressbuch mit Facebook ab um eventuelle Mitglieder zu finden, dabei werden Teile dieser Daten gespeichert und auch für Freundschaftsvorschläge verwendet, aktuell steht dazu wieder etwas bei Heise. Ein Weiteres Kapitel in dieser Geschichte ist der „Like“ Button. Der Button kann von Webseitenbetreibern eingebunden werden um Lesern damit eine (einfache) Verlinkung mit Facebook herzustellen. Wenn man ihn (als Facebookmitglied) drückt wird man zu Facebook umgeleitet und kann den Link (z.b.) als Status einstellen („Ich lese gerade xyz“). Der Knopf selbst ist ein kleines Script welches vom Facebook Server geladen wird. Mit dem reinen Laden der Webseite (welche den Knopf einbindet) wird aber auch der Referer übertragen, die aktuell geladene Seite, wodurch Facebook weiß, wo man gerade surft. Daneben wird noch ein Cookie übertragen, mit dem der Nutzer eindeutig identifiziert werden kann. Das Alles ohne, dass man einen Facebook Account hat bzw. eingeloggt ist.Die daraus Resultierenden Daten sind vergleichbar mit denen von Google Analytics, nur dass die dafür (noch) nicht verwendet werden.

Mit der zunehmenden Verbreitung des „Like“ Buttons wird der Nutzer für Facebook (ohne sein Zutun) immer transparenter.

Nun Stellt sich die Frage: Will man das??? Will man, dass ein Webdienst, den man unter Umständen garnicht nutzen will (weil man ihm z.B. nicht Vertraut) trotzdem weiß, wo man sich aufhält und welche Interessen man hat??

Als Webseitenbetreiber stellt sich auch die Frage: Will man seine Nutzer „ausliefern“, die Daten kostenlos weitergeben wodurch andere Firmen (unter Umständen) viel Geld daran verdienen können??

Welche Möglichkeit hat man als Webseitenbetreiber: Den Button einfach nicht einbinden. Für WordPress gibt es zum Beispiel „freie“ Alternativen, welche komplett Lokal laufen und keine Daten weitergeben.

Die Bedenken gelten aber nicht nur für Facebook. Die Funktionsweise ist bei einigen Webdiensten vergleichbar. Werbeanbieter, Analysedienste, Micropaymentdienste und viele andere bieten kleine Scripte zum einbauen in Webseiten an und bekommen dadurch Nutzerdaten „frei Haus“.

Als Nutzer kann man solche Scripte auch einfach Blocken, was mit den Erweiterungen AdBlockPlus (wurde eigentlich für Werbung erstellt) oder NoScript geht, für AdBlockPlus wäre hier die „Easy Privacy List“ zu empfehlen

Bin ich mit meiner Ansicht alleine? RA Stadler hat sich z.B. mit dem Thema befasst und ist zu dem Entschluss gekommen, dass der Button sehr wahrscheinlich gegen (deutsches) Datenschutzrecht verstößt. Wer kurz Sucht wird noch mehr zu dem Thema finden.

Ich für meinen Teil hab das Script auf meinen Rechnern (bzw in den Browsern) blockiert (wie viele andere auch). Das mag zwar jetzt als „Spaßbremse“ aussehen aber ich will nicht, dass Firmen unkontrolliert viele Daten über mich Sammeln. Es gibt zwar noch genug andere Scripte die fröhlich Sammeln, aber irgendwo muss man ja Anfangen und das ganze etwas eingrenzen.

De-Mail <-> GnuPG

De-Mail soll der „neue“ E-Maildienst für Deutschland heißen. Sicherheit soll durch Verschlüsselung und „kontrollierte“ Zuweisung der Adressen kommen. Um Sich zu registrieren muss man seine Identität bei einer Behörde bestätigen, dann bekommt man eine De-Mailadresse im Format vorname.nachname@anbieter.de, falls der eigentliche Name schon Vergeben ist werden Zahlen angehängt -> max.mustermann2@anbieter zum Beispiel.

Die E-Mails werden auf dem Server verschlüsselt gespeichert und auch nur verschlüsselt übermittelt. Es gibt (bei Bedarf) Empfangsbestätigungen bei der Zustellung und Lesebestätigungen beim lesen der De-Mail. Diese Features kosten allerdings Geld, untypisch für E-Mails. Noch dazu sind die Server „inkompatibel“ zu normalen Mailservern, man kann also nur von und zu De-Mailpostfächern Nachrichten schicken, aber nicht an andere Anbieter (z.B. im Ausland). Im moment Bieten nur GMX, Web.de und die Telekom dieses Feature an, offiziell gestartet ist es noch nicht, da das zugrundeliegende  Gesetz noch nicht verabschiedet ist.

Eine Alternative mit ähnlichem Ansatz ist der E-Postbrief der Deutschen Post, der Funktionsumfang ist vergleichbar und das System ist genauso inkompatibel zu normalen E-Mails wie zu De-Mail.

Beide Systeme sollen freiwillig sein, De-Mail soll (unter Anderem) zur gesicherten Kommunikation mit Behörden dienen und damit viele Behördengänge unnötig machen.

Besitzt man allerdings ein De-Mail Postfach und gibt man die Adresse an Behörden, ist man verpflichtet sein Postfach regelmäßig zu Prüfen.

Die Hauptfeatures sind einerseits die Verschlüsselung der Nachrichten, andererseits die Authentifizierung der Nutzer. Diese Features sind an Sich nichts neues.

Die größte Schwachstelle ist die Verschlüsselung der Nachricht, weil diese bei der Zustellung kurz entschlüsselt und neu verschlüsselt wird. Falls eine Person sich also Zugang zum Server verschafft, könnte er diese Nachrichten lesen oder gar Verändern. Da die Servern aber „staatlich geprüften Sicherheitsstandards entsprechen“ soll dies nicht möglich sein und man sich keine Gedanken machen, dass das System unsicher wäre ( via Netzpolitik), ich selbst habe daran allerdings meine Zweifel und würde mich nicht Wundern wenn sich das System doch als unsicher herausstellt.

Ein völlig anderer Ansatz ist dagegen schon seit einigen Jahren auf dem Markt und genießt seitdem leider ein Nischendasein, die E-Mail Verschlüsselung mit PGP/GnuPG oder S/MIME. Beide Verfahren sind end-to-end Verschlüsselungen, Nachrichten werden also beim Absender verschlüsselt (im E-Mailclient) und erst beim Empfänger wieder Entschlüsselt. Der Weg dazwischen ist nahezu egal, da nicht alle Informationen zur Entschlüsselung nicht mitgeliefert werden (Passwort bzw Schlüssel). GnuPG ist eine unsymmetrische Verschlüsselung und besitzt einen Privaten und einen Öffentlichen Schlüssel. Nachrichten können von jedem mit dem öffentlichen Schlüssel verschlüsselt werden, entschlüsselt aber nur mit dem Privaten. Auf Basis des Web-of-Trust wird die Echtheit der Personen und Schlüssel sichergestellt. Wenn man einer Person Vertraut kann man Ihren Schlüssel unterschreiben, wodurch dritte das Vertrauen „sehen“, sie sehen wer die Schlüssel unterschrieben hat.

S/MIME funktioniert dagegen mit X.509 Zertifikaten (wie oft auch VPN Tunnel) welche von „zentralen“ Stellen herausgegeben werden. Von den Ausgabestellen wird die Echtheit des Empfängers sichergestellt. Die eigentliche Verschlüsselung ist auch end-to-end, die E-Mail wird also nicht auf ihrem Weg entschlüsselt und wieder neu verschlüsselt.

Beide Verfahren könnte man ebenso wie De-Mail einsetzen, Behörden könnten Zertifikate ausgeben (oder GnuPG Schlüssel mit ihrem Schlüssel unterschreiben und damit die Echtheit bestätigen) und damit normale E-Mails verschlüsseln. Dies würde mit dem bisher Eingesetzten E-Mailsystem ohne Probleme sogar Weltweit funktionieren und noch dazu Geld sparen. Dafür hätte der Staat keine so ausgedehnte Kontrolle über das System wie bei De-Mail.

Meine Meinung zu dem Thema: Ich finde De-Mail überflüssig, mit den Bestehenden Diensten könnte man vergleichbare Sicherheit (eventuell sogar noch höhere) auch abbilden, nur hat dann der Staat keine (so große) Kontrolle darüber, ob die E-Mail auch ankommt und kann dadurch nicht so viel Druck machen, wenn man sie einfach Ignoriert. Die Verpflichtungen die mit dem Dienst kommen aber auch, dass es extra Geld kostet lassen mich davon Abstand nehmen. Ich habe gerne selbst die Kontrolle darüber wem und wo ich meine Daten anvertraue, einer im Auftrag des Staates arbeitenden Stelle möchte ich sie ganz bestimmt nicht geben, da Fahr ich lieber doch die 2km zum Amt. Das kurzfristige Entschlüsseln wird mit der Abwehr von Viren und Spam begründet, wenn ich aber so etwas lese bekommt das ganze einen faden Beigeschmack. Durch die doch immernoch lauten Rufe nach Internetsperren gehe ich davon aus, dass früher oder später auch De-Mails gefiltert werden (nach was auch immer). Ich bleibe bei eigenen Servern und GnuPG.

Wenn jemand Fehler findet (z.B. inhaltliche), Ergänzungen hat, oder sich einfach über etwas Beschweren will  soll sich bitte Melden (per Kommentar oder Mail) und nicht direkt eine Abmahnung schicken.

Erfahrungen mit fglrx + Ubuntu 10.04 + Dual Monitor

Als ich im Herbst letzten Jahres mit meinen neuen PC zusammengestellt habe, entschloss ich mich vorerst eine OnBoard Grafikkarte zu nehmen und da ich einen AMD Prozessor wollte wurde es eine ATI Radeon HD 4200.

Da der radeon Treiber bei dieser Karte und unter Ubuntu 9,10 noch kein Compositing (Compiz) unterstütze, musste ich (wohl oder übel) den proprietären fglrx von ATI nehmen. Zu meiner Überraschung funktionierte mit diesem alles Problemlo , Suspend-to-Disk genauso wie Suspend-to-Ram.

Danach kam irgendwann das Update auf Ubuntu 10.04 und es lief auch weiterhin alles.

Vor ein paar Wochen nun gesellte sich zu dem (bisher verwendeten) 17″ TFT ein deutlich größerer TFT hinzu und da meine Grafikkarte 2 Anschlüsse besitzt wollte ich auch 2 Monitore gleichzeitig nutzen. Nun kamen die Probleme: Suspend funktionierte nicht mehr. Der PC ist zwar „eingeschlafen“, beim „aufwachen“ allerdings fror der PC ein.

Ein schönes Feature des neuen Monitores ist, dass im Fuß ein Gelenk eingebaut is um den Monitor hochkant zu betreiben. Dieses Feature nennt man Pivot (bzw Pivot-Funktion) und ist beim Lesen von längeren Texten, Feeds und vergleichbarem sehr angenehm. Der Spaß daran wurde mir aber schnell genommen weil der Bildaufbau sehr Ruckelig war und beim scrollen starke Streifen aufwies (diagonal, oben rechts angefangen im 45° Winkel nach unten gehend). Ich dachte, dass dies an der Leistung der OnBoard Grafikkarte hängt.

Dieses Problem beschloss ich vorerst zu ignorieren, das Suspendproblem wollte ich aber lösen.

Xorg[1201]: segfault at c801f88d10 ip 00007ff93806a2d9 sp 00007fff9501aa90 error 4 in fglrx_drv.so[7ff937db5000+6d7000]

Diese Zeile wird nach dem Suspend in die Syslog geschrieben, der Rechner wacht auch normal auf, ist per LAN pingbar nur eben die Monitore bleiben schwarz. Sobald nur ein Monitor angeschlossen ist funktioniert alles.

Nun habe ich gelesen, dass der radeon Treiber in Ubuntu 10.04 meine Grafikkarte unterstützen soll, startete also schnell ein Live Ubuntu (bevor ich mir mit den Tests mein normales Ubuntu zerschieße) und alles lief: Dual Monitor funktioniert, Compositing geht und Suspend auch, wohlgemerkt mit dem freien radeon Treiber. Die Umstellung war dadurch beschlossene Sache und musste nur noch in die Tat umgesetzt werden.

Ein Flottes „apt-get remove fglrx“ sollte zum Erfolg verhelfen, eigentlich…

Es kam nur ein Fehler zurück, gut dachte ich, fglrx wird ja noch verwendet und wollte dafür sorgen, dass beim nächsten Start der Treiber nicht geladen wird. Im restricted-manager deaktivieren war nicht möglich und brach immer mit einem nichtssagenden Fehler ab (bestenfalls, dass dpkg einen Fehler zurückgegeben hat).

Kurz im /etc/modprobe.d/ Verzeichnis geschaut und siehe da: radeon steht auf der Blacklist (angelegt von fglrx), diesen von dieser genommen und „zur Sicherheit“ fglrx hinzugefügt, damit er auf keinen Fall geladen wird. Diese Entscheidung sollte sich aber noch rächen also NICHT nachmachen, großer Fehler.

Nach dem hinzufügen auf die Blacklist der obligatorische Neustart, damit auch das „neue“ Modul verwendet wird. Schwarzer Bildschirm, nichts ging mehr. Gefreut, dass Ubuntu eine Rettungskonsole mitbringt (zweiter Punkt im Grub) und diese gestartet, doch auch diese brachte nur einen schwarzen Bildschirm. Der Spaß ging also erst richtig los. Wie „rettet“ man ein System an diesem man keine Monitore verwenden kann?

Ein live Linux vom Stick oder CD ist dein Freund und Helfer.

Live CD wieder rein, dort dann meine Festplatte gemountet und ein chroot auf diese gemacht, wodurch ich „normal“ arbeiten konnte wie im eigentlichen (eben etwas zerstörten) System, auf der Konsole wohlgemerkt.

Vorher muss  aber /proc, /dev und /sys angelegt werden, dies geht mit

mount -t proc proc /media/pfad_zur_platte/proc

mount -t sysfs sysfs /media/pfad_zur_platte/sys

mount –bind /dev /media/pfad_zur_platte/dev

In der chroot-Umgebung dann ein „apt-get purge fglrx“ ausgeführt, wieder ein Fehler:

Entferne fglrx ...
dpkg-divert: Keine Übereinstimmung mit Paket
  beim Entfernen von »diversion of /usr/lib32/libGL.so.1.2 to /usr/lib32/fglrx/libGL.so.1.2.xlibmesa by fglrx«
  »diversion of /usr/lib/libGL.so.1.2 to /usr/lib/fglrx/libGL.so.1.2.xlibmesa by xorg-driver-fglrx« gefunden
dpkg: Fehler beim Bearbeiten von fglrx (--remove):
 Unterprozess installiertes post-removal-Skript gab den Fehlerwert 2 zurück

Kurz gesucht und auf den folgenden Befehl gestoßen

dpkg-divert --remove /usr/lib32/libGL.so.1.2

Danach funktionierte  auch das Entfernen von fglrx.

Kurz kontrolliert ob die Blacklist der Kernelmodule wieder stimmt und dann der nächste Neustart, von der Live-CD ins normale System, toi toi toi.

Nach einem Login (juhu, der X11 funktioniert wieder) präsentiert sich Gnome in gewohnter Optik. Dual Monitor funktioniert weiterhin, genauso auch Compositing. Kurz Suspend-to-Ram getestet und siehe da: funktioniert auch endlich (wieder).

Beim Surfen dann den Monitor nochmals kurz gedreht und keine Streifen mehr gesehen, Pivot funktioniert nun auch. Der Bildaufbau ist im Hochformat genauso schnell wie im Querformat, sogar das lag am fglrx und nicht wie zuerst gedacht an der Grafikkarte.

Also: regelmäßig überprüfen ob es eventuell bessere Treiber für die eingesetzte Hardware gibt (und nicht nur neue Versionen des eingesetzten Treibers) welche besser funktionieren.