extension of rsync on crypted files

2002-06-27 Thread Mikael moshir
Hello,
I am a french student and I have written a technical report on an extension of the rsync algorithm to crypted files.I started from the situation of a client machine A user who doesn't wish to save an original file v0 and its successive versions v1 v2 v3 ... on a distant server B but rather to save the private ciphering of these files on the server. Let C be the cipher algorithm and xi=C(vi) the ciphering of the clear file vi, the client A wishes to save x0, x1, x2... on the server B and not v0,v1 This situation arrises for secured files backup providers which offer an option of a secured and confidential file's history backup - a client can keep the history of a file. 
Trying to use rsync here is not a good solution because the ciphering transformation on file versions disperses the correlations between them and then when Rsync tries to localize common blocks between ciphered versions, he hardly ever finds and the compression resulting from the common sequences factorisation can't happen.
My method proposes a solution to this problem and allows to save ciphered versions on a distant server with costs (storage, communications, algorithmic complexity) comparable to rsync.I want to know if anyone finds my work of interest and if anyone of you knows if such a problem have beenadressed before. I keep the documentation of my article (in french but i am working on an english translation) for anyone who would have more details.Thank you!
Ps: sorry for my small english skill.Yahoo! Mail -- Une adresse @yahoo.fr gratuite et en fran├žais !

RE: Largest file system being synced

2002-06-27 Thread Granzow, Doug (NCI)


I am currently syncing 1.3 terabytes of files using rsync.  This is spread
across about 12 filesystems all on the same server.  Unfortunately we are
planning to move away from rsync because it is taking too long to run and it
takes up too much memory (some of the rsync processes take up 1.5 GB of RAM
-- if we get two of those running at once, the server dies).  We have been
very happy with rsync but it has recently reached a critical mass where it
can no longer handle the number of files we are trying to sync in a timely
manner.   But if you are looking for the largest rsync site, we might be a
contender. :)

FYI, we also use (and plan to continue to use) rsync for several smaller
mirroring operations.


 I'm interested in large file system replication capability of 
 rsync. Could
 some of you people who use it share how large their mirroring 
 is? What would
 you say is the largest sized site being mirrored using rsync?
 
 Thanks!
 
 JP

-- 
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: extension of rsync on crypted files

2002-06-27 Thread Ben Escoto

 MM == mmikaelfr  iso-8859-1
 wrote the following on Thu, 27 Jun 2002 15:26:51 +0200 (CEST)

  MM I am a french student and I have written a technical report on
  MM an extension of the rsync algorithm to crypted files.  I started
  MM from the situation of a client machine A user who doesn't wish
  MM to save an original file v0 and its successive versions v1 v2 v3
  MM ... on a distant server B but rather to save the private
  MM ciphering of these files on the server. Let C be the cipher
  MM algorithm and xi=C(vi) the ciphering of the clear file vi, the
  MM client A wishes to save x0, x1, x2... on the server B and not
  MM v0,v1 This situation arrises for secured files backup
  MM providers which offer an option of a secured and confidential
  MM file's history backup - a client can keep the history of a file.

Sounds interesting.  Do you mean that the server holds multiple
versions of the file so older versions can also be restored?  Is this
done by storing checksum information about older files on the client?
Also, if I understood right, isn't this a bit different from rsync
since on the server you wouldn't see the files x0, x1, x2, ... but
rather the files x0, d1, d2, ... where d1 is a some kind of delta from
x0 to x1 (or I suppose an encrypted delta from v0 to v1)?  Or have I
misunderstood your system?


--
Ben Escoto



msg04442/pgp0.pgp
Description: PGP signature


RE: Largest file system being synced

2002-06-27 Thread Breedlove, Robert

What are you moving to?

