Der lange Weg von Wine 1.4 nach Debian Wheezy

Es hat länger gedauert als viele gedacht hätten. Doch nun ist es soweit und Debian hat ein aktuelles und stabiles Wine in Version 1.4 in seinen Repos. Da ich Wine in der Vergangenheit für einige bekannte Spiele wie World of Warcraft oder Starcraft II benutzt habe, hat mich das Schicksal dieses Pakets nicht kalt gelassen und mir später auch einige interessante Einsichten in die Entwicklung von Debian GNU/Linux gebracht.
Es stimmt, nicht jeder hält Wine, eine Zwischenschicht für Windows entwickelte Programme und dem Linuxkernel, für einen Segen. Ich denke jedoch, dass Wine denjenigen hilft, die irgendwo noch dieses eine, scheinbar unersetzbare, Windowsprogramm haben, dass sie vom kompletten Umstieg auf Linux abhält. Ich habe privat mit Windows nichts mehr am Hut, doch mir hat es in der Vergangenheit beim Wechseln auch geholfen, zugegeben bei einer sehr optionalen Sache wie Computerspielen.

Nun machte mich seit zwei Jahren stutzig, warum Debian mit einer vollkommen veralteten Wine-Version ausgeliefert wurde. Im Sommer letzten Jahres erfuhr ich dann, dass Wine einem sogenannten Code-Audit unterzogen wurde und das gesamte Paket so umgebaut werden musste, dass es sich mit den in Debian verfügbaren freien Werkzeugen auch bauen ließ.
Danach passierte lange Zeit nichts. Der Paketverwalter hatte keine Zeit mehr. Einige engagierte Helfer arbeiteten trotzdem weiter, hatten aber nur eingeschränkte Rechte. Sie wurden vom ursprünglichen Paketverwalter nicht als Teammitglieder aufgenommen und hatten deswegen keine Möglichkeit eine neuere Version hochzuladen.

Erst als einer der Helfer, Michael Gilbert, schließlich zum Debianentwickler "befördert" wurde, durfte er sogenannte NMUs von Wine einstellen. Diese Non-Maintainer-Uploads sind in der Regel nur dafür gedacht um ein gravierendes Problem mit einem Paket zu lösen, wenn der ursprüngliche Paketverwalter keine Zeit dafür hat. Jeder Debianentwickler hat das Recht dazu. Die Pakete werden je nach Dringlichkeit in eine Warteschlange gepackt, so dass Zeit bleibt das Paket zu begutachten oder auch wieder zu entfernen, wenn es den Ansprüchen nicht genügen sollte.
Obwohl der Paketverwalter selbst nicht aktiv sein konnte, forderte er jedoch, dass jede einzelne Wine-Version in den letzten zwei Jahren nach und nach hochgeladen werden sollte. Spätestens hier begannen einige dann den Kopf zu schütteln.
Joey Hess brachte es dann auf den Punkt. Der Bug demonstriere Schwächen in prozeduralen und administrativen Bereichen. Anstatt zu versuchen ein perfektes Paket zu bauen, wäre es für die Mehrheit der Benutzer besser gewesen, wenn man einfach ein aktuelles Wine-Paket verfügbar gemacht hätte. Notfalls hätte man sich auch der Ubuntu-Version bedienen können, die nachweislich einwandfrei funktioniere.
Was mich später beeindruckt hat, war das Verhalten von Michael Gilbert, der wiederholt geschrieben hat, dass es ihm besser gefällt auf Zusammenarbeit zu setzen als die Konfrontation mit dem Paketverwalter zu suchen. Optionen wie Wine für sich zu beanspruchen ("Hijacking") schloss er z.B. ausdrücklich aus. Steve Langasek ging soweit zu sagen, dass Hijacking schlicht "asozial" sei und es weitere Prozeduren wie z.B. "Orphaning" oder das Technische Komitee gebe, womit dem Paket ein neuer Paketverwalter zugewiesen werden könne.

Am Ende wurden alle Helfer schließlich zu offiziellen Teammitgliedern des Wine-Pakets gemacht und die Arbeit konnte normal fortgesetzt werden. Der ganze Vorgang hat exemplarisch gezeigt, welche dynamischen Prozesse in einem Projekt wie Debian ablaufen, in dem jeder einzelne Entwickler eine sehr starke Stellung, aber auch viel Verantwortung hat.

Für alle Benutzer gibt es als Ergebnis nun zu vermelden, dass es sowohl möglich sein wird Wine 1.4 (stable) als auch die Entwicklerversion (im Moment 1.5) in Zukunft parallel zu installieren und Dank Multiarch sollte es später ebenfalls möglich sein, sogar 4 verschiedene Wine-Versionen parallel einzurichten. Happy End.

Der Fünf-Cent-pro-Tag-vServer

Im Februar hatte ich mich für das Mieten eines vServers entschieden und im März festgehalten, was mich an einem solchen virtuellen Rechner für mein Spieleprojekt interessierte. Als ich ein paar Wochen zuvor auf der Debian-Devel-Mailingliste auf das Thema OpenVZ- und XEN-vServer gestoßen bin, wusste ich zwar, inwiefern sich die einzelnen Virtualisierungstechnologien unterscheiden, kannte aber das Wettbewerberfeld der VPS-Abieter kaum.
Inzwischen weiß ich mehr und bin zwischenzeitlich ebenso Kunde bei NbIserv geworden und miete dort den VS-Prepaid-Server.

