[Fab-user] Trouble running ad-hoc commands w/o having to re-enter password for each host.

Discussion:

Waldbieser, Carl

2014-08-05 15:16:33 UTC

Sometimes, I want to just run an ad-hoc shell command on multiple hosts that requires elevated privileges. E.g. I might want to grep a couple logs that are not world-readable.

(fabenv)[***@odin fabrications]$ pip freeze
Fabric==1.9.0
ecdsa==0.11
paramiko==1.14.0
pycrypto==2.6.1
wsgiref==0.1.2
(fabenv)[***@odin fabrications]$ type fab
fab is hashed (/home/waldbiec/projects/python/virt_envs/fabenv/bin/fab)
(fabenv)[***@odin fabrications]$ fab -H ldap4,ldap5 -- sudo echo 'a test'
[ldap4] Executing task '<remainder>'
[ldap4] run: sudo echo a test
[ldap4] out: [sudo] password for waldbiec:
[ldap4] out: a test
[ldap4] out:

[ldap5] Executing task '<remainder>'
[ldap5] run: sudo echo a test
[ldap5] out: [sudo] password for waldbiec:
[ldap5] out: a test
[ldap5] out:

Done.
Disconnecting from ldap4... done.
Disconnecting from ldap5... done.
(fabenv)[***@odin fabrications]$

So I had to type my password in 2 times, even though it is the same on each of the 2 servers. Am I doing something wrong?

Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College

Jeff Forcier

2014-08-05 18:24:00 UTC

Permalink

This sounds like the same issue as
https://github.com/fabric/fabric/issues/1130 and I'll add a link to
your mail there once it's in the archives. Thanks! Will be digging
into things for a bugfix release later this week so this regression
should be fixed then.

Best,
Jeff

Post by Waldbieser, Carl
Sometimes, I want to just run an ad-hoc shell command on multiple hosts that requires elevated privileges. E.g. I might want to grep a couple logs that are not world-readable.
Fabric==1.9.0
ecdsa==0.11
paramiko==1.14.0
pycrypto==2.6.1
wsgiref==0.1.2
fab is hashed (/home/waldbiec/projects/python/virt_envs/fabenv/bin/fab)
[ldap4] Executing task '<remainder>'
[ldap4] run: sudo echo a test
[ldap4] out: a test
[ldap5] Executing task '<remainder>'
[ldap5] run: sudo echo a test
[ldap5] out: a test
Done.
Disconnecting from ldap4... done.
Disconnecting from ldap5... done.
So I had to type my password in 2 times, even though it is the same on each of the 2 servers. Am I doing something wrong?
Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College
_______________________________________________
Fab-user mailing list
https://lists.nongnu.org/mailman/listinfo/fab-user

--
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org

Jeff Forcier

2014-08-06 21:34:28 UTC

Permalink

Hi Carl,

I just took a look and cannot replicate the behavior you described -
normal password memory works fine for me on all recent versions of
Fabric. (The other issues I mentioned look like a slightly different
problem.)

Is there anything in your real world scenario that you omitted for
brevity earlier? E.g. are you using the parallel features, modifying
env.passwords, etc? If you can provide your fabfile (it gets loaded
even when running adhoc commands) that might also help us figure out
what's going wrong.

Best,
Jeff

Post by Jeff Forcier
This sounds like the same issue as
https://github.com/fabric/fabric/issues/1130 and I'll add a link to
your mail there once it's in the archives. Thanks! Will be digging
into things for a bugfix release later this week so this regression
should be fixed then.
Best,
Jeff

--
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org

Waldbieser, Carl

2014-08-06 21:47:19 UTC

Permalink

Jeff,

The output was taken verbatim from my workstation.

When you say a fabfile is loaded even when running ad hoc commands-- where would it be loaded from? Â I believe I ran the fab command from my $HOME.

Thanks,
Carl

Jeff Forcier <***@bitprophet.org> wrote:Hi Carl,

I just took a look and cannot replicate the behavior you described -
normal password memory works fine for me on all recent versions of
Fabric. (The other issues I mentioned look like a slightly different
problem.)

Is there anything in your real world scenario that you omitted for
brevity earlier? E.g. are you using the parallel features, modifying
env.passwords, etc? If you can provide your fabfile (it gets loaded
even when running adhoc commands) that might also help us figure out
what's going wrong.

