Hi

Just bumping this thread to let interested parties know I found the 
solution for this.
I had in .ansible.cfg this line:

ask_sudo_pass  = True

Once that was removed all issues have disappeared.
Don't really see why, but the fact remains: no problems whatsoever.
I'm guessing that somehow ansible's behaviour changes in unexpected ways 
for me to see.
I connect through a user and then sudo to root. The first stage is done 
through ssh certs. No passwds there.
The second is a normal sudo.
If I add -K to the command line works flawlessly. with the setting on the 
.cfg file I get all kinds of weird behaviour that you can read on this 
thread.

Anyway. Solved!

Thanks all for the time



On Thursday, 13 February 2014 10:42:39 UTC, Makimoto Marakatti wrote:
>
> I've been looking at all that, but work gets in the way! :)
> Right now I'm going to ignore that error in the lone box and get some 
> things done. When I'm finished with the whole reorganisation, the issue 
> most probably will have gone away...
> anyway, thanks for the help! appreciated!
>
> On Thursday, 13 February 2014 09:53:49 UTC, Walid Shaari wrote:
>>
>> no but system root or what ever user you are running ansible as (su, 
>> sudo, user) could have different permissions on an NFS mount than system 
>> permissions. root could be squashed, ids could be not mapped correctly 
>>
>>
>> On 13 February 2014 12:48, Makimoto Marakatti <[email protected]> wrote:
>>
>>> yes, /home is on nfs on some systems, but even if that raises chances of 
>>> issues with ansible, it's not conclusive. Some of the hosts that indeed 
>>> have the /home shared do not show any issues. So there's something going 
>>> on, but haven't yet figured it out.
>>>
>>>
>>> On Thursday, 13 February 2014 09:06:06 UTC, Walid Shaari wrote:
>>>
>>>> is any of the /tmp and $HOME/tmp in a shared file system?
>>>>
>>>>
>>>> On 13 February 2014 11:34, Makimoto Marakatti <[email protected]>wrote:
>>>>
>>>>> No difference there really. I even tried to chmod 777 ~/.ansible to 
>>>>> see if it made a difference, but no luck.
>>>>> I will get to the root cause eventually... :)
>>>>>
>>>>>
>>>>> On Wednesday, 12 February 2014 16:16:07 UTC, Walid Shaari wrote:
>>>>>
>>>>>> what are the  /tmp and $HOME/tmp permissions? I am wondering if it is 
>>>>>> a permission issue, you can fix it using the raw module?!
>>>>>>
>>>>>>
>>>>>> On 12 February 2014 18:57, Makimoto Marakatti <[email protected]>wrote:
>>>>>>
>>>>>>>
>>>>>>> Well, if I set remote_tmp to the default I get the same error 
>>>>>>> message as above in ~50% of my servers. Setting it to /tmp gives me 
>>>>>>> issues 
>>>>>>> with this single server.
>>>>>>> Having close to 400 boxes, I'm prone to lean to the less damaging 
>>>>>>> option. It somehow has to do with the fact that in many of those 
>>>>>>> failing 
>>>>>>> %50 boxes the home dir is a shared one through NFS. But it's not 
>>>>>>> granted 
>>>>>>> either to get an error because the home dir is on nfs: it just has more 
>>>>>>> probabilities of failing. (IE: haven't figured out yet what the real 
>>>>>>> issues 
>>>>>>> is...)
>>>>>>>
>>>>>>> Reading about this, is there not the possibility to have a conf file 
>>>>>>> in the playbook dir? That would actually take precedence over the main 
>>>>>>> one??
>>>>>>>
>>>>>>> At this point any advice is good :)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Wednesday, 12 February 2014 14:23:06 UTC, Michael DeHaan wrote:
>>>>>>>
>>>>>>>> There is not, which is not saying I'm unsympathetic.
>>>>>>>>
>>>>>>>> Needing to specify remote temp is an infrequent thing, and not 
>>>>>>>> really a common OS divergence thing most people run into anymore.   
>>>>>>>> Most 
>>>>>>>> folks just pick a path that works, like $HOME/tmp.
>>>>>>>>
>>>>>>>> I'm a bit curious why the $HOME related option didn't work across 
>>>>>>>> the board?  Does the user not have a homedir?
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Feb 12, 2014 at 9:19 AM, Makimoto Marakatti <
>>>>>>>> [email protected]> wrote:
>>>>>>>>
>>>>>>>>>
>>>>>>>>> Ok. So what are my options here? I cannot be the only person with 
>>>>>>>>> a situation like this.
>>>>>>>>> Diverging OS baseline installs is one of the reasons ansible is 
>>>>>>>>> used after all?
>>>>>>>>> Is there not any workaround?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Wednesday, 12 February 2014 12:57:54 UTC, Michael DeHaan wrote:
>>>>>>>>>
>>>>>>>>>> Not currently.
>>>>>>>>>>
>>>>>>>>>> Patches to add it as an inventory variable would be accepted 
>>>>>>>>>> (just apply to any group you need), but I'm not sure it really 
>>>>>>>>>> belongs as a 
>>>>>>>>>> playbook keyword.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Wed, Feb 12, 2014 at 7:53 AM, Makimoto Marakatti <
>>>>>>>>>> [email protected]> wrote:
>>>>>>>>>>
>>>>>>>>>>>  Is there a way then to set this in a playbook at runtime?
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On Wednesday, 12 February 2014 12:39:02 UTC, Brian Coca wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> this is not currently configurable by host, just the 
>>>>>>>>>>>> ansible.cfg setting and the environment variable 
>>>>>>>>>>>> ANSIBLE_REMOTE_TEMP.
>>>>>>>>>>>>
>>>>>>>>>>>  -- 
>>>>>>>>>>> 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
>>>>>>>>>>> .
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>  -- 
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>
>>>>>>>>  -- 
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>>  -- 
>>>>> 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.
>>>>>
>>>>
>>>>  -- 
>>> 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.
>>>
>>
>>

-- 
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/e2b5646d-90c1-454b-8626-0c77747e4bc2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to