Re: daemon-server via SSH (was Re: new rsync release needed soon?)
On Thu, Aug 01, 2002 at 02:25:50PM -0500, Dave Dykstra wrote: ... I tried it out with an example like rsync -e ssh --rsync-path= /etc/motd localhost:: and the first thing one runs across is that the remote side tries to open /etc/motd.conf and reports an error only to the syslog. The man page explains that the way to set a different config file is by using ssh and authorized_keys and set the forced command with a --config-file option. I suggest we have rsync --daemon first look for $HOME/rsyncd.conf before looking for /etc/rsyncd.conf. That will be a modification to the server side, but other than that a cool thing about this patch is that it seems to work quite well with older versions of rsync on the server side. Also, I don't know how clean it will be to implement, but I think it will save us a lot of questions if we let that initial error message about not being able to open /etc/rsyncd.conf show up on the and the client and not go only to syslog. I've submitted patches for the above to CVS. Here's the checkin message: When using daemon mode over a remote shell program and not running as root, default the config file to just rsyncd.conf in the current directory instead of /etc/rsyncd.conf. Also, fix problems with logging messages when running daemont mode over a remote shell program: it was pretty much doing the opposite of what it should have, sending early error messages to the log and later messages to the client. Switched it around so the very early error messages go to the client and the later ones go to the log. I think the man pages should still be updated to consistently talk change what it used to call rsync server to rsync server without a remote shell program. - Dave Dykstra -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: new rsync release needed soon?
On Sun, Aug 04, 2002 at 12:50:04AM +1000, Martin Pool wrote: On 31 Jul 2002, Dave Dykstra [EMAIL PROTECTED] wrote: Yes I think a new release is needed soon, but there's more patches than that that should get in. We need to weigh up getting functions in vs making steps small enough that the chance of breakage is acceptable. I am afraid that at the moment our only means of getting really good cross-platform test coverage for rsync is to throw a release out, and so that inclines me towards being conservative in what we put in. Hopefully we can try to get people on the list testing -rc releases more aggressively. Was an RC announced recently? I don't recall seeing it here. For what it's worth (my usage isn't very varied) i'm now running from friday's cvs + patches. A bunch of them have been posted and I was hoping you were keeping track of them and would be putting more of them in. I will try to read back through the list and see about merging them this week, with a view to a release candidate on about the 11th, and a release about a week after that. The patch that I'd most like to see get in JD Paul's patch for using SSH and daemon mode together. We still don't have an agreement on what the syntax should be. I think the combination of -e ssh and :: which he implemented is the most understandable syntax and we should just go with it. I agree that it would be really good to support it. However, -e and :: seem to be a persistent source of confusion for new users. I'm not sure if this change will help those people, or what if anything would be better. (More later on this.) I concur on the confusion issue. Never got it wrong myself but it took a little puzzling over. Perhaps if the manpage changed the terminology a bit so that instead of calling it an rsync server we called it an rsync daemon it would reduce the confusion of when :: is needed. After all with --rsh you are connecting to a server. Another thing that may help would be to restructure USAGE and GENERAL so that GENERAL became more of a TOC of USAGE and we had USAGE subsections on using locally using without rsync daemon on server using with rsync daemon on server using with rsync daemon over ssh transport running rsync daemon on server and fold the examples in. Reading over it again just now i get the impression that the manpage has suffered from the documentation equivalent of code spagettification. It might also help if either [user@]host::module or rsync://[user@]host[:port]/module were deprecated and moved to an errata section. I know, this is a whole flame-fest and i'm sorry but i think it needs to be said that the extra two possible invocation syntaxes are making support more difficult than it needs to be. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: new rsync release needed soon?
On 31 Jul 2002, Dave Dykstra [EMAIL PROTECTED] wrote: Yes I think a new release is needed soon, but there's more patches than that that should get in. We need to weigh up getting functions in vs making steps small enough that the chance of breakage is acceptable. I am afraid that at the moment our only means of getting really good cross-platform test coverage for rsync is to throw a release out, and so that inclines me towards being conservative in what we put in. Hopefully we can try to get people on the list testing -rc releases more aggressively. A bunch of them have been posted and I was hoping you were keeping track of them and would be putting more of them in. I will try to read back through the list and see about merging them this week, with a view to a release candidate on about the 11th, and a release about a week after that. The patch that I'd most like to see get in JD Paul's patch for using SSH and daemon mode together. We still don't have an agreement on what the syntax should be. I think the combination of -e ssh and :: which he implemented is the most understandable syntax and we should just go with it. I agree that it would be really good to support it. However, -e and :: seem to be a persistent source of confusion for new users. I'm not sure if this change will help those people, or what if anything would be better. (More later on this.) -- Martin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: daemon-server via SSH (was Re: new rsync release needed soon?)
On Thu, Aug 01, 2002 at 04:58:31PM -0500, Dave Dykstra wrote: ... Ok, I put that in. I now tested it on Linux and unfortunately it doesn't properly look up the names unless I configure --disable-ipv6. I'm out of time for today, however, I'll try to look at it tomorrow morning (unless somebody else figures it out in the meantime). Perhaps it needs to distinguish between whether or not the IP address is actually an IPv6 address, which I presume is the difference between having 3 dots in the string or more. I checked in code to look for more than 3 dots in the first part of $SSH_CLIENT, otherwise it does the same thing as when INET6 is not defined. I have tested on Linux with INET6 defined, but I haven't tested it when ipv6 is enabled in openssh because I don't have any systems with ipv6 enabled. Does anybody on the list have a setup of that? If so, could you please post what $SSH_CLIENT looks like after being called over an ipv6 connection? Also, someone with ipv6 ssh please test the current rsync CVS doing ssh to daemon mode on ipv6 to a module with hosts allow so we can see if it is properly discovering the host name. Actually, just checking the log file for the name of the logged client machine is probably enough. As for your question of how to know when to look at the SSH_CLIENT environment variable, I wonder if the is_a_socket() call that was in the original patch would be enough of a distinguishing factor. Like this: ... I'll have to look at the code in more detail to know if this works or not. I tried it; it doesn't work on Solaris. I discovered an easier way and checked it in: it now simply checks the am_server global variable, which is only set when doing daemon mode over --rsh. - Dave Dykstra -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: new rsync release needed soon?
On Wed, Jul 31, 2002 at 12:03:00PM -0500, Dave Dykstra wrote: Yes I think a new release is needed soon, but there's more patches than that that should get in. A bunch of them have been posted and I was hoping you were keeping track of them and would be putting more of them in. To put in my two bits. I would be pleased to see my --link-dest and --exclude-from stdin patches get in. The opinions of others my differ but they are fairly non-intrusive and i've seen a moderate amount of interest. I've just resynced them with cvs and resent so they should apply cleanly. -- J.W. SchultzPegasystems Technologies email address: [EMAIL PROTECTED] Remember Cernan and Schmitt -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: daemon-server via SSH (was Re: new rsync release needed soon?)
On Wed, Jul 31, 2002 at 05:54:29PM -0700, Wayne Davison wrote: On Wed, 31 Jul 2002, Dave Dykstra wrote: The patch that I'd most like to see get in JD Paul's patch for using SSH and daemon mode together. I've completed my mods to get this updated to the latest CVS version and then checked it all in. Since things had changed quite a bit, I applied the patch by hand and then compared my changes to the original patch to ensure that I did a good job. I did leave out one thing that I had a question about in main.c: the code that was looking for a -l option in the remote-shell command. If the user specifies a username in both the host-spec and in their ssh command, do we really want to silently eliminate one of them? Or should we maybe complain and fail? I think I might prefer to let the remote- shell command run and let it complain about the two -l options (if that's what it wants to do), but I could be convinced otherwise. I'm pretty sure that we discussed that issue when the patch was developed, and there are some cases where you want to use both. Yes: the notion of a userid in an rsync server module is not the same thing as the ssh -l userid; the former specifies which password to use in a secrets file, and the latter specifies which userid to log in as. I think the way JD did it was the compromise we agreed on: if a userid is specified only with userid@hostname, it should be used for both purposes, but if the -e command includes -l it should override the login userid only. This is documented in the man page at CONNECTING TO AN RSYNC SERVER OVER A REMOTE SHELL PROGRAM. I've tested normal rsync operations to ensure that it is still working right, but not daemon mode (which I don't normally use). If someone could help out with the testing, I'd appreciate it. I tried it out with an example like rsync -e ssh --rsync-path= /etc/motd localhost:: and the first thing one runs across is that the remote side tries to open /etc/motd.conf and reports an error only to the syslog. The man page explains that the way to set a different config file is by using ssh and authorized_keys and set the forced command with a --config-file option. I suggest we have rsync --daemon first look for $HOME/rsyncd.conf before looking for /etc/rsyncd.conf. That will be a modification to the server side, but other than that a cool thing about this patch is that it seems to work quite well with older versions of rsync on the server side. Also, I don't know how clean it will be to implement, but I think it will save us a lot of questions if we let that initial error message about not being able to open /etc/rsyncd.conf show up on the and the client and not go only to syslog. One thing that did not work for me is the hosts allow and presumably hosts deny: it says ERROR: access denied to testdir from unknown (). There was code on the server side that's reads $SSH_CLIENT for the IP address and set remote.shell.connection as the host name. It was switching on is_a_socket() though, and at least in my case that is returning true for the ssh connection. I went ahead and developed a fix for that and submitted it to CVS. Any time $SSH_CLIENT is specified, I use that for the client IP address, and I look up the real name with getnameinfo(). I included code I thought would be needed for IPv6 but haven't tested that part yet, I hope somebody else can. - Dave Dykstra -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: new rsync release needed soon?
Another change that I think really ought to go in is something like the one at http://lists.samba.org/pipermail/rsync/2002-February/006371.html to get the correct error codes out of rsync. But first I think we really need to hear from Tridge why he put that code there in the first place. Martin, did you ever ask him? If not, can you please get him to look at it? - Dave Dykstra -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: daemon-server via SSH (was Re: new rsync release needed soon?)
On Thu, Aug 01, 2002 at 02:25:50PM -0500, Dave Dykstra wrote: ... One thing that did not work for me is the hosts allow and presumably hosts deny: it says ERROR: access denied to testdir from unknown (). There was code on the server side that's reads $SSH_CLIENT for the IP address and set remote.shell.connection as the host name. It was switching on is_a_socket() though, and at least in my case that is returning true for the ssh connection. I went ahead and developed a fix for that and submitted it to CVS. Any time $SSH_CLIENT is specified, I use that for the client IP address, and I look up the real name with getnameinfo(). I included code I thought would be needed for IPv6 but haven't tested that part yet, I hope somebody else can. Hey, it just occurred to me that always checking for $SSH_CLIENT will be a problem if somebody wants to start a normal background daemon from an interactive ssh session, or even if they've restarted inetd from one. What's a reliable way of determining on the server side that it's been started from ssh? Maybe we could set another global in start_daemon() or daemon_main(). - Dave -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: daemon-server via SSH (was Re: new rsync release needed soon?)
On Thu, 1 Aug 2002, Dave Dykstra wrote:
I think the way JD did it was the compromise we agreed on: if a userid
is specified only with userid@hostname, it should be used for both
purposes, but if the -e command includes -l it should override the
login userid only.
OK, that makes sense. I'm sorry I missed that. I've committed the code
I had ommitted that implements this.
As for your SSH_CLIENT change, it doesn't compile on my Linux system
with INET6 defined (due to the IPv6 structures having different names).
I needed to make this patch to get it to compile:
Index: clientname.c
--- clientname.c2002/08/01 19:17:00 1.9
+++ clientname.c2002/08/01 21:05:53
-112,8 +111,13
socklen_t sin_len = sizeof sin;
memset(sin, 0, sin_len);
+#ifdef INET6
+ sin.sin6_family = af;
+ inet_pton(af, client_addr(fd), sin.sin6_addr.s6_addr);
+#else
sin.sin_family = af;
inet_pton(af, client_addr(fd), sin.sin_addr.s_addr);
+#endif
if (!lookup_name(fd, (struct sockaddr_storage *)sin, sin_len,
name_buf, sizeof name_buf, port_buf, sizeof port_buf))
As for your question of how to know when to look at the SSH_CLIENT
environment variable, I wonder if the is_a_socket() call that was in
the original patch would be enough of a distinguishing factor. Like
this:
Index: clientname.c
--- clientname.c2002/08/01 19:17:00 1.9
+++ clientname.c2002/08/01 21:05:53
-51,8 +51,7
initialised = 1;
- ssh_client = getenv(SSH_CLIENT);
- if (ssh_client != NULL) {
+ if (!is_a_socket(fd) (ssh_client = getenv(SSH_CLIENT)) != NULL) {
strlcpy(addr_buf, ssh_client, sizeof(addr_buf));
/* truncate SSH_CLIENT to just IP address */
p = strchr(addr_buf, ' ');
-100,7 +99,7
strcpy(name_buf, default_name);
initialised = 1;
- if (getenv(SSH_CLIENT) != NULL) {
+ if (!is_a_socket(fd) getenv(SSH_CLIENT) != NULL) {
/* Look up name of IP address given in $SSH_CLIENT */
#ifdef INET6
int af = AF_INET6;
I'll have to look at the code in more detail to know if this works or
not.
..wayne..
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: daemon-server via SSH (was Re: new rsync release needed soon?)
On Thu, Aug 01, 2002 at 02:08:36PM -0700, Wayne Davison wrote:
On Thu, 1 Aug 2002, Dave Dykstra wrote:
I think the way JD did it was the compromise we agreed on: if a userid
is specified only with userid@hostname, it should be used for both
purposes, but if the -e command includes -l it should override the
login userid only.
OK, that makes sense. I'm sorry I missed that. I've committed the code
I had ommitted that implements this.
As for your SSH_CLIENT change, it doesn't compile on my Linux system
with INET6 defined (due to the IPv6 structures having different names).
I needed to make this patch to get it to compile:
Index: clientname.c
--- clientname.c 2002/08/01 19:17:00 1.9
+++ clientname.c 2002/08/01 21:05:53
-112,8 +111,13
socklen_t sin_len = sizeof sin;
memset(sin, 0, sin_len);
+#ifdef INET6
+ sin.sin6_family = af;
+ inet_pton(af, client_addr(fd), sin.sin6_addr.s6_addr);
+#else
sin.sin_family = af;
inet_pton(af, client_addr(fd), sin.sin_addr.s_addr);
+#endif
if (!lookup_name(fd, (struct sockaddr_storage *)sin, sin_len,
name_buf, sizeof name_buf, port_buf, sizeof port_buf))
Ok, I put that in. I now tested it on Linux and unfortunately it doesn't
properly look up the names unless I configure --disable-ipv6. I'm out of
time for today, however, I'll try to look at it tomorrow morning (unless
somebody else figures it out in the meantime). Perhaps it needs to
distinguish between whether or not the IP address is actually an IPv6
address, which I presume is the difference between having 3 dots in the
string or more.
As for your question of how to know when to look at the SSH_CLIENT
environment variable, I wonder if the is_a_socket() call that was in
the original patch would be enough of a distinguishing factor. Like
this:
Index: clientname.c
--- clientname.c 2002/08/01 19:17:00 1.9
+++ clientname.c 2002/08/01 21:05:53
-51,8 +51,7
initialised = 1;
- ssh_client = getenv(SSH_CLIENT);
- if (ssh_client != NULL) {
+ if (!is_a_socket(fd) (ssh_client = getenv(SSH_CLIENT)) != NULL) {
strlcpy(addr_buf, ssh_client, sizeof(addr_buf));
/* truncate SSH_CLIENT to just IP address */
p = strchr(addr_buf, ' ');
-100,7 +99,7
strcpy(name_buf, default_name);
initialised = 1;
- if (getenv(SSH_CLIENT) != NULL) {
+ if (!is_a_socket(fd) getenv(SSH_CLIENT) != NULL) {
/* Look up name of IP address given in $SSH_CLIENT */
#ifdef INET6
int af = AF_INET6;
I'll have to look at the code in more detail to know if this works or
not.
I tried it; it doesn't work on Solaris.
- Dave
--
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: new rsync release needed soon?
On 1 Aug 2002, Dave Dykstra [EMAIL PROTECTED] wrote: Another change that I think really ought to go in is something like the one at http://lists.samba.org/pipermail/rsync/2002-February/006371.html to get the correct error codes out of rsync. But first I think we really need to hear from Tridge why he put that code there in the first place. Martin, did you ever ask him? If not, can you please get him to look at it? I will follow that up with him. -- Martin -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
new rsync release needed soon?
On Wed, Jul 31, 2002 at 10:21:49AM +1000, Martin Pool wrote: On 30 Jul 2002, Wayne Davison [EMAIL PROTECTED] wrote: On Tue, 30 Jul 2002, Martin Pool wrote: The --password-file option only applies to rsync daemon connections, not ssh. Perhaps we should make rsync complain about such options that don't make sense (another example being trying to use -e with a :: hostspec)? There's a patch in cvs to make it complain about -e with ::. The manual actually already says that --password-file does not effect remote shells, but I have made it a bit more obvious. I agree that a warning would be good. Shall we do a new release soon? There's just one more change I would like to put in, which is partially rolling back the IPv6 patch so that it uses the old code, unmodified, if --disable-ipv6 is specified. I'm not sure this needs to go in before the next release though. I think it would reduce the overall level of pain, particularly on older platforms. Yes I think a new release is needed soon, but there's more patches than that that should get in. A bunch of them have been posted and I was hoping you were keeping track of them and would be putting more of them in. The patch that I'd most like to see get in JD Paul's patch for using SSH and daemon mode together. We still don't have an agreement on what the syntax should be. I think the combination of -e ssh and :: which he implemented is the most understandable syntax and we should just go with it. I think there should be a special call for testing when you a release is about ready to go, and give people about a week to soak it. We want to be sure we get a stable release. - Dave Dykstra -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: new rsync release needed soon?
On the subject of needed patches, I just recently completed a patch for librsync that fixed the mdfour code to have uint_64 or 2 uint_32's for size. Without this, the checksums on files 512Megs are incorrect. The code should drop into rsync without a hitch. The same goes for mdfour in samba, becuase that is where librsync got the code from anyway. Robert Weber University of Colorado Boulder On Wed, Jul 31, 2002 at 10:21:49AM +1000, Martin Pool wrote: On 30 Jul 2002, Wayne Davison [EMAIL PROTECTED] wrote: On Tue, 30 Jul 2002, Martin Pool wrote: The --password-file option only applies to rsync daemon connections, not ssh. Perhaps we should make rsync complain about such options that don't make sense (another example being trying to use -e with a :: hostspec)? There's a patch in cvs to make it complain about -e with ::. The manual actually already says that --password-file does not effect remote shells, but I have made it a bit more obvious. I agree that a warning would be good. Shall we do a new release soon? There's just one more change I would like to put in, which is partially rolling back the IPv6 patch so that it uses the old code, unmodified, if --disable-ipv6 is specified. I'm not sure this needs to go in before the next release though. I think it would reduce the overall level of pain, particularly on older platforms. Yes I think a new release is needed soon, but there's more patches than that that should get in. A bunch of them have been posted and I was hoping you were keeping track of them and would be putting more of them in. The patch that I'd most like to see get in JD Paul's patch for using SSH and daemon mode together. We still don't have an agreement on what the syntax should be. I think the combination of -e ssh and :: which he implemented is the most understandable syntax and we should just go with it. I think there should be a special call for testing when you a release is about ready to go, and give people about a week to soak it. We want to be sure we get a stable release. - Dave Dykstra -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsy nc Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html -- Status: by weberr Wed Jul 31 12:26:16 2002 -- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: new rsync release needed soon?
On Wed, Jul 31, 2002 at 10:21:49AM +1000, Martin Pool wrote: There's just one more change I would like to put in, which is partially rolling back the IPv6 patch so that it uses the old code, unmodified, if --disable-ipv6 is specified. There was another patch that I thought was needed with all the timeout problems people have been seeing with large files -- the patch that Stefan Nehlsen sent a few months back. I modified it to work with the latest CVS version, tested it, and checked it in. From my reading of the patch, I think it has a very low chance of screwing anything up. If others disagree, I can back it out and we can put it in later. On Wed, 31 Jul 2002, Dave Dykstra wrote: The patch that I'd most like to see get in JD Paul's patch for using SSH and daemon mode together. We still don't have an agreement on what the syntax should be. I think the combination of -e ssh and :: which he implemented is the most understandable syntax and we should just go with it. I'd be glad to check that in and if there is still disagreement over the syntax, we can change it in CVS. I'll look at this next. Talking syntax reminds me of another patch that I think should go in: the one that makes rsync accept rsync:// syntax in the destination, not just the source. Anyone disagree with that? ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: new rsync release needed soon?
On Wed, Jul 31, 2002 at 12:29:31PM -0600, Robert Weber wrote: On the subject of needed patches, I just recently completed a patch for librsync that fixed the mdfour code to have uint_64 or 2 uint_32's for size. Without this, the checksums on files 512Megs are incorrect. The code should drop into rsync without a hitch. The same goes for mdfour in samba, becuase that is where librsync got the code from anyway. Actually... I further refined and cleaned this patch and it's in my librsync delta refactor patch. I believe this patch also offers a significant performance increase... I can extract out just the mdfour changes into a seperate patch and submit it, just tell me where you want it. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key -- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Re: new rsync release needed soon?
On Wed, Jul 31, 2002 at 04:28:55PM -0700, Wayne Davison wrote: On Wed, 31 Jul 2002, Robert Weber wrote: On the subject of needed patches, I just recently completed a patch for librsync that fixed the mdfour code to have uint_64 or 2 uint_32's for size. Without this, the checksums on files 512Megs are incorrect. In order to interoperate with older versions of rsync, wouldn't we need to continue to generate the incorrect checksums on all but the newest (freshly bumped up) protocol number? ..wayne.. I'm not sure... it probably needs more analysis. rsync primarily uses mdfour sums as the big checksums on blocks in the signature. I think it highly unlikely that blocksizes of greater than 512M are used, so this change wouldn't affect that. However, it looks like rsync also uses mdfour for it's whole file checksums when using the -c option. In this case, any file larger than 512M would end up with a different whole file sum, causing it to do a full signature/delta/patch when it is not needed. However, the resulting delta would be very small, so this might be tolerable. The biggest worry is I think rsync also does whole file sums for any signature/delta/patch to double (triple?) check the final result. If this is the case, then yes, fixing mdfour will break old rsync'ing of files greater than 512M. If this is really an issue, I can cripple the patch with one line so that it conforms with the old mdfour code. This would give you the performance benefits, and a single line change to uncripple it further down the track. Alternatively I could add a modified finalise function to give crippled sums, allowing the application software to pick what kind of sum it wants. Someone on the librsync lists mentioned a while back that some rsync or samba person had identified a bug in the mdfour finalise routines and had a fix for it. I'm not sure if this 512M limit was it. I'd be interested to know if/how this affects samba. -- -- ABO: finger [EMAIL PROTECTED] for more info, including pgp key -- -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
daemon-server via SSH (was Re: new rsync release needed soon?)
On Wed, 31 Jul 2002, Dave Dykstra wrote: The patch that I'd most like to see get in JD Paul's patch for using SSH and daemon mode together. I've completed my mods to get this updated to the latest CVS version and then checked it all in. Since things had changed quite a bit, I applied the patch by hand and then compared my changes to the original patch to ensure that I did a good job. I did leave out one thing that I had a question about in main.c: the code that was looking for a -l option in the remote-shell command. If the user specifies a username in both the host-spec and in their ssh command, do we really want to silently eliminate one of them? Or should we maybe complain and fail? I think I might prefer to let the remote- shell command run and let it complain about the two -l options (if that's what it wants to do), but I could be convinced otherwise. I've tested normal rsync operations to ensure that it is still working right, but not daemon mode (which I don't normally use). If someone could help out with the testing, I'd appreciate it. ..wayne.. -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
