php70u

[slashterix]

Hurray! PHP 7 is finally a thing! http://php.net/archive/2015.php#id2015-12-03-1

Would you like me to list the other packages I use in PHP here or in separate issues?

[carlwgeorge]

Howdy @slashterix,

Thanks for your request. Let's get the main php70u package done first before we start down the module rabbit hole. When we get to that point, a separate issue for each module will be preferred.

Here is our standard review process for new package requests.

1. Is the new package a good fit for IUS?
2. Is the new package maintainable with our current resources?
3. Is the requester willing to test the new package to ensure it works as expected?

PHP is certainly a good fit for IUS, and should be maintainable. Of course we knew this was coming, so I've been working on this in the background for a bit now. There are some significant changes, so it's a more complicated update than just s/5.6.16/7.0.0/ in the spec file. I'll keep this issue updated with my progress.

Please confirm item 3, that you are will to test the packages when we create them.

[slashterix]

Yes, I will help test these packages once they come out. My devs are super excited to get their code on faster PHP.

[Xon]

:+1:

[carlwgeorge]

Interested parties can watch this repo for updates.

[carlwgeorge]

Whenever we start a new package, we like to evaluate possible changes to make going forward. We have several ideas for PHP 7.0 that we would like community feedback on. Initial packages have been built and are available in our development repos (yum --enablerepo=ius-dev) for EL6 and EL7, which demonstrate some of these ideas.

package name for Apache HTTP Server module

In Fedora and RHEL, the php package is actually the Apache HTTP Server module for PHP, commonly known as mod_php. This is inconsistent with other Apache HTTP Server modules (mod_wsgi, mod_perl, etc), and causes confusion for new users who assume that the php package is the PHP language (actually contained in php-common). I submitted an RFC to Fedora to rename the php package to mod_php. If Fedora accepts the RFC, we will definitely make a similar move. If Fedora declines the RFC, we might still make a change for IUS. At this point the RFC seems to be positively received and could be done as part of the Fedora update to PHP 7. Unfortunately, that might not happen until Fedora 25. We would like to make a decision for the IUS PHP 7.0 packages now. The initial packages are using the name mod_php70u; we could alternatively use the name php70u-mod_php. It has a virtual provides for php and php70u, which means that yum install php70u will result in the mod_php package being installed, similar to previous IUS packages.

webserver config files

In Fedora, both httpd and nginx now use a filesystem subpackage to create their respective /etc directories and add a user ("apache" and "nginx" respectively). That change has propagated to nginx in EPEL, but not to httpd in RHEL. Additionally, the upstream nginx RPM packages do not have the filesystem subpackage. The Fedora php-fpm package requires both httpd-filesystem and nginx-filesystem, in order to have a directory to place a default webserver config. Additionally, Fedora php-fpm runs as the apache user (added by httpd-filesystem) with a unix socket, and sets up an access control list to allow both the apache and nginx user access.

For IUS, we don't have the luxury of httpd-filesystem, and we also know that many RHEL6 users choose the upstream nginx repo over EPEL due to the newer version (so no nginx-filesystem either). In the php56u-fpm IUS package, we decided to use a dedicated "php-fpm" user (instead of the "apache" user) and default to using a TCP port, not a unix socket (to avoid needing the "apache" and "nginx" users present for the unix socket access control list). We want to start including fpm config files for httpd and nginx, so we are trying a new idea. The initial packages for php70u include two new subpackages that do not have equivalents in Fedora.

• php70u-fpm-nginx
  • contains /etc/nginx/default.d/php.conf and /etc/nginx/conf.d/php-fpm.conf
  • requires php70u-fpm and nginx
• php70u-fpm-httpd
  • contains /etc/httpd/conf.d/php-fpm.conf
  • requires php70u-fpm and httpd >= 2.4

If a user installs one of these packages, they get a working php-fpm setup with the webserver of their choice with no further steps necessary. Switching from the TCP port to a unix socket would require just a few comment/uncomment steps in the relevant config files. On EL6, php70u-fpm-httpd would resolve the httpd >= 2.4 dependency to our httpd24u package.

hugepages issue on EL6

Problems have been reported with php-fpm on EL6. We considered patching it ourselves, but it sounds like the fix is planned for 7.0.1, so we will probably just wait for that version to be released before we put packages into the stable repos.

httpd module configuration file

@remicollet suggested that we install the httpd module config file as 15-php.conf instead of 10-php.conf. This change would only affect EL7, where the module configs have their own directory. The purpose would be to possibly allow greater compatibility with Software Collection packages, if a user wanted to use both. Additionally, he suggested adding a conditional to ensure that mod_php5 isn't loaded before trying to load mod_php7, to prevent segfaults.

We are not opposed to cooperating with other repositories where it makes sense. However, we are curious, is anyone actually using IUS PHP and (RH)SCL PHP together on the same system? And even if they are, should they? The modules can't be loaded at the same time, so we would just be enabling the packages to be installed at the same time.

Summary

Sorry for the wall of text. Here is a short recap of the feedback we are looking for.

1. Should we move the Apache HTTP Server module for PHP into a subpackage called mod_php70u (or something similar)?
2. Should we use php70u-fpm-nginx and php70u-fpm-httpd subpackages to ship the respective webserver configs for fpm?
3. Is the hugepage issues worth delaying our packages until 7.0.1 is released?
4. Is install compatibility with (RH)SCL worth considering?

[MikeParkin]

We're a design/development agency that use PHP for ecommerce websites. We've automated our infrastructure provisioning with tools like Ansible. We love/use IUS because it allows us to mix solid CentOS with up to date packages for things we need. Thought worth mentioning that, so that my feedback is in context (We might not be the target audience for your feedback).

