Software Engineer turned Director at a Silicon Valley company.

After the switch to management I was eager for a technical project and decided to take on self hosting for privacy and ethical reasons as well as the technical challenge. I’ve made several attempts at managing all my self hosted services from scratch and eventually found Cloudron.

I've got a branch where I've almost gotten LDAP syncing fully working, but invites don't seem to be working properly.

Even if I try to send an invite directly through the web interface, it just hangs. The user shows in the list, however the logs never show a success or failure response for the request. I've checked the SMTP settings and they appear to be correct. I'll keep debugging though.

https://git.cloudron.io/iamthefij/bitwardenrs-app/tree/ldap-sync

@yusf What are you wanting to see incorporated? The directory sync connector?

That diff that @girish linked is to add experimental support for the upstream Directory Connector APIs to allow you to use the upstream connector.

The directory connector could probably be added as a separate app much like ONLYOFFICE is with Nextcloud.

Alternately, I wrote the original bitwarden_rs_ldap connector, which was supported from within the single install. It was auto configured and then triggered by a timer every 5 min to auto send invites. The reason it wasn't included in the final Cloudron release was because the LDAP connector doesn't in the same way as other Cloudron apps and it was confusing to the users who were testing.

As @girish said, it works by sending users invites. Passwords cannot be synced because the Bitwarden server never even gets to know your password.

It looks like it has been removed, but we could probably patch back in the old LDAP sync at least and make it something that could be configured using file manager or the terminal as an advanced feature.

It would seem that supporting Keycloak would be a great way to still only really have to maintain LDAP on the Cloudron side and then add support for OpenID Connect, OAuth 2.0
and SAML 2.0.

I've never set up Keycloak though, so I can't speak to it's ease of use or maintaining, but it is often recommended when people talk about FOSS Identity and Access Management tools.

@nicolas Are your wordpress instances up to date? Do you have plugins installed in those instances?

That's where my mind goes immediately.

I'm working on packaging Authelia as a Cloudron app, which is slightly different.

Use case is that I have a second server with some services that I would like to authenticate against my Cloudron LDAP.

LDAP syncing is now available for bitwarden_rs. Check it out on the wiki.

Do you have your app shared on git.cloudron.io yet? If so I can help contribute.

Got it working! Turns out I needed to enable SMTP_EXPLICIT_TLS.

Now I just have to schedule the sync task and do some cleanup. Should have a fully ready app soon.

@will just a note, I don't believe fbartels version supports a using a dump for backing up the database. This means that if the backup is taken while the db is in a transaction, it could be corrupted.

Bitwarden_rs now supports an admin API for making sqlite backups, but does not have any cron embedded. Similar to the way the LDAP sync tool works, an additional script could be added to periodically make dumps of the sqlite database so that it can be properly backed up.

Instead, the version I have is using MySQL, which leverages the native Cloudron backup and restore functionality.

That and the LDAP invite service are the real differences between the two forks. If you do not wish to use automated LDAP invites on my fork, you can select to opt out when installing. This is covered in the readme.

@yusf Yea, the Readme describe the reasoning.

There is no way to actually do true SSO without breaking the model for Bitwarden. The only thing that we can do is automatically invite users to sign up.

The Bitwarden_rs project doesn't have a way to invite without sending an email as when an SMTP server is configured, it will generate unique invite links for each user.

If you disable SSO, you only disable the auto-invite feature. You will then need to invite yourself via the Admin panel (admin token is echoed in the logs and in /app/data/admin_token). You can then invite anyone else you wish manually.

@iamthefij I should say... it worked to increase the limit. My contacts still don't load.

@nebulon said in Increase Nextcloud PHP memory limit:

/app/data/php.ini

I undid everything I set, but then I grepped through /app/data and found php_value memory_limit 512M in /app/data/htaccess. It's not present in /app/data/.htaccess though. I'm confused as to why both of these exist in the first place.

But anyway, I commented out the lines in /app/data/htaccess, restarted and it looks like it worked!

Thanks for the help.

I know very little about PHP, so I'm running low on things to try. I've tried grepping through /app/code for other places where memory_limit is referenced, and I don't see anything else limiting it.

@girish deleted and restarted. Nextcloud still says 512MB but php -i shows memory_limit => 1024M => 1024M.

@girish I had updated the .user.ini because it had previously said memory_limit=512M, so that's why I changed it. Should I remove it or change it back? I've already removed it from everywhere else.

@girish @nebulon I've restarted the app with all those values set and Settings > System still shows Memory Limit: 512 MB

I'm having this issue but it is with contacts: https://forum.cloudron.io/topic/6813/increase-nextcloud-php-memory-limit

I'm getting an error Apr 12 16:27:12 [Tue Apr 12 23:27:12.433970 2022] [php7:error] [pid 285] [client 172.18.0.1:57230] PHP Fatal error: Allowed memory size of 536870912 bytes exhausted (tried to allocate 33554440 bytes) in /app/data/apps/dav/lib/CardDAV/CardDavBackend.php on line 996, and I'm trying to increase the memory limit to 1025M.

So far I've added

• 'memory_limit' => '1024M' to /app/data/config/config.php,
• memory_limit=1024M to /app/data/.user.ini
• memory_limit=1024M to /app/data/php.ini
• PHP_MEMORY_LIMIT=1024M to /app/data/config.env

But none of these seems to have worked. Any ideas where I should be able to make this adjustment? The server itself is already allocated to up to 1.5Gb, and the error seems to be PHP related, but I'm not sure where to set this.

Very interesting conversation.

Getting upstream projects to support Cloudron distribution as well as others (eg. Docker Compose, Helm, Flatpak, etc.) would be the most scalable, but probably a hard sell. Additionally, even if it were done, would that be the right call? Even projects like Debian maintain their own repositories.

I'm not sure if this is available somewhere, but if there were install metrics for apps, that could go a long way in showing upstream projects how many users are using their application on the platform and encouraging them to offer more support, even if Cloudron maintains the repo.

For example, this is how Home Assistant reports install metrics: https://analytics.home-assistant.io/#integrations

Actually, Home Assistant also has their own "Addons" features which installs managed Docker based applications from a repo that is mostly maintained by the project leads but is also community supported. Much like Cloudron. They also have addon stats here: https://analytics.home-assistant.io/#add-ons

@iamthefij Ok. Just restored matomo from backup again and it's all good.