а что есть

{ "id" : "memory:2", "class" : "memory", "handle" : "DMI:003D", "description" : "Flash Memory", "physid" : "3d", "slot" : "System board or motherboard", "units" : "bytes", "capacity" : 8388608, "children" : [ { "id" : "bank", "class" : "memory", "handle" : "DMI:003F", "description" : "FLASH Non-volatile 33 MHz (30,3 ns)", "product" : "25X/Q Series", "vendor" : "Winbond", "physid" : "0", "units" : "bytes", "size" : 8388608, "width" : 8, "clock" : 33000000 } ] },

биос?

хммм вот такой вопрос: - есть rpm который устанавливается через yum - есть rpm группа, которая может присутствовать, а может не присутствовать есть ли у кого идея, как без shell красиво через when проверить, есть ли на хосте хотя бы один пакет из группы rpm? например, группа rpm - nginx, haproxy, mysql, и если хотя бы один из группы есть - нужно вкатить на хост net-tools. если нету - пройти мимо…

хммм вот такой вопрос: - есть rpm который устанавливается через yum - есть rpm группа, которая может присутствовать, а может не присутствовать есть ли у кого идея, как без shell красиво через when проверить, есть ли на хосте хотя бы один пакет из группы rpm? например, группа rpm - nginx, haproxy, mysql, и если хотя бы один из группы есть - нужно вкатить на хост net-tools. если нету - пройти мимо…

ошибочный юзкейс

ошибочный юзкейс

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

https://habrahabr.ru/post/305400/#comment_9695112 - коммент =)

закинуть бы в комменты линк на этот чат.. ))

придут 100500 человеков. будут трындеть про хостинг. зачем нам это :) ?

хостинг перенапрвлять в хостинг ) а с ансиблом может будет и спецов больше..

придут 100500 человеков. будут трындеть про хостинг. зачем нам это :) ?

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

нуок )

кто подскажет, можно ли внутри lookup еще указать вложенную переменную в качестве пути к темплейт файлу: virt: name={{ inventory_hostname }} command=define xml="{{ lookup('template', "{{ template_file }}"') }}"

девапсы, а расскажите, вы в плейбуки включаете таск на апдейт всей системы? А-ля: - name: update system become: yes yum: name='*' state=latest

девапсы, а расскажите, вы в плейбуки включаете таск на апдейт всей системы? А-ля: - name: update system become: yes yum: name='*' state=latest

нет

вот я тоже так думаю

а как вы апдейтите системы?

а как вы апдейтите системы?

запланированно

запланированно

сначала на dev и staging

потом, после все ок — на прод

отлично, спасибо

ну это кроме критических обновлений безопасности, там отдельный подход

А расскажите за отдельный подход

для начала, как вы узнаёте, что вышло критическое обновление безопасности?

нет

Однажды таким образом получил расхождение libmemcached. В одном месте сервера обновились, а в другом нет

CVE или новости дистриба

CVE или новости дистриба

то есть не автоматически, читаете CVE

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

то есть не автоматически, читаете CVE

угу, в основном, пока выйдут апдейты — уже везде разжевано как только можно

после доступности — вне очереди выкатка на dev/stage прогон смоков и выкатка

процедура та-же в принципе, но вне очереди

спасибо

только не регрессия а смоки ганяем — обновления безопасности не ломают функциональность, в основном

вот такой кейс: - есть файл №1 (кусок статического и подкладываемого на сервер конфига) - есть файл №2 (кусок динамически генерируемого через templates+inventory конфига) - includes не поддерживается приложением для которого конфиг нужно: слить файлы в один проблема: - в lineinfile не подставить template - в blockinfile не подставить template - assemble не умеет работать с избранными двумя файлами в папке (а их там много) - перемещать куда-то файлы - shell начинается и вообще телодвижения лишние - template не умеет дописывать в начало и конец файла можно сделать shell: cat file1 >> file2 и всё ок, но осадочек остался.

кейс решается не очень красиво, но решается: в файл №2 сразу запихивается весь статический конфиг. с другой стороны это тоже конфиг, почему бы ему там не лежать.

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

ну а как ты бы сделал, точно так же?

конечно. только изначально. без этих головняков.

зачем склеивать конфиги на сервере, если их можно склеить сразу здесь

иначе это опять fabric какой-то, а не ансибл

ну вот показалось логичным хранить в files большие куски конфигов, которые не меняются.

