Docker

[fda77]

Fortsetzung von https://github.com/Freetz-NG/freetz-ng/issues/468#issuecomment-1047184629

[pfichtner]

Ich fang mal an Themen zu sammeln 😄

Wo man u.U. Docker einsetzen kann:

• Bau von Freetz-NG Images via Docker Container (lokal, eigener CI-Server, Cloud-CI-Server, Cloud) @PeterPawn ja, geht alles problemlos, geht "sogar" auf github und das auch kostenlos, zumindest das u.U. nicht zu viele Leute an die große Glocke hängen bzw. tun, denn so ein Build benötigt ja durchaus temporär nicht unerheblich Plattenplatz und auch nicht ganz unerheblich CPU-Zeit
• Bau der Freetz-NG host tools via github action, z.B. durch trigger, wenn sich Verzeichnisinhalte ändern
• Bei push getriggerte builds, die bestimmte images (verschiedene .configs) bauen um zu verifizieren, ob der push "ok" war

Wer unbedingt in einer VM bauen will (oder muss) kann natürlich dazu in der VM dann auch docker nutzen statt die ganzen Abhängigkeiten wieder händisch nachzuinstallieren. Und natürlich kann man auch VMs gescriptet bauen, z.B. mit Unterstützung von vagrant/packer und Provisionierungstools wie ansible, chef, puppet, saltstack, cfengine, etc.

Weitere Ideen und jegliche Diskussion willkommen

[pfichtner]

Und Docker ist für mich wie Tempo oder Nutella, @PeterPawn ich meinte eigentlich allgemein Containervirtualisierung bzw. OCI

[fda77]

Um die Tools zu bauen wäre das ganz praktisch. Der Bau ohne Downloads dauert nur ein paar Minuten, da da aber öfter mal was geändert wird wäre es ganz nett wenn das komplett automatisch funktionieren würde.
Optimal wäre wenn per GIT dann auch noch

• Die Datei nach https://github.com/Freetz-NG/dl-mirror committet würde
• und die Checksumme und Version angepasst würde
  Das ganz könnte aber viel Auswand sein. Falls man zu etwas neuerem als Ubuntu 14 wechselt, könnte es sein bei manchen mit alten Systemen nicht mehr läuft, es gibt immer jemanden

Dann gibt es noch die 25 Toolchains: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/dl-toolchains_make
Jede braucht bei mir um die 20 Minuten. So oft werden die aber nicht aktualisiert, zb bei Config- oder Versions-Änderungen der uclib
Dafür verwende ich die gleich Ubuntu14 VM: 3GB ram, 18GB hdd, viele Cores. Das könnte man auf irgend einen schnellen Cloud-Dingens auslagern

Tests: Es gibt so viele unterschiedliche Kombinationen von Konfigurationen, die kann man gar nicht alle testen. Aktuell kann man in Freetz 296 verschiede AVM-Images auswählen. Und dazu die ganzen Packages die sich teilweise gegenseitig beeinflussen, oder verschieden Versionen von openssl usw. Und dann weiss man noch nicht mal ob so ein Image wirklich funktionieren würde

Ein DockerContainer zum Erstellen von eigenen Images find ich auch gut, bei dem alles funktioniert und das alle https://freetz-ng.github.io/freetz-ng/PREREQUISITES.html hat. Du hast ja schon sowas (müsste ich mal ausprobieren...). Das würde auch solchen Dingen vorbeugen wie dass beim aktuellen Ubuntu "ldconfig" nicht mehr im PATH ist. Den kann man dann ausführen wo man will.

[pfichtner]

Um die Tools zu bauen wäre das ganz praktisch. Der Bau ohne Downloads dauert nur ein paar Minuten, da da aber öfter mal was geändert wird wäre es ganz nett wenn das komplett automatisch funktionieren würde. Optimal wäre wenn per GIT dann auch noch

Das Triggern des Build funktioniert auf meinem fork schonmal problemlos, d.h. wenn sich beim push unterhalb von toolchain etwas ändert wird in einem container gebaut.

* Die Datei nach https://github.com/Freetz-NG/dl-mirror committet würde

Das ist kein Problem

* und die Checksumme und Version angepasst würde
  Das ganz könnte aber viel Auswand sein. Falls man zu etwas neuerem als Ubuntu 14 wechselt, könnte es sein bei manchen mit alten Systemen nicht mehr läuft, es gibt immer jemanden

Klingt nach ein wenig sed Zauber o.ä. den man dann noch ausführen müsste

[pfichtner]

* Die Datei nach https://github.com/Freetz-NG/dl-mirror committet würde

Das ist kein Problem

Falls noch ein manuelles "ok" gewünscht sein sollte, wäre auch das automatische bauen mit automatischem Erstellen eines PRs im dl-mirror eine nette Möglichkeit (zumindest für den Anfang wahrscheinlich sogar wünschenswert und am Ende vielleicht sogar ganz ausreichend)

[pfichtner]

Dafür verwende ich die gleich Ubuntu14 VM: 3GB ram, 18GB hdd, viele Cores. Das könnte man auf irgend einen schnellen Cloud-Dingens auslagern

Bei den kostenlosen Angeboten wirst Du bei ähnlichen Buildzeiten landen als bei einem durschnittlichen Server bei Dir unter Deinem Schreibtisch, Bei den Toolchains ist ja die Buildzeit vermutlich auch gar nicht so entscheidend/wichtig. Und wenn es deutlich schneller gehen soll wirst Du vermutlich nicht sonderlich von schnelleren CPUs profitieren sondern wenn nur über Skalierung via cores, also stärkere Parallelisierung im build.

@fda77 4 Stunden 20 Minuten hat das Bauen der Toolchain auf der github kostenlos Variante beansprucht, ich vermute arg viel schneller wird es in der genannten VM auch nicht sei, oder? Und keine Ahnung wie schnell es ginge, wenn man bei AWS oder Co. eine fette Kiste/fettes Cluster dafür nutzt.

[pfichtner]

@fda77 4 Stunden 20 Minuten hat das Bauen der Toolchain auf der github kostenlos Variante beansprucht, ich vermute arg viel schneller wird es in der genannten VM auch nicht sei, oder? Und keine Ahnung wie schnell es ginge, wenn man bei AWS oder Co. eine fette Kiste/fettes Cluster dafür nutzt.

Habe auch mal noch nen job für die hosttools aufgesetzt, die brauchen 10 Minuten. Habe beide jobs jetzt so zusammengestellt, dass sie automatisch github releases erzeugen.

[pfichtner]

Der Einfachheit halber, baue ich derzeit mit dem Ubuntu20 basierten Image, um zu wissen, dass es überhaupt geht wie angedacht. Ubuntu Version und/oder Distribution müsste dann noch angepasst werden.

[fda77]

Ich möchte gar nicht wissen ob alle Pakete für eine Box baubar sind, da gibt es bestimmt einige die nicht mehr funktionieren, die aber auch niemand mehr nutzt :)
Die Hashes gibt tools/dl-toolchains_eval schon aus, aber das ist nur semi-automatisch

4 Stunden 20 Minuten hat das Bauen der Toolchain auf der github kostenlos Variante beansprucht,

Wenn du unverändert tools/dl-toolchains_make ausgeführt hast wurden so 10 Stück gebaut, das ist grob 1 Stunde langsamer als mein 9 Jahr alter Server.
Man hätte aber keine lokalen Stromkosten.

Wenn man statt Ubuntu 14 auf 20 setzen würde, könnte es aber bei einigen "aktuellen" Distributionen Problem geben, ich denke da an Debian die oft Jahre hinterherhinken. Für Ubuntu 14 müsste man aber manuell ein paar Programme aktualisieren (prerequisites)

Daher bin ich nicht so sicher wie man das am besten ändern sollte, wenn man es ändert. Ich hab noch keine Zeit gefunden mir Docker selbst anzuschauen

[pfichtner]

Kannst Du hier sehen, ist ja public https://github.com/pfichtner/freetz-ng/releases
Vollautomatisiert, sobald sich was unterhalb von toolchain ändert wird gebaut und als relase veröffentlicht.
Buildzeiten würden sich vermutlich noch ordentlich optimieren lassen, momentan wird ja alles sequentiell gebaut, das könnte man ja massiv parallelisieren.

[fda77]

Allein die Idee die tool automatisch bauen zu lassen ist prima, denn durch 8cb5a2e sind die schon wieder veraltet.
Es stellt sich nur die Frage wie sehr man Github vertraut, dass da in die binaries nicht irgend ein Unsinn hinein kommt. Es muss ja nicht von Github selbst erfolgen, sondern zB durch einen Hack. Dann werden die veränderten Binaries bei jedem ausgeführt

