Benutzer:Leo/Blog:2019 May 11 19:59:49 CEST - Versionsgeschichte

MathiasMahnke: /* Techniktreffen (11.05.2019) */

2019-05-12T08:40:23Z

Techniktreffen (11.05.2019)

← Nächstältere Version		Version vom 12. Mai 2019, 08:40 Uhr
Zeile 3:		Zeile 3:
	Heute waren Tobias, Henning, Lars, Martin und Mathias in der [[Frieda23]] anzutreffen.		Heute waren Tobias, Henning, Lars, Martin und Mathias in der [[Frieda23]] anzutreffen.

	==== 60 GHz-Test ====		==== 60 GHz WLAN 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.		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.

MathiasMahnke: /* Server Boot-Analyse */

2019-05-12T07:15:18Z

Server Boot-Analyse

← Nächstältere Version		Version vom 12. Mai 2019, 07:15 Uhr
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.

MathiasMahnke: /* Boot-Analyse */

2019-05-12T07:14:17Z

Boot-Analyse

← Nächstältere Version		Version vom 12. Mai 2019, 07:14 Uhr
Zeile 8:		Zeile 8:
	Für den mobilen Knoten konnten wir uns dank eines tragbaren Akkus mit 12 V Ausgang auf der Headgehalbinsel in Rostock frei bewegen.		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 ====		==== 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 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.

MathiasMahnke am 12. Mai 2019 um 07:14 Uhr

2019-05-12T07:14:06Z

← Nächstältere Version		Version vom 12. Mai 2019, 07:14 Uhr
Zeile 14:		Zeile 14:

	==== Firmware-Upgrade von ryoko ====		==== 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.		Die Firmware-Aktualisierung auf Basis der DELL Patches des Virtualisierungsservers [[Server/ryoko\|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 [[Server/howmei\|howmei]] wieder auf die ursprünglichen Werte zurück gestellt werden.

	==== IPv6 und DNS ====		==== IPv6 und DNS ====

MathiasMahnke am 11. Mai 2019 um 20:46 Uhr

2019-05-11T20:46:16Z

← Nächstältere Version		Version vom 11. Mai 2019, 20:46 Uhr
Zeile 1:		Zeile 1:
	=== Techniktreffen (11.05.2019) ===		=== Techniktreffen (11.05.2019) ===

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

	==== 60 GHz-Test ====		==== 60 GHz-Test ====

MathiasMahnke am 11. Mai 2019 um 20:45 Uhr

2019-05-11T20:45:14Z

← Nächstältere Version		Version vom 11. Mai 2019, 20:45 Uhr
Zeile 2:		Zeile 2:

	==== 60 GHz-Test ====		==== 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.		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 ~~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 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. ~~Das~~ "Dell-Lifecycle"~~-Ding~~ mochte die erkannten Aktualisierung nicht ~~heruterladen~~.		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-Adressen der ~~APs~~ aufzulösen:		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~~-Nameserver~~.		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), steht die Automatisierung (also die nächtliche Aktualisierung) ~~allerdings~~ noch aus.		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 ~~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)~~.		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.

	==== ~~ondataservice~~ vs. ~~netjson~~====		==== on-dataservice 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.		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.

MathiasMahnke: /* Boot-Analyse */

2019-05-11T19:28:00Z

Boot-Analyse

← Nächstältere Version		Version vom 11. Mai 2019, 19:28 Uhr
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 ====

Leo: Techniktreffen (11.05.2019)

2019-05-11T18:03:28Z

Techniktreffen (11.05.2019)

Neue Seite

=== 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 Vorbeireitung 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:
<pre>
dig AAAA 1.23.aps.on
dig -x fd32:d8d3:87da:0:e894:f6ff:fe3f:69de
</pre>

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.