Systemd - лучшая система инициализации!!!!11

12.12.2013 14:48 #354594

Наоборот, ALT-овцы молодцы, правильно сделали, как и Gentoo-шники.

12.12.2013 14:54 #354599

Ну флаг им в руки. Молодцы, ни кто не спорит.
Я лишь сказал, что другие не сделают так. Но Альт не захватит мир.

12.12.2013 14:58 · отредактировано #354600

Vascom написал:
[quote=redix]Vascom, а что, Альт уже в нормальных ходит? :D

В том-то и дело что нет. Потому я так и написал, что нормальные не будут делать как Альт.

lone_wolf, вернуть eth0 - дело двух секунд. Если это проблема, то стоит начать изучение с чего-то попроще.[/quote]
ну как 1 из вариантов через ip2route переименовать а потом при перезагрузке переименовывать через crontab
так что я не настолько глупый как может показатся :P

"Vascom" написал:
вернуть eth0 - дело двух секунд

ну раз так если не затруднит то расскажите пожалуйста как это сделать за 2 секунды буду очень признателен :[ а может не я 1 *DRINK*

12.12.2013 15:42 #354611

Наверное, многие помнят в книге Д. Свифта «Путешествия Лемюэля Гулливера» ситуацию с войной в Лилипутии из-за разногласий по поводу того, с острой или с тупой стороны разбивать вареные яйца. Изначально было принято разбивать яйца с тупого конца. Но однажды наследник трона порезал себе палец, разбивая яйцо. И тогда император издал указ, что отныне яйца можно разбивать только с острого конца, тем же, кто ослушается, грозила смертная казнь. И тогда все недовольные этим указом подняли восстание, которое в итоге переросло в религиозную войну между государствами Лилипутией и Блефуску.

А..... Ничего не напоминает?

12.12.2013 15:44 #354612

lone_wolf, лень :)
Тем более ты уже нашёл выход из ситуации. Значит всё можем, если захотим.

12.12.2013 16:00 · отредактировано #354614

"Vascom" написал:
Нормальные дистрибутивы так делать не будут.

"Vascom" написал:
Предоставлять пользователю выбор между хорошей современной системой инициализации и sysV.

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

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

p.s. это не камень в огород systemd, а размышления на тему вечного спора "ненужно и нужно".

12.12.2013 16:17 #354617

Vascom написал:
lone_wolf, лень :)
Тем более ты уже нашёл выход из ситуации. Значит всё можем, если захотим.

эх жаль конечно... но хозяин барин *PARDON*

17.12.2013 10:22 #355443

xxblx написал:
[quote="Vascom"]Нормальные дистрибутивы так делать не будут.

"Vascom" написал:
Предоставлять пользователю выбор между хорошей современной системой инициализации и sysV.

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

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

p.s. это не камень в огород systemd, а размышления на тему вечного спора "ненужно и нужно".[/quote]
Все дистрибутивы, пытающиеся предоставить пользователю выбор из всего что есть, делают это плохо. Сил у них не хватает.
К тому же одно дело предоставлять выбор из равноценных (или почти) компонентов, например Гном, КДЕ, XFCE и такими разными вещами как sysV и systemd. Надо понимать разницу.

18.12.2013 01:24 #355625

"xxblx" написал:
Пока что никто мне не смог объяснить что же за "катастрофические ситуации" привели к этим переменам.

а если объяснять, слушать будете? Моя основная проблема с init и ethX в том что начинает твориться когда в сервера больше 20 интерфейсов.
а когда их больше сотни, начинается кромешный ад, причем при каждой перезагрузке он становится все хуже. А если интерфейсы динамически цепляются и отцепляются, то RHEL5 и все что работает по тому же принципу вообще уходят в полную несознанку, а свежая федора пашет как часы.

хотите сказать что столько интерфейсов не бывает? тогда я вас удивлю.

18.12.2013 02:20 #355634

"Vascom" написал:
Все дистрибутивы, пытающиеся предоставить пользователю выбор из всего что есть, делают это плохо. Сил у них не хватает.

А свечку держали?

"Vascom" написал:
тому же одно дело предоставлять выбор из равноценных (или почти) компонентов, например Гном, КДЕ, XFCE и такими разными вещами как sysV и systemd. Надо понимать разницу.

Конечно, надо понимать разницу. :SARCASM

18.12.2013 02:28 · отредактировано #355637

xxblx написал:
Будь systemd хоть и того современней, называть ненормальными все дистрибутивы, пытающиеся предоставить пользователю выбор

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

18.12.2013 04:14 · отредактировано #355643

"dyasny" написал:
а если объяснять, слушать будете?

С удовольствием.

"dyasny" написал:
Моя основная проблема с init и ethX в том что начинает твориться когда в сервера больше 20 интерфейсов.
а когда их больше сотни, начинается кромешный ад, причем при каждой перезагрузке он становится все хуже. А если интерфейсы динамически цепляются и отцепляются, то RHEL5 и все что работает по тому же принципу вообще уходят в полную несознанку, а свежая федора пашет как часы.

