нет доменов - нет возможности создания почтовых доменов? как бы в этом есть логика )

котоны - в личку

👌

скорее всего, как привязать домен?

простите еще раз за офтоп, просто хочу закрыть тему по Vesta
нашел инфу что нельзя создать несколько админских аккаунтов
"is not possible to add multiple admin users with permission features"

Это я. Только у меня пока слава богу без винды.

Я юзал шефа, после не много ансибла. Остановился для подобной задачи на солте по причине того, что он умеет а-ля групповые политики. Т.е. ты определил стейты и он их поддерживает. Очень удобно должно выйти с учётом того, что машины baremetal офисные. То свет выключат, то месяцами не включают, то в командировке сотрудник. А солт всё поддерживать должен на должном уровне.

И ещё хотел сказать что у моего коллеги есть опыт только баша. Я вот только на днях я понял - как же ему будет больно входить в солт. Но ни чего не поделаешь. Придётся плакать.

Здравствуйте, подскажите пожалуйста как лучше организовать ci для тестовой ветки, хочу раскатывать стейты из тестовой ветки на тестовые хосты, сделал следующее в настройках мастера:

ext_pillar:
  - git:
    - master https://gitrepo/pillars.git:
    - test https://gitrepo/pillars.git:


gitfs_saltenv:
  - base:
    - ref: master
  - test:
    - ref: test

gitfs_remotes:
   - https://gitrepo/states.git:

в пилларах top.sls

base:
   '*minion*':
     - hosts.{{ grains['id'] }}
test:
   'test':
     - hosts.{{ grains['id'] }}

запускаю оркестрацию с таким содержимом

sls_run_minion:
  salt.state:
    - tgt: 'role:test'
    - tgt_type: pillar
    - saltenv: test
    - pillarenv: test
    - sls:
      - nginx

пишет что неможет найти миньёнов

Comment: No minions returned

Кажется я что-то не то делаю, но примеров как это реализовать найти немогу

Блин как же тяжело было в pillar.stack разобраться. Оказалось дело в следующих вещах

{# --- WARNING --- #}
{# stack config support only jinja like comments#}
{# --- WARNING --- #}

{# --- WARNING --- #}
{# When this config is rendering stack variable(object) doesn't exist yet #}
{# --- WARNING --- #}

{# --- WARNING --- #}
{# Based on previous comment: #}
{# This config is intended only for specifying the rendering order of other files. #}
{# You can only control the order in this file using standard salt data (such as pillars, grains). #}
{# --- #}
{# Conditions based on rendered data by the pillar.stask themselves #}
{# can only be used inside the files that are included here.  #}
{# --- WARNING --- #}

{# --- WARNING --- #}
{# You cannot describe same pillar mulitple twice at one level (file)  #}
{# --- WARNING --- #}

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

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

аларм! джигурда в джиндже

Что-то я не пойму, вроде в документации написано что можно salt-mine адресов с нескольких интерфейсов, только почему-то не получается, как не пробую

ips:
    - mine_function: network.ip_addrs
    - eth0
    - ens10
ips:
    - mine_function: network.ip_addrs
    - interface: eth0, ens10
ips:
    - mine_function: network.ip_addrs
    - interface: [eth0, ens10]

ips:
    - mine_function: network.ip_addrs
    - eth0
    - ens10
ips:
    - mine_function: network.ip_addrs
    - interface: eth0, ens10
ips:
    - mine_function: network.ip_addrs
    - interface: [eth0, ens10]

А чего получается ?

Грейнс чем не подошли ?

ничего не выдаёт. Если по одному запрашивать то норм.

так было бы оптимальнее для окрестрации для настройки wireguard

{# --- WARNING --- #}
{# stack config support only jinja like comments#}
{# --- WARNING --- #}

{# --- WARNING --- #}
{# When this config is rendering stack variable(object) doesn't exist yet #}
{# --- WARNING --- #}

{# --- WARNING --- #}
{# Based on previous comment: #}
{# This config is intended only for specifying the rendering order of other files. #}
{# You can only control the order in this file using standard salt data (such as pillars, grains). #}
{# --- #}
{# Conditions based on rendered data by the pillar.stask themselves #}
{# can only be used inside the files that are included here.  #}
{# --- WARNING --- #}

{# --- WARNING --- #}
{# You cannot describe same pillar mulitple twice at one level (file)  #}
{# --- WARNING --- #}

Сейчас разбираюсь с pillarstack (gitstack), не пойму что оставить в top.sls
вроде top.sls обрабатывается раньше чем stack.cfg
Как у вас реализовано все в stack.cfg или и там и там (top.sls + stack.cfg) ?

Я пока сам разбираюсь. Думаю в top у меня почти ни его не останется. Чем то конечно top удобнее. Но у меня не всё что я хотел получалось описать. Поэтому решил только stack (пока).