systemd в продакшене и ентерпрайзе

Каво? systemd сейчас на КАЖДОМ сервере. Какого чёрта он делает возле мёртвого Mir?

А ты что хочешь что бы Mir был на каждом сервере? :D

Ну, Mir стал Wayland-композитором, а Wayland уже можно запускать по сети, так что в некоторых задачах, возможно, и хотел бы. @_@

А расскажите, какие проблемы у вас решили эти замечательные вещи

mir

Не прикасался

вейланд

Не готов, графическая затычка. Альтернатив ксорговым утилкам нема == ненужно. Игорь лагает в усмерть.

системд

Как инит работает. Более нахрен не нужен. Тьфу тьфу проблем нет. Но стараюсь это не трогать.

:D

Платиновые треды ЛОРа, том 19-ый, часть пятая.

systemd никаких проблем не решил, а только заставил читать документацию и запоминать новые команды. Mir вроде как умер, ну а Wayland и Xorg на серверах особо не нужны.

Ну c systemd сильно лучше стало.

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

Wayland пока не засадил - Nvidia. Но жду.

Я одного не могу понять — зачем редхату вообще все эти запарки? Каким образом он может заработать на них так, как не сможет закработать дед ваня-админ?

системд

Просто работает. Юниты правил ровно один раз, iwd из коробки с connman плохо дружил.

mir

Он сырой и в целом не особо нужен.

wayland

Пакетов гораздо меньше, композитор заметно легче, чем xorg + wm + compton. Просто работает, никакой возни с драйверами и прочими непотребствами. Баги чинятся со временем, легаси есть легаси. Тиринга нет.

А вы не слышали новость что придумали системЫ? Там он сразу идет в контейнере и там вроде как-то переименовали логи+конфиги, в реестр вроде. И ещё под виндой запускаться нужно, уже вроде в пм виндовом лежит как полтора месяца, щас заживем на интерпрайзе. Автор мелкомягкие кстати.

Вендорлок обыкновенный. Только в Редхат сейчас могут по сути разобраться в поведении того же systemd, да еще и меняют его с каждым релизом. Та же история с wayland.

А расскажите, какие проблемы у вас решили эти замечательные вещи, и как теперь вам стало с ними легко жить?

Ну.. я как-то настраивал крутилку в usb-звуковухе через lirc и сервис lirc сразу после использования крутилки начинал жрать 100% одного ядра. Жрать не прекращал. И тут мне очень помог systemd: к любому юниту можно сделать override и в нем, например, ограничить использование CPU: CPUAccounting=true CPUQuota=2% И lirc у меня прекратил жрать CPU (не прекратил, конечно, но доступно ему теперь только 2% ядра).

Сейчас я правда переполз на gnome3 и в нем крутилка у звуковухи работает из коробки.

Мы нежеланные Божьи дети

И управлять удобнее, те же журналы.

для ньюфагов разве что. я уже проводил тут спор с ньюфагами. я при помощи oldschool делаю выборку по времени из логов за меньшее число нажатий.

логи RH окончательно испортил. это, пожалуй, одна из самых больших их M$-type какашек за последнее время.

1. Нужны пруфсы;

2. Вопрос в том, что решения на systemd/journalctl будут работать везде, а твой колхоз – неизвестно.

Делай. Кто тебе мешает 😃

Не то чтобы вот прям решил, но по каким-то непонятным причинам на сервере на CentOS не запустился pm2 - выдавал ошибку при старте, ошибка не гуглилась. Я наверно неделю потратил на то чтобы разобраться в проблеме а потом плюнул и оформил веб-приложения на ноде в виде сервисов systemd. Это оказалось проще чем я думал, так и работает, запускается при старте сервера и управляется через systemctl.

Вот журнал правда не понравился.

RH, кто же еще... а те, кто пишут «И управлять удобнее, те же журналы.» наступают на мою больную мозоль)

И глюков с ним не видел в отличии от upstart.

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

Ну если CUPS + SAMBA говносфт, то я даже не знаю как назвать средний десктопный линуксовый проект…

Программисты на марше. Логи испортил Рэд Хэт, а какашки от МС.

мне лично молодой редхатовец особо не стыдясь сообщил, что они используют маркетинговые исследования от M$. так что не знаю, как там старый редхат, а новый повязан с лидерами индустрии: те же исследования, те же выводы, те же идеи... идут хвостом за лидером.