Обозначена конкретная проблема возникавшая со старыми наименованиями и решаемая новыми.
Спасибо за конкретный вменяемый ответ.

А то все приводят два аргумента вроде "red hat" и "современная". Но если спросить, в чем плюсы этой "современности", по факту, какие возникшие ранее проблемы она решает, не говорят.

18.12.2013 04:58 #355645

dyasny написал:
[quote="xxblx"]Пока что никто мне не смог объяснить что же за "катастрофические ситуации" привели к этим переменам.

а если объяснять, слушать будете? Моя основная проблема с init и ethX в том что начинает твориться когда в сервера больше 20 интерфейсов.
а когда их больше сотни, начинается кромешный ад, причем при каждой перезагрузке он становится все хуже. А если интерфейсы динамически цепляются и отцепляются, то RHEL5 и все что работает по тому же принципу вообще уходят в полную несознанку, а свежая федора пашет как часы.

хотите сказать что столько интерфейсов не бывает? тогда я вас удивлю.[/quote]
спасибо за четкое пояснение и пример, но у меня возникает только 1 вопрос а как же привязка к маку ? *SCRATCH*

18.12.2013 06:18 #355649

Vascom написал:
Ну флаг им в руки. Молодцы, ни кто не спорит.
Я лишь сказал, что другие не сделают так. Но Альт не захватит мир.

Точно не захватит. После их безбожной кастрации ACC и вообще-то странным обращением с systemctl. Поставила ради прикола Centauros 7 platform, так и снесла - тоска и глюки. Возникает нехорошее ощущение, что Alt двинулся тропою ROSA...

18.12.2013 09:35 #355677

"lone_wolf" написал:
спасибо за четкое пояснение и пример, но у меня возникает только 1 вопрос а как же привязка к маку ?

ее недостаточно. проблема в том, что обычно в серверах, пихают дикую мешанину из карточек - broadcom на мамке, разные интели в паре медленных слотов, 10g интели, мелланоксы, челси, циски... плюс версии, прошивки, варианты... все эти kmod-ы грузятся медленно, и на тот момент когда init доходит до загрузки сети, модули еще не загружены. Это значит что после загрузки сервера надо как минимум рестартовать network, и обычно еще и udevadm trigger

А если у меня UCS, с динамически цепляемыми интерфейсами, которые меняют маки в зависимости от задач, то init с udev-ом начинают слегка офигевать.

Теперь представяем вполне типичную для таких масштабов систему, где несколько сотен блейдов с такими вот динамичными интерфейсами, постоянно поднимают из темплейта ВМ, цепляют к ней нужные интерфейсы через VMFEX, по несколько десятков на каждую, закачивают данные, ВМ их обрабатывает, возвращает, и ее убивают чтоб поднять другую. Все это происходит очень быстро, за сутки в нашем ДЦ например "оборот" - 15-20 тысяц виртуалок. Ждать пока отработает udev и network service никто не может, скорость загрузки очень важна, потому что все это - финансовые данные для практически всех банков континента.

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

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

18.12.2013 09:49 #355681

"dyasny" написал:
А если у меня UCS, с динамически цепляемыми интерфейсами, которые меняют маки в зависимости от задач, то init с udev-ом начинают слегка офигевать.

Ага, слышал звон, да не знал, где он. По-вашему, включенный в systemd код udev не офигевает, да? Офигевает, ровно так же. Зато удобочитаемые имена теперь надо ручками возвращать. Прогресс, ага.

18.12.2013 09:54 #355684

"yars" написал:
Ага, слышал звон, да не знал, где он.

дада, конечно, куда уж нам, сирым и убогим...

"yars" написал:
По-вашему, включенный в systemd код udev не офигевает, да? Офигевает, ровно так же. Зато удобочитаемые имена теперь надо ручками возвращать. Прогресс, ага.

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

18.12.2013 09:58 #355687

yars, это для человека кажутся такие имена сложнее. Но для автоматики - это намного проще, тем более, что имя не меняется от загрузки к загрузке, как происходит с обычными eth0.
А полный автоматизм - разве не наша цель? Разгрузить человека от рутинной работы.
Вот у меня на рабочем компе (не сервер) две сетевухи, подключена одна. И мне было неудобно, что имя у неё рандомно было то eth0, то eth1. А сейчас всё чётко и понятно, однозначно.

18.12.2013 10:06 #355688

Это если и было, то меня не коснулось. Да и вообще, это была проблема криво написанных правил udev. Вот этого как минимум.

text

ls -1 /lib/udev/rules.d/
75-persistent-net-generator.rules

Показать

text

cat /lib/udev/rules.d/75-persistent-net-generator.rules 
# do not edit this file, it will be overwritten on update
# these rules generate rules for persistent network device naming
#
# variables used to communicate:
#   MATCHADDR             MAC address used for the match
#   MATCHID               bus_id used for the match
#   MATCHDRV              driver name used for the match
#   MATCHIFTYPE           interface type match
#   COMMENT               comment to add to the generated rule
#   INTERFACE_NAME        requested name supplied by external tool
#   INTERFACE_NEW         new interface name returned by rule writer
ACTION!="add", GOTO="persistent_net_generator_end"
SUBSYSTEM!="net", GOTO="persistent_net_generator_end"
# ignore the interface if a name has already been set
NAME=="?*", GOTO="persistent_net_generator_end"
# device name whitelist
KERNEL!="eth*|ath*|wlan*[0-9]|msh*|ra*|sta*|ctc*|lcs*|hsi*", GOTO="persistent_net_generator_end"
# ignore Xen virtual interfaces
SUBSYSTEMS=="xen", GOTO="persistent_net_generator_end"
# read MAC address
ENV{MATCHADDR}="$attr{address}"
# match interface type
ENV{MATCHIFTYPE}="$attr{type}"
# ignore KVM virtual interfaces
ENV{MATCHADDR}=="52:54:00:*", GOTO="persistent_net_generator_end"
# ignore VMWare virtual interfaces
ENV{MATCHADDR}=="00:0c:29:*|00:50:56:*", GOTO="persistent_net_generator_end"
# ignore Hyper-V virtual interfaces
ENV{MATCHADDR}=="00:15:5d:*", GOTO="persistent_net_generator_end"
# These vendors are known to violate the local MAC address assignment scheme
# Interlan, DEC (UNIBUS or QBUS), Apollo, Cisco, Racal-Datacom
ENV{MATCHADDR}=="02:07:01:*", GOTO="globally_administered_whitelist"
# 3Com
ENV{MATCHADDR}=="02:60:60:*", GOTO="globally_administered_whitelist"
# 3Com IBM PC; Imagen; Valid; Cisco; Apple
ENV{MATCHADDR}=="02:60:8c:*", GOTO="globally_administered_whitelist"
# Intel
ENV{MATCHADDR}=="02:a0:c9:*", GOTO="globally_administered_whitelist"
# Olivetti
ENV{MATCHADDR}=="02:aa:3c:*", GOTO="globally_administered_whitelist"
# CMC Masscomp; Silicon Graphics; Prime EXL
ENV{MATCHADDR}=="02:cf:1f:*", GOTO="globally_administered_whitelist"
# Prominet Corporation Gigabit Ethernet Switch
ENV{MATCHADDR}=="02:e0:3b:*", GOTO="globally_administered_whitelist"
# BTI (Bus-Tech, Inc.) IBM Mainframes
ENV{MATCHADDR}=="02:e6:d3:*", GOTO="globally_administered_whitelist"
# Realtek
ENV{MATCHADDR}=="52:54:00:*", GOTO="globally_administered_whitelist"
# Novell 2000
ENV{MATCHADDR}=="52:54:4c:*", GOTO="globally_administered_whitelist"
# Realtec
ENV{MATCHADDR}=="52:54:ab:*", GOTO="globally_administered_whitelist"
# Kingston Technologies
ENV{MATCHADDR}=="e2:0c:0f:*", GOTO="globally_administered_whitelist"
# Xensource
ENV{MATCHADDR}=="00:16:3e:*", GOTO="globally_administered_whitelist"
# match interface dev_id
ATTR{dev_id}=="?*", ENV{MATCHDEVID}="$attr{dev_id}"
# do not use "locally administered" MAC address
ENV{MATCHADDR}=="?[2367abef]:*", ENV{MATCHADDR}=""
# do not use empty address
ENV{MATCHADDR}=="00:00:00:00:00:00", ENV{MATCHADDR}=""
LABEL="globally_administered_whitelist"
# build comment line for generated rule:
SUBSYSTEMS=="pci", ENV{COMMENT}="PCI device $attr{vendor}:$attr{device} ($driver)"
SUBSYSTEMS=="usb", ATTRS{idVendor}=="?*", ENV{COMMENT}="USB device 0x$attr{idVendor}:0x$attr{idProduct} ($driver)"
SUBSYSTEMS=="pcmcia", ENV{COMMENT}="PCMCIA device $attr{card_id}:$attr{manf_id} ($driver)"
SUBSYSTEMS=="ieee1394", ENV{COMMENT}="Firewire device $attr{host_id})"
# ibmveth likes to use "locally administered" MAC addresses
DRIVERS=="ibmveth", ENV{MATCHADDR}="$attr{address}", ENV{COMMENT}="ibmveth ($id)"
# S/390 uses id matches only, do not use MAC address match
SUBSYSTEMS=="ccwgroup", ENV{COMMENT}="S/390 $driver device at $id", ENV{MATCHID}="$id", ENV{MATCHDRV}="$driver", ENV{MATCHADDR}=""
# see if we got enough data to create a rule
ENV{MATCHADDR}=="", ENV{MATCHID}=="", ENV{INTERFACE_NAME}=="", GOTO="persistent_net_generator_end"
# default comment
ENV{COMMENT}=="", ENV{COMMENT}="net device ($attr{driver})"
# write rule
DRIVERS=="?*", IMPORT{program}="write_net_rules"
# rename interface if needed
ENV{INTERFACE_NEW}=="?*", NAME="$env{INTERFACE_NEW}"
LABEL="persistent_net_generator_end"

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

18.12.2013 10:07 #355689

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