env.port not honored if host string lacks port specification #138

Closed
bitprophet opened this Issue Aug 19, 2011 · 8 comments

Projects

None yet

2 participants

@bitprophet
Member

Description

User sm0ke in IRC says he had a problem where his remote system had a nonstandard SSH port, and his use of env.port was ignored -- only specifying the port number in the host string worked.

I seem to recall this being fixed before but don't see a ticket, so check this out -- it's quite possible it's slipped by due to my usual emphasis on host strings over env vars.


Originally submitted by Jeff Forcier (bitprophet) on 2010-02-05 at 09:11am EST

Relations

  • Duplicated by #313: setting port in .fabricrc won't work
  • Related to #4: Allow for storing/using metadata about hosts
@bitprophet bitprophet was assigned Aug 19, 2011
@bitprophet
Member

Erich Heine (sophacles) posted:


This is because everything in operations does this:

connections[env.host_string]

There is never any checking against env.host, env.port, and env.user. This propagates to HostConnectionCache where all opers are done based on normalize(key). This is probaly best fixed by some sort of function: get_host_from_env or something, which returns the requested stuff, prioritizing env.host et. al over env.host_string. (or whatever order of ops is desired).

Possibly even a get_connection_from_env would work...


on 2010-02-06 at 01:36pm EST

@bitprophet
Member

Jeff Forcier (bitprophet) posted:


Yea, that would do it.

The more I think on it, though, the more I think this may be best solved by jumping straight to something that solves #4 -- a global "use this port" only makes sense in the "connecting to one and only one server" scenario, and is often ineffective or doesn't map well to multi-host setups.

Put another way -- having per-host metadata with, perhaps, some 'default' specification (hello class inheritance?) would solve this problem by just making things more flexible and less confusing.


on 2010-02-07 at 04:25pm EST

@bitprophet
Member

Erich Heine (sophacles) posted:


Some initial work re my previous comment: http://github.com/sophacles/fabric/tree/bug138

Not sure what else would be needed to get everything happy.

Edit: Ok, I did that before I noticed Jeff had made his comment above. Since the work was already done, might as well keep it for reference ;)


on 2010-02-07 at 04:57pm EST

@bitprophet
Member

Fábio M. Costa (fabiomcosta) posted:


I'm having this same problem. My server receives ssh connections on port 2222 (not the default one).
Do you have any updates on this? How can i set another port to be used by fabric?
Thanks


on 2010-05-14 at 04:34pm EDT

@bitprophet
Member

Jeff Forcier (bitprophet) posted:


Fabio, you can still specify the port in your host strings, e.g. env.hosts = ['hostname:2222'] or @hosts('hostname:2222'). See the usage docs for more info.

The only thing broken right now is that writing to env.port doesn't work correctly, but since you can specify full host strings everywhere, it's not usually a serious problem. (Otherwise I would've opted to fix it sooner instead of deciding to possibly wait for a more wide-ranging solution.)


on 2010-05-14 at 07:15pm EDT

@bitprophet
Member

Mikhail Korobov (kmike) posted:


The only thing broken right now is that writing to env.port doesn’t work correctly, but since you can specify full host strings everywhere, it’s not usually a serious problem.

env.user is still broken too and this causes some headaches:

from fabric.api import *

def host1():
    env.hosts = ['example.com']
    env.user = 'user1'
    puts('host1 was executed')

def host2():
    env.hosts = ['example2.com']
    env.user = 'user2'
    puts('host2 was executed')

def user():
    puts("%s, %s" % (env.hosts, env.user))

# make host1 default
host1()

and then:

(my_env)> fab user
host1 was executed
[example.com] Executing task 'user'
[example.com] ['example.com'], user1

Done.
(my_env)> fab host2 user
host1 was executed
[example.com] Executing task 'host2'
[example.com] host2 was executed
[example2.com] Executing task 'user'
[example2.com] ['example2.com'], user1

Done.

It seems that env.user and env.port are now working reliably only for information purposes and shouldn't be manipulated directly. Fabric is from the latest git checkout.


on 2011-02-10 at 01:13pm EST

@pjotrp
pjotrp commented Dec 20, 2011

When using a name that does not resolve by DNS, but in /etc/hosts, such as localhost, fabric will not honour it. Using the IP address works. I am putting this here, as I was using a different port, and spent ages looking at the wrong problem.

Not OK:

fab -H biolinux@localhost:2222 -f ./../fabfile.py -c ./../contrib/minimal/fabricrc_debian.txt install_biolinux:packagelist=./../contrib/minimal/main.yaml,environment=biolinux-test

OK:

fab -H biolinux@127.0.0.1:2222 -f ./../fabfile.py -c ./../contrib/minimal/fabricrc_debian.txt install_biolinux:packagelist=./../contrib/minimal/main.yaml,environment=biolinux-test

@bitprophet
Member

As part of #3 I found it useful to make env.port more fully-fledged, so it will now be able to be used to set a default port number that isn't 22. My earlier concerns about it "not mapping well" don't make a lot of sense in hindsight.

I'll close this ticket when that stuff is merged.

@bitprophet bitprophet added a commit that referenced this issue Feb 3, 2012
@bitprophet bitprophet Tweaks to env.port re #138 re #3 7b46e66
@bitprophet bitprophet added a commit that referenced this issue Feb 3, 2012
@bitprophet bitprophet Changelog re #138, fixes #138 830fb62
@bitprophet bitprophet closed this in 830fb62 Feb 3, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment