Kaum gedacht, schon habe ich einen User ohne Shell angelegt, dazu ein Zertifikat und ab dafür. Schön wärs. Mit der Meldung, der Server würde den Schlüssel nicht akzeptieren, verabschiedete sich der SSH-Client, der von Subversion aufgerufen wurde. Nach mehreren neuen Schlüsseln, stellte sich heraus, dass es wunderbar funktionierte, wenn ich dem User eine Shell zuwies.

Der Suchmaschine sei Dank, habe ich für dieses unschöne Problem eine Lösung gefunden. Dem User bleibt eine Shell zugewiesen, allerdings gibt man dem SSH-Daemon noch ein paar Befehle mit, um den Shell-Zugriff einzuschränken. Folgendes trägt man vor dem Schlüsseltyp in der Datei authorized_keys ein:

command="/usr/bin/svnserve -t -r /home/user/svn/",no-port-forwarding,no-agent-forwarding,no-X11-forwarding,no-pty

Offensichtlich startet der Client erstmal den SVN-Server auf der entfernten Maschine, falls dieser nicht schon läuft, ohne Shell geht das schief. Die Lösung funktioniert nur, wenn man sich per Public-Key-Authentication einloggen kann. Sinnvollerweise ist das aber sowieso aktiviert und der passwortbasierte Login deaktiviert.

Zum Update auf KDE SC 4.5 genügen wenige Befehle in der Konsole:

sudo apt-add-repository ppa:kubuntu-ppa/backports
sudo apt-get update && sudo apt-get dist-upgrade

Aber aufgemerkt: Nicht nur dass man sich damit „Fremdpakete“ einfängt, man installiert sich auch noch im Gegensatz zu früheren Versionen die Beta 2 von Qt 4.7. Ein Update sollte man sich also genau überlegen.

Bisher habe ich keine Möglichkeit gefunden, Loggerhead ohne große Pythonskripterei an nginx anzubinden und da ich eher wenig Ahnung von Python habe, will ich diese Lösung lieber vermeiden, auch wenn sie den Vorteil genießt, nur einen Webserver zu benötigen.

Da Loggerhead einen eingebauten Webserver mitbringt und sich die Last darauf auch in Grenzen hält, bietet sich also die Möglichkeit an, nginx als Proxy zu verwenden. Dazu legt man in der Konfigurationsdatei einen neuen Server an:

server {
listen 80;
server_name bzr.domain.de;

location ~ ^/ {
proxy_set_header Host $http_host;
proxy_pass http://localhost:8080;
}
}

Zu Beachten ist das Setzen des Host-Feldes des HTTP-Headers auf den ursprünglichen Wert, da sonst alle Links, die von Loggerhead produziert werden, auf localhost zeigen würden. Natürlich muss der Port noch angepasst werden und schon ist Loggerhead über http://bzr.domain.de und nicht nur über http://domain.de:8080 erreichbar.

(…) We remain committed to delivering 64-bit support in a future release of Flash Player.  No further information is available at this time. (…)

Ich wanke noch zwischen Freude und Entäuschung. Einerseits ist es schön, dass Adobe einsieht was für einen Müll (via) sie da produzieren und es vom Netz nehmen, andererseits wäre nach so einer langen Testphase doch mal ein ordentliches Stück Software drin gewesen.

Ob es überhaupt noch ein Flashplugin für 64-Bit Systeme geben wird, wage ich angesichts des WebM-Projektes zu bezweifeln.

Neben kleinen Veränderungen am Aussehen und unter der Haube, ist es nun möglich in den verschiedenen Bereichen von Ubuntuusers zu suchen. Desweiteren habe ich die hoffentlich funktionierende Update-URL ergänzt, so dass die Extension bei einer neuen Version automatisch geupdatet werden sollte. Diejenigen, die sich UUfC gestern schon installiert haben, bitte ich von Hand zu aktualisieren, wenn Bedarf besteht. UUfC findet ihr weiterhin in der Extension Gallery von Google.

Nächster Punkt in der Queue ist die Standard-Konformität von HTML und CSS, um mein Gewissen zu beruhigen.

Sehr schick ist auch das Erweitern von Chromium durch Extensions. Mit geringen Kenntnissen in HTML, Javascript und CSS hat man sich in kurzer Zeit Erweiterungen zusammengezimmert. Das habe ich auch getan und herausgekommen ist ein kleiner Helfer, der mich schnell zu meinen Zielen auf Ubuntuusers.de führt:

Ubuntuusers for Chromium 0.1

Die Erweiterung möchte ich euch natürlich nicht vorenthalten. Installieren könnt ihr sie über die Extension-Gallery von Google Chrome. Über Kommentare würde ich mich freuen.

