Резервное копирование Deja Dup / Boto S3, получение 403 с действительными учетными данными

Я использую Deja Dup для резервного копирования моего ноутбука на S3. Это работало для многих резервных копий, но по состоянию на 20 дней назад перестал работать.

Traceback (most recent call last):
  File "/usr/bin/duplicity", line 1532, in <module>
    with_tempdir(main)
  File "/usr/bin/duplicity", line 1526, in with_tempdir
    fn()
  File "/usr/bin/duplicity", line 1364, in main
    action = commandline.ProcessCommandLine(sys.argv[1:])
  File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 1108, in ProcessCommandLine
    globals.backend = backend.get_backend(args[0])
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 223, in get_backend
    obj = get_backend_object(url_string)
  File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 209, in get_backend_object
    return factory(pu)
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/_boto_single.py", line 161, in __init__
    self.resetConnection()
  File "/usr/lib/python2.7/dist-packages/duplicity/backends/_boto_single.py", line 194, in resetConnection
    raise e
S3ResponseError: S3ResponseError: 403 Forbidden

Я проверил правильность пользовательских политик. Я протестировал их в тестере политик AWS, а также использовал их с CLI AWS для составления списка сегментов, чтения из резервной копии и записи в резервную корзину.

Резервные копии на моем рабочем столе все еще работают и используют те же учетные данные. Резервные копии рабочего стола и ноутбука не входят в одну корзину, но используются одинаковые учетные данные пользователя.

Время моей машины не синхронизировано.

Я проверил правильность настроек deja dup как в пользовательском интерфейсе, так и в редакторе dconf.

Я использую свой ноутбук больше, чем мой рабочий стол, поэтому возможно, что он получил какое-то обновление, которое могло бы испортить вещи, но я не уверен что.

Копался в течение нескольких часов сейчас и в растерянности. Я хотел бы эту резервную копию, прежде чем пытаться обновить до 18.04 в ближайшем будущем.

информация о версии: aws-cli/1.15.79 Python/2.7.12 Linux/4.15.0-30-универсальный botocore/1.10.78 boto 2.49.0
ботокор 1.10.78

Изменить: выше было с Ubuntu 16. Я недавно обновился до Ubuntu 18 и все еще испытываю проблему. Я думаю, что это та же самая проблема, но журналы немного отличаются. Вот что они есть на Ubuntu 18:

DUPLICITY: ERROR 30 S3ResponseError
DUPLICITY: . Traceback (innermost last):
DUPLICITY: .   File "/usr/bin/duplicity", line 1555, in <module>
DUPLICITY: .     with_tempdir(main)
DUPLICITY: .   File "/usr/bin/duplicity", line 1541, in with_tempdir
DUPLICITY: .     fn()
DUPLICITY: .   File "/usr/bin/duplicity", line 1380, in main
DUPLICITY: .     action = commandline.ProcessCommandLine(sys.argv[1:])
DUPLICITY: .   File "/usr/lib/python2.7/dist-packages/duplicity/commandline.py", line 1127, in ProcessCommandLine
DUPLICITY: .     globals.backend = backend.get_backend(args[0])
DUPLICITY: .   File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 223, in get_backend
DUPLICITY: .     obj = get_backend_object(url_string)
DUPLICITY: .   File "/usr/lib/python2.7/dist-packages/duplicity/backend.py", line 209, in get_backend_object
DUPLICITY: .     return factory(pu)
DUPLICITY: .   File "/usr/lib/python2.7/dist-packages/duplicity/backends/_boto_single.py", line 166, in __init__
DUPLICITY: .     self.resetConnection()
DUPLICITY: .   File "/usr/lib/python2.7/dist-packages/duplicity/backends/_boto_single.py", line 191, in resetConnection
DUPLICITY: .     location=self.my_location)
DUPLICITY: .   File "/home/aaronloes/.local/lib/python2.7/site-packages/boto/s3/connection.py", line 628, in create_bucket
DUPLICITY: .     response.status, response.reason, body)
DUPLICITY: .  S3ResponseError: S3ResponseError: 403 Forbidden
DUPLICITY: . <?xml version="1.0" encoding="UTF-8"?>
DUPLICITY: . <Error><Code>SignatureDoesNotMatch</Code><Message>The request signature we calculated does not match the signature you provided. Check your key and signing method.</Message><AWSAccessKeyId>XXXXXCENSORXXXXX</AWSAccessKeyId><StringToSign>PUT

Я очистил свой ключ в журналах, но я убедился, что это правильный ключ. Я не уверен, как получить дубликаты /dejadup, чтобы снова запросить мой секрет AWS, потому что, может быть, это как-то плохо кэшировалось?

awscli 1.15.79
Python 2.7.15rc1 4.15.0-38-generic boto 2.49.0
ботокор 1.10.78

Edit смог получить deja-dup, чтобы запросить у меня новые учетные данные, но все равно без разницы. Я знаю, без сомнения, что двуличность использует соответствующие учетные данные, и я знаю, без сомнения, что учетные данные хороши.

Источник

1 ответ

Попробуйте переустановить двуличность. Большинство подобных проблем можно решить с помощью простой переустановки. В противном случае используйте tar для создания резервной копии диалогового окна / with и следующего кода:

#!/bin/sh
# Backup all files under / directory
# Display message with option to cancel
dialog --title "Backup" --msgbox "Time for backup! Press <Enter> to start backup or <Esc> to cancel." 0 0
# Return status of non-zero indicates cancel
if [ "$?" != "0" ]
then
  dialog --title "Backup" --msgbox "Backup was canceled at your request." 0 0
else
  tarlocation=$(dialog --inputbox "Where would you like to save the TAR file?" 0 0)
  dialog --title "Backup" --infobox "Backup in progress..." 0 0
  cd ~
  # Backup using tar; redirect any errors to a
  # temporary file      
  tar -czf $tarlocation 0 0 >|/tmp/ERRORS$$ 2>&1
  # zero status indicates backup was successful
  if [ "$?" = "0" ]
  then
    dialog --title "Backup" --msgbox "Backup completed successfully." 0 0
  else
    # Backup failed, display error log
    dialog --title "Backup" --msgbox "Backup failed -- Press <Enter> to see error log." 0 0
    dialog --title "Error Log" --textbox /tmp/ERRORS$$ 0 0
  fi
fi
rm -f /tmp/ERRORS$$
clear

Спасибо!

Источник

Итак, я наконец понял это. Это заняло некоторое время, потому что я перестал использовать данный компьютер в качестве основного. Недавно мне понадобилось его использовать, и я решил попробовать еще раз, и ответ пришел ко мне.

В какой-то момент либо boto (маловероятно), либо duplicity/deja-dup перестали использовать учетные данные, которые я предоставил ему в его конфигурации, и начали использовать учетные данные, которые я установил в своих переменных среды. Предполагается, что Boto принимает предоставленные учетные данные перед поиском среды, поэтому я предполагаю, что это как-то связано с duplicity/deja-dup. Я знаю, что произошли изменения, потому что я установил резервные копии и эти переменные среды в тот день, когда получил этот компьютер.

Я удалил переменные среды, и резервные копии снова начали работать.

Тайна наконец разгадана.

Источник
Другие вопросы по тегам