Hi,
ok so basically that would (invoke with SETUID) be to invoke rsync daemon
as root for example? More
or less I have to run the daemon as root to be able to update files for all
users dont I? For example if I want
to rsync the homedirs area, I have to run the deamon as root or run a
Matt McCutchen-7 wrote:
OK, let's be clear here. If you want to start a daemon to accept
connections, the command is rsync --daemon; pass a --config=FILE
option if you want to use a configuration file other than the
default /etc/rsyncd.conf . If you want to access an rsync daemon, put a
On Mon, 2008-03-17 at 05:58 -0700, Peter Heiss wrote:
Although, I am still having problems with
the daemon on the remote server. I ran the command rsync --daemon on the
remote server, no error there. But then I ran the following error to do a
test backup and received this error:
# rsync
On Mon, 2008-03-17 at 05:58 -0700, Peter Heiss wrote:
hosts allow = trusted.hosts
BTW, the hosts allow field needs to contain the actual list of trusted
hosts, not the name of a file holding the list.
Matt
--
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
On Mon, 2008-03-17 at 12:24 +0100, Andy Smith wrote:
ok so basically that would (invoke with SETUID) be to invoke rsync daemon
as root for example? More
or less I have to run the daemon as root to be able to update files for all
users dont I? For example if I want
to rsync the homedirs
Hello,
I try to backup files from a NAS to our backup-server using rsync.
The NAS itself is not able to run rsync.
Therefore I installed rsyncd (cwrsync 2.1.1) on a windowsserver which
has access to the NAS.
I configured the rsyncd like this:
[nspPR53_so2]
path =
On Mon, 2008-03-17 at 15:57 +0100, Kalb Stefan wrote:
I try to backup files from a NAS to our backup-server using rsync.
The NAS itself is not able to run rsync.
Therefore I installed rsyncd (cwrsync 2.1.1) on a windowsserver which
has access to the NAS.
I configured the rsyncd like this:
---
rsyncd.conf.yo |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/rsyncd.conf.yo b/rsyncd.conf.yo
index f365333..f17e3d5 100644
--- a/rsyncd.conf.yo
+++ b/rsyncd.conf.yo
@@ -456,7 +456,7 @@ tt(fe80::%link1/:::::)nl()
)
You can also combine hosts
On Fri, 2008-02-22 at 17:14 -0500, Matt McCutchen wrote:
On Fri, 2008-02-22 at 14:19 +0100, Lasse Kliemann wrote:
Is this correct behavior?
File `foo' gets overwritten with directory `foo',
even though --ignore-existing is given.
I had never thought about this case, but probably
https://bugzilla.samba.org/show_bug.cgi?id=5299
--- Comment #4 from [EMAIL PROTECTED] 2008-03-17 11:15 CST ---
I'm still working on coming up with a set of files that I can share with you
that will reproduce the problem. So far I have only seen this happen with my
VMware files for my
Ok thanks for that!
I've tried implementing this but Im getting a nasty issue, rsync is core
dumping on the recieving server (the daemon
side).
Im running this command:
/usr/local/bin/rsync -vv -r -e ssh -vv -l rsync -i
/usr/home/rsync/.ssh/id_dsa /usr/home/rsync/rra/ bkupsrv::confidential
On Mon, 2008-03-17 at 17:48 +0100, Andy Smith wrote:
I've tried implementing this but Im getting a nasty issue, rsync is core
dumping on the recieving server (the daemon
side).
Alas, there's a bug in rsync 3.0.0: a daemon crashes unless it is given
an explicit --config=FILE option. Either
https://bugzilla.samba.org/show_bug.cgi?id=5287
--- Comment #2 from [EMAIL PROTECTED] 2008-03-17 12:00 CST ---
As I alluded to in my prior comment, I did some work to silence the unused
parameter warnings. They should be gone on any compiler that supports the
-Wno-unused-parameter
Great thnx! No prob to reinstate the forced command in authorized_keys with
explicit conf=
Ooof, hurt my head working out that I had to put use chroot = no if Im not
using root! lol But
at last its all working!! Thanks alot for all the assistance!!
Once last point, does it make any difference
On Mon, 2008-03-17 at 18:33 +0100, Andy Smith wrote:
Once last point, does it make any difference if I push or pull from the
server side? Im thinking
the only important thing is if you pull you can set the server side
read-only which is better for
security, that about right??
Yes, that's
Stefan,
Please keep this on the list (CC rsync@lists.samba.org ).
On Mon, 2008-03-17 at 17:33 +0100, Kalb Stefan wrote:
I corrected the path to:
[nspPR53_so2]
path = //172.21.87.9/nspPR53_so/material/doc
read only = true
transfer logging = yes
But no success.
Error message remains the
Ok, well really thanks for being so helpful! All working now!
For the record Im transfering 2Gb of RRD DB files and with rsync daemon over
ssh
I've cut sync times by about half and the speedup value I have is about
80. Not bad
but I think I have a disk IO bottleneck preventing it being
- Collect material that applies to all daemon filters in the documentation of
the filter parameter, and make it more complete and coherent.
- Amplify the recommendation to exclude entire subtrees properly since the
excluded_below check is easy to circumvent and I have proposed removing it
https://bugzilla.samba.org/show_bug.cgi?id=4561
--- Comment #4 from [EMAIL PROTECTED] 2008-03-17 22:14 CST ---
I have posted a revised version of the patch that covers non-regular files and
has slightly improved documentation in branch tweak-opts of my repository at:
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project rsync.
The branch, master has been updated
via aa0e6b9977eff5c5433239a916623a4a3e8a67cb (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project rsync.
The branch, master has been updated
via df476bfcff992fb66765d338128dffcf58369722 (commit)
from
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project rsync.
The branch, master has been updated
via d4c5cb2b0101299569dbbeeae08597c8300f92e7 (commit)
from
22 matches
Mail list logo