env.passwords doesn't work

[henryon]

Recently, I use fab to deploy some middleware or run some command on remote server. but even if I specified the env.password(s)。 when I run the fab, still prompt me to provide the password.

any ideas or suggestion?

The code like below

import sys,os,time
from fabric.api import *
from fabric.api import local,output
output['output']=True
import fabric
import logging

logging.basicConfig(level=logging.DEBUG)
def host(str=''):
    if str == '-':
        list = _to_list(sys.stdin)
    else:
        list =  str.split('\n')
    env.hosts = _to_hosts(list)
    print env.hosts
    #print "Here OOOOOOO"
    env.passwords = _to_passwords(list)
    #netifs = _to_netifs(list)
    print env.passwords



def _to_list(handle):
    list = []
    while True:
        line = handle.readline().strip()
        print line
        if line:
            list.append(line)
        else:
            return list

def _to_hosts(list):
    hosts = []
    for line in list:
        kvp = line.split('|')
        hosts.append(kvp[1])
    return hosts

def _to_passwords(list):
    passwords = {}
    for line in list:
        kvp = line.split('|')
        passwords[kvp[1]] = kvp[2]
    return passwords
# '''
#def  new_user(username,admin='no',comment="No comment provided"):
#   log_action("New User (%s): %s" % (username,comment))
#   pass
def exists(path):
    with settings(warn_only=True):
        return  run('test -e %s ' % path)

def hello(name="world!"):
    print("Hello %s! " % name)
        run("uname -r",pty=False,combine_stderr=True)

when I run the fab as below the prompt information as below.

root@MyUbuntu:~/test# grep 160.171 server.db |fab host:-  hello
eth0|10.250.160.171|ABC|test

['10.250.160.171']
{'10.250.160.171': 'ABC'}
[10.250.160.171] Executing task 'hello'
Hello world!! 
[10.250.160.171] run: uname -r
DEBUG:paramiko.transport:starting thread (client mode): 0x436768d0L
INFO:paramiko.transport:Connected (version 2.0, client OpenSSH_5.3)
DEBUG:paramiko.transport:kex algos:['diffie-hellman-group-exchange-sha256', 'diffie-hellman-group-exchange-sha1', 'diffie-hellman-group14-sha1', 'diffie-hellman-group1-sha1'] server key:['ssh-rsa', 'ssh-dss'] client encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-cbc@lysator.liu.se'] server encrypt:['aes128-ctr', 'aes192-ctr', 'aes256-ctr', 'arcfour256', 'arcfour128', 'aes128-cbc', '3des-cbc', 'blowfish-cbc', 'cast128-cbc', 'aes192-cbc', 'aes256-cbc', 'arcfour', 'rijndael-cbc@lysator.liu.se'] client mac:['hmac-md5', 'hmac-sha1', 'umac-64@openssh.com', 'hmac-sha2-256', 'hmac-sha2-512', 'hmac-ripemd160', 'hmac-ripemd160@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] server mac:['hmac-md5', 'hmac-sha1', 'umac-64@openssh.com', 'hmac-sha2-256', 'hmac-sha2-512', 'hmac-ripemd160', 'hmac-ripemd160@openssh.com', 'hmac-sha1-96', 'hmac-md5-96'] client compress:['none', 'zlib@openssh.com'] server compress:['none', 'zlib@openssh.com'] client lang:[''] server lang:[''] kex follows?False
DEBUG:paramiko.transport:Ciphers agreed: local=aes128-ctr, remote=aes128-ctr
DEBUG:paramiko.transport:using kex diffie-hellman-group1-sha1; server key type ssh-rsa; cipher: local aes128-ctr, remote aes128-ctr; mac: local hmac-sha1, remote hmac-sha1; compression: local none, remote none
DEBUG:paramiko.transport:Switch to new keys ...
DEBUG:paramiko.transport:Trying discovered key 865642cf225227d9781b12554e2ce4d9 in /root/.ssh/id_rsa
DEBUG:paramiko.transport:userauth is OK
I
[10.250.160.171] Login password for 'root': DEBUG:paramiko.transport:EOF in transport thread

[bitprophet]

#1159 also seems to imply the same thing. I'll have to try and duplicate locally - thanks for the report!

[bitprophet]

And now a report from the mailing list: http://lists.nongnu.org/archive/html/fab-user/2014-08/msg00006.html - clearly something regressed here.

[bitprophet]

I cannot recreate this on any branch via the following:

• create two users, testuser and testuser2 with the same password, on a local vm of mine
• fab -H testuser@vm2,testuser2@vm2 -- whoami
• Enter password at 1st prompt
• Watch it run the 2nd instance of the task w/o prompting me

So password memory is not wholly broken, at least (which is what the ML post implied). Checking over the two tickets in more detail, they're both setting env.passwords manually so it's probably getting cleared out incorrectly or something.

EDIT: Looks like this is just yet another case of host strings being horrible hacks - neither user seems to be editing env.passwords with fully qualified host strings, which is the format it uses. If I do the same thing - e.g. set env.passwords = {'testuser@vm2': 'pass', ...} - I also encounter prompts...because I didn't do env.passwords = {'testuser@vm2:22': 'pass'}.

There's no real way to "fix" this besides educating users about the need to be fully explicit. And then releasing Fab 2 that doesn't use host strings :) Will ensure the docs have a clear warning about this...

[henryon]

l've fixed this issue by 'root'@ip:port not sure whether the document of description not updated?

[dean]

@bitprophet I think it's completely obscure to require explicit ports here when they are inferred (if not explicitly provided) almost everywhere else. Would it be possible to just infer a default when a port isn't explicitly provided?