bug in permissions on symlinks
I see rsync has this in rsync.h #ifndef HAVE_LCHOWN #define lchown chown #endif So on Linux lchown changes the ownership on a symlink, whereas chown on a symlink will change the ownership of its target. man lchown says In versions of Linux prior to 2.1.81 (and distinct from 2.1.46), chown did not follow symbolic links. Since Linux 2.1.81, chown does follow symbolic links, and there is a new system call lchown that does not follow symbolic links. Since Linux 2.1.86, this new call (that has the same semantics as the old chown) has got the same syscall number, and chown got the newly introduced number. I'm not at all sure the way we're calling it is correct. There could be systems where there is no lchown, but chown on a symlink still follows the link. I seem to remember Solaris behaving this way, but I'm not sure if that is the system call or just the chown command. In this case we might be accidentally setting the ownership of the destination. On such a machine we should just not set the ownership of the symlink at all. (To be really tricky I guess we could seteuid() before creating the link.) David, do you have a machine that behaves like this? -- Martin
Re: rsync 2.5.0 bit length overflow
On 30 Nov 2001, Thomas J Pinkl [EMAIL PROTECTED] wrote: I'm seeing: bit length overflow code 4 bits 6-7 in the output of rsync 2.5.0 between two Red Hat Linux systems. One is RH 6.1 (kernel 2.2.19-6.2.1, glibc 2.1.3-22), the other is RH 7.2 (kernel 2.4.9-13, glibc 2.2.4-19). Both systems have rsync 2.5.0. On the RH 6.1 box, I run this command: rsync -v --stats -az -e rsh -H --exclude-from FILE /some/dir/. rh72:/some/dir/. Anyone have a idea of what this means? That comes from zlib. It seems like a harmless warning. Is it reproducible? Are the file trees transferred correctly? -- Martin
Bug in rsyncd 2.5.0 while handling config file string values
I compiled and tried rsync 2.5.0 but could not get the server
running. loadparm.c:string_set() now calls free() which it did not do
in 2.4.6 and this free() tries to free memory that was not allocated
with malloc.
Here is a gdb run (done after adding return before fork() in
become_daemon) which shows where it crashes and what my minimal config
file for demonstrating the bug was. The config file only had one line
which was: uid = foobar
/usr/local/src/rsync/rsync-2.5.0:gdb ./rsync
GNU gdb 5.0.90-cvs (MI_OUT)
(gdb) r --daemon --config=../rsyncd.conf
Starting program: /usr/local/src/rsync/rsync-2.5.0/./rsync --daemon
--config=../rsyncd.conf
Program received signal SIGSEGV, Segmentation fault.
0x4009cb2d in free () from /lib/libc.so.6
(gdb) bt
#0 0x4009cb2d in free () from /lib/libc.so.6
#1 0x08061286 in string_set (s=0x807ace4, v=0x808b374 foobar) at loadparm.c:400
#2 0x08061a20 in lp_do_parameter (snum=-2, parmname=0x808b370 uid,
parmvalue=0x808b374 foobar)
at loadparm.c:647
#3 0x08061b8b in do_parameter (parmname=0x808b370 uid, parmvalue=0x808b374
foobar) at loadparm.c:678
#4 0x0806057b in Parameter (InFile=0x808b200, pfunc=0x8061b58 do_parameter, c=0) at
params.c:405
#5 0x080606a4 in Parse (InFile=0x808b200, sfunc=0, pfunc=0x8061b58 do_parameter) at
params.c:461
#6 0x08060848 in pm_process (FileName=0xb80c ../rsyncd.conf, sfunc=0,
pfunc=0x8061b58 do_parameter) at params.c:540
#7 0x08061cc7 in lp_load (pszFname=0x808b1c0 ../rsyncd.conf, globals_only=1) at
loadparm.c:747
#8 0x08063095 in daemon_main () at clientserver.c:506
#9 0x0805225a in main (argc=0, argv=0x0) at main.c:817
#10 0x400476ef in __libc_start_main () from /lib/libc.so.6
(gdb) select 1
(gdb) p s
$1 = (char **) 0x807ace4
(gdb) p *s
$2 = 0x807680c nobody
(gdb) p sDefault
$3 = {name = 0x0, path = 0x0, comment = 0x0, lock_file = 0x8076813
/var/run/rsyncd.lock,
read_only = 1, list = 1, use_chroot = 1, transfer_logging = 0, ignore_errors = 0,
uid = 0x807680c nobody, gid = 0x807680c nobody, hosts_allow = 0x0, hosts_deny =
0x0,
auth_users = 0x0, secrets_file = 0x0, strict_modes = 1, exclude = 0x0, exclude_from
= 0x0,
include = 0x0, include_from = 0x0, log_format = 0x80767f3 %o %h [%a] %m (%u) %f
%l,
refuse_options = 0x0, dont_compress = 0x80767c0 *.gz *.tgz *.zip *.z *.rpm *.deb
*.iso *.bz2 *.tbz,
timeout = 0, max_connections = 0, ignore_nonreadable = 0}
(gdb) shell cat ../rsyncd.conf
uid = foobar
(gdb)
--
Heikki Vatiainen * [EMAIL PROTECTED]
Tampere University of Technology * Tampere, Finland
rsync internationalization?
Does anybody care about supporting non-English message locales in rsync? (Do all sysadmins speak English? :-) Would anybody contribute translations if we had the framework? -- Martin
Re: Bug in rsyncd 2.5.0 while handling config file string values
On 2 Dec 2001, Heikki Vatiainen [EMAIL PROTECTED] wrote: I compiled and tried rsync 2.5.0 but could not get the server running. loadparm.c:string_set() now calls free() which it did not do in 2.4.6 and this free() tries to free memory that was not allocated with malloc. Thankyou for the report. This should be fixed in 2.5.1pre1, which is available from the usual site. -- Martin
Re: rsync 2.5.0 bit length overflow
Martin Pool wrote: On 30 Nov 2001, Thomas J Pinkl [EMAIL PROTECTED] wrote: I'm seeing: bit length overflow code 4 bits 6-7 in the output of rsync 2.5.0 between two Red Hat Linux systems. One is RH 6.1 (kernel 2.2.19-6.2.1, glibc 2.1.3-22), the other is RH 7.2 (kernel 2.4.9-13, glibc 2.2.4-19). Both systems have rsync 2.5.0. On the RH 6.1 box, I run this command: rsync -v --stats -az -e rsh -H --exclude-from FILE /some/dir/. rh72:/some/dir/. Anyone have a idea of what this means? That comes from zlib. It seems like a harmless warning. Is it reproducible? Are the file trees transferred correctly? I see a similar warning every night. In my case the src is 2.5.0 and dest is 2.4.6pre1. I'll upgrade the dest and see if it still happens. It only happens on certain dirs -- I'm guessing dirs with large number of files, but I'm not sure yet... eric bash$ grep bit length overflow */*errors |wc 12743822 54680
Re: rsync-2.5.0 patch for make check bug
On 30 Nov 2001, Tom Schmidt [EMAIL PROTECTED] wrote: Attached is a patch for rsync 2.5.0 to fix the make check option. Thankyou, commmitted. -- Martin
Re: Why does one of there work and the other doesn't
On 30 Nov 2001, Randy Kramer [EMAIL PROTECTED] wrote: I am not sure which end the 100 bytes per file applies to, and I guess that is the RAM memory footprint?. Does rsync need 100 bytes for each file that might be transferred during a session (all files in the specified directory(ies)), or does it need only 100 bytes as it does one file at a time? At the moment that is 100B for all files to be transferred in the whole session. This is a big limit to scalability at the moment, and a goal of mine is to reduce it to at most holding file information from a single directory in memory. -- Martin
Re: --no-detach option?
I'm starting to think we need to not show all the options in the default --help output. I think perhaps the default should be to show the commonly-used options (-avz, --include, : vs ::) and then have --help-options and so on for more details. It is getting quite ridiculous. There's one or two packages that do this, but I can't remember which ones right at the moment. -- Martin
rsync-2.5.1pre1 with -F option
I compiled and tried rsync 2.5.1pre1.
RSYNC with -F option dumps a core.
% gdb ./rsync
GNU gdb 5.1
(gdb) r -F
Starting program: /work/rsync-2.5.1pre1/./rsync -F
Program received signal SIGSEGV, Segmentation fault.
write_batch_argvs_file (orig_argc=-2, argc=0, argv=0x0) at batch.c:153
153if ( !strcmp(argv[i],-F) ){ /* safer to change it here than script*/
...
-- ayamura
Socket address problems with 2.5.1pre1
The problem shows in the following log snippet. The numeric address of
the peer (localhost in this case) is garbage.
rsyncd[32671]: reverse name lookup failed
rsyncd[32671]: rsync: forward name lookup for failed: Name or service not known
rsyncd[32671]: rsync on debian/ from UNKNOWN (::10fa:ffbf:a426:608%5)
rsyncd[32671]: wrote 616 bytes read 70 bytes total size 143069
I am using linux 2.4.10-pre14 with GNU C lib 2.2.4. To be precise, the
libc comes with Debian unstable distribution and its exact version is
2.2.4-6. The Debian's changelog says for 2.2.4-5:
* Pulled from CVS as of Oct 27, 2001:
- Includes fnmatch fix upstream.
- strxfrm fix.
- dlfcn fix for C++ program usage.
- ENABLE_NLS fixes for various functions (doesn't affect us, sinceit is
mainly meant for non-nls builds).
- IPv6 reverse lookup fixes.
...
However, I think the problem may not be specific to this C lib
version.
I applied this patch to socket.c:client_addr() to experiment a bit:
--- socket.c.orig Tue Nov 27 08:01:05 2001
+++ socket.cSun Dec 2 21:04:20 2001
@@ -555,7 +555,7 @@
**/
char *client_addr(int fd)
{
- struct sockaddr ss;
+ struct sockaddr_storage ss;
int length = sizeof(ss);
static char addr_buf[100];
static int initialised;
@@ -564,11 +564,14 @@
initialised = 1;
- if (getpeername(fd, ss, length)) {
+ if (getpeername(fd, (struct sockaddr *)ss, length)) {
exit_cleanup(RERR_SOCKETIO);
}
- getnameinfo(ss, length,
+syslog(LOG_INFO, length %d, sizes: sockaddr %u, sockaddr_storage %u,
+ length, sizeof (struct sockaddr), sizeof (struct sockaddr_storage));
+
+ getnameinfo((struct sockaddr *)ss, length,
addr_buf, sizeof(addr_buf), NULL, 0, NI_NUMERICHOST);
return addr_buf;
}
The patch replaces struct sockaddr with struct sockaddr_storage and
prints some length information into the syslog. The idea of using
struct sockaddr_storage came from KAME's patch for 2.4.6 and Itojun's
AF-independent application paper at
http://www.kame.net/newsletter/19980604/
The results were:
rsyncd[32707]: length 28, sizes: sockaddr 16, sockaddr_storage 128
rsyncd[32707]: reverse name lookup failed
rsyncd[32707]: rsync: forward name lookup for failed: Name or service not known
rsyncd[32707]: rsync on debian/ from UNKNOWN (:::127.0.0.1)
rsyncd[32707]: wrote 616 bytes read 70 bytes total size 143069
The forward name lookup still fails but at least the numeric address
is correct. It looks like the trucation getpeername() has to do goes
unnoticed and this causes problems with output from getnameinfo(). In
message [EMAIL PROTECTED] Martin wrotes
that:
I have merged the KAME.net IPv6 patch onto the track-kameipv6
branch. It compiles and seems to work but is not yet updated to fit
into HEAD (i.e. 2.4.7pre).
There are some issues that need to be addressed: in particular I
think the patch makes more assumptions about having a modern sockets
interface than we can get away with on all our systems.
I guess this is one of the issues that need addressing?
--
Heikki Vatiainen * [EMAIL PROTECTED]
Tampere University of Technology * Tampere, Finland
Re: command= and arbitrary keys...
If it's what I suspect, answer these questions: Are all the keys different? (You have to say yes here.) Yes, should have thought to make that clear initially. Are you using an ssh-agent at the calling end? (You want no here, and a -i keyfile in the ssh call.) Nope. Very irritating. This is, to my mind, a great failing in ssh: if you have an agent then the -i option is as good as ignored - any keys in the agent will still be considered for use in the connection. To this end I have a script called nphssh here: Great tip, thanks. Dave
Re: command= and arbitrary keys...
Hi all, I've asked this question before, but I was never able to fix the problem, and now it's back again and I'd like to try and resolve it. I have an authorized_keys file with about twenty keys, most of which are prefaced with command=/usr/bin/rsync If I put my host key at the top of the authorized_keys file, I can connect without a problem. If it gets put near the bottom, ssh seems to pick an arbitrary key, accepts my passphrase, and starts to run one of the rsync commands. One of the thoughts was that because many of the hosts are running openssh-2.3 and not the latest. If it's likely this is the problem, I'll upgrade them all, but there are a lot of hosts, and I'd rather not do it if it isn't necessary.. Other ideas, perhaps? Thanks, Dave Well, I read here that it accepts your passphrase - how does this work, then? If you use keys, you need no passphrase - if you use passwords, it won't do the commands in ~/.ssh/authorized_keys2. And to turn off the agent as Cameron Simpson told previously, it's sufficient to clear the environment variable SSH_AUTH_SOCK (at least on UNIX). Hope that helps! Regards, Phil
Re: Files in use
On 28 Nov 2001, [EMAIL PROTECTED] wrote: Hello all I have been watching and learning from this list for a couple of months now.. Here is my first question. If rsync comes across a file that is in use by somebody. What happens? Does the file get skipped or does the entire transfer halt? rsync tries to open the file using the operating system's normal mechanism. If the OS allows it to be opened while it is in use, then that's what will happen -- this may result in rsync seeing a file which is in an inconsistent state. (This is just the same as cp, tar, etc.) To avoid this, you need to either arrange your own interlock between the process using the file and rsync (e.g. by stopping the daemon during backup), or see if your OS has mandatory file locks. On the destination rsync always writes to a temporary file and then renames it. This operation is atomic on Unix, so processes will either see the old file or the new one. Processes that have the old file open it will continue to use it even after it's been unlinked. Note that if you use --partial then rsync will perform this rename when the transfer is cancelled even if the file is only partially transferred. -- Martin
