-
Notifications
You must be signed in to change notification settings - Fork 795
Use root credentials explicitly #92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…unning puppet as root using sudo because mysql will still look in the user's home directory in that case unless told otherwise.
Conflicts: lib/puppet/provider/database/mysql.rb
There are some added invocations of mysql and mysqladmin since the original commit that also need the defaults file specified.
mysql and mysqladmin are not actually interpolating ~root, but there's a fact for that.
The fact supplied by stdlib is root_home.
These commands are using unqualified table names, so a database needs to be specified.
I have merged this change and tested it on the systems I managed. This change is required for me as puppet otherwise returns errors about not being able to find .my.cnf, as $HOME is not /root when puppet is started via the init script, and via the way we run puppet manually. Please can someone merge this change into puppetlabs-mysql. |
Hi @inkblot, thanks for this pull request! This is definitely something we want to merge, but 7 of the provider spec tests will fail because they are expecting specific arguments to the |
What gems are required to run the rspec suite? |
@inkblot You should only have to |
There are more. In a clean gemset after installing puppetlabs_spec_helper:
I will committing a Gemfile. |
Ah sorry, I forgot to mention that puppet is a requirement as well (whether system packages or gems) because I just take it for granted :). |
Also, https://github.com/puppetlabs/puppetlabs-mysql/blob/master/.gemfile already exists. |
|
Found the blog post. How do I mock the root_home fact from stdlib so that the spec can assert a stable value? |
After running bundler, Also, after running |
@inkblot Perhaps You can mock the |
The mysql invocations in the provider changed, and they're pretty tightly coupled, so they need to be updated here. The :root_home fact isn't getting set for some reason, but this does pass as is.
This demonstrates facts not getting mocked. I don't know enough to say why.
@hunner Can you take a look at this spec and help me understand what's not working right? The fact isn't getting successfully mocked. One thing I notice is that all of the other specs that mock facts are in spec/classes, and this one is in spec/unit. Is there a significant difference between the two location? |
I tried to use this pull request, but when I ran it as is, I encountered an error:
I tried it with just |
Sorry, nevermind, I used an updated version that uses Facter. My bad. |
Pinging again for this. @branan, could you review it? This needs to be rebased to be merged. |
pdksync - (maint) Update pdk-template to f778803
The mysql root password is stored in .my.cnf in root's home directory. However, the mysql and mysqladmin commands use the value of the HOME environment variable rather than libc user ent data to determine the location of .my.cnf. This causes the puppet module's mysql and mysqladmin invocations to fail when HOME and the current user's home directory are not the same, e.g. if the puppet process was started using sudo.
I had created a pull request earlier and then got talked out of it. My initial discovery was that 'sudo puppet agent -t' failed but the running puppet daemon was able to apply the catalog. Someone suggested 'sudo -i puppet agent -t' which works. I have since discovered that even restarting the agent daemon with sudo ('sudo /etc/init.d/puppet restart') causes the a mismatch. This is much more insidious because the running daemon will fail on every run.