Wenn man die Angebote scannt laufen einem die drei gängigsten freien Virtualisierungstechniken OpenVZ, XEN und KVM regelmäßig über den Weg. Des öfteren findet sich leider auch gar keine Angabe auf der Webseite des Anbieters oder sie ist zumindest gut versteckt.
Ich empfehle bei der Suche nach dem passenden vServer weder den obligatorischen Testseiten noch einem Bericht zu vertrauen. Das klingt übertrieben vorsichtig, aber meiner Meinung nach ist es bei kaum einem anderen Produkt einfacher sich selbst einen ersten Eindruck zu verschaffen. Anfragen zum Testen des vServers wurden bisher bei mir immer positiv beantwortet und selbstverständlich steht euch natürlich auch ein Widerrufsrecht zu, wenn der Server nach den ersten Tagen nicht gefallen sollte.
Einige interessante Ideen zu Testmethoden für vServer habe ich auf Virtualist.de gefunden, einer Seite, die sich ebenfalls vServer-Tests widmet. Zwar gilt auch hier das, was ich ein paar Zeilen zuvor geschrieben habe, ich verlinke sie trotzdem, weil ich bei zwei dort gelisteten Anbietern mittlerweile selbst zufriedener Kunde bin und die Seite ein guter Einstieg ist, wenn man erst einmal nur eine Liste mit Anbietern haben möchte. Den Rest überlasse ich eurer Bewertung.

NbIServ

Dort bin ich auf NbIServ gestoßen, ein Unternehmen aus dem Raum Gera in Thüringen. Der Anbieter wirbt mit einem sogenannten Prepaid-Server. Die Kosten belaufen sich auf 5 Cent pro Tag. Sollte das Guthaben 30 Tage lang unter 0,01 Euro liegen wird der Server gelöscht und der Vertrag beendet. Eine Mindestvertragslaufzeit gibt es nicht. Als Kennwerte liefert der Server 128MB RAM und 2 GB Speicherplatz. Bei den Werten kann man sich die Virtualisierungslösung denken, es ist natürlich OpenVZ. Besonders für dieses Preisniveau ist auch das Anlegen eines Snapshots für Backupzwecke, das problemlos vom FTP-Server heruntergeladen werden kann.
Die Bestellung ist unkompliziert. Typisches Onlineformular und danach den Vertrag plus Kopie des Personalausweises per E-Mail an den Anbieter schicken. Die Bereitstellung des Servers erfolgte innerhalb weniger Stunden.

Das Benutzerszenario

Ich wollte schon länger einen SSH bzw. OpenVPN-Server im Netz haben, zu dem ich mich aus unsicheren Netzen verbinden kann. Außerdem gefiel mir die Idee einem eigenen Mumble/Murmur-Server zur Verfügung zu haben, wofür NbIServ sogar ein spezielles Abbild anbietet. Da von den Ressourcen weiterhin Luft war konnte ich mir auch den schon erwähnten vsftpd-Server für OpenArena leisten. Von der Bandbreite stehen mindestens 100 Mbit laut Produktbeschreibung bereit und 1 TB Traffic sind inklusive. Den Traffic erreiche ich natürlich nicht einmal annähernd, die Bandbreite schwankt nach Tageszeit, war für mein Szenario bisher aber immer ausreichend.
Den Support habe ich bisher als vorbildlich und schnell erlebt. Die "langsamste" Reaktionszeit war drei Stunden. Das Ticket wurde mit Priorität "gering" um Mitternacht abgeschickt und um 3.00 Uhr beantwortet. 😉 Mir wurde ebenso prompt beim Aktivieren des TUN-Device für OpenVPN geholfen. Der einzige Makel, der mir bisher aufgefallen ist, war ein teilweise hoher Serverload zwischen 1-6 Uhr, wo ich die Vermutung hatte, dass die automatischen Backups der Mitkunden dafür verantwortlich waren. Der Support hat den vServer auf einen anderen Master umgezogen, seitdem läuft der Server vollkommen stabil.

oVZManager

NbIServ benutzt den oVZManager als webgestützte Administrationshilfe. Ich finde, er ist übersichtlich strukturiert und bietet alle wichtigen Optionen, die man als Kunde wirklich braucht. Server stoppen und starten, neue Images einspielen, Kontostand abfragen, Traffic überwachen und es gibt sogar die Möglichkeit einen Backupsnapshot anzulegen. Momentan findet ein Upgrade auf Version 2.0 statt.

Was mir in der 128-MB-OpenVZ-Klasse bisher aufgefallen ist

    • Aptitude weigert sich manchmal eine Installation durchzuführen: FATAL -> Failed to fork.

Das Problem ist im Wiki von openvz.org gut erklärt und bedeutet nichts anderes, als dass dem Container bzw. der Applikation nicht genug Ressourcen, in meinem Fall privvmpages, zur Verfügung stehen. Am einfachsten umgeht man das Problem, indem man apt-get in diesem Fall zum Paketmanagement benutzt.

    • Monit Fehlermeldung

'localhost' statistic error -- memory usage gathering failed
May 24 16:58:49 hostname monit[1077]: system statistic error -- cannot get real memory buffers amount

Ein bekannter Bug in Monit, der in Debian Wheezy gefixt worden ist. Ein Upgrade hilft. Außerdem habe ich extrem hohe CPU-Wait-Werte mit Monit gemessen, die so nicht stimmen können. Dem Bug bin ich aber bisher nicht weiter nachgegangen.

    • Allgemeine Ressourcenknappheit und Einschränkungen

128 MB RAM ist natürlich nicht üppig. Man muss/sollte seine Ansprüche dementsprechend anpassen. Mit meinem Benutzerszenario komme ich jedoch auf ca. 600 MB belegten Festplattenspeicher und eine Auslastung von 44 MB RAM bei einem 64bit Debian. Zum Monitoring, für einen Voice-Server oder einen kleinen Webserver reicht das. OpenVZ virtualisiert auf Betriebssystemebene. Man teilt sich den Kernel mit allen anderen Gästen und man hat in der Regel als Kunde keinen Einfluss auf geladene Kernelmodule. Eine freundliche Anfrage beim Support hilft hier oft weiter.

Warum der lange Text?

