Damit ich nicht immer wieder unter http://mumble.info/snapshot selbst nachgucken muss, ob es Updates gibt, wird nun mit Hilfe von Python regelmäßig ein News-Feed erzeugt, der die letzten 30 Pakete enthält.
Erreichbar ist er unter http://natenom.name/r/mumbledownloads, was aktuell eine Weiterleitung ist, da der entgültige Ort des Feeds noch nicht feststeht; die Weiterleitung wird aber in jedem Fall bleiben. Es könnte sein, dass der Feed nicht ganz Standard-konform ist und die Uhrzeiten noch nicht korrekt sind. Es hat jedoch funktioniert mit akregator, Thunderbird und Liferea.
Vielleicht kann den Feed ja noch jemand gebrauchen
Es ist zu beachten, dass dies kein offizieller Feed des Mumble-Projekts ist; es wird nur die Verzeichnisliste des Projektservers ausgewertet.
Update (2013-03-13): Es wird jetzt eine kurze Beschreibung angezeigt, um welche Art von Datei es sich handelt.
Damit der Mumble-Client die Serverliste mitsamt der dargestellten Informationen anzeigen kann, verschickt er ein spezielles Ping-Paket an jeden eingetragenen Server und anhand der Antwort erhält er Informationen zu der Anzahl der Benutzer und der Slots, der Protokollversion und der verfügbaren Bandbreite pro Benutzer.
Dieses Paket kann man auch selbst ohne Mumble-Client an jeden Server schicken.
Dass es dazu bereits ein fertiges Python-Script gibt, wurde vor ein paar Tagen im IRC gepostet; habe die Informationen zusammengefasst im Wik.
Mumble-Django ist ein in Python implementiertes Admin-Interface für die Verwaltung von einem oder mehreren Mumble-Servern (Murmur). Für Interessierte gibt es einen Demo-Zugang unter demo.mumble-django.org. Eine gute Installationsanleitung findet sich hier.
In der aktuellen, stabilen Version 2.7 fehlen jedoch noch ein paar Einstellungen und man muss zu einer anderen Möglichkeit greifen, diese zu ändern; z. B. über eine interaktive Python-Shell, direkten Datenbankzugriff (während der Server aus ist) oder sonstigem.
Dies hat sich jedoch vor ein paar Tagen geändert, man kann seitdem alle verfügbaren Einstellungen in Mumble-Django konfigurieren. Die Änderungen werden in Version 2.8 enthalten sein; man kann sich aber auch jetzt schon die Entwicklerversion herunterladen, es lohnt sich
Neues
Folgende Einstellungen sind dazugekommen:
opusthreshold (Angabe in Prozent ohne %-Zeichen)
Wenn der angegebene Prozentanteil der Clients auf einem Server Unterstützung für den neuen Opus-Codec hat, wird dieser für den gesamten Server aktiviert; Clients ohne diesen Codec sind dann tontechnisch ausgeschlossen.
registerpassword (Zeichenkette)
Passwort, welches für die Registrierung in der offiziellen Serverliste verwendet wird.
registerlocation (Zeichenkette) Land, in dem der Mumble-Server in der Serverliste eingeordnet werden soll; hierfür müssen bestimmte Voraussetzungen gegeben sein, siehe hier.
allowping (An/Aus)
Wenn deaktiviert, kann man in der Serverliste nicht sehen, wieviele Benutzer sich auf einem Server befinden und wieviele Slots der Server hat.
sslpassphrase (Zeichenkette)
Das Passwort für einen geschützten, privaten Zertifikats-Schlüssel
channelnestinglimit (Zahlenwert)
Maximale Verschachtelungstiefe (Ebenen) für Kanäle
Verbesserungen
Bezüglich der suggest-Einstellungen(Push-To-Talk, Positionsabhängiges Audio und Client-Version) kann man nun nicht mehr nur angeben, was empfohlen wird, sondern die Empfehlung auch deaktivieren.
Passt
Damit deckt Mumble-Django alle für Mumble verfügbaren Einstellungen ab und ist auch für das zukünftige Mumble 1.2.4 gerüstet
Das Plugin murmur-munin.py für Munin wurde aktualisiert:
Es hat nun die Einstellung messagesizemax, die auf denselben Wert voreingestellt ist, den auch der Mumble-Server verwendet, damit die Auswertung auch noch bei größeren Servern funktioniert.
Es kann auch Server abfragen, bei denen der Zugriff auf Ice per Passwort geschützt ist (icesecret).
Die aktuelle Version von DeafToAFK ist 0.9.0 und liegt auf Github.
Der Code wurde umgestaltet und ist nun hoffentlich übersichtlicher als vorher, auch wenn er teils noch umständlich ist.
Bug(?)
Grund für das Update ist ein unschönes Verhalten des Mumble-Servers:
Erstellt man einen temporären A, erhält dieser als channel_id z. B. die 223. Löscht man nun den Kanal A und erstellt danach einen neuen temporären Kanal B, ohne dass vorher weitere Kanäle erstellt wurden, so erhält dieser neue Kanal auch wieder die channel_id 223.
Dadurch landeten auf einem Server, dessen Admin auf den Bug aufmerksam gemacht hat und auf dem viele Benutzer mit temporären Kanälen arbeiten, immer wieder Leute fremden Kanälen.
Lösung
Das Problem wurde so gelöst, dass sich DeafToAFK per Callback beim Löschen eines Kanals einklinkt und überprüft, ob einer der eingetragenen AFK-Benutzer im gelöschten Kanal war, bevor er sich stumm und taub gestellt hat. Falls ja, so wird der Wert des gespeicherten Kanals durch den von defaultchannel ersetzt.
MuMo – Mumble Moderator – ist ein System, welches die Kommunikation zwischen Ice und einem Mumble-Server übernimmt und einem sehr einfach die Möglichkeit gibt, Plugins/Module zu entwickeln um die Funktionalität von eines Mumble-Servers (Murmur) zu erweitern. Man kann sich an bestimmte Ereignisse wie z.B. “userConnected” anhängen und kann dann dem Benutzer eine Nachricht zukommen lassen.
MuMo wird entwickelt von einem der Hauptentwickler von Mumble, Stefan ‘dd0t’ Hacker.
Es werden bereits Module mitgeliefert, um den Benutzer nach einer einstellbaren Zeit der Untätigkeit in einen AFK-Kanal zu verschieben oder mittels !seen Username eine Info zu erhalten, wann derjenige Benutzer das letzte Mal auf dem Server war.
Im Wiki gibt es auch noch ein paar andere Module, wie z.B. Antirecord, welches Benutzer stumm und taub stellt wenn sie aufnehmen oder DeafToAFK, welches nur Benutzer in den AFK-Kanal verschiebt, wenn sie sich stumm und taub gestellt haben: http://wiki.natenom.name/mumble/tools/mumo/module.
Es ist wirklich sehr einfach mit ein paar Python-Kenntnissen solche Module zu schreiben; und es macht Spass.
Einzig die Verwendung von Kontextmenüs (rechtsklick auf einen Benutzer oder Kanal) ist noch nicht in MuMo implementiert; doch stattdessen kann man über den Textchat Befehle an den Server senden, wie beim !seen Modul.
Die Installation von MuMo ist etwas tricky, deshalb gibt es hier eine Installationsanleitung für das aktuelle Debian Squeeze; andere Distris werden wohl etwas andere Bezeichnungen der Pakete haben; aber ab dem Punkt “MuMo holen” sollte alles gleich sein.
Man braucht natürlich auch noch einen laufenden Mumble-Server, am besten die Version 1.2.3; dafür sollte es genügend Dokumentation geben.
Will man jedoch Module verwenden, die auf Befehle über den Textchat von Mumble reagieren, wie z.B. “!seen” des gleichnamigen Moduls, so braucht man einen Mumble-Server in der Version 1.2.4, da erst hier das neue Callback userTextMessage implementiert wurde.
Wenn MuMo läuft, ist die aktuelle und gut dokumentierte Murmur.ice sehr hilfreich; sie enthält Informationen über die Struktur der Daten, die man in MuMo verarbeiten kann.
Das Modul läuft soweit und die Funktionalität des alten Scripts ist komplett implementiert, wenn auch die Interaktion anders ist.
Der Code ist mit Sicherheit sehr unsauber; aber es funktioniert soweit.
Zumindest das Grundgerüst (MuMo) ist bestimmt sehr sauber. Es sollte also nicht mehr den Bug geben, dass nach einer gewissen Zeit der Server nicht mehr reagiert bis das Script gewaltsam beendet wird.
Dank MuMo kann man nun auch einstellen, für welche virtuellen Server sich das Modul verantworlich fühlen soll. Auch lässt sich die komplette Konfiguration pro virtuellem Server anders festlegen. Da es leider noch keine Möglichkeit gibt, Kontextmenüs zu verwenden, werden stattdessen die drei Befehle !allow, !list und !disallow verwendet, die als Nachricht an eine beliebige Stelle des Servers geschickt werden können (Benutzer oder Kanal).
Benutzer, die keine Aufnahmeerlaubnis haben, werden sofort stumm und taub gestellt; sobald sie ihre Aufnahme beenden können sie wieder hören und sprechen; genauso wie Benutzer, deren Aufnahmeerlaubnis während einer Aufnahme entzogen wird.
Mit dem Befehl !list bekommt man – nur als Mitglied der Gruppe canallowrecord – eine Übersicht der aktuell auf dem Server befindlichen Benutzer, deren SessionIDs und der Benutzer, die aktuell eine Aufnahmeerlaubnis haben:
Bei sehr umfangreichen/großen Mumble-Servern mit vielen Beschreibungen, Kommentaren, Bildern usw. kann es passieren, dass man bei Benutzung der Funktion getTree() in Python folgende Meldung bekommt:
exception ::Ice::MemoryLimitException
Das liegt dann daran, dass der Standardwert von MessageSizeMax in Python nicht groß genug ist um die komplette Nachricht auszuwerten.
Das Problem war bereits von PHP bekannt, für Python kannte ich aber bis dato keine Lösung.
So, es funktioniert im Prinzip … auf unserem Mumble-Server kann man nun “Schere, Stein, Papier” (SSP) über das Kontextmenü spielen
Die Idee dazu hatte ich heute morgen weil wir ab und an mal das Problem haben, dass manche Menschen aggro aufeinander sind ihre Rechte nutzen um sich zu beweisen …
… vielleicht wird es ja damit besser.
Es ist allerdings auf registrierte Benutzer beschränkt, da es auch eine Bestenliste geben soll.
Alles zum Spiel steht dann im Log-Bereich:
Noch wird natürlich nicht gekickt, das kommt erst später; oder eine sonstwie geartete Nachricht, whatever.
Features:
Wenn der Herausgeforderte oder der Herausforderer den Server verlässt, wird das Spiel automatisch gelöscht.
Die Nachricht über die Herausforderung geht an alle Kanäle in denen sich die beiden Spieler befinden; genauso verhält es sich mit dem Ergebnis.
Man kann nicht gegen sich selbst spielen
Geplante Features:
Bestenliste (SQLite), die man auch übers Kontextmenü abrufen kann
Verlierer wird gekickt oder bekommt eine Nachricht
Herausforderung verfällt nach 30 Sekunden
Wenn der Quellcode nicht mehr ganz so schrecklich ist, werde ich diesen auch wieder ins Wiki laden.
Das uralte Stille-Treppe Script wurde überarbeitet und verbessert
Die Features des Sticky-Scripts sind:
Selbst ein Admin kann seinen Sticky Status nicht entfernen.
Wenn sich ein Admin im Sticky befindet, kann er nicht aus “Rache” einen anderen Benutzer in den Sticky Status versetzen.
Der Sticky Status wird auch über Reconnects gespeichert.
Wenn sich ein Benutzer mit Sticky zum Server verbindet, bekommt er einen Hinweistext.
Es ist nicht möglich, sich selbst versehentlich einen Sticky zu geben.
Wenn der Sticky entfernt wird, so wird der Benutzer automatisch in den Kanal verschoben in dem er vorher war.
Der “verurteilte” Benutzer wird automatisch in den Sticky-Raum – bei uns die Stille Treppe – verschoben und kommt dort erst wieder raus, wenn der Sticky Status entfernt wird. An die Benutzer im Kanal geht eine Meldung raus, was da gerade passiert.
Wer das ausprobieren möchte, ist auf unserem Server herzlich willkommen.