-Original Message-
From: Granzow, Doug (NCI) [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 27, 2002 8:31 AM
To: '[EMAIL PROTECTED]'
Subject: RE: Largest file system being synced



I am currently syncing 1.3 terabytes of files using rsync.  This is spread
across about 12 filesystems all on the same server.  Unfortunately we are
planning to move away from rsync because it is taking too long to run and it
takes up too much memory (some of the rsync processes take up 1.5 GB of RAM
-- if we get two of those running at once, the server dies).  We have been
very happy with rsync but it has recently reached a critical mass where it
can no longer handle the number of files we are trying to sync in a timely
manner.   But if you are looking for the largest rsync site, we might be a
contender. :)

FYI, we also use (and plan to continue to use) rsync for several smaller
mirroring operations.


 I'm interested in large file system replication capability of 
 rsync. Could
 some of you people who use it share how large their mirroring 
 is? What would
 you say is the largest sized site being mirrored using rsync?
 
 Thanks!
 
 JP

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

-- 
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: documentation bug for --daemon use chroot in conjunction with -o and -g

2002-06-27 Thread Dave Dykstra

On Tue, Jun 25, 2002 at 05:11:40PM -0400, pyxl wrote:
 Well,
 
 Looking at the source for 2.5.5, I'm only seeing mention of it under the 
 --numeric-ids flag in rsync(1); --owner doesn't make mention of it at all.
 What you quoted must be in CVS (I'd look, but I don't know how to do a
 remote CVS checkout yet, and am too lazy to learn at this moment).

I researched it at 
http://cvs.samba.org/cgi-bin/cvsweb/rsync/rsync.yo

and see that it was taken out of the --owner item in rsync 2.5.1 by change
1.86:
http://cvs.samba.org/cgi-bin/cvsweb/rsync/rsync.yo.diff?r1=1.85r2=1.86

That patch had many wording changes to the man page, suggested by somebody
from the community, and I think it was wrong to drop this info.   I will
fix it for the next release, but I don't want to use your suggested wording
because I don't want to make it sound like we're recommending that people
do use chroot = no; instead, I will just inform them of the consequences.

- Dave Dykstra



 Here's a patch for the changes to those man pages against the 2.5.5 release 
 tree.  It changes --owner in rsync(1) and use chroot in rsyncd.conf(5).
 
 diff -uNr rsync-2.5.5/rsync.1 rsync-2.5.5_update/rsync.1
 --- rsync-2.5.5/rsync.1   Wed Feb  6 16:21:19 2002
 +++ rsync-2.5.5_update/rsync.1Tue Jun 25 16:28:52 2002
  -488,7 +488,9 
 .IP \fB-o, --owner\fP 
 This option causes rsync to set the owner of the
 destination file to be the same as the source file\.  On most systems,
 -only the super-user can set file ownership\.  
 +only the super-user can set file ownership\.  For this to work when one
 +side is an rsync daemon, the module must be configured with use chroot = 
 no
 +or else only numeric uid and gid will be provided\.
 .IP 
 .IP \fB-g, --group\fP 
 This option causes rsync to set the group of the
 diff -uNr rsync-2.5.5/rsyncd.conf.5 rsync-2.5.5_update/rsyncd.conf.5
 --- rsync-2.5.5/rsyncd.conf.5 Fri Aug 31 04:12:35 2001
 +++ rsync-2.5.5_update/rsyncd.conf.5  Tue Jun 25 16:46:51 2002
  -144,7 +144,9 
 of not being able to follow symbolic links outside of the new root path
 when reading\.  When use chroot is false, for security reasons
 symlinks may only be relative paths pointing to other files within the
 -root path, and leading slashes are removed from absolute paths\.  The
 +root path, and leading slashes are removed from absolute paths\.  Note
 +that for --owner (-o) and --group (-g) client side options to function,
 +use chroot must be set to false for the module\.  The
 default for use chroot is true\.
 .IP 
 .IP \fBmax connections\fP 

-- 
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: Largest file system being synced

2002-06-27 Thread Granzow, Doug (NCI)

