#5642 - demonstratr: Re-work Demonstratr for v11
-
By PDStig
- Added
- 3 views
| Identifier | #5642 |
|---|---|
| Issue type | Feature request or suggestion |
| Title | demonstratr: Re-work Demonstratr for v11 |
| Status | Closed (rejected) |
| Tags |
Roadmap: v11 (custom) |
| Handling member | Deleted |
| Addon | General / Uncategorised |
| Description | Re-work the demonstratr addon for version 11 so it works with composr.app and how the server running composr.app is structured.
composr.app server has tighter security than compo.sr server. So things like root MySQL, direct git access, and domain management cannot be performed via scripts. Therefore, Demonstratr will have to operate differently. * Set up demo.composr.app. All Demonstratr instances will fall under this sub-domain. Instead of having sub-domains for every instance (cannot do this with the tighter security), each instance will be a subdirectory on this domain. The main demo.composr.app page will just redirect to the page on composr.app for setting up a personal demo. * Use the XML DB instead of MySQL for personal demos. We can't use root (security), so we can't create databases automatically for instances. It would be much easier just to use XML as it's flat-file (so it can simply and quickly be discarded with the instance / directory). And since these are just temporary personal demos, we don't care about the performance caveats since these will not be production sites anyway. * Don't use templates. When someone elects to start up a personal demo, just extract the contents of the latest release into the appropriate subdirectory and do_install_to it (with the XML DB). Make sure to install pre-defined content as well. * Keep track of running instances by member (so require a member account on composr.app to set up a personal demo. This will significantly decrease spam instances and will only allow one instance per member at a time). * Delete installations after 7 days. Members can always create a new one if they weren't finished exploring the features. This isn't about letting members maintain their demo configuration. It's just about letting them try the features. If they want to save everything, they should install v11 themselves on their own server / host. * Make sure instances are chrooted. Don't allow doing anything outside the instance's own subdirectory. I think Composr's hack attack system is good enough but double-check on this. Make sure even the administrator can't do anything too damaging (especially in Commandr). * SSH and FTP cannot be automatically set up either for security reasons. Therefore, perhaps we should also specify a Demonstratr list of non-bundled addons to install as well with every instance. And make WebDAV one of them. * Lock down any config options that should never be changed on Demonstratr instances even by admins. I think there's a hook to do this. Add a template for this in Demonstrator itself. |
| Steps to reproduce | |
| Additional information | By re-working Demonstratr over time, we can ensure members can still create personal demos to try out v11 before they install it for themselves. |
| Funded? | No |
The system will post a comment when this issue is modified (e.g., status changes). To be notified of this, click "Enable comment notifications".
Comments
Our competitors don't do it, and it was always horribly difficult to maintain and a performance worry.
Hosting demos would be a great thing for an interested third party to provide, and then this could be linked to our site however people voted for it to be.
We also are holding back the market, as companies maybe would consider having free Composr trials if we didn't effectively do the same thing.
Should we leave it in the repos? My suggestion is we make a new repos for "archived" addons so we can keep them out of the main development branch and thus don't have to worry about it breaking anything being there and having to put unnecessary maintenance time into it.
Great idea!