<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">Am 26. Mai 2015 um 10:30 schrieb Tobias Theobald <span dir="ltr"><<a href="mailto:tobitheo@gmail.com" target="_blank">tobitheo@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Hey,<div><br></div><div>wir haben uns auch schon Gedanken über eine derartige Infrastruktur gemacht:</div><div><br></div><div>Für User-Services habe ich einen IPv4 /23-Block (also ~512 Adressen) "reserviert", die irgendwo zentral verwaltet werden müssen damit es keine Kollisionen gibt. Hier gibt es dann die Möglichkeit, diese per DHCP zu verteilen, dann müssen sie in die Config von den DHCP-Servern eingetragen werden. Alternativ könnte man Knoteninhabern sagen, sie sollen sich die IPs statisch einstellen. Als Admin gefällt mir die DHCP-Variante besser weil die Usability besser ist.</div></div></blockquote><div><br></div><div>Ein zentrales Angebot wäre wünschenswert. Statische IPs sind ja trotzdem möglich, insofern beides machbar / hier sehe ich keine Kollision.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><div>Bzgl DNS müsste man auf jeden Fall einen Eintrag bei unseren internen DNS-Servern machen. Die Knotennamen spielen hier erstmal überhaupt keine Rolle da die Knoten keine IPv4-Adresse haben und nur vermittelnd agieren, dh wenn man beispielsweise für eine MAC-Adresse eines Clients ein festes Mapping einbaut, dann wird dieser Client dieses Mapping auch bekommen egal über welchen Freifunk-Knoten er sich verbindet. Dementsprechend käme hier nur die von dir genannte Variante 3 in Frage.</div><div><br></div><div>Dann müssten diese Mappings noch eingetragen werden, wofür es mehrere Möglichkeiten gibt:</div><div>* Configs auf Github packen und Pull Requests für Eintragungen benutzen.</div><div>  Vorteile: Gut überschaubar für sowohl uns als auch euch.</div><div>  Nachteile: Pull Requests müssen schon gleich im richtigen Format kommen, Alle MAC-IP-DNS-Mappings sind öffentlich, was ein Sicherheitsrisiko darstellt.</div><div>* Configs auf HackSaar-Gitlab und Pull Requests benutzen.</div><div>  Vorteile: höhere Sicherheit, da nicht jeder das Repo einsehen kann.</div><div>  Nachteile: Weniger Transparenz, Pull Requests müssen schon gleich im richtigen Format kommen</div><div>* Web-Formular für Eintragungen benutzen und werden von dem Admin-Team freigeschaltet.</div><div>  Vorteile: Sehr hohe Usability und Sicherheit</div><div>  Nachteile: Keine Transparenz außer durch Admin-Team, Programmieraufwand für das Webformular.</div><div><br></div><div>Würde persönlich Nummer drei bevorzugen, aber ich weiß nicht wie kritisch ihr das mit der Transparenz seht. Ich persönlich vertraue mir natürlich :D und ich verspreche auch explizit, dass ich keinen absichtlichen Schabernack treibe (siehe Pico-Peering-Agreement), aber ich weiß nicht inwiefern ihr mir da vertraut. </div><div><br></div><div>Noch kurz zu den Sicherheits- und Privatsphäreaspekten: Die Bekanntgabe des MAC-IP-DNS-Mappings erlaubt es Angreifern durch MAC-Address-Spoofing, sich als Man-in-the-Middle zu etablieren. Das ist aber ein generelles Risiko im Freifunk-Netz. Außerdem sollte angemerkt werden, dass die MAC-Adresse als personenbezogenes Datum angesehen werden kann, da sie pro Gerät eindeutig ist. Insofern ist der Veröffentlichung (im Rahmen von zB Github oder dem Hacksaar-Wiki) potenziell problematisch und könnte einer Datenschutzerklärung bedarfen.</div><div><br></div></div></blockquote><div><br></div><div>Ist es wirklich eine höhere Sicherheit, die MAC-Adressen "geheim" zu verwalten, oder wäre das nur Security by Obscurity und daher unrelevant? Falls mein Verständnis korrekt ist, und man die MAC-Adressen auch mit einem automatisiert herausfinden <i>könnte</i>, sehe ich es nicht als kritisch an, die MAC-Adressen auch öffentlich zu verwalten. In diesem Fall überwiegt für mich die Transparenz und ich würde Modell 1 favorisieren, ein public - repo auf github. Dieses Vorgehen schließt auch ein "Eintrags-Formular" auf der Webseite nicht aus, falls jemand nicht in der Lage sein sollte ein pull-request korrekt zu formulieren.<br><br></div><div>Wie lösen andere Communities das Problem?<br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>Kommentare?</div><div><br></div><div>LG</div><div>Tobi</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">2015-05-23 10:23 GMT+02:00 Wolfgang Barth <span dir="ltr"><<a href="mailto:wolfgang@barthwo.de" target="_blank">wolfgang@barthwo.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Ich rege an es zu ermöglichen innerhalb des Freifunknetzes lokale<br>
und/oder regionale Dienste anbieten zu können auch ohne daß man da auf<br>
den Backbones viel tun müsste.<br>
<br>
Idee 1: In die Routersoftware einen "Mikroserver" für einfachstes html<br>
einbauen, der lokale Informationen des Betreibers beinhalten kann, z.B.<br>
bei einem Restaurant die Speisekarte, ober bei mir, mit einem Router am<br>
Startplatz eines Wanderweges, Beschreibungen von diesen. Im Moment kann<br>
man ja auch schon my.ffsaar aufrufen. Dann sollte ein klein bisschen<br>
mehr auch gehen. Meinetwegen über my.ffsaar/lokal, das man dann z.B.<br>
über QR Code bewerben kann. Wenn das überall gleich ist, wäre das<br>
interessant, dann könnte man die Adresse und/oder QR Code gleich mit auf<br>
die Freifunk-Aufkleber drucken. Wenn jemand dort keine eigenen html<br>
Seite hinterlegt, dann kommt nur eine Standard Begrüssungsseite raus.<br>
Selbst wenn das nur genau eine Seite ist, macht das schon Sinn, dann<br>
kann man dort Links auf Internetseiten einbauen mit weitergehenden Infos<br>
oder Angeboten.<br>
<br>
Idee 2: An einem Router per Ethernet-Port angeschlossene Geräte<br>
erreichbar machen. Ebenfalls über ein my.ffsaar/lokal oder ähnlich. Dann<br>
kann man dort irgendein Gerät (Raspberry Pi?) anschliessen oder sowas<br>
mit beliebigen lokalen Diensten.<br>
<br>
Idee 3: Diese lokalen Server auch im ganzen <a href="http://saar.freifunk.net" target="_blank">saar.freifunk.net</a><br>
erreichbar machen über einen DNS Service per<br>
name-meines-routers.ffsaar/lokal oder meinservice.ffsaar oder so.<br>
<br>
Gibt es ähnliche Dienste schon in anderen Freifunk Communities?<br>
<br>
Ich habe da Dienste bei den Augsburgern gesehen:<br>
<a href="http://augsburg.freifunk.net/netz/dienste.html" target="_blank">http://augsburg.freifunk.net/netz/dienste.html</a><br>
oder Paderborn:<br>
<a href="https://paderborn.freifunk.net/dienste/" target="_blank">https://paderborn.freifunk.net/dienste/</a><br>
<br>
Und darüber, wie man es realisieren kann:<br>
<a href="https://silkemeyer.net/inhalte-und-dienste-im-freifunk-netz-anbieten" target="_blank">https://silkemeyer.net/inhalte-und-dienste-im-freifunk-netz-anbieten</a><br>
<span><font color="#888888"><br>
Wolfgang<br>
--<br>
<a href="mailto:freifunk-public@saar.freifunk.net" target="_blank">freifunk-public@saar.freifunk.net</a> - Diskussion und Hilfe der Freifunk Saar Community.<br>
Verwaltung: <a href="https://lists.hacksaar.de/listinfo/freifunk-public" target="_blank">https://lists.hacksaar.de/listinfo/freifunk-public</a><br>
Abbestellen: <a href="mailto:freifunk-public-unsubscribe@saar.freifunk.net" target="_blank">freifunk-public-unsubscribe@saar.freifunk.net</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>--<br>
<a href="mailto:freifunk-public@saar.freifunk.net">freifunk-public@saar.freifunk.net</a> - Diskussion und Hilfe der Freifunk Saar Community.<br>
Verwaltung: <a href="https://lists.hacksaar.de/listinfo/freifunk-public" target="_blank">https://lists.hacksaar.de/listinfo/freifunk-public</a><br>
Abbestellen: <a href="mailto:freifunk-public-unsubscribe@saar.freifunk.net">freifunk-public-unsubscribe@saar.freifunk.net</a><br>
<br></blockquote></div><br></div></div>