Auf der Ubucon 2008 habe ich ja einen Vortrag über LVM gehalten.

Das ganze hat mir viel Spaß gemacht, und ich denke auch bei den Teilnehmern kam das Thema gut an. Einziger Kritikpunkt waren die LVM-Snapshots, den diese konnte man damals zwar erstellen, aber nicht einfach mal eben zurücksichern.

Dies ist jetzt möglich da Kernel und LVM-Tools die nötigen Patches erhalten und akzeptiert haben. Man benötigt dafür aber Kernel 2.6.33 sowie LVM-Tools in Version 2.02.58 welche es leider nicht mehr in Lucid geschafft haben. Somit muss man auch auf der aktuellen LTS Version, auf dieses sinnvolle Feature verzichten.

Debian Testing hat die benötigte Version der LVM-Tools schon in den Paketquellen, allerdings ist zu hoffen das 2.6.33 es vielleicht doch noch schafft.

Heute haben wir pyNeighborhood in der Version 0.5.1rc2 veröffentlicht. Hier der Eintrag vom Launchpad.

Für Ubuntu gibt es natürlich wieder ein PPA (Link), für Arch Linux ein AUR (Link) und für Debian kommen Pakete sobald die Final Version 0.5.1 veröffentlicht wurde.

Es werden noch freiwillige gesucht die im Launchpad die Übersetzungen für andere Sprachen wie Deutsch und Englisch fertig machen (Link) könnten.

Ich betreue nun seit heute das AUR Paket von pyNeighborhood. Es handelt sich dabei um die aktuellste Version aus den Quellen, d.h. diese ist wesentlich aktueller wie die PPAs die man z.b. auf Launchpad für Ubuntu bekommen würde.

Dies sollte einigen Leute das nervige manuelle installieren in Zukunft sparen. Das PPA wird wohl im laufe der nächsten Woche mal aktualisiert.

Ist euch auch schon aufgefallen das viele Geräte heute Netzwerkfähig sind?

Auf den ersten Blick freut man sich oft, aber ich habe hier viele Geräte in der Firma für die man den Hersteller vierteilen sollte! Das wären z.B.:

• USV Anlagen die kein richtiges SNMP können
• Lautsprecheranlagen die sich nur aus dem aktuellen Subnetz bedienen lassen
• Programme die nur unter dem Benutzer laufen der diese auch Installiert hat

Ich denke es gibt noch einige andere Sachen auf die man gerne reinfallen kann. Beim Kauf einer 200.000€ ELA Anlage denkt man wohl nicht daran das die Implementierung der Netzwerkfähigkeit jeden Fachinformatiker zum weinen bringen würde.

Daher gilt auch hier ein guter alter Spruch: Darum prüfe wer sich ewig bindet, ob sich nicht was besseres findet!

Seit Anfang der Woche gibt es pyNeighborhood in der Version 0.5.1-rc1 im Launchpad.

Zusätzlich gibt es ein neues PPA, so das es nun eine saubere Trennung zwischen meinem Persönlichen PPA und dem Projekt PPA gibt. Dies ist insbesondere sinnvoll da ich ja vielleicht auch mal was anderes als pyNeighborhood in meinem PPA haben möchte.

Hauptsächlich wurden in der neuen Vorabversion von pyNeighborhood übrigens diverse Bugs gefixt. Wenn wir nichts mehr finden was wirklich wichtig wäre hoffe ich das aus dieser Version 0.5.1 wird, welche wir dann in Ubuntu 10.04 LTS bekommen wollen. Der Maintainer hat mir zumindest zugesichert das es kein Problem sein dürfte!

Prima wäre es übrigens wenn ihr gefundene Fehler direkt im Launchpad meldet, Danke.

Ich vermute das schon jeder diesen Link hier kennt.

Auf jeden Fall lohnt es sich mal "reinzuklicken", den es zeigt mal wieder mehr wie doof (oder Verzweifelt) man sein kann ;-)

