S3 BACKEND_URL credentials error
Brought to you by:
edso
Menu
▾
▴
#85 S3 BACKEND_URL credentials error
Duply 1.10 version inserts url encoded username into target url with S3 protocol but, AFAIK, S3 doesn't support it.
Now, trying to make a backup raises the following python exception:
InvalidUriError: Invalid match bucket name in URI "XXXXXXXXXXx@bucket-name"
Duply 1.9.2 works fine because it sends credentials as BACKEND_PARAMS.
Related
that's an unfortunate but necessary backward incompatibility. pls check the Changelog and unset user and passphrase vars and export the needed env vars instead.
..ede
On August 7, 2015 12:25:36 PM GMT+02:00, David Pujadas dpujadas@users.sf.net wrote:
Related
Bugs:
#85Export AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY in profile conf file solved the problem.
Thanks
You have broken backwards compatibility in an amazingly horrible way, and it's not properly documented on HOW to fix it unless you go spelunking through crap and just "figure it out". For the next person along who's backups on several machines broke with 1.10+ updates, here's what you do:
1) Copy TARGET_USER and TARGET_PASS from your .duply/<profile>/conf to a notepad, then comment them out. If you don't comment them out, the new duply 1.10+ will shove them into your bucket name for some reason that isn't clear at all resulting in errors and a python exception.</profile>
2) If you don't already, create a wrapper script to run your duply commands so that you can export the variables.
3) In the wrapper, export the Environment variables for your service before you run duply that are the same values as TARGET_USER and TARGET_PASS, for example:
S3:
export AWS_ACCESS_KEY_ID=(old TARGET_USER)
export AWS_SECRET_ACCESS_KEY=(old TARGET_PASS)
Google:
export GS_ACCESS_KEY_ID=(old TARGET_USER)
export GS_SECRET_ACCESS_KEY=(old TARGET_PASS)
The upgrade to 1.10 should have just done this better rather than straight up breaking existing configs with no clear explanation of what to do (that Changelog is a joke, as is the template). I also don't see why the code couldn't have just examined the TARGET for the bucket keywords (i.e. gs:// or s3://) and exported the TARGET_USER and TARGET_PASS into the needed variables and not screw up the bucket name.
Horrible upgrade. Horrible. If you break backwards compatibility this hard, up the version number a full major release (2.x) and add warnings ahead of time about how you're about to break everyone's configuration.
On 26.08.2015 02:37, troy engel wrote:
you probably refer to the Changelog which you immediately read after your old config stopped working with the new version i suppose?
if you are not aware, 1.10.1 released 7 days ago fixed this issue
totally unnecessary, put them into your conf file as documented in the Changelog
well sir, right back at you. and please mind your manners if you plan to post any more tickets. rudeness only get's you so far.
inserting the user into the url was a bug resulting of the cleanup. that's fixed.
wrt. to parsing protocols and treating every one differently i stated my reasons in the Changelog entry
hope you will recover from your experience soon. btw. nobody forced you to upgrade.. simply stick to the old if it works for you.
noted. my opinion on it is still that the Changelog entry explains the change it well enough provided of course that users read it if they experience problems after an upgrade.
expecting that your config will work after an upgrade is nice, but not guaranteed by many softwares, not just duply.
anyway.. thx for your entertaining post. you made my morning.. ede
It's still the case with 1.11.3. and duplicity 0.7.07.1
If you specify the legacy TARGET_USER and TARGET_PASS and exporting AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY:
"InvalidUriError: Invalid bucket name in URI "s3"
as explained in the 1.10 changelog. there is and will be no more target specific code in duply.
why are you setting TARGET_USER and TARGET_PASS at all when they are not supported by this backend.
i am sorry that this breaks backward compatibility of the conf file, but i see no other way i could have reached mentioned aim.
regards ..ede
On 10.06.2016 14:56, Roland Moriz wrote:
Related
Bugs:
#85because some recent Distros still ship an older duply version that relies on that, while others not. I hoped to find a way to write a config file that works with all versions of duply/duplicity.
i am open to suggestions, but hacking special rules for every backend and documenting them and the whole routine again when some backend changes is just a waste of time.
..ede
On 10.06.2016 15:42, rmoriz wrote:
Related
Bugs:
#85Hi ede,
I got it working but you have to admit that it's not really explained in the changelog. :-) Or is it?
Last edit: sinklar 2015-09-11
morning Sinklar,
"
1.10 (31.7.2015)
...
- featreq 31 " Support for duplicity Azure backend " - ignored a
contributed patch by Scott McKenzie and instead opted for removing almost
all code that deals with special env vars required by backends.
adding and modifying these results in too much overhead so i dropped this
feature. the future alternative for users is to consult the duplicity
manpage and add the needed export definitions to the conf file.
appended a commented example to the template conf below the auth section.
"
http://duply.net/wiki/index.php/Duply-Changelog
if you feel this can be solved, worded better feel free to suggest anything apart from versioning config files ;).. ede/duply.net
On 11.09.2015 07:40, sinklar wrote:
Related
Bugs:
#85Maybe just telling clearly in the changelog that people need to use something like :
instead of:
would be good enough. ;-)
you are aware that there are several backends demanding special env vars. if i document s3 i would have to do the same for every backend. that's exactly the reason why i point to the duplicity man page.
when i find time i might readd the old routines and add a deprecation warning for those cases. but that's kind of a big if.
..ede
On 12.09.2015 15:58, sinklar wrote:
Related
Bugs:
#85