Ein letzter Hinweis: Die Erweiterung stammt nicht vom Ubuntuusers-Projekt. Bitte stellt also keine Support-Anfragen an das UU-Team.

Morgen werde ich noch ein paar mehr einkippen. Torrents zum Befüllen finden sich übrigens bei Dirks Logbuch.

Um die Verbindung mit ProFTPD zu verschlüsseln geht man also wie folgt vor:

1. Zertifikat generieren:
Da es sich um eine SSL-basierte Verschlüsselung handelt, muss man zunächst einen privaten Schlüssel und ein Zertifikat erstellen:

openssl req -x509 -newkey rsa:1024 -keyout /etc/ssl/private/proftpd.key -out /etc/ssl/certs/proftpd.crt -nodes -days 365

Die Schlüsseldatei darf nur vom Benutzer root gelesen werden:

chmod 0600 /etc/ssl/private/proftpd.key

2. ProFTPD konfigurieren:

Nun muss noch ProFTPD so konfiguriert werden, dass es Verbindungen über ftps erlaubt bzw. unterstützt. Hierzu öffnet man die Datei /etc/proftpd/tls.conf in einem Editor und setzt folgende Einstellungen:

<IfModule mod_tls.c>
TLSEngine                     on
TLSLog                        /var/log/proftpd/tls.log
TLSProtocol                   SSLv3
TLSRSACertificateFile         /etc/ssl/certs/proftpd.crt
TLSRSACertificateKeyFile      /etc/ssl/private/proftpd.key
TLSVerifyClient               off
TLSRequired                   on
TLSRenegotiate                required off
</IfModule>

Ob man TLSv1 oder SSLv3 verwendet, hängt leider vom Klienten ab. Manche, wie z.B. Dolphin (via kio-ftps), beherrschen TLS noch nicht. Um die Änderungen zu übernehmen, muss man zuletzt ProFTPD neu starten:

/etc/init.d/proftpd restart

ProFTPD wird nun keine Verbindungen mehr akzeptieren, die über ftp hereinkommen. Stattdessen muss man das ftp(e)s-Protokoll verwenden.

Vor ein paar Minuten ging ein Kopete Chatfenster mit einer Nachricht eines ehemaligen Kameraden aus der Grundausbildung auf, mit dem ich schon seit Jahren nichts mehr geschrieben hatte. Darin eine eher harmlos wirkende Aufforderung: “schau mal das foto an „. Im Nachhinein sieht der Link schon verdächtig aus, ohne groß nach zu denken habe ich aber drauf geklickt. Nur erschien kein Bild, sondern nichts. Google fand dann einen haufen Meldungen über einen Virus.

Nun. Etwas Gutes hat der Virus dann doch gebracht: Eine nette kleine Plauderei mit dem ehemaligen Kameraden .

//Edit: Entschuldigung an alle Planetenleser. War eigentlich nicht für den UU.de-Planeten gedacht.

Die Frage, die sich jeder Ubuntu-Benutzer irgendwann zwangsläufig irgendwann mal stellt – und sei es nur für 0,068 Sekunden – ist, wo er sich in dieser Kette einreihen könnte. Da gibt es beispielsweise die Möglichkeit, Bugs zu melden, Patches einzusenden, zu übersetzen oder Hilfe in Foren zu leisten. Das ist unerlässlich, aber verlangt oft viel Zeit und tiefe Kenntnis der Materie, die Otto normal nicht hat.

Was fast keine Kenntnisse und kaum Zeit verschlingt ist, bei der Verteilung der Ubuntu-Abbilder zu helfen. Traffic ist zwar nicht selten, dafür aber in großen Mengen sehr teuer, selbst wenn es nur der Strom ist, den er verbraucht. Die Verteilung per Torrent bietet sich daher an, da es die Last von den Servern nimmt und auf viele Schultern verteilt. Das funktioniert natürlich nur, wenn auch viele die Abbilder über Torrent beziehen und bereitstellen. Ein kleiner Nebeneffekt sind Bandbreiten, die schnell in den Megabyte-Bereich wachsen. Wer versucht hat, Ubuntu kurz nach dem Release herunter zu laden, der weiß das zu schätzen.

Wenn nicht schon in der Standardinstallation vorhanden, lassen sich Torrentclients, wie z.B. Transmission oder Ktorrent, bequem per Paketverwaltung installieren. Für meinen Server mit Indianer freunde ich mich gerade mit Torrentflux an. Die Download- und Uploadgeschwindigkeiten, sollte man in den Einstellungen wenigstens überprüfen und ggf. korrigieren, nicht dass der Surf- oder Telefoniergenuss darunter leidet. Bei Servern, die nicht daheim stehen, sollte man unbedingt die Soft- und Hardlimits setzen, damit der Inklusivtraffic nicht überschritten wird.

