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

Aus Opennet
Wechseln zu: Navigation, Suche
(Techniktreffen (11.05.2019))
 
(Boot-Analyse)
Zeile 7: Zeile 7:
 
Derzeit können wir unsere Server nicht rebooten, da etwas in der Kombination von efi 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 Server nicht rebooten, da etwas in der Kombination von efi 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 Vorbeireitung 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 ====

Version vom 11. Mai 2019, 20:28 Uhr

Inhaltsverzeichnis

Techniktreffen (11.05.2019)

60 GHz-Test

Wir haben einen Reichweitentest mit zwei 60GHz (802.11ad) Geräten durchgeführt. Bei ca. 250m Sichtverbindung kamen wir an die Grenze einer zuverlässigen Verbindung. Danach brach die Verbindung immer abrupt ab. Bei 250m konnten wir noch ca. 90MBit/s mit iperf messen.

Boot-Analyse

Derzeit können wir unsere Server nicht rebooten, da etwas in der Kombination von efi 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. Das "Dell-Lifecycle"-Ding mochte die erkannten Aktualisierung nicht heruterladen.

IPv6 und DNS

Inzwischen ist es möglich, die IPv6-Adressen der APs 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-Nameserver.

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), steht die Automatisierung (also die nächtliche Aktualisierung) allerdings noch aus.

Somit können wir in Bälde die statische Host-Liste (für die IPv6/AP-Zuordnung) aus der Firmware entfernen. Technologisch sind wir im Bereich der IPv6-Adressen also nun beim Übergang von statischen Listen zu DNS-Abfragen (bei IPv4 wurde dies ca. 1983 erreicht).

ondataservice vs. netjson

Für die Inventarisierung werden derzeit mit OLSRv1 und dem ondataservices Plugin 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 ondataservice 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