[pfichtner]

Prinzipiell sollten zwei Dinge getrennt werden:

• Ob man Docker zum Bauen nutzt (das halte ich mal für ziemlich sinnig) und
• wo das ganze dann gebaut wird

Github bietet prinzipiell mal die Möglichkeit, Dinge bei Änderungen auszulösen und bieten mittlerweile auch die Möglichkeit direkt auf Github zu bauen. Das lässt sich aber via Webhooks auch auf beliebigen anderen Umgebungen ausführen. Dabei hast Du dann aber immer zwangsläufig das Vetrauensverhältnis, dass derjenige der woanders gebaute Binaries verwendest, immer automatisch der Buildumgebung vertrauen muss, dass diese integer ist. Dabei ist es natürlich egal, ob das Github, ein anderer CI-Server, das in der Cloud gehostetetes Linux-System oder der Server zu Hause unter dem Schreibtisch ist.

[pfichtner]

toolchains sowie hosttools build läuft jetzt automatisiert auf Basis des ubuntu 14.04 images.

Folgende Dinge musste ich ändern

• Abgelaufene Zertifikate entfernen da sich sonst wget und Co. verweigern
• Die Prüfung auf die make version entfernen, da ubuntu 14.04 make 3.81 beinhaltet, aber 3.81 gefordert wird. Es sieht so aus, als ob make 3.81 hierfür ausreichend ist

[pfichtner]

Ich habe mal beschrieben wie man auf jedem beliebigem Linux (besser gesagt auf jedem System auf welchem Docker verfügbar ist [1]) ohne irgendwelche Vorbedingungen erfüllen zu müssen, Freetz(-NG) Images bauen kann und dazu auch Screencasts erstellt: https://github.com/pfichtner/pfichtner-freetz
Dort sieht man auch, dass das alle Dateien ganz normal auf dem Hostsystem liegen während der menuconfig, make und co. dann im container laufen.

[1] Das Image habe ich z.Z. "nur" für x86 gebaut und würde das auch dabei belassen bis nicht jemand andere Anforderungen hat

[fda77]

Danke, teste ich mal. x86 würde ich ignorieren, viele neue Distributinen haben nur noch 64bit, die precompiled Pakete sind auch 64bit

[fda77]

Ein erster Versuch mit den actions: 78e3648

[pfichtner]

Was meinst Du mit "erster Versuch"? Das pushen ins repo?
#475 (reply in thread) und
#475 (reply in thread) hattest Du gesehen/angeschaut?

[fda77]

Ja hab ich. Wollte aber klein mit dem Script anfangen

[pfichtner]

Alles klar, bestens! Du kannst beliebig viele actions nutzen, ich empfehle, für jede Aufgabe eine eigene action anzulegen.
Falls Du den nächsten Schritt/etwas mit dem was ich gemacht habe weitermachen/übernehmen willst: Bediene Dich bzw. sag Bescheid wie es weiter gehen soll.

[fda77]

Ich weiss aktuell noch nicht was man noch sinnvolles machen könnte.
Würdest du es nicht auch zu unsicher finden die tools (oder gar toolchains) remote bauen lassen?
Einen Docker-Container um selbst Freetz zu bauen überlass ich lieber dir :)

[fda77]

Das Updaten der docs/ scheint gut zu funktionieren. Nur blöd dass man immer git installieren muss, dadurch ist die Laufzeit viel größer

[pfichtner]

Würdest du es nicht auch zu unsicher finden die tools (oder gar toolchains) remote bauen lassen?
Gut ist auf jeden Fall die Frage von ob Docker/VM/bare metal davon zu trennen, wo dies dann liegt.

Ob ich es unsicher finde, ist wirklich ein schwierige Frage, der Angriffsvektor ist definitiv größer, als bei irgendjemandem auf dem Rechner unterm Schreibtisch. Solange Bedenken bestehen (und die sind ja nicht unbegründet) würde ich das ganze nicht in "die cloud" auslagern wollen. Was aber sicher gut wäre ist, dass das ganze mit "infrastructure as code" für Dich und jeden anderen reproduzierbar baubar wäre, also eben nicht von Deiner VM abhängt und Du auch nicht die Gefahr bei Dir liegen hast, dass Du die VM backupen musst da es beim Verlust sonst schiwerig wird. Von daher fände ich es gut, wenn Du das ganze weiterhin baust, aber eben in einer für jedermann reproduzierbaren Umgebung (da bietet sich natürlich docker primär an, alles andere wie Provisonierungswerkeuge gehen auch, sind aber deutlich schwergewichtiger). Das andere, ob man doch mal wo anders baut ist dann eine offene, nachgelagerte Überlegung die man irgendwann bzw. jederzeit bei Bedarf später diskutieren kann.

Einen Docker-Container um selbst Freetz zu bauen überlass ich lieber dir :)

Klar, das meinte ich auch gar nicht, ich meinte eher, dass Du Dich bei dem was ich an github actions für hosttools/toolchain bedienen kannst.

[pfichtner]

Das Updaten der docs/ scheint gut zu funktionieren. Nur blöd dass man immer git installieren muss, dadurch ist die Laufzeit viel größer

Bei Dingen die ich nicht händisch machen muss sind mir die Laufzeiten eigentlich egal, also wenn z.B. der Automat drei Minuten braucht ich aber jedesmal eine Minute händische Arbeit spare. Und es ist ja auch nichts zeitkritisches, es ist doch egal, ob sie docs ein oder zwei Minuten später aktualisiert wurden. Ich bin da auch immer froh, dass ich an diese Dinge nicht denken muss, dass diese eben automatisch geschehen und ich eine Mail kriege, wenn etwas nicht klappt.

Falls man das ganze optimieren will, kann man natürlich statt eines blanken ubuntus ein Image nutzen bei welchem git bereits installiert ist, z.B. das, mit meinem freetz-image mit welchem ich freetz baue.

[pfichtner]

Scheint als wären Docker, Github Actions und Du @fda77 neue, beste Freunde geworden 😆

[fda77]

Ich hab noch nie docker genutzt oder installiert gehabt :D

Die precompiled Dinge sind nicht von meiner VM abhängig, man brauch eine ein Linux das Freetz compilierne kann, und prerequisites. Ich nutze Ubuntu 14 x64 damit es überall läuft. Wenn man was neuere nimmt wird wieder irgend jemand sich beschweren. https://freetz-ng.github.io/freetz-ng/PREREQUISITES.html#ubuntu ist auch aktuell, die 4 zusätzlichen Pakete muss man halt manuell aktualisieren, und nciht wie du die Abfrage entfernen ;-) Manche Fritzboxen (glaube kernel) brauchen die neuere Version! Und dann ruft man die tools/dl-* script auf.
Meine VM will ich aber nicht veröffentlichen, da ist die lokale Netzwerk-config, Freigaben und Passwörter usw drin. So genau weiss ich das nicht mehr, ich hab nicht darauf geachtet

egal, ob sie docs ein oder zwei Minuten später aktualisiert wurden

Die aktuellen actions könnten Fehlschlagen wenn in der Zwischenzeit ein Commit kommt der inkompatible ist. Die docs werden dann einfach beim nächsten mal aktualisiert, das ist nicht so schlimm

Falls man das ganze optimieren will, kann man natürlich statt eines blanken ubuntus ein Image nutzen bei welchem git bereits installiert ist, z.B. das, mit meinem freetz-image mit welchem ich freetz baue.

Geht das mit github? Aber eigentlich finde ich ein relativ leeres System ganz gut, dann vergisst man nicht was man installieren muss...

[pfichtner]

Eigentlich hab ich die actions wie Shell-Scripte genutzt. Man muss nur ein paar Eigenarten von Github und Variablen-Handling kennen vagrant, ansible, ... von diesen hab ich noch nie gehört :) Laufzeit optimieren: Da gibts eigentlich nur das "docs".

Da bleibt nur noch "docs": 30 sec Vorbereitung und 20 sec fürs generieren selbst. Und für diese halbe Minute lohnt es sich für mich nicht diese ganzen docker dinge anzuschauen.

Glaube auch, dass sich das kaum rentiert, habe es aber ja trotzdem mal umgesetzt, links dazu siehe ganz zum Schluß.