Danach muss man nur noch die Torrent-Dateien der Wahl, welche jedes Mal auch in der Ankündigung verlinkt werden, in den Clienten einkippen und los geht’s. Hat man keine Lust mehr, kann man den Seed anhalten oder die Datei einfach wieder entfernen.

Spätestens bei HD Aufnahmen, die wenigstens 720p als Auflösungsnorm verwenden und meißt h264 kodiert in einem Matroska-Container liegen, ist aber Schluss mit lustig. 720p/1080p Aufnahmen sind beherrscht von Ruckeln und Abstürzen des Players, wenn überhaupt mal ein Bild angezeigt wird (SMPlayer/MPlayer und VLC nehmen sich da beide nicht viel).  Den Abstürzen, die desöfteren bei Sprüngen oder Wechsel in den Vollbildmodus und zurück auftreten, bin ich noch nicht Herr geworden, vermute allerdings die Schuld beim propiertären NVIDIA-Treiber, da oft nicht nur der Player abstürzt, sondern auch gleich das gesamte System „Auf Wiedersehen“ sagt. Das Ruckeln konnte ich glücklicherweise beseitigen.

Unter der rießigen Vielfalt an Einstellungen bietet (S)MPlayer nämlich die Möglichkeit, MPEG1/2 und h264 in mehreren Threads zu dekodieren. Hier habe ich die Anzahl von 1 auf 4, mit der ich das beste Ergebnis erzielt habe, erhöht. Zusätzlich habe ich beim Loop Filter die Option „Überspringen nur bei HD Videos“ gesetzt. Das verspricht noch mal einen Geschwindigkeitsschub bei nicht sichtbarem Qualitätsverlust.

Wer eine NVIDIA Grafikkarte besitzt und den hauseigenen Treiber verwendet, kann zudem Grafik auf die Grafikkarte verbannen und als Ausgabegerät „vdpau“ einstellen, wobei ich den Verdacht habe, dass das zu weiteren Instabilitäten führt.

Zum Schluss würde es mich sehr interessieren, wer von euch mit ähnlicher Hardware bestückt ist und ohne zusätzliche Einstellungen unter Ubuntu HD-Videos problemlos (also flüssig und ohne Abstürze beim Springen bzw. Wechsel des Vollbildmodus) wiedergeben kann oder ähnliche Probleme hat. Schwache Hardware mag ich nämlich ausschließen, zumal sogar Netbooks damit Werbung machen, HD ohne Probleme wiedergeben zu können. Im Moment halte ich daher eine Kombination aus mäßiger h264 Unterstützung, was durchaus verständlich ist, und NVIDIA-Treiber für die Schuldigen dieser Problematik.

Update: Ein weiterer geschickter Schachzug ist das Abschalten der Funktion „Überspringen von Bildern“. Damit laufen sogar 1080p Aufnahmen vollkommen reibungslos. Das Wechseln in den Vollbildmodus und Zeitsprünge machen auch keine Probleme mehr.

Die Installation verlief reibungslos – bis auf ein nerviges Knacken in den Lautsprechern, dass ich mit Hilfe des Forums von ubuntuusers.de leicht beheben konnte. Der Bootvorgang, aber auch vor allem das Herunterfahren, hat sich im Vergleich zu früheren Version was die Geschwindigkeit angeht extrem verbessert. Dafür muss ich an dieser Stelle Lob an die Entwickler aussprechen.

Allerdings gibts auch Negatives zu berichten. Im Allgemeinen bin ich nicht kleinlich und Programme, die mal auf Englisch sind, stören mich nicht weiter. Wenn mein Rechner mit mir zweisprachig reden will, soll er halt. Vielleicht hänge ich mich an diesem einen Beispiel auch zu sehr auf, aber was ist denn hier wieder schiefgelaufen:

Solches Denglisch finde ich extrem nervig und schlechte Publicity ist es zudem. Sehr wahrscheinlich wurde das sogar mehrmals (Upstream und von den Kubuntu-Übersetzern ) ins Deutsche übersetzt. Warum also funktioniert die Lokalisierung mal wieder nicht ordentlich?