We're planning to move to Veritas Volume Replicator.  It has the advantage
of working at the filesystem level, so whenever a write is done on the
primary site, the same write is automatically done on the mirror site.  For
what I am doing here, it should (hopefully!) work a lot better than rsync
because it runs continuously, and it doesn't have the startup overhead of
building a file list, which is the biggest problem with rsync when you are
dealing with large groups of files.



 -Original Message-
 From: Breedlove, Robert [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, June 27, 2002 11:46 AM
 To: Granzow, Doug (NCI); '[EMAIL PROTECTED]'
 Subject: RE: Largest file system being synced
 
 
 What are you moving to?
 
 -Original Message-
 From: Granzow, Doug (NCI) [mailto:[EMAIL PROTECTED]]
 Sent: Thursday, June 27, 2002 8:31 AM
 To: '[EMAIL PROTECTED]'
 Subject: RE: Largest file system being synced
 
 
 
 I am currently syncing 1.3 terabytes of files using rsync.  
 This is spread
 across about 12 filesystems all on the same server.  
 Unfortunately we are
 planning to move away from rsync because it is taking too 
 long to run and it
 takes up too much memory (some of the rsync processes take up 
 1.5 GB of RAM
 -- if we get two of those running at once, the server dies).  
 We have been
 very happy with rsync but it has recently reached a critical 
 mass where it
 can no longer handle the number of files we are trying to 
 sync in a timely
 manner.   But if you are looking for the largest rsync site, 
 we might be a
 contender. :)
 
 FYI, we also use (and plan to continue to use) rsync for 
 several smaller
 mirroring operations.
 
 
  I'm interested in large file system replication capability of 
  rsync. Could
  some of you people who use it share how large their mirroring 
  is? What would
  you say is the largest sized site being mirrored using rsync?
  
  Thanks!
  
  JP

-- 
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: extension of rsync on crypted files

2002-06-27 Thread jw schultz

On Thu, Jun 27, 2002 at 03:26:51PM +0200, Mikael moshir wrote:
 
 Hello,
 
 I am a french student and I have written a technical
 report on  an extension of the rsync algorithm to crypted
 files.  I started from the situation of a client machine A
 user who doesn't wish to save an original file v0 and its
 successive versions v1 v2 v3 ... on a distant server B but
 rather to save the private ciphering of these files on the
 server. Let C be the cipher algorithm and xi=C(vi) the
 ciphering of the clear file vi, the client A wishes to
 save x0, x1, x2... on the server B and not v0,v1 This
 situation arrises for secured files backup providers which
 offer an option of a secured and confidential file's
 history backup - a client can keep the history of a file. 
 
 Trying to use rsync here is not a good solution  because
 the ciphering transformation on file versions disperses
 the correlations between them and then when Rsync tries to
 localize common blocks between ciphered versions, he
 hardly ever finds and the compression resulting from the
 common sequences factorisation can't happen.
 
 My method proposes a solution to this problem and allows
 to save ciphered versions on a distant server with costs
 (storage, communications, algorithmic complexity)
 comparable to rsync.  I want to know if anyone finds my
 work of interest and if anyone of you knows if such a
 problem have been adressed before.  I keep the
 documentation of my article (in french but i am working on
 an english translation) for anyone who would have more
 details.  Thank you!
 
 Ps: sorry for my small english skill.

That skill is sufficient but you need shorter lines (hit the
carriage return).

I will try to clarify since it looks like this hasn't been
understood.

terminology:
plaintext == unencrypted file
ciphertext == encrypted file
client == local system
server == distant system

You have a client with plaintext files.  The server provides
access to multiple versions of files but on the server they are
encrypted.

As you have described it this sounds a great deal like a SCM
(source code management) system with encryption thrown in.

Presumably the encryption is because the user doesn't wish
to trust the owner of the server with maintaining his
privacy.