Best,
Jeff

--
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org

Jeff Forcier

2014-08-07 17:17:04 UTC

Permalink

Sorry - I made the assumption you had one for non-adhoc tasks, but
yes, it's possible to run without one. So unless you happened to have
a fabfile.py in your $HOME then that's not a factor at all.

Still - I was unable to replicate the problem on my end, so there's
not a lot I can think of from here. If you feel like debugging a bit,
I'd look at the two subroutines in fabric/auth.py (and/or the spots
they are called within fabric/network.py) to see what's going on.

What *should* be happening is your first password entry ends up
calling set_password(), which should then be updating env.password
(and env.passwords, though that's not as important here). The
subsequent connection ought to be calling get_password() and ending up
with that env.password value instead of prompting you.

Best,
Jeff

Post by Waldbieser, Carl
Jeff,
The output was taken verbatim from my workstation.
When you say a fabfile is loaded even when running ad hoc commands-- where
would it be loaded from? I believe I ran the fab command from my $HOME.
Thanks,
Carl
Hi Carl,
I just took a look and cannot replicate the behavior you described -
normal password memory works fine for me on all recent versions of
Fabric. (The other issues I mentioned look like a slightly different
problem.)
Is there anything in your real world scenario that you omitted for
brevity earlier? E.g. are you using the parallel features, modifying
env.passwords, etc? If you can provide your fabfile (it gets loaded
even when running adhoc commands) that might also help us figure out
what's going wrong.
Best,
Jeff

Post by Waldbieser, Carl
Sometimes, I want to just run an ad-hoc shell command on multiple hosts
that requires elevated privileges. E.g. I might want to grep a couple logs
that are not world-readable.
Fabric==1.9.0
ecdsa==0.11
paramiko==1.14.0
pycrypto==2.6.1
wsgiref==0.1.2
fab is hashed
(/home/waldbiec/projects/python/virt_envs/fabenv/bin/fab)
[ldap4] Executing task '<remainder>'
[ldap4] run: sudo echo a test
[ldap4] out: a test
[ldap5] Executing task '<remainder>'
[ldap5] run: sudo echo a test
[ldap5] out: a test
Done.
Disconnecting from ldap4... done.
Disconnecting from ldap5... done.
So I had to type my password in 2 times, even though it is the same on
each of the 2 servers. Am I doing something wrong?
Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College
_______________________________________________
Fab-user mailing list
https://lists.nongnu.org/mailman/listinfo/fab-user

--
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org

Waldbieser, Carl

2014-08-07 17:24:49 UTC

Permalink

Jeff,

Thanks, for the pointers. I will look into it and let you know what I find out.

Carl

----- Original Message -----
From: "Jeff Forcier" <***@bitprophet.org>
To: "Waldbiec" <***@lafayette.edu>
Cc: "Fabric Mailing List" <fab-***@nongnu.org>
Sent: Thursday, August 7, 2014 1:17:04 PM
Subject: Re: [Fab-user] Trouble running ad-hoc commands w/o having to re-enter password for each host.

Sorry - I made the assumption you had one for non-adhoc tasks, but
yes, it's possible to run without one. So unless you happened to have
a fabfile.py in your $HOME then that's not a factor at all.

Still - I was unable to replicate the problem on my end, so there's
not a lot I can think of from here. If you feel like debugging a bit,
I'd look at the two subroutines in fabric/auth.py (and/or the spots
they are called within fabric/network.py) to see what's going on.

