ubuntuusers – gambaru.de

Januar 3, 2013

Linux iuvat – Spieleserver mit Debian: 2012 in schicken Graphen

Ich denke, es hat sich ausgezahlt Munin und Qstat vergangenes Jahr zu installieren. Hier sind noch ein paar Charts, die die Auslastung der einzelnen Spieleserver über das Jahr repräsentieren. Die Graphen lesen sich so:
Die Y-Achse visualisiert die Anzahl der Spieler bzw. Bots, die zu einem Zeitpunkt X auf dem Server spielen. Die Werte wurden alle 5 Minuten mit QStat ermittelt und dann mit Hilfe von Munin in einen Graph umgewandelt. Es kann durchaus vorgekommen sein, dass 10 Spieler auf dem Server gespielt haben, jedoch diesen in dem Moment verlassen haben als der Wert mit Munin und QStat registriert wurde. Auf das Jahr verteilt sollte diese Unschärfe jedoch kleiner ausgefallen sein.

OpenArena

Mein Favorit. Die Serverkonfiguration machte hier am meisten Spaß und der Server wird rege genutzt. Standardmäßig wird Deathmatch, also "Jeder-gegen-Jeden", angeboten. Der Mapcycle besteht aus 60 Karten, wobei die populärsten bzw. am besten spielbaren Karten öfter aufgerufen und immer wieder einige größere oder unbekanntere Maps eingestreut werden. Jeden Mittwoch ändert sich automatisch die Konfiguration, InstantGib ist an der Reihe. An jedem ersten Sonntag in Monat gibt es dann noch einen besonderen Spielmodus, der sich "Ketchup Vampire" nennt. Der merkwürdige Name stammt von der Tatsache her, dass man in diesem Modus pro zugefügtem Schadenspunkt 0.33333 Lebenspunkte erhält ("vampire mode") und es für bessere Spieler umso schwieriger wird Frags zu erzielen, je größer die Differenz in Frags zu den nachfolgenden Spielern ist ("catch up").

Der Jahreschart zeigt ziemlich eindrucksvoll, dass der Server täglich besucht wird und im Vergleich zu den anderen Spieleservern auch die höchste Auslastung hat. Auffallend sind die Spitzen bei kontinuierlich 3-4 zu jeder Tageszeit, was für OpenArena ziemlich viel ist. Bis auf eine Ausnahme war dieser Ausschlag jeweils auf das Abschalten eines "konkurrierenden" Deathmatch-Servers zurückzuführen, der praktisch alle DM-Spieler in Europa bündelt. Der Wert stellt also so etwas wie die theoretisch mögliche Auslastung dar. Als ich von 0.8.5 auf 0.8.8 im Mai wechselte, brach die Spielerzahl ein wenig ein, besserte sich dann aber wieder, nachdem ich den FTP-Server eingerichtet hatte, von wo aus man automatisch die neuen Daten beziehen kann. Im Sommer keine Überraschungen: Weniger Spieler, dafür mehr Sonne und Luft. Gut so.
Das Phänomen kennt jeder Onlinespieler. Es gibt einen Server A auf dem 5 Spieler spielen und einen Server B mit 0 Spielern. Welchen Server wird Spieler A beitreten? Natürlich joint jeder A. So bleibt der eine Server immer recht gut besucht und wenn sich dort einige Stammspieler regelmäßig einfinden, bleibt das auch so. Jeder neue Server muss hingegen erst um diese Stammspieler durch gute Pings und ein abwechslungsreiches Programm werben und ich denke, dies hat bei meinem Server von Anfang an ganz gut geklappt und an manchen Tagen kann man stundenlang ohne Unterbrechung menschliche Spieler "fraggen".

Red Eclipse

Red Eclipse ist ein ziemlich neues Spiel für Debian und Ubuntu. Genauso wie Sauerbraten basiert es auf der Cube-Engine und ist dementsprechend äußerst anspruchslos an die Hardware. Jedoch unterscheiden sich Gameplay und Design deutlich vom Ogre-Spiel. Das Ganze ist eher futuristisch gehalten. Munition oder das Sammeln von Items steht gar nicht im Vordergrund. Hier geht es mehr um Bewegung. Faszinierend sind die zahlreichen Gamemodi und Einstellungsmöglichkeiten.
Die Community ist noch recht klein, wächst aber stetig. Wenn am frühen Morgen nur wenige Spieler online sein sollten, kann man immer noch auf ein Spiel gegen Bots zurückgreifen.

Als ich es zu gut meinte und selbst Servervariablen für alle freigegeben hatte, dauerte es keine zwei Tage bis mir Monit mitteilte, dass die Prozessorauslastung konstant bei über 75% lag. Als ich dem Server beitrat, war auch sofort klar warum. Die Werte waren so unnatürlich hoch, dass einzelne Gewehrsalven praktisch die Stärke von Erdbeben hatten und das ganze Spiel nur noch unnatürlich hin- und hervibrierte. Reich ihnen den kleinen Finger und sie reißen dir den Arm aus.
Nun läuft der Server ohne diese Freiheiten, aber immer noch mit der Möglichkeit über 100 Karten auszuwählen, darunter auch die von Sauerbraten. Die Anzahl der Spieler zog kurioserweise erst mit der Veröffentlichung der neuen Version 1.3.1 an, weil ich nicht wechselte bzw. nicht wechseln konnte. Debian ist im Freeze, weswegen Version 1.2 immer noch spielbestimmend ist. Da mein Server der einzige in Europa ist, der noch 1.2 benutzt bündelte das ein paar Spieler und ich hatte ja auch von der OpenArena-Geschichte gelernt. 🙂
Ich werde bis mindestens April daran festhalten, dann gibt es wohl auch einen Backport für Red Eclipse, zumindest erwähnte das der Maintainer mir gegenüber im IRC.

Sauerbraten

Das Spiel erinnert mich immer an alte LAN-Zeiten als man zum Krafttraining nicht ins Fitnessstudio gehen musste, sondern seinen Vorbis-Big-Tower und den Oschi von Röhrenmonitor durch die Gegend schleppen musste. Das war die Zeit als man auch noch solche BNC-Stecker zum Zocken brauchte, aaach ja.
Um wieder zum Spiel zurückzukommen, Sauerbraten macht eine Menge Laune. Das Spiel war sehr einfach als Server aufzusetzen und ist genauso einfach zu bedienen. Hier gab es schon eine umfangreichere Anleitung. Der Server ist absolut anspruchslos. Selbst bei einem vollen Server mit 16 aktiven Spielern, geht die CPU-Anzeige in htop nicht über 1% auf dem kleinsten vServer. Der Speicherverbrauch liegt ebenfalls bei unter 1% bei 256 MB RAM absolut. Einfach WOW.
Da der Client die ganze Arbeit übernimmt und der Ping nicht so die Rolle spielt, ermöglicht das auch Spielern aus Amerika problemlos in Deutschland zu zocken. Man sieht deswegen auch des öfteren in tiefster Nacht noch Ausschläge auf dem Graphen. Die Auslastung des Servers ist schwer vorherzusagen, da er absolut offen ist und vom "Master" auch wieder geschlossen werden kann. So kann es sein, dass 2 Spieler über Stunden den Server für sich beanspruchen und zu einer anderen Zeit sich ein Dutzend Leute zum Coop-Edit einfinden. Genauso war er aber gedacht. Der Aufwand den öffentlichen Server zu administrieren geht gegen Null.

Teeworlds

In Teeworlds steckt eine Menge Liebe. Das kann man nicht nur an den witzigen Tees erkennen, sondern auch an dem actionreichen Gameplay, dass den Spaß des klassischen 3D-Egoshooters in die zweidimensionale Welt transportiert hat. Die Serverkonfiguration ist ähnlich einfach wie bei Sauerbraten, der Server ein Vorbild an Effizienz.
Um den Spielern ähnliche Freiheiten wie bei Sauerbraten zu bieten, habe ich Karten und Spielmodi zur Abstimmung freigegeben und eigene Optionen in die Config eingebaut. Jeder hat also die Wahl Deathmatch, Capture the Flag oder Team Deathmatch zu spielen und zwischen allen offiziellen Karten zu wählen. Passend zum Spielmodus werden dann neue Variablen gesetzt.
Leider zeigte diese Wahl bis vor kurzem kaum Wirkung, der Server blieb weitestgehend leer. Das liegt vor allem daran, dass es mittlerweile an die 1000 Teeworld-Server gibt und meiner da eben nur einer unter vielen ist. Vergangenen Monat entdeckte dann scheinbar eine anonyme Gruppe von Leuten den Server und lastete diesen ordentlich aus. Deswegen hält Teeworlds auch den Tagesrekord. 🙂

Ich denke Teeworlds macht auf jeder LAN-Party eine Menge Spaß und ist von mir eine echte Empfehlung, wenn man Lust auf einen Ego-Shooter der anderen Art hat. Aber Vorsicht: Wenn du Probleme mit dem "Hooken" hast, wirst du auch schon mal als Noob beschimpft. 😯

Dezember 16, 2012

ZNC: Ein funktionsreicher IRC-Bouncer – mit Anleitung

