Re: Failed to create rounding.h!
On Sat, May 10, 2008 at 08:15:58AM +0200, Dominik Mahrer (Teddy) wrote: > /usr/include/compat.h:22:2: warning: #warning "This header is obsolete, use > ap_compat.h instead" > /tmp/ccHr5d51.s: Assembler messages: > /tmp/ccHr5d51.s:1409: Error: symbol `fstatat64' is already defined [...] You might want to try undefining HAVE_COMPAT_H in config.h and see if that helps. Otherwise you need to figure out where those duplicate symbols are coming from. ..wayne.. -- Please use reply-all for most replies to avoid omitting the mailing list. 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: large backups taking longer with 3.0.2
On Fri, May 09, 2008 at 09:06:02AM -0400, Robert DuToit wrote: > I havn't compiled 3.0.3 pre1 yet but have been seeing considerable longer > backup times on OSX 5.2, using 3.0.2 over 3.0.1. There is nothing in the changes for 3.0.2 would affect rsync's speed. Perhaps the patches you applied differ between the versions? e.g. Did you enable create-time preservation? ..wayne.. -- Please use reply-all for most replies to avoid omitting the mailing list. 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: rsync error: timeout in data send/receive (code 30) at /home/lapo/packaging/tmp/rsync-2.6.3/io.c(153)
On Thu, May 08, 2008 at 08:59:41AM -0700, arguellodw wrote: > rsync error: timeout in data send/receive (code 30) at > /home/lapo/packaging/tmp/rsync-2.6.3/io.c(153) You are reaching your idle-time timeout. Either make it larger (e.g. --timeout=360) or upgrade to a newer rsync version that has support for keep-alive messages in the protocol and see if that helps. ..wayne.. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5455] destination files with resource forks now have current mtime
https://bugzilla.samba.org/show_bug.cgi?id=5455 [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #1 from [EMAIL PROTECTED] 2008-05-10 10:28 CST --- Is your rsync patched or stock? If patched, which patches are applied? -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5455] destination files with resource forks now have current mtime
https://bugzilla.samba.org/show_bug.cgi?id=5455 --- Comment #2 from [EMAIL PROTECTED] 2008-05-10 10:31 CST --- One other question: have you modified the meaning of -E (using a popt alias)? Because -E in 3.0.2 doesn't mean what it means in an Apple-modified rsync (a stock rsync uses -AX instead). -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- Please use reply-all for most replies to avoid omitting the mailing list. 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: Rsync won't be quiet
On Tue, May 06, 2008 at 06:27:27PM -0700, Patrick Nolan wrote: > I thought the -q option and the redirection to /dev/null would > keep it quiet under normal circumstances. Apparently not. It should. You shouldn't even require -q since you're not using -v. I tried out your setup, and didn't get any output at all, so I don't know what you're seeing. > Maybe I don't understand "transfer logging". I believe it makes the > client log its actions in "log file". You have that right. It indeed tells the rsync daemon to include info for every transferred file, not just thinks like connects and such. ..wayne.. -- Please use reply-all for most replies to avoid omitting the mailing list. 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: Should no-tweak mode become the default?
Original Message Subject: Re: Should no-tweak mode become the default? From: Wayne Davison <[EMAIL PROTECTED]> To: Matt McCutchen <[EMAIL PROTECTED]> Date: 05/09/2008 11:25 PM > On Thu, May 08, 2008 at 09:34:07PM -0400, Matt McCutchen wrote: >> This is to continue my discussion with Carl [...] about whether >> no-tweak mode should become rsync's default when --inplace is not >> specified. > > I completely reject this idea. The --inplace option is all about data > updating, not attribute updating. Most of the time when I'm copying > things, I want rsync to modify file attributes in-place, and I almost > never want it to modify a file's content in-place. So joining those > two disparate things into a single option would be counter productive. > > I also don't want to change the default because most of the time when a > user is using rsync ad-hoc, it is not being used for a backup. When it > is, the command has usually been setup in a script that we can expect > to have been configured with the right options. So, I think changing > rsync's default would inconvenience users. OK, I can understand that but the problem is there are currently no right options for the daemon to fix this. > Rsync currently supports the full preservation of attributes in an > incremental-backup scenario by copying into an empty hierarchy of files > using one of the --*-dest options (usually --link-dest). Anything > different is a method of copying that rsync does not currently support > (without an extra patch that adds an additional option). It's not that > unreasonable to want to do this, but at the moment if you're using link- > dest into a directory of existing files, you're telling rsync that you > care more about disk space and less about the history of file > attributes (which is a choice that some folks have made when doing > this). I'm not advocating using "--link-dest" in a populated directory. I'm not advocating using "--link-dest" at all. The reason I wanted the default changed is because it would automatically fix current backup systems that are vulnerable to this problem without all the vulnerable folks out there having to update all of their software and settings (just the rsync binary). Truly, though, it's not really a problem in rsync but in the backup systems that made the assumption that rsync's default behavior is appropriate for the job they are giving it. If the default won't be changed then it would be good to at least have an option that can be mandated on the server (daemon) side to not tweak attributes. That way maintainers of existing backup software can fix it if they choose. Not the painless fix that changing the default would be but at least something to reduce this vulnerability in what is probably the most common usage of rsync. > ..wayne.. Thanks, Carl Thompson -- Please use reply-all for most replies to avoid omitting the mailing list. 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: Should no-tweak mode become the default?
On Sat 10 May 2008, Carl E. Thompson wrote: > > The reason I wanted the default changed is because it would > automatically fix current backup systems that are vulnerable to this > problem without all the vulnerable folks out there having to update all > of their software and settings (just the rsync binary). Truly, though, > it's not really a problem in rsync but in the backup systems that made > the assumption that rsync's default behavior is appropriate for the job > they are giving it. > > If the default won't be changed then it would be good to at least have > an option that can be mandated on the server (daemon) side to not tweak > attributes. That way maintainers of existing backup software can fix it > if they choose. Not the painless fix that changing the default would be > but at least something to reduce this vulnerability in what is probably > the most common usage of rsync. My two cents... A backup system should at the least ensure that the last version is correct. If it has to tweak the attributes to do that, it should. If another behaviour is required, then that's the responsibility of the software used; rsync should not have to be changed to do that, and hence the default should not be changed. You don't want --link-dest, but IMHO that solves the problem for any backup software. Dirvish for example works very well in creating a fresh snapshot that's accurate every time without changing older snapshots. Paul Slootman -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5455] destination files with resource forks now have current mtime
https://bugzilla.samba.org/show_bug.cgi?id=5455 [EMAIL PROTECTED] changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID --- Comment #3 from [EMAIL PROTECTED] 2008-05-10 16:05 CST --- Sorry you are right. The problem is with Apple's rsync. I thought that make install would overwrite Apple's rsync with the new one. I even checked with rsync -h, but I must have seen the directory name and thought it was the version number. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- Please use reply-all for most replies to avoid omitting the mailing list. 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: Should no-tweak mode become the default?
On Sat, 2008-05-10 at 10:13 -0700, Carl E. Thompson wrote: > Truly, though, > it's not really a problem in rsync but in the backup systems that made > the assumption that rsync's default behavior is appropriate for the job > they are giving it. My view exactly. > If the default won't be changed then it would be good to at least have > an option that can be mandated on the server (daemon) side to not tweak > attributes. That way maintainers of existing backup software can fix it > if they choose. Right. I changed bug 5448 to request such a daemon option, and I will implement it in my repository as soon as I get the time (or you can even implement it yourself if you like). In the meantime, you could use a daemon with your patch, --inplace refused, and max connections = 1 (to avoid the issues I described in bug 4561 comment 6). Matt signature.asc Description: This is a digitally signed message part -- Please use reply-all for most replies to avoid omitting the mailing list. 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: Should no-tweak mode become the default?
On Sat, 2008-05-10 at 21:04 +0200, Paul Slootman wrote: > A backup system should at the least ensure that the last version is > correct. If it has to tweak the attributes to do that, it should. No one is considering leaving the last version incorrect. The "no-tweak" mode replaces the destination file with a new file that has the correct attributes. > If another behaviour is required, then that's the responsibility of the > software used; rsync should not have to be changed to do that, and hence > the default should not be changed. I agree that the default should not be changed, but I still would like to see the --no-tweak option added because it is a good way to safely resume an interrupted --link-dest backup and get the latest source data. The alternatives are: (1) use --ignore-existing, which misses recent changes to already-copied source files, or (2) move the destination aside and start a new destination with --link-dest to both the old destination and the previous snapshot, which requires more scripting, spends extra time relinking and deleting, and gets messy if multiple interrupts/resumes occur. I intend to maintain a version of rsync supporting the --*tweak options in my repository whether or not Wayne adds the options to the offical rsync. Matt signature.asc Description: This is a digitally signed message part -- Please use reply-all for most replies to avoid omitting the mailing list. 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: Should no-tweak mode become the default?
Original Message Subject: Re: Should no-tweak mode become the default? From: Paul Slootman <[EMAIL PROTECTED]> To: rsync@lists.samba.org Date: 05/10/2008 12:04 PM > ... > My two cents... > A backup system should at the least ensure that the last version is > correct. If it has to tweak the attributes to do that, it should. > If another behaviour is required, then that's the responsibility of the > software used; rsync should not have to be changed to do that, and hence > the default should not be changed. The last backup is always correct in either case. The problem is that all backups including those prior to the last can be rendered unusable (accidentally or not) with the current behavior of rsync. So it's possible for a malicious user that gains access to a computer to destroy _all_ backups of that computer on a remote backup server that uses rsync (and their are many). Fixing rsync to not tweak attributes by default fixes that vulnerability without having to change all of those backup programs to use something else. > You don't want --link-dest, but IMHO that solves the problem for any > backup software. Dirvish for example works very well in creating a fresh > snapshot that's accurate every time without changing older snapshots. "--link-dest" introduces other security problems itself which I have already discussed at length. Trading one vulnerability for others is not a good solution in my opinion which is why I'm not thrilled with "--link-dest" being the answer. > Paul Slootman Thank you, Carl Thompson -- Please use reply-all for most replies to avoid omitting the mailing list. 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: Should no-tweak mode become the default?
On Sat, 2008-05-10 at 15:22 -0700, Carl E. Thompson wrote: > "--link-dest" introduces other security problems itself which I have > already discussed at length. I guess you're referring to item 2 in your original description of bug 5448? Item 2a would be solved by the daemon link-dest parameter that I requested in bug 5449 and plan to implement in my repository. For item 2b: I don't see why putting the real previous backup inside the chroot is worse than putting a hard-linked copy of it inside the chroot, because a compromised daemon could destroy the backup either way. For item 2c: if there are any specific outstanding issues that impede your use of --link-dest, please name them. You are of course welcome to use whatever approach you prefer, but my point is that once bug 5449 is implemented, there is nothing wrong with the daemon-side link-dest approach. Matt signature.asc Description: This is a digitally signed message part -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5457] New: Add a client-side --munge-symlinks option
https://bugzilla.samba.org/show_bug.cgi?id=5457 Summary: Add a client-side --munge-symlinks option Product: rsync Version: 3.0.3 Platform: Other OS/Version: Linux Status: NEW Severity: enhancement Priority: P3 Component: core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] QAContact: [EMAIL PROTECTED] Just as we have worked hard recently to secure daemons from untrusted clients, I think we should try to secure clients that pull data from untrusted daemons. One of the easiest ways a daemon could compromise a client is to send a symlink to a sensitive area and a file under the symlink, e.g., "foo" -> "/home/matt" and "foo/.ssh/authorized_keys". This is essentially the same exploit that necessitates symlink munging for not-purely-chroot daemon modules, just turned around. I would like to be able to prevent this exploit while still storing some representation of the daemon's symlinks in the destination. A natural way to support this would be to add a client-side option --munge-symlinks that munges received symlinks and unmunges sent symlinks just like the daemon parameter. (Of course, the prefix "/rsyncd-munged/" isn't quite accurate for a client, but let's use it anyway for compatibility.) --munge-symlinks would also make it possible to work around bug 4037 when the receiver is not a daemon. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5458] New: -a -X throws error when processing fifo, even if --no-D is specified
https://bugzilla.samba.org/show_bug.cgi?id=5458
Summary: -a -X throws error when processing fifo, even if --no-D
is specified
Product: rsync
Version: 3.0.1
Platform: x86
OS/Version: Mac OS X
Status: NEW
Severity: normal
Priority: P3
Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
QAContact: [EMAIL PROTECTED]
i have a backup script which runs on a central "server" and uses rsync to pull
data across the lan from target hosts. all machines are running osx 10.5.2
(intel), and the same version of rsync (3.0.1, from macports). the script has
been working fine generally for quite some time. however, recently as part of
a project, i created a named pipe in a backup target dir on my laptop. when i
made my weekly sanity check of the backup script's log, i discovered the
following error:
rsync: get_xattr_names: llistxattr("tmp/sf_daemon/fifo",1024) failed: Operation
not permitted (1)
rsync error: some files could not be transferred (code 23) at main.c(1497)
[generator=3.0.1]
in some cases (where very large numbers of files in the same target hierarchy
were involved), this error also appears to have prevented the copying of some
other, unrelated files which i would have expected to have been backed up. i
have evidence of this, but haven't tried to reproduce that specific effect.
although i found this somewhat disturbing, i've come to expect some xattr
flakiness using rsync on osx, so, since i don't need the fifo to be backed up
anyway, i thought in the interests of time that i would just use --no-D to
exclude any such files from the backup, and thus work around the error.
however, that didn't seem to work either ... so here we are. if you want, i
can send you the whole script, etc., but that may be overkill (let me know).
in the meanwhile, this is the offending command (copied from the log file):
executing /opt/local/bin/rsync
-a
--no-D
--delete
--no-whole-file
--out-format=%o %12b %n
-X
-8
-e
ssh
--rsync-path=/opt/local/bin/rsync
--exclude=.*
crow://Users/jpf/tmp
/Volumes/truth/backup/daily/crow/CLASS.5/Users/jpf
i haven't tried backing up the fifo with -X turned off because i care less
about backing up a fifo than i do about picking up the osx-specific metadata
that still lurks in some files' resource forks ...
here's the output of rsync --version:
spock(root):/var/log/backup# rsync --version
rsync version 3.0.1 protocol version 30
Copyright (C) 1996-2008 by Andrew Tridgell, Wayne Davison, and others.
Web site: http://rsync.samba.org/
Capabilities:
64-bit files, 32-bit inums, 32-bit timestamps, 64-bit long ints,
socketpairs, hardlinks, symlinks, IPv6, batchfiles, inplace,
append, ACLs, xattrs, iconv, symtimes
rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you
are welcome to redistribute it under certain conditions. See the GNU
General Public Licence for details.
if you want more details, or the whole script package, please let me know at
the reporter address.
thanks,
-jf
--
Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the QA contact for the bug, or are watching the QA contact.
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
DO NOT REPLY [Bug 5458] -a -X throws error when processing fifo, even if --no-D is specified
https://bugzilla.samba.org/show_bug.cgi?id=5458 [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Comment #1 from [EMAIL PROTECTED] 2008-05-10 23:25 CST --- ls -l of the fifo: prwx-- 1 jpf staff 0 May 10 18:55 fifo the script runs as root, and accesses the target machines over ssh. authentication is via host keys. -- Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the QA contact for the bug, or are watching the QA contact. -- Please use reply-all for most replies to avoid omitting the mailing list. To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html
