patch: alternate ssh port
David Lowry
At my site we're thinking of running SSH on an alternate port for
slack to connect to. As far as I can tell, the only way to specify
the port for rsync is to change the -e option to something like: -e
'ssh -p 1111'
I've created a small patch that allows the user to specify either a --
ssh-port or -p option to slack or a SSH_PORT directive in the config
file. I've attached it in case somebody else has the same need.
David
PS Alan, really good job on the way you handle options and the config
file. I only had to add the option in one place to get it picked up
by both the option parser and the config file parser. It's a lot more
fun to work with well-written code. :-)
Alan Sundell
Another way to do this is to just put it in ~root/.ssh/config.
e.g. mine says:
Host slack-master
User slack
IdentityFile /etc/ssh/ssh_host_rsa_key
...and you could add a "Port" directive.
Also, I wonder if instead of just doing SSH_PORT, it would be better
to let people completely override the entire ssh command. IOW, to
have an option just like rsync's -e/--rsh option.
Previously, I was worried about having to do space splitting, but now
that I look at your patch I see we end up passing the value to rsync
as a single string, anyway, so no worries there.
What do you think?
--Alan
PS Thanks for the compliment :) However, that's probably the only
remotely good feature of the code :/ Wish I could get around to doing
some cleanups...
David Lowry
Alan Sundell
> When you change the configuration to connect to slack-master:slack, it works
> fine, even though the slack code doesn't add the
> "-e ssh." I guess rsync is somehow figuring out that you mean ssh. Of
> course, I may not quite understand the way slack and/or rsync is supposed to
> handle ssh.
Thanks for bringing this up. I made some changes to the slack.conf
manpage to explain this better. Here's the text (modified a bit to
work better not in nroff):
SOURCE can be in one of four forms:
* /path/to/dir
Use a local directory.
* somehost:/path/to/dir
Use given directory on a remote host via rsync over SSH.
* rsync://somehost/module
Use module on a remote rsyncd server (directly over the
network).
* somehost::module
Use the rsync daemon protocol over SSH to the given
host. See "USING RSYNC-DAEMON FEATURES VIA A
REMOTE-SHELL CONNECTION" in rsync (1)
All forms of SOURCE are passed directly to rsync, so you can
do things like add "user@" before the host on any remote
forms. For more about what rsync can do, see its manual
page, of course.
For the last form, however, we do a little magic. rsync
treats the last two forms equivalently, so we overload the
last form by automatically passing "-e ssh" to rsync when we
see it. This hack lets us tell slack to use this nice
feature of rsync just using the SOURCE config option.
> My suggestion would be to remove the auto-detection code and only add the -e
> option to rsync if the rsh-command is defined. The biggest disadvantage is
> that this change isn't backwards compatible.
Yeah, I kind of don't like it, but would like to maintain backwards
compatibility.
I also still kind of dig the original justification of being able to
do handle the simple case simply. I was thinking of imitating svn and
using a URL syntax like rsync+ssh://
Eventually, it would be nice to:
1) have slack-getroles use slack-sync for transport for remote role
lists, so that only slack-sync needs to know about these things
2) add support for more transports to slack-sync. For example, we
might be able to cook up something for http:// using wget. Or at the
very least, http+tgz://. I think someone asked for this once (it's in
the TODO, anyway).
--Alan
David Lowry
On Jun 16, 2007, at 12:21 AM, Alan Sundell wrote:
>
> On 6/14/07, David Lowry <dlo...@bju.edu> wrote:
>> When you change the configuration to connect to slack-
>> master:slack, it works
>> fine, even though the slack code doesn't add the
>> "-e ssh." I guess rsync is somehow figuring out that you mean ssh. Of
>> course, I may not quite understand the way slack and/or rsync is
>> supposed to
>> handle ssh.
>
> Thanks for bringing this up. I made some changes to the slack.conf
> manpage to explain this better. Here's the text (modified a bit to
> work better not in nroff):
>
> [...]
>
> All forms of SOURCE are passed directly to rsync, so you can
> do things like add "user@" before the host on any remote
> forms. For more about what rsync can do, see its manual
> page, of course.
>
> For the last form, however, we do a little magic. rsync
> treats the last two forms equivalently, so we overload the
> last form by automatically passing "-e ssh" to rsync when we
> see it. This hack lets us tell slack to use this nice
> feature of rsync just using the SOURCE config option.
That's a really kind way of saying: "You should have looked in the
rsync man page." :-) Even if that's not what you meant, I should
have. :-) Thanks for clearing it up.
>> My suggestion would be to remove the auto-detection code and only
>> add the -e
>> option to rsync if the rsh-command is defined. The biggest
>> disadvantage is
>> that this change isn't backwards compatible.
>
> Yeah, I kind of don't like it, but would like to maintain backwards
> compatibility.
> I also still kind of dig the original justification of being able to
> do handle the simple case simply. I was thinking of imitating svn and
> using a URL syntax like rsync+ssh://
Now that I understand why you're doing it, I think I'll modify my
suggestion:
1) Leave the auto detection code. With the explanation you added, I
think it should be clear how slack handles "::"
2) Add the "Port" option to the FAQ that tells how to set up ssh, but
comment it out. That should help keep dense people like me from
messing with perfectly good code. :-)
3) If you think there's a need to mess with the rsh command of rsync,
add the attached patch. I modified my original changes to now offer
an -e or --rsh option to pass to rsync. Other than the ssh port, I
can't think of a reason for needing it, but I imagine there's
somebody out there with a special case.