Problems with rsync server over ssh client
I'm trying to use ssh on the client side, mainly because I want to authenticate rsync clients using LDAP. I'm having issues. It seems when I use --rsh=ssh -l username, that the rsync server is ignore my rsyncd.conf uid and gid directives. My goal is to create a dropbox repository for files where a user can basically rsync a file to another allow on the rsync server and allow rsync to handle changing overship on that rsync. For example: rsync foo.txt -av --rsh=ssh -l joeuser [EMAIL PROTECTED]::repository/ And my rsyncd.conf looks like this: uid = root gid = root syslog facility = local5 pid file = /var/run/rsyncd.pid [repository] path = /home/janeuser/dropbox comment = Jane User Dropbox auth users = joeuser janeuser read only = false uid = janeuser gid = janeuser use choot = yes When I use ssh, I get a permission denied on entering /home/janeuser/dropbox as if its ignoring my uid and gid directives in the module. Like I said, if I don't use ssh and I use a secrets file, this works as it should but I really need to be able to authenticate against existing system users that are using ldap for their authentication. Thanks -jeremy -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
Re: Problems with rsync server over ssh client
On 2/3/05 2:56 PM, Wayne Davison [EMAIL PROTECTED] wrote: On Thu, Feb 03, 2005 at 02:01:28PM -0800, Jeremy Hansen wrote: use --rsh=ssh -l username, that the rsync server is ignore my rsyncd.conf uid and gid directives. Correct. Normal users don't have unix permissions to change to another user, so rsync assumes that if you're not root (UID 0), you can't setuid(). If you're trying to limit what remote hosts can connect, the best solution is probably to go back to using a daemon and adding a hosts allow value of 127.0.0.1 so that the only connections it allows are from localhost. Then, your remote users would use ssh to tunnel into the machine and connect: ssh -fN -L 8873:localhost:873 -l joeuser filedrop rsync -av foo.txt --port 8873 localhost::repository/ (If you connect via ssh1, dump the -N option and specify a sleep 30 command.) All the users on the same remote machine can make use of the port-8873 connection to filedrop's port 873. If instead you were trying to provide different permissions to different users based on who they logged in as via ssh, you'll need to come up with something custom for that. For instance, if you created a wrapper program that would only execute a hard-wired rsync command based on the who the current user was, you could set the setuid bit on the executable, and it would then run rsync with root permissions. Whether that would be secure enough for your system depends on how you feel about setuid-bit programs and also on how well you code up the exec logic (making sure that it can't try to run arbitrary programs, for instance). It sounds as if I need some kind of wrapper. Host based filtering isn't my issue. I need to allow users to upload files to other users and I need those uploaded files to have the correct ownership of whoever the files are being given to. I understand now that using the --rsh=ssh -l user command just spawns an rsync session as whatever -l user is, therefore the degraded permissions. I see from the archives that someone wrote an ldap patch, which seems as if it would work well for my situation. Thanks -jeremy ..wayne.. -- To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
problem uploading to an rsync server
For some reason I'm having a problem uploading to an rsync server: [root@csa i386]# rsync -azvv --progress --stats /home/www/www.blah.com/* blah@localhost::test/ Password: building file list ... done ERROR: module is read only unexpected EOF in read_timeout It claims my module is read only, but it is not: [test] uid = root gid = root path = /home/www/www.blah.com-test comment = this is a test auth users = blah secrets file = /etc/rsyncd.secrets It's set to localhost because this is going over an stunnel. Yes, I did try it without the stunnel and same results. How can I debug this. This is 2.4.6 on both sides because 2.5.0 just fails completely for uploading and downloading. Thanks -jeremy -- .o--0O0--o.
Re: problem uploading to an rsync server
These are two redhat machines, running 6.2. server side error in systlog: Dec 5 12:11:25 geo rsyncd[15335]: rsync to test/ from [EMAIL PROTECTED] (192.168.0.50) Dec 5 12:11:25 geo rsyncd[15335]: transfer interrupted (code 1) at main.c(401) This is the error not going over stunnel. Thanks -jeremy On Wed, 5 Dec 2001, Jeremy Hansen wrote: For some reason I'm having a problem uploading to an rsync server: [root@csa i386]# rsync -azvv --progress --stats /home/www/www.blah.com/* blah@localhost::test/ Password: building file list ... done ERROR: module is read only unexpected EOF in read_timeout It claims my module is read only, but it is not: [test] uid = root gid = root path = /home/www/www.blah.com-test comment = this is a test auth users = blah secrets file = /etc/rsyncd.secrets It's set to localhost because this is going over an stunnel. Yes, I did try it without the stunnel and same results. How can I debug this. This is 2.4.6 on both sides because 2.5.0 just fails completely for uploading and downloading. Thanks -jeremy -- .o--0O0--o.
Re: {rsync} problem uploading to an rsync server
AHH, thank you very much! -jeremy On Wed, 5 Dec 2001, M. Drew Streib wrote: On Wed, Dec 05, 2001 at 03:05:19PM -0500, Jeremy Hansen wrote: It claims my module is read only, but it is not: [test] uid = root gid = root path = /home/www/www.blah.com-test comment = this is a test auth users = blah secrets file = /etc/rsyncd.secrets from the man page for rsyncd.conf: read only The read only option determines whether clients will be able to upload files or not. If read only is true then any attempted uploads will fail. If read only is false then uploads will be possible if file permissions on the server allow them. The default is for all modules to be read only. Note that read only is the default. You'll need to explicitly set read only to false if you want the module to be writeable. -drew -- .o--0O0--o.
Re: problem with 2.4.7pre4
Linux. Other files are ok, even files that are simular in size, I have a 700meg file that seems ok. I'm aware of the 2 gig limit, but these files aren't close to 2gigs. Note that I get very bad behavior with 2.4.7pre4, it doesn't even attempt to copy, 2.4.6 just seems to fail at the end. -jeremy On Thu, 29 Nov 2001, Dave Dykstra wrote: What operating system? Can you copy smaller files OK? I think the limit for 32 bits is 2GB so you shouldn't be running into that. - Dave Dykstra On Thu, Nov 29, 2001 at 02:24:14PM -0500, Jeremy Hansen wrote: yOn Thu, 29 Nov 2001, Jeremy Hansen wrote: rsync: connection unexpectedly closed (0 bytes read so far) rsync error: error in rsync protocol data stream (code 12) at io.c(139) Just a note here, if I move the rsync server back to 2.4.6, I'm at least able to initiate an actual copy. 2.4.7pre4 just fails right away with the above. Also, on 2.4.6 I was getting this: access_log write failed on access_log : Success unexpected EOF in read_timeout THis is about an 800meg file I'm trying to copy. Thanks -jeremy -- The trouble with being poor is that it takes up all your time. -- The trouble with being poor is that it takes up all your time.
Re: problem with 2.4.7pre4
On Fri, 30 Nov 2001, Martin Pool wrote: On 29 Nov 2001, Jeremy Hansen [EMAIL PROTECTED] wrote: Linux. By the way when reporting bugs like this it is good to give a more specific description, like RedHat 7.1 on x86. Sorry. This is a Red Hat 6.2 machine. 2.2.19 kernel. Both ends are the same. Other files are ok, even files that are simular in size, I have a 700meg file that seems ok. I'm aware of the 2 gig limit, but these files aren't close to 2gigs. Note that I get very bad behavior with 2.4.7pre4, it doesn't even attempt to copy, 2.4.6 just seems to fail at the end. 2.4.7 should not have a 2GB limit unless the underlying OS does. On Linux this means that you need a moderately recent version of both the kernel (2.4?) and C library. If you have that, despite running on a mostly-32-bit processor it should work properly. rsync --version will tell you whether rsync *thinks* it can handle big files, but it's possible that they will still fail. access_log write failed on access_log : Success unexpected EOF in read_timeout That error often means the ssh connection is failing. The server is running rsyncd and client connections are going over an stunnel. The daemon is actually running using DJB's ucspi-tcp/daemontools/supervise. Here is the command line of the server: exec envuidgid root \ tcpserver -DRUvX -x /etc/tcpcontrol/rsyncd.cdb 0 rsync rsync -vvv --daemon Can you please post the exact command you're running and the rsyncd configuration file? Here is the command line of the client: rsync -avz --progress rsync://localhost/apache_logs/access_log . localhost because this is going over an stunnel. Here is the rsyncd.conf: use chroot = yes hosts allow = 127.0.0.1 uid = nobody gid = nobody [apache_logs] uid = root gid = root path = /usr/local/apache/logs comment = apache server log files, etc. read only = yes Thank You. -jeremy -- The trouble with being poor is that it takes up all your time.
Re: problem with 2.4.7pre4
On Fri, 30 Nov 2001, Martin Pool wrote: On 29 Nov 2001, Jeremy Hansen [EMAIL PROTECTED] wrote: rsync -avz --progress rsync://localhost/apache_logs/access_log . tridge just reminded me that -a does *not* detect hardlinks. You need -H too. Hmm, there are no hard links involved here. I think you're confusing me with another poster. I'll do the trace on stunnel. Thanks -jeremy A documentation bug implied that -a was enough. I've just fixed it. -- The trouble with being poor is that it takes up all your time.
Re: problem with 2.4.7pre4
Actually, I did it this time without stunnel and got the same results: Nov 29 16:49:49 rio rsyncd[24007]: transfer interrupted (code 20) at rsync.c(229) It's literally right at the end of the transfer. Somewhere in renaming the temp file or something?? -jeremy On Thu, 29 Nov 2001, Jeremy Hansen wrote: So...it seems I did receive an error from stunnel. So now do I have to go off to the stunnel list :-) Nov 29 16:26:04 rio stunnel[20970]: SSL_write (ERROR_SYSCALL): Broken pipe (32) Nov 29 16:26:04 rio stunnel[20970]: Connection reset: 53424205 bytes sent to SSL, 104 bytes sent to socket Nov 29 16:26:04 rio rsyncd[20971]: transfer interrupted (code 20) at rsync.c(229) Thanks -jeremy On Thu, 29 Nov 2001, Jeremy Hansen wrote: On Fri, 30 Nov 2001, Martin Pool wrote: On 29 Nov 2001, Jeremy Hansen [EMAIL PROTECTED] wrote: rsync -avz --progress rsync://localhost/apache_logs/access_log . tridge just reminded me that -a does *not* detect hardlinks. You need -H too. Hmm, there are no hard links involved here. I think you're confusing me with another poster. I'll do the trace on stunnel. Thanks -jeremy A documentation bug implied that -a was enough. I've just fixed it. -- The trouble with being poor is that it takes up all your time.
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: --no-detach option?
Has any work been done to create an option for rsync to send its logging
output to STDOUT for djb style logging? This would be a useful option for
me. --log-stdout?
Thanks
-jeremy
On Wed, 21 Nov 2001, Jos Backus wrote:
On Wed, Nov 21, 2001 at 08:54:18AM -0600, Dave Dykstra wrote:
Excuse me, I meant to say if stdin in IS a socket.
That mode of operation is used when running from inetd or tcpserver. Not
detaching from the parent is useful when one wants the parent (supervise in
this case) to manage the rsync process instead.
Here's a patch, based on Max Bowsher's patch. If deemed useful I will supply
the man patch as well.
Index: clientserver.c
===
RCS file: /cvsroot/rsync/clientserver.c,v
retrieving revision 1.74
diff -u -r1.74 clientserver.c
--- clientserver.c9 Nov 2001 06:58:39 - 1.74
+++ clientserver.c21 Nov 2001 19:26:45 -
@@ -26,6 +26,7 @@
extern int read_only;
extern int verbose;
extern int rsync_port;
+extern int no_detach;
char *auth_user;
int sanitize_paths = 0;
@@ -500,7 +501,8 @@
return start_daemon(STDIN_FILENO);
}
- become_daemon();
+ if (!no_detach)
+ become_daemon();
if (!lp_load(config_file, 1)) {
exit_cleanup(RERR_SYNTAX);
Index: options.c
===
RCS file: /cvsroot/rsync/options.c,v
retrieving revision 1.62
diff -u -r1.62 options.c
--- options.c 9 Sep 2001 04:41:14 - 1.62
+++ options.c 21 Nov 2001 19:26:46 -
@@ -55,6 +55,7 @@
int am_sender = 0;
int recurse = 0;
int am_daemon=0;
+int no_detach = 0;
int do_stats=0;
int do_progress=0;
int keep_partial=0;
@@ -203,6 +204,7 @@
rprintf(F, --include-from=FILE don't exclude patterns listed in FILE\n);
rprintf(F, --version print version number\n);
rprintf(F, --daemonrun as a rsync daemon\n);
+ rprintf(F, --no-detach do not detach from the parent\n);
rprintf(F, --address bind to the specified address\n);
rprintf(F, --config=FILE specify alternate rsyncd.conf file\n);
rprintf(F, --port=PORT specify alternate rsyncd port number\n);
@@ -285,6 +287,7 @@
/* TODO: Should this take an optional int giving the compression level? */
{compress,'z', POPT_ARG_NONE, do_compression},
{daemon, 0, POPT_ARG_NONE, am_daemon},
+ {no-detach,0, POPT_ARG_NONE, no_detach},
{stats,0, POPT_ARG_NONE, do_stats},
{progress, 0, POPT_ARG_NONE, do_progress},
{partial, 0, POPT_ARG_NONE, keep_partial},
--
The trouble with being poor is that it takes up all your time.
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.
