Users February 2020

users@lists.freifunk-potsdam.de

7 participants
7 discussions

Wiki: Dateiverwaltung
by Carsten N 08 Mar '20

08 Mar '20

Hallo, ich versuche von dem Bild[0] eine neue Version (Anhang) hochzuladen und bekomme folgende Fehlermeldung. [a49bbb506a5407bac183e675] 2019-05-24 20:23:46: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBQueryError" Normales hochladen funktioniert. Löschen wird mit einem Fehler quittiert aber die Datei scheint dann weg zu sein [ac27adb806715ba9871664b5] 2019-05-24 20:29:12: Fataler Ausnahmefehler des Typs „Wikimedia\Rdbms\DBUnexpectedError" Kann wer helfen? [0] https://wiki.freifunk-potsdam.de/Datei:Rz-infrastruktur.png#filehistory -- Viele Grüße Carsten

2 6

Zertifikate für 254-33-MCBMobil+254-34-MCB
by Leander Neubronner 01 Mar '20

01 Mar '20

Hallo lieber Zertifikateverteiler, Wir bräuchten für unsere neuen Router im Mediencampus Babelsberg (leider kein WLAN, aber wahrscheinlich ein paar Öffentliche FFP-Seiten/Dienste) VPN-Zertifikate. Viele Grüße, Leander Sent from my iPad

2 3

[Berlin-wireless] Nächstes Release / Namenswahl
by Sven Roederer 14 Feb '20

14 Feb '20

Hallo, ich hab mal meine Gedanken dazu unter [1] festgehalten und schlage etwas in Richtung "Freifunk Berlin 2020.02.0" vor. Wenn wir uns darauf einigen, auf den Releasenamen (Kathleen,Hedy, Gonzo) zu verzichten, sparen wir uns aufwendige Umbauten am Code (und die Suche nach Freiwilligen, die das machen wollen). Gleichzeitig gewinnen wir eine schnell erkannbare Sicht, wie alt die Firmwarebasis ist. Die aktuelle Hedy-Serie würde sich dann etwa 2018.02.4 nennen, und deutlich zeigen, wie altbacken alles ist. "Freifunk Berlin" durch etwas wie "Gluon" zu ersetzen ist auch möglich, denn auch die Potsdamer nutzen ja auch unseren Unterbau. Hat jemand eine schöne Idee für einen Namen? GRuss Sven 1 - https://github.com/freifunk-berlin/firmware/issues/747 P.S: die Mail lage schon eine Weile im Entwurfs-ordner, daher der vorschlag für ein "2020.02.0" release. Aber inzwischen ist das unrealistisch. Am 27.06.19 um 19:26 schrieb Sven Roederer: > Malte, > > ich bin mir recht sicher, diesen Vorschlag auch gemacht zu haben. Das > Feedback (keins oder negativ) hat mich die Idee wieder vergessen lassen. > Also von mir wieder ein deutliches JA zu "dartumsbasiertem Releasename". > > Sven > > > Am 27.06.19 um 14:16 schrieb Malte: >> On Thu, 27 Jun 2019, Perry wrote: >> >>>> Wie gesagt wundere ich mich über >>>> * die Änderung des Namensschemas und "Verstoß" gegen das semantische >>>> Versioning >> [...] >>> Natürlich andere konkrete vorschläge sind willkommen. >> >> Semantic Versioning macht überhaupt keinen Sinn für Dinge, die keine klar definierte API haben. SemVer ist für Bibliotheken geeignet und für sonst nicht viel. Schreiben wir die Firmware für >> Programmierer oder für Anwender? Letztere können mit SemVer so oder so nichts anfangen. >> >> Mein Vorschlag: >> >> a) Einen dauerhaften Namen für die Firmware ausdenken und den nicht alle paar Monate ändern, damit die Sache suchbar und klar identifizierbar bleibt. Einen Release-Name ist bestenfalls optional (ich >> würde ihn ganz weglassen. Ist zwar hip, von "Hedy" oder sonstwas zu reden, aber macht die Sache weniger zugänglich für Neulinge). >> >> b) Versionsnummern benutzen, die an das Release-Datum angelehnt sind, wie es so ziemlich alle anderen auch machen. Ansonsten wissen nur Insider, wie alt die jeweilige Firmware ist. >> >> Siehe z.B. >> Ubuntu 18.04 "Bionic" >> Gluon v2018.x >> OpenWrt 18.x >> >> Man kann sich bei den Versionsnummern einfach überlegen, ob man es den Anwendern einfach machen will, oder ob man bei dem ursprünglich von in erster Linie Marketing-Überlegungen angetriebenen alten >> Schema bleiben will. Ich sage nur "Industrie 4.0"... >> >> Grüße, >> Malte >> >> _______________________________________________ >> Berlin mailing list >> Berlin(a)berlin.freifunk.net >> http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin >> Diese Mailingliste besitzt ein �ffentlich einsehbares Archiv >> > > _______________________________________________ > Berlin mailing list > Berlin(a)berlin.freifunk.net > http://lists.berlin.freifunk.net/cgi-bin/mailman/listinfo/berlin > Diese Mailingliste besitzt ein ffentlich einsehbares Archiv >

1 0

Grafana-monitoring und Hedy
by Sven Roederer 14 Feb '20

14 Feb '20

Hallo Potsdam, ich habe durch zufall im Github euer grafana-monitoring gefunden. Da es erstmal sehr ansehlich ist, habe ich euer Package-feed in die Firmware aufgenommen [1]. Das freifunk-potsdam-collect package habe ich mal auf meinen Router geschmissen und bin seither bei euch vertreten [2]. Ich würde das jetzt eine zeit mitlaufen lassen und evtl. ist das ja eine Inspiration für den ersatz von Monitoring-berlin.freifunk.net Gruss Sven 1 - https://github.com/freifunk-berlin/firmware/commit/25f9144a9c2fbce7be9bea1b… 2 - https://monitor.freifunk-potsdam.de/grafana/d/000000008/node-overview?orgId…

1 0

Grafana keine Traffic Daten
by Bernd Nemetz 12 Feb '20

12 Feb '20

Hi, Im Grafana sehe ich keine Traffic Daten mehr. Ist das nur bei mir so, oder kann wer anders das bestätigen? Gruß Bernd

1 0

Hedy für Fritzbox 7412 ?
by Frank Schiersner 11 Feb '20

11 Feb '20

3 2

OLSR-> Linkqualitätseinstellungen -> etx_ffeth
by Johannes Rohr 01 Feb '20

01 Feb '20

Hallo, in der Anleitung zu Kathleen heißt es: / / /LQ algorithm/ /Damit Kabelkopplungen (Mesh über LAN) nicht als ganzer Hop gezählt werden stellen wir auf etx_ffeth um. Dadurch wird sie nur noch als zehntel Hop gerechnet. Ohne diese Einstellung kann dein Router nicht mit den anderen Meshen. / /Unter Services -> OLSRv4 -> Link Quality Settings -> LQ algorithm auf / // /"etx_ffeth" umstellen. / Das habe ich bei meinen Routern überall brav gemacht. Für Hedy <https://wiki.freifunk-potsdam.de/Hedy> findet sich keine solche Anweisung mehr. Wird die Einstellung nicht mehr gebraucht? In jedem Fall muss sie wohl bei allen Routern identisch sein. Johannes

2 1

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Users February 2020