Icecast installieren und die Version einordnen

Wählen Sie den Installationsweg, bevor Sie Pfade aus Beispielen übernehmen. Distributionspakete sind in ihr Betriebssystem eingebunden. Ein selbst gebauter Server unter einem eigenen Präfix hat andere Dateien und einen anderen Wartungsweg. Beide Wege können unterschiedliche Versionen liefern.

Ein Distributionspaket verwenden

Prüfen Sie unter Debian zunächst das Paket aus den eingerichteten Paketquellen:

sh · Codebeispiel

apt-cache policy icecast2
sudo apt install icecast2
dpkg-query -W icecast2
dpkg -L icecast2

Diese Befehle gelten für Debian, nicht pauschal für jede Linux-Distribution. Bei der Quellenprüfung führte Debian stable die Version 2.4.4, während das Originalprojekt 2.5.0 anbot. Distributionskorrekturen und Upstream-Support sind getrennt zu bewerten. Verwenden Sie Beispiele für die tatsächlich installierte Version und beachten Sie die Dienstkonfiguration Ihrer Distribution.

Die Dateiliste zeigt die installierten Orte von icecast.xml, Webdateien und Verwaltungstransformationen. Setzen Sie nicht /usr/local/etc voraus, wenn das Paket /etc/icecast2 nutzt. Läuft bereits ein Dienst, untersuchen Sie ihn vor dem Start eines zweiten Prozesses auf demselben Port.

Ein bestimmtes Upstream-Release bauen

Laden Sie das gewünschte Archiv beim Originalprojekt. Notieren Sie Dateiname und Prüfsumme, entpacken Sie es in ein Arbeitsverzeichnis und lesen Sie die enthaltene README. Zu den Voraussetzungen von 2.5.0 gehören libxml2, libxslt, libogg/libvorbis, libigloo und librhash. Zum Kompilieren sind Entwicklungsheader nötig; reine Laufzeitbibliotheken reichen unter Umständen nicht. curl ermöglicht URL-Authentifizierung und Verzeichnisanbindung.

Im entpackten Release-Verzeichnis lautet der Build-Ablauf mit einem bewusst eigenen Installationspräfix:

sh · Codebeispiel

./configure --prefix="$HOME/icecast-local"
make
make install

$HOME/icecast-local steht hier für Ihren gewählten Testort und keine systemweite Installation. Ein Release-Archiv enthält bereits configure. Für einen Git-Checkout gelten zusätzliche Bootstrap- und Submodulschritte. Vermischen Sie diese Installationen nicht. Ein historisches Installationsbeispiel mit erhöhten Rechten ist kein Grund, den Server als root zu betreiben.

Erst die Installation, dann den Stream prüfen

Prüfen Sie Hilfe beziehungsweise Versionsausgabe des gewählten Programms und das Startprotokoll. Halten Sie Paket- oder Archivherkunft zusammen mit der Laufzeitversion fest. Ein erfolgreicher Build belegt weder TLS-Unterstützung noch einen laufenden Dienst oder hörbares Audio. Anschließend folgt der begrenzte Test des ersten Streams.