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

я щас ещё раз перечитал доку, тепреь не жопой, и немного понел что become этож уже после соединения

(и что я зря имя пользователя в ключ "become" запихал, ага)

получается без правки конфига проиграть плейбук под другим юзером не выйдет?

погоди

ты что хочеьш?

http://docs.ansible.com/ansible/playbooks_delegation.html

ты что хочеьш?

у меня есть плейбук cold, оно подготавливает базовые вещи на сервере, включая управление пользователями и вот этим всем

run_once - кажется это твой кейс

первый раз его надо играть от рута

дальше от deploy пользователя

потому что после первого проигрывания рута выключат

гм

какой-то ты сложный

может не надо рута "того"?:)

надо, надо

pci dss?

да

iso 27001?

может не надо рута "того"?:)

как не надо-то?

а

да и без pci тоже не надо

не надо, логин отключить еще куда не шло

а вот целиком рута....

ну так логин и отключаетс

PermitRootLogin noooooooo

ну, да, я так и подумал тоже

просто если у тебя логин от рута заборонен, как ты будешь плейбуки от него гонять без become?

короче, единственный вариант, который я для тебя вижу - новые машины в один инвентари, после провижина - в другой инвентари

ну в теории можно в cold.yml оставить только выключалку рута

и остальное провижен вынести в другой плейбук и его гонять уже от deploy пользователя

ну напиши обертку, которая будет хост ранить с параметрами и переносить имя хоста в другой файл

а withoutpassword не ?

у них pci, им никак нельзя

причём самый мерзкий saq который на 60 страниц :(

либо переходи на saltstack

там твою задачу можно реализовать

только провижин будет сложнее :)

ну уж нет

я уже натрахался с ансиблом, мне чот пока хватит

получается без правки конфига проиграть плейбук под другим юзером не выйдет?

да почему, в inventory прямо пропиши, например )

или параметром передай

если бы у аргументов был правильный приоритет я бы тут не нудел, а первый раз простоб играл с -u root

и гладил бы себе соски от счастья

-E

чо мешает-то? у него максимальный приоритет

круче только йайца

и то не факт

эм, я чот ен вижу такого ключа -E

-e вижу

да

он, сорян

тоесть сделать в host_vars/all переменную там run_as: deploy и потом тупо через -e run_as: root оверрайдить?

с remote_user: "{{ run_as }}"?

типа того

а глобальную конфигурацию remote_user куда принято класть?

для всех плейбуков?

grou vars?

или еще проще ansible-playbook blabla.yml -e remote_user=root -i inventory

м

по идее ты можешь ремоут юзер переопределить и так

нука

чот нифига, один член идёт на хост как deploy

блин

ну тогда run_at остается :(

некрасиво, правда

хотя блин

я помню что переопределял

:(

яж говорю, параметры передаваемые через cli ваще смысла не имеют

должны, может там формат другой

я ж дано теребонил ансибль

потому что приорет у конфигурации

потом долго сидел на папете

потому что приорет у конфигурации

нет

ну вот есть ключ

-u REMOTE_USER, --user=REMOTE_USER connect as this user (default=None)

http://docs.ansible.com/ansible/playbooks_variables.html#variable-precedence-where-should-i-put-a-variable

extra vars (always win precedence)

пример из доки