Was macht man, wenn man nicht nur eine Mailingliste verfolgen, sondern auch einem IRC-Channel beitreten soll, um dort über die aktuellsten Geschehnisse des Debian-Games-Teams auf dem Laufenden zu bleiben? Man greift zu ZNC, einem IRC-Proxy oder auch Bouncer genannt. Das tolle daran ist, dass die Verbindung zum Channel nie unterbrochen wird und man von überall, unterwegs und mit verschiedenen IRC-Klienten gleichzeitig sich zum Bouncer verbinden kann, der unter anderem die Fähigkeit besitzt den eigenen Channel-Nick zu reservieren und die Konversationen der letzten Stunden wiederzugeben, so dass man nichts verpasst.
In diesem Beitrag geht es um die Inbetriebnahme von ZNC auf einem vServer (natürlich funktioniert auch jeder Heimserver) für ein Netzwerk (irc.oftc.net) und mehrere Channel.

Installation

Wie immer einfach.
aptitude install znc

Konfiguration

Die Konfiguration ist genauso geradlinig. Immer wenn es in dem animierten GIF etwas schneller geht, müsst ihr nur die Standardeinstellung mit ENTER bestätigen.

Der Port auf dem ZNC lauschen soll lässt sich beliebig festlegen. Sollte der IRC-Server, wie dies bei irc.debian.org der Fall ist, SSL unterstützen, muss ein Pluszeichen vor den Port des IRC-Servers gestellt werden. Ob es IPv4 oder doch schon IPv6 sein soll, Benutzername und Passwort, ist natürlich individuell verschieden.
Wer sich nicht sofort für das Aktivieren von zusätzlichen Modulen entscheiden möchte, kann das später immer noch nachholen. Dazu müsst ihr lediglich

/msg *status help

in eurem favorisierten IRC-Client eingeben, sobald ihr euch mit ZNC verbunden habt. Mit Befehlen wie

/msg *status ListAvailMods
/msg *status LoadMod Name-des-Moduls

erhaltet ihr Hilfe und könnt euren bevorzugten IRC-Gehilfen nachladen. Für mich war z.B. die log-Funktion wichtig, damit ich Nachrichten später noch lesen konnte. Für ZNC gibt es selbstverständlich auch ein Wiki, wo sich viele Hinweise und Antworten finden lassen und auch die obligatorische FAQ für ZNC.

Beispielkonfiguration mit Irssi

Wenn ZNC erst einmal auf dem Heim- oder vServer läuft, muss nur noch der favorisierte IRC-Klient so eingerichtet werden, dass dieser sich nun zuerst mit ZNC verbindet.
Für Irssi genügt z.B. folgender Eintrag in $HOME/.irssi/config:

