Hi Chris,

On Thu, Aug 12, 2010 at 11:44 AM, Shenton, Chris (HQ-LM020)[InDyne,
Inc] <chris.shen...@nasa.gov> wrote:
> I'm a fabric newbie so perhaps not using it right.  I'm trying to use sudo() 
> and setting the user= parameter to postgres or other applications users.  It 
> appears to want to source MY own ~/.bash_profile, which generates harmless 
> but annoying errors.

This is because the actual command run, by default, is something like:

    /bin/bash -l -c "sudo -u postgres \"some command here\""

So /bin/bash is invoked by the connecting user, and since the -l
(login) flag is given, that's why it sources your Bash startup files.

You can modify env.shell to remove the -l flag to address that
specific issue; see http://docs.fabfile.org/0.9.1/usage/env.html#shell
for details.

(BTW, you can see exactly what is being passed down the line for all
your commands by specifying --show=debug or setting output.debug=True.
This will show the bash wrapper if it's enabled, as well as any
escaping being done.

> If I say use the shell=False parameter it fail when it automatically tries to 
> change to MY own home directory.

This is simply how SSH works; commands invoked directly assume a
starting working directory of the connecting user's homedir. I'm not
aware of any way to change this offhand.

> Having no shell also prevents actions like 'cd' and 'source' from working, 
> which I need to activate virtual environments.

That actually wouldn't work even with the shell wrapper on; each run()
or sudo() command is its own session. (Think of them like individual
invocations of "ssh myserver <command>".)

To keep state you need to perform tricks such as prefixing each
command with "cd <somewhere> && <actual command>". Fabric has some of
these build in, such as "with cd():", which I see you've already found
-- there's a more generic "with prefix():" coming in the next release
or two, too.

> The first example's doing postgres and things actually work OK here, because 
> it doesn't need to be in any particular directory. But I'd like to get rid of 
> the distracting error messages:

As mentioned, most of the messages are because it's a login shell by
default. Removing the -l will hopefully fix both of them.

> The second example's doing django in a virtual env and the first works (with 
> an annoying error msg) but the second one fails since the 'source' command is 
> not available without a shell:

See above! :)

> Perhaps I'm being naive, but I would think that if sudo() specifies a "user=" 
> parameter that on the remote server it should change to the directory of the 
> specified user and set HOME to it before executing the command, like
>
>  sudo -H -u username pwd
>
> would do.

An interesting idea. I'm not sure I'd want that to be the default, for
a handful of reasons, but one of the nice things about Fabric being
pure Python is that you can easily define your own higher level
wrapper functions, like those in fabric.contrib.

So you could write your own sudo function (either shadowing the
builtin or with a tweaked name) and use that pretty easily (especially
once we add more dependency injection, e.g. allowing you to pass in
the "runner" to use for high level stuff like contrib.files.append()).

And if others find it useful there's a chance it could be added to
core as another function argument, or a standalone function in
contrib.

Hope that all helps!

Best,
Jeff

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

_______________________________________________
Fab-user mailing list
Fab-user@nongnu.org
http://lists.nongnu.org/mailman/listinfo/fab-user

Reply via email to