Hey, das ist ein Blog. 🙂 Ich bin nun seit einem Monat Kunde bei NbIServ und werde mir das Angebot längerfristig anschauen. Wenn sich etwas dramatisch ändert, werde ich auch darüber schreiben. Die Quintessenz des Ganzen ist: Es gibt Angebote für kleine Aufgaben, die nicht unbedingt viel Geld kosten müssen und sie lassen sich spielend leicht testen. Im Prinzip ist es bei dem Produkt "vServer" egal, was man irgendwo liest, solange es möglich ist die "Ware" vorher zu prüfen. Ihr kauft hier kein neues Auto und selbst bei Mindestvertragszeiten von einigen Monaten kann man sich in der Preiskategorie auch einen "Fehlschlag" erlauben. Ich denke 5 Cent pro Tag ist fair.

Noch ein Kandidat

Einen weiteren Blick habe ich auf nhost und dessen Angebot "vServer S" geworfen. Ich halte mich kurz. Das Produkt ist ähnlich zu dem von NbIServ, mich überzeugte aber die Leistung nicht. Zwar steht z.B. 2 TB Traffic nominell zur Verfügung, aber schon beim Einloggen verhielt sich das System weniger reaktionsfreudig. Auch der Festplatten-Benchmark bonnie++ zeigte z.B. schlechtere Werte als bei NbIServ an. Außerdem gab es hier keine Backupmöglichkeit und die Vertragslaufzeit beträgt 12 Monate, obwohl mich das in dieser Preiskategorie nicht abschreckt.
Der Support war freundlich und antwortete schnell. Nhost ist scheinbar noch ein junges Unternehmen, deswegen würde ich auch hier einen eigenen Testserver anfordern und mir die Sache selbst anschauen. Die Bereitstellung über den Support war problemlos möglich.

Serverway und der Spieleserver

Nicht unerwähnt lassen möchte ich an dieser Stelle noch serverway.de, wo mein Spieleprojekt gehostet wird. Ich bin mit dem Anbieter bisher sehr zufrieden. Trotzdem ich das kleinste vServer-Angebot mit XEN benutze ist die Leistung für alle dort laufenden Spieleserver im grünen Bereich. Interessant ist auch, dass Serverway KVM-vServer anbietet, bei denen man Betriebssysteme wie FreeBSD und Linuxkernel beliebig installieren kann. Ich hoffe, die Leistung bleibt einfach so.

E-Mails lesen ist wie Linux

Ich bin gerade drauf und dran Mutt näher kennenzulernen. Dieses Mal ernsthaft. Zuvor hat mich die detailverliebte Konfiguration immer ein wenig von der Entdeckung abgehalten.
Just in diesen Tagen erhielt ich auch den ersten Kommentar zu Alpine, einem weiteren herausragenden E-Mail-Programm für die Konsole. Nach wie vor fühlt sich Alpine für mich wie der "typische" E-Mail-Client an, der nicht nur Mails verwalten (Stichwort: MUA), sondern auch senden, empfangen und filtern kann.
Mutt hingegen bleibt seinen Zielen treu: "Ein Programm für eine Aufgabe". Je nach Bedarf kommen noch Helfer wie msmtp, fetchmail oder procmail hinzu.
Da ich immer noch drei verschiedene E-Mail-Programme benutze und dabei nicht mal den gelegentlichen Zugriff per Webbrowser als Extravariante dazuzähle, frag ich mich manchmal auch, wie viel E-Mail-Clients braucht die Welt und ob ich nicht auch mit einem auskommen könnte. Doch E-Mails lesen ist scheinbar doch wie Linux.
Ich kann mich ehrlich gesagt nicht mehr an all meine Entdeckungen erinnern. Nur soviel weiß ich noch, dass ich schon sehr früh einen Webmail-Zugang hatte, Horde sei Dank. Gleichzeitig musste ich mich mit Outlook Express herumschlagen. Zum Glück nicht lange, denn schon kurz nach meinem Einstieg in die Linuxwelt stieß ich auf KMail, dem ich aber, ebenso wie KDE, nicht lange treu geblieben bin.

Evolution


Die Groupware-Suite des Gnome-Desktops übernahm spätestens seit 2006 die Führung, als ich zum ersten Mal Ubuntu ausprobiert hatte. Es war damals wie heute sehr angenehm, dass das E-Mail-Programm perfekt in die Desktopumgebung integriert ist und Kalender- oder Adressbuchinformationen mit anderen Anwendungen geteilt werden. Evolution bestach schon immer durch ein übersichtliches und intuitives Design und die simple Einrichtung von neuen E-Mail-Konten. Bis zum letzten Jahr benutzte ich es durchgehend und entschied mich erst im Zuge des Wechsels zu Debian Testing und der Umgestaltung meines Rechners zum Multiboot-System für einen Umstieg. So fließend die Übergänge und die Integration von Evolution in Gnome ist, einen Nachteil hat das Ganze. Die Verzahnung macht Evolution auch schwerfällig und seine Abhängigkeiten zu Gnome führen dazu, dass er sich als alleinstehendes E-Mail-Programm in einem leichtgewichtigen Fenstermanager-Setup kaum eignet.

Thunderbird alias Icedove


Letztes Jahr entschied ich mich schließlich dazu auf Mozillas Thunderbird oder besser Debians Icedove zu setzen. Die Wahl fiel nicht schwer, da er mir auch in der Windows- und Mac-Welt häufiger begegnet. So gelang es mir zwar nicht meinen Vater komplett zum Umstieg auf Linux zu überreden, aber wenigstens hat er mit Thunderbird nun Gefallen an einem Stück Freier Software gefunden, ohne dass er sich dessen wahrscheinlich wirklich bewusst ist. 😉 Das wirklich Positive an Icedove ist, dass die Einrichtung eines neuen E-Mail-Kontos mit ein paar Klicks ein Kinderspiel ist und wirklich so gemacht ist, dass auch Gelegenheitsnutzer hier durchsteigen können.
Ich persönlich empfinde die Performance gegenüber Evolution, gerade im Umgang mit IMAP-Servern, auf dem gleichen Rechner als besser. Für den letzten Feinschliff gibt es wie bei Mozillas anderem Vorzeigeprojekt, Firefox, Addons, die die Funktionalität des Programms spielend erweitern können. Am besten gefallen mir hier Lightning, der Kalender, und Enigmail, mit dem ich E-Mails mit GnuPG signiere.

Claws-Mail


Hast du einen älteren Desktop-PC oder Laptop, möchtest aber nicht auf Komfort und eine grafische Oberfläche zum E-Mail abrufen verzichten, dann ist möglicherweise Claws-Mail das richtige Programm für dich. Es besticht neben einer exzellenten Performance, schnellen Startzeiten und einer Fülle an Funktionen zum punktgenauen Justieren jeder E-Mail-Einstellung ebenso durch Plugins, die sich bei Debian und Co. leicht über das Paketmanagement installieren lassen. Claws-Mail reagiert ausgesprochen reaktionsfreudig selbst bei Tausenden von Mails (manche sprechen sogar von Zehntausenden) und bietet ebenfalls die Möglichkeit E-Mails mit GnuPG zu verschlüsseln und zu signieren. Claws-Mails große Fülle an Funktionen macht es nicht ganz so schnell zugänglich wie Thunderbird. Seine geringen Anforderungen an die Hardware, wenige Abhängigkeiten mit anderen Paketen und seine Leistungsfähigkeit sind jedoch die perfekte Voraussetzung für jedes leichtgewichtige Desktopsystem. Abgesehen davon ist die Bedienung mit der Tastatur ebenfalls sehr gut gelöst.
Als Alternative bleibt Sylpheed, von dessen Codebasis sich Claws-Mail mittlerweile abgespalten hat. Für alle, die es gerne grafisch mögen und einen sehr leistungsfähigen E-Mail-Client suchen, kann ich Claws-Mail auf jeden Fall sehr empfehlen.

Alpine


Noch ressourcenschonender E-Mails lesen lässt sich mit Alpine und konsolenbasierten E-Mail-Clients. Alpine benutze ich seit 2 Jahren. Es hat den Charm selbst auf den ältesten Computern problemlos zu funktionieren und verhält sich dabei wie man es von einem typischen E-Mail-Client gewohnt ist. Alpine kann sowohl Mails versenden, mehrere POP- und IMAP-Konten abrufen und verwalten und Nachrichten gemäß vorgegebener Rollen filtern und weiterverarbeiten. Viele Konsolenprogramme funktionieren ausgezeichnet in Zusammenhang mit Alpine, darunter z.B auch Antiword, mit dem angehängte Word-Dokumente in Textform dargestellt werden können.
Einziger Wermutstropfen: Die Entwicklung von Alpine wurde 2008 von den Universität von Washington eingestellt. Zwar gibt es das Nachfolgeprojekt re-alpine, doch die ganz großen Veränderungen sind seitdem ausgeblieben. Ich vermisse z.B. eine standardmäßige Integration von GnuPG. Wer jedoch darauf verzichten kann und Englisch als einzig unterstütze Sprache akzeptiert, hat ein leicht zugängliches und gut dokumentiertes Programm für die Konsole, das auch den Ansprüchen fortgeschrittener Nutzer genügt.

Mutt


Nun also noch Mutt. Er hat den Ruf ein Werkzeug für Fortgeschrittene und Profis zu sein und gehört zu den Standardwerkzeugen einer Debianinstallation, was auf die große Verbreitung unter Debianentwicklern zurückzuführen ist. (Vermutlich) ist er der letzte E-Mail-Client, mit dem ich mich näher beschäftigen werde. Im Gegensatz zu den Vorurteilen gelingt der grundlegende Einstieg recht schnell, wenn man eine gute Erklärung findet. Man muss sich daran gewöhnen, dass Mutt strikt nach Aufgaben trennt und eben nur ein MUA ist, also die Oberfläche, die die E-Mails verwaltet und darstellt. Sowohl für das Senden als auch das Filtern von E-Mails werden zusätzliche Werkzeuge benötigt. Mutt entspricht deswegen wie kaum ein anderer E-Mail-Client der modularen UNIX-Philosophie: "Schreibe Computerprogramme so, dass sie nur eine Aufgabe erledigen und diese gut machen".

Schlusswort

Linux wurde in der Vergangenheit oft mit dem Ruf belegt ein Betriebssystem zu sein, das sich ausschließlich nur über die Konsole sinnvoll bedienen lässt. Man hört schnell die Unterstellung heraus, Linux lasse sich eben nur auf eine Art und Weise "richtig" bedienen.
Linux verhält sich genauso wie die Suche nach dem passenden E-Mail-Programm. Zuallererst ist alles eine Geschmacksfrage. Mancher bevorzugt eine konsistente Desktopumgebung wie Gnome, wo jede Applikation mit der anderen ineinandergreift, andere wiederum suchen eine einfache und geradlinige Konfiguration oder ein E-Mail-Programm, das schlicht unabhängig und überall einsetzbar ist.
Es gibt kein Richtig oder Falsch, nur eine Vielzahl an Möglichkeiten. Mir hilft Freie Software etwas Neues zu entdecken, etwas, dass sich meinen Rechnern anpasst, transparent ist, sich kontrollieren lässt und auf meine Wünsche eingeht.
Kurz: E-Mails lesen macht Spaß.

Iceweasel ESR für Debian Squeeze und Wheezy – Kein Support mehr für 3.6

Eine kurze Erinnerung an alle, die Iceweasel alias Firefox mit Debian verwenden. Mike Hommey, Paketverwalter für Iceweasel und Firefox-Entwickler, hat gestern in seinem Blog noch einmal daran erinnert, dass Iceweasel 10 ESR in den Backports für Debian Squeeze zur Verfügung steht. Die ehemals unterstützte Version 3.6 erhält keine Updates mehr und sollte nicht mehr benutzt werden.
Weiterhin wird zwar Iceweasel 3.5.16 wie gewohnt bis 2014 unterstützt, er empfiehlt aber ein Upgrade auf Iceweasel 10 zu machen. Dieser Empfehlung möchte ich mich hier anschließen. Man bemerkt deutlich die verbesserte Leistung des neueren Iceweasel-Browsers. Außerdem stehen deutlich mehr Funktionen und aktuellere Addons zur Verfügung.

Update 07.06.2012: Heute wurde auf der Debian-Mailingliste "debian-security-announce" offiziell empfohlen von Iceweasel 3.5 auf Iceweasel 10 ESR zu wechseln.
Ich gehe davon aus, dass Iceweasel 10 uns in der nächsten stabilen Veröffentlichung von Debian erhalten bleibt und entweder separat durch Mike Hommey weitergepflegt wird oder durch die nächste ESR-Version, Iceweasel 17, wie bisher durch einen Backport ersetzt wird.
Unter dem Begriff ESR oder Extended Support Release verbreitet Mozilla ein Langzeit-Release, dass vor allem Unternehmen und Öffentlichen Einrichtungen zu Gute kommen soll, die an einer stabilen und langfristig gepflegten Version interessiert sind und nicht die Möglichkeiten haben den normalen "Rapid-Release"-Zyklus zu supporten.
Die aktuellste Version von Iceweasel befindet sich zur Zeit in Experimental. Auf mozilla.debian.net werden nach wie vor die Wege beschrieben, wie man an die gewünschte Version für den jeweiligen Debian-Zweig gelangen kann.
Ansonsten kann ich noch meine Artikel zu Debians Backports oder Iceweasel 6 empfehlen, die das Prinzip ebenfalls erklären.
Wer immer den Überblick über das Versionswirrwarr behalten möchte, kann sich z.B. auch apt-show-versions installieren. Hat man zuvor alle Quellen/Zweige in der /etc/apt/sources.list eingetragen, für die man sich interessiert, genügt

apt-show-versions -a iceweasel


um eine Übersicht über alle verfügbaren Paketversionen zu erhalten.

vnstat und vnstati: Volumen des Netzwerkverkehrs übersichtlich visualisieren

Im Zeitalter von Flat-Angeboten rangierten bei mir Programme zum Überwachen des Datenverkehrs bisher eher auf den hinteren Plätzen. Seitdem ich aber einen vServer mein Eigen nenne, interessiert mich das tägliche Volumen an ein- und ausströmenden Bits und Bytes umso mehr.
Gut, ich denke die meisten VPS-Anbieter bieten schon eine Art von Netzwerkmonitor an, da sie selbst daran interessiert sind, dass der Kunde die vereinbarte Trafficgrenze nicht überschreitet. So macht das mein Anbieter auch und stellt mir sogar eine grafische Übersicht und Charts zur Verfügung, wann und wie viel Datenverkehr durch die Leitungen fließt.
Der Nachteil des Ganzen ist, ich muss mich erst einmal in das Kundenmenü einloggen und kann nicht eben so die Daten auch auf meiner Projektseite darstellen.
Wie immer gibt es mehrere Alternativen. Ich dachte zuerst an RRDtool und MRTG oder ntop. Beide sahen sehr vielversprechend aus, doch sie boten mir zu viele Funktionen, wenn man das so pauschal umschreiben kann. Ich hingegen wollte etwas schlichtes und einfaches. Eine Ausgabe auf der Konsole, vielleicht noch ein paar nette Graphen dabei, die die Datenmenge visualisieren.
Womit ich bei vnstat gelandet war und ein charmantes Werkzeug gefunden hatte.
Vnstat hat ein Init-Skript und startet als Daemon. Im Hintergrund überwacht er dann das vorher definierte Interface und sammelt die mitgezählte Datenmenge in einer Datenbank. Keine Sorge, vnstat ist äußerst genügsam. 1 MB RAM solltet ihr aber einplanen.
Zuerst muss das Interface in /etc/vnstat.conf definiert werden, welches standardmäßig überwacht werden soll. Danach wird die Datenbank erstellt bzw. erneuert. Z.B. für eth0:

vnstat -u -i eth0


Macht man das nicht, erscheint diese Fehlermeldung.

Starting vnStat daemon: vnstatdZero database found, exiting.

Die restlichen Optionen in der Konfigurationsdatei sind gut dokumentiert. Dort lässt sich vor allem das Erscheinungsbild der Ausgabe festlegen.

Bedienung

Die Bedienung von vnstat ist unkompliziert.

vnstat -s

                     rx      /      tx      /     total    /   estimated
 eth0:
       May '12    911.31 MiB  /    1.45 GiB  /    2.34 GiB
       Jun '12    470.22 MiB  /  773.50 MiB  /    1.21 GiB  /   18.40 GiB
     yesterday    287.79 MiB  /  468.17 MiB  /  755.96 MiB
         today    182.42 MiB  /  305.33 MiB  /  487.75 MiB  /     496 MiB

vnstat -h

 eth0                                                                     23:35
  ^      t
  |      t
  |      t                                                           t
  |      t                                                           t
  |      t        t                                                  t
  |      t        t                                                  t
  |     rt        t                                                  t
  |   t rt        t                                t                 t
  |  rt rt  t     t                               rt              t  t r   t
  |  rt rt rt     t                      rt       rt rt          rt rt rt rt
 -+--------------------------------------------------------------------------->
  |  00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17 18 19 20 21 22 23
 h  rx (KiB)   tx (KiB)      h  rx (KiB)   tx (KiB)      h  rx (KiB)   tx (KiB)
00      14016      23119    08       1331       1338    16       9086       9262
01      30605      63348    09       2884       1561    17       3132       2485
02      10203      18235    10       3578       2039    18       5605       2448
03       2365       1848    11       6236       6186    19       5697       6172
04       2930      42386    12       8270       6724    20      12474      14342
05       1437       1210    13       5878       4099    21      11467      55362
06       1680       1886    14       5107       2972    22      17298      11634
07       1554       1231    15      13417      19035    23      12446      16185

vnstat -d

