Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Currently several of the ssh calls assume everyones system is pretty vanilla. I've got to work with a hosting provider that puts ssh on port 100.
Here's a patch that allows me to define additional options to be used when rsync or sql sync needs to talk to that host.
Config addition looks like:
$options['site-aliases']['remote.host.uri'] = array (
'label' => 'Staging Server',
'uri' => 'remote.host.uri',
'root' => '/var/www/drupal6',
'remote-host' => '1.2.3.4',
'remote-user' => 'dan',
'ssh-options' => "-p 100", # <-- HERE is the additional option
'db-url' => 'mysqli://dbuser:dbpass@localhost/drupal6_multisite',
);
You can also define alternate identity files, auth options, or ssh tunneling oddities using this.
Attached patch passes these options through the relevant site settings used by _drush_sql_sync()and eventually to drush_core_call_rsync() in the $options.
In the main, rsync allows all the same options as ssh, and in the current code drush_core_call_rsync uses the -e ssh invocation anyway.
It touches the bit that used to say
$dump_exec = "ssh $source_remote_user...
and it's now
$dump_exec = "ssh $source_remote_ssh_options $source_remote_user...
or
$exec = "rsync -e 'ssh $ssh_options' $mode$options $source $destination";
There is a potential for confusion for conflating these options if both your source and target aliases are remote. ... but that isn't supported anyway, so it's a non-existent edge case.
It does not validate that the options you define are valid syntax, but that's your problem. It allows just a string, not any key-val options array because it's hardly worth it.
I added a paragraph to example.drushrc.php to document it.
| Comment | File | Size | Author |
|---|---|---|---|
| drush_sync-support_additional_ssh_connection_options-20100116.patch | 5.44 KB | dman |
Comments
Comment #1
dman commentedOK, I see some similarity with #671542: Backend invoke shouldn't always insist on prohibiting password authentication!
This is doing the same thing, but from the site-aliases end, and used as a setting for the sync commands.
The other issue only does (exactly the same thing) as a commandline option for backend it seems.
... we even used the same label and syntax for our independent versions, so it must be intuative and wanted :-)
Comment #2
moshe weitzman commentedI'll also note that I have been using my .ssh/config file to store stuff like alternate port. We may or may not want to trun drush into a full ssh config tool. I don't know.
Comment #3
dman commentedIMO, these options are per-host, per-targets, so I put these options into the site-aliases array, where it defines things I need to know about the deployment target.
I've got too many environments to be doing this in my ~/.ssh/config , plus maybe I'll be setting up a daemon or cron to do this someday. At least I want my co-developers to use the tool the same way I do.
And it's a handy place to refer to when I need to remember how to get at a host to sync up months later.
Comment #4
greg.1.anderson commentedHm, dman does make a good point that it is easier to share a drushrc file than .ssh/config. However, it is possible to have ssh config options apply per-host, so .ssh/config is actually more efficient (terse) than site aliases, because you can have multiple drupal sites per host. That would require duplicating your ssh config options in every site definition if you use site aliases, but you would only need one definition per host if you use .ssh/config.
I've opened up #671542: Backend invoke shouldn't always insist on prohibiting password authentication for consideration. I propose that we -either- back out ssh-options as shown in the patch there and mark this issue as "won't fix", -or- (visa-versa) commit this patch and mark the other "won't fix". If we don't take out ssh-options, I have a comment or two for this patch, but I'll put that off until a decision is reached on 671542.
Comment #5
dman commentedFair comment.
I'm in favor of the visibility, portability, share-abilty and back-up-ability (and implicit documentation) of putting it in site-aliases,
but there's certainly also a case to me made for me to get more familiar with tweaking my ssh/config file. ... and write some docs to let other co-developers who come after me do to to ... on each machine ... for each account ...
Open for discussion...
Comment #6
moshe weitzman commentedI've thought about this a bit and I think it is OK to commit once greg's upcoming comments are addressed. Teams of devs will be sharing drushrc.php and it is handy to bake in stuff like port number rather than having each team member do that on his machine.
Comment #7
moshe weitzman commentedI think we should commit this patch after Greg's comments are provided and incorporated. I've marked #671542-11: Backend invoke shouldn't always insist on prohibiting password authentication as Won't Fix.
Comment #8
dman commentedSo what would the comments be?
Please don't let it be about white-space or similar.
Useful suggestions that contain less characters than just making the actual changes they suggest will be received gracefully.
Comment #9
greg.1.anderson commentedAm I really that bad? ;) Often, the issue with change requests is not the number of characters required to make them, but in testing the change afterwards. I rather like the project management conventions used in drush, even when I'm on the receiving end of minor requests. In an open-source project, the best time to get it right is before the first commit. Enough of that, though.
It was regrettable that I was too lazy to put my comments in #4 above, because now I cannot remember them, even after re-reviewing the patch. There doesn't seem to be any way to remove the PasswordAuthentication=no with this variant. That doesn't bother me, though -- tested and committed. If it turns out that I was wrong and there are more issues, then in deference to dman's request in #8, I will gladly make them my problem & re-open this issue.
Comment #10
dman commented:-B
I was just groaning out load about how patches sometimes get dragged out, eating up brain-cycles from (at least) two competent contributors over things like array-wrapping or the right kind of quote. ... when the requested change could be done in a minute, but talking about it makes the cycle take days. Not pointing any fingers at individuals at all, in fact I've screened them out of my mind, and it's not about drush, just issue queues in general. Nothing personal.
Actual code, we can indeed test and review etc. I just was hoping that this months-old suggestion wasn't being held up for lack of a full-stop in a comment or something :-) . The foreshadowing was cryptic.
Seeing as it isn't - ALL COOL!