@hustler We don't have anything public for students but can you write to support@cloudron.io ? We will see what we can do, thanks.

@ApplegateR I think this is some legacy hosting provider API. Cloudron uses https://api.cloudflare.com/ , so we should be fine.

Given the inclusion of EROFS in the Linux kernel and it making into Ubuntu, a few questions come to mind. Among the features listed are compression and caching. Hence the question is, what is the Cloudron configuration for EROFS and are we using the potential for caching and compression since we run so many containers based on an identical base image. @girish is it defaults or thoughtful tuning?

@Aizat said in Wasabi Timed Deleted Storage: @timconsidine thanks, I'll check Scaleway and Hetzner out FYI both (aside from Hetzner US location where they're just co-locating)) are 100% powered by renewable energy too, imho an important consideration in a climate emergency

@timconsidine Yes, as mentioned by @humptydumpty and maybe start with, what tools do I need to have ready, and we should get our feet wet with in some cases, before starting, which are going to be in use during the whole process. Cloudron CLI of course, what else? A docker registry? A GIT server? A VPS with docker installed? A Docker desktop version? (as well as the previous?) How are they connected? Etc Maybe also an example of how one is (or should be) set up? Thanks for the offer mate!

Thanks Girish! @girish said in Vultr DNS default TTL: The changelog is not comprehensive, it doesn't have 1-1 relation with all changes since it also goes into the UI. Only way to know is the git log for small changes. Totally fair. I was surprised to see that one missing since there's a ton of smaller changes still in the changelog in previous versions. I always thought the changelog was quite comprehensive before, but maybe it's geared more high-level now.

Thank you so much @fbaretls! Since Uptime Kuma has all the notification types I need (Matrix, really ) this solves my issue See you in the co-olperative sector, @jdaviescoates

@LoudLemur Looks like it but I don’t remember if on purpose or as part of the Ubuntu Server installation - it’s quite some time ago that I installed Ubuntu Server on this machine Festplatte /dev/mapper/beebox--vg-root: 461,58 GiB, 495603154944 Bytes, 967974912 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes Festplatte /dev/mapper/beebox--vg-swap_1: 3,69 GiB, 3942645760 Bytes, 7700480 Sektoren Einheiten: Sektoren von 1 * 512 = 512 Bytes Sektorgröße (logisch/physikalisch): 512 Bytes / 512 Bytes E/A-Größe (minimal/optimal): 512 Bytes / 512 Bytes

@jdaviescoates said in Shared Authentication between Apps: I'd still love a simple way to allow for Open Registration on my Cloudron: https://forum.cloudron.io/post/5339 I agree that would be great also.

Now I'm hungry for a bag of Doritos.

@nebulon said in List of apps that support LDAP/Cloudron User Directory?: For a start I have update the appstatus page to include a checkmark for apps which have LDAP enabled at https://www.cloudron.io/appstatus.html Thanks! @nebulon said in List of apps that support LDAP/Cloudron User Directory?: @humptydumpty I do think it might be nice to have a filter directly in the app library listing within the dashboard. I think I will add this for the next release. Agreed, thanks!

Holy bananas!

I would be interested to know if someone does this outside of Cloudron for their existing business/personal use. Seems like a lot of work (and probably just easier to switch out your NS provider if they are flaky). We use route53 for cloudron.io and AFAIK it has never gone down.

Cool, I'll get around to following everyone next week. I'm @shane@social.futurnumerique.com! (My site at futurnumerique.com is down because I'm moving from its Yunohost home to Cloudron.)

@necrevistonnezr Great questions! I'm still pondering this myself, but got delayed with some other projects. I don't have an HA setup yet, but I'd assume the easiest way to achieve it may be to duplicate the server (i.e. restore Cloudron backup on a new server), then use rsync to keep them in sync on the boxdata directory for example, then use DNS for failover where the MX server address on the other server can be used with a higher weight to be last in the selection and thus only used if the first MX server isn't responding. Just my initial two cents anyways, but haven't thought it out thoroughly yet. Will probably give it more thought once the Cloudron multi-server management feature is in-place as it may make things a little bit easier.

I will probably end up with a different solution I teste FileRun in a LAMP app (after reading @scooke reply here) and it does exactly what I need without all the added bloat and unpolished UI of Nextcloud. It sorts pictures by date taken Has a better UI than NextCloud (personal opinion) It is a lot faster in previewing images Works with the Nextcloud desktop and Android client (or any other app that supports webdav) Can organize photos in albums and collections (I am not really interested in this, but it's a nice to have) I hope that it will officially come to Cloudron at some point.

@necrevistonnezr excellent catch! I think I searched “email” when I should have just searched “mail”. There may be a couple others I missed.

@3246 Are you backing up /snapshot/ or the parent directory? /snapshot/ is sufficient for a daily backup as it holds the current status of all files - versioning etc. is done by restic. Also, how did you calculate these dirsizes?

@ianhyzy said in running many WP installs on one cloudron: @d19dotca thanks! mind sharing any of your php tweaks? I'm curious what other people are doing here Certainly! The values change periodically for me based on various circumstances, however here's the current values I'm using in the php.ini file for WordPress... default_socket_timeout = 300 max_execution_time = 300 max_input_time = 60 max_input_vars = 3000 memory_limit = 256M post_max_size = 128M upload_max_filesize = 128M The top are the values needed usually for best performance from certain page builders and important plugins in WordPress, plus I have a few sites that host videos / other large files so I keep the sizes somewhat large too and tweak as needed for each customer website. Also, on the wp-config.php file, I also set the following property which allows the WordPress memory limit to match that of the php.ini file, rather than keeping them separate. But in some cases it may be wise to keep them separate too, it's really a case-by-case basis, I just find I often keep them the same so doing it this way means I only have to set it in one spot and removes the risk of keeping them separate unintentionally... define( 'WP_MEMORY_LIMIT', ini_get( 'memory_limit' ) ); // sets memory limit to match php.ini Then for the actual application itself, I currently set a 1 GB memory limit on each one.