@freeseacher а не ты случаем молекулу тыкал ?

тыкал

летом еще

А её как-то можно научить тестировать плейбук целиком, а не роль отдельно ? И у меня есть ощущение что она неделает мердж для переменных

немного магии и chattr +i и всё...

сча ищу вверх, и вижу такие же вопросы %(

а выбрали её или что-то другое в итоге ?

её

мда вот аспект с магией нерадует

пулреквесты да...

молекула хорошая

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

он долго не верил что у фряхи путь до питона другой

и не хотел делать переопределялку для этого

господа помогите понять nomad ?

помощь вида "nomad - это как yarn, только от hashicorp" тебе помогла?

канешна. спасибо бро.

@freeseacher а как указать путь к натив инвентори ? а то у меня переменные в глубине и их игнорит похоже

там обычный ансибл

никаокго рокетсаеса

относись к ней ка кк запускалке вагранта и ансибла и все встанет на сои места

ansible-playbook --become \ --inventory-file "${WORKSPACE}/${PROJECT}/environments/${ENV}" \ --tags=${ACTION} \ ${SKIP_TAGS} \ --extra-vars "env=${ENV} $EXTVARS" \ --vault-password-file ~/.ansible/vault.${PROJECT} \ "${WORKSPACE}/${PROJECT}/${ROLE}.yml" у нас вот такая запускалка ансибла

и когда груп вары лежат в /${PROJECT}/environments/${ENV}/group_vars я вижу красивые ошибки о том что переменные неопределены

Привет народ! Подскажите как можно побороть эту напасть: "Unable to restart service docker: Failed to restart docker.service: Interactive authentication required.\n" Для пользователя, от которого это запускается команды вида sudo systemctl * docker доступны без пароля

Сама же задача выглядит просто

- name: Restart docker become: yes service: name: docker state: restarted

Просто предположу, что sudo выполняется не непосредственно при вызове systemctl, а при вызове сформированного ансиблом скрипта sudo /tmp/.... А на это дело sudo не настроен. Как быстрый хак я бы использовал shell: 'sudo systemctl docker restart', но это заведомо хреновое решение.

А вообще, какой-то диссонанс у меня в голове. Ansible как бы запускается пользователем, который обязан уметь быть рутом. Это ж администрирование все-таки.

и дыра в безопасности, при таком подходе

)

вы так говорите, как будто пользователя прямо скомпрометировать так легко

запретить логин по паролю, нафигачить ключей, прописать allow\deny для ссш пользователей

запретить логин по паролю, нафигачить ключей, прописать allow\deny для ссш пользователей

а как запретить логин по паролю части пользователей (не-руту)?

сохраняя при этом пароль для sudo того же

указать левый шелл

но с логином по ключам

а-ля without-password

Try Match in sshd_config: Match User user1,user2,user3,user4 PasswordAuthentication no Or by group: Match Group users PasswordAuthentication no Or, as mentioned in the comment, by negation: Match User !root PasswordAuthentication no

о, что надо, спс

а пароли для судо при ключах по моему нафиг не нужны

если прое..терять ключ, еще уровень защиты

если проебал ключ - на нём стоит пассфраза

и ключи с проёбаных девайсов немедленно должны удаляться с хостов

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

ERROR: S client not available

не надо так

1 ключ 1 машина

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

поэтому разные пассфразы и пароль судо

1 ключ 1 машина

и будет в дропбоксе 1000 ключей...

сохраняя при этом пароль для sudo того же

для sudo пароль будет. причём тут ssh?

правильнее тогда уж группировать

для sudo пароль будет. причём тут ssh?

при том что "убрать пароль с юзера" - не решение

ну или lock user - который добавит ! перед паролем

PasswordAuthentication no для всех по ssh

и будет в дропбоксе 1000 ключей...

зачем?

авторизация только по ключам

PasswordAuthentication no для всех по ssh

см выше

твоя машина

не сервер

не надо нигде хранить ssh ключи кроме локали

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

разумеется. их надо менять время от времени

зачем?

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

Привет народ! Подскажите как можно побороть эту напасть: "Unable to restart service docker: Failed to restart docker.service: Interactive authentication required.\n" Для пользователя, от которого это запускается команды вида sudo systemctl * docker доступны без пароля

в sudoers Defaults:username !requiretty

а ноут с собой носить не?

при авторизации по ключам пароли для судо нафиг не нужны