@p44 - Do you find the 2 PM (presumably that's a "peak" time for your server traffic) impacts performance at all?
This is a very good question. Performances could be affected but our customers in that time they are in lunch time, so we prefer to keep an updated copy of backup after "morning work". Backup all data it takes around 30minutes.
@girish Oh that's a good idea! I don't think I knew I could create a mailbox and have an app use that mailbox, or at least I didn't really consider it before. I think that's a good workaround. Thanks! 🙂
@nebulon Thanks! You have very comprehensive explained why not in an easy to understand way👍 . Relevant discussion here for those who will never visit the "App Packaging and Development" section of the forum!
@nebulon would all binaries not run (eg. /bin/sh from within the base) or just Go binaries that you compiled within the buildx pipeline? If it's the former, it may not be using the right base image. If it's the latter and the former works, perhaps setting the GOARCH variable via a build-arg would solve it.
Note: I personally have not used buildx yet, but from what I can see it's a simpler, automatic version of what I'm trying to do with qemu that handles the manifest for you. So I think you should just be able to build without the muckiness of all the build-args I pass, but if not you can play with mixing those in until it works.
I think buildx is supported on my laptop, so I can give it a try, but it's not supported on my CI box yet, so I haven't switched.
This is both for retry when, for example the backup done prior to the update, fails temporarily, as well as if apps and platform gets updates, they lock each other so retries in not so busy times are an effective workaround.
Right.. It seems there are many candidates zabbix, netdata, some SNMP thing I forget etc. I prefer simply making sure Cloudron "works" with these existing software. It's why we added a way to open up the firewall as well. Happy to make any more fixes required to make these things work more easily.
@girish Ah okay, that makes sense on the tgz part. Unfortunately I haven't had much success at all in any quicker times (in fact it's often closer to double the time than tgz, taking between 1-2 hours) when using rsync in my tests for OVH Object Storage. But maybe I just haven't found that 'sweet spot' yet. I'll keep testing. Thanks Girish.
-- Configure DNS
-- Downloads docker image and manifest file from the Cloudron app store
-- Sets up addons
-- Logrotate, Collect (stats about the app, how much CPU, memory it using etc), Firewall
-- Runs the docker container
--- Dynamic configuration (giving the app db credentials, SMTP credentials to send email, e.g. for WordPress it creates the wp-config.php file with all the relevant credentials)
-- Gets SSL certificates from LetsEncrypt (and set-up reverse proxy, i.e. when blog.domain.com is visited forward to this container)
-- Read only and stateless app containers (all apps are read only - apps cannot write to their file system, if they could then users could add all sorts of random files and it wouldn't be possible to update smoothly, the code cannot be modified. This means when there is an update we can just throw away the old container and get in the new container. So where does the app write stuff it needs to? We let the app write in 3 locations 1) /tmp for temporary files 2) /run which contains runtime files which an app needs to communication across various processes, 3) app/data/ where the app will put images, files uploaded etc - everything in app data is part of the backup, /tmp and /run is not backed up)
-- Rolling updates
-- Signed releases
-- Selenium based tests (test that everything actually still works)
@girish I understand then I probably mixed a bunch of problem in one threat and I'm sure you did that with good intention but erasing the historic of the post 24635 and changing the tittle of my "issue" make me feel sad, if it is not angry :(.
the BUG with the automount as been partially resolve by adding an IP in the /etc/hosts which
goes against Cloudron recommendation about not modifying the system
wasn't stable enough since a StorageBox use DHCP
for an unknown reason wasn't working all the time for both CIFS/WebDav
Now without the historic, I receive notable reply which contain great advice but are out of context and make me feel stupid and also feel I'm loosing my time to try to build something on top of Cloudron. Also in the historic, someone (I believe it was @jdaviescoates) already replied it was possible to share the data between Jellyfin and Nextcloud (this is why I was using this example because it was concrete).