скажите, пожалуйста, в ансибл 2.8.1 нормально что он запускает таску, которая помечена тэгом когда я не указываю его при запуске плейбука??
- name: Delete ssh keys on servers
lineinfile:
state: absent
path: "/home/{{ ansible_user }}/.ssh/authorized_keys"
line: "{{ item }}"
with_items:
- "{{ stefan_home }}"
tags:
- delete
запускаю так ansible-playbook playbooks/ssh_keys.yml -l prom-storage
TASK [Delete ssh keys on servers] *****************************************************************************************************
ok: [prom-storage]=> (item=ssh-rsa
а ты писал скип-тегс?
Ivan
Driver
Stefan
Да, нормально. По умолчанию теги игнорируются, если не заданы ключи вызова соответствующие
вот как, насколько помню в старых версиях ансибла он видя таску с тэгом но не указаный при запуске, то скипал сразу
Timur
Для regex лучше так:
when: url is regex("example.com/\w+/foo")
Stefan
Нормально, если хотите пропустить, используйте --skip-tags
и аргументом передавать нужный тэг?((
Stefan
что-то это не удобно они сделали, разве нет? раньше ведь не нужны были такие манипуляции
Stefan
эх
Timur
Тогда будут запускаться только таски без тегов
Timur
Или --tags untagged
Timur
By default, Ansible runs as if --tags all had been specified.
Stefan
а смысл было перепиливать то что было?
Ivan
Тимур, я правильно понимаю, что ансибл ищет питон той версии, что и на контроллере?
Timur
Он ищет дефолтный питон
Timur
Ему пофиг какой
Timur
В старых версиях ансибла искал в пути /usr/bin/python
Ivan
Что значит дефолтный питон?
Странно.
На ноде он есть, но третий. И 2.7.2 его не видит, только после установки минимала. который тащит питон2.7
Timur
Что значит дефолтный питон?
Странно.
На ноде он есть, но третий. И 2.7.2 его не видит, только после установки минимала. который тащит питон2.7
2.7 действительно не видит, потому что путь у питона не /usr/bin/python, правильно?
Timur
2.8 более корректно детектит пути
Timur
https://docs.ansible.com/ansible/latest/reference_appendices/faq.html#how-do-i-configure-a-jump-host-to-access-servers-that-i-have-no-direct-access-to
Timur
https://docs.ansible.com/ansible/latest/reference_appendices/config.html?highlight=ansible_python#interpreter-python
Ivan
У меня 2 вехи ещё в проекте, переход на 2.8 и впил митогена
Ivan
с чего лучше начинать?
Timur
Лучше с 2.8
Timur
Там больше нюансов может быть
Павел П.
Добрый день, вопросик.
ансибл версии 2.7.2
модулем apt хочу обновить пакет до последней мажорной версии.
получаю
version number inconsistent with state=latest: mypackage=1:0.24*"
Если делать state не latest а present - вообще ужас
Unable to correct problems, you have held broken packages
В гугле нашлось только
https://stackoverflow.com/questions/41375578/ansible-install-package-pinned-to-major-versions
что про другой модуль и никак не помогло.
Что делать?
Павел П.
*минорной версии конечно же
Dmitriy
а вы руками пробовали ? мне не нравится "Unable to correct problems, you have held broken packages", это похоже на ошибку пакетного менеджера
Timur
Timur
Это уже не на уровне ансибла
Отделение Bereke Bank
@gecube твой выход 😏
Отделение Bereke Bank
Да 😂
Dmitriy
*offtop* будто на centos не может быть проблем с пакетным менеджером
George
их там меньше
Отделение Bereke Bank
не может 😏
inqfen
У меня yum ломался, совсем как-то
inqfen
На 6 центосе вроде
Павел П.
да, походу и права в версиях пакета до 1:0.25 есть ошибки в зависимостях.
c state=present отработало
Спасибо!
Dmitriy
их там меньше
да бросьте вы, все ломается, все зависит от кривизны рук, кхем, администратора. Подобное мне доставалось в наследство, много крови попило
Dmitriy
я же о том же, сломать можно все, особенно если бездумно копипастить команды под рутом с сайта васи хацкера.
Dmitriy
да, походу и права в версиях пакета до 1:0.25 есть ошибки в зависимостях.
c state=present отработало
Спасибо!
к слову, наскольк я понял state present как раз ставит, если отсутствует, последнюю версию пакета доступного в менеджере пакетов, но он не обновит версию пакета, если стоит старая версия. Поэтому, как по мне, state latest, в большинстве своем, предпочтительнее, если задача не стоит иначе.
Павел П.
к слову, наскольк я понял state present как раз ставит, если отсутствует, последнюю версию пакета доступного в менеджере пакетов, но он не обновит версию пакета, если стоит старая версия. Поэтому, как по мне, state latest, в большинстве своем, предпочтительнее, если задача не стоит иначе.
да вот с latest ругнулся
с present 1:3.16*
обновил с 1:3.16.0 до 1:3.16.12 хотя в репозитории были и 3.17 и 3.18
Отделение Bereke Bank
к слову, наскольк я понял state present как раз ставит, если отсутствует, последнюю версию пакета доступного в менеджере пакетов, но он не обновит версию пакета, если стоит старая версия. Поэтому, как по мне, state latest, в большинстве своем, предпочтительнее, если задача не стоит иначе.
state: latest не идемпотентен
Я так чуть куб не уронил, когда кубелет обновился и послал старый конфиг нафиг 😅
Dmitriy
да вот с latest ругнулся
с present 1:3.16*
обновил с 1:3.16.0 до 1:3.16.12 хотя в репозитории были и 3.17 и 3.18
довольно странно, если често. Но думаю это более глубже знать логику работу, чтоб понять почему произошло именно так, чего я , увы, не знаю.
George
Скажите, если мне нужно найти в каком файле находится конфиг (сетевой интерфейс в старых бубунтах/дебианах), то это ещё ансибл или уже модуль?
Отделение Bereke Bank
Не понял. В старых оно же всегда было /etc/network/interfaces?
George
А в новых может быть /etc/network/interfaces.d/чопопалотут
Timur
Timur
ansible_facts.network
George
Смотрю. Какой факт там говорит об имени конфига?
Timur
Там интерфейсы все можно найти
Timur
Тебе же они нужны?
George
Нет, мне нужен файл конфига в котором интерфейс настраивается. Интерфейс я и так знаю.
George
Но, кстати, идея с кастомными фактами мне нравится больше, чем кулибинство в середине модуля.
George
George
Поясню. Никто не мешает один и тот же интерфейс объявить во всех возможных местах. Я видел такое. Приоритет - у NM перед ifup. Прям дичь какая-то
George
Поэтому правильно заходить с другого конца - не пытаться понять как сконфигурирована сеть, а сконфигурировать ее тем способом, который считаешь нужным
George
Понимаю, что это не всегда возможно. Но даже в облачных средах ты эту проблему решишь
George
Мне нужно алиас на интерфейс повесить. Персистентно, чтобы после ребута жил.
George
Причем машины не ты наливал ?
George
Всё хуже. Часть - baremetal с чужим провизом, часть - виртуалки. Условно говоря, есть требование с нашей стороны о дистрибутиве, но вот точное положение имени конфига сказать не можем. Либо /etc/network/interfaces, либо interfaces.d/
George
А что мешает тебе алиас в своем месте определить ?
George
Я поигрался с кастомными фактами, кажется, это путь к успеху. Их можно на питоне написать, и всё сделать по совети (включая тесты).
George
Которое будет совместимо с обоими способами ?
George
ifupdown не умеет несколько конфигов дочитывать. А писать юнит с повешиванием алиаса на интерфейс - стрельба себе в ногу (а если интерфейс переименуют?)
George
ifupdown не умеет несколько конфигов дочитывать. А писать юнит с повешиванием алиаса на интерфейс - стрельба себе в ногу (а если интерфейс переименуют?)
А если переименовали, то старую запись алиаса как ты грохнешь ?
George
Я вижу, что лучше, чем модуль. Кастомный факт не завязан на ансибл и просто выдаёт кусок json'а наружу. Идеально для отладки.
George
У меня по ТЗ ограничение по ОС есть.
George
Просто в пределах ifupdown внутри одного дистрибутива сильно большой разброд, чтобы можно было захардкодить.
George
В моём окружении 90% с /etc/network/interfaces.d/, это официальная бубунтоводная методология.
George
Модуль, кстати, сложнее писать, чем факт. И отлаживать сложнее.
George
Факт руками запустить можно, а модуль требует ансибла.
Terry
херасе бот