Re: Problems with remote repository access via sftp

On 02/10/2022 21:37, Martin Michel wrote:
> Hi Denis,

Hi Martin,

> 
> thanks for the quick update.
> I tried the new version 2.7.8.RC2 and have mixed findings:
> 
>> OK, this is a bug in dar, it is now fixed in git/branch_2.7.x and is
>> available in Release Candidate 2 for 2.7.8 (aka 2.7.8.RC2):
>> https://dar.edrusb.org/dar.linux.free.fr/Interim_releases/
> 
> (1 ✔) Compiling and dynamic linking on my local system:
> This worked! I could access my archive and run dar successfully with -l and -t options given this command:
> [dar-2.7.8.RC2]$ src/dar_suite/dar -l sftp://[email protected]/archives/server4you/first

OK, good to know, thanks for the feedback

> 
>> I've setup a dar_static version with the upgraded static builds of libcurl
>> and librsync, but as I have not run a lot of testing on it, this dar_static
>> binary will be left available only for testing, waiting for official 2.7.8
>> release. You can fetch it at:
>>
>> https://dar.edrusb.org/dar.linux.free.fr/Specific_builds/
> 
> 
> (2) I downloaded this dar_static and here again, different behaviour if I run it from my local system or from my VPS:
> 
> (2.1 - local ✘)
> $ dar_static -l sftp://[email protected]/archives/server4you/first
> Please provide the password for login xxxx at host xxxx.your-storagebox.de:
> Segmentation fault

I have double checked, and I have no segfault with this static binary 
when run on the machine (kvm virtual machine) where it has been 
compiled... though, on a different VM, same kernel, same operating 
system, in fact a former clone of this first VM that has diverged over 
time, I get the Segfault as you get!


> 
> 
> (2.2 - VPS ✘)
> $ ./dar_static_2.7.8.RC2_x86_64_GNU_Linux -t sftp://[email protected]/archives/server4you/first
> Please provide the password for login xxxx at host xxxx.your-storagebox.de:
> No backup file is present in sftp://xxxx.your-storagebox.de//archives/server4you for archive first, please provide the last file of the set. [return = YES | Esc = NO]
> Escaping...
> Final memory cleanup...
> Aborting program. User refused to continue while asking: No backup file is present in sftp://xxxx.your-storagebox.de//archives/server4you for archive first, please provide the last file of the set.
> 
> Note that dar has injected a slash into the path, making it absolute?

that's possible yes, I will review the code to know if so, and why I did 
                       it that way.

> 
> So it seems that dar_static can connect to my sftp but still has problems to read the archive from the given path.
> No problems concerning this with dar dynamically linked though.
> 
> 
> And last but not least, all versions fail to connect with SSH key method.
> If I use sftp directly on my cloud storage, I do not have to enter password because I configured my SSH key for authentication.

you should add -avc command of 2.7.8.RC2 and see what libcurl reports

> 
> Independent from dar or dar_static, I got this error when I try to do the same here:
> 
> (3) with SSH key ✘
> $ ./dar_static_2.7.8.RC2_x86_64_GNU_Linux -t sftp://[email protected]/archives/server4you/first -afile-auth
> Final memory cleanup...
> ---- exception type = [BUG] ----------
> [source]
>          File mycurl_easyhandle_node.cpp line 176 : it seems to be a bug here
>          stack dump : [...]
> 	[...]
> [most outside call]
> ----------------------------------- >
> INTERNAL ERROR, PLEASE REPORT THE PREVIOUS OUTPUT TO MAINTAINER


Thanks for this feedback, I will look forward to analyse and fix it 
soon. But it already sounds interesting in regard to the problem we meet.

> 
> 
> As I interpret the message, it is a libcurl bug?

no, this is sanity check inserted in libdar, that triggers this type of 
message when the code goes to somewhere it should never go.

(for example, incoherence between a variable or object status and a 
function/method that should never be executed in such context)

> 
> Kind regards,
> Martin
> 

Regards,
Denis