1. Makes no difference to us, we install once and can easily change/add packages. It's not hard to search for your package (I can never remember the names anyway).
2. Sounds like a nice addition, why not.
3. No. There will always be bugs. Users can upgrade. Centos7 seems unaffected. PHP7 is bleeding edge, people will test before pushing to production (or expect issues).
4. If co-operating does not cause issues then why not. We're not using (RH)SCL but if there is no adverse affects to doing so, I don't see a problem.

[ficus]

Agree with what MikeParkin said in response to the summary questions.

I think that RFC is a really good idea and will prevent confusion as more people start to use httpd24. I recently tried to install php55u package a couple times while intending to use mpm-event before I realized my error.

[jeffsheltren]

1. Doesn't really matter to me. I think the rename is useful, but so is being consistent with standards in Fedora/RHEL. If you were to rename it, I'd prefer something with a php70u prefix, like php70u-mod_php.
2. Sounds good.
3. No, but 7.0.1 is now released anyway.
4. I'm not mixing IUS/SCL anywhere, but it'd be nice to leave this option open.

Thanks for your work on these packages!

[carlwgeorge]

Thanks everyone for the feedback so far.

@MikeParkin Our users (you and your team) are definitely the target audience in our call for feedback.

@ficus Yup, we regularly help users who are confused by the existing naming. It just happened again today in IRC.

@jeffsheltren I agree, being consistent with the rest of the Red Hat ecosystem is certainly important. We try to deviate from the Fedora spec file as little as possible, but still makes changes when it makes sense to do so. We have some general guidelines for this process.

• Stay consistent with Fedora
• Make maintaining the packages easier
• Make using the packages easier

Sometimes these goals align, but sometimes they conflict, and we have to make a judgement call. For example, a php70u-fpm-nginx package will be inconsistent with Fedora, but has a negligible maintenance cost and should make things easier for our users. I would suggest that same setup for Fedora, but they have chosen a different path and it would likely be too difficult to change direction now. With the case of the mod_php naming, I felt that change made sense for Fedora as well, so I sent the feedback upstream. It's all a balancing act in our quest to make the best RPMs possible and contribute to the overall Red Hat ecosystem.

On the idea of consistency with the Red Hat ecosystem, I noticed that SCL PHP packages have a virtual provides for httpd24-mod_php. This got me thinking; mod_php isn't a PHP module, it is an Apache HTTP Server module. As such, it is more important to reserve the prefix to indicate the version of httpd the module is built against, not the version of PHP that is being embedded. We don't currently build mod_php for IUS's httpd24u package, but if we did, the name httpd24u-php70u-mod_php is messy; httpd24u-mod_php70u would be more appropriate I think. It still shows up in yum search mod_php output, so at this point I am leaning toward keeping the name mod_php70u.

[slashterix]

php70u-pear updates https://github.com/slashterix/php56u-pear php70u-pecl-imagick updates https://github.com/slashterix/php56u-pecl-imagick usiing the current RC of the pecl package

[slashterix]

Other pecl packages we use and their status:

• gearman - appears to be abandonware now, we'll be switching to a better maintained job queue
• geoip - appears to be replaced by a pure php library https://github.com/maxmind/GeoIP2-php
• memcached - work on the pecl package is continuing, but not released https://github.com/php-memcached-dev/php-memcached/tree/php7
• pthreads - has a stable build, I'll test it soon
• xdebug - has a beta build, I'll test it soon

[Xon]

No issues with the php 7.0.1 packages so far. :+1:

[carlwgeorge]

Unfortunately, the php->mod_php suggestion has been rejected by Fedora. Now we must decide if it is worthwhile to keep this change in IUS (php70u->mod_php70u). Revisiting those guidelines I mentioned earlier...

Stay consistent with Fedora

Renaming php70u to mod_php70u is inconsistent with the Red Hat ecosystem. This is partially mitigated with mod_php70u providing php70u (so yum install php70u will still work).

Make maintaining the packages easier

The changes to the spec file are minimal and have a negligible maintenance cost. The more descriptive package name should help prevent one of the most common support questions we receive.

Make using the packages easier

The more descriptive package name should be less confusing for users.

All things considered, I think it is worth it to keep the mod_php70u subpackage. Anyone else want to weigh in?

[jeffsheltren]

I agree mod_php70u is a "better" name, but being inconsistent with Fedora is going to make things more difficult/confusing for users. That said, if this makes maintenance/support easier for IUS, that may be worth it.

[slashterix]

I also agree that it's a good proposal, but fear the confusion to people if you are inconsistent with RHEL.

Maybe just a page on https://ius.io/ explaining how the naming is different from upstream would be enough as anyone using the repo would have gone there for info on connecting in the first place.

[carlwgeorge]

@slashterix Thanks for checking that pear builds correctly against php70u. I created a new repo for it, but instead of forking from php56u-pear, I forked it from Fedora. I did include your change regarding getting the matching version of install-pear.php. At some point we need to document our process for forking from Fedora (recently we started doing it a new way to preserve the git commit history) so that community members can create packages the same way as the CoreDev team.

[carlwgeorge]

We've decided to stick with the mod_php70u subpackage. While this is inconsistent with Fedora, we feel that the benefits outweigh the drawbacks.

• The changes to the spec file are minimal.
• It can still be installed with yum install php70u because of the virtual provides.
• If there are unforeseen issues in the future, it is easy to revert to the old name.

I think that the potential confusion wouldn't be any worse than the existing confusion. In addition, like @slashterix suggested, we are considering adding dedicated pages on the website to describe things like this. mysqlclient16 is another example of an IUS change that needs better documentation.

Anyways, these packages will move to the stable repos during tonight's automation. Thanks everyone who provided feedback to help make this happen! If anyone is interested in testing php70u-pear please send us feedback on issue #31.

[MikeParkin]

Thanks!