Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

Optionally avoid using ssh if going to localhost #98

Open
bitprophet opened this Issue · 42 comments
@bitprophet
Owner

Description

run()/sudo() would intelligently see that you're going to localhost and just run local() instead. This would probably be an optional thing.

Comments from Jeff on IRC:

and yea, I mean there's always going to be overhead with ssh vs straight pipes offhand I don't think it would be terrifically difficult to update run/sudo (especially in master now that they've been refactored) to call/return local() intelligently I'm not positive that I'd want that semi magical behavior in core (even with it off by default with an optin to enable it, tho that would help) but even so, it'd be an interesting experiment. and if it is as simple as I'm thinking I honestly can't come up with a good reason not to (again provided it is not the default behavior)

Originally submitted by Nick Welch (mackstann) on 2009-11-11 at 01:39pm EST

Relations

  • Duplicated by #364: Allow for local operation to bypass SSH layer
  • Related to #26: Implement "dry run" feature
@bitprophet bitprophet was assigned
@bitprophet
Owner

James Pearson (xiong.chiamiov) posted:


As also mentioned on irc, I don't normally run ssh server on a desktop machine, so I can't actually ssh to localhost.


on 2009-11-11 at 03:13pm EST

@bitprophet
Owner

Travis Swicegood (tswicegood) posted:


I've just implemented something similar this evening in the form of a new fabric.operations function called do. It looks at env.run_as to see if it equals "local", and in doing so switches out to the local method instead of the run (or sudo if sudo=True is passed in as a kwarg). It also handles prefixing local commands with sudo in the event they're running local.

This is sort of a different way around this problem which works without changing the behavior of run or sudo. These changes are available in my repository.


on 2010-01-11 at 12:22am EST

@bitprophet
Owner

Morgan Goose (goosemo) posted:


I really don't see this being plausible. What's the point in doing run as local. One of the requirements of Fabric is sshd running on the machine, remote or loopback. The other problem being that only changing local doesn't take into account put, get, rsync_project, and others that would all still need ssh. Trying to implement those, would just really cause more issues, since it's now in the realm of making fabfiles translate to bash.


on 2011-03-13 at 11:14pm EDT

@bitprophet
Owner

Jeff Forcier (bitprophet) posted:


While I'm also not 100% convinced this is a great idea, it's clearly something a number of users feel the need for -- another request has been lodged as #364 with another explanation of the use case.

I've also added the dry-run ticket as related to this one, because (I assume -- if any of the requesting users can verify this that'd be great) the main use case for this feature is for testing/dry-running.


on 2011-06-23 at 11:26am EDT

@bitprophet
Owner

As noted in #538, if we're ever able to fully normalize the three runners so they can be used interchangeably, we'll need to make sure that shell escaping works consistently across them. Right now we don't shell escape local, though that's at least partly because it's not using a shell wrapper.

@jordanambra

If anyone is wondering "why would anyone do this?", the answer is that if you have a deployment pipeline, it can be helpful to run the same exact deployment script, no matter which environment, rather than having a special setup script for localhost vs. everything else.

@brodul

+1 for the feature

@domguard

+10

@Spaxe

+1

@hangtwenty

+1

To hold you over, you can just make sure you have the OpenSSH server running. First do sudo apt-get install ssh to make sure you have it installed (even if you think you do). Then do sudo service ssh start|stop|restart as needed. Learned from this thread.

@andresriancho

+1

My use case is simple: I want to use the same django-deploy script to configure ec2 instances both with cloud-init through CloudWatch (the case for running local commands) and using the regular fab deploy_django -H foo@bar.

@jstasiak

+1

This would be really useful. One use case I have is using vagrant shell provisioner to configure particular vm using fabric and without the need to ssh localhost.

@grjones

+1

I was surprised not to see this in Fabric already.

@andresriancho

FYI: Implementation of this feature gets more complex when you think about fabric functions like reboot().

@kunitoki

+1

Should be part of core already !

@alb-i986

+1

It would perfectly make sense: from an abstract point of view, local is just a special case of run, where no SSH machinery is involved.

One more thing to point out (maybe obvious): Fabric should be smart enough to decide if a run should be converted to local AFTER reading /etc/hosts.

I mean: if we have

env.host = [ 'mywebserver' ]

and in /etc/hosts we have:

127.0.0.1 mywebserver

then, any run calls should actually be local calls.

Taking this concept a step further, we should also treat run as a local call when the remote host resolves to an IP which is assigned to a network interface of the local machine.
E.g.:
fabfile:

env.host = [ 'mywebserver' ]

/etc/hosts:

192.168.1.1 mywebserver

ip addr:

[...]
eth0:
  inet 192.168.1.1
[...]
@xarg

Fabric 2 will use pyinvoke/invoke so this should be pretty easy to do there. I would wait for Fabric 2 for a non-hacky way to do this.

@sbward

+1

@onceuponatimeforever

:+1: Please implement this, especially as mac computers aren't automatically set up to have SSH tunnels configured for remote access to the localhost server.

@dtbog

+1 :)

@tolbkni

+1 please

@graingert

We're using Fab to build debian packages and this adds extra complexity

@Friz-zy

guys, hello all
i try to create clone of fabric with difference:

  • run() function works in the same way with subprocess.popen under localhost as under ssh connect to remote host
  • Factory uses openssh or any another ssh client (you should modified config for this), so you can use all power of ssh sockets
  • Factory uses gevent library for asynchronous executing

You can take a look if you need this feature
https://github.com/Friz-zy/factory

@AntoniosHadji

I may be missing something in this discussion, but here is what I did to use the same code with fab run command on both localhost and remote machines.

  1. I set env.use_ssh_config = True in my fabfile.py
  2. ssh-copy-id localhost

This doesn`t solve your issue if you are not running ssh server on your local machine

@laike9m

+1

@gerardohuck

+1 Please implement this feature :)

@cgarciaarano

+1

Could be very useful to bootstrap Docker images using existing Fabric scripts. This feature would avoid to install an SSH server on the container, which is against the Docker best practices

@F481

+1

@sbilly

+1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.