Was ich aber gener optimieren würde: Die new+old dl-toolchains sind bis auf 2 Zeilen identisch. Kann man in diesen .yml-actions Dateien includen/sourcen?

yaml selbst unterstützt das nicht. GHA unterstützt das wohl auch nicht wirklich, was ich dazu gefunden habe ist https://docs.github.com/en/actions/using-workflows/reusing-workflows und https://github.com/mithro/actions-includes

Das mit dem Ubuntu 14 container muss ich mir anschauen/ausprobieren, dazu kann ich nichts sagen. Ich hab davan gar keine Ahnung!!

So sieht dann die Benutzung des gebauten Images aus, in dem dann alles notwendige, wie erwähnt, bereits inkludiert ist:
https://github.com/pfichtner/freetz-toolchain-docker-userdemo/blob/main/.github/workflows/showcase.yml
https://github.com/pfichtner/freetz-toolchain-docker-userdemo/actions (siehe Ausgaben)

[fda77]

Dieses include verursacht mehr Aufwand als die Datei einfach zu kopieren und 2 Zeilen auszutauschen :)

Das Image spart jedenfalls einiges an Zeit. Man könnte die Sprache noch auf utf/en oder de umstellen, umask in der profile einstellen, einen user anlegen usw... Nur wie hast du diese Dinge da hineinbekommen? Mit einem lokalen Docker? Das du dann da hochgeladen hast? Ich kann das image: ghcr.io/pfichtner/freetz-toolchain-docker:main nicht benutzen.

[pfichtner]

Dieses include verursacht mehr Aufwand als die Datei einfach zu kopieren und 2 Zeilen auszutauschen :)

Das Image spart jedenfalls einiges an Zeit. Man könnte die Sprache noch auf utf/en oder de umstellen, umask in der profile einstellen, einen user anlegen usw... Nur wie hast du diese Dinge da hineinbekommen? Mit einem lokalen Docker? Das du dann da hochgeladen hast? Ich kann das image: ghcr.io/pfichtner/freetz-toolchain-docker:main nicht benutzen.

umask, user etc. ist da alles drin, wie in https://github.com/pfichtner/pfichtner-freetz auch, siehe https://github.com/pfichtner/pfichtner-freetz/blob/main/entrypoint.sh

image: ghcr.io/pfichtner/freetz-toolchain-docker:main gehört zur Organisation "pfichtner" und derzeit nur für diese "Organisation" nutzbar, siehe mein Kommenar gestern

[pfichtner]

Nur wie hast du diese Dinge da hineinbekommen? Mit einem lokalen Docker? Das du dann da hochgeladen hast? Ich kann das image: ghcr.io/pfichtner/freetz-toolchain-docker:main nicht benutzen.

Stinknormales Dockerfile, wird auch via GHA gebaut, siehe https://github.com/pfichtner/freetz-toolchain-docker

[pfichtner]

Ich kann das image: ghcr.io/pfichtner/freetz-toolchain-docker:main nicht benutzen.

Man könnte das Image auch in der ghcr public machen, FALLS es public sein sollte würde ich es aber, wie im Kommentar gestern geschrieben, eher nach dockerhub pushen wollen

[fda77]

Ob man die Binaries von github verwenden sollte ist so ne Sache... funktionieren würde es. Ich müsste jedenfalls nicht immer eine alte VM anwerfen müssen und selbst bauen, sondern nur ein klick auf die Action...

Die tools hab ich hier getestet (repo wird später gelöscht): https://github.com/fda77/freetz-ng/runs/6115431760?check_suite_focus=true , auch das automatisch aktualiseren klappt: https://github.com/fda77/freetz-ng/commit/1a93594d306d712cbef81a3fba95dcf2884fee8c und https://github.com/fda77/freetz-ng/releases
Blöd find ich dass zu jeden release ein Tag generiert werden muss

Die Toolchains musste ich teilen, alle 25 brauchen ~8h und Github limitiert die Laufzeit auf exakt 6h -.-
Wegen c94cb42 sollte man die Toolchains aktualisieren, da durch falsche Pfade (vom build System der binaries) libs wie die libatomic nicht gefunden werden.
Automatisch aktualisieren hab ich nicht eingebaut, nur https://github.com/Freetz-NG/freetz-ng/runs/6108293032?check_suite_focus=true#step:15:7

Eigene freetz-images bauen geht auch, die .config importiert man am besten von einem geheimem Server: https://github.com/Freetz-NG/freetz-ng/blob/master/.github/workflows/make_freetz.yml_#L55= Und man sollte das ganze in einem privaten Repo machen

[pfichtner]

Eigene freetz-images bauen geht auch, die .config importiert man am besten von einem geheimem Server: https://github.com/Freetz-NG/freetz-ng/blob/master/.github/workflows/make_freetz.yml_#L55= Und man sollte das ganze in einem privaten Repo machen

Ja, das habe ich via gha auf Basis meines https://github.com/pfichtner/freetz-docker Images ja bereits gemacht. Das geht natürlich auch mit jedem anderen Basis Image, nur dass man da die Dinge noch nachinstallieren muss, die ich eben bereits in mein Image gepackt habe (sprich die Dinge die in den prerequisites aufgeführt sind).
Die .config in das repo direkt zu legen habe ich keine Schmerzen, was erachtest Du da als kritisch als dass Du die von einem anderen Server ziehst?

[fda77]

Es ging mir nicht darum die .config zu verstecken, sondern sie dynamisch zu ändern ohne etwas commiten zu müssen. Wenn man geforkt hat muss man nur die URL in den github-secrets anlegen. Deshlab habe ich den Tag-namen auch abhängig von der ausgewählten Box gemacht. Ich experimentiere da aber noch. Das geheimste in der .config ist das Passwort der signatur-keys, wobei das in 99% "freetz" sein sollte. Die signaturkeys selbst würde ich aber nicht commiten wollen

[pfichtner]

Ich glaube ich habe jetzt verstanden was Du meinst, ich würde das grundsätzlich anders machen: Wieso forken? Ich habe ein PoC (privates Projekt), da habe ich meine (eine x-beliebige Beispiel)-Config drin liegen. Das Projekt ist kein fork. Ein Projekt mit der .config, sonst nix. Sonst nix? Nicht ganz richtig: Natürlich noch der github-workflow in dem drin steht, dass ein build im Container mit "meinem" freetz-docker Image durchgeführt werden soll. Ich würde aber nie ein Projekt forken, weil ich bei mir einen gleichen/ähnlichen workflos haben möchte wie im geforkten Projekt (egal ob es sich um eine oder 1000 Zeilen handelt).
Sollte in der .config was drin sein was ich nicht öffentlich haben will, dann kann ich das Projekt private machen oder die keys als secrets ablegen und beim build dann in die .config einsetzen.

[fda77]

Aber es bleibt die grundsätzliche Frage zu den Ubuntu14 Actions: Sollen binaries von Github in Freetz verwendet werden? Diese werden auf den Computer während "make" ausgeführt.
Ob der Ami aus Heimatschutzgründen was einschleust oder der Russe Github hackt ist schlussendlich einerlei...
Dagegen wäre es andererseits sehr komfortabel

• Ich bin dazu noch unentschlossen
• Ich hab hippie gefragt, er tendiert leicht zu nicht-github
• du?

Wäre auch hier gut wenn es noch mehr Meinungen geben würde...

[pfichtner]

Es kommt drauf an, vor was man sich schützen will: Bei den von Dir genannten Gründen (jemand "hackt" Github, sprich: privilege escalation), dann besteht nicht nur die Gefahr dass binaries sondern auch alles andere ver-/geändert werden könnte, also Sourcen, Skripte etc. und zwar natürlich auch "an git vorbei". Wenn man sich davor schützen will, dann dürfen die Sourcen/Binaries/Skripte nirgendwo öffentlich abgelegt werden, das gilt/galt natürlich nicht nur für Github sondern generell git und alle anderen Versionsverwaltungssysteme, darutner subversion und CVS.
Verändert jemand die Binaries, sind diese sobald Du neuere Versionen hochlädst, wie sauber, wohingegen, sollte jemand Skripte (dazu zähle ich auch die GHAs) verändern auch neue gebaute Binaries korrumpiert wären.
Ebenfalls möglich wäre, Schadcode in die in den GHAs verwendeten Basisimages zu schleusen, welche dafür sorgen, dass in diesen Containern gebaute Binaries Schadcode enthalten (den Punkt können wir aber wahrscheinlich als derart unwahrscheinlich gleich vom Tisch fegen, da es sehr unwahrscheinlich ist, dass jemand derartigen allgemein funktionierenden Schadcode in dockerhub einschleust. Wenn dort Schadcode eingeschleust würde, würde der eher bei der Ausführung github selbst angreifen und nicht Binaries in einem ihm unbekannten Buildsystem verändern).
Weiterhin ist noch die Gefahr, dass die GHAs bestimmte Privilegien haben (z.B. Hochladen der gebauten Binaries) welche ergaunert und missbraucht werden können, was u.U. nicht eben nur das Austauschen/Verändern von Binaries/Sourcen sondern auch weitere Supply-Chain-Angriffe ermöglicht, in dem z.B. mit den egaunerten Priviliegien in sonst nicht zugänglichen Repositories/Servern andere Dinge gelesen und/oder beschrieben werden können. (das halte ich tatsächlich für die einzige erntzunehmende aber wahrscheinlichste Gefahr).