eth0 / daily

         day         rx      |     tx      |    total    |   avg. rate
     ------------------------+-------------+-------------+---------------
      05/28/12    159.61 MiB |  263.27 MiB |  422.88 MiB |   40.09 kbit/s
      05/29/12    215.86 MiB |  382.90 MiB |  598.75 MiB |   56.77 kbit/s
      05/30/12    227.47 MiB |  315.93 MiB |  543.41 MiB |   51.52 kbit/s
      05/31/12    308.36 MiB |  520.59 MiB |  828.96 MiB |   78.60 kbit/s
      06/01/12    287.79 MiB |  468.17 MiB |  755.96 MiB |   71.68 kbit/s
      06/02/12    184.27 MiB |  307.72 MiB |  492.00 MiB |   47.47 kbit/s
     ------------------------+-------------+-------------+---------------
     estimated       187 MiB |     312 MiB |     499 MiB |

Abgerundet wird das Ganze noch durch vnstat -m und vnstat -t, eine monatliche Anzeige und die Übersicht der 10 verkehrsreichsten Tage.

vnstat als tägliche Zusammenfassung per E-Mail erhalten

Man kann z.B. einen Cron-Job definieren, der täglich um 23:59 die Zusammenfassung per Mail an den Superuser schickt.

59 23   * * *   apo             /usr/bin/vnstat -s | mail -s "vsrv52135: Daily traffic eth0" root@localhost

vnstati

Praktischerweise gibt es noch vnstati, dass die Statistiken in schöne, übersichtliche Graphen transformieren kann.

Ich habe mir ein simples Skript geschrieben, dass jeden Tag um Mitternacht die Graphen produziert und in ein Verzeichnis des Webservers kopiert.

#!/bin/sh
# Visualisierter Netzwerkverkehr mit Vnstat
# Ausgabe der Dateien in das Webserververzeichnis stats/traffic
set -e
Target="/home/linuxiuvat/linuxiuvat.de/stats/traffic/graph/"
# stündlich
/usr/bin/vnstati -h -o ${Target}vnstat_hourly.png
# täglich
/usr/bin/vnstati -d -o ${Target}vnstat_daily.png
# monatlich
/usr/bin/vnstati -m -o ${Target}vnstat_monthly.png
# Top10
/usr/bin/vnstati -t -o ${Target}vnstat_top10.png
# Zusammenfassung
/usr/bin/vnstati -s -o ${Target}vnstat_summary.png

Anschließend lässt sich die visualisierte Datenmenge unter http://linuxiuvat.de/stats/traffic/ anschauen.

apt-clone: Backup in verbesserter Debian-Manier

Eher durch Zufall bin ich erneut auf apt-clone gestoßen, nachdem ich nach Programmen mit vorangestelltem "apt-" gesucht hatte. Vor einem Jahr wurde dieses schicke Skript auf linuxundich.de vorgestellt, als apt-clone noch dabei war in Debian aufgenommen zu werden.
Apt-clone ist im Prinzip der verbesserte "The Debian Way" beim Backup machen.
Es übernimmt automatisch das Sichern des Paketstatus, speichert den Schlüsselring und kann sogar nicht mehr herunterladbare Pakete oder Drittprogramme mit dpkg-repack wieder in neue Pakete verschnüren. Ziemlich praktisch, wenn man seine Druckertreiber gelöscht hat und diese nun neu gepackt werden.

Backup machen

apt-clone clone /home/apo --with-dpkg-repack

Wiederherstellen

apt-clone restore apt-clone-state-rechnername.tar.gz


Die Syntax ist ziemlich übersichtlich. Mit apt-clone clone wird ein Backup gemacht und in meinem Home-Verzeichnis gespeichert und zusätzlich nicht mehr verfügbare Pakete neu gepackt. Nach kurzer Zeit landet alles in einer Tar-Datei und kann mit apt-clone restore wiederhergestellt werden. Das wars.
Sicher ein Vorteil, wenn man den aktuellen Paketzustand des Rechners dauerhaft klonen möchte. Zusätzlich muss dennoch /etc und /home gesichert werden, was aber in den meisten Fällen ausreichend ist um ein Debian-basiertes System zu sichern und wieder ruhig schlafen zu können :).

Debian Administrator's Handbook und ein neuer Link für das Blogroll

Ok, nach den letzten Posts denke ich, war es an der Zeit Raphaël Hertzogs Blog auch mal dauerhaft in meinem Blog als Link und Blogroll zu verankern. Normalerweise braucht man so etwas wahrscheinlich nicht noch einmal extra ankündigen, aber da das Hinzufügen eines Blogrolls in diesem Blog durchschnittlich alle zwei Jahre passiert, musste ich doch ein paar Worte drüber verlieren.

Bevor ich hier einen Permalink verewige habe ich in der Regel mehrere Stunden und eher Tage mit dem Lesen des Blogs verbracht und kenne das Blog seit mehreren Monaten. Das Thema muss selbstverständlich passen. Ob danach noch regelmäßig Artikel erscheinen spielt keine Rolle, sofern die Seite weiterhin online ist. Das ausschlaggebende Argument ist, das Lesen des Blogs hat mich dazu gebracht mich so stark mit den dortigen Themen zu beschäftigen, dass man schon sagen kann: Es hat mein Leben verändert!
Pathos, Pathos, mag sein. Bei KMandla oder Urukrama stimmt das aber.
Raphaël Hertzogs Blog ist nicht nur informativ, es gibt Menschen, die für Debian arbeiten ein Gesicht. Wer schon immer mal wissen wollte, wer sich hinter dem Namen des Paketverwalters eines Debianpakets verbirgt, erfährt hier viel Wissenswertes.
Insbesondere interessiert mich aber die Sicht eines Debianentwicklers, der seit seinem 18. Lebensjahr dabei ist und so wichtige Werkzeuge wie dpkg mitentwickelt und auch dokumentiert, wie man selbst zu Debian beitragen kann.
Außerdem fällt er auf der Mailingliste debian-devel immer mit technischen und sachkundigen Posts auf, was man nicht von allen Teilnehmern der Liste behaupten kann.
Dann wäre da noch sein Buch Debian Administrator's Handbook, dass in Zusammenarbeit mit Roland Mas erschienen ist. Ich denke, es ist ein großartiger Beitrag zu Debian GNU/Linux, da es unter einer freien Lizenz steht und für jeden online oder zum Download bereitsteht und ein wirklich gutes Nachschlagewerk zu vielen Themen rund um Debian ist.
So viel zu meinen wichtigsten Gründen. Mag sein, dass ich zu kritisch bin und mehr Permalinks setzen sollte. Ich versuche das mit Links zu speziellen Artikeln in einzelnen Posts, die zum Thema passen und interessant sind, wieder wett zu machen. Vielleicht ist am Ende ja zumindest ein wenig tröstend, dass ich alle gleich schlecht behandele.

