Handbook:Parts/Networking/Advanced/ru

Расширенная настройка
Переменная config_eth0 это основа в конфигурации интерфейса. Это список инструкций высокого уровня для настройки интерфейса (eth0 в данном случае). Каждая команда в списке инструкций выполняется последовательно. Интерфейс считается работоспособным, если хотя бы одна команда работает.

Вот список встроенных инструкций:

Если команда не выполняется, укажите значение для fallback. fallback вариант должен строго соответствовать структуре конфигурации.

Возможно сцепить эти значения вместе. Вот несколько практических примеров:

Сетевые зависимости
Сценарии инициализации в могут зависеть от конкретного сетевого интерфейса или просто от "net". Все сетевые интерфейсы в системе инициализации Gentoo обеспечивают то, что называется "net".

Если в переменная rc_depend_strict установлена в , тогда все сетевые интерфейсы "net" "должны" быть удачно запущены перед тем как зависимости от "net" смогут запуститься. Другими словами, если в системе есть net.eth0 и net.eth1, то они должны быть оба запущены перед тем, как сможет запустится init-скрипт, зависящий от "net".

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

Но что по поводу зависимости net.br0 от net.eth0 и net.eth1? от net.eth1, возможно, нужно настроить беспроводное или PPP устройство перед добавлением их в сетевой мост. Это нельзя сделать в, так как это символьная ссылка на net.lo.

Ответ в определении настройки rc_need_ в :

Этого, однако, не достаточно, как такового. Сетевые init-скрипты используют виртуальную зависимость, которая называется "net", которая информирует систему о том, что сеть доступна. Очевидно, что и в предыдущем случае, сеть должна быть помечена как доступной, только тогда, когда поднят интерфейс net.br0, а не другие. Таким образом, мы должны написать в так:

За подробной информацией о зависимостях обратитесь к разделу о написании init-скриптов в Gentoo Handbook. Больше информации о доступно в виде комментариев в самом файле.

Имена переменных и значения
Имена переменных динамичны. Как правило, они следуют следующей структуре. Например, переменная dhcpcd_eth0 содержит значение для опций dhcpcd на интерфейсе eth0, а dhcpcd_essid содержит опции для dhcpcd при подключении любой из интерфейсов к ESSID "essid".

Тем не менее, нет жестких правил, которые бы говорили, что имена сетевых интерфейсов должны называться ethx. Многие беспроводные интерфейсы называются как wlanx или rax на ряду с ethx. Кроме того, некоторым пользовательским интерфейсам, таким как сетевые мосты, можно назначать любое имя. Для того, чтобы сделать жизнь более прекрасной, беспроводным точкам доступа могут быть назначены имена без цифро-буквенных символов - это важно, так как пользователи могут настраивать сеть для конкретной ESSID.

Недостаток в этом всем то, что Gentoo использует переменные баш для работы с сетью, а баш не может ничего использовать за пределами английского алфавита и цифр. Чтобы обойти это ограничение, мы заменяем любой не английский буквенно-цифровой символ на символ _ (подчеркивание).

Другой недостаток баш проявляется в содержании переменных; некоторые символы должны быть экранированы. Это можно сделать путем добавления \ (обратного слэша) перед символами которые должны быть экранированы. Ниже приведен список символов, которые должны быть экранированы таким образом:, и.

В это примере мы использовали беспроводной ESSID, поскольку они могут содержать большое количество символов. Мы будем использовать идентификатор ESSID My "\ NET:

Настройка выше устанавливает DNS домен в My "\ NET, когда беспроводная карта подключена к точке доступа у которой ESSID My "\ NET.

Как это работает
Имена сетевых интерфейсов не выбираются произвольно: ядро Linux и менеджер устройств (в большинстве систем используется Udev в качестве менеджера устройства, хотя могут быть другие варианты) выбирают имя сетевого интерфейса через фиксированный набор правил.

В случае обнаружения сетевой карты в системе, ядро Linux собирает необходимые данные об этой карте. В которые входят:


 * The onboard (on the interface itself) registered name of the network card, which is later seen through the ID_NET_NAME_ONBOARD value.
 * The slot in which the network card is plugged in, which is later seen through the ID_NET_NAME_SLOT value.
 * The path through which the network card device can be accessed, which is later seen through the ID_NET_NAME_PATH value.
 * The (vendor-provided) MAC address of the card, which is later seen through the ID_NET_NAME_MAC value.

Based on this information, the device manager decides how to name the interface on the system. By default, it uses the first hit of the first three variables above ( ID_NET_NAME_ONBOARD, _SLOT or _PATH ). For instance, if ID_NET_NAME_ONBOARD is found and set to, then the interface will be called eno1.

Given an active interface name, the values of the provided variables can be shown using :

As the first (and actually only) hit of the top three variables is ID_NET_NAME_PATH, its value is used as the interface name. If none of the variables contain values, then the system reverts back to the kernel-provided naming (eth0, eth1, etc.)

Использование устаревшего именования
Before this change, network interface cards were named by the Linux kernel itself, depending on the order that drivers are loaded (amongst other, possibly more obscure reasons). This behavior can still be enabled by setting the  boot parameter in the boot loader.

Использование пользовательского именования
The entire idea behind the change in naming is not to confuse people, but to make changing the names easier. Suppose a system has two interfaces that are otherwise called eth0 and eth1. One is meant to access the network through a wire, the other one is for wireless access. With the support for interface naming, users can have these called lan0 (wired) and wifi0 (wireless - it is best to avoid using the previously well-known names like eth* and wlan* as those can still collide with the suggested names).

Find out what the parameters are for the cards and then use this information to set up a custom own naming rule:

Because the rules are triggered before the default one (rules are triggered in alphanumerical order, so 70 comes before 80) the names provided in the rule file will be used instead of the default ones. The number granted to the file should be between 76 and 79 (the environment variables are defined by a rule start starts with 75 and the fallback naming is done in a rule numbered 80).