Nach dem Umzug der Gluon-Bäckerei in eine VM habe ich für Lohmar eine 2.7-stable-rsk gebacken auf Basis von Gluon 2.4.1 und an der Hauptstrasse einige Router damit in den Testbetrieb genommen.
Das Schema zeigt die VM und die Anbindung fürs Monitoring über collectd inkl. Einspeisung in influxdb und Verarbeitung mit Grafana.
In der VM sind alfred, batman-adv und hopglass Server noch nicht scharf. Leistungsdaten aus Lohmar werden momentan noch über citylight eingesammelt und über public Net zum Server geschaufel - das kann sich dann ändern, wenn die vm01 ins Netz einwählt und die Daten direkt sammelt.
Ihr habt eine spezielle Firmware für eine Backerei-Kette gemacht?
Was macht ihr da denn anders als „bei der normalen Firmware“? (Ich hoffe jetzt mal, nicht eine Flash-Page. Preinstalled SSH-Keys für einfacheres Deployment? Das Collectd-Monitoring ist dann speziell für das Projekt?)
Was die Gluonversion „2.4.1“ anbetrifft: Das war, was mich eigentlich getriggert hat, hier überhaupt hineinzuschauen, da es doch nur (laut Bild) ein gluon 2016.2.4 zu sein scheint.
Witzig, das dachte ich im ersten Moment auch, aber dann bin ich davon ausgegangen, dass dies schlicht der Name der VM ist in der die Images gebaut werden.
Genau so ging es mir auch, bin stets an sinnvollem Monitoring interessiert und frage mich auch was es mit der Versionsnummer auf sich hat.
@adorfer. Firmware backen = Gluon Bäckerei - reine Funktionsbeschreibung der Umgebung in der VM
ansonsten kommen da die rsk-pakete rein, die mittlwerweile auch von Stefan’s Firmware Backstube in die images eingebacken werden. Doku mit uci parametern dazu hatte ich bereits gepostet.
collectd ist nur transportweg ab citylight – im image laufen weiterhin die standard-tasks
Bevor ich Stefan Änderungen ins git repo gebe, teste ich den code erstmal im laufenden Betrieb.
@adorfer. Firmware backen = Gluon Bäckerei - reine Funktionsbeschreibung der Umgebung in der VM
ansonsten kommen da die rsk-pakete rein, die mittlwerweile auch von Stefan’s Firmware Backstube in die images eingebacken werden. Doku mit uci parametern dazu hatte ich bereits gepostet.
Wäre es nicht sinnvoller eine allgemein gebräuchliche Terminologie zu verwenden?
Die richtige Bezeichnung wäre „Build Server“ und Features werden nicht eingebacken sondern integriert.
Sowas schreckt halt Leute ab die das ganze auf einem professionellem Level unterstützen wollen und gibt eben evtl den falschen Eindruck das die Personen hinter dem Projekt eher Laien sind.
