Do not manage mysql.ini when using Ubuntu repo

[tdm4]

When using the Ubuntu PPA repo, the php::extension::config tries to manage mysql.ini even though it does not exist in PHP 7.0 or 7.1. This results in a PHP warning about mysql.so not existing. This diff disables and removes the mysql.ini file if using PHP 7.0 or 7.1.

[jackdpeterson]

As a workaround, one can utilize stages if on a new version of puppet to execute this outside of the scope of the module until this PR gets merged in (bump).

[jackdpeterson]

  before => Stage['main']
}
stage { 'last':
}
Stage['main'] -> Stage['last']```

### PHP Module workarounds ###


class last_stuff () {
  file { '/usr/lib/php/20160303/pdo-mysql.so':
    ensure => 'link',
    target => '/usr/lib/php/20160303/pdo_mysql.so',
    owner  => 'root',
    group  => 'root',
    mode   => '0755'
  }
  exec { 'Remove_php_mysql_ini':
    command => "phpdismod mysql; rm -f /etc/php/${php::globals::php_version}/mods-available/mysql.ini",
    onlyif  => "test -f /etc/php/${php::globals::php_version}/mods-available/mysql.ini",
    path    => '/bin/:/sbin/:/usr/bin/:/usr/sbin/',
  }

  exec { 'Remove_php_pdo_mysql_ini':
    command => "rm -f /etc/php/${php::globals::php_version}/mods-available/pdo_mysql.ini",
    onlyif  => "test -f /etc/php/${php::globals::php_version}/mods-available/pdo_mysql.ini",
    path    => '/bin/:/sbin/:/usr/bin/:/usr/sbin/',
  }
}

class { 'last_stuff':
  stage => last
}



### End of PHP Module Workarounds ###

is what that potential workaround looks like

[BenConstable]

Another temporary workaround, which may be a bit simpler, is to override the extension ini setting when defining the MySQL extension dependency. For example:

class { '::php':
  extensions => {
    mysql => {
      settings => {
        extension => undef,
      },
    },
  },
}

Using this method, the mysql.ini file will still be created (which isn't perfect), but the extension=mysql.so entry will be removed.

[Yggdrasil]

@BenConstable That was a clever idea, but in my case it simply puts extenstion=undef in the mysql.ini file, which of course leads to the error:
Unable to load dynamic library '/usr/lib/php/20160303/undef'

To be fair I set the config via Hiera, so perhaps that makes a difference in my case. It appears Hiera treats the undef as a string.

php::extensions:
  mysql: { 'settings': { 'extension': undef } }

Any idea how to apply this workaround correctly via Hiera?

[Yggdrasil]

@BenConstable I managed to answer my own question. The correct setting in Hiera is:

php::extensions:
  mysql: { 'settings': { 'extension': } }

This indeed causes the mysql.ini file to be empty and prevents the warning. Thanks again for this relatively clean workaround.

[jonhattan]

In yaml you can use null to mean undef

[bastelfreak]

@tdm4 thanks for this PR. Are you able to rebase? I also added a few inline comments.

[bastelfreak]

please use the new $facts hash instead of topscope facts

[bastelfreak]

I really don't think that an exec() doing rm is the correct approach here. A file resource with ensure => absent is probably the way to go.

[bastelfreak]

Thanks for opening this issue. It hasn't seen activity in a while, so I'm going to close the issue. This doesn't mean that we don't think this issue is valid, we're just trying to assess what issues are still relevant. If you still need this(even if you're not willing to work on it yourself) please feel free to reopen it. Again thanks for opening the issue, users who report bugs and ask for features are some of the most important players in the open source community. Feel free to hop by #voxpupuli on irc.freenode.net if you'd like to chat with us about any of this.

[jonhattan]

@bastelfreak Only project managers can reopen PRs/issues.

This PR is still relevant.

[bastelfreak]

@jonhattan are you interested in rebasing this and adressing the inline comments I made in the last review?