Aufräumtipps Teil III: Debsums – Geänderte oder kaputte Dateien mit Debian und Ubuntu finden

Debians Paketsystem kann mehr als nur Software installieren. Tatsächlich ist jedes Paket nach einem sehr präzisen Schema aufgebaut, dass es ermöglicht zusätzliche Informationen zu speichern. Eine (beinahe) unverwechselbare Eigenart jedes Pakets ist die Md5-Prüfsumme. Beinahe deswegen, weil es mittlerweile möglich ist verschiedene Dateien zu erzeugen, die den gleichen Hashwert besitzen.
Zum Auffinden von geänderten Dateien gibt es das Paket debsums. Ruft man es einfach mit

debsums


auf, ist die Ausgabe sehr wortreich und zeigt mit OK oder FAILED an, ob eine Datei eines installierten Debianpakets manipuliert wurde oder nicht. Ausgeschlossen von dieser Anzeige sind grundsätzlich Konfigurationsdateien. Mit der Option -a, --all werden diese in die Überprüfung miteinbezogen. Gibt man hingegen -e, oder --config an werden nur geänderte Konfigurationsdateien angezeigt.
Die interessanteste Option aber ist -c oder --changed, mit der sich nur die veränderten Dateien anzeigen lassen. Ich hatte vor einigen Wochen die Installationsbeschreibung für meinen neuen Drucker niedergeschrieben und dabei auch dokumentiert, dass ich /lib/udev/rules.d/60-libsane.rules ändern musste.
Ein paar Wochen später wunderte ich mich, warum der Scanner nicht mehr richtig funktionieren wollte. Ich hatte leider vergessen, dass die Regeln durch ein Upgrade von udev überschrieben wurden und somit meine Veränderungen verloren gingen. (Ich muss das im alten Beitrag noch ergänzen. 🙂 )
Mit

debsums --changed


sieht man dann sofort, welche Dateien des Pakets geändert worden sind und kann ggf. Vorsichtsmaßnahmen ergreifen. Nicht jedes Debianpaket bietet eine Md5-Prüfsumme an. Wie Eingangs schon erwähnt besteht auch die Möglichkeit identische Prüfsummen für zwei verschiedene Dateien oder Pakete zu erzeugen, weswegen man sich nicht blind auf debsums bei einem Sicherheitsaudit des eigenen Rechners verlassen sollte. Es gibt auch Software wie z.B Tiger, die eine solche Funktion schon integriert hat.
Insgesamt ist debsums ein sehr nützliches Werkzeug, wenn man schnell wissen möchte, was sich gegenüber dem Originalpaket geändert hat oder wenn man fremde Rechner übernimmt und einen schnellen Überblick über die Veränderungen haben möchte.
Dieser Tipp stammt ebenfalls aus dem englischen Blog von Raphaël Hertzog.

Aufräumtipps Teil II: Automatisch installierte Pakete mit Debian und Ubuntu entfernen

Hier ist ein weiterer Artikel zum Thema Aufräumen mit Debian und Ubuntu, der sich an den letzten Artikel nahtlos anschließt. Raphaël Hertzog hat in seinem englischen Blog daraus eine kleine Serie gemacht, die ich so interessant fand, dass ich sie in Deutsch hier festhalten wollte.
In diesem Fall geht es um automatisch installierte Pakete und wie man sie wieder loswerden kann.
Jeder kennt das sicherlich bei Debian und Ubuntu, wenn man apt-get oder aptitude benutzt und folgende Ausgabe im Terminal zu sehen ist.

apt-get install claws-mail
Paketlisten werden gelesen... Fertig
Abhängigkeitsbaum wird aufgebaut
Statusinformationen werden eingelesen... Fertig
Die folgenden zusätzlichen Pakete werden installiert:
claws-mail-i18n libcompfaceg1 libetpan15 libpisock9
Vorgeschlagene Pakete:
claws-mail-doc gedit kwrite mousepad nedit claws-mail-tools jpilot pilot-link kpilot gnome-pilot evolution sylpheed
Die folgenden NEUEN Pakete werden installiert:
claws-mail claws-mail-i18n libcompfaceg1 libetpan15 libpisock9
0 aktualisiert, 5 neu installiert, 0 zu entfernen und 2 nicht aktualisiert.
Es müssen 4.356 kB an Archiven heruntergeladen werden.
Nach dieser Operation werden 11,3 MB Plattenplatz zusätzlich benutzt.
Möchten Sie fortfahren [J/n]?

Die "folgenden zusätzlichen Pakete" sind die automatisch installierten Pakete, die man zwar nicht explizit installieren wollte, die aber notwendig sind, damit das ursprüngliche Programm, claws-mail, reibungslos funktioniert.
Aptitude stellt für diese Pakete ein Extrafeld zur Verfügung.

Mit aptitude show claws-mail-i18n findet man z.B.

Automatically installed: yes

Je nachdem welches Frontend man bevorzugt, kann man entweder mit

apt-mark showauto

oder

aptitude search ~M


