Re: [Duplicity-talk] Problems with Hubic cron tasks

[Tapio Sokura]

Hello,

The user the task is run as is the same as when the task is run manually from 
the shell. Only that user has the .hubic_credentials etc files and the task 
does succeed sometimes when run under cron, but mostly not.

Is there a way to get more useful information on what exactly fails during 
connecting/authentication phase? I tried upping the verbosity level, but it 
doesn't give much about this phase of the process..


  Tapio

On March 30, 2018 11:31:12 AM UTC, Kenneth Loafman <address@hidden> wrote:
>Under cron the task is running as root, not the user.  One thing to try
>is:
>
>sudo -i user; duplicity --name=backup2018 ...
>
>That will make cron run as the user.
>
>...Ken
>
>
>On Wed, Mar 28, 2018 at 11:19 AM, Tapio Sokura via Duplicity-talk <
>address@hidden> wrote:
>
>> Hello,
>>
>> I'm using duplicity 0.7.16 (epel packaged, I see 0.7.17 is also
>available
>> there now) with Hubic on CentOS 7, with a cron task that runs a few
>times
>> per month. The command line is something like this:
>>
>> duplicity incr --name backup2018 --asynchronous-upload
>--encrypt-sign-key
>> 0xAAAAAAAAAAAAAAAA --use-agent --exclude-device-files
>> --exclude-other-filesystems --log-file /location/of/hubic-backup.log
>> --volsize 900 --allow-source-mismatch --max-blocksize 8192
>/mnt/sourcedir
>> cf+hubic://backup2018
>>
>> The problem is that mostly the cron tasks are not going through.
>Always
>> the error seems to be related to authentication / connecting to
>hubic. Here
>> are some typical error messages:
>>
>> most common:
>> Connection failed, please check your credentials: KeyError 'error'
>>
>> a few occasions:
>> Connection failed, please check your credentials:
>AuthenticationFailed
>> Unable to authorize client_id, invalid login/password ?
>>
>> The user home directory has a .hubic_credentials file with working
>Hubic
>> credentials in it. I've tried both not touching .hubic_tokens and
>removing
>> the .hubic_tokens file before backup to have it recreated with fresh
>> tokens, but it doesn't seem to work reliably either way.
>>
>> When manually running duplicity from command line as the same user I
>seem
>> to have better luck. Is there something special that needs to be
>accounted
>> for when using cron to run duplicity? Currently I'm just setting PATH
>and
>> SHELL to match what the user running duplicity has natively in a
>login
>> shell.
>>
>>   Tapio
>>
>> _______________________________________________
>> Duplicity-talk mailing list
>> address@hidden
>> https://lists.nongnu.org/mailman/listinfo/duplicity-talk
>>