updater issueshttps://gitlab.nic.cz/turris/updater/updater/-/issues2024-03-25T15:28:43+01:00https://gitlab.nic.cz/turris/updater/updater/-/issues/330More detailed User-Agent header2024-03-25T15:28:43+01:00Lukas JelinekMore detailed User-Agent headerIt would be good to provide more information inside the `User-Agent` header. I suggest especially these ones:
- Precise specification of the given Turris OS version (Build ID) - it would be useful to distinguish between multiple release...It would be good to provide more information inside the `User-Agent` header. I suggest especially these ones:
- Precise specification of the given Turris OS version (Build ID) - it would be useful to distinguish between multiple release candidates, nightly builds etc.
- Device type including its revision and HW architecture - it can be partially detected from accessed paths but it generates additional overhead
### Current header
```
Turris Updater/70.0.0 (TurrisOS 6.0.3)
```
### Proposed header
```
Turris Updater/70.0.0 (TurrisOS 6.0.3; r16703+129-079ce0413a; Turris Omnia/v0; arm_cortex-a9_vfpv3-d16)
```https://gitlab.nic.cz/turris/updater/updater/-/issues/324Add another updater mode: approvals with good update confirmation2022-02-14T23:43:41+01:00Martin PeckaAdd another updater mode: approvals with good update confirmationHi, regarding to the occasional reports on forum from people with failed updates of routers they can't physically access, I think implementing another updater mode would help them a lot.
You’d basically install a cron job to revert the ...Hi, regarding to the occasional reports on forum from people with failed updates of routers they can't physically access, I think implementing another updater mode would help them a lot.
You’d basically install a cron job to revert the update before executing it, and the user would need to manually connect to the router and click a button in Reforis to confirm the update went well. If not, the router would automatically revert the update and reboot after some time. Of course, that’s not the best idea with MOX, but on Omnia, it could be pretty useful (I’m myself doing something similar manually).
This way, I could update the remote Omnias much quicker without fear that there will be undesired downtime. The downtime would be limited to tens of minutes max if the update fails.https://gitlab.nic.cz/turris/updater/updater/-/issues/314Take in to considerations priorities in plan ordering2022-06-06T14:11:02+02:00Karel KociTake in to considerations priorities in plan orderingWe have priority of packages and they should be installed in that priority. It is weak order requirement we should include. It also improves update in general.We have priority of packages and they should be installed in that priority. It is weak order requirement we should include. It also improves update in general.https://gitlab.nic.cz/turris/updater/updater/-/issues/313Add FilesSignature2021-06-11T08:24:02+02:00Karel KociAdd FilesSignature`FilesSignature` should be same extension as `LinkSignature` but assembled from list of files.
Originally I thought that we do not need this but it turns out that sometimes patches do not bump version but add/remove files. This can caus...`FilesSignature` should be same extension as `LinkSignature` but assembled from list of files.
Originally I thought that we do not need this but it turns out that sometimes patches do not bump version but add/remove files. This can cause collision but only in existing installations. This can be in the end pretty hard to detect. We should cover this even when this does not happen so often because of that.https://gitlab.nic.cz/turris/updater/updater/-/issues/312Reinstall check should also tak in to consideration other fields2022-06-06T14:15:04+02:00Karel KociReinstall check should also tak in to consideration other fieldsAt the moment we reinstall when one of these fields change: `"Version", "Architecture", "LinkSignature", "Depends", "Conflicts", "Provides"`. We should reinstall also on other fields.
These fields are used in OpenWrt and make sense to t...At the moment we reinstall when one of these fields change: `"Version", "Architecture", "LinkSignature", "Depends", "Conflicts", "Provides"`. We should reinstall also on other fields.
These fields are used in OpenWrt and make sense to trigger reinstall on them:
* Essential (although we do not use this)
* Conffiles
* Alternativeshttps://gitlab.nic.cz/turris/updater/updater/-/issues/306Preserve modified orphan config files for even installed packages2023-05-30T14:39:37+02:00Karel KociPreserve modified orphan config files for even installed packagesAt the moment when package is removed and it contains configuration file we keep it in database to track modified config. Problem is that we do not do the same if package is upgraded and removes configuration. We just remove modified con...At the moment when package is removed and it contains configuration file we keep it in database to track modified config. Problem is that we do not do the same if package is upgraded and removes configuration. We just remove modified configuration in such case.
The reason why we should not do it is to on one side preserve configuration modifications by users even if that might mean keeping around no longer used files. The second reason and more important one is that this might be just an issue in package and new version can revert to it as well as some other new package can take ownership of it. We should not reset config in such case.https://gitlab.nic.cz/turris/updater/updater/-/issues/302Allow (or check if possible) replan on virtual package2020-06-15T12:15:06+02:00Karel KociAllow (or check if possible) replan on virtual packageDoing replan on specially immediate one on virtual package turns out to be pretty useful. The point is that you can just line all package you want to update once before you reexecute updater without needing to select one of them to be th...Doing replan on specially immediate one on virtual package turns out to be pretty useful. The point is that you can just line all package you want to update once before you reexecute updater without needing to select one of them to be the root of three and inserting others as additional dependencies. The reason is that might not be always possible such as if that creates cycle that just can't be broken. With such cycle updater possibly won't allow update as updater is critical package.
I am convince that using virtual packages do not work at the moment with replan as those are ignored when plan is created. This means that with routine cutting away plan in case of replan won't cut it simply because there is not package to cat plan at.https://gitlab.nic.cz/turris/updater/updater/-/issues/300Detect broken Internet connection2023-08-16T14:59:54+02:00Vojtech MyslivecDetect broken Internet connectionWhen a WAN is down and Internet connection is not available, updater "spam" Foris notifications with:
```
unreachable: https://repo.turris.cz/omnia/lists/base.lua: Couldn't resolve host 'repo.turris.cz'
```
which is a bit cryptic, espec...When a WAN is down and Internet connection is not available, updater "spam" Foris notifications with:
```
unreachable: https://repo.turris.cz/omnia/lists/base.lua: Couldn't resolve host 'repo.turris.cz'
```
which is a bit cryptic, especially for new Turris users.
It would be really nice to enhance user experience and lower "false issues" [like that](https://forum.turris.cz/t/nemohu-resolvovat-repo-turris-cz/12907) (that's really not unique).Turris OS 5.1https://gitlab.nic.cz/turris/updater/updater/-/issues/299Make missing package hash fatal error2020-11-24T13:57:24+01:00Karel KociMake missing package hash fatal errorTo ensure that packages are verified we should check and not install package if there was no hash verification in place.
To enable override of this we should add `unsecure` extra option for package list to allow no hash verification opt...To ensure that packages are verified we should check and not install package if there was no hash verification in place.
To enable override of this we should add `unsecure` extra option for package list to allow no hash verification optionally (such as for localrepo).Turris OS 5.2.0https://gitlab.nic.cz/turris/updater/updater/-/issues/294Check collisions between Alternatives and files/links2022-06-06T14:25:05+02:00Karel KociCheck collisions between Alternatives and files/linksWe should check for collisions between alternatives and other files. Right now we just overwrite any existing link in place but that is not ideal.
The collision checking should discover following problem: https://gitlab.labs.nic.cz/turr...We should check for collisions between alternatives and other files. Right now we just overwrite any existing link in place but that is not ideal.
The collision checking should discover following problem: https://gitlab.labs.nic.cz/turris/turris-build/issues/122
We should also handle the same way all links. We can insert links from packages with priority 0. That way we can fallback on them if Alternatives package is removed and no other alternative (over just original package) was left in system.https://gitlab.nic.cz/turris/updater/updater/-/issues/289Change how approvals work to instead call hook2020-10-15T15:11:16+02:00Karel KociChange how approvals work to instead call hookCurrently approvals generate to provided path file that requests approval. Next run user can use hash from that file to approve those changes.
This is not ideal I feel and much less complicated and direct would be to just use hooks. We ...Currently approvals generate to provided path file that requests approval. Next run user can use hash from that file to approve those changes.
This is not ideal I feel and much less complicated and direct would be to just use hooks. We could have approval hooks that are called to decide if update is approved. There can be more than one approval script so approve can be done by more than now one fixed way.
Updater should provide hook with list of changes and expect it to exit in specific way to signal one of three states:
* undecided
* deny
* approve
When at least one script provides deny or approve than such action is performed. No other script should be executed after that. Undecided result forwards updater on to another hook.https://gitlab.nic.cz/turris/updater/updater/-/issues/283Retrieve TOS version from updater2019-10-14T14:40:23+02:00Martin MatějekRetrieve TOS version from updaterUseful mainly for foris-controller.Useful mainly for foris-controller.Turris OS 4.0.2https://gitlab.nic.cz/turris/updater/updater/-/issues/281Suppress only immediate replan with `--no-replan` option2022-06-06T14:27:50+02:00Karel KociSuppress only immediate replan with `--no-replan` optionReplan makes sense to be used to not only update updater self (immediate) but also to apply changes to updater configuration introduced from packages. The problem with disabling replan because we don't want to immediate replan is that th...Replan makes sense to be used to not only update updater self (immediate) but also to apply changes to updater configuration introduced from packages. The problem with disabling replan because we don't want to immediate replan is that those configs are not considered and ignored.
We should either introduce new `--no-immediate-replan` and change `--out-of-root` to include that one. Or we can just replace behavior of `--no-replan` to disable only immediate replan.https://gitlab.nic.cz/turris/updater/updater/-/issues/272Add support for PKG_UPGRADE variable in package scripts2020-01-29T14:50:07+01:00Karel KociAdd support for PKG_UPGRADE variable in package scriptsThis variable seems to be set to `1` when package is updated. Up to my knowledge we are not doing that (although I haven't looked in to the code).
We should probably introduce it. There is small problem with it that we do not know if it...This variable seems to be set to `1` when package is updated. Up to my knowledge we are not doing that (although I haven't looked in to the code).
We should probably introduce it. There is small problem with it that we do not know if it is a new installation or not in location where we generate those variables, we know only that we have to install it. It should not be hard to see if package is already installed but it is not directly accessible in that code location.https://gitlab.nic.cz/turris/updater/updater/-/issues/262Add mode in which pkgupdate reinstall all packages2019-09-27T12:51:52+02:00Karel KociAdd mode in which pkgupdate reinstall all packagesThis should "solve" problem when we switch between branches. In single branch we have script that bumps packages and forces updater to reinstall them but between branches we have nothing like that. The good enough hack is to reinstall ev...This should "solve" problem when we switch between branches. In single branch we have script that bumps packages and forces updater to reinstall them but between branches we have nothing like that. The good enough hack is to reinstall everything every time. This can be archived easily just by not filtering out installed packages (causing reinstall instead). So this is option to skip single check in code.Turris OS 4.0https://gitlab.nic.cz/turris/updater/updater/-/issues/258Test that we don't left any garbage in tmpdir2019-05-24T09:36:45+02:00Karel KociTest that we don't left any garbage in tmpdirWe have ability to set tmpdir for all tests so we can do that and check if none of them left some garbage there. The idea is that we can detect if even on error we remove our temporally files.
Currently we are not verifying this at all.We have ability to set tmpdir for all tests so we can do that and check if none of them left some garbage there. The idea is that we can detect if even on error we remove our temporally files.
Currently we are not verifying this at all.https://gitlab.nic.cz/turris/updater/updater/-/issues/257localrepo: architecture of package should be checked and support for non-nati...2019-05-06T17:47:29+02:00Karel Kocilocalrepo: architecture of package should be checked and support for non-native ones should be addedCurrently we do not check if added package is of native architecture. We should do that.
That also introduced new problem and that is what if we want to use localrepo to maintain repository for non-native packages. This should be used f...Currently we do not check if added package is of native architecture. We should do that.
That also introduced new problem and that is what if we want to use localrepo to maintain repository for non-native packages. This should be used for rootfs preparation on Omnia for Mox. We need some approach on how to maintain non-native architecture local repositories because of that.https://gitlab.nic.cz/turris/updater/updater/-/issues/256Change user agent to contain additional information2019-05-06T17:46:46+02:00Karel KociChange user agent to contain additional informationWe should add additional information to user agent. Currently we only report updater version but it is common to also report the OS version, kernel version and network software version. This should help us to discover problematic clients...We should add additional information to user agent. Currently we only report updater version but it is common to also report the OS version, kernel version and network software version. This should help us to discover problematic clients and detect if some combination of software is not failing because of our server configuration.
Current user agent contains only updater version in following format: `"Turris Updater/" UPDATER_VERSION`
I suggest to append additional information in standard form: `"Turris Updater/" UPDATER_VERSION (ADD1; ADD2)`
Additional information should be:
* Version and name of distribution
* Architecture and kernel version and name
* Version of libcurlTurris OS 4.0https://gitlab.nic.cz/turris/updater/updater/-/issues/246Differenciate between failure in script from critical and non-critical packages2022-06-06T14:32:45+02:00Karel KociDifferenciate between failure in script from critical and non-critical packagesWhen some script (postinst, prerm,..) fails then we should (and I hope that we do) print error to user. But it's more or less warning in this sense. If some tiny package fails it's postinst then it should be warning. But that is not same...When some script (postinst, prerm,..) fails then we should (and I hope that we do) print error to user. But it's more or less warning in this sense. If some tiny package fails it's postinst then it should be warning. But that is not same if kernel fails its postinst. So all packages requested as critical should result to error to be reported to user but anything else should be warning.https://gitlab.nic.cz/turris/updater/updater/-/issues/245Replace updater.sh with updater-suppervisor.py or something2019-05-06T17:47:32+02:00Karel KociReplace updater.sh with updater-suppervisor.py or somethingIt's clear that updater.sh is now in state where it's almost unmaintable and there is requirements from foris to post updater's state to foris-controller. It's clear that we would have to implement some suppervising daemon for updater (i...It's clear that updater.sh is now in state where it's almost unmaintable and there is requirements from foris to post updater's state to foris-controller. It's clear that we would have to implement some suppervising daemon for updater (it might be running only if updater is running. In different words it would be executed and killed by updater.sh). But there might be even better solution for this. What about if we create updater-suppervisor.py (or some better name?) instead of updater.sh or as something that updater.sh runs. That would replaced current functionality of updater.sh with cleaner code and could also post status of updater to foris-controller on its own.