[NIXP] Systemd получил новые сетевые возможности: форвардинг и маскарадинг IP, базовое управление брандмауэром

[Bizdelnick]

А о том, что люди не используют systemd - они ведь сами это пишут. То есть ругают systemd и пишут, что не используют его. Нет тех, кто бы использовал и ругал одновременно

А что, надо обязательно плакать и колоться, но жрать? Если человек не использует systemd, это не значит, что он его в глаза не видел или "видел как-то раз".

Покажите пожалуйста ваш гибкий и удобный скрипт запуска демона vsftpd для sysVinit. А я покажу как это в системд-юните выглядит. Вот и сравним у кого гибче и удобнее.

А я как-то уже приводил пример инит-скрипта, который невозможно было перевести в юнит systemd, если не писать враппер на том же шелле. Если Вы забыли (а Вы не могли пройти мимо темы про systemd, так что Вы его должны были видеть), напомню: там в качестве аргумента команде надо было передать вывод другой команды.
Именно это и означает, что шелл - гибче. В одном случае имеем просто скрипт, в другом - конфиг + скрипт. Вопрос: что проще?

[Vascom]

Ну вот видите - "простыня", а в системд-юните всего несколько строк. Которые обеспечивают не меньший функционал.
Так что непонятно что же вас не устраивает.

Конечно же проще конфиг+скрипт, как в системд. Ведь когда просто один скрипт - это простыня и даже не unix way пресловутый. Получаем данные (конфиг отдельно) и протой скрипт отдельно вместо одного сложного скрипта.

[Yaros]

Ну вот видите - "простыня", а в системд-юните всего несколько строк. Которые обеспечивают не меньший функционал.
Так что непонятно что же вас не устраивает.

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

Конечно же проще конфиг+скрипт, как в системд. Ведь когда просто один скрипт - это простыня и даже не unix way пресловутый. Получаем данные (конфиг отдельно) и протой скрипт отдельно вместо одного сложного скрипта.

Простыня потому что довольно подробно все расписано. В случае ошибок или корректировки поведения - гораздо точнее отлавливаются ошибки. А в чем неюниксвейность, не объясните?
В чем критичность выносить конфиг в случае скрипта, который встречается в системе один раз? Наплодить сущностей, чтоб поразнообразнее?

[Vascom]

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

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

Неюниксвейность в том, что в простыне смешиваются данные (конфиг) и интерфейс их обработки (сам скрипт). А это уж точно не unix way.
Создать один файл конфига в /etc это не "наплодить сущностей". Большинство программ-демонов и так имеют конфиг - вот и надо его использовать.

[Bizdelnick]

Vascom
В случае systemd сложность никуда не девается, она оказываеся в init. Который по определению обязан быть предельно простым, потому что упадёт он - упадёт вся система.
Да, и почему Вы сводите вопрос к unit vs. initscript? Основная часть претензий к systemd остаётся в итоге в стороне.

[Yaros]

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

Без этих допусловий вообще знать про систему инициализации не нужно. Она работает, настроена идеально и никто про нее не в курсе.

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

Я могу в /etc/init.d/ однострочников на перле накидать. По Вашей логике, там точно проще искать ошибку в случае чего =)

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

Если, кстати, начать все сокращать, то простыни не выйдет. А в подробно разжеванной простыне текста ошибок как раз меньше.
Заодно расскажите, с чего простыня превратилась в "сложную простыню"?

Неюниксвейность в том, что в простыне смешиваются данные (конфиг) и интерфейс их обработки (сам скрипт). А это уж точно не unix way.
Создать один файл конфига в /etc это не "наплодить сущностей". Большинство программ-демонов и так имеют конфиг - вот и надо его использовать.

В скрипте на 50 строк достаточно данные вынести в начало скрипта. Городить конфиг ради, по сути, констант - это как раз точно не unix-way.

Да, и почему Вы сводите вопрос к unit vs. initscript? Основная часть претензий к systemd остаётся в итоге в стороне.

К скриптам он сводит, потому что я аргументы с ними в примере приводил.

[Bizdelnick]

Неюниксвейность в том, что в простыне смешиваются данные (конфиг) и интерфейс их обработки (сам скрипт).