servers = (
{
    address = "123.123.123.123";
    chatnet = "OFTC";
    port = "55555";
    use_ssl = "yes";
    ssl_verify = "no";
    autoconnect = "yes";
    password = "Apo:meingeheimesPasswort";
}

Die Adresse des ZNC-Servers, Port, Netzwerk, Benutzername und Passwort, das wars. Nach dem Start verbindet sich dann Irssi sofort verschlüsselt via SSL mit dem Bouncer, der wiederum eine verschlüsselte Verbindung zum IRC-Server irc.debian.org aufgebaut hat.
Wer sich E-Mail lesen gar nicht abgewöhnen kann, darf auch einen Cronjob einrichten und danach Logrotate anweisen einem die tägliche IRC-Logdatei per Mail zukommen zu lassen. 😉

Dezember 9, 2012September 26, 2019

Freie Klänge und Audacity: Erschaffe deine eigenen Spielesounds

Vor ein paar Wochen war es endlich soweit und ich betätigte mich zum ersten Mal als Spieleentwickler oder besser Ersetzer-von-unfreien-Spieleinhalten. Mein Ansporn war ein rundenbasiertes Strategiespiel namens LGeneral, dessen Vorbild die "ältere" Generation vielleicht noch als Panzer General kennt. Das Spiel hat mich dazu gebracht diverse Leute zu kontaktieren, eine Reise in die Vergangenheit anzutreten und LGeneral für Debian schließlich wiederzubeleben.
Das Spiel ist sicher einen Extraartikel wert, deswegen wollte ich heute nur zeigen wie man ein häufig auftretendes Problem bei freien Spielen lösen kann. Das Ersetzen von unfreien Inhalten durch eben freie.
LGenerals Spielengine ist in C programmiert und unter der GPL-2 lizenziert, der Spielinhalt selbst wird jedoch aus dem kommerziellen Spiel "Panzer General" in das native Format von LGeneral mittels eines Konverters umgewandelt, so dass die alten Kampagnen und Szenarios spielbar bleiben. Die Community geht davon aus, dass der Publisher von Panzer General mittlerweile das Interesse an dem Spiel verloren hat und es nun als "Abandonware" verfügbar ist, also ungefähr so wie vom Laster gefallen.
Wie ihr euch sicher denken könnt, sieht das Debian etwas anders, weswegen das Spiel bis heute nur in der contrib-Sektion verfügbar ist und der Spielinhalt es nicht einmal nach non-free schafft. Als ich mich dem Spiel angenommen habe, schwor ich mir zumindest die Spielengine zukunftssicher zu machen und die dort verwendeten Sounds und Bilder aus Panzer General zu ersetzen und zu verändern.
Eine mögliche Quelle für freie Klänge und Geräusche findet sich z.B. bei freesound.org.

Ich musste eine Reihe von Geräuschen ersetzen, die alle selten länger als 2-3 Sekunden andauerten. Darunter waren die Propeller- und Turbinengeräusche eines Flugzeugs, ein fahrendes Auto und das typische Heranschwappen von Wellen.
Wenn man bei freesound.org z.B. den Suchbegriff "sea" eingibt, findet man als ersten Treffer eine hervorragende und kristallklare Aufnahme von Wellengeräuschen, oceanwavecrushing.wav, die an einem dänischen Fjord aufgenommen worden ist. Es brach mir fast das Herz diese Aufnahme zu zerstückeln und in die gleiche Soundqualität wie bei LGeneral zu überführen, aber das Ergebnis kam dem Original sehr nahe und war dennoch eigenständig und verschieden.

Audacity

Für eine solche Aufgabe bietet sich das freie Audiobearbeitungsprogramm Audacity an. Damit lassen sich nicht nur Teile einer Musikaufnahme "ausschneiden", sondern auch diverse Effekte auf diese Probe anwenden und schließlich in ein eigenständiges Stück abspeichern. Nachdem man die verlustfreie .wav-Datei mit Audacity geöffnet hat, kann man mit Hilfe der gedrückten linken Maustaste und der Entf-Taste das passende Stück aus dem Sample ausschneiden und dann weiterbearbeiten. Mit Strg+1 oder mit der Option "Einzoomen" unter Ansicht könnt ihr den Ausschnitt auf die Millisekunde genau bearbeiten.

Hat man die richtige Stelle gefunden, kann man nun diverse Effekte darauf anwenden. Damit der Klang nicht zu abrupt beginnt und endet gibt es z.B. die Effekte Ein- und Ausblenden. Dreht noch etwas an der Tonhöhe und dem Tempo und schon habt ihr den Sound für ein Spiel. Der ganze Rest ist Ausprobieren und Experimentieren. Die fertige Datei lässt sich in alle populären Musikformate exportieren, darunter *.mp3, *.ogg und *.flac.

Das fertige Stück klang dann so:
sea.wav

Weitere Beispiele

air.wav

Original: http://www.freesound.org/people/daveincamas/sounds/43807/
air2.wav

Original: http://www.freesound.org/people/digifishmusic/sounds/47347/
battle.wav

Original: http://www.freesound.org/people/Omar%20Alvarado/sounds/93741/

Dezember 8, 2012

Richard Stallman wettert gegen Ubuntu Spyware

Es gibt einige universelle Konstanten im Universum: Lichtgeschwindigkeit, Plancksches Wirkungsquantum, die 42 und natürlich Richard Stallman. Sucht man nach einer klar definierten und polarisierenden Meinung zum Thema Freie Software, findet man sie mit traumwandlerischer Sicherheit bei ihm. Genau das Richtige für einen kleinen Aufreißer bei Sonnenschein und Schnee am Wochenende.
Gestern veröffentlichte RMS, wie er von vielen liebevoll abgekürzt wird, in seinem Blog den Artikel Ubuntu Spyware: What to do?
Er stellt darin die These auf, dass Freie Software die Nutzer vor schädlicher, gar boshafter Software beschütze und Ubuntu dieses Paradigma mit der Einführung seiner Shopping-Funktionen bei Amazon nun grob verletzt habe, indem Benutzerdaten standardmäßig an die Server von Canonical, dem Unternehmen hinter Ubuntu, übermittelt werden.
Selbst wenn dieses Feature nach der Installation ausgeschaltet wäre, bestünde immer noch die Gefahr für die Benutzer, dass deren Daten jederzeit wieder transferiert werden können. Zwar könne jede Einzelne diese Funktion abschalten, jedoch würde das bedeuten, dass die Abgrenzung zwischen proprietärer Software und freier Software verwischen würde und das Argument "Freie Software spioniert nicht" nicht mehr gelte. Wer schon ein paar andere Artikel von Richard Stallman kennt erahnt, was sein Fazit war.
Hört auf Ubuntu zu benutzen und es anderen weiterzuempfehlen!
Wenn man seinen Artikel zu Amazon gelesen hat und weiß, dass selbst Debian auf der Liste der Distributionen steht, die von der Free Software Foundation nicht empfohlen werden, kommt diese Aussage nicht vollkommen überraschend.
Diese Schwarz-Weiß-Ansichten sind einfach formuliert und egal was man von ihnen hält, man weiß immer genau für was der Andere steht oder eben nicht. Ob die Welt aus zahlreichen Grautönen besteht oder gar bunt ist, interessiert da nicht. Die Frage, die ich mir gestellt habe war, welche Möglichkeiten hat eigentlich ein Unternehmen, dass mit Freier Software arbeitet und handelt, Gewinne zu machen? Wie kann ich Menschen für ein Produkt begeistern und maßgeschneiderte Lösungen anbieten, ohne dass ich dafür etwas über sie wissen muss?
Das scheint ein ganz schön vertracktes Problem zu sein, nichts speichern, nichts wissen, aber dennoch Informationen in Echtzeit via Internet anbieten. Klar, Canonical könnte auch den Versandkatalog von Amazon auf DVD an alle seine Nutzer verschicken, die ihn dann lokal installieren. Möglichkeiten neue Arbeitsplätze zu schaffen, gibt es viele.
Vielleicht ist Stallmans Vorschlag, lokale und entfernte Suche strikt zu trennen und nur mit expliziter Einwilligung der Nutzer zu handeln, gar nicht so verkehrt und die einzige Möglichkeit alle datenschutzrechtlichen Bedenken auszuräumen. Doch ist es realistisch anzunehmen, dass jeder Nutzer zwei getrennte Schnittstellen benutzen würde, wenn es sie denn gäbe? Wer denkt bei der ganzen Diskussion eigentlich an die kleinen Buchläden und Einzelhändler, die von so einer Funktion so oder so nicht profitieren?
Im Moment weiß ich nur, dass ich kein Patentrezept habe. Mehr Transparenz bei all diesen "Shopping-Features" wäre sicherlich nicht verkehrt und dann bitte schön auch mit größerer Auswahl. Aufrufe zum Boykott halte ich jedoch für falsch, solange es die Möglichkeit gibt die betreffende Funktion einfach bei Nichtgefallen zu deaktivieren.
sudo apt-get remove unity-lens-shopping

November 14, 2012

Hilfe zur Selbsthilfe – Erkenne die Probleme deines Lieblingspakets

Genug mit dem Blogurlaub. Bevor ich das Schreiben ganz verlerne, mache ich meine Antwort zu einer E-Mail kurzerhand öffentlich und versuche ein paar nützliche Links und Hilfsmittel anzuschneiden, mit denen ihr erkennen könnt, ob etwas mit eurem Lieblingspaket nicht stimmt und wie ihr vielleicht sogar dabei helfen könnt, damit sich die Lage wieder etwas aufhellt.
Vor kurzem erhielt ich per Mail die Anfrage, wie ich es mit Xarchiver halten würde. Vor einigen Jahren, einige erinnern sich sicherlich noch, war das immerhin das Standardprogramm von Xfce, wenn es um das Archivieren bzw. Komprimieren von Dateien und Verzeichnissen ging, auch wenn es eine Zeitlang mit Squeeze konkurrierte.
Beide Programme sind ein wenig in der Versenkung verschwunden, weil sie schon seit längerem von Xfce nicht mehr beworben werden. Xarchiver steckt seit 2009 in einer Art Winterschlaf und solange niemand die Entwicklung erneut aufnimmt, wird dies auch weiterhin so bleiben. Jedoch ist es im Grunde genommen gar nicht so schlecht um dieses Programm bestellt und es erfreut sich nach wie vor einer großen Anzahl von Nutzern.

Die Diagnose

Wie bei den meisten Programmen gibt es auch bei Xarchiver ein paar Bugs. Das stellt sich z.B. so dar, dass man mitunter eine böse Überraschung erlebt, wenn man versucht 7z-Archive zu öffnen und das Programm dabei abstürzt. Die Bugs #665642 und #551468 erzählen davon und auch auf Launchpad sammeln sich die Fehlerberichte.
In Ubuntu liefert die Paketübersicht den ersten Hinweis darauf, wie es um das Paket bestellt ist. Neben dem Link zu den Fehlerberichten ist vor allem interessant zu wissen, dass Xarchiver von den Ubuntu MOTU (Master of the Universe ;)) Entwicklern betreut wird, jedoch wie die meisten Ubuntu-Pakete ursprünglich vom Debian-Projekt stammt und dort einen Maintainer besitzt, der sich in der Regel auch darum kümmert.
Für Debian gibt es eine ganz ähnliche Paketübersicht wie bei Ubuntu, jedoch mit einem besonderen Bonus, Debians Package Tracking System (PTS). In dieser Übersicht erkennt man oft schon mit einem Blick wie es um das Paket bestellt ist.
Bei Xarchiver fällt auf, dass der letzte Upload vor mehr als drei Jahren stattfand, was man unter der Rubrik News schnell erkennen kann. Auf der linken Seite befinden sich die allgemeinen Angaben zum Paket, den Versionen und wer der aktuelle Betreuer ist. Rechts wiederum ist die Kurzübersicht zu den Fehlern unterteilt nach Schweregrad. Viele nützliche Links befinden sich darunter. Insbesondere der Bericht von Lintian über festgestellte Paketfehler macht oft deutlich wie es um die inneren Werte des Pakets steht.
Als Indikator für die Popularität des Pakets dient hingegen der sogenannte Popcon-Wert. Debian bietet hier gegenüber der Ubuntu-Variante ein paar nette Graphen, die Aufschluss über die Benutzerentwicklung geben. Der Trend bei Xarchiver zeigt klar nach oben und mit mehr als 6000 installierten Anwendungen, das sind immerhin 5% aller eingereichten Berichte, ist Xarchiver für eine optionale Anwendung ziemlich begehrt.
Wäre das Paket "verwaist" oder würde der Betreuer nach einem Nachfolger suchen, gäbe es unter Todo einen weiteren Link, der auf den entsprechenden Fehlerbericht zeigen würde. Da dies nicht der Fall ist, kann man nur zum Schluss kommen, dass das Paket aktuell nicht betreut wird, jedoch auch kein Nachfolger gesucht wird, Fehler aufweist, von denen sich einige beseitigen lassen und das ganze Paket ziemlich populär ist. Auf der anderen Seite stagniert die Entwicklung seit mehr als drei Jahren, weswegen der Paketbetreuer auf jeden Fall auf Mithilfe angewiesen ist, wenn er nicht gleich selbst der neue Entwickler von Xarchiver werden möchte.
In so einem Fall würde ich also den Patch für den 7z-Bug, den es tatsächlich schon gibt, an den Fehlerbericht anhängen und freundlich anfragen, ob das Paket weiterhin noch betreut wird. In der Regel sollte man danach:

Zwei Wochen warten, dann noch einmal nachfragen.
Nach einem Monat einen Blick auf diese Seite werfen und den Links zur Debian-Mailingliste für Qualitätssicherung und dem hauseigenen IRC-Channel folgen und das Problem dort ansprechen.

In der Regel wird das Paket spätestens dann für neue interessierte Betreuer freigegeben. Der Vorgang könnte meiner Meinung nach etwas einfacher sein und zur Zeit gibt es tatsächlich eine aktive Diskussion darüber diesen Prozess durch einen Fehlerbericht einzuleiten. Dieser kann dann von jedem Nutzer eingereicht werden, jedoch nur von Debianentwicklern bestätigt werden, wonach das Paket für einen Nachfolger freigegeben wird. Das Ganze ist noch nicht spruchreif, wird aber mit etwas Glück in den nächsten Monaten vorgestellt werden.

Fazit

Oft spielen wie immer mehrere Faktoren zusammen. Die Entwicklung des Programms ist eingeschlafen, der Paketbetreuer scheint in Urlaub zu sein und am eigenen PC fragt man sich nur, woran hängt es eigentlich. Das Paketverfolgungssystem von Debian bietet die wichtigsten Infos auf einen Blick und danach kann man dann entscheiden, ob man Zeit in die Fehlerbeseitigung investieren möchte oder doch lieber zu einer Alternative greift.

Oktober 16, 2012September 26, 2019

Du willst ein Spiel in Debian und Ubuntu sehen? So gehts!

Mich erreichte vor drei Wochen eine nette E-Mail und schnell kamen wir auf das Thema Freie Software und Spiele bei Debian zu sprechen. Unter anderem erhielt ich auch ein paar Vorschläge, welche Spiele es in die nächste Veröffentlichung von Debian schaffen sollten, was mich zu der Idee brachte diesen Artikel zu schreiben.

Du willst ein Spiel in Debian und Ubuntu sehen? So gehts!