Dagegen muss man jetzt natürlich noch halten, dass die VM auf dem Server unter dem Schreibtisch auch Angriffsvektoren bietet (natürlich deutlich geringere) dafür aber widerrum soetwas wie in Einbruch in das System bei der selbstgehosteten VM wohl nie/nicht so schnell auffällt und aufgedeckt wird, wie ein breiterer Angriff auf Github, der entsprechend durch Github aufgedeckt werden könnte.

Ich bleibe erstmal bei meiner Aussage: Ich würde das ganze in einem Container bauen (so bzw. so ähnlich wie es derzeit via GHA stattfindet), jedoch dies eben nicht auf Github sondern lokal in einem Docker/OCI Container. Das Hochladen der resultierenden Artefakte würde ich weitgehenst automatisieren und mir lediglich überlegen, ob ich secret/token für den Upload auf der lokalen Platte liegen haben möchte oder ob ich dies jedesmal eingeben möchte.

[fda77]

Git ist recht sicher, wenn man mit "hashes" ausgecheckt ist es garantier was es vorher war, zb https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/genext2fs-host/genext2fs-host.mk#L1=
Und bei freetz (sollten..) alle http/ftp downloads auch einen hash haben, zb https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/genext2fs-host/genext2fs-host.mk#L3=
Seit ausser mir auch andere pushen können signierte ich meine commits, siehe https://github.com/Freetz-NG/freetz-ng/commits/master
Daher seh ich den Code als recht sicher an wie er aktuell ist, egal wo das git liegt.
Bei externen docker/github Dingen kann ich mir bei nichts sicher sein. Die VM setz ich immer auf einen Snapshot zurück

[pfichtner]

Seit ausser mir auch andere pushen können signierte ich meine commits, siehe https://github.com/Freetz-NG/freetz-ng/commits/master Daher seh ich den Code als recht sicher an wie er aktuell ist, egal wo das git liegt. Bei externen docker/github Dingen kann ich mir bei nichts sicher sein. Die VM setz ich immer auf einen Snapshot zurück

Ob Deine commits signiert sind oder ob die Datei inhaltlich noch dem entspricht was sie gestern war, dürfte der GHA relativ egal sein, die checkt aus und baut, das meinte ich 😆
Klar, das Basis Docker ubuntu-14.04 Image könnte jemand auf DockerHub manipulieren, wenn das allerdings passiert haben wir vermutlich noch ein paar andere Probleme 😄
Und die "externen github Dinge": Die hast Du doch jetzt schon, Du schiebst ja die Artefakte auf github, diese können da dann auch korrumpiert werden, unabhängig davon ob Du oder ob eine GHA die hochgeladen hast/hat.

[fda77]

Okay, man müsste dann noch den kompletten git-hash ausgeben der ausgecheckt wurde.

die Artefakte auf github, diese können da dann auch korrumpiert werden

Nein, siehe step "result": https://github.com/Freetz-NG/freetz-ng/runs/6108293032?check_suite_focus=true#step%3A15%3A7=

[pfichtner]

Verstehe den Link auf die GHA nicht.
Du lädst jetzt bereits Binaries (Toolchain/Hosttools) auf github.
Szenario privilege escalation, es ist also jemand ist in der Lage Daten/Dateien in der Freetz-Organisation zu ändern. So jemand kann sowohl die Binaries ändern als auch an anderen Stellen die jeweiligen Prüfsummen. Und das hat nichts mit der Frage zu tun, wie die Dateien da hingekommen sind, also mit der Frage ob selbst bauen oder GHA.

[pfichtner]

Okay, man müsste dann noch den kompletten git-hash ausgeben der ausgecheckt wurde.

Und da habe ich kein ausreichendes knowhow bezüglich git. Der git hash ist ja nur der hash des Commits und nicht die Prüfsumme von irgendwas. Ich vermute, wenn Du Zugriff auf das Dateisystem hast, kannst Du den Inhalt des commits bzw. den Zustand von Dateien zu diesem Zeitpunkt ersetzen ohne dass das ein ersichtlich ist, die Zustände/Dateiinhalte fliesen nicht in den commit hash ein. Das ist aber wie gesagt Vermutung ohne Wissen.

[fda77]

Ne, das hast du falsch verstanden. die Dateien im "result" wurden generiert und es wird gleich die checksumme (im format für freetz) angezeigt.
Wenn man am Checkout was ändert kommen in der Ausgabe von tools/freetz_revision Zeichen (MOFA) dazu. Das sieht man zb auch im geflashten Image

[fda77]

Die Actions sind nicht ernsthaft zum vorcompilieren zu verwenden:

Dh 33 Stunden, in welchem Zeitraum weiss ich aber nicht

Bleiben also nur die anderen Actions die lediglich Textcommits erstellen. Diese können ohne viel nachzuinstallieren laufen, bzw man können ein beliebiges Ubuntu Docker image nehmen das für Freetz alle prerequisites hat

[pfichtner]

Die Actions sind nicht ernsthaft zum vorcompilieren zu verwenden:

Zumindest nicht ohne den Einwurf diverser Münzen oder Scheine 😆
Hatte ich natürlich vermutet/befürchtet aber nie ausgekostet dass es soweit mal kam.

Dh 33 Stunden, in welchem Zeitraum weiss ich aber nicht

Ich vermute mal "pro Monat" ohne es zu wissen.

[fda77]

Hängt auch davon ab wie das berechnet wird. Falls es je Core ist, ist mit 8 Cores in 4 Stunden am Monatslimit und man kann mit spenden beginnen...

[fda77]

Fragen zu https://github.com/pfichtner/freetz-toolchain-docker/blob/main/.github/workflows/docker-publish.yml
Ich verstehe die ganze Datei nicht. Wohin wird diese Image überhaupt hochgeladen? Docker-Hub? Und wo kommen die Zugangsdaten her? Muss man dafür ein eigenes Repo auf Guthub verwenden?
Die für die actions (intern) genutzten images hab ich damit lokal erstellt: https://github.com/Freetz-NG/freetz-ng/blob/master/.github/docker/.build.sh

[pfichtner]

In die docker (container) registry von github (GHCR). Wäre ja Blödsinn, die nach dockerhub zu pushen um das Image dann an andere Stelle innerhalb von github wieder aus dockerhub zu pullen. Ob man dafür ein eigenes repo anlegen muss weiß ich nicht, aber im Sinne von Trennung finde ich das aber eigentlich am saubersten, warum sollte das in einem anderen repo liegen? (ok, gerade gesehen, dass Du das aber so gemacht hast, mir ist nicht ersichtlich wo der Vorteil liegt, ich würde das trennen).
Zugangdaten brauchst Du keine solange Du es nur innerhalb Deiner Organisation verwenden möchtest (was ja m.E. der Fall ist, Du willst ja die docker images für den Bau von toolchain etc. nur selbst nutzen).
Ich hätte jetzt einfach die Ownership für das genannte Repo zu Freez-NG transferiert, Du scheinst aber irgendwelche anderen Pläne zu haben (warum das alles innerhalb des Freetz-Firmware-Repos? Hat doch damit gar nix zu tun, oder? Warum mit shell Skripten bauen?).
Falls Du den anderen Weg gehen/probieren willst sag Bescheid, dann transferiere ich das Repo.

[pfichtner]

Natürlich könntest Du aus der GHA heraus auch nach dockerhub pushen falls gewollt, siehe https://github.com/pfichtner/freetz-toolchain-docker/blob/9cf4c8bd049c604185f9a0184f536e9d0c13c263/.github/workflows/docker-publish.yml#L19
(dafür sehe ich aber keine Notwendigkeit, da Du diese Images ja nur selbst verwenden willst und das Dockerfile ist ja öffentlich, so dass es jedermann auch bei sich nutzen könnte falls doch gewünscht).
Dann musst Du aber natürlich die Zugangsdaten bzw. Tokens als secret hinterlegen, so habe ich das z.B. bei https://github.com/pfichtner/pfichtner-freetz gemacht

