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
@nicolas Are your wordpress instances up to date? Do you have plugins installed in those instances?
That's where my mind goes immediately.
@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.
Way back when this first came up in 2017, there was a discussion on the issue boards for Ubuntu. This is the response from the PM at Canonical who added the feature including an explanation of how it has been used in the past and how they intend to use it.
https://bugs.launchpad.net/ubuntu/+source/base-files/+bug/1701068/comments/11
It can be disabled entirely by running sudo sed -i 's/^ENABLED=.*/ENABLED=0/' /etc/default/motd-news (source).
Debian support would be great, but I thought I'd present a bit more information for folks stumbling on this to read up on and make a decision on how they want to manage their server.
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.
@JOduMonT First off, that site is just reviewing app permissions. It’s docking Signal for requesting things like access to camera (used for taking and sending photos). That’s not really relevant here.
From a security standpoint, the Signal protocol is the gold standard for secure messaging. Other apps , like WhatsApp have even implemented it themselves.
Signal is also a non-profit and spends a considerable amount of effort in reducing knowledge needed to operate on the server. Their goal is to get to a point you don’t have to trust the server at all.
I have never heard of the app you’re recommending, but I don’t see any information about how they manage their encryption. Their website link (from Google Play) lands on some obscure website that doesn’t really load unless I turn off my tracker blockers. The site then doesn’t really indicate why I should trust them. No information on their funding or security. Also, the Play Store listing says it includes Ads. Which is a huge no-no for privacy.
Telegram is a popular app, but Signal is often recommended for security/privacy. First off, Telegram offers both encrypted and unencrypted messaging and defaults to unencrypted. Group messages cannot even be encrypted at all. In Signal, all is encrypted. Furthermore, when using encryption, Telegram uses a custom crypto algorithm they wrote rather than industry trusted ones like Signal does. This goes against a common maxim in the security industry “don’t roll your own crypto”. It could be just as secure, but less eyes on it means we just don’t know enough about it. Most professionals prefer a tried and true system.
Anyway, I’m pretty passionate about secure messaging, so I’ve done a bit of research here. All that said, unless they are willing to switch, the best one is the one your friends are using. Messaging is useless if you’re the only one with it. Kinda relates to the article will posted about encrypted email in the first place.
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.
@jdaviescoates Mailpile has both those features: https://www.mailpile.is/
Might be a good app request.
@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.
@nebulon said in Cloudron on a Raspberry pi?:
To give one simple example, any app using the go language, where we take the release builds, has to get some logic or separate Dockerfile to deal with arm.
I have some experience with this and have set up my own multi-arch go build pipelines using a single Dockerfile for some of my other apps: minitor-go, dockron, tag-checker, and for Python ones too: original minitor.
Here's a sample repo demonstrating my process: multiarch-pipeline-test. It's easier these days if your server has docker buildx though.
Also, since with Cloudron we're most often building things that exist upstream, here's an example multi-arch build repo I have for the Golang project cadvisor. It will auto build a particular cadvisor version on a git tag so I just need to create a release on my Gitea server and the build is started and deployed. With cadvisor, I have to clone the whole repo and cross-compile the cadvisor binary for arm becaue there is no pre-compiled binary. If there is, it should be even easier to just pull that binary.
Anyway, I'm happy to help if there are any applications that may be critical to be ported.
@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.
@mehdi I agree with this. However, it would also be important to have the ability to give the container a static internal IP and allow the configuration of the VPN app to set that container as the default DNS server.
This was something that came up early on when we were discussing AdGuardHome and PiHole. Most folks recommend only exposing something like this via a VPN without binding to 53 on your public network interface. A VPN still allows people to use it from anywhere but adds a layer of authentication.
The way things are now, it's very likely that folks misconfigure their DNS server. Part of Cloudron's draw is that users don't have to think so hard about "doing the right thing". The best way to do that would be to not bind only to a VPN interface and support the VPN setting the DNS server as the default.
A setting to "do the wrong thing" could be there for folks that really know what they are doing, but maybe a little more difficult to get to so someone who enables it will also know how to manage their firewalls. Either through their VPS provider or on the machine.
Personally, I host mine at home and access over a VPN.
@nicolas Are your wordpress instances up to date? Do you have plugins installed in those instances?
That's where my mind goes immediately.
@Lonk LDAP is just a directory tool. You can use it today with 2FA by storing the TOTP info there, just like you would with any other database.
The difficulty is that the application must actually use that data.
Alternatives would be to use methods like a proxy where you authenticate with username and password+token rather than a third field for token. This would allow implementing 2FA universally though it is unintuitive to users.
Cool! Do apps already have access to each other through the bridge? Or would that need to be made possible as well?
I've build and maintain a bunch of multi-arch images myself for some of my smaller projects.
You can definitely build on an x86 system by using emulation. I used to install qemu and then use build args to ensure that the right base image was being pulled (eg library/ubuntu for x86 vs armv7/ubuntu for armv7) because otherwise, by default, an x86 machine would pull the x86 image. After building and pushing I generate a manifest and push that so that each platform pulls the right image. This is probably the simplest example I have of that since it's a single Python file.
All that said... there is now an experimental feature of Docker available via the docker buildx command.
Here's a recent (April) blog post from Docker about the new method. It's far simpler, so if you can get that working, it'd be ideal. I haven't taken the time to switch over myself just yet.
@doodlemania2 I'm not sure exactly what you've configured, but many folks do not have static IP addresses to do this with. Not only does my home network frequently change IP addresses, but my mobile network does as well.
@girish yea, that's pretty much all that should be required. As long as the two containers can communicate via their internal host names, it should be sufficient.
The other advantage here is that it enables you to use the DNS from a mobile phone. Otherwise whenever you switch to a new network you receive the networks DNS via DHCP.