Hi,
Ich greife hier mal einen Beitrag von Clemens aus den Thread [Dev] Puppet Module auf.
Was passiert, wenn sich die Beteiligten nicht an die getroffenen Vereinbarungen halten, haben wir gerade erst gesehen als eine relativ
große
Gruppe gegen jede Empfehlung testing Firmware produktiv eingesetzt
hat. Das
führt bei allen Beteiligten zu Unmut und massivem Mehraufwand.
Das die testing Firmware auf stable gezeigt hat und die normale nordwest.freifunk.net SSID ausgestalte anstatt testing.nordwest.freifunk.net war mein Fehler. Ich habe da ein wenig unüberlegt gehandelt.
Prinzipiell ist testing wie der narme schonsagt eben testing also eine in den meisten fällen unstable version mit vielen ungeprüften Code Fragmenten. Wer diese Firmware einsetzt muss sich bewusst sein das die Router dabei zerstört werden können.
Ich denke das ist selbstverständlich allen klar.
Dennoch denke ich gerade darüber nach das good_signatures level der testing branches in der site.conf von 1 auf 2 zu inkrementieren. Das würde dazu führen das wenn jemand eine testing Firmware baut diese signiert und anschließend hoch lädt nicht ohne die zweite Signatur über das testing Netz verteilt wird.
Es muss aber auch allen klar sein das wenn wir das tun ich bei jeder erdenklichen testing Firmware nach Signaturen fragen werde.
vg Tarek
Am Dienstag, 9. Februar 2016, 00:11:30 CET schrieb Jan-Tarek Butt via Dev:
Es muss aber auch allen klar sein das wenn wir das tun ich bei jeder erdenklichen testing Firmware nach Signaturen fragen werde.
Hi,
bitte nicht machen. Ich habe da auch zwei Gründe für, warum man das nicht machen sollte. Einen theoretischen und einen praktischen:
Der theoretische: Es ist eine testing Firmware. Die wird niemals produktiv eingesetzt und wenn sie in einem Testsetup zum Einsatz kommt, dann ist dieses Setup sehr klein und im Idealfall abgetrennt vom Rest des Netzes. Ein realer Schaden, der nicht auch mit einer Signatur entstehen könnte kann gar nicht entstehen. Das Schlimmste was passieren kann ist, dass ein paar Testrouter in einem Testnetz gebricked werden. Who cares?
Der praktische: Ich möchte, dass wir in Zukunft intensiver testen. Wir haben längst über 1k Devices und können es uns eigentlich nicht mehr leisten mehr oder weniger ungetestete Firmware auf den Markt zu werfen. Das Problem: manuelles Testen ist sehr aufwendig und zeitintensiv. Und zudem ist ein manueller Testprozess selbst wieder Fehleranfällig. Der komplette Test-Prozess muss also automatisiert werden. Ihr kennt das evtl. von Unittests: Ihr macht einen Commit in ein Repository, der Computer deployed eure Software in einem temporären Environment, führt die Unittests aus und schickt euch fünf Minuten später eine Mail wenn er einen Fehler festgestellt hat. Bei großen Softwareprojekten sind solche Verfahren unumgänglich.
Der Weg dahin ist lang, aber der erste Schritt ist, dass ein Computer die Test-Firmware automatisiert bauen und in einem Testnetz deployen kann. Das würde uns schon einen großen Batzen Arbeit abnehmen, funktioniert aber nicht, wenn die Firmware vor dem Deployen von einem oder sogar mehreren Mensch signiert werden muss.
Darum: kein manuelles Signieren von Testing-Firmwares bitte. Eine einzelne Signatur eines Computers zur Verifikation der Echtheit der Testing-Firmware reicht vollkommen aus.
Viele Grüße Clemens
P.S. für diesen Zweck war auch die Stellenausschreibung für den Gitlab-CI Experten ;)
On 02/09/16 01:03, Clemens John via Dev wrote:
Am Dienstag, 9. Februar 2016, 00:11:30 CET schrieb Jan-Tarek Butt via Dev:
Es muss aber auch allen klar sein das wenn wir das tun ich bei jeder erdenklichen testing Firmware nach Signaturen fragen werde.
Hi,
bitte nicht machen. Ich habe da auch zwei Gründe für, warum man das nicht machen sollte. Einen theoretischen und einen praktischen:
Der theoretische: Es ist eine testing Firmware. Die wird niemals produktiv eingesetzt und wenn sie in einem Testsetup zum Einsatz kommt, dann ist dieses Setup sehr klein und im Idealfall abgetrennt vom Rest des Netzes. Ein realer Schaden, der nicht auch mit einer Signatur entstehen könnte kann gar nicht entstehen. Das Schlimmste was passieren kann ist, dass ein paar Testrouter in einem Testnetz gebricked werden. Who cares?
Dem stimme ich wohl zu.
Der praktische: Ich möchte, dass wir in Zukunft intensiver testen. Wir haben längst über 1k Devices und können es uns eigentlich nicht mehr leisten mehr oder weniger ungetestete Firmware auf den Markt zu werfen. Das Problem: manuelles Testen ist sehr aufwendig und zeitintensiv. Und zudem ist ein manueller Testprozess selbst wieder Fehleranfällig. Der komplette Test-Prozess muss also automatisiert werden. Ihr kennt das evtl. von Unittests: Ihr macht einen Commit in ein Repository, der Computer deployed eure Software in einem temporären Environment, führt die Unittests aus und schickt euch fünf Minuten später eine Mail wenn er einen Fehler festgestellt hat. Bei großen Softwareprojekten sind solche Verfahren unumgänglich.
Der Weg dahin ist lang, aber der erste Schritt ist, dass ein Computer die Test-Firmware automatisiert bauen und in einem Testnetz deployen kann. Das würde uns schon einen großen Batzen Arbeit abnehmen, funktioniert aber nicht, wenn die Firmware vor dem Deployen von einem oder sogar mehreren Mensch signiert werden muss.
Darum: kein manuelles Signieren von Testing-Firmwares bitte. Eine einzelne Signatur eines Computers zur Verifikation der Echtheit der Testing-Firmware reicht vollkommen aus.
Jo, ich hätte das jetzt unter experimental gepackt aber in testing geht das auch. Im Grunde reicht testing auch.
P.S. für diesen Zweck war auch die Stellenausschreibung für den Gitlab-CI Experten ;)
Aso ja warum sagst du das nicht gleich. So einen hatten wir schon mal oder willst du das gerne über gitlab-CI lösen ?
Ich kann die Tage mal ein automatisierten buildserver aufsetzen ? Das ist ne Sache von ne halben Stunde.
vg Tarek
Am Dienstag, 9. Februar 2016, 02:01:06 CET schrieb Jan-Tarek Butt via Dev:
Aso ja warum sagst du das nicht gleich. So einen hatten wir schon mal oder willst du das gerne über gitlab-CI lösen ?
Jo das soll über Gitlab gelöst werden, da dort automatische Builds und Unittests in einem quasi Standard umgesetzt werden können. Brauchst nichts machen, du hast ja schon genug zu tun ;)
LG Clemens
On 02/09/16 02:17, Clemens John via Dev wrote:
Am Dienstag, 9. Februar 2016, 02:01:06 CET schrieb Jan-Tarek Butt via Dev:
Aso ja warum sagst du das nicht gleich. So einen hatten wir schon mal oder willst du das gerne über gitlab-CI lösen ?
Jo das soll über Gitlab gelöst werden, da dort automatische Builds und Unittests in einem quasi Standard umgesetzt werden können. Brauchst nichts machen, du hast ja schon genug zu tun ;)
Das ist gut zu hören :D
Ich schmeiß jetzt noch eben ein build für 0.8 an und gehe pennen. :)
gn8 Tarek
-
Clemens John -
Jan-Tarek Butt