freifunkbremen / gluon-site-ffhb Goto Github PK

Auf dem Freifunk Bremen Treffen 17.02.2107 haben wir (@genofire, @timlukas, @Yannoik und @corny), zusätzlich zu dem Standardzustand von Mesh-VPN und bandwidth_limit, auch neue egress und ìngress Werte für bandwidth_limit besprochen.

Final hatten wir uns für die folgenden Werte entschieden:

egress = 2000,
ingress = 14000,

Diese Werte haben wir aufgrund der typischen, schmalen Internetverbindung an der man Freifunk evtl. drosseln will entschieden: 16.000. 8.000 ist zu schmal, als das Drosseln Sinn ergibt.
Für 16.000 sind 1.000 (Vodafone, 1und1) oder 2.000 (T-Kom, o2) typische Uploadraten. Idee war, einen kleinen Anteil zwischen 10% und 20% für das private Netzwerk zu reservieren. Für down fiel die Wahl auf 14.000, für up auf 2.000.
Mir ist aufgefallen, dass der zweite Wert nicht ansatzweise Sinn ergibt, da dann genau gar nichts reserviert wäre.

Also stelle ich die Werte hier noch mal zur Diskussion.
Schlagt Werte zwischen 80% und 90% vor und, ob wir uns an 1.000 oder 2.000 orientieren sollen:

Es gibt im Moment den "stable"-Branch (921a16a; davon wurde die letzte stable-Firmware gebaut: v2015.1.2+bremen2); und es gibt den "master"-Branch (57e582d), auf dem einige aktuelle Config-Änderungen liegen und von dem noch keine Firmware gebaut wurde.

Wenn wir jetzt eine neue stable-Firmware mit weiteren Config-Änderungen bauen wollen: von welchem Branch sollte das dann kommen? Ich finde, wir sollten hierfür den stable-Branch auf einen sauberen Stand bringen, von dem dann bei Bedarf gebaut werden könnte.

Ich denke, die Änderungen auf dem master-Branch sind alle für die stable-Firmware geeignet. @jplitza @mortzu @xmorpheus @komaflash: seht ihr das auch so?

Außerdem ist 5c2df64 ("Remove vpn0[456] again") im Moment für die stable-FW nötig, solange wir VPN4/5/6 nicht in die stable-FW aufnehmen wollen.

Ich schlage also vor, dass wir auf 57e582d (den master-Branch) noch 5c2df64 folgen lassen und das Ergebnis als stable-Branch nehmen.

Ich könnte das wohl hier im FreifunkBremen-Repo direkt umsetzen (per Pull-Request aus meinem Fork trau ich mir das nicht zu). Kann aber auch gern jemand anders machen.

Bei SSH mit Passwort sollte noch ein Sicherheitshinweis im Bezug auf Keys eingefügt werden.
Dies wurde am 06.03.20 so beschlossen.

Wenn man eine stable firmware mit ./build.sh stable baut, wird ein release name vorgeschlagen. Jedoch basiert der Vorschlag auf der letzten testing version.
Beispiel output:

Building Gluon 2015.1.2 as stable
Last release in branch testing was 2015.1.2+bremen2~testing
Release name for this build [default: 2015.1.2+bremen2]: 

A few days ago we discussed reworking the build.sh and the readme needs to be updated as well as soon as that happen (there is already at least one mistake in it at the moment already).

I wanted to talk about in what way the build.sh should work in the future.
At the moment I was thinking it should:

• help build all targets at once
• automatically determine the release name

But other than that I am not sure what features to keep.
Discuss! :-)

kA was genau mit SSL nachinstallieren hier gemeint ist:
https://wiki.ffhb.de/Treffen/2022_12_16.md

• welches package soll ssl installieren?
• sind package quellen default nun auf https? (in /etc/opkg/distfed.conf oder so)
  • curl http://downloads.bremen.freifunk.net/opkg/modules/gluon-ffhb-2022.1.1+bremen1/ -v funktioniert ohne https

Like this:
FreifunkVogtland/site-ffv@a179bca#diff-a3864532a8df90f563cd73bcf11f7af1R6

Ist seit: https://wiki.ffhb.de/Treffen/2022_11_18.md Testing

For new +bremen releases i create the branch v2021.1.2 ...

After this Version become Stable, we could merge it back to master:
master...v2021.1.2

TODOs / Issues:

• ein Upgrade zu machen, wenn der Knoten hinter einem Fritzbox-Gastzugang hängt, der nur UDP-Port 50000 zulässt. Der Download wird dann von der Fritzbox blockiert.
  • wird das Upgrade nicht über den VPN-Tunnel runtergeladen?
  • Quelle: https://wiki.ffhb.de/Treffen/2022_12_16.md

• update from v2019.1-bremen1
  • erwartet domain ffhb_legacy
  • mesh mit v2019.1
  • mesh mit v2019.1.1 ffhb_legacy
  • mesh NICHT mit v2019.1.1 ffhb_11s
• new install v2019.1.1
  • erwartet domain ffhb_legacy
  • mesh mit v2019.1
  • mesh mit v2019.1.1 ffhb_legacy
  • mesh NICHT mit v2019.1.1 ffhb_11s
• change to ffhb_11s
  • ssh uci set gluon.core.domain='ffhb_11s' && gluon-reconfigure && gluon-reload
    (danke @hiaseilert )
    • mesh NICHT mit v2019.1
    • mesh NICHT mit v2019.1.1 ffhb_legacy
    • mesh mit v2019.1.1 ffhb_11s
  • Webgui - Setup-Modus
    • mesh NICHT mit v2019.1
    • mesh NICHT mit v2019.1.1 ffhb_legacy
    • mesh mit v2019.1.1 ffhb_11s
  • Zeitlicher Switch
    • mesh NICHT mit v2019.1
    • mesh NICHT mit v2019.1.1 ffhb_legacy
    • mesh mit v2019.1.1 ffhb_11s
  • Offline Switch
    • mesh NICHT mit v2019.1
    • mesh NICHT mit v2019.1.1 ffhb_legacy
    • mesh mit v2019.1.1 ffhb_11s

Problem:
Hat ein Knoten keinen Zugang zum Internet ist es für nicht-technische Nutzer des FFHB nicht klar, warum der Knoten kein Internet hat. Dies schadet dem Freifunk-Image und macht den Nutzer "offline".

Lösungsvorschlag:
Der Knoten überprüft regelmäßig ob eine Verbindung zum Internet besteht. Besteht diese nicht ändert der Knoten seine SSID von "bremen.freifunk.net" zu einer speziellen SSID die kommuniziert, dass keine Verbindung zum Internet besteht. Z.B. "Kein Internet FFHB".

Weitere Diskussion:
https://wiki.bremen.freifunk.net/Treffen/2019_12_06

siehe https://wiki.ffhb.de/Treffen/2020_04_17#freifunk-bremen-protokoll-pad_domainselector-louis

es sollte ausreichen hide_domain = true in die ffhb_11s.conf zu schreiben

In 2018.1 wurde eingeführt, das per default ssh nur noch mit ssh-keys funktioniert.
So wird es wieder angeschaltet: https://gluon.readthedocs.io/en/v2020.1.x/package/gluon-web-admin.html

Oder wollen wir es aus Sicherheitsgründen so lassen?
👍 mit Passwort
👎 ohne Password (nur SSH-Keys)