Skip to content
Snippets Groups Projects
Unverified Commit 9770ae06 authored by Philipp Rothmann's avatar Philipp Rothmann Committed by Paul
Browse files

rümpelrümpel

parent 28795d31
No related branches found
No related tags found
No related merge requests found
# Release Procedure
Example for a 0.10 release based on Gluon v2018.2
### 0. Pre-Build
* Add (or update) "Gluon release version <-> firmware/site release version" to [README.md](https://github.com/freifunk-luebeck/site-ffhl/blob/master/README.md) in the site repository master branch:
* ``0.10: v2018.2``
### 1. Build
<pre><code>$ VERSION=0.10-1
$ GLUON_VERSION=v2018.2
$ git clone https://github.com/freifunk-gluon/gluon.git
$ cd gluon
$ git checkout $GLUON_VERSION
$ git clone https://github.com/freifunk-luebeck/site-ffhl.git site
$ make update
$ for target in ar71xx-generic ar71xx-tiny ar71xx-nand brcm2708-bcm2708 brcm2708-bcm2709 mpc85xx-generic ramips-mt7621 sunxi-cortexa7 x86-generic x86-geode x86-64; do echo "Building: $target"; make GLUON_TARGET="$target" clean; make GLUON_RELEASE=$VERSION GLUON_BRANCH=stable GLUON_TARGET="$target" -j $(nproc); done
$ make manifest GLUON_BRANCH=beta GLUON_RELEASE=$VERSION GLUON_PRIORITY=0
$ make manifest GLUON_BRANCH=stable GLUON_RELEASE=$VERSION GLUON_PRIORITY=7
</code></pre>
Visually check that output/images/* and the contents of output/images/sysupgrade/{stable,beta}.manifest looks fine.
Then copy output/images to ``srv01.luebeck.freifunk.net:/var/lib/ffhl-firmware/autoupdates/0.10-1``. And run ``chown -R firmware:nogroup /var/lib/ffhl-firmware/autoupdates/0.10-1``. This maps to: https://luebeck.freifunk.net/firmware/0.10-1/sysupgrade/
### 2. Beta release
First, manually download and flash a few images to a few devices to check that the overall build process went fine. If the devices boot fine, then:
<pre><code>$ cd site
$ git tag v0.10-1 master
$ git push origin v0.10-1
$ git push
$ cd ..
$ ./contrib/sign.sh ~/your-autoupdate-key.priv ./output/images/sysupgrade/beta.manifest
</code></pre>
The sign.sh call needs to be redone by each signer to reach the minimum amount of valid signatures needed for the autoupdater to start. Then:
* Update the beta.manifest on the server with the new, added signatures below the "---" in the local copy of the beta.manifest.
* On srv01.luebeck.freifunk.net call:
<pre><code>$ cd /var/lib/ffhl-firmware/autoupdates/
$ rm beta
$ ln -s 0.10-1 beta
</code></pre>
Then check for about 2 weeks that nodes with the beta branch selected in their autoupdater updated and run fine. Make sure to have at least one device of the more popular ones on a beta branch.
*Post-beta-rollout checklist:*
* Nodes are alive and stable with new version number (check node's status page)
* Check that all wifi interfaces are up and running (run ``iwinfo`` via ssh)
* Check that meshing works (run ``batctl o`` via ssh)
* Check that the process list looks fine (run ``ps`` via ssh - no missing processes? no new, suspicious processes?)
* Check that /etc/config/autoupdater looks fine and has the correct public keys
* Check that /etc/dropbear/authorized_keys was left unmodified
### 3. Stable release
If everything went smoothly, with no issues so far then proceed here. Otherwise redo steps 1) and 2) with the appropriate changes and increment the build version number (e.g. 0.10-2 for the second try).
First update the "DATE" parameter in your local copy of the stable.manifest to a time in the future at which autoupdates should start. Note that until then all signers (or at least the minimum amount of signers necessary) should have added their signature. Otherwise the safety measure of an update stretched over a week via GLUON_PRIORITY will not apply. That is, if the minimum amount of necessary signatures was added after DATE + GLUON_PRIORITY then all nodes will update immediately instead of stretched over a week.
To sign the stable release do the following in your local copy:
<pre><code>$ cd site
$ git tag v0.10 master
$ git push origin v0.10
$ git push
$ cd ..
$ ./contrib/sign.sh ~/your-autoupdate-key.priv ./output/images/sysupgrade/stable.manifest
</code></pre>
The sign.sh call needs to be redone by each signer to reach the minimum amount of valid signatures needed for the autoupdater to start. Then:
* Update the DATE in the stable.manifest on the server with the new start time.
* Update the stable.manifest on the server with the new, added signatures below the "---" in the local copy of the stable.manifest.
* On srv01.luebeck.freifunk.net call:
<pre><code>$ cd /var/lib/ffhl-firmware/autoupdates/
$ ln -s 0.10-1 0.10
$ ln -s 0.10-1 stable
</code></pre>
*Pre-stable-rollout checklist:*
* Verify that images are downloadable via https://luebeck.freifunk.net/firmware/0.10/sysupgrade/
* Verify that stable.manifest on the server contains a sufficient amount of valid signatures
* Verify that the start DATE of the stable.manifest on the server is correct
Then prior the stable update start date, inform passengers: Inform about scheduled landing time of the new release and the firmware changes it contains on the talk@luebeck.freifunk.net mailing list.
*Peri-stable-rollout checklist:*
* Daily:
* Check that the predicted number of nodes updates to the new firmware version
* For the nodes which updated successfully, check their status page:
* enough RAM
* load ok (usually < 1)
* neighbor link quality ok
* Monitor mailing lists for passenger feedback
In case of any issues occurring, on srv01.luebeck.freifunk.net abort via:
<pre><code>$ cd /var/lib/ffhl-firmware/autoupdates/
$ rm 0.10
</code></pre>
*Post-stable-rollout checklist:*
* Check if any nodes might have failed updating (any nodes that might have gone offline, especially during the update time at about 04:00 o'clock.
* If available, inform individual node owners via the contact information they set in the config-mode about their failed update. If possible, determine cause for failure.
* Update firmware version and models on the website: https://luebeck.freifunk.net/firmware.html
* set "FIRMWARE_VERSION" in _plugins/firmwares.rb
* run "jekyll build"
* check for warnings about unknown/new devices: add them to firmwares.rb
* rerun "jekyll build" and update firmware.rb until no more warnings occur
* git-commit and -push changes
* Update https://luebeck.freifunk.net/: Add a new blog entry to inform about the new firmware release
* Inform via Twitter about the new firmware release
* Increment DEFAULT_GLUON_RELEASE in https://github.com/freifunk-luebeck/site-ffhl/blob/master/site.mk
## Version Numbering
``0.10.5-3 - 0.x[.y]-z``
* **x:** major version number
* **y:** minor version number
* **z:** build version number
***The major version number (x) is increased:***
* for releases with a new Gluon major version number (e.g. Gluon v2018.1.3 -> Gluon v2018.2) and/or
* for releases with significant changes to site.conf and/or site.mk
If the major version number is increased than any previous minor version number is removed. (**ok:** 0.9.5 -> 0.10, **not ok:** 0.9.5 -> 0.10.1)
***The minor version number (y) is increased or added:***
* for releases with a new Gluon minor version number (e.g. Gluon v2018.1 -> Gluon v2018.1.3), with only small or no changes to site.conf or site.mk
***The build version number (z) is increased:***
* if a beta rollout was not satisfactory
After a stable release/rollout with a particular build version number, it is not increased further. New stable releases should use a new minor and/or major version number.
# Roadmap
### v0.12
[gluon v2019.1.1](https://github.com/freifunk-gluon/gluon/commit/239c379d066b73dfc84c60ff57ed5e37a1af30c6)
- remove basic and supported_rates
- batman_adv correct version (BATMAN_IV_LEGACY)
- 5ghz outdoor mode
### v0.13
- gluon v2020.?
- Wechsel zu batman-adv 15
- Wechsel der Gateways
# Firmware
Die Freifunk-Firmware Gluon basiert auf OpenWRT. OpenWRT ist eine Linux Distribution für hauptsächlich in Netzwerkumgebungen eingesetzte Embedded Systeme.
## Download
Die aktuelle Lübecker Firmware findest du auf unserer [Mitmach-Seite](https://luebeck.freifunk.net/mitmachen.html).
Alle finalen Firmware-Images werden zudem in unserem [Firmware-Archiv](https://luebeck.freifunk.net/firmware/) gesammelt.
## Entwicklung
Kontakt: IRC [#gluon](http://en.irc2go.com/webchat/?net=hackint&room=gluon) im [hackint](http://hackint.eu/)
- [gluon](https://github.com/freifunk-gluon/gluon/)
- [gluon-docs](http://gluon.readthedocs.org/)
- [site-ffhl](https://github.com/freifunk-luebeck/site-ffhl)
# Gateways
## Übersicht
## Setup
### Dienste
# Infrstruktur
Diese Seite soll fuer uns einen kleinen Ueberblick geben. Dinge, die wir benutzen und Zugang zu haben sollten hier eingetragen werden. Falls etwas zeitweilig nicht funktioniert, sollte das auch hier stehen. Im besten Fall mit einem Hinweis, warum das so ist. Auch wer auf gerade wo Zugang hat bzw. wen man dafuer kontaktieren muss, sollte hier stehen.
---
title: "Infrastruktur"
---
# Infrastruktur
## Netzwerk
## Server
Das Freifunk Lübeck Mesh Netzwerk lässt sich auf mehreren Schichten abstrahieren.
Einerseits bauen Nodes mittels 802.11s direkt per WLAN ein Mesh Netzwerk zu nahegelegenen
Nodes oder auch per Richtfunkstrecke zu weiter entfernten auf.
| Name | Hostname | wer verwaltet den? | Kommentar |
|------------|----------------------------------------------|------------------------------------------------------------------|-----------------------------------------------------------------------|
| srv01 | srv01.luebeck.freifunk.net | linus, neoraider, magu, kaspar, nils, wupo, paul, wonka, philipp | |
| srv02 | srv02.luebeck.freifunk.net (mesh only, ipv6) | linus, paul, wonka | |
| hostentor | holstentor.mesh.ffhl.chaotikum.org | kaspar, neoraider, linus, l (?), paul, wonka | |
| muehlentor | holstentor.mesh.ffhl.chaotikum.org | neoraider, linus, kaspar, l (?), paul, wonka | |
| kaisertor | kaisertor.mesh.ffhl.chaotikum.org | linus, yuna, paul, wonka, philipp | Ist noch nicht als Gateway aktiv |
| huextertor | huextertor.mesh.ffhl.chaotikum.org | linus, zafer, paul, philipp | Ist noch nicht als Gateway aktiv |
| builder | builder.luebeck.freifunk.net (mesh only) | paul, Philipp, Linus | Da soll bald ein builder drauf laufen der uns die images builden kann |
Als Routingprotokoll wird B.A.T.M.A.N. advanced verwendet. Dieses routet auf OSI-Layer 2 und lässt damit
alle Nodes als Teil eines Switch erscheinen.
Da es zu diesem Zeitpunkt noch undenkbar ist, alle Nodes direkt per WLAN anzubinden, baut ein Node
über den Uplink (der reguläre Internetanschluss) mit Fastd eine VPN Verbindung zu einem der Gateways auf.
Damit wird es Teil des Mesh-VPN und kann alle anderen Nodes des Freifunknetzes erreichen.
## Dienste
| Name | wo laeuft das? | wer verwaltet das? |
|------------|--------------------------------|--------------------------------------------------------------------------------------------------|
| gitolite | srv01 | neoraider, nils, linus, paul, philipp |
| fastd-keys | git@srv01 | neoraider, nils, mkm, jamalaka, frank, magu, tjorven, linus, fluse, eichi, kaspar, sasette, paul |
| webiste | webiste@srv01 | neoraider, nils, mkm, magu, linus, pascal, jix, paul |
| grafana | luebeck.freifunk.net/statistik | paul, linus, Philipp |
Traffic der aus dem Freifunknetz herausgeht, wird im normalfall über die Gateways ausgeleitet um Probleme mit
der Störerhaftung zu umgehen, kann aber durch entsprechende Konfiguration auch direkt über den Uplink des
Nodes ausgehen.
### Layer2 Routing mit B.A.T.M.A.N.
B.A.T.M.A.N. (Better Approach To Mobile Adhoc Networking)
[Wikipedia](https://de.wikipedia.org/wiki/B.A.T.M.A.N.)
### Mesh-VPN mit fastd
Das Mesh-VPN verbindet einzelne Freifunkrouter, die sich nicht direkt sehen können, über das Internet miteinander.
Wird ein Knoten über den WAN-Port mit dem Internet verbunden, baut dieser eine verschlüsselte Verbindung zu unseren VPN-Gateways auf. Das sind von freiwilligen betriebene Server, die u.a. auch die getunnelten Routen ins Internet bereitstellen. In erster Linie ersetzen sie jedoch die ansonsten nötigen Richtfunkstrecken um Freifunk-"Inseln" zu verbinden.
Das VPN basiert zur Zeit auf [fastd](https://github.com/NeoRaider/fastd). fastd ist ein sehr einfacher und kleiner Tunneldaemon, der sichere Handshakes und Verschlüsselung bietet.
Um einen Freifunkknoten am Internet zu betreiben, sind folgenden Vorraussetzungen nötig:
1. Der Knoten versucht eine IP mittels DHCP zu beziehen. (Das Konfigurieren einer statischen IP ist möglich)
2. Offene Ports:
- UDP 53 (DNS) wird benötigt um die DNS Adressen der Gateways aufzulösen
- UDP 10000 (fastd) wird für die eigentliche VPN Verbindung verwendet.
Weiterhin versuchen die Knoten mittels NTP ihre Uhrzeit abzugleichen und über den WAN Port weitere Knoten zu finden. Das finden weiterer Knoten geschieht mittels Ethernet Paketen des Typs 0x4305.
Alle anderen Ports dürfen (oder sollten sogar!) gesperrt werden, um einen Zugriff aufs eigene Netzwerk völlig auszuschließen. Die Firmware der Knoten trennt die Netzwerke selber schon voneinander. Dazu werden mehrere virtuelle Netzwerkbrücken innerhalb des Knotens angelegt. Eine enthält alle Interfaces, auf denen Freifunk-Nutzdaten, (das Client WLAN mit der ESSID luebeck.freifunk.net, das VPN und die gelben LAN Ports das Knotens). Ein Routing zwischen dieser Brücke und dem WAN Port wird durch mehrere Mechanismen ausgeschlossen.
## SSH-Keys
| Name | Key |
|---------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Paul | `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMNci5346re/3QqOhjC9PW1Zo0MA47hMm2r1GcEvdgff paul@taco` |
| | `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFEE6VP2jNtotQHEdc+qyw9jHA8Z2Bj2BAwKyhH/SjRG paul@tapas` |
| yksflip | `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGFEc3u8Zffw9l7kIJRBB5p1RXHtA7LSDl6li/Zr6C1e yksflip@laptop` |
| Linus | `ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEApOTMJ+6z+x7jKeMRKj0imqdNdc65T+n8GKtNtf9KZjHf17K547JfDc0i4/SdCJO6Kud8gaoSm4YxhzOsJ/9c3GmyedvtyMJ1KFyTqd0PDOmvsgjviD4EfdENen55rYRwovKAHFgBN7vksgdcZcgVBCkApTrJelHVaHRukji7lNDNdA09qZBYkBPluPWA5MxFkntfarKzkSxdPnspkVmjSYYJ+PRiVJ5kcFv+FwjwmWjBSg8Ua5CSQ4kpUfCzXVXdnWKaaOcOqDkoIyr7/FHPNt9t35MpTjFrZ9s9o0DvPjaMW6fG6m0oq7IqBIZQR/iI8zTG+3LqkNwE0UH1gfidGrWLLNfZsP6HWKuJ6aUSaEBLBQV03wrj+9TDbCj4BiJHEUoG8rtPomsoP/kVuxvQhazJtGBvi2dY7lvirNrDdL+Cx3Po6DhTsJ4ScadWBjIiLJD4aN/k7WEp5i71du0PesyMiWlFyFlUXJh04OR7S7lD09s6m1bpNnyYXsyekJDbROckCZJCBd6Nq9JS0OekbFhGD2a9Yn9SZwl6qxsxvvadr0DoGVKBAo5VBOEsCFOZdQ9GPhBg8alQLBpjfG7M1rIP4Fq+5GYgsApq0SXP9HUXqpCTU1G3GKuaPO6dU1onJn9CxaJ/IrPzkbah7pLEtCypu2NjD0LXEFVfmzi/vm0=` |
# Infrstruktur
Diese Seite soll für uns einen kleinen Überblick geben. Dinge, die wir benutzen und Zugang zu haben sollten hier eingetragen werden. Falls etwas zeitweilig nicht funktioniert, sollte das auch hier stehen. Im besten Fall mit einem Hinweis, warum das so ist. Auch wer auf gerade wo Zugang hat bzw. wen man dafuer kontaktieren muss, sollte hier stehen.
## Server
| Name | Hostname | wer verwaltet den? | Kommentar |
|------------|----------------------------------------------|------------------------------------------------------------------|-----------------------------------------------------------------------|
| srv01 | srv01.luebeck.freifunk.net | linus, neoraider, magu, kaspar, nils, wupo, paul, wonka, philipp | |
| srv02 | srv02.luebeck.freifunk.net (mesh only, ipv6) | linus, paul, wonka | |
| hostentor | holstentor.mesh.ffhl.chaotikum.org | kaspar, neoraider, linus, l (?), paul, wonka | |
| muehlentor | holstentor.mesh.ffhl.chaotikum.org | neoraider, linus, kaspar, l (?), paul, wonka | |
| kaisertor | kaisertor.mesh.ffhl.chaotikum.org | linus, yuna, paul, wonka, philipp | Ist noch nicht als Gateway aktiv |
| huextertor | huextertor.mesh.ffhl.chaotikum.org | linus, zafer, paul, philipp | Ist noch nicht als Gateway aktiv |
| builder | builder.luebeck.freifunk.net (mesh only) | paul, philipp, Linus | Da soll bald ein builder drauf laufen der uns die images builden kann |
## Dienste
| Name | wo laeuft das? | wer verwaltet das? |
|------------|--------------------------------|--------------------------------------------------------------------------------------------------|
| gitolite | srv01 | neoraider, nils, linus, paul, philipp |
| fastd-keys | git@srv01 | neoraider, nils, mkm, jamalaka, frank, magu, tjorven, linus, fluse, eichi, kaspar, sasette, paul |
| webiste | webiste@srv01 | neoraider, nils, mkm, magu, linus, pascal, jix, paul |
| grafana | luebeck.freifunk.net/statistik | paul, linus, philipp |
## SSH-Keys
| Name | Key |
|---------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
| Paul | `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIMNci5346re/3QqOhjC9PW1Zo0MA47hMm2r1GcEvdgff paul@taco` |
| | `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFEE6VP2jNtotQHEdc+qyw9jHA8Z2Bj2BAwKyhH/SjRG paul@tapas` |
| Philipp | `ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIGFEc3u8Zffw9l7kIJRBB5p1RXHtA7LSDl6li/Zr6C1e yksflip@laptop` |
| Linus | `ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAgEApOTMJ+6z+x7jKeMRKj0imqdNdc65T+n8GKtNtf9KZjHf17K547JfDc0i4/SdCJO6Kud8gaoSm4YxhzOsJ/9c3GmyedvtyMJ1KFyTqd0PDOmvsgjviD4EfdENen55rYRwovKAHFgBN7vksgdcZcgVBCkApTrJelHVaHRukji7lNDNdA09qZBYkBPluPWA5MxFkntfarKzkSxdPnspkVmjSYYJ+PRiVJ5kcFv+FwjwmWjBSg8Ua5CSQ4kpUfCzXVXdnWKaaOcOqDkoIyr7/FHPNt9t35MpTjFrZ9s9o0DvPjaMW6fG6m0oq7IqBIZQR/iI8zTG+3LqkNwE0UH1gfidGrWLLNfZsP6HWKuJ6aUSaEBLBQV03wrj+9TDbCj4BiJHEUoG8rtPomsoP/kVuxvQhazJtGBvi2dY7lvirNrDdL+Cx3Po6DhTsJ4ScadWBjIiLJD4aN/k7WEp5i71du0PesyMiWlFyFlUXJh04OR7S7lD09s6m1bpNnyYXsyekJDbROckCZJCBd6Nq9JS0OekbFhGD2a9Yn9SZwl6qxsxvvadr0DoGVKBAo5VBOEsCFOZdQ9GPhBg8alQLBpjfG7M1rIP4Fq+5GYgsApq0SXP9HUXqpCTU1G3GKuaPO6dU1onJn9CxaJ/IrPzkbah7pLEtCypu2NjD0LXEFVfmzi/vm0=` |
# Einstieg
Alle Interessierten sollen diese Seiten bei den ersten Schritten in unserem Netzwerk helfen.
## Schnelleinstieg
Um sich nur als Nutzer im Netzwerk zu befinden, reicht es, wenn eine Verbindung mit einem Knoten in der Nähe hergestellt wird. Dafür einfach in das passende WLAN einwählen und los geht's. Dabei strahlt jeder Router ein Netz mit der ID ''luebeck.freifunk.net'' aus. Zugangsdaten werden nicht benötigt.
## Der eigene Knoten
Nach einiger Zeit oder wenn es keinen Knoten in der Nähe gibt, kommt vielleicht der Wunsch auf, einen eigenen Knoten aufzustellen. Das ist recht leicht möglich. Zunächst braucht man einen WLAN-Router, der von unserer Firmware unterstützt wird. Auf diesen spielt man dann unsere Firmware auf. Nach ein paar Minuten ist es so weit und der eigene Knoten ist einsatzbereit.
Nähere Informationen befinden sich auf dieser [Seite]({{< relref "/docs/Hardware" >}}).
## Server
Auch ganze Server können eingebunden werden. Das ist besonders dann nützlich, wenn Inhalte wie Webseiten und Ähnliches eingebracht werden sollen. Da hier schon etwas umfangreicheres Wissen nötig ist, bietet sich ein persönlicher Besuch an. Dabei helfen wir gern.
## Firmware-Entwicklung
Alle nötigen Infos zur Mitarbeit an der Firmware sind auf auf der [Firmware-Seite]({{< relref "/docs/Firmware" >}}) zusammengefasst.
# Protokolle unserer Orga-Treffen
* [[2015-04-23|protokolle_orga/2015-04-23]] OTRS + viele Kleinigkeiten
- [2015-04-23]({{< relref "2015-04-23" >}})
- [2015-07-16]({{< relref "2015-07-16" >}})
- [2015-08-20]({{< relref "2015-08-20" >}})
- [2015-09-17]({{< relref "2015-09-17" >}})
- [2015-10-15]({{< relref "2015-10-15" >}})
- [2015-11-19]({{< relref "2015-11-19" >}})
- [2019-01-17]({{< relref "2019-01-17" >}})
- [2019-02-21]({{< relref "2019-02-21" >}})
- [2019-08-15]({{< relref "2019-08-15" >}})
---
title: "Technik Kram"
---
# Netzwerk
Prinzipiell besteht das Freifunk Lübeck Mesh Netzwerk aus verschiedenen Schichten. Zum einen gibt es natürlich die WLAN-Router, die über die Luft ein WLAN Mesh-Netzwerk aufbauen und hier die Datenpakete weiterleiten.
Zum zweiten gibt es verschiedene Knoten, die kleine Wolken in Lübeck durch einen verschlüsselten Tunnel über das Internet miteinander verbinden. Wer einen schnellen Internetzugang hat, kann somit gerne seine eigene kleine Wolke bei sich zu Hause starten. Die Internetleitung wird hierbei ''nicht'' als Ausgang für andere Mesh-Nutzer ins Internet benutzt. Siehe auch: [[Mesh-VPN]].
Zum dritten gibt es verschiedene Knoten im Mesh-Netzwerk die ihre Internetleitung nicht nur für den VPN-Tunnel zur Verfügung, sondern auch anderen Benutzern direkt als Ausgang ins Internet, als sogenannter Internet-Gateway. Hierzu sollte man sich aber zuvor über die rechtlichen Konsequenzen informieren. (die Gesetzeslage ist hierbei leider auch nach dem BGH-Gerichtsurteil immernoch unklar... siehe auch: [[hier|http://freifunkstattangst.de/2010/06/17/das-wlan-urteil-des-bgh-und-seine-auswirkungen-auf-offene-netze/]] und [[hier|http://www.elektrischer-reporter.de/labor/video/235/]]) Jeder ist für seinen Knoten prinzipiell selbst verantwortlich.
[[Netzwerk:IP-Subnetze]]
## Architektur
Bisher fahren wir die [[Komplettes-Briding|http://kbu.freifunk.net/index.php/Netzwerk-Konfiguration#Komplettes_Bridging]] Strategie. Das heißt für jedes Gerät im Mesh-Netzwerk scheint alles nur wie ein großer Switch zu sein, alles ist virtuell nur einen einzigen Hop entfernt.
## DNS
Wir haben für unser Netz die TLD ffhl ausgewählt. Auf burgtor und holstentor läuft ein bind und die Zonefiles liegen vorerst auf https://github.com/MetaMeute/ffhl-dns
Bei Änderungswünschen könnt ihr entweder Pull-Requests erstellen oder direkt tcatm@ccchl.de anmailen. In naher Zukunft wird es hoffentlich ein dezentrales System zur Verwaltung der Domains geben.
## Peerings
Infos zu den [[Peerings]] hält die entsprechende Seite bereit.
......@@ -2,14 +2,16 @@
headless: true
---
- [About]({{< relref "/docs/About" >}})
- [Mitmachen]({{< relref "/docs/Mitmachen" >}})
- [Infrastruktur]({{< relref "/docs/Infrastruktur" >}})
- [Übersicht]({{< relref "/docs/Infrastruktur/Übersicht" >}})
- [Gateways]({{< relref "/docs/Infrastruktur/Gateways" >}})
- [IP-Netze]({{< relref "/docs/Infrastruktur/IP_netze" >}})
- [Firmware]({{< relref "/docs/Firmware" >}})
- [Release Procedure]({{< relref "/docs/Firmware/Release-Procedure" >}})
- [Roadmap]({{< relref "/docs/Firmware/Roadmap" >}})
- [Hardware]({{< relref "/docs/Hardware" >}})
- [About]({{< relref "/docs/About" >}})
- [Externe Quellen]({{< relref "/docs/About/Externe Quellen" >}})
- [Protokolle]({{< relref "/docs/Protokolle" >}})
- [FAQ]({{< relref "/docs/FAQ" >}})
- [Hilfe]({{< relref "/docs/hilfe" >}})
......
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment