Re: [ansible-project] Automatically connecting as different user on later runs after 'root' is disabled

[Greg Bell]

Thanks for the thoughts Brian.

> You could have the first task attempt to 'connect as root and set
> the other user', ignore their failure and continue with rest of
> play with correct credentials

This is a new idea to me.  Obviously some smell around ignoring failures.


> You could skip the 'as root' tasks depending on a passed var

Requires operator knowledge of state.


> Variation on the above, have the play update host_vars for that host
> with needs_root=False and have needs_root=True in group_vars/all.yml
> after updating the machine to not need root.

This is interesting.  In effect, I'm keeping knowledge of state on the 
local machine.  Downsides might be - others operators don't have my 
machine's state knowledge, I've built a non-obvious state mechanism, 
and some machines in a group may fail, thus the state of the group is 
not necessarily accurate.



> Another variation, add the host to 'doesnt_need_root' group in play

Interesting idea.  Then the inventory sort of becomes a text-based
database, manipulated by plays.  Yuck.

Which of these seems cleanest to you?  The automatic ones all feel
like complicated mechanisms built on top of Ansible that sort  of go 
against the ideology of Ansible.



~gb

--
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-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/5e8305a8-befc-91b0-263f-9c090c2579ef%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[ansible-project] Automatically connecting as different user on later runs after 'root' is disabled

[Greg Bell]

Hi,

One of my tasks disables root over ssh.
Another creates an 'app' user that has sudo powers.

That means that the way to connect to the host changes after the first run.

Is there a smarter way to easily adjust to this new state than manually 
adding --become and --user command-line options to ansible-playbook on 
subsequent runs?


-- 
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-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/b36131d5-a1f5-4ed5-949e-55d5cc0ec9ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ansible-project] Can I convince anybody that the mysql_db state=import behavior is a bug?

[Greg Bell]

Hi,

As discussed at here a long time ago 
,mysql_db
 
state=import will import the given file unconditionally.

There's a good chance the database has been updated since the original run 
of ansible, so this behavior means users should never run ansible after the 
server goes public.

The link above discusses several options for only running import once, but 
the nuances and trade-offs of each are lost on me as a non-expert.

I would suggest that, since we're not talking about a write-once sort of 
target like conf files in /etc, this behavior is bad.  In fact, it just now 
nearly wiped out a bunch of data for me as I made a configuration change 
and confidently (stupidly?) re-ran my ansible script.

The import function should refuse to import data if there's already data in 
the database.  Or, it shouldn't be it's own 'state' (not really a state) 
and be a part of the actions done for state == 'present'.

Have I convinced anybody?  If so, I'll file a bug on GitHub... didn't want 
to clutter that if I'm off the mark.


-- 
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-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/2fe8ee8f-3dbd-472e-800b-e16a39ced7b3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ansible-project] Re: Shell Permission denied

[Greg Bell]

My OCD is noticing that Ansible's running --list, but you use -l from the 
command line.  Of course no difference, right?

I don't know what the problem is, but maybe it's not becoming root?  Can 
you shell:whoami?

-- 
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-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/d00106d1-3eae-4c2e-abdb-30079d06f4b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[ansible-project] Re: Specfic multistage application deployment methodology

[Greg Bell]

I'm not understanding your problem, and am too new to help anyway, but I'll 
ask a clarifying question:  Are you hoping Ansible sets up your development 
environment, or that it accesses it during deployment?

-- 
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-project+unsubscr...@googlegroups.com.
To post to this group, send email to ansible-project@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/ansible-project/eca39009-6e31-4f88-ade4-9f912c75e7e7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.