Assigning to the registered maintainer.

CC: (none) => marja11
Assignee: bugsquad => makowski.mageia

(In reply to Marja van Waes from comment #1)
> Assigning to the registered maintainer.

wally, can you help ?

CC: (none) => jani.valimaa

It's really python-paramiko which is broken and causes issues in duplicity.

Pushed new python-paramiko [1] with a patch from upstream via Fedora to core/updates_testing. Please test.

[1] python-paramiko-1.15.2-1.1.mga5

Source RPM: duplicity-0.6.25-2.mga5 => python-paramiko-1.15.2-1.mga5

SRPM:
python-paramiko-1.15.2-1.1.mga5

RPMS:
python-paramiko-1.15.2-1.1.mga5
python3-paramiko-1.15.2-1.1.mga5

Hi
I just installed python-paramiko-1.15.2-1.1.mga5.noarch.rpm from core/update/testing and I confirm this fixes the error in duplicity.
Looks good to be pushed to update.

thanks

Changed the package ID in the title from
 python-pycrypto-2.6.1-6.1 to python-paramiko-1.15.2-1
according to Comments 3 & 4.

Summary: python-pycrypto-2.6.1-6.1.mga5 update broke duplicity => python-paramiko-1.15.2-1 broke duplicity
CC: (none) => lewyssmith

I looked at length into deploying Duplicity, but it seems a quagmire of scp/ssh stuff at both ends.
@Nicolas Can you suggest a way of installing/configuring it on a stand-alone box with the necessary scp/ssh stuff? It looks really easy to use once everything is set up at both ends.

@Lewis : usage is rather easy in fact ; on the remote server, you just need an ssh account and a directory to store the backups.
On the local machine I run for example :

duplicity --allow-source-mismatch --volsize 500 --progress /home ssh://user@remote/backup/home

This will backup /home into the directory /backup/home on "remote".

@lewis: I had been intending to have a look at this.  I could take this because I have several machines on the network.  Not backing up /home though (160GB) :-)

CC: (none) => tarazed25

x86_64 with Mate
Installed duplicity and used it to test python-paramiko-1.15.2-1.mga5
 
$ duplicity --allow-source-mismatch --volsize 500 --progress /home/lcl/ruby ssh://lcl@vega/data/ruby
Duplicity 0.6 series is being deprecated:
See http://www.nongnu.org/duplicity/

ssh: Unknown exception: CTR mode needs counter parameter, not IV
ssh: Traceback (most recent call last):
ssh:   File "/usr/lib/python2.7/site-packages/paramiko/transport.py", line 1610, in run
ssh:     self.kex_engine.parse_next(ptype, m)
ssh:   File "/usr/lib/python2.7/site-packages/paramiko/kex_group1.py", line 74, in parse_next

.... etc ....

Updated python-paramiko
$ rpm -qa | grep paramiko
python-paramiko-1.15.2-1.1.mga5
$ duplicity --allow-source-mismatch --volsize 500 --progress /home/lcl/ruby ssh://lcl@vega/data/ruby

Duplicity 0.6 series is being deprecated:
See http://www.nongnu.org/duplicity/

Exception in thread Thread-1:
Traceback (most recent call last):
  File "/usr/lib64/python2.7/threading.py", line 810, in __bootstrap_inner
    self.run()
  File "/usr/lib/python2.7/site-packages/paramiko/transport.py", line 1645, in run
    emsg = '%s (%d)' % (e.args[1], e.args[0])
IndexError: tuple index out of range


askpass was triggered twice, first for the user password on the remote machine and then the password on the private key of the local machine (I think).
After the traceback the command hung.

A second attempt bypassed the user password and then failed:
$ duplicity --allow-source-mismatch --volsize 100 --progress /home/lcl/ruby ssh://lcl@vega/data/ruby

Duplicity 0.6 series is being deprecated:
See http://www.nongnu.org/duplicity/

BackendException: ssh connection to lcl@vega:22 failed: Private key file is encrypted

It looks like it is not so easy after all, on a LAN.

Tried the update on another machine:
$ duplicity --allow-source-mismatch --volsize 500 --progress /home/lcl/ruby ssh://lcl@vega/data/ruby

Duplicity 0.6 series is being deprecated:
See http://www.nongnu.org/duplicity/

BackendException: ssh connection to lcl@vega:22 failed: No authentication methods available

Note that a remote login to vega succeeds without any problem at all so there is nothing wrong with the connection.  duplicity does not even ask for a password.

From the duplicity man pages:
      ssh paramiko backend (enabled by default)
              paramiko (SSH2 for python) -
              http://pypi.python.org/pypi/paramiko (downloads);
              http://github.com/paramiko/paramiko (project page)
              pycrypto (Python Cryptography Toolkit) -
              http://www.dlitz.net/software/pycrypto/

$ rpm -qa | grep pycrypto
python-pycrypto-2.6.1-6.1.mga5

What is SSH2?

duplicity certainly looks like the easiest approach to testing this update; all the others have a learning curve or are more relevant to developers.

Testing on a system where I have ssh setup such that ssh mine opens a bash
session on a second system ...

[dave@x5v Desktop]$ duplicity /home/dave/Desktop/ ssh://dave@mine/testduplicity

Duplicity 0.6 series is being deprecated:
See http://www.nongnu.org/duplicity/

Local and Remote metadata are synchronized, no sync needed.
Last full backup date: none
GnuPG passphrase: 
Retype passphrase to confirm: 
No signatures found, switching to full backup.
--------------[ Backup Statistics ]--------------
StartTime 1489716645.94 (Thu Mar 16 22:10:45 2017)
EndTime 1489716645.95 (Thu Mar 16 22:10:45 2017)
ElapsedTime 0.01 (0.01 seconds)
SourceFiles 6
SourceFileSize 18253 (17.8 KB)
NewFiles 6
NewFileSize 18253 (17.8 KB)
DeletedFiles 0
ChangedFiles 0
ChangedFileSize 0 (0 bytes)
ChangedDeltaSize 0 (0 bytes)
DeltaEntries 6
RawDeltaSize 14113 (13.8 KB)
TotalDestinationSizeChange 6895 (6.73 KB)
Errors 0
-------------------------------------------------

On the dest system, in the directory it created, ran
gpg duplicity-full.20170317T021038Z.vol1.difftar.gpg
to create the unencrypted diff file.

Then ran tar-xf on he difftar file and confirmed the files were present in
the snapshot/ directory.

Both the source and dest systems are running Mageia 5 x86_64.

I'll test from a Mageia 5 i586 vb guest shortly.

Whiteboard: advisory => advisory MGA5-64-OK

Same testing ok with an i586 vb guest, but with a different dest directory.

Validating the update.

Keywords: (none) => validated_update
Whiteboard: advisory MGA5-64-OK => advisory MGA5-64-OK MGA5-32-OK
CC: (none) => sysadmin-bugs

An update for this issue has been pushed to the Mageia Updates repository.

http://advisories.mageia.org/MGAA-2017-0010.html

Status: NEW => RESOLVED
Resolution: (none) => FIXED