interface post-up в CentOS

    Полдня промучался на тему того, как заствить CentOS выполнить некий скрипт после поднятия интерфейса. После первого неудачного гугления появления первых трудностей заставил себя, однако, не действовать по принципу «Лучше грязный хак, чем долгий гемор»: удержался от втыкания костыля в /etc/sysconfig/network-scripts/ifup-eth
    Дабы и коллег удержать от подобного пишу сюда результат своих изысканий.

    1. В чистом виде аналог дебиановского post-up в CentOS отсутствуют. Не надо даже пытаться его искать.
    2. Все, что есть, это некая фича описанная в Red Hat Knowledgebase DOC-8695

    Если вкрадце: предлагается создать некий /sbin/ifup-local. В который затем поместить свой полезный (или бесполезный) код. Например:
    #Set the MTU for eth0 only using the ip command
    if [ "$1" = "eth0" ]; then
    exec /sbin/ip link set dev ${1} mtu 1200
    fi

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

    3. Описанных в статье Настройка сети в Linux через конфиг-файлы, ч.1 каталогов ifup.d и ifdown.d просто не нашлось. О них нет даже упоминания /etc/sysconfig/network-scripts/*

    Исходя из 1,2,3 единственным правильным решением считаю размешение в /sbin/ скрипта ifup-local следующего содержания:
    #!/bin/bash

    POSTUPNAME="/etc/sysconfig/network-scripts/post-up-$1"
    if [ -x $POSTUPNAME ]; then
    exec $POSTUPNAME
    fi


    Соответственно, в /etc/sysconfig/network-scripts/ после этого помещаются файлы post-up-eth0 и т.д. с полезным кодом внутри.

    И напоследок, аналогично дело обстоит и с запуском кода перед поднятием интерфейса (/sbin/ifup-pre-local), перед его отключением (/sbin/ifdown-pre-local) и после его отключения (/sbin/ifdown-local).

    PS Работа велась на CentOS release 5.4 (Final). Ни одного сервера в результате вскрытия не пострадало.
    Поделиться публикацией

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 11

      0
      Как раз искал что-то похожее! Спасибо что заботитесь о будущих админах.
        0
        Автор помоему недостаточно подкован в 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.
          0
          Отвечаю по пунктам)
          1. Да, к debian-подобным привык, есть такое. Сейчас вот с rh-подобными разбираюсь.
          2. пример с mtu взят из Red Hat Knowledgebase DOC-8695 (!) Но умоляю Вас сильно не пинать Red Hat, они все же многое сделали для Linux и Open Source сообщества вцелом) Да и статья в kbase писалась в далеком декабре 2004го, может за 5 лет, как раз и добавили параметр для задания MTU
          3. Ни в коем случае не собираюсь ругать тот или иной дистриб. Мотивы, по которым писалась моя заметка — в первых двух ее абзацах.

          Если вдаваться в подробности, то изначальная цель была другой — заставить весь трафик данного хоста (даже локальный — т.е. в пределах его подсети) ходить через gateway. Сам знаю, что задача несколько странная. Так как перелопатив весь каталог network-scripts я не нашел возможности удаления/изменения маршрута для родной подсети, создаваемого по-умолчанию — пришлось работать через запускаемый скрипт.

          В случае, если вы ткнете меня в способ решения данной задачи не выходя за пределы идеологии RH — буду очень благодарен.
            0
            С удовольствие ткну :)
            вот примеры:

            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. Я переживаю и стараюсь помочь, чтоб не дать разочароваться в них.
            :)
              0
              забыл в первый пунк:
              NETWORK=192.168.0.0
                0
                На практике не проверял — сделаю это в понедельник (не люблю в ночь на субботу ковырять настройки интерфейса у работающего сервера… чревато....)))) Пока просто скрипты почитал

                SCOPE=«peer 192.168.0.1» — это хак)))
                И исключительно по принципу «грязный хак против долгого гемора»
                Причем откровенный… Ну где же тут идеология RH?.. Ведь стоит им в скрипте организовать проверку SCOPE по возможным значениям (хотя бы на том уровне, на котором это организовано для параметров маршрутизации) — и работа сети после апдейта нарушится.
                  0
                  По Вашему разумению, вообще все команды ip xxx — это хак… смешно.
                  Ну еще бы проверяли бы.
                  Идеалогия в том, чтоб настройки хранились там где им положено, что и было Вам наглядно продемонстрировано.
                  И заместо «благодарности», обещанной в предыдущем ответе, Вы прикрываете свою некомпетентность, откровенным хамством.
                  по Вашему, если я в том же файле напишу:
                  ETHTOOL_OPTS=«speed 10 duplex half autoneg off»
                  то это тоже будет хак?
                  если это хак — тогда использование отдельно команды после поднятия интерфейса — это извращение.

                  Вы красиво пытались прикрыть отсутствие знаний, заботой о будущих админах — ну и где ж здесь расхождение с желаемым?
                    0
                    Команды ip — очень удобное средство.
                    «чтоб настройки хранились там где им положено» — да я только за!
                    вот только использование отсутствия проверки параметра SCOPE для того, чтобы вставить другой параметр (peer) со значением этого другого параметра — считаю неразумным. Как только в скрипте появится данная проверка (параметра scope, благо он задокументирован) — это сразу проявится. Способ же предложенный мной не использует никаких назадокументированных возможностей скрипта. Более того, опирается на статью из RH KB. При этом все настройки продолжают хранится в /etc/sysconfig/network-scripts/
                    Именно там, где их и будут искать.
                    А по поводу примера использвоания ETHTOOL_OPTS — ничего против не имею. В данном случае, имя параметра и его назначение вполне соотносится со значением ему присвоенным.
                    Вас послушать, так за появление в федоре каталогов ifup.d и ifdown.d вообще надо на костре сжечь. Мой способ просто реализует их функционал. Они ведь тоже служат для выполнения отдельных команд после поднятия интерфейса.
                    И я действительно считаю, что полная команда, прописанная в файле лежащем, к примеру, в ifup.d гораздо удобнее, чем подстановака одного параметра вместо другого, опирающаяся на отсуствии проверки этого другого параметра скриптом. Как-то очевиднее это, что ли…
                    Отсуствия у себя знаний в определенных областях я не стесняюсь. Вот только ваша категоричная вера в собственную исключительную правоту вызывает у меня, как минимум. удивление. Я готов с радостью увеличить уровень своей компетентности в данном вопросе. Но ваши доводы не кажутся мне достаточными, чтобы назвать ваш способ решения задачи единственно-верным, а мой — предать огню)) Оценивать же чью-то компетентность только на основании того, разделяет ли человек мое мнение в определенном (достаточно узком) вопросе или нет — я бы не стал. Мне кажется, что тут вы перегибаете палку.
                    По поводу же хамства — ни в коем случае не собирался Вас задеть.

                      0
                      Поясните пожалуйста тогда, в чем разница между поднятие scope через команду ip и запись на поднятие в файле настройки самого интерфейса?
                      То есть, получаеться, что записать этот параметр в файле настройки интерфейса — это хак, а отдельной командой, в отдельном файле — это true way. Кстати и в debian-based, есть возможность давать команды post-up и т.д. непосредственно в самом файле /etc/network/interfaces
                      Не хочу перегибать, если чем-то задел, прошу прощения, но в корне не согласен.
                      Да и распалятся по поводу, не вижу необходимости, Ваша задача решена. И поверьте мне, если в будущем админ будет разбираться с Вашими настройками, то в первую очередь будет смотреть в фал настроек интерфейса, а не в папки if-up.d и т.д., и увидев данную запись, поймет смысл не просматривая дополнительные файлы.
                      Тем более что у меня нет аккаунта на Хабре(очень жаль), это аккаунт моего товарища, он любезно предоставил возможность написать в этот топик, когда увидел моё возмущение по subj.
                        0
                        Разница в использовании недокументированных возможностей. Речь вот о чем:
                        Присутствуй в скриптах обработка параметра 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 (или его аналогом) мы получим более стабильную систему. Ну а админу — да, придется потратить дополнительно пару секунд на то, чтобы просмотреть еще один файл.

                        Надеюсь, что у меня получилось пояснить свою точку зрения.
            0
            Неясно, кто и как должен вызывать
            ifup-local <interface_name>

            Ссылка на сайт редхака недоступна, ибо требует подписки.

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

            Самое читаемое