What *should* be happening is your first password entry ends up
calling set_password(), which should then be updating env.password
(and env.passwords, though that's not as important here). The
subsequent connection ought to be calling get_password() and ending up
with that env.password value instead of prompting you.

Best,
Jeff

Post by Waldbieser, Carl
Sometimes, I want to just run an ad-hoc shell command on multiple hosts
that requires elevated privileges. E.g. I might want to grep a couple logs
that are not world-readable.
Fabric==1.9.0
ecdsa==0.11
paramiko==1.14.0
pycrypto==2.6.1
wsgiref==0.1.2
fab is hashed
(/home/waldbiec/projects/python/virt_envs/fabenv/bin/fab)
[ldap4] Executing task '<remainder>'
[ldap4] run: sudo echo a test
[ldap4] out: a test
[ldap5] Executing task '<remainder>'
[ldap5] run: sudo echo a test
[ldap5] out: a test
Done.
Disconnecting from ldap4... done.
Disconnecting from ldap5... done.
So I had to type my password in 2 times, even though it is the same on
each of the 2 servers. Am I doing something wrong?
Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College
_______________________________________________
Fab-user mailing list
https://lists.nongnu.org/mailman/listinfo/fab-user

--
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org

Waldbieser, Carl

2014-08-07 20:30:29 UTC

Permalink

Jeff,

I think I traced the problem to a spot in io.py around line 156 in the method "loop()".
By the time the statement:

prompt = _endswith(self.capture, env.sudo_prompt)

is executed, self.capture contains "Sorry, try again.\n".

That may be because if I shell into the server and enter an incorrect password, it looks like this:

[***@ldap4 PROD ~]$ sudo echo "hello"
[sudo] password for waldbiec:
Sorry, try again.
[sudo] password for waldbiec:
^C

Thanks,
Carl

----- Original Message -----
From: "Jeff Forcier" <***@bitprophet.org>
To: "Waldbiec" <***@lafayette.edu>
Cc: "Fabric Mailing List" <fab-***@nongnu.org>
Sent: Thursday, August 7, 2014 1:17:04 PM
Subject: Re: [Fab-user] Trouble running ad-hoc commands w/o having to re-enter password for each host.

Sorry - I made the assumption you had one for non-adhoc tasks, but
yes, it's possible to run without one. So unless you happened to have
a fabfile.py in your $HOME then that's not a factor at all.

Still - I was unable to replicate the problem on my end, so there's
not a lot I can think of from here. If you feel like debugging a bit,
I'd look at the two subroutines in fabric/auth.py (and/or the spots
they are called within fabric/network.py) to see what's going on.

What *should* be happening is your first password entry ends up
calling set_password(), which should then be updating env.password
(and env.passwords, though that's not as important here). The
subsequent connection ought to be calling get_password() and ending up
with that env.password value instead of prompting you.

Best,
Jeff

Post by Waldbieser, Carl
Sometimes, I want to just run an ad-hoc shell command on multiple hosts
that requires elevated privileges. E.g. I might want to grep a couple logs
that are not world-readable.
Fabric==1.9.0
ecdsa==0.11
paramiko==1.14.0
pycrypto==2.6.1
wsgiref==0.1.2
fab is hashed
(/home/waldbiec/projects/python/virt_envs/fabenv/bin/fab)
[ldap4] Executing task '<remainder>'
[ldap4] run: sudo echo a test
[ldap4] out: a test
[ldap5] Executing task '<remainder>'
[ldap5] run: sudo echo a test
[ldap5] out: a test
Done.
Disconnecting from ldap4... done.
Disconnecting from ldap5... done.
So I had to type my password in 2 times, even though it is the same on
each of the 2 servers. Am I doing something wrong?
Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College
_______________________________________________
Fab-user mailing list
https://lists.nongnu.org/mailman/listinfo/fab-user

--
Jeff Forcier
Unix sysadmin; Python/Ruby engineer
http://bitprophet.org

Carlos García

2014-08-05 16:29:11 UTC

Permalink

I also had experienced that annoyance.

The simplest way to avoid it, it's to write a task like this one in your
fabfile:

@task
def execute(command):
sudo(command)

And use it:

fab -H ldap4,ldap5 execute:"echo 'a test'"

This way you just need to type your sudo password once, as fabric will
cache it.

Hope it works

Regards
--
Carlos GarcÃa
Director de Operaciones
Tel. 695 624 167 - 902 620 100
www.stoneworksolutions.net

AVISO DE CONFIDENCIALIDAD
Tanto este mensaje como todos los posibles documentos adjuntos al mismo son
confidenciales y estÃ¡n dirigidos exclusivamente a los destinatarios de los
mismos. Por favor, si Ud no es uno de dichos destinatarios, notifÃquenos
este hecho y elimine el mensaje de su sistema. Queda prohibida la copia,
difusiÃ³n o revelaciÃ³n de su contenido a terceros sin el previo
consentimiento por escrito del remitente. En caso contrario, vulnerarÃ¡n la
legislaciÃ³n vigente