Benutzer:Leo/Blog:2019 May 11 19:59:49 CEST: Unterschied zwischen den Versionen

Aus Opennet
Wechseln zu: Navigation, Suche
(Boot-Analyse)
(Server Boot-Analyse)
Zeile 9: Zeile 9:
  
 
==== Server Boot-Analyse ====
 
==== Server 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.
+
Derzeit können wir unsere Hardware Server nicht neu starten bzw. keine Kernel Aktualisierung durchführen , da etwas in der Kombination von UEFI und grub mit RAID und GPT 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.

Version vom 12. Mai 2019, 08:15 Uhr

Inhaltsverzeichnis

Techniktreffen (11.05.2019)

Heute waren Tobias, Henning, Lars, Martin und Mathias in der Frieda23 anzutreffen.

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.

Server Boot-Analyse

Derzeit können wir unsere Hardware Server nicht neu starten bzw. keine Kernel Aktualisierung durchführen , da etwas in der Kombination von UEFI und grub mit RAID und GPT 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 auf Basis der DELL Patches des Virtualisierungsservers ryoko 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.

Anschließend haben wir die offiziellen Intel Patches sowie Kernel Updates über Debian erfolgreich eingespielt. Die Performance des Servers ist nun wieder in einem guten Zustand. Entsprechend konnten die VM Ressourcen des Monitoring Servers howmei wieder auf die ursprünglichen Werte zurück gestellt werden.

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.

Meine Werkzeuge
Namensräume

Varianten
Aktionen
Start
Opennet
Kommunikation
Karten
Werkzeuge