ок, thanks.

зачем склеивать конфиги на сервере, если их можно склеить сразу здесь

про именно ансибл пока не могу утверждать, а вообще смысл делить конфиги есть - например, 1 сущность - 1 конфиг. У нас apache и nginx так сделано. И да, это удобно.

сравнил жопу с пальцем

но если такое деление ничего практического не даст - то да, нах надо.

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

ну у меня был один сервис, просто у него был кусок статический (большой) + кусок динамический, обновляемый каждый раз при прогоне, поменялось инвентори - перевыкати конфиг. не тот случай.

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

можно сделать прелоадер, который соберет 1 из нескольких.. но смысл?

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

а оф позиция нгинха - "инклуды не нужны". Так-то (с).

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

можно сделать прелоадер, который соберет 1 из нескольких.. но смысл?

ну я через pre_task сделал, он идет на хосты за пределами роли, и собирает с них переменные, а иначе он про них ничего не узнает.

опять начали.. нормально же сидели. инклуды им не нужны…

условия тоже не нужны, может быть? где-то я видал петицию даже.

инклуды нужны, когда от них есть толк )

а оф позиция нгинха - "инклуды не нужны". Так-то (с).

инклуды не нужны.

я помнится видел одну толстую инсталяцию. точнее какое то время ее админил.

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

ибо 100500 инклудов

давайте отменим инклуды, отменим if, вот петиция: http://antiifcampaign.com так отменим bool, так победим.

инклуды не нужны.

ну сделай сотню сайтов у нгинха.. и чтобы можно было отключить в произвольное время 1 хост, а через неделю включить назад. И придешь ты к шаблонам. А потом добавь вот именно этой паре хостов особые локейшены, и шаблоны станут сложнее нгинховых. И компилятор в 1 конфиг на каждый чих, да. Вот она, сила говноподелия и бредовых устоев

"для уменьшения конфигурации" ибо "все и так знают наши дефолты" и "в этом месте накосячить нельзя" и "тут поведение по умолчанию лучше подходит"

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

всё хорошо в меру.

а, и главное — всё это должно рулиться автоматом!

то есть тьма шаблонов или тьма седов-грепов

и это дерьмо :)

да, лучше 1 файл и тьма седов-грепов..

вот кстати, иногда склоняюсь ко мнению, что большой конфиг с include - это следствие, а не причина. идеально, когда код занимает страницу и читается.

и я лучше буду 100500 инклудов админить, чем 1 файл

давайте отменим инклуды, отменим if, вот петиция: http://antiifcampaign.com так отменим bool, так победим.

это для какого языка вообще? )

быть может 100500 файлов должно быть на стороне системы управления. но на выходе желательно иметь один файл.

ибо nginx не умеет выводить конфиг в стиле "include defaults"

хотя nginx -T уже шаг в нужном направлении

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

потому что олени инклудили, что уж тут сделаешь. если уебашки, привыкшие к .htaccess, начинают начинать свое любимое дрочилово "программирование на конфигах" - это всегда боль

вот да. программирование на конфигах - это жесть.

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

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

в обучении новых людей.

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

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

позитивная сторона тоже есть: неплохой скилл вырабатывает - разбираться в чужом конфиге.

доведенный до абсурда

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

ты про 500 миль ?

нет, про конфиг sendmail, который сначала был "простой", а потом упоролись до такого состояния, что его надо было КОМПИЛИРОВАТЬ

нет, про конфиг sendmail, который сначала был "простой", а потом упоролись до такого состояния, что его надо было КОМПИЛИРОВАТЬ

там тоже про сендмайл :)

m4 - это просто!

нет, про конфиг sendmail, который сначала был "простой", а потом упоролись до такого состояния, что его надо было КОМПИЛИРОВАТЬ

кто не компилирует конфиги - тот лох.

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

)

вообще конфиг должен быть вхуячен в бинарник с кодом

ОДИН СТАТИК ФАЙЛ, ГО ГО ГО, ЯСОЗДАЛ :)

хаха. да, в go именно так.

один бинарник + один конфиг.

и конфиг вкомпилен в бинарник

вообще конфиг должен быть вхуячен в бинарник с кодом

это код должен быть вхуячен в бинарник с конфигом!

чо то флейм пошел.

m4 - это просто!

Особые олдфаги писали на том языке, в который оно компилировалось...

например, я. было дело :)