Beispielpacket : special treatment for single node by firmwareupdate (gluon-treatment)

hab ein Paket gebaut was es erlaubt einzelne Nodes zu modifizieren während eines FW updates. Das zum Beispiel praktisch wenn man ohne ssh einzelne Dinge ändern wollte / müsste.

aus der README.md

Gluon script to enable special treatment for single nodes based on their macs. You can than do slightly corrections to single nodes via an update especialy if you dont have ssh access.

basicly you HAVE to have your own repo of gluon-treatment where you put your Files for every single node you want to change, the example repo will do nothing than deleting itself.

put this into your modules file similar like this and add gluon-treatment to your site.mk.

GLUON_SITE_FEEDS='v14tov15helper ssidchanger banner treatment'
PACKAGES_TREATMENT_REPO=https://github.com/viisauksena/gluon-treatment.git
PACKAGES_TREATMENT_COMMIT=74b423c678b00000000000000002a7
PACKAGES_TREATMENT_BRANCH=master

you have to make a file for each node you want modify with the name to the MAC Adress of br-client in uppercase letters : the MAC of the node is the same as n meshviewer but uppercase and with : you have to make file executeable ! (chmod a+x …) See the example file in files/lib/gluon/treatment/macs.

The script would run at one time (cronjob) and then check for treatment files and then delete them and the cronjob and the script itself, so nothing is left at the end. And all Nodes are thereby „normalized“ as intendet.

its a hack, but quiet convenient to correct things like deprecated branches. It has some drawbacks for sure, we dont care.

here are some example treatment contents, you can add as much and creativly as you want

#!/bin/sh
# set hostname
uci set system.@system[0].hostname=blablabla
uci commit

#!/bin/sh
# change fastd mtu (dangerous if wrong mtu, because loosing connection to Freifunk at all is possible)
sed -i s/mtu\ \'1426\'/mtu\ \'1280\'/g /etc/config/fastd
/etc/init.d/fastd restart

#!/bin/sh
# change geo or activate/deactivate
uci set gluon-node-info.@location[0].latitude=<LAT>
uci set gluon-node-info.@location[0].longitude=<LONG>
uci set gluon-node-info.@location[0].share_location=1
uci commit gluon-node-info

#!/bin/sh
# add ssh-key 
echo "ssh-rsa AAAAB3NzaC1yc2EA..SUPERSTRONGSSHKEY... mykey-name" >> /etc/dropbear/authorized_keys
echo "ssh-rsa AAAAB3NzaC1yc2EA..SUPERSTRONGSSHKEY2... otherkey-name" >> /etc/dropbear/authorized_keys

#!/bin/sh
# remove all ssh keys (deactivate ssh login)
rm /etc/dropbear/authorized_keys
/etc/init.d/dropbear restart

#!/bin/sh
# force branch switch, ice if you want to remove old branches completly
uci set autoupdater.settings.branch=newbranch
uci commit

#!/bin/sh
# install a package later on this node
# (your opkg and module packages have to setup properly)
opkg update
opkg install gluon-status-page

#!/bin/sh
# some routers were stolen, or some people use freifunk "harmfully"
sed -i s/"<ssid>"/"dieser Router ist geklaut"/g /var/run/hostapd-phy0.conf
killall -HUP hostapd

#!/bin/sh
... whatever you love to do ...

CC-BY

(update: sed im Beispielcode zu einer weniger gefährlichen Variante geändert)

2 Likes

Ich ahne zwar schon, welche Diskussionen sich hier entspinnen wird, aber nützlich finde ich es trotzdem.

1 Like

@adorfer : dachte mir das du das sagen wirst :slight_smile: … , das ja nix was FW bauende nicht eh tun könnten, hier nur ein handy tool dazu um nicht das rad 100* neu zu erfinden

Damit wird das System der mehreren Signaturen für ein Update untergraben.

Das halte ich für einen großer Rückschritt.

Ein Weg der für derartige Anpassungen die gleiche Anzahl Signaturen erwartet wie ein Autoupdate wäre akzeptabel.

@MrMM , das stimmt nicht. Du/Ihr musst ja die FW bauen, und entsprechend signieren. Und nur was diese Leute da abnicken kommt da rein. in der modules steht ja die refferenz inkl commit und branch (wie sonst auch).

