Swuder

Решено, помогли на другом ресурсе. Из офф документации:

become_user set to user with desired privileges, the user you ‘become’, NOT the user you login as. Does NOT imply become: yes, to allow it to be set at host level.

В become_user указывается пользователь, права которого требуется получить через sudo, соответственно нужно было указать root'a, а не myuser.

В каком месте у win_shell есть атрибут state ?

Ansible

Для Prometheus есть несколько систем для долговременного хранения данных. Самая простая в поддержке VictoriaMetrics

https://github.com/VictoriaMetrics/VictoriaMetrics
https://github.com/thanos-io/thanos
https://github.com/grafana/mimir

Выбирайте любую

Есть ли смысл делить небольшую сеть (около 30 компьютеров, 15 ip-камер, 15- ip-телефонов, пару серверов) на подсети, если она будет поделена на vlan-ы?

Если отвечать на этот вопрос, игнорируя любые другие вещи, то - да, причём не просто имеет смысл, а необходимо.

Формально, если компьютеры в одном вилане, камеры в другом, а телефоны в третьем, то они существуют так, словно подключены к разным коммутаторам. И вроде тогда пофиг, какие подсети. Но..

Всем этим надо управлять, всё это надо мониторить, и некоторые узлы из одного вилана должны будут получать доступ к узлам другого. Например, компьютер охраны должен будет видеть изображения с камер, а админ - иметь возможность управления сервером IP-телефонии...

Как можно обеспечить доступ? ну либо соответствующие рабочие станции будут иметь две и более сетевых карт, либо будет единый сервер маршрутизации. Но в обоих случаях для корректной работы необходимо, чтобы не было пересечения по подсетям, иначе настройка таблиц маршрутизации превратится в весьма непростую задачу, особенно в случае дублирования адресов.

Вопрос для курсовой работы.

А вот это означает, что необходимо рассмотреть ВСЕ возможные схемы организации сети, сравнить их между собой, и только на основании этого сравнения ответить на вопрос, надо или нет.

VLAN это не только возможно разделить большие сети.
В обычной жизни 30+15+15=60 устройств это не много для офиса и администраторы редко заморачиваются vlan, т.к. не всегда есть возможно купить коммутаторы которые умеют работать с VLAN.

Но для курсовой можно выделить такие плюсы использования vlan
1. Безопасность. Хорошим тоном является выносить такие устройства как камер, телефоны, принтера, сервера в отдельную сеть (vlan) и настраивать ограниченный доступ. Что позволяет оградить потенциально любопытных пользователей, злоумышленников, зараженные ПК от возможности скомпрометировать сеть предприятия.
2. Qos. Разделение на vlan позволяет настроить приоритет трафика в этом vlan, что может быть актуально для VoIP трафика.
3. Сервера. Это так же связано с безопасность, часто сервера имеют публикацию, что потенциально открывает возможность взлома данного сервера из мира. Для повышения безопасности, сервера с публикацией необходимо размещать в отдельном VLAN так называемая зона DMZ, у которой нет или есть ограниченный доступ в локальную сеть. Так же использование одной сети открывает возможности для использования атак по типу MITM.
4. Диагностика. Гораздо проще найти виновника пакостей когда сеть сегментирована на VLAN. Например, если сервера и ПК будет в одной сети, то какакой-то пользователь назначит на свой ПК IP аналогичный серверу и все устройства в сети будут иметь проблемы с доступом к этому серверу.
5. Так же WIFI стоит разделять минимум на два VLAN, гостевой и рабочий. Гостевой соответственно не должен иметь доступа к внутренней сети. Рабочий должен иметь ограниченный доступ т.к. в него может подключаться устройства BYOD которые покидают компанию и могут потенциально нести(принести) угрозу.
6. VPN. Разделение на VLAN упрощает построение VPN сетей при маштабировании компании или предоставлении сотрудникам доступа из вне посредствам VPN.

Нужно менять в той части конфигурации, которая в DCS хранится, через patronictl edit-config

Петцольд "Код тайный язык информатики"

в initrd/init вместо /bin/sh я указал setsid cttyhack sh. Ошибка пропала

общепринятых нормах поведения

Ха, ха и ещё раз ха. Общепринятые нормы? Стандартные пути? Это всё не про линукс.

Если вы пишите программу для линуксоидов, то она должна работать абсолютно нестандартно и неудобно максимально далеко от общепринятого user-friendly виндового подхода.

Отсутствует конфиг? Ну так пусть программа ищет его в /var/, потом в ~/.config/, затем в /user/conf, и ещё в переменных среды + можно задать значения флагами при запуске.

Не работает без конфига? Ну так пусть создаст и размажет по системе 10 разных конфигов, которые друг друга includят.

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

Сложно запомнить? Лень писать документацию? Пусть пользователи записываются в mailing list, а цитаты оттуда можно вставить в максимально неудобном непонятном формате в man. --help, разумеется, должен показывать rtfm.

p.s.
Это не шутка. Реальные enterprise программы так и работают.

ОП, ты хочешь странного. Осознай, что демоны (а systemd управляет как раз программами типа daemon) по определению не предназначены для взаимодействия непосредственно с пользователем, в частности через терминал. А значит, у тебя два выхода:

1. Перестать хотеть странного, и реализовать нормальные логи и анализировать их. Тогда можно будет в любой момент посмотреть историю, выведенную в лог.
При необходимости отслеживать файл лога в реальном времени можно использовать команду tail -f файл.log. Почитай про неё.
Также можно натравить на лог какую-нибудь утилиту мониторинга, которая будет его читать и посылать тебе оповещения о событиях по другому каналу.
Если лог большой, есть logrotate.
Минус - специфические терминальные фишки в логе работать не будут. Скажем, прогрессбар там не сделаешь, и ввести текст не получится.

2. Отказаться от запуска программы как классического демона, и запускать её через утилиту screen. Тогда ты сможешь сконнектиться к сессии screen когда угодно.
Плюс - взаимодействие с терминалом как обычно. В том числе из разных ssh сессий.
Минус - screen не самая удобная штука, сочетания клавиш там мозголомные. Плюс всё равно запуск screen придётся заворачивать в systemd если тебе нужен автозапуск и автоперезапуск.