Ich bin ja seit einiger Zeit der Entwickler von pyNeighborhood.

Neuerungen

In der letzten Version 0.5.0 wurde das Suchen von Netzwerkfreigaben über smbtree erledigt. Es stellte sich jedoch heraus das dies nicht unbedingt die cleverste Entscheidung war. Daher haben wir für Version 0.5.1 wieder eine Browsing-Engine auf Basis von Version 0.4 entwickelt.

Das ist nicht die einzige Umstellung, auch wurde die Versionsverwaltung von Subversion auf Bazaar umgestellt, da sich diese wesentlich besser in Launchpad integriert.

Zusätzlich verwendet pyNeighborhood jetzt intern SQL zur Speicherung der Daten. Keine Angst, niemand muss deswegen eine Datenbank installieren: Wir verwenden SQLite.

Da nicht jeder Drag & Drop mochte haben wir jetzt auch implementiert das man mit einem Doppelklick eine Freigabe mounten kann. Der Rest der Änderungen sind hauptsächlich Bugfixes.

Testen erwünscht!

Da es sich hierbei um eine -rc0 Version handelt bitte ich darum pyNeighborhood einfach mal zu testen. Wenn alles gut läuft könnte dies auch die alte pyNeighborhood Version aus Ubuntu oder Debian ersetzen, was natürlich sehr wünschenswert wäre!

Bezugsquellen

pyNeighborhood steht unter der GPL-3 Lizenz und ist somit also OpenSource Software. Am einfachsten geht es wenn man Ubuntu verwenden, den hierfür habe ich schon ein fertiges PPA. Die andere Möglichkeit wäre direkt die aktuelle Bazaar Version zu verwenden in der vielleicht schon der ein oder andere Bug mehr ausgemerzt wurde. An diese kommt man über die Projektseite, auf welcher man auch gefundene Fehler melden sollte.

Der Wink mit dem Zaunpfahl...

Was pyNeighborhood noch fehlt ist ein richtiges schönes Logo im SVG-Format ;-)

