freifunkbremen / gluon-site-ffhb

Site config for gluon

Anleitung

Um die Bremer Firmware zu bauen sind folgende Vorbereitungen notwendig:

# Build-Dependencies installieren (Debian/Ubuntu)
sudo apt-get install coreutils schedtool build-essential subversion git libncurses5-dev zlib1g-dev unzip gawk libssl-dev python2.7
# Dieses und das Gluon-Repository clonen
git clone --recursive https://github.com/FreifunkBremen/gluon-site-ffhb.git

Um eine bestimmte Version der Bremer Firmware zu bauen sind folgende Befehle nötig:

# In das Verzeichnis wechseln
cd gluon-site-ffhb/
# Die gewünschte Version auschecken ($tag ist z.B. v2016.2.3+bremen2)
git checkout $tag
# Gluon auf die passende Version bringen
git submodule update
# Build-Prozess anstoßen
./build.sh

Lief der Build-Prozess erfolgreich durch, liegen in gluon/output/images/ die fertigen Images inklusive eines Manifests für den Autoupdater, das schon mit dem eigenen ECDSA-Key signiert wurde falls dieser unter ~/.ecdsakey liegt. In gluon/output/packages/ liegen außerdem per opkg auf dem Knoten nachinstallierbare Kernel-Module.

Will man ohne build.sh manuell make im Verzeichnis gluon aufrufen, wie in der offiziellen Gluon-Doku, muss man jedem Aufruf von make den Parameter GLUON_SITEDIR=$PWD/../ nachstellen (oder wie in build.sh einmal per export GLUON_SITEDIR=$PWD/../ setzen), damit Gluon das site-Repository findet. Alternativ kann man einen Symlink anlegen, indem man während man im site-Repository ist den Befehl ln -s $PWD gluon/site ausführt.

In jedem Fall wird der Gluon-Release-Name automatisch aus dem ausgecheckten Tag generiert - auch falls kein Tag, sondern z.B. der master-Branch ausgecheckt wurde! Falls das nicht gewünscht ist lässt sich durch folgenden Aufruf vor dem entsprechenden Build-Befehl (./build.sh oder make) ein eigener Release-Name festlegen:

export GLUON_RELEASE="2017.1+bremen1+dein-nickname"

Analog lassen sich alle anderen GLUON_*-Variablen überschreiben, außerdem die folgenden build.sh-spezifischen Variablen:

• GLUON_TARGETS: Welche Architekturen werden von build.sh gebaut
• KEYFILE: Der Ort des Schlüssels, mit dem das testing/nightly-Manifest automatisch unterschrieben werden soll

gluon-site-ffhb's Issues

offline SSID einführen

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

Stable Release of v2021.1.2

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

TLS nachinstallieren

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

SSH mit Passwort

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)

build.sh release name Vorschlag für stable firmware kaputt

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]: 

Domain dropdown ausblenden

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

Gluon without wifi also build without respondd-module-airtime

v2017.1 branch - site.conf needs a site_seed

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

RFC: bandwidth_limit standard values

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:

Verbindung	80%	90%
16.000	12.400	14.400
1.000	800	900
2.000	1.600	1.800

[Test] Domainsplitt + 11s - Abnahme von v2019.1.1

• 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

SSH mit Passwort: Sicherheitshinweis

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

rework of build.sh

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! :-)

stable-Branch klarmachen

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.