Hi,
seid so lieb und canceled mir nicht jedesmal die automatisierten Firmware
Builds sonst aktualisieren sich meine Router nicht. Wir haben die Builds extra
eingerichtet damit niemand etwas tun muss um automatisch die aktuellste
Entwicklerfirmware auf seinen Router zu bekommen. Das funktioniert aber nur
wenn ihr den Server das Zeugs auch bauen lasst. Wenn ich jedesmal manuell auf
retry drücken muss ist das suboptimal ;)
https://git.nordwest.freifunk.net/ffnw-firmware/siteconf/builds
Danke
Clemens
Hi,
Ich hab gestern Abend die testing Firmware fertiggestellt.
Ich warte nur noch auf ein OK seites Stefan, das die Server soweit sind.
Dann würde ich die images unter firmware.ffnw.de freigeben :)
Schönen gruß
Tarek
Hallo zusammen,
Ich würde gerne vorbereiten für die Firmware Version 1.0 die zu
releasenden hoods diskutieren.
Mir stellen sich ein paar Fragen vorweg.
Wie viele serverseitige hoods sind aktuell möglich?
Wie viele Router sollen diese hoods fassen?
Welche BSSIDs sind aktuell für die testhoods belegt?
Ursprünglich war der Plan in 1.0 eine großflächige hood um Wittmund WHV
zufassen, sowie eine Großflächige hood um Osnabrück.
Vom Volumen entspräche das ca. 500-600 Router pro hood.
Je nachdem wie viele hoods wir in v1.0 releasen wollen würde ich
folgende hoods vorschlagen: (haubsächlich get es hier gerade um die
koordinaten)
{
"name": "osna",
"host": "osna01.sn.ffnw.de",
"port": "xxxx",
"publickey": "xxxx",
"bssid": "02:CA:FF:EE:BA:BD",
"defaulthood": false,
"boxes": [
[
[
"52.18",
"7.90"
],
[
"52.32",
"8.22"
]
]
]
},
{
"name": "ibben",
"host": "ibben01.sn.ffnw.de",
"port": "xxxx",
"publickey": "xxxx",
"bssid": "02:CA:FF:EE:BA:BC",
"defaulthood": false,
"boxes": [
[
[
"52.08",
"7.33"
],
[
"52.39",
"7.90"
]
]
]
},
{
"name": "ganderke",
"host": "ganderke01.sn.ffnw.de",
"port": "xxxx",
"publickey": "xxxx",
"bssid": "02:CA:FF:EE:BA:BB",
"defaulthood": false,
"boxes": [
[
[
"52.99",
"8.30"
],
[
"53.16",
"8.70"
]
]
]
},
{
"name": "witt-whv",
"host": "witt-whv01.sn.ffnw.de",
"port": "xxxx",
"publickey": "xxxx",
"bssid": "02:CA:FF:EE:BA:BA",
"defaulthood": false,
"boxes": [
[
[
"53.49",
"7.73"
],
[
"53.65",
"8.19"
]
]
]
},
{
"name": "ol-rast",
"host": "ol-rast01.sn.ffnw.de",
"port": "xxxx",
"publickey": "xxxx",
"bssid": "02:CA:FF:EE:BA:B9",
"defaulthood": false,
"boxes": [
[
[
"53.09",
"7.97"
],
[
"53.27",
"8.30"
]
]
]
}
Eine Diskussion über die BSSID Vergabe findet im thread
"Hood Mesh BSSID" statt.
Wie ist eure Meinung dazu ?
Schöne Grüße
Tarek
Hi,
wir haben im Rahmen der gluon Umstellung 2012-2013 damals ein VPN crypto
eingeführt. Ich habe mir da schon länger Gedanken drüber gemacht. Ich
bin zu den Schluss gekommen, das ein crypto auf dem VPN an sich sinnlos
ist und letztlich nur zur ausbremsung des Durchsatzes durch fastd sowie
einer stärkeren Limitierung Server seits führt. Ohne das ein
vorteilhafter Grund dafür bestehen bleibt. Das crypto Ansicht ist
relativ witzlos da sowohl public key als auch private key in gits rumliegen.
Somit hat grundsätzlich jeder einfach die Möglichkeit die VPN
Verschlüsselung aufzuheben.
Ich wäre dafür in v1.0 die Verschlüsselung von fastd wieder zu
entfernen. Das sollte den Durchsatz auf den Routern erhöhen und zur
Entlastung von Gateways führen. Ein Nachteil fällt mir dadurch nicht ein.
Schöne Grüße
Tarek
Moin,
in abspreache mit Stefan bastel ich gerade am ersten Hoodfile.
Ich bin über den Punkt Mesh BSSID gestolpert.
Aktuell ist diese bei uns "02:CA:FF:EE:BA:BE" und für die Default Hood
kann diese auch so bleiben.
Kann ich einfach nach freidünken für Hoods andere BSSID vergeben, oder
gibt es da vorgaben die ich noch nicht kenne`?!
Ansonsten mach ich einfach:
02:CA:FF:EE:BA:BE -> Default Hood
02:CA:FF:EE:BA:B0 -> Hood Osnabrück
02:CA:FF:EE:BA:B1 -> Hood Butjardingen/Friesland/Wilhelmshaven/Wittmund
und die später folgenden Hoods werden weiter hochgezählt.
02:CA:FF:EE:BA:B2
02:CA:FF:EE:BA:B3
02:CA:FF:EE:BA:B4
02:CA:FF:EE:BA:B5
02:CA:FF:EE:BA:B6
02:CA:FF:EE:BA:B7
02:CA:FF:EE:BA:B8
02:CA:FF:EE:BA:B9
Meinungen / Wünsche / Kritik / Lob / Tadel / Zustimmung / Ablehnung?!
Keine Reaktion deute ich mal als Zustimmung
Gruß
Johannes
Ahoi,
auf srv15 haben wir momentan zwei VMs, die den Traffic über ein
internes Netz auf den VM-Host leiten, auf dem Bird läuft.
Nun stellt sich mir die Frage, ob mit dem Ausrollen unserer
Puppetmodule so ein Setup zur Zeit nicht möglich wäre, sprich:
Supernode und Rheinland-Anbindung müssen zwangsläufig auf demselben
Host sein.
Kann einer unserer Puppetentwickler dazu was sagen?
Grüße
bjo
--
xmpp bjo(a)schafweide.org
Hi,
> Hört sich sehr stimmig an.
> Die testhood kann erst ja auf 08 bleiben bis wir später Platz haben.
>
> Wenn dann die ersten Router ungezogen sind können wir ja auf einem neuen Server eine Testhood anlegen.
>
> Mach du doch mal eine hood.json, um den Puppet Part kümmere ich mich dann. Nächste Woche habe ich Luft.
Ich würde im laufe des Wochenendes eine json Datei Generieren lassen.
Evtl. wollen hier noch ein paar drauf schreiben.
vg
Tarek
Hi,
Ich habe heute eine neue Firmware gebaut. Basisdaten:
* Firmware-Version: 0.9
* Gluon-Version: v2016.1.x
* Commit ID: 15886fb65b9bcae8770f0bfa1bfc3718f70c9541
* Download: http://firmware.ffnw.de/0.9/
Folgende upstream Änderungen gab es:
*
https://gluon.readthedocs.io/en/v2016.1.4/releases/v2016.1.4.html#bugfixes
* Fixes #714 https://github.com/freifunk-gluon/gluon/issues/714
* Fixes #721 https://github.com/freifunk-gluon/gluon/issues/721
* Fixes #754 https://github.com/freifunk-gluon/gluon/issues/754
* ar71xx-generic: add support for Ubiquiti Rocket M XW
* Fixes #755 https://github.com/freifunk-gluon/gluon/issues/755
* Fixes #687 https://github.com/freifunk-gluon/gluon/issues/687
Folgende Comunnity speziffischen Änderungen gab es:
* Neues Paket ffnw-hoods hinzugefügt. Dieses Paket enthält das
hoodfile welches eine json datei ist die, die default hood
beschreibt.
* Neues Paket ffnw-hoodselector hinzugefügt. Dieses Paket enthält den
hoodselector welcher eine halbautomatische Layer 2 Segmentierung
anhand des hoodfiles realisiert.
* geolacator patch führt zur error meldung wenn die positions
Qualität = 0 ist.
* nightly autoupdater branch hinzugefügt. liefert Images die täglich
aus dem aktuellen master compeliert werden.
* firmware signatur key von lethexa(Tim aus WHV) hinzugefügt
Die Änderungen an der Siteconf können im Siteconf-Repo mittels folgendem
Befehl eingesehen werden:
git diff v0.8.2 v0.9
Die Änderungen an unseren eigenen Paketen können im Packages-Repository
mittels folgendem Befehl eingesehen werden:
git diff b290ec25eca44cc8bb30a407958a539151a06aab
384427d91babb80756b3e5df75c6c361fd3b3f1a
Viele Grüße
Tarek
--
# Home tarek(a)ring0.de
# Freifunk Nordwest <tarek(a)ffnw.de>
# GnuPG:
# Ich nehme verschlüsselte Mails entgegen.
# Fingerprint: 57C0 5D95 DBB0 8A60 159D D114 D41F 2089 1E7A 91C2
# Download Key: http://pgp.mit.edu/pks/lookup?op=get&search=0x1E7A91C2
# Anleitung zur Mailverschlüsselung: http://bit.ly/1e3g2yF
FYI
-------- Forwarded Message --------
Subject: Re: [Dev] Hoods für firmware version 1.0
Date: Fri, 20 May 2016 21:26:06 +0200
From: Stefan <stefan(a)osnabrueck.freifunk.net>
To: Jan-Tarek Butt <tarek(a)ring0.de>
Hört sich sehr stimmig an.
Die testhood kann erst ja auf 08 bleiben bis wir später Platz haben.
Wenn dann die ersten Router ungezogen sind können wir ja auf einem neuen
Server eine Testhood anlegen.
Mach du doch mal eine hood.json, um den Puppet Part kümmere ich mich
dann. Nächste Woche habe ich Luft.
Am 20. Mai 2016 21:15:59 MESZ, schrieb Jan-Tarek Butt <tarek(a)ring0.de>:
>Hi,
>
>On 05/20/16 19:52, Stefan wrote:
>> Hey Tarek,
>>
>> sehr guter Plan.
>> Aktuell gibt es auf srv08 4 Fastd Instanzen, die wie folgt aufgeteilt
>werden könnten:
>>
>> - WHV
>> - Wittmund
>> - Oldenburg?
>
>Das fände ich schon mal super und wäre dafür.
>
>> - und eine Testinstanz
>
>Hier würde ich vorschlagen das die test instance auf einen Vollständig
>eigenen Server kommt da hier durch aus auch mal anderen protokolle zum
>Einsatz kommen könnten usw.
>
>> srv03 wäre für folgende Hoods mit 2 Fastd Instanzen gut
>>
>> - OS-Stadt (130 Router)
>> - Ibbenbüren (120 Router)
>>
>> Pro Fastd Instanz wären hier bei 03 125 Router machbar
>
>Ich würde sonst vorschlagen einer hood mehere fastd instanze zu
>zuweisen
>somit können wir das Volumen einer hood erhöhen.
>
>> Die Server sind aktuell eh schon so eingerichtet.
>> Wie haben nun 2 Server im ersten Schritt zur Verfügung. Alternativ
>könnten wir noch 1 VM auf srv15 anlegen, da könnten auch noch 150
>Router hin.
>
>Sobald wir die ersten hoods ausgerollt haben werden Ressourcen aus der
>Dedaulthood frei. Damit können wir weitere hoods bauen.
>
>
>>> Ich würde gerne vorbereiten für die Firmware Version 1.0 die zu
>>> releasenden hoods diskutieren.
>>>
>>> Mir stellen sich ein paar Fragen vorweg.
>>>
>>> Wie viele serverseitige hoods sind aktuell möglich?
>
>OK, ich schließe daraus das aktuell 6 hoods normale hoods möglich sind.
>
>>> Wie viele Router sollen diese hoods fassen?
>
>Mein Vorschlagt hier wären 300 Router pro hood. Das entspräche 2-3
>Fastd
>Instanzen pro Hood.
>
>vg
>Tarek
--
vg
Stefan
