Cloudron 5.6.2

[jdaviescoates]

@d19dotca OK, so maybe in Branding there could be a checkbox "display version number in footer" and anyone who doesn't want it displayed there (although again I note that no one has expressed this view as far as I'm aware) could uncheck the box?

[d19dotca]

I updated my Cloudron server tonight to 5.6.2, and notice some strange behaviour, wanted to raise it in case it's an issue that needs to be fixed or if it's just a random issue in my environment.

Oct 11 21:17:14 box:syncer Done processing adds null
Oct 11 21:17:14 box:shell backup-snapshot/box (stdout): 2020-10-12T04:17:14.158Z box:backupupload upload completed. error: null
Oct 11 21:17:14 box:backups runBackupUpload: result - {"result":""}
Oct 11 21:17:14 box:backups uploadBoxSnapshot: took 11.439 seconds
Oct 11 21:17:14 box:backups Rotating box backup to id 2020-10-12-041551-611/box_2020-10-12-041714-173_v5.6.1
Oct 11 21:17:14 box:tasks 6182: {"percent":78.64117647058819,"message":"box: Copying /mnt/cloudron-backups/snapshot/box to /mnt/cloudron-backups/2020-10-12-041551-611/box_2020-10-12-041714-173_v5.6.1"}
Oct 11 21:17:14 box:shell copy spawn: /bin/cp -al /mnt/cloudron-backups/snapshot/box /mnt/cloudron-backups/2020-10-12-041551-611/box_2020-10-12-041714-173_v5.6.1
Oct 11 21:17:18 box:backups Rotated box backup successfully as id 2020-10-12-041551-611/box_2020-10-12-041714-173_v5.6.1
Oct 11 21:17:18 box:updater updating box https://prod-cloudron-releases.s3.amazonaws.com/box-cdae1f0d06-1d3c27ec30-5.6.2.tar.gz
Oct 11 21:17:18 box:tasks 6182: {"percent":70,"message":"Installing update"}
Oct 11 21:17:18 box:shell update spawn: /usr/bin/sudo -S /home/yellowtent/box/src/scripts/update.sh /tmp/box-1720011772
Oct 11 21:17:19 box:shell update (stdout): Updating Cloudron with /tmp/box-1720011772
reset service cloudron-updater status in case it failed
Oct 11 21:17:19 box:shell update (stdout): Failed to reset failed state of unit cloudron-updater.service: Unit cloudron-updater.service is not loaded.
Oct 11 21:17:19 box:shell update (stdout): => Run installer.sh as cloudron-updater.
Oct 11 21:17:19 box:shell update (stdout): => starting service (ubuntu 18.04) cloudron-updater. see logs at /home/yellowtent/platformdata/logs/updater/cloudron-updater-2020-10-12_04-17-19.log
Oct 11 21:17:19 box:shell update (stdout): Running as unit: cloudron-updater.service

It ran into an error and so the update failed, but then it actually seemed like it worked because it's now showing me at 5.6.2 after I had refreshed the Settings page. The error from the logs: "Oct 11 21:17:19 box:shell update (stdout): Failed to reset failed state of unit cloudron-updater.service: Unit cloudron-updater.service is not loaded."

Any ideas with the above behaviour? I may be misremembering but I seem to recall seeing the same behaviour when upgrading to 5.6.1 previously as well.

Then the second behaviour that seemed strange (but maybe this is by design?) is that before the 5.6.2 update I had Bitwarden app update pending, when the Cloudron server 5.6.2 update was completed, then the update for Bitwarden was missing and I initially thought "oh good, it was updated at the same time too" (which kind of would make sense since the "Update" button was under the App Updates area of Settings for Cloudron). But later found that it was sort of just "reset" and needed to be checked for an update to install again on the app Updates page. Is this behaviour expected, where Cloudron updates will reset any pending app updates?

[nebulon]

Both of what you see is expected. First the reset of the cloudron-updater.service is just an attempt to fix a potentially lingering update process state. Maybe the message could be changed to not look like an error.

The second point of available updates is because of the update states are actually cached in memory, so if the box process is restarted it looses that state. Since it checks periodically it will eventually come back (can also be triggered from the dashboard). This is purely done to avoid having to sync persistent state in the db or such.

[d19dotca]

@nebulon Okay, the second one makes sense. That first one though... maybe the behaviour is expected but from a UX standpoint that’s not too great to update and then see that the update failed and then only see that it actually worked after refreshing the page. If the update succeeded then there should be no failure noted to the user at all. Right? It’s basically saying “hey I failed, look at me, just kidding I succeeded”.

[girish]

@d19dotca That "failed but actually succeeded" warning is suppressed in some parts of the code but it seems we missed the one in the update route. I have patched it now.

[d19dotca]

@girish Thank you Always the speedy fixes haha Love it.

[Lonkle]

What's this mean exactly?

• nginx: add splash pages for IP based browser access

[girish]

@Lonk said in Cloudron 5.6.2:

• nginx: add splash pages for IP based browser access

If you navigate to http://ip or https://ip, it won't redirect to dashboard anymore. It will instead show a bare bones splash page now. We did this because it was reported as a security issue when someone is trying to hide the server ip.

[girish]

@jdaviescoates There you go - https://git.cloudron.io/cloudron/box/-/commit/2aa5c387c7a480fdc5048c64b04b9ce0eeb18dde . You can put %VERSION% in the footer now in the next release

[jdaviescoates]

@girish great, thanks!

[Lonkle]

@girish said in Cloudron 5.6.2:

@jdaviescoates There you go - https://git.cloudron.io/cloudron/box/-/commit/2aa5c387c7a480fdc5048c64b04b9ce0eeb18dde . You can put %VERSION% in the footer now in the next release

You da best! I need this for now so I never forget to re-apply my box patches.