p.s.

программисты - это как раз вы.

systemd-networkd заменил кучу скриптов, которые к тому же не были идемпотентными.

wayland выглядит слишком сырым, а единственными нативными приложениями у меня были композитор и эмулятор терминала. Пытался использовать sway+swaybar вместо xmonad+xmobar, полностью повторить свой близкий к дефолту конфиг xmonad на sway не смог, хотя у меня когда-то получалось это сделать на fvwm.

mir никогда не видел нигде, и почти ничего про него не знаю.

Далее моя оценка происходящему, которая очень поверхостна и субъективна:

Идея systemd хороша, но реализация недостаточно хорошо вписывается в мир POSIX. Надо бы разделить systemd на более число частей, и использовать между ними более типичные для юниксов интерфейсы — примеров достаточно у s6.

wayland хорош и идеей, и реализацией, но нужно больше софта. Нужны более продвинутые утилиты для настройки и опроса оборудования (аналоги xrandr, xset, xinput), для настройки раскладок клавиатуры (те же xinput, xset, xmodmap, setxkbmap), для манипуляций с окнами (xlsclients, xdotool, wmctrl, xkill) и отладки (xev, xtruss). Возможно, нужен какой-то промежуточный слой, так как сейчас слишком много задач возложено на композитор.

Какую задачу решает mir я вообще понять не могу. Да, из описания ясно, что выкинуть легаси-иксы, но каких-то киллер-фич не видно.

через криптошлюх всё идёт

Так и быть, покормлю.

системд

Свитчнул на него генту еще до того как его пометили стабильным, загрузка и выключение стали очень быстрыми по сравнению с опенрц. Сейчас, правда, ментейнеры наклепали юнитов с задержками, но все равно неплохо. Журнал с поисковым индексом позволяет удобно и быстро смотреть сообщения интересующего сервиса за интересующий период. Мультисит настраивать стало легко и приятно, loginctl в связке с udev и xorg позволяет просто приаттачить юсб хаб к определенному месту и все, что пользователь этого места в него воткнет, будет доступно в сеансе, который запущен на нем, и не будет в других.

wayland

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

systemd никаких проблем не решил

Решил. Теперь скриптов-обвязок над демонами писать надо в разы меньше.

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

Документацию всегда полезно читать.

системд

А расскажите, какие проблемы у вас решили эти замечательные вещи, и как теперь вам стало с ними легко жить?

Ну с systemd реально легче жить, фичастый супервизор, вменяемые логи, сеть, контейнеры, логины. У всего этого есть вменяемый однообразный CLI и D-Bus API.

Супервизор. Можно не писать костыли для проверки условий, слежения за процессами, перезапуска упавших демонов (и того, что от них зависит), расстановки лимитов/приоритетов. В systemd это всё искаропки и автоматически. Ах да, я могу сделать echo "[Service]\nEnvironment=FOO=bar" >> /etc/systemd/system/foo.service.d/bar.conf или systemctl set-property foo.service CPUQuota=20%, и это будет работать в общем случае без ручного копания в инитскриптах каждого конкретного демона.

Логи. @crypt может сколько угодно сочинять про происки жидомасонов из RH, но journalctl -u some_fancy_shit.service --since '12:34:56' --until '23:45:01' или journalctl -k -b-1 написать быстрее, проще и удобнее, чем трахаться с грепоседом.

Контейнеры. Ну nspawn просто удобнее LXC и LXD вместе взятых, и он есть искаропки на каждой машине. Я уже говорил про вменяемый однообразный CLI?

Сеть. Мне вообще это не особо важно, я не питаю отвращения к NetworkManager (у меня он даже на серверах кое-где), а netcfg в арче и так достаточно приятен, но по сравнению с башелапшой из других дистрибутивов тут просто no contest.

Ах да, ресолвер. systemd-resolved — это единственный линуксовый ресолвер, который автоматически делает the right thing в случае одного или нескольких VPN, в каждом из которых есть свой внутренний DNS-сервер для внутренних доменов.

Про дбас. Можно например написать простейший скрипт на питоне, подцепиться к D-Bus сигналам на нужных эндпоинтах и мониторить всё что происходит в системе (падения демонов, выполненные задачи, логины пользователей). Из пейлоада можно вытащить invocation ID и ещё одним вызовом выбрать логи, сгенерированные конкретным процессом (или всеми процессами демона за его последний запуск). Очень годно и удобно. У меня так сделаны типа_алерты на домашнем сервере.

