Guten Abend zusammen,
hier ist einmal ein kleiner Preview-Stand zu dem, was wir bisher gemeinsam umgesetzt haben:
Fokus lag bisher auf einer Implementierung des Layer2-VPNs mit fastd und einer möglichst einfachen Konfiguration für den User.
Es existiert nun eine neue Seite im Webinterface von IPFire, auf der man eine Liste der verfügbaren Freifunk-Communities bekommen kann und einfach die gewünschte auswählt.
Beim Speichern wird der VPN-Schlüssel erstellt, die Konfiguration für fastd angelegt und der Daemon gestartet, der sich dann mit seinen Peers verbindet und das Batman-Interface hochfährt.
Sourcen gibt es hier:
http://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/heads/ba...
Anbei findet Ihr einen Screenshot der Weboberfläche.
-Michael
Am 2014-11-26 02:49, schrieb Michael Tremer:
Anbei findet Ihr einen Screenshot der Weboberfläche.
Ganz großes Kino. Ich freue mich sehr.
Vielen Dank für deine Arbeit!
Hallöle,
kann das Webfrontend dann zukünftig direkt die site.conf einlesen, um eine Community hinzuzufügen?
Das wäre sehr wichtig denke ich, da man dann nicht für jede kleine Änderung jeder Community manuell eingreifen müsste.
Beste Grüße
Chris
Am 26. November 2014 um 02:49 schrieb Michael Tremer < michael.tremer@ipfire.org>:
Guten Abend zusammen,
hier ist einmal ein kleiner Preview-Stand zu dem, was wir bisher gemeinsam umgesetzt haben:
Fokus lag bisher auf einer Implementierung des Layer2-VPNs mit fastd und einer möglichst einfachen Konfiguration für den User.
Es existiert nun eine neue Seite im Webinterface von IPFire, auf der man eine Liste der verfügbaren Freifunk-Communities bekommen kann und einfach die gewünschte auswählt.
Beim Speichern wird der VPN-Schlüssel erstellt, die Konfiguration für fastd angelegt und der Daemon gestartet, der sich dann mit seinen Peers verbindet und das Batman-Interface hochfährt.
Sourcen gibt es hier:
http://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/heads/ba...
Anbei findet Ihr einen Screenshot der Weboberfläche.
-Michael
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hallo,
die Communities sind nicht hartkodiert, sondern werden aus einem JSON-File eingelesen. Da stehen Name, IDs usw. drin, aber auch die BSSIDs des Meshs usw.
Jede Community kann einfach die Datei erweitern und sich selbst dort einfügen und schon taucht sie in der Liste auf. Wir gehen davon aus, dass diese Liste auch an anderen Orten wiederverwendet werden kann.
-Michael
On Wed, 2014-11-26 at 10:16 +0100, Chris Bischoff wrote:
Hallöle,
kann das Webfrontend dann zukünftig direkt die site.conf einlesen, um eine Community hinzuzufügen?
Das wäre sehr wichtig denke ich, da man dann nicht für jede kleine Änderung jeder Community manuell eingreifen müsste.
Beste Grüße
Chris
Am 26. November 2014 um 02:49 schrieb Michael Tremer michael.tremer@ipfire.org: Guten Abend zusammen,
hier ist einmal ein kleiner Preview-Stand zu dem, was wir bisher gemeinsam umgesetzt haben: Fokus lag bisher auf einer Implementierung des Layer2-VPNs mit fastd und einer möglichst einfachen Konfiguration für den User. Es existiert nun eine neue Seite im Webinterface von IPFire, auf der man eine Liste der verfügbaren Freifunk-Communities bekommen kann und einfach die gewünschte auswählt. Beim Speichern wird der VPN-Schlüssel erstellt, die Konfiguration für fastd angelegt und der Daemon gestartet, der sich dann mit seinen Peers verbindet und das Batman-Interface hochfährt. Sourcen gibt es hier: http://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/heads/batman Anbei findet Ihr einen Screenshot der Weboberfläche. -Michael _______________________________________________ SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Am 2014-11-26 10:16, schrieb Chris Bischoff:
kann das Webfrontend dann zukünftig direkt die site.conf einlesen, um eine Community hinzuzufügen?
Das wäre sehr wichtig denke ich, da man dann nicht für jede kleine Änderung jeder Community manuell eingreifen müsste.
Nein, dass Webinterface von IPFire kann die site.conf von Gluon nicht einlesen.
Wir haben uns dazu entschlossen ein GIT Repository zu verwenden um dort die Communities, welche an diesem Projekt teilhaben wollen, zu pflegen.
Grund dafür sind Daten, welchen zb. in der site.conf nicht vorliegen und/oder überflüssig sind.
Ein weiterer Grund gegen das Parsen der Lua Syntax war das Format und das fehlen eines entsprechenden Parsers. Wir haben die Daten auf das wesentliche Reduziert.
Ich könnte mir aber vorstellen ein externes Tool zu bauen welches uns aus die JSON-Files entsprechend erzeugt.
Hier könnte man auch die Informationen aus der site.conf nutzen.
Die in dem GIT Repository eingepflegten Daten, fließen dann mit in den Build-Prozess bei IP-Fire ein und werden somit regelmäßig aktualisiert. Es gibt ca. pro Monat ein Update von IP-Fire, im Zuge dessen werden dann auch die Daten der Communities aktualisiert.
Sobald die Integration von Freifunk in IPFire abgeschlossen und in der offizielle Version ist, werde ich dies Bundesweit kommunizieren.
Den Startschuss wollen wir mit den Domänen Ruhrgebiet, Möhne und Rheinufer machen!
Nabend,
On Wed, 2014-11-26 at 20:10 +0100, Philip Berndroth wrote:
Am 2014-11-26 10:16, schrieb Chris Bischoff:
kann das Webfrontend dann zukünftig direkt die site.conf einlesen, um eine Community hinzuzufügen?
Das wäre sehr wichtig denke ich, da man dann nicht für jede kleine Änderung jeder Community manuell eingreifen müsste.
Nein, dass Webinterface von IPFire kann die site.conf von Gluon nicht einlesen.
Wir haben uns dazu entschlossen ein GIT Repository zu verwenden um dort die Communities, welche an diesem Projekt teilhaben wollen, zu pflegen.
Ich kann vielleicht mal etwas ausführen wieso wir uns dazu entschlossen haben:
Es scheint solch eine Liste noch nicht wirklich einheitlich zu geben. Offenbar gibt es viele von halb-aktuellen Listen in verschiedenen Formaten, die alle unterschiedliche Informationen mit sich bringen. Das ist für uns insofern ein Problem, da wir einfach nur ein Dropdown-Menü auf der Seite haben wollten mit welchem der User auswählen kann zu welcher Community er gehört. Das Eingeben von den ganzen Konfigurationsoptionen wollten wir somit dem User ersparen. Von irgendwo her müssen wir die aber dennoch bekommen...
Noch eine Liste mehr ist wahrscheinlich auch keine Lösung, aber funktioniert für jetzt. Wie ihr das intern regelt und ob ihr eine Datenbank anlegt wo ihr alle Informationen dieser Art vereint - das macht am Ende des Tages eigentlich keinen Unterschied mehr. Vielleicht lasst ihr euch da mal was einfallen...
Philip hat sich bereit erklärt die Pflege der Liste zu übernehmen.
Grund dafür sind Daten, welchen zb. in der site.conf nicht vorliegen und/oder überflüssig sind. Ein weiterer Grund gegen das Parsen der Lua Syntax war das Format und das fehlen eines entsprechenden Parsers.
Lua ist natürlich verhältnismäßig schlecht, wenn man die Daten in unterschiedlichen Anwendungen einlesen will.
Wir haben die Daten auf das wesentliche Reduziert.
*Für uns* reduziert. Ob das noch brauchbar für eine andere Anwendung ist kann ich nicht sagen.
Ich könnte mir aber vorstellen ein externes Tool zu bauen welches uns aus die JSON-Files entsprechend erzeugt. Hier könnte man auch die Informationen aus der site.conf nutzen.
Die in dem GIT Repository eingepflegten Daten, fließen dann mit in den Build-Prozess bei IP-Fire ein und werden somit regelmäßig aktualisiert. Es gibt ca. pro Monat ein Update von IP-Fire, im Zuge dessen werden dann auch die Daten der Communities aktualisiert.
Sobald die Integration von Freifunk in IPFire abgeschlossen und in der offizielle Version ist, werde ich dies Bundesweit kommunizieren.
Den Startschuss wollen wir mit den Domänen Ruhrgebiet, Möhne und Rheinufer machen!
Das sehe ich nicht so. Ich finde nicht, dass es einen Grund gibt die Entwicklung zurückzuhalten bis diese "offiziell" ist. Wir sollten so viele Tester mit ins Boot holen wie möglich und brauchen das daher nicht geheim halten. Das verbessert unter dem Strich nur das Endergebnis.
Supportet werden grundsätzlich alle Communities, die in der Liste stehen (und die natürlich BATMAN benutzen).
-Michael
Hi,
ich hatte dem Philip vorhin schon gesagt, dass die Batman Version möglicherweise suboptimal für die Client Seite sein kann, da in der offiziellen batman adv die Patches aus dem gluon Zweig nicht enthalten sind (z.b. split horizon).
Eine einheitliche Liste automatisiert zusammen zu bekommen halte ich für eher simpel.
Man braucht lediglich eine json im git wo alle ihre URL auf die site.conf der Community angeben, damit man die mit einem daemon periodisch alle auslesen und homologisieren kann - in welches Format auch immer...
So ähnlich läuft es für die Community Map auch schon.
Beste Grüße
Chris Am 26.11.2014 21:52 schrieb "Michael Tremer" michael.tremer@ipfire.org:
Nabend,
On Wed, 2014-11-26 at 20:10 +0100, Philip Berndroth wrote:
Am 2014-11-26 10:16, schrieb Chris Bischoff:
kann das Webfrontend dann zukünftig direkt die site.conf einlesen, um eine Community hinzuzufügen?
Das wäre sehr wichtig denke ich, da man dann nicht für jede kleine Änderung jeder Community manuell eingreifen müsste.
Nein, dass Webinterface von IPFire kann die site.conf von Gluon nicht
einlesen.
Wir haben uns dazu entschlossen ein GIT Repository zu verwenden um dort
die Communities, welche an diesem Projekt teilhaben wollen, zu pflegen.
Ich kann vielleicht mal etwas ausführen wieso wir uns dazu entschlossen haben:
Es scheint solch eine Liste noch nicht wirklich einheitlich zu geben. Offenbar gibt es viele von halb-aktuellen Listen in verschiedenen Formaten, die alle unterschiedliche Informationen mit sich bringen. Das ist für uns insofern ein Problem, da wir einfach nur ein Dropdown-Menü auf der Seite haben wollten mit welchem der User auswählen kann zu welcher Community er gehört. Das Eingeben von den ganzen Konfigurationsoptionen wollten wir somit dem User ersparen. Von irgendwo her müssen wir die aber dennoch bekommen...
Noch eine Liste mehr ist wahrscheinlich auch keine Lösung, aber funktioniert für jetzt. Wie ihr das intern regelt und ob ihr eine Datenbank anlegt wo ihr alle Informationen dieser Art vereint - das macht am Ende des Tages eigentlich keinen Unterschied mehr. Vielleicht lasst ihr euch da mal was einfallen...
Philip hat sich bereit erklärt die Pflege der Liste zu übernehmen.
Grund dafür sind Daten, welchen zb. in der site.conf nicht vorliegen
und/oder überflüssig sind.
Ein weiterer Grund gegen das Parsen der Lua Syntax war das Format und
das fehlen eines entsprechenden Parsers.
Lua ist natürlich verhältnismäßig schlecht, wenn man die Daten in unterschiedlichen Anwendungen einlesen will.
Wir haben die Daten auf das wesentliche Reduziert.
*Für uns* reduziert. Ob das noch brauchbar für eine andere Anwendung ist kann ich nicht sagen.
Ich könnte mir aber vorstellen ein externes Tool zu bauen welches uns
aus die JSON-Files entsprechend erzeugt.
Hier könnte man auch die Informationen aus der site.conf nutzen.
Die in dem GIT Repository eingepflegten Daten, fließen dann mit in den
Build-Prozess bei IP-Fire ein und werden somit regelmäßig aktualisiert. Es gibt ca. pro Monat ein Update von IP-Fire, im Zuge dessen werden dann auch die Daten der Communities aktualisiert.
Sobald die Integration von Freifunk in IPFire abgeschlossen und in der
offizielle Version ist, werde ich dies Bundesweit kommunizieren.
Den Startschuss wollen wir mit den Domänen Ruhrgebiet, Möhne und
Rheinufer machen!
Das sehe ich nicht so. Ich finde nicht, dass es einen Grund gibt die Entwicklung zurückzuhalten bis diese "offiziell" ist. Wir sollten so viele Tester mit ins Boot holen wie möglich und brauchen das daher nicht geheim halten. Das verbessert unter dem Strich nur das Endergebnis.
Supportet werden grundsätzlich alle Communities, die in der Liste stehen (und die natürlich BATMAN benutzen).
-Michael
Hi,
On Wed, 2014-11-26 at 22:03 +0100, Chris Bischoff wrote:
Hi,
ich hatte dem Philip vorhin schon gesagt, dass die Batman Version möglicherweise suboptimal für die Client Seite sein kann, da in der offiziellen batman adv die Patches aus dem gluon Zweig nicht enthalten sind (z.b. split horizon).
Das wurde mir auch berichtet. Ebenso auch, dass die BATMAN-Entwickler den Patch abgelehnt haben. Aufgrund unserer üblichen Richtlinien bzgl. dessen werden wir den Patch nicht aufnehmen können.
Eine einheitliche Liste automatisiert zusammen zu bekommen halte ich für eher simpel.
Man braucht lediglich eine json im git wo alle ihre URL auf die site.conf der Community angeben, damit man die mit einem daemon periodisch alle auslesen und homologisieren kann - in welches Format auch immer...
So ähnlich läuft es für die Community Map auch schon.
Es wäre sehr schön, wenn man sich möglichst bald auf ein Format einigen kann.
-Michael
Beste Grüße
Chris
Am 26.11.2014 21:52 schrieb "Michael Tremer" michael.tremer@ipfire.org: Nabend,
On Wed, 2014-11-26 at 20:10 +0100, Philip Berndroth wrote: > Am 2014-11-26 10:16, schrieb Chris Bischoff: > > > kann das Webfrontend dann zukünftig direkt die site.conf einlesen, > > um eine Community hinzuzufügen? > > > > Das wäre sehr wichtig denke ich, da man dann nicht für jede kleine > > Änderung jeder Community manuell eingreifen müsste. > > > Nein, dass Webinterface von IPFire kann die site.conf von Gluon nicht einlesen. > > Wir haben uns dazu entschlossen ein GIT Repository zu verwenden um dort die Communities, welche an diesem Projekt teilhaben wollen, zu pflegen. Ich kann vielleicht mal etwas ausführen wieso wir uns dazu entschlossen haben: Es scheint solch eine Liste noch nicht wirklich einheitlich zu geben. Offenbar gibt es viele von halb-aktuellen Listen in verschiedenen Formaten, die alle unterschiedliche Informationen mit sich bringen. Das ist für uns insofern ein Problem, da wir einfach nur ein Dropdown-Menü auf der Seite haben wollten mit welchem der User auswählen kann zu welcher Community er gehört. Das Eingeben von den ganzen Konfigurationsoptionen wollten wir somit dem User ersparen. Von irgendwo her müssen wir die aber dennoch bekommen... Noch eine Liste mehr ist wahrscheinlich auch keine Lösung, aber funktioniert für jetzt. Wie ihr das intern regelt und ob ihr eine Datenbank anlegt wo ihr alle Informationen dieser Art vereint - das macht am Ende des Tages eigentlich keinen Unterschied mehr. Vielleicht lasst ihr euch da mal was einfallen... Philip hat sich bereit erklärt die Pflege der Liste zu übernehmen. > Grund dafür sind Daten, welchen zb. in der site.conf nicht vorliegen und/oder überflüssig sind. > Ein weiterer Grund gegen das Parsen der Lua Syntax war das Format und das fehlen eines entsprechenden Parsers. Lua ist natürlich verhältnismäßig schlecht, wenn man die Daten in unterschiedlichen Anwendungen einlesen will. > Wir haben die Daten auf das wesentliche Reduziert. *Für uns* reduziert. Ob das noch brauchbar für eine andere Anwendung ist kann ich nicht sagen. > Ich könnte mir aber vorstellen ein externes Tool zu bauen welches uns aus die JSON-Files entsprechend erzeugt. > Hier könnte man auch die Informationen aus der site.conf nutzen. > > Die in dem GIT Repository eingepflegten Daten, fließen dann mit in den Build-Prozess bei IP-Fire ein und werden somit regelmäßig aktualisiert. Es gibt ca. pro Monat ein Update von IP-Fire, im Zuge dessen werden dann auch die Daten der Communities aktualisiert. > > Sobald die Integration von Freifunk in IPFire abgeschlossen und in der offizielle Version ist, werde ich dies Bundesweit kommunizieren. > > Den Startschuss wollen wir mit den Domänen Ruhrgebiet, Möhne und Rheinufer machen! Das sehe ich nicht so. Ich finde nicht, dass es einen Grund gibt die Entwicklung zurückzuhalten bis diese "offiziell" ist. Wir sollten so viele Tester mit ins Boot holen wie möglich und brauchen das daher nicht geheim halten. Das verbessert unter dem Strich nur das Endergebnis. Supportet werden grundsätzlich alle Communities, die in der Liste stehen (und die natürlich BATMAN benutzen). -Michael
Sieht gut aus soweit!
Was meiner sicht noch fehlt: - Konfigurationsmöglichkeit welches Interface für Freifunk konfiguriert wird - Anpassungsmöglichkeit des Knotennamen
- Konfigurationsmöglichkeit für das von Jan-Marten beschriebene Szenario
- Daniel
Am 26.11.2014 um 02:49 schrieb Michael Tremer:
Guten Abend zusammen,
hier ist einmal ein kleiner Preview-Stand zu dem, was wir bisher gemeinsam umgesetzt haben:
Fokus lag bisher auf einer Implementierung des Layer2-VPNs mit fastd und einer möglichst einfachen Konfiguration für den User.
Es existiert nun eine neue Seite im Webinterface von IPFire, auf der man eine Liste der verfügbaren Freifunk-Communities bekommen kann und einfach die gewünschte auswählt.
Beim Speichern wird der VPN-Schlüssel erstellt, die Konfiguration für fastd angelegt und der Daemon gestartet, der sich dann mit seinen Peers verbindet und das Batman-Interface hochfährt.
Sourcen gibt es hier:
http://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/heads/ba...
Anbei findet Ihr einen Screenshot der Weboberfläche.
-Michael
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
On Wed, 2014-11-26 at 11:09 +0100, Daniel Weismüller wrote:
Sieht gut aus soweit!
Was meiner sicht noch fehlt:
- Konfigurationsmöglichkeit welches Interface für Freifunk
konfiguriert wird
So weit sind wir noch nicht. Das wird halt noch kommen...
- Anpassungsmöglichkeit des Knotennamen
Ich frag mich eigentlich, ob der überhaupt da stehen muss. Das habe ich nur gebaut, weil es in der Konfiguration ein "prefix" gab, das alle Router haben. Die heißen alle FF-irgendwas.
Der Name wird nur an der Stelle angezeigt und in keine Konfiguration geschrieben und ist daher nur als Vorschlag zu sehen...
- Konfigurationsmöglichkeit für das von Jan-Marten beschriebene
Szenario
s.o.
-Michael
Daniel
Am 26.11.2014 um 02:49 schrieb Michael Tremer:
Guten Abend zusammen,
hier ist einmal ein kleiner Preview-Stand zu dem, was wir bisher gemeinsam umgesetzt haben:
Fokus lag bisher auf einer Implementierung des Layer2-VPNs mit fastd und einer möglichst einfachen Konfiguration für den User.
Es existiert nun eine neue Seite im Webinterface von IPFire, auf der man eine Liste der verfügbaren Freifunk-Communities bekommen kann und einfach die gewünschte auswählt.
Beim Speichern wird der VPN-Schlüssel erstellt, die Konfiguration für fastd angelegt und der Daemon gestartet, der sich dann mit seinen Peers verbindet und das Batman-Interface hochfährt.
Sourcen gibt es hier:
http://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=shortlog;h=refs/heads/ba...
Anbei findet Ihr einen Screenshot der Weboberfläche.
-Michael
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hi,
Am 26.11.2014 um 13:24 schrieb Michael Tremer:
Ich frag mich eigentlich, ob der überhaupt da stehen muss. Das habe ich nur gebaut, weil es in der Konfiguration ein "prefix" gab, das alle Router haben. Die heißen alle FF-irgendwas.
Der Name wird nur an der Stelle angezeigt und in keine Konfiguration geschrieben und ist daher nur als Vorschlag zu sehen...
Der Knotenname sollte über alfred bekannt gegeben werden, damit er z.B. in der Knotenmap (z.B. hier https://freifunk-muenster.de/map/) der jeweiligen Community auftaucht. Ein FF-Prefix ist ansich nicht nötig, kommt aber sicher auf die jeweilige Freifunk-Community an. Über Alfred bekommt man z.B. Name, Hardwaremodell, ob fastd läuft und welche Version es ist, ob der autoupdater läuft und auf welchem branch er ist, welche Firmware-Version installiert ist, welche batman-adv Version läuft, die Geolocation, Kontaktinformation zum Knotenbetreiber und diverse statistische Informationen.
Ich habe mal die Alfred-Daten eines Knotens angehangen.
Gruß Jan-Marten
Wobei auf den gluon Knoten der gesetzte Hostname als Name mittels Alfred gesendet wird, was auch nicht verkehrt ist...
Am 26. November 2014 um 16:46 schrieb Jan-Marten Brüggemann < fussel@fusselkater.org>:
Hi,
Am 26.11.2014 um 13:24 schrieb Michael Tremer:
Ich frag mich eigentlich, ob der überhaupt da stehen muss. Das habe ich nur gebaut, weil es in der Konfiguration ein "prefix" gab, das alle Router haben. Die heißen alle FF-irgendwas.
Der Name wird nur an der Stelle angezeigt und in keine Konfiguration geschrieben und ist daher nur als Vorschlag zu sehen...
Der Knotenname sollte über alfred bekannt gegeben werden, damit er z.B. in der Knotenmap (z.B. hier https://freifunk-muenster.de/map/) der jeweiligen Community auftaucht. Ein FF-Prefix ist ansich nicht nötig, kommt aber sicher auf die jeweilige Freifunk-Community an. Über Alfred bekommt man z.B. Name, Hardwaremodell, ob fastd läuft und welche Version es ist, ob der autoupdater läuft und auf welchem branch er ist, welche Firmware-Version installiert ist, welche batman-adv Version läuft, die Geolocation, Kontaktinformation zum Knotenbetreiber und diverse statistische Informationen.
Ich habe mal die Alfred-Daten eines Knotens angehangen.
Gruß Jan-Marten
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hier die Preview-Version für x86:
http://people.ipfire.org/~ms/branches/batman/ipfire-2.17.i586-full-core86.is...
On Wed, 2014-11-26 at 17:12 +0100, Chris Bischoff wrote:
Wobei auf den gluon Knoten der gesetzte Hostname als Name mittels Alfred gesendet wird, was auch nicht verkehrt ist...
Am 26. November 2014 um 16:46 schrieb Jan-Marten Brüggemann fussel@fusselkater.org: Hi,
Am 26.11.2014 um 13:24 schrieb Michael Tremer: > Ich frag mich eigentlich, ob der überhaupt da stehen muss. Das habe ich > nur gebaut, weil es in der Konfiguration ein "prefix" gab, das alle > Router haben. Die heißen alle FF-irgendwas. > > Der Name wird nur an der Stelle angezeigt und in keine Konfiguration > geschrieben und ist daher nur als Vorschlag zu sehen... Der Knotenname sollte über alfred bekannt gegeben werden, damit er z.B. in der Knotenmap (z.B. hier https://freifunk-muenster.de/map/) der jeweiligen Community auftaucht. Ein FF-Prefix ist ansich nicht nötig, kommt aber sicher auf die jeweilige Freifunk-Community an. Über Alfred bekommt man z.B. Name, Hardwaremodell, ob fastd läuft und welche Version es ist, ob der autoupdater läuft und auf welchem branch er ist, welche Firmware-Version installiert ist, welche batman-adv Version läuft, die Geolocation, Kontaktinformation zum Knotenbetreiber und diverse statistische Informationen. Ich habe mal die Alfred-Daten eines Knotens angehangen. Gruß Jan-Marten _______________________________________________ SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hallo Michael!
Ich habe gerade das Image auf einer x86 Hardware installiert. Nach dem ich den Menüpunkt Netzwerk -> Freifunk aufrufe, bekomme ich den folgenden Fehler angezeigt:
No such file or directory at /srv/web/ipfire/cgi-bin/freifunk.cgi line 326
Hast Du einen Tipp auf Lager?
Hi,
ja das sieht dann doch schon einmal gut aus...
Der Fehler kommt, weil das File mit den Netzen fehlt. Das war angedacht unter /var/ipfire/freifunk/networks.json zu liegen. Ich hatte ein File und das als Liste im Sinn. So sollte es aktuell gehen.
Wenn du das als eine Sammlung einzelner Dateien organisieren willst, dann ist mir das auch recht. Der Code muss dann nur etwas umgebaut werden.
Es wäre schön, wenn das bis morgen zum Treffen fertig ist, dass wir das schon einmal akhaken können und zum nächsten Schritt übergehen...
-Michael
On Sun, 2014-11-30 at 17:04 +0100, Philip Berndroth wrote:
Hallo Michael!
Ich habe gerade das Image auf einer x86 Hardware installiert. Nach dem ich den Menüpunkt Netzwerk -> Freifunk aufrufe, bekomme ich den folgenden Fehler angezeigt:
No such file or directory at /srv/web/ipfire/cgi-bin/freifunk.cgi line 326
Hast Du einen Tipp auf Lager?
-- Viele Grüße Philip Berndroth
Freifunk Ruhrgebiet Freifunk Rheinland e.V. http://www.freifunk-ruhrgebiet.de
Am 26.11.2014 um 19:55 schrieb Michael Tremer michael.tremer@ipfire.org:
Hier die Preview-Version für x86:
http://people.ipfire.org/~ms/branches/batman/ipfire-2.17.i586-full-core86.is...
Hallo Michael!
Vielen Dank für den Hinweis. Bisher bin ich nicht meh dazu gekommen es zu testen. Das holen wir heute Abend nach!
Am 30.11.2014 um 22:48 schrieb Michael Tremer michael.tremer@ipfire.org:
Wenn du das als eine Sammlung einzelner Dateien organisieren willst, dann ist mir das auch recht. Der Code muss dann nur etwas umgebaut werden.
Es wäre wirklich besser das in einzelnen JSON-Files zu organisieren, so ist es auch einfacher eine Community hinzuzufügen.
Es wäre schön, wenn das bis morgen zum Treffen fertig ist, dass wir das schon einmal akhaken können und zum nächsten Schritt übergehen…
Ich habe weitere Communities hinzugefügt und würde dich bitten, dass einlesen der JSON-Files anzupassen.
Hi!
@Jan-Marten: Muss das Schema denn zwingend so aussehen oder können auf Felder weggelassen werden?
Einige der Informationen fallen natürlich ja raus für IPFire. Sowas wie "hardware" -> "model" oder "software" -> "autoupdater" zum Beispiel...
-Michael
On Wed, 2014-11-26 at 16:46 +0100, Jan-Marten Brüggemann wrote:
Hi,
Am 26.11.2014 um 13:24 schrieb Michael Tremer:
Ich frag mich eigentlich, ob der überhaupt da stehen muss. Das habe ich nur gebaut, weil es in der Konfiguration ein "prefix" gab, das alle Router haben. Die heißen alle FF-irgendwas.
Der Name wird nur an der Stelle angezeigt und in keine Konfiguration geschrieben und ist daher nur als Vorschlag zu sehen...
Der Knotenname sollte über alfred bekannt gegeben werden, damit er z.B. in der Knotenmap (z.B. hier https://freifunk-muenster.de/map/) der jeweiligen Community auftaucht. Ein FF-Prefix ist ansich nicht nötig, kommt aber sicher auf die jeweilige Freifunk-Community an. Über Alfred bekommt man z.B. Name, Hardwaremodell, ob fastd läuft und welche Version es ist, ob der autoupdater läuft und auf welchem branch er ist, welche Firmware-Version installiert ist, welche batman-adv Version läuft, die Geolocation, Kontaktinformation zum Knotenbetreiber und diverse statistische Informationen.
Ich habe mal die Alfred-Daten eines Knotens angehangen.
Gruß Jan-Marten _______________________________________________ SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Am 27.11.2014 um 17:44 schrieb Michael Tremer:
Hi!
@Jan-Marten: Muss das Schema denn zwingend so aussehen oder können auf Felder weggelassen werden?
Einige der Informationen fallen natürlich ja raus für IPFire. Sowas wie "hardware" -> "model" oder "software" -> "autoupdater" zum Beispiel...
Hi,
Es müssen nicht alle Felder gefüllt werden.
Bei Hardware könnte man eventuell CPU-Modell oder sowas rein schreiben.
Contact kann nützlich sein, wenn ein Knoteninhaber erreicht werden muss (weil sein Knoten mist macht, oder ähnliches), das ist in der Gluon-Firmware auch einfach nur ein Textfeld für Freitext.
Location ist natürlich wichtig, wenn man auf der Karte angezeigt werden will.
Ansonsten sind natürlich die Informationen unter "network" wichtig, und eventuell auch die unter "software". (autoupdater natürlich ausgenommen)
Die statistischen Informationen in Option 159 sind nice-to-have, für die Statistiken, aber nicht unbedingt notwendig.
Gruß Fussel
Hi,
es gibt also auch keine Pflichtfelder... Hmm.
Freifunk Ruhrgebiet sendet die Daten zusätzlich gzip-komprimiert. Trotzdem tauche ich in der Liste nicht auf ([1] und [2]).
Was könnten die Gründe dafür sein?
-Michael
[1] http://map.freifunk-ruhrgebiet.de/list.html [2] http://map.freifunk-ruhrgebiet.de/alfred/alfred.html
On Thu, 2014-11-27 at 19:35 +0100, Jan-Marten Brüggemann wrote:
Am 27.11.2014 um 17:44 schrieb Michael Tremer:
Hi!
@Jan-Marten: Muss das Schema denn zwingend so aussehen oder können auf Felder weggelassen werden?
Einige der Informationen fallen natürlich ja raus für IPFire. Sowas wie "hardware" -> "model" oder "software" -> "autoupdater" zum Beispiel...
Hi,
Es müssen nicht alle Felder gefüllt werden.
Bei Hardware könnte man eventuell CPU-Modell oder sowas rein schreiben.
Contact kann nützlich sein, wenn ein Knoteninhaber erreicht werden muss (weil sein Knoten mist macht, oder ähnliches), das ist in der Gluon-Firmware auch einfach nur ein Textfeld für Freitext.
Location ist natürlich wichtig, wenn man auf der Karte angezeigt werden will.
Ansonsten sind natürlich die Informationen unter "network" wichtig, und eventuell auch die unter "software". (autoupdater natürlich ausgenommen)
Die statistischen Informationen in Option 159 sind nice-to-have, für die Statistiken, aber nicht unbedingt notwendig.
Gruß Fussel
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hi,
tauchst du denn in den Alfred Rohdaten (alfred-json -z -r 158) auf? Z.B. auf einem anderen Knoten oder auf einem Superknoten?
Dann müsste man mal schauen, ob dem ffmap-backend eventuell doch irgendetwas fehlt.
Gruß Jan-Marten
Am 29.11.2014 um 22:34 schrieb Michael Tremer:
Hi,
es gibt also auch keine Pflichtfelder... Hmm.
Freifunk Ruhrgebiet sendet die Daten zusätzlich gzip-komprimiert. Trotzdem tauche ich in der Liste nicht auf ([1] und [2]).
Was könnten die Gründe dafür sein?
-Michael
[1] http://map.freifunk-ruhrgebiet.de/list.html [2] http://map.freifunk-ruhrgebiet.de/alfred/alfred.html
On Thu, 2014-11-27 at 19:35 +0100, Jan-Marten Brüggemann wrote:
Am 27.11.2014 um 17:44 schrieb Michael Tremer:
Hi!
@Jan-Marten: Muss das Schema denn zwingend so aussehen oder können auf Felder weggelassen werden?
Einige der Informationen fallen natürlich ja raus für IPFire. Sowas wie "hardware" -> "model" oder "software" -> "autoupdater" zum Beispiel...
Hi,
Es müssen nicht alle Felder gefüllt werden.
Bei Hardware könnte man eventuell CPU-Modell oder sowas rein schreiben.
Contact kann nützlich sein, wenn ein Knoteninhaber erreicht werden muss (weil sein Knoten mist macht, oder ähnliches), das ist in der Gluon-Firmware auch einfach nur ein Textfeld für Freitext.
Location ist natürlich wichtig, wenn man auf der Karte angezeigt werden will.
Ansonsten sind natürlich die Informationen unter "network" wichtig, und eventuell auch die unter "software". (autoupdater natürlich ausgenommen)
Die statistischen Informationen in Option 159 sind nice-to-have, für die Statistiken, aber nicht unbedingt notwendig.
Gruß Fussel
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hi,
ich habs nun noch einmal probiert und konnte eigentlich nicht verifizieren was geht und was nicht.
Ich kann definitiv in meiner lokalen Instanz von alfred mein Blob wieder finden. Wenn ich das auf nem TP-Link-Router mache, dann schmiert der ab. Zugang zu einem anderen System, das das nicht tut habe ich derzeit nicht...
-Michael
On Sun, 2014-11-30 at 00:35 +0100, Jan-Marten Brüggemann wrote:
Hi,
tauchst du denn in den Alfred Rohdaten (alfred-json -z -r 158) auf? Z.B. auf einem anderen Knoten oder auf einem Superknoten?
Dann müsste man mal schauen, ob dem ffmap-backend eventuell doch irgendetwas fehlt.
Gruß Jan-Marten
Am 29.11.2014 um 22:34 schrieb Michael Tremer:
Hi,
es gibt also auch keine Pflichtfelder... Hmm.
Freifunk Ruhrgebiet sendet die Daten zusätzlich gzip-komprimiert. Trotzdem tauche ich in der Liste nicht auf ([1] und [2]).
Was könnten die Gründe dafür sein?
-Michael
[1] http://map.freifunk-ruhrgebiet.de/list.html [2] http://map.freifunk-ruhrgebiet.de/alfred/alfred.html
On Thu, 2014-11-27 at 19:35 +0100, Jan-Marten Brüggemann wrote:
Am 27.11.2014 um 17:44 schrieb Michael Tremer:
Hi!
@Jan-Marten: Muss das Schema denn zwingend so aussehen oder können auf Felder weggelassen werden?
Einige der Informationen fallen natürlich ja raus für IPFire. Sowas wie "hardware" -> "model" oder "software" -> "autoupdater" zum Beispiel...
Hi,
Es müssen nicht alle Felder gefüllt werden.
Bei Hardware könnte man eventuell CPU-Modell oder sowas rein schreiben.
Contact kann nützlich sein, wenn ein Knoteninhaber erreicht werden muss (weil sein Knoten mist macht, oder ähnliches), das ist in der Gluon-Firmware auch einfach nur ein Textfeld für Freitext.
Location ist natürlich wichtig, wenn man auf der Karte angezeigt werden will.
Ansonsten sind natürlich die Informationen unter "network" wichtig, und eventuell auch die unter "software". (autoupdater natürlich ausgenommen)
Die statistischen Informationen in Option 159 sind nice-to-have, für die Statistiken, aber nicht unbedingt notwendig.
Gruß Fussel
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Hi,
danke für den Tipp.
Das haben wir am Montag einmal mit Philip zusammen probiert. Es funktioniert, wenn man alfred nicht im Master-Modus startet. Aus dem Hilfetext habe ich geschlossen, dass man das tun sollte...
Ich habe ein kleines Script geschrieben, das die Daten aus unserem System zusammensucht:
http://git.ipfire.org/?p=people/ms/ipfire-2.x.git;a=blob;f=config/alfred/ann...
Das taucht auch zeitweise auf der Alfred-Seite auf. Schauen wir mal ob das permanent bleibt, wenn ich nicht dauernd alles neu starte zum Debuggen.
-Michael
On Sun, 2014-11-30 at 00:35 +0100, Jan-Marten Brüggemann wrote:
Hi,
tauchst du denn in den Alfred Rohdaten (alfred-json -z -r 158) auf? Z.B. auf einem anderen Knoten oder auf einem Superknoten?
Dann müsste man mal schauen, ob dem ffmap-backend eventuell doch irgendetwas fehlt.
Gruß Jan-Marten
Am 29.11.2014 um 22:34 schrieb Michael Tremer:
Hi,
es gibt also auch keine Pflichtfelder... Hmm.
Freifunk Ruhrgebiet sendet die Daten zusätzlich gzip-komprimiert. Trotzdem tauche ich in der Liste nicht auf ([1] und [2]).
Was könnten die Gründe dafür sein?
-Michael
[1] http://map.freifunk-ruhrgebiet.de/list.html [2] http://map.freifunk-ruhrgebiet.de/alfred/alfred.html
On Thu, 2014-11-27 at 19:35 +0100, Jan-Marten Brüggemann wrote:
Am 27.11.2014 um 17:44 schrieb Michael Tremer:
Hi!
@Jan-Marten: Muss das Schema denn zwingend so aussehen oder können auf Felder weggelassen werden?
Einige der Informationen fallen natürlich ja raus für IPFire. Sowas wie "hardware" -> "model" oder "software" -> "autoupdater" zum Beispiel...
Hi,
Es müssen nicht alle Felder gefüllt werden.
Bei Hardware könnte man eventuell CPU-Modell oder sowas rein schreiben.
Contact kann nützlich sein, wenn ein Knoteninhaber erreicht werden muss (weil sein Knoten mist macht, oder ähnliches), das ist in der Gluon-Firmware auch einfach nur ein Textfeld für Freitext.
Location ist natürlich wichtig, wenn man auf der Karte angezeigt werden will.
Ansonsten sind natürlich die Informationen unter "network" wichtig, und eventuell auch die unter "software". (autoupdater natürlich ausgenommen)
Die statistischen Informationen in Option 159 sind nice-to-have, für die Statistiken, aber nicht unbedingt notwendig.
Gruß Fussel
SIG-Freifunk-de mailing list SIG-Freifunk-de@lists.ipfire.org http://lists.ipfire.org/mailman/listinfo/sig-freifunk-de
Am 04.12.2014 um 20:34 schrieb Michael Tremer:
Das haben wir am Montag einmal mit Philip zusammen probiert. Es funktioniert, wenn man alfred nicht im Master-Modus startet. Aus dem Hilfetext habe ich geschlossen, dass man das tun sollte...
Ja, Master-Modus sollte auf den Knoten laufen, die die Alfred-Daten sammeln. Also die Supernodes oder so, aber nicht auf einem normalen Knoten ;)
Gruß Jan-Marten
-
Chris Bischoff -
Daniel Weismüller -
Jan-Marten Brüggemann -
Michael Tremer -
Philip Berndroth