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

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.

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.

@nebulon Why do you say that? Is there something wrong with SQLite? Or you just worried about when support is eventually added?

Any insights on the issues accessing the API from a scheduled task? It would be good to get this resolved anyway.

Hey @nebulon, @girish . Any ideas how I can proceed to make this work for Cloudron?

I'm happy to patch box to use exec rather than run, or provide an option, but it's unclear why the decision was made to do run in the first place.

FYI @murgero @will I don’t think that git repo has any of the fixes or changes I’ve added. Try the one I linked much earlier. (I’m on mobile so I can’t link it now).

So I recently upgraded my Cloudron to the newest version that includes notifications. Now I get this notification once a day.

When I check my email status, it's all green checkboxes (yay!), but I still get the notification.

I checked my box logs and I found:

2019-02-25T10:30:05.219Z box:mail Ignored error - relay: Error: Timeout
    at Socket.<anonymous> (/home/yellowtent/box/src/mail.js:150:18)
    at emitNone (events.js:106:13)
    at Socket.emit (events.js:208:7)
    at Socket._onTimeout (net.js:410:8)
    at ontimeout (timers.js:498:11)
    at tryOnTimeout (timers.js:323:5)
    at Timer.listOnTimeout (timers.js:290:5)
2019-02-25T10:30:06.347Z box:mail checkRblStatus: myhost.com (ip: 123.456.789.101) servers: []
2019-02-25T10:30:06.348Z box:cloudron checkMailStatus: myhost.com failed status checks
2019-02-25T10:30:06.352Z box:notifications upsert:  uid-9261ef5c-e91a-4d31-9575-4fb5fd7cfa08 Email is not configured properly /#/email

Looks like there is some kind of bug in the checker logic.

In an effort to build better monitoring, it would be good to look at supporting existing tooling as well. For example, a Prometheus exporter would allow users to take advantage of the robust feature set offered by Prometheus and Grafana. Or, if Cloudron already stores persisted metrics in a graphite database or something, a way to connect to that from an external server running a monitoring suite would suffice.

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.

@nebulon not really. It just said it cannot connect.

@fbartels I see. Yea, totally agree that it’s not really necessary for most folks usage. The instance I run outside of Cloudron today uses neither of them. I’m using it as a simple personal password manager.

I believe Cloudron tends to prefer configurations that are ready for a small enterprise. My personal Gogs server was fine with SQLite and local auth as well, but Cloudron is configured with MySQL and LDAP.

‍️

@fbartels what issues are you having with the LDAP sync?

FYI @murgero @will I don’t think that git repo has any of the fixes or changes I’ve added. Try the one I linked much earlier. (I’m on mobile so I can’t link it now).

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?

Hey @girish any updates on this? I've been holding off on migrating from my external instance to my Cloudron one because I'm not sure about the process of migrating from the dev one to an official one. Any guidance on when to expect this or if it's possible to preserve the Docker volume would be helpful.

@girish I'd be neat if that gets merged, but the maintainers rejected a previous patch for direct LDAP support and that's why it was moved to a different binary. See comments here: https://github.com/dani-garcia/bitwarden_rs/pull/396#issuecomment-464059020

@girish there are lots of open source projects that offer paid/proprietary services out there. You can point to Ubuntu or Android as very popular ones.

As someone who has contributed (albeit only a few small patches) I'm quite surprised to see an attempt to change the license. I'm also not sure that the license change is legal. I am not a lawyer, but my understanding of AGPL would be that since there was no CLA (or was there? I don't remember singing one for Cloudron) signed by contributors, each contributor owns the rights to their patches. To change the license, you would need approval by each contributor. If those patches are still AGPL, then any additional changes to the code base since then must also still covered by AGPL in order to be in compliance.

@girish great to hear! Let me know if there is anything I can do to help.

@murgero I’ve been meaning to do the same.

Should be doable with something like HAProxy, but I wanted to use some better auth mechanism, so I’ve been working on this: https://git.iamthefij.com/iamthefij/dockamole

The server is essentially just an ssh server that is configured to disallow running commands and only allow port forwarding. The client can be run anywhere and it exposes the ports for you.

I’m planning to run a server on my Cloudron to forward LDAP and Graphite (hopefully), and then I can deploy a client on my other VPS. I also plan to do the same with my NAS at home so I can have my VPS access it without exposing http access to my home network.

There are many ways to do this though.