On Wednesday, April 2, 2014 2:50:52 PM UTC-5, Bradley Frank wrote:
>
> Puppet 2.7, using the mysql module, version 2.1.0.
>
> I do not wish to have Puppet manage the root password because passwords
> should not be included in my manifests (which are captured in Git).
> I have a setup where /root/.my.cnf symlinks to a central .my.cnf file on a
> NFS mount. The goal is to have Puppet do all the database setup, create the
> symlink, then I log in and update root password.
> To make this work, here is a snippet of the steps I'm executing:
>
>
> class { '::mysql::server':
> databases => $databases,
> override_options => $override_options,
> grants => $grants,
> package_name => 'MariaDB-server',
> remove_default_accounts => true,
> restart => true,
> service_enabled => true,
> service_name => 'mysql',
> users => $users,
> }
>
> file { '/root/.my.cnf':
> ensure => 'link',
> target => '/nfs/projects/a/admin/.my.cnf',
> }
>
> Class['::mysql::server'] ->
> File['/root/.my.cnf']
>
>
Why do you need that relationship? Is there a reason why Puppet shouldn't
sync File['/root/.my.cnf''] before it applies Class['::mysql::server']?
The only good reason I can imagine is that the class installs a default
version of that file (or may do), though if so then it cannot be doing that
via a File resource.
I could maybe see it the other way around. In fact, if
Class['::mysql::server'] actually ensures that the service is running, and
the service draws configuration from the file, then syncing the File first
is the only way that makes sense.
>
> Problem #1) This returns a dependency cycle error:
>
> err: Could not apply complete catalog: Found 1 dependency cycle:
> (Anchor[mysql::server::end] => Class[Mysql::Server] => File[/root/.my.cnf]
> => Mysql_grant[pma@%] => Class[Mysql::Server::Providers] =>
> Anchor[mysql::server::end])
>
> ($users includes 'pma@%' so that I can point phpMyAdmin to the database at
> a later point.)
>
> After unsuccessfully troubleshooting the problem, I changed my manifest to
> the following:
>
> exec { 'symlink':
> command => "ln -s ${mycnf} /root/.my.cnf",
> unless => "ls /root/.my.cnf",
> }
>
> Class['::mysql::server'] ->
> Exec['symlink']
>
>
Again, I don't understand why you're even attempting this. The dependency
cycle you described should be a warning that what you are trying to do is
not internally consistent. If that's not in fact the case then the cycle
reflects a bug in the module.
>
> Problem #2) Only part of ::mysql::server executes before the symlink is
> created.
>
> ...snip...
> ** [out :: ] notice:
> /Stage[main]/Mysql::Server::Providers/Mysql_grant[pma@%]/ensure: created
> ** [out :: ] notice:
> /Stage[main]/Mysql::Server::Account_security/Mysql_user[root@<hostname>]/ensure:
>
> removed
> ** [out :: ] notice:
> /Stage[main]/Mysql::Server::Account_security/Mysql_database[test]/ensure:
> removed
> ** [out :: ] notice: /Stage[main]/Hmdc_mariadb/Exec[symlink]/returns:
> executed successfully
> ** [out :: ] err:
> /Stage[main]/Mysql::Server::Account_security/Mysql_user[root@::1]/ensure:
> change from present to absent failed: Execution of '/usr/bin/mysql
> --defaults-extra-file=/root/.my.cnf -e DROP USER 'root'@'::1'' returned 1:
> ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
> password: YES)
> ** [out :: ]
> ** [out :: ] err:
> /Stage[main]/Mysql::Server::Account_security/Mysql_user[@<hostname>]/ensure:
> change from present to absent failed: Execution of '/usr/bin/mysql
> --defaults-extra-file=/root/.my.cnf -e DROP USER ''@'<hostname>'' returned
> 1: ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using
> password: YES)'
> ...snip...
>
>
> I was under the impression that chaining meant all instructions would
> finish before moving on to the next? I'm considering putting a sleep
> statement in my symlink exec, in the hopes that a few more seconds will
> allow ::mysql::server to finish executing.
>
>
This part appears to be a containment issue (
http://docs.puppetlabs.com/puppet/latest/reference/lang_containment.html).
It may reflect a bug in the module, but it might also arise as a result of
misuse of the module.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/bbb571c4-4ec3-4fc7-a892-b94823c4bfe0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