Durch einen Zufall konnte ich heute endlich mal FireWire ausprobieren. Dies liegt daran das ein Arbeitskollege von mir eine Sony DCR-HC51E auf seiner Hochzeit dabei hatte. Leider wusste niemand so genau wie man da Videos runter bekommt :-(

Glücklicherweise verfügt die Kamera über einen Firewire Anschluss so das man mit Kino auch unter Linux ohne große Probleme die Videos von der Kamera bekommt.

Vorbereitung

Firewire

Vorbereiten muss man nicht viel, es genügt wenn die Kernelmodule raw1394 und dv1394 geladen sind:

sudo modprobe raw1394
sudo modprobe dv1394

Software

Als Software ist Kino sehr gut, bei der Fehlersuche ("Steckt die Kamera richtig?") ist gscanbus von Vorteil da man die Bustopologie damit sehen kann:

sudo aptitude install kino gscanbus

Action!

Das einzige was man jetzt noch beachten muss ist, das Kino ja Lese und Schreibrechte auf /dev/raw1394 benötigt. Immer wieder gibt es Anleitungen wie "Nimm einfach den Benutzer in die Gruppe disk mit auf."... Bitte, macht sowas nicht! Den nicht nur /dev/raw1394 hat als Gruppe disk, sondern vor allem auch Datenträger (Festplatten), wodurch es ermöglich wird das man ohne weitere Hürden direkt die Festplatte manipulieren kann, da man ja Schreibrechte direkt auf den Datenträger hat (vorbei am Dateisystem).

Es ist, zumindest wenn man Kino nicht oft braucht viel sinnvoller Kino Temporär als root (mit sudo) laufen zu lassen. Zwar hat Kino dadurch mehr Rechte, und könnte diese durch eine Sicherheitslücke in Kino missbrauchen, aber man öffnet nicht einem User (und somit vielen anderen Sicherheitslücken) die ganzen Datenträger.

Die Sicherheitstechnisch sinnvollste Lösung wäre eine Anpassung der udev Regeln, dies aber auch nur auf den ersten Blick. Den über das IEEE1394 Subsystem ist eh Zugriff auf das restliche System möglich.

Meiner Meinung nach sollte man daher Kino wirklich "einfach" als root (mit sudo) laufen lassen, was sicherlich einigen Administratoren nicht gefallen wird:

sudo kino

Die Videodateien, auch die Exportierten Videos, gehören so aber leider dem Benutzer root. Um das zu ändern kann man dies hier ausführen:

sudo chown benutzer:benutzer /pfad/zu/den/videos/*.dv

Nach diesem Befehl gehören die Dateien dem Benutzer benutzer, und man kann diese wie gewohnt bearbeiten.

Fazit

Video mit Kino von der Firewire tauglichen Kamera zu laden ist relativ einfach. Stolpersteine gibt es eigentlich nur beim Sicherheitsaspekt, was aber wenn man es nicht täglich brauch verschmerzlich ist.

Ich gehe in diesem Artikel nicht weiter auf Kino ein, da es hierfür schon mehr als genug Dokumentation (auch deutsche) im Netz gibt.

Getestet habe ich alles was in diesem Artikel steht unter Ubuntu Hardy Heron (64-Bit, 8.04 LTS), es sollte aber auch auf andere Distributionen übertragbar sein.

Neulich ist mir mal aufgefallen unter welcher Krankheit viele Menschen leiden. Der Maximierungskrankheit!

Symptome

Am Anfang versucht man nur Fenster bei denen es sinnvoll ist zu Maximieren. Später werden fast alle Programme maximiert.

Doch das ist noch lange nichts gegen das Endstatium: Man fängt an Multi-Head Konfigurationen zu basteln, oder versucht selbst den Taschenrechner zu maximieren.

Abhilfe

Eine Behandlung durch Medikamente ist leider (noch) nicht möglich. Man braucht Eisernen willen um nicht zu vergessen das der Browser auch prima ohne 1680x1050 auskommt. So hat man noch Prima Platz für andere Programme/Fenster!

Mir ist aber aufgefallen das ich nicht der einzige mit dieser Krankheit bin, bis auf GIMP (und den Taschenrechner) mache ich leider auch alles groß. Dabei könnte man viel mehr gleichzeitig machen wenn man die vorhanden Fläche/Auflösung effektiver nutzen würde!

Das mit dem maximieren kommt aber wohl aus der Windows Welt, dort arbeitet man ja meistens so. Unter Linux wo sich ein durchschnittlicher Fenstermanager aber merken kann wo ein Fenster aufgehen soll ist das ganze relativ sinnfrei.

Daher: Nieder mit der Maximierungskrankheit!

Für Linux gibt es übrigens ein Window Resizer Addon, das einem dabei hilft den Firefox auch auf großen Schirmen "klein" zu bekommen.

Im laufe der Woche habe ich geprüft ob eine Umstellung von VirtualBox auf KVM für mich Sinn macht.

Was ich am meisten (noch) an KVM vermisse ist Transparentes Networking. So wie es VirtualBox jetzt auch kann, und VMWare es schon ewig tut. Natürlich kann man eine Bridge aufbauen, doch das ist umständlich und muss eigentlich auch garnicht sein!

Dank Virt-Manager gibt es zumindest schon mal eine gute UI für KVM. Dadurch wird die Sache nach und nach wirklich interessant. Das war ja vor einiger Zeit noch ein großes Problem, den KVM auf der Shell macht eher wenig Spaß. Vor allem da es ja eine Vielzahl von Parameter gibt!

An Virt-Manager fehlt aber (noch) der USB Support. Was auf Servern z.B. für USB Dongles für diverse Software ganz praktisch wäre.

Ich denke KVM wird in ca. einem Jahr auch für mich eine Alternative zu Virtualbox sein. In vielen Punkten ist KVM dank Virt-Manager jetzt schon VirtualBox vorraus.