elementaryOS und die Indikatoricons

elementaryOS verfügt über eine Status- und Menüleiste, ähnlich macOS. In dieser Leiste, welche sich am oberen Bildschirmrand befindet, befinden sich Indikatoren für das Netzwerk, den Sound und einige andere Dinge. Auch Applikationen, wie z. B. der Nextcloud-Client legen dort ihr Status-Icon ab. Wenn der Nextcloud-Client unter elementaryOS in der Version 6 (Odin) installiert wird, taucht allerdings kein Icon in der oberen Leiste auf. Grund hierfür ist das diese nicht Out-of-the-box unterstützt wird.

Die Einstellungen von elementaryOS

Allerdings kann hier Abhilfe geschaffen werden mit dem Wingpanel Ayatana-Compatibility Indicator. Um diesen in elementaryOS zu installieren, sollte im ersten Schritt das Terminal geöffnet und einige Abhängigkeiten installiert werden:

install libglib2.0-dev libgranite-dev libindicator3-dev libwingpanel-dev indicator-application

Anschließend kann der Download der entsprechenden DEB-Datei angestoßen werden:

wget -c "https://github.com/Lafydev/wingpanel-indicator-ayatana/blob/master/com.github.lafydev.wingpanel-indicator-ayatana_2.0.7_amd64.deb?raw=true" -O wingpanel-indicator.deb

Danach wird das heruntergeladene Paket installiert:

dpkg -i wingpanel-indicator.deb

Nun muss dafür gesorgt werden, dass der Wingpanel Ayatana-Compatibility Indicator beim Systemstart geladen wird. Dies kann unter elementaryOS über die Systemeinstellungen und dort den Punkt Anwendungen bewerkstelligt werden. Dort findet sich der Punkt Beim Anmelden automatisch gestartete Anwendungen. Unter diesem Punkt wird nun unten links eine neue Anwendung hinzugefügt und dort ein benutzerdefinierter Befehl eingegeben:

/usr/lib/x86_64-linux-gnu/indicator-application/indicator-application-service

Im Terminal muss nun noch eine Änderung an der Datei indicator-application.desktop vorgenommen werden:

nano /etc/xdg/autostart/indicator-application.desktop

Dort muss nun der Parameter Pantheon; hinzugefügt werden, sodass die Datei am Ende wie folgt aussieht:

[Desktop Entry]
Type=Application
Name=Indicator Application
Exec=/usr/lib/x86_64-linux-gnu/indicator-application/indicator-application-service
StartupNotify=false
Terminal=false
OnlyShowIn=Unity;GNOME;Pantheon;
NotShowIn=ubuntu;
NoDisplay=true
AutostartCondition=GNOME3 unless-session gnome

Nach einem Neustart des Systems funktioniert der neue Indikator, sodass z. B. das Status-Icon des Nextcloud-Clients ebenfalls auftauchen sollte.

Minecraft Server Status Checker

Auf der Suche nach einem kleinen Tool, um zu testen ob ein Minecraft-Server ordnungsgemäß läuft, bin ich auf den Minecraft Server Status Checker gestoßen. Er überprüft ob der Server erreichbar ist und liefert einige weitere Informationen wie z.B. die aktuelle Spieleranzahl. Zu finden ist der Check auf der Webseite des ehemaligen Minecraft-Entwickler Nathan Adams.

dinnerbone.com/minecraft/tools/status/

dinnerbone.com/minecraft/tools/status/

Der Minecraft Server Status Checker ist dabei freie Software dessen Quelltext auf GitHub zu finden ist. Als Lizenz wurde die Apache Licence gewählt.

Das Icecast-Protokoll

Bei Icecast handelt es sich um einen freien Streamingserver. Der Server nimmt ein Signal entgegen und streamt es über einen Mountpoint, mit welchem sich die Nutzer des Servers verbinden um den Stream zu hören. Leider ist das Icecast-Protokoll nicht wirklich gut dokumentiert. Stattdessen wird darauf verwiesen, das der Quellcode verfügbar ist. Mit diesem Artikel soll diesem Problem ein wenig Abhilfe geschaffen werden. Das Icecast-Protokoll ist streng genommen einfaches HTTP. Wenn ein Eingangssignal zu einem Icecast-Server gestreamt sendet die Streamingquelle einen HTTP-Request (am Beispiel von butt):

PUT /stream123 HTTP/1.1
Authorization: Basic c291cmNlOmhhY2ttZQ==
User-Agent: butt 0.1.14
Content-Type: audio/mpeg
ice-name: no name
ice-public: 0
ice-audio-info: ice-bitrate=128;ice-channels=2;ice-samplerate=44100

Bei Mixxx würde dieser Request so aussehen:

SOURCE /stream123 HTTP/1.0
Authorization: Basic c291cmNlOmhhY2ttZQ==
User-Agent: libshout/2.0.0
Content-Type: application/ogg
ice-name: 
ice-public: 0
ice-url: http://www.mixxx.org
ice-genre: Live Mix
ice-audio-info: bitrate=128
ice-description:

Den SOURCE-Request den Mixxx hier anwendet ist seit der Version 2.4 des Icecast-Server veraltet und sollte nicht mehr genutzt werden. Stattdessen soll der PUT-Request verwendet werden. Wie man hier sehen kann erfolgt die Authentifizierung über das Basic Authentication Scheme (auch als HTTP Basic Authentication bekannt). In dem Request sind eine Reihe von ice-* Parametern zu finden:

ice-audio-info
Der Parameter ice-audio-info übermittelt eine Schlüssel-Wert-Liste von Audioinformationen. Die Parameter werden dabei durch ein Semikolon getrennt, das ganze könnte z.B. so aussehen:

channels=2;samplerate=48000;

Die Parameter müssen dabei mit der URL-Kodierung kodiert werden.

ice-bitrate
Der Parameter ice-bitrate setzt die Bitrate des Streams.

ice-description
Ist die Beschreibung des Streams nicht mit dem Tag stream-description definiert, so kann die Beschreibung über den Parameter ice-description eingestellt werden.

ice-genre
Ist das Genre des Streams nicht mit dem Tag genre definiert, so kann dies über den Parameter ice-genre eingestellt werden.

ice-name
Ist der Streamname nicht mit dem Tag stream-name definiert, so kann dies über den Parameter ice-name eingestellt werden.

ice-public
In der Konfiguration gibt es das Attribut public, welches angibt ob der Stream in einem öffentlichen Verzeichnis auftauchen soll. Ist der Public-Tag für den Mountpoint nicht definiert, kann dies über den Parameter ice-public gesetzt werden.

ice-url
Ist die URL des Streams nicht mit dem Tag stream-url definiert, so kann dies über den Parameter ice-url eingestellt werden.

Daneben gibt es noch den Content-Type welcher die Art des Streams definiert. Auf diesen Request antwortet der Icecast-Server (wenn die Authentifizierung korrekt ist) mit einem:

HTTP/1.0 200 OK

Statt dem Statuscode 200 sind noch eine Reihe weiteres Codes als Antwort möglich:

401 You need to authenticate
Die Authentifizierungsdaten sind nicht korrekt.

403 Content-type not supported
Streamformat wird von Icecast nicht unterstützt.

403 No Content-type given
Der Quellclient sendete kein Content-Type mit, dies wird allerdings zwingend benötigt.

403 internal format allocation problem
Internes Problem von Icecast mit dem gewählten Formatplugin.

403 too many sources connected
Das in der Konfiguration definierte Limit an gleichzeitig verbundenen Clients wurde überschritten.

403 Mountpoint in use
Der gewählte Mountpoint ist bereits in Benutzung.

500 Internal Server Error
Ein interner Fehler im Icecastserver, auf Clientseite gibt es für diesen Fehler keine Lösung.

Eine Besonderheit ist der Statuscode 100 (Continue) welcher gesendet wird, wenn der Client einen Request mit folgendem Inhalt gesendet hat:

Request: 100-continue

Mit dem Statuscode bestätigt der Server das der Client weiter Daten senden kann. Danach beginnt der Quellclient mit dem häppchenweisen senden des Ogg Vorbis- oder MP3-Stream – das bedeutet das eine MP3 nicht am Stück gesendet wird, sondern in Häppchen welche das Fortschreiten des Streams widerspiegeln. Beim Empfangen eines Streams passiert effektiv das selbe. Der Client (z.B. VLC) sendet dem Server einen GET-Request:

GET /stream123 HTTP/1.1
Host: 10.63.48.119:8000
User-Agent: VLC/2.2.1 LibVLC/2.2.1
Range: bytes=0-
Connection: close
Icy-MetaData: 1

Darauf antwortet der Icecast-Server mit mit:

HTTP/1.0 200 OK
Server: Icecast 2.4.0
Date: Thu, 02 Jul 2015 10:13:50 GMT
Content-Type: audio/ogg
Cache-Control: no-cache
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Pragma: no-cache
ice-audio-info: samplerate=44%2e100;channels=1;quality=0
icy-pub:1

Anschließend sendet der Icecast-Server die Audiodaten an den Client, welche dieser wiedergibt.

Dieser Tweet ist in dieser Woche nicht verfügbar

Ich hatte vor einiger Zeit einen Status-Bot für Twitter geschrieben. Dieser Bot schaut ob eine Bedingung erfüllt ist und twittern dann einen Satz wie:

Die Tür ist offen.

Wenn die Bedingung sich wieder ändert, könnte der Bot:

Die Tür ist zu.

twittern. Allerdings gibt es da ein Problem. Twitter lässt doppelte Tweets innerhalb einer bestimmten Zeitspanne (Gerüchten zu folge – eine Woche) nicht zu. Damit muss sich der Status-Bot etwas ausdenken wenn er die gleiche Nachricht öfters verschicken möchte. Wenn man dieses Verhalten von Twitter nicht kennt, wundert sich warum der Tweet nicht abgeschickt werden kann. Die einfachste Möglichkeit ist es hier einfach einen Zähler in den Tweet einzubauen. Alternativ kann man die gleiche Nachricht natürlich in unterschiedliche sprachliche Konstrukte packen.

GitHub Statusseite

Falls man bei der Entwicklung plötzlich feststellt das GitHub nicht mehr so funktioniert wie es sollte gibt es dafür zwei Möglichkeiten. Entweder macht der lokale Anschluss Probleme oder die Schuld liegt bei GitHub. Möchte man GitHub als Schuldigen ausschließen, hilft die Statusseite von GitHub.

GitHub Status

GitHub Status

Diese ist dabei unter https://status.github.com/ zu finden. Im Falle einer Störung erfährt man hier um welche Störung es sich handelt, und wie lange die Störung noch vorhalten wird. Angereichert ist das ganze mit ein paar Statistiken über Antwortzeiten und Fehlerhäufigkeiten.