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

[Dirk Estenfeld]

Hello Michael,

whow, thank you very much fort he very detailed feedback.

Webapps: Yes, my suggestion would also be your 2nd way (i.e. copy from
/web). Because otherwise it might end up no longer being a copy.
You "only" have to copy the database where there are databases in the
webapps and change the information accordingly in the copied webapp
information.

Yes, of course, the copier has to adapt the configs in the copy so that it
doesn't run around on the original database. But from my point of view, a
text hint is sufficient here. 
Yes, of course, you need a site admin. But here I would also have said that
you have to create it manually afterwards and then change it to the
siteadmin under Services/Web Owner. Because if you automatically create a
new site admin, it probably won't suit some people and they will delete it
again and create a new one.
Another issue is the user site prefix (if set), which of course must not be
taken over, or must be changed.

I would say that anyone who is also allowed to create sites may create
copies.

Hmmmm, indeed, subdomains would also be a possibility for the copy, but here
I think we have the problem that subdomains are created "strangely". You
don't have an /etc/httpd/conf/vhsots/site<nr>_sub<nr> and
/etc/httpd/conf/vhsots/site<nr>_sub<nr>.include file but some weird
constellation under (I think) conf.d. You have hardly any possibilities to
make adjustments to the web server config and if you do, they will be
overwritten the next time you change the web server config in the GUI or you
trigger config recreates within a yum update. So if we want to go the
subdomain way, which would of course also be charming, then the subdomains
would have to be created more as full domains.
If you would take over the config of the subdomains into the "normal"
config, then the SSL issue could also be solved differently, because then
theoretically each subdomain could get its own LE certificate.

My idea (or that of our customer) was a "real" copy into a new site. Because
then you have your own siteadmin, a separate directory, a different database
etc. but the settings can be made or changed in the same way. 
I may need a copy because I want to test an update of a software to a
different version and then I may have to use a different PHP version for the
copy. Then I am already at the end of my possibilities with a subdomain.
So all in all, I don't think the subdomain idea is so good. As written.
Unless you blow up the subdomain so much that it basically amounts to a site
within a site.

Maybe there are other (silent) readers here who have an input?

Best regards,
Dirk


blackpoint GmbH – Friedberger Straße 106b – 61118 Bad Vilbel 


-----Ursprüngliche Nachricht-----
Von: Blueonyx <blueonyx-bounces at mail.blueonyx.it> Im Auftrag von Michael
Stauber
Gesendet: Dienstag, 22. Juni 2021 19:51
An: blueonyx at mail.blueonyx.it
Betreff: [BlueOnyx:24977] Re: Feature Request Copy-Site

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
_______________________________________________
Blueonyx mailing list
Blueonyx at mail.blueonyx.it
http://mail.blueonyx.it/mailman/listinfo/blueonyx
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5506 bytes
Desc: not available
URL: <http://mail.blueonyx.it/pipermail/blueonyx/attachments/20210624/7b949375/attachment.p7s>