On Tuesday 2020-12-15 08:43, Ralf Lang wrote:

...

According to https://en.opensuse.org/openSUSE:Packaging_PHP

PHP applications should put PHP files under /usr/share/php/{<Vendor Name> or <Application Name>}.

Currently, the /usr/share/php directory is not in the filesystem package and also not provided by PHP{7,8}. Should this directory be provided by PHP{7,8} or should packages create this directory themselves as needed? Or should packages install in the /usr/share/php{7,8} instead? in my opinion, PHP code should not go into a runtime specific directory. It is feasible to run multiple versions of PHP on one machine, even

Am 15.12.2020 um 08:40 schrieb Arjen de Korte: though one would look at containers today. so usr/share/php without any version should be correct.

I would argue that, in practice, /usr/share/<theusualpackagename> (not /usr/share/php) is used, and the admin is then supposed to add a httpd configuration fragment to his apache/nginx that maps it into the URI space. Kind of like how the server:mail:kopano/kopano-webapp package does it.

Am 15.12.2020 um 09:39 schrieb Eric Schirra:

Am 2020-12-15 08:40, schrieb Arjen de Korte:

...

According to https://en.opensuse.org/openSUSE:Packaging_PHP

PHP applications should put PHP files under /usr/share/php/{<Vendor Name> or <Application Name>}.

Currently, the /usr/share/php directory is not in the filesystem package and also not provided by PHP{7,8}. Should this directory be provided by PHP{7,8} or should packages create this directory themselves as needed? Or should packages install in the /usr/share/php{7,8} instead? Why should a php-web-application go under this directory? This is totally illogical and not reproducible. For me a web application should be under /srv/www. It's not a "normal" application. It's application which runs under one server.

We had the argument for and against /srv/www for several years. I don't really feel any side of the argument is superior. We should settle for one or the other and work out the details on how to implement it and document that, not go back to the general question time and again. -- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Hi, Am 15.12.2020 um 09:57 schrieb Eric Schirra:

Am 2020-12-15 09:41, schrieb Ralf Lang:

...

Am 15.12.2020 um 09:39 schrieb Eric Schirra:

...

Am 2020-12-15 08:40, schrieb Arjen de Korte:

...

According to https://en.opensuse.org/openSUSE:Packaging_PHP

PHP applications should put PHP files under /usr/share/php/{<Vendor Name> or <Application Name>}.

Currently, the /usr/share/php directory is not in the filesystem package and also not provided by PHP{7,8}. Should this directory be provided by PHP{7,8} or should packages create this directory themselves as needed? Or should packages install in the /usr/share/php{7,8} instead? Why should a php-web-application go under this directory? This is totally illogical and not reproducible. For me a web application should be under /srv/www. It's not a "normal" application. It's application which runs under one server.

We had the argument for and against /srv/www for several years. I don't really feel any side of the argument is superior. We should settle for one or the other and work out the details on how to implement it and document that, not go back to the general question time and again.

I does not know about the old discussion. And i don't forbid my mouth. Sure, that's not my intention. I just think we should settle it either way. /usr/share has hunderd of packages/application in it. We would have no overview wath is a "normal package" and what is a web-package.

Why would I care for such an overview? I usually care for the application I want to work with - and if it's installed. We had a tradition in SUSE and debian to symlink configs to /etc/ - which also had its times of popularity and unpopularity - and treat applications as applications, independent of ruby, php, perl, python. This would argue for using fhs-inspired layouts, putting application code in /usr/somewhere and copying/linking cli to /usr/bin. The other POV is, web apps are not apps, they belong into /srv/www and they should not be treated as apps (/etc, /usr/bin) Either is good but we should have it consistent and predictable.

This is for people which have to much time. But not for people which really must work.

-- Ralf Lang Linux Consultant / Developer Tel.: +49-170-6381563 Mail: lang@b1-systems.de B1 Systems GmbH Osterfeldstraße 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537

Citeren Michael Ströder :

On 12/15/20 9:57 AM, Eric Schirra wrote:

...

Am 2020-12-15 09:41, schrieb Ralf Lang:

...

Am 15.12.2020 um 09:39 schrieb Eric Schirra:

...

Am 2020-12-15 08:40, schrieb Arjen de Korte:

...

According to https://en.opensuse.org/openSUSE:Packaging_PHP

PHP applications should put PHP files under /usr/share/php/{<Vendor Name> or <Application Name>}.

Currently, the /usr/share/php directory is not in the filesystem package and also not provided by PHP{7,8}. Should this directory be provided by PHP{7,8} or should packages create this directory themselves as needed? Or should packages install in the /usr/share/php{7,8} instead? Why should a php-web-application go under this directory? This is totally illogical and not reproducible. For me a web application should be under /srv/www. It's not a "normal" application. It's application which runs under one server.