Das nur ein Tool um mit Zwischenupdate, oder einmalig während eines updates Dinge zu fixen, sonst nix - nix was bleibt. Was Firmware bauende da fixen wollen, entscheiden ja die Leute selbst. Darin liegt doch die eleganz dieses Skriptes, man muss die FW und den ganzen Prozess nicht irgendwie aufbohren für alle, sondern hinterlegt Bonbons für einzelne Router.

Dramatik läge woanders - aber meine Meinung wäre, wer den autoupdater an hat erwartet von denen die Netze Betreiben und Firmware bauen das die sinnvolle Dinge tun. und verweise mal auf diese Antwort : zu Firmware und Vertrauen Code Review auf Sicherheit - #29 von fuzzle
(wobei das grundsätzlich zu diskutieren hier offtopic wäre)

Das sed -i s/1426/1280/g /etc/config/fastd finde ich super. Wenn im public key „zufällig“ mal 1426 vorkommt, geht danach garnichts mehr und die Gateways werden entlastet.

edit:

  • ifconfig sollte für sowas nicht verwendet werden. Das wc -l ist überflüssig.
  • Lieber node_id statt MAC verwenden. Die ist dafür da einen speziellen Knoten zu identifizieren.
  • Es ist nicht sinnvoll die Dateien zu entfernen, da das nur im Overlay geschieht. Stattdessen sollte man ein Flag (im uci) setzen und das auswerten.
  • Das Script sollte nicht stündlich laufen sondern lieber während des Upgradeprozesses beim nächsten Boot. Dann ist das System in einem recht gut definierten Zustand.
1 Like

@tcatm gute einwände,
das sed - kommt nur aus einem Beispiel - bei unseren 600 keys kommt das zwar nicht vor, wir kennen aber im einzelnen ja nicht die secret keys, und da könnte das passieren, und das wäre tatsächlich doof - werde das (auch oben) auf sed -i s/mtu\ \'1426\'/mtu\ \'1280\'/g /etc/config/fastd ändern.
node_id statt MAC, ja genauso gute idee, wonach man testet is im Grunde ja egal - im Moment eben nach ifconfig br-client | grep <MAC> und weil ich da gerne ne 1 stehen hab halt wc -l - aber du hast recht, hier nicht nötig (gewohnheit) … ich könnte auch gleich gegen $mac in der if-schleife testen wenn ich grep -o <MAC> benutze …
wie gesagt, das halt design
dateien entfernen : ja das hab ich auch festgestellt - schade, die sind auch da noch da wenn ich das paket entferne mit opkg remove gluon-treatment , bei einem Folgeupdate verschwinden die dann … von daher kann ich damit leben.
stündlich : dazu fehlt mir das verständnis um das korrekt einzubauen, aber wie bei der MAC<->NODE_ID … just design Entscheidung, bzw wenn du mir das kurz skizzierst lern ich das auch gern. (wo und wie prozesse im first reboot ändern)

@tcatm da ich das recht verstanden hab, das du das Skript eh nicht magst, würd ich das jetzt auch nicht ändern, unsere Zwecke hier erfüllt das allemal
Dieses Forum braucht unbedingt mal gut ironie-tags :irony:

Ich habe nicht gesagt, dass ich das Skript nicht mag. Das sind lediglich Aspekte, die zu beachten wären, wenn das Skript vielleicht irgendwann mal nach Upstream in Gluon kommen sollte.

Wie Upgradeskripte ausgeführt werden ist hier dokumentiert: Upgrade scripts — Gluon 2016.1.2 documentation

@tcatm , dann tu ich dir unrecht,

ich glaube bevor ich da strukturell weiterarbeite (NodeID oder MAC oder sysupgrade …) brauch ich erstmal eine klare vorstellung davon wo und wie Menschen die das in die site.mk einbauen via gluon-treatment \ denn die dazugehörigen miniscripte hinterlegen. Das über die modules zu lösen und dann eigene Repo zu pflegen ist doch doof - bzw. ist dann eben nicht als feste option eingebaut.
Die Idee das quasi per Node eine Datei existiert ist glaub ganz gut … vielleicht ähnlich der Sprachdateien dann hinterlegen?

