search

downtownallday / cloudinabox

An installation of Nextcloud that borrows some of the "Mail-in-a-Box" code and standards
Other
2 stars 1 forks source link

Motivation for "existence" and difference to mailinabox-ldap #1

Closed dumblob closed 4 years ago

dumblob commented 4 years ago

Hi, I just came across this endeavor and I find it awesome. On the other hand I'm asking myself why does cloudinabox even exists if you already actively maintain mailinabox-ldap which seems to fill the same purpose while being "more" compatible with the original mail-in-a-box which means less maintenance of the fork than maintaining a completely separate project cloudinabox.

Could you maybe shold some more light on the differences and motivation?

Thank you!

I was about to deploy your mailinabox-ldap, but I'm currently unsure whether I shouldn't choose cloudinabox instead.

downtownallday commented 4 years ago

Thanks for noticing this project - you're the first!

Cloudinabox is a full Nextcloud installation for cloud-based file sharing plus all the other things Nextcloud can do. Whereas, mailinabox-ldap is a mail server. Although mailinabox includes a Nextcloud installation, it is there just for calendar and contacts.

Cloudinabox and mailinabox-ldap are meant to work together, providing a simple, easy to deploy cloud server for file sharing along with a mail server, both of which share the same user account database (via LDAP).

When integrated, contacts and calendars for mailinabox-ldap are provided by cloudinabox and the mailinabox Nextcloud is disabled.

I was motivated by some of the principals Josh architected with mailinabox that I wanted to keep with cloudinabox to make administration consistent and easy to maintain, such as automatic SSL/TLS certificates with Let's Encrypt, simple duplicity-based backups, updates made by the setup script, restore from backup running a simple setup script, etc.

I hope that answered your questions.

Thanks

dumblob commented 4 years ago

Thanks a lot for the quick response!

Yes, you answered all my questions. But a few additional arose out of it :wink:.

1) Do you have some long-term (years) plans with cloudinabox or is it just something you're "testing" or making for fun? In other words, do you have some real serious use cases backing the development/maintenance of cloudinabox or rather not?

2) Thanks a lot for clarification of the difference between mail-in-a-box/mailinabox-ldap and cloudinabox - I wasn't aware of the fact, that mail-in-a-box didn't have standard Nextcloud installation, but rather a limited one with no easy/supported way to promote it to a full-featured unrestricted Nextcloud instance (my plan is to use quite some modules in Nextcloud including picoCMS with mod_rewrite). I'm new to MIAB (I came across MIAB as I don't want to maintain mail & Nextcloud servers manually any more and make everything way more /fully?/ automated).

3) Are there any known drawbacks or non-goals or issues or todo items for cloudinabox?

4) Do you already know you need or will need some help with maintenance/development of cloudinabox?

downtownallday commented 4 years ago

No long-term lofty plans, per se. I actively use cloudinabox (plus mailinabox-ldap) on my own servers and will keep the projects going for the foreseeable future.

I've accomplished what I wanted to do with cloudinabox and it's working well for me. There are a number of things I'm considering like adding automated tests with Travis-CI support and a CLI since there is no web administration component.

4: As needs/ideas arise, sure!

BTW, Josh wasn't interested in adding LDAP support to mailinabox, which is why I forked it and created mailinabox-ldap.

dumblob commented 4 years ago

CLI since there is no web administration component

Yep, that sounds kind of important. At least for changes to DNS - e.g. adding/removing domains, subdomains, etc. (I believe there won't be need for any super advanced stuff though - just these "routine" tasks could be made easier with "compatibility & update" semi-guarantee provided by such administration tooling).

If you use proxy_pass with nginx on your cloudinabox servers, could you publish which rules do you use? As I wrote I'd like to try using pico CMS - namely for the main mydomain.tld landing site (and having e.g. mydomain.tld/cloud for Nextcloud). Is such use case supported by cloudinabox? I'm asking to avoid surprises like LE cert issuing not working etc.

BTW, Josh wasn't interested in adding LDAP support to mailinabox, which is why I forked it and created mailinabox-ldap.

That's how I came across these two repos of yours :wink:.

downtownallday commented 4 years ago

Just to be clear - the CLI would be for cloudinabox, and although I said cloudinabox doesn't have a web interface, Nextcloud does, which is 99% of what matters anyway.

BTW, DNS and its configuration is handled by mailinabox-ldap, which has a web admin interface (same as mailinabox's).

As for using a prefix for Nextcloud ("/cloud") - that is currently not supported. But, if you're interested in Pico CMS for Nextcloud, you would just install pico cms from the Nextcloud admin interface once cloudinabox is installed.

https://apps.nextcloud.com/apps/cms_pico

dumblob commented 4 years ago

BTW, DNS and its configuration is handled by mailinabox-ldap, which has a web admin interface (same as mailinabox's).

Sorry, I misunderstood. Then I currently can't think of any good frequent real use case for some CLI tooling :wink:.

But, if you're interested in Pico CMS for Nextcloud, you would just install pico cms from the Nextcloud admin interface once cloudinabox is installed.

Sure.

Without the /cloud URL rewriting the pico CMS (or any other) wouldn't make much sense for my use cases. Can you think of any downsides of using plain rewriting rules in cloudinabox to achieve the /cloud behavior while allowing https://mydomain.tld/index.php/apps/cms_pico/pico_proxy to become the landing (/) page?

downtownallday commented 4 years ago

Maybe using two virtual hosts would work using two tlds or subdomains. For example, cloud.mydomain.tld and cms.mydomain.tld (or maybe just mydomain.tld for cms, but am unsure if that would work). cloudinabox uses nginx's "sites-available" / "sites-enabled" directories, so you could add your own there.

dumblob commented 4 years ago

Actually it should work as you write: https://github.com/nextcloud/cms_pico/issues/57#issuecomment-626093968 . Thanks for your support - I must give cloudinabox a try!