See also Tikis remote management tools
Context: You want several Tiki instances on a same Virtualmin server. How to organize? How to segment data?
Most of the previous testing of Tiki Manager was done on ClearOS. And ClearOS is not designed for shared hosting but instead to have different servers per project. When we do have multiple Tiki instances (clones and test upgrades, or even completely different projects), they are on the same level.
Virtualmin is designed for shared hosting and designed to have different users with different permissions. This is great and we will use this. But there are many permutations and will require some TLC.
There are virtual servers and sub-servers:
Now how should we handle various use cases?
- An org that needs just one Tiki
- A Tiki shared hosting service
- A dev server (needs many Tikis)
- A show server: https://dev.tiki.org/show.tiki.org+Overview
Working scenario is that we must always plan for more than one Tiki instance. At the very least to test upgrades.
I dislike adding extra Tikis as example.org and example.org/21x/ and want example.org and 21x.example.org
I never want to install Tiki directly anymore. Everything should be done via Tiki Manager.
So perhaps the 1st application of all Virtualmin Virtual Servers should be Tiki Manager with a pattern as follows:
1st domain is manager.example.org
Tiki Manager CLI:
If web interface is activated:
Then, all sites follow the pattern. Ex.:
This will permit to use relative paths for all data not stored in the DB. Like https://doc.tiki.org/File-Storage#Ideal_scenario
But someone could want a different access level for dev. Ex.: So some developers don't have access to production. So production would be:
But dev would be:
But you still want Tiki Manager to permit a clone from prod to dev.
There will be recipes (probably at least 2) to get Tiki Manager working on Virtualmin:
a) A single instance of Tiki Manager running as root which manages Tiki instances in various web spaces (which Virtualmin calls virtual servers)
b) For each web space (virtual server) to potentially have its own instance of Tiki Manager. Which then opens a new question for clones / and cloneandupdate: do we push or pull?
When cloning from prod to dev (without root and when they are in two different virtual servers), it will require using SSH to same server. /home/project1/manager/tiki-manager.php will connect as devuserforproject1 to push clone.
We brainstormed on the idea that Tiki Manager could be used to install other Tiki Managers. Perhaps the root Tiki Manager could launch Virtualmin CLI/API to create a new webspace (virtual server), and install a Tiki Manager, which in turn installs a Tiki.
There are many recent changes to Tiki Manager to make it work well with Virtualmin
These changes generally also make Tiki Manager better even without Virtualmin (ex.: running as non-root)
More concerns on the roadmap:
I look forward to your ideas on how we can make this great and have all the community dogfooding
Niel suggested to not use Virtual Servers and have a pattern of