Red Hat Bugzilla – Bug 457680
scp destination fails if no username is specified.
Last modified: 2008-08-12 14:20:22 EDT
Description of problem:
The recent duplicity update caused my backup scripts to fail. This was due to not having a username specified in the scp:// based destination url.
Previously I had scp://hostname/path and this now fails. I have had to change it to scp://user@hostname/path.
My "hostname" is actually a ssh config entry pointing to the real host and I have specified the correct user there. I see no need to specify it again.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Try and run duplicity /source_path/ scp://remotehost/target_path
Traceback (most recent call last):
File "/usr/bin/duplicity", line 482, in <module>
File "/usr/bin/duplicity", line 477, in with_tempdir
File "/usr/bin/duplicity", line 405, in main
action = commandline.ProcessCommandLine(sys.argv[1:])
File "/usr/lib/python2.5/site-packages/duplicity/commandline.py", line 464, in ProcessCommandLine
backup, local_pathname = set_backend(args, args)
File "/usr/lib/python2.5/site-packages/duplicity/commandline.py", line 374, in set_backend
backend1, backend2 = backends.get_backend(arg1), backends.get_backend(arg2)
File "/usr/lib/python2.5/site-packages/duplicity/backends.py", line 89, in get_backend
File "/usr/lib/python2.5/site-packages/duplicity/backends.py", line 334, in __init__
self.host_string = parsed_url.username + "@" + parsed_url.hostname
TypeError: unsupported operand type(s) for +: 'NoneType' and 'str'
Simon, thanks your your report. I have forwarded this bug report to the upstream maintainer, because I'm personally not so good in fixing python code. As soon as I get a reply by upstream and/or a patch, I'll apply and ask you to test before pushing another update for Fedora and EPEL.
For the moment, either please downgrade or use the workaround you already discovered. I'll let you know, once I know more regarding this.
Upstream report is https://savannah.nongnu.org/bugs/index.php?23988 - will be worked ASAP on it as per upstream's reply.
Simon, can you please test, whether the patch from http://savannah.nongnu.org/support/download.php?file_id=16234 solves your problem?
The relevant file is /usr/lib/python2.X/site-packages/duplicity/backends.py
The patch fixed my issue.
Simon, thanks for your feedback. I've built updated packages which contain the
patch you confirmed as working. The packages should reach Fedora and EPEL repos
in the next days.
39788 (duplicity): Build on target fedora-4-epel succeeded.
39787 (duplicity): Build on target fedora-5-epel succeeded.
Package: duplicity-0.4.12-2.fc8 Tag: dist-f8-updates-candidate Status: complete
Package: duplicity-0.4.12-2.fc9 Tag: dist-f9-updates-candidate Status: complete
Package: duplicity-0.4.12-2.fc10 Tag: dist-f10 Status: complete
duplicity-0.4.12-2.fc8 has been submitted as an update for Fedora 8
duplicity-0.4.12-2.fc9 has been submitted as an update for Fedora 9
duplicity-0.4.12-2.fc8 has been pushed to the Fedora 8 stable repository. If problems still persist, please make note of it in this bug report.
duplicity-0.4.12-2.fc9 has been pushed to the Fedora 9 stable repository. If problems still persist, please make note of it in this bug report.