GithubHelp home page GithubHelp logo

gluon-site-ffhb's Introduction

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 People

Contributors

anon6789 avatar apuester avatar corny avatar genofire avatar jortgies avatar jplitza avatar lokn avatar mablae avatar mortzu avatar oliver avatar proxyhb avatar rapha-dev avatar simjost avatar xmorpheus avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

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.

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

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

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

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.