I haven't had a chance to finish the overall guide for the cloudron specific part but I completed a guide for installing OpenCTI with Traefik, Elasticsearch, and lots of plugins. I also have a complete docker-compose for OpenCTI, Elasticsearch cluster with X-Pack security, and multiple plugins as well as LDAP integration. you can find it here

OpenCTI install guide
https://dev.azure.com/Mastadamus/OpenCTI/_wiki/wikis/OpenCTI.wiki/3/OpenCTI-with-Traefik-Reverse-Proxy

OpenCTI GIT that contains my templates
https://dev.azure.com/Mastadamus/_git/OpenCTI

If you just want to skip to how you integrate LDAP with OpenCTI docker-compose I will paste examples below

- PROVIDERS__LDAP__STRATEGY=LdapStrategy - PROVIDERS__LDAP__CONFIG__URL=ldaps://Your.Domain.Name:636 - PROVIDERS__LDAP__CONFIG__BIND_DN={{`cn=admin,ou=system,dc=YourLDAPserverName`}} - PROVIDERS__LDAP__CONFIG__BIND_CREDENTIALS=XXXXXXXXXX - PROVIDERS__LDAP__CONFIG__SEARCH_BASE={{`ou=users,dc=YourLDAPserverName`}} - PROVIDERS__LDAP__CONFIG__SEARCH_FILTER={{`(cn={{username}})`}} - PROVIDERS__LDAP__CONFIG__MAIL_ATTRIBUTE=mail - PROVIDERS__LDAP__CONFIG__ACCOUNT_ATTRIBUTE=givenName - PROVIDERS__LDAP__CONFIG__ALLOW_SELF_SIGNED=true - PROVIDERS__LOCAL__STRATEGY=LocalStrategy

@nebulon Good to know. Thank you!

@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! 🙏

@girish Cost and complexity is a thing, from domain integration to simply wanting to use your existing server you pay resources for to run an additional app or two.

The assumption backups are needed is false.

Yet, if we take the time to revisit an old idea of additional VM like isolation via Nestybox, (which is a single line code change) we may have our cake and eat it too, with backups at no extra work.

Personally I don't care for any of the benefits of the packaged apps for the unpackaged ones, unless they're no effort as a side-effect of the implementation.

The only thing I can think of we might need more of is control over nginx rev proxy settings and mappings.

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.