Thank you.  The reason we used a bogus user@realm value in our inventory 
was because it "worked" and allowed us to run playbooks as the 
authenticated user rather than relying on a set value in inventory or 
requiring operators to enter it at the command line.  Leaving it blank in 
our 2.0 install caused the following error:
   An exception occurred during task execution. To see the full traceback, 
use -vvv. The error was: TypeError: argument of type 'NoneType' is not 
iterable 

We did find that specifying the transport as kerberos and leaving the 
ansible_user variable undefined provides the same functionality in the 
newer builds.  Although we will need to change our inventory, this will 
only be problematic until we get everyone updated to 2.2.

The behavior you describe for newer builds makes sense.

Thanks again for your assistance.




On Monday, November 14, 2016 at 11:27:56 AM UTC-5, Matt Davis wrote:
>
> Pre-2.1, Ansible *only* supported the "default" Kerberos principal, so 
> folks needing more than one Kerberos principal at a time (eg, multiple 
> principals in parallel or the ability to switch principals mid-run) were 
> hosed. With 2.1 and later (and some associated fixes to pykerberos and 
> requests_kerberos), we actually use ansible_user (when specified) to look 
> up the right user. If it's not specified, we revert to the default 
> principal behavior that 2.0 and previous used.
>
> Why are you specifying a nonsensical value for ansible_user instead of 
> just leaving it blank?
>
> If you need to set it back to null at the host level for some reason, you 
> can do that in YAML (eg host_vars) with the ~ character as the value, or by 
> using !!null. I don't believe those work in .ini inventory, though. I'd 
> strongly suggest you just not set it to a garbage value, though.
>
> -Matt
>
> On Monday, November 14, 2016 at 7:42:52 AM UTC-8, mmcgrellis mmcgrellis 
> wrote:
>>
>> We have a current setup that works using Ansible v2.0.0 in which we 
>> specify ansible_ssh_user in inventory exactly as follows.
>>
>> ansible_ssh_user: user@realm
>>
>> When running playbooks we use kinit to get a kerberos ticket using real 
>> credentials ([email protected] <javascript:>) and everything 
>> works.
>> That is ansible uses the kerberos ticket for [email protected] 
>> <javascript:> and we can successfully connect to Windows servers.
>>
>>
>> However, behavior in Ansible 2.1 and 2.2 is different.  When using the 
>> newer versions, Ansible tries to connect with the fake user@realm username, 
>> ignoring our kerberos ticket and hence failing to connect.
>> - changing ansible_ssh_user to ansible_user makes no difference
>> - specifying the [email protected] <javascript:> with the -u 
>> option on the command line makes no difference
>>
>> What does work is setting ansible_user to [email protected] 
>> <javascript:> in the inventory.  However, this is problematic as we have 
>> several users and don't want to have to constantly change our inventory 
>> depending on which user is actually running playbooks.
>>
>> Am I missing something or did something change in regards to behavior?  
>> Is there some way to get the old behavior?
>>
>> Thanks.
>>
>>
>>

-- 
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/cdd3d69b-1f28-4292-8e8c-df3d4613b84d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to