Я создал сценарий, который запускается двуличие для резервного копирования файлов, которые у меня есть на VPS, и использует ключ GPG, который я создал как пользователь.
Когда я пытаюсь запустить этот сценарий как СУДО, я получаю:
GPGError: GPG Failed, see log below:
===== Begin GnuPG log =====
gpg: C7B2Y6DO: skipped: public key not found
gpg: [stdin]: encryption failed: public key not found ===== End GnuPG log =====
Теперь я понимаю, почему это так (потому что это не ключ SUDO, это ключ пользователя), но прежде чем я пойду и заново сгенерирую ключ для SUDO, можно ли заставить sudo использовать ключ пользователя?
Не очень важно, но сценарий смоделирован на основе комбинации этих трех сайтов: http://www.cenolan.com/2008/12/how-to-incremental-daily-backups-amazon-s3-duplicity/
http://www.randys.org/2007/11/16/how-to-automated-backups-to-amazon-s-s3-with-duplicity/
Решение: в сценарий bash добавлено следующее:
HOME=/home/user/
Плавник
Вы пробовали --homedir вариант?
Я считаю, что конфигурация sudo по умолчанию - сохранить $ HOME. Итак, если вы вошли в систему как user1 и использовали sudo scriptname где имя сценария echo $HOME, вы должны ожидать, что в ответ будет "/ home / user1", а не "/ root".
Я предполагаю, что BassKozz не изменил этого. Возможно, он не вошел в систему как желаемый user1, запустив сценарий как sudo. Возможно, он действительно просто запускает скрипт от имени пользователя root, например, через cronjob root. В этом случае его $ HOME никогда бы не был / home / user1, поэтому даже если sudo сохраняет значение $ HOME, это не помогает. В этом случае должны работать любые другие ответы, которые говорят вам, как установить $ HOME на правильное значение или сообщить gpg, где находится ваш домашний адрес.
Если, однако, это правда, поскольку он говорит, что он даже не может запустить свой дублирующий скрипт «как sudo» - то есть, когда вошел в систему как user1 и набрал sudo duplicity_script, то проблема не в неверно установленном $ HOME. Как мы видели, в этом случае $ HOME должно иметь правильное значение. Так что проблема в другом. Я недостаточно слышал и недостаточно хорошо знаю duplicity + gpg, чтобы предположить, что это может быть.
Если вы используете параметр «--preserve-env» для sudo, то GPG в сеансе sudo сможет найти gpg-agent, работающий в собственном сеансе.
Пример:
sudo --preserve-env ВАША_КОМАНДА ...
Вы уверены, что хотите шифровать свои резервные копии с помощью пользовательского gpg-ключа?
если у вас нет отдельной резервной копии вашего gpg-ключа (что, я надеюсь, у вас есть), вы не сможете расшифровать какие-либо резервные копии, если вы потеряли содержимое своего домашнего каталога.