@admins: please move to correct category if needed (and delete this line afterwards).
Simply delaying the reboot of an update doesn’t solve the following problems:
the configuration before the update could already break the functionality; hence in productive enviroments (or with room-/housemates/-wives/… that start making really problems not having network access) one would want to check if others (“early adopters”) come up with problems before installing it.
persons with special security/privacy needs want to check each (updated) packet before updating the router
one simply doesn’t like “forced” updates
“once burned, twice cautious” - update can in special situations (which the developers will never be able to completely foresee) completely or partially break functionality and one would want to check if others (“early adopters”) come up with problems before installing it.
the foris users are at a high percentage IT geeks/professionals and are used to troubleshoot etc and therefore don’t need immediate automatic updates
…
Therefore there are several options / questions / proposals how to change the update procedure (I will update this as soon as others provide more opportunities):
As a base I’d like to mention the options of Windows 7:
automatically install when available and reboot instantly after update
automatically install when available but reboot when user’s ready to do so
inform that update is available but don’t install automatically
don’t inform about available updates and don’t install automatically
downloading the full set of updates packages and dependencies at the random time, but only installing later at a fixed time or following a reboot, and only if there are no missing packages or conflicts.
Even more conservative: Simply show the option (perhaps inform that an upgrade is available per email or Turris app) to upgrade with detailed information on every change that will be made and allow the user to manually upgrade or not.
[quote=“doctorjames, post:2, topic:4948”]
[Show that an upgrade is in progress by] Maybe different flashing [light] sequences for the phases of the update too in case it gets stuck for some reason (such as with my case where I had a non-standard DNS forwarding setup and the kresd behaviour changed)
[/quote]
Yes, that’s an excellent idea. Maybe different flashing sequences for the phases of the update too in case it gets stuck for some reason (such as with my case where I had a non-standard DNS forwarding setup and the kresd behaviour changed).
I previously installed the Turris app on my phone so that could be another way to display a message about an update in progress, though obviously the message would have to be pushed before the network was modified. (I didn’t see any messages this time due to multiple reboots, but unfortunately for the last Turris OS update the messages were shown in Czech despite both the phone and Omnia being set to use the English locale).
We don’t want this as that would mean router restart durring day time.
We have this
We have this now with approvals.
This is disabled updater.
Most of these issues are solved by approvals. Now if you want you can check what changes will be applied. Maybe what there should be now added is more management tools. Like for example warning about edited files replaced by following update.
Also I don’t agree with you at some points like for example:
This is simply not true. If you are geek than you probably using Foris just sporadically and using Luci or SSH instead.
You don’t have to update. But than we provide you no support. Updating from older versions than previous stable (with some exceptions of factory images we shipped routers with) are not directly supported and tested. In that case you are on your own (although you can ask us). So we don’t want to force updates but we have to.
And it’s not exactly hard to do. I will look in to it some time in future.
Well we could send notification about new update (I think that mobile application won’t show it because it fetches those every time you start it) but it would landed in your email box which is not perfect as you might not have internet connection. So I think that better options is to have approvals enabled with for example 24 delay.
Well that application is weird. Person developing it is no longer in firm and we have nobody to develop it now. We are kind of in no point with it and looking for solution (developers to develop it).
I’ve got another idea: Differentiate security updates (+ bug fixes) and the new releases:
For security updates / bug fixes, I want to have them automatic, as soon as possible (and I expect they do not modify behavior, just address some bugs). I also do not expect these would break things (i.e. no changes of configuration files which would cut the service off completely).
For new releases I personally prefer to have it on “approval needed” - and I would really like the release notes too, so I can prepare for it and take my time to do upgrade manually (because I use few customizations that might need adaption, as I have learnt during upgrade to 3.8). Some others might choose automatic here instead (those who use only Foris for their setup should be safe here).
Now I set it to “approval needed” for all, which is not ideal, even important security updates will wait for my action and I might be unable to do that for several days or even weeks (but it’s still much better for me than end up with broken service).
That’s not so easy. You can’t just take “security updates” and apply them to whatever old version you have.
EDIT: bigger distributions (or even packages) maintain multiple branches for this purpose, but I don’t think the Turris project would like to pay the extra work in maintenance.
I think that Turris Team already does it; When there is bug or security issue, they roll updated package ASAP (they do not wait for next release).
By the way, security is never easy. And Turris project always claimed they do care about security a lot (it started as security research project AFAIK), so I believe guys from Turris Team will never use “that is not so easy” as an excuse when it comes to security.
I will still wait for their opinion about my proposal.
They do that. But if there was a feature update that you skipped (like 3.8) and a security problem came afterwards, they will only fixup 3.8 and not 3.7 or 3.6. So, if you don’t delay too long, what you propose would work. IMHO it’s basically solved by the option of delayed updates that you can explicitly approve, but I’ll look forward to their opinion.
We can do that. Let me state it more technically. We can do automatic approvals for fixup releases (X.X.?). That would be possible, although not easy and not too reliable (I would check version of package turris-version in generated plan). So yes we can do that and I will think about that. It makes sense. But problem is that this works only till we release new minor or major release. We are not big distribution so with release of new stable version we are no longer supporting original minor version. So no security fixes are release so it helps with security but only partially.