Archiv der Kategorie: Linux

nginx-rtmp mit Standby-Bild wenn kein Publisher verbunden ist

Im Beitrag „Lokal von OBS zu OBS streamen mittels nginx-basiertem RTMP-Server“ zeigte ich, wie man zwischen OBS-Instanzen in einem Netzwerk streamen kann. Das ursprüngliche Streaming-Projekt ist längst abgeschlossen, jedoch bin ich retrospektiv nochmal alle Verbesserungsvorschläge und -möglichkeiten durchgegangen.

Hierbei wurde auch klar, dass ein direkter Stream über eine teils instabile Verbindung insbesondere beim Streaming zu YouTube nicht unproblematisch ist. Um beim Streaming zu YouTube zu vermeiden, dass der Stream entgültig und unwiederbringlich beendet wird (beispielsweise passiert das durch Beendigung des Streams in OBS oder bei einem Verbindungsabbruch, wenn der Stream nicht innerhalb kurzer Zeit wieder gestartet wird) empfiehlt es sich, einen Streaming-Proxy zu verwenden.

nginx-rtmp mit Standby-Bild wenn kein Publisher verbunden ist weiterlesen

HAProxy 2.2 – 2.8 unter SLES 10 (SuSE Linux Enterprise Server 10) kompilieren

Im letzten Artikel „HAProxy 2.0/2.1 unter SLES 10 (SuSE Linux Enterprise Server 10) kompilieren“ habe ich gezeigt, wie es möglich ist, HAProxy 2.0 und 2.1 unter SLES 10 zu kompilieren. Da der Support für 2.1 bereits ausgelaufen ist und für 2.0 (LTS) in Q2 2024 ausläuft, erscheint es interessant, auch neuere Versionen für einen alten Linux-Stack zu kompilieren.

HAProxy 2.2 – 2.8 unter SLES 10 (SuSE Linux Enterprise Server 10) kompilieren weiterlesen

HAProxy 2.0/2.1 unter SLES 10 (SuSE Linux Enterprise Server 10) kompilieren

Manchmal ergeben sich im IT-Umfeld merkwürdige Aufgaben – beispielsweise wenn eine Anwendung, die selbst erheblich neuer ist, als das Betriebssystem auf dem sie kompiliert und installiert werden soll, unter einem entsprechenden System lauffähig gemacht werden soll.

Wie kann nun vorgegangen werden, um einen relativ aktuellen HAProxy auf SLES 10 zu kompilieren und zu installieren?

HAProxy 2.0/2.1 unter SLES 10 (SuSE Linux Enterprise Server 10) kompilieren weiterlesen

Lokal von OBS zu OBS streamen mittels nginx-basiertem RTMP-Server

Vor kurzem hatte ich das Vergnügen/den Auftrag, mich mit Medienstreams, RTMP und OBS zu befassen. Grundkenntnisse in ffmpeg und Medienkonvertierung hatte ich bereits in meiner Laufbahn erworben.

Ziel war, Medienstreaming von einem Publisher zu einem RTMP-Server einzurichten um den Stream dort wiederum von einem Client abzurufen und in einen Livestream welcher zu YouTube gestreamt wird, einzufügen.

Anfangs stand der Gedanke, zwei Videoquellen mittels ffmpeg unter Windows abzugreifen und per RTMP zum Server zu streamen. Nachdem sich jedoch technische Schwierigkeiten bei der Ansprache der Videoquellen ergaben, insbesondere aufgrund der schwer zu realisierenden Hardwarecodierung mit ffmpeg unter Windows und AMD Vega 11 GPUs (eigentlich APUs), wechselte ich zunächst zu OBS unter Windows und schickte den Stream damit an den RTMP-Server.

Lokal von OBS zu OBS streamen mittels nginx-basiertem RTMP-Server weiterlesen

Datenwiederherstellung von defekten Speichermedien mittels ddrescue und photorec

Kürzlich kam ich in die Verlegenheit, eine 15 Jahre alte Festplatte mit einer Gesamtlaufzeit von fast 70.000 Stunden, die schon seit langem zahlreiche defekte Sektoren und somit Lesefehler aufwies, einer größer angelegten Wiederherstellungsaktion zu unterziehen.

Beim Typ der Festplatte handelte es sich um eine SAMSUNG HD501LJ, ein zeitgenössisches Festplattenmodell wie es in zahlreichen Systemen dieser Zeit zum Einsatz kam und welches in den darauffolgenden Jahren erst durch 750GB- und 1TB-Modelle ersetzt wurde, bevor die Festplatten-Sparte von SAMSUNG dann 2011 teilweise von Seagate übernommen wurde.

Die Aufgabenstellung war in diesem Fall nicht ganz einfach, denn es sollten:

  • möglichst viele Daten gesichert (gelesen) werden
  • Bestandsdaten auf den Dateisystemen verfügbar gemacht werden
  • bereits lange in der Vergangenheit gelöschte Daten gefunden und verfügbar gemacht werden
  • sofern möglich, die Daten auf ein neues gleichgroßes oder größeres Speichermedium geschrieben werden, um das ursprüngliche System wieder zu starten
Datenwiederherstellung von defekten Speichermedien mittels ddrescue und photorec weiterlesen

Nextcloud: Der HTTP-Header „X-Frame-Options“ ist nicht als „SAMEORIGIN“ konfiguriert (obwohl er konfiguriert ist)

Eine interessante Anekdote aus meiner Arbeit mit Nextcloud. Im Backend wird ein „Sicherheits- und Konfigurationscheck“ angeboten, der einige Tipps und Empfehlungen für die Nextcloud-Serverinstanz vorschlägt.

Nachdem ich alle aufgeführten Aufgaben erledigt hatte, blieb eine bestehen:

Der HTTP-Header „X-Frame-Options“ ist nicht als „SAMEORIGIN“ konfiguriert. Dies stellt ein potenzielles Sicherheits- oder Datenschutzrisiko dar, und wir empfehlen, diese Einstellung zu ändern.

NEXTCLOUD ADMIN BACKEND -> OVERVIEW

Da dies eine einfache Überprüfung ist, habe ich die Entwicklerkonsole meines Browsers geöffnet und überprüft, ob der Header gesetzt war. Und das war er. Seltsam? Zu diesem Zeitpunkt war ich mir ziemlich sicher, dass etwas mit der Erkennung dieses Headers nicht stimmte, aber ich konnte nicht sofort erkennen wo und wie genau.

Nachdem ich im Internet recherchiert und mindestens eine Stunde lang damit herumgespielt hatte, entschied ich mich, den Sicherheitsscanner scan.nextcloud.com zu verwenden, um sicherzustellen, dass die Warnung auch dort angezeigt wird. Jetzt kommt der lustige Teil: Der Scanner zeigte die Warnung ebenfalls an, allerdings mit zwischengespeicherten Daten vom letzten Jahr. Nach einem erneuten Scan und einem A+ auf dem Scanresultat, verschwand die Warnung auch im Nextcloud-Backend.

Wahrscheinlich stützt sich die Nextcloud-Backend-Prüfung auf denselben Datensatz, den scan.nextcloud.com verwendet, und indem ich die Sicherheitsprüfung auf scan.nextcloud.com manuell wiederholte, verschwand die Warnung. Es ist nicht nötig, an irgendwelchen Webserver-Konfigurationen herumzufummeln, da Nextcloud in allen neueren Versionen den X-Frame-Options-Header von sich aus korrekt setzt.