innetgr revised netgroup patch against 2.6.0

innetgr.. much easier..

Had a look for the user section but didn't find it in my 15 seconds of 
looking..

--- access.c    2003-07-30 16:12:27.000000000 +1000
+++ ../rsync-2.6.0-Linux/access.c       2004-02-01 23:21:12.000000000 +1100
 <at>  <at>  -22,10 +22,21  <at>  <at> 
   */

 #include "rsync.h"
+#include <netdb.h>

 static int match_hostname(char *host, char *tok)
 {
+       char *netgroup;
+
+       if(strlen(tok)>1){
+               if(tok[0]==' <at> '){
+                       netgroup=tok+1;
+                       if(innetgr(netgroup, host, NULL, NULL)){
+                               return(1);
+                       }
+               }
+       }
        if (!host || !*host) return 0;
        return wildmatch(tok, host);
 }

Re: innetgr revised netgroup patch against 2.6.0

On Sun, Feb 01, 2004 at 11:25:22PM +1100, Travis Freeland wrote:
> 
> innetgr.. much easier..

Much cleaner.  But the code could be tightened further.
I've provided an example.  Note also formatting changes.

Also, we use tabs, not spaces for indent.  If that is your
mailer either fix the config or use text/plain (not x-diff)
attachments.

> Had a look for the user section but didn't find it in my 15 seconds of 
> looking..

Do the user, user+host and the autoconf and I'll consider
this for CVS.

> --- access.c    2003-07-30 16:12:27.000000000 +1000
> +++ ../rsync-2.6.0-Linux/access.c       2004-02-01 23:21:12.000000000 +1100
>  <at>  <at>  -22,10 +22,21  <at>  <at> 
>    */
> 
>  #include "rsync.h"
> +#include <netdb.h>
> 
> 
>  static int match_hostname(char *host, char *tok)
>  {
> +       char *netgroup;
> +

Re: [PATCH] --links-depth for rsync

On Sat, Jan 24, 2004 at 11:09:46PM +0200, Antti Tapaninen wrote:
> 
> Hello,
> 
> about a year ago I ran into situation where there's a "metadirectory"
> containing directories and symlinks to files. There was a need to mirror
> the contents of files and directories gathered via symlinks to this
> metadirectory, regular mirroring of the tree wouldn't do any good.
> 
> The attached patch gives the user ability to define how many symbolic
> links rsync should follow before actually adding it to the file list.
> 
> Any code behaviour without the new parameter is unchanged, I've used the
> previous versions of the patch with rsync 2.5.x for the last year and
> might just as well share the patch. Consider merging the patch for the
> next release, please reply to me directly for additional feedback or
> issues.
> 
> Cheers,
> -Antti

Thanks for updating the patch for those who might have need
of it.  I don't anticipate committing this at this time.

flist.c is in flux and 1.169 is in the midst of that so you
might want to rediff against rsync 2.6.1 when that is
released.

--

-- 
________________________________________________________________

Re: --daemon for clients

On Thu, Jan 29, 2004 at 04:58:45PM +0100, Stefan Hoefer wrote:
> Hello
> 
> I have the following situation: one perl script opens a TCP connection to
> a remote server running another perl script. The file descriptors on both
> sides are mapped to STDIN and STDOUT file descriptors. After some
> "talking", I would like to start rsync using the "exec" call on both sides
> of the connection, with both rsync partners using the existing connection
> (inherited on STDIN and STDOUT). On the server side, this is no problem (I
> can use the --daemon switch). Is there any way rsync can perform this on
> the client side, too?
> 
> Thanks for any help

I have a vague recollection that of there being a patch that
would allow rsync to connect to open file descriptors. 

-- 
________________________________________________________________
	J.W. Schultz            Pegasystems Technologies
	email address:		jw <at> pegasys.ws

		Remember Cernan and Schmitt
--

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

[PATCH] --one-file-system and automounter

We use rsync in a Linux installation script. First, the root filesystem
of another machine on the network is cloned with "rsync -axzH", and then
a few files are updated to give the clone its own identity. This works
fine, but last week, the Postfix mailer daemon on a new machine refused
to start because some lock files had a link count of 2. It turned out
that rsync had created two copies of the root filesystem, and
hard-linked all files (-H option), because the original machine had a
"bind" mount at the time of the clone. The bind mount has the same
device number as the root, but it is inside an automount directory, so
it should have been skipped by the -x option.

The automounter uses a program map file to NFS-mount the root filesystem
of other machines on the network. When the machine itself is accessed, a
"bind" mount is used instead of NFS as an optimization. For example,
when you have the automounter on /mnt/net, and a bind mount to the
machine itself (kemi), the device numbers are:

$ stat -c '%4D %n' /mnt /mnt/net /mnt/net/kemi
 302 /mnt
  19 /mnt/net
 302 /mnt/net/kemi

The followin rsync invocation shows that the "kemi" subdirectory is
*not* skipped by the -x option, but later by the --exclude option:

$ rsync -axvvn --exclude=kemi /mnt /tmp/dest
expand file_list to 4000 bytes, did move
excluding directory mnt/net/kemi because of pattern kemi
delta-transmission disabled for local transfer or --whole-file
total: matches=0  tag_hits=0  false_alarms=0 data=0

rsync_failed

Hello

I came about the following phenomeon when
the server ( dell poweredge 2650 ) is rsyncing to
the same and remote server.
the connection was close and copying the file didn't finish
yet.

Network Topology:

Dell2650 ----L2SW---L3SW---Dell2650

L2SW: Procurve4108gl
L3SW: BigIron15000

when the unexpected failed come about, the ping
of end-to-end is no problem, and telnet is O.K
when I look at the output message of
" netstat -i " the statistics of errors and collision
packet was pointing to " 0 " so it looks like no problem at all.

I'll put the log

------------------------------------------------------------
# ./bin/PD_rsync.sh 
 rsync: error writing 4096 unbuffered bytes - exiting: Broken pipe
 rsync error: error in rsync protocol data stream (code 12) at io.c(463)
 rsync: writefd_unbuffered failed to write 4092 bytes: phase 
"unknown":

Re: [PATCH] --one-file-system and automounter

On Mon, Feb 02, 2004 at 12:01:12PM +0100, Dick Streefland wrote:
> The attached patch for rsync-2.6.0 moves the cross-filesystem check to
> just before a directory is traversed. This obsoletes the function
> skip_filesystem() to test the parent directory. The mount point itself
> is still included, but its contents is skipped.

Thanks for the patch.  This is already fixed in the CVS version of
rsync, but it was changed in a slightly different way that I thought I'd
mention.  When using the --copy-links (-L) or the --copy-unsafe-links
options, a symlink that points to a file on a different filesystem has
been traditionally skipped by rsync.  Your patch would change this so
that rsync copies these files.

I had been thinking about this distinction (due to my having recently
patched this), and am wondering, is the old behavior really what we
want?  I can see arguments both ways:  that a file-name (a symlink that
we asked to be expanded to a file) on the exclusive filesystem is being
skipped (which is bad), and that a file that was not contained by the
exclusive filesystem was skipped (which is good).  What do folks think?

..wayne..
--

-- 
To unsubscribe or change options: http://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

cygwin announcement fwd: rsync-2.6.0-1

Here it goes...
actually already on the mirrors from some time and easily installable 
from http://cygwin.com/setup.exe

From: Lapo Luchini <lapo <at> lapo.it>
Subject: Updated: rsync-2.6.0-1
Newsgroups: gmane.os.cygwin.announce
Date: 2004-02-01 22:26:40 GMT

I have uploaded version 2.6.0-1 of the open source utility that provides
fast incremental file transfer.
It needed no patch at all.
See website for the many changes: http://rsync.samba.org/

If you have questions or comments, please send them to the Cygwin
mailing list at:  cygwin <at> cygwin.com .  I would appreciate if you would
use this mailing list rather than emailing me directly.  This includes
ideas and comments about the setup utility or Cygwin in general.

If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

rsync 2.6.0 causing incredible load on Linux 2.4.x?

Hi everyone. Has anyone experienced rsync 2.6.0 causing huge amounts of
system load? Especially on Linux 2.4?

We recently upgraded our "push" machine to rsync 2.6.0 and the next push
that went out (rsyncing about 3GB of data to 15 servers sequentially
over gigabit ethernet) caused the box to hit 110.59. We only know the
load because snmpd was still working, but nothing else in userspace was.

We couldn't see if rsync was causing this.. but upon reboot we regressed
to 2.5.7 (the rpm install version from RH8.0), and there was no more
load problem. We do know that the files did get updated on 2 of the 15
servers, though not completely on the second one.

Its entirely possible that this was something else.. but the box had
never locked up like this, and it happened precisely after rsync was
upgraded. I haven't been able to reproduce it in our test environment,
and I'm not too keen on taking the box down again just to confirm this.
However, I wouldn't mind doing so if it meant fixing a major bug in
rsync. We love rsync here and would be served quite well by the new
from_list option.

Oh, and one other thing... whats up with this:

-rwxr-xr-x    1 root     root      1294978 Jan 30 12:54 /usr/local/rsync-2.6.0/bin/rsync
-rwxr-xr-x    1 root     root       216785 Dec  3 20:42 /usr/bin/rsync

Has rsync really added 5 times as many features? More error checking?
Just curious really. They're both stripped binaries in case thats what
you were thinking. ;)

