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

Armutszeugnis: DNS bei Alfahosting 2023 und wie man doch IPv6 nutzen kann

Kürzlich erneuerte ich die Internetpräsenz für einen Sportverein. Nach erfolgtem Update wollte ich das Paket durch Aktivierung von IPv6 abrunden. Dies scheiterte in den letzten Jahren jedoch immer daran, dass die Domains des Vereins bei Alfahosting als Teil eines Web- und Mailhostings für 3,99€ im Monat gebucht sind, Alfahosting in seinen DNS-Einstellungen jedoch keine Quad-A-Records (AAAA-Records) unterstützt.

IPv6 als 1998 standardisiertes Protokoll ist 25 Jahre später noch immer nicht ganz angekommen. Zumindest in meiner Heimatstadt, aus der auch Alfahosting stammt?

Ganz so leicht wollte ich hier nicht aufgeben. Folgend zeige ich meine drei Versuche, IPv6 mit einer bei Alfahosting registrierten Domain zu unterstützen.

Armutszeugnis: DNS bei Alfahosting 2023 und wie man doch IPv6 nutzen kann 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.

Segfaults in imapproxy durch falsche/fehlende Konfiguration

In den letzten Tagen hatte ich ein bisschen mit imapproxy zu tun. Im Original von den SquirrelMail-Entwicklern entwickelt, stellt imapproxy eine Art Proxy für das Handling von IMAP-Verbindungen zum jeweiligen IMAP-Backend bereit. So muss die Webanwendung, welche nicht in der Lage ist, Verbindungen lange geöffnet zu halten, nicht immer wieder Netzwerkumläufe anstellen, die je nach Situation viel Zeit kosten können. Eine Art persistente Verbindung für IMAP.

imapproxy ist genau so alte und zurückgelassene Software wie SquirrelMail selbst. Das Interface alt, die Codebase veraltet, letzte Aktualisierung der Gnade Ende 2021 um PHP 8-Kompatibilität herzustellen.

Derzeit erhält man imapproxy noch in den Debian- und Ubuntu-Repositories und der Code ist unter salsa.debian.org zu erhalten. Die offizielle imapproxy.org-Seite ist nicht mehr erreichbar.

Bei der Erstellung einer Minimalkonfiguration ist mir direkt aufgefallen, dass es für die Konfiguration praktisch kein Errorhandling gibt. Das heißt, dass bei fehlenden, nicht-optionalen Optionen imapproxy generell einfach mit SIGSEGV aussteigt. Debugging-Tool der Wahl ist hierbei dann strace.

Daraufhin erarbeitete ich mir eine passende Minimalkonfiguration, ein Teilnehmer der Dovecot-Mailingliste empfahl ebenfalls eine solche:

Segfaults in imapproxy durch falsche/fehlende Konfiguration weiterlesen

Funktionierende Lösung zur Installation von Ubuntu 22.04 über iPXE mit cloud-init, subiquity, auto-install, curtin

Ich entschuldige mich vorab für den folgenden polemischen Beitrag. Aber was Canonical da abgeliefert hat ist ehrlichgesagt eine einzige Katastrophe. Seit 22.04 gibt es den Legacy-Debian-Installer nicht mehr, welcher bei 20.04 noch verfügbar war. Möchte man sauber Hosts über PXE komissionieren, ist bei Ubuntu nun cloud-init, subiquity, auto-install oder wie auch immer sie den Unsinn nennen, angesagt. Hauptsache die Buzzword-Quote stimmt, Funktionalität ist nunmehr nebensächlich. „Cloud-init is the industry standard multi-distribution method for cross-platform cloud instance initialization“…

Die neue YAML-Syntax sollte Verbesserungen bringen, aber das Chaos ist dadurch nur noch größer. root-User lassen sich im „identity“ Dictionary nicht anlegen, automatische Updates im Installationsprozess lassen sich nur mit einem Hack abstellen, die Referenzierung auf user-data und user-meta Files ist völlig undurchdacht, die YAML-Files erfordern nicht-YAML-konforme Syntax um zu funktionieren (wer hat sich die bescheuerte Erfordernis von „#cloud-config“ in der ersten Zeile der user-data YAML ausgedacht?), der Installationsprozess wird ewig in die Länge gezogen, ISO-Images sind zusätzlich zum Kernel und der Initramdisk nun auch bei Installation nötig und als wäre das nicht genug, werden diese in der Standardkonfiguration auch noch doppelt geladen (2×1,3GB) sodass eine Installation mindestens 3GB RAM erfordert, mit Hack dann 2GB. Schöne neue Welt.

Funktionierende Lösung zur Installation von Ubuntu 22.04 über iPXE mit cloud-init, subiquity, auto-install, curtin weiterlesen