Re: rsync server over SSH [includes code patches]
On Tue, 18 Dec 2001, Martin Pool wrote:
On 4 Dec 2001, JD Paul [EMAIL PROTECTED] wrote:
Here's a new version of my rsync-server-over-remote-shell patch:
This looks good. My main reservation is that it makes it even harder
to explain how rsync works, but I think the increase in flexibility
justifies it.
I certainly understand that concern! (I'm sure I'm not the only one
who sometimes thinks that it would be better to split rsync into
several different programs [even if they were the same binary] with
different semantics to make things clearer -- all using the same rsync
engine under the hood.)
I'd like to get some of the smaller patches in to stabilize 2.5 before
we do this.
Sounds good to me.
P.S. Question -- is the enum { } of all the OPT_ variables in
options.c necessary any more? It looks like it's not.
Why? They're used to link from long_options to the cases in
parse_arguments(). Some of them might be obsolete now, but it doesn't
seem worthwhile to take them out.
I don't know how I missed that. I must have been writing late at
night. :-)
JD
Re: rsync server over SSH [includes code patches]
On 4 Dec 2001, JD Paul [EMAIL PROTECTED] wrote:
Here's a new version of my rsync-server-over-remote-shell patch:
This looks good. My main reservation is that it makes it even harder
to explain how rsync works, but I think the increase in flexibility
justifies it.
I'd like to get some of the smaller patches in to stabilize 2.5 before
we do this.
P.S. Question -- is the enum { } of all the OPT_ variables in
options.c necessary any more? It looks like it's not.
Why? They're used to link from long_options to the cases in
parse_arguments(). Some of them might be obsolete now, but it doesn't
seem worthwhile to take them out.
--
Martin
Re: rsync server over SSH [includes code patches]
On Thu, Nov 29, 2001 at 09:11:58AM +1100, Martin Pool wrote: ... 1. remove AC_FUNC_MEMCMP from configure.in because it causes Sunos 4.1.4 to die. memcmp() there fails the 8-bit clean test, but it doesn't matter because memcmp() in rsync is only used to test if something is equal or not equal, not to compare if it is less or greater. What breaks if we leave it in? Is memcmp a compiler intrinsic or something like that? No objection to taking it out, I'm just curious. It says don't know how to build memcmp.o. The configure rule only adds memcmp.o to $LIBOBJS, which was not used before. AC_FUNC_MEMCMP has always been in configure.in but before now it has been ignored because @LIBOBJS@ was not used in Makefile.in now and that was the only thing it affected. I think it is, isn't it? LIBOBJS = ... @LIBOBJS@, etc. It is now, but it wasn't a week ago. See http://pserver.samba.org/cgi-bin/cvsweb/rsync/Makefile.in.diff?r1=1.55r2=1.56f=h - Dave
Re: rsync server over SSH [includes code patches]
sun/amdahl/unixware patch All these are applied now. I changed the library routines to just include rsync.h -- Martin
Re: rsync server over SSH [includes code patches]
Hi -- Sorry for the delay getting back to you; Thanksgiving holiday intervened and I'm only now catching up on my email backlog 1. You're entirely right about the --remote-user option. I'll remove that. 2. I'll merge with the latest version from CVS. 3. I'll do that; I prefer -u myself. That's better. I read over the patch a little more closely this time and have a few more comments: 1. The --remote-user option is unnecessary because you can instead specify '-e ssh -l user'. 2. Please post the patch again against the latest development version of rsync out of CVS (http://www.samba.org/samba/cvs.html or rsync://rsync.samba.org/ftp/unpacked/rsync/) because that's the form it will need to be in order to get it in. I'll test it out then and look at it closely. 3. Please post the next patch with GNU diff's -u option. It's easier to read. - Dave Dykstra
Re: rsync server over SSH [includes code patches]
Actually, my patch already has that in rsync_module():
if (is_a_socket(f_in)) {
addr = client_addr(f_in);
host = client_name(f_in);
} else {
char *ssh_client = getenv(SSH_CLIENT);
addr = ssh_client ? ssh_client : n/a;
host = remote shell connection;
}
The problem is that I was only looking at string usages of SSH_CLIENT
(debugging mostly) rather than allow_access() use. That shouldn't be
hard to fix; we just need to truncate a copy of the SSH_CLIENT string
at the first whitespace. I'll see if I can get that into the next
version of my patch.
JD
On Mon, 26 Nov 2001, Martin Pool wrote:
On 25 Nov 2001, Jeremy Hansen [EMAIL PROTECTED] wrote:
Ok, I have the patch working, things seems to work except that using hosts
allow in the rsyncd.conf seems to break things.
What an interesting bug. :-)
The proximate connection to the rsync server will be from the sshd
process which is running on the server host, so stdin will probably be
a unix-domain socket. In other words because rsync is not directly
connected to the client, it can't use the usual mechanism to find the
client's address.
Perhaps we can get rsync to look at $SSH_CLIENT, which contains the
necessary information. We need to think carefully to make sure this
is secure though.
--
Martin
Re: rsync server over SSH [includes code patches]
On 27 Nov 2001, Dave Dykstra [EMAIL PROTECTED] wrote: 2.4.7 isn't released yet. Martin has put a lot of changes in the last week into CVS, and when I tried it yesterday it didn't compile anywhere but Linux. Today it looks a bit better but I still have problems on all my platforms except Linux Sgi. Anyway, the point is that it's probably better for you to wait until he does make a release to save yourself some work because it isn't done changing. Martin, the problem on all my platforms is that it can't find AF_INET6 when compiling lib/inet_pton.c (I compile on the oldest releases of each type that are still in active use so I can rely on upward compatibility; for example, it works on Solaris 7 but not Solaris 5.5.1). Yes, the IPv6 patch which was supposed to not break anything unless --enabled actually turned out to break most things aside from BSD/Linux, and I have been gradually trying to sort out their header files. Other good news is that make check now seems to work on most platforms, except for Redhat/Insure++ which generates some apparently spurious warnings. AF_INET6 __P(()) Thanks, I know about those two. I'm going to try to fix them today. I'm not sure if you've seen this: http://build.samba.org:80/build.pl?tree=rsyncfunction=Recent+Builds It's a pretty good tool, since I don't have direct access to (for example) a CRAY. The downside is that it requires changes to be checked in to HEAD for them to be tested. It's not easy being green! That's a simple fix, but going beyond that getaddrinfo.c has a problem because __P isn't defined. __P is an idiom for handling old compilers that can't cope with ANSI prototypes. We don't support them, so I just need to get rid of it. -- Martin
Re: rsync server over SSH [includes code patches]
Can someone tell me why this, and other patches on the list are failing
for me. I have a feeling I'm applying these diffs incorrectly for some
reason.
Thanks
-jeremy
On Tue, 20 Nov 2001, JD Paul wrote:
Hi --
I've made the changes to my code changes and the new diffs (against
2.4.6 again) are included below.
Syntax for running rsync server over a remote shell (e.g. ssh) is now:
rsync [options] -e ssh source [user@]host::module[/dest]
rsync [options] -e ssh [user@]host::module[/source] dest
Cheers --
JD
[EMAIL PROTECTED]
On Tue, 20 Nov 2001, JD Paul wrote:
On Tue, 20 Nov 2001, Dave Dykstra wrote:
I'm uncomfortable with adding yet another syntax. I'd prefer just keying
off the -e when the two colons are used. Currently -e is ignored if
you use two colons, so we don't need to worry about upward compatibility
except from people who had no idea what they were doing.
That's a very good point. In my thinking about syntax, I was somewhat
misled by the standard practice at my site -- we habitually use
RSYNC_RSH=ssh in the environment instead of '-e ssh' (so I tend to
forget about that option).
I'll get rid of the ':::' (as much as I'm fond of it) and re-submit
the diffs; that change won't take much. It'll probably take more time
to modify the man page than the code...
-cut here--
Index: authenticate.c
===
RCS file: /juno/repository/usr/local/pkg/rsync/authenticate.c,v
retrieving revision 1.1.1.4
retrieving revision 1.3
diff -c -b -r1.1.1.4 -r1.3
*** authenticate.c2001/10/19 04:10:00 1.1.1.4
--- authenticate.c2001/10/24 22:00:38 1.3
***
*** 202,208
otherwise return username
*/
! char *auth_server(int fd, int module, char *addr, char *leader)
{
char *users = lp_auth_users(module);
char challenge[16];
--- 202,208
otherwise return username
*/
! char *auth_server(int f_in, int f_out, int module, char *addr, char *leader)
{
char *users = lp_auth_users(module);
char challenge[16];
***
*** 221,229
base64_encode(challenge, 16, b64_challenge);
! io_printf(fd,%s%s\n, leader, b64_challenge);
! if (!read_line(fd, line, sizeof(line)-1)) {
return NULL;
}
--- 221,229
base64_encode(challenge, 16, b64_challenge);
! io_printf(f_out,%s%s\n, leader, b64_challenge);
! if (!read_line(f_in, line, sizeof(line)-1)) {
return NULL;
}
Index: clientserver.c
===
RCS file: /juno/repository/usr/local/pkg/rsync/clientserver.c,v
retrieving revision 1.1.1.4
retrieving revision 1.5
diff -c -b -r1.1.1.4 -r1.5
*** clientserver.c2001/10/19 04:09:27 1.1.1.4
--- clientserver.c2001/11/21 03:37:30 1.5
***
*** 29,48
int start_socket_client(char *host, char *path, int argc, char *argv[])
{
! int fd, i;
! char *sargs[MAX_ARGS];
! int sargc=0;
! char line[MAXPATHLEN];
char *p, *user=NULL;
- extern int remote_version;
- extern int am_sender;
extern struct in_addr socket_address;
-
- if (argc == 0 !am_sender) {
- extern int list_only;
- list_only = 1;
- }
if (*path == '/') {
rprintf(FERROR,ERROR: The remote path must start with a module
name\n);
return -1;
--- 29,42
int start_socket_client(char *host, char *path, int argc, char *argv[])
{
! int fd;
! int ret;
char *p, *user=NULL;
extern struct in_addr socket_address;
+ /* this is redundant with code in start_inband_exchange(), but
+this short-circuits a problem before we open a socket, and
+the extra check won't hurt */
if (*path == '/') {
rprintf(FERROR,ERROR: The remote path must start with a module
name\n);
return -1;
***
*** 55,68
*p = 0;
}
- if (!user) user = getenv(USER);
- if (!user) user = getenv(LOGNAME);
-
fd = open_socket_out(host, rsync_port, socket_address);
if (fd == -1) {
exit_cleanup(RERR_SOCKETIO);
}
server_options(sargs,sargc);
sargs[sargc++] = .;
--- 49,96
*p = 0;
}
fd = open_socket_out(host, rsync_port, socket_address);
if (fd == -1) {
exit_cleanup(RERR_SOCKETIO);
}
+ ret = start_inband_exchange(user, path, fd, fd, argc, argv);
+
+ return (ret 0 ) ? ret : client_run(fd, fd, -1, argc, argv);
+ }
+
+ int
Re: rsync server over SSH [includes code patches]
Actually, right now I'm just a rej on main.c cali:/usr/src/redhat/SOURCES/rsync-2.4.6# patch -p0 ../rsync-ssh-over-daemon.patch patching file `authenticate.c' patching file `clientserver.c' patching file `main.c' Hunk #2 FAILED at 166. Hunk #8 FAILED at 763. 2 out of 8 hunks FAILED -- saving rejects to main.c.rej Possibly this patch is against CVS HEAD. So you can either build against CVS (more useful, possibly more exciting), or try to integrate the rejected changes yourself by opening main.c in an editor and trying to insert the corresponding changes at the right place. If you use emacs you might like to use emerge. See http://cvs.samba.org/ for instructions on getting an anonymous cvs checkout. -- Martin
Re: rsync server over SSH [includes code patches]
On Mon, 26 Nov 2001, Martin Pool wrote: Actually, right now I'm just a rej on main.c cali:/usr/src/redhat/SOURCES/rsync-2.4.6# patch -p0 ../rsync-ssh-over-daemon.patch patching file `authenticate.c' patching file `clientserver.c' patching file `main.c' Hunk #2 FAILED at 166. Hunk #8 FAILED at 763. 2 out of 8 hunks FAILED -- saving rejects to main.c.rej Possibly this patch is against CVS HEAD. So you can either build against CVS (more useful, possibly more exciting), or try to integrate the rejected changes yourself by opening main.c in an editor and trying to insert the corresponding changes at the right place. If you use emacs you might like to use emerge. See http://cvs.samba.org/ for instructions on getting an anonymous cvs checkout. Actually, that bombs pretty bad: cali:~/rsync/rsync# patch -p0 ../rsync-ssh-over-daemon.patch patching file `authenticate.c' Hunk #1 succeeded at 203 (offset 1 line). patching file `clientserver.c' Hunk #1 FAILED at 29. Hunk #2 FAILED at 49. Hunk #3 succeeded at 120 (offset 20 lines). Hunk #4 FAILED at 132. Hunk #5 succeeded at 138 with fuzz 1 (offset 8 lines). Hunk #6 succeeded at 173 with fuzz 1 (offset 20 lines). Hunk #7 FAILED at 241. Hunk #8 FAILED at 251. Hunk #9 FAILED at 275. Hunk #10 FAILED at 297. Hunk #11 succeeded at 390 with fuzz 2 (offset 24 lines). Hunk #12 succeeded at 407 (offset 29 lines). Hunk #13 succeeded at 423 with fuzz 1 (offset 28 lines). Hunk #14 succeeded at 455 (offset 29 lines). Hunk #15 succeeded at 514 (offset 28 lines). 7 out of 15 hunks FAILED -- saving rejects to clientserver.c.rej patching file `main.c' Hunk #1 FAILED at 126. Hunk #2 FAILED at 166. Hunk #3 FAILED at 558. Hunk #4 succeeded at 656 (offset 71 lines). Hunk #5 succeeded at 615 with fuzz 1 (offset 2 lines). Hunk #6 succeeded at 740 (offset 76 lines). Hunk #7 succeeded at 766 with fuzz 2 (offset 25 lines). Hunk #8 FAILED at 788. 4 out of 8 hunks FAILED -- saving rejects to main.c.rej patching file `options.c' Hunk #1 FAILED at 53. Hunk #2 succeeded at 91 with fuzz 1 (offset 6 lines). Hunk #3 succeeded at 149 (offset 43 lines). Hunk #4 succeeded at 175 (offset 6 lines). Hunk #5 succeeded at 242 with fuzz 2 (offset 49 lines). Hunk #6 FAILED at 303. Hunk #7 FAILED at 626. Hunk #8 succeeded at 496 (offset -134 lines). 3 out of 8 hunks FAILED -- saving rejects to options.c.rej patching file `proto.h' Hunk #1 succeeded at 1 with fuzz 1. Hunk #2 succeeded at 37 (offset 20 lines). Hunk #3 succeeded at 153 with fuzz 2 (offset 6 lines). patching file `rsync.1' Hunk #1 FAILED at 1. Hunk #7 succeeded at 637 with fuzz 2 (offset 11 lines). Hunk #8 succeeded at 783 (offset 2 lines). 1 out of 8 hunks FAILED -- saving rejects to rsync.1.rej patching file `socket.c' Hunk #1 succeeded at 305 with fuzz 1 (offset 83 lines). Hunk #2 FAILED at 355. 1 out of 2 hunks FAILED -- saving rejects to socket.c.rej so it's probably not again cvs. I'll try and hand patch it. THanks -jeremy -- The trouble with being poor is that it takes up all your time.
Re: rsync server over SSH [includes code patches]
Ok, I have the patch working, things seems to work except that using hosts allow in the rsyncd.conf seems to break things. Nov 25 17:39:24 rio sshd[26919]: Accepted password for jeremy from 12.162.2.10 port 61876 ssh2 Nov 25 17:39:24 rio PAM_unix[26919]: (sshd) session opened for user jeremy by (uid=0) Nov 25 17:39:24 rio rsyncd[26920]: reverse name lookup failed Nov 25 17:39:24 rio rsyncd[26920]: rsync denied on module test from unknown (4.0.0.0) Nov 25 17:39:24 rio PAM_unix[26919]: (sshd) session closed for user jeremy With out hosts allow, I see: Nov 25 17:40:04 rio PAM_unix[27040]: (sshd) session opened for user jeremy by (uid=0) Nov 25 17:40:04 rio rsyncd[27059]: reverse name lookup failed Nov 25 17:40:04 rio rsyncd[27059]: rsync allowed access on module test from UNKNOWN (4.0.0.0) Nov 25 17:40:04 rio rsyncd[27059]: rsync on test/testfile from UNKNOWN (4.0.0.0) Nov 25 17:40:04 rio rsyncd[27059]: wrote 71 bytes read 75 bytes total size 3 Nov 25 17:40:04 rio PAM_unix[27040]: (sshd) session closed for user jeremy It doesn't seem to be able to resolve for some reason. Any ideas on this? -jeremy On Sun, 25 Nov 2001, Jeremy Hansen wrote: On Mon, 26 Nov 2001, Martin Pool wrote: Actually, right now I'm just a rej on main.c cali:/usr/src/redhat/SOURCES/rsync-2.4.6# patch -p0 ../rsync-ssh-over-daemon.patch patching file `authenticate.c' patching file `clientserver.c' patching file `main.c' Hunk #2 FAILED at 166. Hunk #8 FAILED at 763. 2 out of 8 hunks FAILED -- saving rejects to main.c.rej Possibly this patch is against CVS HEAD. So you can either build against CVS (more useful, possibly more exciting), or try to integrate the rejected changes yourself by opening main.c in an editor and trying to insert the corresponding changes at the right place. If you use emacs you might like to use emerge. See http://cvs.samba.org/ for instructions on getting an anonymous cvs checkout. Actually, that bombs pretty bad: cali:~/rsync/rsync# patch -p0 ../rsync-ssh-over-daemon.patch patching file `authenticate.c' Hunk #1 succeeded at 203 (offset 1 line). patching file `clientserver.c' Hunk #1 FAILED at 29. Hunk #2 FAILED at 49. Hunk #3 succeeded at 120 (offset 20 lines). Hunk #4 FAILED at 132. Hunk #5 succeeded at 138 with fuzz 1 (offset 8 lines). Hunk #6 succeeded at 173 with fuzz 1 (offset 20 lines). Hunk #7 FAILED at 241. Hunk #8 FAILED at 251. Hunk #9 FAILED at 275. Hunk #10 FAILED at 297. Hunk #11 succeeded at 390 with fuzz 2 (offset 24 lines). Hunk #12 succeeded at 407 (offset 29 lines). Hunk #13 succeeded at 423 with fuzz 1 (offset 28 lines). Hunk #14 succeeded at 455 (offset 29 lines). Hunk #15 succeeded at 514 (offset 28 lines). 7 out of 15 hunks FAILED -- saving rejects to clientserver.c.rej patching file `main.c' Hunk #1 FAILED at 126. Hunk #2 FAILED at 166. Hunk #3 FAILED at 558. Hunk #4 succeeded at 656 (offset 71 lines). Hunk #5 succeeded at 615 with fuzz 1 (offset 2 lines). Hunk #6 succeeded at 740 (offset 76 lines). Hunk #7 succeeded at 766 with fuzz 2 (offset 25 lines). Hunk #8 FAILED at 788. 4 out of 8 hunks FAILED -- saving rejects to main.c.rej patching file `options.c' Hunk #1 FAILED at 53. Hunk #2 succeeded at 91 with fuzz 1 (offset 6 lines). Hunk #3 succeeded at 149 (offset 43 lines). Hunk #4 succeeded at 175 (offset 6 lines). Hunk #5 succeeded at 242 with fuzz 2 (offset 49 lines). Hunk #6 FAILED at 303. Hunk #7 FAILED at 626. Hunk #8 succeeded at 496 (offset -134 lines). 3 out of 8 hunks FAILED -- saving rejects to options.c.rej patching file `proto.h' Hunk #1 succeeded at 1 with fuzz 1. Hunk #2 succeeded at 37 (offset 20 lines). Hunk #3 succeeded at 153 with fuzz 2 (offset 6 lines). patching file `rsync.1' Hunk #1 FAILED at 1. Hunk #7 succeeded at 637 with fuzz 2 (offset 11 lines). Hunk #8 succeeded at 783 (offset 2 lines). 1 out of 8 hunks FAILED -- saving rejects to rsync.1.rej patching file `socket.c' Hunk #1 succeeded at 305 with fuzz 1 (offset 83 lines). Hunk #2 FAILED at 355. 1 out of 2 hunks FAILED -- saving rejects to socket.c.rej so it's probably not again cvs. I'll try and hand patch it. THanks -jeremy -- The trouble with being poor is that it takes up all your time.
Re: rsync server over SSH [includes code patches]
On 25 Nov 2001, Jeremy Hansen [EMAIL PROTECTED] wrote: Can someone tell me why this, and other patches on the list are failing for me. I have a feeling I'm applying these diffs incorrectly for some reason. What error do you get when you try to apply them? You probably want something like patch -p0 ~/rsync.diff -- Martin
Re: rsync server over SSH [includes code patches]
On Tue, 20 Nov 2001, Dave Dykstra wrote: rsync [options] -e ssh source [...] [user@]host:::module[/path] rsync [options] -e ssh [user@]host:::module[/path] dest I'm uncomfortable with adding yet another syntax. I'd prefer just keying off the -e when the two colons are used. Currently -e is ignored if you use two colons, so we don't need to worry about upward compatibility except from people who had no idea what they were doing. I see that your change works even with the default rsh transport, but if people really want that they can say '-e rsh'. That's a very good point. In my thinking about syntax, I was somewhat misled by the standard practice at my site -- we habitually use RSYNC_RSH=ssh in the environment instead of '-e ssh' (so I tend to forget about that option). I'll get rid of the ':::' (as much as I'm fond of it) and re-submit the diffs; that change won't take much. It'll probably take more time to modify the man page than the code... Thanks! JD [EMAIL PROTECTED]
