[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