Monthly Archives: Februar 2020

Container und IPv6 – Basics zum Verständnis / Netzwerkzuschnitt

Posted on by

In diesem Beitrag erläutere ich erst einmal die grundlegenden Probleme welche sich beim Einsatz von Container-Lösungen im Netzwerk ergeben und wie man sie sinnvoller Weise technisch lösen kann. Schlüssel hierfür ist die Verwendung von IPv6 anstelle von IPv4. In einem weiteren Artikel beschreibe ich dann die konkrete Umsetzung. Wer sich mit IPv6 und Containern bereits sicher fühlt kann diesen Artikel ggf. überspringen.

Container sind der aktuelle Stand der Technik was die Auslieferung und die Laufzeitumgebung für Serversoftware betrifft. Die Para-Virtualisierung löst einige Probleme die man typischer Weise hatte, unter anderem das Alles-oder-Nichts-Problem, wenn es darum geht Systemsoftware zu aktualisieren. Mit jedem größeren Versionssprung gibt es die Gefahr, dass bestimmte Teile des eigenen Codes nicht mehr laufen. Aktuell gibt es immer noch genügend Projekte und Software welche auf ältere (um nicht zu sagen teilweise uralte) Versionen von PHP angewiesen sind um zu funktionieren. Mit dem Versionssprung von 5.x nach 7.0 sind einige Altlasten und Funktionen über Bord geworfen worden, unter anderem auch der gesamte Stack für die MySQL-Anbindung, was einigen Anwendungen dann doch das Genick bricht. Häufig stand man nun vor dem Problem, für einen Teil des gehosteten Angebots die Version anheben zu wollen, aber die Altlasten müsste man dafür erst einmal auf Stand bringen. Das ist nicht immer ohne weiteres möglich. Mit Containern schafft man sich hier ggf. kleinere Services mit jeweils ihrer maßgeschneiderten Umgebung – inklusive abgeschottetem Datenbankserver, den sich nicht mehr alle Angebote teilen müssen (über die Vor- und Nachteile von Datenbanken in Containern kann man einen eigenen Artikel schreiben).

Continue reading →

Rasperry Pi 3B+ mit Samsung LE22S86BD

Posted on by

Bereits seit einiger Zeit habe ich einen Rasperry Pi, nachdem ich bereits einiges damit herumgespielt hatte soll er nun endlich seinen Stammplatz als Medienzuspieler am Fernseher bekommen, damit man nicht jedesmal einen Laptop anschließen muss, nur um einen Stream zu schauen. Zumal ich ja sagen muss, dass das aktuelle Fernsehprogramm mich ohnehin nicht vom Hocker haut und bei meiner ganzen sportlichen Aktivität bleibt mit selten die Zeit zum Fernsehschauen.

Auch daher muss es erst einmal der aktuell vorhandene Fernseher tun, ein etwas älteres Modell von Samsung, Modell LE22S86BD. Die Einrichtung des Raspi habe ich natürlich am Monitor mit samt Tastatur, Maus und Netzwerk durchgeführt und nicht am Fernseher. Das Ergebnis ist dann leider auch gar nicht Plug&Play sondern eher fühlt man sich in die Zeiten des „Plug&Pray“ zurück versetzt. Denn nach dem Anschluss per HDMI sieht man nahezu nichts, genauer gesagt nur eine Fehlermeldung auf dem LCD-TV „Mode not supported“. Da kommen bei mir prompt Erinnerungen an die ersten Gehversuche mit Xfree86 als Grafikserver – damals musste man auch mit viel Trial&Error die richtigen Einstellungen für Grafikkarte und Monitor herausfinden. Wenn man das übertrieben hat, konnte man mit den Versuchen sogar durchaus Geräte dauerhaft unbrauchbar machen.

Mit folgenden Einstellungen in der „/boot/config.txt“ bekommt man bei diesem Fernseher ein formatfüllendes Bild ohne Trauerränder hin:

hdmi_group=1 # CEA => TV-modes
hdmi_mode=5 # 1080i, 60Hz 
disable_overscan=1 # TV does not support overscan

Das ist die einzige Kombination die ich zuverlässig ans Laufen bekommen habe, auch wenn „tvservice“ durchaus andere modi meldet:


pi@raspberrypi:~ $ tvservice -m DMT
Group DMT has 5 modes:
mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
mode 35: 1280x1024 @ 60Hz 5:4, clock:108MHz progressive
mode 57: 1680x1050 @ 60Hz 16:10, clock:119MHz progressive



pi@raspberrypi:~ $ tvservice -m CEA
Group CEA has 9 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
(native) mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
(prefer) mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced
pi@raspberrypi:~ $

Falls also irgendjemand noch diese Kombination betreiben will, ich hoffe ich erspare ihm hiermit eine ziemlich mühsame Ausprobiererei – Kommentare und weiter funktionierende Modi sind natürlich herzlich willkommen.