Gracefully fail when env.use_ssh_config == True but there is no config file #587

Closed
rbp opened this Issue Mar 13, 2012 · 4 comments

Projects

None yet

2 participants

@rbp
rbp commented Mar 13, 2012

If env.use_ssh_config is True, Fabric tries to load the env.ssh_config_path. However, if that is not set, or if the config file is not present, fabric aborts.

It would be very handy to be have env.use_ssh_config gracefully fall back to returning an empty dict when there is no config file available, just like ssh would behave (i.e., use config file if available, otherwise carry on with defaults).

If this makes sense, I'll be glad to provide a patch (even if it turns out not to be as trivial as it seems).

Owner

I think that's fine, but it should at least emit a warning of some kind, the reason it fails hard right now is that use_ssh_config is off by default, so the assumption is if it's on the user is expecting it to successfully load a file. Silent failure in that scenario would be bad.

rbp commented Mar 14, 2012

Fair enough. Although the use case I bumped into was: we're using Fabric to automate a build/deploy system that a few different people can trigger (on the command-line or via Jenkins), and some of these people require ~/.ssh/config to be read (because they use different keys for different hosts), and some don't (because they use a single key that's used by default). Doesn't seem to be so far fetched.

Anyway, I'll write a small patch and do a pull request a bit later today. Thanks!

Owner

While it's a relatively crude method, you might want to experiment with setting use_ssh_config to False again globally, and have the users that need it create a ~/.fabricrc containing use_ssh_config = yes (technically that'll set it to "yes" but that's still a true value and Fabric's 'rcfile' only allows for strings, sigh...).

It's been a while but I believe that will correctly activate the setting for those users. Worth trying, especially since it could eliminate the discussed warning that some of your users would have to see every time.

Owner

Ironically I got bit by this myself just recently in a very similar situation to @rbp. Don't see a PR but AFAICT all we need to do is change the abort to a warn -- I am not sure why it was an abort to begin with. Doing this now.

@kelvan kelvan pushed a commit to kelvan/freieit that referenced this issue Jun 16, 2015
gregor tags fixtures. fabfile updateindex createsuper. fab fix missing confi…
…g bug see fabric/fabric#587
64b8541
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment