Coder Social home page Coder Social logo

puppet-galera's Introduction

puppet-galera

Build Status Puppet Forge Puppet Forge - downloads

NOTE: The "main" branch on GitHub contains the development version, which may break anything at any time. Consider using one of the official releases instead.

Table of Contents

  1. Overview
  2. Requirements
  3. Usage
  4. OS and Cluster Compatibility
  5. Reference
  6. Limitations
  7. Development

Overview

This module will massage puppetlabs-mysql into creating a Galera cluster on MySQL, MariaDB or XtraDB. It also supports setting up an Arbitrator node.

It will try to recover from failures by bootstrapping on a node designated as the master if no other nodes appear to be running mysql, but if the cluster goes down and the master is permanently taken out, another node will need to be specified as the 'master' that can bootstrap the cluster.

Requirements

  • Puppet 7 or higher
  • puppetlabs/mysql
  • A supported version of Codership Galera (MySQL), MariaDB or Percona XtraDB Cluster
  • nmap is required for the cluster bootstrap functionality
  • puppetlabs/xinetd if galera::status_type is set to xinetd (default for FreeBSD)
  • puppet/systemd if galera::status_type is set to systemd (default for newer Linux distributions)
  • puppetlabs/firewall unless galera::configure_firewall is disabled

Usage

Basic usage

Basic usage requires only the FQDN of the master node, a list of IP addresses of other nodes and two passwords:

class { 'galera':
  # Galera vendor and version
  vendor_type    => 'codership',
  vendor_version => '8.0',
  # Galera cluster config
  cluster_name    => 'mycluster',
  galera_servers  => ['10.0.99.101', '10.0.99.102', '10.0.99.103'],
  galera_master   => 'node1.example.com',
  root_password   => 'pa$$w0rd',
  status_password => 'pa$$w0rd',
}

On Debian/Ubuntu systems the user debian-sys-maint@localhost is required for updates and will be created automatically, but you should set a proper password when using these platforms:

class { 'galera':
  deb_sysmaint_password => 'secretpassword',
  ...

WSREP provider options

Note that the module will automatically add the required Galera/WSREP provider options to the server configuration. Currently the following parameters are automatically added: wsrep_cluster_address, wsrep_cluster_name, wsrep_node_address, wsrep_node_incoming_address, wsrep_on, wsrep_provider, wsrep_slave_threads, wsrep_sst_method, wsrep_sst_auth, wsrep_sst_receive_address.

Some of these values are used directly from their respective class parameter. For example, to change the SST method:

class { 'galera':
  wsrep_sst_method => 'xtrabackup',
  ...

Other values like wsrep_cluster_address and wsrep_sst_auth are generated from several class parameters. Please have a look at the parameter reference and the module's data directory for further details.

Of course, all Galera/WSREP provider options can be overridden by using the $override_options parameter (see below for an example).

More complex example

Furthermore, a number of simple options are available to customize the cluster configuration according to your needs:

class { 'galera':
  # Galera vendor and version
  vendor_type     => 'codership',
  vendor_version  => '8.0',
  #
  # Galera cluster config
  cluster_name    => 'mycluster',
  galera_servers  => ['10.0.99.101', '10.0.99.102', '10.0.99.103'],
  galera_master   => 'node1.example.com',
  root_password   => 'pa$$w0rd',
  status_password => 'pa$$w0rd',
  #
  # This will be used to populate my.cnf values that
  # control where wsrep binds, advertises, and listens
  local_ip => $facts['networking']['ip'],
  #
  # This will be set when the cluster is bootstrapped
  root_password => 'myrootpassword',
  #
  # Disable this if you don't want firewall rules to be set
  configure_firewall => true,
  #
  # Configure the SST method
  wsrep_sst_method => 'xtrabackup-v2',
  #
  # These options are only used for the firewall -
  # to change the my.cnf settings, use the override options
  # described below
  mysql_port => 3306,
  wsrep_state_transfer_port => 4444,
  wsrep_inc_state_transfer_port => 4568,
  #
  # This is used for the firewall + for status checks
  # when deciding whether to bootstrap
  wsrep_group_comm_port => 4567,
}

A catch-all parameter $override_options can be used to populate my.cnf and overwrite default values in the same way as the puppetlabs-mysql module:

class { 'galera':
  override_options => {
    'mysqld' => {
      'bind_address' => '0.0.0.0',
    }
  }
  ...
}

Configuring an Arbitrator

Configuring an Arbitrator service is straight-forward:

class { 'galera':
  arbitrator      => true,
  cluster_name    => 'mycluster',
  galera_servers  => ['10.0.99.101', '10.0.99.102', '10.0.99.103'],
  ...
}

You may even use the same parameters that you would normally use for database nodes, when $arbitrator is set to true they will be ignored. This makes it easy to share the same parameters across all cluster nodes, no matter if they are real database nodes or just an arbitrator service.

Custom repository configuration

This module automatically determines which APT/YUM repositories need to be configured. This depends on your choices for $vendor_type, $vendor_version and $wsrep_sst_method. Each of these choices may enable additional repositories.

For example, if setting $vendor_type=codership and $wsrep_sst_method=xtrabackup, the module will enable the Codership repository to install the Galera server and the Percona repository to install the XtraBackup tool. This works because every vendor/version and SST method may specify the internal $want_repos parameter, which is essentially a list of repositories.

Disable repo management if you are managing your own repos and mirrors:

class { 'galera':
  configure_repo => false,
  ...
}

Or if you just want to switch to using a local mirror, simply change the repo URL for the chosen $vendor_type. For Codership you would add something like this to Hiera:

# RHEL-based systems
galera::repo::codership::yum:
  baseurl: "http://repo.example.com/RPMS/<%= $vendor_version_real %>/%{facts.os.release.major}/%{facts.os.architecture}/"
  ...
# Debian-based systems
galera::repo::codership::apt:
  location: "http://repo.example.com/apt/<%= $vendor_version_real %>/%{facts.os.distro.codename}/"
  ...

FreeBSD support

This module (and all its dependencies) provide support for the FreeBSD operating system. However, from all vendors MariaDB seems to provide the best support for Galera clusters on FreeBSD. The following configuration is known to work:

class { 'galera':
  configure_firewall => false,
  configure_repo     => false,
  galera_servers     => ['10.0.99.101', '10.0.99.102'],
  galera_master      => 'node1.example.com',
  root_password      => 'pa$$w0rd',
  status_password    => 'pa$$w0rd',
  vendor_type        => 'mariadb',
  vendor_version     => '10.11',
}

EPP supported for many options

This module supports inline EPP for many of its options and parameters. This way class parameters and internal variables can be used when specifying options. Currently this is enabled for $override_options, $wsrep_sst_auth and all repository options.

# server/wsrep options
galera::override_options:
  mysqld:
    wsrep_sst_method: "<%= $wsrep_sst_method %>"
    wsrep_provider: "<%= $params['libgalera_location'] %>"

galera::wsrep_sst_auth: "root:<%= $root_password %>"
# repo configuration
galera::repo::codership::yum:
  baseurl: "http://releases.galeracluster.com/mysql-wsrep-<%= $vendor_version_real %>/%{os_name_lc}/%{os.release.major}/%{os.architecture}/"
  ...

OS and Cluster Compatibility

Note that not all versions of Percona XtraDB, Codership Galera and MariaDB are supported on all operating systems. Please consult the official documentation to find out if your operating system is supported.

Below you will find an incomplete and possibly outdated list of known (in)compatiblities. Take it with a grain of salt.

RedHat Debian Ubuntu FreeBSD
Percona XtraDB Cluster 8 / 9 11 / 12 22.04 / 24.04 14.x
8.0 ✔️ / ✔️ ✔️ / ✔️ ✔️ /
Codership Galera (MySQL)
8.0 / 8.4 ✔️ ✔️ / ✔️ ✔️ ✔️ ✔️ / ✔️ ✔️ ✔️ ✔️ / ✔️ ✔️ ❌ ❌
MariaDB Galera Cluster
10.11 / 11.4 ❌ ❌ / ✔️ ✔️ ❌ ❌ / ✔️ ✔️ ❌ ❌ / ✔️ ✔️ ✔️ ✔️

The table only includes the two most recent (LTS) versions. Older and possibly outdated releases are not listed, although they may still be supported by their vendors.

Reference

Classes and parameters are documented in REFERENCE.md.

Limitations

This module was created to work in tandem with the puppetlabs-mysql module, rather than replacing it. As the stages in the mysql module are quite strictly laid out in the mysql::server class, this module places its own resources in the gaps between them.

Of note is an exec that will start the mysql service with parameters which will bootstrap/start a new cluster, but only if it cannot open the comms port to any other node in the provided list. This is verified with a simple nmap command and should not be considered terribly reliable.

Furthermore the bootstrap functionality may be considered harmful for existing clusters. For extra safety, the bootstrap command may be set to something like /bin/false (see GH-116 for more information).

It should also be noted that it is not possible to unset default configuration variables (see GH-174). This is true for this modules' own variables, but also for pre-defined variables that are set by the puppetlabs/mysql module.

Development

Contributing

Please use the GitHub issues functionality to report any bugs or requests for new features. Feel free to fork and submit pull requests for potential contributions.

All contributions must pass all existing tests, new features should provide additional unit/acceptance tests.

puppet-galera's People

Contributors

aderumier avatar alexjfisher avatar altima avatar arnoudj avatar claytono avatar clicktrend avatar cvieri avatar davideagle avatar earthgecko avatar efoft avatar fraenki avatar gregoryo2014 avatar guimaluf avatar jgrassler avatar kemra102 avatar kotty666 avatar lightning- avatar matthewfischer avatar michaeltchapman avatar oranenj avatar reamer avatar rickerc avatar roock avatar serverbiz avatar spjmurray avatar svengerlach avatar tbeitter avatar twizzydizzy avatar vbartoni avatar wolfaba avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

puppet-galera's Issues

dependency cycle

Hi,
I try to install the mysql +galera with puppet with

192.168.207.138 db1.test
 192.168.207.139 db2.test
 192.168.207.140 db3.test

a)  in the /etc/puppetlabs/code/environments/production/modules  , I use the git clone https://your.git  galera  to create the module
b)  puppet module list can show the entry of  "michaeltchapman-galera (v0.5.0)",  and actually, there is a warning for the 'puppetlabs-mysql(v3.6.2)' since  your requirement are >3.8.0, 

c)  I change the site.pp  with 

node default {
class { 'galera':
galera_servers => ['192.168.207.139','192.168.207.140'],
galera_master => 'db1.test',
vendor_type => 'mariadb',
status_password => 'mariadb',
}
}

d) and I issue the command ' puppet agent --test' on db1.test, but it failed with

(File[mysql-config-file] => Class[Mysql::Server::Config] => Package[rsync] => Class[Mysql::Server::Install] => Package[mysql-server] => Class[Mysql::Server::Install] => Class[Mysql::Server::Config] => File[mysql-config-file])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz

MySQL not starting on master node when using Ubuntu.

On the master node, mysql is initially started with:

service mysql start --wsrep_cluster_address=gcomm://

Unfortunately the init script on Debian/Ubuntu does not allow extra parameters to be passed to it, so it will fail to start MySQL. Have to start it by hand now, to get the rest of the cluster running.

Wrong bootstrap command for Debian Stretch

Hi,

At the end of init.pp, the bootstrap_galera_cluster initialize the cluster with the command defined in params.pp. The issue is, under Debian Stretch, we get:

$bootstrap_command = 'service mysql start --wsrep_cluster_address=gcomm://'

when really, it should be:

$bootstrap_command = '/usr/bin/galera_new_cluster'

After fixing params.pp, it worked for me with the default mariadb-server and galera-3 packages. FYI, here's the way I called the galera class:

class { 'galera':
galera_servers => $all_masters_ip,
galera_master => $first_master,
mysql_package_name => 'mariadb-server',
vendor_type => 'mariadb',
root_password => 'myPaSs',
status_password => 'myPaSs2',
configure_repo => false,
configure_firewall => false,
galera_package_name => 'galera-3',
}

which worked if fixing $bootstrap_command, but didn't by default.

Package conflicts with vendor type Percona

OS: CentOS 7.7.1908
Puppet version: 5.5.10
Puppet-galera version: 1.0.6

init.pp

class { 'galera':
  galera_servers     => ['xxx.xxx.xxx.xxx','xxx.xxx.xxx.xxx', 'xxx.xxx.xxx.xxx'],
  galera_master      => 'pxc1.test.domain',
  root_password      => 'passw0rd',
  status_password    => 'passw0rd',
  configure_firewall => false,
  vendor_type        => 'percona',
}