вейланд, mir, позиционируя их, как глобальную замену устаревшим <…> xorg

А каким боком вейланд, Mir и Xorg к продакшену и энтерпрайзу?

Только в Редхат сейчас могут по сути разобраться в поведении того же systemd, да еще и меняют его с каждым релизом. Та же история с wayland

Ну типа системд сейчас 10 лет, а башескриптам — полвека. Тупо поэтому найдется больше людей, которые смогут разобраться в последнем. В остальном ядро — 100 тыс строк, а со всеми возможными модулями это миллион строк. В grep 150 тыс строк, но я почему-то не вижу, чтобы кто-то орал «никто не понимает grep, grep становится неподъемным для простого волонтера проектом».

Контейнеры. Ну nspawn просто удобнее LXC и LXD вместе взятых, и он есть искаропки на каждой машине

Вот что я не ожидал — так что буду согласен с тобой. nspawn — это «правильный» контенер.

Вопрос в том, что решения на systemd/journalctl будут работать везде, а твой колхоз – неизвестно.

Везде это где? Сейчас даже под шиндой можно грепнуть скопированный лог. А что делать с базой journalctl ?
И не забываем что «колхоз» таки остался. Часть логов в бинарщине часть остается в текстовом. «Разнообразие» так сказать получилось.

Логи. @crypt может сколько угодно сочинять про происки жидомасонов из RH, но journalctl -u some_fancy_shit.service --since '12:34:56' --until '23:45:01' или journalctl -k -b-1 написать быстрее, проще и удобнее, чем трахаться с грепоседом.

если учесть, что sed здесь не при чем, ты просто не знаешь это кунг-фу. я грепну,

вместо
journalctl -u some_fancy_shit.service --since '12:34:56' --until '23:45:01'
так
grep "Jan 12" /va/log/some

а потом воспользуюсь комбо в текстовом редакторе для выборки и это будет проще, чем твои танцы с '--' и "'.

а теперь скажи мне, как нам очистить логи для выбранного сервиса (-u)?

или как нам сделать удаленное логирование для этого сервиса?

nspawn — это «правильный» контенер.

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

Сеть. Мне вообще это не особо важно, я не питаю отвращения к NetworkManager (у меня он даже на серверах кое-где), а netcfg в арче и так достаточно приятен, но по сравнению с башелапшой из других дистрибутивов тут просто no contest.

ну да, NM - это официальный выбор редхат, а networkd - недоделка с проблемами от ЛП. дублированный функционал в рамках одной конторы. Арррхитектура!

«питоновая лапша» aka NetworkManager у меня во времена CentOS 6 не подымал сеть по DHCP на рабстанциях в отличие от башелапши.

а на серверах сеть не часто переделывают.

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

Я тебе скажу секрет, но докер тоже не предполагает безопасности. То, что некоторые люди используют его из соображений «да меня никто не взломает» — это правда, никто не взломает, потому что ты никому не нужен. Ну, или потому что твои сервисы наглухо огорожены и там хоть на баше можно крутить сервисы. Серьезные дяди, вроде гугла и амазона, чужие контейнеры запускают в выделенных виртуалках.

Ах да, ресолвер. systemd-resolved — это единственный линуксовый ресолвер, который автоматически делает the right thing в случае одного или нескольких VPN, в каждом из которых есть свой внутренний DNS-сервер для внутренних доменов.

о, поздравляю, они покрыли твой юзкейс! да! именно поэтому мы вибираем Linux. не потому что мы инженеры и нам важна гибкость! нет, мы любим готовые решения, потому что мы стали жирные и ленивые, как M$ админы.

Я тебе скажу секрет, но докер тоже не предполагает безопасности

??? знаешь, даже если ты гей и откроешь мне по секрету, что у вас в компании 55% сотрудников геи, я что-то не пойму, какой вывод я должен из этого сделать. я вот не гей и докер не использую.

Серьезные дяди

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

Ах да, ресолвер. systemd-resolved — это единственный линуксовый ресолвер, который автоматически делает the right thing в случае одного или нескольких VPN, в каждом из которых есть свой внутренний DNS-сервер для внутренних доменов.

