Der faule Admin automatisiert: Gluon auf echter Hardware testen
This is a modal window.
Das Video konnte nicht geladen werden, da entweder ein Server- oder Netzwerkfehler auftrat oder das Format nicht unterstützt wird.
Formale Metadaten
| Titel |
| |
| Serientitel | ||
| Anzahl der Teile | 275 | |
| Autor | ||
| Lizenz | CC-Namensnennung 4.0 International: Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen. | |
| Identifikatoren | 10.5446/52361 (DOI) | |
| Herausgeber | ||
| Erscheinungsjahr | ||
| Sprache |
Inhaltliche Metadaten
| Fachgebiet | ||
| Genre | ||
| Abstract |
| |
| Schlagwörter |
rC3 - remote Chaos Experience191 / 275
7
8
9
10
11
13
14
19
20
22
24
27
35
37
38
42
43
47
48
52
53
55
56
57
60
61
62
65
67
69
77
80
82
84
86
87
88
90
92
96
97
100
101
102
107
108
109
112
114
116
117
119
121
122
126
128
129
132
134
136
137
140
142
143
145
146
148
149
150
151
152
153
154
157
159
161
162
163
164
165
166
167
168
169
177
179
180
181
186
188
192
193
194
195
198
200
201
208
209
211
212
213
214
215
219
220
221
222
223
226
232
234
235
236
237
240
242
243
244
246
247
248
249
251
254
255
259
260
264
265
266
267
270
272
275
00:00
HardwareFirmwareHardwareCASA <Programm>VariableVorlesung/Konferenz
01:01
HardwareRouterPOWER <Computerarchitektur>Open SourceLINUXNormalvektorRouterPhysikalische GrößeProject <Programm>Hub <Informatik>InternetTestbedEbeneHardwareSoftwaretestNumerisches GitterMomentenproblemKonfigurationsraumPerspektiveBerührung <Mathematik>GatewayDoppelreihePositionVirtuelle AdresseNotebook-ComputerScheibeNabel <Mathematik>Switch <Kommunikationstechnik>WahrscheinlichkeitsverteilungServerTreiber <Programm>Prozess <Physik>CodeStandardabweichungRollbewegungPlatteRALLY <Programm>WhiteboardPOWER <Computerarchitektur>Konfigurator <Softwaresystem>FirmwareSenderOrganic ComputingComputeranimation
10:57
Nabel <Mathematik>Treiber <Programm>Version <Informatik>Virtuelles privates NetzwerkClientFirmwareRepository <Informatik>RouterSoftwaretestVerschlingungGroße VereinheitlichungLINUXNormalvektorWeb logFirmwareInternetQuelle <Physik>HardwareVersion <Informatik>Treiber <Programm>SystemplattformMomentenproblemRepository <Informatik>ClientUngleichungNabel <Mathematik>Geometrischer KörperCodeLEAPAbstrakter SyntaxbaumPlug inUpdateARM <Computerarchitektur>Notebook-ComputerVirtuelles privates NetzwerkPOWER <Computerarchitektur>Endlicher AutomatFlächentheorieKonfigurationsraumotto <Programmiersprache>Hydrostatischer AntriebWebcamMotiv <Mathematik>ServerAnwendungssoftwareSocket-SchnittstelleSkriptspracheOrdnungsbegriff
20:52
MengeMagnetbandlaufwerkVerfügbarkeitFirmwareRouterHausdorff-RaumSoftwaretestNumerisches GitterKonfigurationsraumSoftwareBesprechung/Interview
Transkript: Deutsch(automatisch erzeugt)
00:16
Willkommen zu unserem ersten Talk. Das sind der Chrissy und der Kazaar. Beide sind vom
00:22
Freifunk Braunschweig. Seit 2014 sind sie dabei, also auch so lange seitdem es den Freifunk Braunschweig gibt. Seit drei Jahren testen sie auch ihre Firmware automatisiert. Das machen sie, weil sie auch ein bisschen an ihrer Firmware verändern. Und damit
00:42
können sie damit halt besser klarkommen. Versuchen sie automatisiert zu testen. Heute geht es primär um ihr Test Setup, weniger um die Veränderungen an der Firmware. Und ja, also dann jetzt der volle Admin automatisiert gluern auf echter Hardware testen.
01:02
Moin. Moin. Los geht's. Wie viele Freifunk Communities benutzen ja auch wir gluern und so ein Gluern Release, das ist ja getestet. Aber dieses Gluern Release ist ja nicht das, was man am Ende auf seine Community freilässt. Denn per Design hat so ein Gluern ja noch eine Site-Konfiguration, die dafür für jede Community draufkommt. Und viele Communities
01:23
haben dann noch irgendwelche Pakete oder anderen Änderungen, damit draufliegen. Zum Beispiel die Standardverortung oder die Standardort ihrer Knoten einzustellen im Konfigmodus. Und auch die Backends sind ja alle leicht unterschiedlich. Und so ein Gerät, also es gibt ja nicht nur ein Gerät, für das man so ein Gluern baut, sondern
01:43
es gibt da eine Handvoll, also eine sehr große Handvoll Geräte davon. Und das alles hat uns dazu bewegt zu sagen, naja, so ein Gluern Release mag getestet sein. Aber wir wollen mit unserer Konfiguration da ja nochmal drauf testen. Und insbesondere mit unserem Projekt Parker haben wir relativ viele Änderungen, die auch relativ tief
02:01
eingreifend in so einen Gluern eingreifen. Und das alles wollen wir natürlich testen und das natürlich automatisiert, denn wir sind ja faul. Ja, für uns hat sich vor drei Jahren mal die Gelegenheit ergeben, von unserer Stadt Braunschweig eine finanzielle Förderung zu bekommen und einen Teil, den wir uns fördern lassen, wollten, waren ein automatisiertes Testbed. Und wir haben
02:22
uns damals vier Ziele gesteckt für dieses Projekt. Und die möchte ich auch einmal kurz erzählen und wie weit wir da gekommen sind vielleicht auch. Das erste, was wir damals erreichen wollten, war, wir möchten eigentlich in der Lage sein, unsere frischen Freifunk-Firmware-Images, die wir gebaut haben, vor möglichst überall zu testen. Wir haben damals gemerkt, wenn man erst so ein Bild macht und da läuft noch ein paar Stunden, weil man echt viele
02:42
Images bauen muss und dann ist man irgendwann später erst wieder dran und kriegt die richtige Hardware in die Hände, um das auch zu testen, dann dauern die Release-Prozesse unnötig lange. Und deswegen möchten wir eigentlich Hardware haben, die irgendwo liegt und die wir von dort aus benutzen können, ohne dass wir erst die passende Hardware aus dem Schrank zaubern müssen dafür. Und das funktioniert halt auch zusammen mit
03:03
den Testen, das sehen wir später. Ein weiteres Ziel, was wir erreichen wollten, war, wir wollten eigentlich so kleine Freifunkt-Testbeds zu guten Freifunkern aus unserer Community verteilen, von denen wir wissen, dass sie Probleme mit im Internet haben. Zum Beispiel, weil das irgendein unsägliches DS-Lite ist oder weil es irgendwie ein Kabelnetz oder sowas
03:21
ist. Dann könnten wir halt sehen, wie sieht eigentlich aus deren Perspektive unser Freifunkt-Netz aus, aber das haben wir bisher noch nicht geschafft. Die Hardware ist noch da, das müssen wir zu gegebener Zeit mal angehen. Eine weitere Sache, die sehr gut funktioniert, ist automatisiertes Testen von Freifunkt-Images. Und zwar, wenn so ein Image aus unserem Bildprozess rausfällt, dann bringen wir das auf
03:43
unsere Testing-Infrastruktur, schmeißen die Tests an, warten 5-10 Minuten und dann haben wir einen Test-Result, wo wir dann sehen, naja, funktionieren die Dinge, die wir haben wollen eigentlich noch oder sind da Sachen kaputtgegangen. Das letzte Ziel ist, naja, für uns ist schon wichtig, dass Freifunkt als Community funktioniert, also sowohl auf der
04:02
Seite der Router, die wir aufstellen, aber auch auf der Entwicklungsseite. Und da möchten wir euch jetzt etwas davon zurückgeben und deswegen erzählen wir euch heute davon. Dann habt ihr einen Steinbruch, wo ihr vielleicht ein paar Sachen von euch verwenden könnt oder vielleicht wollt ihr das auch einfach so nachbauen, wie wir es haben und seid dann schon glücklich. Wenn man jetzt so Router fernsteuern möchte,
04:21
gibt es so ein paar, na, Probleme will ich nicht sagen, sagen wir Herausforderungen, die man lösen muss. Zum einen muss man halt irgendwie mit der Hardware interfacen, weil man möchte jetzt ja echte Hardware testen. Was heißt das? Na, in der Regel will man irgendwie an den serialen Anschluss von so einem Router ran, weil dann kann ich mit dem Router und auch mit dem Bootloader und auch mit dem
04:41
Linux auf dem Router reden. Und das kann ich auch dann, wenn ich mir ein kaputtes Image geflasht habe oder beim Testen doch mal irgendwas kaputt geht. Also ich brauch die Serial, dann kann ich load und fernsteuern. Dann möchte ich in der Lage sein, die Sturmversorgung für diesen Router zu schalten, weil dann kann ich den Router halt neu starten und komme auf jeden Fall definitiv wieder
05:00
in den Bootloader, ganz egal welchem Zustand ich sonst bin. Und ich möchte in der Lage sein, Knöpfe an so einem Router zu drücken, weil ja, mit gedruckten Knöpfen kann ich auch sowas wie einen Druck von Reset simulieren, mit dem ich dann zum Beispiel wieder in den Config Mode zurückwechseln kann, weil ich das dann später testen möchte.
05:21
Unsere Router haben State. Zum einen haben wir irgendwie so einen Configuration State, das heißt, unsere Router wissen mit welchen Gateways sie sich verbinden müssen. Sie wissen, welchen Namen sie haben und an welchen Positionen sie sind. Und sie haben auch solchen State wie VPN Keys, sei es jetzt für FastDio oder in unserem Fall häufig für WireGuard, aber das ist halt State, der auf den Routern permanent
05:41
drauf ist. Und zum anderen haben wir natürlich ein Runtime State, das heißt, unser Router befindet sich in einem Bootloader, befindet sich im Config Mode, also im Linux oder befindet sich im normalen Running Mode. Und all diesen State müssen wir halt auch mitmanagen. Unsere Router haben per Definition was mit Netzen zu tun, offensichtlich. Das heißt, auch darum müssen wir uns irgendwie darum
06:02
kümmern. Bei uns haben wir jetzt da im Moment einen sehr genaue Router, dazu später noch ein bisschen was. Und wir müssen irgendwie schauen, wie es eigentlich mit Testinginfrastruktur auf dem Target ist. Wir haben uns dafür ein ganz klares Nein entschieden. Wir möchten keine spezielle Testinginfrastruktur auf dem
06:22
Target haben, sondern wir möchten, dass all unsere Testinginfrastruktur außenrum ist. Und wenn wir auf dem Target irgendwas brauchen, dann müssen wir das im Test mitbringen, sodass wir mit einem Vanillagluon, was abgesehen von der Side-Konfiguration genau so aufgetappt liegt, halt auch schon testen können. Und damit haben wir auch die minimalste Beeinflussung, die wir mit dem Test erreichen können.
06:43
Wie sieht das Ganze dann im Hardware-Aufbau aus? Wir haben halt irgendwie einen Router, den wir testen wollen. Und ich habe jetzt hier schon wieder zum zweiten Mal den 841er gezeigt. Und ja, unser erstes Test-Bett, das wir aufgebaut haben, benutzt genauso einen Router. Warum? Zwei Gründe, bevor sich Leute die Zehennägel hochrollen.
07:02
Oder vielleicht auch trotzdem. Zum einen, man hat da von Kilogramm bei so rumliegen. Warum will man sie nicht verwenden? Wenn sie kaputt sind, man hat den nächsten. Man verliert da nicht viel mit. Und das andere ist, zumindest mit unserem Project Parker Freifunknetz, was auf WireGuard aufsetzt, funktionieren die Geräte noch ganz brauchbar. Und solange Gluon sie weiter
07:20
unterstützt, sehen wir gerade keinen Grund, sie loszuwerden. Also testen wir auf der kleinsten Hardware, die wir unterstützen wollen. Zu jedem Router gibt es einen Test-Server. Oder zu Ende Routern gibt es hier einen Test-Server an einem Ort. Das sind bei uns Raspberry Pis, weil die sind klein und billig. Und sie haben halt diese GPayOs dran, mit denen wir später noch Dinge schalten können.
07:41
Wir haben ein Labornetz, wo halt nur diese Geräte drin sind und in denen es Internet gibt, sodass unsere Router später auch unsere Infrastruktur erreichen können nach außen, wenn man testen will, ob sie auch online gehen können. Der Pi und unser Test-Server ist auch in diesem Lab-Netz drin, sodass er da auch erreichbar ist.
08:00
Unser Kleintnetz von unserem Router steckt mit einem USB-Ethernet-Dongle an unserem Test-Server, sodass wir dann auch klein auf unserem Router sein können. Und USB-Ethernet, weil so können wir dann auch mehrere mit Hubs quasi beliebig viele Router später an unseren Pi anschließen, was das Ganze skalierbar macht.
08:22
Wir haben als Power-Switch ein Vierfach-Relais-Board aus dem Maker-Zugehör vom Ebay. Da steckt man auf der einen Seite 5 Volt und so ein GPIO von einem Pi dran. Und auf der anderen Seite hat man halt ein recht potentes Relais, was Dinge schalten kann. Das benutzen wir zum einen, um einfach auf der 9 Volt Seite oder auf der 12 oder 48 Volt Seite
08:40
unseres Routers Spannungsversorgung zu schalten. Und zum anderen benutzen wir die auch, um die Taster zu überbrücken und können damit dann Tastendrücke simulieren. Und zu guter Letzt haben wir USB-Serial-Adapter, die auf der einen Seite im Router in die Serial angelötet sind und auf der anderen Seite per USB in unseren Pi stecken. Das wirkt jetzt hier alles so wunderschön aufgeräumt
09:00
auf dieser Folie und gradlinig. Der reale Aufbau ist natürlich wieder ein bisschen wirrer. Und wer sich jetzt denkt, man hat das eigentlich auf eine Holzplatte gespackst, ja, wir haben das auf eine Holzplatte geschraubt. Das war damals das Einfachste, was uns gerade entgegen kam und es hat sich bis heute gehalten, deswegen gab es keinen Grund, das zu ändern. Ihr seht unten den Router, mit dem wir testen,
09:21
ein Loch in den Deckel gebohrt, dass die Kabel rauskommen können. In der Ebene darüber sieht man rechts, glaube ich, das USB-Serial-Adapter, links USB-Ethernet, so ein bisschen hinter der Antenne versteckt. Oben rechts der Pi, oben links das Vierfach-Relais-Board, wo dann halt die Leitungen hingehen, die man mit diesen Relais schalten möchte.
09:42
Softwareseitig könnte man natürlich jetzt anfangen, sich irgendwie kleine Shell-Skripte oder Python-Snippets zu bauen, die mit der Hardware-Interface in die GPIOs schalten oder irgendwie auf das Serial-of-Input warten. Das ist aber irgendwie ganz schön anstrengend und das wäre irgendwie cooler, wenn man das abstrahiert hat. Und wir haben uns dann entschieden, das mit Labgrid zu machen. Labgrid ist eine Python-Library,
10:03
die dafür gedacht ist, Embedded Linux Fernsteuer-Hardware Das ist ein Open-Source-Projekt, findet man auf GitHub. Und wenn ihr mal einen Blick in die Dokumentation werfen wollt, die gibt es bei ReadTheDogs.io. Disclaimer, ich arbeite für die Firma, die große Teile davon gesponsert hat.
10:21
Das heißt, ich komme häufiger mit den Dingen in Berührung. Wie sieht das dann aus, wenn man sich das mal anguckt? Labgrid, wie gesagt, ist eine Hardware-Abstraction-Library, liegt also in der Mitte zwischen der Hardware, die man abstrahieren möchte, und in diesem Fall unsere Labor-Technik, also unsere Serial-Adapter.
10:41
Da hätte man im Labgrid nicht nur einen einzelnen Treiber, der weiß, wie man mit einem Serial spricht, das wäre noch langweilig. Labgrid hat auch Infrastruktur, um mehrere Serial-Adapter zu unterscheiden. Zum Beispiel anhand ihrer Seriennummer oder an einem USB-Port, an dem sie stecken. Und oben drauf gibt es dann Treiber, die wissen, wie man mit einem Bootloader spricht oder wie man mit einer Linux-Shell spricht, da Kommandos absetzt
11:01
und sich dann Return-Code und Ausgabe zurückholt. Es gibt Treiber für verschiedene Power-Switches, von irgendwie einem GPIO bis hin zu einer Server-Fernsteuer-Technik, wo viele Power-Sockets geschaltet in ein Gerät eingebaut sind. Man kann GPIOs auf verschiedenen Plattformen treiben,
11:21
und es gibt noch wesentlich mehr Treiber. Zum Beispiel, wenn man Switcher hat, die SNMP können, kann man gucken, an welchen Ports eigentlich welche IP-Adressen rausfallen. Aber da will ich hier gar nicht mehr darauf eingehen. Das schaffen wir sonst nicht. Nach oben gibt es jetzt drei Interfaces, mit denen man mit LabGris sprechen kann. Es gibt ein Command-Line-Interface. Das ist das, was man benutzt, wenn man interaktiv mit so einem Router arbeiten möchte.
11:42
Ich brauche mal kurz für eine Präsentation einen Screenshot von einem Router im Config-Modus. Dann flasche ich halt ein Firmware-Image und bringe den Router eben dahin. Das kann ich über Command-Line machen. Es ist aber auch ein Python-Library, das heißt, ich kann auch einfach gegen Skripten, wenn ich sowas habe wie, ich möchte gerne mal 1000 Mal einen Router starten,
12:00
weil ein Freifunker gemeldet hat, bei jedem 50. Mal funktioniert das irgendwie nicht. Und dann sind Sachen komisch, könnte man das Skripten, starte den Router einfach ganz häufig. Und wenn man den komischen Zustand erreicht hat, lässt man ihn da stehen. Und man guckt sich dann später an, was das Problem war. Das, worum es heute hauptsächlich geht, ist das PyTest-Plugin, dass man das halt ins PyTest integrieren kann.
12:24
LabGrid macht auch viel Vorbereitung schon dafür, dass wir mit dem State unseres Geräts zurechtkommen. Wenn wir uns mal anschauen, zumindest für den Runtime-State, so ein Gerät startet immer im Bootloader. Typischerweise ist einfach der Auto-Boot an, das heißt, nachdem der Bootloader gestartet ist, wartet er für einen ganz kurzen Moment
12:40
und lädt dann das Linux und springt das an. Aber es gibt halt Treiber, die wissen, wie man so einen Bootloader einfängt, den Auto-Boot unterbricht und dann halt Dinge tun kann. Und das kann man aus dem LabGrid fernsteuern und auch verfolgen. Es gibt in LabGrid einen Zustandsautomaten, das State Machine, das nennt sich da Strategy. Und die Strategy weiß, wie sie erkennt,
13:02
in welchem State sich gerade so ein Device Under Test befindet. Und hat auch Code, der einem von dem einen in den anderen State bringen kann. Sodass man halt auch kontrollieren kann, bin ich im Bootloader, möchte ich jetzt ein neues Image per TFTP flashen, solche Dinge. Wir haben dann halt PyTest.
13:21
Ich möchte mal kurz ein bisschen was zu PyTest erzählen, bevor wir da gleich nochmal einsteigen, wie wir das wirklich benutzen. PyTest ist ein Python-Testing-Framework. Das hört sich jetzt erst mal so an, als könnte man da mit super Python-Anwendungen testen. Das ist sicherlich auch richtig, aber es ist erst wesentlich generischer gebaut. Man kann damit halt im Wesentlichen alles testen. Es ist einfach Infrastruktur, um Tests zu bauen.
13:41
Und Labgrid bringt halt ein PyTest-Plugin mit, sodass man dann die Labgrid-Infrastruktur im PyTest benutzen kann, sodass man halt Tests schreiben kann, die echte Hardware oder ein echtes Linux auf einem anderen Gerät testen. Wie sieht so ein Test dann aus? Den würde ich mal kurz nochmal erklären, so ein bisschen Überblick zu verschaffen.
14:01
Generell benutzen wir halt offensichtlich PyTest in unserem Python-Code. Und im PyTest gibt es einen Konzept, das nennt sich Fixtures. Das ist im Wesentlichen eine Methode, die man später in seinen Tests benutzen kann, ganz intelligent. Und zwar macht die irgendwelche Vorbereitungen, um zum Beispiel in diesem Fall ein Gerät in einen Zustand zu bringen.
14:25
Die Strategy selber, die wir jetzt hier benutzen, ist auch eine Fixture, die uns halt das Labgrid zur Verfügung stellt. Und mit diesem Transition Shell sagen wir einfach, liebe Strategy, sorg dafür, dass dieser Router jetzt im Zustand Shell ist, also im gebooteten Linux. Das benutzen wir jetzt hier einfach in unserem Test.
14:40
Das heißt, wenn dieser Test irgendwann mal gestartet wird, also der Body dieser Funktion, dann sind wir auf jeden Fall in einer Linux-Shell und können dann Kommandos ausführen. Target ist eine weitere Fixture, die uns das Labgrid gibt, sodass wir dann auch mit dem kompletten Target interagieren können, mit allen Treibern, die dazugehören. Also dem Device an der Test und der Shell-Steiltechnik außen rum.
15:00
Wir holen uns jetzt einfach den Shell-Treiber, der über die Serial mit dem Gerät spricht, weil wir möchten ja mit der Serial reden. Und dann füllen wir darauf ein Kommando aus und holen uns den Rückgabewert, die std-out, und den Return Code. Und dann machen wir darauf noch ein paar Vergleiche. Und wenn das alles gut aussieht, dann war der Test erfolgreich.
15:20
Vielleicht, wenn irgendwas von dem fehl schlägt, dann war es das nicht. Das wäre jetzt hier sogar ein echter Testfall und auch eine wesentlichen vollständige Test-Suite, die man jetzt benutzen kann, wenn das Target das so hergibt. Aber Casar zeigt uns jetzt noch ein paar Details, wie reale Tests für Skloren aussehen. Genau, diese Infrastruktur, die kann man jetzt natürlich benutzen, um genau unsere Ziele zu erreichen, nämlich
15:42
Freifunk-Images zu testen, Teile der Infrastruktur und darüber auch zu testen. Dazu bilden wir in genau so einer Strategie den Flow, den so ein Gluon nimmt, erstmal ab, oder den so ein Router nimmt. Wir fangen nämlich mit dem Bootloader unten an.
16:02
Dann können wir den Router flashen, kommen in den Config-Modus, können diesen konfigurieren und können dann im normalen Betriebsmodus Tests darauf ausführen. Wenn wir einen Bootloader anfangen, sehe ich einen Test zum Beispiel so aus, der nimmt das Target und hat die Fixture in U-Boot, also sorgt das Lab-Grid dafür, dass wir im U-Boot sind
16:20
und kann dann mal den Command Version ausführen und einfach mal schauen, ist da alles in Ordnung, hat der Command funktioniert, ist der U-Boot ungefähr so, wie wir uns das vorstellen. Damit wir mit ausreichend Confidence in den nächsten Schritt gehen können, nämlich das Flashen, das ist jetzt kein Test, sondern das übernimmt die Strategy für uns, macht das über TFTP,
16:43
schreibt das an die richtigen Stellen, gibt die richtigen Commands ab und das sorgt dann am Ende dafür, dass der Router genau die Firmware geflasht hat, in unserem Fall diese Parkerpunktbin, die wir auch testen wollen, denn irgendwann müssen wir den Router mit der Firmware flashen, die wir haben wollen.
17:01
Dann wechseln wir in den Config-Mode, das übernimmt auch wieder die Strategy für uns, das sieht dann oben inGoodConfig und dieser Test jetzt zum Beispiel überprüft, ob unsere Default-Koordinaten, die wir hinterlegt haben, auch so im Config-Modus stehen. Um zu schauen, hat der Zyklus funktioniert, dass
17:21
Zeit-Config und unsere eigenen Änderungen alle auch in das Image eingeflossen sind. Da kann man jetzt natürlich noch mehr Tests machen, wir testen noch, ob der Zyklus funktioniert. Das kann man sich dann aber alles mal in den Quellen am Ende anschauen.
17:41
Dann konfigurieren wir diesen Router. Da tauschen wir vor allem den VPN-Key, damit die Infrastruktur nicht jedes Mal einen neuen Knoten sieht und wir immer denselben Knoten haben. Wir konfigurieren uns das Private-Wi-Fi-Paket, das wir übernommen haben, damit wir das hinterher überprüfen können, ob das alles funktioniert.
18:02
Wir nehmen noch ein, zwei andere Einstellungen vor, da legen wir dieses H-Key, damit wir das am Ende testen können. Dann kommen wir zum Hauptteil, zum Fleisch quasi. Unser Test ist der Test im Betrieb. Das ist jetzt ein Beispiel-Test, der eben genau diese Private-Wi-Fi-Config im
18:20
Running-Modus testet. Schaut nämlich einfach mal, gibt es diese Wi-Fi-ID, ist die jetzt in der IW-Config tatsächlich am Ende angekommen, wird die tatsächlich ausgestrahlt. Um da mal zu schauen, läuft da alles. Da kann man jetzt natürlich noch viel mehr Tests machen. Was wir schon haben, ist, dass die Infrastruktur einmal getestet wird.
18:41
Das geschaut wird, ob der DNS-Server funktioniert im Parker. Läuft auf jedem Knoten oder auf vielen Knoten auch noch ein DLCP-Server. Das wird alles überprüft. Wenn man sich dann überlegt, wie wir da noch weiter machen können, was wir auch in Zukunft noch machen werden, ist einmal Knoten ohne VPN, also die keinen eigenen Ablink haben, sondern gemesht werden. Die
19:02
müssen natürlich auch so getestet werden und dafür braucht man natürlich noch einen zusätzlichen Knoten, der in dagegen steht, von dem man weiß, dass der funktioniert, mit dem man meshen kann. Man kann einen Client simulieren, indem man zum Beispiel eine Container-Lösung seiner Wahl verwendet auf dem Test-Server und sich über eben genau das vorhin genannte Interface auf diesen Router
19:23
als Client einloggt. Wenn man mal schaut, bekomme ich eine IP-Adresse, funktioniert meine DNS-Auflösung, kann ich die in die Infrastruktur pingen, kann ich ins Internet pingen. Solche Dinge kann man dann auch mal testen. Und auch den Schritt des Firma-Updates. Also man schreibt im ersten Schritt eine
19:41
bekannte, eine bekannt gute Firmware auf diesen Router, konfiguriert den, testet es kurz durch und schreibt dann mit dem normalen Sys-Upgrade eine neue Firmware, die man gerade testen möchte, rein und kann dann die Tests noch mal durchführen, um zu schauen, funken die in die Migrationsfade, wie ist das mit bestehender Konfig, um da die Testabdeckung
20:03
noch mal zu erhöhen. Ja, wie fängt man an, wenn man das jetzt auch machen möchte? Wir haben die Tests in einem Repository auf unserem GitLab, also dem vom Stratum 0. Der Link ist jetzt angezeigt. Zum Lab-Grid noch mal der Link zur Dokumentation und auch zu einem Talk,
20:21
den Chrissy hier mal gegeben hat, wenn man sich da noch mehr mit befassen möchte, wenn nicht dieses Lab-Grid so funktioniert. Und ja, eine, in Klamotten fast, aktuelle Will-of-Material, die wir, das sind auch die Bilder, die wir gezeigt haben, die findet man uns im Stratum im Blog. Ja, damit würde ich sagen Happy Hacking.
20:41
Und wir haben jetzt noch ein gutes Stückchen Zeit übrig. Von daher stimmen wir jetzt für Fragen im Big Blue Button für euch zur Verfügung und dann freue ich mich da auf viele Diskussionen. Danke fürs Zuhören. Vielen Dank. Okay, das war ja jetzt relativ viel. Wir haben eine Frage aus dem IRC.
21:01
Da hat jemand gefragt, was eigentlich dieses Gluon ist. Könnt ihr uns das kurz erklären, oder? Ja, sehr gerne. Gluon ist die Firmware, auf der eigentlich viele Freifunknetze beruhen. Was viel an Freifunk ausgemacht hat, war ja die breite Verfügbarkeit von Geräten, die man einfach benutzen kann.
21:21
Und da hat Gluon einen sehr großen Teil zu beibetragen. Gluon basiert auf OpenBRT, was auch eine Firmware für mobile Router ist. Und ja, damit unterstützen wir eine riesige Menge an Geräten. Und jede Community baut sich sein eigenes Gluon. Also dieselbe Software, ein bisschen Konfiguration, unterschiedlich. Genau, das ist das, was das Rückgrat
21:40
von vielen Freifunknetzen ausmacht. Zumindest von den Geräten, die man sich zu Hause als Endnutzer hinstellt. Okay, danke für die Antwort. Danke, dass ihr euch die Zeit genommen habt und auch euch auch die Mühe gemacht habt, trotz dass ihr trotzdem nicht vor Ort da seid.
22:02
Wir haben uns selber einen Tag gefreut und ich hoffe, wir sehen jetzt jede Menge kleine automatisierte Test-Setups, die hier überall auf dem Boden schießen. Ja, das wird uns auf jeden Fall freuen. Wenn dazu noch Fragen sind, man findet uns noch im IRC an verschiedenen Stellen und auch in der 2D-Welt, wenn sie denn launcht.
22:23
Genau, sprecht uns gerne an. Ja, dann vielen Dank für eure Zeit. Und dann wünsche ich euch noch einen wunderschönen remote Congress. Danke schön, euch auch. Vielen Dank für die Mühe, vielen Dank für streamen.