Bug#317418: Updated Sarge package available
> Wonderful! However... your last changelog.Debian entry was in
> September 2005, and the patch is from 2006-08-26.
> > https://bugzilla.samba.org/show_bug.cgi?id=3929
>
> So somehow I doubt that you already included that patch. :-)
Whoops! Please send over a large trout, I must be confused by the
bugs :)
Serge
--
Serge van Ginderachter
http://www.vanginderachter.be/
Failing to plan is planning to fail.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317418: Updated Sarge package available
On Tue, 2006-09-12 at 19:28 +0200, Andy Spiegl wrote: > When can we expect the Debian package to include this patch? > (especially the backported version would be greeeat) I backported it a long time ago, I thought it was referenced in this bug thread? Anyway, you can pick up the package here deb http://www.vanginderachter.be/downloads/debian/packages/archives sarge main Serge -- Serge van Ginderachter http://www.vanginderachter.be/ Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317418: Updated Sarge package available
In can meanwhile confirm that this update also solves the problem in rsnapshot. Upstream has also been updated on this. Is there any way where this patch could go into Sarge? -- Serge van Ginderachter smime.p7s Description: S/MIME Cryptographic Signature
Bug#317418: Updated Sarge package available
I can confirm that the bug is solved with the patch earlier http://lists.samba.org/archive/rsync/2005-April/012338.html I updated the Sarge package - rsync version 2.6.4-6 with it and testrunned it using the --delete option, which works as expected. 'rsync_2.6.4-6.svg1_i386.deb' and full source can be downloaded here: http://www.vanginderachter.be/downloads/debian/ I tried to build this package the Debian way, but as my experience with customising debian packages is very limited, it might be good if some more people could verify. Also, don't hesitate on giving me any feedback I could learn from, thanks. I will further monitor the behavior of rsnapshot, which was broken in Sarge because of this bug. I expect that problem to be solved now in Sarge. HTH, -- Serge van Ginderachter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#317418: rsync --delete option does not work
Package: rsync Version: 2.6.4-6 rsync does not always honor the --delete* options. An earlier report of that bug can be found here: http://lists.samba.org/archive/rsync/2005-April/012335.html a short analysis here: http://lists.samba.org/archive/rsync/2005-April/012337.html and a possible solution here: http://lists.samba.org/archive/rsync/2005-April/012338.html As this bug breaks the rsnapshot package feature wise in Sarge - which is how I found out about it - I put the rsnapshot maintainer in carbon copy. -- Serge van Ginderachter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#158170: #158170: rsync: hangs or exits with strange errors when pulling, files
Paul Slootman wrote: > My suspicions would be NFS (but then I'm not objective :-) I can totally share your point of view in a very subjective way. > Do you mean that without the timeout option, it does work with this > scponly shell? Yes, exactly. > I would expect that "scponly" would imply not being able > to run any given command: only scp would be permitted. I can attest that remains possible, at meast rsync is still able to launch another rsync process on the remote host, although I didn't look into how this exactly works, nor what the security consequences are. (improving security was the main reason to use scponly in this case.) Serge van Ginderachter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#305923: rsnapshot does not handle new rsync '--timeout' option
Hello Christoph, we (upstream author and me) can't reproduce this bug. ... rsnapshot make no use of scp, we are not sure why it is used in your setup. Do you have a special environment (special ssh version, some restrictions with ssh), a forced command in your authorized_keys file on the remote host or something like that? You are right on this. I found the other trigger to the problem: The remote user ([EMAIL PROTECTED]) which rsync/rsnapshot authenticates against, had /usr/bin/scponly (v4.0-1) as his shell. Changing the the shell to /bin/sh makes the problem go away. Please also try to run the rsync command manually, cause maybe this error is not caused by rsnapshot. The examples I gave, where run manually. It was the exact statement as generated by the rsnapshot script. Given this new information, I guess this is more an rsync bug/feature, and has nothing to do with rsnapshot? (I posted an update on this on rsync bug 158170; it was during troubleshooting my problems with that bug, that I was experimenting with the timeout option.) Serge -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#158170: #158170: rsync: hangs or exits with strange errors when pulling, files
In the mean time I have been experimenting with the newest version. Troubleshooting was a little hard, as I equally was struggling with an NFS problem at my provider. It is that NFS space I am rsync'ing with. As of today, I have no more time-out problems. I am now using the latest 2.6.4-1 version. Where at first I was succesfully syncing using the --timeout option, this is not necessary any more. Right now I'm not sure if this was in my case a pure rsync problem, or related to the NFS problem. On a side note, I noticed that using the --timeout option for remote backups using ssh transport, failed when the remote user has /usr/bin/scponly (v4.0-1) as his shell. The error rsync returns is: /usr/bin/rsync -av --delete --numeric-ids --timeout 300 --rsh=/usr/bin/ssh \ [EMAIL PROTECTED]:/mnt/backup/ \ /BACKUP/snapshots/daily.0/server/ invalid characters in scp command! here:=300 --numeric-ids . /mnt/backup/ try using a wildcard to match this file/directory The problem goes away when using /bin/sh as the remote user's shell. I'm not sure if this is a bug or a feature, and if I should file a separate bug report in this? Serge van Ginderachter -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#158170: #158170: rsync: hangs or exits with strange errors when pulling, files
On Sun, 2005-04-10 at 20:31 +0200, Paul Slootman wrote: > The current 2.6.4 version does indeed have extra code to prevent > timeouts happening, however that should only take effect when both sides In the mean time I noticed other situations where both sides needed to be upgraded. Where I first thought the problem was solved, I now had troubles again. I'll have to look into this extra option: > of the transfer has at least version 2.6.4 and when the --timeout option > is used... But I somehow doubt it will help, as time-outs keep occurring even after several hours. I'll see tomorrow how my backup script went. Thanks for your support, -- Serge van Ginderachter <[EMAIL PROTECTED]> -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#158170: #158170: rsync: hangs or exits with strange errors when pulling, files
Hi,
Same problem here, rsync seems to hang" but as an strace show, there's a
time-out after a while
| select(5, NULL, [4], NULL, {60, 0}) = 0 (Timeout)
I invoke rsync from cron via the rsnapshot script, but it makes no
difference invoking it from a shell.
Notice that I get the problem doing remote ssh pulls as well as local
sync's, on different partitions as well as on the same partition.
my version was = 2.6.3-2_i386
I'm not sure what triggered the bug, I vaguely recall that I went
through an apt-get upgrade last week on this Sarge/testing system, but
it was a long time since I last did that, so I'm not sure if rsync got
upgraded at the time.
Then I noticed that there was a new version in Unstable: 2.6.4-1.
After installing this one, the problem went away. Note that I only
upgraded rsync on the 'pulling server', where I start the proces.
--
Serge van Ginderachter
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
