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

Tomohiro Hosaka bokutin at bokut.in
Sat May 30 08:17:21 -05 2020


Hi Michael,

As an aside, mariadb 10.4 was successfully installed without breaking 
the availabirity of phpmyadmin on the control panel.
I like the stable version, but it was requested by the customer.
https://wordpress.org/about/requirements/

This is the main subject.

I am worried about the following points.

* The source vsites were all prefered_siteAdmin eq ''.
* In this case, even if you try to select from siteAdmin, there may be 
two or more users and it will not be automatically selected.
* With prefered_siteAdmin eq '', easy-migrate.pl does 
--chown=nobody:siteXX.
* As a result CGI does not work.
   CGIWrap Error: Execution of this script not permitte
   Execution of (nobody) is not permitted for the following reason:
   User not Privileged.
* When doing --chown=$siteAdmin:siteXX, because exceeds the quota often, 
we will need to reconfigure the quota.
* In addition, if the migrate to UID=$siteAdmin, I think also, if it is 
also possible to turn off the option of PHP DSO.

I also understand that a lot of improvements are included by migrating 
to PHP-FPM & UID=$siteAdmin.

Thank you for the very fulfilling explanation.

I would like to worry a little while imagining the modification of 
easy-migrate.pl and the operation after migration.

Thanks,


On 2020-05-29 05:23, Michael Stauber wrote:
> 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.


More information about the Blueonyx mailing list