@girish Hi , I have made sure that that my repo should not have any git data or meta data. I even tried shrinking the app on my end as much as I can. If you want to take a look on the app , here it is : https://github.com/llaske/sugarizer
Yes that should work fine. Based on the information you gave, I assume each one of your customer has an individual domain, which can be added to your Cloudron and then the corresponding apps installed on subdomains of that. Once a domain is added, the email server and mailboxes can be managed for each domain individually.
That is going to be a bit hard to add at the moment, since the data model for access controls is user and group based and the admin status is just a flag on the user record. This may be possible once we have more fine grained access controls and a real admin group as such.
add the following info in the "Ldap Login" settings:
LDAP server host: 172.18.0.1
LDAP port: 3002
BASE DN of LDAP server: ou=users,dc=cloudron
Users Branch: ou=users
LDAP attributes: ou=users,dc=cloudron
Attribute corresponding to the user name: username
Groups Branch: ou=groups,dc=cloudron
Attributes corresponding to the group name: cn
Admins group: users (not working)
In the "New users when LDAP auth is successful" tab check
Should new Piwigo users be created when users authenticate succesfully via LDAP?
Automatic group settings don't work, maybe that's my fault, this means after a user is successfully logged in, you have to manually change his/her group to whichever you want. There's also the mentioning of an OpenLDAP bug on the page, but that's where my french stopped working and I didn't use that code.
@girish thanks for getting back on this. Had to playing around with the apache2 configuration and was finally able to figure out a way that works. To make a long story short: ProxyPreserveHost lead to a infinite loop. As soon as I removed it, things started working.
I am not sure if smtp_forward will work for your use case.
oh, that is indeed true. I stumbled upon something that suggested that this could be achieved with smtp_forward, but reading the page closer this indeed would not work as desired for me.
I'd rather want to avoid fetching mails from cloudron the the extra server. I'll have to think about some alternative approaches (maybe stick with my current relay setup and just make cloudron one of the relay targets).
@El-Gavy Good question, thanks for asking. The Cloudron backend is FOSS and usable completely standalone and you can use it without the fontend or the Cloudron App Store. It's actually very similar to other projects like dokku, flynn, deis, kubernetes, docker etc in that regard. These projects are also "backend" software and have no web interface to do stuff. To make the backend "useful" out of the box, our app packages are also open source.
The Cloudron frontend (web interface) makes use of the REST API and is part of our Open core style business model. The Cloudron App Store is a service for 1-click deployment and update of curated apps which is also part of our business model.
IOW, I like to think of Cloudron frontend as building on an opensource components akin to products like Docker Data Center and Tectonic (which are closed source).