# vars\_prompt issues

**URL:** <https://forum.ansible.com/t/vars-prompt-issues/11459>\
**Category:** Ansible Project\
**Created:** [April 26, 2012, 4:32pm UTC](https://forum.ansible.com/t/vars-prompt-issues/11459 "2012-04-26T16:32:47Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![Dave\_Coutu](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dave\_Coutu](https://forum.ansible.com/u/Dave_Coutu)\
**Post date:** [April 26, 2012, 4:32pm UTC](https://forum.ansible.com/t/vars-prompt-issues/11459/1 "2012-04-26T16:32:47Z")

</div>

Hey Folks,

Running into some odd behavior (currently on the devel branch) with vars\_prompt. What I am seeing are 2 things.

1. I get no console echo when inputting the variables that I prompt for. I can’t remember if we decided to mask the input of these variable entirely or if there was a way to only mask certain variables we prompt for. For these variables in particular I want to use, it would be good to echo them. The only things we would want to prompt and not echo for would be passwords/passphrases, imo.
2. I appear to get prompted twice for the variable input. In the .ansible/setup file that gets created on the client machine, the values entered via the second prompt are the ones present. Again, the only time we would want to prompt twice (and do a comparison against the 2 inputs) would be passwords/passphrases, and if there was a failure, re-prompt.

Here’s what I see…

[xx]$ ansible/bin/ansible-playbook site/deploy-servers.yml -K  
sudo password:  
Release to deploy?  
input for release\_version:  
Who’s your Daddy?  
input for Daddy:

Release to deploy?  
input for release\_version:  
Who’s your Daddy?  
input for Daddy:

A couple other things I have noticed during testing:

1. On the client machines, the setup file under .ansible is owned by root (artifact of running through sudo?). I was able to delete it just happily tho as myself after logging into the client directly.

2. If the playbook is interrupted for whatever reason, we get stale files under .ansible/tmp. I can clean these out but they may never get noticed otherwise if you didn’t know to look for them.

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [April 26, 2012, 6:45pm UTC](https://forum.ansible.com/t/vars-prompt-issues/11459/2 "2012-04-26T18:45:46Z")

</div>

> Hey Folks,
> 
> Running into some odd behavior (currently on the devel branch) with vars\_prompt. What I am seeing are 2 things.
> 
> 1. I get no console echo when inputting the variables that I prompt for. I can’t remember if we decided to mask the input of these variable entirely or if there was a way to only mask certain variables we prompt for. For these variables in particular I want to use, it would be good to echo them. The only things we would want to prompt and not echo for would be passwords/passphrases, imo.

vars\_prompt is ONLY intended for passwords

Other variables should be version controlled with the PB. We have also talked about reinstating --extra-args, which is going to happen, so a release version you can just pass in on the command line.

Typing things is kinda against the point of automation, right? 🙂

> 1. I appear to get prompted twice for the variable input. In the .ansible/setup file that gets created on the client machine, the values entered via the second prompt are the ones present. Again, the only time we would want to prompt twice (and do a comparison against the 2 inputs) would be passwords/passphrases, and if there was a failure, re-prompt.

The variable name and the prompt should be printed on one line, like this:

dogs\_out: Who Let The Dogs Out?

Patches welcome!

> Here’s what I see…
> 
> [xx]$ ansible/bin/ansible-playbook site/deploy-servers.yml -K  
> sudo password:  
> Release to deploy?  
> input for release\_version:  
> Who’s your Daddy?  
> input for Daddy:
> 
> Release to deploy?  
> input for release\_version:  
> Who’s your Daddy?  
> input for Daddy:
> 
> A couple other things I have noticed during testing:
> 
> 1. On the client machines, the setup file under .ansible is owned by root (artifact of running through sudo?). I was able to delete it just happily tho as myself after logging into the client directly.

Presumably. If running as sudo we should really use the root setup file location. Someone want to fix this? 🙂

> 1. If the playbook is interrupted for whatever reason, we get stale files under .ansible/tmp. I can clean these out but they may never get noticed otherwise if you didn’t know to look for them.

I am thinking a cleanup module is probably warranted, that could be used at the end of playbooks and such, or on demand.

The async files are also subject to this. This could also be used to cover your tracks in the setup file, maybe?

–Michael

---

<div class="post-metadata">

**Author:** ![Dave\_Coutu](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dave\_Coutu](https://forum.ansible.com/u/Dave_Coutu)\
**Post date:** [April 26, 2012, 7:52pm UTC](https://forum.ansible.com/t/vars-prompt-issues/11459/3 "2012-04-26T19:52:45Z")

</div>

> Hey Folks,
> 
> Running into some odd behavior (currently on the devel branch) with  
> vars\_prompt. What I am seeing are 2 things.
> 
> 1) I get no console echo when inputting the variables that I prompt for.  
> I can't remember if we decided to mask the input of these variable  
> entirely or if there was a way to only mask certain variables we prompt  
> for. For these variables in particular I want to use, it would be good to  
> echo them. The only things we would want to prompt and not echo for would  
> be passwords/passphrases, imo.
> 
> vars\_prompt is ONLY intended for passwords
> 
> Other variables should be version controlled with the PB. We have also  
> talked about reinstating --extra-args, which is going to happen, so a  
> release version you can just pass in on the command line.
> 
> Typing things is kinda against the point of automation, right? 🙂

Ok, confirms the lack of echo, makes perfect sense. However if you are  
going to do that, you might need to prompt twice and do a comparison if  
it's going to set the password for something. If it's going to use the  
password to carry out an auth action, probably not so much.

In the case of doing a version release, I don't think we can't assume that  
people using the PBs have write access to them, as some orgs may have  
separation of privileges and responsibilities. They may only have read and  
hence couldn't modify or submit for version control. This is the problem  
with my current config server at the moment. It controls releases so I  
can't give my engineers the ability to do any deploys as they get much more  
access to things (and the potential to break a lot) if they have write  
access. --extra-args would be totally acceptable 🙂 I also admit, I am  
testing the include of a release file that contains version vars, so I did  
think of that 😉

While I agree that typing things is kinda against the point of automation,  
I'll say what I told my last VP (as he wanted to automate EVERYTHING and  
would have phased out his Systems Engineers if he could, leaving only a  
not-even Junior NOC to run things). Automation for me is one of many  
tools, not an end solution or the only solution. You can't automate  
everything but you strive to automate as much as you can. Some processes  
do require a human at the wheel when dealing in certain markets and  
institutions. Otherwise everyone runs around pointing fingers at each  
other and blaming "the system" when something breaks or doesn't behave  
properly. But it raises an interesting question.. If you extend ansible  
into doing lots of automated tasks on a scheduled basis, you are somewhat  
defeating your security as you are at some point enabling password-less  
sudo on your clients, and potentially passphrase-less SSH keys (or setting  
up an agent once on the overlord that needs to be kept an eye on). I was  
trying to think how one could avoid some of these pitfalls if you really  
wanted to be hands-off. Maybe I'm missing something somewhere, would love  
for someone to shed some light on this for me if anyone can. My logic  
surely isn't fool-proof ;).

> 2) I appear to get prompted twice for the variable input. In the  
> .ansible/setup file that gets created on the client machine, the values  
> entered via the second prompt are the ones present. Again, the only time  
> we would want to prompt twice (and do a comparison against the 2 inputs)  
> would be passwords/passphrases, and if there was a failure, re-prompt.
> 
> The variable name and the prompt should be printed on one line, like this:
> 
> dogs\_out: Who Let The Dogs Out?
> 
> Patches welcome!

Not sure if I follow what you are saying here.. I've got them defined in  
the playbook with that proper syntax. Did you mean something else? In the  
example I gave below (this is output from the playbook run), when you are  
prompted for the vars when running a playbook, you get prompted twice for  
them, and if you enter different input each time, it doesn't complain and  
takes the 2nd input.

> Here's what I see..
> 
> [xx]$ ansible/bin/ansible-playbook site/deploy-servers.yml -K  
> sudo password:  
> Release to deploy?  
> input for release\_version:  
> Who's your Daddy?  
> input for Daddy:
> 
> Release to deploy?  
> input for release\_version:  
> Who's your Daddy?  
> input for Daddy:
> 
> A couple other things I have noticed during testing:
> 
> 1) On the client machines, the setup file under .ansible is owned by root  
> (artifact of running through sudo?). I was able to delete it just happily  
> tho as myself after logging into the client directly.
> 
> Presumably. If running as sudo we should really use the root setup file  
> location. Someone want to fix this? 🙂

Not sure which way to go on that one. I think there are good cases for  
root or the user, but the key thing is to make sure it isn't publicly  
accessible by prying eyes if it contains any sensitive variables in case  
you forget to come up from behind with another playbook to erase the  
sensitive variables in the setup file.

> 2) If the playbook is interrupted for whatever reason, we get stale  
> files under .ansible/tmp. I can clean these out but they may never get  
> noticed otherwise if you didn't know to look for them.
> 
> I am thinking a cleanup module is probably warranted, that could be used  
> at the end of playbooks and such, or on demand.
> 
> The async files are also subject to this. This could also be used to  
> cover your tracks in the setup file, maybe?

