Mhm, welcher Provider da wohl Probleme hatte?
2 „Gefällt mir“
Da ich gerade das icvpn-meta Repository gefunden habe, habe ich gerade mal einen Pull Request erstellt um die Rhein-Neckar Daten zu updaten: https://github.com/freifunk/icvpn-meta/pull/603
Wir haben da aktuell zwar keine Verbindung, aber falls das doch noch mal wieder verbunden werden soll ist es sicherlich besser, wenn die Daten halbwegs aktuell sind.
2 „Gefällt mir“
Der sync zwischen den authoritativen Nameservern (ns1.ffrn.de, ns2.ffrn.de und ns3.ffrn.de) wird nun per TSIG authentifiziert.
Seit heute Nacht setzen wir nun knot-resolver auf resolver1.ffrn.de und resolver2.ffrn.de ein. (Ein Resolver wird auch gerne allgemein „DNS Server“ genannt).
Bisher war es so, das der per DHCP verteilte „v4-resolver“ ein bind auf jedem der Gateways war. Die per Router Advertisement (IPv6) verteilen Resolver waren auch vorher schon resolver{1…2}.ffrn.de.
Da IPv6 sowieso bevorzugt wird sollte das eigentlich, bis auf die ganz paar Geräte die kein IPv6 können (wobei man mit denen vermutlich eh nicht in einem öffentlichen WLAN unterwegs sein sollte (da veraltet)), keinen Unterschied machen.
Die hauptsächliche Neuerung ist das wir nun DNSSEC überall strikt prüfen. Das bedeutet, das wenn der Eintrag nicht passt die resolver keine IP zurückliefern. Das ist aber nur relevant, wenn es einen DNSSEC Eintrag für die Domain gibt.
Beobachten kann man das ganz aktuell (wie @JevermeisteR festgestellt hat) auf cve.mitre.org. (Edit: Der Fehler wurde nun wohl behoben,)
1 „Gefällt mir“
Nachdem chat.ffrn.de nicht mehr funktionierte stellte sich heraus, dass das mit der Umstellung auf direkte nftables Regeln (Debian 10 schreibt in der Standardeinstellung alle iptables Regeln zu nftables Regeln um) auf dem Host tools-itter.ffrn.de zu tun hatte. Beim Starten des RocketChat Docker Containers mittels docker-compose up -d bekam man einen wie folgend aussehenden Fehler:
ERROR: for rocketchat Cannot start service rocketchat: driver failed programming external connectivity on endpoint rocketchat_rocketchat_1 (xxxxxxxxxxxxxxxxxxxxxxxxxxxxx): (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 127.0.0.1 --dport 3002 -j DNAT --to-destination 172.18.0.2:3000 ! -i br-4905ae49b518: iptables v1.8.2 (nf_tables): Chain 'DOCKER' does not exist
Es stellte sich heraus, das ein systemctl restart docker hier Abhilfe schaffen konnte.
1 „Gefällt mir“
Früher wurde collectd im Zusammenhang mit Graphite genutzt um ein paar Metriken zu sammeln. Doch da der Graphite Server nicht mehr verfügbar war führte das dazu das die Server beispielsweise bei Reboots erst in einen 90 Sekunden Timeout laufen mussten.
Nachdem ich auf den VM Hosts und den Gateways den Service neulich bereits deaktiviert und gestoppt hatte, habe ich nun gestern festgestellt gehabt, das auf v6upstream.ffrn.de dieser noch lief und sämtlichen RAM gefressen hatte.
Daher habe ich mittels salt '*' service.status collectd.service geprüft ob der sonst noch irgendwo läuft. Und wie sich herrausstellte lief er auch noch auf map.ffrn.de. Dort wurde er also in beiden VMs deaktiviert und gestoppt.
Leider ist v6upstream bisher nicht im Monitoring was Server Ressourcen angeht. Das werde ich nachholen. So kann ich leider nicht sagen wie lange da bereits aller RAM belegt war. Mein Eindruck war, das es keine grundsätzlichen Probleme mit IPv6 gegeben haben dürfte. Aber das ist nicht belegbar und es hat keine entsprechenden Tests gegeben.
Salt States
Inzwischen habe ich unsere Salt States mal veröffentlicht. Was da nicht enthalten ist, sind die Pillars. Das ist ein privates Repository in welchem die Konfigurationsdaten gespeichert sind. Dort stehen dann zum Beispiel die Passwörter drin. Oder aber auch die jeweiligen Werte für einzelne Konfigurationsoptionen auf den unterschiedlichen Systemen.
Das ist aber noch stark in Arbeit. Nicht enthalten sind da also zum Beispiel die Gateway Konfigurationen.
map.ffrn.de
Ich habe hier die neueste Version des Meshviewers ausgerollt (über Salt)
Firmware
Ich habe eine neue nightly auf Basis von Gluon 2020.1.3 hochgeladen.
Bei stable sind wir aktuell ja noch bei 2019.1.2. Das wird sich auch nicht unmittelbar ändern, da der aktuelle Plan nicht vorsieht Tiny Geräte (also hauptsächlich Geräte mit 4 MB RAM und 32 MB Flash - beispielsweise die „beliebten“ TP-Link 841) auf Gluon 2020 zu updaten, da sie damit nicht gut laufen. Das wird sich aufgrund der Hardware Limitierungen wohl auch nicht ändern.
Daher ist der aktuelle „Plan“ Multidomain unter Gluon 2019 einzuführen und dann die „ordentlichen“ 
Geräte auf Gluon 2020 zu updaten.
Gluon 2019 wird wohl auch noch etwas Pflege (Updats) erhalten, da vor der Problematik mit den tiny Geräten einige stehen.
Der Unterschied zwischen Gluon 2019 und 2020 ist übrigens hauptsächlich die neuere OpenWrt Version bei 2020.
Ich würde also definitiv davon abraten neue Tiny Geräte zu kaufen und sich mal darüber Gedanken zu machen, wenn man noch ein solches Gerät einsetzt), eventuell auf ein „zeitgemäßes“ Modell zu updaten.
3 „Gefällt mir“
Es gab hier im Forum ein Problem das E-Mails nicht verschickt wurden und Push Benachrichtigungen gingen auch nicht raus. Sollte nun behoben sein. Hatte mit Änderungen in der Firewall zu tun. Da war Forwarding nicht richtig erlaubt.
1 „Gefällt mir“
Weiterhin gibt es ab heute für unseren Blog unter https://blog.ffrn.de eine Kommentarfunktion. Es werden automatisch Themen im Forum für jeden Blogeintrag erstellt. Das gilt auch für ältere Blogposts.
3 „Gefällt mir“
Ich habe gerade alle FFRN Systeme rebootet. Gab für Debian Kernel Updates.
Auf stats.ffrn.de kann man ganz schön sehen wie die Nodes dabei von Gateway zu Gateway wechseln mussten:
2 „Gefällt mir“
Ich plane übrigens aktuell die Abschaltung von chat.ffrn.de. Sobald es soweit ist wird es aber nochmal eine größere Nachricht geben. Wirklich genutzt wird das meines Wissens aber eh nicht.
Wir Admins nutzen aktuell Matrix für unsere Kommunikation. Und es wurden auch schon mal öffentliche Räume eingerichtet:
- #ffrn:ffrn.de (Allgemein)
- #technik:ffrn.de (Technik)
Wie das alles ganz genau aussehen soll ist auch noch nicht klar. Und auch ob Matrix wirklich die Antwort auf die Frage ist wie wir leichtgewichtigere Kommunikation innerhalb der Community ermöglichen können ist nicht geklärt.
Dazu gehört auch ob wir öffentliche Accounts bereitstellen wollenn, können, … Da gibt es noch viele ungeklärte Fragen.
Aber wer einen Matrix Account hat kann ja mal joinen.
Noch ein Kommentar zu Matrix Accounts:
Ich persönlich würde eher von matrix.org abraten. Einerseits aus ideologischer Sicht, da es sich nun mal um eine sehr zentrale Instanz handelt, andererseits aber auch, da es (wenigstens in letzter Zeit) nicht ganz so stabil zu funktionieren scheint. Aber eine direkte Empfehlung (außer selber hosten), habe ich aktuell leider auch nicht. Ich habe nur beim kurzen Googlen gerade diese Liste mit öffentlichen Matrix Servern gefunden. Aber ob da wirklich eine ordentliche Alternative dabei ist weiß ich auch nicht.
Über die in der security.txt hinterlegte E-Mail Addresse hat sich Gaurav Popalghat (LinkedIn Profil) bei uns gemeldet und darauf hingewiesen, das wir bisher sehr großzügig mit einigen Versionsinformationen der verwendeten Software waren.
Während ich nicht viel von „Security through Obscouruty“ halte, so mag es eben vielleicht doch helfen, da bei einer neu bekanntgewordenen Sicherheitslücke ein Angreifer (bei beschränkten Ressourcen) sich vielleicht erst auf die Ziele konzentriert welche in Versionsdatenbanken mit der betroffenen Version gelistet sind. Das ist aber natürlich (falls überhaupt) nur ein minimaler zeitlicher Vorteil.
Da uns jedocch aktuell keine Nachteile bekannt sind (also zum Beispiel Software welche die Versionsinformation dafür braucht um zu entscheiden ob ein Workarround angewendet werden muss oder nicht), habe ich die Infos für ssh, knot (autoritativer nameserver) und nginx (Webserver) mal etwas eingeschränkt.
Heute in der Früh (03:00 - 03:45) habe ich altneckar.ffrn.de (Wiki) auf Debian 10 geupdatet (von Debian 9). Es war eine sehr kurzfristige Entscheidung, daher gab es keine Ankündigung.
Die Auswirkungen sollten sich um die Uhrzeit aber auch in Grenzen gehalten haben. Dieses Forum, die Karte, resolver1, gw05, gw06 und gw08 waren währenddessen nicht erreichbar. Das Netz als solches sollte aber nicht wirklich beeinträchtigt gewesen sein.
2 „Gefällt mir“
Nun ist der letzte verbleibende Host dran. Dadurch wird es zu Einschränkungen bei IPv6 kommen.
Okay, auch auf elsenz.ffrn.de (Wiki) läuft nun Debian 10.
2 „Gefällt mir“
Heute Nachmittag um 17:06 ist die Netzwerkverbindung auf altneckar.ffrn.de abgebrochen und das Teil war nicht mehr erreichbar. Um 18:02 habe ich einen manuellen Reset des Servers bei Hetzner beauftragt (manuell damit ein Techniker mal vor dem Neustart schaut ob da was auffälliges steht). Um 18:32 wurde der Reset dann durchgeführt und ich habe dann um 19:00 die VMs die dort laufen gestartet.
Ursache dürfte vermutlich ein Treiber/Firmware Problem mit der Netzwerkkarte zu sein. 
Mal schauen ob und wie man das beheben kann.
Jun 17 15:56:25 altneckar kernel: [130799.804952] e1000e 0000:00:1f.6 eth0: Detected Hardware Unit Hang:
Jun 17 15:56:25 altneckar kernel: [130799.804952] TDH <ad>
Jun 17 15:56:25 altneckar kernel: [130799.804952] TDT <9b>
Jun 17 15:56:25 altneckar kernel: [130799.804952] next_to_use <9b>
Jun 17 15:56:25 altneckar kernel: [130799.804952] next_to_clean <ad>
Jun 17 15:56:25 altneckar kernel: [130799.804952] buffer_info[next_to_clean]:
Jun 17 15:56:25 altneckar kernel: [130799.804952] time_stamp <101f1cc3d>
Jun 17 15:56:25 altneckar kernel: [130799.804952] next_to_watch <ae>
Jun 17 15:56:25 altneckar kernel: [130799.804952] jiffies <101f1d030>
Jun 17 15:56:25 altneckar kernel: [130799.804952] next_to_watch.status <0>
Jun 17 15:56:25 altneckar kernel: [130799.804952] MAC Status <80083>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PHY Status <796d>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PHY 1000BASE-T Status <7800>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PHY Extended Status <3000>
Jun 17 15:56:25 altneckar kernel: [130799.804952] PCI Status <10>
Jun 17 15:56:26 altneckar kernel: [130800.892485] e1000e 0000:00:1f.6 eth0: Reset adapter unexpectedly
Jun 17 15:56:26 altneckar kernel: [130800.893533] br-mesh: port 1(eth0.4042) entered disabled state
Jun 17 15:56:30 altneckar kernel: [130804.255231] e1000e: eth0 NIC Link is Up 1000 Mbps Full Duplex, Flow Control: Rx/Tx
Entsprechende Einträge im Log habe ich auch auf elsenz.ffrn.de gefunden. „Normalerweise“ scheint sich das wieder zu fangen, aber ich vermute das hat dann heute Nachmittag nicht geklappt.
1 „Gefällt mir“
altneckar.ffrn.de ist schon wieder ab etwa 07:19 nicht mehr erreichbar gewesen.
Ich hatte gestern, kurz nach den letzten Post, mal testweise einen neueren Kernel installiert, aber das hat dann wohl nichts gebracht. Schade
root@altneckar ~ # uname -a
Linux altneckar 4.19.0-9-amd64 #1 SMP Debian 4.19.118-2+deb10u1 (2020-06-07) x86_64 GNU/Linux
root@altneckar ~ # apt install linux-image-5.5.0-0.bpo.2-amd64 linux-headers-5.5.0-0.bpo.2-amd64
root@altneckar ~ # reboot now
W: molly-guard: SSH session detected!
Please type in hostname of the machine to reboot: altneckar
root@altneckar ~ # uname -a
Linux altneckar 5.5.0-0.bpo.2-amd64 #1 SMP Debian 5.5.17-1~bpo10+1 (2020-04-23) x86_64 GNU/Linux
2 „Gefällt mir“
So sieht es übrigens aus wenn Updates für die Server verfügbar sind:
root@master ~ # salt '*' pkg.list_upgrades
gw02.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
resolver2.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
tools-itter.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
gw04.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
meet.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
git.ffrn.de:
----------
itter.ffrn.de:
----------
libavcodec58:
7:4.1.6-1~deb10u1
libavfilter7:
7:4.1.6-1~deb10u1
libavformat58:
7:4.1.6-1~deb10u1
libavutil56:
7:4.1.6-1~deb10u1
libpostproc55:
7:4.1.6-1~deb10u1
libruby2.5:
2.5.5-3+deb10u2
libswresample3:
7:4.1.6-1~deb10u1
libswscale5:
7:4.1.6-1~deb10u1
ruby2.5:
2.5.5-3+deb10u2
stats.ffrn.de:
----------
forum.ffrn.de:
----------
v6upstream.ffrn.de:
----------
gw03.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
gw09.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
tools-elsenz.ffrn.de:
----------
altneckar.ffrn.de:
----------
libavcodec58:
7:4.1.6-1~deb10u1
libavfilter7:
7:4.1.6-1~deb10u1
libavformat58:
7:4.1.6-1~deb10u1
libavutil56:
7:4.1.6-1~deb10u1
libpostproc55:
7:4.1.6-1~deb10u1
libruby2.5:
2.5.5-3+deb10u2
libswresample3:
7:4.1.6-1~deb10u1
libswscale5:
7:4.1.6-1~deb10u1
ruby2.5:
2.5.5-3+deb10u2
elsenz.ffrn.de:
----------
libavcodec58:
7:4.1.6-1~deb10u1
libavfilter7:
7:4.1.6-1~deb10u1
libavformat58:
7:4.1.6-1~deb10u1
libavutil56:
libavutil56:
7:4.1.6-1~deb10u1
libpostproc55:
7:4.1.6-1~deb10u1
libruby2.5:
2.5.5-3+deb10u2
libswresample3:
7:4.1.6-1~deb10u1
libswscale5:
7:4.1.6-1~deb10u1
ruby2.5:
2.5.5-3+deb10u2
unifi.ffrn.de:
----------
tickets.ffrn.de:
----------
gw06.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
gw05.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
resolver1.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
map.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
gw08.ffrn.de:
----------
libruby2.5:
2.5.5-3+deb10u2
ruby2.5:
2.5.5-3+deb10u2
Und man kann die dann so einspielen:
root@master ~ # salt '*' pkg.upgrade
stats.ffrn.de:
----------
v6upstream.ffrn.de:
----------
gw02.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
forum.ffrn.de:
----------
git.ffrn.de:
----------
tickets.ffrn.de:
----------
tools-itter.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
resolver2.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
tools-elsenz.ffrn.de:
----------
gw04.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
meet.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
unifi.ffrn.de:
----------
itter.ffrn.de:
----------
libavcodec58:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libavfilter7:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libavformat58:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libavutil56:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libpostproc55:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
libswresample3:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libswscale5:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
gw03.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
gw09.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
elsenz.ffrn.de:
----------
libavcodec58:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libavfilter7:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libavformat58:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libavutil56:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libpostproc55:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
libswresample3:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libswscale5:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
gw05.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
map.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
gw06.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
resolver1.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
gw08.ffrn.de:
----------
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
altneckar.ffrn.de:
----------
libavcodec58:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libavfilter7:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libavformat58:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libavutil56:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libpostproc55:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
libswresample3:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
libswscale5:
----------
new:
7:4.1.6-1~deb10u1
old:
7:4.1.4-1~deb10u1
ruby2.5:
----------
new:
2.5.5-3+deb10u2
old:
2.5.5-3+deb10u1
Wir haben nun innerhalb der letzten 36 Stunden 4 Abuse Mitteliungen wegen P2P erhalten. Das ist zu viel. Das verursacht jedes mal Arbeit und wenn das weiterhin überhand nimmt, wird Hetzner (unser Hoster), vermutlich auch irgendwann mit mehr als einem Formular für eine Stellungsnahme (welche innerhalb einer immer kürzer werdenden Frist beantwortet werden muss) reagieren. Klärt die Leute bitte auf das es auch legale, günstige Angebote gibt und sie kein P2P für illegale Aktivitäten verwenden sollen.
Das komisch ist ja auch, das es bei diesen 4 Abuse Mitteilugen nur um 3 verschiedene Filme geht. Und alle sind auf Netflix (um jetzt mal die bekannteste Firma zu nennen) verfügbar.
So kann das nicht weitergehen.
Es steht mit der nightly 1.5.x-20200720 nun der erste Build auf Basis des gestern veröffentlichten Gluon 2020.2 zur Verfügung.
Ich habe owe dann mal aktiviert und man kann das mal testen. Bei Freifunk Darmstadt gibt es einen Blogpost der genauer erklärt was es mit OWE auf sich hat. Als SSID habe ich erstmal owe.freifunk-rhein-neckar.de gewählt.
Da unsere stable ja noch auf Gluon 2019 basiert habe ich da auch mal eine 1.3.2-20200720 unter Verwendung von Gluon 2019.1.x bauen lassen. Da gibt es keine wirklich große Änderungen, aber es wurden nochmal ein paar Abhängigkeiten aktualisiert. Diese Firmware (oder eine ähnliche) wird vermutlich die Tage als experimental veröffentlicht werden (und sich dann langsam in Richtung Stable bewegen).
2 „Gefällt mir“