Diese Dateien sollten dann per Signatur beglaubigt werden um nicht einzelnen Admins eine Hintertür zu Knoten im Feld zu erlauben.

@MrMM : ich glaube ich ahne dein Missverständnis. Mein Paketvorschlag baut von Anfang an die potentiellen Dateien in die FW ein … und prüft dann auf allen Routern je selber ob sie damit gemeint sind. Von daher gelten die „normalen“ FW Regeln.

Ein externes holen von Dateien im Betrieb geschieht nicht! Das wäre Prinzipiell auch eine Möglichkeit, und dann hättest du vollkommen recht. Ich find die Idee auch nicht gut - aus eben deinen Gründen. Nochmal dieser SkriptVorschlag funktioniert anders!

Du hast recht.

Ich bin davon ausgegangen, dass die Liste der zu bearbeitenden Knoten nachgeladen wird.

Mit dem Einbau ins Image ist natürlich Sichergestellt, dass nur die geplanten Knoten behandelt werden.

März bis Mai, ist noch keine Leichenfledderung :wink:

Ich bin derzeit auf der Suche nach etwas in der Art, und daher sehr froh, geschätzte 90% der Arbeit nicht selbst/from scratch (inkl. der Fehler) machen zu müssen.

Ein Einsatzzweck wird die Korrektur von Geo-Koordinaten sein, darum wurden wir schon öfter mal gebeten (»könnt Ihr das nicht ändern, ich komm’ nicht dazu, den auszubauen«). Ein anderer ist die Korrektur von Migrationsfehlern, z. B. weil eine bestimmte Ressource zum Updatezeitpunkt nicht zur Verfügung stand und nur Defaults eingetragen wurden.

1 Like

Sehr nett. Aber irgendwie stehe ich etwas auf dem Schlauch. Habe dein Paket in unser eigenes Repo übertragen und versuche damit zu bauen. Bekomme allerdings ein „Package not found“ und er baut nichts.

Unser Repo: GitHub - freifunklippe/packages

Die korrekte Commit ID ist in der modules eingetragen. Was mag das sein? Hast du einen Tipp für mich?

@collimas : du hast 1. das package in die modules datei eingetragen? und 2. die modules unter gluon/site/ hinterlegt? und dann das wie hinzugefügt? …
der Fehler meint halt wohl genau das … irgendwo hast du was „vergeigt“ das er das nicht findet

überhaupt müsstest du ein eigenes repo anlegen - weil du ja dort die special treatment dateien anlegen willst … sonst macht das ganze packet keinen sinn

Ja, ist in unserem Repo gelandet, siehe Link bei meiner Frage. Die modules mit der richtigen commit id liegt unter gluon/site. In der site mk wurde eine Zeile "gluon-treatment " hinzugefügt.

ahja, seh das ihr ein package bundle habt, da könnt es sein das das Makefile nicht zu passt … ich hab bisher immer die packages einzeln in git repos gehabt und einzeln in den modules hinzugefügt - wie gesagt, er findet das paket nicht, wenn er die anderen findet, müsstest du herausfinden wo der unterschied ist …

Die anderen Pakete findet er ohne Probleme. Mit fällt auf, dass als Dependency das Paket gluon-core angegeben ist. Das installieren wir in unserer Firmware normalerweise nicht. Kann es sein, dass ich dieses in der site.mk aktivieren muss?
Gibt es noch weitere Möglichkeiten, einen solchen Fehler zu tracen?

so ohne richtiges log is das schwierig - bau doch mal mit den parametern V=99 | tee meinmake.lo
und schau das genau an, da steht welches package dann genau an welcher stelle fehlt. gluon core „muss“ glau nicht unbedingt (is schon ne weile her) aber micron.d wird sicher müssen!

Ein Log kann ich liefern.

Da liegen auch die modules und die Templates für site.conf und site.mk
Aber irgendwie sehe ich es nicht, Kannst du damit vielleicht etwas anfangen?
Ach so, ich habe das Paket in ein separates Repo geforkt. Bringt leider nichts.

  • Log-Download gelöscht *