[BlueOnyx:23908] Re: easy-migrate.pl 5208R(PHP DSO) -> 5209R(suPHP)

[Michael Stauber]

Hi Tomohiro,

> Thank you for locale/ja_JP/*.po merged.
> I resumed the migration verification work this morning, and was
> impressed when it was updated!

Very well. :-)

> I also know there is a problem with PHP DSO on the 5208R. For example,
> files created by PHP are not included in the quota because their
> permissions are apache.
>
> I also understand that suPHP uses fork(not "pre"fork) and has a very
> different execution model than PHP DSO.
>
> Also, why did you choose suPHP and not mod_ruid2?
> I think mod_ruid2 fixes UID issues and is more like 5208R PHP (DSO) in
> terms of DSO.
> Or are you considering the following?
>> https://github.com/mind04/mod-ruid2

Yes, mod_ruid2 is included as an option in BlueOnyx since 5209R. We
never ported it back to 5207R/5208R because the changes in PHP
implementation would have massively disrupted services on existing
servers during a YUM update.

Let us look at the different PHP implementations first, before I go over
your suggested code changes for Easy Migrate.

5207R/5208R ony supported one PHP version and allowed either DSO or suPHP.

5209R/5210R allow DSO, DSO+mod_ruid2, suPHP and FPM/FastCGI - plus the
ability to have multiple different PHP versions installed at the same
time. If suPHP or FPM/FastCGI is used, then each Vsite can run whatever
PHP version you need it to run. Ranging from PHP-5.3 -> PHP 7.4 on 5209R
and from PHP 5.6 -> PHP 7.4 on 5210R. PHP PKGs are available in the
BlueOnyx shop.

The following PHP implementations are available on 5209R/5210R:
================================================================

PHP (DSO): This should not be used. At all. PHP scripts need to be owned
by apache:apache, which ignores quota, creates security issues and
prohibits uploads/edits via FTP.

PHP (DSO) + mod_ruid2: This is slightly better, as it allows you to run
PHP scripts with the UID/GID of one of the siteAdmins. Which one can be
configured under "Site Management" / <Vsite> / "Services" / "Web Ownership".

suPHP: suPHP has performance issues and of all the available methods
it's the least desired. It's only saving grace is that it runs the PHP
scripts with the UID/GID of one of the site administrators and also
allows you to run whatever PHP version you want.

FPM/FastCGI: Generally you *should* use PHP-FPM on 5209R and 5210R. It
is fast, can be individually configured and each Vsite can use whatever
PHP version it needs. And it can run the scripts with the UID/GID of one
of the site administrators.

The DSO method is (typically) based on the PHP version that is included
via the OS, but it can also be universally switched to a newer PHP
version by installing a PHP PKG from the shop and switching the server
to use this one instead for DSO.

A 5207R/5208R uses PHP 5.3.3 for DSO
A 5209R uses PHP 5.4.16 for DSO
A 5210R uses PHP 7.2.11 for DSO

Now say you're migrating from a 5209R to 5210R via Easy-Migrate. Your
Vsites were using PHP as DSO (5.4.16) for some Vsites and suPHP with a
newer PHP-7.1 for some other Vsites.

All the migrated Vsites that used to use PHP-5.4.16 via DSO would now
run on 7.2.11 if the DSO method had been retained. This would most
likely break all the Vsites that were using DSO before.

For that reason Easy-Migrate switches them to suPHP on migration and
keeps these Vsites running on whatever PHP version they had before -
provided that PHP version is available on the target system.

This causes the least problems in my view.


> +                    # if (($SYSTEM{'System'}{'productBuild'} ne
> '5210R') && ($SYSTEM{'System'}{'productBuild'} ne '5209R')) {
> +                    #     if ($Vsite_NameSpace->{'suPHP_enabled'} eq "1") {
> +                    #         $Vsite_NameSpace->{'mod_ruid_enabled'} = "0";
> +                    #         $Vsite_NameSpace->{'fpm_enabled'} = "0";
> +                    #         $Vsite_NameSpace->{'enabled'} = "1";
> +                    #     }
> +                    #     elsif ($Vsite_NameSpace->{'enabled'} eq "1") {
> +                    #         $Vsite_NameSpace->{'suPHP_enabled'} = "1";
> +                    #         $Vsite_NameSpace->{'mod_ruid_enabled'} = "0";
> +                    #         $Vsite_NameSpace->{'fpm_enabled'} = "0";
> +                    #     }
> +                    #     elsif
> ($Vsite_NameSpace->{'mod_ruid_enabled'} eq "1") {
> +                    #         $Vsite_NameSpace->{'suPHP_enabled'} = "0";
> +                    #         $Vsite_NameSpace->{'fpm_enabled'} = "0";
> +                    #         $Vsite_NameSpace->{'enabled'} = "1";
> +                    #     }
> +                    #     elsif ($Vsite_NameSpace->{'fpm_enabled'} eq "1") {
> +                    #         $Vsite_NameSpace->{'suPHP_enabled'} = "0";
> +                    #         $Vsite_NameSpace->{'mod_ruid_enabled'} = "0";
> +                    #         $Vsite_NameSpace->{'enabled'} = "1";
> +                    #     }
> +                    #     else {
> +                    #         $Vsite_NameSpace->{'suPHP_enabled'} = "0";
> +                    #         $Vsite_NameSpace->{'mod_ruid_enabled'} = "0";
> +                    #         $Vsite_NameSpace->{'fpm_enabled'} = "0";
> +                    #         $Vsite_NameSpace->{'enabled'} = "0";
> +                    #     }
> +                    # }

No, sorry! *THIS* section absolutely *must* stay in. :-)

I can understand why you commented it out to fix the particular problem
you saw. And that's fine if it solves a problem you had.

But the PHP implementation changed drastically between BlueOnyx 5208R
and 5209R when we added DSO+mod_ruid2 and FPM/FastCGI, which previous
versions of BlueOnyx didn't have.

This section of code makes sure that the PHP settings get adjusted to
the correct (new) format when importing from a 5207R/5208R to a 5209R or
5210R.

> I assume that the reason for changing to "rsync ... --chwon=" and
> suPHP in easy-migrate.pl is to try to fix the above problem in this
> phase. Do you have?
> If the guess is correct, I would consider not chowning during this
> phase and having time to fix chown after migration.

"Easy-Migrate" chowns files and folders on import directly to the owner
that *should* own the files and folders. When we import DNS data, we
chown to "named:named". When we import User data, we import to
"<username>:<new-Vsite-Group>". Likewise, data in the Vsite directory is
chowned to whatever UID:GID it must have. Typically that's the UID of
the siteAdmin that's specified under "Web Ownership".

Anything under the /web directory will get chowned to the GID that the
Vsite now has and to the UID of the siteAdmin who is specified under
"Web Ownership", so that DSO+mod_ruid2, suPHP and PHP-FPM can work with it.

5210R also has a very complex permission set that *must* be set
correctly for Chroots to work and Easy-Migrate also directly enforces
the correct permissions on import.

My suggestion for your usage case (5208R -> 5209R) would be this:

1.) Import via Easy-Migrate.
2.) Switch all Vsites to FPM/FastCGI
3.) For each Vsite select a siteAdmin under "Web Ownership" that owns
    the files of the Vsite and whose UID:GID will be used to run PHP
    scripts.

If you can't or won't be able to use FPM/FastCGI, then use DSO+mod_ruid2
and also for each Vsite select a siteAdmin under "Web Ownership".

That way you'll have the least issues in the future and all your PHP
scripts run with an UID:GID that is associated to the Vsite they belong to.

-- 
With best regards

Michael Stauber