Почему куколка пытается внести изменения в файлы пользователя, используя учетные данные другого пользователя, и терпит неудачу? - PullRequest
0 голосов
/ 02 января 2019

На некоторых серверах puppet пытается внести изменения в файлы и каталоги пользователя, используя неверные учетные данные пользователя, и завершается неудачей.

Я использую puppet на 8 серверах, некоторые с Ubuntu OS (puppet 6.0.4 18.04, puppet 5.5.8 16.04) и некоторые с Debian 9 (puppet 5.5.8). На трех серверах Ubuntu (не на всех), один с puppet 5.5.8 и два с 6.04, puppet делает что-то странное:

При запуске puppet agent --test --debug вывод выглядит следующим образом (псевдоним, конечно):

Notice: 
/Stage[main]/User/Ssh_authorized_key[user1@computer1]/ensure: 
removed
Info: Computing checksum on file /home/user1/.ssh/authorized_keys
Debug: Creating /home/user1/.ssh as user2
Error: /Stage[main]/User/Ssh_authorized_key[user1@computer1]: Could 
not evaluate: Permission denied @ dir_s_mkdir - /home/user1/.ssh
Notice: 
/Stage[main]/User/Ssh_authorized_key[user3@computer3]/ensure: 
removed
Debug: Creating /home/user1/.ssh as user2
Error: /Stage[main]/User/Ssh_authorized_key[user3@computer3]: Could 
not evaluate: Permission denied @ dir_s_mkdir - /home/user1/.ssh

Обратите внимание, что агент puppet работает от имени пользователя root, а user1, user2 и user3 - обычные пользователи.

Puppet был установлен из официального репозитория puppetlabs, следуя текущей документации.

Что я заметил, так это то, что, хотя в манифесте-марионетке пользователи идентифицируются, и на их группы ссылается только их имя пользователя, которое идентично на всех серверах (user1 - user1 на всех серверах), uid и gid - нет. управляется puppet и отличается (user1 имеет uid 1001 на одном сервере и 1003 на другом). Как бы то ни было, марионетка не должна использовать uid, если она не указана в манифесте.

Есть идеи?

1 Ответ

0 голосов
/ 02 января 2019

Мой комментарий выше был правильным, я включаю его для других, имеющих такую ​​же проблему: Похоже, что в отличие от марионеточного управления здесь purge_ssh_keys, если установить в «user1», не только

"... ищите ключи в файле .ssh / authorized_keys в доме пользователя каталог. Удалите все ключи, которые не управляются как ssh_authorized_key ресурсы ".

и удаляет все ключи, не установленные как «ssh_authorized_key» для «user1».

Но также пытается удалить любое вхождение ключа, установленного как "ssh_authorized_key" для "user1" в файле с авторизацией любого другого пользователя.

...