FunkFeuer Wiki - Benutzerbeiträge [de]

Regionen/Wien/MapSpecialConfig

2022-07-28T12:19:53Z

Pocki:

#
# Dies ist ein Dokument, das stündlich von der Map (https://map.funkfeuer.at/wien) abgerufen wird
# und bestimmten Knoten & Links Besonderheiten zuweist (Syntax weiter unten)
#
# Bitte beachte beim Editieren, dass jede Zeile mit einem Leerzeichen zur korrekten Darstellung beginnen muss.
#
# Kommentare:
# # das Kommentar beginnt ab # und gilt für die ganze Zeile
# // das Kommentar beginnt ab // und gilt für die ganze Zeile
# /* das Kommentar gilt nur in diesem Bereich */
#
#
# Syntax:
# (alle case-sensitive)
# Aufgrund des Datenschutzes kann statt des Knotennamens auch die Node-ID angegeben werden (siehe Map)
#
# node NodeName 5ghzbackbone // der Knoten namens "NodeName" ist ein wichtiger teil des 5GHz Backbones, wird mit grünem Marker dargestellt
# node NodeName tunnelmaster // ??
#
#
# link NodeA NodeB ethernet [static] // der Knoten "NodeA" hat zu "NodeB" eine Kabelverbindung, graue Linie
# link NodeA NodeB 5ghz [static] // der Knoten "NodeA" hat zu "NodeB" eine 5GHz (Highspeed) Verbindung, grüne Linie
# link NodeA NodeB tunnel [static] // der Knoten "NodeA" hat zu "NodeB" einen Tunnel, blaue Linie
#
# die Option static bedeutet, dass der Link auch angezeigt wird,
# wenn es keine OLSR Verbindung zwischen den 2 Knoten gibt und sollte normalerweise nicht verwendet werden.
#

#backbone wired
link nig-bb nessus-bb ethernet static
link nig-bb falke-bb ethernet static
link nig-bb anexia-bb ethernet static

#roofnode internal wired
link nig-bb nig ethernet
link nessus-bb nessus ethernet
link nessus-bb tunnel ethernet
link falke-bb 2345falke ethernet
link anexia-bb anexia ethernet

#roofnodes
node krypta-bb 5ghzbackbone
node nig-bb 5ghzbackbone
node nessus-bb 5ghzbackbone
node falke-bb 5ghzbackbone
node anexia-bb 5ghzbackbone

#pocki hide special configured link
link 2718 2756 hide
link 2718 3031 hide

Regionen/Wien/MapSpecialConfig

2022-02-24T10:01:11Z

Pocki:

Regionen/Wien/MapSpecialConfig

2022-02-24T09:24:33Z

Pocki:

Regionen/Wien/MapSpecialConfig

2022-02-24T07:41:02Z

Pocki:

#
# Dies ist ein Dokument, das stündlich von der Map (https://map.funkfeuer.at/wien) abgerufen wird
# und bestimmten Knoten & Links Besonderheiten zuweist (Syntax weiter unten)
#
# Bitte beachte beim Editieren, dass jede Zeile mit einem Leerzeichen zur korrekten Darstellung beginnen muss.
#
# Kommentare:
# # das Kommentar beginnt ab # und gilt für die ganze Zeile
# // das Kommentar beginnt ab // und gilt für die ganze Zeile
# /* das Kommentar gilt nur in diesem Bereich */
#
#
# Syntax:
# (alle case-sensitive)
# Aufgrund des Datenschutzes kann statt des Knotennamens auch die Node-ID angegeben werden (siehe Map)
#
# node NodeName 5ghzbackbone // der Knoten namens "NodeName" ist ein wichtiger teil des 5GHz Backbones, wird mit grünem Marker dargestellt
# node NodeName tunnelmaster // ??
#
#
# link NodeA NodeB ethernet [static] // der Knoten "NodeA" hat zu "NodeB" eine Kabelverbindung, graue Linie
# link NodeA NodeB 5ghz [static] // der Knoten "NodeA" hat zu "NodeB" eine 5GHz (Highspeed) Verbindung, grüne Linie
# link NodeA NodeB tunnel [static] // der Knoten "NodeA" hat zu "NodeB" einen Tunnel, blaue Linie
#
# die Option static bedeutet, dass der Link auch angezeigt wird,
# wenn es keine OLSR Verbindung zwischen den 2 Knoten gibt und sollte normalerweise nicht verwendet werden.
#

#backbone wired
link nig-bb nessus-bb ethernet static
link nig-bb falke-bb ethernet static
link nig-bb anexia-bb ethernet static

#roofnode internal wired
link nig-bb nixroof ethernet
link nessus-bb nessus ethernet
link nessus-bb tunnel ethernet
link falke-bb 2345falke ethernet
link anexia-bb anexia ethernet

#roofnodes
node krypta-bb 5ghzbackbone
node nig-bb 5ghzbackbone
node nessus-bb 5ghzbackbone
node falke-bb 5ghzbackbone
node anexia-bb 5ghzbackbone

#pocki hide special configured link
link wehr24 luxi122home hide

Regionen/Wien/MapSpecialConfig

2022-02-24T07:39:08Z

Pocki:

#
# Dies ist ein Dokument, das stündlich von der Map (https://map.funkfeuer.at/wien) abgerufen wird
# und bestimmten Knoten & Links Besonderheiten zuweist (Syntax weiter unten)
#
# Bitte beachte beim Editieren, dass jede Zeile mit einem Leerzeichen zur korrekten Darstellung beginnen muss.
#
# Kommentare:
# # das Kommentar beginnt ab # und gilt für die ganze Zeile
# // das Kommentar beginnt ab // und gilt für die ganze Zeile
# /* das Kommentar gilt nur in diesem Bereich */
#
#
# Syntax:
# (alle case-sensitive)
# Aufgrund des Datenschutzes kann statt des Knotennamens auch die Node-ID angegeben werden (siehe Map)
#
# node NodeName 5ghzbackbone // der Knoten namens "NodeName" ist ein wichtiger teil des 5GHz Backbones, wird mit grünem Marker dargestellt
# node NodeName tunnelmaster // ??
#
#
# link NodeA NodeB ethernet [static] // der Knoten "NodeA" hat zu "NodeB" eine Kabelverbindung, graue Linie
# link NodeA NodeB 5ghz [static] // der Knoten "NodeA" hat zu "NodeB" eine 5GHz (Highspeed) Verbindung, grüne Linie
# link NodeA NodeB tunnel [static] // der Knoten "NodeA" hat zu "NodeB" einen Tunnel, blaue Linie
#
# die Option static bedeutet, dass der Link auch angezeigt wird,
# wenn es keine OLSR Verbindung zwischen den 2 Knoten gibt und sollte normalerweise nicht verwendet werden.
#

#backbone wired
#link nig-bb krypta-bb ethernet static
link nig-bb nessus-bb ethernet static
link nig-bb falke-bb ethernet static
link nig-bb anexia-bb ethernet static

#roofnode internal wired
#link krypta-bb kryptaroof ethernet
link nig-bb nixroof ethernet
link nessus-bb nessus ethernet
link nessus-bb tunnel ethernet
link falke-bb 2345falke ethernet
link anexia-bb anexia ethernet

#roofnodes
node krypta-bb 5ghzbackbone
node nig-bb 5ghzbackbone
node nessus-bb 5ghzbackbone
node falke-bb 5ghzbackbone
node anexia-bb 5ghzbackbone

node kryptaroof 5ghzbackbone

link wehr24 luxi122home hide

Regionen/Wien/MapSpecialConfig

2022-02-24T07:28:24Z

Pocki:

#
# Dies ist ein Dokument, das stündlich von der Map (https://map.funkfeuer.at/wien) abgerufen wird
# und bestimmten Knoten & Links Besonderheiten zuweist (Syntax weiter unten)
#
# Bitte beachte beim Editieren, dass jede Zeile mit einem Leerzeichen zur korrekten Darstellung beginnen muss.
#
# Kommentare:
# # das Kommentar beginnt ab # und gilt für die ganze Zeile
# // das Kommentar beginnt ab // und gilt für die ganze Zeile
# /* das Kommentar gilt nur in diesem Bereich */
#
#
# Syntax:
# (alle case-sensitive)
# Aufgrund des Datenschutzes kann statt des Knotennamens auch die Node-ID angegeben werden (siehe Map)
#
# node NodeName 5ghzbackbone // der Knoten namens "NodeName" ist ein wichtiger teil des 5GHz Backbones, wird mit grünem Marker dargestellt
#
#
# link NodeA NodeB ethernet [static] // der Knoten "NodeA" hat zu "NodeB" eine Kabelverbindung, graue Linie
# link NodeA NodeB 5ghz [static] // der Knoten "NodeA" hat zu "NodeB" eine 5GHz (Highspeed) Verbindung, grüne Linie
# link NodeA NodeB tunnel [static] // der Knoten "NodeA" hat zu "NodeB" einen Tunnel, blaue Linie
#
# die Option static bedeutet, dass der Link auch angezeigt wird,
# wenn es keine OLSR Verbindung zwischen den 2 Knoten gibt und sollte normalerweise nicht verwendet werden.
#

#backbone wired
#link nig-bb krypta-bb ethernet static
link nig-bb nessus-bb ethernet static
link nig-bb falke-bb ethernet static
link nig-bb anexia-bb ethernet static

#roofnode internal wired
#link krypta-bb kryptaroof ethernet
link nig-bb nixroof ethernet
link nessus-bb nessus ethernet
link nessus-bb tunnel ethernet
link falke-bb 2345falke ethernet
link anexia-bb anexia ethernet

#roofnodes
node krypta-bb 5ghzbackbone
node nig-bb 5ghzbackbone
node nessus-bb 5ghzbackbone
node falke-bb 5ghzbackbone
node anexia-bb 5ghzbackbone

node kryptaroof 5ghzbackbone

link wehr24 luxi122home hide

Services

2021-04-16T11:38:30Z

Pocki: Links korrigiert

*'''[[Services/Organisation|Organisation]]'''

*'''[https://portal.funkfeuer.at/wien/ Portal Wien (Redeemer, Frontend Benutzerdatenbank)]''' ''Stammdaten-, Node- und IP-Adressverwaltung ''
*'''[https://forum.funkfeuer.at/ Forum]'''

*'''[http://lists.funkfeuer.at/mailman/listinfo Mailinglisten]'''

*'''[[Projekte/Housing]]'''

*'''[[5V/8W_Housing]]''' AKA [[Projekte/Housing/EmbeddedRack|Projekte/Housing/'''EmbeddedRack''']]

*'''[http://gallery.funkfeuer.at/ Gallery]'''

*'''Tunnelserver''' [[Services/Organisation/Tunnelserver|Weiterführende Infos]]
**'''[https://tunnel.funkfeuer.at/ Tunnelserver StatusInfo] ([https://tunnel.wien.funkfeuer.at/openvpn3-1.php neu] [https://tunnel.wien.funkfeuer.at/openvpnplain.php alt] [https://tunnel.funkfeuer.at/dash/ graphisch])''' ''der OpenVPN-Tunnel Clients im Netz von FunkFeuer-Wien: Suidao''

*'''Weathermaps''' ''zeigen Auslastung und aktuelle Trends unserer Infrastruktur'':
**'''[https://nms.bb.funkfeuer.at/plugins/Weathermap/output/bbcoreint-bw.png Backbone-Core-Intern]''' ''an der physischen Struktur angelehnt''
**'''[https://nms.bb.funkfeuer.at/plugins/Weathermap/output/the4.png The-4-Zones]''' ''nach logischem Netzwerkaufbau orientiert''

*'''[https://lg.bb.funkfeuer.at Backbone Routing]''' ''bird looking glass ermöglicht traceroute''
*'''[http://smokeping.funkfeuer.at/ Smokeping]''' ''Netzwerklatenzübersicht, aufgrund Hardwaredefekt temporär offline''
*'''[[Benutzer:Pocki#Privates_Monitoring|Netzwerkstatus (Monitoring von OLSR, Routen, Uptime)]]'''
*'''[https://atlas.ripe.net/probes/?search=as35492&status=&af=&country= RIPE ATLAS Probes]''' ''messen Netzwerkverfügbarkeit und Konnektivität''

*'''[https://voip.funkfeuer.at VoIP Telefonie]''' ''im Netz von FunkFeuer-Wien''
*'''[http://download.funkfeuer.at Downloadbereich]''' FunkFeuer-CI

*'''[[Services/Security]]'''
*'''[[Services/Safety]]'''
*'''[[Services/DNS]]'''

Services/Organisation/Core Infrastruktur/Server

2020-08-18T12:18:45Z

Pocki: /* Core Server */

== Core Server ==