Не смешиваются. Конфиг лежит отдельно и сорсится скриптом как в дебианообразных, так и в редхатообразных дистрибутивах. В случае с systemd этот конфиг, кстати, тоже используется, только он, разумеется, не сорсится, а парсится, поэтому там нельзя использовать конструкции более сложные, чем переменная=значение.

[Vascom]

У вас так часто падает init и вы каждый раз выясняете в чём проблема?

Не надо путать однострочник на перле с простым и понятным синтаксисом systemd-юнитов. Вы подменяете понятия.

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

У нас вот нет проблем в использовании systemd. И мы не обсираем другие системы инициализации и новости о их достижениях (побольше бы таких новостей). Прошу и вас воздержаться. А так же пишите багрепорты, фичареквесты, участвуйте в разработке, чтобы было всё как вам удобно.

Кстати, системд легко позволяет использовать старые простыни. Так что всё же непонятно, что конкретно вас не устраивает.

[Bizdelnick]

У вас так часто падает init и вы каждый раз выясняете в чём проблема?

Если бы он у меня хоть раз упал, я бы серьёзно занялся поиском замены ему (и, вероятно, дистрибутиву). Но кода в нём, по счастью, мало, оттестирован он вдоль и поперёк, так что вероятность подобного безобразия стремится к нулю. Когда кода до фига и больше, вероятность сюрпризов очень сильно возрастает.

Кстати, системд легко позволяет использовать старые простыни. Так что всё же непонятно, что конкретно вас не устраивает.

почему Вы сводите вопрос к unit vs. initscript? Основная часть претензий к systemd остаётся в итоге в стороне.

[Vascom]

Так озвучьте эту "основную часть" претензий к системд. Вкратце и без эмоций.
Только не забывайте, что systemd в процессе развития, всё можно поправить, изменить.

[Bizdelnick]

Так озвучьте эту "основную часть" претензий к системд.

Я выше две ссылки приводил, почитайте.

systemd в процессе развития, всё можно поправить, изменить.

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

[Vascom]

Процесс развития - это же хорошо. Ядро тоже меняется, графический стек, DE всякие. Почему же нападки лишь на systemd? Значит не в развитии дело.
Если вам не требуется - просто не обновляйте свои системы - и вопрос решён.

Вот почему нельзя так сразу обсуждать новость, а не как на первой странице?

[Yaros]

Не надо путать однострочник на перле с простым и понятным синтаксисом systemd-юнитов. Вы подменяете понятия.

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

У вас так часто падает init и вы каждый раз выясняете в чём проблема?
...
В общем вы из пальца высасываете себе проблемы. Выглядит так, что вам просто лень (может возраст не позволяет) перестроить своё мышление и научиться чему-то новому.

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

Кстати, системд легко позволяет использовать старые простыни. Так что всё же непонятно, что конкретно вас не устраивает.

А зачем костыль для старых простыней, если можно остаться на старом ините?
Вообще, основная претензия у меня к systemd - то, что он пытается все вокруг себя повязать. То бишь, не-unixway.

[Vascom]

Вот, уже лучше. Начинаете говорить "по мне", то есть понимаете, что все люди разные, запросы и возможности у них разные, что нельзя огульно хаять то, что делают другие для себя (systemd).

Что значит "он пытается"? Systemd одушевлённый и действует самостоятельно? Или его только один Леннарт делает, а не десятки людей?
Разработчики, маинтейнеры, системные администраторы, пользователи выбирают systemd потому что он для них удобен.
Ни кто же лично вас не заставляет использовать systemd (а если заставляет - это, наверное, лиш ваш работодатель, но не Леннарт), или использовать весь функционал systemd?
Ну не пользуйтесь, зачем мучиться?

[Bizdelnick]

Ядро тоже меняется, графический стек, DE всякие. Почему же нападки лишь на systemd?

С ядром отдельный вопрос. Полноценных альтернатив ему нет, у прочих вариантов существенно хуже функционал. Сравнивать, по сути, не с чем. Если же говорить об изменениях - они никогда (за крайне редкими исключениями) не ломают того, что работало, такова политика Линуса. Леннарту есть, чему поучиться.
Графический стек и DE - да, меняются. Но пока никто не выкидывает из дистрибутивов Xorg, чтобы заменить его на Wayland. Никто не выкидывает Xfce или тайловые WM в угоду GNOME. Наоборот, в дистрибутивы усиленно добавляют MATE. Чего возмущаться-то? Свобода выбора - это прекрасно, чем больше альтернатив - тем лучше. Кому не нравится GNOME3 - таки возмущаются, тут Вы неправы, но они уходят на MATE или что-то другое и успокаиваются.