Gehe auf die Suche. Es gibt tatsächlich viele Spiele, die als Freie Software entwickelt werden, aber von denen noch kaum jemand gehört hat. Berusky2 in der Linuxversion gibt es zwar schon mehr als ein Jahr, von einem Paket in Ubuntu oder Debian fehlt jedoch noch jede Spur. FreeOrion ist ein rundenbasiertes, intergalaktisches Weltraumeroberungsspiel in der Tradition der Master-of-Orion-Serie. Lips of Suna ist ein ironisch gemeintes Action-Rollenspiel. Leider existiert für all diese Spiele noch kein Debianpaket. Weitere Ideen zu Linuxspielen findest du z.B. bei holarse-linuxgaming.de, der Linux Game Database, Penguspy, Linuxgames.com und bei vielen weiteren Links.
Mache sie bekannt. Es nützt nichts, wenn du die Einzige bist, die all diese Spiele kennt. Mache sie bekannt! Das Games Team von Debian pflegt ein paar Seiten im Debian-Wiki. Unter anderem sind das Games/Suggested und Games/Unsuitable. Erstellt euch einen Account für das Wiki und tragt eure Ideen unter "Suggested" ein. Haltet euch an die alphabetische Sortierung und beschreibt, um was es bei dem Spiel geht, unter welcher Lizenz man es verbreiten darf, in welcher Programmiersprache es geschrieben wurde und was euch ansonsten noch für Besonderheiten aufgefallen sind.
Erstellt einen RFP- oder ITP-Fehlerbericht. RFP steht für request for package und ITP für intent to package. Falls ihr das Spiel selbst nach Debian bringen wollt, ist ITP natürlich die erste Wahl, in den meisten Fällen genügt es jedoch schon Aufmerksamkeit zu erzeugen, indem ihr einen RFP-Fehlerbericht verfasst.
Am einfachsten benutzt ihr reportbug.
reportbug wnpp
Mit diesem Befehl erstellt ihr einen Fehlerbericht gegen das sogenannte Pseudo-Paket "wnpp", Work-Needing-and-Prospective-Packages. Folgt ihr den Menüoptionen zum Thema RFP, könnt ihr ein Paket vorschlagen, welches ihr für geeignet haltet, um irgendwann in Debian oder Ubuntu zu erscheinen.
Nutzt das richtige Forum. Spieleentwicklung geschieht häufig auf bestimmten Mailinglisten, im IRC, aber auch Foren und jede andere Kommunikationsform sind denkbar. Debian hat eine eigene Mailingliste für die Entwicklung von Spielen, bei Ubuntu gibt es ebenfalls ein eigenes GamingTeam! Wenn ihr eine gute Idee habt, sprecht sie an, stellt sie vor, verwirklicht sie! Umso mehr Informationen ihr zur Verfügung stellt, desto besser können sich Interessierte eine Meinung darüber bilden, ob sie das Spiel als Paket einbringen wollen. Lasst euch jedoch auch von Rückschlägen nicht entmutigen.
Tu es selbst. Ihr habt euch die Mühe gemacht und alle Informationen zusammengetragen, sie öffentlich gemacht, aber so richtig will keiner anbeißen. Warum? Freie Software zu entwickeln ist für viele nur ein Nebenjob. Ihr erntet also nur Missmut und gar Unverständnis, wenn ihr erwartet, dass irgendjemand ein Spiel für euch paketieren soll. Macht es einfach selbst. Die Chancen steigen exponentiell, wenn ihr euch selbst als zukünftiger Paketverwalter anbietet.
Wenn gute Gründe gegen die Karriere als Paketverwalterin sprechen, macht euch den Spaß und tragt so viele Informationen zusammen wie nur möglich, haltet sie am besten auf einer eigenen Wiki-Seite fest und stellt sie vor. Die meiste Arbeit bei der Erstellung eines Pakets ist nicht selten nur die reine Technik, sondern oft das Sichten der Lizenzen. Stimmt es tatsächlich, wenn die Entwickler ein reines "Open-Source-Spiel" versprechen? Oft offenbart z.B.
grep -ri "All rights reserved" /Pfad-zum-Spiel
die ein oder andere Überraschung. Ihr helft der zukünftigen Aufnahme des Spiels in Debian und Ubuntu ungemein, wenn ihr solche "Show-stopper" frühzeitig erkennt und problematische Dateien und Code öffentlich dokumentiert.

Ich erwähnte es sicherlich schon an der ein oder anderen Stelle. Freie Software bietet einem alle Freiheiten, ist manchmal auch anstrengend, macht jedoch auch immer wieder Spaß.
Mach mit!

September 19, 2012

Wie man veröffentlichungskritische Bugs in Debian beseitigt

Es hält sich hartnäckig das Gerücht, dass es so etwas wie einen Konkurrenzkampf zwischen Debian und Ubuntu gebe. Tatsächlich ermutigt Ubuntu jedoch neue Software über Debian einzubringen. Im Umkehrschluss heißt das auch, dass jeder Beitrag zu Debian auch ein Beitrag zu Ubuntu ist.
In diesem Artikel geht es darum, dass auch ein kleiner Beitrag der gesamten Distribution weiterhelfen kann und dass das Beseitigen von Bugs, Modifizieren von Quelltext und die Neuerstellung des Pakets kein Hexenwerk sein muss. Besonders hilfreich ist das Beseitigen von sogenannten veröffentlichungskritischen Bugs, kurz RC-Bugs genannt.

Der grobe Ablauf

Finde einen RC-Bug, der dich interessiert.
Erstelle einen Patch für das Problem.
Schicke die Lösung an die Fehlerdatenbank von Debian.
Finde jemanden, der das Paket hochladen kann.

Finde einen RC-Bug

Erster Anlaufpunkt um einen RC-Bug zu finden ist die Ultimative Debian Datenbank (UDD). Hier lässt sich mit Hilfe verschiedener Filteroptionen die Suche exakt einschränken. Für den angehenden Kammerjäger ist diese Ansicht die zur Zeit beste. Wichtig ist, dass man alle schon mit Patch markierten Bugs und alle die neuer als 7 Tage sind ignorieren kann, da es bei ersteren eine Lösung gibt und bei letzteren dem Paketverwalter zumindest eine Chance eingeräumt werden sollte, das Problem selbst zu lösen.
Ein hilfreiches Werkzeug ist das Programm rc-alert, welches sich im Paket devscripts befindet und anzeigt, welche Software auf dem eigenen Rechner kritische Fehler aufweist. Ein Bonus von rc-alert ist, dass es nach Debtags filtern kann.
Mit dem nachfolgenden Befehl werden nur Debian Testing und Unstable nach Bugs durchsucht und geflickte und kurz vor dem Upload stehende Pakete ausgelassen. Zusätzlich wird nur jene Software aufgelistet, die in Perl oder Python implementiert worden ist.
rc-alert --include-dists TU --exclude-tags P+ --debtags implemented-in::perl,implemented-in::python
Multi Disk Error

Erstelle einen Patch

In vielen Fällen benötigt man nicht einmal Kenntnisse in einer Programmiersprache, sondern es genügt mit einem Texteditor umgehen zu können. In Bug #675220, #685959 und #685958 geht es schlicht darum, dass die E-Mail-Adresse des Paketverwalters ungültig ist, was gegen die Paketrichtlinien von Debian verstößt. Genauso gut kann aber auch eine Abhängigkeit falsch sein, wodurch das Paket sich nicht mehr kompilieren lässt. Diese Art von Fehler haben zwar ernste Auswirkungen, lassen sich jedoch in der Regel leicht beheben.
Zum Arbeiten mit Quellpaketen solltet ihr euch das Paket build-essential oder, wenn ihr Gefallen an der Sache gefunden habt, packaging-dev installieren.
apt-get source textedit.app
Mit Hilfe von dpkg-dev wird automatisch das Quellpaket entpackt. Nachdem man in das entpackte Quellverzeichniss gewechselt ist, sollte man zuerst einen neuen Changelog-Eintrag anlegen und deutlich machen, dass man hier eine Änderung als Nicht-Paketverwalterin vornimmt.
dch --nmu
Hierdurch wird automatisch das Changelog mit dem richtigen Eintrag geöffnet. Da der Patch für Unstable gedacht ist (der Regelfall) sollte das UNRELEASED dementsprechend in unstable umgeändert werden. Noch eine kurze Beschreibung, was ihr geändert habt und ein wichtiger Schritt für einen Non-Maintainer-Upload (NMU) ist getan.

