я хочу запустить все, кроме 1го из первой группы и все из 2ой группы
тогда, возможно, так: hosts: [(group1:!host1)] + group2
Sergey
Lex
к сожалению...
Vladislav 👻
Там "или" надо вместо плюса вроде
Lex
костыли наше все )
Lex
а зачем или ?
Lex
мне и то и то надо
Vladislav 👻
Поэтому или
Sergey
За что уважаю авторов Ansible - объектная модель чаще всего предполагает только один способ сделать что-то адекватно.
Vladislav 👻
Vladislav 👻
вот так надо
Vladislav 👻
https://docs.ansible.com/ansible/latest/user_guide/intro_patterns.html#working-with-patterns
Vladislav 👻
возможно надо скобки, потому что я по документации не понял, что с приоритетом выполнения булевых операций
Vladislav 👻
- hosts: hostname[1:3]
кстати, к слову, там же есть пример, как можно через регулярку сделать подобное
Артём
А какой правильный способ решить следующую задачу:
linux-пользователю, условно user, от которого выполняется соединение под ansible, запрещено беспарольное su.
become-юзеру, условно root, разрешено беспарольное su.
Создание пользователей модулем postgresql_user выполняется от posgresql-юзера, условно postgres.
В общей части роли всё работает нормально, потому что происходит эскалация user->root, для которой задан пароль. В момент, когда начинается создание пользователей, на попытке эскалации user->postgres, плей падает с ожидаемой ошибкой
FAILED! => {"msg": "Incorrect su password"}
Можно ли решить проблему на уровне плейбука, чем-нибудь вроде смены последовательности эскалаций на user->root->postgres, не трогая настройки pam.su и постгреса?
Vladislav 👻
уже здесь обсуждали подобное, нельзя вроде
Vladislav 👻
точнее не так, можно, но вашему юзеру надо выдать sudo во все стороны, чтобы он мог в обход рута переходить на нужного пользователя
Vladislav 👻
цепочку переходов в ансибле вроде не смог никто не реализовать
Sergey
цепочку переходов в ансибле вроде не смог никто не реализовать
Через модуль shell 😊 Только нафиг оно надо?...
Vladislav 👻
ну или так да и действительно "нафиг" 😬
Артём
Ну, чтобы не трогать согласованные с ИБ настройки pam, очевидно.
Vladislav 👻
согласуйте отдельного пользователя для ансиблы тогда
Vladislav 👻
хотя конечно забавно видеть, как ИБ не дает админам админить - я бы послал таких ИБ
Sergey
Ну, чтобы не трогать согласованные с ИБ настройки pam, очевидно.
Правила группы говорят, что мы не занимаемся согласованием настроек PAM с ИБ: модуля soglasovat_pam в Ansible нет.
В этом случае ваш верный друг - башсибл, к сожалению.
Артём
цепочку переходов в ансибле вроде не смог никто не реализовать
Ну, вот ответ вполне однозначный. Если и правда нет такого - то остальное лирика.
Lex
- hosts: host-group1:!host1:host-group2
так работает! во я...смотрю в книгу вижу фигу ))
благодарю
Timur
А какой правильный способ решить следующую задачу:
linux-пользователю, условно user, от которого выполняется соединение под ansible, запрещено беспарольное su.
become-юзеру, условно root, разрешено беспарольное su.
Создание пользователей модулем postgresql_user выполняется от posgresql-юзера, условно postgres.
В общей части роли всё работает нормально, потому что происходит эскалация user->root, для которой задан пароль. В момент, когда начинается создание пользователей, на попытке эскалации user->postgres, плей падает с ожидаемой ошибкой
FAILED! => {"msg": "Incorrect su password"}
Можно ли решить проблему на уровне плейбука, чем-нибудь вроде смены последовательности эскалаций на user->root->postgres, не трогая настройки pam.su и постгреса?
Не понял проблемы, если честно. А что мешает с паролем сделать become на любого нужного юзера?
Артём
Плей запускается с --become —become-method=su —become-pass=TOOR
Дальше в одном таске переопределяется become-user. Я, честно говоря, не представляю, как пароль повторно затребовать.
Timur
Плей запускается с --become —become-method=su —become-pass=TOOR
Дальше в одном таске переопределяется become-user. Я, честно говоря, не представляю, как пароль повторно затребовать.
Параметры become можно на уровне отдельных тасков определять
Timur
Включая пароль
Артём
Который заправить в vault. Спасибо, это вариант.
Timur
Совершенно верно
Yuf
Я просто хотел попробовать автоматизировать.
То есть на виртуальной машине есть сайт, он работает с под пользователя apache и ему принадлежит.
И хотел автоматизировать в плане заходить не из под root на виртуальную машину, в папку с сайтом и делать git pull с определенной ветки.
Gitlab ci + runner не решит ваших проблем ?
Egor
Gitlab ci + runner не решит ваших проблем ?
Был я там в группе gitlab_ci.
Там свелось все к тому, что я столкнулся с проблемой запуска gitlab-ci.yml на всех gitlab-runner.
Мне сказали, что лучше сделать это с помощью ansible.
Yuf
А по поводу become_method кажись sudo должно быть + плейбук с параметром -K должен запускается
Egor
А по поводу become_method кажись sudo должно быть + плейбук с параметром -K должен запускается
С проблемой толком разобрался.
Там просто под мой случай подходит только модуль shell или безумная игра с правами, так как другие модули дополнительные команды используют, я так понял.
Yuf
Я думаю без топорного shell сможете решить свою задачу
Egor
Я думаю без топорного shell сможете решить свою задачу
Ну или как мне подсказали частый патерн:
ansible пользователь, nopasswd и подключение по ssh ключу.
Max
А какой правильный способ решить следующую задачу:
linux-пользователю, условно user, от которого выполняется соединение под ansible, запрещено беспарольное su.
become-юзеру, условно root, разрешено беспарольное su.
Создание пользователей модулем postgresql_user выполняется от posgresql-юзера, условно postgres.
В общей части роли всё работает нормально, потому что происходит эскалация user->root, для которой задан пароль. В момент, когда начинается создание пользователей, на попытке эскалации user->postgres, плей падает с ожидаемой ошибкой
FAILED! => {"msg": "Incorrect su password"}
Можно ли решить проблему на уровне плейбука, чем-нибудь вроде смены последовательности эскалаций на user->root->postgres, не трогая настройки pam.su и постгреса?
это бессмыслица в общем.
sudo - механизм позволить пользователю x выполнять действие с привилегиями пользователя z.
если ваш основной пользователь должен выполнить действие как postgres, вам нужно настроить /etc/sudoers.d/myuser, в котором вы разрешаете ему делать некоторые операции как postgres.
Max
можно даже это ^^^ сделать временно
Yuf
Egor
Я так и делаю
А такой вопрос получается, в рамках Ансибла в чем получается отличие, от использование просто root.
Ну то есть в обоих случаях я так понимаю идет разрешение всего и вся.
Yuf
У меня есть серваки где root закрыт по ssh ... Приходится так использовать
Vladislav 👻
Рут не везде разрешают удаленное подключение
Vladislav 👻
Заходишь под своим или ансибл юзером специальным и судо в кого угодно - самый нормальный паттерн
Yuf
По дефолту в debian/ubuntu закрыт например в отличие от Centos
Egor
Понял, спасибо за ответы, то есть чисто из за доступности root.
Yuf
Вот мой рабочий плейбук
Yuf
Который на днях тестил
Yuf
Yuf
@egormak
Egor
Yuf
Если что могу линк в приват послать
Timur
Yuf
Совсем все плохо ?
Sergey
Башсибл же 😊
Erick
Yuf
Кидайте помидоры я готов ) плейбук собрал на коленках
Yuf
Неа ;(
Max
если серьезно, идемпотентность, это один из главных win-ов ансибла.
Timur
Ещё по стилю там все очень грустно
Timur
Вот недавно накидывал:
https://lean-delivery.com/ansible-development-kit/docs/ansible_style_guide
Timur
Можете оценить начальный вариант
Max
+100.
Max
насчет причин snake_case - из пайтона это.
Max
в ансибле
Yuf
если серьезно, идемпотентность, это один из главных win-ов ансибла.
Сорри пипл а можно про это по подробнее
Yuf
Yuf
Вот недавно накидывал:
https://lean-delivery.com/ansible-development-kit/docs/ansible_style_guide
Этого будет достаточно ? Или ещё что-то почитать
Max
идемпотентность - способность 'из коробки' делать то что нужно, т.е. перескакивать через то, чего дклать не нужно.
Max
это делают модули.
niko
лол
niko
ты наркоман что ле
Yuf
Хто ?