Judging by several recent threads there are quite a few
people who could be interested.  I suggest you look in the
list archives for the word encrypt.  You speak of a
technical report that i assume actually discusses the
method.  If you can distill that down (cut out the academic
verbiage and focus on actual method sans proofs) to a couple
of hundred words or less you could post it for discussion.
A link to source code wouldn't hurt.  We focus here on what
actually works and even broken code speaks louder than
speculation.


-- 

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 digest, Vol 1 #778 - 11 msgs

2002-06-27 Thread Catalino Cuadrado

I haven't gotten it to work successfully, I'm still struggling with the
same setgroups error that you are. However, I can tell you what I have
tried. So far I have rsync configured to run in --daemon mode using the
command: sudo rsync --daemon I can prompt it for a list of modules, but
when I go to copy a module, I get the error @ERROR: setgroups failed.
I can copy locally, from one HD to another, but I can't get it to copy
over the network, even using the sudo rsync ipaddress:/Filename / method.
So it's been kind of aggrivating. I'm thinking it has to do with the fact
that rsync needs to be run locally, and you're running it from a remote
server... If there's a way to trick the system into thinking that the
rsync daemon is running as root on the local machine, that would be ideal.
Unfortunately, I don't know enough about the UNIX side of things to get
that far.
-Tito

  Message: 5
 Date: Thu, 27 Jun 2002 10:08:00 -0600
 From: [EMAIL PROTECTED]
 Subject: rsync 2.5.5 and Mac OS X
 To: [EMAIL PROTECTED]
 Reply-To: [EMAIL PROTECTED]

 Greetings,

 Has anyone successfully compiled rsync 2.5.5 under Mac OS X (not
 Server), and actually have it work fully?

 I'm in a position where I'm trying to setup an automated nightly remote
 backup between and Cobalt Raq4 (running a variant of Redhat Linux) and a
 Mac running OS X 10.1.5 with the latest development tools installed.  As
 has been pointed out previously on the list, one has to ./configure with
 the --disable-ipv6 flag to even get it to compile at all.  However
 there's further issues when trying to back up to the Mac running rsync
 in inetd --daemon mode.

 When I issue the following command:

 ---
 rsync -avz /home [EMAIL PROTECTED]::raqbackup
 ---

 I get the following error:

 ---
 @ERROR: setgroups failed
 rsync: connection unexpectedly closed (79 bytes read so far)
 rsync error: error in rsync protocol data stream (code 12) at io.c(150)
 ---

 On the server end, rsyncd.log shows the following:

 ---
 2002/06/27 09:50:03 [19768] setgroups failed: Invalid argument
 ---

 I've had luck running rsync 2.5.2 running through ssh, but because I
 can't get it to retain the user/group ownership settings it's completely
 useless as 'mirrored' backup unless I spent the next month hand
 restoring the file ownership's by hand.  The man pages noted this
 limitation, unless running as super-user, which I haven't been able to
 get to work (use chroot=yes in rsyncd.conf doesn't seem to do it)

 If anyone has been able to get Mac OS X 10.1.5 running as a rsync server
 in such a fashion, I'd really appreciate hearing from you.

 For debuging purposes, my current rsyncd.conf is:

 ---
 use chroot = yes
 max connections = 1
 syslog facility = local5
 motd file = /etc/rsyncd.motd
 log file = /var/log/rsyncd.log
 pid file = /var/run/rsyncd.pid
 lock file = /var/run/rsync.lock

 [raqbackup]
 path = /Volumes/Eeyore/RaqBackup
 comment = Raq Backup Directory
 auth users = xxx
 secrets file = /etc/rsyncd.secrets
 ---

 and the destination directory is set as:

 ---
 drwxrwxrwx2 nobody  nobody  24 Jun 26 22:09 RaqBackup
 ---


-- 
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: Largest file system being synced

2002-06-27 Thread jw schultz

On Thu, Jun 27, 2002 at 02:21:08PM -0400, Granzow, Doug (NCI) wrote:
 We're planning to move to Veritas Volume Replicator.  It has the advantage
 of working at the filesystem level, so whenever a write is done on the
 primary site, the same write is automatically done on the mirror site.  For
 what I am doing here, it should (hopefully!) work a lot better than rsync
 because it runs continuously, and it doesn't have the startup overhead of
 building a file list, which is the biggest problem with rsync when you are
 dealing with large groups of files.

Unless this is a new product I've used it.  It works fairly
well and unlike most Veritas products the error messages
actually mean something.  It has been about two years so
this could be a new product but the one i dealt with was
really meant to be used as part of a N second fail-over
solution with heartbeats et al.  I give my comments here
to further general knowledge and so you can hear from someone
other than a Veritas spokes-being.

It doesn't work at the filesystem level.  It works at the
block device level.  Every time a block is modified it is
queued for transmission to the mirror(s).  If the same block
is queued twice there is no coalescence, it will be sent
twice.  We did it over a VPN and Oracle kept sending the
same block over and over every five seconds due to an
acknowledged Oracle bug.

There are three caveats to be aware of. You will get more
network traffic than you probably expected.  Only one
end of the connection can be used at a time.  And the
filesystem on the mirror(s) is in the same state it would be
if you pulled the plug so to go on-line requires the
filesystem to replay the journal.

It served the purpose, over a VPN needed more babysitting
than i liked, but it did work fairly well but i disagree
with the approach.

 
 
 
  -Original Message-
  From: Breedlove, Robert [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, June 27, 2002 11:46 AM
  To: Granzow, Doug (NCI); '[EMAIL PROTECTED]'
  Subject: RE: Largest file system being synced
  
  
  What are you moving to?
  
  -Original Message-
  From: Granzow, Doug (NCI) [mailto:[EMAIL PROTECTED]]
  Sent: Thursday, June 27, 2002 8:31 AM
  To: '[EMAIL PROTECTED]'
  Subject: RE: Largest file system being synced
  
  
  
  I am currently syncing 1.3 terabytes of files using rsync.  
  This is spread
  across about 12 filesystems all on the same server.  
  Unfortunately we are
  planning to move away from rsync because it is taking too 
  long to run and it
  takes up too much memory (some of the rsync processes take up 
  1.5 GB of RAM
  -- if we get two of those running at once, the server dies).  
  We have been
  very happy with rsync but it has recently reached a critical 
  mass where it
  can no longer handle the number of files we are trying to 
  sync in a timely
  manner.   But if you are looking for the largest rsync site, 
  we might be a
  contender. :)
  
  FYI, we also use (and plan to continue to use) rsync for 
  several smaller
  mirroring operations.
  
  

-- 

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: Largest file system being synced

2002-06-27 Thread Jason Haar

On Thu, Jun 27, 2002 at 01:31:12PM -0700, jw schultz wrote:
 It doesn't work at the filesystem level.  It works at the
 block device level.  Every time a block is modified it is
 queued for transmission to the mirror(s).  If the same block

Are there any Linux users out there using the likes of RAID'ed-NBD, CODA or
Intermezzo for a similar effect?

The NBD (network block device) looks interesting, it allows you to mount a
remote raw partition - so you can effectively RAID over the network.
Supports transaction logs too (which would be necessary in a rsync-style role)

-- 
Cheers

Jason Haar
Information Security Manager, Trimble Navigation Ltd.
Phone: +64 3 9635 377 Fax: +64 3 9635 417
PGP Fingerprint: 7A2E 0407 C9A6 CAF6 2B9F 8422 C063 5EBB FE1D 66D1

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



cygwin rsync and ascii files

2002-06-27 Thread michael . protulipac

I am ysyncing text files between NT/95/XP machines and Solaris.   I noted
that the text/ascii files created on the windows platforms contain ^M at
the end of each line when transfered to the Solaris system.  This can be
explained by the binary transmission and can use FTP is ASCII mode to
prevent this from happening.  It is crutial that we preserve the time
stamp, so running dos2unix isn't one of the top solutions (unless I write
something to touch the file back to the original time).  Is there an
option to rsync files in ASCII mode?  I would also appreciate and entertain
other solutions.