That would super cool and addresses the above noted security state :). The  
setup file is definitely useful for troubleshooting/debugging, making sure  
that it contains what you had expected to be in there, but I don't want it  
hanging around if I know I have a good working state. Having it be  
available for a last action in a playbook sounds awesome, and I like the  
idea of having ansible reach out and do a clean on demand.

Thanks Mike!

Dave

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [April 26, 2012, 9:15pm UTC](https://forum.ansible.com/t/vars-prompt-issues/11459/4 "2012-04-26T21:15:09Z")

</div>

> > > Hey Folks,
> > > 
> > > Running into some odd behavior (currently on the devel branch) with vars\_prompt. What I am seeing are 2 things.
> > > 
> > > 1. I get no console echo when inputting the variables that I prompt for. I can’t remember if we decided to mask the input of these variable entirely or if there was a way to only mask certain variables we prompt for. For these variables in particular I want to use, it would be good to echo them. The only things we would want to prompt and not echo for would be passwords/passphrases, imo.
> > 
> > vars\_prompt is ONLY intended for passwords
> > 
> > Other variables should be version controlled with the PB. We have also talked about reinstating --extra-args, which is going to happen, so a release version you can just pass in on the command line.
> > 
> > Typing things is kinda against the point of automation, right? 🙂
> 
> Ok, confirms the lack of echo, makes perfect sense. However if you are going to do that, you might need to prompt twice and do a comparison if it’s going to set the password for something. If it’s going to use the password to carry out an auth action, probably not so much.

It doesn’t store that password anywhere, there is no need for a double prompt.

> In the case of doing a version release, I don’t think we can’t assume that people using the PBs have write access to them, as some orgs may have separation of privileges and responsibilities. They may only have read and hence couldn’t modify or submit for version control. This is the problem with my current config server at the moment. It controls releases so I can’t give my engineers the ability to do any deploys as they get much more access to things (and the potential to break a lot) if they have write access. --extra-args would be totally acceptable 🙂 I also admit, I am testing the include of a release file that contains version vars, so I did think of that 😉

Yes, we’re going with --extra-args.

> > The variable name and the prompt should be printed on one line, like this:
> > 
> > dogs\_out: Who Let The Dogs Out?
> > 
> > Patches welcome!
> 
> Not sure if I follow what you are saying here… I’ve got them defined in the playbook with that proper syntax.

I am referring to what we should change the prompt to look like so it doesn’t occur on two lines, which is confusing. That is all.

> > Presumably. If running as sudo we should really use the root setup file location. Someone want to fix this? 🙂
> 
> Not sure which way to go on that one. I think there are good cases for root or the user, but the key thing is to make sure it isn’t publicly accessible by prying eyes if it contains any sensitive variables in case you forget to come up from behind with another playbook to erase the sensitive variables in the setup file.

I wasn’t asking, actually… I’m stating the way it needs to be.

If the effective user is root in sudo mode we SHOULD use the /etc/ansible/setup setup location, and also look there for template metadata. It won’t affect the desired result at all. It’s an implementation detail.

I’ll just file a ticket on this.

> > > 1. If the playbook is interrupted for whatever reason, we get stale files under .ansible/tmp. I can clean these out but they may never get noticed otherwise if you didn’t know to look for them.
> > 
> > I am thinking a cleanup module is probably warranted, that could be used at the end of playbooks and such, or on demand.
> > 
> > The async files are also subject to this. This could also be used to cover your tracks in the setup file, maybe?
> 
> That would super cool and addresses the above noted security state :). The setup file is definitely useful for troubleshooting/debugging, making sure that it contains what you had expected to be in there, but I don’t want it hanging around if I know I have a good working state. Having it be available for a last action in a playbook sounds awesome, and I like the idea of having ansible reach out and do a clean on demand.