[Vascom]

Так выкидывает не Леннарт, а разработчики дистрибутивов. Что же вы их не ругаете?
Они получили в своё распоряжение отличный инструмент, наверное увидели в нём плюсы для своих дистрибутивов.

Возникает вопрос: почему вы промолчали, не переубедили их? А вы лишь продолжаете ругать Леннарта.

[Yaros]

Вот, уже лучше. Начинаете говорить "по мне", то есть понимаете, что все люди разные, запросы и возможности у них разные, что нельзя огульно хаять то, что делают другие для себя (systemd).

Что значит "он пытается"? Systemd одушевлённый и действует самостоятельно? Или его только один Леннарт делает, а не десятки людей?
Разработчики, маинтейнеры, системные администраторы, пользователи выбирают systemd потому что он для них удобен.
Ни кто же лично вас не заставляет использовать systemd (а если заставляет - это, наверное, лиш ваш работодатель, но не Леннарт), или использовать весь функционал systemd?
Ну не пользуйтесь, зачем мучиться?

Проблема в том, что Gnome завязан уже на systemd частично. То есть, меня напрягает, что в линухе меня начали лишать выбора и отходить от unix-way.

[Vascom]

Ну так это же Гном виноват.
А то получается вы вините куст какао в том, что шоколад очень вкусный и люди от него толстеют.

Леннарт же не виноват, что вы не разработчик Гном и не можете повлиять на них.

[Bizdelnick]

Так выкидывает не Леннарт, а разработчики дистрибутивов. Что же вы их не ругаете?

Ругаем, не перживайте. (-:

А то получается вы вините куст какао в том, что шоколад очень вкусный и люди от него толстеют.

Нет, мы ругаем макдак за то, что люди подсаживаются на него и толстеют. Разница в том, что куст растёт себе и растёт, а макдак на этом бизнес делает.

[yars]

Простой пример - видел я как-то инит-скрипт запуска сервиса для System V - ад и израиль

Опять снова-здорово?

Spoiler

Код: Выделить всё

$ cat /etc/rc.d/rc.networkmanager
#!/bin/sh
#
# NetworkManager:   NetworkManager daemon
#
# description:  This is a daemon for automatically switching network \
#               connections to the best available connection. \
#
# processname: NetworkManager
# pidfile: /var/run/NetworkManager/NetworkManager.pid
#

prefix=/usr
exec_prefix=/usr
sbindir=${exec_prefix}/sbin

NETWORKMANAGER_BIN=${sbindir}/NetworkManager

# Sanity checks.
[ -x $NETWORKMANAGER_BIN ] || exit 0

PIDFILE=/var/run/NetworkManager/NetworkManager.pid

nm_start()
{
  if [ "`pgrep dbus-daemon`" = "" ]; then
    echo "D-BUS must be running to start NetworkManager"
    return
  fi

  # Just in case the pidfile is still there, we may need to nuke it.
  if [ -e "$PIDFILE" ]; then
    rm -f $PIDFILE
  fi

  echo "Starting NetworkManager daemon:  $NETWORKMANAGER_BIN"
  $NETWORKMANAGER_BIN
}

nm_status()
{
  local pidlist=`cat $PIDFILE 2>/dev/null`
  if [ -z "$pidlist" ]; then
    return 1
  fi
  local command=`ps -p $pidlist -o comm=`
  if [ "$command" != 'NetworkManager' ]; then
    return 1
  fi
}

nm_stop()
{
  echo -en "Stopping NetworkManager: "
  # Shut down any DHCP connections, otherwise the processes will be orphaned
  # and the connections will not come up when NetworkManager restarts.
  if ps ax | grep /sbin/dhcpcd | grep -q libexec/nm-dhcp ; then
    ps ax | grep /sbin/dhcpcd | grep libexec/nm-dhcp | while read line ; do
      kill -HUP $(echo $line | cut -b 1-5)
    done
  fi
  if ps ax | grep /sbin/dhclient | grep -q /var/lib/NetworkManager ; then
    ps ax | grep /sbin/dhclient | grep /var/lib/NetworkManager | while read line ; do
      kill -HUP $(echo $line | cut -b 1-5)
    done
  fi
  local pidlist=`cat $PIDFILE 2>/dev/null`
  if [ ! -z "$pidlist" ]; then
    kill $pidlist &>/dev/null
    sleep 3
    rm -f $PIDFILE &>/dev/null
  fi
  echo "stopped";
  sleep 3
}

nm_restart()
{
  nm_stop
  nm_start
}

case "$1" in
'start')
  if ( ! nm_status ); then
    nm_start
  else
    echo "NetworkManager is already running (will not start it twice)."
  fi
        ;;
