рпм так накатывает по крайней мере от этого юзера

там права на установку тоже дал

Потому что пытается сделать рестарт от юзера mgr без sudo

он бы тогда не написал нет прав?

Вроде нельзя ограничить список команд через судо для ансибл

become не стоит делать для переключения на юзера без рутовых прав

https://docs.ansible.com/ansible/2.5/user_guide/become.html#can-t-limit-escalation-to-certain-commands

Огребете кучу проблем

https://docs.ansible.com/ansible/2.5/user_guide/become.html#can-t-limit-escalation-to-certain-commands

Совершенно верно

ансибловому юзеру нельзя ограничивать права

Или не стоит пытаться делать этим юзером то, что требует повышения прав с помощью sudo

ансибловому юзеру нельзя ограничивать права

так я хочу дать юзеру права только на установку рпм и рестарт сервиса

Тогда никакого become делать не надо

У юзера должны быть права на это без sudo

передавать по ссш рута или привелигерованного пользователя не хотелось бы

Рута не надо

Просто дайте права юзеру на рестарт сервиса без sudo

И уберите все become

Будет работать тогда

а из мат части, тот синтаксис который я написал рабочий?

Если become убрать - то да

сейчас проверю то же самое на руте

Можно сделать raw: sudo systemctl restart nginx become: yes И все должно быть ок при текущих настройках

Можно сделать raw: sudo systemctl restart nginx become: yes И все должно быть ок при текущих настройках

хотелось бы по понятием с модулем)

хотелось бы по понятием с модулем)

Кажется нет внятного способа ограничить права на уровне sudoers?‍♂

Кажется нет внятного способа ограничить права на уровне sudoers?‍♂

печаль конечно, я с ансибл не очень пока хорошо знаком, но это логично ограничвать права учётке для установки по и рестарта сервиса

Кажется нет внятного способа ограничить права на уровне sudoers?‍♂

Есть, но способ так сказать уникальный авторский

То есть костыльный

Связкой FreeIPA + AWS

Сколько это будет стоить по затратам времени и сил - не знаю.

хотелось бы по понятием с модулем)

Что мешает просто дать нужные права юзеру?

Нужные это рут для запуска питона?

Нет, это права на перезапуск сервисов

Что мешает просто дать нужные права юзеру?

дал, через суду)

Хоть питоном, хоть как

дал, через суду)

Без sudo

Права на перезапуск сервисов ансиблом?

Нет, это права на перезапуск сервисов

Через systemd? Policy kit?

проверил, с рутом прокатывает, проблема в правах

Без sudo

проще тогда через комманд или шелл так понимаю

дал, через суду)

Ансиблу пофиг ваш sudo. Он копирует питоновскую прогу на хост под своим юзером. Потом запускает ее под ним же. Если есть вызов become, то переключается на рута для запуска. Если указан специальный юзер - переключается на него. И запускает всю директиву от этого юзера. Ансибл не делает просто sudo systemctl. Это не баш.

Через systemd? Policy kit?

Да, как вариант

Ансиблу пофиг ваш sudo. Он копирует питоновскую прогу на хост под своим юзером. Потом запускает ее под ним же. Если есть вызов become, то переключается на рута для запуска. Если указан специальный юзер - переключается на него. И запускает всю директиву от этого юзера. Ансибл не делает просто sudo systemctl. Это не баш.

под каким юзером он копирует свою прогу?

под каким юзером он копирует свою прогу?

Под тем, которым вы подключаетесь к хосту

Да, как вариант

Настраивали когда-нибудь?

Под тем, которым вы подключаетесь к хосту

я подклчают под тем же

Питоновский модуль для перезапуска сервиса никакое sudo не вызывает

Питоновский модуль для перезапуска сервиса никакое sudo не вызывает

косяк)

Это не косяк

Это просто вы не понимаете, как работает ансибл, и хотите странного :)

Вам сказали, как можно решить проблему

с устаноской рпм через модуль юма прокатило суду

Либо давайте соответствующие права ансибловому юзеру без sudo

Либо тому юзеру, на которого делается sudo

Я буду благодарен за ссылку на объяснения как работает ансибл

А еще лучше - просто дать права ансибловому юзеру делать sudo на рута

А еще лучше - просто дать права ансибловому юзеру делать sudo на рута

не хотелось бы передавать по сети такого юзера

Тогда сделайте другого юзера с соответствующими правами и переключайтесь с помощью become на него

Тогда сделайте другого юзера с соответствующими правами и переключайтесь с помощью become на него

так понимаю проще всего вызывать через комманд

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

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

Да

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

я подключаюсь через того же юзера

так понимаю проще всего вызывать через комманд

