I
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.
I don't expect that the security issue is one of ongoing concern, but the ethical one is. I've read several articles about it and will probably avoid registering one myself.
Still, branding is powerful and rebranding something is a huge risk. I wouldn't recommend Cloudron attempt it. Maybe there is a way to balance things out with a banner somewhere calling attention to the issue and that Chagos support website.
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.
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.
@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.
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 and that could happen with any TLD. Do you suspect there is a trend or increased risk of .io being blocked by authorities?
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.
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.
I'd prefer to restrict a Cloudron instance to a particular zone rather than use the Global API Key. Whenever I do so, I get an error from Cloudron. What should the account be scoped to? Or is it even possible to use this?
@jdaviescoates Mailpile has both those features: https://www.mailpile.is/
Might be a good app request.
After making a few upstream patches to Authelia, I've gotten an Authelia Cloudron App running! (yay!)
Unfortunately it won't work due to the Cloudron Nginx config. (Bummer!)
Repo and context for those interested https://git.cloudron.io/iamthefij/authelia-app
Would be cool to have still, but I'm not ready to dig through the Nginx changes given how broad the impact would be.
@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.
I got everything working now by skipping some updates, finding a problematic one and debugging it a bit. I'm leaving a message I was going to send mid debugging before I managed to get it working just in case anyone else comes across the same issue.
I got it working by skipping versions until I got to one that wouldn't apply. It was v4.41.0. It would run but the database migration would never connect to MySQL. This happened even after I got to the version just before and tried to apply it a few times.
While I was debugging I found that the MySQL connection wouldn't work from the Terminal. Then I put the app into recovery to debug further. It MySQL worked in the Terminal there, so I turned off recovery mode and it booted just fine! Not sure what the root issue was though. Unusual that I was able to reproduce it but then it kind of resolved itself. Maybe switching to or from recovery resets some value causing an issue. I'm not sure.
Original message:
So, this is now pretty specific to Ghost. I've made it up to v4.40.2 just fine, but when I apply the next version v4.41.0, Ghost fails to start.
The log shows
Jul 11 14:39:18 ==> Start ghost
Jul 11 14:39:18 ==> Clear potential migration lock
Jul 11 14:39:18 mysql: [Warning] Using a password on the command line interface can be insecure.
Jul 11 14:39:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:39:30 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:39:40 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:39:50 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:40:00 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:40:10 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:40:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:40:30 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:40:40 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:40:50 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:41:00 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:41:10 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:41:20 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:41:30 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:41:32 json: updated "/app/data/config.production.json" in-place
Jul 11 14:41:32 json: updated "/app/data/config.production.json" in-place
Jul 11 14:41:32 json: updated "/app/data/config.production.json" in-place
Jul 11 14:41:32 ===> Copy frotend/public folder for asset generation
Jul 11 14:41:32 ==> Loading /app/data/env for potential overrides
Jul 11 14:41:32 ==> Ensure permissions
Jul 11 14:41:32 ==> Migrating database
Jul 11 14:41:40 => Healtheck error: Error: connect ECONNREFUSED 172.18.17.238:2368
Jul 11 14:41:44 [2023-07-11 21:41:44] ERROR Invalid database host.
Jul 11 14:41:44
Jul 11 14:41:44 Invalid database host.
Jul 11 14:41:44
Jul 11 14:41:44 "Please double check your database config."
Jul 11 14:41:44
Jul 11 14:41:44 Error ID:
Jul 11 14:41:44 500
Jul 11 14:41:44
Jul 11 14:41:44 Error Code:
Jul 11 14:41:44 DATABASE_CREATION_FAILED
Jul 11 14:41:44
Jul 11 14:41:44 ----------------------------------------
Jul 11 14:41:44
Jul 11 14:41:44 Error: connect ETIMEDOUT
Jul 11 14:41:44 at /home/cloudron/ghost/versions/5.41.0/node_modules/knex-migrator/lib/database.js:134:19
Jul 11 14:41:44 at /home/cloudron/ghost/versions/5.41.0/node_modules/knex-migrator/lib/database.js:50:23
Jul 11 14:41:44 at Connection._handleTimeoutError (/home/cloudron/ghost/versions/5.41.0/node_modules/knex-migrator/node_modules/mysql2/lib/connection.js:202:17)
Jul 11 14:41:44 at listOnTimeout (node:internal/timers:564:17)
Jul 11 14:41:44 at process.processTimers (node:internal/timers:507:7)
The diff for this version bump is here: https://git.cloudron.io/cloudron/ghost-app/-/commit/93e180df6ad9216f8f04480b9b60212816f86c28
I've tried restoring my backup to v4.40.2 and re-applying multiple times but it continues to fail. It also fails if I use the CLI to skip this version and jump to the latest.
@jk That actually used to be possible, but the OAuth provider is now gone.
Adding something like Keycloak or even Shibboleth would add back an OAuth provider.