Topics created by d19dotca

@d19dotca You can try https://git.cloudron.io/cloudron/box/-/commit/3c565defca000feb21c47e9d8c9ada4c62c11cef and then systemctl restart box. Alternately, you just use the docker CLI until the next release: usr/bin/docker update --memory 805306368 --memory-swap 1610612736 mail The containers are named mysql, postgresql, mail, mongodb.

Those sync.cache files are state files of the rsync backup uploader. That has to run as root to be able to list and read the app's files, the app file permissions here depend on the app itself and how it manages permissions. The yellowtent user as such does not have root rights on the system and uses helper scripts in such cases. The list of scripts which need and thus run with elevated permissions can be found at https://git.cloudron.io/cloudron/box/-/blob/master/setup/start/sudoers

I appreciate everyone trying to help Seems this may be something I need to figure out myself given the seemingly unique circumstances I’m running into. But if I find a good way to do this I’ll be sure to update this thread for others who may run into the same circumstances in the future.

Great stuff, persisting with it!

@d19dotca I have added some docs now. https://cloudron.io/documentation/backups/#schedule has info on the timeout and nice. https://cloudron.io/documentation/backups/#concurrency-settings on the concurrency settings.

@jdaviescoates Normally this kind of plugin for security they want to have access to all the WordPress to intervene if needed on all the WordPress root directory. This message is form wp. Because WordPress it's self provide an interface not edit files and accessing data, when a plugin try to access the filesystem with the filesystem API and the API fail, will automatically ask for the credential of ftp. But .htaccess is editable I think on managed too, so it's trying to do something in a read only directory on the image.

@girish Thank you kindly!

@marcusquinn You're right, I should have done that. I was lazy at the moment and just wanted to get it filed while it was on my mind.

from me I think Mailboxes & Nextcloud are always going to be the most disk-hungry data silos, so they make more sense to have on attached drives or storage than almost any other app. Although the Video & Photo Library ones could be for some. It doesn't make sense to keep increasing VPS sizes just for the additional disk-space, when mostly the CPUs & RAM are adequate on reasonably low tiers. I'm always tight with paying for unused utilities so that we can be generous in paying for developers to make these efficiencies

@girish Just provided access and sent the email.

@girish That would be ideal! In fact if that can come in the next couple of months, I'll hold off my own DNS change until that's there. Because the whole "my." doesn't really conform to the standards that people expect when they need to enter in their server names for a mail server. I'd definitely love if Cloudron could use it's own "mail" subdomain and it's own certificate for the mail server portion so that I can still have clients connect to mail.<domain>.<tld> without impact since that's what I have told a dozen or so to do already over the last 1.5 years. And no, the decision wasn't anything to do with Cloudron or DigitalOcean really. My main reason for the move away from DigitalOcean isn't anything to do with Cloudron or DigitalOcean. If you're curious... the decision was mostly for two reasons: A movement from both myself and my clients to keep everything (as much as possible) in Canada. And my current DNS provider (LunaNode) has their infrastructure in Canada only (well France too, I believe). It's one of those "shop local" sort of things. The DNS provider I currently use has a great feature that I can take advantage of in the future when running a secondary Cloudron server as a mirror image of the first one (waiting for that clustering capabilities in the future, hint hint haha). The advantage is that they have monitoring tools I can use, and based on those monitoring tools they can automatically update DNS records to the other IP address if monitoring detects one of the servers as "down" for whatever reason. To me this is like the health checks in load balancing, but I don't have to pay for load balancing with this solution. I see this as a further advantage to using LunaNode for the DNS management. So yeah, nothing to do with Cloudron or DigitalOcean really, so no worries there. Just a decision made for various reasons (the biggest two above, but also a bit of my own OCD and others haha). I will keep my primary domain on DigitalOcean then for now if you think the SSL cert for the mail subdomain would arrive in the next couple of months. Because I think that's a fantastic idea, and I think that was something I mentioned or questioned back when I started using Cloudron because I was so surprised that it had to be "my." as that's not something that conforms to the standards of mail server hostnames, and I wanted to keep things more standard for my clients to avoid having to explain non-standard implementations. I say standard loosely here as I realize there's no official standard, but it's more a de-facto one that mail. is the subdomain to use, or imap., etc. Hope that helps.

If this is disabled or archived, this also means that it is still "known" to the system, currently the data simply is not removed from the disk, but other relevant information is purged from the database. So I agree, that deleting an account should also delete the mailbox data, if there is no proper way to restore that (currently you have to create a new mailbox record with the same mailbox handle and magically the data comes back). For that some archived state could be the solution to have a structured way to restore.

@nebulon Big fan of Dark Mode, thanks for your work to add it!

@ice Let's discuss in https://forum.cloudron.io/topic/2947/wordpress-has-stopped-working

@d19dotca I guess that depends exactly on what you want to use the cloudron cli for. A workflow could look like the following: change/update version of a package in the app commit the change to git (you could edit and commit directly in e.g. gitea or gitlab) this automatically triggers the ci platform this one could do some verification create the updated docker image deploy it to your cloudron The simples form of this could be a post-commit hook in your git hosting tool.

Yeah, we made changes specifically to preserve the mail from. If you find that it doesn't work, please report back.

Awesome this got resolved on it's own

Update: It is thankfully as easy as removing the data from the users table in the user_pass column. Removing the value from the user_pass column on each user who you want to only authenticate using LDAP/Cloudron, will force that expected behaviour. If there is a password in the database, authentication will succeed with the local password OR the LDAP/Cloudron password, so removing that password will force it to rely only on LDAP/Cloudron authentication.

Correct. We don't need to re-create container to change the memory limit. But we still need to restart it after adjusting memory limit because of the limitations in our packaging. I think over time we have learnt that it is not a good idea to setup apache to auto-scale based on container memory limit. Those things are very dependent on the app/plugin use. I think java apps require a restart at this point since the JVM gets passed in the heap memory as a flag on startup, maybe there is a workaround for this as well, have to investigate. But at that point, we can atleast make the memory limit code not re-create container which I think is where bulk of the slowness is.

Yeah, the box is set to Public. Not sure why the discrepancy but this was set a few years ago and has seen 100s of GitLab updates in the meantime. Anyway, thanks in advance for any contribution We don't have proper instruction for testing the UI but you can do this: npm install gulp develop --api-origin=https://my.domain.com This then runs a local dev server at localhost:4000 which you can use for testing.