Ну, если вам это проще, то и ансибл не нужен тогда :)

mgr

У юзера, которым вы подключаетесь, нет нужных прав

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

Если пользователю дать права выполнять sudo systemctl но не дать выполнять, предположим, sudo apt, то пользователь сможет управлять службами, но не сможет ставить софт модулями ансибл?

Если пользователю дать права выполнять sudo systemctl но не дать выполнять, предположим, sudo apt, то пользователь сможет управлять службами, но не сможет ставить софт модулями ансибл?

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

Если у пользователя есть право сделать sudo systemctl, то он просто становится рутом на время исполнения этой команды

Права на запуск тех или иных программ, я это так формулирую. По сути обе команды - это программы =)

Но это работает только для этой конкретной команды

К правам на запуск питона это не относится :)

Чудесно. То есть если пользователю не давать права на запуск питона из под рута, то ансибл подключающийся к хостам с учётной записью пользователя будет работать в части модулей и программ которые ограниченны теми правилами, которые расписаны в политике sudo?

Написал конечно как насрал, но эти бесконечные авторизации и права доступа требуют такой вот казёнщины

Чудесно. То есть если пользователю не давать права на запуск питона из под рута, то ансибл подключающийся к хостам с учётной записью пользователя будет работать в части модулей и программ которые ограниченны теми правилами, которые расписаны в политике sudo?

Если у пользователя, под которым подключился ансибл, нет права эскалировать привилегии любым способом (не только sudo), то ансибл будет выполняться только от этого юзера с его родными правами. Политики sudo для этого юзера ансиблу параллельны

Ансибл - это не баш

Вы неправильно использовали become, потому что

become нужно использовать для переключения на юзера, у которого есть права на выполнение нужных действий (например, перезапуск сервиса)

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

Вы неправильно использовали become, потому что

там не только бикам, там еще бикам метод, как можно неправильно использовать суду) и почему рпм в данной конфигурации с биками прокатывает суду?

Become тут не нужен, это я неправильно написал, а не ansible

Подскажите, пожалуйста, в документации добавление нескольких ключей для пользователя выглядит так: - name: Set up multiple authorized keys authorized_key: user: deploy state: present key: '{{ item }}' with_file: - public_keys/doe-jane - public_keys/doe-john А если есть список пользователей и каждому надо несколько ключей прописать, как тогда код выглядеть будет?

там не только бикам, там еще бикам метод, как можно неправильно использовать суду) и почему рпм в данной конфигурации с биками прокатывает суду?

become делает, условно говоря sudo su - mgr, и от него уже запускает нужный питоновский таск с модулем

become делает, условно говоря sudo su - mgr, и от него уже запускает нужный питоновский таск с модулем

а нет под рукой ссылки на эти подробности?

Почему rpm у вас работает - я не знаю. Может, права у юзера есть соответствующие без sudo

а нет под рукой ссылки на эти подробности?

https://docs.ansible.com/ansible/2.7/user_guide/become.html

а нет под рукой ссылки на эти подробности?

Можно просто вызвать плейбук с -vvvv и увидеть команды которые выполняет ансибл

Питоновский код там не увидишь :)

https://docs.ansible.com/ansible/2.7/user_guide/become.html

спасибо, эту уже бегло листал

В режиме дебага можно увидеть ключи, с которыми запускается ssh сессия и питоновские модули

Но что делает сам питон, там не увидишь - только результат в виде output и error

Питоновский код там не увидишь :)

Вроде и не нужно

Если интересно, как работает модуль systemd, то можно посмотреть в код

https://github.com/ansible/ansible/blob/devel/lib/ansible/modules/system/systemd.py

спасибо!

ansible осень настала

Подскажите, пожалуйста, в документации добавление нескольких ключей для пользователя выглядит так: - name: Set up multiple authorized keys authorized_key: user: deploy state: present key: '{{ item }}' with_file: - public_keys/doe-jane - public_keys/doe-john А если есть список пользователей и каждому надо несколько ключей прописать, как тогда код выглядеть будет?

Проитерироваться по чему-нибудь типа users: - username: jane keys: | Key1 Key2 - username: john keys: | Key3 Key4

Проитерироваться по чему-нибудь типа users: - username: jane keys: | Key1 Key2 - username: john keys: | Key3 Key4

я не могу разобраться как именно итерирование написать. получается что надо по пользователям идти, с этим ок authorized_key: user = {{ item.username }} state = present key = "{{ lookup('fileglob', 'files/public_keys/*').split(',') }}" with_items: '{{users}}' в вот эта часть key = "{{ lookup('fileglob', 'files/public_keys/*').split(',') }}" пока не работает. да, тут просто все клчи из папки пробую добавить пока что