textedit.app (4.0+20061029-3.4) unstable; urgency=low
  * Non-maintainer upload.
  * Fix invalid maintainer email address. (Closes: #675220)

Der wichtigste Anlaufpunkt im Quellpaket ist das Debian-Verzeichnis. In debian/control lassen sich z.B. allgemeine Paketinformationen wie die E-Mail-Adresse des Maintainers, Abhängigkeiten oder auch die empfohlenen Pakete in einer einfachen Textdatei definieren. Der "Fix" für die vorher erwähnten Bugs war es, das Maintainer-Feld zu aktualisieren. Gäbe es noch weitere Änderungen zu machen, könnte man mit
dch -a
weitere Einträge zum Changelog hinzufügen und die entsprechende Textdateien innerhalb des Debian-Verzeichnisses ändern.

Einen Patch mit Quilt erstellen

Müsst ihr hingegen den Quellcode selbst patchen und entspricht das Paket dem neuen Format 3.0 (quilt), könnt ihr quilt zum Patchen benutzen. Ob ein Paket dies unterstützt findet ihr heraus, indem ihr einen Blick in die Datei debian/source/format werft. Raphaël Hertzog hat die Bedienung von quilt in einem sehr guten Artikel auf den Punkt gebracht.
Der grobe Ablauf ist, dass ihr innerhalb des Debian-Verzeichnisses einen Ordner patches erstellen müsst, falls er nicht vorhanden ist und dann nach diesem Schema Patches erzeugt.

Erstellt einen neuen Patch
quilt new NamedesPatches
Verändert eine oder mehrere Dateien nach Belieben
quilt edit Datei
Wendet den Patch auf die Originaldatei an
quilt push
Erneuert den Patch, wenn er schon existiert.
quilt refresh

Einen Patch importieren

quilt import -P NamedesPatches /Pfad-zum-Patch.patch
quilt push
Häufig kommt es auch vor, dass schon jemand einen Patch hinterlassen hat und man ihn selbst ausprobieren oder testen möchte.

Schicke den Patch an die Fehlerdatenbank

Ist man der Meinung alles erledigt zu haben, sollte man zuerst alle Patches wieder zurücksetzen und das Quellpaket neu bauen.
Innerhalb des Quellverzeichnisses:
quilt pop -a
Dann

cd ..
dpkg-source -b textedit.app-4.0+20061029

Wenn ihr alles richtig gemacht habt, müsste nun eine weitere .dsc-Datei entstanden sein. Mit Hilfe von debdiff, dass sich auch im Paket devscripts befindet, lassen sich nun alle gemachten Unterschiede als Diff in eine neue Datei ausgeben, der Patch.
Allgemein:

debdiff altesPaket.dsc neuesPaket.dsc > Paket.debdiff

Im Speziellen:

debdiff textedit.app_4.0+20061029-3.3.dsc textedit.app_4.0+20061029-3.4.dsc > textedit.app.debdiff

Diese Datei muss jetzt nur noch per Mail an den Fehlerbericht geschickt werden und dieser mit dem passenden Tag patch markiert werden. Die Anleitung zur Bedienung der Fehlerdatenbank verrät alle Details. Zum Markieren als Patch genügt eine Mail an control@bugs.debian.org mit folgendem Inhalt, wobei nnnnnn für die Fehlernummer steht

tags nnnnnn patch
thanks

Einen Sponsor finden

Im Regelfall sollte das Anhängen des Patches an den Fehlerbericht mehr als ausreichend sein. Es besteht jedoch auch die Möglichkeit das Paket direkt zu mentors.debian.net hochzuladen, wo ihr Hilfe von Debianentwicklern erhalten könnt. Vorher müsst ihr noch wissen, wie man Debianpakete aus den Quellen baut, was auch zum Testen des Patches nützlich ist.
Habt ihr einen Account bei den Mentoren erstellt und seid ihr den Regeln für einen Non-Maintainer-Upload gefolgt, sind die Aussichten gut dort jemanden zu finden, der das gepatchte Paket in das Archiv hochladen kann. Vorausgesetzt natürlich, es löst tatsächlich das Problem.

Lesenswerte und inspirierende Links

September 11, 2012

Reprepro: Das eigene Paketarchiv für Debian und Ubuntu

Archivbild von Politikaner Wikipedia.org
Ich bin in den letzten Wochen zum ersten Mal mit der Situation konfrontiert worden, ein Repositorium für meine eigenen Debianpakete erstellen zu wollen. Davor beschränkten sich meine Experimente z.B. auf das Erstellen eines Backports für den DWM-Fenstermanager oder ein schnell gebasteltes Paket für den Cube-Server-Lister. Mit Reprepro existiert die Möglichkeit ein eigenes Paketarchiv für Deb-Pakete aufzusetzen und sie lokal mit Hilfe von Apt zu installieren oder Freunden, Testern, der Firma oder schlicht der ganzen Welt zur Verfügung zu stellen. Und das geht so.

Vorbedingungen

Ihr benötigt:

Einen gültigen GPG-Schlüssel
Eigene Deb-Pakete
Reprepro
Einen Web- oder FTP-Server

Ein gültiger GPG-Schlüssel

Führt das folgende Kommando aus:
gpg --gen-key
Die folgenden Dialoge sind selbsterklärend und die Voreinstellungen sinnvoll. Wählt den RSA-Schlüssel (1) und mindestens 2048bit Schlüssellänge.
Die ID eures öffentlichen Schlüssels (pub) erfahrt ihr mit
gpg --list-keys
In meinem Fall wäre das 475C34B9. Mit dem GPG-Schlüssel werden später die Deb-Pakete und das Reprepro-Archiv signiert, so dass ihr anhand der Signatur die Authentizität der heruntergeladenen Pakete erkennen könnt. Damit jemand anders dies auf dem eigenen Rechner überprüfen kann, muss der öffentliche Schlüssel in den Schlüsselring von Debian oder Ubuntu importiert werden.
gpg --output gambaru_archiv.asc --armor --export 475C34B9
Mit diesem Befehl wird der öffentliche Schlüssel im ASCII-Format in die Datei gambaru_archiv.asc exportiert.
wget https://www.gambaru.de/blog/wp-content/uploads/2012/09/gambaru_archiv.asc
Nach dem Herunterladen wird er mit
sudo apt-key add gambaru_archiv.asc
in den Schlüsselring importiert und
sudo apt-key list
verrät, ob er tatsächlich im Schlüsselring angekommen ist.

Eigene Deb-Pakete

Dieser Abschnitt könnte leicht Bücherwände füllen. Für den Anfang tun es aber auch "Wie man Debian-Pakete aus den Quellen baut" oder ihr schaut euch am besten Pbuilder an, womit sich Pakete in einer "Reinraumumgebung" für unterschiedliche Architekturen und sowohl für Ubuntu und Debian bauen lassen und das vollkommen unabhängig von eurer Ubuntuversion. Es lohnt sich das Pbuilder-Howto auf ubuntu.com zu studieren.
Die fertigen Pakete können auch nachträglich mit
debsign Paketname.changes
debsign Paketname.dsc
dpkg-sig --sign builder mediathekview_3.0.0-1_all.deb
signiert werden.

Reprepro

Reprepro ist ein Werkzeug, mit dem sich ein eigenes lokales Repository anlegen lässt, das dem offiziellen Debian Archive Kit in kaum einer Beziehung nachsteht. Es gibt weitere Alternativen, jedoch überzeugt mich Reprepro nicht nur durch seinen großen Funktionsumfang, sondern es kommt auch ohne Datenbankserver aus und lässt sich schnell einrichten. Das Handbuch von Reprepro sowie man reprepro helfen bei der Inbetriebnahme weiter.

Schritt 1:

Zuerst muss ein beliebiges Basisverzeichnis angelegt werden.
mkdir -p ~/reprepro/debian
Im Debian-Verzeichnis wird danach ein Unterordner namens conf angelegt und in diesem die Dateien distributions und options.

Schritt 2:

Der Inhalt von distributions.

Origin: gambaru.de
Codename: experimental
Architectures: i386 amd64 source
Components: main
Description: Private Debian-Pakete von http://gambaru.de
SignWith: yes
Origin: gambaru.de
Codename: wheezy
Architectures: i386 amd64 source
Components: main
Description: Private Debian-Pakete von http://gambaru.de
SignWith: yes

Diese Datei ist als einzige wirklich notwendig. In ihr werden die Distributionen definiert, für die die selbsterstellten Pakete gedacht sind. Ich habe sowohl eine für Experimental als auch Wheezy angelegt. Für Ubuntu lässt sich Wheezy auch durch Precise oder Quantal ersetzen oder ihr könnt euch einen komplett eigenen Codenamen ausdenken. Tatsächlich benötigt ihr nur die Felder Codename, Components und Architecture. Meine Pakete sind DFSG-frei und landen deswegen in Main. Ich stelle sie für die Architekturen i386 und amd64 und natürlich als Quellpakete zur Verfügung. Die Option SignWith: yes führt dazu, dass das gesamte Archiv mit dem zuerst gefundenen GPG-Schlüssel signiert wird. Anstelle von yes kann hier auch die Key-ID stehen.
Der Inhalt der Datei options.

verbose
ask-passphrase

Wenn diese Datei existiert wird jede Zeile als zusätzliches Argument beim Aufruf von Reprepro übergeben, wobei Parameter, die manuell per Kommandozeile übergeben werden, Vorrang genießen. Verbose sorgt für gesprächigere Statusmeldungen und bei ask-passphrase erwartet Reprepro die Eingabe des Passworts für den GPG-Schlüssel, um das Archiv zu signieren.
Nur der Vollständigkeit halber: Es existieren noch die Konfigurationsdateien updates, pulls und incoming, die man für weitergehende Studien im Hinterkopf behalten sollte, hier aber nicht gebraucht werden.

Beispiele

Fügt das Paket mediathekview_3.0.0-1_all.deb dem Archiv experimental hinzu, welches sich im Basisverzeichnis ~/reprepro/debian befindet.
reprepro -b ~/reprepro/debian includedeb experimental /var/cache/pbuilder/sid-amd64/result/mediathekview_3.0.0-1_all.deb
Fügt das Quellpaket mediathekview_3.0.0-1.dsc dem Archiv experimental hinzu, welches sich im Basisverzeichnis ~/reprepro/debian befindet.
reprepro -b ~/reprepro/debian includedsc experimental /var/cache/pbuilder/sid-amd64/result/mediathekview_3.0.0-1.dsc
Allgemein:
reprepro -b [Basisverzeichnis] includedeb|includedsc ARCHIV [Pfad zum Deb-Paket]
Die Eingabe des Basisverzeichnisses kann man weglassen, wenn man eine Umgebungsvariable exportiert oder die nachfolgende Zeile in seine .zshrc einträgt. Z.B.
export REPREPRO_BASE_DIR='/home/apo/reprepro/debian'
Danach lassen sich Pakete mit
reprepro includeb experimental Mein-Paket.deb
von überall hinzufügen.
Entfernen lassen sich Pakete aus dem Archiv mit:
reprepro remove experimental Mein-Paket
Und mehr müsst ihr nicht wissen. Ein Tipp noch am Rande: Damit ihr das GPG-Passwort nicht permanent neu eingeben müsst, solltet ihr Programme wie Gnome-Keyring oder Keychain und gnupg-agent installiert haben, womit das Passwort zwischengespeichert wird.

Das eigene Deb-Archiv lokal verfügbar machen

Am einfachsten ist es nun auf das lokal erstellte Paketarchiv zuzugreifen, wozu lediglich diese Einträge der /etc/apt/sources.list hinzugefügt werden müssen.

deb file:///home/apo/reprepro/debian/ experimental main
deb-src file:///home/apo/reprepro/debian/ experimental main

Zur Sicherheit solltet ihr die Pin-Priorität dieser Pakete absenken, indem ihr einen Eintrag zur Datei /etc/apt/preferences hinzufügt. Im Regelfall muss sie zuerst angelegt werden. Mit ihr lässt sich präzise das Mischen von mehreren Paketquellen steuern. (Stichwort Apt-Pinning, siehe auch man apt_preferences.)

Package: *
Pin: release o=gambaru.de
Pin-Priority: 1

Da es sich bei meinen Paketen um experimentelle Pakete handelt, ist es am besten die Priorität auf 1, einen sehr niedrigen Wert, zu setzen. Ihr könnt das Ergebnis vorher und nachher mit
apt-cache policy
überprüfen.
Danach genügt wie immer
aptitude update
aptitude -t experimental mediathekview
um das eigene Paket via Apt mit allen Abhängigkeiten zu installieren.

Reprepro: Repository weltweit freigeben

Mit Hilfe eines Web- oder FTP-Servers lässt sich das eigene Archiv auch weltweit und nicht nur lokal verteilen. Die Konfiguration eines Webservers wie Lighttpd war mir schon einen eigenen Beitrag wert. Reprepro funktioniert natürlich auch mit Nginx und Apache.
Ich habe mich jedoch für einen FTP-Server entschieden. Hierzu benutze ich vsftpd. Die Anleitung für die Konfiguration im Zusammenspiel mit OpenArena lässt sich ganz einfach auch auf Reprepro übertragen.
In diesem Fall betreibt ihr den FTP-Server ausschließlich anonym ohne Schreibrechte. Ich habe den kompletten Debian-Ordner des Basisverzeichnisses von Reprepro mittels SCP hochgeladen und die Unterordner db und conf aus Sicherheitsgründen entfernt. Um die Paketquellen von gambaru.de einzubinden, müsstet ihr folgendes in der /etc/apt/sources.list eintragen und den gambaru_archiv-Schlüssel eurem Schlüsselring hinzugefügt haben.

deb ftp://46.182.19.209/debian experimental main
deb-src ftp://46.182.19.209/debian experimental main

Fazit

PPAs waren gestern, heute baut man sich sein eigenes Paketarchiv. 😉 Es gibt noch viele weitere Optionen von Reprepro zu entdecken. Unter anderem ist die automatische Verarbeitung von "incoming queues" möglich und das Spiegeln des kompletten Debian- und Ubuntu-Archivs! Wenn ihr häufig Deb-Pakete herunterladet und Bandbreite sparen wollt, hilft eventuell auch Apt-Cacher-NG, ein Proxy-Server, weiter.
Jeder, der bis hierhin gelesen hat, hat sich automatisch als Tester für zwei Pakete qualifiziert, an denen ich gerade arbeite und hoffe sie als Paketverwalter weiterpflegen zu dürfen. Bitte Bugs direkt hier oder in den alten Posts zu Mediathekview und Wbar melden. 🙂

August 29, 2012Januar 5, 2020

Backup leicht gemacht: Lokale und entfernte Sicherung mit Dirvish, Rsync und SSH

An mehreren Stellen habe ich hier schon meine ganz persönlichen Backup-Methoden vorgestellt.

Die Reihe könnte man noch eine Weile mit weiteren guten Alternativen fortführen. Oft kombiniere ich auch die ein oder andere Variante, wenn mir Daten besonders wichtig sind. In den vergangenen Wochen habe ich mir endlich Dirvish näher angeschaut, das Rsync und SSH miteinander verbindet und mir wieder einmal die Frage gestellt: "Warum eigentlich nicht früher?". 🙂 Wer sowieso schon Rsync und SSH kennt, aber sich die vielen Kommandos nicht merken oder sogar Skripte dafür schreiben möchte, kann ganz einfach auf Dirvish zurückgreifen, das diese Probleme schon vor einer Dekade gelöst hat.
Interessant ist Dirvish nicht nur für alle, die gerne nach besonders effizienten Lösungen für die Konsole suchen, sondern es besticht vor allem durch die einfache Konfiguration und der Möglichkeit die Sicherung vollautomatisch per Cron-Job ablaufen zu lassen und kann auch ganz leicht manuell bedient werden.
Im Folgenden beschreibe ich die Sicherung eines Laptops und eines entfernten vServer mit Hilfe von Dirvish, Rsync und SSH. Dabei werden alle Daten auf eine handelsübliche USB-Festplatte gesichert, die an den Laptop angeschlossen ist.

Backup eines lokalen Rechners auf eine USB-Festplatte mit Dirvish

aptitude install dirvish

Nach der Installation von Dirvish, welches auch automatisch Rsync als Abhängigkeit mitinstalliert, könnt ihr mit der Dokumentation in /usr/share/doc/dirvish/HOWTO.Debian.gz und im dazugehörigen Beispiel-Ordner sofort loslegen. Für die gesamte Konfiguration sind lediglich zwei Dateien entscheidend.

master.conf

Die Datei master.conf wird nach /etc/dirvish/master.conf kopiert. Hierin werden alle globalen Einstellungen festgeschrieben.

bank: Gibt den Pfad zum Speicherort der Sicherung an. In meinem Fall existieren zwei Verzeichnisse auf einer externen USB-Festplatte, der ich zuvor mit
tune2fs -L backup /dev/mapper/udisks-uuid-und-noch-mehr-Text
einen kürzeren und leichter zu merkenden Namen gegeben habe. Wenn man schon dabei ist, kann man sie auch gleich mit luksformat vorher verschlüsseln.
exclude: Definiert die Verzeichnisse, die nicht gesichert werden sollen.
Runall: Die zuerst angegebenen Namen bezeichnen die sogenannen Schließfächer (vault), in denen die Daten gespeichert werden. Ein Schließfach ist nichts anderes als ein Unterverzeichnis, das man nach dem zu sichernden Dateisystem benennen sollte. Der Zeitstempel definiert nicht den Zeitpunkt der Ausführung, sondern dient lediglich als Bezugspunkt. Sollte das Backup z.B. aus welchen Gründen auch immer später ausgeführt werden, wird die Sicherung auf 22.00 Uhr zurückdatiert, damit die Logik intakt bleibt.
expire-default: Kann z.B. never oder +15 days sein und gibt an, wie lange einzelne Sicherungen standardmäßig vorgehalten werden sollen.
expire-rule: Wer den Aufbau der Datei crontab kennt, weiß sofort um was es geht. Die erste Zeile besagt, dass am ersten Tag der Woche, dem Montag, erstellte Backups für 3 Monate vorgehalten werden sollen. Man kann mit Hilfe dieser Syntax weitere beliebige Zeiträume und Zeitpunkte definieren.

bank:
	/media/backup/dirvish/laptop
	/media/backup/dirvish/server
exclude:
	lost+found/
	proc/
Runall:
	laptop-root	22:00
	laptop-home	22:00
	server-root	22:00
expire-default: +15 days
expire-rule:
#       MIN HR    DOM MON       DOW  STRFTIME_FMT
	*   *     *   *         1    +3 months
#	*   *     1-7 *         1    +1 year
#	*   *     1-7 1,4,7,10  1
#	*   10-20 *   *         *    +4 days
#	*   *     *   *         2-7  +15 days

Der Laptop

Erstellt nun die zweite Konfigurationsdatei für das Schließfach laptop-root. In diesem Beispiel wäre das
/media/backup/dirvish/laptop/laptop-root/dirvish/default.conf.
Default.conf ist immer richtig und für die meisten Anwendungsfälle vollkommen ausreichend. Es lassen sich aber noch zusätzliche Konfigurationen erstellen (Branch).

client: laptop
tree: /
xdev: 1
index: gzip
log: gzip
image-default: %Y%m%d
exclude:
        /var/cache/apt/archives/*.deb
        /var/cache/man/**
        /tmp/**
        /var/tmp/**
        *.bak
        /proc/**

Die Datei ist ähnlich wie die Datei master.conf aufgebaut. Wichtig sind hierbei vor allem:
client: In diesem Fall laptop. Wenn dieser Name dem Rechnernamen entspricht (hostname), erkennt Dirvish automatisch, dass es sich um ein lokales Backup handelt und verwendet kein SSH.
tree: Welches Verzeichnis gesichert werden soll. In diesem Fall das gesamte Wurzelverzeichnis.
xdev: Kann den Wert 1 oder 0 annehmen. 1 bedeutet, dass die Sicherung auf das angegebene Dateisystem beschränkt bleibt und Dirvish z.B. eingehängten Verzeichnissen nicht folgen wird. Hat man wie ich /home auf eine andere Partition installiert, würde dieses beim Wert 1 nicht gesichert werden. Hierzu muss also ein weiteres Schließfach mit einer neuen default.conf angelegt werden oder man setzt xdev hier auf 0.
Des Weiteren lässt sich der Zeitstempel für das Backup festlegen und Verzeichnisse von der Sicherung ausschließen. Diese Regel gilt zusätzlich zu den in der master.conf getroffenen Einstellungen.
Für das Schließfach "latop-home" müsst ihr noch einmal die Schritte gehen. Hier ändert sich nur der Wert der tree-Variable auf /home und ggf. die ausgeschlossenen Verzeichnisse.

Die erste Sicherung - Initialisieren

dirvish --vault laptop-root --init
dirvish --vault laptop-home --init

Am nächsten Tag könnt ihr dann mit

dirvish-runall

ein neues Backup erstellen, bei dem nur die geänderten Daten gesichert werden. Aufgrund der Verwendung von Hardlinks und der inkrementellen Natur der Datensicherung wird deswegen nur wenig Speicherplatz benötigt. Wird dieser doch einmal knapp, lässt sich mit

dirvish-expire

Platz schaffen, indem die in der master.conf definierten Regeln Anwendung finden.
Wer einen eigenen Heimserver betreibt, kann auch die Einstellungen in /etc/cron.d/dirvish beibehalten, die dafür sorgen, dass Dirvish automatisch um 04.22 Uhr ausgeführt wird. Wer den Rechner nicht 24/7 laufen lässt, sollte die Datei entfernen oder den Cron-Job auskommentieren.

Entfernte Sicherung eines vServers mit Hilfe von SSH

Wenn ihr bis hierher gefolgt seid, dann ist die Datensicherung eures vServers, auf die an euren Laptop angeschlossene USB-Festplatte, ein Kinderspiel.
Ihr benötigt dafür auf jeden Fall das Paket SSH, einen Account auf dem Server und SSH-Schlüssel. Weiterhin gehe ich davon aus, dass ihr wie im alten Beitrag beschrieben den Port des SSH-Servers geändert habt und Root sich nicht anmelden darf.
Diese Beschränkung heben wir nun wieder auf, da wir den kompletten vServer sichern wollen. Aber...Root darf nur ein einzelnes Kommando über SSH ausführen, den Rsync-Befehl, und sonst nichts.

Default.conf des Servers auf dem Backup-Rechner

client: server
rsh: ssh -p 44444 -i '/root/.ssh/id_rsa'
tree: /
xdev: 1
index: gzip
log: gzip
image-default: %Y%m%d
exclude:
        /var/cache/apt/archives/*.deb
        /var/cache/man/**
        /tmp/**
        /var/tmp/**
        *.bak

Der entscheidende Unterschied zu der lokalen Sicherung der Daten des Laptops ist der geänderte Wert für client: und die Variable rsh. Am besten tragt ihr in /etc/hosts einen Alias für eure Server-IP ein und nennt diesen dann schlicht server.
Der Wert für rsh (remote shell) ist der SSH-Befehl, um sich mit einem SSH-Server und dem SSH-Schlüssel zu verbinden, der auf einem Nicht-Standardport Anfragen entgegennimmt.

Auf dem Server

In der Datei /etc/ssh/sshd_config den Wert für PermitRootLogin auf forced-commands-only setzen.
Danach noch dem öffentlichen SSH-Schlüssel in /root/.ssh/authorized_keys eine Bedingung voranstellen, die erfüllt sein muss, damit sich Root anmelden darf. (vor ssh-rsa schreiben)

command="rsync --server --sender -vlHogDtprxe.iLsf --numeric-ids . /",from="10.0.0.5",no-port-forwarding,no-X11-forwarding,no-agent-forwarding

Mit from= lässt sich sogar die IP-Adresse einschränken, von der sich Root anmelden darf. Der Befehl selbst lässt sich leicht mit htop auf dem Server herausfinden, wenn man ein Dirvish-Backup beobachtet oder man macht es wie Thor Dreier mit einem Hilfsskript, von dem auch dieser exzellente Dirvish-Tipp stammt. Sein Artikel aus dem Jahr 2005 ist auf jeden Fall empfehlenswert.

Fazit

Dirvish ist eine alte, aber noch lange nicht ergraute Lösung zum Sichern von Daten. Mit Hilfe auch gerne etwas älterer Hardware, habt ihr im Handumdrehen eine Backup-Lösung für alle Rechner zu Hause und für das Rechenzentrum in Schweden. 😉

Juli 12, 2012November 19, 2019

Lecker – Cube 2: Sauerbraten

Es ist angerichtet. Anstatt kulinarischer Spezialitäten gibt es heute jedoch das native Linuxspiel Cube 2: Sauerbraten. Zugegeben für all die, wo Deutsch als Muttersprache haben tun, klingt dieser Name für einen waschechten Ego-Shooter erst einmal seltsam in den Ohren. Scheinbar aber nicht für den Erschaffer des Spiels, Wouter „Aardappel“ van Oortmerssen. Wen sollte das bei seinem Spitznamen, "Kartoffel", auch wundern.
In diesem Beitrag stelle ich Cube 2: Sauerbraten vor, das seit mehr als vier Monaten zu meinem Spieleprojekt gehört. Ich beschreibe hier die wichtigsten Spielmerkmale, natürlich gibt es auch Bilder und Links und eine auf den Punkt gebrachte Anleitung, wie man selbst einen dedizierten und offenen Sauerbraten-Server mit Debian und Ubuntu aufsetzen kann.
Und was den Namen anbelangt...einfach Englisch aussprechen: Sourrrrbrrrääten. Perfekter Name für einen Ego-Shooter. 🙂

Warum Sauerbraten?

Nachdem ich mir ein paar Kriterien für in Frage kommende Spiele ausgedacht hatte, punktete Sauerbraten auf jeden Fall mit seinen außerordentlich geringen Hardwareanforderungen sowohl beim Client als auch beim Server.
Das Spiel ist schnell, wirklich schnell, genauso wie in den guten alten Zeiten. Neben 20 verschiedenen Spielmodi existieren auch noch mehr als 150 offizielle Karten, 7 Waffen, ein toller Soundtrack und ein bemerkenswertes Feature, neue Karten mit mehreren Spielern gleichzeitig online zu erschaffen. Von all den Spielen auf dem Server ist es jedoch am "unfreisten". Richard Stallman wird es vermutlich nie spielen. Die Spielengine und damit der Server ist zwar unter einer freien Lizenz verfügbar, große Teile der Mediendateien jedoch nicht.
Dennoch glaube ich, dass Sauerbraten eine Chance verdient hat, da das Spiel nicht nur die Möglichkeit bietet neue freie Inhalte zu schaffen, sondern auch schon Projekte wie Red Eclipse inspiriert hat, deren Medieninhalte unter freien Lizenzen stehen.

Der Sauerbraten-Client

aptitude install sauerbraten
Die Spielanforderungen von Sauerbraten sind moderat. Eine 1-GHz-CPU, 256MB RAM und eine Geforce 4 MX sollten es mindestens sein. Wer jemals einen Ego-Shooter gespielt hat, kennt das grundlegende Prinzip. So lässt sich auch Sauerbraten mit den W-A-S-D-Tasten steuern, mit Space springt der eigene Avatar, mit der linken Maustaste wird geschossen und mit kreisenden Mausbewegungen das Sichtfeld geändert.
Danach sind noch erwähnenswert:
R - Sollte man trotz aller Versuche in einer Ecke zu campen über die Flagge gestolpert sein, dann kann man sie mit einem Druck auf R wieder fallenlassen. 😉
T - öffnet den Chat. Auf einem öffentlichen Server ohne AUTH kann man mit der Eingabe von /setmaster 1 Masterrechte erlangen. Dazu gleich mehr.
E - Startet den Bearbeitungsmodus, in dem es möglich ist, innerhalb des Coop-Edit-Modus mit mehreren Mitspielern gleichzeitig eine Karte zu verändern oder neuzugestalten! Auf ogros.org gibt es eine nette Übersicht zu einer (englischen) Videoanleitung zum Thema.
Mehr ist wirklich nicht notwendig, um in das Spiel einsteigen zu können.

Serverbrowser und das Menü

Das Spielmenü und insbesondere der Serverbrowser könnten übersichtlicher gestaltet sein. Es gibt jedoch die Möglichkeit ein eigenes zu erstellen, wie dieser Artikel auf ogros.org beschreibt. Da die Voreinstellungen gut sind und man intuitiv in das Spiel findet, muss man sich hier nicht lange aufhalten. Unter Keys lassen sich die Tastenbelegungen ändern.

Cube Server Lister

Ich hatte den Cube Server Lister schon an anderer Stelle erwähnt. Wer sich mit dem normalen Serverbrowser nicht anfreunden kann, sollte sich die Zeit nehmen und der Anleitung folgen, wie man sich ein eigenes CSL-Debianpaket erstellen kann. Mit diesem Hilfsprogramm, dass unter der GPL veröffentlicht worden ist, lassen sich Details zu allen Cube-2-Servern anzeigen und mit einem Doppelklick auf den Servernamen des jeweiligen Spiels tritt man einem Spiel bei.

Spielmodi

Sauerbraten bietet ein Wiki mit einem Multiplayer Guide und eine umfangreiche Dokumentation.
Im Mehrspielermodus gehört man entweder dem guten oder dem bösen Team an. Mit leisen Zwischentönen halten wir uns natürlich nicht auf. Unabhängig davon gilt: Die roten Spieler sind immer die Gegner und mit den blauen spielt man in einem Team zusammen.
In Sauerbraten gibt es sieben verschiedene Waffen: Doppelläufige Schrotflinte, Minigun, Gewehr, Raketenwerfer, Granaten, Pistole, Fäuste/Kettensäge. Dazu lassen sich in den meisten Modi Gesundheit, Rüstung und Munition aufsammeln.
Das Spiel bietet zur Zeit 20 verschiedene Spielmöglichkeiten und in der aktuellen Entwicklerversion stehen schon weitere parat. Neben dem klassischen Free For All (FFA) und InstaGib, wo es einfach nur um "Jeder gegen Jeden" geht, gibt es natürlich auch noch Fahnenraub (alias Capture the Flag). Mir persönlich gefällt "Regen Capture" ziemlich gut, wo man auf einer relativ großen Karte verschiedene Punkte kontrollieren muss. An einer eroberten Station erhält man Waffen, Leben und Punkte. Dieser Modus ist auch mit sehr vielen Spielern noch interessant und sehr dynamisch.
Der Screenshot zeigt eine Szene aus einem Spiel mit dem Modus "Regen Capture". Außerdem erkennt man an der Servernachricht, dass der Server gepatcht wurde.

Coop-Edit-Modus

Auf meinem offenen Server wird sehr oft der Coop-Edit-Modus genutzt. Hier lassen sich gemeinsam mit anderen Spielern bestehende Karten modifizieren oder komplett neue erstellen. Die oben erwähnte Anleitung zum Kartenbau oder ein Blick auf die Wiki-Seite Mapping and Editing ist ein guter Start in die Materie. Das Wichtigste: Wenn ihr einem Server beitretet, auf dem an einer neuen Karte gearbeitet wird, einfach /getmap in den Chat schreiben und ihr seht den aktuellen Stand vor euch. Hier sind ein paar Screenshots von einer Coop-Edit-Sitzung auf dem Server.
In Natenoms Blog findet ihr unter anderem ein cooles Video zu einer selbst erstellten Karte, die eine in sich geschlossene kleine Stadt darstellt. Da steckt sicher eine Menge Arbeit drin.

Musik

Sauerbratens instrumentaler Metalsoundtrack stammt von Marc A. Pullen, lässt sich auf last.fm herunterladen und befindet sich selbstverständlich auch im OGG-Format in /usr/share/games/sauerbraten/fanatic/.

Der Sauerbraten-Server

Aufgrund des besonderen Client-Server-Modells ist der Sauerbraten-Server sehr leichtgewichtig. Der Speicherverbrauch liegt bei 2-3 MB RAM auf einem 64bit-System und auch die CPU-Anzeige von htop habe ich selbst bei einem vollen Server noch nie über 1% springen sehen. Im Gegensatz zu vielen anderen Mehrspieler-Spielen ist es bei Sauerbraten nicht notwendig, dass Server und Client sich permanent über Treffer und Aktionen austauschen, was es erlaubt die wesentlichen Funktionen des Servers auf ein Minimum zu beschränken. Dadurch bleibt das Spiel selbst bei hohen Pings noch spielbar. Auf der anderen Seite macht es Sauerbraten gegenüber Cheatversuchen auch verwundbarer, was durch die Open-Source-Natur des Spiels noch begünstigt wird.

Die Authentifizierung

Sauerbraten begegnet diesem Problem mit einer ungewöhnlichen, aber nachvollziehbaren Entscheidung. Da selbst die populärsten proprietären Spiele mit einem Stab von bezahlten Entwicklern keinen vollkommenen Schutz gegen jede Art von Manipulationsversuch bieten können, haben die Entwickler die Verantwortung und Kontrolle an die Spielgemeinschaft zurückgegeben. Auf jedem Server kann ein Spieler sogenannter "Master" werden und Verstöße mit einem Bann vom Server bestrafen. Die Funktion wird entweder über das Spielmenü oder durch Eingabe von /setmaster 1 im Chat (Taste t) aufgerufen.
Sauerbraten-Server kennen im Wesentlichen zwei Arten von Autorisation: Mit Auth-Schlüssel und ohne.

Auth-Schlüssel. Durch den Hauptentwickler des Spiels werden sogenannte Auth-Schlüssel vergeben, mit denen vertrauenswürdige Spieler auf jedem Server mit Auth-Status Master werden können.
Öffentliche Server. Jeder kann dem Server beitreten. Diejenige, welche zuerst /setmaster 1 in den Chat eingibt, erhält den Master-Status.

Von diesen beiden Formen der Registrierung ist der Administrator des Server mit seinem Admin-Passwort jedoch nicht betroffen. Er kann jederzeit mit /setmaster und der anschließenden Eingabe des Admin-Passworts selbst dann zum Master werden, wenn diese Rechte schon an einen anderen Spieler vergeben worden sind.
Für mein Projekt habe ich mich für einen öffentlichen Sauerbraten-Server entschieden, auf dem jeder Master werden kann. Zusätzlich ist es möglich den Server so zu sperren, dass zwar weiterhin Spieler beitreten können, diese aber nur zuschauen und den Chat mitlesen dürfen. (L=Locked)

Installation und Konfiguration

aptitude install sauerbraten-server
Zur Inbetriebnahme des Servers ist es sinnvoll einen unprivilegierten Benutzer mit adduser anzulegen, z.B. sauerbraten. In dessen Home-Verzeichnis wird die zentrale Konfigurationsdatei server-init.cfg erstellt. Die verfügbaren Einstellungsmöglichkeiten sind überschaubar, was es einfach macht sich zurechtzufinden. Es ist sinnvoll die Shell des Benutzer auf /bin/false zu setzen.
chsh sauerbraten -s /bin/false
Das Programm lässt sich am besten in einer Screen-Sitzung starten. Hierzu erstellt man eine ausführbare Datei start.sh mit folgendem Inhalt.

#!/bin/sh
while true
do
/usr/games/sauerbraten-server -q/home/sauerbraten
echo "server abgestuerzt am `date`" > letzter_crash.txt
done

Den Server kann man danach auf diese Weise starten:
su sauerbraten -s /bin/dash -c "screen -m -d -S ffa_sauer sh start.sh"
Sollte es tatsächlich zu einem Absturz kommen, sorgt die While-Schleife automatisch für den Neustart und für einen kurzen Vermerk in der Datei "letzter_crash.txt". Sauerbraten läuft sehr stabil. Bei einer Uptime von > 30 Tagen kam es jedoch auch schon zum Crash. Die oben genannte Konfiguration sorgt dann dafür, dass der Server nur wenige Sekunden nicht erreichbar ist.
Schließlich lässt er sich auch über eine Cron-Reboot-Aktion bei einem Neustart hochfahren. In /etc/crontab steht deswegen
@reboot sauerbraten screen -d -m -S ffa_sauer sh /home/sauerbraten/start.sh
Der Port des Servers lässt sich ändern. Wer eine Firewall betreibt muss den Standardport 28785 und 28786 freigeben. Spielt man im LAN gilt das auch für Port 28784. Allgemein gesprochen: Gebt immer Port und Port+1 frei und im LAN zusätzlich noch 28784.

Modifikationen

Ich betreibe den Server, so wie ihn Debian und auch Ubuntu ausliefern, ohne jede Form von Modifikation. Es gibt verschiedene Projekte, die die Standardfunktionen erweitert haben, jedoch weiterhin kompatibel zum Original sind. Neue Merkmale sind unter anderem veränderte Statistikanzeigen im Spiel, neue Kontrollmöglichkeiten durch den Admin und Integration mit IRC. Maßgeblich sind das die Projekte XSBS und Hopmod. Ebenfalls erwähnenswert ist Bandnudel, ein Skript um Statistiken für den Server zu erstellen. Da ich diese Modifikationen nicht benutze, seid ihr hier auf euch allein gestellt.
Des Weiteren bietet der gesamte Webauftritt des Ogros-Clans einen guten Überblick, was man mit selbst erstellen Servermodifikationen erreichen kann. Leider werden diese im Gegensatz zum Cube-Server-Lister, der ebenfalls von dort stammt, nicht frei zur Verfügung gestellt.

Screenshots

Hier sind ein paar Screenshots. Viele weitere gibt es hier.