Category Archives: Fedora

Was lange währt…wurde endlich mal fertig \o/

Posted on by

Ihr erinnert Euch an diese Geschichte mit den Kameras des TerraPad?

TerraPad: Fedora mit First Light o/

Was lange währt…wurde endlich mal fertig \o/

Es läuft Kernel 6.14.6 und die Kameras arbeiten beide zuverlässig mit Cheese und „Kamera„. Wo es noch etwas hapert ist Firefox. Der bringt leider nur ein imaginäres Standbild zustande, daß in irgendeinem Puffer enthalten ist. Natürlich gingen die Kameras schon vor Kernel 6.14.6, aber erst mit ca. 6.14.4 werden die Chips auch nach den StandBy wieder aktiviert, so daß man halt immer ein Bild bekommt und nicht nur nach dem physikalischen Einschalten, was echt praktisch ist 😉

Dem Kamerachip fehlt natürlich die richtige Initialisierung z.B. mit dem korrekten Weißabgleich. Das Bild ist etwas grünstichig und braucht auch viel Lichteinfall (der Shutter ist falsch eingestellt) um ein halbwegs ordentliches Bild zu liefern.

Für eine Videokonferenz auf der Sonne wird es reichen, aber Urlaubsfilme sollte man damit noch nicht machen 😉

Bei einem kleinen Testlauf ist die „Kamera“ Anwendung 100% effektiver als Cheese. Letzteres braucht 120% Cpuleistung nur für das Anzeigen des Kamerabildes ohne Videoaufnahme. „Kamera“ dagegen braucht nur 50% eines Kernes, ist also wesentlich effizienter und hat den großen Vorteil die Kameras beliebig oft hin und her schalten zu können, was Cheese leider nur genau einmal schafft 😉

Wenn man jetzt eine Videokonferenz mit dem eigenen Bild beglücken will, muß Cheese laufen und das Vollbildgeteilt werden. Die Latenz dabei hat die Klasse „ähm…geht so“ . Wesentlich komplizierter ist das Mikrosetup, weil das Buildin-Mic auf dem Mainboard mit „bescheiden“ geradezu großzügig tituliert ist. Ein Headset ist Pflicht, soll es vernünftig klingen.

Wer die Irrungen und Wendungen der TerraPad live erleben will, kommt man besten heute Abend mal bei Linux am Dienstag vorbei, wenn in Braunschweig das Wetter mitspielt versteht sich 😉

Default Cinnamon Theme auf bisherige Version zurückstellen

Posted on by

Das zu erklären wir schwieriger, fangen wir mal so an. Seit Fedora 41 hat Cinnamon die Version 6.4.x und vorher war es 6.2.x . u.a. hat sich der Theme geändert, was bedeutet, daß man einen dickeren Font für seine Fenstertitel in der Leiste hat.

Default Cinnamon Theme auf bisherige Version zurückstellen

Hier das Problem mal grafisch dargestellt:

NEU:

ALT:

Es ist einfach der bessere Font und der bessere Kontrast, aber das ist ja nur meine Meinung 😉

Wie bekommt man das wieder?

Zwei Wege, Ihr downgraded das cinnamon Paket, macht Euch eine Kopie von „/usr/share/cinnamon/theme/“ , updated dann wieder und spielt dort Eure Kopie ein, aber das führt früher oder später zu Problemen, weil das nächste Update das wegbüggelt. Ergo, muß eine bessere Lösung her.

Eigenen Theme kopieren

Das „Backup“ das Ihr durch den Downgrade gemacht habt, kopiert Ihr nicht an den oben genannten Ort sondern legt Euch als root diesen Ordner /usr/share/themes/Classic/cinnamon/ an und kopiert das Backup da rein. Schon könnt Ihr den „Classic“ Theme in der Theme Anwendung sehen und auswählen. Alles Zurück auf normal!

Alternativer Weg zum alten Theme

Erstmal ladet Ihr Euch von Koji das alte SRC RPM von Cinnamon 6.2.9 von Fedora 40 runter, dann packen wir es aus: cinnamon-6.2.9-1.fc40.src.rpm

rpm2cpio cinnamon-6.2.9-1.fc40.src.rpm | cpio -idmv
tar xzvf cinnamon-6.2.9.tar.gz
cd cinnamon-6.2.9/cinnamon/
tar c * | tar x -C /usr/share/themes/Classic/cinnamon/

jetzt könnt Ihr die angelegten Verzeichnisse des RPMs wieder löschen, das RPM auch und seid fertig.

Teil 3: Advanced Routing

Posted on by

https://marius.bloggt-in-braunschweig.de/2025/04/26/teil-2-einen-ganzen-server-rsyncen/

Bei Hetzner seine Server hinstellen, ist echt eine Herausforderung für den Admin, da kommen wir ohne Advanced Routing gar nicht hin.

