previously, we had a singleton 'main' flag to indicate a site can
be used for updates. with this new approach, we can get rid of the
'primary' concept. each site can be used for updates or not.
1. add setup, teardown hooks
2. move the managed mount setup and teardown to filesystem backend
3. remove this vague storage.js
we should convert storageApi into a real object, so we don't have to
keep passing apiConfig around
format is part of the backup target
in the future, if we want per-app format or schedule, we can add this
separately to the apps table itself. the full box backup can ignore
apps with a set backup target and use the latest backup (like an errored app).
the nice thing is restore will work correctly.
what's important:
* if task code ran, it exits with 0. this code is regardless of (error, result)
* when it exited cleanly, we will get the values from the database
* if task timed out, the box code kills it and it has a flag tracking timedOut. we can
ignore exit code in this case.
* if task code was stopped, box code will send SIGTERM which ideally it will handle and end with 70.
* if task code crashed and it caught the exception, it will return 50
* if task code crashed and node nuked us, it will exit with 1
* if task code was killed with some unhandleabe signal, taskworker.sh will return the signal (9=SIGKILL)
this is now moved entirely to cloudron-support --enable-remote-access.
this emphasizes more that users have to get ssh access to the server before
we can do anything about it. it's far too simple for people to click this
button.
we have now also added clear terms to understand what remote access entails.
(what happens if support personnel makes a mistake. who is liable? etc)
Girish Ramakrishnan