'stop')
  nm_stop
        ;;
'restart')
  nm_restart
        ;;
'status')
  if ( nm_status ); then
    echo "NetworkManager is currently running"
  else
    echo "NetworkManager is not running."
  fi
        ;;
*)
  echo "usage $0 start|stop|status|restart"
esac

Чего неясно?

[yars]

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

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

[Vascom]

Всё сложно и неочевидно.
То ли дело юнит:

Код: Выделить всё

[Unit]
Description=Network Manager
Wants=network.target
Before=network.target network.service

[Service]
Type=dbus
BusName=org.freedesktop.NetworkManager
ExecStart=/usr/sbin/NetworkManager --no-daemon
# NM doesn't want systemd to kill its children for it
KillMode=process

[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.NetworkManager.service
Also=NetworkManager-dispatcher.service

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

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

Ну не стандартный, а распространённый. Устраивает такой термин?

[yars]

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

Пруф удобства, или не было.

То ли дело юнит:

И как это отлаживать? В чем именно сложности и неочевидности? Не вижу ни того, ни другого. Вот uselessd - ближе к тому, что реально могло бы заменить init, но опять же, не вижу зачем, когда последний оттестирован вдоль и поперек и вероятность сюрпризов от него близка к нулевой, в отличие от.

Устраивает такой термин?

Разница между распространенным и стандартным слишком велика, так что нет, не устраивает.

[serzh-z]

Использовать неподдерживаемый софт - это, как правило, не слишком хорошая идея.

Вот оно, зришь в корень! Кто-то, разработчики и мейнтенеры дистрибутива, решили, что для них удобнее поддерживать дистрибутив с systemd. Не понимаю, о чём можно так долго спорить в новостях про systemd.

[Yaros]

Всё сложно и неочевидно.

То есть Вы не знаете баша, вероятность 99%. В противном случае, инит-скрипт очевиден.

То ли дело юнит:

Код: Выделить всё

[Unit]
Description=Network Manager
Wants=network.target
Before=network.target network.service

[Service]
Type=dbus
BusName=org.freedesktop.NetworkManager
ExecStart=/usr/sbin/NetworkManager --no-daemon
# NM doesn't want systemd to kill its children for it
KillMode=process

[Install]
WantedBy=multi-user.target
Alias=dbus-org.freedesktop.NetworkManager.service
Also=NetworkManager-dispatcher.service

Ничего более понятного тут не вижу. Оно другое, но более понятным не могу назвать.

[Bizdelnick]

Всё сложно и неочевидно.

OMG, да что там неочевидного-то? case что ли?

[yoshakar]

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

На самом деле, для разработчиков и майтайнеров проще всего бросить дистрибутив и не поддерживать его совсем. И если сейчас они так легко перешли на systemd, значит завтра они так же легко перейдут на "нет дистрибутива".

[eddy]

Ха, да ты просто неосилятор?

Давай, ты сейчас выучишь язык Brainfuck и напишешь на нем пару модулей ядра линукс?
Что, не осилил? Фу, неосилятор!!!

Идеология Unix давно себя изжила.

И что фанатик-вантузятник делает на линуксофоруме?
Вон отсюда!!!

[yars]

Вон отсюда!!!

Категорично, но, увы, иначе сказать сложно
Нет, я, конечно, понимаю, что нынешний линукс уже далеко не тот, что был десять лет назад, но, ИМХО, делать систему менее прозрачной и менее конфигурабельной -- значит убивать ее на корню. Не серверами едиными нынче жив линукс, нет и не может быть универсального инструмента на все случаи жизни. Даже разводные ключи и те порой хуже обычных гаечных ключей. Последние же бывают накидные, торцовые, специальные... А вы хотите systemd на embedded системах запускать.

[serzh-z]

На самом деле, для разработчиков и майтайнеров проще всего бросить дистрибутив

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