Zusammen mit Lorenz und Stefan haben wir gerade festgestellt, das die
fastd namen viel zu lang sind und gluon diese nicht übernimmt.
Alt:
mesh_vpn_backbone_peer_<srv> ist zu lang für gluon
Neu:
vpn_<srv>
Daher hier ein Vorschlag zum drastischen einkürzen. Es ist nur ein
Bezeichner von daher nix weltbewegendes.
Der Merge Request:
https://git.nordwest.freifunk.net/ffnw-firmware/packages/merge_requests/14
und für Tarek als Patch zum anschauen:
From e4ec14e6f43ad43d927fa49c0e4ae827005d4e2e Mon Sep 17 00:00:00 2001
From: Johannes Rudolph <johannes.rudolph(a)ffnw.de>
Date: Thu, 26 May 2016 15:56:56 +0200
Subject: [PATCH] Make fastd peer names shorter at the moment they are to Long
---
hoodselector/luasrc/hoodselector | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/hoodselector/luasrc/hoodselector b/hoodselector/luasrc/hoodselector
index 1b27b87..7c3e1a3 100755
--- a/hoodselector/luasrc/hoodselector
+++ b/hoodselector/luasrc/hoodselector
@@ -275,7 +275,7 @@ end
local function directVPN()
-- escape special chars "[]-"
for outgoingIF in io.open("/sys/kernel/debug/batman_adv/bat0/originators", 'r'):lines() do
- if outgoingIF:match(string.gsub("%[ " .. uci:get('fastd', 'mesh_vpn_backbone', 'net') .. "%]","%_",'-'):gsub("%-", "%%-")) then
+ if outgoingIF:match(string.gsub("%[ " .. uci:get('fastd', 'vpn', 'net') .. "%]","%_",'-'):gsub("%-", "%%-")) then
return true
end
end
@@ -297,7 +297,7 @@ local function getCurrentPeers()
for prefix,peer in pairs(index) do
local tmpPeer = {}
if prefix:match(".name") then
- if peer:match("mesh_vpn_backbone_peer_") then
+ if peer:match("vpn_") then
local tmpRemote = uci:get('fastd', peer, 'remote')
tmpRemote = tmpRemote[1]:split(" ")
local remote = {}
@@ -368,7 +368,7 @@ local function vpn_reconfiguration_needed(hood_serverlist)
for local_server_config_name, local_server in pairs(local_serverlist) do
local local_server_exists_in_hoodfile = false
for hood_server_index,hood_server in pairs(hood_serverlist) do
- if (local_server_config_name == 'mesh_vpn_backbone_peer_'.. hood_server["host"]:split('.')[1]) then
+ if (local_server_config_name == 'vpn_'.. hood_server["host"]:split('.')[1]) then
local_server_exists_in_hoodfile = true
if ( local_server.key ~= hood_server['publickey'] ) then
return true
@@ -389,7 +389,7 @@ local function vpn_reconfiguration_needed(hood_serverlist)
for hood_server_index,hood_server in pairs(hood_serverlist) do
local hood_server_exists_locally = false
for local_server_config_name, local_server in pairs(local_serverlist) do
- if (local_server_config_name == 'mesh_vpn_backbone_peer_'.. hood_server["host"]:split('.')[1]) then
+ if (local_server_config_name == 'vpn_'.. hood_server["host"]:split('.')[1]) then
hood_server_exists_locally = true
end
end
@@ -408,9 +408,9 @@ local function vpn_reconfigure(hood_serverlist)
end
-- add servers from hoodfile
- local group = 'mesh_vpn_backbone'
+ local group = 'vpn_'
for i,hood_server in pairs(hood_serverlist) do
- uci:section('fastd', 'peer', group .. '_peer_' .. hood_server.host:split('.')[1],
+ uci:section('fastd', 'peer', group .. hood_server.host:split('.')[1],
{
enabled = 1,
net = 'mesh_vpn',
--
libgit2 0.24.0
Gruß
Johannes
Hi,
ich würde gerne noch mal über die hood ansprechpantern sprechen.
Clemens hat folgendes zu Diskussion gestellt:
Ich möchte gerne vorschlagen, dass es für jede Hood mindestens zwei
feste technische Ansprechpartner gibt, die mit ihrem Namen und ihrer
Emailadresse im Hoodfile verzeichnet werden. Hintergrund ist, dass es in
der Vergangenheit häufiger zu Überlastungserscheinungen im Admin-Team
kam und ich gerne Anreize schaffen möchte sich auch auf der
administrativen Seite von Freifunk zu engagieren.
Konsequenz des Vorschlags ist, dass Hoods nur für Regionen eingerichtet
werden, die auch Ehrenamtliche für die technischen Betreuung in das
Admin-Team entsenden können. Das müssen nicht zwingend lokale Betreuer
sein auch wenn dies wünschenswert ist. Vielmehr geht es bei diesem
Vorschlag darum Verantwortung zu übernehmen. Zum einen sollen Regionen,
die von den technischen Weiterentwicklungen profitieren wollen auch
etwas zurückgeben und Verantwortung für die Technik übernehmen indem sie
sich zwei technische Betreuer suchen und zum anderen wird auch das
Admin-Team insgesamt in die Pflicht genommen neues Personal in komplexe
technische Sachverhalte einzuarbeiten.
Ich würde diese Änderung gerne in das Hoodfile aufnehmen und nicht in
eine externe Liste im Wiki auslagern, da die technischen Ansprechpartner
an einer zentralen Stelle verzeichnet sein sollten, die z.B. auch im
Webinterface abgefragt und Angezeigt werden kann. Der Platzbedarf je
Hood liegt bei ca. 200 Byte. Bei 10 Hoods also ca. 2KB. Ich denke das
können wir verschmerzen, wenn wir im Gegenzug eine Verbesserung der
Organisationsstruktur erzielen können. Die technische Realisierung
erfolgt über ein weitere Attribut für jede Hood:
Moin
ich habe im Issure #3 schon gesagt, dass ich es machen will.
Ein Debug Paket erstellen, welches eine Ausgabe erzeugt, die man
versenden kann um das debugging zu verbessern.
Ich würde gerne Ideen Sammeln welche "Angaben" hier sinvoll wären.
Ich bitte um vorschläge ;)
Gerne im Issue kommentieren
https://git.nordwest.freifunk.net/ffnw-firmware/packages/issues/3
Gruß
Johannes
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
