freifunk-franken
/
firmware
9
7
Fork 13
Code Issues 48 Pull Requests 7 Releases 17 Wiki Activity

fff-nodewatcher: Improve package #99

Closed
adschm wants to merge 4 commits from adschm:nodew into master
pull from: adschm:nodew
merge into: freifunk-franken:master
Conversation 1 Commits 4 Files Changed 5 +15 -12
adschm commented 2021-01-31 13:59:26 +01:00
Owner
Copy Link

This contains several organizational and one functional change to improve the usability of the nodewatcher package.

This contains several organizational and one functional change to improve the usability of the nodewatcher package.
adschm added the
packages/fff
 label 2021-01-31 13:59:26 +01:00
adschm added 4 commits 2021-01-31 13:59:26 +01:00
b08694359a fff-nodewatcher: consolidate uci-defaults scripts 
The uci-defaults scripts are meant to provide defaults for a
specific package. Distributing them across several packages makes
no sense and just makes maintainance worse.

Thus, move the network part of the initialization back to the
proper package. While at it, suppress output from add commands.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
2a970972a3 fff-nodewatcher: only run uci-defaults once 
If /etc/config/nodewatcher already exists, a proper uci-defaults
script should not overwrite it. Since this package is the owner
of the config file, this change won't change anything for the
current firmware, but will allow to use this as a package, too.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
fba996f30f fff-nodewatcher: specify config file as config file 
This package is the owner of the config file, so add it to the
Makefile. This will have vanilla OpenWrt copy it during upgrade.

Since we disable this mechanism, it will not change anything for
our standard firmware.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
43ac6a5daa fff-nodewatcher: add config option to disable nodewatcher 
This adds an option 'disabled' that will allow to disable
nodewatcher when desired.

Signed-off-by: Adrian Schmutzler <freifunk@adrianschmutzler.de>
rohammer reviewed 2021-02-08 19:34:35 +01:00
src/packages/fff/fff-nodewatcher/Makefile
@ -22,1 +22,4 @@
define Package/$(PKG_NAME)/conffiles
/etc/config/nodewatcher
endef
rohammer commented 2021-02-08 19:34:35 +01:00
Member
Copy Link

hi, kannst du mir mal kurz erklaeren, was das define Package/xx/conffiles macht. Was ich dazu gefunden habe ist nicht befriedigend.

hi, kannst du mir mal kurz erklaeren, was das define Package/xx/conffiles macht. Was ich dazu gefunden habe ist nicht befriedigend.
adschm commented 2021-02-08 19:55:10 +01:00
Author
Owner
Copy Link

OpenWrt sieht vor, dass config-Files einmalig erstellt werden; entweder beim ersten Boot für eingebaute Packages oder beim Installieren für Packages via opkg. Führt man dann ein sysupgrade durch, wird nicht wie bei unserer Firmware alles wieder gelöscht, sondern die config bleiben grundsätzlich erhalten. Welche config-Files das genau sind, wird u.a. hier festgelegt:
https://github.com/openwrt/openwrt/blob/master/package/base-files/files/sbin/sysupgrade#L142

Genau dort greifen wir bei unserer Firmware auch ein, und ändern das mit dem ersten(?) build-Patch ab.
Wie du siehst, gibt es mehrere Quellen für solche Dateien:
/etc/sysupgrade.conf, /lib/upgrade/keep.d, ...

Ein anderes subset wird von opkg verwaltet, und lagert hier (kuck mal bei nem richtigen OpenWrt rein):
/usr/lib/opkg/status

Dort sind status-Daten zu allen Packages enthalten, inklusive der definierten conffiles inkl. hash. Sysupgrade hebt bei vanilla-OpenWrt nun alle Conf-Files auf, die hier gelistet sind, und deren hash sich vom default unterscheidet (zumindest habe ich das so verstanden). Umgekehrt wird eine Datei, die weder in /etc/sysupgrade.conf etc. noch hier gelistet ist, beim upgrade verworfen, auch wenn sie in /etc/config/ liegt.

So, warum nun das Ganze:
Ich möchte die Packages so modifizieren, dass man sie mittelfristig auch einfach als feed mit vanilla-OpenWrt bauen kann (lokal ist das schon fertig). Diese Änderung hier ist dabei insofern hilfreich, als nun bei vanilla-OpenWrt die /etc/config/nodewatcher, die der nodewatcher-Package "gehört", nun korrekt über ein Upgrade hinweg erhalten bleibt. Weiterhin bleibt jedoch das Verhalten der buildscript-basierten Firmware davon unbeeinflusst, weil diese ja den entsprechenden Upgrade-Mechanismus komplett abschaltet. Ich kann mit der Änderung also beide Szenarios sauber unterstützen, und genau das ist das Ziel.

