[BlueOnyx:24977] Re: Feature Request Copy-Site

[Michael Stauber]

Hi Dirk,

> based on a customer's request and my own experience, I would find a
> "copy site" option very helpful.
> 
> This means copying the files under web (or wwwroot under 5210R), the
> database(s) created for the site via Blueonyx and the settings for PHP.
> 
> You can create an admin user for the copied site yourself afterwards.
> 
> The copy could be a button that turns <name>.<domain> into
> copy_<name>.copy_<domain>. In any case, web and e-mail aliases should
> not be copied. Users should also not be copied into new users.
> 
> Or you could enter a target name . domain to which it should be copied.
> The IP can be retained.
> 
> The function would be practical to create a test site or to make a live
> site out of a test site.


There are a couple of complications with this, but it's feasible.

Say a Vsite has a Wordpress install deployed via WebApps and the
obligatory RoundCube. It runs PHP-FPM with PHP 7.4.

We now intent to copy the Vsite. A new (empty) Vsite is created with a
slightly different name and the same IP.

WebApp-Installer will automatically deploy a new RoundCube into that, so
we just ignore to copy the old RoundCube over and will also skip the
copy of its SQL database.

We configure the copied Vsite with the same settings (minus the aliases).

Now it gets complicated with any remaining deployed WebApps such as the
mentioned Wordpress. I need to instruct the WebApp installer to deploy a
blank Wordpress into the same path as on the original Vsite. Then I need
to trigger a web files and SQL backup on the source Vsite, copy that
over to the Vsite copy and restore it there.

Next we perhaps want to copy all *other* files from /web over, which
could play havoc with the just restored Wordpress and freshly deployed
RoundCube that got automatically rolled out when the new Vsite was
created. A copy transactions should therefore perhaps ignore the
directories where these are installed. Yet that might cause missing
files if Wordpress was directly installed into /web.

So it has to be the other way around: Copy /web (ignoring /roundcube),
then restore the WebApp files.

If there are now WebApps deployed via the GUI, then we just copy /web
instead and be done with it.

That's doable.

However: Once copied that way the Vsite needs an admin user as
Web-Owner, of PHP-FPM or suPHP will barf. And if we copy interactive
sites this way (like Wordpress and others) the copied SQL database
and/or config files still have incorrect paths and/or URLs and/or SQL
access details configured in their SQL database and/or config files.

So one way or another: The person who triggered the copy or the person
who wants to manage it still has a lot of manual work ahead of him
before he has a *working* copy that he can mess with.

Next issue: ACLs.

Who's allowed to use the Site-Copy function? Admin for sure. Or other
users with 'serverAdmin' privileges that include 'VsiteManagement'.
Which *could* be a reseller account. In which case the Vsite copy could
directly be assigned to be under his management.

A 'siteAdmin' can only manage one Vsite. So even if we give him the
grantable right to use Site-Copy, he wouldn't be able to manage the
copy. Unless we set up a new siteAdmin account directly for him and let
him know the login details.

Yet: If it's just for siteAdmins (where it would perhaps be more useful)
we could make the copy inside a subdomain. That has the benefit that
everything remains contained in that Vsite:

Same PHP version, same disk quota, same siteAdmin and "Web-Owner" (for
PHP-FPM and suPHP) and that directly eliminates a whole batch of
transient issues.

We could also skip tying this into the WebApp installer, as the copy is
run outside of the management of the WebApp installer for as long as the
copy remains in the subdomain directory. It can easily be brought back
under WebApp's management by copying the subdirectory back into the web
path of the Vsite and/or copying the copies SQL database back into the
original database.

So if we use the subdomain approach for Site-Copy it would be a lot
fewer hassles. Both on the coding front as well as on the end-user
front. Because the existing siteAdmin already has all the rights,
privileges and tools at his disposal to deal with the copy forwards and
backwards.

You might say that that right now subdomains don't have SSL, so for
testing it would be kind of suboptimal. That's true. However: Taco
Scargo had requested that feature (SSL for subdomains) recently and I'm
about to roll it out in the next few days. RPMs for it are already in
the BlueOnyx-5210R-Testing repository.

So doing a copy of a Vsite into a subdomain on the same Vsite could
still be accessed via SSL, provided the Vsite either has a Wildcard
certificate or a Let's Encrypt certificate that includes the DNS name of
the subdomain. The LE page in the GUI has been reworked in that regards.

I have to think a bit more about it, but yeah: I can make that work.

-- 
With best regards

Michael Stauber