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

Ability to run NC in a subdir #14

Closed dumblob closed 2 years ago

dumblob commented 2 years ago

I'd like to have a choice to run NC in a subdir as documented in https://docs.nextcloud.com/server/stable/admin_manual/installation/nginx.html#nextcloud-in-a-subdir-of-the-nginx-webroot (on cloud.example.com). It's to allow hosting of wordpress on the same machine (on example.com).

Do you perceive this also as useful?

downtownallday commented 2 years ago

The issue I see with supporting it are the expectations that additional installed software, like Wordpress, will continue to work properly when cloudinabox is upgraded. Or that conflicts don't arise when system software is upgraded or cloudinabox is updated. For those reasons, I can't add this in directly.

That said, I think it would be helpful to have a contrib directory containing scripts for modifying the installation that could be activated manually. They would be "use at your own risk", and maintained by the script creator independent of the project.

In mailinabox-ldap, any script appearing in the 'local' directory is run after setup, which gives an opportunity to modify or add something to setup. Contrib scripts on mailinabox-ldap are in setup/mods.available, you just create a symlink in local to the mod to activate it. A similar thing could be done here.

In this case, a setup mod could remove the ngnix symlink for nextcloud in /etc/nginx/sites-enabled, and add in a new one that does what you want.

dumblob commented 2 years ago

That said, I think it would be helpful to have a contrib directory containing scripts for modifying the installation that could be activated manually. They would be "use at your own risk", and maintained by the script creator independent of the project.

Sounds reasonable. I'd then expect the installation "wizard" to ask about these additional unsupported contributed things at the end of the installation process (an interactive multiple-choice menu?).

The reason for this is to make it part of the fully automated update process (and rely on compatibility checks inside of the contrib scripts themself - e.g. I'd save md5 of the /etc/nginx/sites-enabled/nc... file and check it before removing the symlink - if the check would fail, then the whole contrib script would fail and inform user about it).

What do you think?

downtownallday commented 2 years ago

I don't think any changes to setup is needed or desired. If a site wants to use a contributed script, they just create the symlink themselves.

Say you create a script for "NC in a subdirectory" called "nc-in-subdir.sh" and it's committed into setup/mods.available. All that's needed is for the site owner to create a symlink local/nc-in-subdir.sh -> setup/mods.available/nc-in-subdir.sh.

New information in the README would explain this.

The "local" symlinks don't go away with upgrades, or updates since "local" is not a committed git directory.

"local" could also be a symlink to /home/user-data/local so that if a server is restored from backup, the same setup mods would still work.

dumblob commented 2 years ago

"local" could also be a symlink to /home/user-data/local so that if a server is restored from backup, the same setup mods would still work.

Yep, this should be mentioned as "recommended" in README.

Btw. could the setup "wizard" after the whole installation process succeeded at least point out the same things as the README? Namely the existence of "contrib" scripts and how to work with them in a recommended way?

downtownallday commented 2 years ago

sure

dumblob commented 2 years ago

Thanks! I hope I'll get to the nextcloud_in_subdir (any suggestions for a better name?) module rather sooner than later.

downtownallday commented 2 years ago

Nice. Name seems fine to me.