[pfichtner]

Ich würde mich an diesen Fragen entlang hangeln:

• Soll das Image direkt durch Dritte "gepullt" werden können? Ja: Dann nach DockerHub pushen (GHCR wäre auch möglich DockerHub ist aber für Dritte einfacher zu nutzen da default registry)
• Nein, aber das Image soll durch Dritte einfach gebaut werden können ohne dass diese ein zusützliches repo auschecken müssen, weil Du sagst, dass das Erstellen von Docker-Images zum Bau von Hosttools/Toolchain integraler Bestandteil der freetz-firmware sein soll? Ja: Dann das/die Dockerfiles dort lassen wo sie sind.
• Nein: Eigenes Repo

In allen Fällen würde ich aber das Bauen via GHA (nativ) ohne irgendwelche Shellskripte machen und diese manuell bei Bedarf ausführen oder Triggern, wenn sich im Dockerfile (oder zugehörigen Dateien) etwas ändert. Natürlich ist das triggern in einem eigenen Repo einfacher, da man dort einfach auf beliebige Änderungen im gesamten Repo reagiert.

Ich würde argumentieren, dass das Erstellen von Docker-Images zum Bau von Hosttools/Toolchain nicht integraler Bestandteil der freetz-firmware ist und mit dieser eigentlich nichts zu tun hat. Falls Du also nicht sagst, dass Du jedermann einfach ein Docker-Image für den Bau von Hosttools/Toolchain zur Verfügung stellen willst (was ich auch nicht als nötig erachte), wäre meine Intention die des eigenen Repos (und dies public), so dass das dieses repo geclonet werden kann bzw. das darin liegende Dockerfile verwendet werden kann.

[fda77]

Nicht vergessen, ich hab von Docker keine Ahnung! Interessant dass man die Images auch zu GH hochladen kann, wenn ich das vorher gewusst hätte!
Mir geht es eigentlich nur um ein Image mit dem jeder ein Fritzbox Image erstellen kann, also öffentlich. Oder zum testen von Sachen wie https://github.com/Freetz-NG/freetz-ng/issues/552 , falls er es doch noch hinbekommt seine .config irgendwann hochzuladen. Am besten wären auch mit verschiedenen Ubuntu Versionen, 18 20 22.
Die 3 vorhandenen sind eher für die internen Sachen und zum testen. Das nur für die Docs ist sehr klein, ein grösseres braucht viel länger zum starten (10 statt 20 sec oder so). Ein extra Repo nur mit 3 Dateien finde ich übertrieben

[fda77]

Ich muss sagen https://github.com/pfichtner/pfichtner-freetz sieht gut aus, ich verstehe nur nichts davon :)

[pfichtner]

Mir geht es eigentlich nur um ein Image mit dem jeder ein Fritzbox Image erstellen kann, also öffentlich.
Oder zum testen von Sachen wie #552 , falls er es doch noch hinbekommt seine .config irgendwann hochzuladen.

Das gibt's seit Jahrtausenden, u.a. von mir (https://github.com/pfichtner/pfichtner-freetz)
Es gibt m.E. keine Grund, dass man jetzt noch ein weiteres Image veröffentlicht, wenn Du mir sagst in was sich das von meinem unterscheiden würde baue kann ich schauen ob ich das aufnehmen kann/will. Mach in dem Fall bitte einen Issue im genannten repo auf.

Ich dachte jetzt eher an das was wir das letzte Mal diskutiert hatten, nämlich Images die die benötigten Dinge beinhalten um hosttools/toolchain bauen zu können (um eben nicht jedesmal alles beim Build erstmal im ubuntu Basisimage installieren zu müssen). Diese Images gibt es nirgends (wieso auch), Um die geht es m.E.

Am besten wären auch mit verschiedenen Ubuntu Versionen, 18 20 22. Die 3 vorhandenen sind eher für die internen Sachen und zum testen.

Macht aus Anwendersicht wenig Sinn, warum sollte jemand der ein Dockerimage für den Bau nutzen möchte Wert drauf legen, ob dies ein Debian/Ubuntu/SuSE/whatever ist? Sinnvoll würde ich es auf Sicht von Freetz erachten um zu verifizieren, ob der Build unter den verschiedenen Distros/Versionen funktioniert (falls das gewollt).

Das nur für die Docs ist sehr klein, ein grösseres braucht viel länger zum starten (10 statt 20 sec oder so).
Die Startzeite der Images sollten alle ähnlich groß sein, die Größe spielt da nur sehr bedingt rein. Der Start von pfichtner-freetz dauert 0,02 Sekunden.

[pfichtner]

Ich muss sagen https://github.com/pfichtner/pfichtner-freetz sieht gut aus, ich verstehe nur nichts davon :)

Du hast es doch inklusive der bei Dir irrelvanten Teile in https://github.com/Freetz-NG/freetz-ng/blob/master/.github/docker/firmware/Dockerfile übernommen. Was verstehst Du nicht? Wofür das Docker Image gut ist? Vermutlich eher was docker-publish.yml macht, oder? Wenn ich ein GH Release mache, das git repo taggen, und dann auf dem Stannd das Docker Image bauen und nach DockerHub pushen, also das was Dein Shell Skript tut. Sollte aber an dem Kommentaren ableitbar sein.

[fda77]

Die Startzeite der Images sollten alle ähnlich groß sein, die Größe spielt da nur sehr bedingt rein

Vielleicht liegt es an der Downloadzeit von Docker-Hub

Sinnvoll würde ich es auf Sicht von Freetz erachten um zu verifizieren, ob der Build unter den verschiedenen Distros/Versionen funktioniert

Genau. Die würde ich dann aber lieber im haupt-repo haben, es könnten viele werden

Ich dachte jetzt eher an das was wir das letzte Mal diskutiert hatten, nämlich Images die die benötigten Dinge beinhalten um hosttools/toolchain bauen zu können (um eben nicht jedesmal alles beim Build erstmal im ubuntu Basisimage installieren zu müssen).

Das hab ich doch sogar hinbekommen und so in Verwendung. Von github gebaute binaries sind mir aber zu unsicher. Ich teste nur vorab ob alles compiliert ("intern"). "docs" änderungen sind okay, da sieht man was geändert wurde

Es gibt m.E. keine Grund, dass man jetzt noch ein weiteres Image veröffentlicht, wenn Du mir sagst in was sich das von meinem unterscheiden würde baue kann ich schauen ob ich das aufnehmen kann/will

Ne, braucht man auch nicht. Deine Doku dazu ist ja schon recht schick. Soll ich das dann einfach hier verlinken? https://github.com/Freetz-NG/freetz-ng#requirement

[pfichtner]

Vielleicht liegt es an der Downloadzeit von Docker-Hub

Ja klar, wenn das Image natürlich lokal nicht vorliegt muss es erstmal gezogen werden, je größer desto länger dauert das, aber das ist ja einmalig.

Sinnvoll würde ich es auf Sicht von Freetz erachten um zu verifizieren, ob der Build unter den verschiedenen Distros/Versionen funktioniert

Genau. Die würde ich dann aber lieber im haupt-repo haben, es könnten viele werden

Das sind ja aber alles Dinge, mit denen Du (via GHA) verifizieren willst, ob die gemachten Änderungen in freetz-ng ok sind/waren: Das würde ich nicht in das reinlegen, was zu prüfen ist.

Ich dachte jetzt eher an das was wir das letzte Mal diskutiert hatten, nämlich Images die die benötigten Dinge beinhalten um hosttools/toolchain bauen zu können (um eben nicht jedesmal alles beim Build erstmal im ubuntu Basisimage installieren zu müssen).

Das hab ich doch sogar hinbekommen und so in Verwendung. Von github gebaute binaries sind mir aber zu unsicher. Ich teste nur vorab ob alles compiliert ("intern"). "docs" änderungen sind okay, da sieht man was geändert wurde

Es gibt m.E. keine Grund, dass man jetzt noch ein weiteres Image veröffentlicht, wenn Du mir sagst in was sich das von meinem unterscheiden würde baue kann ich schauen ob ich das aufnehmen kann/will