automatisch installierte Pakete finden. Während aptitude diese zusätzlich installierten Pakete mit aptitude remove claws-mail oder aptitude purge claws-mail entfernen würde, benachrichtigt apt-get einem nur über diese Möglichkeit. Tatsächlich muss man noch apt-get autoremove ausführen, damit apt-get diese automatisch installierten Pakete wieder entfernt.
Der Trick mit diesem Feature ist der folgende. Man kann zum einen Software als automatisch installiert markieren.

apt-mark markauto cmus

oder

aptitude markauto cmus

Damit erkennt der Paketmanager, dass diese Pakete nicht mehr gebraucht werden, sofern kein weiteres Paket mehr davon abhängt. Auf meinem System würde der letzte Befehl z.B. sofort zur Deinstallation von cmus führen.
Häufiger hingegen kommt es vor, dass plötzlich ganze Desktopumgebungen deinstalliert werden sollen, wenn man nur daran interessiert ist Teile der Gnome-Desktopumgebung zu entfernen.
Der "Trick" besteht auch hier darin, dem Paketmanager zu signalisieren, was man behalten möchte und was nicht. Stellt man fest, dass Metapakete oder wichtige Software wie gnome-session oder gnome-shell entfernt werden sollen, kann man mit

apt-mark unmarkauto gnome-session gnome-shell oder
aptitude unmarkauto gnome-session gnome-shell


dem System deutlich machen, dass man diese Pakete behalten möchte. Mit dieser Methode lässt sich gezielt automatisch installierte Software entfernen, ohne dass die ganze Distribution dadurch in Mitleidenschaft gezogen wird.
Zusammen mit den weiteren Hilfsmittel ist das eine gute Ausgangsbasis sein Debian minimal und sauber zu halten.

Logcheck: Überwachung von Logdateien mit Regulären Ausdrücken

Letzte Woche hatte ich Logwatch vorgestellt, dass bei mir auf dem Server seinen Dienst als Beobachter von Logdateien verrichtet. Wie so oft bei Linux gibt es natürlich eine Reihe von Alternativen. Darunter habe ich mir später Logcheck genauer angeschaut.
Der größte Unterschied nach der Installation ist das Benachrichtigungsintervall, das standardmäßig eine Stunde beträgt. Die ganze Konfiguration befindet sich in /etc/logcheck. In der Datei logcheck.conf wird das allgemeine Verhalten festgelegt. In logcheck.logfiles definiert man hingegen die zu überwachenden Logdateien. Für einen Server sollte

REPORTLEVEL="server"

eingestellt sein. Für einen reinen Desktop-PC genügt hingegen "workstation" und für sicherheitskritische Systeme kann es auch "paranoid" sein.
Logcheck funktioniert nach einem simplen Prinzip. Je nach REPORTLEVEL werden die Regeln in /etc/logcheck/cracking.d/ und /etc/logcheck/violations.d/ abgearbeitet und auf die vorher definierten Logdateien angewendet. Treffen die dort formulierten Bedingungen zu wird entweder ein ATTACK- oder SECURITY-Alarm ausgelöst. In den entsprechenden Ignore-Ordnern für Paranoid, Server und Workstation befinden sich hingegen Regeln als Reguläre Ausdrücke, die "normale" Einträge herausfiltern.
Alles was weder unter ATTACK noch SECURITY fällt ist dann ein sogenanntes SYSTEM-Ereignis, was z.B. auch der Download einer Datei vom FTP-Server sein kann.
Voreingestellt werden /var/log/syslog und /var/log/auth.log überwacht. Um z.B. die Logdateien des vsftpd-Servers zu überprüfen, trägt man in /etc/logcheck/logcheck.logfiles den Pfad zur Logdatei

/var/log/vsftpd.log

ein. Schon nach kurzer Zeit erhält man Meldungen wie

Sun May 27 22:06:24 2012 [pid 2] CONNECT: Client "123.123.123.123"

Danach findet jedoch kein Download statt, dennoch wird eine E-Mail-Benachrichtigung verschickt. Diese Art von Meldungen lassen sich in /etc/logcheck/ignore.d.server/vsftpd als Regulärer Ausdruck definieren. Daraufhin wird das Vorkommnis während der stündlichen Auswertung ignoriert.
Regel

^w{3} w{3} [ :[:digit:]]{11} [ :0-9]{4} [pid [0-9]+] CONNECT: Client "[0-9]+.[0-9]+.[0-9]+.[0-9]+"$

Dieser Reguläre Ausdruck nach dem POSIX-Standard passt genau auf die Zeile der Logdatei. Da ich ihn selbst geschrieben habe, verstehe ich zwar was damit gemeint ist. Wenn man hingegen vor fremden Regulären Ausdrücken steht, muss man sich oft erst einmal in die Materie einarbeiten und einige Knoten lösen.
Mir hat definitiv die schon vorhandene Konfiguration bei Logcheck geholfen. Weiterhin kann ich auch den englischen Wikipedia-Artikel zum Thema Regular Expressions empfehlen. Ferner gibt es unter dem Suchbegriff "regexp tester" zahllose Seiten, die in Javascript, Flash oder Java eine Plattform anbieten um eigene Ausdrücke zu testen. Keine davon hat mich aber auf den ersten Blick vollkommen begeistert.
Ich denke am einfachsten ist es, man schreibt den Regulären Ausdruck in eine Datei und testet ihn mit egrep -f, z.B.

egrep -f meine_regeln /var/log/vsftpd.log


Wird im Terminal eine Ausgabe angezeigt stimmt alles. Oft fange ich dabei erst einmal grob an, indem ich Sonderzeichen wie Punkte oder eckige Klammern escape und danach dann Wort für Wort und Zahl für Zahl alles ersetze. Ziel ist es die unerwünschten Zeilen so genau wie möglich mit Regulären Ausdrücken einzugrenzen.
Logcheck erfordert etwas Einarbeitungszeit, damit es sehr gut funktioniert. Gibt es nichts zu melden oder funktionieren die Ignore-Regeln bleibt Logcheck leise und meldet sich nur noch, wenn es wirklich was zu sagen gibt.