Hide Forgot
Description of problem: I use rdiff-backup to backup my F9 system to a CentOS 4 system. The remote system has rdiff-backup version 1.0.5. Since upgrading rdiff-backup on F9 system to version 1.2.1, backup stopped working. Version-Release number of selected component (if applicable): rdiff-backup-1.2.1-1.fc9.i386 (on F9) rdiff-backup-1.0.5-2.el4 (on CentOS 4) Steps to Reproduce: 1. su -c "rdiff-backup --verbosity 3 --exclude-globbing-filelist /home/tadej/backup/rdiff_backup_excludes.txt --include-globbing-filelist /home/tadej/backup/rdiff_backup_includes.txt --exclude /home/tadej /home/tadej samson-tbackup::/home/tbackup/tadej1" tadej Actual results: I get the following output: Warning: Local version 1.2.1 does not match remote version 1.0.5. Exception ' Warning Security Violation! Bad request for function: rpath.make_file_dict with arguments: ['/home/tbackup/tadej1'] ' raised of class '<class 'rdiff_backup.Security.Violation'>': File "/usr/lib/python2.5/site-packages/rdiff_backup/Main.py", line 302, in error_check_Main try: Main(arglist) File "/usr/lib/python2.5/site-packages/rdiff_backup/Main.py", line 319, in Main rps = map(SetConnections.cmdpair2rp, cmdpairs) File "/usr/lib/python2.5/site-packages/rdiff_backup/SetConnections.py", line 78, in cmdpair2rp return rpath.RPath(conn, filename).normalize() File "/usr/lib/python2.5/site-packages/rdiff_backup/rpath.py", line 860, in __init__ else: self.setdata() File "/usr/lib/python2.5/site-packages/rdiff_backup/rpath.py", line 884, in setdata self.data = self.conn.rpath.make_file_dict(self.path) File "/usr/lib/python2.5/site-packages/rdiff_backup/connection.py", line 448, in __call__ return apply(self.connection.reval, (self.name,) + args) File "/usr/lib/python2.5/site-packages/rdiff_backup/connection.py", line 370, in reval if isinstance(result, Exception): raise result Traceback (most recent call last): File "/usr/bin/rdiff-backup", line 23, in <module> rdiff_backup.Main.error_check_Main(sys.argv[1:]) File "/usr/lib/python2.5/site-packages/rdiff_backup/Main.py", line 302, in error_check_Main try: Main(arglist) File "/usr/lib/python2.5/site-packages/rdiff_backup/Main.py", line 319, in Main rps = map(SetConnections.cmdpair2rp, cmdpairs) File "/usr/lib/python2.5/site-packages/rdiff_backup/SetConnections.py", line 78, in cmdpair2rp return rpath.RPath(conn, filename).normalize() File "/usr/lib/python2.5/site-packages/rdiff_backup/rpath.py", line 860, in __init__ else: self.setdata() File "/usr/lib/python2.5/site-packages/rdiff_backup/rpath.py", line 884, in setdata self.data = self.conn.rpath.make_file_dict(self.path) File "/usr/lib/python2.5/site-packages/rdiff_backup/connection.py", line 448, in __call__ return apply(self.connection.reval, (self.name,) + args) File "/usr/lib/python2.5/site-packages/rdiff_backup/connection.py", line 370, in reval if isinstance(result, Exception): raise result rdiff_backup.Security.Violation: Warning Security Violation! Bad request for function: rpath.make_file_dict with arguments: ['/home/tbackup/tadej1'] Traceback (most recent call last): File "/usr/bin/rdiff-backup", line 23, in ? rdiff_backup.Main.Main(sys.argv[1:]) File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py", line 285, in Main [root@tlinux-stable cron.daily]# take_action(rps) File "/usr/lib64/python2.3/site-packages/rdiff_backup/Main.py", line 253, in take_action connection.PipeConnection(sys.stdin, sys.stdout).Server() File "/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py", line 352, in Server self.get_response(-1) File "/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py", line 314, in get_response try: req_num, object = self._get() File "/usr/lib64/python2.3/site-packages/rdiff_backup/connection.py", line 230, in _get raise ConnectionReadError("Truncated header string (problem " rdiff_backup.connection.ConnectionReadError: Truncated header string (problem probably originated remotely) Expected results: Backup should finish without an error.
Alas, different versions of rdiff-backup sometimes have issues. http://www.nongnu.org/rdiff-backup/FAQ.html#compatible Not sure what we can do here. ;( I have been trying to decide if pushing a new version to EPEL is a good idea or not. ;( On the one hand, it would help situations like you have. On the other hand, it would cause issues with other sites where all the rest of the machines are still on an older version. ;( So, in short, can you upgrade your centos4 box version and see if it works then?
Any news here? Another idea is to make a 'rdiff-backup10' and a 'rdiff-backup12' packages and use alternatives to switch between them. Thats a lot of overhead however. It might be best to just update EPEL to 1.2. Thoughts?
Unison has the same problem, there both branches are packaged, but afaik unison can also tries to use a binary called unison-$VERSION if the normal unison binary does not match the required version. Maybe this can be patched into rdiff-backp, too. I am not sure, but maybe this is also helpful to be still able to recover backups made with an older release of rdiff-backup.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '9'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 9's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 9 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This is needing to be dealt with. I think I will look at just upgrading EPEL. The version in fedora has been stable for quite a while now.
As far as I understand recent meeting minutes[0] you can go forward with updating EPEL. [0] http://meetbot.fedoraproject.org/fedora-meeting/2009-07-31/fedora-meeting.2009-07-31-20.59.log.html#l-10
Sorry again this bug has languished so long. ;( At the most recent meeting it was decided that protocol issues like this one would not be sufficent to update in a epel stable release. ;( So, I'm back to doing a rdiff-backup12 or something for epel. ;( There's two approaches I can take to this: 1. Try and make a modified package that has 'rdiff-backup12' and all the commands and such refer to 'rdiff-backup12' and it thus doesn't conflict with the current 1.0.5 version. You can then install them both and call the one you want. 2. Modify both the existing one and the new one to use alternatives and that would allow both to be installed, but only one could be called with 'rdiff-backup' (whichever one you have marked active). Any thoughts? Both are messy, but have up and downsides. I'll try and get a review up for the new one as soon as I figure out which way to go above...
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle. Changing version to '12'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
*** Bug 537852 has been marked as a duplicate of this bug. ***
Thoughts about the packaging style (from comment #7) Does rdiff-backup allow you to specify which command to run on the "remote"? If so, that would makes sense to have both installed simultaneously so a server could support 1.0 and 1.2. Although it would add complication to configuring clients. On the client side I personally don't see much value in having both versions available at the same time as the likely hood of needing to back up SOME data to a 1.0 server and other data to a 1.2 server doesn't seem high. I'm all for using the alternates system as that would be a "cleaner" solution for handling the defaults and make setup simpler. Is there anything I can do to help with this effort? I am pretty proficient at building rpm packages and would be willing to help build the specs or you. (I have a fedora account just haven't had the motivation yet to play around with submitting packages) Currently I have resorted to using and rpmforge package for the meantime until this gets resolved.
Sigh. This bug keeps dropping off my radar. ;( Edward: would you still be willing to make a rdiff-backup12 package for EPEL-5/EPEL-4 that contains a parallell installable rdiff-backup-1.2.x version? If we have that and can choose with alternatives it might work out.
I was just thinking of this issue recently too, as it fell of the "map" with me as well. I actually had to rebuild my server a month ago (HD failure, RAID equipment coming soon). And was reminded yesterday that I forgot to re-establish the backups on the box (oops).. So I'll be needing rdiff-backup running on the box again. I'll work on the package over the next week and attach updated specs to this bug. /add to todo list
Great. You can either add it here and I can submit it as a new package, or you can submit it if you like for review. Thanks!
Created attachment 434865 [details] updated spec and patches to add alternatives support I've attached a zip that contains the two SPEC files and two patches to add in alternatives support.. I've tested it on my CentOS5 x86 box that it each version correctly works (even when both are installed). And tested the following upgrade paths. When the current EPEL rdiff-backup 1.0.5 is installed the new package correctly updates and setups the alternates. When the rpmforge rdiff-backup 1.2.8 is installed, installing the rdiff-backup12 correctly "obsoletes" the rdiff-backup 1.2.8 package from rpmforge.
Excellent. These changes look great to me... Shall I submit a rdiff-backup12 package from this? Or would you like to do so/help maintain it?
How do I go about submitting it, since it's a specific package to EPEL (doubt there is need for it in Fedora). And will there be a need to add this to RHEL 6 EPEL as well? (as I see you updated RHEL 6 to the 1.2 release)
well, for EPEL5 we need to keep 'rdiff-backup' as the old one, and you will need to submit a new package for 'rdiff-backup12'. For EL6 and fedora we have rdiff-backup already that is 1.2, so we could submit there a 'rdiff-backup10' package for backward compat there. See: https://fedoraproject.org/wiki/Join_the_package_collection_maintainers for the full process. I can review the packages and sponsor you. To summarize the new requests: rdiff-backup12 -> epel5 only rdiff-backup10 -> fedora 12/13/14/rawhide+epel6 (I don't know how much call there is for the old version in fedora/epel6 though), I sure haven't heard many people asking for it.
This message is a reminder that Fedora 12 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 12. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '12'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 12's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 12 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
This needs to be changes to RHEL 4 and RHEL 5 as that is where the fix is being focused. (which is done I just have to finish getting my fedora account setup and submitting the package)
Rather I mean EPEL 4 and 5
Yeah. Please do let me know if there is anything I can do to expadite things. ;)
Fedora EPEL 5 changed to end-of-life (EOL) status on 2017-03-31. Fedora EPEL 5 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora or Fedora EPEL, please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.