Проект /etc/net. Вопросы конфигурации сетевых настроек Linux.

Денис Овсиенко, ALT Linux Team. Доклад для конференции OSDN.org.ua'2004

Valid HTML 4.0 Transitional

  1. Введение

    В настоящее время значительная (если не бОльшая) часть компьютеров с Linux имеет подключение к сети, которое обрабатывается системой конфигурации. Под конфигуратором сети в данном случае понимается программная часть (набор сценариев и программ), обрабатывающая собственно настройки конкретной Linux-системы. Конфигуратор должен позволять оперировать состоянием системы уровнем понятий "включить/выключить поддержку сети", "сконфигурировать/расконфигурировать сетевой интерфейс вручную", "отреагировать на сетевой интерфейс с горячим подключением".
    Основные широко применяющиеся системы конфигурации сети Linux — RedHat initscripts и Debian /etc/network (и наследованные от них). В ALTLinux основная используемая система — net-scripts (ответвление от RedHat initscripts). Периодически я сталкивался с ситуациями, когда штатных средств net-scritps было недостаточно для требуемой конфигурации. Иногда проблему удаётся решить в обход штатных средств путём добавления в rc.local дополнительных команд, но при рестарте сети или системы эти настройки зачастую оказываются потерянными. Ещё один недостаток состоит в том, что добавление поддержки нового типа сетевых интерфейсов как правило требует очередной копии одного и того же shell-кода и не всегда полностью отражает специфику конкретного типа интерфейса.
    В результате анализа существующих конфигурационных утилит и возникающих задач была начата разработка новой системы конфигурации /etc/net (etcnet) для полноценного использования современных возможностей Linux. Часть решений мигрировала из числа оригинальных дополнений к net-scripts из ALTLinux. Исходный код публикуется на домашней странице проекта.

  2. Принципиальные отличия от аналогов.

  3. Описание /etc/net

    Все файлы располагаются в каталоге /etc/net. В нём располагаются файлы глобальной конфигурации, каталог со сценариями (/etc/net/scripts) и каталог с настройками /etc/net/ifaces. Необходимо отметить, что для каждого интерфейса обязательно определён его тип, который либо вычислен из имени, либо явно определён в конфигурации. На основании типов при общем старте формируется порядок конфигурации интерфейсов. Например, для запуска bonding-интерфейса необходимо, чтобы подчинённые интерфейсы уже были созданы и сконфигурированы. При простейшей обработке по алфавиту будет сначала предпринята попытка обработать bond0, так как он лексикографически меньше eth0 и eth1. Без отсутствия строгой типизации этот конфликт можно решить только в частном порядке, как это сделано в initscripts RHEL: 

    # master device?
if [ "${TYPE}" =  "Bonding" ] || ethtool -i $DEVICE | grep -q "driver: bonding" ; then
    /sbin/ip link set dev ${DEVICE} up
    for device in `fgrep -l "MASTER=${DEVICE}" /etc/sysconfig/network-scripts/ifcfg-*` ; do
        /sbin/ifup ${device##*/}
    done
fi

    Этот код обрабатывает всего один частный случай и не будет работать для, например, TEQL-интерфейсов. Но что делать, если необходимо создать интерфейс aaa0, который будет являться VLAN-интерфейсом для eth0, но при такой схеме обработается (ошибочно) до создания родительского интерфейса? В etcnet эта неопределённость уменьшена за счёт типов интерфейсов, каждый из которых включает один или более видов, к которым в свою очередь уже принадлежат конкретные интерфейсы (не все из приведённых видов поддерживаются на момент публикации этого доклада):

    Видно, что если обрабатывать интерфейсы в указанном порядке, то большинство проблем, вызванных лексикографическим порядком обработки, исчезнет. Для полного решения проблемы зависимости также запланирован механизм административного назначения порядка инициализации и зависимостей внутри логической группы.
    Если по имени интерфейса нельзя определить его тип, то тип обязательно должен быть указан в конфигурационном файле. Это жёсткое требование etcnet.

    Следующей важной частью общей логики работы является порядок конфигурации интерфейса. Он разработан таким образом, чтобы все типы и виды интерфейсов обрабатывались по одному общему принципу. Основные действия выполняются в сценарии /etc/net/scripts/ifup-common, который вызывается из сценариев /etc/net/scripts/ifup для обычных интерфейсов и /etc/net/scripts/ifup-removable для интерфейсов с горячим подключением (в последнем случае вызов происходит из агентов сменных устройств). Упрощённый алгоритм работы ifup-common выглядит следующим образом:

    1. чтение общих настроек
    2. чтение настроек для текущего вида интерфейса
    3. определение профиля
    4. чтение настроек для конкретного экземпляра интерфейса
    5. конфигурация беспроводных расширений
    6. конфигурация канальных параметров для всех интерфейсов
    7. конфигурация канальных параметров для вида
    8. конфигурация канальных параметров для экземпляра
    9. очистка интерфейса от адресов
    10. конфигурация IPv4 (адреса, маршруты, таблицы и правила маршрутизации)
    11. конфигурация IPv6 (адреса и маршруты)
    12. конфигурация IPX
    13. финализация

    Указанная последовательность предоставляет два важных преимущества: во-первых, опции могут наследоваться на нескольких уровнях; во-вторых, этот порядок позволяет при необходимости выполнять для конкретного вида или типа интерфейса необходимые действия в ключевых моментах процесса конфигурации. За счёт этого etcnet формируется как гибкая система с разумными параметрами по умолчанию.

    Рассмотрим два примера.

  4. Целесообразные области применения

    Конечно, учитывая нестандартный подход и разнообразие опций, в первую очередь etcnet предназначен для опытных сетевых администраторов. Тем более, так как процесс разработки продолжается (возможны ошибки в коде, смена путей и названий файлов, значений переменных), следует уметь оценивать риски от возможных сбоев в работе как при первом ознакомлении с пакетом, так и при смене версий. В то же время в текущей версии пакет может быть успешно использован (и используется) на некоторых системах. В настоящий момент etcnet рекомендуется сетевым администраторам, которым не хватает возможностей стабильных прототипов для настройки сложных маршрутизаторов. Это позволит им ознакомиться с вероятной штатной системой сетевой конфигурации в ALTLinux поколения 3.0.

  5. Сопутствующие вопросы и замечания

    Так как конфигурация сети является одной из базовых составляющих дистрибутива Linux, etcnet нельзя просто установить и использовать. Потребуются некоторые изменения в системе и некоторых программах.
    В ходе разработки были изготовлены патчи для пакетов wireless-tools и pcmcia-cs. В первом случае была модифицирована утилита ifrename, во втором решена проблема с тем, что cardmgr не отслеживал смену имени интерфейса. Оба патча будут включены в дерево разработки Sisyphus. Также следует иметь в виду, что сценарии используют некоторые функции, которые специфичны для ALTLinux, на других дистрибутивах работоспособность будет проверяться только накануне стабильного релиза. Ещё один момент — выявленная ошибочная обработка событий вставки и извлечения сетевых карт смешанного типа, когда hotplug взаимодействует с cardmgr. Эта проблема после исследования скорее всего также потребует дополнительного патча.

  6. Направления и сроки развития.

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