181

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

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

182

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

183 (12.12.2013 15:02:23 отредактировано lone_wolf)

Vascom пишет:
redix пишет:

Vascom, а что, Альт уже в нормальных ходит?  ag

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

lone_wolf, вернуть eth0 - дело двух секунд. Если это проблема, то стоит начать изучение с чего-то попроще.

ну как 1 из вариантов через ip2route переименовать а потом при перезагрузке переименовывать через crontab
так что я не настолько глупый как может показатся  ae

Vascom пишет:

вернуть eth0 - дело двух секунд

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

Спросить - стыд минуты, не узнать - стыд всей жизни

184

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

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

In Tux We Trust     Centos 6.5
Самурай без меча подобен самураю с мечом, но только без меча, однако как-будто с мечом, которого у него нет, но и без него он как с ним...

185

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

186 (12.12.2013 16:28:26 отредактировано xxblx)

Vascom пишет:

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

Vascom пишет:

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

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

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

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

Fedora GNOME3

187

Vascom пишет:

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

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

Спросить - стыд минуты, не узнать - стыд всей жизни

188

xxblx пишет:
Vascom пишет:

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

Vascom пишет:

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

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

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

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

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

189

xxblx пишет:

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

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

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

190

Vascom пишет:

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

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

Vascom пишет:

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

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

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

191 (18.12.2013 02:29:15 отредактировано Termo)

xxblx пишет:

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

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

ПатреГ не любит Gnome...

192 (18.12.2013 04:17:16 отредактировано xxblx)

dyasny пишет:

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

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

dyasny пишет:

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

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

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

Fedora GNOME3

193

dyasny пишет:
xxblx пишет:

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

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

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

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

Спросить - стыд минуты, не узнать - стыд всей жизни

194

Vascom пишет:

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

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

195

lone_wolf пишет:

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

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

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

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

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

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

196

dyasny пишет:

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

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

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

197

yars пишет:

Ага, слышал звон, да не знал, где он.

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

yars пишет:

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

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

198

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

199

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

ls -1 /lib/udev/rules.d/
75-persistent-net-generator.rules
+ открыть спойлер
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 одинаков, правила только различаются...

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

200

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

201

dyasny пишет:
+ открыть спойлер
lone_wolf пишет:

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

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

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

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

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

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

понял спасибо, да соглашусь под такие нагрузки systemd удобней.
Ну а нам обывателям придется 1 раз заморочится чтобы переименовать интерфейс как нам понравится  ab
Кстати кто подскажет как это проше сделать ?

Спросить - стыд минуты, не узнать - стыд всей жизни

202

Проще не переименовывать.
Или, наверное, можно алиас любой создать.

203 (18.12.2013 11:52:01 отредактировано yars)

lone_wolf пишет:

Кстати кто подскажет как это проше сделать ?

Пойдемте в отдельную тему ab

lone_wolf пишет:

Ну а нам обывателям придется 1 раз заморочится чтобы переименовать интерфейс как нам понравится

...и пересобирать systemd, когда требуется поддержка отдельного /usr bx

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

204

yars пишет:

Пойдемте в отдельную тему

идем  bs  (кто создает ?)

Спросить - стыд минуты, не узнать - стыд всей жизни

205

Присоединился к рядам поклонников systemd! Он крут!

206

lone_wolf пишет:
yars пишет:

Пойдемте в отдельную тему

идем  bs  (кто создает ?)

Ну, давайте вы =)

Истинный hotplug - это обычная электрическая розетка: воткнул - работает, и никаких драйверов.
Arch Linux/Xfce/Xiaomi Mi Notebook Pro 15.6 | Slackware64-current/Xfce/Lenovo G580

207

dyasny - может поменять админа ?

Я конечно далек от мысли...(с)

208

smaharbA пишет:

dyasny - может поменять админа ?

в смысле?

209

форум разделился на два лагеря.
одним консерватизм подавай, другим систэмДЭ.

когда уже война начнется?  am

"Фирма Майкрософт не собирается поддерживать протокол TCP/IP в своих OS" 1993 (c) Билл Гейтс
"Мы изобрели новый протокол передачи данных, мы назвали его TCP/IP" 1995 (c) Билл Гейтс

210

Войны не будет. Прогресс не остановить.