operating on multiple MySQL databases...

[Dmitry Makovey]

Hi,

my current usecase is to walk around multiple MySQL DB hosts and remove user from them. Sounds like a nice usecase for mysql_user module. Bit of complication: all hosts have different root credentials. I do not want to either hardcode credentials into the playbook/CLI invocation nor do I feel comfortable sticking it on every box under ${HOME}/.my.cnf . What are current recommendations for this kind of scenario. I've seen vars_prompt, however since I'll need it per-host: how do I do that? Another thing - since we're talking "action" vs "configuration" I felt it's a task for "ansible CLI" vs "ansible-playbook", am I understanding things correctly? What shall I do with multiple hosts and their login credentials?

[Michael DeHaan]

The typical way to keep secret data is to load them via "vars_files" from a directory outside of your main playbooks repository.

It is perfectly fine to set up playbooks for doing common tasks if you want to, I actually don't use /usr/bin/ansible hardly ever, except maybe to reboot some nodes, or to check something simple like uptime.

Though if you want to use the ansible program instead, that is fine too.

But playbooks are for all kinds of processes, not just configuration.

Rolling updates of applications are a particulary common non-OS-config task.

On Fri, Jul 12, 2013 at 12:06 PM, Dmitry Makovey <droop...@gmail.com> wrote:

Hi,

my current usecase is to walk around multiple MySQL DB hosts and remove user from them. Sounds like a nice usecase for mysql_user module. Bit of complication: all hosts have different root credentials. I do not want to either hardcode credentials into the playbook/CLI invocation nor do I feel comfortable sticking it on every box under ${HOME}/.my.cnf . What are current recommendations for this kind of scenario. I've seen vars_prompt, however since I'll need it per-host: how do I do that? Another thing - since we're talking "action" vs "configuration" I felt it's a task for "ansible CLI" vs "ansible-playbook", am I understanding things correctly? What shall I do with multiple hosts and their login credentials?

--
You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Michael DeHaan <mic...@ansibleworks.com>
CTO, AnsibleWorks, Inc.
http://www.ansibleworks.com/

[Dmitry Makovey]

On Friday, July 12, 2013 12:39:31 PM UTC-6, Michael DeHaan wrote:

The typical way to keep secret data is to load them via "vars_files" from a directory outside of your main playbooks repository.

I thought of that - but can't find a way to do it "dictionary style" with mapping hostname -> login:password for multiple machines. Am I looking at creating <hostname>_login and <hostname>_pass variables? Any better solutions that I can recycle inside a single "mysql_user" command? 

 

It is perfectly fine to set up playbooks for doing common tasks if you want to, I actually don't use /usr/bin/ansible hardly ever, except maybe to reboot some nodes, or to check something simple like uptime.

Though if you want to use the ansible program instead, that is fine too.

But playbooks are for all kinds of processes, not just configuration.

Rolling updates of applications are a particulary common non-OS-config task.

ok, good to know. I just got a feeling that ansible is "more natural" in setting things up, as running tasks becomes a bit more cumbersome with all the output suppressed etc. "ansible" in those cases is pleasantly verbose :)

 

[Dmitry Makovey]

ok, good to know. I just got a feeling that ansible is "more natural" in setting things up, as running tasks becomes a bit more cumbersome with all the output suppressed etc. "ansible" in those cases is pleasantly verbose :)

 

that should've read as:

 ok, good to know. I just got a feeling that ansible-playbook is "more natural" in setting things up, as running tasks becomes a bit more cumbersome with all the output suppressed etc. "ansible" in those cases is pleasantly verbose :)

[Michael DeHaan]

That's why there is the "-v" option to ansible-playbook :)

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dmitry Makovey]

On Friday, July 12, 2013 1:51:33 PM UTC-6, Michael DeHaan wrote:

That's why there is the "-v" option to ansible-playbook :)

you'll have to agree that it is not nearly as useful as output of "absible" when it comes to post-processing. ;) and yes - I do use "ansible-playbook -vv" a lot.

[Dmitry Makovey]

On Friday, July 12, 2013 10:06:08 AM UTC-6, Dmitry Makovey wrote:

Hi,

my current usecase is to walk around multiple MySQL DB hosts and remove user from them. Sounds like a nice usecase for mysql_user module. Bit of complication: all hosts have different root credentials. I do not want to either hardcode credentials into the playbook/CLI invocation nor do I feel comfortable sticking it on every box under ${HOME}/.my.cnf . What are current recommendations for this kind of scenario. I've seen vars_prompt, however since I'll need it per-host: how do I do that?

now that we've dealt with ansible vs ansible-playbook, what about the above. I did see vars_files Michael mentioned but how do I do it per-host? Am I missing something obvious?

[Michael DeHaan]

"host_vars" and "group_vars" perhaps?

--

You received this message because you are subscribed to the Google Groups "Ansible Project" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ansible-proje...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Dmitry Makovey]

On Monday, July 15, 2013 10:50:53 AM UTC-6, Michael DeHaan wrote:

"host_vars" and "group_vars" perhaps?

yes, I was looking at those. Still unconvinced I'd like to store those passwords clear-text (esp. when I push it into central repo). Probably I should just integrate gpg invocation to pull cred info into the vars. Sounds hacky but at least stores things securely. Now what's the best way to marry ansible and gpg prompt? gpg-agent? Is it a completely whacked idea?

 

[Jim Kleckner]

You might find this closed pull request interesting. It explored using a keyring implementation:

  https://github.com/ansible/ansible/pull/2184

[Michael DeHaan]

See also very long (better) thread about storing encrypted data in a "vault" type approach.

We need to squash the 1.3 bug queue first though before we start entertaining testing that.

--

[prateek gupta]

Can you please cross check this 

Im trying to create a user but it gets executed but the user is not getting created in my RDS mysql DB .

--------------------

---

#creating a sql user

 - hosts: localhost

   tasks:

    #- name: test

   - mysql_user: login_host=abcde.us-west-2.rds.amazonaws.com priv=*.*:SELECT,INSERT,UPDATE,DELETE,CREATE,DROP,RELOAD,PROCESS,REFERENCES,INDEX,ALTER,SHOWDATABASES,CREATETEMPORARYTABLES,LOCKTABLES,EXECUTE,REPLICATIONSLAVE,REPLICATIONCLIENT,CREATEVIEW,SHOWVIEW,CREATEROUTINE,ALTERROUTINE,CREATEUSER,EVENT login_port=3306 login_user=klm login_password=abc name=marley password=klms state=absent