N
So while this app being very geeky, it seems to work rather well what @timconsidine has put together. If the individual processes within the app get run by supervisor like in other packages, to avoid just backgrounding them within start.sh I think we can add some basic integration tests and get this published. Especially since it bundles an http server it seems a much better fit for Cloudron out of the box.
Great job so far!
It is a bit to tinker, but you can see all locations Cloudron mostly writes to at https://docs.cloudron.io/storage/#default-data-directory and you could relocate those to the M.2 drive then (see relocate section in the docs page)
Further for swap you may also just add the swapfile onto the M.2 drive.
This is currently not on our list. But you should be able to use Cloudron groups for that already, just have to add the users accordingly.
Yeah I was about to mention that. It is not a great design decision on espo side how they laid out the login view.
Like nearly all apps, they come with a app local admin account. The postinstall notes show the credentials.
Very similar as just explained in https://forum.cloudron.io/topic/14061/default-config-changes/13 Cloudron user roles do not propagate to the apps. We did this in the past and that caused all kinds of unexpected side-effects, as roles in apps can mean different things as what they mean within Cloudron. It may be clearer if you think of how for example the Cloudron role "user manager" should translate into espo?
Cloudron will return the groups a user is part of. However admin or app operator are roles not groups. So an app does not know if a user is also an admin on your Cloudron or such.
Long ago we did expose this, but this usually does not map well to apps. Roles and groups often mean different things within different apps.
Ah thanks for the clarification. Maybe we can think of some different UI which has an overview and some drilled down info if wanted.
Since you will need valid certificates for all domains, it makes most sense to go via the Cloudron api to add such subdomains to the app. The app internally then has to handle the delivery of content accordingly based on the virtual hostname.
For this we have the manual refresh button, the infomation in those situations won't be faster available by just running the background job more often.
But if someone has a hint on how to gather the information faster on linux without causing a lot of disk I/O, that would be great.
This is currently only refreshed once a day, since it is a tradeoff between accuracy and causing a lot of disk I/O for no reason 99% of the time. Thing is if the disk is not too fast and/or the server has a large disk, it just takes very long on linux to get detailed disk usage info besides the capacity+used+free overview per filesystem/partition.
So this is not a technical thing we can implement, but more what we optimize for.
Do you see any errors in the system logs at /home/yellowtent/platformdata/logs/box.log when you trigger a refresh of the disk usage?
Does the folder /home/yellowtent/platformdata/logs/tasks/ even exist? Maybe you purged all subfolders there?
If it doesn't exist, run:
mkdir -p /home/yellowtent/platformdata/logs/tasks/
chown yellowtent:yellowtent /home/yellowtent/platformdata/logs/tasks/
you have to prefix the env variables with export statement, as env.sh is a .sh file. So like:
export OPENAI_API_KEY=...
Logrotation would not kick in that fast, so maybe the system cannot write to disk/create new files? Do you see any errors in /home/yellowtent/platformdata/logs/box.log while triggering a new backup run? Does that file even have new log entries?
Logrotate is implemented by default with Cloudron, however I think the feature request is to be able to configure Cloudron to send logs to a logcollector, in this case some other debian server?
Also maybe just reinstall the app to start fresh then. There isn't much actual data stored in the app anyways.
Indeed looks like they removed all the beta labels by now. Maybe I will get around looking at the package over the weekend.
Which domain name did you change? The dashboard domain? does it resolve to the correct IP?
We were able to inspect the server today morning and after some debugging it turns out the system was booting a kernel which doesn't have memory cgroups enabled. In fact that kernel wasn't even installed on the system but apparently linode provides a way to boot the system with other kernels. This seems what caused the issues that the containers couldn't start anymore.