У меня есть сервер, который использует марионеточный vcsrepo для обновления кода в локальном репозитории Mercurial на основе тега.
Когда я изменяю требуемый тег, используя параметр vcsrepo «revision», vcsrepo должен выполнить hg pull и hg update в репо.
Все работает нормально.
Однако я создал клон этого сервера, чтобы проверить что-то еще, и теперь, когда я запускаю обновление марионетки, я получаю сообщение об ошибке:
Not trusting file /var/hg/repo/.hg/hgrc from untrusted user *user*, group *group*
Это происходит потому, что марионетка работает от имени пользователя root, а файл hgrc принадлежит пользователь
Пользовательский параметр в vcsrepo должен иметь дело с этим:
vcsrepo { '/var/hg/repo':
ensure => present,
provider => hg,
source => 'ssh://****',
user => 'user',
owner => 'user',
group => 'group',
revision => '1.12'
}
т.е.
команды hg должны запускаться как пользователь так что требование доверия в Mercurial выполнено.
Но это не работает. Сервер клонирования - это битовая копия оригинала.
Я понял это.
Puppet запускается с правами root. Это означает, что для vcsrepo, использующего mercurial, пользователь root должен доверять пользователю, которому принадлежит файл .hgrc в обновляемом репо.
Чтобы установить это доверие, вы добавляете
[trusted]
user = 'user'
В /root/.hgrc
Когда выполняется mercurial, он ищет доверительные отношения в $ HOME / .hgrc.
На моем существующем сервере марионеточный агент выполнялся с помощью cron, поэтому cron видел бы $ HOME как /root/.hgrc
На клонированном сервере я запускал обновление марионетки в интерактивном режиме, открыв корневую оболочку с помощью
sudo bash
Однако это сохраняет мою переменную $ HOME с тем же значением, что и у моего первоначального пользователя, поэтому mercurial не смог найти требуемую достоверную информацию в /root/.hgrc
Когда я установил корневую оболочку с
sudo -i
Была установлена правильная переменная $ HOME, и обновление марионетки прошло успешно.
Параметр user в vcsrepo относится к пользователю, который используется для аутентификации на ртутном удаленном сервере, а не к пользователю, который запускает процесс на локальном сервере.