Yep. I’ll file a ticket on this and suggest someone pick it up.

---

<div class="post-metadata">

**Author:** ![Dave\_Coutu](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dave\_Coutu](https://forum.ansible.com/u/Dave_Coutu)\
**Post date:** [April 26, 2012, 9:38pm UTC](https://forum.ansible.com/t/vars-prompt-issues/11459/5 "2012-04-26T21:38:19Z")

</div>

> Ok, confirms the lack of echo, makes perfect sense. However if you are  
> going to do that, you might need to prompt twice and do a comparison if  
> it's going to set the password for something. If it's going to use the  
> password to carry out an auth action, probably not so much.
> 
> It doesn't store that password anywhere, there is no need for a double  
> prompt.

Sorry, should have been more clear on what I was stating. What I meant for  
"set the password for something" is if that variable you prompt for is used  
to set a password or passphrase for something in a system (say for when you  
install spunk and want to change the admin password, setup an encrypted  
partition, etc.) you want to make sure that the password/passphrase that is  
used is what you thought you had typed. Without a local echo, you have no  
idea what you typed and if you don't do a secondary prompt with a compare,  
you don't guarantee you know what was typed. Granted, if it was me, I  
would probably be copying & pasting something that I knew I had typed  
correctly, but it's also possible to copy over whitespace in doing so and  
that mucks things up good too.

I'll file a ticket on the current double prompt for variables. As it is  
now, it only makes the possibility that you type something incorrectly more  
probable. Looks like you or someone else will be fixing how that prompt  
appears on one line so no ticket for that.

Everything else makes sense and sounds great!

Dave

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [April 26, 2012, 9:43pm UTC](https://forum.ansible.com/t/vars-prompt-issues/11459/6 "2012-04-26T21:43:49Z")

</div>

> > > Ok, confirms the lack of echo, makes perfect sense. However if you are going to do that, you might need to prompt twice and do a comparison if it’s going to set the password for something. If it’s going to use the password to carry out an auth action, probably not so much.
> > 
> > It doesn’t store that password anywhere, there is no need for a double prompt.
> 
> Sorry, should have been more clear on what I was stating. What I meant for “set the password for something” is if that variable you prompt for is used to set a password or passphrase for something in a system (say for when you install spunk and want to change the admin password, setup an encrypted partition, etc.) you want to make sure that the password/passphrase that is used is what you thought you had typed. Without a local echo, you have no idea what you typed and if you don’t do a secondary prompt with a compare, you don’t guarantee you know what was typed. Granted, if it was me, I would probably be copying & pasting something that I knew I had typed correctly, but it’s also possible to copy over whitespace in doing so and that mucks things up good too.
> 
> I’ll file a ticket on the current double prompt for variables. As it is now, it only makes the possibility that you type something incorrectly more probable. Looks like you or someone else will be fixing how that prompt appears on one line so no ticket for that.

There’s already a ticket on the prompt, we should just do this together.

---

<div class="post-metadata">

**Author:** ![Dave\_Coutu](https://avatars.discourse-cdn.com/v4/letter/d/57b2e6/32.png) [@Dave\_Coutu](https://forum.ansible.com/u/Dave_Coutu)\
**Post date:** [April 26, 2012, 10:04pm UTC](https://forum.ansible.com/t/vars-prompt-issues/11459/7 "2012-04-26T22:04:12Z")

</div>

> There's already a ticket on the prompt, we should just do this together.

I'll add comments to that ticket then. One other thing needs clarification  
now that I re-read... "It doesn't store that password anywhere, there is  
no need for a double prompt. " What do you mean by doesn't store that  
password anywhere? On the overlord or the client do you mean?

---

<div class="post-metadata">

**Author:** ![Michael\_DeHaan](https://avatars.discourse-cdn.com/v4/letter/m/c4cdca/32.png) [@Michael\_DeHaan](https://forum.ansible.com/u/Michael_DeHaan)\
**Post date:** [April 26, 2012, 10:36pm UTC](https://forum.ansible.com/t/vars-prompt-issues/11459/8 "2012-04-26T22:36:03Z")

</div>

This was based on not understanding you previously.

Disregard.