Der dokumentierte Stand ist Commit ea3554b5167f6780a8be77f1715f90ed02005665. Seine configure.ac nennt 2.4.0-kh22. Das offizielle Release icecast-2.4.0-kh22 erschien am 4. Juli 2023. Der festgelegte Master-Commit stammt vom 21. November 2023. Das sind unterschiedliche Herkunftsangaben und keine austauschbaren Downloads.
Das laufende System erfassen
Notieren Sie Programmherkunft, Commit oder Paketrevision, Buildoptionen, Bibliotheken, Dienstidentität, Konfiguration und öffentliche URLs. Erfassen Sie Source-Protokolle, Hörerprüfung, Mustervorrang, Relay-Quellen, Fallback-Medien und eigene XSLT-Dateien. Sichern Sie geschützt und bewahren Sie eine funktionierende Binärdatei auf.
NEWS beschreibt Änderungen bis kh22, etwa an Relays und Verbindungsverarbeitung. Das Änderungsprotokoll beweist nicht, dass jede genannte Korrektur in einem unbekannten Paket enthalten ist. Ordnen Sie das konkrete Artefakt dem Quellenstand zu.
Schnittstellen ausdrücklich vergleichen
| Grenze | Vertrag des KH-Standes | Frage für die Migration |
|---|---|---|
| Mount-Regeln | Exakte Namen, Muster und Vorrang | Gewinnt weiterhin die gewünschte Regel? |
| Authentifizierung | Klassische htpasswd-/URL-Optionen | Verweigern Fehler weiterhin die Zulassung? |
| Relays | Lokaler Mount mit mehreren Hostkandidaten | Bleiben Vorrang und Wiederholung erhalten? |
| TLS | Socket-ssl und Zertifikatspfade | Stimmen Buildunterstützung und Zertifikatskette? |
| Administration | Registrierte KH-Befehlsnamen | Verarbeitet Automatisierung die echte Antwort? |
| Dateipfade | KH-Aliasattribut dest | Bleiben öffentliche und private Pfade getrennt? |
Ersetzen Sie KH-Konfiguration nicht vollständig durch XML von regulärem Icecast 2.5. Syntax, Rollen, Upstreams, TLS und Verzeichniseinstellungen unterscheiden sich. Umgekehrt beweist das unveränderte Behalten einer alten XML-Datei nicht, dass ein neuer KH-Build jede Option übernimmt.
Vorbereiten, beobachten und Rückkehr ermöglichen
Bauen Sie einen isolierten Kandidaten mit anderen Ports und Pfaden ohne Verzeichnismeldung auf. Prüfen Sie Source, Hörer, absichtliche Trennung, alle Relay-/Fallback-Wege und verweigerte Anmeldung. Vergleichen Sie Logs und Zählerbedeutungen. Halten Sie für jedes Ergebnis Binärdatei und XML fest.
Planen Sie erst danach ein Wartungsfenster mit passender Rückkehr. Bestehende Verbindungen, Anmeldestatus und externe Clients benötigen ausdrückliche Beobachtung. Der redaktionelle Quellenvergleich der genannten Unterlagen ist erfolgt. Build- und Laufzeitabnahme bleiben eigene Prüfungen und folgen nicht aus diesem Artikel.