Benutzer:Leo/Blog:2019 May 11 19:59:49 CEST: Unterschied zwischen den Versionen
(→Boot-Analyse) |
|||
| Zeile 2: | Zeile 2: | ||
==== 60 GHz-Test ==== | ==== 60 GHz-Test ==== | ||
| − | Wir haben einen Reichweitentest mit zwei | + | Wir haben einen Reichweitentest mit zwei [[MikroTik RouterBoard]] Geräten durchgeführt. Bei ca. 250 m Sichtverbindung kamen wir an die Grenze einer zuverlässigen Verbindung. Danach brach die Verbindung immer abrupt ab. Bei 250 m konnten wir noch ca. 90 MBit/s mit iperf messen. Bis 200 m war eine Verbindung mit 900 Mbit/s möglich. |
| + | |||
| + | Für den mobilen Knoten konnten wir uns dank eines tragbaren Akkus mit 12 V Ausgang auf der Headgehalbinsel in Rostock frei bewegen. | ||
==== Boot-Analyse ==== | ==== Boot-Analyse ==== | ||
| − | Derzeit können wir unsere Server nicht | + | Derzeit können wir unsere Server nicht neu starten, da etwas in der Kombination von UEFI und grub standardmäßig falsche Konfigurationsdateien erzeugt. Wir haben dies im Detail weiter angeschaut. Es gibt bald einen Bug-Report bei Debian dazu. |
Dabei konnten wir mit der IPMI-Schnittstelle via eingebundener virtueller Datenträger alles (inkl. Recovery mittels Debian-Image) aus der Ferne tun. Wir können nun also unbesorgt auch die anderen Virtualisierungsserver (aqua und tamago) mit ein wenig Vorbereitung aus der Ferne rebooten. | Dabei konnten wir mit der IPMI-Schnittstelle via eingebundener virtueller Datenträger alles (inkl. Recovery mittels Debian-Image) aus der Ferne tun. Wir können nun also unbesorgt auch die anderen Virtualisierungsserver (aqua und tamago) mit ein wenig Vorbereitung aus der Ferne rebooten. | ||
==== Firmware-Upgrade von ryoko ==== | ==== Firmware-Upgrade von ryoko ==== | ||
| − | Die Firmware-Aktualisierung des ryoko-Servers schlug leider fehl. | + | Die Firmware-Aktualisierung des ryoko-Servers schlug leider fehl. Der "Dell Lifecycle Controller" mochte die erkannten Aktualisierung nicht herunterladen. Die referenzierten Dateien lt. Repository Datei lagen nicht an der dort verzeichneten Stellen. Wir haben den Datenverkehr mitgeschnitten. Die Patches der Hardware konnten wir daher zunächst nicht durchführen. |
==== IPv6 und DNS ==== | ==== IPv6 und DNS ==== | ||
| − | Inzwischen ist es möglich, die IPv6 | + | Inzwischen ist es möglich, die IPv6 Adressen der Access Points aufzulösen: |
<pre> | <pre> | ||
dig AAAA 1.23.aps.on | dig AAAA 1.23.aps.on | ||
| Zeile 19: | Zeile 21: | ||
</pre> | </pre> | ||
| − | Dies funktioniert (aufgrund der privaten Domain und des privaten IP-Bereichs) natürlich nur über die Opennet | + | Dies funktioniert (aufgrund der privaten Domain und des privaten IP-Bereichs) natürlich nur über die Opennet Namensserver. |
Die notwendigen Daten (konkret: die Main-IPv6-Adresse) werden seit kurzem von der API eingesammelt. Über einen API-Abruf lassen sich somit fortan Zonen-Dateien erzeugen, die wir in unsere Nameserver einbinden. | Die notwendigen Daten (konkret: die Main-IPv6-Adresse) werden seit kurzem von der API eingesammelt. Über einen API-Abruf lassen sich somit fortan Zonen-Dateien erzeugen, die wir in unsere Nameserver einbinden. | ||
| − | Da auf unserem primären Nameserver (heartofgold) leider derzeit noch ein altes Debian-System läuft (der Umstieg ist fast | + | Da auf unserem primären Nameserver (heartofgold) leider derzeit noch ein altes Debian-System läuft (der Umstieg ist fast erledigt), steht die Automatisierung (also die nächtliche Aktualisierung) noch aus. |
| − | Somit können wir | + | Somit können wir bald die statische Liste für die IPv6 und AP-Zuordnung aus der Firmware entfernen. Technologisch sind wir im Bereich der IPv6-Adressen also nun beim Übergang von statischen Listen zu DNS-Abfragen. |
| − | ==== | + | ==== on-dataservice vs. NetJSON==== |
| − | Für die Inventarisierung werden derzeit mit OLSRv1 | + | Für die Inventarisierung werden derzeit mit OLSRv1 oder dem HTTP Abruf die on-dataservices Daten der APs eingesammelt. Es stand die Frage im Raum, ob wir diese Eigenentwicklung auf einen Standardmechanismen ändern wollen/können. Hierzu wurde sich [[NetJSON]] angeschaut. NetJSON scheint für Konfigurationsmanagement gut verwendbar zu sein. Hier gibt es auch Tools. Für unseren konkreten Fall gibt es jedoch nur wenig Mehrwert. Es gibt bei uns bereits eine JSON Datei, welche als Nachfolge von on-dataservice über OLSRv1 (Nameservice Plugin mit SQLite DB) existiert. Das Format zu ändern und auf einen Standard zu wechseln, hat nur wenig Mehrwert derzeit. |
Version vom 11. Mai 2019, 22:45 Uhr
Inhaltsverzeichnis |
Techniktreffen (11.05.2019)
60 GHz-Test
Wir haben einen Reichweitentest mit zwei MikroTik RouterBoard Geräten durchgeführt. Bei ca. 250 m Sichtverbindung kamen wir an die Grenze einer zuverlässigen Verbindung. Danach brach die Verbindung immer abrupt ab. Bei 250 m konnten wir noch ca. 90 MBit/s mit iperf messen. Bis 200 m war eine Verbindung mit 900 Mbit/s möglich.
Für den mobilen Knoten konnten wir uns dank eines tragbaren Akkus mit 12 V Ausgang auf der Headgehalbinsel in Rostock frei bewegen.
Boot-Analyse
Derzeit können wir unsere Server nicht neu starten, da etwas in der Kombination von UEFI und grub standardmäßig falsche Konfigurationsdateien erzeugt. Wir haben dies im Detail weiter angeschaut. Es gibt bald einen Bug-Report bei Debian dazu.
Dabei konnten wir mit der IPMI-Schnittstelle via eingebundener virtueller Datenträger alles (inkl. Recovery mittels Debian-Image) aus der Ferne tun. Wir können nun also unbesorgt auch die anderen Virtualisierungsserver (aqua und tamago) mit ein wenig Vorbereitung aus der Ferne rebooten.
Firmware-Upgrade von ryoko
Die Firmware-Aktualisierung des ryoko-Servers schlug leider fehl. Der "Dell Lifecycle Controller" mochte die erkannten Aktualisierung nicht herunterladen. Die referenzierten Dateien lt. Repository Datei lagen nicht an der dort verzeichneten Stellen. Wir haben den Datenverkehr mitgeschnitten. Die Patches der Hardware konnten wir daher zunächst nicht durchführen.
IPv6 und DNS
Inzwischen ist es möglich, die IPv6 Adressen der Access Points aufzulösen:
dig AAAA 1.23.aps.on dig -x fd32:d8d3:87da:0:e894:f6ff:fe3f:69de
Dies funktioniert (aufgrund der privaten Domain und des privaten IP-Bereichs) natürlich nur über die Opennet Namensserver.
Die notwendigen Daten (konkret: die Main-IPv6-Adresse) werden seit kurzem von der API eingesammelt. Über einen API-Abruf lassen sich somit fortan Zonen-Dateien erzeugen, die wir in unsere Nameserver einbinden.
Da auf unserem primären Nameserver (heartofgold) leider derzeit noch ein altes Debian-System läuft (der Umstieg ist fast erledigt), steht die Automatisierung (also die nächtliche Aktualisierung) noch aus.
Somit können wir bald die statische Liste für die IPv6 und AP-Zuordnung aus der Firmware entfernen. Technologisch sind wir im Bereich der IPv6-Adressen also nun beim Übergang von statischen Listen zu DNS-Abfragen.
on-dataservice vs. NetJSON
Für die Inventarisierung werden derzeit mit OLSRv1 oder dem HTTP Abruf die on-dataservices Daten der APs eingesammelt. Es stand die Frage im Raum, ob wir diese Eigenentwicklung auf einen Standardmechanismen ändern wollen/können. Hierzu wurde sich NetJSON angeschaut. NetJSON scheint für Konfigurationsmanagement gut verwendbar zu sein. Hier gibt es auch Tools. Für unseren konkreten Fall gibt es jedoch nur wenig Mehrwert. Es gibt bei uns bereits eine JSON Datei, welche als Nachfolge von on-dataservice über OLSRv1 (Nameservice Plugin mit SQLite DB) existiert. Das Format zu ändern und auf einen Standard zu wechseln, hat nur wenig Mehrwert derzeit.
