FunkFeuer Wiki - Benutzerbeiträge [de]

Regionen/Wien/Verein/202105 GV

2021-05-13T11:20:49Z

Yellow: Dopplung entfernt

Notizen des Vorstands zur Generalversammlung des Vereins FunkFeuer Wien im Mai 2021

'''Achtung: Die Inhalte dieser Wikiseite werden laufend geändert und dienen als öffentliche Arbeitsunterlage des Vorstands.''' Die endgültigen Inhalte kommen zur Abhaltung der Generalversammlung auf die Protokollseite unter [[Regionen/Wien/Verein/202105_GV_Protokoll]].

[[ NA | Präsentationsfolien]] ([[NA | TeX-Source]])

Bitte diese Wikiseite nicht selbst bearbeiten! Vorschläge, Diskussionen, Kandidaturen bitte per Mail an mailto:wien@lists.funkfeuer.at

== Datum, Uhrzeit, Ort ==

* Donnerstag, 27.05.2021
* Eintreffen ab 20:30, Beginn um 21:00
* Ort: online unter https://treffen.funkfeuer.at/b/mat-wne-hkn

== Ankündigung ==

Die Ankündigung der GV erfolgt bis 13.05.2021 über die Mitglieder-Mailingliste.

== Stimmrechtsübertragungen ==

§9 Abs. 5: "Die Übertragung des Stimmrechts auf ein anderes Mitglied im Wege einer schriftlichen Bevollmächtigung ist zulässig."

Formvorschlag: Email bis spätestens 24.05.2021 18:00 an den Vorstand (mailto:vorstand@funkfeuer.at) à la "Ich, <code>$NAME</code>, bevollmächtige <code>$VERTRETER_IN</code>, mein Stimmrecht bei der FunkFeuer-Generalversammlung am <code>$DATUM</code> auszuüben."

'''Es muss kein "Formular" verwendet werden.''' Bitte rechtzeitig erledigen, damit wir bei etwaigen Nachfragen zur Person noch ein e-Mail schreiben können.

== Anträge ==

Anträge zur Tagesordnung müssen mindestens drei Tage vor Beginn der GV an mailto:vorstand@funkfeuer.at gemeldet werden. '''Wir empfehlen davor eine öffentliche Diskussion über die Mailingliste mailto:wien@lists.funkfeuer.at '''

Anträge bezüglich der Statuten bitte als Merge Request an das Statuten-Repository auf GitLab, eine Diskussion vorher ist empfohlen: https://gitlab.com/funkfeuer/Statuten-Wien

== Redebeiträge ==

Siehe Unterseite zum Selbereintragen: [[Regionen/Wien/Verein/202105_GV/Redebeiträge]]

== Kandidaturen ==
Kandidaturen für den Vorstand müssen mindestens drei Tage vor der Generalversammlung unter Nennung der angestrebten Funktion(en) an mailto:vorstand@funkfeuer.at unter Nennung der angestrebten Funktion(en) gemeldet werden. Wir empfehlen eine öffentliche Kandidatur über die Mailingliste mailto:wien@lists.funkfeuer.at

Im Folgenden listet der Vorstand alle 1. ihm bekannten und 2. explizit veröffentlichten oder ihm zur Veröffentlichung freigegebenen Kandidaturen.

'''Achtung: Die Inhalte dieses Abschnitts werden laufend geändert.''' Die finalen Kandidaturen werden nach Ablauf der Meldefrist zur Abhaltung der Generalversammlung auf die Protokollseite verschoben: [[Regionen/Wien/Verein/202105_GV_Protokoll]]

----

== Vorschlag für eine Tagesordnung ==

* Begrüßung
* Feststellen der Beschlussfähigkeit
* Redebeiträge
* Bericht des Vorstands
* Bericht der Rechnungsprüfer
* TBD: Abstimmung über Entlastung des Vorstands
* Wahl
* Anträge
* Allfälliges
* Verabschiedung

Regionen/Wien/Verein/202105 GV

2021-05-13T11:19:59Z

Yellow: Block Kandidaten dazu

Notizen des Vorstands zur Generalversammlung des Vereins FunkFeuer Wien im Mai 2021

'''Achtung: Die Inhalte dieser Wikiseite werden laufend geändert und dienen als öffentliche Arbeitsunterlage des Vorstands.''' Die endgültigen Inhalte kommen zur Abhaltung der Generalversammlung auf die Protokollseite unter [[Regionen/Wien/Verein/202105_GV_Protokoll]].

[[ NA | Präsentationsfolien]] ([[NA | TeX-Source]])

Bitte diese Wikiseite nicht selbst bearbeiten! Vorschläge, Diskussionen, Kandidaturen bitte per Mail an mailto:wien@lists.funkfeuer.at

== Datum, Uhrzeit, Ort ==

* Donnerstag, 27.05.2021
* Eintreffen ab 20:30, Beginn um 21:00
* Ort: online unter https://treffen.funkfeuer.at/b/mat-wne-hkn

== Ankündigung ==

Die Ankündigung der GV erfolgt bis 13.05.2021 über die Mitglieder-Mailingliste.

== Stimmrechtsübertragungen ==

§9 Abs. 5: "Die Übertragung des Stimmrechts auf ein anderes Mitglied im Wege einer schriftlichen Bevollmächtigung ist zulässig."

Formvorschlag: Email bis spätestens 24.05.2021 18:00 an den Vorstand (mailto:vorstand@funkfeuer.at) à la "Ich, <code>$NAME</code>, bevollmächtige <code>$VERTRETER_IN</code>, mein Stimmrecht bei der FunkFeuer-Generalversammlung am <code>$DATUM</code> auszuüben."

'''Es muss kein "Formular" verwendet werden.''' Bitte rechtzeitig erledigen, damit wir bei etwaigen Nachfragen zur Person noch ein e-Mail schreiben können.

== Anträge ==

Anträge zur Generalversammlung sind mindestens drei Tage vor dem Termin der Generalversammlung beim Vorstand schriftlich oder per E-Mail einzureichen.

Anträge zur Tagesordnung müssen mindestens drei Tage vor Beginn der GV an mailto:vorstand@funkfeuer.at gemeldet werden. '''Wir empfehlen davor eine öffentliche Diskussion über die Mailingliste mailto:wien@lists.funkfeuer.at '''

Anträge bezüglich der Statuten bitte als Merge Request an das Statuten-Repository auf GitLab, eine Diskussion vorher ist empfohlen: https://gitlab.com/funkfeuer/Statuten-Wien

== Redebeiträge ==

Siehe Unterseite zum Selbereintragen: [[Regionen/Wien/Verein/202105_GV/Redebeiträge]]

== Kandidaturen ==
Kandidaturen für den Vorstand müssen mindestens drei Tage vor der Generalversammlung unter Nennung der angestrebten Funktion(en) an mailto:vorstand@funkfeuer.at unter Nennung der angestrebten Funktion(en) gemeldet werden. Wir empfehlen eine öffentliche Kandidatur über die Mailingliste mailto:wien@lists.funkfeuer.at

Im Folgenden listet der Vorstand alle 1. ihm bekannten und 2. explizit veröffentlichten oder ihm zur Veröffentlichung freigegebenen Kandidaturen.

'''Achtung: Die Inhalte dieses Abschnitts werden laufend geändert.''' Die finalen Kandidaturen werden nach Ablauf der Meldefrist zur Abhaltung der Generalversammlung auf die Protokollseite verschoben: [[Regionen/Wien/Verein/202105_GV_Protokoll]]

----

== Vorschlag für eine Tagesordnung ==

* Begrüßung
* Feststellen der Beschlussfähigkeit
* Redebeiträge
* Bericht des Vorstands
* Bericht der Rechnungsprüfer
* TBD: Abstimmung über Entlastung des Vorstands
* Wahl
* Anträge
* Allfälliges
* Verabschiedung

Regionen/Wien/Verein/202105 GV

2021-05-13T11:02:14Z

Yellow: URL und Diskussionhinweis ergänzt

Notizen des Vorstands zur Generalversammlung des Vereins FunkFeuer Wien im Mai 2021

'''Achtung: Die Inhalte dieser Wikiseite werden laufend geändert und dienen als öffentliche Arbeitsunterlage des Vorstands.''' Die endgültigen Inhalte kommen zur Abhaltung der Generalversammlung auf die Protokollseite unter [[Regionen/Wien/Verein/202105_GV_Protokoll]].

[[ NA | Präsentationsfolien]] ([[NA | TeX-Source]])

Bitte diese Wikiseite nicht selbst bearbeiten! Vorschläge, Diskussionen, Kandidaturen bitte per Mail an mailto:wien@lists.funkfeuer.at

== Datum, Uhrzeit, Ort ==

* Donnerstag, 27.05.2021
* Eintreffen ab 20:30, Beginn um 21:00
* Ort: online unter https://treffen.funkfeuer.at/b/mat-wne-hkn

== Ankündigung ==

Die Ankündigung der GV erfolgt bis 13.05.2021 über die Mitglieder-Mailingliste.

== Stimmrechtsübertragungen ==

§9 Abs. 5: "Die Übertragung des Stimmrechts auf ein anderes Mitglied im Wege einer schriftlichen Bevollmächtigung ist zulässig."

Formvorschlag: Email bis spätestens 24.05.2021 18:00 an den Vorstand (mailto:vorstand@funkfeuer.at) à la "Ich, <code>$NAME</code>, bevollmächtige <code>$VERTRETER_IN</code>, mein Stimmrecht bei der FunkFeuer-Generalversammlung am <code>$DATUM</code> auszuüben."

'''Es muss kein "Formular" verwendet werden.''' Bitte rechtzeitig erledigen, damit wir bei etwaigen Nachfragen zur Person noch ein e-Mail schreiben können.

== Anträge ==

Anträge zur Tagesordnung müssen bis spätestens '''TBD''' an mailto:vorstand@funkfeuer.at gemeldet werden. '''Wir empfehlen davor eine öffentliche Diskussion über die Mailingliste mailto:wien@lists.funkfeuer.at '''

Anträge bezüglich der Statuten bitte als Merge Request an das Statuten-Repository auf GitLab, eine Diskussion vorher ist empfohlen: https://gitlab.com/funkfeuer/Statuten-Wien

== Redebeiträge ==

Siehe Unterseite zum Selbereintragen: [[Regionen/Wien/Verein/202105_GV/Redebeiträge]]

----

== Vorschlag für eine Tagesordnung ==

* Begrüßung
* Feststellen der Beschlussfähigkeit
* Redebeiträge
* Bericht des Vorstands
* Bericht der Rechnungsprüfer
* TBD: Abstimmung über Entlastung des Vorstands
* Wahl
* Anträge
* Allfälliges
* Verabschiedung

Diskussion:Services/Organisation/Gallery

2021-02-01T09:21:57Z

Yellow:

Ad keine PHP für neue Projekte - warum eigentlich nicht? Ist PHP unsicher oder sind die Anwendungen nur schlecht programmiert?

Wir stehen derzeit bei PHP8 / PHP7 als unterstützte Sprachversionen.
Viele Projekte sind in veralteten Versionen geschrieben, die vor der Umstellung auf Objekte und Typisierung erstellt wurden. Dadurch muss bei neuen Projekten (wie in allen Sprachen) darauf geachtet werden, dass diese mit einem aktuellen Interpreter auch funktionieren, und auch gewartet werden.

