puppetlabs-apache
puppetlabs-apache copied to clipboard
PHP module not working on Ubuntu 22.04 / Jammy
Describe the Bug
The module tries to install libapache2-mod-php7.2
which is not available on Ubuntu 22.04 / Jammy.
Expected Behavior
Use libapache2-mod-php8.1
instead.
Steps to Reproduce
Steps to reproduce the behavior:
- Code example:
class { 'apache':
mpm_module => 'prefork',
}
class { 'apache::mod::php': }
- Results:
Error: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install libapache2-mod-php7.2' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package libapache2-mod-php7.2
E: Couldn't find any package by glob 'libapache2-mod-php7.2'
E: Couldn't find any package by regex 'libapache2-mod-php7.2'
Error: /Stage[main]/Apache::Mod::Php/Apache::Mod[php7.2]/Package[libapache2-mod-php7.2]/ensure: change from 'purged' to 'present' failed: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install libapache2-mod-php7.2' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
E: Unable to locate package libapache2-mod-php7.2
E: Couldn't find any package by glob 'libapache2-mod-php7.2'
E: Couldn't find any package by regex 'libapache2-mod-php7.2'
Notice: /Stage[main]/Apache/File[/etc/apache2/conf.d]: Dependency Package[libapache2-mod-php7.2] has failures: true
Environment
- Module version: 7.0.0
- Puppet version 6.27.1
- Platform: Ubuntu 22.04
Additional Context
The proper package for Ubuntu 22.04 should be libapache2-mod-php8.1
Workaround:
class { 'apache':
mpm_module => 'prefork',
}
class { 'apache::mod::php':
php_version => '8.1',
path => '/usr/lib/apache2/modules/libphp8.1.so',
}
Can you come up with a patch? It should be here: https://github.com/puppetlabs/puppetlabs-apache/blob/3839c93572110e9a6ed61edf0fdc4a32e0770137/manifests/params.pp#L365-L370
Right now there isn't proper CI support for Ubuntu 22.04 so we can't claim full support but having that part in the code already helps.
You can also have a further look and see about the mod packages. They're probably closer to Debian 11.
@ekohl Indeed the package name seems to be easily fixable by adding this line in the params.pp
file:
'22.04' => '8.1', # Ubuntu Jellyfish
However there are still problems with paths to libphp.so
when it should be libphp8.1.so
. This behavior is related to these lines:
https://github.com/puppetlabs/puppetlabs-apache/blob/1d436fddff7fb27969f5df627d17d98a7a5e4ba6/manifests/mod/php.pp#L41-L45
https://github.com/puppetlabs/puppetlabs-apache/blob/1d436fddff7fb27969f5df627d17d98a7a5e4ba6/manifests/mod/php.pp#L92-L95
These condition where probably added for compatibility with PHP 8 in another Linux distribution (I suspect CentOS). I'm trying to figure out how to properly fix this without breaking things.
These conditions over the PHP major version were added in Pull Request #2121.
According to this comment in #2119:
PHP8 dropped the conventions of including the major versions in apache modules. This fix makes it so that moving forward the module will no longer add the major in the relevant places.
Which is untrue for Debian (Sid) and Ubuntu (Jammy). The Pull Request was probably intended to add support for PHP 8.x, but I can't figure out for what Linux distribution.
Related, there's #2261 which may have the same cause.
Related, there's #2261 which may have the same cause.
I think the Red Hat family has dropped support for PHP modules since RHEL/CentOS 8.x so I'm not sure this is related
I think the Red Hat family has dropped support for PHP modules since RHEL/CentOS 8.x so I'm not sure this is related
It looks like you're right for at least CentOS Stream 9 (there you must use php-fpm), but in 8.x there's still mod_php inside modules.
I did some tests with on several Linux distributions.
I used the following code:
class { 'apache':
mpm_module => 'prefork',
}
class { 'apache::mod::php': }
I also changed the params.pp
:
$php_version = $facts['os']['release']['major'] ? {
'9' => '7.0', # Debian Stretch
'10' => '7.3', # Debian Buster
'20.04' => '7.4', # Ubuntu Foccal Fossal
'22.04' => '8.1', # Jammy Jellyfish <-- I added this line
default => '7.2', # Ubuntu Bionic, Cosmic and Disco
}
Results:
- Ubuntu 20.04: Works, PHP 7.4 as Apache module.
- Ubuntu 22.04: Does not work
- CentOS Stream 8: Works, PHP 7.2 FPM
- Rocky Linux 9: Does not work
- Debian 11: Works, PHP 7.4 as Apache module
- openSuse Leap 15.4 (because SLES 15 is not free): Does not work
So far I don't see any setup where PHP 8.x could work.
Following my previous message, I changed the mod/php.pp
file.
L41-L45:
if (versioncmp($php_version, '8') < 0) {
$mod = "php${php_version}"
} else {
# $mod = 'php'
$mod = "php${php_version}"
}
L92-95:
$_lib = $_php_major ? {
# '8' => "${libphp_prefix}.so",
'8' => "${libphp_prefix}${php_version}.so",
default => "${libphp_prefix}${php_version}.so",
}
Results:
- Ubuntu 20.04: Works
- Ubuntu 22.04: Works
- CentOS Stream 8: Works
- Rocky Linux 9: Does not work
- Debian 11: Works
- openSuse Leap 15.4: Does not work
Unless there's something that I didn't see, I still don't understand in which Linux distribution or what setup these conditions with the PHP version are used.
I can make a fix and a Pull Request but I'm still trying to figure out if this will induce a breaking change...
On CentOS Stream 8 you can try (on a fresh system) dnf module enable php:8.0
to get PHP 8. If you already have a module enabled, dnf module reset php && dnf module switch-to php:8.0
.
On CentOS Stream 8 you can try (on a fresh system)
dnf module enable php:8.0
to get PHP 8. If you already have a module enabled,dnf module reset php && dnf module switch-to php:8.0
.
Thanks !
I enabled the php:8.0
module on my CentOS 8 test server, then I used the following Puppet code:
class { 'apache':
mpm_module => 'prefork',
}
class { 'apache::mod::php':
php_version => '8.0',
}
I managed to make PHP 8 work, and the module name is libphp.so
.
Here are my thoughts right now:
- Debian & Ubuntu still use
libphp8.1.so
- CentOS 8 use
libphp.so
(for PHP 8.x) - opensuse support is broken anyway
I'll see if I can make a Pull Request.