We had the argument for and against /srv/www for several years. I don't really feel any side of the argument is superior. We should settle for one or the other and work out the details on how to implement it and document that, not go back to the general question time and again.

I does not know about the old discussion. And i don't forbid my mouth. /usr/share has hunderd of packages/application in it.

Personally I don't care about FHS and different feelings about directory layout.

But I do care about things still being functional and secure. To me it seems PHP builds are now seriously broken on Tumbleweed.

E.g. nextcloud builds are currently broken for Tumbleweed. It seems on Tumbleweed it wants to install to /usr/htdocs/nextcloud/, which seems pretty odd.

Also package roundcubemail is installed into /usr/roundcubemail *and* /usr/share/php7/Roundcube. Which also seems inconsistent.

This is a known problem, but the fix has not entered Tumbleweed yet: https://build.opensuse.org/package/rdiff/Apache/apache2?linkrev=base&rev=633

To whom it may concern: Bear in mind that people caring about security might have directory paths used in web server configs, php-fpm configs and AppArmor profiles. So announcing such massive changes here would be nice *before* breaking things.

Ciao, Michael. _______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org

On 12/15/20 12:39 PM, Neal Gompa wrote:

On Tue, Dec 15, 2020 at 3:42 AM Ralf Lang wrote:

...

We had the argument for and against /srv/www for several years. I don't really feel any side of the argument is superior. We should settle for one or the other and work out the details on how to implement it and document that, not go back to the general question time and again.

Using /srv in packages breaks their usability for MicroOS setups (e.g. openSUSE MicroOS web app appliance images, etc.). So it is strongly discouraged that applications install files into /srv.

I'd even argue that PHP applications should be configured to always run under control of php-fpm listening on a Unix domain socket. Benefits: - no need to install or alias the app into web server's document root - better process isolation - separate systemd units - privilege separation with separate system accounts, especially dir/files writeable by PHP application - no limitation to run with apache2-prefork - easier migration to nginx - separation of AppArmor profiles Caveat: - one needs to use mod_proxy_fcgi, but this is in standard packages nowadays I expect real PHP experts to come up with some more advantages and disadvantes. AFAICS darix already started some work in this direction in his OBS home repo: https://build.opensuse.org/package/show/home:darix:apps/roundcubemail https://build.opensuse.org/package/show/home:darix:apps/nextcloud BTW: darix seems to already package the Nextcloud apps, so no need to grant nextcloud write access to apps directory. Cool. Ciao, Michael.

Am 15.12.20 um 13:35 schrieb Dominique Leuenberger / DimStar:

On Tue, 2020-12-15 at 09:39 +0100, Eric Schirra wrote:

...

Am 2020-12-15 08:40, schrieb Arjen de Korte:

...

According to https://en.opensuse.org/openSUSE:Packaging_PHP

PHP applications should put PHP files under /usr/share/php/{<Vendor Name> or <Application Name>}.

Currently, the /usr/share/php directory is not in the filesystem package and also not provided by PHP{7,8}. Should this directory be provided by PHP{7,8} or should packages create this directory themselves as needed? Or should packages install in the /usr/share/php{7,8} instead? Why should a php-web-application go under this directory? This is totally illogical and not reproducible. For me a web application should be under /srv/www. It's not a "normal" application. It's application which runs under one server.

There is actually a technical argument to all this as well:

/srv is a separate btrfs volume. So if a packag installs to /srv/…, then an admin that a snapshot rollback, the RPM database O(in /usr) is being rolled back, referencing the old package, but the files on /srv stay non-rolled back, as it is intentionally split out.

/srv is for the admin to populate his data, non-packaged stuff, there we do not want a system-rollback to revert the admin (and potenitally even user data) files.

Cheers, Dominique

Hi Dominique! This is the point! RPMs should not place content in the /srv/ directory. I'm also providing some packages (mediawiki, processire) which actually can provide multiple, sym-linked instances of the same software in different path - where the source is a single directory under /usr/shared/. If the package is directly stored under /usr/shared/ or under /usr/shared/php is not that important (INHO), but AppArmor configuration could be a point for /usr/shared/php. Best regards, Johannes

_______________________________________________ openSUSE Factory mailing list -- factory@lists.opensuse.org To unsubscribe, email factory-leave@lists.opensuse.org List Netiquette: https://en.opensuse.org/openSUSE:Mailing_list_netiquette List Archives: https://lists.opensuse.org/archives/list/factory@lists.opensuse.org

-- Johannes Weberhofer Weberhofer GmbH, Austria, Vienna