* [https://entwickler.de/online/php-sicherheit-von-php-4-x-bis-php-5-5-2-136924.html php-sicherheit-von-php-4-x-bis-php-5-5]
* [https://www.php.de/forum/php-de-intern/off-topic-diskussionen/1502927-php-soll-angeblich-per-definition-unsicher-sein-meinung-eines-einzelnen php-soll-angeblich-per-definition-unsicher-sein]

Ad selfregistration:

Bisher handhaben wir das doch so, dass neue User zunächst beim Montagstreffen im Metalab einen Account erhalten - warum nicht dann mit diesen Credentials arbeiten? Eventuell könnte man den Anmeldevorgang öffnen, indem man ihn in eine Vorregistrierung und eine Bestätigung trennt - verbunden mit unterschiedlichen Berechtigungen.

SSO vs. anonym, vs. Fotos aus anderer Quelle hier darstellen, hier gibt es vielfältige Lösungen, die getrennt von den technischen Lösungen betrachtet werden sollten.

Diskussion:Projekte/Housing/Umzug/Lüftung

2020-07-12T09:44:49Z

Yellow:

Diese Seite soll der Diskussion bzgl. Lüftung dienen, da es im Chat schwierig ist für alle im Nachhinein mit zu lesen.

=== Problem ===
* Temperatur laufend bei über 38°C - siehe [[Services/Organisation/Housing/Temperatur]]

=== Ideen für eine Lösung ===
* Radialventilator auf höherer als halber Leistung?
** Gabs da nicht Probleme mit der Geräuschentwicklung, wenn die Leistung gesteigert wird?
** Überdruck im Schacht erzeugt Reibungsverluste, und Abgang in die Sammlung
* Lässt sich der Luftstrom irgendwie teilen, damit die Geräuschentwicklung erträglich bleibt und trotzdem die Umwälzung stattfinden kann?
* Ansatz mit Split-Klimagerät
* Abluftrohr in die Keramiksammlung
* Druckzuluft von der Öffnung Traforaum

Events/Test

2020-07-04T22:15:31Z

Yellow: Die Seite wurde neu angelegt: „{{Event |name=Test |mainevent=Test |date=1.1.1970 }}“

Regionen/Wien/Verein/202006 GV Protokoll

2020-06-17T15:37:05Z

Yellow: Seite initial erzeugt

Regionen/Wien/Verein/202005 GV Protokoll

2020-06-12T20:31:34Z

Yellow: Version mit Wikitables

Liebe Anwesende der ordentlichen Generalversammlung 2020,
Liebe funkfeuerinteressierte Gemeinschaft!

Vielen Dank für Eure interessiere Teilnahme an unserer
ersten Generalversammlung ausschließlich im virtuellen Raum!

Ich darf mich erstmalig als Obmann an Euch wenden, und gleich
auf die erste außerordentliche GV seit längerem hinweisen (s.u.).
Als weitere Neuerung habe ich die Stimmen, die aus Stimmübertragungen resultieren, getrennt notiert. Dies soll in Hinblick auf etwaige Anträge für die Limitation von Stimmübertragungen als Hinweis auf die vorhergehenden Wahlergebnisse dienen.

Hier nun die Aufzeichnungen zum Ablauf der
ordentlichen Generalversammlung 2020 am Dienstag, 19.05.2020

;Begrüßung
: Wir haben nach einigen Versuchen mit der Technik kurz nach dem geplanten Beginn eine mit den Vorjahren vergleichbare Anzahl an Mitgliedern und Interessierten versammelt. Nun können wir mit der Begrüßung (und einigen Zwischenrufen) starten.

;Feststellen der Beschlussfähigkeit
: Die Beschlussfähigkeit durch eine ordentlich zusammengekommene Versammlung wurde durch den Obmann festgestellt.
;Bericht des Vorstands
: Der Vorstand berichtet aus der Arbeit der letzten Jahres, weitere Details in den Vortragsfolien.
;Bericht der Rechnungsprüfer
;Abstimmung über Entlastung des Vorstands
: Die Entlastung des Vorstands wurde mit 28+8 JA-Stimmen gegen 2+1 NEIN-Stimmen bei sechs Enthaltungen angenommen.
;Wahl
: Die Wahlen zum Vorstand und den Rechnungsprüfern wurden wie in den Vorjahren das Wahlverfahren durch Zustimmung [1] angewendet.
: Daher sind in der folgenden Tabelle für jeden Kandidaten die JA-Stimmen entscheidend, und die NEIN-Stimmen als Referenz angeführt.
=== Wahl des Vorstands ===
{| class="wikitable" style="text-align: center;"
|-
! Position
! Name
! JA
! NEIN
|-
|rowspan="3"| Obmann
| Gschwendt, Markus
| 10+2
| 25+8
|-
| Rafetseder, Albert
| 24+3
| 13+6
|-
| '''Šubik, Matthias'''
| 22+9
| 16
|-
|rowspan="5"| Obmann, Stv.
| Brajković, Christofer
| 14+7
| 22+2
|-
| Gschwendt, Markus
| 13+3
| 23+6
|-
| Kittenberger, Markus
| 16+8
| 20+1
|-
| '''Lösch, Christoph'''
| 25+8
| 11+1
|-
| Rafetseder, Albert
| 20+2
| 16+7
|-
|rowspan="5"| Schriftführer
| Brajković, Christofer
| 7+1
| 29+8
|-
| Gschwendt, Markus
| 12+2
| 24+7
|-
| '''Maierhofer, Daniel'''
| 29+7
| 6+2
|-
| Rafetseder, Albert
| 19+4
| 16+6
|-
| Sengeis, Manfred
| 18+8
| 17+2
|-
|rowspan="4"| Schriftführer Stv.
| Brajković, Christofer
| 19+6
| 16+4
|-
| Gschwendt, Markus
| 14+2
| 21+8
|-
| Rafetseder, Albert
| 18+4
| 17+6
|-
| '''Sengeis, Manfred'''
| 26+7
| 9+3
|-
|rowspan="4"| Kassier
| Brajković, Christofer
| 18+6
| 17+4
|-
| Gschwendt, Markus
| 14+2
| 21+8
|-
| Marvillo, Adnan
| 15+3
| 20+7
|-
| '''Rafetseder, Albert'''
| 24+7
| 11+2
|-
|rowspan="4"| Kassier Stv.
| '''Brajković, Christofer'''
| 19+7
| 17+3
|-
| Gschwendt, Markus
| 14+2
| 22+8
|-
| Ott, Pascal
| 19+3
| 17+7
|-
|}

===Wahl der Rechnungsprüfer:===
{| class="wikitable" style="text-align: center;"
| '''Graf, Sebastian'''
| 23+7
| 13+3
|-
| Gschwendt, Markus
| 15+3
| 21+7
|-
| Kriegisch, Adi
| 25+4
| 11+6
|-
| '''Ott, Pascal'''
| 28+10
| 8
|}

;Anträge
: Wegen der fortgeschrittenen Uhrzeit, und der deutlich reduzierten Teilnehmerzahl nach der kurzen Pause, wird vom Vorsitz eine Vertagung auf eine außerordentliche GV binnen eines Monats zur Abstimmung gebracht.

{| class="wikitable"
|JA 17+11
|NEIN 5+1
|ENTHALTUNG 3
|}
;Verabschiedung

Ich hoffe Euch so zahlreich wie möglich bei der außerordentlichen Generalversammlung am 17.6. (siehe getrenne Einladung) wieder als Teilnehmer zu sehen.

Albert, Christofer, Christoph, Daniel, Manfred und Matthias

[1] https://de.wikipedia.org/wiki/Wahl_durch_Zustimmung

Diskussion:Regionen/Wien/Verein/202005 GV Protokoll

2020-06-12T20:22:58Z

Yellow: Der Seiteninhalt wurde durch einen anderen Text ersetzt: „Entwurf von hier entfernt. Protokoll ist nun auf der Seite“

Entwurf von hier entfernt. Protokoll ist nun auf der Seite

Regionen/Wien/Verein/202005 GV Protokoll

2020-06-12T20:22:01Z

Yellow: Erste Version aus der Mail kopiert, Tabellenübertragung fehlt noch

Liebe Anwesende der ordentlichen Generalversammlung 2020,
Liebe funkfeuerinteressierte Gemeinschaft!

Vielen Dank für Eure interessiere Teilnahme an unserer
ersten Generalversammlung ausschließlich im virtuellen Raum!

Ich darf mich erstmalig als Obmann an Euch wenden, und gleich
auf die erste außerordentliche GV seit längerem hinweisen (s.u.).
Als weitere Neuerung habe ich die Stimmen, die aus Stimmübertragungen resultieren, getrennt notiert. Dies soll in Hinblick auf etwaige Anträge für die Limitation von Stimmübertragungen als Hinweis auf die vorhergehenden Wahlergebnisse dienen.

Hier nun die Aufzeichnungen zum Ablauf der
ordentlichen Generalversammlung 2020 am Dienstag, 19.05.2020

• Begrüßung
Wir haben nach einigen Versuchen mit der Technik kurz nach dem geplanten Beginn eine mit den Vorjahren vergleichbare Anzahl an Mitgliedern und Interessierten versammelt. Nun können wir mit der Begrüßung (und einigen Zwischenrufen) starten.

• Feststellen der Beschlussfähigkeit
Die Beschlussfähigkeit durch eine ordentlich zusammengekommene Versammlung wurde durch den Obmann festgestellt.
• Bericht des Vorstands
Der Vorstand berichtet aus der Arbeit der letzten Jahres, weitere Details in den Vortragsfolien.
• Bericht der Rechnungsprüfer
• Abstimmung über Entlastung des Vorstands
Die Entlastung des Vorstands wurde mit 28+8 JA-Stimmen gegen 2+1 NEIN-Stimmen bei sechs Enthaltungen angenommen.
• Wahl
Die Wahlen zum Vorstand und den Rechnungsprüfern wurden wie in den Vorjahren das Wahlverfahren durch Zustimmung [1] angewendet.
Daher sind in der folgenden Tabelle für jeden Kandidaten die JA-Stimmen entscheidend, und die NEIN-Stimmen als Referenz angeführt.

Obmann:
Gschwendt, Markus; JA 10+2 NEIN 25+8
Rafetseder, Albert; JA 24+3 NEIN 13+6
-> Šubik, Matthias; JA 22+9 NEIN 16

Obmann, Stv.:
Brajković, Christofer; JA 14+7 NEIN 22+2
Gschwendt, Markus; JA 13+3 NEIN 23+6
Kittenberger, Markus; JA 16+8 NEIN 20+1
-> Lösch, Christoph; JA 25+8 NEIN 11+1
Rafetseder, Albert; JA 20+2 NEIN 16+7

Schriftführer:
Brajković, Christofer; JA 7+1 NEIN 29+8
Gschwendt, Markus; JA 12+2 NEIN 24+7
-> Maierhofer, Daniel; JA 29+7 NEIN 6+2
Rafetseder, Albert; JA 19+4 NEIN 16+6
Sengeis, Manfred; JA 18+8 NEIN 17+2

Schriftführer Stv.
Brajković, Christofer; JA 19+6 NEIN 16+4
Gschwendt, Markus; JA 14+2 NEIN 21+8
Rafetseder, Albert; JA 18+4 NEIN 17+6
-> Sengeis, Manfred; JA 26+7 NEIN 9+3

Kassier
Brajković, Christofer; JA 18+6 NEIN 17+4
Gschwendt, Markus; JA 14+2 NEIN 21+8
Marvillo, Adnan; JA 15+3 NEIN 20+7
-> Rafetseder, Albert; JA 24+7 NEIN 11+2

Kassier Stv.
-> Brajković, Christofer; JA 19+7 NEIN 17+3
Gschwendt, Markus; JA 14+2 NEIN 22+8
Ott, Pascal; JA 19+3 NEIN 17+7

Rechnungsprüfer
-> Graf, Sebastian; JA 23+7 NEIN 13+3
Gschwendt, Markus; JA 15+3 NEIN 21+7
Kriegisch, Adi; JA 25+4 NEIN 11+6
-> Ott, Pascal; JA 28+10 NEIN 8

• Anträge
Wegen der fortgeschrittenen Uhrzeit, und der deutlich reduzierten Teilnehmerzahl nach der kurzen Pause, wird vom Vorsitz eine Vertagung auf eine außerordentliche GV binnen eines Monats zur Abstimmung gebracht.

JA 17+11 NEIN 5+1 ENTHALTUNG 3
• Verabschiedung

Ich hoffe Euch so zahlreich wie möglich bei der außerordentlichen Generalversammlung am 17.6. (siehe getrenne Einladung) wieder als Teilnehmer zu sehen.

Albert, Christofer, Christoph, Daniel, Manfred und Matthias

[1] https://de.wikipedia.org/wiki/Wahl_durch_Zustimmung

Hardware/MiktroTik LHG5

2020-06-03T07:26:03Z

Yellow: Yellow verschob die Seite Hardware/MiktroTik LHG5 nach Hardware/MikroTik LHG5: Tippfehler, verhindert Auffindung, daher verschoben

#WEITERLEITUNG [[Hardware/MikroTik LHG5]]

Hardware/MikroTik LHG5

2020-06-03T07:26:02Z

Yellow: Yellow verschob die Seite Hardware/MiktroTik LHG5 nach Hardware/MikroTik LHG5: Tippfehler, verhindert Auffindung, daher verschoben

{{Router
|name=RouterBoard LHG-5nD
|manufacturer=MikroTik
|Picture=MikroTikLHG5.jpg
|deprecated=Nein
|v642=Ja
|outdoor=Ja
|cpu=Atheros AR9344, 600 MHz
|ram=64 MB
|flash=16 MB
|poe=passiv
|ethernetports=1
|switch=Nein
|wifi=Ja
|wifiband=5 GHz
|wifistandard=802.11an
|mimostreams=2x2
|firmware=[http://downloads.openwrt.org/snapshots/targets/ar71xx/mikrotik/openwrt-ar71xx-mikrotik-rb-nor-flash-16M-initramfs-kernel.bin OpenWRT Snapshot]
|flashmethod=Sysupgrade nach TFTP-Boot
|antenna=Ja
|antennatype=Gitter
|antennapol=H/V
|antennagain=24,5 dBi
|datasheet=https://routerboard.com/RBLHG-5nD
|streetprize=55
}}

== Flashen von LEDE ==

# Booten eines [https://downloads.lede-project.org/snapshots/targets/ar71xx/mikrotik/lede-ar71xx-mikrotik-rb-nor-flash-16M-initramfs-kernel.bin LEDE-initramfs] via TFTP (siehe unten)
# Log-in mit Standard-Credentials
# Flashen des gewuenschten Sysupgrade-Images (*nicht* factory, da der MikroTik-Bootloader erhalten bleibt)

== TFTP-Boot ==

Zum initialen Flashen und Situationen, in denen man nicht mehr über das Netzwerk zugreifen kann:

# Abstecken
# Reset-Button drücken und halten, befindet sich neben dem Ethernet-Port
# Anstecken
# Grüne LED beobachten: Zuerst blinkt sie, dann leuchtet sie durchgehend, dann geht sie aus. Hier den Knopf loslassen.
# Die LHG sucht nun nach einem DHCP-Lease und einem TFTP-Server (initramfs, kein sysupgrade oder dergleichen!). Klappt alles, bootet sie selbiges.
# Wird kein Image geflasht, startet beim nächsten Boot wieder das installierte System.

Script, um mit dnsmasq einen simplen DHCP+TFTP Server temporär auf einem Interface zu starten (Firmware Image muss im Ordner "tftproot" liegen. Erster Scriptparameter ist das Interface, zweiter ist der Name der Firmware Image Datei):
<nowiki>#!/bin/bash

INTERFACE="$1"
BOOTFILE="$2"

ip address add 10.42.0.1/24 dev "$INTERFACE"
dnsmasq --interface "$INTERFACE" --enable-tftp --tftp-root="$(pwd)/tftproot" --dhcp-boot="$BOOTFILE" --dhcp-authoritative --listen-address 10.42.0.1 --dhcp-range 10.42.0.10,10.42.0.20 --bootp-dynamic --port 0 --no-daemon --log-dhcp --dhcp-leasefile="/tmp/netboot.leases"
ip address delete 10.42.0.1/24 dev "$INTERFACE"</nowiki>

== Open Issues 0xFF-Integration ==

Nachfolgend die bisher identifizierte Schwachstellen, die einer einfachen Nutzung für 0xFF entgegen stehen:

* Create default switch config
* Improve LuCI switch config by amending board.json
* Package switch config extensions

Hardware/MikroTik LHG5

2020-06-03T07:23:42Z

Yellow: typo fix

Diskussion:Regionen/Wien/Verein/202005 GV Protokoll

2020-06-01T12:52:21Z

Yellow: Wahlergebnis der Rechnungsprüfer elektronisiert

Der Text des Protokolls ist noch in der Feedbackrunde,
aber die Arbeit der großen Tabelle ist schonmal erledigt.

=== Wahl des Vorstands ===
{| class="wikitable" style="text-align: center;"
|-
! Position
! Name
! JA
! NEIN
|-
|rowspan="3"| Obmann
| Gschwendt, Markus
| 10+2
| 25+8
|-
| Rafetseder, Albert
| 24+3
| 13+6
|-
| '''Šubik, Matthias'''
| 22+9
| 16
|-
|rowspan="5"| Obmann, Stv.
| Brajković, Christofer
| 14+7
| 22+2
|-
| Gschwendt, Markus
| 13+3
| 23+6
|-
| Kittenberger, Markus
| 16+8
| 20+1
|-
| '''Lösch, Christoph'''
| 25+8
| 11+1
|-
| Rafetseder, Albert
| 20+2
| 16+7
|-
|rowspan="5"| Schriftführer
| Brajković, Christofer
| 7+1
| 29+8
|-
| Gschwendt, Markus
| 12+2
| 24+7
|-
| '''Maierhofer, Daniel'''
| 29+7
| 6+2
|-
| Rafetseder, Albert
| 19+4
| 16+6
|-
| Sengeis, Manfred
| 18+8
| 17+2
|-
|rowspan="4"| Schriftführer Stv.
| Brajković, Christofer
| 19+6
| 16+4
|-
| Gschwendt, Markus
| 14+2
| 21+8
|-
| Rafetseder, Albert
| 18+4
| 17+6
|-
| '''Sengeis, Manfred'''
| 26+7
| 9+3
|-
|rowspan="4"| Kassier
| Brajković, Christofer
| 18+6
| 17+4
|-
| Gschwendt, Markus
| 14+2
| 21+8
|-
| Marvillo, Adnan
| 15+3
| 20+7
|-
| '''Rafetseder, Albert'''
| 24+7
| 11+2
|-
|rowspan="4"| Kassier Stv.
| '''Brajković, Christofer'''
| 19+7
| 17+3
|-
| Gschwendt, Markus
| 14+2
| 22+8
|-
| Ott, Pascal
| 19+3
| 17+7
|-
|}

===Wahl der Rechnungsprüfer:===
{| class="wikitable" style="text-align: center;"
| '''Graf, Sebastian'''
| 23+7
| 13+3
|-
| Gschwendt, Markus
| 15+3
| 21+7
|-
| Kriegisch, Adi
| 25+4
| 11+6
|-
| '''Ott, Pascal'''
| 28+10
| 8
|}

Diskussion:Regionen/Wien/Verein/202005 GV Protokoll

2020-06-01T12:34:03Z

Yellow: Tabelle mit Wahlergebnissen eingefügt

Der Text des Protokolls ist noch in der Feedbackrunde,
aber die Arbeit der großen Tabelle ist schonmal erledigt.

{| class="wikitable" style="text-align: center;"
|-
! Position
! Name
! JA
! NEIN
|-
|rowspan="3"| Obmann
| Gschwendt, Markus
| 10+2
| 25+8
|-
| Rafetseder, Albert
| 24+3
| 13+6
|-
| '''Šubik, Matthias'''
| 22+9
| 16
|-
|rowspan="5"| Obmann, Stv.
| Brajković, Christofer
| 14+7
| 22+2
|-
| Gschwendt, Markus
| 13+3
| 23+6
|-
| Kittenberger, Markus
| 16+8
| 20+1
|-
| '''Lösch, Christoph'''
| 25+8
| 11+1
|-
| Rafetseder, Albert
| 20+2
| 16+7
|-
|rowspan="5"| Schriftführer
| Brajković, Christofer
| 7+1
| 29+8
|-
| Gschwendt, Markus
| 12+2
| 24+7
|-
| '''Maierhofer, Daniel'''
| 29+7
| 6+2
|-
| Rafetseder, Albert
| 19+4
| 16+6
|-
| Sengeis, Manfred
| 18+8
| 17+2
|-
|rowspan="4"| Schriftführer Stv.
| Brajković, Christofer
| 19+6
| 16+4
|-
| Gschwendt, Markus
| 14+2
| 21+8
|-
| Rafetseder, Albert
| 18+4
| 17+6
|-
| '''Sengeis, Manfred'''
| 26+7
| 9+3
|-
|rowspan="4"| Kassier
| Brajković, Christofer
| 18+6
| 17+4
|-
| Gschwendt, Markus
| 14+2
| 21+8
|-
| Marvillo, Adnan
| 15+3
| 20+7
|-
| '''Rafetseder, Albert'''
| 24+7
| 11+2
|-
|rowspan="4"| Kassier Stv.
| '''Brajković, Christofer'''
| 19+7
| 17+3
|-
| Gschwendt, Markus
| 14+2
| 22+8
|-
| Ott, Pascal
| 19+3
| 17+7
|-
|}

Regionen/Wien/Verein/202005 GV Protokoll

2020-06-01T11:23:56Z

Yellow: Initiale Version Link auf Diskussion angelegt

Das Protokoll ist als Entwurf in [[Diskussion:Regionen/Wien/Verein/202005_GV_Protokoll]]

Regionen/Wien/Verein/202006 GV

2020-06-01T10:36:42Z

Yellow: doppelter Hinweis entfernt

Notizen des Vereinsvorstands zur außerordentlichen Generalversammlung des Vereins FunkFeuer Wien im Juni 2020

'''Achtung: Die Inhalte dieser Wikiseite werden laufend geändert und dienen als öffentliche Arbeitsunterlage des Vorstands.''' Die endgültigen Inhalte kommen zur Abhaltung der Generalversammlung auf die Protokollseite unter [[Regionen/Wien/Verein/202006_GV_Protokoll]].

Bitte diese Wikiseite nicht selbst bearbeiten! Vorschläge, Diskussionen, Kandidaturen bitte per Mail an mailto:wien@lists.funkfeuer.at

== Datum, Uhrzeit, Ort ==

* Mittwoch, 17.06.2020
* Eintreffen ab 18:00, Beginn um 18:30
* Ort: online unter https://treffen.funkfeuer.at/b/mat-dcv-4ft

== Ankündigung ==

Die Ankündigung der ao. GV erfolgt am 02.05.2020 über die Mitglieder-Mailingliste sowie die Wien- und Discuss-Listen.

== Stimmrechtsübertragungen ==

§9 Abs. 5: "Die Übertragung des Stimmrechts auf ein anderes Mitglied im Wege einer schriftlichen Bevollmächtigung ist zulässig."

Formvorschlag: Email bis spätestens 16.06.2020 18:00 an den Vorstand (mailto:vorstand@funkfeuer.at) à la "Ich, <code>$NAME</code>, bevollmächtige <code>$VERTRETER_IN</code>, mein Stimmrecht bei der FunkFeuer-Generalversammlung am <code>$DATUM</code> auszuüben."

'''Es muss kein "Formular" verwendet werden.''' Bitte rechtzeitig erledigen, damit wir bei etwaigen Nachfragen zur Person noch ein e-Mail schreiben können.

== Anträge ==

Anträge zur Tagesordnung müssen bis spätestens 14.06.2020 18:00 an mailto:vorstand@funkfeuer.at gemeldet werden. '''Wir empfehlen davor eine öffentliche Diskussion über die Mailingliste mailto:wien@lists.funkfeuer.at '''

Anträge bezüglich der Statuten bitte als Merge Request an das Statuten-Repository auf GitLab: https://gitlab.com/funkfeuer/Statuten-Wien

----

== Vorschlag für eine Tagesordnung ==

* Begrüßung
* Feststellen der Beschlussfähigkeit
* Kurzbericht des Vorstands zur neuen Periode
* Anträge
* Allfälliges
* Verabschiedung

Regionen/Wien/Verein/202006 GV

2020-06-01T10:33:02Z

Yellow: Hinweis auf die neue URL entfernt

Notizen des Vereinsvorstands zur außerordentlichen Generalversammlung des Vereins FunkFeuer Wien im Juni 2020

'''Achtung: Die Inhalte dieser Wikiseite werden laufend geändert und dienen als öffentliche Arbeitsunterlage des Vorstands.''' Die endgültigen Inhalte kommen zur Abhaltung der Generalversammlung auf die Protokollseite unter [[Regionen/Wien/Verein/202006_GV_Protokoll]].

Bitte diese Wikiseite nicht selbst bearbeiten! Vorschläge, Diskussionen, Kandidaturen bitte per Mail an mailto:wien@lists.funkfeuer.at

== Datum, Uhrzeit, Ort ==

* Mittwoch, 17.06.2020
* Eintreffen ab 18:00, Beginn um 18:30
* Ort: online unter https://treffen.funkfeuer.at/b/mat-dcv-4ft

== Ankündigung ==

Die Ankündigung der ao. GV erfolgt am 02.05.2020 über die Mitglieder-Mailingliste sowie die Wien- und Discuss-Listen.

== Stimmrechtsübertragungen ==

§9 Abs. 5: "Die Übertragung des Stimmrechts auf ein anderes Mitglied im Wege einer schriftlichen Bevollmächtigung ist zulässig."

Formvorschlag: Email bis spätestens 16.06.2020 18:00 an den Vorstand (mailto:vorstand@funkfeuer.at) à la "Ich, <code>$NAME</code>, bevollmächtige <code>$VERTRETER_IN</code>, mein Stimmrecht bei der FunkFeuer-Generalversammlung am <code>$DATUM</code> auszuüben."

'''Es muss kein "Formular" verwendet werden.''' Bitte rechtzeitig erledigen, damit wir bei etwaigen Nachfragen zur Person noch ein e-Mail schreiben können.

== Anträge ==

Anträge zur Tagesordnung müssen bis spätestens 14.06.2020 18:00 an mailto:vorstand@funkfeuer.at gemeldet werden. '''Wir empfehlen davor eine öffentliche Diskussion über die Mailingliste mailto:wien@lists.funkfeuer.at '''

Anträge bezüglich der Statuten bitte als Merge Request an das Statuten-Repository auf GitLab: https://gitlab.com/funkfeuer/Statuten-Wien

'''Achtung: Die Inhalte dieses Abschnitts werden laufend geändert.''' Die finalen Kandidaturen werden nach Ablauf der Meldefrist zur Abhaltung der Generalversammlung auf die Protokollseite verschoben: [[Regionen/Wien/Verein/202005_GV_Protokoll]]
----

== Vorschlag für eine Tagesordnung ==

* Begrüßung
* Feststellen der Beschlussfähigkeit
* Kurzbericht des Vorstands zur neuen Periode
* Anträge
* Allfälliges
* Verabschiedung

Regionen/Wien/Verein/202006 GV

2020-06-01T10:32:37Z

Yellow: Initiale Version als Entwurf entwickelt

Notizen des Vereinsvorstands zur außerordentlichen Generalversammlung des Vereins FunkFeuer Wien im Juni 2020

'''Achtung: Die Inhalte dieser Wikiseite werden laufend geändert und dienen als öffentliche Arbeitsunterlage des Vorstands.''' Die endgültigen Inhalte kommen zur Abhaltung der Generalversammlung auf die Protokollseite unter [[Regionen/Wien/Verein/202006_GV_Protokoll]].

Bitte diese Wikiseite nicht selbst bearbeiten! Vorschläge, Diskussionen, Kandidaturen bitte per Mail an mailto:wien@lists.funkfeuer.at

== Datum, Uhrzeit, Ort ==

* Mittwoch, 17.06.2020
* Eintreffen ab 18:00, Beginn um 18:30
* Ort: online unter https://treffen.funkfeuer.at/b/mat-dcv-4ft -- '''ACHTUNG, NEUE URL!'''

== Ankündigung ==

Die Ankündigung der ao. GV erfolgt am 02.05.2020 über die Mitglieder-Mailingliste sowie die Wien- und Discuss-Listen.

== Stimmrechtsübertragungen ==

§9 Abs. 5: "Die Übertragung des Stimmrechts auf ein anderes Mitglied im Wege einer schriftlichen Bevollmächtigung ist zulässig."

Formvorschlag: Email bis spätestens 16.06.2020 18:00 an den Vorstand (mailto:vorstand@funkfeuer.at) à la "Ich, <code>$NAME</code>, bevollmächtige <code>$VERTRETER_IN</code>, mein Stimmrecht bei der FunkFeuer-Generalversammlung am <code>$DATUM</code> auszuüben."

'''Es muss kein "Formular" verwendet werden.''' Bitte rechtzeitig erledigen, damit wir bei etwaigen Nachfragen zur Person noch ein e-Mail schreiben können.

== Anträge ==

Anträge zur Tagesordnung müssen bis spätestens 14.06.2020 18:00 an mailto:vorstand@funkfeuer.at gemeldet werden. '''Wir empfehlen davor eine öffentliche Diskussion über die Mailingliste mailto:wien@lists.funkfeuer.at '''

Anträge bezüglich der Statuten bitte als Merge Request an das Statuten-Repository auf GitLab: https://gitlab.com/funkfeuer/Statuten-Wien

'''Achtung: Die Inhalte dieses Abschnitts werden laufend geändert.''' Die finalen Kandidaturen werden nach Ablauf der Meldefrist zur Abhaltung der Generalversammlung auf die Protokollseite verschoben: [[Regionen/Wien/Verein/202005_GV_Protokoll]]
----

== Vorschlag für eine Tagesordnung ==

* Begrüßung
* Feststellen der Beschlussfähigkeit
* Kurzbericht des Vorstands zur neuen Periode
* Anträge
* Allfälliges
* Verabschiedung

IP-Adresskonzept

2020-05-28T09:23:22Z

Yellow: /* Ausgangssituation und Rahmenbedingungen */ early registration erklärt.

== Überblick der FunkFeuer-IPv6-Adressbereiche ==
Präfix-
länge 16| 32| 48| 64| 80| 96| 112| 128|
FunkFeuer IPv6 (0<=x<=7) 29 2a02:006x:....:....:....:....:....:....
|
+- Early Registration 40 2a02:0060:00..:....:....:....:....:....
|
+- User Blocks 32 2a02:0061:....:....:....:....:....:....
|
+- Infrastruktur 48 2a02:0061:0000:....:....:....:....:....
| |
| +- 4in6, Egress 80 2a02:0061:0000:00ee:0000:....:....:....
| +- 4in6, Ingress 80 2a02:0061:0000:00ee:0001:....:....:....
| +- Loopback 64 2a02:0061:0000:00ff:....:....:....:....
|
+- Per-Node (nnnn!=0) 48 2a02:0061:nnnn:....:....:....:....:....

== Ausgangssituation und Rahmenbedingungen ==
Der Verein Funkfeuer Wien verfügt über den IPv6 Global Unicast Adressraum 2a02:60/29. Aufgrund von “early registration”, also Versuchen mit IPv6 nach der Zuteilung an Funkfeuer, sind die Netze 2a02:60:0::/48, 2a02:60:1::/48 sowie
2a02:60:2::/48 vergeben und teilweise (noch 2 nodes mit OLSRv1, läuft aus) im operativen Einsatz. Mit einem Betrachtungsfokus der nächst höheren Verwaltungsebene (eines /40 Prefix), ist daher der gesamte Netzbereich 2a02:60::/40 als teilweise belegt zu berücksichtigen.

== Anforderungsprofil an das 0xFF-Adressierungkonzept ==
# IPv6 soll das präferierte Layer-3-Protokoll innerhalb des Netzes sein.
# IPv4 soll zumindest während dem Übergang mittels OLSRv1 weiter unterstützt werden.
# Der für das Mesh-Netz vergebene Adressbereich soll nach außen aggregierbar sein.
# Durch vorausschauende Wahl geeigneter Boundaries soll die Möglichkeit zur Delegation von DNS Reverse Zonen beachtet werden.
# Das Design soll skalierbar sein, sodass andere Communities (z.B. 0xFF Graz) sich dem Konzept anschließen können.
# IPv6: Die Vergabe von IPv6 Adressen soll RFC6177 konform sein.
# IPv6: Gemäß IPv6 Design Guidelines, sollen Prefixe standortorientiert vergeben werden.
# IPv6: Der Einsatz von “stateless modified EUI64” Adressierung soll möglich sein.
# IPv4: Im verwendeten IPv6 Adressraum sollen IPv4-Adressen in Übereinstimmung mit RFC4291 mittels eines “Mapping-Mechanismus” abgebildet bzw. “gemappt” werden können.

== Umsetzung des IPv6-Adressierungskonzeptes ==
Die Vorgabe nach Standortorientierung (lt. RFC6177) legt nahe, die “Node-ID” des Redeemer als Teil der IPv6-Adresse heranzuziehen. Wir gehen davon aus, dass 65535 Standorte für den Verwaltungbereich von Funkfeuer Wien, das entspricht 16 Bit im Adressfeld, ausreichend sind. (Anm.: Die Node-ID mit der Nummer Null gilt als reserviert. Erklärung im Text unten.)

Der Empfehlung von RFC6177 nach vorausschauender Kapazitätsplanung wird nachgekommen, indem pro Standort bis zu 65535 lokale Netze realisierbar sind. Das ermöglicht eine flexible Segmentierung mit /64 Netzen pro Interface. Durch die jeweiligen Standortbetreiber sind diese Adressbits, entsprechend den individuellen Erfordernissen und Gegebenheiten, selbstständig zu vergeben.

Die Realisierung einer “modified EUI64” Adressierung gemäß RFC4291 Appendix A, erfordert die Bereitstellung von 64 Bit im Host-Teil der IPv6-Adresse.

Unter Berücksichtigung aller oben beschriebenen Fakten, ergibt sich ein erforderlicher Adressraum eines /32 Prefixes. Auf Grund bereits bestehender Teilbelegungen ist in der /32 Verwaltungsebene der nächstmögliche freie und zusammenhängende Adressraum: 2a02:61::/32.

Das ist in voller Schreibweise:

Allocation: 2a02:61::/32
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|
Erste Adresse: 2a02:0061:0000:0000:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:ffff:ffff:ffff:ffff:ffff:ffff

Dieser Bereich ist für das Mesh-Netz von 0xFF, Funkfeuer Wien, zu wählen.

== IPv6-Bereich für Infrastruktur ==
Für Infrastruktur abseits der User Blocks wird der Bereich 2a02:61::/48 reserviert. Innerhalb von diesem Bereich finden sich die Loopback Adressen und auch die Tunnel Bereiche.

Allocation: 2a02:61::/48
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|
Erste Adresse: 2a02:0061:0000:0000:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:0000:ffff:ffff:ffff:ffff:ffff

== IPv6-Adressen für Nodes ==

=== Link-lokale Adressen ===
Geräte generieren pro Device-Interface automatisch mindestens eine link-lokale Adresse aus dem Bereich fe80::/64. Diese werden für die OLSRv2-Kommunikation zwischen Devices verwendet. Sie haben einen lokalen scope, Adressen sind nur auf OSI Layer 2 gültig, werden somit nicht geroutet.
Da dieseselben Adressen (auf verschiedenen Links) mehrfach vorkommen können, identifiziert OLSRv2 Devices über andere, global gültige Adressen (siehen unten). OLSRv1 kann damit ''nicht'' umgehen [Anm: Bitte klarstellen, warum nicht?]

Allocation & used: fe80::/64
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|
Erste Adresse: fe80:0000:0000:0000:0000:0000:0000:0000
Letzte Adresse: fe80:0000:0000:0000:ffff:ffff:ffff:ffff

=== Loopback-Adressen ===
Devices generieren mindestens eine global gültige Adresse aus dem Bereich 2a02:61:0:ff::/64 per EUI64. Diese Adresse identifiziert das Interface eindeutig und wird auch von OLSRv2 als Identifier herangezogen. Aufgrund der Eindeutigkeit der EUI64 zugrunde liegenden MAC-Adressen ist sicher gestellt, dass keine Adresse mehrfach verwendet wird. Weiters ermöglicht dieses Vorgehen, ein Device ohne vorherige Adresszuweisung in Betrieb nehmen zu können.

Allocation & used: 2a02:61:0:ff::/64
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|
Erste Adresse: 2a02:0061:0000:00ff:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:0000:00ff:ffff:ffff:ffff:ffff

Dies ist etwa auf der Hälfte der Knoten in Verwendung. Damit ist keine Zuordnung zur Nodeid direkt möglich, deswegen werden User-Blocks verwendet.

=== User-Blocks ===
Hierbei handelt es sich um Adressbereiche, die pro Knoten zugewiesen werden können, um anschließend in Subnetzen "hinter" dem Knoten Verwendung zu finden. Dazu wird eine eindeutige Standortkennung in die Bits 33-48 der IPv6-Adresse eingefügt. Diese 16 Bits sind aus der “Node-ID” des [https://portal.funkfeuer.at/wien/ Redeemer] abgeleitet. Somit resultiert für jeden registrierten Standort ein 48 Bit langes “Site-Prefix”. Die Node-ID mit der Nummer Null (0x0000) ist dabei für Infrastruktur reserviert (siehe unten) und wird nicht vergeben.

Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|
Erste Adresse: 2a02:0061:0001:0000:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:ffff:ffff:ffff:ffff:ffff:ffff

== IPv4-Adressen für Nodes ==
'''Wichtig:''' Diese Adressierung ist nur für reine IPv6 Knoten relevant. Knoten die weiterhin über Dual Stack angebunden sind benötigen diese idR nicht.

IPv4-Adressen werden auf Devices als native IPv4-Interfaces bereit gestellt. Für den Transport des IPv4-Traffics über das IPv6-Netz wird das 4in6-Verfahren angewandt, das im Linux-Kernel seit längerem zuverlässig implementiert ist und einen zustandslosen Tunnel zwischen dem Device und einem Tunnel-Server herstellt. Für das Mapping von IPv4-Adressen auf IPv6 wird der Bereich 2a02:61:0:ee::/64 verwendet. IPv4-Adressen werden dabei auf die letzten 32 Bit gemappt, wobei für eingehenden und ausgehenden Traffic unterschiedliche Subnetze verwendet werden, wodurch zwischen 0xFF und dem Rest des Internets unterschieden werden kann (Details siehen unten). Das Konzept ist im Detail unter [[Projekte/v642/IPv4_Support]] erklärt.

Es werden IPv4-Adressen aus dem Bereich 185.194.20.0/23 vergeben. Pro Knoten wird grundsätzlich eine (1) IPv4-Adresse vergeben. Es wird nicht automatisch eine IPv4-Adresse pro Knoten alloziert, sondern die IPv4-Adresse muss angefragt werden. Die Zuweisung soll automatisiert werden.

Allocation: 2a02:61:0:ee::/64
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|
Erste Adresse: 2a02:0061:0000:00ee:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:0000:00ee:ffff:ffff:ffff:ffff

=== Outbound-Traffic (von Device zu Tunnel-Server) ===
Für das Mapping der IPv4 Adressen für Traffic vom FunkFeuer Netz ins Internet wird der Bereich 2a02:61:0:ee::/80 verwendet. Der gesamte Adressbereich wird durch die Tunnel-Server angekündigt, wodurch sämtlicher getunnelter IPv4-Traffic seinen Weg dorthin nimmt.

Used: 2a02:61:0:ee::/80
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|
Erste Adresse: 2a02:0061:0000:00ee:0000:0000:0000:0000
Letzte Adresse: 2a02:0061:0000:00ee:0000:ffff:ffff:ffff

=== Inbound-Traffic (von Tunnel-Server zu Device) ===
Für das Mapping der IPv4 Adressen für Traffic vom Internet ins FunkFeuer Netz wird der Bereich 2a02:61:0:ee:1::/80 verwendet. Adressen aus den 0xFF zugewiesenen IPv4-Adressblöcken werden dabei wie o.g. User-Blocks behandelt: Technisch werden diese durch den innehabenden Knoten über ihre Loopback-(IPv6)-Adresse angekündigt, organisatorisch werden diese zugeteilt.

Used: 2a02:61:0:ee:1::/80
Bitgrenze: 16| 32| 48| 64| 80| 96| 112| 128|
Erste Adresse: 2a02:0061:0000:00ee:0001:0000:0000:0000
Letzte Adresse: 2a02:0061:0000:00ee:0001:ffff:ffff:ffff

Projekte/Datenschutz

2020-05-19T13:05:35Z

Yellow:

== 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 (Anm.: Wir sollten das mit der Aufnahme als ao/o Mitglied mit abfragen

* Gibt es ein '''Verarbeitungsverzeichnis'''?
(Anm.: Ich glaube wir erstellen das hier gerade neu, so ausführlich wie das hier zugeht)

== 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-18T09:56:56Z

Yellow: Fotoeinwilligung hinzugefügt

== 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?
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-18T09:41:17Z

Yellow: /* Smokeping? */

== 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? ==
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:37:22Z

Yellow: /* Wiki-Account */

== 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?
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:34:12Z

Yellow: /* Allgemein */

== 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#OLSRv1_Status genauer nachgelesen werden. Zusammengefasst: Informationen aus der Map1-API (IP-Adressen, Knotenname und Geolocations *ohne* Kontaktdaten, erfordert einen User-Login) werden mit der OLSR-Topologie verschnitten und die Veränderungen im beschränkten zeitlichen Verlauf vermerkt. Eine Map stellt dies ähnlich wie Map1-BaseMap dar. So kann erkannt werden, welche Nodes/Links es noch vor einigen Tagen online gab, aktuell aber im Netzwerk fehlen.]

== 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?

Projekte/Datenschutz

2020-05-18T09:31:39Z

Yellow: /* Website */

Projekte/Datenschutz

2020-05-18T09:30:32Z

Yellow: /* Mailinglisten */

Projekte/Datenschutz

2020-05-18T09:19:41Z

Yellow: /* Bankdaten */

Projekte/Datenschutz

2020-05-18T09:18:47Z

Yellow: /* Riot */ Allgemeinen Motivationsparagrafen eingefügt.

Services/Organisation/Gallery

2020-05-14T14:37:55Z

Yellow: persönlich klingenden Kommentar entfernt

== Beschreibung ==
Photo Gallery zur Ablage von Bildern von Knoten, Events, Workshops, Konferenzen,...

== Abhängigkeiten ==

Anregung:
Für Inklusion in der nodeDB wäre es sehr gut, wenn jedes Photo und uach jeder node (== standort) einen statischen permalink hat, der sich auch bei Versions-upgrades nicht mehr ändert.
Bitte das in die Entscheidung bei der Auswahl der gallery berücksichtigen.

== Verwendung ==
Die Gallery soll grundsätzlich offen für alle Funkfeuer-User sein.

--> Frage: IP range Funkfeuer oder Funkfeuer login (nodeDB/redeemer)?

Gesonderte Zugriffsrechte für manche Bereiche wären wünschenswert - etwa für einzelne Bilder oder Standorte (Alben).

== Maintainer ==
Markus Gschwendt

== Brainstorming ==

=== Anforderungen ===

Die bisherige Gallery basiert auf G2. Gallery2 und Gallery3 werden nicht mehr weiterentwickelt. Die Migration auf ein anderes System ist erforderlich.

* möglichst kein externes Cloud Service
* möglichst keine PHP Software (auch für andere Projekte - warum eigentlich? -> Diskussionsseite)
* möglichst statische Seiten
* ev. (shell-)Scripts die die Bilder darstellen
und Bilder-Upload getrennt davon (möglichst Userfreundlich)
* Upload soll für 'Neue' möglich sein (selfregistration -> entspricht das dem Workflow? -> Diskussionsseite)
* künftige Erfassung der Fotorechte

weiterführende Informationen zu Alternativen:
https://www.it-pulse.eu/webanwendungen/menalto-gallery/gallery-team-verkuendet-aus-fotogalerie-software-1809.html

=== Mögliche Lösungen ===

* Neuer Lösungsansatz: Keine Gallery mehr benützen, sondern die Bilder in Forenbeiträgen im neuen [https://forum.funkfeuer.at Forum] ablegen. Spart Maintership, ist kein PHP, Forum ist per se eine Form von Social-Media mit Kommentarfunktion, User können entscheiden, ob sie Daten sichtbar machen oder nicht.

Die nachfolgenden Projekte sind in alphabetischer Reihenfolge sortiert.

==== Coppermine ====

* Website: http://coppermine-gallery.net/
* Programmiersprache: PHP
* Lizenz: GPL v3.0 [http://documentation.coppermine-gallery.net/en/copyrights.htm]

* Demo: http://coppermine-gallery.net/demo/cpg15x/
* Plugins: http://coppermine-gallery.net/plugins.php?cpg_version=both

(+)zahlreiche Plugins verfügbar (Backup, Massimport, Panoramaviewer, Timeline, ...)
(+)individuell konfigurierbare Userprofil-Einträge
(+)Passwortgeschützte Alben möglich

===== Migration von G2 zu Coppermine 1.5.x =====
http://forum.coppermine-gallery.net/index.php?topic=76143.0

==== DAlbum ====

* Website: http://www.dalbum.org
* Programmiersprache: PHP
* Lizenz: GPL v2+ [http://www.dalbum.org/index.php?go=Copyrights]

(+) baut auf lokaler Ordnerstruktur auf, welche indiziert wird
(-)kein integrierter Bilder Upload (ist via FTP [http://www.dalbum.org/index.php?go=Upload gedacht])
(·)[http://dalbum.org/index.php?go=Access User Verwaltung]
(·)beim Indizieren werden auch Thumbnails erstellt
(+)Pic-Infos werden ausgelesen und lassen sich ein/ausblenden

==== Drupal + Node Gallery ====

* Website: https://www.drupal.org
* Website Modul: https://www.drupal.org/project/node_gallery
* Programmiersprache: PHP 5.6 oder 7.x
* Lizenz: GPL 2

(+) Flexibilität: Es handelt sich um ein stark DB-orientiertes CMS mit zahlreichen Modulen
(+) Erweiterbar
(+) Code-Updates über Cronjob mittels "drush -y up"
(+) Darstellung der Nodes über Views anpassbar - ermöglicht Filter, Sortierung, Gruppierung.
(-) Bedarf des Einlernens
(-) Bedarf der Anpassung

==== Hugo + Hugo-gallery oder Hugo + HugoPhotoswipe + PhotoSwipe ====

* Hugo Website: https://gohugo.io/tools/
* Programmiersprache: Go

* Hugo-Gallery
** Repository: https://github.com/icecreammatt/hugo-gallery/blob/master/README.md
** Lizenz: MIT [https://github.com/icecreammatt/hugo-gallery/blob/master/LICENSE]

* HugoPhotoSwipe
** Repository: https://github.com/GjjvdBurg/HugoPhotoSwipe/blob/master/README.rst
** Lizenz: GPL v3.0 [https://github.com/GjjvdBurg/HugoPhotoSwipe/blob/master/LICENSE]

* PhotoSwipe
** Website: http://photoswipe.com/
** Lizenz: MIT 'with Wordpress exception'

(·) Hugo ist ein statischer Websitegenerator auf Basis von Go; die beiden Erweiterungen können scriptbasiert Galerien erstellen.
(·) PhotoSwipe ist rein auf Javascript aufgebaut und nutzt vordefinierte Bildgrößen. Dokumentation [http://photoswipe.com/documentation/getting-started.html]

Meinungen:
sieht auch nach einem guten statischen Generator aus.

==== Media Goblin ====

* Website: http://www.mediagoblin.org/
* Lizenz: GNU AGPLv3 [http://mediagoblin.readthedocs.io/en/stable/siteadmin/about.html#how-is-gnu-mediagoblin-licensed]

(+) War schon mal Projekt bei Google Summer of Code, und reicht regelmäßig dort ein.
(-) Es ist riesig, sowohl bezüglich Funktionalität (Video-Transkodierung etc.) als auch Sourcen.
(·) Medien landen in einer (lokalen) Datenbank, nicht Verzeichnisbaum.
(·) Bringt sein eigenes Django-artiges (?) Framework, aber eben nicht Django.
(+) Debian/Ubuntu-Pakete, Fedora/Redhat vorhanden; Abhängigkeiten:
Python 2.7 or Python 3.4+
python-lxml
git
SQLite/PostgreSQL
Python Imaging Library (PIL)
virtualenv
nodejs
http://mediagoblin.readthedocs.io/en/stable/siteadmin/deploying.html

Meinungen:
"This project is part of the GNU Project." Supporttechnisch sicher nicht übel.

==== nextcloud ====
(getestet)

* Website: http://nextcloud.com/
* Demo: https://demo.nextcloud.com/
* Programmiersprache: PHP
* Lizenz: GNU AGPL 3.0 [https://github.com/nextcloud/nextcloud.com/blob/master/LICENSE]

(-) keine Baum-Darstellung der Gallery
(-) kein Resizing der Bilder
(-) keine Pic-Infos,... in der Gallery-Darstellung

Meinung: mbmn als Gallery ungeeignet [+/-] (2/0)

==== PhotoFloat ====

* Website: https://git.zx2c4.com/PhotoFloat/about/
* Programmiersprache: Python2
* Lizenz: GPL v2.0+ [https://git.zx2c4.com/PhotoFloat/about/]

Eindrücke:
PhotoFloat hat eine serverseitige Authentifizierung basierend auf flask-login, sodass man Alben etc. mit Login "schützen" kann. https://flask-login.readthedocs.io/en/latest/

Allerdings sehe ich da weder ein Web-Interface für Selbstregistrierung, noch Unterstützung für mehr als zwei (!?) User.

Es dürfte auch keinen Web-Bilder-Upload geben, und von PEP-8 [5] hat der Autor wohl noch nichts gehört :-) https://www.python.org/dev/peps/pep-0008/#tabs-or-spaces

Fazit: (Auch) PhotoFloat bräuchte einige Anpassungen und Umbauten für den Gallery-Anwendungsfall.

==== Piwigo ====
(getestet)

* Website: http://piwigo.org
* Programmiersprache: PHP
* Lizenz: GNU GPLv2 [http://piwigo.org/basics/license]

(·) wird oft als Ersatz für G2 und G3 Projekte verwendet.

Meinungen:
* schaut interessant aus

===== Migration von G2 nach Piwigo =====
Migration von G2 mittels Scripts möglich etwa:
https://github.com/dschwen/g2piwigo

==== Sigal ====

* Website: http://sigal.saimon.org/
* Programmiersprache: Python
* Lizenz: MIT [http://sigal.saimon.org/en/latest/]

(·) album metadaten via markdown files.
(+) generiert wenn gewünscht auch eine nette Karte basierend auf den Koordinaten in den Photo-Metadaten via leaflet / openstreetmap.
(+) einfach zu installieren und konfigurieren.
(+) könnte als cronjob, git post-receive hook oder dergleichen laufen.
(?) die offene frage wäre dann wie man sicher fotos von selbst registrierten users in einen lokalen ordner am server bekommt.

Meinungen:
sieht nach einem guten statischen Generator aus.

==== WordPress ====

* Website:
* Programmiersprache: PHP
* Lizenz: GPL v2 + [https://wordpress.org/about/license/]

(·) via Plugin: Gallery Manager

Meinungen:
* ganz allgemein... Hände weg von wordpress; Gegenfrage: warum?
* Sicherheitslücken...; Gegenargument: die werden aber üblicherweise flott gestopft...;

==== Zenphoto ====
(getestet)

* Website: http://www.zenphoto.org/
* Programmiersprache: PHP
* Lizenz: GPL v2+ [http://www.zenphoto.org/pages/licenses/]

(·) eher als Foto-CMS gedacht
(?) Userrechte für verschiedene Fotogrößen?

===== Migration von G2 zu Zenphoto =====
http://www.zenphoto.org/news/gallery2-to-zenphoto-migration/

==== GoGallery ====

* Website: https://github.com/smancke/gogallery
* Programmiersprache: Go
* Lizenz: MIT License [https://github.com/smancke/gogallery/blob/master/LICENSE]

==== Chevereto Free ====

* Website: https://chevereto.com/free
* Programmiersprache: PHP
* Lizenz: GNU Affero General Public License v3.0 [https://github.com/Chevereto/Chevereto-Free/blob/master/LICENSE]
* Demo: https://demo.chevereto.com/

=== Zeitplan ===

* Brainstormingphase ... bis Herbst 2017
* Sept. 2017 Entscheidung über System.
* Umsetzung bis Anfang 2018.

=== Diverse Links ===

https://en.wikipedia.org/wiki/Comparison_of_photo_gallery_software

wiki deutsch listet teilweise andere auf
https://de.wikipedia.org/wiki/Webgalerie

https://www.heise.de/download/products/foto/web-galerien

Regionen/Wien/Verein/202005 GV

2020-05-12T12:45:06Z

Yellow:

Notizen des Vereinsvorstands zur Generalversammlung des Vereins FunkFeuer Wien im Mai 2020

'''Achtung: Die Inhalte dieser Wikiseite werden laufend geändert und dienen als öffentliche Arbeitsunterlage des Vorstands.''' Die endgültigen Inhalte kommen zur Abhaltung der Generalversammlung auf die Protokollseite unter [[201905_GV_Protokoll]].

[[NX | Präsentationsfolien]] ([NX TeX-Source])

Bitte diese Wikiseite nicht selbst bearbeiten! Vorschläge, Diskussionen, Kandidaturen bitte per Mail an mailto:wien@lists.funkfeuer.at

== Datum, Uhrzeit, Ort ==

* Dienstag, 19.05.2020
* Eintreffen ab 18:00, Beginn um 18:30
* Ort: online unter https://bbb.runout.at/b/run-ryg-gdk

== Ankündigung ==

Die Ankündigung der GV erfolgte am 04.05.2020 über die Mitglieder-Mailingliste sowie die Wien- und Discuss-Listen.

== Stimmrechtsübertragungen ==

§9 Abs. 5: "Die Übertragung des Stimmrechts auf ein anderes Mitglied im Wege einer schriftlichen Bevollmächtigung ist zulässig."

Formvorschlag: Email bis spätestens 18.05.2020 18:00 an den Vorstand (mailto:vorstand@funkfeuer.at) à la "Ich, <code>$NAME</code>, bevollmächtige <code>$VERTRETER_IN</code>, mein Stimmrecht bei der FunkFeuer-Generalversammlung am <code>$DATUM</code> auszuüben."

'''Es muss kein "Formular" verwendet werden.''' Bitte rechtzeitig erledigen, damit wir bei etwaigen Nachfragen zur Person noch ein e-Mail schreiben können.

== Anträge ==

Anträge zur Tagesordnung müssen bis spätestens 16.05.2020 18:00 an mailto:vorstand@funkfeuer.at gemeldet werden. '''Wir empfehlen davor eine öffentliche Diskussion über die Mailingliste mailto:wien@lists.funkfeuer.at '''

Anträge bezüglich der Statuten bitte als Merge Request an das Statuten-Repository auf GitLab: https://gitlab.com/funkfeuer/Statuten-Wien

== Kandidaturen ==

Kandidaturen für den Vorstand müssen bis spätestens 16.05.2020 18:00 an mailto:vorstand@funkfeuer.at unter Nennung der angestrebten Funktion(en) gemeldet werden. Wir empfehlen eine öffentliche Kandidatur über die Mailingliste mailto:wien@lists.funkfeuer.at

Im Folgenden listet der Vorstand alle 1. ihm bekannten und 2. explizit veröffentlichten oder ihm zur Veröffentlichung freigegebenen Kandidaturen.

'''Achtung: Die Inhalte dieses Abschnitts werden laufend geändert.''' Die finalen Kandidaturen werden nach Ablauf der Meldefrist zur Abhaltung der Generalversammlung auf die Protokollseite verschoben: [[201905_GV_Protokoll]]

Alphabetisch nach Name (Name wie am ZVR-Auszug, bzw. Nickname/Redeemer):

{| class="wikitable sortable" style="text-align: center;"
|-
!style="text-align: left;"|'''Kandidat_in \ Funktion'''
!style="width: 10%;"|'''Obfrau / Obmann'''
!style="width: 10%;"|'''Stv._in'''
!style="width: 10%;"|'''Schriftführer_in'''
!style="width: 10%;"|'''Stv._in'''
!style="width: 10%;"|'''Kassier_in'''
!style="width: 10%;"|'''Stv._in'''
!style="width: 10%;"|'''Rechnungsprüfer_in (2x)'''
|-
|style="text-align: left;"|GRAF, Sebastian-Wilhelm || || || || ||||||x
|-
|style="text-align: left;"|LÖSCH, Christoph || ||x||x||x|| ||x||
|-
|style="text-align: left;"|MAIERHOFER, Daniel A. || || ||x||x|| || ||
|-
|style="text-align: left;"|MARVILLO, Adi || || || || ||x|| ||
|-
|style="text-align: left;"|OTT, Pascal || || || || || ||x||x
|-
|style="text-align: left;"|RAFETSEDER, Albert ||x||x||x||x||x||x||
|-
|style="text-align: left;"|Runout || ||x|| ||x|| ||x||
|-
|style="text-align: left;"|SENGEIS, Manfred || || || ||x|| || ||
|-
|style="text-align: left;"|ŠUBIK, Matthias ||x||x||x||x||x||x||
|-
|}

----

== Vorschlag für eine Tagesordnung ==

* Begrüßung
* Feststellen der Beschlussfähigkeit
* Bericht des Vorstands
* Bericht der Rechnungsprüfer
* Abstimmung über Entlastung des Vorstands
* Wahl
* Anträge
* Allfälliges
* Verabschiedung

Regionen/Wien/Verein/202005 GV

2020-05-12T12:35:01Z

Yellow: Namensnennung klargestellt (hoffentlich)

Notizen des Vereinsvorstands zur Generalversammlung des Vereins FunkFeuer Wien im Mai 2020

'''Achtung: Die Inhalte dieser Wikiseite werden laufend geändert und dienen als öffentliche Arbeitsunterlage des Vorstands.''' Die endgültigen Inhalte kommen zur Abhaltung der Generalversammlung auf die Protokollseite unter [[201905_GV_Protokoll]].

[[NX | Präsentationsfolien]] ([NX TeX-Source])

Bitte diese Wikiseite nicht selbst bearbeiten! Vorschläge, Diskussionen, Kandidaturen bitte per Mail an mailto:wien@lists.funkfeuer.at

== Datum, Uhrzeit, Ort ==

* Dienstag, 19.05.2020
* Eintreffen ab 18:00, Beginn um 18:30
* Ort: online unter https://bbb.runout.at/b/run-ryg-gdk

== Ankündigung ==

Die Ankündigung der GV erfolgte am 04.05.2020 über die Mitglieder-Mailingliste sowie die Wien- und Discuss-Listen.

== Stimmrechtsübertragungen ==

§9 Abs. 5: "Die Übertragung des Stimmrechts auf ein anderes Mitglied im Wege einer schriftlichen Bevollmächtigung ist zulässig."

Formvorschlag: Email bis spätestens 18.05.2020 18:00 an den Vorstand (mailto:vorstand@funkfeuer.at) à la "Ich, <code>$NAME</code>, bevollmächtige <code>$VERTRETER_IN</code>, mein Stimmrecht bei der FunkFeuer-Generalversammlung am <code>$DATUM</code> auszuüben."

'''Es muss kein "Formular" verwendet werden.'''

== Anträge ==

Anträge zur Tagesordnung müssen bis spätestens 16.05.2020 18:00 an mailto:vorstand@funkfeuer.at gemeldet werden. '''Wir empfehlen davor eine öffentliche Diskussion über die Mailingliste mailto:wien@lists.funkfeuer.at '''

Anträge bezüglich der Statuten bitte als Merge Request an das Statuten-Repository auf GitLab: https://gitlab.com/funkfeuer/Statuten-Wien

== Kandidaturen ==

Kandidaturen für den Vorstand müssen bis spätestens 16.05.2020 18:00 an mailto:vorstand@funkfeuer.at unter Nennung der angestrebten Funktion(en) gemeldet werden. Wir empfehlen eine öffentliche Kandidatur über die Mailingliste mailto:wien@lists.funkfeuer.at

Im Folgenden listet der Vorstand alle 1. ihm bekannten und 2. explizit veröffentlichten oder ihm zur Veröffentlichung freigegebenen Kandidaturen.

'''Achtung: Die Inhalte dieses Abschnitts werden laufend geändert.''' Die finalen Kandidaturen werden nach Ablauf der Meldefrist zur Abhaltung der Generalversammlung auf die Protokollseite verschoben: [[201905_GV_Protokoll]]

Alphabetisch nach Name (Name wie am ZVR-Auszug, bzw. Nickname/Redeemer):

{| class="wikitable sortable" style="text-align: center;"
|-
!style="text-align: left;"|'''Kandidat_in \ Funktion'''
!style="width: 10%;"|'''Obfrau / Obmann'''
!style="width: 10%;"|'''Stv._in'''
!style="width: 10%;"|'''Schriftführer_in'''
!style="width: 10%;"|'''Stv._in'''
!style="width: 10%;"|'''Kassier_in'''
!style="width: 10%;"|'''Stv._in'''
!style="width: 10%;"|'''Rechnungsprüfer_in (2x)'''
|-
|style="text-align: left;"|GRAF, Sebastian-Wilhelm || || || || ||||||x
|-
|style="text-align: left;"|LÖSCH, Christoph || ||x||x||x|| ||x||
|-
|style="text-align: left;"|MAIERHOFER, Daniel A. || || ||x||x|| || ||
|-
|style="text-align: left;"|MARVILLO, Adi || || || || ||x|| ||
|-
|style="text-align: left;"|OTT, Pascal || || || || || ||x||x
|-
|style="text-align: left;"|RAFETSEDER, Albert ||x||x||x||x||x||x||
|-
|style="text-align: left;"|Runout || ||x|| ||x|| ||x||
|-
|style="text-align: left;"|SENGEIS, Manfred || || || ||x|| || ||
|-
|style="text-align: left;"|ŠUBIK, Matthias ||x||x||x||x||x||x||
|-
|}

----

== Vorschlag für eine Tagesordnung ==

* Begrüßung
* Feststellen der Beschlussfähigkeit
* Bericht des Vorstands
* Bericht der Rechnungsprüfer
* Abstimmung über Entlastung des Vorstands
* Wahl
* Anträge
* Allfälliges
* Verabschiedung

Regionen/Wien/Verein/202005 GV

2020-05-04T17:49:02Z

Yellow: Wie im Gespräch angekündigt, hier meine Bereitschaft in allen Funktionen tätig zu werden.

Notizen des Vereinsvorstands zur Generalversammlung des Vereins FunkFeuer Wien im Mai 2020

[[NX | Präsentationsfolien]] ([NX TeX-Source])

'''Bitte diese Wikiseite nicht selbst bearbeiten!''' Vorschläge, Diskussionen, Kandidaturen bitte per Mail an mailto:wien@lists.funkfeuer.at

== Datum, Uhrzeit, Ort ==

TBD, TBD, TBD

(spätestens 27.05.2020 für eine reguläre Ablöse des Vorstands)

== Ankündigung ==

Die Ankündigung der GV erfolgt mindestens zwei Wochen im Voraus über die Mitglieder-Mailingliste sowie die Wien- und Discuss-Listen.

== Stimmrechtsübertragungen ==

§9 Abs. 5: "Die Übertragung des Stimmrechts auf ein anderes Mitglied im Wege einer schriftlichen Bevollmächtigung ist zulässig."

Formvorschlag: Email mind. einen Tag zuvor an den Vorstand (mailto:vorstand@funkfeuer.at) à la "Ich, <code>$NAME</code>, bevollmächtige <code>$VERTRETER_IN</code>, mein Stimmrecht bei der FunkFeuer-Generalversammlung am <code>$DATUM</code> auszuüben."

'''Es muss kein "Formular" verwendet werden.'''

== Anträge ==

Anträge zur Tagesordnung müssen mindestens 3 Tage zuvor vor 18:00 an mailto:vorstand@funkfeuer.at gemeldet werden. '''Wir empfehlen davor eine öffentliche Diskussion über die Mailingliste mailto:wien@lists.funkfeuer.at '''

Anträge bezüglich der Statuten bitte als Merge Request an das Statuten-Repository auf GitLab: https://gitlab.com/funkfeuer/Statuten-Wien

== Kandidaturen ==

Kandidaturen für den Vorstand müssen mindestens 3 Tage zuvor vor 18:00 an mailto:vorstand@funkfeuer.at unter Nennung der angestrebten Funktion(en) gemeldet werden. '''Wir empfehlen eine öffentliche Kandidatur über die Mailingliste mailto:wien@lists.funkfeuer.at '''

Im Folgenden listet der Vorstand alle ihm 1. bekannten und 2. explizit veröffentlichten oder zur Veröffentlichung freigegebenen Kandidaturen.

Alphabetisch nach Nachnamen:

{| class="wikitable sortable" style="text-align: center;"
|-
!style="text-align: left;"|'''Kandidat_in \ Funktion'''
!style="width: 10%;"|'''Obfrau / Obmann'''
!style="width: 10%;"|'''Stv._in'''
!style="width: 10%;"|'''Schriftführer_in'''
!style="width: 10%;"|'''Stv._in'''
!style="width: 10%;"|'''Kassier_in'''
!style="width: 10%;"|'''Stv._in'''
!style="width: 10%;"|'''Rechnungsprüfer_in (2x)'''
|-
|style="text-align: left;"|GRAF, Sebastian-Wilhelm || || || || ||||||x
|-
|style="text-align: left;"|LÖSCH, Christoph || ||x||x||x|| ||x||
|-
|style="text-align: left;"|MAIERHOFER, Daniel A. || || ||x||x|| || ||
|-
|style="text-align: left;"|MARVILLO, Adi || || || || ||x|| ||
|-
|style="text-align: left;"|OTT, Pascal || || || || || ||x||x
|-
|style="text-align: left;"|RAFETSEDER, Albert ||x||x||x||x||x||x||
|-
|style="text-align: left;"|Runout || ||x|| ||x|| ||x||
|-
|style="text-align: left;"|SENGEIS, Manfred || || || ||x|| || ||
|-
|style="text-align: left;"|ŠUBIK, Matthias ||x||x||x||x||x||x||
|-
|}

----

== Vorschlag für eine Tagesordnung ==

* Begrüßung
* Feststellen der Beschlussfähigkeit
* Bericht des Vorstands
* Bericht des Kassiers
* Bericht der Rechnungsprüfer
* Abstimmung über Entlastung des Vorstands
* Wahl
* Anträge
* Allfälliges
* Verabschiedung

Projekte/Housing/Umzug

2020-01-04T21:00:26Z

Yellow: Antennennutzung am VKM aktualisiert nach Dachbegehung

== Zusammenfassung ==

'''Das FunkFeuer-Housing muss bis 28.02.2020 umziehen.''' Wir planen auf dieser Seite, wie es weitergeht. Helft alle mit: mailto:housing@lists.funkfeuer.at

== Aktueller Status ==

31.12.2019: Wir arbeiten den Plan für das VKM aus. (Am Metakeller arbeitet zurzeit niemand.)

=== Aktuelles Ziel ===

* Weitere Schritte im VKM klären: Vertrag, Vorarbeiten Decke / Wände / Zugang, Schließsystem, Luftfluss (Sommer, Winter)

{| class="wikitable"
|+ Vergleich Metakeller und VKM
! Eigenschaft !! Metalab !! VKM !! Porzellaneum
|-
| Plan || [https://github.com/aaaaalbert/funkfeuer-sachen/blob/master/metakeller/planskizze_keller_rhs6.pdf PDF hier] || [https://github.com/aaaaalbert/funkfeuer-sachen/blob/master/vkmkeller/planskizze_keller_vkm.pdf und hier]
|-
| Fläche || 19+9m^2 || 23 m^2 fix, mehr möglich || 4,3x5,6m=24m^2
|-
| Raumhöhe (Gewölbe!) || 2-2,8m || 1,5-2,5m || 1,5-2,2m
|-
| Temperatur || 16-18°C || 20-22°C, Trafotür 26° || "ähm kühl halt"
|-
| Boden || Erde || Asphaltiert || Erde, große Pflastersteine
|-
| Raummiete || 150 € || keine || -
|-
| Dachnutzung || sehr eingeschränkt || möglich || unwahrscheinlich
|-
| GF-Erschließung || 12 kEUR (unverhandelt) || 36 kEUR || ?
|-
| GF-Miete || 200 € monatlich || 300 € monatlich || ?
|-
| Nachbar-Community || Metalab <3 || Verein || Verein
|-
| Zugang || breite Stiegen || enge Wendeltreppe || Stiegen
|-
| Kundenzugang || Keymaster || Portier || evtl. Portier
|-
| Kühlluft || Schächte || Schacht in den Hof/Park || Schacht/Luke zur Gasse
|-
| Vorarbeiten || Räumung; Estrich (~170 €/m^2), Decke || Decke; Kühlung || Estrich, Decke, Wände
|-
| Distanz zur Krypta || 408m || 626m || 1400m
|-
|}

----

== Hintergrund & Chronik ==

In der Krypta im 2. Keller der ÖBV betreibt der Verein FunkFeuer sein Housing. Hier wird einerseits vereinseigene Hardware gehostet, die für das Funknetz relevant ist:

* Anbindung des Kryptaroofs (--> Fortbestand des Standortes nach Auszug wird noch verhandelt )

* Einer von mehreren Uplinks / Verbindung zum NIX (--> Backbone-Team plant weiteres Vorgehen)

Der VM-Host für Wiki, Redeemer usw. sowie das SAN sind seit Anfang 2019 abgesiedelt und jetzt in einem Datacenter eines Sponsors auf einem anderen Vereinsserver untergebracht.

Andererseits steht hier Hardware vom FunkFeuer-Housing (Server, RasPIs von Unterstützer_innen gegen Kostenbeitrag) sowie die dazugehörige Infrastruktur (Switches, Verkabelung, Racks, Lüfter).

Außerdem verwahrt der Verein hier seine (Papier-)Dokumentation.

Der Vorstand hat Kenntnis über den Plan der ÖBV bekommen, dass deren Gebäude ab März 2020 generalsaniert und die sanierten Räume wahrscheinlich nicht mehr für uns zur Verfügung stehen werden. Szenario ist also: '''Wir müssen Ende Februar 2020 aus der Krypta aussiedeln und können wahrscheinlich nicht wieder hinein.'''

Housing-Maintainer, Vorstand und Community haben Interesse, weiterhin ein Housing-Projekt mit Krypta-ähnlichen Bedingungen zu betreiben.

Eine Schließung des Housings oder Änderung des Modells (z.B. reines untervermietetes Rackhosting) wurde diskutiert, aber aufgrund der Konsequenzen verworfen.

Wir bauen das Housing also an einem neuen Standort wieder auf.

=== Was bisher geschah ===

* 17.09.2018: wien@, discuss@, housing@ informiert und um Mithilfe gebeten.
* 24.10.2018: Deadline für [https://dudle.inf.tu-dresden.de/Neuhousing-Treffen/ Terminabstimmung des nächsten Housingtreffens]
* 28.10.2018: Treffen ab 18:00 im Metalab
* 26.01.2019: Start Server- und Servicemigration Wirt3 -> Ford
* 04.02.2019: Endbericht Servermigration Wirt3 -> Ford beim MoMo
* 07.02.2019: Dark-Fiber-Angebote Wienstrom für Metakeller und Volkskundemuseum eingeholt
* 20.02.2019: Treffen ab 18:00 im Metalab
* 01.03.2019: Planskizze Metakeller
* 28.03.2019: Prinzipielles OK vom Metakeller
* 26.04.2019: Infomail über neue Frist und Möglichkeit der Metalab-Keller-Miete
* 29.04.2019: Verlängerung der aktuellen DF-Strecke Krypta-NIG um ein Jahr
* 27.05.2019: Generalversammlung inklusive Bericht zum Zwischenstand "Krypta neu"
* 01.07.2019: Begehung und genauere Vermessung des Metakellers
* 31.07.2019: Migration r01krypta zur InterXion im Rahmen der neuen Kooperation mit Anexia
* 03.09.2019: Preise für E-Installation im Metakeller (~4.000 EUR)
* 09.09.2019: Begehung, Vermessung VKM
* 17.09.2019: Treffen ab 18:00 im Metalab zur weiteren Planung VKM
* 23.09.2019: Treffen 13-14:00 im VKM
* 16.10.2019: Anfrage AUVA RHS 21
* 19.10.2019: Porzellaneum?
* 22.10.2019: Absage AUVA
* 27.10.2019: Erstbegehung Porzellaneum: https://gallery.funkfeuer.at/v/Wien/housing/porz30/
* 10.11.2019: Gentzgasse?
* 14.11.2019: Zweitbegehung & Erstbesprechung Porzellaneum
* 18.11.2019: VKM-Leitung treffen
* 20.11.2019: GF-Preise für Porzellaneum
* 27.11.2019: Budgetplanung mit Regelbesteuerung
* 02.12.2019: MoMo zur Housing-Planung -> 2x klein und fürs Erste nur mit Funk?
* 04.12.2019: Budgetierung Linkredundanz, Stromzähler
* 07.12.2019: Heattest VKM-Keller. Fazit: Schaut gut aus mit der Entlüftung!
* 09.12.2019: Grobe Strom-, Luft-, Linkplanung VKM
* 11.12.2019: Das VKM will uns
* 11.12.2019: Teststrecke Richtung nbg->conesphere aufgebaut
* 12.12.2019: Erstbegehung Eisvogelgasse -> Gut, aber für jetzt zu aufwändig
* 14.12.2019: Stichworte für Porzellaneum aufbereitet
* 19.12.2019: Aufwandsabschätzung, Projektplan VKM
* 20.12.2019: VKM-Zugang um den Jahreswechsel möglich; Stromzähler-Vorlaufzeiten
* 22.12.2019: Vorkette Decke
* 23.12.2019: Vorschlag für ein Kündigungsschreiben
* 29.12.2019: Planung 60-GHz-Redundanz
* 01.01.2020: 16:00 Arbeitstreffen im Metalab
* 02.01.2020: Begehung für Stromzähler
* 04.01.2020: 12:00 Treffen Krypta, ~12:30 VKM für Decke, Wände, Racks, Uplink / Haus-GF

=== Hilf mit! ===

Wir freuen uns über jede Unterstützung (Strukturierung, Planung, Angebote einholen, Umzug, Einrichtung, ...), die wir jetzt und in den nächsten Monaten bis Jahren kriegen können.

Melde Dich am besten per Mail bei mailto:housing@lists.funkfeuer.at und sei dabei.

Regionen/Wien/Verein/201805 GV Protokoll

2018-05-31T19:55:22Z

Yellow: Protokoll in Erstfassung eingetragen, ToDos vermerkt.

== Allgemeines ==
Die ordentliche Generalversammlung 2018 fand am Dienstag, 22.5.2018 ab 18:00 Uhr im Metalab Wien wie angekündigt statt.
Nach der Ausgeben der Stimmkarten starteten wir um 18.15 Uhr mit 22 stimmberechtigten Mitgliedern, und acht Delegationen.

Durch später eintreffende Mitglieder erhöht sich im Laufe der GV die Zahl der Stimmen auf 35, inkl. acht Delegationen. Die Ankunftszeiten wurden nicht getrennt im Protokoll erfasst, ab Beginn der Wahlen wurden keine Wahlkarten mehr ausgegeben.

== Bericht des Vorstandes ==
Obmann Wolfgang berichtet für den Vorstand, hierbei wurden folgende Projekte erläutert:
* Backbone Erneuerung
** Allgemeines (Siehe [[Services/Organisation/Backbone_Network]]
** Was sind Roofnodes
** Was sind Backboneswitches
* [[http://housing.funkfeuer.at]]
** neue RFID Reader, nur noch eine Karte für draußen und drinnen
** Neue Meraki Cams, danke dafür an [[Benutzer/Deltahotel]]
** Neues Housing Frontend/Ticketsystem für Housing Benutzer<br />Jetzt sollte Housing Support besser gehen
* [[http://forum.funkfeuer.at]]
** Durch Initiative von Freiwilligen haben wir wieder ein Forum<br />Account selbst anlegen, und mitmachen
* Upstream durch Community-IX<br />Die Community IX Initiative gibt uns Upstream mit 10Gbit/s!
* embedded housing<br />Das embedded housing hat nun 24 Plätze, und fernwartbaren Strom
* IPMI/iDRAC/iLO/admin VLAN mit IPSec Connectivity<br />Im Housing kann man nun die Admin Ports mit einem fertigen VPN VLAN verbinden, damit man hier diese Wartungsports nicht ins Internet hängen muss
* Lifeball<br />Durch Freiwillige von Funkfeuer wird heuer wieder der Lifeball mit Connectivity versorgt. Durch den Ausfall eines anderen Sponsors macht Funkfeuer heuer auch mehr verkabelte Anschlüsse für Funktionen des Veranstalters und seiner Partner.
*MoMo<br />Die "Monatlichen Montagstreffen" sind gut besucht, und werden meistens durch Paul auch ins Internet übertragen. Für Themen sind alle Mitglieder und Interessierte aufgerufen einfach Vorschläge zu machen, und so einen Termin wahrzunehmen. Wer dazu Unterstützung braucht, einfach fragen.

== Antrag auf Angleichung des Geschäftsjahres ==
Der Vorstand griff die Anregung der Rechnungsprüfer auf, und evaluierte ob das Geschäftsjahr an die laufenden Vorstandsperioden angeglichen werden soll. Nach ausführlicher Evaluierung und Beratung schlägt der Vorstand vor das Geschäftsjahr nicht anzupassen, sondern ggf. durch eine zusätzliche Generalversammlung die Vorstandsperiode wieder anzugleichen. Der Antrag wurde zur Abstimmung gestellt, eine zusätzliche GV wäre aber Aufgabe des nächsten Vorstandes.

Der Antrag wurde mit fünf Enthaltungen und ohne Pro-Stimmen abgelehnt.

== Bericht der Rechnungsprüfer ==
Der Bericht der Rechnungsprüfer wurde verlesen.
Die Rechnungsprüfer haben sich entschuldigt, und eine ausführliche Abhandlung zur Verlesung übersandt.

== Entlastung des Vorstandes für 2017 ==
Die Entlastung des Vorstandes wurde ohne Gegenstimmen bei sieben Enthaltungen angenommen.

== Vorstellung der Kandidaten ==
Alle Kandidaten für Vereinsämter wurden kurz vorgestellt.
[[Regionen/Wien/Verein/Kandidaturen_GV_2018]]

== Neuwahl des Vorstandes ==
Der neue Vorstand wurde Position für Position gewählt, Mehrfachstimmen waren möglich.

=== Abstimmung Obmann ===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Käfer, Thomas ||14
|-
|style="text-align: left;"|Kittenberger, Markus ||16
|-
|style="text-align: left;"|Rafetseder, Albert ||20
|-
|style="text-align: left;"|Šubik, Matthias ||15
|-
|}

=== Abstimmung Obmann Stv.===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Käfer, Thomas ||17
|-
|style="text-align: left;"|Gschwendt, Markus ||17
|-
|style="text-align: left;"|Kittenberger, Markus ||22
|-
|style="text-align: left;"|Sengeis, Manfred ||21
|-
|style="text-align: left;"|Šubik, Matthias ||18
|-
|}

=== Abstimmung Schriftführer ===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Käfer, Thomas ||17
|-
|style="text-align: left;"|Gschwendt, Markus ||14
|-
|style="text-align: left;"|Sengeis, Manfred ||20
|-
|style="text-align: left;"|Šubik, Matthias ||30
|-
|}

=== Abstimmung Schriftführer Stv. ===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Käfer, Thomas ||15
|-
|style="text-align: left;"|Gschwendt, Markus ||15
|-
|style="text-align: left;"|Sengeis, Manfred ||21
|-
|}

=== Abstimmung Kassier ===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Mutschlechner, Thomas ||23
|-
|style="text-align: left;"|Gschwendt, Markus ||17
|-
|}

=== Abstimmung Kassier Stv. ===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Gschwendt, Markus ||24
|-
|}

== Annahme ==
Die Wahl wurde von allen Kandidaten angenommen, und der neue Obmann bedankt sich bei Wolfgang Nagele für sein Engagement und übernimmt den Vorsitz.

== Änderungsvanträge an die Statuten ==
Die Änderungsanträge wurden in mit den umgekehrten Nummern der Pull-Requests auf GitHub aufgerufen, kurz vorgestellt und diskutiert, dann abgestimmt. Alle Anträge wurden heuer von Thomas Käfer eingebracht.

* Pull Request #6, abgelehnt nur mit Gegenstimmen bei dreizehn Enthaltungen
* Pull Request #5, abgelehnt mit zwei Für-Stimmen, bei neun Enthaltungen
* Pull Request #4, abgelehnt mit zwei Für-Stimmen, bei sieben Enthaltungen
* Pull Request #3, abgelehnt mit sieben Für-Stimmen, bei vier Enthaltungen
* Pull Request #2 nach Diskussion durch Antragsteller zurückgezogen, wird bei einer späteren GV ggf. wieder zur Abstimmung kommen.

== Ende der Veranstaltung ==
Die GV wurde ohne Allfälliges um 20:25 Uhr geschlossen, und in den offenen Rahmen überführt.

== ToDo ==
Dieses Protokoll hat nicht alle Themen richtig verlinkt mit den Subseiten hier im Wiki. Weiters fehlen noch die Links zu den GitHub Pull-Requests

Regionen/Wien/Verein/201805 GV Protokoll

2018-05-31T19:44:55Z

Yellow: Zwischenstand, es fehlt noch der letzte Punkt

== Allgemeines ==
Die ordentliche Generalversammlung 2018 fand am Dienstag, 22.5.2018 ab 18:00 Uhr im Metalab Wien wie angekündigt statt.
Nach der Ausgeben der Stimmkarten starteten wir um 18.15 Uhr mit 22 stimmberechtigten Mitgliedern, und acht Delegationen.

Durch später eintreffende Mitglieder erhöht sich im Laufe der GV die Zahl der Stimmen auf 35, inkl. acht Delegationen. Die Ankunftszeiten wurden nicht getrennt im Protokoll erfasst, ab Beginn der Wahlen wurden keine Wahlkarten mehr ausgegeben.

== Bericht des Vorstandes ==
Obmann Wolfgang berichtet für den Vorstand, hierbei wurden folgende Projekte erläutert:
* Backbone Erneuerung
** Allgemeines (Siehe [[Services/Organisation/Backbone_Network]]
** Was sind Roofnodes
** Was sind Backboneswitches
* [[http://housing.funkfeuer.at]]
** neue RFID Reader, nur noch eine Karte für draußen und drinnen
** Neue Meraki Cams, danke dafür an [[Benutzer/Deltahotel]]
** Neues Housing Frontend/Ticketsystem für Housing Benutzer<br />Jetzt sollte Housing Support besser gehen
* [[http://forum.funkfeuer.at]]
** Durch Initiative von Freiwilligen haben wir wieder ein Forum<br />Account selbst anlegen, und mitmachen
* Upstream durch Community-IX<br />Die Community IX Initiative gibt uns Upstream mit 10Gbit/s!
* embedded housing<br />Das embedded housing hat nun 24 Plätze, und fernwartbaren Strom
* IPMI/iDRAC/iLO/admin VLAN mit IPSec Connectivity<br />Im Housing kann man nun die Admin Ports mit einem fertigen VPN VLAN verbinden, damit man hier diese Wartungsports nicht ins Internet hängen muss
* Lifeball<br />Durch Freiwillige von Funkfeuer wird heuer wieder der Lifeball mit Connectivity versorgt. Durch den Ausfall eines anderen Sponsors macht Funkfeuer heuer auch mehr verkabelte Anschlüsse für Funktionen des Veranstalters und seiner Partner.
*MoMo<br />Die "Monatlichen Montagstreffen" sind gut besucht, und werden meistens durch Paul auch ins Internet übertragen. Für Themen sind alle Mitglieder und Interessierte aufgerufen einfach Vorschläge zu machen, und so einen Termin wahrzunehmen. Wer dazu Unterstützung braucht, einfach fragen.

== Antrag auf Angleichung des Geschäftsjahres ==
Der Vorstand griff die Anregung der Rechnungsprüfer auf, und evaluierte ob das Geschäftsjahr an die laufenden Vorstandsperioden angeglichen werden soll. Nach ausführlicher Evaluierung und Beratung schlägt der Vorstand vor das Geschäftsjahr nicht anzupassen, sondern ggf. durch eine zusätzliche Generalversammlung die Vorstandsperiode wieder anzugleichen. Der Antrag wurde zur Abstimmung gestellt, eine zusätzliche GV wäre aber Aufgabe des nächsten Vorstandes.

Der Antrag wurde mit fünf Enthaltungen und ohne Pro-Stimmen abgelehnt.

== Bericht der Rechnungsprüfer ==
Der Bericht der Rechnungsprüfer wurde verlesen.
Die Rechnungsprüfer haben sich entschuldigt, und eine ausführliche Abhandlung zur Verlesung übersandt.

== Entlastung des Vorstandes für 2017 ==
Die Entlastung des Vorstandes wurde ohne Gegenstimmen bei sieben Enthaltungen angenommen.

== Vorstellung der Kandidaten ==
Alle Kandidaten für Vereinsämter wurden kurz vorgestellt.

== Neuwahl des Vorstandes ==
Der neue Vorstand wurde Position für Position gewählt, Mehrfachstimmen waren möglich.

=== Abstimmung Obmann ===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Käfer, Thomas ||14
|-
|style="text-align: left;"|Kittenberger, Markus ||16
|-
|style="text-align: left;"|Rafetseder, Albert ||20
|-
|style="text-align: left;"|Šubik, Matthias ||15
|-
|}

=== Abstimmung Obmann Stv.===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Käfer, Thomas ||17
|-
|style="text-align: left;"|Gschwendt, Markus ||17
|-
|style="text-align: left;"|Kittenberger, Markus ||22
|-
|style="text-align: left;"|Sengeis, Manfred ||21
|-
|style="text-align: left;"|Šubik, Matthias ||18
|-
|}

=== Abstimmung Schriftführer ===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Käfer, Thomas ||17
|-
|style="text-align: left;"|Gschwendt, Markus ||14
|-
|style="text-align: left;"|Sengeis, Manfred ||20
|-
|style="text-align: left;"|Šubik, Matthias ||30
|-
|}

=== Abstimmung Schriftführer Stv. ===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Käfer, Thomas ||15
|-
|style="text-align: left;"|Gschwendt, Markus ||15
|-
|style="text-align: left;"|Sengeis, Manfred ||21
|-
|}

=== Abstimmung Kassier ===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Mutschlechner, Thomas ||23
|-
|style="text-align: left;"|Gschwendt, Markus ||17
|-
|}

=== Abstimmung Kassier Stv. ===
{| class="wikitable sortable" style="text-align: center;"
|-
|style="text-align: left;"|Gschwendt, Markus ||24
|-
|}

Regionen/Wien/Verein

2018-05-31T18:49:00Z

Yellow: /* Generalversammlung 2018 */ Protokoll Link hinzu

Der Verein dient als Plattform zur Verbreitung des Wissens, das nötig ist, um ein solches Netzwerk aufzubauen und zu betreiben. Um dies zu bewerkstelligen, gibt es die [[Regionen/Wien/Montagstreffen | Montagstreffen]] und die Mailinglisten.

== Offizielles ==

=== Presseanfragen ===
Presseanfragen bitte an: [mailto:presse@funkfeuer.at presse@funkfeuer.at]

=== Rechnungen, Buchhaltung ===

Rechnungen bitte an [mailto:billing@funkfeuer.at billing@funkfeuer.at].

=== Offizielle Vereinsadressen ===
==== Postanschrift ====

Verein FunkFeuer Wien<br />
Postfach 44<br />
1016 Wien<br />
Email: [mailto:vorstand@funkfeuer.at vorstand@funkfeuer.at]

==== Vereinsanschrift laut ZVR ====

Verein FunkFeuer Wien<br />
Gonzagagasse 11/25<br />
1010 Wien<br />

(Anm.: Diese Adresse gibt es nur, weil das LPD Wien kein Postfach als Vereinsadresse akzeptiert. '''Kleine Sendungen bitte an unsere Postanschrift (siehe oben), größere Lieferungen bitte vorher vereinbaren.''')

==== USt.-UID, ZVR-Nummer ====

* ZVR: 814804682
* UID: ATU67830859

=== Kontoverbindung ===

Inhaber: Verein FunkFeuer Wien<br />
IBAN: AT552023000000143982<br />
BIC/SWIFT: SPLSAT21

=== Vorstand ===

Per 22.05.2018

* Obmann: Albert Rafetseder
* Obmann Stv.: Markus Kittenberger
* Kassier: Thomas Mutschlechner
* Kassier Stv.: Markus Gschwendt
* Schriftführer: Matthias Šubik
* Schriftführer Stv.: Manfred Sengeis

=== Statuten, Mitgliedsantrag, Stimmrechtsübertragung ===

Hier geht's zu den [https://raw.githubusercontent.com/FunkFeuer/Statuten-Wien/master/Statuten_Funkfeuer_Wien.pdf Statuten] und dem [[Media:Mitgliedsantrag-Funkfeuer-Wien.pdf | Mitgliedsantrag]] und der
[[Media:Stimmrechts%C3%BCbertragung-GV2018-blanko.pdf | Stimmrechtsübertragung GV2018]].

== Spenden ==

Der laufende Betrieb des FunkFeuer-Netzes setzt einiges an Hardware voraus. Um diese Unkosten zu decken, bitten wir euch um freiwillige Spenden. Entscheidet selbst, was euch das Netz wert ist.

== Generalversammlung 2018 ==
Diese findet am Dienstag 22.5 18:00 (Eintreffen am 17:30) im Metalab statt.

[[Regionen/Wien/Verein/201805_GV_Protokoll]]
[[Regionen/Wien/Verein/Kandidaturen_GV_2018|Kandidaturen]]

Statutenänderungsanträge: [https://github.com/FunkFeuer/Statuten-Wien/pulls]

Regionen/Wien

2018-05-31T18:47:47Z

Yellow:

== Aktuelles ==

== Mitmachen ==
Du möchtest mitmachen? Darüber freuen wir uns sehr! Bitte [[Regionen/Wien/Mitmachen | hier]] entlang für alle Informationen!

== Verein (Rechtliches) ==
Wir haben eine eigene [[Regionen/Wien/Verein | Seite]] mit allen Informationen zum Verein inkl. allen Pflichtangaben. Auch dort zu finden: Statuten, Mitgliedsantrag und Informationen zum Vorstand.

== Tools ==
* [https://map.funkfeuer.at Karte]: Eine interaktive Karte, die die Topologie inkl. sämtlicher Knoten enthält.
** [https://map.funkfeuer.at/wien/ Wien] (als [https://map.funkfeuer.at/wien/data.php XML])
** [https://map.funkfeuer.at/nodemap/ nodemap] ([https://github.com/eripek/0xFF-NodeMap Sourcecode])
* [http://smokeping.funkfeuer.at/smokeping Smokeping]: Ein praktisches Tool, um Latenzzeiten im [http://smokeping.funkfeuer.at/smokeping/freenet Netz] grafisch darzustellen.

== Kontakt ==
* Forum: https://forum.funkfeuer.at/
* Chat: https://wiki.funkfeuer.at/wiki/Chat (für einfache schnelle Fragen)
* Mailinglisten: https://lists.funkfeuer.at/mailman/listinfo (Sehr viele Abonnenten, aber in letzter Zeit weniger Aktivität)

802.11s

2018-05-31T18:38:34Z

Yellow:

= '''IM AUFBAU - Any help is welcome!''' =

Wie Ad-hoc nur '''VIEL''' besser ;-)

Der 2012 veröffentlichte Standard IEEE 802.11s definiert eine mögliche technische Grundlage von Mesh-Netzwerken. Er stellt eine modernisierte Variante des älteren Ad-Hoc/IBSS-Modus dar. Als Routingprotokoll wird das Hybrid Wireless Mesh Protocol (HWMP) definiert, aber die Nutzung anderer Protokolle wie OLSR oder B.A.T.M.A.N. ist möglich.

[[Datei:Under-construction.png]]

==Frequenzen mesh_id==
*2,4Ghz
**mesh_id 11s.funkfeuer.at
**Kanal 11 2462 MHz
**Bandbreite 20/40Mhz

*5Ghz
**mesh_id 11s.funkfeuer.at
**Kanal TBA

==Merkmale - Vor/Nachteile==
:Deutlich höhere Datenraten möglich als bei Ad-hoc
:Kompatibel zu anderen 802.11x Standards ( Client -> Meshpoint )
:Nodes müssen/sollten auf dem selben Channel laufen
:Wird praktisch von jedem mac80211 Treiber unterstützt und ist somit auf so gut wie jedem Gerät einsetzbar wo OpenWRT läuft
:mesh_id muss auf allen Nodes ident sein
:Bringt sein eigenes Layer2 Mesh-Protokoll mit, kann aber deaktiviert werden ( derzeit im Funkfeuer bitte nicht verwenden )
:Bandbreiten ( 20/40/80Mhz ) sind untereinander kompatibel und werden "On-the-Fly" angepasst
:Kann im Bridgemode auch auf alter Hardware verwendet werden

==AirOS==
Zum jetzigen Zeitpunkt (12.04.2018) keine Unterstützung durch Ubiquiti :-(

== OpenWRT ==

===Konfiguration über LUCI===
:Teilweise noch Buggy aber möglich, z.B. mesh_id wird im Scan nicht angezeigt

===Konfiguration über CLI===

*/etc/configs/wireless

config wifi-device 'radio0'
option type 'mac80211'
option channel '11'
option hwmode '11g'
option path 'platform/ar933x_wmac'
option htmode 'HT40'
option country 'AT'

config wifi-iface 'default_radio0'
option device 'radio0'
option mode 'mesh'
option mesh_id '11s.funkfeuer.at' # '''Sollte/Muss mit den benachbarten Nodes übereinstimmen.'''
option mesh_fwding '0' # '''Schaltet das 802.11s eigene routing aus! WICHTIG! Da wir derzeit [[Knowledge_Base/OLSR|OLSR]] verwenden!'''
option encryption 'none'
option network 'mesh'

Wlan-Lan Bridge

ebtables -P FORWARD DROP

===Ohne eigenes [[Knowledge_Base/OLSR|OLSR]] als Bridge für -> "Edgerouter-Setup"===

Hier wird eine Möglichkeit beschrieben, eine Antenne mit OpenWRT und 802.11s in ein vorhandenes Edgerouter-Setup einzubinden.

==== LUCI ====

==== CLI ====

eth0.1100

==Getestete Hardware==
=== Confirmed Working ===
:[[Hardware/GL-AR150|GL-AR150]]
:[[Hardware/GL-AR300M|GL-AR300M]]
:[[Hardware/AirGridM2|AirGrid M2]]
:[[Hardware/AirGridM5|AirGrid M5]]
:[[Hardware/NanoBeam_M5-400|Nano/PowerBeam M5]]
:[[Hardware/WRT54GL|WRT54GL]]
:[[Hardware/NanoStation_M5|Nanostation (Loco) M2/M5]]
:[[Hardware/GL-AR750|GL-AR750]] # DSF Problem mit dem ath10k Treiber - 5Ghz nur auf Indoorfrequenzen nutzbar

Regionen/Wien

2018-05-31T18:13:00Z

Yellow:

== Aktuelles ==

== Mitmachen ==
Du möchtest mitmachen? Darüber freuen wir uns sehr! Bitte [[Regionen/Wien/Mitmachen | hier]] entlang für alle Informationen!

== Verein (Rechtliches) ==
Wir haben eine eigene [[Regionen/Wien/Verein | Seite]] mit allen Informationen zum Verein inkl. allen Pflichtangaben. Auch dort zu finden: Statuten, Mitgliedsantrag und Informationen zum Vorstand.

== Tools ==
* [https://map.funkfeuer.at Karte]: Eine interaktive Karte, die die Topologie inkl. sämtlicher Knoten enthält.
** [https://map.funkfeuer.at/wien/ Wien] (als [https://map.funkfeuer.at/wien/data.php XML])
** [https://map.funkfeuer.at/nodemap/ nodemap] ([https://github.com/eripek/0xFF-NodeMap Sourcecode])
* [http://smokeping.funkfeuer.at/smokeping Smokeping]: Ein praktisches Tool, um Latenzzeiten im [http://smokeping.funkfeuer.at/smokeping/freenet Netz] grafisch darzustellen.

== Kontakt ==
* Forum: https://forum.funkfeuer.at/
* Chat: https://wiki.funkfeuer.at/wiki/Chat (für einfache schnelle Fragen, für komplexe Themen aufgrund fehlender Struktur ungeeignet)
* Mailinglisten: https://lists.funkfeuer.at/mailman/listinfo (Sehr viele Abonnenten, aber in letzter Zeit weniger Aktivität)

Regionen/Wien/Verein/Kandidaturen GV 2018

2018-05-19T13:20:37Z

Yellow: Kandidatur eingetragen, Formatierung den anderen Listen angeglichen

== Kandidaturen für Vorstandsfunktionen ==

Diese Tabelle dient nur der Dokumentation, alle Kandidaturen sind bitte bis spätestens Samstag 19.5 18:00 an den Vorstand zu richten, am einfachsten per E-Mail an vorstand@funkfeuer.at

{| class="wikitable sortable" style="text-align: center;"
|-
!style="text-align: left;"|'''Kandidat \ Funktion'''
!style="width: 13.3%;"|'''Obmann'''
!style="width: 13.3%;"|'''Stv.'''
!style="width: 13.3%;"|'''Schriftführer'''
!style="width: 13.3%;"|'''Stv.'''
!style="width: 13.3%;"|'''Kassier'''
!style="width: 13.3%;"|'''Stv.'''
|-
|style="text-align: left;"|Gschwendt, Markus ||-||x||x||x||x||x
|-
|style="text-align: left;"|Käfer, Thomas ||x||x||x||x||-||-
|-
|style="text-align: left;"|Kittenberger Markus ||x||x||x||x||x||x
|-
|style="text-align: left;"|Mutschlechner, Thomas ||-||-||-||-||x||x
|-
|style="text-align: left;"|Rafetseder, Albert ||x||x||x||x||x||x
|-
|style="text-align: left;"|Sengeis, Manfred ||-||x||x||x||-||x
|-
|style="text-align: left;"|Šubik, Matthias ||x||x||x||x||x||x
|-
|}

Alle Personenbezeichnungen, die auf dieser Wikiseite sprachlich in der männlichen oder weiblichen Form
verwendet werden, gelten gleichermaßen sinngemäß für jedwedes Geschlecht.

Services

2017-05-11T20:58:56Z

Yellow:

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

*'''[https://portal.funkfeuer.at/wien/ IP-Adressverwaltung]'''

*'''[http://tunnel.tunnel.wien.funkfeuer.at/openvpn.php openVPN-StatusInfo]'''
:''Status aller openVPN-Tunnel Clients im Netz von Funkfeuer-Wien''

*'''[http://tunnel6.funkfeuer.at/tunnel6.php 6in4-StatusInfo]'''
:''Status aller 6in4-Clients im Netz von Funkfeuer-Wien''

*'''[http://zorro.kunstlabor.at/voip VOIP Telefonie]'''
:''VOIP im Netz von Funkfeuer-Wien''

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

*'''[https://www.funkfeuer.at/Housing.240.0.html Housing]'''

*'''[https://portal.funkfeuer.at/wien/ Redeemer (Frontend Benutzerdatenbank) Wien]'''

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

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

Services/Safety

2017-05-11T18:52:41Z

Yellow: Erster Entwurf

== Merksatz ==
Damit unseren Vereinsmitglieder bei der Ausübung ihres Hobbies nichts passiert, gibt es ein paar leicht zu merkende Regeln:

* '''keine gefährlichen Arbeiten alleine'''
* '''keine vermeidbare Arbeiten in gefährlichen Orten'''
* '''keine gefährlichen Arbeiten ohne ausreichende Absicherung.'''

== Warum? ==

=== Nicht alleine Arbeiten weil ... ===

Wo auch immer ich zu tun habe und mich verletzen könnte oder mich verletze, kann mir ein Buddy helfen. Von Pflaster picken, bis Werkzeug anreichen, so dass ich nicht am Mast eine sichere Arbeitshaltung verlassen muss. Jeder muss auf seine Gesundheit achten, aber auch ein Beispiel für die anderen sein.

=== Gute Vorbereitung ist alles ===
Alles was man am Schreibtisch konfigurieren, vorkonfektionieren, oder testen kann, sollte dort auch gemacht werden. Am Dach beidhändig Stecker krimpen, und weder Werkzeug noch mich selber festzumachen, ist ein no-go.

=== Persönliche Schutzausrüstung ===
Bei Dachbegehungen sind Sicherheitsschuhe ein muss. Vor allem wenn man weiter geht als auf eine Dachterrasse, vielleicht sogar auf ein bisher unbekanntes Dach. Ein verknackster Knöchel, ein mit Werkzeug oder Mastteilen zerschlagener Zeh, das sind alles leicht vermeidbare Unfälle.

== Wir helfen ==
Arbeitsmaterial kann man sich bei KollegInnen ausleihen, gibt es im Baumarkt oder im Internet. Auf Nachfrage können wir gerne auch einen gemeinsamen Termin für das einstudieren der Verwendung von Sicherungsgurten machen.

Hauptseite

2017-05-11T18:32:30Z

Yellow: /* Weitere Informationen zu Funkfeuer.at */ Tippfehler

{{#ask:[[Category:Events]]
[[EndDate::>{{CURRENTYEAR}}-{{CURRENTMONTH}}-{{CURRENTDAY}}]]
[[IsMainEvent::+]]
|?#=page
|?name=name
|?Date#ISO=date
|?EndDate#ISO=enddate
|format=template
|template=EventList_Mainpage
|named args=yes
|sort=date
|intro= <div style="display:inline-block; float:right; border: 1px solid #6991AA;margin: 3px 10px; padding: 0px 15px 15px 5px"> <h2>kommende Events</h2> {{EventListIntro_Mainpage}}
|outro= {{TableEnd}} </div>
}}

<table style="empty-cells:hide">
<tr><td>
{{InfoBanner
|title=Wiki-Migration
|titlebgcolor=#b0d320
|text=Es ist geschafft! Dieses Wiki ist nun das Funkfeuer-Wiki. Unser altes Wiki findet sich unter [http://oldwiki.funkfeuer.at oldwiki.funkfeuer.at] -- die Inhalte dort sind '''veraltet''', bitte nur mehr in historischem Kontext konsumieren. :-)
}}

{{InfoBanner
|title=Neu hier?
|titlebgcolor=#556270
|text=Funkfeuer.at ist jene Plattform, unter der österreichweit freie WLAN-Netze betrieben werden. <br>Die Grundidee dabei ist, einen eigenen Wireless-LAN Netzwerkknoten zu betreiben und entsprechend dem [[PicoPeeringAgreement]] darüber anderen Netzteilnehmern freien Daten-Transit zu ermöglichen.<br>Im Zusammenspiel mit dem dynamischen Routing Protokoll [http://www.olsr.org OLSR] entsteht damit fast von selbst ein gemeinschaftliches Netzwerk, bei dem jedoch die Komponenten des Netzes im Besitz der einzelnen User verbleiben.
}}

{{InfoBanner
|title=Bei FunkFeuer.at mitmachen
|text=Funkfeuer versteht sich als ein soziales Netz, bei dem sich technisch Interessierte über alle politischen, kulturellen und sozialen Grenzen hinweg dem Thema [http://de.wikipedia.org/wiki/Freies_Funknetz Freier Netze in Österreich] widmen. Eine kurze Einführung wie du mitmachen kannst findest du in unserer [[Erste Schritte|Kurzeinführung]]
}}
</td><td style="vertical-align:top">
</td></tr>
</table>
==Weitere Informationen zu Funkfeuer.at==
*[http://www.funkfeuer.at Die 0xFF-Funkfeuer Homepage]
:ist die Homepage des Vereins und stellt Referenzlinks zu den einzelnen örtlichen Initiativen und den wichtigsten Services des Vereins zur Verfügung.

*[https://lists.funkfeuer.at/mailman/listinfo Die Funkfeuer Mailinglisten]
: dienen der schriftlichen Kontaktaufnahme innerhalb der einzelnen Communities und ist neben der Wiki eine unserer wichtigsten Dokumentationsquellen.

*[http://gallery.funkfeuer.at/ Die Bildergalerie]
: ist unsere Foto-Sammlung, in der sich viele Panoramas, Bilder von Knoten aber auch Events finden. Möglicherweise entdeckst du dein Dach auf einem Foto, dann ist es sehr wahrscheinlich, dass du einen Link aufbauen kannst. Du kannst in der Galerie auch selbst Fotos von deinem Knoten hochladen.

== Noch kein Funkfeuer in deiner Region? ==
Unter [[Neue Initiativen]] kannst du deine Kontaktinformationen veröffentlichen und so weitere Interessenten in deiner Gegend finden, die mit dir gemeinsam ein neues Netz aufbauen. Die bestehenden Funkfeuer-Netze stehen euch dann gerne mit Rat und Tat zur Seite!

== Sponsoren ==
Bei der Finanzierung der zentralen Funkfeuer-Infrastruktur (z.B. Router, Glasfaser-Anbindungen) unterstützen uns folgende Sponsoren, wofür wir uns herzlich bedanken! Möchten auch Sie die Arbeit von Funkfeuer unterstützen? Treten Sie mit uns in Kontakt: [[Regionen/Wien/Verein|Funkfeuer Wien]]

[[File:Logo-nextlayer.png|link=https://www.nextlayer.at|NextLayer GmbH]] [[File:Logo-nessus.png|link=https://www.nessus.at|Nessus GmbH]] [[File:Logo-easyname.png|link=https://www.easyname.at|easyname GmbH]] [[File:Logo-stadt-graz.png|link=http://www.graz.at/cms/beitrag/10015013/267046|Stadt Graz Kulturamt]]

__NOTOC__

Services/Organisation/Roof Nodes

2017-05-06T20:02:29Z

Yellow: Mal wild ein paar Anmerkungen zur Diskussion hinzu

== Aktueller Stand ==
Diese Seite spiegelt den aktuellen Stand wider, und wird der aktuellen Netzsituation angepasst.

=== Definition "Roof Nodes" ===
Roof Nodes sind Standorte, welche neben der Funk-Anbindung zu anderen Mitgliedern auch eine kabelgebundene direkte (Layer2-)Verbindung zum [[Services/Organisation/Backbone_Network|Backbone Network]] haben und dem Verein langfristig zur Verfügung gestellt werden.

Das sind derzeit konkret:
# 1010 Wien, Landesgerichtsstraße 18 - "[[Services/Organisation/Roof_Nodes/kryptaroof|kryptaroof]]" (Österreichische Beamtenversicherung)
# 1010 Wien, Universitätsstraße 7 - "[[Services/Organisation/Roof_Nodes/nixroof|nixroof]]" (Neues Institutsgebäude (NIG) / [https://www.vix.at/vix_locations.html VIX1])
# 1100 Wien, Fernkorngasse 10 - "[[Services/Organisation/Roof_Nodes/nessus|nessus]]" (NESSUS GmbH)

=== Allgemeines ===
* "Gesponserte" Antennen bzw. Geräte werden als 'Schenkung angesehen und gehen in das Eigentum des Vereins über.
''Besitz ist es sowieso, aber wollen wir einen Eigentumsübergang mit allen Haftungen? Ich würde hier eher eine Dauerleihgabe ansehen, die nur vom Verein aus beendet werden kann. Dadurch können Garantieabwicklungen, Entsorgung, Lizenzen, etc. beim beliehenen Eigentümer verbleiben (20170506 yellow)''
* Auf den Roof Nodes befestigte Antennen bzw. eingesetzte Geräte werden ohne weitere Vereinbarung als Sponsoring Dauerleihgabe angesehen.
* -> Überlegen wir uns, welche Roofnode-Komponenten dem Verein wichtig sind, die kauft der Verein (ab) oder lässt sie sich spenden, wenn das jemand möchte. Alles andere gehört dem, der's gekauft hat.

-> Es wurde diskutiert, ob die Roof Nodes für alle zugänglich sein sollten. Einerseits ist Funkfeuer ein experimentelles Netzwerk, wo es jedem frei steht neue Technologien zu testen, andererseits gibt es Bedenken zwecks Sicherheit und teils auch administrativem Aufwand bzgl. Funkplan usw.
''Jeder kann in unserem Netzwerk testen, '''nach Rücksprache mit allen/Netzkoordinatoren/dem Papst. TBD''' ''

Evtl. ein Kompromiss: Einschränkung der Roof Nodes, dafür Nodes für Tests zur Verfügung stellen. Geeignete Nodes dafür: wuk, fl49, ..
''Ich glaube das führt zu weit auf dieser Seite, aber man kann ja den Vereinskollegen Standorte für Tests zur Verfügung stellen, sind ja keine Roofnodes, aber ob und wie die dann durch den Verein zu verwalten sind, ist ein anderes Thema.''

=== Kurzbeschreibung ===
Wartung der Funkfeuer Roof Nodes, welche die Anbindung des Funknetzwerks an das kabelgebundene Backbone Netzwerk bereit stellen.

Unter Wartung wird die Einhaltung der vereinbarten Rahmenbedingungen, Instandhaltung, Übersichtlichkeit im Ganzen, möglichst Aktualität der Hardware, Dokumentation sowie bestmöglicher Nutzen für Alle verstanden.

=== Detailbeschreibung ===
* Einhaltung der vereinbarten Rahmenbedingungen
** Frage: Was ist erlaubt, wo sind die Grenzen?
''Grenzen in der Bauordnung, dem Hauseigentümer, etc. etc. Wird bei Errichtung eines Standortes am besten gleich definiert, oder nachdefiniert.''
** Frage: Ein 10 Meter Mast? Mehrere Masten? 5 Antennen? 10?
* Instandhaltung
** Clean-Node Policy: kein Müll verursachen! Verpackungsmaterial und getauschte/defekte Geräte wieder mitnehmen!
''Ich hinterlasse alles so, wie ich es vorzufinden wünsche. Das passt am Klo, aber auch am roofnode''
** keine Hardware ungenutzt(=kein Kabel angeschlossen) am Mast/Dach/Dachboden lagern! Wird nach einem Monat gleichem Status abgebaut.
''Ja zu -roofnode-ist-kein-Lager-, ein konkreter Zeitraum ist aber schwer auszumachen''
** keine losen Kabel! nicht angeschlossene aber optisch intakte Kabel eingerollt in Kasten verstauen oder am Masten befestigen!
** defekte Hardware bzw. Kabel zeitnah ersetzen falls benötigt!
** Abbau von alter aktiver Hardware ein Monat im Voraus ankündigen, da evtl. doch noch genutzt wird.
* Funkplan beachten
** möglichst keine Frequenz doppelt an einem Standort (Ausnahme: "räumlich" komplett voneinander getrennt/abgeschirmt)
** Limits bei Sendeleistung einhalten.
** optimale Ausrichtung beachten, dabei möglichst keine anderen am Standort bestehenden Antennen stören
* Aktualität der Hardware und darauf laufenden Software
** Firmware-Updates werden ausschliesslich Nachts eingespielt, Wöchentliches Wartungsfenster: Sonntag 00:00-03:00
''Ich würde hier zuerst mal abklären warum ein roofnode, von denen wir jetzt schon drei haben, nicht redundant ist. Arbeiten am Dach sind sicherer bei Tageslicht, und wir sind kein Provider, d.h. wo es SPOF gibt, gibt es auch Ausfälle außerhalb von 0-3 Uhr SO LT''
** Ausnahme kritische Security-Updates, werden am gleichen Tag, bzw. um 00:00-03:00 eingespielt
''per definitionem kritische Security Updates kann man sofort einspielen, sollte man sich nur koordinieren, sonst ist der Uplink fürs Update weg.''
** Wartungsfenster bedeutet, dass es in diesem Zeitraum kurzzeitige Verbindungsunterbrechungen geben kann.
** Veränderungen an Hardware wird eine Woche zuvor angekündigt, sofern es sich nicht um einen Ausfall handelt und daher asap passiert.
* Dokumentation
** [https://backbone.funkfeuer.at/ Backbone-Wiki]
** Doku Struktur beachten..

=== Schnittstelle ===
* ?nein? Der Anschluss soll weitestgehend ohne Einschränkungen frei und offen von jedem Mitglied nutzbar sein
* Es soll stets das gewollte dynamische OLSR Routing genutzt werden
* Optimalerweise sollte die Stromversorgung der Antenne mit PoE übernommen werden
* Möglichkeit1: am EdgeSwitch (separiertes untagged VLAN mit OLSR-1v4 und OLSR-2v6 zum Translation-Server)
* Möglichkeit2: am EdgeRouter (native OLSR-1v4 und OLSR-2v6)
''Ist das für die Antenne nicht genau ident?''
* Konfiguration der Antennen:
** Anlegen eines eigenen Users "funkfeuer" mit [https://backbone.funkfeuer.at dokumentiertem Passwort]
** lokales [https://backbone.funkfeuer.at management VLAN] anlegen mit [https://backbone.funkfeuer.at dokumentierter IP-Adresse]
** jeder soll sich per WLAN verbinden können (daher keine proprietären Protokolle wie AirMAX, keine Verschlüsselung, Passwörter, ...)
*** falls bestehende Verbindungen beeinträchtigt werden, nach Absprache mit Maintainer, eine eigene Antenne sponsorn/einsetzen!
** Unumgängliche Spezial-Einstellungen dem Maintainer zum Dokumentieren melden (z.B. Mikrotik nv)
** keine VLANs und keine speziellen Konfigurationen auf dem WLAN Interface
** OLSR Traffic muss untagged per WLAN raus gehen

=== Zutrittskontrolle ===
* für Zugang VorOrt sind erst die Service Maintainer zu kontaktieren um das Vorhaben abzuklären
* Maintainer kümmert sich dann um Zutritts-Erlaubnis (z.B. bei nix den Portier informieren, bei nessus..?)
* bei Realisierung des Vorhabens ist ein Service Maintainer oder eine autorisierte Person dabei

=== Physische Aufbaurichtlinien ===
* Alle Geräte sind gut leserlich nachhaltig zu beschriften
* Keine losen Kabel rumliegen lassen! Defekte Hardware und Kabel sofort entfernen!
* Ungenutzte Antennen sind abzubauen und den Eigentümern zurückzugeben oder, nach Erlaubnis, weiter zu spenden.
* “Ungenutzt” wird dadurch definiert, dass über den Zeitraum von einem Monat keine aktive WLAN Verbindung besteht.
* Ungenutzte Kabel sind eingerollt im Kasten zu verstauen oder eingerollt am Masten zu befestigen

== Abhängigkeiten ==
* [[Services/Organisation/Backbone_Network|Backbone Network]]
* evtl. [[Services/Organisation/Insel_Tunnels|Tunnelserver]]

== Verwendung ==
* ([http://tunnel.tunnel.wien.funkfeuer.at tunnel.tunnel])
* [http://router.kryptaroof.wien.funkfeuer.at router.kryptaroof]
* [http://vlan33.nixroof.wien.funkfeuer.at vlan33.nixroof]
* [http://router.nessus.wien.funkfeuer.at router.nessus]

== Maintainer ==
* [[Benutzer:vchrizz|Christoph Lösch]]
* [[Benutzer:bernhard|Bernhard Marker]]
* [[Benutzer:runout|Markus Gschwendt]]
* [[Benutzer:markit|Markus Kittenberger]]
* [[Benutzer:baloo1986|Christofer Brajkovic]]
* [[Benutzer:datacop|Clemens Hopfer]]

Services/Organisation/Roof Nodes

2017-05-06T18:05:14Z

Yellow:

== Aktueller Stand ==
Diese Seite spiegelt den aktuellen Stand wider, und wird der aktuellen Netzsituation angepasst.

=== Definition "Roof Nodes" ===
Roof Nodes sind Standorte, welche neben der Funk-Anbindung zu anderen Mitgliedern auch eine kabelgebundene direkte (Layer2-)Verbindung zum [[Services/Organisation/Backbone_Network|Backbone Network]] haben und dem Verein langfristig zur Verfügung gestellt werden.

Das sind derzeit konkret:
# 1010 Wien, Landesgerichtsstraße 18 - "[[Services/Organisation/Roof_Nodes/kryptaroof|kryptaroof]]" (Österreichische Beamtenversicherung)
# 1010 Wien, Universitätsstraße 7 - "[[Services/Organisation/Roof_Nodes/nixroof|nixroof]]" (Neues Institutsgebäude (NIG) / [https://www.vix.at/vix_locations.html VIX1])
# 1100 Wien, Fernkorngasse 10 - "[[Services/Organisation/Roof_Nodes/nessus|nessus]]" (NESSUS GmbH)

=== Allgemeines ===
* "Gesponserte" Antennen bzw. Geräte werden als '''Schenkung''' angesehen und gehen in den Besitz des Vereins über.
* Auf den Roof Nodes befestigte Antennen bzw. eingesetzte Geräte werden als solches Sponsoring angesehen.
* -> Überlegen wir uns, welche Roofnode-Komponenten dem Verein wichtig sind, die kauft der Verein (ab) oder lässt sie sich spenden, wenn das jemand möchte. Alles andere gehört dem, der's gekauft hat.

-> Es wurde diskutiert, ob die Roof Nodes für alle zugänglich sein sollten. Einerseits ist Funkfeuer ein experimentelles Netzwerk, wo es jedem frei steht neue Technologien zu testen, andererseits gibt es Bedenken zwecks Sicherheit und teils auch administrativem Aufwand bzgl. Funkplan usw.

Evtl. ein Kompromiss: Einschränkung der Roof Nodes, dafür Nodes für Tests zur Verfügung stellen. Geeignete Nodes dafür: wuk, fl49, ..

=== Kurzbeschreibung ===
Wartung der Funkfeuer Roof Nodes, welche die Anbindung des Funknetzwerks an das kabelgebundene Backbone Netzwerk bereit stellen.

Unter Wartung wird die Einhaltung der vereinbarten Rahmenbedingungen, Instandhaltung, Übersichtlichkeit im Ganzen, möglichst Aktualität der Hardware, Dokumentation sowie bestmöglicher Nutzen für Alle verstanden.

=== Detailbeschreibung ===
* Einhaltung der vereinbarten Rahmenbedingungen
** Frage: Was ist erlaubt, wo sind die Grenzen?
** Frage: Ein 10 Meter Mast? Mehrere Masten? 5 Antennen? 10?
* Instandhaltung
** Clean-Node Policy: kein Müll verursachen! Verpackungsmaterial und getauschte/defekte Geräte wieder mitnehmen!
** keine Hardware ungenutzt(=kein Kabel angeschlossen) am Mast/Dach/Dachboden lagern! Wird nach einem Monat gleichem Status abgebaut.
** keine losen Kabel! nicht angeschlossene aber optisch intakte Kabel eingerollt in Kasten verstauen oder am Masten befestigen!
** defekte Hardware bzw. Kabel zeitnah ersetzen falls benötigt!
** Abbau von alter aktiver Hardware ein Monat im Voraus ankündigen, da evtl. doch noch genutzt wird.
* Funkplan beachten
** möglichst keine Frequenz doppelt an einem Standort (Ausnahme: "räumlich" komplett voneinander getrennt/abgeschirmt)
** Limits bei Sendeleistung einhalten.
** optimale Ausrichtung beachten, dabei möglichst keine anderen am Standort bestehenden Antennen stören
* Aktualität der Hardware und darauf laufenden Software
** Firmware-Updates werden ausschliesslich Nachts eingespielt, Wöchentliches Wartungsfenster: Sonntag 00:00-03:00
** Ausnahme kritische Security-Updates, werden am gleichen Tag, bzw. um 00:00-03:00 eingespielt
** Wartungsfenster bedeutet, dass es in diesem Zeitraum kurzzeitige Verbindungsunterbrechungen geben kann.
** Veränderungen an Hardware wird eine Woche zuvor angekündigt, sofern es sich nicht um einen Ausfall handelt und daher asap passiert.
* Dokumentation
** [https://backbone.funkfeuer.at/ Backbone-Wiki]
** Doku Struktur beachten..

=== Schnittstelle ===
* ?nein? Der Anschluss soll weitestgehend ohne Einschränkungen frei und offen von jedem Mitglied nutzbar sein
* Es soll stets das gewollte dynamische OLSR Routing genutzt werden
* Optimalerweise sollte die Stromversorgung der Antenne mit PoE übernommen werden
* Möglichkeit1: am EdgeSwitch (separiertes untagged VLAN mit OLSR-1v4 und OLSR-2v6 zum Translation-Server)
* Möglichkeit2: am EdgeRouter (native OLSR-1v4 und OLSR-2v6)
* Konfiguration der Antennen:
** Anlegen eines eigenen Users "funkfeuer" mit [https://backbone.funkfeuer.at dokumentiertem Passwort]
** lokales [https://backbone.funkfeuer.at management VLAN] anlegen mit [https://backbone.funkfeuer.at dokumentierter IP-Adresse]
** jeder soll sich per WLAN verbinden können (daher keine proprietären Protokolle wie AirMAX, keine Verschlüsselung, Passwörter, ...)
*** falls bestehende Verbindungen beeinträchtigt werden, nach Absprache mit Maintainer, eine eigene Antenne sponsorn/einsetzen!
** Unumgängliche Spezial-Einstellungen dem Maintainer zum Dokumentieren melden (z.B. Mikrotik nv)
** keine VLANs und keine speziellen Konfigurationen auf dem WLAN Interface
** OLSR Traffic muss untagged per WLAN raus gehen

=== Zutrittskontrolle ===
* für Zugang VorOrt sind erst die Service Maintainer zu kontaktieren um das Vorhaben abzuklären
* Maintainer kümmert sich dann um Zutritts-Erlaubnis (z.B. bei nix den Portier informieren, bei nessus..?)
* bei Realisierung des Vorhabens ist ein Service Maintainer oder eine autorisierte Person dabei

=== Physische Aufbaurichtlinien ===
* Alle Geräte sind gut leserlich nachhaltig zu beschriften
* Keine losen Kabel rumliegen lassen! Defekte Hardware und Kabel sofort entfernen!
* Ungenutzte Antennen sind abzubauen und den Eigentümern zurückzugeben oder, nach Erlaubnis, weiter zu spenden.
* “Ungenutzt” wird dadurch definiert, dass über den Zeitraum von einem Monat keine aktive WLAN Verbindung besteht.
* Ungenutzte Kabel sind eingerollt im Kasten zu verstauen oder eingerollt am Masten zu befestigen

== Abhängigkeiten ==
* [[Services/Organisation/Backbone_Network|Backbone Network]]
* evtl. [[Services/Organisation/Insel_Tunnels|Tunnelserver]]

== Verwendung ==
* ([http://tunnel.tunnel.wien.funkfeuer.at tunnel.tunnel])
* [http://router.kryptaroof.wien.funkfeuer.at router.kryptaroof]
* [http://vlan33.nixroof.wien.funkfeuer.at vlan33.nixroof]
* [http://router.nessus.wien.funkfeuer.at router.nessus]

== Maintainer ==
* [[Benutzer:vchrizz|Christoph Lösch]]
* [[Benutzer:bernhard|Bernhard Marker]]
* [[Benutzer:runout|Markus Gschwendt]]
* [[Benutzer:markit|Markus Kittenberger]]
* [[Benutzer:baloo1986|Christofer Brajkovic]]
* [[Benutzer:datacop|Clemens Hopfer]]

Benutzer Diskussion:2A03:E600:0:0:0:0:0:69

2016-08-18T07:06:32Z

Yellow: Testeintrag für IPv6 Benutzerseiten

Muhahaha .... IPv6 .... ungekürzt .....

Knowledge Base

2016-08-18T07:04:00Z

Yellow: Basissuche / Netzwerksuche dazu

Du befindest dich jetzt in der Wissensdatenbank von Funkfeuer.at

== Fehlersuche ==
==="Das Internet ist kaputt"===
Diesen Satz hört man auch von IT-Technikern leider viel zu oft. Aber eigentlich ist uns allen klar, dass es sich ja nur um unsere Verbindung zum Internet, oder sogar nur um den Browser, oder sogar nur um einen einzelnen Dienst handelt. Am besten man macht sich gleich selbst daran, herauszufinden was es sein könnte. Meistens besteht der Fehler nämlich nur in diesem einen Fall, und jemand anderes muss ihn erst mühsam rekonstruieren. Hier ein paar Möglichkeiten das Problem einzuschränken.

==== Basissuche ====
Die Basissuche kann viel Zeit sparen, es haben schon gestandene Techniker 1,5 Std. nach einem Fehler gesucht, nur weil der Kollege gerade Updates am Mailserver gemacht hat. Deshalb hier eine Checkliste, die so allgemein gehalten ist, dass sie möglichst viele Fehlerstellungen abdeckt.

* Geht der gewünschte Dienst vielleicht mit dem Handy? Oder das Web im Chrome/Chromium neben Edge oder Safari?
* Geht ein anderer Dienst, z.B. bing statt google?
* kann ich statt des Namens, z.B. www.funkfeuer.at auch 78.41.116.37 schreiben?
* Gibt es eine Fehlermeldung? "Name wurde nicht gefunden", "Der Server hat die Verbindung abgelehnt", "Zertifikatsfehler"?
* Kann ich mein Gerät neustarten, anders einstellen?
* Sind alle Anschlüsse so, wie ich es erwarte? Ist da vielleicht ein Kabel zuviel im Computer/Router angesteckt?
* Wann ist es das letzte Mal gegangen?
* Wurden inzwischen Updates eingespielt?

=== Netzwerksuche ===
Nachdem die Basissuche abgeschlossen wurde, und der Fehler vermutlich doch an der Verbindung liegt, hier nun eine Checkliste für den Router/Computer, und dessen Konfiguration und Verbindung.

* Alle Netzwerkstecker mit Kabel und LED leuchten normal, blinken normal?
* In den Netzwerkeinstellungen / Terminal sehe ich eine IP und ein Gateway?
Leider fehlt hier die Zeit alle Betriebssysteme und Interfaces aufzuführen, aber jedes Netzwerkgerät (sogar Drucker) können diese Einstellungen ausgeben.
* Ist das Gateway erreichbar? ping/arp?
* Löst der Nameserver Namen auf "ping g.co" vs. "ping 4.2.2.1", bzw. "ping <meindienst>"
* kann ich eine Verbindung zu dem gewünschten Dienst nachvollziehen? "traceroute/tracert/tracepath <meindienst>"

Habe ich all dies gemacht, kann ich sogar den grimmigsten IT-Techniker um Rat fragen, weil die Arbeit ist schon gemacht, jetzt geht es in die Interpretation.

===Webservice geht nicht, ist "komisch"===

Am Router, oder am Linux, Cygwin, Win10+Ubuntu geht es mit curl oder wget so:

<nowiki>curl -i http://<service>.funkfeuer.at/</nowiki>
oder
<nowiki>wget —server-response -O - http://<service>.funkfeuer.at </nowiki>
In der Antwort bekommt man zusätzlich zum Quelltext der angefragten URL auch noch die Kopfzeilen des Webservers, die sonst der Browser verarbeitet. Hier stehen aber wichtige Hinweise, wie die genaue Serveruhr (zum Logbuchvergleich), Größe, Content-Type (Art der übermittelten Daten).

Die Antwort sieht dann z.B. so aus:
<nowiki>
ich@meinserver:~> curl -i http://map.funkfeuer.at
HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Thu, 18 Aug 2016 06:39:13 GMT
Content-Type: text/html
Content-Length: 397
Last-Modified: Fri, 18 May 2012 00:22:06 GMT
Connection: keep-alive
ETag: "4fb5962e-18d"
Accept-Ranges: bytes

<html>
<head>
<title></title>
</title>
<body>
<h2>map.funkfeuer.at</h2>
<ul>
<li><a href="wien">Wien</a> <font style="font-size: 66%"><a href="ChangeLog.txt">(ChangeLog)</a></font></li>
<li><a href="graz">Graz</a></li>
<li><a href="weststeiermark/">Weststeiermark</a></li>
<li><a href="experimental">Wien <small>(experimental version)</small></a></li>
</ul>
</body>
<html>
</nowiki>
== Allgemeines zu WLAN ==

=== Basiswissen zur Risikobewertung hochfrequenter elektromagnetischer Felder ===

INHALTE:

• Einführung in die umweltmedizinische Thematik

• Technische und physikalische Grundlagen

• Biologische Wirkungen von HF-Feldern–Stand des Wissens

• Risikobewertung aus ärztlicher Sicht

• Fallbeispiel aus der umweltmedizinischen Praxis

• Behandlungsstrategien bei subjektiv empfundener Elektrosensibilität

http://www.izmf.de/sites/default/files/download/IZMF_CME-Fortbildung_2014.pdf

bzw.

http://lax.priv.at/0xff/Risikobewertung_HF_Felder.pdf

== für Developer ==
Hier findest Du Informationen, wenn Du in unserem Netz Neues entwickeln willst.

=== IANA Private Enterprise Number ===
Funkfeuer Wien hat für seine SNMP-Entwicklung seitens der [http://www.iana.org Internet Assigned Numbers Authority (IANA)] die '''Nummer 42893''' zugeteilt bekommen.

Der Eintrag kann [http://www.iana.org/assignments/enterprise-numbers bei www.iana.org] abgefragt werden.
Änderungen sind [http://pen.iana.org/pen/PenModification.page über diesen Link] möglich.

=== High Efficiency WLAN Study Group (HEW) ===
http://www.ieee802.org/11/Reports/hew_update.htm

=== In-Band Simultaneous Transmit and Receive (STR) ===
Durch geschickte Signalverarbeitung kann ein schwaches und spektral schmales 2,4-GHz-Signal gesendet und gleichzeitig auf derselben Frequenz empfangen werden.
Normalerweise übertönt eine Antenne im Sendebetrieb ein eingehendes Signal derart stark, dass es der Empfänger nicht mehr "hören" kann. Denn der Pegel des eingehenden Signals ist wegen der Streckendämpfung beim Empfänger um etliche Größenordnungen schwächer als der Pegel des eigenen Sendesignals. Dennoch setzen manche Funkverfahren Vollduplex-Techniken ein – aber eben über zwei Frequenzen (Frequency Division Full Duplex). Weil dafür zusätzliche aufwendige Analoghardware erforderlich ist, begnügt man sich oft mit der billigeren Version und nutzt nur einen Kanal im Halbduplex-Verfahren, bei dem immer nur einer von zwei Teilnehmern sendet. Das halbiert jedoch die Kapazität des Kanals, weil ein Teilnehmer nur die Hälfte der Zeit senden kann.

Wenn man aber separate Antennen zum Senden und Empfangen einsetzt und die Empfangsantenne dort aufstellt, wo die selbstgesendeten Daten am schwächsten eintreffen, empfangene Signale aber normal, dann lässt sich eine Frequenz dennoch zum gleichzeitigen Senden und Empfangen nutzen.

Verwendet man aber drei Antennen, zwei zum Senden eines identischen Signals und eine zum Empfangen. Der Kniff besteht in der exakten Konstellation der drei Antennen: Die Sendeantennen sind in einer Entfernung aufgestellt, in der sich Wellenberg der einen und Wellental der anderen am Scheitelpunkt treffen – dort treten Interferenzeffekte auf, bei denen sich die beiden Sendesignale im Idealfall gegenseitig auslöschen (Nullpunkt) und ebendort ist die beste Position für die Empfangsantenne. Die Technik wird als als Antenna Cancellation bezeichnet.

[http://www.stanford.edu/~dineshb/comm292-bharadia.pdf Dual Band Radios]

[https://mentor.ieee.org/802.11/dcn/13/11-13-1122-01-0hew-considerations-for-in-band-simultaneous-transmit-and-receive-str-feature-in-hew.pdf In-Band Simultaneous Transmit and Receive (STR)]

Knowledge Base

2016-08-18T06:41:21Z

Yellow: Reihenfolge umgestellt, Fehlersuche mit erstem Absatz hinzu.

Du befindest dich jetzt in der Wissensdatenbank von Funkfeuer.at

== Fehlersuche ==
===Webservice geht nicht, ist "komisch"===

Am Router, oder am Linux, Cygwin, Win10+Ubuntu geht es mit curl oder wget so:

<nowiki>curl -i http://<service>.funkfeuer.at/</nowiki>
oder
<nowiki>wget —server-response -O - http://<service>.funkfeuer.at </nowiki>
In der Antwort bekommt man zusätzlich zum Quelltext der angefragten URL auch noch die Kopfzeilen des Webservers, die sonst der Browser verarbeitet. Hier stehen aber wichtige Hinweise, wie die genaue Serveruhr (zum Logbuchvergleich), Größe, Content-Type (Art der übermittelten Daten).

Die Antwort sieht dann z.B. so aus:
<nowiki>
ich@meinserver:~> curl -i http://map.funkfeuer.at
HTTP/1.1 200 OK
Server: nginx/1.6.2
Date: Thu, 18 Aug 2016 06:39:13 GMT
Content-Type: text/html
Content-Length: 397
Last-Modified: Fri, 18 May 2012 00:22:06 GMT
Connection: keep-alive
ETag: "4fb5962e-18d"
Accept-Ranges: bytes

<html>
<head>
<title></title>
</title>
<body>
<h2>map.funkfeuer.at</h2>
<ul>
<li><a href="wien">Wien</a> <font style="font-size: 66%"><a href="ChangeLog.txt">(ChangeLog)</a></font></li>
<li><a href="graz">Graz</a></li>
<li><a href="weststeiermark/">Weststeiermark</a></li>
<li><a href="experimental">Wien <small>(experimental version)</small></a></li>
</ul>
</body>
<html>
</nowiki>
== Allgemeines zu WLAN ==

=== Basiswissen zur Risikobewertung hochfrequenter elektromagnetischer Felder ===

INHALTE:

• Einführung in die umweltmedizinische Thematik

• Technische und physikalische Grundlagen

• Biologische Wirkungen von HF-Feldern–Stand des Wissens

• Risikobewertung aus ärztlicher Sicht

• Fallbeispiel aus der umweltmedizinischen Praxis

• Behandlungsstrategien bei subjektiv empfundener Elektrosensibilität

http://www.izmf.de/sites/default/files/download/IZMF_CME-Fortbildung_2014.pdf

bzw.

http://lax.priv.at/0xff/Risikobewertung_HF_Felder.pdf

== für Developer ==
Hier findest Du Informationen, wenn Du in unserem Netz Neues entwickeln willst.

=== IANA Private Enterprise Number ===
Funkfeuer Wien hat für seine SNMP-Entwicklung seitens der [http://www.iana.org Internet Assigned Numbers Authority (IANA)] die '''Nummer 42893''' zugeteilt bekommen.

Der Eintrag kann [http://www.iana.org/assignments/enterprise-numbers bei www.iana.org] abgefragt werden.
Änderungen sind [http://pen.iana.org/pen/PenModification.page über diesen Link] möglich.

=== High Efficiency WLAN Study Group (HEW) ===
http://www.ieee802.org/11/Reports/hew_update.htm

=== In-Band Simultaneous Transmit and Receive (STR) ===
Durch geschickte Signalverarbeitung kann ein schwaches und spektral schmales 2,4-GHz-Signal gesendet und gleichzeitig auf derselben Frequenz empfangen werden.
Normalerweise übertönt eine Antenne im Sendebetrieb ein eingehendes Signal derart stark, dass es der Empfänger nicht mehr "hören" kann. Denn der Pegel des eingehenden Signals ist wegen der Streckendämpfung beim Empfänger um etliche Größenordnungen schwächer als der Pegel des eigenen Sendesignals. Dennoch setzen manche Funkverfahren Vollduplex-Techniken ein – aber eben über zwei Frequenzen (Frequency Division Full Duplex). Weil dafür zusätzliche aufwendige Analoghardware erforderlich ist, begnügt man sich oft mit der billigeren Version und nutzt nur einen Kanal im Halbduplex-Verfahren, bei dem immer nur einer von zwei Teilnehmern sendet. Das halbiert jedoch die Kapazität des Kanals, weil ein Teilnehmer nur die Hälfte der Zeit senden kann.

Wenn man aber separate Antennen zum Senden und Empfangen einsetzt und die Empfangsantenne dort aufstellt, wo die selbstgesendeten Daten am schwächsten eintreffen, empfangene Signale aber normal, dann lässt sich eine Frequenz dennoch zum gleichzeitigen Senden und Empfangen nutzen.

Verwendet man aber drei Antennen, zwei zum Senden eines identischen Signals und eine zum Empfangen. Der Kniff besteht in der exakten Konstellation der drei Antennen: Die Sendeantennen sind in einer Entfernung aufgestellt, in der sich Wellenberg der einen und Wellental der anderen am Scheitelpunkt treffen – dort treten Interferenzeffekte auf, bei denen sich die beiden Sendesignale im Idealfall gegenseitig auslöschen (Nullpunkt) und ebendort ist die beste Position für die Empfangsantenne. Die Technik wird als als Antenna Cancellation bezeichnet.

[http://www.stanford.edu/~dineshb/comm292-bharadia.pdf Dual Band Radios]

[https://mentor.ieee.org/802.11/dcn/13/11-13-1122-01-0hew-considerations-for-in-band-simultaneous-transmit-and-receive-str-feature-in-hew.pdf In-Band Simultaneous Transmit and Receive (STR)]

Tools

2016-07-15T11:24:15Z

Yellow: Formatting

Eine Toolsammlung für alle Belange rund um Funkfeuer:

=== Coverage ===
* [https://airlink.ubnt.com/ Ubiquiti Outdoor Wireless Link Calculator]: Brauchbares Tool auf Basis von Google-Maps (und deren Höhendaten). Berücksichtigt auch die Fresnel-Zone.
* [http://www.ve2dbe.com/english1.html RadioMobile]: Windows-Software für Funkamateure zur detaillierten Berechnung der Ausleuchtung. Gibt es wohl nun auch in einer [http://www.ve2dbe.com/rmonline.html Web-Version] (ungetestet).
* [http://www.solwise.co.uk/wireless-elevationtool.html Solwise]: Ein weiteres Online-Tool auf Basis der Google-Daten, das allerdings nur die Line-of-Sight ausgibt.
* [http://wisp.heywhatsthat.com heywhatisthat.com] Weiteres Online-Tool, das aber auch [http://www.heywhatsthat.com Panoramaprofile] rechnen kann. Damit findet man Linkpartner wieder.

Weiters interessant für das Befüllen von Tools könnten folgende Geodaten sein:

* [https://www.wien.gv.at/stadtentwicklung/stadtvermessung/geodaten/als/ Laserscan der Stadt Wien] mit 50 cm Auflösung.
* [https://www.wien.gv.at/stadtentwicklung/stadtvermessung/geodaten/dgm/daten.html Geländemodell der Stadt Wien] in verschiedenen Auflösungen.
* [http://data.ktn.gv.at/package/digitales-gelaendemodell-dgm-oesterreich/ Geländemodell Österreichs] auf Basis von Laserscans, 10 m Auflösung.