disable fact gathering, have the first task be setup: as root (ignore_errors), condition the rest of the tasks on it's success or failure
On Mon, May 11, 2015 at 12:04 PM, Callum Macdonald <[email protected]> wrote: > I did find another workaround, but it's not very elegant either. > > In my bootstrap.yml file I created two identical blocks, one with > `remote_user: root` and one without. Then I can conditionally run the > playbook against one host like so: > > ansible-playbook bootstrap.yml -l host -t root > or > ansible-playbook bootstrap.yml -l host -t current > > It's also ugly, but at least doesn't require code changes when I want to > init a new host. > > Cheers - Callum. > > > On Monday, 11 May 2015 17:58:53 UTC+2, Callum Macdonald wrote: >> >> @Adrian: Did you ever find a better solution? >> >> I tried adding a custom value per host, like `bootstrap_user=root`, so I >> could manually configure that this user should be used for the bootstrap >> playbook. It seems like `remote_user: "{{ bootstrap_user }}"` is not >> interpreted, but passed directly to the ssh command as the literal username. >> So this approach doesn't really work. >> >> In the end, I did like you, and wrote the user into the playbook. I'll >> manually edit it when bootstrapping new hosts. :-( >> >> Cheers - Callum. >> >> On Tuesday, 25 March 2014 12:39:12 UTC+1, Adrian Simmons wrote: >>> >>> Thanks Michael, >>> >>> On Monday, 24 March 2014 12:32:10 UTC, Michael DeHaan wrote: >>>> >>>> I highly recommend arranging variables in group_vars/ and host_vars/ >>>> directories versus trying to fit them into the INI file -- IMHO, it's a lot >>>> easier to read. >>> >>> I do have the ansa user in host_vars/all – this is a user setup just for >>> ansible to use and I do want *all* hosts to use it. >>> I need to run a setup play once to get the ansa user into place on each >>> host and that setup play has ansible_ssh_user in "vars"... >>> >>>> >>>> ansible_ssh_user in "vars" as this will override that setting, which >>>> seems to be not what you want to do. >>> >>> ...because overriding that setting just for the setup play is *exactly* >>> what I want to do. >>> >>> My question was regarding two different types of base boxes. Vagrant and >>> non-vagrant – for the vagrant boxes the setup play needs to set the var >>> ansible_ssh_user to 'vagrant' and for the non-vagrant it needs set to >>> 'root'. There's no neat and tidy separation between groups, [production], >>> [testing] etc may each have vagrant or non-vagrant hosts, so I cant just use >>> group_vars. >>> >>> What I've done as a workaround is to have my vagrantfile setup the root >>> user for ssh access – so that the vagrant based boxes and non-vagrant behave >>> exactly the same as far as my setup play is concerned. >>> >>> Reading the documentation again today I'm thinking I should probably have >>> my setup play look for an ansible fact specific to a vagrant box and then a >>> conditional in the setup play based on that, so that I can have one setup >>> play that deals with both types of box. >>> >>> >>> >>>> >>>> >>>> >>>> On Mon, Mar 24, 2014 at 6:25 AM, Adrian Simmons <[email protected]> >>>> wrote: >>>>>> >>>>>> Right now the only thing I can think of is to work outside of ansible, >>>>>> setting up the root account with vagrant to match that on the non-vagrant >>>>>> hosts, so I can have a single setup play. >>>>> >>>>> Looks like that question was to long and rambling to get answers :P >>>>> At least writing it all down sometimes makes you think of the best >>>>> answer. >>>>> >>>>> I took my own advice and did the work in vagrant instead, to set the >>>>> root account up with ssh key access so my setup play can work just as it >>>>> can >>>>> on non-vagrant nodes. I'll have my main ansible play remove that key as a >>>>> part of securing ssh access. >>>>> >>>>> >>>>> -- >>>>> 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 [email protected]. >>>>> To post to this group, send email to [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/ansible-project/c4955e25-6220-4048-b432-990c3f14db47%40googlegroups.com. >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>> >>>> > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/ansible-project/3b62439c-620a-4e32-8d8f-6df329c4a38e%40googlegroups.com. > > For more options, visit https://groups.google.com/d/optout. -- Brian Coca -- 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 [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/ansible-project/CAJ5XC8mc%2B8MwbotxsC1Dwq1Ef9Si0cLLMnPCLLdAAr-JZ9ExRQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
