Комментарии 11
Как раз искал что-то похожее! Спасибо что заботитесь о будущих админах.
Автор помоему недостаточно подкован в RH системах. Привыкли видать к Debian-based.
в Вашем, конкретном случае, для задания MTU, есть такой параметр в файлах ifcfg-ethX.
А поднимается он строками (158-160) из /etc/sysconfig/network-scripts/ifup-eth:
if [ -n "${MTU}" ]; then
ip link set dev ${DEVICE} mtu ${MTU}
fi
Думается мне, что не надо ругать дистрибютив не разобравщись — нехорошая привычка. А для того чтоб действительно разобратся, достаточно внимательно почитать скрипты в папке /etc/sysconfig/network-scripts/
Вообще в RH (imho) организация настройки сети, как то route, rule, ipsec etc… намного удобнее и понятнее, поясняю — IMHO.
в Вашем, конкретном случае, для задания MTU, есть такой параметр в файлах ifcfg-ethX.
А поднимается он строками (158-160) из /etc/sysconfig/network-scripts/ifup-eth:
if [ -n "${MTU}" ]; then
ip link set dev ${DEVICE} mtu ${MTU}
fi
Думается мне, что не надо ругать дистрибютив не разобравщись — нехорошая привычка. А для того чтоб действительно разобратся, достаточно внимательно почитать скрипты в папке /etc/sysconfig/network-scripts/
Вообще в RH (imho) организация настройки сети, как то route, rule, ipsec etc… намного удобнее и понятнее, поясняю — IMHO.
Отвечаю по пунктам)
1. Да, к debian-подобным привык, есть такое. Сейчас вот с rh-подобными разбираюсь.
2. пример с mtu взят из Red Hat Knowledgebase DOC-8695 (!)Но умоляю Вас сильно не пинать Red Hat, они все же многое сделали для Linux и Open Source сообщества вцелом) Да и статья в kbase писалась в далеком декабре 2004го, может за 5 лет, как раз и добавили параметр для задания MTU
3. Ни в коем случае не собираюсь ругать тот или иной дистриб. Мотивы, по которым писалась моя заметка — в первых двух ее абзацах.
Если вдаваться в подробности, то изначальная цель была другой — заставить весь трафик данного хоста (даже локальный — т.е. в пределах его подсети) ходить через gateway. Сам знаю, что задача несколько странная. Так как перелопатив весь каталог network-scripts я не нашел возможности удаления/изменения маршрута для родной подсети, создаваемого по-умолчанию — пришлось работать через запускаемый скрипт.
В случае, если вы ткнете меня в способ решения данной задачи не выходя за пределы идеологии RH — буду очень благодарен.
1. Да, к debian-подобным привык, есть такое. Сейчас вот с rh-подобными разбираюсь.
2. пример с mtu взят из Red Hat Knowledgebase DOC-8695 (!)
3. Ни в коем случае не собираюсь ругать тот или иной дистриб. Мотивы, по которым писалась моя заметка — в первых двух ее абзацах.
Если вдаваться в подробности, то изначальная цель была другой — заставить весь трафик данного хоста (даже локальный — т.е. в пределах его подсети) ходить через gateway. Сам знаю, что задача несколько странная. Так как перелопатив весь каталог network-scripts я не нашел возможности удаления/изменения маршрута для родной подсети, создаваемого по-умолчанию — пришлось работать через запускаемый скрипт.
В случае, если вы ткнете меня в способ решения данной задачи не выходя за пределы идеологии RH — буду очень благодарен.
С удовольствие ткну :)
вот примеры:
ifcfg-eth0:
DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.0.255
HWADDR=40:61:86:2b:86:fd
IPADDR=192.168.0.15
NETMASK=255.255.255.255
SCOPE=«peer 192.168.0.1»
route-eth0:
ADDRESS0=0.0.0.0
NETMASK0=0.0.0.0
GATEWAY0=192.168.0.1
И так, весь трафик, весь-весь, будет ходить через 192.168.0.1
В свое время, я конкретно специализировался на RH дистрах. Я не хвалюсь, просто:
1. Это мои Любимые дистры
2. Я перелопатил кучу доков по ним, за Много лет, еще с RH 6.0
3. Я переживаю и стараюсь помочь, чтоб не дать разочароваться в них.
:)
вот примеры:
ifcfg-eth0:
DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.0.255
HWADDR=40:61:86:2b:86:fd
IPADDR=192.168.0.15
NETMASK=255.255.255.255
SCOPE=«peer 192.168.0.1»
route-eth0:
ADDRESS0=0.0.0.0
NETMASK0=0.0.0.0
GATEWAY0=192.168.0.1
И так, весь трафик, весь-весь, будет ходить через 192.168.0.1
В свое время, я конкретно специализировался на RH дистрах. Я не хвалюсь, просто:
1. Это мои Любимые дистры
2. Я перелопатил кучу доков по ним, за Много лет, еще с RH 6.0
3. Я переживаю и стараюсь помочь, чтоб не дать разочароваться в них.
:)
забыл в первый пунк:
NETWORK=192.168.0.0
NETWORK=192.168.0.0
На практике не проверял — сделаю это в понедельник (не люблю в ночь на субботу ковырять настройки интерфейса у работающего сервера… чревато....)))) Пока просто скрипты почитал
SCOPE=«peer 192.168.0.1» — это хак)))
И исключительно по принципу «грязный хак против долгого гемора»
Причем откровенный… Ну где же тут идеология RH?.. Ведь стоит им в скрипте организовать проверку SCOPE по возможным значениям (хотя бы на том уровне, на котором это организовано для параметров маршрутизации) — и работа сети после апдейта нарушится.
SCOPE=«peer 192.168.0.1» — это хак)))
И исключительно по принципу «грязный хак против долгого гемора»
Причем откровенный… Ну где же тут идеология RH?.. Ведь стоит им в скрипте организовать проверку SCOPE по возможным значениям (хотя бы на том уровне, на котором это организовано для параметров маршрутизации) — и работа сети после апдейта нарушится.
По Вашему разумению, вообще все команды ip xxx — это хак… смешно.
Ну еще бы проверяли бы.
Идеалогия в том, чтоб настройки хранились там где им положено, что и было Вам наглядно продемонстрировано.
И заместо «благодарности», обещанной в предыдущем ответе, Вы прикрываете свою некомпетентность, откровенным хамством.
по Вашему, если я в том же файле напишу:
ETHTOOL_OPTS=«speed 10 duplex half autoneg off»
то это тоже будет хак?
если это хак — тогда использование отдельно команды после поднятия интерфейса — это извращение.
Вы красиво пытались прикрыть отсутствие знаний, заботой о будущих админах — ну и где ж здесь расхождение с желаемым?
Ну еще бы проверяли бы.
Идеалогия в том, чтоб настройки хранились там где им положено, что и было Вам наглядно продемонстрировано.
И заместо «благодарности», обещанной в предыдущем ответе, Вы прикрываете свою некомпетентность, откровенным хамством.
по Вашему, если я в том же файле напишу:
ETHTOOL_OPTS=«speed 10 duplex half autoneg off»
то это тоже будет хак?
если это хак — тогда использование отдельно команды после поднятия интерфейса — это извращение.
Вы красиво пытались прикрыть отсутствие знаний, заботой о будущих админах — ну и где ж здесь расхождение с желаемым?
Команды ip — очень удобное средство.
«чтоб настройки хранились там где им положено» — да я только за!
вот только использование отсутствия проверки параметра SCOPE для того, чтобы вставить другой параметр (peer) со значением этого другого параметра — считаю неразумным. Как только в скрипте появится данная проверка (параметра scope, благо он задокументирован) — это сразу проявится. Способ же предложенный мной не использует никаких назадокументированных возможностей скрипта. Более того, опирается на статью из RH KB. При этом все настройки продолжают хранится в /etc/sysconfig/network-scripts/
Именно там, где их и будут искать.
А по поводу примера использвоания ETHTOOL_OPTS — ничего против не имею. В данном случае, имя параметра и его назначение вполне соотносится со значением ему присвоенным.
Вас послушать, так за появление в федоре каталогов ifup.d и ifdown.d вообще надо на костре сжечь. Мой способ просто реализует их функционал. Они ведь тоже служат для выполнения отдельных команд после поднятия интерфейса.
И я действительно считаю, что полная команда, прописанная в файле лежащем, к примеру, в ifup.d гораздо удобнее, чем подстановака одного параметра вместо другого, опирающаяся на отсуствии проверки этого другого параметра скриптом. Как-то очевиднее это, что ли…
Отсуствия у себя знаний в определенных областях я не стесняюсь. Вот только ваша категоричная вера в собственную исключительную правоту вызывает у меня, как минимум. удивление. Я готов с радостью увеличить уровень своей компетентности в данном вопросе. Но ваши доводы не кажутся мне достаточными, чтобы назвать ваш способ решения задачи единственно-верным, а мой — предать огню)) Оценивать же чью-то компетентность только на основании того, разделяет ли человек мое мнение в определенном (достаточно узком) вопросе или нет — я бы не стал. Мне кажется, что тут вы перегибаете палку.
По поводу же хамства — ни в коем случае не собирался Вас задеть.
«чтоб настройки хранились там где им положено» — да я только за!
вот только использование отсутствия проверки параметра SCOPE для того, чтобы вставить другой параметр (peer) со значением этого другого параметра — считаю неразумным. Как только в скрипте появится данная проверка (параметра scope, благо он задокументирован) — это сразу проявится. Способ же предложенный мной не использует никаких назадокументированных возможностей скрипта. Более того, опирается на статью из RH KB. При этом все настройки продолжают хранится в /etc/sysconfig/network-scripts/
Именно там, где их и будут искать.
А по поводу примера использвоания ETHTOOL_OPTS — ничего против не имею. В данном случае, имя параметра и его назначение вполне соотносится со значением ему присвоенным.
Вас послушать, так за появление в федоре каталогов ifup.d и ifdown.d вообще надо на костре сжечь. Мой способ просто реализует их функционал. Они ведь тоже служат для выполнения отдельных команд после поднятия интерфейса.
И я действительно считаю, что полная команда, прописанная в файле лежащем, к примеру, в ifup.d гораздо удобнее, чем подстановака одного параметра вместо другого, опирающаяся на отсуствии проверки этого другого параметра скриптом. Как-то очевиднее это, что ли…
Отсуствия у себя знаний в определенных областях я не стесняюсь. Вот только ваша категоричная вера в собственную исключительную правоту вызывает у меня, как минимум. удивление. Я готов с радостью увеличить уровень своей компетентности в данном вопросе. Но ваши доводы не кажутся мне достаточными, чтобы назвать ваш способ решения задачи единственно-верным, а мой — предать огню)) Оценивать же чью-то компетентность только на основании того, разделяет ли человек мое мнение в определенном (достаточно узком) вопросе или нет — я бы не стал. Мне кажется, что тут вы перегибаете палку.
По поводу же хамства — ни в коем случае не собирался Вас задеть.
Поясните пожалуйста тогда, в чем разница между поднятие scope через команду ip и запись на поднятие в файле настройки самого интерфейса?
То есть, получаеться, что записать этот параметр в файле настройки интерфейса — это хак, а отдельной командой, в отдельном файле — это true way. Кстати и в debian-based, есть возможность давать команды post-up и т.д. непосредственно в самом файле /etc/network/interfaces
Не хочу перегибать, если чем-то задел, прошу прощения, но в корне не согласен.
Да и распалятся по поводу, не вижу необходимости, Ваша задача решена. И поверьте мне, если в будущем админ будет разбираться с Вашими настройками, то в первую очередь будет смотреть в фал настроек интерфейса, а не в папки if-up.d и т.д., и увидев данную запись, поймет смысл не просматривая дополнительные файлы.
Тем более что у меня нет аккаунта на Хабре(очень жаль), это аккаунт моего товарища, он любезно предоставил возможность написать в этот топик, когда увидел моё возмущение по subj.
То есть, получаеться, что записать этот параметр в файле настройки интерфейса — это хак, а отдельной командой, в отдельном файле — это true way. Кстати и в debian-based, есть возможность давать команды post-up и т.д. непосредственно в самом файле /etc/network/interfaces
Не хочу перегибать, если чем-то задел, прошу прощения, но в корне не согласен.
Да и распалятся по поводу, не вижу необходимости, Ваша задача решена. И поверьте мне, если в будущем админ будет разбираться с Вашими настройками, то в первую очередь будет смотреть в фал настроек интерфейса, а не в папки if-up.d и т.д., и увидев данную запись, поймет смысл не просматривая дополнительные файлы.
Тем более что у меня нет аккаунта на Хабре(очень жаль), это аккаунт моего товарища, он любезно предоставил возможность написать в этот топик, когда увидел моё возмущение по subj.
Разница в использовании недокументированных возможностей. Речь вот о чем:
Присутствуй в скриптах обработка параметра PEER в файлах ifcfg-* я бы с радостью его использовал. Ну, например, так:
fcfg-eth0:
DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.0.255
HWADDR=40:61:86:2b:86:fd
IPADDR=192.168.0.15
NETMASK=255.255.255.255
PEER=192.168.0.1
В этом случае шаманство с if-up.d было бы действительно излишним, и я был бы в этом случае почти полностью уверен, что после yum update сохраниться обратная совместимость и новая версия ifup-eth корректно обработает данные настройки.
В вашем же случае, есть хоть небольшая, но вероятность того, что после апдейта параметр
SCOPE=«peer 192.168.0.1»
новой версией ifup-eth так, как мы хотим, обработан не будет. Потому что параметр scope команды ip не может иметь значение «peer 192.168.0.1». И параметр peer команды ip не является подпараметром параметра scope (Но они оба являются подпараметрами параметра IFADDR).
IFADDR := ПРЕФИКС | ADDR peer ПРЕФИКС [ broadcast АДРЕС ] [ anycast АДРЕС ] [ label СТРОКА ] [ scope SCOPE-ID ]
SCOPE-ID := [ host | link | global | ЧИСЛО ]
Именно поэтому, мне кажется, что используя вариант с if-up.d (или его аналогом) мы получим более стабильную систему. Ну а админу — да, придется потратить дополнительно пару секунд на то, чтобы просмотреть еще один файл.
Надеюсь, что у меня получилось пояснить свою точку зрения.
Присутствуй в скриптах обработка параметра PEER в файлах ifcfg-* я бы с радостью его использовал. Ну, например, так:
fcfg-eth0:
DEVICE=eth0
BOOTPROTO=static
BROADCAST=192.168.0.255
HWADDR=40:61:86:2b:86:fd
IPADDR=192.168.0.15
NETMASK=255.255.255.255
PEER=192.168.0.1
В этом случае шаманство с if-up.d было бы действительно излишним, и я был бы в этом случае почти полностью уверен, что после yum update сохраниться обратная совместимость и новая версия ifup-eth корректно обработает данные настройки.
В вашем же случае, есть хоть небольшая, но вероятность того, что после апдейта параметр
SCOPE=«peer 192.168.0.1»
новой версией ifup-eth так, как мы хотим, обработан не будет. Потому что параметр scope команды ip не может иметь значение «peer 192.168.0.1». И параметр peer команды ip не является подпараметром параметра scope (Но они оба являются подпараметрами параметра IFADDR).
IFADDR := ПРЕФИКС | ADDR peer ПРЕФИКС [ broadcast АДРЕС ] [ anycast АДРЕС ] [ label СТРОКА ] [ scope SCOPE-ID ]
SCOPE-ID := [ host | link | global | ЧИСЛО ]
Именно поэтому, мне кажется, что используя вариант с if-up.d (или его аналогом) мы получим более стабильную систему. Ну а админу — да, придется потратить дополнительно пару секунд на то, чтобы просмотреть еще один файл.
Надеюсь, что у меня получилось пояснить свою точку зрения.
Неясно, кто и как должен вызывать
ifup-local <interface_name>
Ссылка на сайт редхака недоступна, ибо требует подписки.
ifup-local <interface_name>
Ссылка на сайт редхака недоступна, ибо требует подписки.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
interface post-up в CentOS