о, поздравляю, они покрыли твой юзкейс! да! именно поэтому мы вибираем Linux. не потому что мы инженеры и нам важна гибкость! нет, мы любим готовые решения, потому что мы стали жирные и ленивые, как M$ админы

А вот у меня жопа горела, когда я инет через PPTP подключал, потому что в лине норм не работал резолв.

А вот у меня жопа горела

обратись к коллегам. systemd в продакшене и ентерпрайзе (комментарий)

они потушат.

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

Только ты не понимаешь, что я на лоре где-то с 2008 и работал во все-СНГ-шной конторе с 2011. Дальше что? По сути есть что ответить?

обратись к коллегам. systemd в продакшене и ентерпрайзе (комментарий)
они потушат

В убунте десятой и бсде не было resolveconf, а вместо этого resolve.conf правился вручную/скриптами/костылями. И это был ад, который всех устраивал.

… используют маркетинговые исследования от M$

Интересная информация. Спасибо

Единообразие конфигурации. Зависимость между сервисами, то есть не нужно матерясь выяснять, почему не может запустить то-то и то-то.

Единообразие конфигурации. Зависимость между сервисами, то есть не нужно матерясь выяснять, почему не может запустить то-то и то-то

Да. Преимущество монолита над микросервисами.

Да. Преимущество монолита над микросервисами.

Это не имеет отношение к монолиту или микросервисам. С OpenRC можно делать то же самое, просто он не так распространен.

Это не имеет отношение к монолиту или микросервисам. С OpenRC можно делать то же самое, просто он не так распространен

Но в итоге функции шела внутрь OpenRC интегрируют. Да, systemd — это перегиб, не спорю. Но старая система инициализации была перегибом в обратную сторону.

Не то чтобы вот прям решил, но по каким-то непонятным причинам на сервере на CentOS не запустился pm2 - выдавал ошибку при старте, ошибка не гуглилась. Я наверно неделю потратил на то чтобы разобраться в проблеме а потом плюнул и оформил веб-приложения на ноде в виде сервисов systemd.

У меня похожая ситуация была, только pm2 запускался и жрал дохрена RAM. Выкину pm2, заюзал systemd – проблема ушла. Ну а года через два я выкинул ноду и взял Java. Тоже systemd заюзал, вот уже год как без проблем всё работает и никакой баш-лапши.

Но в итоге функции шела внутрь OpenRC интегрируют.

Чавой?

Да, systemd — это перегиб, не спорю. Но старая система инициализации была перегибом в обратную сторону.

Старая система инициализации это какая? Sysv? Это по сути rc.local на стероидах.

Но в итоге функции шела внутрь OpenRC интегрируют.

Чавой?

Да, я ошибся. Busybox остается извне, просто ее собирают в жирном варианте. Естественно, вы вольны использовать свой вариант шела.

Старая система инициализации это какая? Sysv? Это по сути rc.local на стероидах

Ну да, башпортянка.

Да, я ошибся. Busybox остается извне, просто ее собирают в жирном варианте. Естественно, вы вольны использовать свой вариант шела.

Я просто не очень понял чо происходит. OpenRC хочет bash для своих сценариев в /etc/init.d.

Ну да, башпортянка.

Depends. Вон в OpenBSD сделали нормально:

#!/bin/ksh
#
# $OpenBSD: vmd,v 1.10 2019/01/21 01:41:16 claudio Exp $

daemon="/usr/sbin/vmd"

. /etc/rc.d/rc.subr

# Child will not return a config parsing error to the parent.
rc_pre() {
	# use rcexec here since daemon_flags may contain arguments with spaces
	${rcexec} "${daemon} -n ${daemon_flags}"
}

rc_stop() {
	_rc_do vmctl stop -a -w
	pkill -T "${daemon_rtable}" -xf "${pexp}"
}

rc_cmd $1

Я просто не очень понял чо происходит. OpenRC хочет bash для своих сценариев в /etc/init.d

Ну хз, если у тебя #!/bin/bash в заголовке, то конечно захочет. Так-то на busybox вполне себе народ запускает OpenRC.

Depends. Вон в OpenBSD сделали нормально

А что правильного? Сама /etc/rc.d/rc.subr — это башпортянка, которая, например, не сможет отреагировать на старт/падение сервиса, не сможет реализовать сокетную активацию сервиса.