Der offizielle Linux-Dekoder besteht aus einer Binärdatei, die man über die Konsole bedienen kann, und einem scheinbar auf die Schnelle zusammengewürfelten PyGTK-Frontend. Daneben gibt es diverse inoffizielle Shell-Skripte zum Schneiden und das auf GTK basierende Tool „OTR-Verwaltung“, mit dem man nicht nur Dekodieren, sondern die Dateien auch verwalten kann, Schneiden, cutlists erstellen und hochladen, etc., etc.

Solche mächtigen Tools sind zwar schön und gut, aber lohnen sich für mich nicht wirklich, da ich OTR hauptsächlich für ein paar Serien nutze, die nach dem Anschauen gleich wieder ins Nirvana verschwinden. Bleibt also nur der kleine Linux-Dekoder, um mal schnell eine Aufnahme zu dekodieren. Allerdings stört es mich unter KDE zunehmend. Neben der Tatsache, dass GTK-Programme unter einer KDE-Oberfläche trotz diverser Einstellungen schrecklich aussehen, braucht das Programm doch ziemlich lange, bis es bereit ist.

Lange Rede, kurzer Sinn: Entstanden ist ein kleines Frontend für den Dekoder, geschrieben in C++ und Qt. Gleich vorneweg: Es ist weder offiziell, noch hat es in anderer Weise etwas mit OTR zu tun, außer natürlich, dass es deren Dekoder zum Dekodieren benutzt.

Im Moment handelt es sich noch um keine fertige Version. Es werden zwar alle gängigen Features des Dekoders unterstützt, es könnten aber noch Fehler im Programm schlummern. Auch ist es bisher nur auf Englisch. Der Quelltext steht unter der GPLv3, dass heißt, ihr könnt unter deren Auflagen den Quelltext benutzen, wenn ihr wollt. Wahrscheinlich will das aber keiner

Es gibt keine fertigen Pakete, da ich damit noch kaum Erfahrungen habe und der Dekoder meistens eh irgendwo auf dem Desktop oder im Heimatverzeichnis liegt. Ein Paket wäre daher noch übertriebener Aufwand. Das Kompilieren ist allerdings auch nicht tragisch:

Zunächst muss man, wenn nicht schon getan, die Pakete libqt4-dev und g++ installieren. Vieles davon kann man ggf. nach dem Kompilieren wieder entfernen. Wichtig ist nur, dass man zum Ausführen noch das Paket libqt4-gui installiert hat. Danach in einem Terminal zum Quellen-Ordner wechseln und qmake && make ausführen. Die entstandene Binärdatei „QTRdec“ kopiert man sich in das Verzeichnis des Dekoders und schon kann man frohlockend dekodieren. Nützlich ist es auch sicherlich, die Readme-Datei zu lesen.

Der Quelltext kann hier heruntergeladen werden: http://code.google.com/p/qtrdec/downloads/list

Ich freue mich auf eventuelle Rückmeldungen dazu und hoffe, dass es ein paar Leuten evtl. nutzt.

Immer mal wieder schaue ich nach, ob aus dem Quelltext eine lauffähige Version herauskommt, und heute ist mein Glückstag, denn diese Revision aus mozilla-central lässt sich tatsächlich durchkompilieren und starten. Leider ist der Feuerfuchs mit Qt-Oberfläche noch überhaupt nicht brauchbar, aber das wird sicher noch. Wer sich selbst ein Kompilat erzeugen will, kann nach dieser Anleitung vorgehen.

Und hier noch einzwei Bildschirmfotos:

Die aktuellen Werte lassen mich allerdings aufhorchen:

/dev/sda: TOSHIBA MK1637GSX: 55°C

/dev/sdb: TOSHIBA MK1637GSX: 52°C

Laut dem Datenblatt der Festplatte sollte die Betriebstemperatur 55°C nicht überschreiten. Inwieweit Toshiba da eine Toleranz mit eingerechnet hat, weiß ich nicht und will es auch nicht herausfinden. Testhalber habe ich aber mal bei beiden Festplatten einen APM-Wert von 128 eingestellt und das Resultat nach etwas mehr als 10 Minuten:

/dev/sda: TOSHIBA MK1637GSX: 50°C

/dev/sdb: TOSHIBA MK1637GSX: 48°C

Und nach etwa 30 Minuten:

/dev/sda: TOSHIBA MK1637GSX: 49°C

/dev/sdb: TOSHIBA MK1637GSX: 44°C

Bei der ersten Platte gab es immherin 6°C Abkühlung, bei der zweiten Platte sogar 8°C im quasi Leerlauf. Vielleicht sehe ich die Sache auch zu kritisch, aber bei diesen Werten und ohne die Toleranz zu kennen, bevorzuge ich doch lieber den langsamen Verschleißtod als den plötzlichen Hitzetod.