Re: rsync 2.6.0 causing incredible load on Linux 2.4.x?

On Mon, Feb 02, 2004 at 02:01:15PM -0800, Clint Byrum wrote:
> Hi everyone. Has anyone experienced rsync 2.6.0 causing huge amounts of
> system load? Especially on Linux 2.4?
> 
> We recently upgraded our "push" machine to rsync 2.6.0 and the next push
> that went out (rsyncing about 3GB of data to 15 servers sequentially
> over gigabit ethernet) caused the box to hit 110.59. We only know the
> load because snmpd was still working, but nothing else in userspace was.
> 
> We couldn't see if rsync was causing this.. but upon reboot we regressed
> to 2.5.7 (the rpm install version from RH8.0), and there was no more
> load problem. We do know that the files did get updated on 2 of the 15
> servers, though not completely on the second one.
> 
> Its entirely possible that this was something else.. but the box had
> never locked up like this, and it happened precisely after rsync was
> upgraded. I haven't been able to reproduce it in our test environment,
> and I'm not too keen on taking the box down again just to confirm this.
> However, I wouldn't mind doing so if it meant fixing a major bug in
> rsync. We love rsync here and would be served quite well by the new
> from_list option.

There aren't too many things that would account for this.
The only one i can think of is an exclude pattern that
causes pathalogical behavior with the new pattern matching
code.  2.6.0 also defaults to ssh and if you have ssh doing
compression by default that could affect it.
You don't show your command-line so nothing else comes to
mind.