Re: Please test rsync-2.5.6pre1
Hi, Did you include Craig Barratt's buffered IO patches (previously posted on this list)? If not, please do as they make a lot of difference on windows machines. /Greger --- Dave Dykstra <[EMAIL PROTECTED]> skrev: > > ENHANCEMENTS: > > * The --delete-after option now implies > --delete. (Wayne Davison) > > * The --suffix option can now be used with > --backup-dir. (Michael > Zimmerman) > > * Combining "::" syntax with the -rsh/-e option > now uses the > specified remote-shell as a transport to talk > to a (newly-spawned) > server-daemon. This allows someone to use > daemon features, such > as modules, over a secure protocol, such as > ssh. (JD Paul) > > * The rsync:// syntax for daemon connections is > now accepted in the > destination field. > > * If the file name given to --include-from or > --exclude-from is "-", > rsync will read from standard input. (J.W. > Schultz) > > * New option --link-dest which is like > --compare-dest except that > unchanged files are hard-linked in to the > destination directory. > (J.W. Schultz) > > * Don't report an error if an excluded file > disappears during an > rsync run. (Eugene Chupriyanov and Bo Kersey) > > * Added .svn to --cvs-exclude list to support > subversion. (Jon > Middleton) > > * Properly support IPv6 addresses in the > rsyncd.conf "hosts allow" > and "hosts deny" fields. (Hideaki Yoshifuji) > _ Gratis e-mail resten av livet på www.yahoo.se/mail Busenkelt! -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
Win2k, rsync, and ssh on cygwin
Hi, The subject line pretty much says it all. Oh, that plus I'm tearing my hair out trying to get it all to play nice together. rsync version = 2.5.5 protocol version 26 OpenSSH_3.5p1, SSH protocols 1.5/2.0, OpenSSL 0x0090608f cygwin -- downloaded in the last 3 days from official mirrors. I'm trying to make one Win2k box rsync with another Win2k box. I managed to get it such that an initial rsync (box A pushed bunches o' files to box B) was slow, but functional. Trying to make a second rsync occur has completely escaped me. ssh hogs up 99.9% of the CPU (on box A, the "sender"), a profiler shows not much in the way of actual traffic going out of box A, box B remains mostly idle, occasionally getting something from rsync. Any pointers on where I can find the solution to this problem? (Aside from sticking a freakin' Debian box in between the Win2k boxes because they can both talk to a 3rd Debian box I have access to for testing, but isn't really an option for daily usage.) Thanks, SarahB -- 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: The behavior of "-u/--update" option on directories
Aaron, Aaron Morris writes: > rsync is just doing what your are telling it to do. Update if the file > is changed or does not exist on the remote side and delete if it no > longer exists on the local side. Yes, I can RTFM, and, suprisingly!, I even _did_ RTFM :)). > The directory may have a newer > timestamp, but you are doing a recursive put so it has to check all the > files and dirs under each directory. At least that is how I see it. > > solution: --exclude "/tmp/" or --exclude "tmp/" Well, I think you missed the point. The "tmp" subdir was just an example. The same can happen in any subdir down the tree. And, if you re-read my post carefully (or even the subject), I said "--update" (mis)behavior __on_directories__ (and _not_ regular files). Truth to be told, after a bit of thinking I _might_ accept the fact that "--update" ignores the timestamps on (sub)directories. Because if it didn't, if any file was "touch"-ed remotely after the last rsync than all subdirs, up to and including to the "top" dir, would have a newer timestamp remotely and thus no file putting would take place. However, I still think that "--update" (or, ideally, another similar option or combination of options) __should__ take into account (sub)directories timestamps and consider for processing only those (sub)directories that have remotely an older timestamp than locally. Or, to put it in your words "...doing a recursive put should be restricted __only__ to the (sub)directories that remotely have a timestamp older than locally". If that means that _no_ update (i.e. put) will take place because __any__ file deep down the tree was touched remotely since the last put...well, than that's it. Again, thanks in advance to anyone can suggest a way to have rsync __also__ in this way. Best regards, Florian > Florian-Daniel Otel wrote: > > Dear all, > > > > I have the following problem: I use the following command to "push" > > files from "local" to a "remote" machine: > > > > [...] > > /usr/bin/rsync -avuz -e "ssh -1" --exclude ".Xauthority" --delete >/user/home/directory/ [EMAIL PROTECTED]:/user/home/directory/ ; > > > > (The ssh is using RSA authentication btw. machines, but that's beside the point). > > > > The problem: > > > > > > On both the local and remote machines there is a subdirectory > > "/user/home/directory/tmp". If on the remote machine that subdirectory > > has a newer time stamp -- e.g. due to a file that was created > > recently i.e. after the last time the local machine did a "pull" -- the > > "--delete" option in the command above makes it such that the said > > newer file is deleted on remote and the timestamp is reseted back to > > the old time stamp i.e. the one for the "tmp/" subdir on the local machine. > > > > > > Putting it shortly, the "--delete" option has precendence over "-u" > > option w.r.t. directories. > > > > Is it so that "-u" works only on files and not on directories ? > > IMHO the appropriate behaviour in a situation like the one described > > above directories on remote that have newer time stamp should be ignored > > and excluded from further processing (i.e. including updating and/or > > deleting any files that do not exist on the local machine). > > > > The question: > > > > Am I right and that is the way things should behave and I am doing > > smth wrong ? If not, and this is the way things are supposed to work, > > can anyone suggest a work-around that would simulate the desired behavior ? > > > > > > > > Many thanks in advance, > > > > Florian > > > > P.S. Please Cc: me on the replies, I'm not on the list. Thanks. > > > > P.P.S: If it matters: In the above setup the "local" machine is a > > Linux running "rsync version 2.5.4 protocol version 26" whereas > > "remote" is a Solaris 2.8 running "rsync version 2.5.5 protocol version 26". > > > > -- > Aaron W Morris > decep > PGP Key ID: 259978D1 > > -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
configure issue (ac_cv_lib_inet_connect) on DYNIX/ptx
Greetings - In trying to get rsync-2.5.6pre1 working on DYNIX/ptx, I found I needed to pass ac_cv_lib_inet_connect=no to configure in order for it actually create a properly configured config.h file. I think this is because configure looks for connect in libinet, (and finds one there somehow). But connect() is resolved by libsocket (but configure doesn't find it when it looks there). I've never taken the time to delve into the guts of autoconf, so I'm not sure if this is a general autoconf problem or a problem that is specific to rsync. At any rate, hopefully, this will be useful to someone. I can send a config.log file to anyone who's interested. After passing ac_cv_lib_inet_connect=no to configure, all tests either PASS or SKIP so it looks good. I also get this warning, which is trivial, but it would be nice to clean it up: "cleanup.c", line 36: portability warning: trigraph sequence replaced This is from the () in cleanup.c. To get rid of the warning, just remove the () from line 36. Michael Sterrett -Mr. Bones.- [EMAIL PROTECTED] -- 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: am I missing something, or are permissions always preserved?
On Mon, Jan 13, 2003 at 02:38:29PM -0600, Dave Dykstra wrote: > On Mon, Jan 13, 2003 at 11:00:58AM -0800, Ben wrote: > > Well that's annoying. I've tried changing the encoding of this > > attempt... maybe it'll get through this time. > > Yes, it came through better this time. > > > As a rule of thumb, I think silent errors a very bad idea. It means > > things might not be behaving like you expect, but you have no idea. In > > general, rsync's current behavior is correct. In my case niche case, it > > doesn't work. I think the proper solution is to change rsync's behavior, > > not reduce the errors it produces. > > Maybe it wouldn't be so bad if it only looked for certain error codes from > the failed chmod. The nice thing about ignoring errors is that it's one > less thing for users to have to learn and understand. > > Any other opinions? First, identify the errno. Is it the same for cygwin and samba mounts? Then do the treatment for that errno(s) only. As far as i can tell except where the filesystem doesn't support chmod an error chmoding here is insane. We just created the file. I'd rather kick out a warning on the first one and then ignore. That warns the user that something isn't quite right without flooding the log. Dave, see my post a litter earlier in the thread for a possible code change. > > > If it comes through, take a look at the patch. I think I did a decent > > job of updating the docs so that purpose of the new flag is clear. > > At a minimum I think the option is too limited. I'd want a solution > that would work for both the fixed permission samba case and the vfat > filesystem under Linux case. In particular, I don't see it skipping > the fchmod in do_mkstemp. I don't know, maybe that's the only addition > that would be needed. -- 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: [rsync] Re: [rsync] Please test rsync-2.5.6pre1
> On Mon, Jan 13, 2003 at 01:59:47PM -0500, Scott Evans wrote: > > > Known issues that will probably need to be resolved before the final > > > release: > > > [...] > > > > Is there any interest in trying to hunt down the "linux -> cygwin > > rsync hanging" problem I'm consistently seeing before this release? > > I'm more than happy to help track it down but I don't know enough about > > rsync to do it myself. > > Well, at a minimum it would be nice to know if it is still happening > with version 2.5.6pre1. If it's no worse than previous versions, we > won't hold up a release of 2.5.6. If a cygwin user tracks it down and > provides a fix that doesn't break anybody else, we'll probably put it in. I'll try out 2.5.6pre1 and report back. If it still doesn't work... Like I said, I'd *really* like to see this fixed but I don't know if I have the rsync background (or the time to get it) to go it on my own. Anyone want to do some handholding? -- 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: List access to rsyncd.conf modules
On Mon, Jan 13, 2003 at 12:40:28PM -, Tamana, Daljit D wrote: > > I've seen this question asked in the archives, but not really answered. > > I would like to limit the rsync operation to modules listed in the > rsyncd.conf file and hence disallow any command line syncs. > > Is there any way of doing this? > Yes. You could restrict execution of the rsync binary using perms and/or locaton. If you don't disable rsh, ssh and all other remote shells though you're only making things a tiny bit more difficult. The below notification is null and void and is way too long. Also a google on the company name is now likely rank the mailing list posting higher than relevant sites. > > > More information on Standard Bank is available at www.standardbank.com > > Everything in this email and any attachments relating to the official business > of Standard Bank Group Limited and any or all subsidiaries, the Company, is > proprietary to the Company. It is confidential, legally privileged and protected > by relevant laws. The Company does not own and endorse any other content. > Views and opinions are those of the sender unless clearly stated as being > that of the Company. > > The person or persons addressed in this email are the sole authorised > recipient. Please notify the sender immediately if it has unintentionally, > or inadvertently reached you and do not read, disclose or use the content > in any way and delete this e-mail from your system. > > The Company cannot ensure that the integrity of this email has been > maintained nor that it is free of errors, virus, interception or interference. > The sender therefore does not accept liability for any errors or omissions > in the contents of this message which arise as a result of e-mail transmission. > If verification is required please request a hard-copy version. This message > is provided for informational purposes and should not be construed as a > solicitation or offer to buy or sell any securities or related financial instruments. > >*** -- 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: am I missing something, or are permissions always preserved?
On Mon, Jan 13, 2003 at 11:00:58AM -0800, Ben wrote: > Well that's annoying. I've tried changing the encoding of this > attempt... maybe it'll get through this time. Yes, it came through better this time. > As a rule of thumb, I think silent errors a very bad idea. It means > things might not be behaving like you expect, but you have no idea. In > general, rsync's current behavior is correct. In my case niche case, it > doesn't work. I think the proper solution is to change rsync's behavior, > not reduce the errors it produces. Maybe it wouldn't be so bad if it only looked for certain error codes from the failed chmod. The nice thing about ignoring errors is that it's one less thing for users to have to learn and understand. Any other opinions? > If it comes through, take a look at the patch. I think I did a decent > job of updating the docs so that purpose of the new flag is clear. At a minimum I think the option is too limited. I'd want a solution that would work for both the fixed permission samba case and the vfat filesystem under Linux case. In particular, I don't see it skipping the fchmod in do_mkstemp. I don't know, maybe that's the only addition that would be needed. - 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: [rsync] Please test rsync-2.5.6pre1
On Mon, Jan 13, 2003 at 01:59:47PM -0500, Scott Evans wrote: > > Known issues that will probably need to be resolved before the final > > release: > > [...] > > Is there any interest in trying to hunt down the "linux -> cygwin > rsync hanging" problem I'm consistently seeing before this release? > I'm more than happy to help track it down but I don't know enough about > rsync to do it myself. Well, at a minimum it would be nice to know if it is still happening with version 2.5.6pre1. If it's no worse than previous versions, we won't hold up a release of 2.5.6. If a cygwin user tracks it down and provides a fix that doesn't break anybody else, we'll probably put it in. - 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: The behavior of "-u/--update" option on directories
rsync is just doing what your are telling it to do. Update if the file is changed or does not exist on the remote side and delete if it no longer exists on the local side. The directory may have a newer timestamp, but you are doing a recursive put so it has to check all the files and dirs under each directory. At least that is how I see it. solution: --exclude "/tmp/" or --exclude "tmp/" Florian-Daniel Otel wrote: Dear all, I have the following problem: I use the following command to "push" files from "local" to a "remote" machine: [...] /usr/bin/rsync -avuz -e "ssh -1" --exclude ".Xauthority" --delete /user/home/directory/ [EMAIL PROTECTED]:/user/home/directory/ ; (The ssh is using RSA authentication btw. machines, but that's beside the point). The problem: On both the local and remote machines there is a subdirectory "/user/home/directory/tmp". If on the remote machine that subdirectory has a newer time stamp -- e.g. due to a file that was created recently i.e. after the last time the local machine did a "pull" -- the "--delete" option in the command above makes it such that the said newer file is deleted on remote and the timestamp is reseted back to the old time stamp i.e. the one for the "tmp/" subdir on the local machine. Putting it shortly, the "--delete" option has precendence over "-u" option w.r.t. directories. Is it so that "-u" works only on files and not on directories ? IMHO the appropriate behaviour in a situation like the one described above directories on remote that have newer time stamp should be ignored and excluded from further processing (i.e. including updating and/or deleting any files that do not exist on the local machine). The question: Am I right and that is the way things should behave and I am doing smth wrong ? If not, and this is the way things are supposed to work, can anyone suggest a work-around that would simulate the desired behavior ? Many thanks in advance, Florian P.S. Please Cc: me on the replies, I'm not on the list. Thanks. P.P.S: If it matters: In the above setup the "local" machine is a Linux running "rsync version 2.5.4 protocol version 26" whereas "remote" is a Solaris 2.8 running "rsync version 2.5.5 protocol version 26". -- Aaron W Morris decep PGP Key ID: 259978D1 -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
The behavior of "-u/--update" option on directories
Dear all, I have the following problem: I use the following command to "push" files from "local" to a "remote" machine: [...] /usr/bin/rsync -avuz -e "ssh -1" --exclude ".Xauthority" --delete /user/home/directory/ [EMAIL PROTECTED]:/user/home/directory/ ; (The ssh is using RSA authentication btw. machines, but that's beside the point). The problem: On both the local and remote machines there is a subdirectory "/user/home/directory/tmp". If on the remote machine that subdirectory has a newer time stamp -- e.g. due to a file that was created recently i.e. after the last time the local machine did a "pull" -- the "--delete" option in the command above makes it such that the said newer file is deleted on remote and the timestamp is reseted back to the old time stamp i.e. the one for the "tmp/" subdir on the local machine. Putting it shortly, the "--delete" option has precendence over "-u" option w.r.t. directories. Is it so that "-u" works only on files and not on directories ? IMHO the appropriate behaviour in a situation like the one described above directories on remote that have newer time stamp should be ignored and excluded from further processing (i.e. including updating and/or deleting any files that do not exist on the local machine). The question: Am I right and that is the way things should behave and I am doing smth wrong ? If not, and this is the way things are supposed to work, can anyone suggest a work-around that would simulate the desired behavior ? Many thanks in advance, Florian P.S. Please Cc: me on the replies, I'm not on the list. Thanks. P.P.S: If it matters: In the above setup the "local" machine is a Linux running "rsync version 2.5.4 protocol version 26" whereas "remote" is a Solaris 2.8 running "rsync version 2.5.5 protocol version 26". -- 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: [rsync] Please test rsync-2.5.6pre1
> Known issues that will probably need to be resolved before the final > release: > [...] Is there any interest in trying to hunt down the "linux -> cygwin rsync hanging" problem I'm consistently seeing before this release? I'm more than happy to help track it down but I don't know enough about rsync to do it myself. -- scott evans :: www.antisleep.com -- 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: Rsync over SSH v2 with strong authentication but not encryptedto get the highest speed on Rsync?
I do not believe there is a way to turn encryption off, however, you might be able to use "blowfish" (or DES, if possible) as a cipher instead of "3DES" which is much slower (and the default for SSH2 in OpenSSH). Also, make sure you are not using compression in rsync or ssh, since it will increase CPU load as well. Boris Gegenheimer wrote: Hello I am trying to set up a backup server running Solaris 8 with rsync 2.5.5 and ipfilter the latest version. The problem i have is i have about 16 different interfaces that are secured via ipfilter , and i tried running rsync via rsh but ipfilter would not set up a keepstate with rsh which meant i had to open up and that is not acceptable. So what i tried then was via ssh and that worked fine but it was very slow and cpu heavy due to the encryption . What i am asking is there some way to configure ssh and rsync to use strong authentication but drop the encryption so that it works faster? Regards Boris -- Aaron W Morris decep PGP Key ID: 259978D1 -- 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: am I missing something, or are permissions always preserved?
Well that's annoying. I've tried changing the encoding of this
attempt... maybe it'll get through this time.
As a rule of thumb, I think silent errors a very bad idea. It means
things might not be behaving like you expect, but you have no idea. In
general, rsync's current behavior is correct. In my case niche case, it
doesn't work. I think the proper solution is to change rsync's behavior,
not reduce the errors it produces.
If it comes through, take a look at the patch. I think I did a decent
job of updating the docs so that purpose of the new flag is clear.
On Mon, 2003-01-13 at 06:54, Dave Dykstra wrote:
> > Okay, attached is a patch I just whipped up that seems to work well. It
> > adds the --skip-perms flag, which has the effect of making rsync not try
> > to set permissions, not even to sane values.
>
> I was not able to read your patch because it seems to have lots of
> characters that I can't view on my email reader. A header on the
> attachment says
> X-MIME-Autoconverted: from 8bit to base64 by mx6.mx.voyager.net
> so my ISP must have had trouble with it.
>
> Anyway, I wasn't thinking of an option, I was thinking of it doing
> something that was the default whenever there was no -p. I'd rather
> avoid adding an option if we can get away with it. I'm now having second
> thoughts about stripping off the setuid/setgid bits by default without
> '-p', because that's not what GNU cp does. I think it would be better if
> it just silently ignored errors from chmod and fchmod when -p is not set.
>
> - Dave
diff -c rsync-2.5.5/README rsync-2.5.5-tukati/README
*** rsync-2.5.5/README Mon Dec 17 17:07:20 2001
--- rsync-2.5.5-tukati/README Sat Jan 11 10:59:30 2003
***
*** 48,53
--- 48,54
--safe-linksignore links outside the destination tree
-H, --hard-linkspreserve hard links
-p, --perms preserve permissions
+ --skip-permsdon't set any permissions on new files
-o, --owner preserve owner (root only)
-g, --group preserve group
-D, --devices preserve devices (root only)
Common subdirectories: rsync-2.5.5/doc and rsync-2.5.5-tukati/doc
Common subdirectories: rsync-2.5.5/lib and rsync-2.5.5-tukati/lib
diff -c rsync-2.5.5/options.c rsync-2.5.5-tukati/options.c
*** rsync-2.5.5/options.c Tue Mar 19 12:16:42 2002
--- rsync-2.5.5-tukati/options.c Sat Jan 11 10:47:00 2003
***
*** 40,45
--- 40,46
int preserve_links = 0;
int preserve_hard_links = 0;
int preserve_perms = 0;
+ int skip_perms = 0;
int preserve_devices = 0;
int preserve_uid = 0;
int preserve_gid = 0;
***
*** 216,221
--- 217,223
rprintf(F," --safe-linksignore links outside the destination tree\n");
rprintf(F," -H, --hard-linkspreserve hard links\n");
rprintf(F," -p, --perms preserve permissions\n");
+ rprintf(F," --skip-permsdon't set any permissions on new files\n");
rprintf(F," -o, --owner preserve owner (root only)\n");
rprintf(F," -g, --group preserve group\n");
rprintf(F," -D, --devices preserve devices (root only)\n");
***
*** 323,328
--- 325,331
{"no-whole-file",0, POPT_ARG_NONE, 0, OPT_NO_WHOLE_FILE, 0, 0 },
{"copy-unsafe-links", 0, POPT_ARG_NONE, ©_unsafe_links , 0, 0, 0 },
{"perms", 'p', POPT_ARG_NONE, &preserve_perms , 0, 0, 0 },
+ {"ignore-perms", 0, POPT_ARG_NONE, &skip_perms , 0, 0, 0 },
{"owner", 'o', POPT_ARG_NONE, &preserve_uid , 0, 0, 0 },
{"group", 'g', POPT_ARG_NONE, &preserve_gid , 0, 0, 0 },
{"devices", 'D', POPT_ARG_NONE, &preserve_devices , 0, 0, 0 },
***
*** 575,580
--- 578,591
}
}
+ if (skip_perms && preserve_perms) {
+ snprintf(err_buf,sizeof(err_buf),
+ "permissions cannot be ignored and preserved at the same time\n");
+ rprintf(FERROR,"ERROR: permissions cannot be ignored"
+ " and preserved at the same time\n");
+ return 0;
+ }
+
if (write_batch && read_batch) {
snprintf(err_buf,sizeof(err_buf),
"write-batch and read-batch can not be used together\n");
Common subdirectories: rsync-2.5.5/packaging and rsync-2.5.5-tukati/packaging
Common subdirectories: rsync-2.5.5/patches and rsync-2.5.5-tukati/patches
Common subdirectories: rsync-2.5.5/popt and rsync-2.5.5-tukati/popt
diff -c rsync-2.5.5/rsync.1 rsync-2.5.5-tukati/rsync.1
*** rsync-2.5.5/rsync.1 Wed Feb 6 13:21:19 2002
--- rsync-2.5.5-tukati/rsync.1 Sat Jan 11 10:56:19 2003
***
*** 261,266
--- 261,267
--safe-linksignore links outside the destination tree
-H, --hard-linkspreserve hard links
-p, --perms preserve permissions
+ --skip-permsdon't set any permissions
Please test rsync-2.5.6pre1
The first rsync-2.5.6 pre-release version is now available at: http://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre1.tar.gz ftp://rsync.samba.org/pub/rsync/preview/rsync-2.5.6pre1.tar.gz rsync://rsync.samba.org/ftp/rsync/preview/rsync-2.5.6pre1.tar.gz There's also a corresponding '.sig' file that contains a gpg signature of the file; the public key is available on the pgp keyservers. Please test it out thoroughly and report problems and bug fix patches to this mailing list. Known issues that will probably need to be resolved before the final release: 1. The Redhat Linux ia64 and Alpha and the OpenBSD Sparc64 ports are all failing the daemon-gzip-upload and daemon-gzip-download tests even though the basic daemon test succeeds. The OpenBSD test reports a core dump, and I suspect they're all having the same problem related to 64 bit. See build output on build.samba.org. Somebody else is going to have to fix this, I don't have the resources. 2. The NetBSD i386 port is failing the chgrp test. NetBSD users, see build.samba.org. 3. --copy-unsafe-links is badly broken. I'm planning on trying to fix this myself. 4. The --modify-window option should default to 2 seconds or 1 second on Cygwin. I'll put this in once somebody determines which it should be. 5. The documentation hosts allow & hosts deny needs to be updated for IPv6. Changes since the 2.5.5 release: ENHANCEMENTS: * The --delete-after option now implies --delete. (Wayne Davison) * The --suffix option can now be used with --backup-dir. (Michael Zimmerman) * Combining "::" syntax with the -rsh/-e option now uses the specified remote-shell as a transport to talk to a (newly-spawned) server-daemon. This allows someone to use daemon features, such as modules, over a secure protocol, such as ssh. (JD Paul) * The rsync:// syntax for daemon connections is now accepted in the destination field. * If the file name given to --include-from or --exclude-from is "-", rsync will read from standard input. (J.W. Schultz) * New option --link-dest which is like --compare-dest except that unchanged files are hard-linked in to the destination directory. (J.W. Schultz) * Don't report an error if an excluded file disappears during an rsync run. (Eugene Chupriyanov and Bo Kersey) * Added .svn to --cvs-exclude list to support subversion. (Jon Middleton) * Properly support IPv6 addresses in the rsyncd.conf "hosts allow" and "hosts deny" fields. (Hideaki Yoshifuji) BUG FIXES: * Fix "forward name lookup failed" errors on AIX 4.3.3. (John L. Allen, Martin Pool) * Generate each file's rolling-checksum data as we send it, not in a separate (memory-eating) pass before hand. This prevents timeout errors on really large files. (Stefan Nehlsen) * Fix compilation on Tru64. (Albert Chin, Zoong Pham) * Better handling of some client-server errors. (Martin Pool) * Fixed a crash that would occur when sending a list of files that contains a duplicate name (if it sorts to the end of the file list) and using --delete. (Wayne Davison) * Fixed a bug that caused rsync to lose the exit status of its child processes and sometimes return an exit code of 0 instead of showing an error. (David R. Staples, Dave Dykstra) INTERNAL: * Many code cleanups and improved internal documentation. (Martin Pool, Nelson Beebe) * More test cases. (Martin Pool) * Updated included popt to the latest vendor drop, version 1.6.4. (Jos Backus) - Dave Dykstra msg06044/pgp0.pgp Description: PGP signature
Re: am I missing something, or are permissions always preserved?
On Sat, Jan 11, 2003 at 11:19:33AM -0800, Ben wrote [off list]: > On Tue, 2003-01-07 at 14:49, Dave Dykstra wrote: > > That sounds reasonable to me that rsync shouldn't try to preserve those > > extra bits without -p. Try making a patch and seeing if that works. > > > > I don't have Samba set up, but on a vfat filesystem on Linux rsync is > > doing even worse because after the initial file creation it does a > > "fchmod(fd, 0600)" which fails and it doesn't even copy files at all. > > > > > Okay, attached is a patch I just whipped up that seems to work well. It > adds the --skip-perms flag, which has the effect of making rsync not try > to set permissions, not even to sane values. I was not able to read your patch because it seems to have lots of characters that I can't view on my email reader. A header on the attachment says X-MIME-Autoconverted: from 8bit to base64 by mx6.mx.voyager.net so my ISP must have had trouble with it. Anyway, I wasn't thinking of an option, I was thinking of it doing something that was the default whenever there was no -p. I'd rather avoid adding an option if we can get away with it. I'm now having second thoughts about stripping off the setuid/setgid bits by default without '-p', because that's not what GNU cp does. I think it would be better if it just silently ignored errors from chmod and fchmod when -p is not set. - 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: IPv6 hosts allow|deny
In article <[EMAIL PROTECTED]> (at Mon, 13 Jan 2003 08:13:06 -0600), Dave Dykstra <[EMAIL PROTECTED]> says: > I am totally mystified by Hideaki's examples. I didn't think colons were > allowed, and I don't see any code in access.c for recognizing them. As far > as I can tell the code only allows decimal notation, not hexadecimal. And > do the blank fields mean anything? getaddrinfo() handles them; it accepts only valid numeric addresses (decimal format for IPv4, hexadecimal format (with scope-id) for IPv6) if it is called with AI_NUMERICHOST flags set. --yoshfuji -- 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: Rsync --daemon v 2.5.5 v26 causing kernel panic
After switching much hardware (and getting some helpful suggestions) I moved the specific machine's files on the backup server to a hard drive outside the raid (still on the backup server, /dev/hdi1) and tried rsync -- problem solved. It seems there's a problem with the journaled filesystems (reiserfs) and raid -- reading the files is ok (cp command worked fine), writing them is not. I'm going to turn on reiser debugging and internal checks and re-run -- maybe I can send something to the reiser or kernel people of interest (don't want to go back to ext2) jw schultz wrote: On Fri, Jan 10, 2003 at 02:25:57PM -0600, Edward King wrote: Has anyone seen this? Looking for past experiences / ideas. Will post progress. I'm tracking down a problem that seems to be caused by rsync. When moving files from a remote server I get a kernel panic. We have a number of servers that back up to a main box -- the panic only occurs when a specific client backs up. It occurs on the box it is backing up to -- not the client. The kernel is Linux 2.4.20 (just compiled -- no patches), files are stored on a 4 disk raid (80GB Western Digital drives, software raid) with Reiserfs. This is being done over a vpn connection controlled by another machine (gateway machine) running tinc so we're not using ssh or any other shell on the rsync machine. I have: recompiled rsync at both locations recompiled the kernel from new source code (panic in 2.4.19, system rebooted in 2.4.20) I will: try different hardware run a file system check at the main system (the one that crashes) exclude directories in the backup (rsync one directory at a time -- see where it crashes) I did notice filenames on the client machine that contain control characters -- but they seem to have backed up before. Just to confirm: You are doing backup-server initiated pull something like "rsync server::module destdir" and the machine you execute this on (the receiver) panics. Rsync will of course not be the culprit. However, rsync is very good at stressing a system and the kernel developers have found it to be a common test case. Most likely it is a hardware fault. Probably timing sensitive. I'd check the logs for oopses and and disk errors. Also try downgrading the mode with hdparm. If this isn't a obvious hardware fault you should report it to the linux-kernel people. Look on www.kernelnewbies.org for instructions. This will be of interest to the developers of md, reiserfs and the specific IDE driver.
Re: IPv6 hosts allow|deny
On Sun, Jan 12, 2003 at 11:51:07PM +0100, Bert Vermeulen wrote: > On Fri, 10 Jan 2003, Bert Vermeulen wrote: > > > On Thu, 9 Jan 2003, Dave Dykstra wrote: > > > > > I went ahead and submitted Hideaki's patch pretty much as is. I took off > > > the ifdef around the memset at the beginning of client_sockaddr() because > > > I figured it wouldn't hurt to do anywhere. Besides, it was checking > > > for a specific operating system (__linux__) which we like to avoid and > > > because there was a typo in the check for HAVE_SOCKADDR_IN6_SCOPE_ID > > > (it was HAVE_SOCKADDR_IN6_SOCPE_ID). I noticed that there was code in > > > access.c that was accessing the same sockaddr_in6 sin6_scope_id field that > > > was protected by ifdef in clientname.c so I put the same ifdef around > > > the code in access.c. I also updated the rsyncd.conf.yo documentation > > > to allow for IP address of the IPv6 form. > > > > > > I have not tested this, I hope it works. > > > > Dave, > > > > Sorry for the late reply, been busy. I'm going to test with the committed > > patch, and will let you know. I can only test on linux, however. > > Well, it works great for me. It might be a good idea to include Hideaki's > comments on this syntax in the docs: > > > Note that scope-id is also supported: > > - fe80::1%eth0 > > - fe80::%eth0/64 > > - fe80::%eth0/::::: > > The example is significant -- this restricts access to the local subnet > only. I don't understand enough how that syntax works in order to be able to write an explanation for people. Could you please try to write something up based on the current version checked in to CVS? I am totally mystified by Hideaki's examples. I didn't think colons were allowed, and I don't see any code in access.c for recognizing them. As far as I can tell the code only allows decimal notation, not hexadecimal. And do the blank fields mean anything? For the record, here are the rest of Hideaki's examples: > > - 3ffe::dead:beef::1 > > - 3ffe::dead:beef::/64 > > - 3ffe::dead:beef::/::::: > > or even > > - ::0123:4567:89ab:cdef/::::: - 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
Rsync over SSH v2 with strong authentication but not encrypted to get the highest speed on Rsync?
Title: Message Hello I am trying to set up a backup server running Solaris 8 with rsync 2.5.5 and ipfilter the latest version. The problem i have is i have about 16 different interfaces that are secured via ipfilter , and i tried running rsync via rsh but ipfilter would not set up a keepstate with rsh which meant i had to open up and that is not acceptable. So what i tried then was via ssh and that worked fine but it was very slow and cpu heavy due to the encryption . What i am asking is there some way to configure ssh and rsync to use strong authentication but drop the encryption so that it works faster? Regards Boris
List access to rsyncd.conf modules
I've seen this question asked in the archives, but not really answered. I would like to limit the rsync operation to modules listed in the rsyncd.conf file and hence disallow any command line syncs. Is there any way of doing this? Thanks in advance regards, Dal More information on Standard Bank is available at www.standardbank.com Everything in this email and any attachments relating to the official business of Standard Bank Group Limited and any or all subsidiaries, the Company, is proprietary to the Company. It is confidential, legally privileged and protected by relevant laws. The Company does not own and endorse any other content. Views and opinions are those of the sender unless clearly stated as being that of the Company. The person or persons addressed in this email are the sole authorised recipient. Please notify the sender immediately if it has unintentionally, or inadvertently reached you and do not read, disclose or use the content in any way and delete this e-mail from your system. The Company cannot ensure that the integrity of this email has been maintained nor that it is free of errors, virus, interception or interference. The sender therefore does not accept liability for any errors or omissions in the contents of this message which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. This message is provided for informational purposes and should not be construed as a solicitation or offer to buy or sell any securities or related financial instruments. *** -- To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.tuxedo.org/~esr/faqs/smart-questions.html