Ich verstehe jetzt aber nicht, warum Du nicht ein bestehendes (z.B. mein) Docker Image zum Bau nutzt sondern nochmal ein eigenes

freetz-ng/.github/workflows/generate_img.yml

Line 16 in 7799769

image: freetzng/dl-packs

Ne, braucht man auch nicht. Deine Doku dazu ist ja schon recht schick. Soll ich das dann einfach hier verlinken? https://github.com/Freetz-NG/freetz-ng#requirement

Kannst Du gerne tun. Die Installation von Docker plus docker run -it -pfichtner/freetz scheint mir eh einsteigerfreundlicher als die Installation von VBox/VMWare, die Installation eines irgendwo abgelegten OVA Images mit intransparentem Inhalt bei welchem dann offensichtlich auch kein Autologinn aktiviert ist und ich noch User und Passwort benötige um dann, nachdem ich ne Shell gestart habe endlich am gleiche Punkt zu stehen. Ich habe mir auch extra Mühe gegeben für Docker-Einsteiger alles notwendige zu beschreiben (ganz unten)

[fda77]

Ich verstehe jetzt aber nicht, warum Du nicht ein bestehendes (z.B. mein) Docker Image zum Bau nutzt sondern nochmal ein eigenes

Die generate_* compilieren nicht und können ein kleineres (schneller) image haben
Und die tools/toolchains brauchen ein ubuntu18 zum testen, denn damit baue ich die (lokal).
Aber mit gehts wie gesagt mehr um "für benutzer", das mit den ganzen verschiedenen vms nervt mich nämlich.
Falls es mal eine neue Abhängigkeit gibt aktualisiert man das image und gut ists. Sonst gibt es jedes mal das unendliche Gejammer

Ich habe mir auch extra Mühe gegeben für Docker-Einsteiger alles notwendige zu beschreiben (ganz unten)

Ich hab ja geschrieben dass ich die Beschreibung nett finde. Und ob ich das verlinken soll

[pfichtner]

Die generate_* compilieren nicht und können ein kleineres (schneller) image haben

Wenn Du die Images in die GHCR schiebst dürfte es fast egal sein, ob das Image 50 MB oder 1 GB hat. Ist aber natürlich Abwegungssache/Deine Entscheidung ob Du für jeden Job ein spezielles Image nutzen willst oder möglichst wenige/allgemeine.

Aber mit gehts wie gesagt mehr um "für benutzer", das mit den ganzen verschiedenen vms nervt mich nämlich. Falls es mal eine neue Abhängigkeit gibt aktualisiert man das image und gut ists. Sonst gibt es jedes mal das unendliche Gejammer

Hab's immer noch nicht verstanden: Willst Du den Benutzern Docker Images für den Bau von Toolchain/Hosttools oder zum Bau von Freet-NG Firmware-Images zur Verfügung stellen? (Ich nehme an ersteres, weil für letzteres gibt's ja schon lange welche)

[fda77]

Für precompiled Zeug braucht man kein eigenes Image, dafür kann man das ganz normale für die Firmware verwenden!
Das einzig besondere an denen ist dass sie besonders alt sind - damit die bins überall laufen! Wenn du die selbst baust laufen die auch bei dir
Recht kleine Images für die generate find ich gut, wer weiss was mit Github/Microsoft wird. Ist dann auch besser lokal laufen zu lassen
Ich teste das trotzdem mal bei Gegehenheit mit GHCR

[fda77]

Ich habs mal hier verlinkt: afa5ad9

[fda77]

Ich hab mich mal an deinem docker image https://hub.docker.com/r/pfichtner/freetz versucht. Ergebnis: göht nicht!!1elf

• docker braucht bei mir ein "sudo" davor, keine ahnung wie das bei anderen distributionen ist. Es gab ne komisch "socket" Fehlermeldung
• Mir war zurst nicht klar dass das in einem Checkout-Verzeichnis aufgerufen werden soll, erst nach https://github.com/pfichtner/pfichtner-freetz#readme
• Es hagelte "permission" denied Meldungen, ich denke das läuft bei mir so wegen SElinux nicht

Btw, hab das mit ghcr hinbekommen. Scheint nicht wirklich schneller zu sein

[pfichtner]

* docker braucht bei mir ein "sudo" davor, keine ahnung wie das bei anderen distributionen ist. Es gab ne komisch "socket" Fehlermeldung

Hast Du den User jemals der docker Gruppe (bzw, der Gruppe dem das socket gehört) hinzugefügt?

* Mir war zurst nicht klar dass das in einem Checkout-Verzeichnis aufgerufen werden soll, erst nach https://github.com/pfichtner/pfichtner-freetz#readme

Soll/muss auch nicht: Kann: Du kannst den Docker Container jederzeit von überalls aus starten. Im Normallfall willst Du ja aber mindestens mal anschließend noch das image Verzeichnis oder meist eher eigentlich das gesamte build Verzeichnis (und das nicht im Container liegen haben und mit dem Container zusammen wegschmeisen). Deswegen dürfte es wohl eher der Normallfall sein auf dem Hostsystem auzuchecken und dort/dann den Container starten und das freetz Verzeichnis in den Container hineinreichen.
Du musst es auch nicht aus dem Checkoutverzeichnis aus aufrufen: Du musst sollst das Checkoutverzeichnis (im readme via $PWD) hineinreichen.
Wenn Du das nicht tust, Das ist das einfachste um an die gebauten images zu kommen (ansonsten musst Du ja irgendwelche Klimmzüge machen), Du kannst natürlich auch nur "images" hinreinreichen, das hast Du aber keine inkrementellen Builds mehr, das das build Verzeichnis und damit der build cache flöten geht wenn Du den Container entfernst.

* Es hagelte "permission" denied Meldungen, ich denke das läuft bei mir so wegen SElinux nicht

Vielleicht wegen Punkt 1?

Btw, hab das mit ghcr hinbekommen. Scheint nicht wirklich schneller zu sein

Die gesamte Containerinitialisierung via GHA mit einem 1.3 GB Image dauerte bei mir 23 Sekunden, also

• Checking docker version
• Clean up resources from previous jobs
• Create local container network
• Starting job container
• Waiting for all services to be ready

Was bedeutet bei Dir "nicht schneller" bzw. was bedeuetet "langsam"?

[fda77]

Hast Du den User jemals der docker Gruppe (bzw, der Gruppe dem das socket gehört) hinzugefügt?

Willst du das jeden fragen? Auch diejenigen die die prerequisites nicht installiert bekommen?

Vielleicht wegen Punkt 1?

Ne, schrieb ja dass dies ein socket-fehler war

Was bedeutet bei Dir "nicht schneller" bzw. was bedeuetet "langsam"?

Kein Unterschied: https://github.com/Freetz-NG/freetz-ng/actions/workflows/generate_docs.yml

[pfichtner]

Hast Du den User jemals der docker Gruppe (bzw, der Gruppe dem das socket gehört) hinzugefügt?

Willst du das jeden fragen? Auch diejenigen die die prerequisites nicht installiert bekommen?