{| class="wikitable"
! scope="col"| Hostname
! scope="col"| Location
! scope="col"| IP-Adresse
! scope="col"| Virtuelle Maschinen
! scope="col"| Maintainer
! scope="col"| Kommentar
|-
| [[Services/Organisation/Core Infrastruktur/Server/deepthought|deepthought]]
| [[Projekte/Housing|Housing/VKM]]
| 78.41.116.45  2a02:60:1:1::45
| lintilla hog eddie dave vogon treebeard?
| ?
|
|-
| [[Services/Organisation/Core Infrastruktur/Server/dwarf|dwarf]]
| [[Projekte/Housing|Housing/VKM]]
| 2a02:60:1:1::3a
| ?
| ?
|
|-
| [[Services/Organisation/Core Infrastruktur/Server/ford|ford]]
| Nessus NDC2
| 78.41.115.242 2a02:60:1:1::99
| garkbit-[[Services/Organisation/Forum|Forum]], [[Services/Organisation/VoIP|VoIP]], publicweb-[[Services/Organisation/Wiki|Wiki]], texas magician lg03krypta narya nenya vilya prince map emily, desiato hotspot s223 s231
| ?
| [https://lists.funkfeuer.at/pipermail/wien/2020-July/013460.html RAID-Check] (jeden ersten Sonntag im Monat), Xen-Virtualisierung
|-
| [[Services/Organisation/Core Infrastruktur/Server/machine|machine]]
| Nessus NDC2
| 193.238.159.36 2a02:61:0:ff:5054:ff:fef3:4696
| [[Services/Organisation/Tunnelserver|suidao/Tunnel]]
| [[Benutzer:erich|Erich N. Pekarek]], [[Benutzer:vchrizz|Christoph Lösch]], [[Benutzer:Pocki|Christian Pock]], [[Benutzer:damadmai|Daniel A. Maierhofer]]
| TS2018
|-
| [[Services/Organisation/Core Infrastruktur/Server/vogsphere|vogsphere]]
| [[Projekte/Housing|Housing/VKM]]
| 78.41.115.193 2a02:60:1:1::55
| caveman jeltz
| ?
|
|-
|}

Services/Organisation/Core Infrastruktur/Server

2020-08-18T07:57:10Z

Pocki: /* Core Server */

== Core Server ==

{| class="wikitable"
! scope="col"| Hostname
! scope="col"| Location
! scope="col"| IP-Adresse
! scope="col"| Virtuelle Maschinen
! scope="col"| Maintainer
! scope="col"| Kommentar
|-
| [[Services/Organisation/Core Infrastruktur/Server/deepthought|deepthought]]
| [[Projekte/Housing|Housing/VKM]]
| 78.41.116.45  2a02:60:1:1::45
| lintilla hog eddie dave vogon treebeard?
| ?
|
|-
| [[Services/Organisation/Core Infrastruktur/Server/dwarf|dwarf]]
| [[Projekte/Housing|Housing/VKM]]
| 2a02:60:1:1::3a
| ?
| ?
|
|-
| [[Services/Organisation/Core Infrastruktur/Server/ford|ford]]
| Nessus NDC2
| 78.41.115.242 2a02:60:1:1::99
| garkbit-[[Services/Organisation/Forum|Forum]], [[Services/Organisation/VoIP|VoIP]], publicweb-[[Services/Organisation/Wiki|Wiki]], texas magician lg03krypta narya nenya vilya prince map emily, desiato hotspot s223 s231
| ?
| [[https://lists.funkfeuer.at/pipermail/wien/2020-July/013460.html |RAID-Check]] (jeden ersten Sonntag im Monat), Xen-Virtualisierung
|-
| [[Services/Organisation/Core Infrastruktur/Server/machine|machine]]
| Nessus NDC2
| 193.238.159.36 2a02:61:0:ff:5054:ff:fef3:4696
| [[Services/Organisation/Tunnelserver|suidao/Tunnel]]
| [[Benutzer:erich|Erich N. Pekarek]], [[Benutzer:vchrizz|Christoph Lösch]], [[Benutzer:Pocki|Christian Pock]], [[Benutzer:damadmai|Daniel A. Maierhofer]]
| TS2018
|-
| [[Services/Organisation/Core Infrastruktur/Server/vogsphere|vogsphere]]
| [[Projekte/Housing|Housing/VKM]]
| 78.41.115.193 2a02:60:1:1::55
| caveman jeltz
| ?
|
|-
|}

Services/Organisation/BaseMap

2020-07-16T07:10:51Z

Pocki: /* Aufbereitung der Map-Daten */

== Beschreibung ==

Die BaseMap war lange Zeit ''die'' Map des Funknetzes unter [https://map.funkfeuer.at/wien/ map.funkfeuer.at/wien]. Diese Map zeigt '''nur IPv4-Adressen und olsrd(v1)''' Topologie. 4in6-IPv4-Adressen aus dem v642-Konzept (werden über olsrd2/IPv6 geroutet) zeigt die Map bei den zugeordneten Knoten nur an. Die nötigen Daten werden aus der Postgres-Datenbank des Redeemers und einer lokal laufenden olsrd-Instanz geholt und miteinander verschnitten. Die Darstellung erfolgt auf einer GoogleMaps Karte und ist in JavaScript umgesetzt.

Gehostet wird der Webservice im Rechnenzentrum von Nessus.

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

==== Login ====
Ohne Login kann die Map nur anonymisierte Knoten ohne IP-Adressen darstellen, deren Geokoordinaten sind gerastert/gerundet.

Ohne Login und aufgerufen von einer FunkFeuer-IP-Adresse kann man die exakten Locations der Knoten sehen und auch die Funktion "Show all Links" aktivieren. Ein Textbaustein "precise locations on" signalisiert diesen Zustand in der Login-Box.

Erst nach einem Login mit einem gültigem Redeemer-User können die kompletten Daten eingesehen werden, darunter Knotennamen und Inhaber/Betreiber-Kontaktdaten und IP-Adressen.

Mittels der Checkbox "Remember" bei den Login-Feldern kann der Login für 30 Tage über ein Browsercookie "behalten" werden. Bei jedem Map-Besuch fängt dieser 30-Tage-Zähler neu an. Ohne dieser Funktion wird der Login nach dem Auslaufen der Session innerhalb von 24min verworfen. Durch Ausloggen wird auch der AutoLogin im betroffenen Browser wieder verworfen. Eine Änderung des Redeemer-Passworts macht alle vorhandenen AutoLogin-Cookies ungültig.

==== Aufbereitung der Map-Daten ====
Die Datenquelle für die Map liefert data.php: es verschneidet die OLSR-Topologie vom lokal laufenden olsrd (txtinfo-plugin) und verschneidet vorkommende IP-Adressen mit den Redeemer-Daten.

Zusätzlich beachtet werden Einstellungen in config.mine.php (IP-Autologin, Definition Tunnel-Knoten, Ignorieren von Tunnellinks z.B. für Roofnodes) und [[#MapSpecialConfig|MapSpecialConfig]].

===== URL-Parameter von data.php =====
data.php kann auch als API für andere Dienste genutzt werden, sofern der Request mittels Login authorisiert ist. Über den url-parameter "format" kann der Output gewählt werden:

* https://map.funkfeuer.at/wien/data.php?format=xml (default)
* https://map.funkfeuer.at/wien/data.php?format=kml
* https://map.funkfeuer.at/wien/data.php?format=ip6 liefert node/device/ip6/ip6type/nodeid
* https://map.funkfeuer.at/wien/data.php?format=nodeids liefert nodeid/lat/lon/nodename/status/ips|names von map-deaktivierten Knoten
* https://map.funkfeuer.at/wien/data.php?format=nodecsv liefert lat/lon/knoten_namen/status von Knoten mit validen Geokoordinaten, ohne Potential-Nodes
* https://map.funkfeuer.at/wien/data.php?format=visjs
* https://map.funkfeuer.at/wien/data.php?format=debug

==== Darstellung der Map ====
* Mögliche Ansichten: GoogleMaps -> Terrain (default), Roadmap, Satellite, Hybrid
* Google Places Searchbox erlaubt schnelles Finden von Orten, Strassen, POIs
* Box "Nodes"
** "Link dieser Ansicht" öffnet ein Popup mit URI zum Kopieren. Aufruf dieser URI sollte die aktuelle Ansicht wiederherstellen: Zoomlevel, MapType, Location
** Download KML: Ermöglicht den Datenexport z.B. zum Öffnen in Google Earth
** Anzahl Nodes gesamt, Anzahl Nodes online (=zumindest eine aktive IP auf einem Node)
** Liste der Nodes - entspricht der Auswahl aus der Box "Ansicht" und/oder dem Suchfeld. Ein Klick auf den Nodennamen scrollt an dessen Position und öffnet die InfoBox des Nodes
** Suchfeld: Suche nach Nodenamen oder Node-ID
** Daten neu laden: aktualisiert die Datenbasis aus OLSR und Redeemer
* Box "Ansicht"
** Filtern die gezeigten Nodes nach
*** Aktive (Nodes mit mindestens einer aktiven IP-Adresse)
*** Inaktive (Nodes, deren IP-Adressen alle offline sind, jedoch früher mal zumindest eine davon aktiv war)
*** Im Aufbau (Nodes, deren IP-Adressen alle offline sind und keine IP seit deren Anlage beim Node jemals aktiv war)
*** Interessiert (Nodes ohne angelegte IP-Adresse)
** Zeige Speziallinks: ein/ausblenden der statisch verwalteten Links (siehe MapSpecialConfig)
** Zeige alle Links: ein/ausblenden aller aktiven Verbindungen. Tunnel-Links werden in diesem Fall nicht gezeigt.
** Zeige Nodenamen: ein/ausblenden der Nodenamen unterhalb der Marker ab einem gewissen Zoomlevel
** Link threshold: blendet Links mit ETX schlechter als dieser Wert aus
* Mausoptionen
** Node hinzufügen
** Messwerkzeig

===== Nodes =====

Die Map zeigt nur Knoten, die im Redeemer für die Map aktiviert sind und valide Geokoordinaten haben.

Zusätzlich zu den Node-Farben laut Box "Ansicht" können aktive Knoten folgende Farben haben:
* grün: aktiver Knoten, der laut MapSpecialConfig als 5ghz-Node definiert ist. Seit 5ghz im Mesh quasi-standard ist, sind die Roofnode-Knoten als grüne Nodes verzeichnet, um diese schnell zu erkennen
* blau: Knoten mit aktivem OpenVPN-Link zum Tunnelserver

Node-Marker werden in 3 unterschiedliche Größen dargestellt, um die Bedeutung im Mesh anhand der Anzahl aktiver, nodeübergreifender OLSR-Links zu zeigen. Je größer, desto mehr Nchbarn hat der Node:
* klein: Knoten mit nur 1 (einen) oder keinem aktiven Link zu einem anderen Knoten
* mittel: Konten mit 2 bis 4 Nachbarn
* gross: Knoten mit 5 oder mehr Nachbarknoten

Bei überlappenden Nodemarkern werden aktive Knoten vor inaktiven gezeigt, kleinere vor größeren - um eine bestmögliche Klickbarkeit zu erlauben.

Bei MouseOver zu einem Nodemarker wird dessen Name (oder ohne Login: dessen NodeID) angezeigt und dessen Links eingeblendet.

Bei Klick auf einen Nodemarker öffnet sich dessen InfoBox. Es ist immer nur eine InfoBox gleichzeitig offen.

===== Node-InfoBox =====

* Name (inkl. Link zur Mapansicht dieses Nodes)
* Link zum Smokeping (falls für den Node zumindest bei einem Device aktiviert)
* NodeID in dezimal (z.B. fürs Ableiten des Management-Netzwerks) und hexadezimal (z.B. fürs Ableiten des IPv6-Prefixes für den Userblock dieses Knotens)
* Knotentyp: normal, 5ghz (grün), tunnel (blau)
* Geokoordinaten
* Inhaber, Adresse des Inhaber-Users, E-Mail-Adresse
* Technischer Kontakt, E-Mail-Adresse

====== Devices ======
Devices (Anzahl aller registrierten IPv4-Adressen)

* farbige Statusbox, signalisiert den Onlinezustand
** grün: online - olsrd aktiv und verbunden
** grün-hell: MID eines aktiven olsrd
** grün-gelb: HNA eines aktiven olsrd
** gelb: HNA subnet eines aktiven olsrd
** orange: online ohne olsrd, ohne HNA, ohne MID
** gelb: unbekannte HNA oder HNA als Subnet
** rot: nicht erreichbar
** grau: bisher nie online gewesen
* Device-Name
** MouseOver beschränkt die Links auf der Map auf jene dieses olsrd Routers
** MouseOver zeigt die IP-Adresse des Devices als Title
** Klick öffnet die URL laut FQDN
* Hinweis in Klammern
** online: olsrd aktiv und verbunden
** Datum mit Uhrzeit: IP war zu diesem Zeitpunkt zuletzt erreichbar
** Datum ohne Uhrzeit: IP ist nicht (mehr) erreichbar, am angegebenen Tag wurde diese IP als HNA angekündigt
** erstellt: datum
** HNA: diese IP wird auf einem anderen Knoten als HNA angekündigt
* eventuelles Warnsymbol <!>: die IP und MID/HNA gehören zu unterschiedichen Knoten!
* von einem olsr-Router abhängige Devices werden eingerückt:
** MID: die IP wird vom oslrd-Router auf einem sekundären Interface verwendet, für das olsr ebenfalls aktiv ist
** HNA: die IP wird vom olsrd-Router als Hostroute angekündigt.
** HNA (gelb): die IP ist Teil eines angekündigten Subnets (nur /28 bis /31 werden aufgelöst)
** >: IP gehört zum oberhalb genannten HNA-Subnet.

====== Links ======
Links werden gezählt:
* Total: von jedem lokalen olsrd-Router zu jedem olsrd-Router eines Nachbarknotens
* Nodes: von diesem Knoten zu einem Nachbarknoten
* Knoteninterne Links werden nicht mitgezählt und auch nicht in der Map dargestellt.

Pro olsrd aktivem Device wird angezeigt:
* Name des lokalen olsr Devices
* in Klammer: Anzahl der Links zu Nachbarknoten-Devices
* verlinktes Nachbarknoten-Device
** MouseOver lässt den Link in der Map blinken
** klick springt zum betroffenen Nachbarknoten und öffnet dessen InfoBox
* ETX Costs numerisch und als farbige Box

===== Node hinzufügen =====
Wenn dieses Tool ausgewählt wurde, wird bei einem Klick auf die Map ein neuer Marker hinzugefügt. An dieser Position kann dann mittels "neuen Node registrieren..." einen neuen Konten im Redeemer erstellen: nötig ist nur nochmals der Redeemer-Login und der Knotenname.

Nach erfolgreichem Abspeichern wird die Anzeige von Knoten im Status "Interessiert" aktiviert und die Mapdaten neu geladen, sodass der neue Node sichtbar wird.

===== Messwerkzeug =====
Mittels zwei freien Klicks in die Map kann zwischen den zwei Positionen die Distanz und Windrichtung (in Grad und als Kürzel) dargestellt werden.

Doppelklick auf einen der beiden Mess-Marker entfernt die Anzeige und macht eine neuerliche Messung möglich.

===== URL-Parameter der BaseMap =====

* Direkt zu einem Node mit InfoBox: https://map.funkfeuer.at/wien/#shownode=2345donau
* Direkt zu einer Location: https://map.funkfeuer.at/wien/#lat=48.21393926636411&lon=16.35928346180073&zoom=18&map=terrain

==== MapSpecialConfig ====

Einige Zustände, die für die Darstellung relevant sind, können aus der Topologie nicht erkannt werden. Folgende Wiki-Page wird in der Datenaufbereitung für die Map als Spezial-Steuerung abgerufen: [[Regionen/Wien/MapSpecialConfig]]

== Abhängigkeiten ==
Die Datenquelle der Map wird auch von anderen Applikationen genutzt.

Services/Organisation/BaseMap

2020-07-15T12:24:30Z

Pocki:

== Beschreibung ==

Die BaseMap war lange Zeit ''die'' Map des Funknetzes unter [https://map.funkfeuer.at/wien/ map.funkfeuer.at/wien]. Diese Map zeigt '''nur IPv4-Adressen und olsrd(v1)''' Topologie. 4in6-IPv4-Adressen aus dem v642-Konzept (werden über olsrd2/IPv6 geroutet) zeigt die Map bei den zugeordneten Knoten nur an. Die nötigen Daten werden aus der Postgres-Datenbank des Redeemers und einer lokal laufenden olsrd-Instanz geholt und miteinander verschnitten. Die Darstellung erfolgt auf einer GoogleMaps Karte und ist in JavaScript umgesetzt.

Gehostet wird der Webservice im Rechnenzentrum von Nessus.

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

==== Login ====
Ohne Login kann die Map nur anonymisierte Knoten ohne IP-Adressen darstellen, deren Geokoordinaten sind gerastert/gerundet.

Ohne Login und aufgerufen von einer FunkFeuer-IP-Adresse kann man die exakten Locations der Knoten sehen und auch die Funktion "Show all Links" aktivieren. Ein Textbaustein "precise locations on" signalisiert diesen Zustand in der Login-Box.

Erst nach einem Login mit einem gültigem Redeemer-User können die kompletten Daten eingesehen werden, darunter Knotennamen und Inhaber/Betreiber-Kontaktdaten und IP-Adressen.

Mittels der Checkbox "Remember" bei den Login-Feldern kann der Login für 30 Tage über ein Browsercookie "behalten" werden. Bei jedem Map-Besuch fängt dieser 30-Tage-Zähler neu an. Ohne dieser Funktion wird der Login nach dem Auslaufen der Session innerhalb von 24min verworfen. Durch Ausloggen wird auch der AutoLogin im betroffenen Browser wieder verworfen. Eine Änderung des Redeemer-Passworts macht alle vorhandenen AutoLogin-Cookies ungültig.

==== Aufbereitung der Map-Daten ====
Die Datenquelle für die Map liefert data.php: es verschneidet die OLSR-Topologie vom lokal laufenden olsrd (txtinfo-plugin) und verschneidet vorkommende IP-Adressen mit den Redeemer-Daten.

===== URL-Parameter von data.php =====
data.php kann auch als API für andere Dienste genutzt werden, sofern der Request mittels Login authorisiert ist. Über den url-parameter "format" kann der Output gewählt werden:

* https://map.funkfeuer.at/wien/data.php?format=xml (default)
* https://map.funkfeuer.at/wien/data.php?format=kml
* https://map.funkfeuer.at/wien/data.php?format=ip6 liefert node/device/ip6/ip6type/nodeid
* https://map.funkfeuer.at/wien/data.php?format=nodeids liefert nodeid/lat/lon/nodename/status/ips|names von map-deaktivierten Knoten
* https://map.funkfeuer.at/wien/data.php?format=nodecsv liefert lat/lon/knoten_namen/status von Knoten mit validen Geokoordinaten, ohne Potential-Nodes
* https://map.funkfeuer.at/wien/data.php?format=visjs
* https://map.funkfeuer.at/wien/data.php?format=debug

==== Darstellung der Map ====
* Mögliche Ansichten: GoogleMaps -> Terrain (default), Roadmap, Satellite, Hybrid
* Google Places Searchbox erlaubt schnelles Finden von Orten, Strassen, POIs
* Box "Nodes"
** "Link dieser Ansicht" öffnet ein Popup mit URI zum Kopieren. Aufruf dieser URI sollte die aktuelle Ansicht wiederherstellen: Zoomlevel, MapType, Location
** Download KML: Ermöglicht den Datenexport z.B. zum Öffnen in Google Earth
** Anzahl Nodes gesammt, Anzahl Nodes online (=zumindest eine aktive IP auf einem Node)
** Liste der Nodes - entspricht der Auswahl aus der Box "Ansicht" und/oder dem Suchfeld. Ein Klick auf den Nodennamen scrollt an dessen Position und öffnet die InfoBox des Nodes
** Suchfeld: Suche nach Nodenamen oder Node-ID
** Daten neu laden: aktualisiert die Datenbasis aus OLSR und Redeemer
* Box "Ansicht"
** Filtern die gezeigten Nodes nach
*** Aktive (Nodes mit mindestens einer aktiven IP-Adresse)
*** Inaktive (Nodes, deren IP-Adressen alle offline sind, jedoch früher mal zumindest eine davon aktiv war)
*** Im Aufbau (Nodes, deren IP-Adressen alle offline sind und keine IP seit deren Anlage beim Node jemals aktiv war)
*** Interessiert (Nodes ohne angelegte IP-Adresse)
** Zeige Speziallinks: ein/ausblenden der statisch verwalteten Links (siehe MapSpecialConfig)
** Zeige alle Links: ein/ausblenden aller aktiven Verbindungen. Tunnel-Links werden in diesem Fall nicht gezeigt.
** Zeige Nodenamen: ein/ausblenden der Nodenamen unterhalb der Marker ab einem gewissen Zoomlevel
** Link threshold: blendet Links mit ETX schlechter als dieser Wert aus
* Mausoptionen
** Node hinzufügen
** Messwerkzeig

===== Nodes =====

Die Map zeigt nur Knoten, die im Redeemer für die Map aktiviert sind und valide Geokoordinaten haben.

Zusätzlich zu den Node-Farben laut Box "Ansicht" können aktive Knoten folgende Farben haben:
* grün: aktiver Knoten, der laut MapSpecialConfig als 5ghz-Node definiert ist. Seit 5ghz im Mesh quasi-standard ist, sind die Roofnode-Knoten als grüne Nodes verzeichnet, um diese schnell zu erkennenb
* blau: Knoten mit aktivem OpenVPN-Link zum Tunnelserver

Node-Marker werden in 3 unterschiedliche Größen dargestellt, um die Bedeutung im Mesh anhand der Anzahl aktiver, nodeübergreifender OLSR-Links zu zeigen. Je größer, desto mehr Nchbarn hat der Node:
* klein: Knoten mit nur 1 (einen) oder keinem aktiven Link zu einem anderen Knoten
* mittel: Konten mit 2 bis 4 Nachbarn
* gross: Knoten mit 5 oder mehr Nachbarknoten

Bei überlappenden Nodemarkern werden aktive Knoten vor inaktiven gezeigt, kleinere vor größeren - um eine bestmögliche Klickbarkeit zu erlauben.

Bei MouseOver zu einem Nodemarker wird dessen Name (oder ohne Login: dessen NodeID) angezeigt und dessen Links eingeblendet.

Bei Klick auf einen Nodemarker öffnet sich dessen InfoBox. Es ist immer nur eine InfoBox gleichzeitig offen.

===== Node-InfoBox =====

* Name (inkl. Link zur Mapansicht dieses Nodes)
* Link zum Smokeping (falls für den Node zumindest bei einem Device aktiviert)
* NodeID in dezimal (z.B. fürs Ableiten des Management-Netzwerks) und hexadezimal (z.B. fürs Ableiten des IPv6-Prefixes für den Userblock dieses Knotens)
* Knotentyp: normal, 5ghz (grün), tunnel (blau)
* Geokoordinaten
* Inhaber, Adresse des Inhaber-Users, e-Mailadresse
* Technischer Kontakt, e-Mailadresse

====== Devices ======
Devices (Anzahl aller registrierten IPv4-Adressen)

* farbige Statusbox, signalisiert den Onlinezustand
** grün: online - olsrd aktiv und verbunden
** grün-hell: MID eines aktiven olsrd
** grün-gelb: HNA eines aktiven olsrd
** gelb: HNA subnet eines aktiven olsrd
** orange: online ohne olsrd, ohne HNA, ohne MID
** gelb: unbekannte HNA oder HNA als Subnet
** rot: nicht erreichbar
** grau: bisher nie online gewesen
* Device-Name
** MouseOver beschränkt die Links auf der Map auf jene dieses olsrd Routers
** MouseOver zeigt die IP-Adresse des Devices als Title
** Klick öffnet die URL laut FQDN
* Hinweis in Klammern
** online: olsrd aktiv und verbunden
** Datum mit Uhrzeit: IP war zu diesem Zeitpunkt zuletzt erreichbar
** Datum ohne Uhrzeit: IP ist nicht (mehr) erreichbar, am angegebenen Tag wurde diese IP als HNA angekündigt
** erstellt: datum
** HNA: diese IP wird auf einem anderen Knoten als HNA angekündigt
* eventuelles Warnsymbol <!>: die IP und MID/HNA gehören zu unterschieldichen Knoten!
* von einem olsr-Router abhängige Devices werden eingerückt:
** MID: die IP wird vom oslrd-Router auf einem sekundären Interface verwendet, für das olsr ebenfalls aktiv ist
** HNA: die IP wird vom olsrd-Router als Hostroute angekündigt.
** HNA (gelb): die IP ist Teil eines angekündigten Subnets (nur /28 bis /31 werden aufgelöst)
** >: IP gehört zum oberhalb genannten HNA-Subnet.

====== Links ======
Links werden gezählt:
* Total: von jedem lokalen olsrd-Router zu jedem olsrd-Router eines Nachbarknotens
* Nodes: von diesem Knoten zu einem Nachbarknoten
* Knoteninterne Links werden nicht mitgezählt und auch nicht in der Map dargestellt.

Pro olsrd aktivem Device wird angezeigt:
* Name des lokalen olsr Devices
* in Klammer: Anzahl der Links zu Nachbarknoten-Devices
* verlinktes Nachbarknoten-Device
** MouseOver lässt den Link in der Map blinken
** klick springt zum betroffenen Nachbarknoten und öffnet dessen InfoBox
* ETX Costs numerisch und als farbige Box

===== Node hinzufügen =====
Wenn dieses Tool ausgewählt wurde, wird bei einem Klick auf die Map ein neuer Marker hinzugefügt. An dieser Position kann dann mittels "neuen Node registrieren..." einen neuen Konten im Redeemer erstellen: nötig ist nur nochmals der Redeemer-Login und der Knotenname.

Nach erfolgreichem Abspeichern wird die Anzeige von Knoten im Status "Interessiert" aktiviert und die Mapdaten neu geladen, sodass der neue Node sichtbar wird.

===== Messwerkzeug =====
Mittels zwei freien Klicks in die Map kann zwischen den zwei Positionen die Distanz und Windrichtung (in Grad und als Kürzel) dargestellt werden.

Doppelklick auf einen der beiden Mess-Marker entfernt die Anzeige und macht eine neuerliche Messung möglich.

===== URL-Parameter der BaseMap =====

* Direkt zu einem Node mit InfoBox: https://map.funkfeuer.at/wien/#shownode=2345donau
* Direkt zu einer Location: https://map.funkfeuer.at/wien/#lat=48.21393926636411&lon=16.35928346180073&zoom=18&map=terrain

==== MapSpecialConfig ====

Einige Zustände, die für die Darstellung relevant sind, können aus der Topologie nicht erkannt werden. Folgende Wiki-Page wird in der Datenaufbereitung für die Map als Spezial-Steuerung abgerufen: [[Regionen/Wien/MapSpecialConfig]]

== Abhängigkeiten ==
Die Datenquelle der Map wird auch von anderen Applikationen genutzt.

Services/Organisation/BaseMap

2020-07-15T12:21:16Z

Pocki:

== Beschreibung ==

Die BaseMap war lange Zeit ''die'' Map des Funknetzes unter [https://map.funkfeuer.at/wien/ map.funkfeuer.at/wien]. Diese Map zeigt '''nur IPv4-Adressen und olsrd(v1)''' Topologie. 4in6-IPv4-Adressen aus dem v642-Konzept (werden über olsrd2/IPv6 geroutet) zeigt die Map bei den zugeordneten Knoten nur an. Die nötigen Daten werden aus der Postgres-Datenbank des Redeemers und einer lokal laufenden olsrd-Instanz geholt und miteinander verschnitten. Die Darstellung erfolgt auf einer GoogleMaps Karte und ist in JavaScript umgesetzt.

Gehostet wird der Webservice im Rechnenzentrum von Nessus.

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

==== Login ====
Ohne Login kann die Map nur anonymisierte Knoten ohne IP-Adressen darstellen, deren Geokoordinaten sind gerastert/gerundet.

Ohne Login und aufgerufen von einer FunkFeuer-IP-Adresse kann man die exakten Locations der Knoten sehen und auch die Funktion "Show all Links" aktivieren. Ein Textbaustein "precise locations on" signalisiert diesen Zustand in der Login-Box.

Erst nach einem Login mit einem gültigem Redeemer-User können die kompletten Daten eingesehen werden, darunter Knotennamen und Inhaber/Betreiber-Kontaktdaten und IP-Adressen.

Mittels der Checkbox "Remember" bei den Login-Feldern kann der Login für 30 Tage über ein Browsercookie "behalten" werden. Bei jedem Map-Besuch fängt dieser 30-Tage-Zähler neu an. Ohne dieser Funktion wird der Login nach dem Auslaufen der Session innerhalb von 24min verworfen. Durch Ausloggen wird auch der AutoLogin im betroffenen Browser wieder verworfen. Eine Änderung des Redeemer-Passworts macht alle vorhandenen AutoLogin-Cookies ungültig.

==== Aufbereitung der Map-Daten ====
Die Datenquelle für die Map liefert data.php: es verschneidet die OLSR-Topologie vom lokal laufenden olsrd (txtinfo-plugin) und verschneidet vorkommende IP-Adressen mit den Redeemer-Daten.

===== URL-Parameter von data.php =====
data.php kann auch als API für andere Dienste genutzt werden, sofern der Request mittels Login authorisiert ist. Über den url-parameter "format" kann der Output gewählt werden:

* https://map.funkfeuer.at/wien/data.php?format=xml (default)
* https://map.funkfeuer.at/wien/data.php?format=kml
* https://map.funkfeuer.at/wien/data.php?format=ip6 liefert node/device/ip6/ip6type/nodeid
* https://map.funkfeuer.at/wien/data.php?format=nodeids liefert nodeid/lat/lon/nodename/status/ips|names von map-deaktivierten Knoten
* https://map.funkfeuer.at/wien/data.php?format=nodecsv liefert lat/lon/knoten_namen/status von Knoten mit validen Geokoordinaten, ohne Potential-Nodes

==== Darstellung der Map ====
* Mögliche Ansichten: GoogleMaps -> Terrain (default), Roadmap, Satellite, Hybrid
* Google Places Searchbox erlaubt schnelles Finden von Orten, Strassen, POIs
* Box "Nodes"
** "Link dieser Ansicht" öffnet ein Popup mit URI zum Kopieren. Aufruf dieser URI sollte die aktuelle Ansicht wiederherstellen: Zoomlevel, MapType, Location
** Download KML: Ermöglicht den Datenexport z.B. zum Öffnen in Google Earth
** Anzahl Nodes gesammt, Anzahl Nodes online (=zumindest eine aktive IP auf einem Node)
** Liste der Nodes - entspricht der Auswahl aus der Box "Ansicht" und/oder dem Suchfeld. Ein Klick auf den Nodennamen scrollt an dessen Position und öffnet die InfoBox des Nodes
** Suchfeld: Suche nach Nodenamen oder Node-ID
** Daten neu laden: aktualisiert die Datenbasis aus OLSR und Redeemer
* Box "Ansicht"
** Filtern die gezeigten Nodes nach
*** Aktive (Nodes mit mindestens einer aktiven IP-Adresse)
*** Inaktive (Nodes, deren IP-Adressen alle offline sind, jedoch früher mal zumindest eine davon aktiv war)
*** Im Aufbau (Nodes, deren IP-Adressen alle offline sind und keine IP seit deren Anlage beim Node jemals aktiv war)
*** Interessiert (Nodes ohne angelegte IP-Adresse)
** Zeige Speziallinks: ein/ausblenden der statisch verwalteten Links (siehe MapSpecialConfig)
** Zeige alle Links: ein/ausblenden aller aktiven Verbindungen. Tunnel-Links werden in diesem Fall nicht gezeigt.
** Zeige Nodenamen: ein/ausblenden der Nodenamen unterhalb der Marker ab einem gewissen Zoomlevel
** Link threshold: blendet Links mit ETX schlechter als dieser Wert aus
* Mausoptionen
** Node hinzufügen
** Messwerkzeig

===== Nodes =====

Die Map zeigt nur Knoten, die im Redeemer für die Map aktiviert sind und valide Geokoordinaten haben.

Zusätzlich zu den Node-Farben laut Box "Ansicht" können aktive Knoten folgende Farben haben:
* grün: aktiver Knoten, der laut MapSpecialConfig als 5ghz-Node definiert ist. Seit 5ghz im Mesh quasi-standard ist, sind die Roofnode-Knoten als grüne Nodes verzeichnet, um diese schnell zu erkennenb
* blau: Knoten mit aktivem OpenVPN-Link zum Tunnelserver

Node-Marker werden in 3 unterschiedliche Größen dargestellt, um die Bedeutung im Mesh anhand der Anzahl aktiver, nodeübergreifender OLSR-Links zu zeigen. Je größer, desto mehr Nchbarn hat der Node:
* klein: Knoten mit nur 1 (einen) oder keinem aktiven Link zu einem anderen Knoten
* mittel: Konten mit 2 bis 4 Nachbarn
* gross: Knoten mit 5 oder mehr Nachbarknoten

Bei überlappenden Nodemarkern werden aktive Knoten vor inaktiven gezeigt, kleinere vor größeren - um eine bestmögliche Klickbarkeit zu erlauben.

Bei MouseOver zu einem Nodemarker wird dessen Name (oder ohne Login: dessen NodeID) angezeigt und dessen Links eingeblendet.

Bei Klick auf einen Nodemarker öffnet sich dessen InfoBox. Es ist immer nur eine InfoBox gleichzeitig offen.

===== Node-InfoBox =====

* Name (inkl. Link zur Mapansicht dieses Nodes)
* Link zum Smokeping (falls für den Node zumindest bei einem Device aktiviert)
* NodeID in dezimal (z.B. fürs Ableiten des Management-Netzwerks) und hexadezimal (z.B. fürs Ableiten des IPv6-Prefixes für den Userblock dieses Knotens)
* Knotentyp: normal, 5ghz (grün), tunnel (blau)
* Geokoordinaten
* Inhaber, Adresse des Inhaber-Users, e-Mailadresse
* Technischer Kontakt, e-Mailadresse

====== Devices ======
Devices (Anzahl aller registrierten IPv4-Adressen)

* farbige Statusbox, signalisiert den Onlinezustand
** grün: online - olsrd aktiv und verbunden
** grün-hell: MID eines aktiven olsrd
** grün-gelb: HNA eines aktiven olsrd
** gelb: HNA subnet eines aktiven olsrd
** orange: online ohne olsrd, ohne HNA, ohne MID
** gelb: unbekannte HNA oder HNA als Subnet
** rot: nicht erreichbar
** grau: bisher nie online gewesen
* Device-Name
** MouseOver beschränkt die Links auf der Map auf jene dieses olsrd Routers
** MouseOver zeigt die IP-Adresse des Devices als Title
** Klick öffnet die URL laut FQDN
* Hinweis in Klammern
** online: olsrd aktiv und verbunden
** Datum mit Uhrzeit: IP war zu diesem Zeitpunkt zuletzt erreichbar
** Datum ohne Uhrzeit: IP ist nicht (mehr) erreichbar, am angegebenen Tag wurde diese IP als HNA angekündigt
** erstellt: datum
** HNA: diese IP wird auf einem anderen Knoten als HNA angekündigt
* eventuelles Warnsymbol <!>: die IP und MID/HNA gehören zu unterschieldichen Knoten!
* von einem olsr-Router abhängige Devices werden eingerückt:
** MID: die IP wird vom oslrd-Router auf einem sekundären Interface verwendet, für das olsr ebenfalls aktiv ist
** HNA: die IP wird vom olsrd-Router als Hostroute angekündigt.
** HNA (gelb): die IP ist Teil eines angekündigten Subnets (nur /28 bis /31 werden aufgelöst)
** >: IP gehört zum oberhalb genannten HNA-Subnet.

====== Links ======
Links werden gezählt:
* Total: von jedem lokalen olsrd-Router zu jedem olsrd-Router eines Nachbarknotens
* Nodes: von diesem Knoten zu einem Nachbarknoten
* Knoteninterne Links werden nicht mitgezählt und auch nicht in der Map dargestellt.

Pro olsrd aktivem Device wird angezeigt:
* Name des lokalen olsr Devices
* in Klammer: Anzahl der Links zu Nachbarknoten-Devices
* verlinktes Nachbarknoten-Device
** MouseOver lässt den Link in der Map blinken
** klick springt zum betroffenen Nachbarknoten und öffnet dessen InfoBox
* ETX Costs numerisch und als farbige Box

===== Node hinzufügen =====
Wenn dieses Tool ausgewählt wurde, wird bei einem Klick auf die Map ein neuer Marker hinzugefügt. An dieser Position kann dann mittels "neuen Node registrieren..." einen neuen Konten im Redeemer erstellen: nötig ist nur nochmals der Redeemer-Login und der Knotenname.

Nach erfolgreichem Abspeichern wird die Anzeige von Knoten im Status "Interessiert" aktiviert und die Mapdaten neu geladen, sodass der neue Node sichtbar wird.

===== Messwerkzeug =====
Mittels zwei freien Klicks in die Map kann zwischen den zwei Positionen die Distanz und Windrichtung (in Grad und als Kürzel) dargestellt werden.

Doppelklick auf einen der beiden Mess-Marker entfernt die Anzeige und macht eine neuerliche Messung möglich.

===== URL-Parameter der BaseMap =====

* Direkt zu einem Node mit InfoBox: https://map.funkfeuer.at/wien/#shownode=2345donau
* Direkt zu einer Location: https://map.funkfeuer.at/wien/#lat=48.21393926636411&lon=16.35928346180073&zoom=18&map=terrain

==== MapSpecialConfig ====

Einige Zustände, die für die Darstellung relevant sind, können aus der Topologie nicht erkannt werden. Folgende Wiki-Page wird in der Datenaufbereitung für die Map als Spezial-Steuerung abgerufen: [[Regionen/Wien/MapSpecialConfig]]

== Abhängigkeiten ==
Die Datenquelle der Map wird auch von anderen Applikationen genutzt.

Services/Organisation/BaseMap

2020-07-15T12:10:29Z

Pocki:

== Beschreibung ==

Die BaseMap war lange Zeit ''die'' Map des Funknetzes unter [https://map.funkfeuer.at/wien/ map.funkfeuer.at/wien]. Diese Map zeigt '''nur IPv4-Adressen und olsrd(v1)''' Topologie. 4in6-IPv4-Adressen aus dem v642-Konzept (werden über olsrd2/IPv6 geroutet) zeigt die Map bei den zugeordneten Knoten nur an. Die nötigen Daten werden aus der Postgres-Datenbank des Redeemers und einer lokal laufenden olsrd-Instanz geholt und miteinander verschnitten. Die Darstellung erfolgt auf einer GoogleMaps Karte und ist in JavaScript umgesetzt.

Gehostet wird der Webservice im Rechnenzentrum von Nessus.

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

==== Login ====
Ohne Login kann die Map nur anonymisierte Knoten ohne IP-Adressen darstellen, deren Geokoordinaten sind gerastert/gerundet.

Ohne Login und aufgerufen von einer FunkFeuer-IP-Adresse kann man die exakten Locations der Knoten sehen und auch die Funktion "Show all Links" aktivieren. Ein Textbaustein "precise locations on" signalisiert diesen Zustand in der Login-Box.

Erst nach einem Login mit einem gültigem Redeemer-User können die kompletten Daten eingesehen werden, darunter Knotennamen und Inhaber/Betreiber-Kontaktdaten und IP-Adressen.

Mittels der Checkbox "Remember" bei den Login-Feldern kann der Login für 30 Tage über ein Browsercookie "behalten" werden. Bei jedem Map-Besuch fängt dieser 30-Tage-Zähler neu an. Ohne dieser Funktion wird der Login nach dem Auslaufen der Session innerhalb von 24min verworfen. Durch Ausloggen wird auch der AutoLogin im betroffenen Browser wieder verworfen. Eine Änderung des Redeemer-Passworts macht alle vorhandenen AutoLogin-Cookies ungültig.

==== Aufbereitung der Map-Daten ====
Die Datenquelle für die Map liefert data.php: es verschneidet die OLSR-Topologie vom lokal laufenden olsrd (txtinfo-plugin) und verschneidet vorkommende IP-Adressen mit den Redeemer-Daten.

===== URL-Parameter von data.php =====
data.php kann auch als API für andere Dienste genutzt werden, sofern der Request mittels Login authorisiert ist. Über den url-parameter "format" kann der Output gewählt werden:

* https://map.funkfeuer.at/wien/data.php?format=xml (default)
* https://map.funkfeuer.at/wien/data.php?format=ip6
* https://map.funkfeuer.at/wien/data.php?format=nodeids

==== Darstellung der Map ====
* Mögliche Ansichten: GoogleMaps -> Terrain (default), Roadmap, Satellite, Hybrid
* Google Places Searchbox erlaubt schnelles Finden von Orten, Strassen, POIs
* Box "Nodes"
** "Link dieser Ansicht" öffnet ein Popup mit URI zum Kopieren. Aufruf dieser URI sollte die aktuelle Ansicht wiederherstellen: Zoomlevel, MapType, Location
** Anzahl Nodes gesammt, Anzahl Nodes online (=zumindest eine aktive IP auf einem Node)
** Liste der Nodes - entspricht der Auswahl aus der Box "Ansicht" und/oder dem Suchfeld. Ein Klick auf den Nodennamen scrollt an dessen Position und öffnet die InfoBox des Nodes
** Suchfeld: Suche nach Nodenamen oder Node-ID
** Daten neu laden: aktualisiert die Datenbasis aus OLSR und Redeemer
* Box "Ansicht"
** Filtern die gezeigten Nodes nach
*** Aktive (Nodes mit mindestens einer aktiven IP-Adresse)
*** Inaktive (Nodes, deren IP-Adressen alle offline sind, jedoch früher mal zumindest eine davon aktiv war)
*** Im Aufbau (Nodes, deren IP-Adressen alle offline sind und keine IP seit deren Anlage beim Node jemals aktiv war)
*** Interessiert (Nodes ohne angelegte IP-Adresse)
** Zeige Speziallinks: ein/ausblenden der statisch verwalteten Links (siehe MapSpecialConfig)
** Zeige alle Links: ein/ausblenden aller aktiven Verbindungen. Tunnel-Links werden in diesem Fall nicht gezeigt.
** Zeige Nodenamen: ein/ausblenden der Nodenamen unterhalb der Marker ab einem gewissen Zoomlevel
** Link threshold: blendet Links mit ETX schlechter als dieser Wert aus
* Mausoptionen
** Node hinzufügen
** Messwerkzeig

===== Nodes =====

Die Map zeigt nur Knoten, die im Redeemer für die Map aktiviert sind und valide Geokoordinaten haben.

Zusätzlich zu den Node-Farben laut Box "Ansicht" können aktive Knoten folgende Farben haben:
* grün: aktiver Knoten, der laut MapSpecialConfig als 5ghz-Node definiert ist. Seit 5ghz im Mesh quasi-standard ist, sind die Roofnode-Knoten als grüne Nodes verzeichnet, um diese schnell zu erkennenb
* blau: Knoten mit aktivem OpenVPN-Link zum Tunnelserver

Node-Marker werden in 3 unterschiedliche Größen dargestellt, um die Bedeutung im Mesh anhand der Anzahl aktiver, nodeübergreifender OLSR-Links zu zeigen. Je größer, desto mehr Nchbarn hat der Node:
* klein: Knoten mit nur 1 (einen) oder keinem aktiven Link zu einem anderen Knoten
* mittel: Konten mit 2 bis 4 Nachbarn
* gross: Knoten mit 5 oder mehr Nachbarknoten

Bei überlappenden Nodemarkern werden aktive Knoten vor inaktiven gezeigt, kleinere vor größeren - um eine bestmögliche Klickbarkeit zu erlauben.

Bei MouseOver zu einem Nodemarker wird dessen Name (oder ohne Login: dessen NodeID) angezeigt und dessen Links eingeblendet.

Bei Klick auf einen Nodemarker öffnet sich dessen InfoBox. Es ist immer nur eine InfoBox gleichzeitig offen.

===== Node-InfoBox =====

* Name (inkl. Link zur Mapansicht dieses Nodes)
* Link zum Smokeping (falls für den Node zumindest bei einem Device aktiviert)
* NodeID in dezimal (z.B. fürs Ableiten des Management-Netzwerks) und hexadezimal (z.B. fürs Ableiten des IPv6-Prefixes für den Userblock dieses Knotens)
* Knotentyp: normal, 5ghz (grün), tunnel (blau)
* Geokoordinaten
* Inhaber, Adresse des Inhaber-Users, e-Mailadresse
* Technischer Kontakt, e-Mailadresse

====== Devices ======
Devices (Anzahl aller registrierten IPv4-Adressen)

* farbige Statusbox, signalisiert den Onlinezustand
** grün: online - olsrd aktiv und verbunden
** grün-hell: MID eines aktiven olsrd
** grün-gelb: HNA eines aktiven olsrd
** gelb: HNA subnet eines aktiven olsrd
** orange: online ohne olsrd, ohne HNA, ohne MID
** gelb: unbekannte HNA oder HNA als Subnet
** rot: nicht erreichbar
** grau: bisher nie online gewesen
* Device-Name
** MouseOver beschränkt die Links auf der Map auf jene dieses olsrd Routers
** MouseOver zeigt die IP-Adresse des Devices als Title
** Klick öffnet die URL laut FQDN
* Hinweis in Klammern
** online: olsrd aktiv und verbunden
** Datum mit Uhrzeit: IP war zu diesem Zeitpunkt zuletzt erreichbar
** Datum ohne Uhrzeit: IP ist nicht (mehr) erreichbar, am angegebenen Tag wurde diese IP als HNA angekündigt
** erstellt: datum
** HNA: diese IP wird auf einem anderen Knoten als HNA angekündigt
* eventuelles Warnsymbol <!>: die IP und MID/HNA gehören zu unterschieldichen Knoten!
* von einem olsr-Router abhängige Devices werden eingerückt:
** MID: die IP wird vom oslrd-Router auf einem sekundären Interface verwendet, für das olsr ebenfalls aktiv ist
** HNA: die IP wird vom olsrd-Router als Hostroute angekündigt.
** HNA (gelb): die IP ist Teil eines angekündigten Subnets (nur /28 bis /31 werden aufgelöst)
** >: IP gehört zum oberhalb genannten HNA-Subnet.

====== Links ======
Links werden gezählt:
* Total: von jedem lokalen olsrd-Router zu jedem olsrd-Router eines Nachbarknotens
* Nodes: von diesem Knoten zu einem Nachbarknoten
* Knoteninterne Links werden nicht mitgezählt und auch nicht in der Map dargestellt.

Pro olsrd aktivem Device wird angezeigt:
* Name des lokalen olsr Devices
* in Klammer: Anzahl der Links zu Nachbarknoten-Devices
* verlinktes Nachbarknoten-Device
** MouseOver lässt den Link in der Map blinken
** klick springt zum betroffenen Nachbarknoten und öffnet dessen InfoBox
* ETX Costs numerisch und als farbige Box

===== Node hinzufügen =====
Wenn dieses Tool ausgewählt wurde, wird bei einem Klick auf die Map ein neuer Marker hinzugefügt. An dieser Position kann dann mittels "neuen Node registrieren..." einen neuen Konten im Redeemer erstellen: nötig ist nur nochmals der Redeemer-Login und der Knotenname.

Nach erfolgreichem Abspeichern wird die Anzeige von Knoten im Status "Interessiert" aktiviert und die Mapdaten neu geladen, sodass der neue Node sichtbar wird.

===== Messwerkzeug =====
Mittels zwei freien Klicks in die Map kann zwischen den zwei Positionen die Distanz und Windrichtung (in Grad und als Kürzel) dargestellt werden.

Doppelklick auf einen der beiden Mess-Marker entfernt die Anzeige und macht eine neuerliche Messung möglich.

===== URL-Parameter der BaseMap =====

* Direkt zu einem Node mit InfoBox: https://map.funkfeuer.at/wien/#shownode=2345donau
* Direkt zu einer Location: https://map.funkfeuer.at/wien/#lat=48.21393926636411&lon=16.35928346180073&zoom=18&map=terrain

==== MapSpecialConfig ====

Einige Zustände, die für die Darstellung relevant sind, können aus der Topologie nicht erkannt werden. Folgende Wiki-Page wird in der Datenaufbereitung für die Map als Spezial-Steuerung abgerufen: [[Regionen/Wien/MapSpecialConfig]]

== Abhängigkeiten ==
Die Datenquelle der Map wird auch von anderen Applikationen genutzt.

Projekte/v642/Konzept

2020-07-14T14:04:32Z

Pocki: /* Vorwort */

== Vorwort ==
Der Artikel enthält die erste Version des Konzepts und dient als Diskussions- und Entscheidungsgrundlage.

Das Konzept bezieht sich nicht auf die Technik der Router oder der Software der Geräte, sondern nur auf die Art der IP-Adressverwaltung.

Es soll auf jeden Fall sichergestellt werden dass die Informationen in den aktiven Komponenten nicht von den äquivalenten Informationen welche an zentraler Stelle gespeichert sind abweicht.

Es gibt zwei grundsätzlich unterschiedliche Ansätze für das Konzept des Projekts v642.

*[[#zentralistische Organisation|'''zentralistischer Aufbau''']]
*[[#dezentrale Organisation|'''dezentraler Aufbau''']]

im folgenden werden die Vor- und Nachteile der beiden Varianten beschrieben.

In weitere Folge muss eine Entscheidung für die eine oder andere Variante erfolgen.

== [[zentralistische Organisation]] ==
Das ist der Ansatz der mit der Verwaltung im Funkfeuer Netz mit [http://marvin.funkfeuer.at Marvin] bisher verfolgt wurde.
Die zentralistische Organisation basiert auf eine zentralen Datenbank welche die Informationen über Geräte, Benutzer, IP-Adressen, ... hält.
Aus der Datenbank werden die Informationen generiert welche dann in die Konfiguration der individuellen Komponenten übertragen werden muss.

Die Datenbank muss dann auch regelmäßig prüfen
* dass die Konfiguration der individuellen Komponenten nicht von der zentralen Datenbank abweicht.
* dass keine Komponenten ins Netz kommen welche nicht in der zentralen Datenbank registriert sind.
dadurch soll sichergestellt werden dass die Informationen in der zentralen Datenbank nicht von den der Konfiguration der aktiven Komponenten abweicht.

== [[dezentrale Organisation]] ==
Die dezentrale Organisation basiert darauf dass die einzelnen Komponenten sich automatisch selbst konfigurieren.

Eine zentrale Plattform sammelt dann die Informationen welche von den aktiven Komponenten übermittelt werden. Die zentrale Plattform dient primär zur Sammlung von Statistiken der einzelnen Nodes zur technischen Betriebsführung des Netzes.

Bei dezentraler Organisation '''kann''' die Steuerung zugelassener Nodes am Gateway erfolgen. Damit können (bewußt oder unabsichtlich) falsch konfigurierte Nodes unterdrückt werden. Es ist nicht zwangsweise erforderlich dass diese Kontrolle ausgeübt wird.

--[[Benutzer:Nodogz|Nodogz]] ([[Benutzer Diskussion:Nodogz|Diskussion]]) 22:55, 18. Apr. 2016 (CEST)

Olsrd2.conf

2020-07-14T14:03:15Z

Pocki: /* olsrd2.conf Beispielkonfiguration */

== olsrd2.conf Beispielkonfiguration ==

Quelle: https://github.com/pocki80/ER-wizard-OLSRd_V2

[global]
failfast no
fork yes
lockfile /var/lock/olsrd2
pidfile /var/run/olsrd2.pid

[log]
file /var/log/olsrd2.log
info main
info http
stderr true

[telnet]
port 2009

[http]
bindto 0.0.0.0
bindto ::0
webserver /config/olsrd2/www
port 8000
acl default_reject
acl first_reject
acl 127.0.0.1
acl 10.0.0.0/8
acl 172.16.0.0/12
acl 192.168.0.0/16
acl 78.41.112.0/21
acl 193.238.156.0/22
acl 185.194.20.0/22
acl ::1
acl 2a02:60::/29

[olsrv2]
originator -2a02:61:0:ee:1::0/80
originator -0.0.0.0/0
originator -::1/128
originator default_accept
#add/modify according your needs
#lan 2a02:61:c0de:51de:/64
#lan 2a02:61:c0de::/48
#lan 2a02:61:0:ff:1234:56ff:fe78:90ab/128
#lan 2a02:61:0:ee:1:ffff:b9c2:14fe/128
forward_hold_time 50
processing_hold_time 30
tc_interval 5
tc_validity 20

[interface=br0]
l2default rx_bitrate 10000000
#configure inbound-metric by neighbor-mac
#l2neighbor rx_bitrate 40000000 44:d9:c6:31:6d:c0
bindto -0.0.0.0/0
bindto -::1/128
bindto default_accept

[interface=lo]
bindto -0.0.0.0/0
bindto -::1/128
bindto default_accept

Regionen/Wien/MapSpecialConfig

2020-06-24T08:25:22Z

Pocki:

#
# Dies ist ein Dokument, das stündlich von der Map (https://map.funkfeuer.at/wien) abgerufen wird
# und bestimmten Knoten & Links Besonderheiten zuweist (Syntax weiter unten)
#
# Bitte beachte beim Editieren, dass jede Zeile mit einem Leerzeichen zur korrekten Darstellung beginnen muss.
#
# Kommentare:
# # das Kommentar beginnt ab # und gilt für die ganze Zeile
# // das Kommentar beginnt ab // und gilt für die ganze Zeile
# /* das Kommentar gilt nur in diesem Bereich */
#
#
# Syntax:
# (alle case-sensitive)
# Aufgrund des Datenschutzes kann statt des Knotennamens auch die Node-ID angegeben werden (siehe Map)
#
# node NodeName 5ghzbackbone // der Knoten namens "NodeName" ist ein wichtiger teil des 5GHz Backbones, wird mit grünem Marker dargestellt
#
#
# link NodeA NodeB ethernet [static] // der Knoten "NodeA" hat zu "NodeB" eine Kabelverbindung, graue Linie
# link NodeA NodeB 5ghz [static] // der Knoten "NodeA" hat zu "NodeB" eine 5GHz (Highspeed) Verbindung, grüne Linie
# link NodeA NodeB tunnel [static] // der Knoten "NodeA" hat zu "NodeB" einen Tunnel, blaue Linie
#
# die Option static bedeutet, dass der Link auch angezeigt wird,
# wenn es keine OLSR Verbindung zwischen den 2 Knoten gibt und sollte normalerweise nicht verwendet werden.
#

#backbone wired
#link nig-bb krypta-bb ethernet static
link nig-bb nessus-bb ethernet static
link nig-bb falke-bb ethernet static
link nig-bb anexia-bb ethernet static

#roofnode internal wired
#link krypta-bb kryptaroof ethernet
link nig-bb nixroof ethernet
link nessus-bb nessus ethernet
link nessus-bb tunnel ethernet
link falke-bb 2345falke ethernet
link anexia-bb anexia ethernet

#roofnodes
node krypta-bb 5ghzbackbone
node nig-bb 5ghzbackbone
node nessus-bb 5ghzbackbone
node falke-bb 5ghzbackbone
node anexia-bb 5ghzbackbone

node kryptaroof 5ghzbackbone

Regionen/Wien/MapSpecialConfig

2020-06-24T08:21:00Z

Pocki: Doppelte Einträge entfernt

#
# Dies ist ein Dokument, das stündlich von der Map (https://map.funkfeuer.at/wien) abgerufen wird
# und bestimmten Knoten & Links Besonderheiten zuweist (Syntax weiter unten)
#
# Bitte beachte beim Editieren, dass jede Zeile mit einem Leerzeichen zur korrekten Darstellung beginnen muss.
#
# Kommentare:
# # das Kommentar beginnt ab # und gilt für die ganze Zeile
# // das Kommentar beginnt ab // und gilt für die ganze Zeile
# /* das Kommentar gilt nur in diesem Bereich */
#
#
# Syntax:
# (alle case-sensitive)
# Aufgrund des Datenschutzes kann statt des Knotennamens auch die Node-ID angegeben werden (siehe Map)
#
# node NodeName 5ghzbackbone // der Knoten namens "NodeName" ist ein wichtiger teil des 5GHz Backbones, wird mit grünem Marker dargestellt
#
#
# link NodeA NodeB ethernet [static] // der Knoten "NodeA" hat zu "NodeB" eine Kabelverbindung, graue Linie
# link NodeA NodeB 5ghz [static] // der Knoten "NodeA" hat zu "NodeB" eine 5GHz (Highspeed) Verbindung, grüne Linie
# link NodeA NodeB tunnel [static] // der Knoten "NodeA" hat zu "NodeB" einen Tunnel, blaue Linie
#
# die Option static bedeutet, dass der Link auch angezeigt wird,
# wenn es keine OLSR Verbindung zwischen den 2 Knoten gibt und sollte normalerweise nicht verwendet werden.
#

#backbone wired
#link nig-bb krypta-bb ethernet static
link nig-bb nessus-bb ethernet static
link nig-bb falke-bb ethernet static
link nig-bb anexia-bb ethernet static

#roofnode internal wired
link krypta-bb kryptaroof ethernet
link nig-bb nixroof ethernet
link nessus-bb nessus ethernet
link nessus-bb tunnel ethernet
link falke-bb 2345falke ethernet
link anexia-bb anexia ethernet

#roofnodes
node krypta-bb 5ghzbackbone
node nig-bb 5ghzbackbone
node nessus-bb 5ghzbackbone
node falke-bb 5ghzbackbone
node anexia-bb 5ghzbackbone

Services/Organisation/Redeemer

2020-06-03T11:17:54Z

Pocki: /* SmokePing */

== Beschreibung ==

Der Redeemer ist die Verwaltung von Usern, Knoten und IP-Adressen für unser Funknetz, erreichbar unter [https://portal.funkfeuer.at/wien/ portal.funkfeuer.at/wien]. Die nötigen Daten werden in einer Postgres-Datenbank gespeichert.

Gehostet wird der Webservice im Rechnenzentrum von Nessus. Die Datenbank liegt auf einem Host im Housing "Vault".

Die Code-Quelle findet sich auf [https://gitlab.com/funkfeuer/redeemer gitlab.com/funkfeuer/redeemer].

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

Seit Mai 2019 können auch IPv6-Adressen für den Adressraum von OLSRv2 verwaltet werden - siehe [[Projekte/Redeemer-Wien]]

==== Verwaltete Daten ====
siehe [[Projekte/Datenschutz]]

==== Hauptseite ====
* Anzeige der eigenen Kontaktdaten
* Anzeige Anzahl Vereinsmitglieder (nur für Mitglieder)
* Anzeige Anzahl der eigenen Nodes und IP-Adressen und Onlinezustand

==== Zuletzt-Online ====
Regelmäßige Pings und Topologie-Abfragen stellen den Onlinezustand jeder IP-Adresse fest. Der Server map.funkfeuer.at führt dazu alle 10min fpings durch und schreibt anschließend aktuelle Timestamps in die Redeemer-Datenbank für alle IP-Adressen/Devices/Nodes, die erreichbar waren (und das aktuelle Tagesdatum für Adressen, die ohne ping-reply in der Topologie als HNA oder MID vorkamen).

Dieser Zuletzt-Online-Zeitpunkt wird im Redeemer genutzt, um jüngst online gesehene Knoten oder Devices mit grünen Symbolen hervorzuheben und die Knotenübersicht auf der Hauptseite in Alle/Online zu trennen. Auch in der BaseMap wird dieser Zeitpunkt für unterschiedliche farbliche Markierung der Devices genutzt.

== Abhängigkeiten ==
Die im Redeemer verwalteten Daten werden in einigen anderen Applikationen genutzt:

==== DNS Auth ====
Anlage von A/AAAA und PTR records

==== Maps ====
Geographische Darstellung der Knoten und deren Links.

Siehe auch:
* [[Services/Organisation/BaseMap]]
* [[Services/Organisation/Node Map]]
* [[Services/Organisation/Olsr2-Map]]

==== SmokePing ====
Siehe auch:
* [[Services/Organisation/Node Monitoring]]

==== LDAP ====

==== WHOIS ====

==== VOIP ====
Siehe auch:
* [[Services/Organisation/VoIP]]

Services/Organisation/Node Monitoring

2020-05-27T15:28:46Z

Pocki:

== Beschreibung ==
Node Monitoring umfasst:
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv4@olsr(v1) unter [http://smokeping.funkfeuer.at/smokeping/freenet/ smokeping.funkfeuer.at/smokeping/freenet]
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv6@olsrv2 unter [http://smokeping.funkfeuer.at/smokeping/olsr2/ smokeping.funkfeuer.at/smokeping/olsr2]
* [[Services/Organisation/Redeemer#Zuletzt-Online|Ermittlung von "Zuletzt Online"]] zur Darstellung in Redeemer und Maps
* Aktuelle SmokePing-Werte als .dat-File
* Aktuelle Routen zu allen Freenet-Zielen als .dat-File
* (inoffiziell) Topologie-Statistik pro Tag
* (inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
* (inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
* (inoffiziell) OLSRd Uptime
* (inoffiziell) OLSRd Versionserkennung
* (extern) UptimeRobot, z.B. https://stats.uptimerobot.com/BPl2ySN2Q

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]
* Adi Kriegisch (Serveradmin)
* Clemens Hopfer (Serveradmin)

== Funktionen ==

=== SmokePing ===
Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

=== Erkennung Zuletzt-Online ===
Siehe [[Services/Organisation/Redeemer#Zuletzt-Online Redeemer]]

=== SmokePing-Werte ===
Täglich um 7:00 werden die SmokePing-Ergebnisse von Freenet und Olsr2 aus den vergangenen 24h als Text-File unter http://smokeping.funkfeuer.at/smokeping/freenet-summary.dat und http://smokeping.funkfeuer.at/smokeping/olsr2-summary.dat bereitgestellt. Diese File enthält pro Nodename/Devicename die Durchschnitte von Ping-Median, Standardabweichung und Paketloss.

=== Aktuelle Routen ===
Auf dem Host smokeping.funkfeuer.at (Standort Housing "Vault") wird täglich um 7:30, 13:30, 19:30 ein TraceRoute zu Freenet-Zielen gemacht und unter http://smokeping.funkfeuer.at/smokeping/traces.dat bereitgestellt. Diese File enthält nur die IP-Adressen und ist nur von einer FunkFeuer-IP-Adresse aus zugänglich.

Die Ziele der Traceroutes werden aus der aktuellen olsr(v1)-Topologie und olsrv2-Topologie ermittelt. Jeder erkannte Hop wird auf die MainIp der jeweiligen olsr-Instanz geändert, sollte die IP eines MID rückgemeldet worden sein. Für einige olsrv2-Router liegt zusätzlich eine manuell gepfegte Liste von "MID-Adressen" vor, um z.B. die Roofnode-Router mit ihren OSPF-Uplinkadressen besser darzustellen.

=== Topologie-Statistik pro Tag ===
(inoffiziell) @rpi3p.wehr24

Holt sich täglich die Topologie von olsr(v1) und olsr2 sowie die SmokePing-Werte, TraceRoute-Files und liefert eine Zusammenfassung:
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?1
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?2
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/chart

Die Versionen von olsrd und olsrd2 werden durch ein tägliches Skript versucht von den einzelnen Routern abzurufen.

=== Topologie-Veränderungen ===
(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== Routen-Veränderungen ===
(inoffiziell)

Das Tool [https://ff.cybercomm.at/monitor/tree.php Route-Monitor] prüft jede Minute die Routen von 10 Nodes und vermerkt die jüngsten 200 Änderungen. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben! Das Tool agiert aus dem Housing beim Knoten 2345falke und betrachtet deshalb die IPv4-Routen auf Sicht der Roofnode-Routers rn01falke.

=== OLSRd Uptime ===
(inoffiziell) @bmk-smoke-01.2345falke

Fragt das httpinfo-plugin (Port 8080) oder jsoninfo-Plugin (Port 9090) ab, um die Uptime und ggf. einen Restart des olsr-daemons festzustellen. Läuft alle 30min über die laut Topologie erreichbaren Router. Diese Files sind nur von einer FunkFeuer-IP-Adresse aus zugänglich.

* [http://193.238.158.8/lastseen/uptime.dat OLSRd-Uptime]
* [http://193.238.158.8/lastseen/uptime.log OLSRd-Restarts]

=== OLSRd Versionserkennung ===
(inoffiziell) @bmk-smoke-01.2345falke

Fragt die bekannten Status-Seiten der Router ab, um die daemon-version festzustellen. Läuft täglich 7:30 über die laut Topologie erreichbaren Router. Diese Files sind nur von einer FunkFeuer-IP-Adresse aus zugänglich.

* [http://193.238.158.8/lastseen/versions.txt OLSRd-Versionen]

Services/Organisation/Node Monitoring

2020-05-27T15:05:44Z

Pocki: /* Aktuelle Routen */

== Beschreibung ==
Node Monitoring umfasst:
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv4@olsr(v1) unter [http://smokeping.funkfeuer.at/smokeping/freenet/ smokeping.funkfeuer.at/smokeping/freenet]
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv6@olsrv2 unter [http://smokeping.funkfeuer.at/smokeping/olsr2/ smokeping.funkfeuer.at/smokeping/olsr2]
* [[Services/Organisation/Redeemer#Zuletzt-Online|Ermittlung von "Zuletzt Online"]] zur Darstellung in Redeemer und Maps
* Aktuelle SmokePing-Werte als .dat-File
* Aktuelle Routen zu allen Freenet-Zielen als .dat-File
* (inoffiziell) Topologie-Statistik pro Tag
* (inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
* (inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
* (inoffiziell) OLSRd Uptime
* (inoffiziell) OLSRd Versionserkennung
* (extern) UptimeRobot, z.B. https://stats.uptimerobot.com/BPl2ySN2Q

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]
* Adi Kriegisch (Serveradmin)
* Clemens Hopfer (Serveradmin)

== Funktionen ==

=== SmokePing ===
Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

=== Erkennung Zuletzt-Online ===
Siehe [[Services/Organisation/Redeemer#Zuletzt-Online Redeemer]]

=== SmokePing-Werte ===
Täglich um 7:00 werden die SmokePing-Ergebnisse von Freenet und Olsr2 aus den vergangenen 24h als Text-File unter http://smokeping.funkfeuer.at/smokeping/freenet-summary.dat und http://smokeping.funkfeuer.at/smokeping/olsr2-summary.dat bereitgestellt. Diese File enthält pro Nodename/Devicename die Durchschnitte von Ping-Median, Standardabweichung und Paketloss.

=== Aktuelle Routen ===
Auf dem Host smokeping.funkfeuer.at (Standort Housing "Vault") wird täglich um 7:30, 13:30, 19:30 ein TraceRoute zu Freenet-Zielen gemacht und unter http://smokeping.funkfeuer.at/smokeping/traces.dat bereitgestellt. Diese File enthält nur die IP-Adressen und ist nur von einer FunkFeuer-IP-Adresse aus zugänglich.

Die Ziele der Traceroutes werden aus der aktuellen olsr(v1)-Topologie und olsrv2-Topologie ermittelt. Jeder erkannte Hop wird auf die MainIp der jeweiligen olsr-Instanz geändert, sollte die IP eines MID rückgemeldet worden sein. Für einige olsrv2-Router liegt zusätzlich eine manuell gepfegte Liste von "MID-Adressen" vor, um z.B. die Roofnode-Router mit ihren OSPF-Uplinkadressen besser darzustellen.

=== Topologie-Statistik pro Tag ===
(inoffiziell) @rpi3p.wehr24

Holt sich täglich die Topologie von olsr(v1) und olsr2 sowie die SmokePing-Werte, TraceRoute-Files und liefert eine Zusammenfassung:
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?1
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?2
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/chart

Die Versionen von olsrd und olsrd2 werden durch ein tägliches Skript versucht von den einzelnen Routern abzurufen.

=== Topologie-Veränderungen ===
(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== Routen-Veränderungen ===
(inoffiziell)

Das Tool [https://ff.cybercomm.at/monitor/tree.php Route-Monitor] prüft jede Minute die Routen von 10 Nodes und vermerkt die jüngsten 200 Änderungen. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben! Das Tool agiert aus dem Housing beim Knoten 2345falke und betrachtet deshalb die IPv4-Routen auf Sicht der Roofnode-Routers rn01falke.

=== OLSRd Uptime ===
(inoffiziell) @bmk-smoke-01.2345falke

Fragt das httpinfo-plugin (Port 8080) oder jsoninfo-Plugin (Port 9090) ab, um die Uptime und ggf. einen Restart des olsr-daemons festzustellen. Läuft alle 30min über die laut Topologie erreichbaren Router.

* [http://193.238.158.8/lastseen/uptime.dat OLSRd-Uptime]
* [http://193.238.158.8/lastseen/uptime.log OLSRd-Restarts]

=== OLSRd Versionserkennung ===
(inoffiziell) @bmk-smoke-01.2345falke

Fragt die bekannten Status-Seiten der Router ab, um die daemon-version festzustellen. Läuft täglich 7:30 über die laut Topologie erreichbaren Router.

* [http://193.238.158.8/lastseen/versions.txt OLSRd-Versionen]

Services/Organisation/Node Monitoring

2020-05-27T14:44:54Z

Pocki:

== Beschreibung ==
Node Monitoring umfasst:
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv4@olsr(v1) unter [http://smokeping.funkfeuer.at/smokeping/freenet/ smokeping.funkfeuer.at/smokeping/freenet]
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv6@olsrv2 unter [http://smokeping.funkfeuer.at/smokeping/olsr2/ smokeping.funkfeuer.at/smokeping/olsr2]
* [[Services/Organisation/Redeemer#Zuletzt-Online|Ermittlung von "Zuletzt Online"]] zur Darstellung in Redeemer und Maps
* Aktuelle SmokePing-Werte als .dat-File
* Aktuelle Routen zu allen Freenet-Zielen als .dat-File
* (inoffiziell) Topologie-Statistik pro Tag
* (inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
* (inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
* (inoffiziell) OLSRd Uptime
* (inoffiziell) OLSRd Versionserkennung
* (extern) UptimeRobot, z.B. https://stats.uptimerobot.com/BPl2ySN2Q

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]
* Adi Kriegisch (Serveradmin)
* Clemens Hopfer (Serveradmin)

== Funktionen ==

=== SmokePing ===
Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

=== Erkennung Zuletzt-Online ===
Siehe [[Services/Organisation/Redeemer#Zuletzt-Online Redeemer]]

=== SmokePing-Werte ===
Täglich um 7:00 werden die SmokePing-Ergebnisse von Freenet und Olsr2 aus den vergangenen 24h als Text-File unter http://smokeping.funkfeuer.at/smokeping/freenet-summary.dat und http://smokeping.funkfeuer.at/smokeping/olsr2-summary.dat bereitgestellt. Diese File enthält pro Nodename/Devicename die Durchschnitte von Ping-Median, Standardabweichung und Paketloss.

=== Aktuelle Routen ===
Auf dem Host smokeping.funkfeuer.at (Standort Housing "Vault") wird täglich um 7:30, 13:30, 19:30 ein TraceRoute zu Freenet-Zielen gemacht und unter http://smokeping.funkfeuer.at/smokeping/traces.dat bereitgestellt. Diese File enthält nur die IP-Adressen.

Die Ziele der Traceroutes werden aus der aktuellen olsr(v1)-Topologie und olsrv2-Topologie ermittelt. Jeder erkannte Hop wird auf die MainIp der jeweiligen olsr-Instanz geändert, sollte die IP eines MID rückgemeldet worden sein. Für einige olsrv2-Router liegt zusätzlich eine manuell gepfegte Liste von "MID-Adressen" vor, um z.B. die Roofnode-Router mit ihren OSPF-Uplinkadressen besser darzustellen.

=== Topologie-Statistik pro Tag ===
(inoffiziell) @rpi3p.wehr24

Holt sich täglich die Topologie von olsr(v1) und olsr2 sowie die SmokePing-Werte, TraceRoute-Files und liefert eine Zusammenfassung:
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?1
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?2
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/chart

Die Versionen von olsrd und olsrd2 werden durch ein tägliches Skript versucht von den einzelnen Routern abzurufen.

=== Topologie-Veränderungen ===
(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== Routen-Veränderungen ===
(inoffiziell)

Das Tool [https://ff.cybercomm.at/monitor/tree.php Route-Monitor] prüft jede Minute die Routen von 10 Nodes und vermerkt die jüngsten 200 Änderungen. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben! Das Tool agiert aus dem Housing beim Knoten 2345falke und betrachtet deshalb die IPv4-Routen auf Sicht der Roofnode-Routers rn01falke.

=== OLSRd Uptime ===
(inoffiziell) @bmk-smoke-01.2345falke

Fragt das httpinfo-plugin (Port 8080) oder jsoninfo-Plugin (Port 9090) ab, um die Uptime und ggf. einen Restart des olsr-daemons festzustellen. Läuft alle 30min über die laut Topologie erreichbaren Router.

* [http://193.238.158.8/lastseen/uptime.dat OLSRd-Uptime]
* [http://193.238.158.8/lastseen/uptime.log OLSRd-Restarts]

=== OLSRd Versionserkennung ===
(inoffiziell) @bmk-smoke-01.2345falke

Fragt die bekannten Status-Seiten der Router ab, um die daemon-version festzustellen. Läuft täglich 7:30 über die laut Topologie erreichbaren Router.

* [http://193.238.158.8/lastseen/versions.txt OLSRd-Versionen]

Services/Organisation/Node Monitoring

2020-05-27T14:36:06Z

Pocki:

== Beschreibung ==
Node Monitoring umfasst:
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv4@olsr(v1) unter [http://smokeping.funkfeuer.at/smokeping/freenet/ smokeping.funkfeuer.at/smokeping/freenet]
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv6@olsrv2 unter [http://smokeping.funkfeuer.at/smokeping/olsr2/ smokeping.funkfeuer.at/smokeping/olsr2]
* [[Services/Organisation/Redeemer#Zuletzt-Online|Ermittlung von "Zuletzt Online"]] zur Darstellung in Redeemer und Maps
* Aktuelle SmokePing-Werte als .dat-File
* Aktuelle Routen zu allen Freenet-Zielen als .dat-File
* (inoffiziell) Topologie-Statistik pro Tag
* (inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
* (inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
* (inoffiziell) OLSRd Uptime
* (inoffiziell) OLSRd Versionserkennung
* (extern) UptimeRobot, z.B. https://stats.uptimerobot.com/BPl2ySN2Q

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]
* Adi Kriegisch (Serveradmin)
* Clemens Hopfer (Serveradmin)

== Funktionen ==

=== SmokePing ===
Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

=== Erkennung Zuletzt-Online ===
Siehe [[Services/Organisation/Redeemer#Zuletzt-Online Redeemer]]

=== SmokePing-Werte ===
Täglich um 7:00 werden die SmokePing-Ergebnisse von Freenet und Olsr2 aus den vergangenen 24h als Text-File unter http://smokeping.funkfeuer.at/smokeping/freenet-summary.dat und http://smokeping.funkfeuer.at/smokeping/olsr2-summary.dat bereitgestellt. Diese File enthält pro Nodename/Devicename die Durchschnitte von Ping-Median, Standardabweichung und Paketloss.

=== Aktuelle Routen ===
Auf dem Host smokeping.funkfeuer.at (Standort Housing "Vault") wird täglich um 7:30, 13:30, 19:30 ein TraceRoute zu Freenet-Zielen gemacht und unter http://smokeping.funkfeuer.at/smokeping/traces.dat bereitgestellt. Diese File enthält nur die IP-Adressen.

Die Ziele der Traceroutes werden aus der aktuellen olsr(v1)-Topologie und olsrv2-Topologie ermittelt. Jeder erkannte Hop wird auf die MainIp der jeweiligen olsr-Instanz geändert, sollte die IP eines MID rückgemeldet worden sein. Für einige olsrv2-Router liegt zusätzlich eine manuell gepfegte Liste von "MID-Adressen" vor, um z.B. die Roofnode-Router mit ihren OSPF-Uplinkadressen besser darzustellen.

=== Topologie-Statistik pro Tag ===
(inoffiziell)

Holt sich täglich die Topologie von olsr(v1) und olsr2 sowie die SmokePing-Werte, TraceRoute-Files und liefert eine Zusammenfassung:
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?1
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?2
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/chart

Die Versionen von olsrd und olsrd2 werden durch ein tägliches Skript versucht von den einzelnen Routern abzurufen.

=== Topologie-Veränderungen ===
(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== Routen-Veränderungen ===
(inoffiziell)

Das Tool [https://ff.cybercomm.at/monitor/tree.php Route-Monitor] prüft jede Minute die Routen von 10 Nodes und vermerkt die jüngsten 200 Änderungen. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben! Das Tool agiert aus dem Housing beim Knoten 2345falke und betrachtet deshalb die IPv4-Routen auf Sicht der Roofnode-Routers rn01falke.

=== OLSRd Uptime ===
(inoffiziell)

Fragt das httpinfo-plugin (Port 8080) oder jsoninfo-Plugin (Port 9090) ab, um die Uptime und ggf. einen Restart des olsr-daemons festzustellen. Läuft alle 30min über die laut Topologie erreichbaren Router.

* [http://193.238.158.8/lastseen/uptime.dat OLSRd-Uptime]
* [http://193.238.158.8/lastseen/uptime.log OLSRd-Restarts]

=== OLSRd Versionserkennung ===
(inoffiziell)

Fragt die bekannten Status-Seiten der Router ab, um die daemon-version festzustellen. Läuft täglich 7:30 über die laut Topologie erreichbaren Router.

* [http://193.238.158.8/lastseen/versions.txt OLSRd-Versionen]

Services/Organisation/Node Monitoring

2020-05-27T14:31:26Z

Pocki:

== Beschreibung ==
Node Monitoring umfasst:
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv4@olsr(v1) unter [http://smokeping.funkfeuer.at/smokeping/freenet/ smokeping.funkfeuer.at/smokeping/freenet]
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv6@olsrv2 unter [http://smokeping.funkfeuer.at/smokeping/olsr2/ smokeping.funkfeuer.at/smokeping/olsr2]
* [[Services/Organisation/Redeemer#Zuletzt-Online|Ermittlung von "Zuletzt Online"]] zur Darstellung in Redeemer und Maps
* Aktuelle SmokePing-Werte als .dat-File
* Aktuelle Routen zu allen Freenet-Zielen als .dat-File
* (inoffiziell) Topologie-Statistik pro Tag
* (inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
* (inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
* (inoffiziell) OLSRd Uptime
* (extern) UptimeRobot, z.B. https://stats.uptimerobot.com/BPl2ySN2Q

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]
* Adi Kriegisch (Serveradmin)
* Clemens Hopfer (Serveradmin)

== Funktionen ==

=== SmokePing ===
Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

=== Erkennung Zuletzt-Online ===
Siehe [[Services/Organisation/Redeemer#Zuletzt-Online Redeemer]]

=== SmokePing-Werte ===
Täglich um 7:00 werden die SmokePing-Ergebnisse von Freenet und Olsr2 aus den vergangenen 24h als Text-File unter http://smokeping.funkfeuer.at/smokeping/freenet-summary.dat und http://smokeping.funkfeuer.at/smokeping/olsr2-summary.dat bereitgestellt. Diese File enthält pro Nodename/Devicename die Durchschnitte von Ping-Median, Standardabweichung und Paketloss.

=== Aktuelle Routen ===
Auf dem Host smokeping.funkfeuer.at (Standort Housing "Vault") wird täglich um 7:30, 13:30, 19:30 ein TraceRoute zu Freenet-Zielen gemacht und unter http://smokeping.funkfeuer.at/smokeping/traces.dat bereitgestellt. Diese File enthält nur die IP-Adressen.

Die Ziele der Traceroutes werden aus der aktuellen olsr(v1)-Topologie und olsrv2-Topologie ermittelt. Jeder erkannte Hop wird auf die MainIp der jeweiligen olsr-Instanz geändert, sollte die IP eines MID rückgemeldet worden sein. Für einige olsrv2-Router liegt zusätzlich eine manuell gepfegte Liste von "MID-Adressen" vor, um z.B. die Roofnode-Router mit ihren OSPF-Uplinkadressen besser darzustellen.

=== Topologie-Statistik pro Tag ===
(inoffiziell)

Holt sich täglich die Topologie von olsr(v1) und olsr2 sowie die SmokePing-Werte, TraceRoute-Files und liefert eine Zusammenfassung:
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?1
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?2
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/chart

Die Versionen von olsrd und olsrd2 werden durch ein tägliches Skript versucht von den einzelnen Routern abzurufen.

=== Topologie-Veränderungen ===
(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== Routen-Veränderungen ===
(inoffiziell)

Das Tool [https://ff.cybercomm.at/monitor/tree.php Route-Monitor] prüft jede Minute die Routen von 10 Nodes und vermerkt die jüngsten 200 Änderungen. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben! Das Tool agiert aus dem Housing beim Knoten 2345falke und betrachtet deshalb die IPv4-Routen auf Sicht der Roofnode-Routers rn01falke.

=== OLSRd Uptime ===
(inoffiziell)

Fragt das httpinfo-plugin (Port 8080) oder jsoninfo-Plugin (Port 9090) ab, um die Uptime und ggf. einen Restart des olsr-daemons festzustellen. Läuft alle 30min über die laut Topologie erreichbaren Router.

* [http://193.238.158.8/lastseen/uptime.dat OLSRd-Uptime]
* [http://193.238.158.8/lastseen/uptime.log OLSRd-Restarts]

Services/Organisation/Node Monitoring

2020-05-27T14:13:23Z

Pocki:

== Beschreibung ==
Node Monitoring umfasst:
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv4@olsr(v1) unter [http://smokeping.funkfeuer.at/smokeping/freenet/ smokeping.funkfeuer.at/smokeping/freenet]
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv6@olsrv2 unter [http://smokeping.funkfeuer.at/smokeping/olsr2/ smokeping.funkfeuer.at/smokeping/olsr2]
* [[Services/Organisation/Redeemer#Zuletzt-Online|Ermittlung von "Zuletzt Online"]] zur Darstellung in Redeemer und Maps
* Aktuelle SmokePing-Werte als .dat-File
* Aktuelle Routen zu allen Freenet-Zielen als .dat-File
* (inoffiziell) Topologie-Statistik pro Tag
* (inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
* (inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
* UptimeRobot, z.B. https://stats.uptimerobot.com/BPl2ySN2Q

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]
* Adi Kriegisch (Serveradmin)
* Clemens Hopfer (Serveradmin)

== Funktionen ==

=== SmokePing ===
Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

=== Erkennung Zuletzt-Online ===
Siehe [[Services/Organisation/Redeemer#Zuletzt-Online Redeemer]]

=== SmokePing-Werte ===
Täglich um 7:00 werden die SmokePing-Ergebnisse von Freenet und Olsr2 aus den vergangenen 24h als Text-File unter http://smokeping.funkfeuer.at/smokeping/freenet-summary.dat und http://smokeping.funkfeuer.at/smokeping/olsr2-summary.dat bereitgestellt. Diese File enthält pro Nodename/Devicename die Durchschnitte von Ping-Median, Standardabweichung und Paketloss.

=== Aktuelle Routen ===
Auf dem Host smokeping.funkfeuer.at (Standort Housing "Vault") wird täglich um 7:30, 13:30, 19:30 ein TraceRoute zu Freenet-Zielen gemacht und unter http://smokeping.funkfeuer.at/smokeping/traces.dat bereitgestellt. Diese File enthält nur die IP-Adressen.

Die Ziele der Traceroutes werden aus der aktuellen olsr(v1)-Topologie und olsrv2-Topologie ermittelt. Jeder erkannte Hop wird auf die MainIp der jeweiligen olsr-Instanz geändert, sollte die IP eines MID rückgemeldet worden sein. Für einige olsrv2-Router liegt zusätzlich eine manuell gepfegte Liste von "MID-Adressen" vor, um z.B. die Roofnode-Router mit ihren OSPF-Uplinkadressen besser darzustellen.

=== Topologie-Statistik pro Tag ===
(inoffiziell)

Holt sich täglich die Topologie von olsr(v1) und olsr2 sowie die SmokePing-Werte, TraceRoute-Files und liefert eine Zusammenfassung:
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?1
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?2
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/chart

Die Versionen von olsrd und olsrd2 werden durch ein tägliches Skript versucht von den einzelnen Routern abzurufen.

=== Topologie-Veränderungen ===
(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== Routen-Veränderungen ===
(inoffiziell)

Das Tool [https://ff.cybercomm.at/monitor/tree.php Route-Monitor] prüft jede Minute die Routen von 10 Nodes und vermerkt die jüngsten 200 Änderungen. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben! Das Tool agiert aus dem Housing beim Knoten 2345falke und betrachtet deshalb die IPv4-Routen auf Sicht der Roofnode-Routers rn01falke.

Services/Organisation/Node Monitoring

2020-05-27T14:12:10Z

Pocki:

== Beschreibung ==
Node Monitoring umfasst:
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv4@olsr(v1) unter [http://smokeping.funkfeuer.at/smokeping/freenet/ smokeping.funkfeuer.at/smokeping/freenet]
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv6@olsrv2 unter [http://smokeping.funkfeuer.at/smokeping/olsr2/ smokeping.funkfeuer.at/smokeping/olsr2]
* [[Services/Organisation/Redeemer#Zuletzt-Online|Ermittlung von "Zuletzt Online"]] zur Darstellung in Redeemer und Maps
* Aktuelle SmokePing-Werte als .dat-File
* Aktuelle Routen zu allen Freenet-Zielen als .dat-File
* (inoffiziell) Topologie-Statistik pro Tag
* (inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
* (inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
* UptimeRobot

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]
* Adi Kriegisch (Serveradmin)
* Clemens Hopfer (Serveradmin)

== Funktionen ==

=== SmokePing ===
Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

=== Erkennung Zuletzt-Online ===
Siehe [[Services/Organisation/Redeemer#Zuletzt-Online Redeemer]]

=== SmokePing-Werte ===
Täglich um 7:00 werden die SmokePing-Ergebnisse von Freenet und Olsr2 aus den vergangenen 24h als Text-File unter http://smokeping.funkfeuer.at/smokeping/freenet-summary.dat und http://smokeping.funkfeuer.at/smokeping/olsr2-summary.dat bereitgestellt. Diese File enthält pro Nodename/Devicename die Durchschnitte von Ping-Median, Standardabweichung und Paketloss.

=== Aktuelle Routen ===
Auf dem Host smokeping.funkfeuer.at (Standort Housing "Vault") wird täglich um 7:30, 13:30, 19:30 ein TraceRoute zu Freenet-Zielen gemacht und unter http://smokeping.funkfeuer.at/smokeping/traces.dat bereitgestellt. Diese File enthält nur die IP-Adressen.

Die Ziele der Traceroutes werden aus der aktuellen olsr(v1)-Topologie und olsrv2-Topologie ermittelt. Jeder erkannte Hop wird auf die MainIp der jeweiligen olsr-Instanz geändert, sollte die IP eines MID rückgemeldet worden sein. Für einige olsrv2-Router liegt zusätzlich eine manuell gepfegte Liste von "MID-Adressen" vor, um z.B. die Roofnode-Router mit ihren OSPF-Uplinkadressen besser darzustellen.

=== Topologie-Statistik pro Tag ===
(inoffiziell)

Holt sich täglich die Topologie von olsr(v1) und olsr2 sowie die SmokePing-Werte, TraceRoute-Files und liefert eine Zusammenfassung:
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?1
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/?2
* https://rpi3p.wehr24.wien.funkfeuer.at/topo/chart

Die Versionen von olsrd und olsrd2 werden durch ein tägliches Skript versucht von den einzelnen Routern abzurufen.

=== Topologie-Veränderungen ===
(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== Routen-Veränderungen ===
(inoffiziell)

Das Tool [https://ff.cybercomm.at/monitor/tree.php Route-Monitor] prüft jede Minute die Routen von 10 Nodes und vermerkt die jüngsten 200 Änderungen. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben! Das Tool agiert aus dem Housing beim Knoten 2345falke und betrachtet deshalb die IPv4-Routen auf Sicht der Roofnode-Routers rn01falke.

Services/Organisation/Node Monitoring

2020-05-27T12:48:07Z

Pocki: /* Aktuelle Routen */

== Beschreibung ==
Node Monitoring umfasst:
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv4@olsr(v1) unter [http://smokeping.funkfeuer.at/smokeping/freenet/ smokeping.funkfeuer.at/smokeping/freenet]
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv6@olsrv2 unter [http://smokeping.funkfeuer.at/smokeping/olsr2/ smokeping.funkfeuer.at/smokeping/olsr2]
* [[Services/Organisation/Redeemer#Zuletzt-Online|Ermittlung von "Zuletzt Online"]] zur Darstellung in Redeemer und Maps
* Aktuelle SmokePing-Werte als .dat-File
* Aktuelle Routen zu allen Freenet-Zielen als .dat-File
* (inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
* (inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
* UptimeRobot

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]
* Adi Kriegisch (Serveradmin)
* Clemens Hopfer (Serveradmin)

== Funktionen ==

=== SmokePing ===
Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

=== Erkennung Zuletzt-Online ===
Siehe [[Services/Organisation/Redeemer#Zuletzt-Online Redeemer]]

=== SmokePing-Werte ===
Täglich um 7:00 werden die SmokePing-Ergebnisse von Freenet und Olsr2 aus den vergangenen 24h als Text-File unter http://smokeping.funkfeuer.at/smokeping/freenet-summary.dat und http://smokeping.funkfeuer.at/smokeping/olsr2-summary.dat bereitgestellt. Diese File enthält pro Nodename/Devicename die Durchschnitte von Ping-Median, Standardabweichung und Paketloss.

=== Aktuelle Routen ===
Auf dem Host smokeping.funkfeuer.at (Standort Housing "Vault") wird täglich um 7:30, 13:30, 19:30 ein TraceRoute zu Freenet-Zielen gemacht und unter http://smokeping.funkfeuer.at/smokeping/traces.dat bereitgestellt. Diese File enthält nur die IP-Adressen.

Die Ziele der Traceroutes werden aus der aktuellen olsr(v1)-Topologie und olsrv2-Topologie ermittelt. Jeder erkannte Hop wird auf die MainIp der jeweiligen olsr-Instanz geändert, sollte die IP eines MID rückgemeldet worden sein. Für einige olsrv2-Router liegt zusätzlich eine manuell gepfegte Liste von "MID-Adressen" vor, um z.B. die Roofnode-Router mit ihren OSPF-Uplinkadressen besser darzustellen.

=== Topologie-Veränderungen ===
(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== Routen-Veränderungen ===
(inoffiziell)

Das Tool [https://ff.cybercomm.at/monitor/tree.php Route-Monitor] prüft jede Minute die Routen von 10 Nodes und vermerkt die jüngsten 200 Änderungen. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben! Das Tool agiert aus dem Housing beim Knoten 2345falke und betrachtet deshalb die IPv4-Routen auf Sicht der Roofnode-Routers rn01falke.

Services/Organisation/Node Monitoring

2020-05-27T12:46:46Z

Pocki: /* Aktuelle Routen */

== Beschreibung ==
Node Monitoring umfasst:
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv4@olsr(v1) unter [http://smokeping.funkfeuer.at/smokeping/freenet/ smokeping.funkfeuer.at/smokeping/freenet]
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv6@olsrv2 unter [http://smokeping.funkfeuer.at/smokeping/olsr2/ smokeping.funkfeuer.at/smokeping/olsr2]
* [[Services/Organisation/Redeemer#Zuletzt-Online|Ermittlung von "Zuletzt Online"]] zur Darstellung in Redeemer und Maps
* Aktuelle SmokePing-Werte als .dat-File
* Aktuelle Routen zu allen Freenet-Zielen als .dat-File
* (inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
* (inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
* UptimeRobot

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]
* Adi Kriegisch (Serveradmin)
* Clemens Hopfer (Serveradmin)

== Funktionen ==

=== SmokePing ===
Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

=== Erkennung Zuletzt-Online ===
Siehe [[Services/Organisation/Redeemer#Zuletzt-Online Redeemer]]

=== SmokePing-Werte ===
Täglich um 7:00 werden die SmokePing-Ergebnisse von Freenet und Olsr2 aus den vergangenen 24h als Text-File unter http://smokeping.funkfeuer.at/smokeping/freenet-summary.dat und http://smokeping.funkfeuer.at/smokeping/olsr2-summary.dat bereitgestellt. Diese File enthält pro Nodename/Devicename die Durchschnitte von Ping-Median, Standardabweichung und Paketloss.

=== Aktuelle Routen ===
Auf dem Host smokeping.funkfeuer.at (Standort Housing "Vault") wird täglich um 7:30, 13:30, 19:30 ein TraceRoute zu Freenet-Zielen gemacht und unter http://smokeping.funkfeuer.at/smokeping/traces.dat bereitgestellt. Diese File enthält nur die IP-Adressen.

Die Ziele der Traceroutes werden aus der aktuellen olsr(v1)-Topologie und olsrv2-Topologie ermittelt. Jeder erkannte Hop wird auf die MainIp der jeweiligen olsr-Instanz geändert, sollte die IP eines MID rückgemeldet worden sein.

=== Topologie-Veränderungen ===
(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== Routen-Veränderungen ===
(inoffiziell)

Das Tool [https://ff.cybercomm.at/monitor/tree.php Route-Monitor] prüft jede Minute die Routen von 10 Nodes und vermerkt die jüngsten 200 Änderungen. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben! Das Tool agiert aus dem Housing beim Knoten 2345falke und betrachtet deshalb die IPv4-Routen auf Sicht der Roofnode-Routers rn01falke.

Services/Organisation/Node Monitoring

2020-05-27T12:20:44Z

Pocki:

== Beschreibung ==
Node Monitoring umfasst:
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv4@olsr(v1) unter [http://smokeping.funkfeuer.at/smokeping/freenet/ smokeping.funkfeuer.at/smokeping/freenet]
* [http://smokeping.funkfeuer.at/ SmokePing] für IPv6@olsrv2 unter [http://smokeping.funkfeuer.at/smokeping/olsr2/ smokeping.funkfeuer.at/smokeping/olsr2]
* [[Services/Organisation/Redeemer#Zuletzt-Online|Ermittlung von "Zuletzt Online"]] zur Darstellung in Redeemer und Maps
* Aktuelle SmokePing-Werte als .dat-File
* Aktuelle Routen zu allen Freenet-Zielen als .dat-File
* (inoffiziell) Erkennung von Topologie-Veränderungen der letzten Tage
* (inoffiziell) Erkennung von IPv4-Routenänderungen der letzten Tage
* UptimeRobot

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]
* Adi Kriegisch (Serveradmin)
* Clemens Hopfer (Serveradmin)

== Funktionen ==

=== SmokePing ===
Die Hostliste für Smokeping von Freenet und Olsr2 wird alle 2 Stunden aus dem Redeemer neu erstellt. Enthalten sind alle Geräte, die für SmokePing aktiviert wurden. IP-Adressen, die länger als 1 Jahr nicht mehr erreichbar waren, werden aus der Hostliste automatisch wieder entfernt.

=== Erkennung Zuletzt-Online ===
Siehe [[Services/Organisation/Redeemer#Zuletzt-Online Redeemer]]

=== SmokePing-Werte ===
Täglich um 7:00 werden die SmokePing-Ergebnisse von Freenet und Olsr2 aus den vergangenen 24h als Text-File unter http://smokeping.funkfeuer.at/smokeping/freenet-summary.dat und http://smokeping.funkfeuer.at/smokeping/olsr2-summary.dat bereitgestellt. Diese File enthält pro Nodename/Devicename die Durchschnitte von Ping-Median, Standardabweichung und Paketloss.

=== Aktuelle Routen ===
Auf dem Host smokeping.funkfeuer.at (Standort Housing "Vault") wird täglich um 7:30, 13:30, 19:30 ein TraceRoute zu allen Freenet-Zielen gemacht und unter http://smokeping.funkfeuer.at/smokeping/traces.dat bereitgestellt. Diese File enthält nur die IP-Adressen.

=== Topologie-Veränderungen ===
(inoffiziell)

Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage. Die Anzeige von Informationen ist nur nach einem Login mit einem Redeemer-User verfügbar.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der BaseMap. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== Routen-Veränderungen ===
(inoffiziell)

Das Tool [https://ff.cybercomm.at/monitor/tree.php Route-Monitor] prüft jede Minute die Routen von 10 Nodes und vermerkt die jüngsten 200 Änderungen. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben! Das Tool agiert aus dem Housing beim Knoten 2345falke und betrachtet deshalb die IPv4-Routen auf Sicht der Roofnode-Routers rn01falke.

Services/Organisation/Node Monitoring

2020-05-27T09:47:27Z

Pocki: /* Maintainer */

Services/Organisation/Node Monitoring

2020-05-27T09:35:58Z

Pocki:

Services/Organisation/Node Monitoring

2020-05-27T09:02:36Z

Pocki:

Services/Organisation/Node Monitoring

2020-05-27T08:52:35Z

Pocki:

Services/Organisation/Redeemer

2020-05-27T08:33:05Z

Pocki: /* Zuletzt-Online */

== Beschreibung ==

Der Redeemer ist die Verwaltung von Usern, Knoten und IP-Adressen für unser Funknetz, erreichbar unter [https://portal.funkfeuer.at/wien/ portal.funkfeuer.at/wien]. Die nötigen Daten werden in einer Postgres-Datenbank gespeichert.

Gehostet wird der Webservice im Rechnenzentrum von Nessus. Die Datenbank liegt auf einem Host im Housing "Vault".

Die Code-Quelle findet sich auf [https://gitlab.com/funkfeuer/redeemer gitlab.com/funkfeuer/redeemer].

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

Seit Mai 2019 können auch IPv6-Adressen für den Adressraum von OLSRv2 verwaltet werden - siehe [[Projekte/Redeemer-Wien]]

==== Verwaltete Daten ====
siehe [[Projekte/Datenschutz]]

==== Hauptseite ====
* Anzeige der eigenen Kontaktdaten
* Anzeige Anzahl Vereinsmitglieder (nur für Mitglieder)
* Anzeige Anzahl der eigenen Nodes und IP-Adressen und Onlinezustand

==== Zuletzt-Online ====
Regelmäßige Pings und Topologie-Abfragen stellen den Onlinezustand jeder IP-Adresse fest. Der Server map.funkfeuer.at führt dazu alle 10min fpings durch und schreibt anschließend aktuelle Timestamps in die Redeemer-Datenbank für alle IP-Adressen/Devices/Nodes, die erreichbar waren (und das aktuelle Tagesdatum für Adressen, die ohne ping-reply in der Topologie als HNA oder MID vorkamen).

Dieser Zuletzt-Online-Zeitpunkt wird im Redeemer genutzt, um jüngst online gesehene Knoten oder Devices mit grünen Symbolen hervorzuheben und die Knotenübersicht auf der Hauptseite in Alle/Online zu trennen. Auch in der BaseMap wird dieser Zeitpunkt für unterschiedliche farbliche Markierung der Devices genutzt.

== Abhängigkeiten ==
Die im Redeemer verwalteten Daten werden in einigen anderen Applikationen genutzt:

==== DNS Auth ====
Anlage von A/AAAA und PTR records

==== Maps ====
Geographische Darstellung der Knoten und deren Links.

Siehe auch:
* [[Services/Organisation/BaseMap]]
* [[Services/Organisation/Node Map]]
* [[Services/Organisation/Olsr2-Map]]

==== SmokePing ====
Siehe auch:
* [Services/Organisation/Node Monitoring]

==== LDAP ====

==== WHOIS ====

==== VOIP ====
Siehe auch:
* [[Services/Organisation/VoIP]]

Services/Organisation/Olsr2-Map

2020-05-27T08:16:10Z

Pocki: /* Abhängigkeiten */

== Beschreibung ==

Die OLSRv2-Map, verlinkt unter [https://map.funkfeuer.at/ map.funkfeuer.at], stellt die IPv6@OLSRv2-Topologie dar. Die nötigen Daten werden aus der der BaseMap-API und aus dem Http2Telnet-Plugin des OLSRd2 eines Roofnode-Routers geholt und miteinander verschnitten. Die Darstellung erfolgt auf einer GoogleMaps Karte und ist in JavaScript umgesetzt.

Gehostet wird der Webservice im Housing beim Knoten 2345falke.

Die Rohdaten der OLSRv2-Topologie sind unter [https://tunnel.funkfeuer.at/v6/ tunnel.funkfeuer.at/v6] abrufbar und zeigen die Topologie aus der Standortsicht des Tunnelservers.

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

==== Login ====
Die Map-Darstellung und die Quelldaten für das Javascript-Overlay sind nur nach einem Login mit einem Redeemer-User verfügbar.

==== Knotenzuordnung ====
Die korrekte Erkennung der Zuordnung einer IPv6-Adreesse zu einem Knoten ist Vorraussetzung für die Darstellung der aktuellen Topologie auf der Karte. Diese Erkennung wird mit mehreren Methoden versucht:
* (zukünftig geplant!) Abfrage der Knotenzuordnung direkt aus dem Redeemer-Daten
* Identifikation über die NodeID, die in der IPv6-Adresse des Originators enthalten ist
* Ableiten der NodeID des Originators, welcher die IPv6-Adresse als attached_lan ankündigt
* Erkennen der IPv4-Adresse des OLSRv2-Routers und deren Knotenzugehörigkeit: stündlich scannt ein cronjob alle olsr(v1)@IPv4-Geräte und ruft deren eventuelle OLSRv2-IP-Adressen ab. Dabei wird auch ein ping6 zur Originator-IPv6 versucht (bis zu 3x). Die Ergebnisse fliessen in die Map-Anzeige mit ein: IPv4 des IPv6-Routers, OLSRv2-Daemonversion, Ping-Ergebnis

==== Farben der Knoten ====
* Grün: ok, an diesem Node ist ein OLSRv2/IPv6-Router aktiv und erreichbar
* Rot: nok, dieser Node ist von der OLSRv2-Domain isoliert und nicht erreichbar
* Blau: nok, dieser Node konnte mittels ping6 nicht erreicht werden
* Weiß: nok, dieser Node ist nur mit olsr(1)@IPv4 erreichbar

==== Farben der Links ====
* Grün: beide Linknachbarn sind erreichbar
* Blau: einer der Linkpartner ist nicht teil des OLSRv2-Broadcasts, aber dennoch erreichbar
* Rot: einer der Linknachbarn war mittels ping6 nicht erreichbar
* Grau: keine OLSRv2-Verbindung, sondern nur olsr(1)@IPv4

== Abhängigkeiten ==
* [[Services/Organisation/Redeemer]]
* [[Services/Organisation/BaseMap]]

Services/Organisation/Olsr2-Map

2020-05-27T08:13:50Z

Pocki: Die Seite wurde neu angelegt: „== Beschreibung == Die OLSRv2-Map, verlinkt unter [https://map.funkfeuer.at/ map.funkfeuer.at], stellt die IPv6@OLSRv2-Topologie dar. Die nötigen Daten werde…“

Services/Organisation/BaseMap

2020-05-27T07:59:50Z

Pocki: /* MapSpecialConfig */

== Beschreibung ==

Die BaseMap war lange Zeit ''die'' Map des Funknetzes unter [https://map.funkfeuer.at/wien/ map.funkfeuer.at/wien]. Diese Map zeigt '''nur IPv4-Adressen und olsrd(v1)''' Topologie. Die nötigen Daten werden aus der Postgres-Datenbank des Redeemers und einer lokal laufenden olsrd-Instanz geholt und miteinander verschnitten. Die Darstellung erfolgt auf einer GoogleMaps Karte und ist in JavaScript umgesetzt.

Gehostet wird der Webservice im Rechnenzentrum von Nessus.

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

==== Login ====
Ohne Login kann die Map nur anonymisierte Knoten ohne IP-Adressen darstellen, deren Geokoordinaten sind gerastert/gerundet.

Ohne Login und aufgerufen von einer FunkFeuer-IP-Adresse kann man die exakten Locations der Knoten sehen und auch die Funktion "Show all Links" aktivieren. Ein Textbaustein "precise locations on" signalisiert diesen Zustand in der Login-Box.

Erst nach einem Login mit einem gültigem Redeemer-User können die kompletten Daten eingesehen werden, darunter Knotennamen und Inhaber/Betreiber-Kontaktdaten und IP-Adressen.

Mittels der Checkbox "Remember" bei den Login-Feldern kann der Login für 30 Tage über ein Browsercookie "behalten" werden. Bei jedem Map-Besuch fängt dieser 30-Tage-Zähler neu an. Ohne dieser Funktion wird der Login nach dem Auslaufen der Session innerhalb von 24min verworfen. Durch Ausloggen wird auch der AutoLogin im betroffenen Browser wieder verworfen. Eine Änderung des Redeemer-Passworts macht alle vorhandenen AutoLogin-Cookies ungültig.

==== MapSpecialConfig ====

Einige Zustände, die für die Darstellung relevant sind, können aus der Topologie nicht erkannt werden. Folgende Wiki-Page wird in der Datenaufbereitung für die Map als Spezial-Steuerung abgerufen: [[Regionen/Wien/MapSpecialConfig]]

== Abhängigkeiten ==
Die Datenquelle der Map wird auch von anderen Applikationen genutzt.

Services/Organisation/Redeemer

2020-05-27T07:32:46Z

Pocki: /* Funktionen */

== Beschreibung ==

Der Redeemer ist die Verwaltung von Usern, Knoten und IP-Adressen für unser Funknetz, erreichbar unter [https://portal.funkfeuer.at/wien/ portal.funkfeuer.at/wien]. Die nötigen Daten werden in einer Postgres-Datenbank gespeichert.

Gehostet wird der Webservice im Rechnenzentrum von Nessus. Die Datenbank liegt auf einem Host im Housing "Vault".

Die Code-Quelle findet sich auf [https://gitlab.com/funkfeuer/redeemer gitlab.com/funkfeuer/redeemer].

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

Seit Mai 2019 können auch IPv6-Adressen für den Adressraum von OLSRv2 verwaltet werden - siehe [[Projekte/Redeemer-Wien]]

==== Verwaltete Daten ====
siehe [[Projekte/Datenschutz]]

==== Hauptseite ====
* Anzeige der eigenen Kontaktdaten
* Anzeige Anzahl Vereinsmitglieder (nur für Mitglieder)
* Anzeige Anzahl der eigenen Nodes und IP-Adressen und Onlinezustand

==== Zuletzt-Online ====
* Regelmäßige Pings und Topologie-Abfragen stellen den Onlinezustand jeder IP-Adresse fest und vermerken den Zeitpunkt etwa alle 10min in der Datenbank.

== Abhängigkeiten ==
Die im Redeemer verwalteten Daten werden in einigen anderen Applikationen genutzt:

==== DNS Auth ====
Anlage von A/AAAA und PTR records

==== Maps ====
Geographische Darstellung der Knoten und deren Links.

Siehe auch:
* [[Services/Organisation/BaseMap]]
* [[Services/Organisation/Node Map]]
* [[Services/Organisation/Olsr2-Map]]

==== SmokePing ====
Siehe auch:
* [Services/Organisation/Node Monitoring]

==== LDAP ====

==== WHOIS ====

==== VOIP ====
Siehe auch:
* [[Services/Organisation/VoIP]]

Services/Organisation/BaseMap

2020-05-27T07:29:51Z

Pocki: Die Seite wurde neu angelegt: „== Beschreibung == Die BaseMap war lange Zeit ''die'' Map des Funknetzes unter [https://map.funkfeuer.at/wien/ map.funkfeuer.at/wien]. Diese Map zeigt '''nur…“

== Beschreibung ==

Die BaseMap war lange Zeit ''die'' Map des Funknetzes unter [https://map.funkfeuer.at/wien/ map.funkfeuer.at/wien]. Diese Map zeigt '''nur IPv4-Adressen und olsrd(v1)''' Topologie. Die nötigen Daten werden aus der Postgres-Datenbank des Redeemers und einer lokal laufenden olsrd-Instanz geholt und miteinander verschnitten. Die Darstellung erfolgt auf einer GoogleMaps Karte und ist in JavaScript umgesetzt.

Gehostet wird der Webservice im Rechnenzentrum von Nessus.

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

==== Login ====
Ohne Login kann die Map nur anonymisierte Knoten ohne IP-Adressen darstellen, deren Geokoordinaten sind gerastert/gerundet.

Ohne Login und aufgerufen von einer FunkFeuer-IP-Adresse kann man die exakten Locations der Knoten sehen und auch die Funktion "Show all Links" aktivieren. Ein Textbaustein "precise locations on" signalisiert diesen Zustand in der Login-Box.

Erst nach einem Login mit einem gültigem Redeemer-User können die kompletten Daten eingesehen werden, darunter Knotennamen und Inhaber/Betreiber-Kontaktdaten und IP-Adressen.

Mittels der Checkbox "Remember" bei den Login-Feldern kann der Login für 30 Tage über ein Browsercookie "behalten" werden. Bei jedem Map-Besuch fängt dieser 30-Tage-Zähler neu an. Ohne dieser Funktion wird der Login nach dem Auslaufen der Session innerhalb von 24min verworfen. Durch Ausloggen wird auch der AutoLogin im betroffenen Browser wieder verworfen. Eine Änderung des Redeemer-Passworts macht alle vorhandenen AutoLogin-Cookies ungültig.

== Abhängigkeiten ==
Die Datenquelle der Map wird auch von anderen Applikationen genutzt.

Services/Organisation/Redeemer

2020-05-27T07:10:51Z

Pocki:

Services/Organisation/Redeemer

2020-05-27T07:08:42Z

Pocki:

== Beschreibung ==

Der Redeemer ist die Verwaltung von Usern, Knoten und IP-Adressen für unser Funknetz, erreichbar unter [[https://portal.funkfeuer.at/wien/ portal.funkfeuer.at/wien]]. Die nötigen Daten werden in einer Postgres-Datenbank gespeichert.

Gehostet wird der Webservice im Rechnenzentrum von Nessus. Die Datenbank liegt auf einem Host im Housing "Vault".

Die Code-Quelle findet sich auf [[https://gitlab.com/funkfeuer/redeemer gitlab.com/funkfeuer/redeemer]].

== Maintainer ==
* [[Benutzer:Pocki|Christian Pock]]

== Funktionen ==

==== Verwaltete Daten ====
siehe [[Projekte/Datenschutz]]

==== Hauptseite ====
* Anzeige der eigenen Kontaktdaten
* Anzeige Anzahl Vereinsmitglieder (nur für Mitglieder)
* Anzeige Anzahl der eigenen Nodes und IP-Adressen und Onlinezustand

==== Zuletzt-Online ====
* Regelmäßige Pings und Topologie-Abfragen stellen den Onlinezustand jeder IP-Adresse fest und vermerken den Zeitpunkt etwa alle 10min in der Datenbank.

== Abhängigkeiten ==
Die im Redeemer verwalteten Daten werden in einigen anderen Applikationen genutzt:

==== DNS Auth ====
Anlage von A/AAAA und PTR records

==== Maps ====
Geographische Darstellung der Knoten und deren Links.

Siehe auch:
* [[Services/Organisation/BaseMap]]
* [[Services/Organisation/Node Map]]
* [[Services/Organisation/Olsr2-Map]]

==== SmokePing ====
Siehe auch:
* [[Services/Organisation/Node Monitoring]]

==== LDAP ====

==== WHOIS ====

==== VOIP ====
Siehe auch:
* [[Services/Organisation/VoIP]]

Services/Organisation/Redeemer

2020-05-27T07:08:07Z

Pocki: Die Seite wurde neu angelegt: „== Beschreibung == Der Redeemer ist die Verwaltung von Usern, Knoten und IP-Adressen für unser Funknetz, erreichbar unter https://portal.funkfeuer.at/wien/…“

Services/Organisation

2020-05-22T08:55:13Z

Pocki: Split BaseMap von Redeemer&DB

Diese Seite dient dazu die verschiedenen Services von FunkFeuer zu organisieren und zu definieren.

== Core Services ==

{| class="wikitable"
! scope="col"| Service
! scope="col"| Kurzbeschreibung
! scope="col"| Maintainer
! scope="col"| Page
|-
| Backbone Network
| Betrieb und Wartung des kabelgebundenen Backbone Netzes inkl. zugehöriger Glasfaserstrecken und der Internetanbindung. Es stellt Netzwerkanbindungen für das Funknetzwerk, Serverhousing sowie interner Dienste bereit.
| [[Benutzer:stefan|Stefan Schultheis]], Wolfgang Nagele, Simon Schwendemann
| [[Services/Organisation/Backbone Network]]
|-
| Core Infrastruktur
| BB-Wiki, Backups, Monitoring, [[Services/Security|Abuse, Security]],...
| Adi Kriegisch, Markus Gschwendt, (und weitere)
| [[Services/Organisation/Core Infrastruktur]]
|-
| Roof Nodes
| Wartung der Standorte welche die Anbindung des Funknetzwerks an das kabelgebundene Netzwerk bereit stellen.
| Markus Gschwendt, Markus Kittenberger [[mailto:freebone@lists.funkfeuer.at Verstärkung gesucht]]
| [[Services/Organisation/Roof Nodes]]
|-
| Redeemer & DB
| Userinterface und Datenbank des Redeemer-Wien unter [https://portal.funkfeuer.at/wien/ Portal] zur Verwaltung von Usern, Nodes, Devices, IP-Adressen.
| [[Benutzer:pocki|Christian Pock]]
| [[Services/Organisation/Redeemer]]
|-
| BaseMap
| BaseMap unter [https://map.funkfeuer.at/wien/ map.funkfeuer.at/wien]
| [[Benutzer:pocki|Christian Pock]]
| [[Services/Organisation/BaseMap]]
|-
| Node Map
| NodeMap unter [https://map.funkfeuer.at/nodemap/ map.funkfeuer.at/nodemap] - siehe Detailseite
| [[Benutzer:erich|Erich N. Pekarek]], Alexander Biringer
| [[Services/Organisation/Node Map]]
|-
| Olsr2-Map
| Olsr2-Map, verlinkt auf [https://map.funkfeuer.at/ map.funkfeuer.at]
| [[Benutzer:pocki|Christian Pock]]
| [[Services/Organisation/Olsr2-Map]]
|-
| Datenpflege Nodes
| Wartung der Daten in der Knoten Datenbank im [https://portal.funkfeuer.at/ Portal]
| [[Benutzer:vchrizz|Christoph Loesch]], [[Benutzer:damadmai|Daniel A. Maierhofer]]
| [[Services/Organisation/Redeemer]]
|-
| Node DB
| <span style="color:#ff0000">TBD by Maintainer</span>
| '''<DU?>'''
| [[Services/Organisation/Node DB]]
|-
| Node Monitoring
| [http://smokeping.funkfeuer.at/ SmokePing] für Freenet und Housing, Erkennung von LastSeen, Anzeige jüngster Olsr(v1)-Topologieänderungen
| Adi Kriegisch, Clemens Hopfer, [[Benutzer:pocki|Christian Pock]]
| [[Services/Organisation/Node Monitoring]]
|-
| Tunnelserver
| OpenVPN Tunnel für Verbindung über Internet zum FunkFeuer-Netzwerk
| [[Benutzer:erich|Erich N. Pekarek]], [[Benutzer:vchrizz|Christoph Lösch]], [[Benutzer:Pocki|Christian Pock]], [[Benutzer:damadmai|Daniel A. Maierhofer]]
| [[Services/Organisation/Tunnelserver]]
|-
| Housing Environment
| <span style="color:#ff0000">TBD by Maintainer - wir starten demnächst mit dem Brainstorming / stay tuned</span>
| Michael Med, Gerhard Steinbeis, Clemens Hopfer
| [[Services/Organisation/Housing Environment]]
|-
| Housing Administration
| Housing Frontend, Verwaltung, Rechnungslegung und Buchhaltung
| Clemens Hopfer, Kassiere
| [[Services/Organisation/Housing Administration]]
|-
| Mail
| Betrieb des Mailservers der zur Kommunikation, vor allem über [https://lists.funkfeuer.at/mailman/listinfo Mailinglisten] dient. Derzeit gibt es keine Postfächer für Personen. Diverse Services/Server nutzen den Mailserver als Smarthost.
| [mailto:postmaster@funkfeuer.at Adi Kriegisch, Markus Gschwendt]
| [[Services/Organisation/Mail]]
|-
| Gallery
| Bildersammlung je Knoten, Event,...
Wir wollen dieses Service auf neue Beine stellen. Ein paar Ideen gibt es bereits.
| Markus Gschwendt, '''Co-Maintainer gesucht!'''
| [[Services/Organisation/Gallery]]
|-
| Wiki
| Betrieb dieses Wikis, sowohl technisch (Wartung) als auch organisatorisch (Gardening).
| David Hopfmüller, Matthias Šubik, [[Benutzer:damadmai|Daniel A. Maierhofer]], [[Benutzer:pocki|Christian Pock]]
| [[Services/Organisation/Wiki]]
|-
| Forum
| Betrieb und Wartung des Forum-Servers und der Discourse Instanz für Mitglieder.
| [[Benutzer:kaefert|Thomas Käfer]], [[Benutzer:vchrizz|Christoph Loesch]], [[Benutzer:erich|Erich N. Pekarek]]
| [[Services/Organisation/Forum]]
|-
| VoIP
| Betrieb und Wartung des Voice over IP Servers sowie Web-Frontend für Mitglieder.
| [[Benutzer:erich|Erich N. Pekarek]], [[Benutzer:vchrizz|Christoph Loesch]], '''<DU?>'''
| [[Services/Organisation/VoIP]]
|-
| Website
| Instandhaltung der Frontpages für FunkFeuer und das Housing.
| Clemens Hopfer
| [[Services/Organisation/Website]]
|-
| DNS Auth
| Zones (funkfeuer.at, Reverse)
| Adi Kriegisch, Markus Gschwendt
| [[Services/Organisation/DNS Auth]]
|-
| DNS Recursor
| Recursive DNS für Housing und Funknetz
| Adi Kriegisch, Markus Gschwendt
| [[Services/Organisation/DNS Recursor]]
|-
| Social Media
| Wir betreuen diverse Social Media Kanäle zur Außenkommunikation und freuen uns sehr über (auch gern kurze) Information zu aktuellen Entwicklungen, Bilder etc,
| Peter Schwindt, Paul Fuxjaeger, Clemens Hopfer
| [[Services/Organisation/Social Media]]
|}

Projekte/Datenschutz

2020-05-19T07:41:22Z

Pocki: /* Interne Datenbank */

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt
* Gibt es ein '''Verarbeitungsverzeichnis'''?

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, (Anm. stratuscumulus: Hoffe die Einwilligungen wurden gespeichert, wenn selber hochgeladen umso besser) und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet. (Anm. stratuscumulus: Wenn Bilder angefertigt werden, am besten gleich solch eine Einwilligungserklärung unterzeichnen lassen, bewusst würde ich ''keinesfalls'' darauf verzichten, das ist sehr problematisch)

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?

* Werden E-Mails dort gespeichert?

* Was und wie lange speichert ein evtl. Mailserver?

* Was ist mit dem Redeemer? Was wird dort außer die angezeigten Felder noch gespeichert? [Pocki: nachstehend die Datenfelder der Redeemer-Tabellen (zwecks Lesbarkeit/Verständnis teilweise vereinfacht)]
** MEMBERS: nickname, hash-of-password, firstname, lastname, street, housenumber, zip, town, email, (optional: telephone, mobilephone, fax, homepage), (depricated/empty: mentor_id, instant_messenger_nick), created, changed, last_login, Mitgliedsstatus, Adminstatus
** VERIFY: hash-of-email, status-code-of-mailserver, catch_all-status, debug-text-last-mailserverresponse, last_checked
** NODES: owner, tech_c, (optional:gps), [_]map, [_]smokeping, created, changed, last_seen
** DEVICES: Node, Name, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, created, changed, last_seen
** IP: Node/Device, IPv4, [_]Dns, last_seen
** IP6: Node/Device, Name, IPv6, (optional: Antenne, Hardware, Ssid, Mac), [_]Smokeping, [_]Dns, created, changed, last_seen

* Ist das LDAP damit verbunden? [Pocki: ja, das LDAP-Verzeichnis wird täglich aus einem Teil der Redeemer-Memberdaten erstellt]

* Welche Dienste werden mittels LDAP verifiziert? [Pocki: voip. Auf Userwunsch: Forum]

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki-Account ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

**Gleiche Fragen wie oben

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

Projekte/Datenschutz

2020-05-18T11:15:06Z

Pocki: /* Mitglieder */

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt
* Gibt es ein '''Verarbeitungsverzeichnis'''?

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname = Nutzername, Passwort

== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet.
== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?
* Werden E-Mails dort gespeichert?
* Was und wie lange speichert ein evtl. Mailserver?
* Was ist mit dem Redeemer? Was wird dort außer die
* Ist das LDAP damit verbunden? Welche Dienste werden mittels LDAP verifiziert?

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki-Account ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

**Gleiche Fragen wie oben

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

Projekte/Datenschutz

2020-05-18T11:14:37Z

Pocki: /* Kategorien von Knoten-Inhabern */

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt
* Gibt es ein '''Verarbeitungsverzeichnis'''?

== Social Media ==
* Facebook
* Twitter
** Wir brauchen da auch Datenschutzhinweise, wer betreut das?
** Gibt es nochmehr Social media Auftritte? Youtube?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name) als optionale Angabe zu einem Device

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname, Nutzername, Passwort
== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?
Wir haben/hatten eine Einwilligungsseite beim Hochladen/Registrieren, und die meisten Fotos sind von den abgebildeten selber hochgeladen worden, bzw. sind die abgebildeten Personen Gründer/Vorstandsmitglieder des Vereins. Das hiervon ausgehende Risiko einer Rechtsverletzung ist also sehr überschaubar. Auf explizite, schriftliche Einwilligungserklärungen haben wir bisher (bewusst) verzichtet.
== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript API lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: API-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?
* Werden E-Mails dort gespeichert?
* Was und wie lange speichert ein evtl. Mailserver?
* Was ist mit dem Redeemer? Was wird dort außer die
* Ist das LDAP damit verbunden? Welche Dienste werden mittels LDAP verifiziert?

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki-Account ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

**Gleiche Fragen wie oben

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

Benutzer:Pocki

2020-05-18T09:54:36Z

Pocki: /* OLSRv1 Status */

= Kontaktinfo =
* Name: Christian Pock
* Mail: pocki (at) pocki.at

= Maintainer =

Ich bin (Co-)Maintainer von
* Portal für Redeemer-Wien https://portal.funkfeuer.at/wien/
* Datenbank für Redeemer-Wien
* Basemap https://map.funkfeuer.at/wien/
* Erkennung von lastseen für Anzeige im Redeemer und Map
* Smokeping http://smokeping.funkfeuer.at/

= Links =
== Privates Monitoring ==
: [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status]
: [https://ff.cybercomm.at/map/ OLSRv1-Map]
: [https://ff.cybercomm.at/monitor/olsr2.php OLSRv2-Status]
: [https://ff.cybercomm.at/map2/ OLSRv2-Map]
: [https://ff.cybercomm.at/monitor/tree.php Routen-Veränderungen]
: [https://ff.cybercomm.at/monitor/takedown.php Outage-Simulator]
: [https://rpi.wehr24.wien.funkfeuer.at/health Funkfeuer-Health-Monitor] via [https://uptimerobot.com/ uptimerobot.com]

=== OLSRv1 Status ===
Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen der letzten Tage.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie von Roofnode-Routern über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden dann in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der offiziellen Funkfeuer-Map. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Dupletten entfernt.

Die Zusammenfassung zeigt, welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge - je zahlreicher die Events, desto kürzer also der Betrachtungszeitraum)

=== OLSRv1-Map ===
Visualisierung der Daten von OLSRv1-Status

Diese minimalistische Map verzeichnet nur jene Knoten und Verbindungen, die innerhalb der vergangenen 50 Tagen aktiv waren. Knoten und Verbindungen, welche schon länger offline sind, werden nicht mehr angezeigt.

Knoten sind in folgenden Farben markiert:
* Grün: Teil Core-Netzwerk (=Layer2-Verbund des vlan33)
* Blau: VPN-Endpunkt des Tunnelservers
* Rot: normal übers Funknetz verbunden
* Grau: aktuell offline

Verbindungen sind in folgenden Farben markiert:
* Grün: aktuell verbunden
* Türkis: aktull verbunden, monitoring deaktiviert
* Rot: offline, war innerhalb der vergangenen 50 Tagen vorhanden
* Rot-dunkel: offline, monitoring deaktiviert
* Gelb: Verbindungen zwischen den Core-Netzwerk-Knoten

Klick auf den Node zeigt:
* Node-Name und Node-ID laut Redeemer
* Aktive OLSR Geräte mit IP und Hostname, MID werden nicht aufgezählt

=== OLSRv2-Status ===
Abfrage von OLSRv2-Infos von einem Roofnode-Router.

Erkennen von Node-ID/Node-Name aus den Redeemer-Daten, Originator oder Attached-Networks.

Stündlich scannt ein cronjob alle olsr(1)@IPv4-Geräte und ruft deren OLSRv2-IP-Adressen ab. Dabei wird auch ein ping6 zur Originator-IPv6 versucht (bis zu 3x). Die Ergebnisse fliessen in die Anzeige mit ein: IPv4 des IPv6-Routers, OLSRv2-Daemonversion, Ping-Ergebnis

Ping-Ergebnisse können sein:
* OK: ping6 war erfolgreich
* OLDOK: ping6 war erfolgreich, IPv4 konnte nicht ermittelt werden
* PROBLM: ping6 war erfolgreich, der Router kommt aber nicht im OLSRv2-Broadcast vor!
* ISOOK: ping6 war erfolgreich, obwohl der Route nicht im OLSRv2-Broadcast vorkommt und eigentlich isoliert erscheint
* ISO: ping6 schlug fehl, der Router kommt nicht im OLSRv2-Broadcast vor und ist nicht via OLSRv2 erreichbar weil von der Domain abgeschnitten (isoliert)
* ERR: ping6 schlug fehl, obwohl der Router im OLSRv2-Broadcast vorkommt und daher erreichbar sein sollte.

=== OLSRv2-Map ===
Visualisierung der Daten von OLSRv2-Status, vorhandene OLSRv1-Links werden grau eingeblendet um IPv4-Only-Nodes/Links zu zeigen.

Nodes sind in folgenden Farben markiert:
* Grün: ok, an diesem Node ist ein OLSRv2/IPv6-Router aktiv und erreichbar
* Rot: nok, dieser Node ist von der OLSRv2-Domain isoliert und nicht erreichbar
* Blau: nok, dieser Node konnte mittels ping6 nicht erreicht werden
* Weiß: nok, dieser Node ist nur mit olsr(1)@IPv4 erreichbar

Links sind in folgenden Farben markiert:
* Grün: beide Linknachbarn sind erreichbar
* Blau: einer der Linkpartner ist nicht teil des OLSRv2-Broadcasts, aber dennoch erreichbar
* Rot: einer der Linknachbarn war mittels ping6 nicht erreichbar
* Grau: keine OLSRv2-Verbindung, sondern nur olsr(1)@IPv4

=== Routen-Veränderungen ===
Jede Minute werden die Routen von 10 Nodes überprüft und Änderungen vermerkt. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben!

=== Outage-Simulator ===
Zeigt, welche IP-Adressen durch einen Router-Ausfall ebenfalls nicht mehr erreichbar sein werden.

=== OLSRd Uptime ===
Fragt das httpinfo-plugin (Port 8080) oder jsoninfo-Plugin (Port 9090) ab, um die Uptime und ggf. einen Restart des olsr-daemons festzustellen. Läuft alle 30min über die laut Topologie erreichbaren Router.

: [http://193.238.158.8/lastseen/uptime.dat OLSRd-Uptime]
: [http://193.238.158.8/lastseen/uptime.log OLSRd-Restarts]

=== Funkfeuer-Health-Monitor ===

Der Service uptimerobot.com fragt alle 5min diverse IPs und HTTP(s)-Services ab und speichert Statistiken. Diese kann man über "Public Status Pages" und auch via API abfragen:

: [https://stats.uptimerobot.com/BPl2ySN2Q stats.uptimerobot.com/BPl2ySN2Q] (direkt)
: [https://rpi3p.wehr24.wien.funkfeuer.at/health rpi3p.wehr24.wien.funkfeuer.at/health] (PHP mit API als Datenquelle)
: [https://tunnel.funkfeuer.at/dash/ tunnel.funkfeuer.at/dash] Dashboard auf dem OpenVPN-Tunnelserver mit einigen Connectivity-Infos

== EdgeRouter-Wizards und Code ==
: [https://github.com/pocki80/ER-wizard-Setup0xFF/releases ER-wizard-Setup0xFF]
: [https://github.com/vchrizz/ER-wizard-OLSRd_V1 ER-wizard-OLSRd_V1] - vchrizz
: [https://github.com/pocki80/ER-wizard-OLSRd_V2 ER-wizard-OLSRd_V2]
: [https://github.com/pocki80/ER-wizard-AutoUpdate ER-wizard-AutoUpdate]
: [https://github.com/pocki80/ER-wizard-ebtables ER-wizard-ebtables]
: [https://github.com/pocki80/ER-wizard-0xFF-WSLE ER-wizard-0xFF-WSLE Webstatus/LetsEncrypt]
: [https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS ER-wizard-OpenVPN-to-Tunnelserver]
: [https://gist.github.com/pocki80/e4c2c16c5c1b8886c8320446768a862f ER-SSH-Prelogin-Banner]
: [https://gist.github.com/pocki80/525cb16b95991c7efed1c053d82422fe ER-ping2web-watchdog]
: [https://gist.github.com/pocki80/fc6ede395e04dde62ce2199a8281261f ER-load_ipv6_hostsfile]
: [https://gist.github.com/pocki80/eeea81945111ac14b937bd46b83412d2 ER-showOlsrLinks-script]
: [https://gist.github.com/pocki80/ab7e239ff78433f4ce8dec371aa0b237 ER-bootLoaderUpdateCheck-script]
: [https://gist.github.com/pocki80/6960085702072220ed48e1137dd5e080 ER-powerCycleEthPort-script]
: [https://github.com/dabeani/0xFF-BMK-webstatus 0xFF-BMK-webstatus] - dabeani

=== ER-wizard-Setup0xFF ===
Der 0xFF-Setup-Wizard ist der einfachste und schnellste Weg, einen jungfräulichen (=befindet sich in factory default settings) EdgeRouter-X für den Betrieb mit Funkfeuer zu konfigurieren. Der Wizard enthält die Offline-Installations-Files für OLSR und OLSRd2 und kann daher ohne vorhandene Netzwerk- oder Funkverbindung angewendet werden. Minimal-Eingaben für eine Basiskonfiguration sind die Funkfeuer-IP und die Node-ID.

Vorgehensweise für die Anwendung/Installation des 0xFF-Setup-Wizards:
* Download der aktuellsten Release vom Github: https://github.com/pocki80/ER-wizard-Setup0xFF/releases
* Router mit Strom versorgen (bootet knapp 60sek) und Notebook/PC mit Port eth0 verbinden
* am Notebook/PC eine fixe IP 192.168.1.2/24 vergeben (der Router hat per default an eth0 die IP 192.168.1.1/24, dhcp disabled)
* im Browser die Page https://192.168.1.1/ aufrufen, eventuelle SSL-Zertifikatswarnungen akzeptieren/übergehen
* Default-User "ubnt" und Default-Passwort beim Login eingeben, dann den Tab-Reiter "Wizards" aufrufen
* in der Wizard-Liste (rechter Rand) auf "+" klicken, um den 0xFF-Wizard hinzuzufügen: Name "0xFF-Setup" eingeben, und die runtergeladene Wizard-TAR.GZ-File im Dateidialog auswählen, danach die Installation bestätigen.
* in der Wizard-Liste (rechter Rand) den neuen 0xFF-Setup-Wizard auswählen (falls nicht schon passiert).

Von diesem Punkt an helfen die Texte direkt im Wizard bei der Initial-Konfiguration:
* Screenshot: https://github.com/pocki80/ER-wizard-Setup0xFF/releases/download/v1.2/Wizard-Screenshot.jpg

=== ER-wizard-OLSRd_V1 ===
Installiert und konfiguriert den olsr (v1) daemon für IPv4 und IPv6. Seit 2017 wird für IPv6 allerdings nicht mehr der olsr(v1), sondern olsrv2 genutzt.

=== ER-wizard-OLSRd_V2 ===
Installiert und konfiguriert den olsrv2 daemon für IPv6.

Dokumentation: [[Medium:OLSRd_V2_Wizard.pdf|OLSRd_V2_Wizard.pdf]]

=== ER-wizard-AutoUpdate ===
Ruft täglich die aktuelle Version auf github ab und installiert gegebenenfalls das aktuelle Update automatisch. Unterstützte Wizards sind: OLSRd_V1, OLSRd_V2, AutoUpdate, WSLE, ebtables

=== ER-wizard-0xFF-WSLE Webstatus/LetsEncrypt ===
Installiert einen zweiten lighttpd für eine Status-Seite und managed das SSL-Zertifikat mittels Lets-Encrypt.

=== ER-wizard-ebtables ===
Ermöglicht es, die Regeln zum Forwarden von Traffic für einzelne Bridges zu aktivieren (generell wird im Bridge-Setup des OLSRd_V1 das Forwarding zwischen den OLSR-Interfaces unterbunden).

=== OpenVPN-to-Tunnelserver ===
Wizard zum Einrichten und Verwalten eines OpenVPN-Tunnels zum Funkfeuer-Tunnelserver.

=== ER-SSH-Prelogin-Banner ===
Fügt der Welcome-Message vom SSH-daemon nützliche Informationen hinzu, um schon vor der Passwort-Eingabe erkennen zu können, um welchen Router und Standort es sich handelt.

CLI> curl -sS https://gist.githubusercontent.com/pocki80/e4c2c16c5c1b8886c8320446768a862f/raw/0xffedgebanner.sh | sudo bash

Welcome to EdgeOS
| |
,---.,---|,---.,---.,---.,---.. .|--- ,---.,---.
|---`| || ||---`| | || || |---`|
`---``---``---|`---`` `---``---``--- `---``
`---` :: edgerouter-router ::
Location: 1234, Knoten 4567
Contact : meine@mailadresse.com
SerialNo: AA:BB:CC:DD:EE:FF

=== Ping-2-Web watchdog ===
Script mit Cronjob, dass alle 12h einen Ping ins Internet absetzt. Bei Misserfolg wird der Ping innerhalb 4-11min wiederholt: bei neuerlichem Fehler wird 1min später der Router rebootet, dabei werden auch die angesteckten PoE-Ports einem PowerCycle unterzogen.

CLI> curl -sS https://gist.githubusercontent.com/pocki80/525cb16b95991c7efed1c053d82422fe/raw/set_ping2web.sh | sudo bash

=== ER-load_ipv6_hostsfile ===
Lädt einmalig alle bekannten OLSR2-IPv6-Adressen aus http://193.238.158.8/0xFF-BMK-webstatus/hosts_originators.txt in die lokale File /etc/hosts:

CLI> curl -sS https://gist.githubusercontent.com/pocki80/fc6ede395e04dde62ce2199a8281261f/raw/load_ipv6_hostsfile.sh | sudo bash

=== ER-showOlsrLinks-script ===
Installiert /usr/local/bin/links script, welches aus einem (1) beliebigen olsrd_info-plugin oder dem Routing-Table die Link-Nachbarn raussucht, je nachdem welches Plugin verfügbar ist. Abgefragt wird olsrd (IPv4) und olsrd2 (IPv6), Anzeige der Default-Route und der Anzahl an Routeneinträgen für den jeweiligen Nachbarn. Überlebt ein FW-Update, da es via post-config.d nachinstalliert wird, wenn weg. Aufruf des commands einfach mittels "links".

CLI> curl -sS https://gist.githubusercontent.com/pocki80/eeea81945111ac14b937bd46b83412d2/raw/install_links_script.sh | sudo bash
CLI> links

olsrd links from txtinfo_plugin
Local IP Remote IP Hyst. LQ NLQ Cost #rts def?
78.41.112.40 193.238.159.153 0.00 1.000 1.000 1.000 2 -
78.41.112.40 78.41.112.141 0.00 1.000 1.000 1.000 486 default
78.41.112.40 78.41.112.3 0.00 1.000 0.510 1.961 5 -

olsrd2 links from nhdpinfo
Int Remote IPv6 Cnt-Routes
br0 2a02:61:0:ff:822a:a8ff:fe5f:8611 2 routes -
br0 2a02:61:0:ff:46d9:e7ff:fe50:2a84 13 routes -
br0 2a02:61:0:ff:feec:daff:fe4d:248f 89 routes default

=== ER-bootLoaderUpdateCheck-script ===
Prüft den aktuellen Router auf Modell, Firmware, Bootloader-Signatur und angeschlossene Geräte (PoE?). Empfiehlt gegebenenfalls das BootLoader-Update inkl. nötige Commands dafür.

Siehe https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-X-X-SFP-bootloader-update/ba-p/1472216

CLI> curl -sS https://gist.githubusercontent.com/pocki80/ab7e239ff78433f4ce8dec371aa0b237/raw/boot-loader-update-check.sh | bash

HW model: EdgeRouter X SFP 6-Port
unpatched - 1 non-poe-port has a link - consider to update...

curl -O https://dl.ubnt.com/firmwares/edgemax/v1.8.0/update-boot.sh
sudo bash update-boot.sh

=== ER-powerCycleEthPort-script ===
Ab EdgeOS 1.10.5 und 2.0.0 behält der EdgeRouter-X-SFP den PoE-Zustand der Ports beim Reboot bei (beim ER-X wird PoE auf eth4 wie bisher kurz unterbrochen). Dadurch werden beim Router-Reboot die Antennen nicht mitrebootet. Um eine angesteckte Antenne mit einem einfachen CLI-Command neuzustarten, kann dieses einfache Script installiert und genutzt werden, es bleibt bei einem FW-Update auch erhalten:

CLI> curl -sS https://gist.githubusercontent.com/pocki80/6960085702072220ed48e1137dd5e080/raw/install_powercycle_script.sh | sudo bash
CLI> powercycle eth4

=== 0xFF-BMK-webstatus ===
Status-Seite und API für Monitoring - ist im WSLE-Wizard eingebunden

= Knoten =
; Betreiber bzw. Tech_C folgender Funkfeuer-Knoten
: wehr24
: luxi122home

Benutzer:Pocki

2020-05-18T09:51:58Z

Pocki: /* OLSRv2-Status */

= Kontaktinfo =
* Name: Christian Pock
* Mail: pocki (at) pocki.at

= Maintainer =

Ich bin (Co-)Maintainer von
* Portal für Redeemer-Wien https://portal.funkfeuer.at/wien/
* Datenbank für Redeemer-Wien
* Basemap https://map.funkfeuer.at/wien/
* Erkennung von lastseen für Anzeige im Redeemer und Map
* Smokeping http://smokeping.funkfeuer.at/

= Links =
== Privates Monitoring ==
: [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status]
: [https://ff.cybercomm.at/map/ OLSRv1-Map]
: [https://ff.cybercomm.at/monitor/olsr2.php OLSRv2-Status]
: [https://ff.cybercomm.at/map2/ OLSRv2-Map]
: [https://ff.cybercomm.at/monitor/tree.php Routen-Veränderungen]
: [https://ff.cybercomm.at/monitor/takedown.php Outage-Simulator]
: [https://rpi.wehr24.wien.funkfeuer.at/health Funkfeuer-Health-Monitor] via [https://uptimerobot.com/ uptimerobot.com]

=== OLSRv1 Status ===
Überwacht die Veränderung der OLSR(1)-Topologie, speichert Veränderungen.

Das Tool [https://ff.cybercomm.at/monitor/olsr.php OLSRv1-Status] holt die Topologie zweier Router (metalab, wehr24) über das http-plugin. Die Daten werden bis zu 4min zwischengespeichert, um die wiederkehrenden Topologie-Querries zu diesen Routern einzusparen. Erfolgen keine "User-Aufrufe" von OLSRv1-Status oder OLSRv1-Map, so aktualisieren sich die Daten alle 10min.

Alle IPs aus der Topologie werden dann in Device-Name und Node-Name umgeschlüsselt. Das passiert primär über die Daten aus der offiziellen Funkfeuer-Map. Wo nicht möglich (Node für Map deaktiviert?) wird ein DNS-Lookup durchgeführt (ebenfalls gecached). Die Links "Von-Node"-"Zu-Node" und "Nodeintern:VonDevice-ZuDevice" werden alphanumerisch sortiert und Duppletten entfernt.

Die Zusammenfassung zeigt welche Nodes erkannt wurden, welche fehlen, welche Links instabil sind,... Die "Spezialnodes" werden über deren Links zum Tunnelserver, zu Kryptaroof und zu Nessus erkannt und unterschieden.

Bei jedem Durchlauf werden die aktuellen Links gegen die gespeicherten Links vergleichen - der Match-Key sind dabei die Node/Geräte-Namen. Ändern sich IP-Adressen, spielt das also keine Rolle / Ändern sich Geräte/Node-Namen bei gleichbleibenden IP-Adressen, wird das als Änderung festgehalten.
* Fehlt aktuell ein Link, der beim vorigen Durchlauf vorhanden war, bekommt diese Link den Status "offline" mit Zeitstempel "offline-since".
* Ist ein Link vorhanden, welcher in der Logfile mit "offline-since" vermerkt ist, dann wird dieser Link als "wiederhergestellt" eingestuft. Der Zeitstempel "offline-since" wird entfernt und ein Zeitstempel "recovered-at" zugewiesen.
* Ist ein Link aktuell vorhanden, der in der Logfile fehlt, wird dieser als "neu" eingestuft

Der Zustand des Links (up oder down) wird für die letzten 200 (etwa 1 bis 1.5 Tage) Durchläufe gespeichert.
* Das Verhältnis "Online-Zustände" zu "Anzahl-Zustände" ergibt den Wert "Online-%". Beispiel 99% bedeutet: von den letzten 200 Proben war der Link 2x down
* Das Verhältnis "Zustandswechsel" zu "Anzahl-Zustände" ergbit die Swap-Rate. Beispiel 4% bedeutet: während der letzten 200 Proben ging die Verbindung 8x in einen anderen Zustand, also vermutlich 4x down und 4x up.

Links mit einer Swap-Rate >2% werden als "Instable" eingestuft und bekommen den Zeitstempel "Swapping since" zugewiesen. Dieser Zustand wird geprüft, wenn ein Link gerade offline gegangen ist. Instable-Links werden als "Stable" eingestuft, wenn sie mit einem Zeitstempel "swapping since" markiert sind und in diesem Moment die Swap-Rate <2% ist. Diese Prüfung wird vorgenommen, wenn ein Link online kommt oder schon länger online ist, jedoch noch den Zeitstempel "swapping since" trägt.

Die Logfile ist 2-teilig: Topologiezustand (Links, Zeitstempel), Notifications/Eventhistory (begrenzt auf 9.000 Einträge)

=== OLSRv1-Map ===
Visualisierung der Daten von OLSRv1-Status

Diese minimalistische Map verzeichnet nur jene Knoten und Verbindungen, die innerhalb der vergangenen 50 Tagen aktiv waren. Knoten und Verbindungen, welche schon länger offline sind, werden nicht mehr angezeigt.

Knoten sind in folgenden Farben markiert:
* Grün: Teil Core-Netzwerk (=Layer2-Verbund des vlan33)
* Blau: VPN-Endpunkt des Tunnelservers
* Rot: normal übers Funknetz verbunden
* Grau: aktuell offline

Verbindungen sind in folgenden Farben markiert:
* Grün: aktuell verbunden
* Türkis: aktull verbunden, monitoring deaktiviert
* Rot: offline, war innerhalb der vergangenen 50 Tagen vorhanden
* Rot-dunkel: offline, monitoring deaktiviert
* Gelb: Verbindungen zwischen den Core-Netzwerk-Knoten

Klick auf den Node zeigt:
* Node-Name und Node-ID laut Redeemer
* Aktive OLSR Geräte mit IP und Hostname, MID werden nicht aufgezählt

=== OLSRv2-Status ===
Abfrage von OLSRv2-Infos von einem Roofnode-Router.

Erkennen von Node-ID/Node-Name aus den Redeemer-Daten, Originator oder Attached-Networks.

Stündlich scannt ein cronjob alle olsr(1)@IPv4-Geräte und ruft deren OLSRv2-IP-Adressen ab. Dabei wird auch ein ping6 zur Originator-IPv6 versucht (bis zu 3x). Die Ergebnisse fliessen in die Anzeige mit ein: IPv4 des IPv6-Routers, OLSRv2-Daemonversion, Ping-Ergebnis

Ping-Ergebnisse können sein:
* OK: ping6 war erfolgreich
* OLDOK: ping6 war erfolgreich, IPv4 konnte nicht ermittelt werden
* PROBLM: ping6 war erfolgreich, der Router kommt aber nicht im OLSRv2-Broadcast vor!
* ISOOK: ping6 war erfolgreich, obwohl der Route nicht im OLSRv2-Broadcast vorkommt und eigentlich isoliert erscheint
* ISO: ping6 schlug fehl, der Router kommt nicht im OLSRv2-Broadcast vor und ist nicht via OLSRv2 erreichbar weil von der Domain abgeschnitten (isoliert)
* ERR: ping6 schlug fehl, obwohl der Router im OLSRv2-Broadcast vorkommt und daher erreichbar sein sollte.

=== OLSRv2-Map ===
Visualisierung der Daten von OLSRv2-Status, vorhandene OLSRv1-Links werden grau eingeblendet um IPv4-Only-Nodes/Links zu zeigen.

Nodes sind in folgenden Farben markiert:
* Grün: ok, an diesem Node ist ein OLSRv2/IPv6-Router aktiv und erreichbar
* Rot: nok, dieser Node ist von der OLSRv2-Domain isoliert und nicht erreichbar
* Blau: nok, dieser Node konnte mittels ping6 nicht erreicht werden
* Weiß: nok, dieser Node ist nur mit olsr(1)@IPv4 erreichbar

Links sind in folgenden Farben markiert:
* Grün: beide Linknachbarn sind erreichbar
* Blau: einer der Linkpartner ist nicht teil des OLSRv2-Broadcasts, aber dennoch erreichbar
* Rot: einer der Linknachbarn war mittels ping6 nicht erreichbar
* Grau: keine OLSRv2-Verbindung, sondern nur olsr(1)@IPv4

=== Routen-Veränderungen ===
Jede Minute werden die Routen von 10 Nodes überprüft und Änderungen vermerkt. Die Nodes auf den Routen der 10 Ziel-Nodes werden dabei gleich mitaktualisiert. Es wird angenommen, dass alle IPs eines Nodes die selbe Route zum Border-Gateway haben!

=== Outage-Simulator ===
Zeigt, welche IP-Adressen durch einen Router-Ausfall ebenfalls nicht mehr erreichbar sein werden.

=== OLSRd Uptime ===
Fragt das httpinfo-plugin (Port 8080) oder jsoninfo-Plugin (Port 9090) ab, um die Uptime und ggf. einen Restart des olsr-daemons festzustellen. Läuft alle 30min über die laut Topologie erreichbaren Router.

: [http://193.238.158.8/lastseen/uptime.dat OLSRd-Uptime]
: [http://193.238.158.8/lastseen/uptime.log OLSRd-Restarts]

=== Funkfeuer-Health-Monitor ===

Der Service uptimerobot.com fragt alle 5min diverse IPs und HTTP(s)-Services ab und speichert Statistiken. Diese kann man über "Public Status Pages" und auch via API abfragen:

: [https://stats.uptimerobot.com/BPl2ySN2Q stats.uptimerobot.com/BPl2ySN2Q] (direkt)
: [https://rpi3p.wehr24.wien.funkfeuer.at/health rpi3p.wehr24.wien.funkfeuer.at/health] (PHP mit API als Datenquelle)
: [https://tunnel.funkfeuer.at/dash/ tunnel.funkfeuer.at/dash] Dashboard auf dem OpenVPN-Tunnelserver mit einigen Connectivity-Infos

== EdgeRouter-Wizards und Code ==
: [https://github.com/pocki80/ER-wizard-Setup0xFF/releases ER-wizard-Setup0xFF]
: [https://github.com/vchrizz/ER-wizard-OLSRd_V1 ER-wizard-OLSRd_V1] - vchrizz
: [https://github.com/pocki80/ER-wizard-OLSRd_V2 ER-wizard-OLSRd_V2]
: [https://github.com/pocki80/ER-wizard-AutoUpdate ER-wizard-AutoUpdate]
: [https://github.com/pocki80/ER-wizard-ebtables ER-wizard-ebtables]
: [https://github.com/pocki80/ER-wizard-0xFF-WSLE ER-wizard-0xFF-WSLE Webstatus/LetsEncrypt]
: [https://github.com/pocki80/ER-wizard-0xFF-OpenVPN2TS ER-wizard-OpenVPN-to-Tunnelserver]
: [https://gist.github.com/pocki80/e4c2c16c5c1b8886c8320446768a862f ER-SSH-Prelogin-Banner]
: [https://gist.github.com/pocki80/525cb16b95991c7efed1c053d82422fe ER-ping2web-watchdog]
: [https://gist.github.com/pocki80/fc6ede395e04dde62ce2199a8281261f ER-load_ipv6_hostsfile]
: [https://gist.github.com/pocki80/eeea81945111ac14b937bd46b83412d2 ER-showOlsrLinks-script]
: [https://gist.github.com/pocki80/ab7e239ff78433f4ce8dec371aa0b237 ER-bootLoaderUpdateCheck-script]
: [https://gist.github.com/pocki80/6960085702072220ed48e1137dd5e080 ER-powerCycleEthPort-script]
: [https://github.com/dabeani/0xFF-BMK-webstatus 0xFF-BMK-webstatus] - dabeani

=== ER-wizard-Setup0xFF ===
Der 0xFF-Setup-Wizard ist der einfachste und schnellste Weg, einen jungfräulichen (=befindet sich in factory default settings) EdgeRouter-X für den Betrieb mit Funkfeuer zu konfigurieren. Der Wizard enthält die Offline-Installations-Files für OLSR und OLSRd2 und kann daher ohne vorhandene Netzwerk- oder Funkverbindung angewendet werden. Minimal-Eingaben für eine Basiskonfiguration sind die Funkfeuer-IP und die Node-ID.

Vorgehensweise für die Anwendung/Installation des 0xFF-Setup-Wizards:
* Download der aktuellsten Release vom Github: https://github.com/pocki80/ER-wizard-Setup0xFF/releases
* Router mit Strom versorgen (bootet knapp 60sek) und Notebook/PC mit Port eth0 verbinden
* am Notebook/PC eine fixe IP 192.168.1.2/24 vergeben (der Router hat per default an eth0 die IP 192.168.1.1/24, dhcp disabled)
* im Browser die Page https://192.168.1.1/ aufrufen, eventuelle SSL-Zertifikatswarnungen akzeptieren/übergehen
* Default-User "ubnt" und Default-Passwort beim Login eingeben, dann den Tab-Reiter "Wizards" aufrufen
* in der Wizard-Liste (rechter Rand) auf "+" klicken, um den 0xFF-Wizard hinzuzufügen: Name "0xFF-Setup" eingeben, und die runtergeladene Wizard-TAR.GZ-File im Dateidialog auswählen, danach die Installation bestätigen.
* in der Wizard-Liste (rechter Rand) den neuen 0xFF-Setup-Wizard auswählen (falls nicht schon passiert).

Von diesem Punkt an helfen die Texte direkt im Wizard bei der Initial-Konfiguration:
* Screenshot: https://github.com/pocki80/ER-wizard-Setup0xFF/releases/download/v1.2/Wizard-Screenshot.jpg

=== ER-wizard-OLSRd_V1 ===
Installiert und konfiguriert den olsr (v1) daemon für IPv4 und IPv6. Seit 2017 wird für IPv6 allerdings nicht mehr der olsr(v1), sondern olsrv2 genutzt.

=== ER-wizard-OLSRd_V2 ===
Installiert und konfiguriert den olsrv2 daemon für IPv6.

Dokumentation: [[Medium:OLSRd_V2_Wizard.pdf|OLSRd_V2_Wizard.pdf]]

=== ER-wizard-AutoUpdate ===
Ruft täglich die aktuelle Version auf github ab und installiert gegebenenfalls das aktuelle Update automatisch. Unterstützte Wizards sind: OLSRd_V1, OLSRd_V2, AutoUpdate, WSLE, ebtables

=== ER-wizard-0xFF-WSLE Webstatus/LetsEncrypt ===
Installiert einen zweiten lighttpd für eine Status-Seite und managed das SSL-Zertifikat mittels Lets-Encrypt.

=== ER-wizard-ebtables ===
Ermöglicht es, die Regeln zum Forwarden von Traffic für einzelne Bridges zu aktivieren (generell wird im Bridge-Setup des OLSRd_V1 das Forwarding zwischen den OLSR-Interfaces unterbunden).

=== OpenVPN-to-Tunnelserver ===
Wizard zum Einrichten und Verwalten eines OpenVPN-Tunnels zum Funkfeuer-Tunnelserver.

=== ER-SSH-Prelogin-Banner ===
Fügt der Welcome-Message vom SSH-daemon nützliche Informationen hinzu, um schon vor der Passwort-Eingabe erkennen zu können, um welchen Router und Standort es sich handelt.

CLI> curl -sS https://gist.githubusercontent.com/pocki80/e4c2c16c5c1b8886c8320446768a862f/raw/0xffedgebanner.sh | sudo bash

Welcome to EdgeOS
| |
,---.,---|,---.,---.,---.,---.. .|--- ,---.,---.
|---`| || ||---`| | || || |---`|
`---``---``---|`---`` `---``---``--- `---``
`---` :: edgerouter-router ::
Location: 1234, Knoten 4567
Contact : meine@mailadresse.com
SerialNo: AA:BB:CC:DD:EE:FF

=== Ping-2-Web watchdog ===
Script mit Cronjob, dass alle 12h einen Ping ins Internet absetzt. Bei Misserfolg wird der Ping innerhalb 4-11min wiederholt: bei neuerlichem Fehler wird 1min später der Router rebootet, dabei werden auch die angesteckten PoE-Ports einem PowerCycle unterzogen.

CLI> curl -sS https://gist.githubusercontent.com/pocki80/525cb16b95991c7efed1c053d82422fe/raw/set_ping2web.sh | sudo bash

=== ER-load_ipv6_hostsfile ===
Lädt einmalig alle bekannten OLSR2-IPv6-Adressen aus http://193.238.158.8/0xFF-BMK-webstatus/hosts_originators.txt in die lokale File /etc/hosts:

CLI> curl -sS https://gist.githubusercontent.com/pocki80/fc6ede395e04dde62ce2199a8281261f/raw/load_ipv6_hostsfile.sh | sudo bash

=== ER-showOlsrLinks-script ===
Installiert /usr/local/bin/links script, welches aus einem (1) beliebigen olsrd_info-plugin oder dem Routing-Table die Link-Nachbarn raussucht, je nachdem welches Plugin verfügbar ist. Abgefragt wird olsrd (IPv4) und olsrd2 (IPv6), Anzeige der Default-Route und der Anzahl an Routeneinträgen für den jeweiligen Nachbarn. Überlebt ein FW-Update, da es via post-config.d nachinstalliert wird, wenn weg. Aufruf des commands einfach mittels "links".

CLI> curl -sS https://gist.githubusercontent.com/pocki80/eeea81945111ac14b937bd46b83412d2/raw/install_links_script.sh | sudo bash
CLI> links

olsrd links from txtinfo_plugin
Local IP Remote IP Hyst. LQ NLQ Cost #rts def?
78.41.112.40 193.238.159.153 0.00 1.000 1.000 1.000 2 -
78.41.112.40 78.41.112.141 0.00 1.000 1.000 1.000 486 default
78.41.112.40 78.41.112.3 0.00 1.000 0.510 1.961 5 -

olsrd2 links from nhdpinfo
Int Remote IPv6 Cnt-Routes
br0 2a02:61:0:ff:822a:a8ff:fe5f:8611 2 routes -
br0 2a02:61:0:ff:46d9:e7ff:fe50:2a84 13 routes -
br0 2a02:61:0:ff:feec:daff:fe4d:248f 89 routes default

=== ER-bootLoaderUpdateCheck-script ===
Prüft den aktuellen Router auf Modell, Firmware, Bootloader-Signatur und angeschlossene Geräte (PoE?). Empfiehlt gegebenenfalls das BootLoader-Update inkl. nötige Commands dafür.

Siehe https://community.ubnt.com/t5/EdgeMAX-Updates-Blog/EdgeMAX-EdgeRouter-X-X-SFP-bootloader-update/ba-p/1472216

CLI> curl -sS https://gist.githubusercontent.com/pocki80/ab7e239ff78433f4ce8dec371aa0b237/raw/boot-loader-update-check.sh | bash

HW model: EdgeRouter X SFP 6-Port
unpatched - 1 non-poe-port has a link - consider to update...

curl -O https://dl.ubnt.com/firmwares/edgemax/v1.8.0/update-boot.sh
sudo bash update-boot.sh

=== ER-powerCycleEthPort-script ===
Ab EdgeOS 1.10.5 und 2.0.0 behält der EdgeRouter-X-SFP den PoE-Zustand der Ports beim Reboot bei (beim ER-X wird PoE auf eth4 wie bisher kurz unterbrochen). Dadurch werden beim Router-Reboot die Antennen nicht mitrebootet. Um eine angesteckte Antenne mit einem einfachen CLI-Command neuzustarten, kann dieses einfache Script installiert und genutzt werden, es bleibt bei einem FW-Update auch erhalten:

CLI> curl -sS https://gist.githubusercontent.com/pocki80/6960085702072220ed48e1137dd5e080/raw/install_powercycle_script.sh | sudo bash
CLI> powercycle eth4

=== 0xFF-BMK-webstatus ===
Status-Seite und API für Monitoring - ist im WSLE-Wizard eingebunden

= Knoten =
; Betreiber bzw. Tech_C folgender Funkfeuer-Knoten
: wehr24
: luxi122home

Projekte/Datenschutz

2020-05-18T09:50:22Z

Pocki: /* Map 3 */

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt
* Gibt es ein '''Verarbeitungsverzeichnis'''?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name)

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname, Nutzername, Passwort
== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript Api lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: Api-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 "IPv6@OLSRv2" ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?
* Werden E-Mails dort gespeichert?
* Was und wie lange speichert ein evtl. Mailserver?
* Was ist mit dem Redeemer? Was wird dort außer die
* Ist das LDAP damit verbunden? Welche Dienste werden mittels LDAP verifiziert?

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki-Account ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

**Gleiche Fragen wie oben

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

Projekte/Datenschutz

2020-05-18T09:49:35Z

Pocki: /* Map 1 "BaseMap" */

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt
* Gibt es ein '''Verarbeitungsverzeichnis'''?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name)

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname, Nutzername, Passwort
== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript Api lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: Api-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP-Adressen aus der Topologie damit verschnitten, dann mittels Javascript Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==
Hier könnte man sagen, dass man aus den Auslastungsdaten von Links Benutzungsmuster ablesen kann.
Allerdings sind die wenigsten Knoten klar nur einer Person, oder auch nur einem Haushalt zuzuordnen.

Das ist wohl der Punkt für die spannendste Diskussion von allen, da hier die Entwicklung des Netzes direkt einem etwaigen Schutz gegenübersteht. Ohne diese Daten kann man ein Netz nicht planen, weiterbauen. Mit diesen Daten (wenn erweitert um einzelne Interfaces) kann ich den Datenverbrauch der einzelnen Personen versuchen zu rekonstruieren.

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?
* Werden E-Mails dort gespeichert?
* Was und wie lange speichert ein evtl. Mailserver?
* Was ist mit dem Redeemer? Was wird dort außer die
* Ist das LDAP damit verbunden? Welche Dienste werden mittels LDAP verifiziert?

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki-Account ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
Findet nicht allgemein statt. Es wurde nur ein Zugangssystem aktiviert, um den um sich greifenden Wiki-SPAM Herr zu werden, weil CAPTCHAs mühsamer, und nicht barrierefrei sind.
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
Hier wurde ein anstehender Neustart bei Softwareversion und Inhaltskoordination genutzt, um neu zu starten.

**Gleiche Fragen wie oben

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?

Projekte/Datenschutz

2020-05-18T09:35:20Z

Pocki: /* Map 3 */

== Grundsätzlich ==

* Werden Dienste auf Servern außerhalb des Funkfeuer-Servers gehostet? Wenn ja, wir brauchen '''Datenauftragsverarbeitungsverträge'''.
* Eine Liste der Personen, welche die unterschiedlichen Dienste/Funktionen betreuen, Admin-Rechte haben und Zugriff auf personenbezogene Daten (Name, E-Mailadresse, IP-Adresse, GPS-Daten etc.) – Zwar spricht § 6 DSG nur von „Mitarbeitern“, aber darunter fallen auch ehrenamtliche Mitarbeiter eines Vereins -> '''Verpflichtungserklärung zum Datengeheimnis''' wird benötigt
* Gibt es ein '''Verarbeitungsverzeichnis'''?

== Kategorien von Knoten-Inhabern ==
* Name, Adresse, Telefonnummer/Handy, E-Mail, Fax, IP-Adresse (von Geräten am Standort, nicht Endgerät)
* SSID (WLAN-Name)

== Mitglieder ==
* Name, Adresse, E-Mail, Telefonnummer, Nickname, Nutzername, Passwort
== Bildergalerie im Wiki ==
* https://gallery.funkfeuer.at/
* '''PROBLEM''': '''''Recht am eigenen Bild''''' (verfassungsrechtlich und europarechtlich geschützt & Datenschutz)
** 1. Warum kann ich nicht-eingeloggt Fotos von Personen sehen?
** 2. Gibt es Einwilligungserklärungen der Personen, die dort sichtbar sind?

== Map 1 "BaseMap" ==
* Fragen:
** Worauf basieren die Maps? Google/Open Street Maps? [Pocki: Google-Maps]
** Wie sind diese damit verbunden? [Pocki: Map-Javascript Api lädt Google-Map]
** Wer hat einen Google-Account der die Maps damit verbindet? [Pocki: Api-Key wurde dankenswerter Weise von wnagele zur Verfügung gestellt]
** Werden die Daten, die den Nodes zugeordnet werden auch an Google o.ä. weitergeleitet? [Pocki: Nein]
** Wie funktioniert die Map an sich? Wie werden die Verbindungen/Nodes darauf angezeigt? [Pocki: Node-Daten werden von Redeemer geladen, IP=Adressen aus der Topologie damit verschnitten, dann mittels Geomarker und Linien als Overlay beim Client auf die Map gelegt.]
* Wem der Node gehört
* GPS-Daten
* Geräte / IP-Adressen

* Node:
** Name: (Smokeping-Link)
** NodeId:
** Typ: normal
** Lat.:
** Lon.:
** User:
** Adresse:
** E-Mail:
** Technischer Kontakt:

== Map 2 "NodeMap" ==
* Map 2:
** Node Information
** Node ID:
** Hex Node ID:
** Node Prefix v642:
** Node Name:
** Coordinates:
** Node Status:
** Node Type:
** Node Technical Contact:
** Owner:
** Address:
** E-Mail:
** Amount of Links:
** local device partner device other node distance ETX
** Amount of Devices:
** Devices:

== Map 3 ==
https://ff.cybercomm.at/monitor/olsr.php -> Was ist das? [Pocki: Kann unter https://wiki.funkfeuer.at/wiki/Benutzer:Pocki#OLSRv2_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSRv2-Topologie verschnitten und (wo möglich) die Zugehörigkeit der IPv6-Adressen zu Knoten versucht. Das Ergebnis wird (ähnlich der Map1-BaseMap) mittels Javascript auf einer Google-Map dargestellt.]

== Smokeping? ==

== Bankdaten ==
* Evtl. Housing? Braucht was eigenes, da ja etwas anderes als der eigentliche Vereinszweck (<Housing ist Bestandteil und Hilfsbetrieb des Vereinszwecks).
* Nur Firmen oder auch Privatpersonen, die dort ihren Server haben?

== Forum ==
* Bild – warum auch sichtbar, wenn man dort nicht eingeloggt ist? – Bedarf einer Information
* Nickname, Name, Standort (Woher), Website, Mitglied seit wann, letzter Beitrag, Aufrufe, wann zuletzt eingeloggt
* Statistik: Wie oft vorbeigekommen, wie lange, welche Themen betrachtet/gelesen/erstellt/bester Beitrag, häufigste Antworten an, likes für/von/Abzeichen

== Riot ==
== Allgemein ==
Wir nutzen Riot für die Nah-Zeit-Kommunikation, wie in der Vor-Mobile-Ära IRC.
Hierbei betreiben wir keinen eigenen Server, sondern nutzen ein föderiertes System, ähnlich e-Mail. D.h. Jeder Teilnehmer wählt selber seinen "home-Server" aus, und verbindet sich mit diesem. Die Kommunikation kann auf Wunsch der Beteiligten E2E verschlüsselt werden, und ist dann nach dem derzeitigen Erkenntnisstand wirklich das, was man von E2E erwartet.

Hierbei werden von der Gemeinschaft keine Daten bereitgestellt, und auch der Verein tritt nicht förmlich auf. Wir nutzen den Service quasi wie ein Gasthaus, bei dem wir keine Visitenkarte hinterlassen, aber einen Tisch auf den Namen Funkfeuer bestellt haben (Anmerkung: So, genug Metaphern).

=== Fragen ===
* Chatraum
* Bilder, Nickname, welche Endgeräte
* ?
* Verifikation?
* Über welchen Server läuft Riot
* Wer hat Zugriff?

== Interne Datenbank ==
* Mitgliederdaten: Nur die vom Formular und den Nodes oder mehr?
* Werden E-Mails dort gespeichert?
* Was und wie lange speichert ein evtl. Mailserver?
* Was ist mit dem Redeemer? Was wird dort außer die
* Ist das LDAP damit verbunden? Welche Dienste werden mittels LDAP verifiziert?

== Mailinglisten ==
===Allgemein===
Wir betreiben einen eigenen Mailing-Listen-Server, auch um hier selber Sicherheit für die Archivierung zu sorgen.
Viele Geschehen der Vereinsgeschichte sind fast nur hier abgebildet.
Hierbei gibt es öffentliche Listen, wie discuss, wien (und ggf. andere geographische Listen), und geschlossene, die der Koordination in der Gemeinschaft dienen. Hierbei werden aber auch über diese Archive angelegt, zwecks der Transparenz der Arbeit in der Zukunft.

* Wer hat Zugriff auf E-Mails, Namen?
Die Archive sind für die jeweiligen Mitglieder einsehbar.
* Was wird dort alles bearbeitet?
Wir versuchen dort eine sachliche Diskussion für das jeweilige Listethema einzuhalten.

* Wieso ist die Wien-Liste öffentlich und die Vorstandsliste nicht? Ich halte das aus datenschutzrechtlicher Sicht für problematisch, da dort über Nodes und Leute diskutiert wird, was evtl. auch schädigend sein kann.
(Anmerkung: Wieso öffentlich, oder wieso nicht öffentlich?)

== Website ==
=== Allgemein ===
AFAIK wurde das Logging der Webseite beendet. Das ist insofern problematisch, als wenn wir eine mehr dynamischere Webseite bauen würden, wir Fehlermeldungen nicht mehr sinnvoll verarbeiten können. D.h. in der Folge eines Beschlusses für eine dynamische Webseite, müssen wir festlegen welche Felder wir wie lange speichern können wollen.
Vielleicht sollten wir auch bei öffentlichkeitswirksamen Maßnahmen eine sinnvolle on-premise Speicherung von pseudonymisierten Statistikdaten (wie piwik) überlegen, um unsere Maßnahmen bewerten zu können.

Eine Kontrolle des Status Quo steht aus.

=== Fragen ===
* IP-Adresse
* User Agent
* besuchte Webseite
* verwendeter Browsertyp/Browserversion
* verwendetes Betriebssystem
* die zuvor besuchte Seite
* Hostname des zugreifenden Rechners
* Uhrzeit der Serveranfrage
* Menge der gesendeten Daten

== Wiki-Account ==
* E-Mail, Username, Passwort
* Wer wann was eingetragen(geändert hat
* Wie findet die Verifikation statt?
* '''Problem''': Warum gibt es ein neues und ein „OldWiki“?
**Gleiche Fragen wie oben

== Cookies ==
* Nur beim Einloggen - > Hinweis beim Einloggen erforderlich, eigentlich bräuchte man ein Cookie-Banner, da aktive Einwilligung erforderlich
* Bei welchen Diensten finden sich Cookies?