puppet-php icon indicating copy to clipboard operation
puppet-php copied to clipboard

Installs wrong version on CentOS 7

Open anlutro opened this issue 7 years ago • 11 comments

On CentOS 7.4, I tell the module to install PHP 7.0 or 7.1:

class { 'php::globals':
  php_version => '7.0',
} ->
class { 'php':
  manage_repos => true,
}

However, PHP 5.6 gets installed.

[vagrant@default ~]$ php --version
PHP 5.6.30 (cli) (built: Jan 19 2017 07:57:06)

I think this is because the remo repo is hardcoded here and never gets overridden: https://github.com/voxpupuli/puppet-php/blob/f8a7d158a20ba9904813292be3dbfc925046951f/manifests/repo/redhat.pp#L10

Puppet version: 4.10.1 Module version: 4.0.0

anlutro avatar May 23 '17 08:05 anlutro

Exactly same problem

cvharris avatar May 24 '17 20:05 cvharris

Same issue here

ktreese avatar May 24 '17 20:05 ktreese

Hi, don't use the 4.0.0 version, try the master branch, it is fixed there

arudat avatar Jun 02 '17 08:06 arudat

Are you sure about this? I am still getting php 5.6

maxmoeschinger avatar Jun 04 '17 18:06 maxmoeschinger

I haven't tried it, but maybe you can override defaults as a workaround?

class { '::php::repo::redhat':
  yum_repo => 'remi_php71',
} ->
class { '::php::globals':
  php_version => '7.1',
} ->
class { '::php':
  manage_repos => true,
}

It would be nice for it to work just by setting the php_version though.

EDIT: I just tested the above with puppet-in-docker and it seems to work.

brunoyb avatar Jun 09 '17 01:06 brunoyb

Yes it works if I overwrite the default for RedHat. But when you specify version 7, it should be installed and if not possible, the build should fail.

maxmoeschinger avatar Jun 09 '17 06:06 maxmoeschinger

So I'm not finding that manually specifying the yum_repo parameter helps at all, with 5.0.0.

philomory avatar Nov 21 '17 03:11 philomory

This has been broke for some months already. I am on master, and it still a problem. My workaround is to use a fixed fork of the repo so far.

luisbrandao avatar Nov 22 '17 19:11 luisbrandao

I have a similar problem, but with a twist. We need to install 'Official' packages on our CentOS farm, thus our go-to is the official software collection repos. This can install php 7.0, but the package name is rh-php70.

I see the manifest dynamically create a $package_prefix for the package in question, but sanity check earlier states is has to be an integer:

From globals: Optional[Pattern[/^[57].[0-9]/]] $php_version = undef,

$globals_php_version = pick($php_version, $default_php_version)

Due to us running CenetOS, it becomes: $package_prefix = "php${globals_php_version}-"

Could also be an option to be able to specify a custom package_prefix in order to use official SCLo repos?

Wernervdmerwe avatar Apr 23 '18 04:04 Wernervdmerwe

Hey. Could one of you provide a patch for this?

bastelfreak avatar Nov 02 '18 13:11 bastelfreak

its odd that this issue was from 2018, but im still having to use the prefix (Centos7), will that remain? Also, this is not landing in the correct path, e.g. php instead its staying php73 even if no other php on the system, for e.g. Where as if i installed the repo default of 5.6, it ends up correctly accessible as php. Its obvious its just following the binary name, however cant there be some logic in there that symlinks it automatically? Maybe by specifying the install path/name, or something?

  1. why cant / how can I specify the version in the global without specifying the prefix if i want to use a default repo (remi)?
  2. More importantly, what can i do to easily add the symlink, from within the php class itself? for now im using
    file { '/bin/php':
      ensure => 'link',
      target => '/bin/php73',
    }