Hä? Soll ich erklären wie man ein Linux installiert? SIcher nicht. Sollte ich in einer Anleitung in dem ich erkläre, was Inhalt meines Dockerimages erklären, wie man auf $Distro Docker installiert? SIcherlich auch nicht! Nichtsestotrotz habe ich die wichtigsten Dinge in der README zusammen geschrieben, inklusive dem Punkt, dass wenn man Docker als nicht root nutzen will, Mitglied der Docker Gruppe sein muss. (Nachtrag: https://github.com/pfichtner/pfichtner-freetz#some-hints-if-youre-new-to-docker)
Willst Du den Leuten erklären, wie man VirtualBox installiert, damit man das VMImage nutzen kann? WIllst Du den Leuten die die prerequisites nicht installiert bekommen erklären wie man die Virtualisierung im BIOS aktiviert? Das ist für mich nicht nachvollziehbar! Was wäre denn Dein Vorschlag um diese Punkte anzugehen?

Was bedeutet bei Dir "nicht schneller" bzw. was bedeuetet "langsam"?

Kein Unterschied: https://github.com/Freetz-NG/freetz-ng/actions/workflows/generate_docs.yml

Das Starten des Containers dauert 7 Sekunden, das Clonen 7 Sekunden, das Bauen 23 Sekunden, wo willst Du denn da Zeit raus holen? Die Containerstatupzeit würde ich jetzt nicht als langsam bezeichnen. Vermutlich ist ein Uterschied zwischen dockerhub und ghcr wohl tatsächlich erst bei großen Images spürbar.

[pfichtner]

Ich habe mal "aus Spaß" geguckt, wie viel Anleitung es beim VM Image gibt, also zumindest verlinkt ist null. Falls Du meinst, dass die Leute die an prerequisites scheitern wenig Probleme mit dem VMImage aber massiv Probleme mit dem Docker Image und einer dort vorhandenen Beschreibung (die man natürlich auch lesen sollte) haben, dann schreib be Warnung an den Docker Image Link oder entferne ihn halt wieder.

[fda77]

Willst Du den Leuten erklären, wie man VirtualBox installiert, damit man das VMImage nutzen kann?

Du beschöftigst dich wohl noch nicht so lange mit Freetz... zb https://freetz-ng.github.io/freetz-ng/wiki/10_Beginner/freetz_linux.html

[pfichtner]

Willst Du den Leuten erklären, wie man VirtualBox installiert, damit man das VMImage nutzen kann?

Du beschöftigst dich wohl noch nicht so lange mit Freetz... zb https://freetz-ng.github.io/freetz-ng/wiki/10_Beginner/freetz_linux.html

Wie viele Hinweise auf Hardware-Virtualiserung im BIOS aktivieren siehst Du dort? Ich habe keinen gefunden.

[pfichtner]

Also mir ist das ja egal, es ist einfach verlink. Es wird aber fast niemand nutzen, wenn es so "kompliziert" ist. Wer sich eh mit docker beschäftigt nimmt wohl lieber ein eigenes image, ich war überrascht wieviele es in diesm hub gab

1. Den Satz verstehe ich vorne und hinten nicht. Das hinzufügen der Gruppe musst Du machen, damit Du docker auf dem Rechner (als nicht-root) nutzen kannst. Das hat null-komma-null mit meinem Image zu tun!
2. "Sein eigenes" Images??? Welches? Du meinst ein eigenes Dockerfile bauen und das laufen lassen sei leichter, als ein fertiges Image zu nutzen? Für Leute die Docker nicht installieren können?

[pfichtner]

Kannst Du mir erklären, was Du als so "kompliziert" erachtest:

• Die Installation von Docker (da habe ich die wichtigsten ein/zwei Punkte in https://github.com/pfichtner/pfichtner-freetz#some-hints-if-youre-new-to-docker ja beschrieben und ergänze auch gerne um DInge die Deiner Meinung nach fehlen und/oder übertrage es auch gerne ins wiki analog der Beschreibung wie man eine Virtualsierungslösung installiert). Die Anleitung für die Installation von Docker dürfte deutlich schmaler ausfallen als die für jede der genannten Virtualsierungslösungen.

oder

• das Nutzen meines Images was ich unter https://github.com/pfichtner/pfichtner-freetz beschrieben habe?

[pfichtner]

Willst Du den Leuten erklären, wie man VirtualBox installiert, damit man das VMImage nutzen kann?

Du beschöftigst dich wohl noch nicht so lange mit Freetz... zb https://freetz-ng.github.io/freetz-ng/wiki/10_Beginner/freetz_linux.html

Du offensichtlich auch nicht oder ist "1. VirtualBox starten" für DIch die Anleitung wie man VirtualBox installiert?

[pfichtner]

Es wird aber fast niemand nutzen, wenn es so "kompliziert" ist. Wer sich eh mit docker beschäftigt nimmt wohl lieber ein eigenes image,

Kann die Argumente nicht nachvollziehen:

Es wird aber fast niemand nutzen, wenn es so "kompliziert" ist.
Was genau ist so "kompliziert"?

Wer sich eh mit docker beschäftigt nimmt wohl lieber ein eigenes image,

Im Satz davor schreibst Du noch, wird eh keiner nutzen, wenn es so kompliziert ist. Wer an der Dockerinstallation scheitert, der wird Docker wohl nicht nutzen, unabhängig von dem/den Image(s) die man nutzen möchte. Und wer Docker nicht installier kriegt, der wird erst recht kein eigenes Image bauen.

Die Argumente passen vorne und hinten icht zusammen.

Du schriebst auch, es wäre die falsche Zielgruppe. Die angedachte Zielgruppe war die, die es auch schafft eine Virtualisierungslösung zu installieren, zu konfigurieren, ein VM-Image runterzuladen und das in die jeweilige Umgebung importieren zu können und das ganze dann auch noch betreiben zu können. Ich traue dieser Zielgruppe auch die Installation von docker zu.
Für die von Dir angesprochene Zielgruppe, die es nicht schafft per copy/paste die notwendingen Befehle für die Installation benötigter Pakete auszuführen wird es halt leider arg eng. Docker bietet Skripte die auf so ziemlich jedes System Docker nageln, aber auch da muss man halt per copy/paste mal curl/wget aufrufen und die Skripte ausführen.
Wenn dann eben selbst bei copy/paste die Hürde zu hoch liegt, dann bleibt am Ende nur noch eine Appliance wo Dinge ohne jegliche Installation genutzt werden können. Ideen und Ansätze hätte ich dafür. Wenn dann aber am Ende der Build auf einer Appliance läuft wird das ein Angebot sein, welches man/keiner mehr kostenfrei anbieten kann. Und damit stellt sich dann die Frage, wie groß der Markt dafür tatsächlich ist.

[fda77]

Wie viele Hinweise auf Hardware-Virtualiserung im BIOS aktivieren siehst Du dort? Ich habe keinen gefunden.

Gabs vielleicht damals als das geschrieben wurde noch nicht ;-) Geht wohl auch ohne, und docker läuft auch in VMs

[pfichtner]

Ich gebe DIr Recht: Wer an apt install $irgendwas bzw. dem Copy/Paste der Installationskommandos aus prerequisites scheitert, der wird auch an apt install docker und/oder dem usermod scheitern. Die scheitern dann aber auch an dem VM-Weg!
Bleibt die Frage ob und wie man den Leute etwas an die Hand geben kann/will damit diese Firmware Images erzeugen können. Bleibt ja fast nur noch ne Appliance.

Edit 1: Wer an Copy/Paste und apt scheitert, dem hilft dann auch kein sudo apt install docker; sudo usermod -aG docker $(whoami)
Kannst/willst Du diese Leute unterstützen? Das wird echt schwer, denn dann fällt das auf der eigenen Maschine weg, Docker entfällt, VMs entfallen, bleibt nur noch Appliance, wo sie nur mit menuconfig konfrontiert werden. Da liese sich schon was bauen, ist nur die Frage wie groß Interesse/Markt ist.

Edit 2: Oder ein Executable (Linux/Mac/Windows) welches man nur ausführen muss und/oder direkt via curl/bash runterladen/ausführen, eventuell auch ein Shell-Installer, egal ob mit oder ohne Docker oder was auch immer: Das was am wenigsten auf einem potentiell Zielsystem erwartet/benötigt und möglichst nichts/wenig dort ändert.

[fda77]

Das sind halt die lautesten. Schau dir mal die Diskussionen im IPPF an, danchdem die "tools" auf x64 (und vor aptgurru) umgestellt wurden und es andere prerequisites gab

[pfichtner]

Wenn man statt docker podman nutzt ist das ganze daemonless und damit reicht die Installation (z.B. apt install podman) aus.
podman run -u root --userns keep-id --rm -it -v $FREETZ_DIRECTORY:/workspace docker.io/pfichtner/freetz

Damit könnte jedermann relativ einfach eine freetz build Umgebung auf einer podman fähigen System starten. Hilft aber nicht der angesprochenen Zielgruppe, die an apt scheitert. Wobei mir weiterhin unklar ist, was man dieser Zielgruppe ausser einer applicance anbieten kann.

[fda77]

Wahrscheinlich werden die meisten bei der vorhandenen VM bleiben und wie gehabt bei neuen prerequisites herumjammern

[pfichtner]

Leute die eine Virtualisierungslösung installiert, ein VM Image runtergeladen und importiert sowie die notwendingen Einstellungen vorgenommen bekommen, die werden sicherlich nicht an nem apt install und an einem docker/podman run scheitern.

[pfichtner]

Es gibt mindestens drei Wege, wie man zu einer Buildumgebung kommt

1. Auf einem vorhandenen Linux-System
2. Auf einer vorgefertigten virtuellen Maschine
3. In einem Docker-Container

Folgendes ist nun zu tun:

Schaffen der notwendigen Basis

Linux-System	VM	Docker
Installation des Linux-System selbst	Installation einer Virtualisierungslösung (VirtualBox/VMWare/...)	Installation einer OCI Runtime (Docker/Podman/...)

Soll es hierfür Anleitungen geben? Ich habe bei Freetz weder eine Anleitung gefunden, wie man ein Linux-System baut, noch wie man eine Virtualisierungslösung installiert, wobei letzteres scheint es ja mit cuma Zaubertinte geschrieben in einem Dokument zu geben, welche aber nur gelesen werden kann, wenn man schon bei DS-Mod dabei war.

"Importieren"

Linux-System	VM	Docker
Ausführen der Kommandos aus PREREQUISITES	Importieren des/eines OVA-Images	"pull" des Images (nicht notwending, geschieht im nächsten Schritt automatisch mit)

Das ist das einzige, was in dem von Dir genannten Dokument für VMWare/Virtualbox/... beschrieben ist. Also der Teil, der bei OCI/Docker nicht durchgeführt werden muss.

Nutzen der Lösung/make inkl. menuconfig

Sieht auf allen Systemen gleich bzw. ähnlich aus. Kann auf dem Linux-System direkt ausgeführt werden, bei Virtualisierung muss entweder die virtuelle Maschine oder der Docker-Container gestartet werden.
Der einzig relevante Unterschied zwischen nativ und virtualisiert (inkl. OCI) ist, ob man das checkout Verzeichnis in oder ausserhalb der Virtualisierung haben möchte.
Vorteil bei ausserhalb: Das gebaute Image liegt dann nicht in der Virtualisierung sondern auf dem Host-System. Desweiteren sind damit schnellere, inkrementelle Builds möglich, da alle "temporär" erzeugten Dateien vorhanden bleiben. Ein weiterer Vorteil: Das "System" kann jederzeit weggeschmissen und damit auch aktualisert werden (z.B. bei akutaliserten PREREQUISITES), ansonsten müssen das die Nutzer selbst tun und wären genau damit dann konfrontiert, vor was Du sie "schützen" wolltest
Auch hierzu findet sich nichts in der Beschreibung (oder ist auch wieder mit cuma Zaubertinte geschrieben).

Idee

Ein Installations-Shell Skript, welches jeweils für die Distribution die benötigten Pakete installiert (also quasi ausführbare PREREQUISITES: Ermitteln der Distro, dann Aufruf von yum/apt/..., also dem was eh in den PREREQUISITES). Die Hürde für Anwender wäre dann, das Skript herunterladen und Ausführen zu müssen, siehe z.B. https://github.com/docker/docker-install.
Wie bereits erwähnt, das liese sich auch mit Provisionierungstools schön lösen, ist aber m.E. zu viel overhead. Vielleicht baue ich trotzdem mal eine ansible Role dafür.

Dieses Installations-Shell Skript könnte man dann auf allen Lösungen anwenden:

• Auf den "nativen" Linux-Systemen
• Zum Bau von VM-Images, auch vollautomatisiert, auch z.B. via GHA via packer o.ä. sobald sich die PREREQUISITES ändern.
• Zum Bau von Docker-Images, auch vollautomatisiert, auch z.B. via GHA sobald sich die PREREQUISITES ändern.

[fda77]

"ausführbare PREREQUISITES" klingt ganz gut, das wird aber nie auf allen Systemen 100%ig funktionieren und wird dann immer irgend welche Fragen nach sich ziehen.
Die "Community" schafft es ja bis heut nicht die PREREQUSISTES aktuell zu halten. Nach den Beschwerden zu urteilen gibt es zahlreiche Debian, bislang ist in den prerequisites dazu nichts zu lesen

[pfichtner]

Hier mal ein aus https://github.com/Freetz-NG/freetz-ng/blob/master/docs/PREREQUISITES.md zusammenkopiertes Gerüst, sollte für die aufgeführten Fälle funktionieren.
sudo habe ich aus jeder Zeile entfernt, damit das Skript auch auf Systemen ohne sudo ausgefürt werden könnte. Es macht hier auch mehr Sinn das Skript bzw. den Interpreter mit Rootrechten aufzurufen.

install-prerequisites.sh.txt

Falls man langfristig diese Informationen nicht redundant führen möchte könnte man das md aus dem Skript erzeugen oder das Skript aus dem md oder beides aus einer strukturierten Datei (XML,CSV,JSON,etc.)

[pfichtner]

Willst Du den Leuten erklären, wie man VirtualBox installiert, damit man das VMImage nutzen kann?

Du beschöftigst dich wohl noch nicht so lange mit Freetz... zb https://freetz-ng.github.io/freetz-ng/wiki/10_Beginner/freetz_linux.html

Falls das irgendwann da mal gestanden haben soll (und damit davon abhängt, wie lange man sich mit Freetz beschäftigt): Ich finde keine einzige Zeile die beschreibt, wie man Virtualbox oder irgendeine andere Virtualsierungslösung installiert.
In diesem Beispiel steht nix, wo finde ich es denn nun?

[pfichtner]

Ich find es witzig dass alle immer an ne Verschwörung denken sobald sie was nicht verstehen. Die Seite gibts seit min 9 Jahren im trac: https://trac.boxmatrix.info/freetz-ng/wiki/help/howtos/common/freetz_linux?action=history und wurde hier zusammenm mit allem vor 3 Jahren importiert: https://github.com/Freetz-NG/freetz-ng/commits/master/docs/wiki/10_Beginner/freetz_linux.md

Was hat das mit Verschwörung oder nicht verstehen zu tun?
Ich sage: "Gibt's ja Freetz-NG auch nicht"
Du sagst. "Doch, gibt es! Nämlich da..."
Ich sage: "Ne, steht da nicht, ich finde auch dort dazu nix"

Ich bleibe dabei: Freetz-NG beschreibt auch nicht, wie man Virtualisierungslösungen installiert, da kannst Du mir noch 100x nen Link schicken, wie man das OVA anschließend dann in VirtualBox und Co. importiert kriegt.

[fda77]

ist doch oben verlinkt

[fda77]

ausserdem hast du behaupter diese seite wäre "aufgetaucht"

[pfichtner]

Ich schreibe jetzt glaube ich zum fünften Mal: Da ist beschrieben, wie man in eine BEREITS INSTALLIERTE Virtualisierungslösung OVA-Images importiert. Wo(???) ist beschrieben wie man diese installiert?
Ich habe nirgends behauptet es wäre was aufgetaucht: Ich hatte lediglich ironischerweise geschrieben, dass die Installationsaleitung wohl mit Zaubertinte geschrieben sein muss, denn ich sehe die nirgends.

[pfichtner]

Die Nutzung des Docker-Images scheint mir nicht komplizierter zu sein als die Nutzung des VM-Images (OVA-Images).
Um das VMImage zu importieren und zu starten bedarf es offensichtlich einer größeren Beschreibung. Bei Docker (OCI) entspricht das einem docker run -it $image.
Wie man zur einer funktionierenden Docker-Installation (im Normalfall Installation via $paketmanager und dem Hinzufügen zur docker Gruppe für die Benutzer, die Docker nutzen dürfen) setze ich voraus[1], genauso wie Freetz voraussetzt, dass man VMware/Virtualbox/... auf seinem Rechner installiert und lauffähig hat.

[1] bzw. hatte das extra noch in einem Abschnitt erwähnt, für Leute die Docker nicht bereits installiert haben

[fda77]

Ich sehe keinen Handlungsbedarf. Für mich reicht docker für die actions und eine VM um was lokal zu machen

[pfichtner]

Bei mir 42

[pfichtner]

Ich sehe auch kein Handlungsbedarf! Dann tu Du bitte aber auch nicht, als ob es welchen gäbe!

Willst Du den Leuten erklären, wie man VirtualBox installiert, damit man das VMImage nutzen kann?
Du beschöftigst dich wohl noch nicht so lange mit Freetz... zb https://freetz-ng.github.io/freetz-ng/wiki/10_Beginner/freetz_linux.html

Ich habe für Docker keine Installationsanleitung geliefert, Freetz liefert keine für VirtualBox/VMware/und Co. Das ist ok! Beides! Aber behaupte bitte nicht dauernd, auf der Seite die Du x-mal verlinkt hast würde sich eine befinden.

[fda77]

Prima, dann sind wird uns ja endlich einig

[pfichtner]

Falls Du Deine Meinung damit jetzt plötzlich geändert hast: Ja.
Ersichtlich war das leider nirgends.
Dass das 13 Tage gebraucht hat, ist wohl nicht mir anzulasten, insofern bin ich an dem "endlich" unbeteiligt.