Bug 466720 - Backup stopped working after upgrade to version 1.2.1
Backup stopped working after upgrade to version 1.2.1
Status: CLOSED EOL
Product: Fedora EPEL
Classification: Fedora
Component: rdiff-backup (Show other bugs)
el5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Kevin Fenzi
Fedora Extras Quality Assurance
: Triaged
: 537852 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-10-13 03:53 EDT by Tadej Janež
Modified: 2017-04-06 06:35 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2017-04-06 06:35:43 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
updated spec and patches to add alternatives support (5.88 KB, application/zip)
2010-07-27 17:48 EDT, Edward Rudd
no flags Details

  None (edit)
Description Tadej Janež 2008-10-13 03:53:33 EDT
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.
Comment 1 Kevin Fenzi 2008-10-13 13:33:11 EDT
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?
Comment 2 Kevin Fenzi 2008-12-15 17:20:04 EST
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?
Comment 3 Till Maas 2009-05-12 07:57:05 EDT
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.
Comment 4 Bug Zapper 2009-06-09 22:57:05 EDT
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
Comment 5 Kevin Fenzi 2009-06-09 23:26:22 EDT
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.
Comment 6 Till Maas 2009-08-11 11:09:25 EDT
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
Comment 7 Kevin Fenzi 2009-10-04 19:31:59 EDT
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...
Comment 8 Bug Zapper 2009-11-16 04:30:26 EST
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
Comment 9 Kevin Fenzi 2009-11-16 14:29:38 EST
*** Bug 537852 has been marked as a duplicate of this bug. ***
Comment 10 Edward Rudd 2009-11-16 16:38:42 EST
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.
Comment 11 Kevin Fenzi 2010-07-18 15:39:35 EDT
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.
Comment 12 Edward Rudd 2010-07-18 18:32:32 EDT
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
Comment 13 Kevin Fenzi 2010-07-18 19:19:40 EDT
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!
Comment 14 Edward Rudd 2010-07-27 17:48:11 EDT
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.
Comment 15 Kevin Fenzi 2010-07-29 13:29:10 EDT
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?
Comment 16 Edward Rudd 2010-08-09 14:51:23 EDT
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)
Comment 17 Kevin Fenzi 2010-08-09 15:38:57 EDT
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.
Comment 18 Bug Zapper 2010-11-04 07:45:31 EDT
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
Comment 19 Edward Rudd 2010-11-04 09:02:14 EDT
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)
Comment 20 Edward Rudd 2010-11-04 09:02:38 EDT
Rather I mean EPEL 4 and 5
Comment 21 Kevin Fenzi 2010-11-04 11:51:57 EDT
Yeah. Please do let me know if there is anything I can do to expadite things. ;)
Comment 22 Fedora End Of Life 2017-04-06 06:35:43 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.