@girish Even the "changeme" note might be good enough.

Cool, this is great, thanks! Even if it's not perfectly dynamic this will save me a lot of typing 🙂

@vincitygialam There are probably better forum to discuss this. This forum is for discussing Cloudron related stuff.

@uiharu We have implemented this now in our latest release. Should be out in the coming week or so.

https://cloudron.io/developer/api/#update-user-password is the API

We are working together with Reclaim Hosting and Bates University to create a new edition of Cloudron for this specific use-case. Please contact us at support@cloudron.io for futher information.

@saglagla There are no plans for any kind of multi IP setup at the moment.

I will mark this as solved for now, as the main issue to change the domain appears to be solved.

Hi, there is already an issue for the feature request at https://git.cloudron.io/cloudron/box/issues/283 lets track it there.

Thanks for the heads up about the broken documentation links, we fixed them now.

This is released now.

@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

This is implemented as part of next release.

This feature is now merged to master and will be part of the next release. There is still some amount of testing needed.

If someone has an opinion on which http status code we should be using, please respond here. Currently I have put a 301, but I am not yet sure if this is dynamic enough for our use-case.

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.

This software should be able to do this
http://duplicity.nongnu.org/index.html

Hi @adamlevine ,

are any of these (Zoho and Mautic) installed on Cloudron? I don't see either of these in the app store of cloudron.

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.

Nano will be part of the next version of the app base image. However there is no schedule currently when that will be released.

@alexy here it goes:

install an empty lamp app

install piwigo (download from http://piwigo.org/download/dlcounter.php?code=latest)

following this tutorial http://www.jouvinio.net/wiki/index.php/LDAP_Plugin_Piwigo and put https://github.com/kvakanet/ldap_login/archive/config2base.zip as ldap_login in your plugins directory and activate it in the backend

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.

Let me know how it goes.

@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've put together the final app here, maybe this is of use for someone else:
https://git.cloudron.io/mandelkind/proxy-app

Given the fact that I had to play around quite a bit, maybe we should add this to the app store as well? As a helper app, like the LAMP one.

@girish said in smtp_forward for Haraka?:

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).

Thanks for looking into this!

This is now implemented, will be part of 2.2 release

@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).