using different remote_user until success

I’ve been struggling with this and googling all morning and getting nowhere fast.

I am using aws dynamic inventory python script to get me an inventory of instances that I am going to make some changes to.

I need to do this on possibly a large number of accounts. The first account I am working on has Linux instances of various flavours.

On some of the instances centos is the user to connect as, on other ec2-user… and I think there are a few imported images that use root, luckily they all use the same keypair.

So I create a list of these users as a var. Now how can I try to connect as each user until success? And then continue on to tasks?

Sorry, my ansible is a bit rusty and everything I google seems to imply that you will know the user for each host and have that user in your inventory file.

Thanks for any advice!

Bill

loop a ping task over the users and use 'ignore_unreachable' and
failed_when: false to keep running that task, register the result and
set ansible_user using the results.

Hi Brian, this seemed like a good way to do it, but I haven't been able to make it work - I haven't done much logic in my plays... mostly just point and shoot tasks.

Sorry, pressed send inadvertently there...

Are you opposed to using a second playbook and using the “include:” module like this?

Thanks,

I think that is sort of what my colleague was alluding to – slightly more elegant though.

So, it will run include-3.yml 3 times? And one will succeed? I obviously have a number of tasks to run after this…

I was kind of hoping to keep this logic all in one with the idea that I might create a single report after about what user worked and what was done … ( not to say that couldn’t be done this way as well, but just my method of thinking)

Also it seem strange that assigning variable to remote_user seems to only work once – is that correct?

I actually dug down into the source and the ssh.py connection plugin and it didn’t look as though it would be a big deal to pass a list to it but I don’t particularly want to wind up with my ‘own’ version of ansible plugins so unless someone thought it was worthwhile having then I probably won’t.

Saying that, as AWS instances do have different user accounts according to flavor, and you can’t get the flavor without connecting, it seems like it might be useful?

Regards

Bill

So, it will run include-3.yml 3 times? And one will succeed?

Yes - in my testing, I added a good user account to use, and that one ran the ping successfully.

I obviously have a number of tasks to run after this…

In my scenariou we have a number of system that might use one of a number of different accounts - the list of what account is used where has been lost to time.

With a script like this we could have it run through a large list of accounts and note which one(s) succeed for each host. After that is done, we then run a fix-it script to either update the systems to use a consistent account, or we update our system database so the proper account is known. Regardless of which direction is gone, it is then easy to generate an inventory with the appropriate login account so Ansible can access them properly without having to try all the keys.

Also it seem strange that assigning variable to remote_user seems to only work once – is that correct?

Not sure - I didn’t dig into the code to check.

I actually dug down into the source and the ssh.py connection plugin and it didn’t look as though it would be a big deal to pass a list to it but I don’t particularly want to wind up with my ‘own’ version of ansible plugins so unless someone thought it was worthwhile having then I probably won’t.

I really shy away from mucking with the deep internals - especially when that code will probably get updated over time and future updates will overwrite my changes.

Saying that, as AWS instances do have different user accounts according to flavor, and you can’t get the flavor without connecting, it seems like it might be useful?

I think so, yes.

Dan

Thanks Dan, I have opened a bug report on this as I don’t see why a variable should not be able to be assigned to remote_user and from various people looking at the simple playbook I don’t ‘think’ I am doing anything wrong syntactically.

I am going to try as you suggest in the meantime – thanks for the suggestion and the answers to my questions, much appreciated.

Regards

Bill

So I tried doing this as described with includes – I spun up a new Amazon Linux instance and things seemed to be working however I have now run into another problem…

When it tries to ping using centos user, it fails with unreachable – good

When it tries to ping using user ec2-user it works as expected and succeeds

When it tries to ping using user root, I get:

TASK [try users] ****************************************************************************************************************************************************************************************

[WARNING]: Unhandled error in Python interpreter discovery for host 10.5.162.167: unexpected output from Python interpreter discovery

[WARNING]: sftp transfer mechanism failed on [10.5.162.167]. Use ANSIBLE_DEBUG=1 to see detailed information

[WARNING]: scp transfer mechanism failed on [10.5.162.167]. Use ANSIBLE_DEBUG=1 to see detailed information

[WARNING]: Platform unknown on host 10.5.162.167 is using the discovered Python interpreter at /usr/bin/python, but future installation of another Python interpreter could change this. See

https://docs.ansible.com/ansible/2.8/reference_appendices/interpreter_discovery.html for more information.

ok: [10.5.162.167]

which is bad… I try to connect using normal ssh root@10.5.162.167 and it fails… so I don’t see how the above is resulting in an OK :frowning:

I have tried with -vvvv and I can’t see exactly what is causing it…. I haven’t tried using debug yet, but thought I would post to see if the basic errors above mean anything to anyone?

I will setting ANSIBLE_DEBUG=1 later today when I have more time again – I have googled selections of the above and haven’t found anything meaningful as of yet.

Thanks, as always for any advice.

Regards

Bill