Hi Michael,
So you are saying this is a feature rather than a bug?
That's fine :) but it nice be a good idea to have it documented somewhere
.. because I am guessing it is common to run scripts as root .. this script
is doing it because it needs to set up users?
Now I have another problem - I am generating some supervisor files from
templates - but my services (roles) have dependencies on other services. So
because the template uses the variable name instead of it picking
"theServiceThatServiceADependsOn" and "ServiceA" as the names it picks
"ServiceA" and "ServiceA" both times. I am guessing this is to do with
variable scoping - that the var name in the dependent service is getting
overridden?
What's the easiest way around this? Is there some way to pass in variables
when I call my template, just like a function call in a conventional
language? I wondered whether I can just have a vars block in my action, but
I checked out a load of Ansible scripts from github, so I can search them
to find solutions to my problems, but I can't see anyone else doing that?
Also I need to trigger supervisorctl in several different roles - we
decided restarting supervisor was a bad idea because it will restart
existing running services so I am doing this:
- name: myservice | Get supervisor to re-read configs
action: command supervisorctl reread
- name: myservice | Trigger a supervisor update
action: command supervisorctl update
- name: myservice | Get supervisor to restart service
action: command supervisorctl restart {{ name }}
Is there any way I can specify this in one place? A role ought to be able
to do it but I need to pass an argument in (name) - it is a function
effectively?
thanks!
Mark
On 25 February 2014 04:17, Michael DeHaan <[email protected]> wrote:
> Would need to see your playbook so we could have something to repro with
> -- there is a lot of fuzzy logic in synchronize that can be difficult but
> if sudo was on I'd feel it chose correctly.
>
> -- Michael
>
> On Feb 24, 2014, at 9:40 PM, Mark Butler <[email protected]>
> wrote:
>
> Hi Michael,
>
> re: problems with rsync, ansible and vagrant
>
> I discovered I could fix this by adding
>
> sudo: False
>
> to my action - it's isn't trying to do a sudo on my local box is it? Which
> would explain why it always failed with the password for the vagrant box?
>
> thanks for your help,
>
> Mark
>
>
> On 24 February 2014 11:28, Michael DeHaan <[email protected]> wrote:
>
>> If you think this is due to pipelining, it's off by default and can be
>> disabled in ansible.cfg.
>>
>> I don't think it is, and that you probably have a general vagrant
>> question.
>>
>>
>>
>>
>> On Sun, Feb 23, 2014 at 1:23 PM, Mark Butler
>> <[email protected]>wrote:
>>
>>> I am having problems using rsync with Ansible and Vagrant, I don't know
>>> if it is the problem that Bryan is encountering, but it seems to be due to
>>> ssh.
>>>
>>> I have opened a stack overflow post about it here:
>>>
>>>
>>> http://stackoverflow.com/questions/21972438/getting-rsync-in-ansible-to-work-with-vagrant
>>>
>>> On Wednesday, 8 January 2014 09:15:04 UTC-8, bryan hunt wrote:
>>>
>>>> That was a stack overflow post I created, I've been trying to figure
>>>> out for the last 3 weeks why I couldn't check out a project (R/W) from
>>>> github using Ansible.
>>>>
>>>> Finally, I started taking Vagrant apart to figure out how it's ssh
>>>> behaviour differed from Ansible's, that was where I got to.
>>>>
>>>> Give it a go yourself, I don't know why it is, but it's the observable
>>>> behaviour using the default SSH provided with OSX Mavericks.
>>>>
>>>>
>>>>
>>>>
>>>> On 8 Jan 2014, at 17:11, Michael DeHaan <[email protected]>
>>>> wrote:
>>>>
>>>> > That seems curious.
>>>> >
>>>> > Is anyone else observing this behavior and do we have any
>>>> documentation more reliable than Stack Overflow, such as an upstream bug
>>>> report or mailing list thread to reference?
>>>> >
>>>> > I hesitate making such changes based on observed stack overflow
>>>> posts, and suspect there's a tradeoff to switching, but that's me just
>>>> wanting to show extra caution on my part.
>>>> >
>>>> > (It's also not ssh_alt specific so it shouldn't block forward
>>>> progress on this front)
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> >
>>>> > On Wed, Jan 8, 2014 at 11:06 AM, bryan hunt <[email protected]>
>>>> wrote:
>>>> > I've been doing a lot of research on why I couldn't get ssh
>>>> forwarding to work with Ansible.
>>>> >
>>>> > I think I've found a bug (in ssh) regarding how it performs
>>>> authentication, the behavior varies depending on how you express the
>>>> command line arguments.
>>>> >
>>>> > http://stackoverflow.com/questions/20952689/vagrant-
>>>> ssh-agent-forwarding-how-is-it-working?noredirect=1#
>>>> comment31511341_20952689
>>>> >
>>>> > In a nutshell . if you execute SSH like so:
>>>> >
>>>> > ssh -o HostName=127.0.0.1 -o User=vagrant -o.........
>>>> >
>>>> > SSH Agent forwarding doesn't work, regardless of how you specify the
>>>> remaining options.
>>>> >
>>>> > But if you execute it like so, it does:
>>>> >
>>>> > ssh [email protected] -o ..........
>>>> >
>>>> > It would be awesome if it executed the SSH command in that manner.
>>>> >
>>>> >
>>>> > On Saturday, January 4, 2014 7:01:55 PM UTC, Michael DeHaan wrote:
>>>> > The "ssh_alt" connection type as implemented by Jerome Wagner greatly
>>>> reduces the amount of operations performed over connections by not
>>>> transferring modules as files for many cases. It's pretty impressive.
>>>> >
>>>> > It can currently be tested on the development branch with
>>>> "connection: ssh_alt" in a play, or "-c ssh_alt".
>>>> >
>>>> > I would like this to become the default in Ansible devel, to be
>>>> released as the default in 1.5, in the next week or two.
>>>> >
>>>> > As such, if everyone using the SSH transport (aka anyone not running
>>>> from RHEL/CentOS/EPEL
>>>> > and still using paramiko), as they normally use Ansible, this will be
>>>> greatly appreciated.
>>>> >
>>>> > I just recently merged in some tweaks to sudo password detection.
>>>> >
>>>> > If we can get it past encountering any problems, we'll remove the old
>>>> ssh.py and replace ssh_alt.py as ssh.py, and there will be no more
>>>> connection named "ssh_alt".
>>>> >
>>>> > Thank you!
>>>> >
>>>> > --
>>>> > Michael DeHaan <[email protected]>
>>>> >
>>>> > CTO, AnsibleWorks, Inc.
>>>> > http://www.ansibleworks.com/
>>>> >
>>>> >
>>>> > --
>>>> > 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].
>>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > Michael DeHaan <[email protected]>
>>>> > CTO, AnsibleWorks, Inc.
>>>> > http://www.ansibleworks.com/
>>>> >
>>>> >
>>>> > --
>>>> > You received this message because you are subscribed to a topic in
>>>> the Google Groups "Ansible Project" group.
>>>> > To unsubscribe from this topic, visit https://groups.google.com/d/
>>>> topic/ansible-project/IeF5rd68xZE/unsubscribe.
>>>> > To unsubscribe from this group and all its topics, send an email to
>>>> [email protected].
>>>> > To post to this group, send email to [email protected].
>>>> > For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>> --
>>> 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/8cd6ffe6-7eed-4ba1-b7bb-6771589faa53%40googlegroups.com
>>> .
>>>
>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>
>>
>> --
>> You received this message because you are subscribed to a topic in the
>> Google Groups "Ansible Project" group.
>> To unsubscribe from this topic, visit
>> https://groups.google.com/d/topic/ansible-project/IeF5rd68xZE/unsubscribe
>> .
>> To unsubscribe from this group and all its topics, 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/CAEVJ8QM90ThUdP6GaEjAQdqW%3Du9Cn6gmQSHToEf8RSpeWpcqWw%40mail.gmail.com
>> .
>>
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>
> --
> 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/CAC_tV5-SyYny35RCJVbBn5UdHGNbM6CL1AKuTsh9Ns1CdO9W8A%40mail.gmail.com
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "Ansible Project" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/ansible-project/IeF5rd68xZE/unsubscribe.
> To unsubscribe from this group and all its topics, 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/-5433849489155842019%40unknownmsgid
> .
>
> For more options, visit https://groups.google.com/groups/opt_out.
>
--
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/CAC_tV58jHs2Dhh%3DmNTMULM_9WPsnCkw_rNNKzVvGOBSB_7KA9Q%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.
