NodeOS auto-updater

[mitsukaki]

I thought this might be a cool module to create. I wouldn't suggest we include it with NodeOS simply to remain simplistic but it could be installed by users. Optimally, the module would simply check for updates on the startup of a NodeOS session. This would be nice for users using a bare-metal installation. The installer would of course run within NodeOS.

I have a few questions however. Is this feasable without using Administrator Mode? Could the updates be cached and then implemented on a system restart? Wouldn't this require the module to be installed while in Administrator Mode?

I like the idea of this. What do y'all think?

[luii]

I kinda like the idea!
On system startup it just should check if newer version are available and notifiy the user but it should not install on its own!
It should install the updates when the system shuts down, but before shutting down it should ask if you want to install updates

But we should seperate system updates and package updates because the system updates like newer kernel and such things should only be installed on admin mode.
And package updates from npm should just be installed (but only when they're not system wide packages)

[piranna]

The more I think about it, the more I think it's a fantastic idea :-D Obviously this would not be on the core of NodeOS, but it would be nice to provide a module that users would install if they want.

I'm used to use the npm-check-updates module and works like a charm :-D so we could be able to use it to be able to check and update all the globally installed modules, and users could be able to exec it on their /init script. I think it would download the modules updated tarballk on the cache and later do the update from them. Obviously this would only be done for globally installed ones, since the locally ones can be installed anywhere :-P I'm not sure if the upgrade should be done on shutdown like Windows does or on boot by the same script, this would be easier since we don't need to update NodeOS to allow to exec scripts on shutdown, that also makes sense.

Global modules would be check and updated too, and would be done automatically on boot too, but this would need a careful thinking since this updates would run as root and so they could be an attack vector if a module gets an update with malware inside. It's an interesting point, but don't think of too much interest since scripts running as root should be minimal (mostly mounting the users partition).

Regarding the upgrade of the kernel... well, it could be done too!!! :-P I have been thinking if rootfs should be mount as /boot and upgrade the kernel version would be a valid use case, so who knows! :-D

[mitsukaki]

This is interesting discussion! Let's continue. As school comes to a close I will finally be able to continue contributing, and as I now have a few users who've opted in to beta test NodeOS-mobile the auto-updater seems more than reasonable.

On system startup it just should check if newer version are available and notifiy the user but it should not install on its own!
It should install the updates when the system shuts down, but before shutting down it should ask if you want to install updates

Interesting suggestion! With this autoupdater, I'm curious whether we ought to go the simplistic as possible route and set a bunch of defaults, or try and make everything configurable. Finding a nice inbetween is something we should pay a lot of attention to seeing that a lot of the people using it won't be advanced users.

But we should seperate system updates and package updates because the system updates like newer kernel and such things should only be installed on admin mode.

Yeah that makes sense. This leaves me with a question. Users can boot into administrator mode, but if an application, like the updater needs it, could it request a reboot into administrator mode? If a kernel update was available, the updater could simply reboot into administrator on shutdown, update the kernel, then turn off the device. (or boot into admin, update, the restart in normal mode if turning on the device and updating)

If we were to attempt to add this feature, it's important that users are querried first before restarting or that could definetely be a feature leveraged by malware.

I'm used to use the npm-check-updates module and works like a charm :-D so we could be able to use it to be able to check and update all the globally installed modules, and users could be able to exec it on their /init script.

Ah okay this sounds excellent! If we were to begin right away, we could build off this module to create the module updater. However, I do have a counter point. To voice simplicity, ought we include a module updater? Technically speaking, anyone wanting to update their modules on device should be using that module or something similar and all our updater would truly need to do is update NodeOS system related modules. What do you think?

Global modules would be check and updated too, and would be done automatically on boot too, but this would need a careful thinking since this updates would run as root and so they could be an attack vector if a module gets an update with malware inside.

Yes, auto updates are often a bad idea. I suggest we prompt users first, but this could definetely be a configurable feature. If a module got loaded while in administrator mode, who know's what could happen! (we all know).

Regarding the upgrade of the kernel... well, it could be done too!!! :-P I have been thinking if rootfs should be mount as /boot and upgrade the kernel version would be a valid use case, so who knows! :-D

This is an exciting idea! I do agree that the feature makes sense. Whether it is, or isn't practical to most users, that I don't know.

[piranna]

In this way, we could also configure nightly tasks to check external dependencies like new versions of the Linux kernel or of Node.js so new packages could be created and published automatically, and the auto-updater could be able to fetch them and have an up-to-date system without having any human harmed or involved in the process :-)

[mitsukaki]

human harmed or involved

haha, well said! Sounds like an excellent idea! Let's start at PR for it.

[mitsukaki]

And maybe we ought to create a thread too? We could just use the PR thread?

[piranna]

Maybe better an independent project, not inside NodeOS core. Remember, modularity and reusability ;-) This could be used on regular Node.js installations, too :-)

[piranna]

[piranna@Latitude:~/Proyectos/prebuild]
 (prerelease) > ncu -g -u

ncu cannot upgrade global packages. Run npm install -g [package] to update a global package

Seems it only last the last mile... :-) Two options, to do a pull-request on npm-check-updates to add that functionality (that since they only update the package.json file and don't do the updates themselves probably it would be discarded), or create a new project using it as dependency that does the real updates.

[mitsukaki]

@piranna I was referring to creating a PR for mounting rootfs as boot :P

[piranna]

Oh, I though you were talking about the auto-updater. They are two independent and unrelated things, and in fact mounting rootfs as /boot don't have too much mistery and it's just a matter of a single line of code, that's why I was not thinking about it... I will accept your pull-request when you have it ready, but we should focus on the auto-updater tool since it's needed first to have it working :-)

By the way, we have open other issues for 1.0 version like the nsh update (my fault...) and the git client, how are they going?

[mitsukaki]

By the way, we have open other issues for 1.0 version like the nsh update (my fault...) and the git client, how are they going?

Git has made no progress from my understanding. I'm contemplating taking it on in the summer.
Nsh update :P no idea!

And yes I'm working on the auto-updater as we speak on 'noUpdate' repo on my page. I know what needs to be done for mounting but if you have a free hand right now, we could save manpower if you went ahead and did it right now.

(I'd have to go hunt which file needs changes because I forget which script does the mounting...)