Teil 3: Advanced Routing

Wir haben einen Hotstand-By Server, der muß 2 IPs haben, damit er genau so funktioniert wie der Originalserver. Wenn man jetzt bei Hetzner einen Server mietet oder hinstellt, dann gibt es eine Hürde man braucht für eine VM min. eine Zusatz IP, in dem Fall 2, und die kommen aus dem gleichen Netzwerksegment, haben aber andere MAC-Adressen, weil Hetzner es nicht erlaubt, zwei (oder alle) IPs auf der gleichen MAC zu haben. Die drohen einem glatt mit Sperren, wenn man sich nicht daran hält. Dazu habe ich noch einen bösen Kommentar am Ende für Euch 😉

„Mehr als ein Interface, aber gleiche Netze? WTF??“

Ja, das geht… ist aber nicht so einfach. Erstmal muß man dazu wissen, wie VMs auf einem Host i.d.R. ans Netz angeschlossen werden: per Bridgeinterface.

Das Bridgeinterface ist eine Art virtueller Switch, bei dem das echte Netzwerkinterface des Hosts mit
dem der VM verbunden wird, so daß da Daten langgehen können. Beispiel:

vmbr0		8000.a8a159c0d0c0	no		enp41s0
							fwpr104p0
							fwpr104p1

Die Brücke heißt „vmbr0“ und das echte Interface ist „enp41s0„. Die zwei Interface der VM sind p0 und p1.

In der VM sieht das dann so aus:

# ip l
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default qlen 1000
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: ens18: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:56:00:da:8b brd ff:ff:ff:ff:ff:ff
    altname enp0s18
3: ens19: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc fq_codel state UP mode DEFAULT group default qlen 1000
    link/ether 00:50:56:00:98:bd brd ff:ff:ff:ff:ff:ff
    altname enp0s19

Die IPs sollen mal „1.1.100.4/26“ und „1.1.100.39/26“ sein, beide fiktiv, sonst kommt noch wer auf dumme Ideen 😉

Was wir jetzt brauchen ist eine priorisierte Route für das zweite Interface, weil sonst der Traffic des zweiten Interfaces ens19 durchs erste Interface ens18 geht, aber wegen der „falschen“ MAC, nicht geroutet oder beachtet wird!

Dazu brauchen wir ip_route2

Wer noch kein Verzeichnis hat, legt es einfach an:

mkdir /etc/iproute2
echo 100 if2 > /etc/iproute2/rt_tables

Dann priorisieren wir alles, was von IP2 kommt, über das Interface 2, damit es nicht durch die Defaultroute über Interface 1 geht:

ip rule add from 1.1.100.39 table if2 prio 1
ip route add 1.1.100.0/26 dev ens19 src 1.1.100.39 prio 1
ip route add default via 1.1.100.1 dev ens19 table if2

Dann können wir eine zweite Defaultroute anlegen, was vorher nicht ging. Das sieht dann so aus:

# ip r
default via 1.1.100.1 dev ens18
1.1.100.0/26 dev ens18 proto kernel scope link src 1.1.100.4
1.1.100.0/26 dev ens19 proto kernel scope link src 1.1.100.39
1.1.100.0/26 dev ens19 scope link src 1.1.100.39 metric 1
169.254.0.0/16 dev ens18 scope link metric 1002
169.254.0.0/16 dev ens19 scope link metric 1003

Damit das permanent so bleibt, was es einfach so nicht möchte, kann man es in ein Script schreiben und das nach dem Start des Netzwerkes aufrufen. Wie Ihr das macht, bleibt Euch überlassen.

Der Kommentar

Hetzner legt nicht ganz zu unrecht Wert auf einen MAC Filter und besteht darauf, daß jede IP eine eigene, von denen vorgegebene MAC hat. Das ist nötig, weil Jeder Jeden im Netz sehen kann, so bekam unsere VM da 3,5Mb/s Broadcasttraffic ab, weil andere Leute keinen Plan von Netzwerken haben und wie man die richtig konfiguriert. Natürlich könnten wir auch Macs als Kunden vorgeben und die akzeptieren die, aber das wäre denen zu viel Aufwand, was Schade ist, weil der Beitrag hier dann überflüssig gewesen wäre 😀

Kann Jeder Jeden sehen, kann man dem seine IPs hochfahren und kapern, deswegen der MAC Filter. Wenn man da aber drauf besteht, anstatt die ganzen Server in VLans zu isolieren, so daß das die sich eben nicht mit Fake ARPs beglücken können, dann muß man das auch überwachen und den Verursacher des Datenmülls stoppen. Das haben die Kollegen bei Hetzner erst gemacht, nachdem ich denen mitgeteilt hatte, daß es wohl ein DDOS Angriff sein könnte ( weil es auch so aussah ) 😀 Jetzt sind wir über Ostern bei 400Kb/s, das klingt schon normaler.