fehlender Upgrade-weg nach Hedy

[SvenRoederer]

Es gibt im Moment keinen offiziellen Weg, um von Kathleen 0.3.0 auf Hedy-1.0.0 zu wechseln. für diesen Wechsel sollte eine "Migration" angelegt werden, wie bei den vorherigen Releases auch (https://github.com/freifunk-berlin/firmware-packages/tree/master/utils/freifunk-berlin-migration).

Primär wurde für Hedy-1.0.0 darauf verzichtet, weil keine personellen Ressourcen dafür vorhanden waren. Zu überlegen ist auch, wie die Migration der Uplink-konfiurationen machbar ist. Ein Wechsel zwischen verschiedenen Uplink-typen sollte möglich sein.

[SvenRoederer]

es fehlt mindestens:

• 330

• 375

• wechsel von 0.3.0 default-uplink (VPN03) zum aktuellen VPN03-flavor setup

[SvenRoederer]

ich hab mal ein Hedy-1.0.0 und ein Kathleen-0.3.0 aufgesetzt. Das V0.3.0 hab ich dann mit bb848483a88be00022bb13c0de9c6199dbd17a11 aktualisiert. Ein Diff über beide Archive gibt dann:

sven@hypnosis:~/freifunk/upgrade 0.3.0 to 1.0.1$ diff -uNr base/ update/ -q|sort Dateien base/etc/config/batman-adv und update/etc/config/batman-adv sind verschieden. Dateien base/etc/config/defaults und update/etc/config/defaults sind verschieden. Dateien base/etc/config/dhcp und update/etc/config/dhcp sind verschieden. Dateien base/etc/config/ffwizard und update/etc/config/ffwizard sind verschieden. Dateien base/etc/config/firewall und update/etc/config/firewall sind verschieden. Dateien base/etc/config/freifunk und update/etc/config/freifunk sind verschieden. Dateien base/etc/config/network und update/etc/config/network sind verschieden. Dateien base/etc/config/olsrd6 und update/etc/config/olsrd6 sind verschieden. Dateien base/etc/config/olsrd und update/etc/config/olsrd sind verschieden. Dateien base/etc/config/openvpn und update/etc/config/openvpn sind verschieden. Dateien base/etc/config/system und update/etc/config/system sind verschieden. Dateien base/etc/config/ucitrack und update/etc/config/ucitrack sind verschieden. Dateien base/etc/config/uhttpd und update/etc/config/uhttpd sind verschieden. Dateien base/etc/config/wireless und update/etc/config/wireless sind verschieden. Dateien base/etc/crontabs/root und update/etc/crontabs/root sind verschieden. Dateien base/etc/hosts und update/etc/hosts sind verschieden. Dateien base/etc/inittab und update/etc/inittab sind verschieden. Dateien base/etc/iproute2/rt_tables und update/etc/iproute2/rt_tables sind verschieden. Dateien base/etc/profile und update/etc/profile sind verschieden. Dateien base/etc/protocols und update/etc/protocols sind verschieden. Dateien base/etc/services und update/etc/services sind verschieden. Dateien base/etc/sysctl.conf und update/etc/sysctl.conf sind verschieden.

0.3.0_to_1.0.0.zip 1.0.0-fresh.zip

[SvenRoederer]

den vollen Diff kann man in 2 gruppen teilen,

• Freifunk-Berlin changes freifunk-changes.txt
• LEDE-changes lede-changes.txt

bis auf die Firewall-sachen sehen die Freifunk-berlin änderungen überschaubar aus. Was machen wir mit den Änderungen, die sich LEDE-seitig ergeben haben?

[SvenRoederer]

Dateien base/etc/config/network und update/etc/config/network sind verschieden.

is fixed by https://github.com/freifunk-berlin/firmware-packages/commit/6665da3c2fa1bf0c6b60d7d82e8b755cbb55bd9a

[SvenRoederer]

this is a gist of the full diff: https://gist.github.com/SvenRoederer/fb70b6937378ca9340557c6bd3e8c88a

[SvenRoederer]

according to https://gist.github.com/SvenRoederer/fb70b6937378ca9340557c6bd3e8c88a/2a8cd1ba5175a1db06c51ff414b780bd1f879d3a#file-pure-100_to_migrated-030-with-cb20306-diff :

• required to migrate
  • line 24
• to discuss:
  • line 37 ... line 164 (Firewall)
  • line 165 ... line 244 (freifunk-defaults - firewall section; this seems to relate to the different firewall-rules above)
  • line 245 & 246 (freifunk-defaults)
  • line 250 & 251 (freifunk-defaults)
  • line 259 ... line 285 (freifunk-defaults)
• OpenWrt-caused (will we care?)
  • line 295 ... line 297 (logging)
  • line 306 ... line 316 (NTP-Server)
  • line 325 ... line 327 (uci-track --> freifunk-policy-routing)
  • line 331 ... line 349 (uhttpd)
  • line 361 ... line 369 (/etc/hosts)
  • line 371 ... line 378 (/etc/inittab)
  • line 379 ... line 388 (/etc/iproute2/rt_tables)
  • line 389 ... line 449 (/etc/profile)
  • line 450 ... line 684 (/etc/protocols & /etc/services)
  • line 698 (sysctl --> net.ipv4.tcp_ecn=0)
• unknown status
  • line8

[bobster-galore]

• unknown status

  • line8 I think this is easy. If it's not there, we add that option (option 'vis_mode'). Unset is not very nice but it seems there is no setting or?

• required to migrate

  • line 24 We translate vpn03_openvpn '1' to option openvpn '1' and adjust the key-stuff for vpn03 since there can be no other than vpn03. We keep a flag for maybe other actions to take? Shall we issue a "it's deprecated!" warning? The migration-Hedy might come later than 12.05.18 so migration should not be blamed for low bandwidth.

• the large sections Would we exchange them as a whole? If there are "personal" settings I have no idea to parse and exchange them.

[SvenRoederer]

line8 - "batman-adv.vis_mode"

https://github.com/openwrt-routing/packages/commit/8a66ed185709df5b9120e602fda760969bebd632 from https://github.com/openwrt-routing/packages/pull/269 --> so it seems safe to ignore. But we can also remove this option, to keep the config tidy.

[SvenRoederer]

to discuss: line 37 ... line 164 (Firewall) line 165 ... line 244 (freifunk-defaults - firewall section; this seems to relate to the different firewall-rules above)

I suggest to leave these settings as they are. I think we should fix https://github.com/freifunk-berlin/firmware/issues/447 & https://github.com/freifunk-berlin/firmware/issues/486 before

[bobster-galore]

line8 - "batman-adv.vis_mode"

Since https://github.com/openwrt-routing/packages/commit/8a66ed185709df5b9120e602fda760969bebd632 says there is no option like this, we should remove this option, to keep the config tidy.

[bobster-galore]

I think we should fix https://github.com/freifunk-berlin/firmware/issues/447 & https://github.com/freifunk-berlin/firmware/issues/486 before The repeated entries is what was reported when running the wizard again. Unfortunately it doesn't happen always.

[SvenRoederer]

line 165 ... line 244 line 245 & 246 line 250 & 251 line 259 ... line 285

looks to me like this is caused by https://github.com/freifunk-berlin/firmware-packages/commit/a08be152151f9d89cde38dfac95d3359092e5aa1 . As noted in https://github.com/freifunk-berlin/firmware-packages/commit/0fab43b6a80841345cf66a4bf8f4f72dab77a664 and the referenced discussion we might just have to copy the current freifunk-defaults file from the /rom area and reapply our defaults (firmware-packages/defaults/freifunk-berlin-freifunk-defaults). This might be the best way on any release anyway.

[SvenRoederer]

As noted in freifunk-berlin/firmware-packages@0fab43b and the referenced discussion we might just have to copy the current freifunk-defaults file from the /rom area and reapply our defaults (firmware-packages/defaults/freifunk-berlin-freifunk-defaults).

just to copy the freifunk-file back as in https://github.com/freifunk-berlin/firmware-packages/commit/620e781f535d0572c5b055e927cddc501d610976 will cause to overwrite user-configured values

• freifunk.contact
• some of freifunk.community. these values had been filled by luci-mod-freifunk-ui (https://github.com/freifunk-berlin/firmware-packages/blob/cbea7a2fb7851c9b268ba6326150424cf9ab0d58/utils/luci-mod-freifunk-ui/luasrc/view/freifunk/index.htm#L47)

[sarumpaet]

Primär wurde für Hedy-1.0.0 darauf verzichtet, weil keine personellen Ressourcen dafür vorhanden waren.

Previously we had a simple policy: No migration present => no merging the PR. There was a reason for that, as uncomfortable as it was.

[SvenRoederer]

line 24 (https://gist.github.com/SvenRoederer/fb70b6937378ca9340557c6bd3e8c88a/revisions#diff-4de08bfd305a6dc708718d4ad82f6a07)

should be fixed by https://github.com/freifunk-berlin/firmware-packages/commit/31a592d13f1d3b9a5fd2a3202ddd3b800d96b9f0

[SvenRoederer]

line8

• there is a issue for this https://github.com/openwrt-routing/packages/issues/370, then this is fixed, we can again think of changing this
• as there is no functional use of this setting it will not cause any problem

[SvenRoederer]

line 325 ... line 327 (uci-track --> freifunk-policy-routing)

this item is at least one time setup in ucitrack from a former install-run of "freifunk-policyrouting" and each new install-run of the package just adds another item. So on a upgrade we just add it twice, which causes the diff, but can be ignored. There is a fix in https://github.com/openwrt/luci/pull/1774

[SvenRoederer]

with the enhanced migration from https://github.com/freifunk-berlin/firmware-packages/tree/a898d8172fb353c60d4d214c708d506e5735c20c the diff of the configs look like https://gist.github.com/SvenRoederer/fb70b6937378ca9340557c6bd3e8c88a/64ce023e5925276946b491336c782404d7390129

line 37 ... line 164 (Firewall) line 165 ... line 244 (freifunk-defaults - firewall section; this seems to relate to the different firewall-rules above)

I prefer to leave as it is, till a general fix is found --> https://github.com/freifunk-berlin/firmware/issues/447, https://github.com/freifunk-berlin/firmware/issues/486

The other items ("/etc/services", "/etc/protocols") are not relevant, imho

[SvenRoederer]

Please see https://github.com/freifunk-berlin/firmware-packages/pull/130

tested by me on GLinet-ar150, GLinet MT300n; by RainerS on WDR-3600

[SvenRoederer]

Buildbots are currently working on https://github.com/freifunk-berlin/firmware/commit/7fbcb7a107a6f9741b70f98613ba85d8a58f4220 which I named Hedy-1.0.1-rc1. This planned release will only provide the mirgation / upgrade from older releases. On top of this we should do Hedy-1.0.2 with updates and fixes

[SvenRoederer]

there is a Hedy-1.0.1-rc2 out since some time, which fixes the outdated packages-berlin feed used in rc1.

There have been several postings on the mailinglist, that some routers have been upgraded successfully. Let's release this as a maintenance-release rather soon.

[bobster-galore]

Since we fixed also the missing dnsmasq user and group for 4MB devices and there are no other reports of something that is missing. We should release soon!

To cite @sarumpaet "Previously we had a simple policy: No migration present => no merging the PR. There was a reason for that, as uncomfortable as it was."

At recent wcw18 I experienced on the OER workshop how valuable the "early" release of hedy is, we would have flashed "0" instead of "10" routers (archer c7 v2 EU/ v4) on that workshop. Furthermore on beginners workshop I only could recommend glinet ar150 routers because these are the only ones which are easy to buy w/o any revision and version hazzle.

Would be nice to have ff-firmware close to the market offering a sound choice of actual router models. If ff-firmware only supports outdated and not commercially available models, I think it's not that attractive to newbies.

[SvenRoederer]

@bobster-galore thanks for finding this dnsmasq user issue (https://github.com/freifunk-berlin/firmware-packages/pull/130#issuecomment-391089773), but as there have been reported no other problems the migration was merged into master. A hedy-1.0.1 packages release was made based on the hedy-1.0.0 with just migration and fixed download-URL for UBNT-snmp-mibs. Buildbots are working on this 5a94ff14ec87d089127a4f861c135d0f58c1f767 now.

I'll then clean the Hedy-1.0.1 branch that it can be used for a release.

[SvenRoederer]

https://github.com/freifunk-berlin/firmware/tree/Hedy-1.0.1 is rebased, cleaned and gives working images. Updating the docu is in process in https://github.com/freifunk-berlin/firmware/tree/prepare_Hedy101.

[sarumpaet]

At recent wcw18 I experienced on the OER workshop how valuable the "early" release of hedy is, we would have flashed "0" instead of "10" routers (archer c7 v2 EU/ v4) on that workshop

Why that? There's always the "master" build which is prominently shown by the util... download helper. The idea was to have "master" as a snapshot build that's reasonably safe to present to the user. An idea which was broken by merging things into master in a hurry, without migration.

Also, new hardware support doesn't need migrations, so supporting new hardware isn't held back by the "migration is needed for master PRs" policy, so what's the point?

[SvenRoederer]

The point is that new Hardware normally will not find it'S way into the OpenWrt "stable" branches (at least for some time not for 17.01). So new hardware is only for OpenWrt master (probably upcoming 18.06) which requires an more "unstable" master on our side. changing the OpenWrt brach will cause some more adaptions and probably migration.

[sarumpaet]

Huh? There's not a single migration in https://github.com/freifunk-berlin/firmware-packages/blob/master/utils/freifunk-berlin-migration/uci-defaults/freifunk-berlin-01-migration.sh because of upstream updates.

And in any case, why not have specific development branches for experimental/partially-broken (e.g., no migration) stuff (if you really need that) while retaining master as a relatively stable continuous build?

[SvenRoederer]

@sarumpaet it's there: https://github.com/freifunk-berlin/firmware-packages/blob/master/utils/freifunk-berlin-migration/uci-defaults/freifunk-berlin-01-migration.sh#L432

or what do you refer to? Can you please open a new issue?