Re: rsync and packet filters

2001-02-20 Thread tim . conway

You're fine.  As long as port 22 is open, you're good to go.  All traffic will be 
encapsulated inside the ssh connection, which is from some non-privileged port on the 
calling machine and port 22 on the server with sshd.

Tim Conway
[EMAIL PROTECTED]
303.682.4917
Philips Semiconductor - Colorado TC
1880 Industrial Circle
Suite D
Longmont, CO 80501





[EMAIL PROTECTED]@[EMAIL PROTECTED] on 02/20/2001 01:58:32 PM
Sent by:[EMAIL PROTECTED]
To: [EMAIL PROTECTED]@SMTP
cc:  
Subject:rsync and packet filters
Classification: 

I'm having a problem with rsync while running on a machine that uses packet
filters (FreeBSD)... I presume this is because I need to permit out/in the
primary port that rsync uses -- but I'm not sure if it routes all traffic
through that port number or if it then uses unprivileged ports after
initial connection.

What port(s) should be opened?

This is being used as:

rsync -avz -e ssh some.machine.com:/usr/local/apache/ /local/machine


Thanks.








Re: rsync and packet filters

2001-02-20 Thread tim . conway

They're in roots path when you're logged in.  Remote command execution is subtly 
different from remote login.
I suspect that if you ssh some.machine.com rsync --help, you'll find that rsync isn't 
found from a non-interactive shell.  Commonly, remote command execution acts as a 
login shell if invoked interactively, but with only the system path, if invoked as a 
remote command.  That means, it doesn't run your .login, .profile, whatever your 
system uses. When you ssh in, then do "which rsync", you initialized a shell to get to 
a shell prompt, so your initializations have happenned.

try the flag --rsync-path=wherever it is on the other end to specify the actual 
location.


Tim Conway
[EMAIL PROTECTED]
303.682.4917
Philips Semiconductor - Colorado TC
1880 Industrial Circle
Suite D
Longmont, CO 80501





[EMAIL PROTECTED]@[EMAIL PROTECTED] on 02/20/2001 03:11:32 PM
Sent by:[EMAIL PROTECTED]
To: Tim Conway/LMT/SC/PHILIPS@AMEC
cc: [EMAIL PROTECTED]@SMTP 
Subject:Re: rsync and packet filters
Classification: 

But I'm getting this error:

rsync -avz -e ssh some.machine.com:/usr/local/apache/ /local5/machine
sh: rsync: not found
unexpected EOF in read_timeout

Same happens on another machine, which is running packet filters.

But the odd thing is that rsync and ssh are all in root's $PATH, as
evidenced by 'which'.

The client machine "some.machine.com" is not running packet filters.


_F

At 03:59 PM 2/20/2001 -0600, [EMAIL PROTECTED] wrote:
You're fine.  As long as port 22 is open, you're good to go.  All traffic
will be encapsulated inside the ssh connection, which is from some
non-privileged port on the calling machine and port 22 on the server with sshd.

Tim Conway
[EMAIL PROTECTED]
303.682.4917
Philips Semiconductor - Colorado TC
1880 Industrial Circle
Suite D
Longmont, CO 80501





[EMAIL PROTECTED]@[EMAIL PROTECTED] on 02/20/2001 01:58:32 PM
Sent by:[EMAIL PROTECTED]
To: [EMAIL PROTECTED]@SMTP
cc:
Subject:rsync and packet filters
Classification:

I'm having a problem with rsync while running on a machine that uses packet
filters (FreeBSD)... I presume this is because I need to permit out/in the
primary port that rsync uses -- but I'm not sure if it routes all traffic
through that port number or if it then uses unprivileged ports after
initial connection.

What port(s) should be opened?

This is being used as:

rsync -avz -e ssh some.machine.com:/usr/local/apache/ /local/machine


Thanks.








IPv6 rsync URLs

2001-02-20 Thread Martin Pool

Perhaps this is already discussed by the IPv6 proposed patches.  I
personally haven't looked at them in detail yet, but it seems like it
would be nice to merge in support.

The major problem is that IPv6 literal addresses include '.' and ':'
as delimiters, which conflicts with the historical usage of those in
URLs.  RFC2732 suggests that IPv6 literal addresses should be
encapsulated in square brackets, such as

  http://[FEDC:BA98:7654:3210:FEDC:BA98:7654:3210]:80/index.html
  http://[1080:0:0:0:8:800:200C:417A]/index.html
  http://[3ffe:2a00:100:7031::1]

I think this should work well for both rsync URL syntax:

  rsync rsync://[FEDC:BA98:7654::3210]:8763/foo

and scp-style syntax:

  rsync -auvz mbp@[::1]:.mutt* .

I think we'll have to strip away the brackets before passing this to
ssh or rsh.  I guess the user should do RSYNC_RSH='ssh -6' if that's
what they want.

Interesting...
-- 
Martin Pool, Human Resource
Linuxcare. Inc.   +61 2 6262 8990
[EMAIL PROTECTED], http://linuxcare.com.au/
Linuxcare.  Putting Open Source to work.