puppet agent output:

Info: Applying configuration version '1574841653'
Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install Percona-XtraDB-Cluster-server-57' returned 1: Transaction check error:
  file /usr/lib64/galera3/libgalera_smm.so from install of Percona-XtraDB-Cluster-server-57-5.7.27-31.39.1.el7.x86_64 conflicts with file from package Percona-XtraDB-Cluster-galera-3-3.36-1.el7.x86_64

Error Summary
-------------
Error: /Stage[main]/Mysql::Server::Install/Package[mysql-server]/ensure: change from 'purged' to 'present' failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install Percona-XtraDB-Cluster-server-57' returned 1: Transaction check error:
  file /usr/lib64/galera3/libgalera_smm.so from install of Percona-XtraDB-Cluster-server-57-5.7.27-31.39.1.el7.x86_64 conflicts with file from package Percona-XtraDB-Cluster-galera-3-3.36-1.el7.x86_64

Error Summary
-------------
Notice: /Stage[main]/Galera/File[/var/run/mysqld]: Dependency Package[mysql-server] has failures: true
Warning: /Stage[main]/Galera/File[/var/run/mysqld]: Skipping because of failed dependencies
Warning: /Stage[main]/Mysql::Server::Installdb/File[/var/log/mariadb/mariadb.log]: Skipping because of failed dependencies
Warning: /Stage[main]/Galera::Status/Xinetd::Service[mysqlchk]/File[/etc/xinetd.d/mysqlchk]: Skipping because of failed dependencies
Warning: /Stage[main]/Xinetd/Service[xinetd]: Skipping because of failed dependencies
Notice: /Stage[main]/Galera/Exec[bootstrap_galera_cluster]: Dependency Mysql_datadir[/var/lib/mysql] has failures: true
Warning: /Stage[main]/Galera/Exec[bootstrap_galera_cluster]: Skipping because of failed dependencies
Warning: /Stage[main]/Mysql::Server::Service/Service[mysqld]: Skipping because of failed dependencies
Warning: /Stage[main]/Galera/Exec[create /root/.my.cnf]: Skipping because of failed dependencies
Warning: /Stage[main]/Mysql::Server::Service/Exec[wait_for_mysql_socket_to_open]: Skipping because of failed dependencies
Warning: /Stage[main]/Mysql::Server::Root_password/Exec[remove install pass]: Skipping because of failed dependencies
Notice: /Stage[main]/Mysql::Server::Root_password/File[/root/.my.cnf]: Dependency Mysql_user[root@localhost] has failures: true
Warning: /Stage[main]/Mysql::Server::Root_password/File[/root/.my.cnf]: Skipping because of failed dependencies
Notice: /Stage[main]/Galera::Validate/Exec[validate_connection]: Dependency Mysql_user[clustercheck@%] has failures: true
Notice: /Stage[main]/Galera::Validate/Exec[validate_connection]: Dependency Mysql_grant[clustercheck@%/*.*] has failures: true
Notice: /Stage[main]/Galera::Validate/Exec[validate_connection]: Dependency Mysql_user[clustercheck@localhost] has failures: true
Notice: /Stage[main]/Galera::Validate/Exec[validate_connection]: Dependency Mysql_grant[clustercheck@localhost/*.*] has failures: true
Warning: /Stage[main]/Galera::Validate/Exec[validate_connection]: Skipping because of failed dependencies
Warning: /Stage[main]/Mysql::Server/Anchor[mysql::server::end]: Skipping because of failed dependencies
Error: Could not find a suitable provider for mysql_datadir
Error: Could not find a suitable provider for mysql_user
Error: Could not find a suitable provider for mysql_grant
Notice: Applied catalog in 5.98 seconds

Unknown function 'mysql_password'

I see on the status manifest on every line that has mysql_password() that it's an unknown function:

Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Unknown function: 'mysql_password'. (file: /etc/puppetlabs/code/environments/production/modules/galera/manifests/status.pp, line: 42, column: 24)

This also on line 27.

This on CentOS btw.

Bootstrap dependency

Hello,

I've got a problem with bootstraping the cluster.
The dependency on Class['mysql::server::installdb'] is not found.
Where should it be declared?

And secondly, on Debian jessie the bootstrap command
service mysql start --wsrep_cluster_address=gcomm://
doesn't work
I have to use
/etc/init.d/mysql start --wsrep_cluster_address=gcomm://
It could be helpful to set this command within the parameters

Thanks

wsrep_sst_method xtrabackup-v2 needed for percona 5.6

We have a cluster that is set up using an earlier version of this module. When upgrading to 1.0.3 we noticed that xtrabackup-v2 was no longer an allowed value for the wsrep_sst_method parameter.

I believe the change makes sense when running percona 5.7, but using just xtrabackup in 5.6 it breaks our state transfers.

Could xtrabackup-v2 still be allowed when using vendor_version: 5.6?

xinetd /etc/services CentOS

Can you change the status.pp file so that augeas checks for tcp and the port as on CenOS 6 there already exists both a TCP and UDP service and therefore adds nothing.
The following works for me, but I haven't checked to see what happens if there is TCP only, UDP only or no service on port 9200.

augeas { 'mysqlchk':
context => '/files/etc/services',
changes => [
"set /files/etc/services/service-name[port='9200' and protocol='tcp']/port 9200",
"set /files/etc/services/service-name[port='9200' and protocol='tcp'] mysqlchk",
"set /files/etc/services/service-name[port='9200' and protocol='tcp']/protocol tcp",
],
}

Parameters are not well documented

Error: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install mariadb-galera-server-5.5' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
Package mariadb-galera-server-5.5 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
mariadb-server-10.0:i386 mariadb-server-10.0

E: Package 'mariadb-galera-server-5.5' has no installation candidate
Error: /Stage[main]/Mysql::Server::Install/Package[mysql-server]/ensure: change from purged to present failed: Execution of '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install mariadb-galera-server-5.5' returned 100: Reading package lists...
Building dependency tree...
Reading state information...
Package mariadb-galera-server-5.5 is not available, but is referred to by another package.
This may mean that the package is missing, has been obsoleted, or
is only available from another source
However the following packages replace it:
mariadb-server-10.0:i386 mariadb-server-10.0

E: Package 'mariadb-galera-server-5.5' has no installation candidate

Dependency cycle with additional_packages, galera_package_name

Using release 0.7.1 of the module and with mysql module version 5.4.0, with these settings in hiera:

galera::galera_package_name: 'galera-3'
galera::mysql_package_name: 'mariadb-server'
galera::vendor_type: 'mariadb'
galera::vendor_version: '10.3'
galera::repo::apt_mariadb_repo_key_server: 'keyserver.ubuntu.com'
galera::repo::apt_mariadb_repo_key: '177F4010FE56CA3336300305F1656F24C74CD1D8'
galera::repo::apt_mariadb_repo_location: "http://mirror.aarnet.edu.au/pub/MariaDB/repo/%{lookup('galera::vendor_version')}/ubuntu"

I get a dependency cycle:

(File[/etc/mysql/conf.d] => Class[Mysql::Server::Config] => Package[rsync] => Class[Mysql::Server::Install] => Package[mysql-server] => Class[Mysql::Server::Install] => Class[Mysql::Server::Config] => File[/etc/mysql/conf.d])

The core of this to me looks like
mysql::server::config => package installs => mysql::server::install
and
mysql::server::install => mysql::server::config

I solved this by changing manifests/init.pp to remove require => Class['mysql::server::config'] from both the additional_packages and galera_package_name package installations.

Does this change make sense as a solution to the problem? I could submit a PR to do so.

Unexpected defaults on CentOS/RHEL 7 for non-MariaDB installations

On CentOS 7 puppetlabs-mysql will default to MariaDB, which results in some MariaDB-specific configurations/paths, even when using Percona XtraDB or Codership Galera Cluster.

This is mostly a cosmetic issue, the MySQL server is still fully functional.

We may overwrite some puppetlabs-mysql parameters to fix this.

should not designate one node as master

Hi Frank.

there is no concept of "master" that can be pre-assigned, and that can always be used to bootstrap the cluster.
There is one node in the cluster which can be considered safe to bootstrap. This node is the last node that was alive in the cluster and it can be determined by grepping as following:

grep safe_to_bootstrap ~mysql/grastate.dat 
safe_to_bootstrap: 0

If it's 1 you can bootstrap from that node.
Of course you can bootstrap for whatever node, but the risk of loosing data is considerably high, depending how long the last node was alive, while the other nodes were down!!

For you reference: Galera Safe To Bootstrap

Hope it helps!

Request - Can you add git tags in the release process

Hi,

We have a little request for the development process of your excellent puppet module we currently using. Can you use the release tags from git when you provide new version in github?

'Cause when we using on our env without this information we get all the modification since our last install and sometime it broke :D like today.

If you use a versioning naming, like in semver.org, we can rely on a precise one and make migration process to a new version with more security.

Thanks a lot for the time provided to the community

`$bind_address` and `$local_ip` class parameters are ignored

I'm guessing this broke from #106, moving from params.pp to Hiera. It looks like this override hash is used directly from the Hiera structure and $bind_address and $local_ip are never merged in to the options hash. the lookup() function will only lookup other values in Hiera, not values passed to the class (which I'm guessing is what happened here).

I believe what needs to be done here is something similar to $_wsrep_cluster_address, and add that to the mysql_deepmerge() before $override_options in init.pp, so that values passed into the class take priority over the defaults (they can actually probably be removed from the defaults hash in the Hiera data at that point, though), but not over anything in the override options hash.

Module is unable to bootstrap a new XtraDB cluster

The module is unable to bootstrap a new cluster if the data directory does not exist:

Notice: /Stage[main]/Galera::Repo/Yumrepo[galera_percona]/ensure: created
Notice: /Stage[main]/Galera::Repo/Yumrepo[galera_epel]/ensure: created
Notice: /Stage[main]/Galera::Repo/Package[Percona-XtraDB-Cluster-shared-compat-57]/ensure: created
Notice: /Stage[main]/Galera/Package[percona-xtrabackup-24]/ensure: created
Notice: /Stage[main]/Mysql::Server::Install/Package[mysql-server]/ensure: created
Notice: /Stage[main]/Mysql::Server::Config/File[mysql-config-file]/ensure: defined content as '{md5}63be06247231f5789304856324bcf3b4'
Notice: /Stage[main]/Mysql::Server::Installdb/Mysql_datadir[/var/lib/mysql]/ensure: created
Notice: /Stage[main]/Galera/Exec[bootstrap_galera_cluster]/returns: executed successfully
Info: /Stage[main]/Galera/Exec[bootstrap_galera_cluster]: Scheduling refresh of Exec[validate_connection]
Error: Systemd start for mysql failed!
Error: /Stage[main]/Mysql::Server::Service/Service[mysqld]/ensure: change from 'stopped' to 'running' failed: Systemd start for mysql failed!
Notice: /Stage[main]/Galera/Exec[create /root/.my.cnf]: Dependency Service[mysqld] has failures: true

In this case, mysql::server::installdb notifies Class['mysql::server::service']... as soon as Exec[bootstrap_galera_cluster] does it's thing, it breaks.

Switch default MySQL version to most recent version

There's no point forcing really old application versions on users that are evaluating this module.
Existing users should specify the required/expected version. Everyone should do this in a production environment.

  • Check available versions for Percona, Codership, MariaDB
  • Update yum/apt repository configurations (if required)
  • Update documentation: demonstrate how to specify a different version/flavour/repo

Cannot install because of dependency issues

When trying to install this module I get the following:

puppet module install fraenki-galera
Notice: Preparing to install into /etc/puppetlabs/code/environments/production/modules ...
Notice: Downloading from https://forgeapi.puppet.com ...
Error: Could not install module 'fraenki-galera' (???)
No version of 'fraenki-galera' can satisfy all dependencies
Use puppet module install --ignore-dependencies to install only this module

Any idea how to fix this ?

Issues with mariadb repo handling

Hi,

  1. MariaDB changed it's apt_key, the one used in galera::repo::mariadb_apt_key is not valid for recent versions of Debian/Ubuntu.

Starting with Debian 9 (Stretch), and Debian Unstable (Sid), and Ubuntu 16.04 LTS (Xenial), the id of our GPG public key is 0xF1656F24C74CD1D8. The full key fingerprint is: 177F 4010 FE56 CA33 3630 0305 F165 6F24 C74C D1D8

(see Installing MariaDB)

  1. The parameter mariadb_apt_location is filled with a hard coded "ubuntu" instead of %{os_name_lc} as it's done with the other *_apt_location params.

mysql::deepmerge dropped in puppetlabs/mysql v8.0.0

With release 8.0.0 of puppetlabs/mysql the function mysql::deepmerge was dropped among others since Puppet 5 (and 6) can do this without Ruby.
puppetlabs/puppetlabs-mysql#1145
https://github.com/puppetlabs/puppetlabs-mysql/blob/master/CHANGELOG.md#800-2019-01-18

So
https://github.com/fraenki/puppet-galera/blob/ca4dacf0d2c917eb80512326202a278f9b88ca4e/manifests/init.pp#L173

should be something like
$options = $_default_options.deep_merge($_wsrep_cluster_address.deep_merge($override_options))

I'm not sure weither the datatype function can merge multiple hashes like the old one, so I cascaded it instead.

AFAIK they are working on a wrapper function to still support calls to mysql::deepmerge. Though this should be changed either way. At the moment this module is incompatible with puppetlabs/mysql 8.0.0

Depdency Cycle in CentOS7

The module seems to get itself into a dependency cycle when run against centos7:

==> control1: Error: Could not apply complete catalog: Found 1 dependency cycle:
==> control1: (Anchor[mysql::server::start] => Class[Mysql::Server::Install] => Package[mysql-server] => Class[Mysql::Server::Install] => File[/var/run/mariadb] => Class[Galera::Repo] => Class[Mysql::Server] => Anchor[mysql::server::start])

I can't get my head around the various anchors in the init script to figure out why this occurs. What's weird is that this doesn't happen when I test against centos6.

Dependency cycle with recent commit

It looks like a recent commit (a9c6bce) has introduced a circular dependency cycle.

Error: Failed to apply catalog: Found 1 dependency cycle:
(File[/etc/mysql/conf.d] => Class[Mysql::Server::Config] => Package[rsync] => Class[Mysql::Server::Install] => Package[mysql-server] => Class[Mysql::Server::Install] => Class[Mysql::Server::Config] => File[/etc/mysql/conf.d])

Dependency on puppetlabs-xinetd

It should be noted that this class is by default dependent on puppetlabs-xinetd. If status and validate are set to true. The README does not reflect this.

Makes it so that the xinetd dependencies does not exist.
status_check => false,
validate_connection => false,

Module cleanup for 1.0

  • Code cleanup (style, deprecations)
  • Restructure documentation
  • Remove abandoned files from repo

Empty Password in debian.cnf

Hi, I am trying to install galera on Ubuntu 14.04:

        class { 'galera':
                status_password                 => 'hs4jk2t',
                galera_servers                  => ['10.0.0.11', '10.0.0.12', '10.0.0.13'],
                galera_master                   => 'controller1.openstacklocal',
                local_ip                        => '10.0.0.11',
                bind_address                    => '10.0.0.11',
                mysql_port                      => '3306',
                wsrep_group_comm_port           => '4567',
                wsrep_state_transfer_port       => '4444',
                wsrep_inc_state_transfer_port   => '4568',
                wsrep_sst_method                => 'rsync',
                root_password                   => 'hs4jk2t',
                override_options                => {}, 
                vendor_type                     => 'mariadb',
                configure_repo                  => true,
                configure_firewall              => false,
                deb_sysmaint_password           => 'abcdefghijkl',
                mysql_restart                   => true,
                package_ensure                  => 'installed',
        }

Applying the manifest, I get an empty password in /etc/mysql/debian.cnf:

ubuntu@controller1:~$ sudo cat /etc/mysql/debian.cnf                                                                
[client]
host     = localhost
user     = debian-sys-maint
password = 
socket   = /var/run/mysqld/mysqld.sock
[mysql_upgrade]
host     = localhost
user     = debian-sys-maint
password = 
socket   = /var/run/mysqld/mysqld.sock
basedir  = /usr
ubuntu@controller1:~$ 

As a result, I keep getting this trying to start the service:

ubuntu@controller1:~$ sudo /etc/init.d/mysql start
 * Starting MariaDB database server mysqld
Nov 15 14:35:18 controller1 mysqld: 151115 14:35:18 [Warning] Access denied for user 'debian-sys-maint'@'localhost' (using password: NO)
Nov 15 14:35:21 controller1 mysqld: 151115 14:35:21 [Warning] Access denied for user 'debian-sys-maint'@'localhost' (using password: NO)
   ...done.
ubuntu@controller1:~$

Any ideas?

Security concern on calling /usr/local/bin/clustercheck

In the way, how /usr/local/bin/clustercheck is called by xinetd, the password of the MySQL user is visible in the command line (via 'ps -ef') during the execution of this script. But passwords should never be visible on the command line.

A better way for my opinion should be to generate a special 'my.somehow.cnf' somewhere in the filesystem, include the MySQL host, user and password as key-value-pairs inside the [client]-division of this file, restrict the access to this file, so that only the clustercheck-user is able to read this file and call mysql in the clustercheck-script with this file as a '--defaults-extra-file' parameter without giving host, user and password separately.

So - I tried upgrading the module to use Percona 5.6...

I changed my code similar to PR 61 ( #61 ) and all seems well.

Until it tries as a part of galera::init to run exec { "create ${::root_home}/.my.cnf" from what I can tell - which then calls mysql::root_password and its "remove install pass" resource. Later in mysql::server::root_password, it then tries to set the root password (as I've passed in my manifest to the galera module) which seems to fail.

Here's the debug output from the puppet run below. The way I fixed it is to do a manual password recovery except adding the --wsrep-new-cluster line (per http://dev.mysql.com/doc/refman/5.6/en/resetting-permissions.html) to the password that I told the galera manifest I wanted to use. Puppet's next run then does all the other DB creation and stuff I told it to and all seems happy. This only breaks on the initial puppet run for a node.

So it seems that the root password is not being set as it would seem to be.

A snippet from my mysql manifest:

class { 'galera':
galera_servers => ['10.0.0.2,10.0.0.3,10.0.0.4'],
galera_master => 'firstnode.example.com',
local_ip => $::ipaddress_eth0,
root_password => 'MyPassword',
configure_repo => false,
configure_firewall => true,
wsrep_sst_method => 'xtrabackup-v2',
validate_connection => false,
status_check => false,
}

First run output:

Debug: Executing: '/usr/bin/dpkg-query -W --showformat '${Status} ${Package} ${Version}\n' percona-xtrabackup'
Debug: Executing: '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install percona-xtrabackup'
Notice: /Stage[main]/Galera/Package[percona-xtrabackup]/ensure: created
Debug: /Package[percona-xtrabackup]: The container Class[Galera] will propagate my refresh event
Debug: Executing: '/usr/bin/dpkg-query -W --showformat '${Status} ${Package} ${Version}\n' percona-xtradb-cluster-galera-3.x'
Debug: Executing: '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install percona-xtradb-cluster-galera-3.x'
Notice: /Stage[main]/Galera/Package[percona-xtradb-cluster-galera-3.x]/ensure: created
Debug: /Package[percona-xtradb-cluster-galera-3.x]: The container Class[Galera] will propagate my refresh event
Debug: Executing: '/usr/bin/apt-get -q -y -o DPkg::Options::=--force-confold install percona-xtradb-cluster-server-5.6'
Notice: /Stage[main]/Mysql::Server::Install/Package[mysql-server]/ensure: created
Info: /Package[mysql-server]: Scheduling refresh of Exec[clean_up_ubuntu]
Debug: /Package[mysql-server]: The container Class[Mysql::Server::Install] will propagate my refresh event
Debug: Class[Mysql::Server::Install]: The container Stage[main] will propagate my refresh event
Debug: Execclean_up_ubuntu: Executing 'service mysql stop'
Debug: Executing: 'service mysql stop'
Notice: /Stage[main]/Galera::Debian/Exec[clean_up_ubuntu]: Triggered 'refresh' from 1 events
Debug: /Stage[main]/Galera::Debian/Exec[clean_up_ubuntu]: The container Class[Galera::Debian] will propagate my refresh event
Notice: /Stage[main]/Mysql::Server::Config/File[mysql-config-file]/ensure: defined content as '{md5}6bd09508c53bb37b90ad3c08f3969a92'
Debug: /Stage[main]/Mysql::Server::Config/File[mysql-config-file]: The container Class[Mysql::Server::Config] will propagate my refresh event
Debug: Class[Mysql::Server::Config]: The container Stage[main] will propagate my refresh event
Debug: Execbootstrap_galera_cluster: Executing check '["/bin/sh", "-c", "nmap -p 4567 10.0.0.1 10.0.0.2 10.0.0.3 | grep -q '4567/tcp open'"]'
Debug: Executing: '/bin/sh -c nmap -p 4567 10.0.0.1 10.0.0.2 10.0.0.3 | grep -q '4567/tcp open''
Debug: Execbootstrap_galera_cluster: Executing '["/bin/sh", "-c", "/etc/init.d/mysql bootstrap-pxc"]'
Debug: Executing: '/bin/sh -c /etc/init.d/mysql bootstrap-pxc'
Notice: /Stage[main]/Galera/Exec[bootstrap_galera_cluster]/returns: executed successfully
Debug: /Stage[main]/Galera/Exec[bootstrap_galera_cluster]: The container Class[Galera] will propagate my refresh event
Notice: /Stage[main]/Mysql::Server::Service/File[/var/log/mysql/error.log]/group: group changed 'adm' to 'mysql'
Debug: /Stage[main]/Mysql::Server::Service/File[/var/log/mysql/error.log]: The container Class[Mysql::Server::Service] will propagate my refresh event
Debug: Servicemysqld: Could not find mysql.conf in /etc/init
Debug: Servicemysqld: Could not find mysql.conf in /etc/init.d
Debug: Servicemysqld: Could not find mysql in /etc/init
Debug: Executing: '/etc/init.d/mysql status'
Debug: Execcreate /root/.my.cnf: Executing check '/usr/bin/mysql --user=root --password=pa$$word -e 'select count(1);''
Debug: Executing: '/usr/bin/mysql --user=root --password=pa$$word -e 'select count(1);''
Debug: /Stage[main]/Galera/Exec[create /root/.my.cnf]/onlyif: Warning: Using a password on the command line interface can be insecure.
Debug: /Stage[main]/Galera/Exec[create /root/.my.cnf]/onlyif: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
Debug: Class[Galera]: The container Stage[main] will propagate my refresh event
Debug: Class[Mysql::Server::Service]: The container Stage[main] will propagate my refresh event
Debug: Execremove install pass: Executing check 'test -f /.mysql_secret'
Debug: Executing: 'test -f /.mysql_secret'
Debug: Prefetching mysql resources for mysql_user
Debug: Executing: '/usr/bin/mysql --defaults-extra-file=/root/.my.cnf -NBe SELECT CONCAT(User, '@',Host) AS User FROM mysql.user'
Debug: Storing state
Debug: Stored state in 0.04 seconds
Error: Failed to apply catalog: Execution of '/usr/bin/mysql --defaults-extra-file=/root/.my.cnf -NBe SELECT CONCAT(User, '@',Host) AS User FROM mysql.user' returned 1: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

Dependency cycle

If I run puppet agent it fails with

Error: Failed to apply catalog: Found 1 dependency cycle:
(Exec[clean_up_ubuntu] => Class[Mysql::Server::Config] => File[/etc/mysql/conf.d] => Class[Mysql::Server::Config] => Class[Mysql::Server::Install] => Package[mysql-server] => Exec[clean_up_ubuntu])
Try the '--graph' option and opening the resulting '.dot' file in OmniGraffle or GraphViz

My configuration is

class { 'galera':
        status_password => $db_cluster['status_password'],
        root_password   => $root_password,
        galera_servers => $db_cluster['nodes'],
        galera_master  => $db_cluster['master'],
        local_ip => $servers[$::fqdn]['ip'],
        vendor_type => 'percona',
        vendor_version => '5.6',
        wsrep_sst_method => 'xtrabackup-v2',
        configure_firewall => false,
        override_options => {
            mysqld => {
                wsrep_cluster_name             => $db_cluster['group_name'],
                wsrep_provider_options         => '"gcache.size=8192M;socket.checksum=1;"',
                skip_name_resolve              => true,
                innodb_flush_method            => 'O_DIRECT',
                innodb_log_files_in_group      => 2,
                innodb_log_file_size           => '64M',
                innodb_flush_log_at_trx_commit => 1,
                innodb_file_per_table          => 1,
                innodb_buffer_pool_size        => '592M',
                tmp_table_size                 => '32M',
                max_heap_table_size            => '32M',
                max_connections                => 500,
                thread_cache_size              => 50,
                open_files_limit               => 65535,
                table_definition_cache         => 4096,
                table_open_cache               => 4096,
                max_allowed_packet             => '16M',
                max_connect_errors             => 1000000,
                key_buffer_size                => '32M',
                log_bin                        => '/var/lib/mysql/mysql-bin',
                expire_logs_days               => 14,
                sync_binlog                    => 1,
                bind_address                   => '0.0.0.0'
            }
        }
    }

I'm using the master branch.

Upgrade to percona cluster 5.6

Are there any plans to upgrade to Percona 5.6? I need FULLTEXT Index for innodb which is available at 5.6!

I forked new branch where I introduced "vendor_type" "percona56" and edited files. I made it only for debian systems. How would you do that? Introducing new parameter like "version" or like I did new "vendor_type"?

GPG issues (at least on CentOS)

I have seen on some other modules that the GPG keys are updates, as I don't see any here and have the following issue on CentOS I would like to ask if we need this as well:

Debug: Executing: '/usr/bin/yum -d 0 -e 0 -y install Percona-XtraDB-Cluster-shared-compat-57'
Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install Percona-XtraDB-Cluster-shared-compat-57' returned 1: warning: /var/cache/yum/x86_64/7/galera_percona/packages/Percona-XtraDB-Cluster-shared-compat-57-5.7.25-31.35.1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 8507efa5: NOKEY
Public key for Percona-XtraDB-Cluster-shared-compat-57-5.7.25-31.35.1.el7.x86_64.rpm is not installed
Importing GPG key 0xCD2EFD2A:
 Userid     : "Percona MySQL Development Team <[email protected]>"
 Fingerprint: 430b df5c 56e7 c94e 848e e60c 1c4c bdcd cd2e fd2a
 From       : http://www.percona.com/downloads/percona-release/RPM-GPG-KEY-percona


Public key for Percona-XtraDB-Cluster-shared-compat-57-5.7.25-31.35.1.el7.x86_64.rpm is not installed


 Failing package is: Percona-XtraDB-Cluster-shared-compat-57-5.7.25-31.35.1.el7.x86_64
 GPG Keys are configured as: http://www.percona.com/downloads/percona-release/RPM-GPG-KEY-percona
Error: /Stage[main]/Galera::Repo/Package[Percona-XtraDB-Cluster-shared-compat-57]/ensure: change from purged to present failed: Execution of '/usr/bin/yum -d 0 -e 0 -y install Percona-XtraDB-Cluster-shared-compat-57' returned 1: warning: /var/cache/yum/x86_64/7/galera_percona/packages/Percona-XtraDB-Cluster-shared-compat-57-5.7.25-31.35.1.el7.x86_64.rpm: Header V4 RSA/SHA256 Signature, key ID 8507efa5: NOKEY
Public key for Percona-XtraDB-Cluster-shared-compat-57-5.7.25-31.35.1.el7.x86_64.rpm is not installed
Importing GPG key 0xCD2EFD2A:
 Userid     : "Percona MySQL Development Team <[email protected]>"
 Fingerprint: 430b df5c 56e7 c94e 848e e60c 1c4c bdcd cd2e fd2a
 From       : http://www.percona.com/downloads/percona-release/RPM-GPG-KEY-percona


Public key for Percona-XtraDB-Cluster-shared-compat-57-5.7.25-31.35.1.el7.x86_64.rpm is not installed


 Failing package is: Percona-XtraDB-Cluster-shared-compat-57-5.7.25-31.35.1.el7.x86_64
 GPG Keys are configured as: http://www.percona.com/downloads/percona-release/RPM-GPG-KEY-percona

Error: Failed to apply catalog: Execution of '/usr/bin/mysql --defaults-extra-file=/root/.my.cnf -NBe SELECT CONCAT(User, '@',Host) AS User FROM mysql.user' returned 1: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

Error: Failed to apply catalog: Execution of '/usr/bin/mysql --defaults-extra-file=/root/.my.cnf -NBe SELECT CONCAT(User, '@',Host) AS User FROM mysql.user' returned 1: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

The error occurs while using the following node definition:

class{'galera':
galera_servers => ['192.168.1.33','192.168.1.34','192.168.1.35','192.168.1.36'],
galera_master => '192.168.1.33',
vendor_type => 'mariadb',

root_password => 'mariadb',

status_password               => 'mariadb',
bind_address                  => $::ipaddress_enp1s0,

}

If i uncomment out the root_password, sections the entire thing fails as well.

Add support for Arbitrator (garbd) nodes

  • Refactor repository management to support multiple repos (also required for #119)
  • Manage garbd package, service and configuration file
  • Add new parameter to enable garbd instead of wsrep
  • Add basic tests for arbitrator feature

Add FreeBSD support

  • Add defaults for package and service name to hiera
  • Evaluate working defaults for bootstrap_command and validate.pp
  • Ensure status.pp is working as expected (hints: clustercheck, xinetd)

Handling of deb_sysmaint_password fails

The variable deb_sysmaint_password in /etc/mysql/debian.cnf is empty as it's scope in the template file seems to be wrong:

password = <%= $deb_sysmaint_password %>

I guess it should be (at least it works):

password = <%= $galera::deb_sysmaint_password %>

The scope handling in manifests/debian.pp is no longer needed afterwards.

Access denied for user 'root,clustercheck'@'localhost' (using password: YES)

Hi,
i get some errors using this class in combination with puppetlabs/mysql
root user get´s created with empty password and does not allow login with pass only with empty pass also error on Clustercheck, /var/log/mariadb folder doesn´t get created

Distributor ID: CentOS
Description: CentOS Linux release 7.7.1908 (Core)
Release: 7.7.1908
Codename: Core
puppet --version 5.5.16
mysql Ver 14.14 Distrib 5.7.27, for Linux (x86_64) using EditLine wrapper
Always done a Clean Setup via Cobbler

my node config:

 class { 'galera':
    galera_servers  => ['xxx.xxx.xxx.xxx', 'xxx.xxx.xxx.xxx', 'xxx.xxx.xxx.xxx'],
    galera_master   => 'poc-db01',
    create_root_user => 'true',
    root_password   => 'pa$$w0rd',
    status_password => 'pa$$w0rd',
    vendor_type     => 'codership',
    local_ip => $facts['networking']['ip'],
    configure_firewall => true,
    mysql_port => 3306,
    wsrep_state_transfer_port => 4444,
    wsrep_inc_state_transfer_port => 4568,
    wsrep_group_comm_port => 4567,
    override_options => {
        'mysqld' => {
            'bind_address' => '0.0.0.0',
        },
    },
}

if vendor_type is "codership" or "mariadb" "/var/log/mariadb" folder ist not created

i added this code to init.pp to prevent puppet run fail

.........

   service_name => $params['mysql_service_name'],
    restart            => $mysql_restart,
  }

 if (($vendor_type == 'codership') or ($vendor_type == 'mariadb')) {
    file { '/var/log/mariadb':
      ensure => 'directory',
      owner  => 'mysql',
      group  => 'mysql',
      require => Class['mysql::server::install'],
      before => Class['mysql::server::installdb'],
   }
  }

 file { $rundir:
    ensure  => directory,
...........
  }

Next Error msg:

Error: Could not prefetch mysql_user provider 'mysql': 
Execution of '/usr/bin/mysql --defaults-extra-file=/root/.my.cnf -NBe SELECT CONCAT(User, '@',Host) AS User FROM mysql.user' returned 1:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)
Error: Failed to apply catalog: Execution of '/usr/bin/mysql --defaults-extra-file=/root/.my.cnf -NBe SELECT CONCAT(User, '@',Host) AS User FROM mysql.user' returned 1:
ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using password: YES)

i can connect to mysql via mysql -uroot -p it requests a pass i just press enter and i'm in.

(root@localhost) [mysql]> select * from user where user='root'\G;
*************************** 1. row ***************************
                  Host: localhost
                  User: root
                plugin: mysql_native_password
........... 
authentication_string:  **<<<< is empty**
      password_expired: N
 password_last_changed: 2019-10-06 19:58:59
     password_lifetime: NULL
        account_locked: N
1 row in set (0.00 sec)

ERROR:
No query specified
(root@localhost) [mysql]>

if i set it manually Password:

(root@localhost) [(none)]>  UPDATE mysql.user SET authentication_string = PASSWORD('pa$$w0rd') WHERE User = 'root' AND Host = 'localhost';
Query OK, 1 row affected, 1 warning (0.01 sec)
Rows matched: 1  Changed: 1  Warnings: 1
(root@localhost) [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.00 sec)
(root@localhost) [(none)]> quit
Bye

it runs till clustercheck and ends with different error, manual login for user "clustercheck" work too

Notice: /Stage[main]/Galera::Validate/Exec[validate_connection]/returns: mysql: [Warning] Using a password on the command line interface can be insecure.
Notice: /Stage[main]/Galera::Validate/Exec[validate_connection]/returns: ERROR 1045 (28000): Access denied for user 'clustercheck'@'localhost' (using password: YES)
Error: /Stage[main]/Galera::Validate/Exec[validate_connection]: Failed to call refresh: 'mysql --host=localhost --user=clustercheck --password=pa$$w0rd -e 'select count(1);'' returned 1 instead of one of [0]
Error: /Stage[main]/Galera::Validate/Exec[validate_connection]: 'mysql --host=localhost --user=clustercheck --password=pa$$w0rd -e 'select count(1);'' returned 1 instead of one of [0]
Notice: /Stage[main]/Mysql::Server/Anchor[mysql::server::end]: Dependency Exec[validate_connection] has failures: true
Warning: /Stage[main]/Mysql::Server/Anchor[mysql::server::end]: Skipping because of failed dependencies
Info: Stage[main]: Unscheduling all events on Stage[main]

Password Hash for "clustercheck" is same as "root":

(root@localhost) [(none)]> select user,host,authentication_string  from mysql.user;
+---------------+-----------+-------------------------------------------+
| user          | host      | authentication_string                     |
+---------------+-----------+-------------------------------------------+
| root          | localhost | *A32931B9B0D4C7CF9173CAA42B07BD2EA453EF94 |
| mysql.session | localhost | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE |
| mysql.sys     | localhost | *THISISNOTAVALIDPASSWORDTHATCANBEUSEDHERE |
| clustercheck  | %         | *A32931B9B0D4C7CF9173CAA42B07BD2EA453EF94 |
| clustercheck  | localhost | *A32931B9B0D4C7CF9173CAA42B07BD2EA453EF94 |
+---------------+-----------+-------------------------------------------+
5 rows in set (0.00 sec)

(root@localhost) [(none)]>

i also debuged down to mysql::server::root_password (root_password.pp),
mysql::Server::create_root_user == true
mysql::server::root_password is set

did i missed some or is this a bug

kind regards

Update OS/module dependencies

  • Use only supported module versions
  • Remove EOL operating systems, add new ones
  • Adjust module boundaries to match the required feature set

nc has no option -z in centos 7

Hi,

There seems to be an issue with init.pp on Centos 7. It would appear that nc done not have the -z command on that platform. My workaround is to replace the "onlyif" call for the bootstrap_galera_cluster with:

"ret=1; for i in ${server_list}; do nc \$i ${wsrep_group_comm_port} < /dev/null; if [ \"\$?\" = \"0\" ]; then ret=0; fi; done; /bin/echo \$ret | /bin/grep 1 -q"

which seems to work on my system.

Unable to replace default value of $galera_servers

Starting with module version 1.0 the default value of $galera_servers is specified in module data. This makes it difficult to replace the default value, possibly breaking some configurations.

For example, when migrating such setups from module version 0.7.x to 1.0 the following undesired changes may be introduced:

Notice: /Stage[main]/Mysql::Server::Config/File[mysql-config-file]/content: 
--- /etc/my.cnf	2018-08-10 23:08:52.166942987 +0200
+++ /tmp/puppet-file20181101-19421-1a7wci9	2018-11-01 22:42:25.060436453 +0100
@@ -75,7 +75,7 @@
 tmpdir = /tmp
 transaction-isolation = READ-COMMITTED
 user = mysql
-wsrep_cluster_address = gcomm://node1.example.com,node2.example.com,node3.example.com/
+wsrep_cluster_address = gcomm://10.10.10.1,node1.example.com,node2.example.com,node3.example.com/

In this case the IP address of "node1" was added to the list, because the default value is $facts['networking']['ip'].

Previous module versions assigned the default value directly in the class parameter and thus did not have this issue, because values were not merged, but simply replaced.

nmap package installation

I'm running into

Duplicate declaration: Package[nmap] is already declared; cannot redeclare at

because other modules already installed nmap. It should be possible to skip nmap installation.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.