Thanks in advance,

Mike



-- 
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 2.5.5 and Mac OS X

2002-06-27 Thread grbear

I've got mine setup in inetd.conf to be executed on a per-call request
of port 873 as written in the man pages. The advantage of using this
method, is that when the client is done and disconnects, the daemon
quits, thereby freeing up resources that it was using. Word of warning
though if you want to try this route.. you need to add an rsync tcp
entry for port 873 into Services with the NetInfo manager in addition to
editing the /etc/inetd.conf file.  You'll have to restart to get any
changes to inetd.conf take effect as 'killall -HUP inetd' has no effect.

When run in the manner above, it is started up as the root user (as
specified in inetd.conf).

- Original Message -
From: Catalino Cuadrado [EMAIL PROTECTED]
Date: Thursday, June 27, 2002 2:19 pm
Subject: Re: rsync digest, Vol 1 #778 - 11 msgs

 I haven't gotten it to work successfully, I'm still struggling 
 with the
 same setgroups error that you are. However, I can tell you what I have
 tried. So far I have rsync configured to run in --daemon mode 
 using the
 command: sudo rsync --daemon I can prompt it for a list of 
 modules, but
 when I go to copy a module, I get the error @ERROR: setgroups failed.
 I can copy locally, from one HD to another, but I can't get it to copy
 over the network, even using the sudo rsync ipaddress:/Filename / 
 method.So it's been kind of aggrivating. I'm thinking it has to do 
 with the fact
 that rsync needs to be run locally, and you're running it from a 
 remoteserver... If there's a way to trick the system into thinking 
 that the
 rsync daemon is running as root on the local machine, that would 
 be ideal.
 Unfortunately, I don't know enough about the UNIX side of things 
 to get
 that far.
 -Tito
 
  Message: 5
  Date: Thu, 27 Jun 2002 10:08:00 -0600
  From: [EMAIL PROTECTED]
  Subject: rsync 2.5.5 and Mac OS X
  To: [EMAIL PROTECTED]
  Reply-To: [EMAIL PROTECTED]
 
  Greetings,
 
  Has anyone successfully compiled rsync 2.5.5 under Mac OS X (not
  Server), and actually have it work fully?
 
  I'm in a position where I'm trying to setup an automated nightly 
 remote backup between and Cobalt Raq4 (running a variant of 
 Redhat Linux) and a
  Mac running OS X 10.1.5 with the latest development tools 
 installed.  As
  has been pointed out previously on the list, one has to 
 ./configure with
  the --disable-ipv6 flag to even get it to compile at all.  However
  there's further issues when trying to back up to the Mac running 
 rsync in inetd --daemon mode.
 
  When I issue the following command:
 
  ---
  rsync -avz /home [EMAIL PROTECTED]::raqbackup
  ---
 
  I get the following error:
 
  ---
  @ERROR: setgroups failed
  rsync: connection unexpectedly closed (79 bytes read so far)
  rsync error: error in rsync protocol data stream (code 12) at 
 io.c(150) ---
 
  On the server end, rsyncd.log shows the following:
 
  ---
  2002/06/27 09:50:03 [19768] setgroups failed: Invalid argument
  ---
 
  I've had luck running rsync 2.5.2 running through ssh, but 
 because I
  can't get it to retain the user/group ownership settings it's 
 completely useless as 'mirrored' backup unless I spent the next 
 month hand
  restoring the file ownership's by hand.  The man pages noted this
  limitation, unless running as super-user, which I haven't been 
 able to
  get to work (use chroot=yes in rsyncd.conf doesn't seem to do it)
 
  If anyone has been able to get Mac OS X 10.1.5 running as a 
 rsync server
  in such a fashion, I'd really appreciate hearing from you.
 
  For debuging purposes, my current rsyncd.conf is:
 
  ---
  use chroot = yes
  max connections = 1
  syslog facility = local5
  motd file = /etc/rsyncd.motd
  log file = /var/log/rsyncd.log
  pid file = /var/run/rsyncd.pid
  lock file = /var/run/rsync.lock
 
  [raqbackup]
  path = /Volumes/Eeyore/RaqBackup
  comment = Raq Backup Directory
  auth users = xxx
  secrets file = /etc/rsyncd.secrets
  ---
 
  and the destination directory is set as:
 
  ---
  drwxrwxrwx2 nobody  nobody  24 Jun 26 22:09 RaqBackup
  ---



-- 
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: Largest file system being synced

2002-06-27 Thread Zoong Pham

On Thu, Jun 27, 2002 at 11:30:39AM -0400, Granzow, Doug (NCI) wrote:
 
 I am currently syncing 1.3 terabytes of files using rsync.  This is spread
 across about 12 filesystems all on the same server.  Unfortunately we are
 planning to move away from rsync because it is taking too long to run and it
 takes up too much memory (some of the rsync processes take up 1.5 GB of RAM

What tool are you moving to?
Did you use rsync for any databases.
My company is considering using rsync to mirror some databases.

Thanks,
-- 
Zoong Pham[EMAIL PROTECTED]
UNIX Systems AdministratorMercy Health and Aged Care Inc.

To get my PGP public key, email me with the subject:
Request for Zoong Pham's PGP public 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



AW: Largest file system being synced

2002-06-27 Thread Martin Bene

Hi Jason,

 Are there any Linux users out there using the likes of 
 RAID'ed-NBD, CODA or
 Intermezzo for a similar effect?
 The NBD (network block device) looks interesting, it allows 
 you to mount a remote raw partition - so you can effectively 
 RAID over the network.


I'd recomend drbd over a nbd + raid solution: 
* drbd knows to read from local device only so performance is generaly better
* it deals nicely with disconnect / reconnect scenarios.

I've used drbd in real-life configurations with linux FailSafe and with
heartbeat as cluster managers, works quite nicely once you get it running.

Problems with drbd:
 * current version doesn't like SMP
 * works at block level, so speed for a full synchronisation depends on
filesystem size, not just used space.
 * resync speed limited to about 4MB/sec - limit aplies only for resync, not
for normal read/write access.

have a look at http://www.linbit.com/en/ for more information.

Bye, 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



Error in Rsync.. Value too large

2002-06-27 Thread Nitin Agarwal


Hi...
I am encountering the following error while syncing the data
error message is: "send_files failed to open abcdata1/PABCBTABD.container000
: Value too large to be stored in data type"
Size of the files for which the error is coming are: 31 GB, 35 GB, 40
GB, 52 GB, and 59 GB each.
Please help I will be highly thankful to you.
Thanks  Regards
Nitin Agarwal


CVS update: rsync

2002-06-27 Thread dwd


Date:   Thu Jun 27 10:51:25 2002
Author: dwd

Update of /data/cvs/rsync
In directory va:/tmp/cvs-serv23719

Modified Files:
rsync.1 rsync.yo rsyncd.conf.5 rsyncd.conf.yo 
Log Message:
Document in --owner and use chroot that --numeric-ids is implied when
use chroot is yes.


Revisions:
rsync.1 1.116 = 1.117
http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.1?r1=1.116r2=1.117
rsync.yo1.101 = 1.102
http://www.samba.org/cgi-bin/cvsweb/rsync/rsync.yo?r1=1.101r2=1.102
rsyncd.conf.5   1.42 = 1.43
http://www.samba.org/cgi-bin/cvsweb/rsync/rsyncd.conf.5?r1=1.42r2=1.43
rsyncd.conf.yo  1.47 = 1.48
http://www.samba.org/cgi-bin/cvsweb/rsync/rsyncd.conf.yo?r1=1.47r2=1.48

___
rsync-cvs mailing list
[EMAIL PROTECTED]
http://lists.samba.org/mailman/listinfo/rsync-cvs