OpenWrt sieht vor, dass config-Files einmalig erstellt werden; entweder beim ersten Boot für eingebaute Packages oder beim Installieren für Packages via opkg. Führt man dann ein sysupgrade durch, wird nicht wie bei unserer Firmware alles wieder gelöscht, sondern die config bleiben grundsätzlich erhalten. Welche config-Files das genau sind, wird u.a. hier festgelegt: https://github.com/openwrt/openwrt/blob/master/package/base-files/files/sbin/sysupgrade#L142 Genau dort greifen wir bei unserer Firmware auch ein, und ändern das mit dem ersten(?) build-Patch ab. Wie du siehst, gibt es mehrere Quellen für solche Dateien: /etc/sysupgrade.conf, /lib/upgrade/keep.d, ... Ein anderes subset wird von opkg verwaltet, und lagert hier (kuck mal bei nem richtigen OpenWrt rein): /usr/lib/opkg/status Dort sind status-Daten zu allen Packages enthalten, inklusive der definierten conffiles inkl. hash. Sysupgrade hebt bei vanilla-OpenWrt nun alle Conf-Files auf, die hier gelistet sind, und deren hash sich vom default unterscheidet (zumindest habe ich das so verstanden). Umgekehrt wird eine Datei, die weder in /etc/sysupgrade.conf etc. noch hier gelistet ist, beim upgrade verworfen, auch wenn sie in /etc/config/ liegt. So, warum nun das Ganze: Ich möchte die Packages so modifizieren, dass man sie mittelfristig auch einfach als feed mit vanilla-OpenWrt bauen kann (lokal ist das schon fertig). Diese Änderung hier ist dabei insofern hilfreich, als nun bei vanilla-OpenWrt die /etc/config/nodewatcher, die der nodewatcher-Package "gehört", nun korrekt über ein Upgrade hinweg erhalten bleibt. Weiterhin bleibt jedoch das Verhalten der buildscript-basierten Firmware davon unbeeinflusst, weil diese ja den entsprechenden Upgrade-Mechanismus komplett abschaltet. Ich kann mit der Änderung also beide Szenarios sauber unterstützen, und genau das ist das Ziel.
rohammer commented 2021-02-08 20:23:13 +01:00
Member
Copy Link

Danke dir!

Ich finde die Moeglichkeit unsere packages mit openwrt zu bauen oder mit opkg nachinstallieren zu koennen richtig klasse. Zumindest fuer die layer3-variante. Das habe ich bisher haendisch gemacht, was doch ein gewisser Konfigurationsaufwand ist.

Danke dir! Ich finde die Moeglichkeit unsere packages mit openwrt zu bauen oder mit opkg nachinstallieren zu koennen richtig klasse. Zumindest fuer die layer3-variante. Das habe ich bisher haendisch gemacht, was doch ein gewisser Konfigurationsaufwand ist.
rohammer approved these changes 2021-02-08 20:23:47 +01:00
rohammer left a comment
Member
Copy Link
Reviewed-by: Robert Langhammer <rlanghammer@web.de>
``` Reviewed-by: Robert Langhammer <rlanghammer@web.de> ```
adschm commented 2021-02-27 16:16:01 +01:00
Author
Owner
Copy Link

Danke, ich habe das auch zu meinem staging-Tree hinzugefügt.

PKG_RELEASE bump habe ich jetzt nur noch am Schluss gemacht, so können wir noch ein paar Commits sammeln für den COMMITCOUNT patch.

Danke, ich habe das auch zu meinem staging-Tree hinzugefügt. PKG_RELEASE bump habe ich jetzt nur noch am Schluss gemacht, so können wir noch ein paar Commits sammeln für den COMMITCOUNT patch.
adschm closed this pull request 2021-02-27 16:16:01 +01:00
adschm deleted branch nodew 2021-02-27 16:16:07 +01:00

Pull request closed

This pull request cannot be reopened because the branch was deleted.
Sign in to join this conversation.
Reviewers
No reviewers
rohammer
Labels
Clear labels   
RFC

   
RFT

   
WIP

   
blocked

   
bsp

touching bsp files or adding devices

  
bug

Something is not working

  
build/scripts/tools

touching buildscript or other tools

  
duplicate

This issue or pull request already exists

  
feature

New feature

  
fixed

Issue that got resolved

  
layer3

only for layer3 FW

  
mantis

Imported from mantis

  
more details required

Reported information is insufficient to debug the issue

  
needs changes

   
node

only for node FW

  
packages/fff

touching our packages

  
rejected

Rejected or won't fix

  
security

   
trivial

simple non-functional changes that are mostly matter of taste

  
upstream

touching upstream version, build or feed patches

No Label
RFC
RFT
WIP
blocked
bsp
bug
build/scripts/tools
duplicate
feature
fixed
layer3
mantis
more details required
needs changes
node
packages/fff
rejected
security
trivial
upstream
Milestone
Clear milestone
No items
No Milestone
Assignees
Clear assignees
No Assignees
2 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: freifunk-franken/firmware#99
No description provided.
Delete Branch "adschm:nodew"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?