Posts made by girish

Hi All,
Since we have released support for custom apps, we have received quite a bit of feedback about the CLI too. I thought I will consolidate them here (and what we are going to do about it).

• No way to integrate with CI/CD. We are adding global options: --token and --server to help with automation.
• If a bad docker image name (say a typo) is passed to cloudron install --image <image>, it ends up in a unrecoverable state. This is a bug in the platform code, we will push an update coming week to fix this. For now, just uninstall the app and start over. If this was an existing app, just roll back to the previous backup.
• It's not obvious that cloudron install also does an update. For some reason, we never thought about this obvious one We will make cloudron install for installing new apps and cloudron update for updating apps.
• Updating an existing app with the CLI does not currently create a backup. So one can end up losing data if they push over an existing app. We will make cloudron update to backup by default with a flag to skip the backup.
• User/Domain/Email/Other management subcommands - The CLI tool's scope currently is only for app development and nothing more. We won't put in effort to implement these subcommands in the CLI tool for now atleast. But if you want to contribute, you are welcome to. Cloudron has a full REST API, so this should be straightforward.
• Many misleading/obscure error messages. This is also getting fixed.

Hopefully, we should push out major CLI release in the coming days. If you had any other workflow issues, please post it here.

@jimcavoli I am just speaking by reading the docs which might be outdated. https://docs.bigbluebutton.org/2.2/install.html#minimum-server-requirements says:

• 4 GB of memory with swap enabled (8 GB of memory is better)
• 4 CPU cores (8 is better)
• TCP ports 80 and 443 are accessible
• UDP ports 16384 - 32768 are accessible
• Port 80 is not in use by another application

Memory requirements aside, those port requirements are quite extreme. Though maybe they are just trying to say "keep a domain available" to host it, not sure.

@cloudron_account Are you able to join our chat at https://chat.cloudron.io and ping @girish or @nebulon there? Since, this seems to be mostly networking related, it helps to speak directly.

Thanks for reporting upstream. https://gitlab.com/commento/commento/issues/240 for anyone looking for the bug report.

So far, we have finished OnlyOffice, OpenVPN and the development apps (with 3.4). Bitwarden and Jitsi/BBB remain. BBB seems to take a LOT of resources, so I am not sure this is a good bit for our users for the moment despite it possibly having a better UI. That said, we use Jitsi everyday and it works great.

@oatwalker Did that work? I will improve the docs to provide the exact commands

We investigated this offline. The root cause was that the S3 storage service (strato hidrive) does not support multi-part copy. The workaround is to use the rsync format (Backups -> configure -> Format) when you have backups > 5GB.

@yusf Correct, it is best to run the build service app in a separate cloudron. Essentially, the build service is building a lot of docker images. It "cleans up" old images periodically. For both of these operations, it requires full access to docker. There is a chance that it removes containers/images of the other apps on Cloudron by mistake. As in, this would be a bug but if someone hits that bug on a production Cloudron that would be a disaster. This is the reason why we recommend running it on a separate Cloudron.

Finally, the build service app is not required at all. You can just build and push images from your laptop or a linux VM or some VPS which has docker.

This is fixed now, will be part of next release.

I can confirm this is a bug. We are working on a fix.

$ host -t TXT icloud.com
icloud.com descriptive text "google-site-verification=knAEOH4QxR29I4gjRkpkvmUmP2AA7WrDk8Kq0wu9g9o"
icloud.com descriptive text "v=spf1 ip4:17.36.0.0/16 ip4:17.41.0.0/16 ip4:17.58.0.0/16 ip4:17.110.0.0/15 ip4:17.111.110.0/23 ip4:17.120.0.0/16 ip4:17.133.0.0/16 ip4:17.139.0.0/16 ip4:17.142.0.0/15 ip4:17.151.1.0/24" " ip4:17.158.0.0/15 ip4:17.162.0.0/15 ip4:17.164.0.0/16 ip4:17.171.37.0/24 ip4:17.172.0.0/16 ip4:17.179.168.0/23 ~all"

Adding the above to example.com's SPF maybe is a start.

@d19dotca Ah, I misread your post. I think what's happening is that iCloud.com does not support SRS. What this means is that when forwarding email (from say A to icloud), it is forwarding email pretending to be the original mail address i.e it declares itself in the MAIL FROM to be A.

Cloudron sees that it is "spoofing" address A because icloud is not listed in the SPF record of A and it rejects the email. This is a good article about how SPF breaks forwarding in general.

In your case, iCloud sends an email with the MAIL FROM set to an address which is on Cloudron itself. It sees that as a spam/spoof and rejects it. The behavior is correct but of course it doesn't help you with your problem.

A fix is to add the icloud servers to the domain A's SPF record. Does icloud list the servers from which it sends mail? Alternately, you can make the current SPF record very permissive. By default, Cloudron will setup the SPF record to only allow the Cloudron server itself.

@fbartels If there is a conflicting username, we skip it. It will log a conflict. If it helps, the code is at https://git.cloudron.io/cloudron/box/blob/master/src/externalldap.js#L185

Yes, base container requirement is gone (it was never enforced by the platform itself, but just our buildbot which is gone now).

I would hold on till 4.3.3 to test the LDAP connector.

Definitely, sounds like something we should do across all our PHP apps.

@d19dotca Is this with 4.3? (We added some code in 4.3 to resolve aliases in lists, which I think you reported earlier in a forum post).

Just a heads up. There were a few bugs/regressions that we found since we released this:

• LDAP connector has a bug causing sync to be super slow.
• LDAP connector does not auto-create users (have to synchronize by hand periodically)
• Private Registry setting fails when using ECR
• Memory usage graphs do not show all the apps

We are pushing out a 4.3 patch release later today that should fix the above issues.

Hi all,
We released Cloudron 4.3. The blog has more details about the release.

• Network View - Use this to select the IP address that Cloudron uses to configure the DNS.
• Custom Apps - Development and deployment of custom apps (using Docker) is integrated a first class feature. See the tutorial for getting started.
• Custom CSP Policy
• LDAP Connector
• email: Auto-subscribe to Spam folder
• ticket: when email is down, add a field to provide alternate contact email
• Add pagination and search to mailbox and mail alias listing
• Resolve any lists and aliases in a mailing list
• Rename Accounts view to Profile
• Add search for groups and user association UI
• List unstable apps by default

This should definitely work. In fact, @nebulon submitted a patch to commento just to make email sending work which I believe is part of the Cloudron package already - https://gitlab.com/commento/commento/merge_requests/88 . I will let @nebulon comment

@KathleenMcArthur Thanks for the feedback

@oatwalker You can use IP tables directly. Something like https://cloudron.io/documentation/security/#static-ip-ranges