Version v15.2 (2013-05-01 20:53) [AUTO]

s4a.tex

@@ -4925,6 +4925,241 @@ systemctl dump > systemd-dump.txt
 \end{Verbatim}
 \end{itemize}
 
+\section{Предсказуемые имена сетевых интерфейсов\sfnote{Перевод статьи
+<<\href{http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames}%
+{Predictable Network Interface Names}>> с официального сайта проекта, по
+состоянию на 2013-01-22 20:22:48 (ревизия \No27).}}
+
+Начиная с версии 197, systemd/udev присваивает сетевым интерфейсам (Ethernet,
+WLAN, WWAN\footnote{Прим. перев.: WWAN (Wireless Wide Area Network)~---
+относительно новый термин, обозначающий технологии глобальных беспроводных
+компьютерных сетей, такие, как GPRS, 3G, WiMAX и т.д.}) стабильные,
+предсказуемые имена. Новая схема именования несколько отличается от классической
+(+eth0+, +eth1+, +wlan0+, \ldots{}), однако при этом лишена и многих ее
+недостатков.
+
+\subsection{Зачем?}
+
+Классическая схема именования сетевых интерфейсов, используемая ядром,
+предполагает последовательное присвоение интерфейсам имен +eth0+, +eth1+ и т.д.,
+по мере опроса оборудования соответствующими драйверами (device probing). На
+современных системах такой опрос не~обеспечивает гарантированного соблюдения
+одного и того же порядка поступления ответов. Вследствие этого, соответствие
+имен реальным интерфейсам не~является чем-то фиксированным, и очень может быть,
+что интерфейс, который сейчас называется +eth0+, при следующей загрузке
+превратится в +eth1+. Такая ситуация приводит к целому ряду проблем, в
+частности, к проблемам с безопасностью: в настройках брандмауэра интерфейсы
+идентифицируются как раз по именам.
+
+Существует несколько подходов к решению этой проблемы. В течение многих лет udev
+поддерживал механизм постоянной привязки имен к интерфейсам, на основе
+MAC-адресов. Такой подход имел множество недостатков, в том числе: требование
+доступности корневого каталога на запись (что возможно далеко не~всегда);
+необходимость внесения изменений в образ системы после загрузки на новом
+оборудовании; привязка к MAC-адресам, которые далеко не~всегда являются
+фиксированными (в частности, это касается многих встраиваемых систем и
+механизмов виртуализации). Тем не~менее, основная проблема такого подхода
+состояла в том, что он использовал имена из того же адресного пространства
+(+ethX+), что и ядро. Вследствие этого, возникали ситуации <<гонки>> между udev
+и ядром, когда udev пытался присвоить интерфейсу имя, которое ядро уже выдало
+другому интерфейсу, что приводило к сбою операции переименования. Вследствие
+перечисленных недостатков, данный механизм был удален из 
+systemd/udev\footnote{Прим. перев.: См. коммит
+\href{http://cgit.freedesktop.org/systemd/systemd/commit/?id=3e2147858f21943d5f4a781c60f33ac22c6096ed}%
+{3e214} от 3 апреля 2012 года, в котором, среди прочего, был удален каталог
++src/udev/src/rule_generator+.}.
+
+Другая попытка решения обсуждаемой проблемы~--- +biosdevname+, программа,
+формирующая имена интерфейсов на основании их физического расположении на
+материнской плате. Соответствующая информация запрашивается у BIOS. В чем-то
+такая схема похожа на ту, которую udev уже давно использует для формирования
+стабильных символьных ссылок на различные устройства (+/dev/*/by-path/*+), но,
+тем не~менее, в ее основе лежат несколько иные алгоритмы (udev, формируя свои
+символьные ссылки, опирается на идентификационные данные, предоставленные
+ядром, в то время как biosdevname использует свои собственные схемы).
+
+И наконец, многие дистрибутивы в своих сетевых скриптах поддерживают механизмы,
+позволяющие присваивать интерфейсам имена, выбранные пользователем (например,
++internet0+, +dmz0+, \ldots). Если бы не~необходимость явного вмешательства
+пользователя, это было бы замечательным решением.
+
+Мы пришли к выводу, что наилучшим вариантом для настроек по умолчанию будет
+схема, являющаяся обобщением и развитием механизма biosdevname. Присвоение
+интерфейсам имен на основании информации об их физическом расположении имеет ряд
+существенных достоинств: такие имена формируются автоматически, всегда
+предсказуемы, а также остаются неизменными даже при добавлении и удалении
+оборудования, что позволяет без лишних проблем заменять сломанные сетевые
+устройства. Тем не~менее, такие выглядят немного сложнее, чем привычные +eth0+ и
++wlan0+, например: +enp5s0+.
+
+\subsection{Что именно было изменено в версии 197?}
+
+В версии 197 мы добавили в systemd/udevd встроенную поддержку нескольких
+различных механизмов именования сетевых интерфейсов, получив в итоге схему,
+похожую на biosdevname, но отличающуюся большей гибкостью и максимально
+приближенную к алгоритмам идентификации устройств, используемым в ядре.
+В частности, udev теперь штатно поддерживает следующие механизмы именования
+сетевых интерфейсов:
+\begin{enumerate}
+	\item Схема именования для устройств, встроенных в материнскую плату (на
+		основании  информации от EFI/BIOS), например: +eno1+.
+	\item Схема именования для устройств, подключенных в слоты PCI Express
+		(также на основании информации от EFI/BIOS), например: +ens1+.
+	\item Схема именования, основанная на физическом расположении точки
+		подключения оборудования, например, +enp2s0+.
+	\item Схема именования на основании MAC-адреса, например,
+		+enx78e7d1ea46da+.
+	\item Классические, непредсказуемые имена, присвоенные ядром, например,
+		+eth0+.
+\end{enumerate}
+
+По умолчанию, systemd 197 при именовании сетевых интерфейсов последовательно
+пытается применить схемы 1--3 (для первых двух требуется информация от
+EFI/BIOS). Если ни одна из них не~подходит, используется схема 5. Что касается
+схемы 4~--- она не~задействована по умолчанию, однако ее можно включить вручную.
+
+Вышеописанная комбинированная схема используется лишь \emph{в последнюю
+очередь}. Если у вас установлена программа biosdevname, для именования сетевых
+устройств будет использоваться именно она. Кроме того, приоритет предоставляется
+любым правилам, добавленным пользователем или разработчиками дистрибутива.
+
+\subsection{Еще раз, что здесь хорошего?}
+
+С нашей новой схемой вы получаете:
+\begin{itemize}
+	\item Имена интерфейсов остаются неизменными после перезагрузок.
+	\item Имена интерфейсов остаются неизменными при добавлении или
+		удалении устройств.
+	\item Имена интерфейсов остаются неизменными при обновлении/изменении
+		ядра и драйверов.
+	\item Имена интерфейсов остаются неизменными при замене сломанных
+		сетевых карт новыми.
+	\item Имена формируются автоматически, безо всякого вмешательства
+		пользователя.
+	\item Имена являются предсказуемыми: достаточно просто взглянуть на
+		вывод +lspci+, чтобы узнать, как будет называться конкретное
+		устройство.
+	\item Изменения в аппаратной конфигурации не~приводят к необходимости
+		записи в каталог +/etc+.
+	\item Полная поддержка системам, корень которых доступен только
+		для чтения.
+	\item Схема именования аналогичная той, которая используется
+		udev для формирования стабильных символьных ссылок в каталоге
+		+/dev+ (+by-path+).
+	\item Работает как на x86, так и на~других архитектурах.
+	\item Работает одинаково во всех дистрибутивах, использующих на
+		systemd/udev.
+	\item От этой схемы очень легко отказаться (см. ниже).
+\end{itemize}
+
+Есть ли у нее недостатки? Да. Раньше, если на компьютере имелся всего один
+сетевой интерфейс, можно было с высокой долей вероятности утверждать, что он
+называется +eth0+. Теперь же, прежде чем администратор начнет настраивать сеть,
+он должен как минимум просмотреть список сетевых интерфейсов.
+
+\subsection{Мне не~нравится ваша схема. Как ее отключить?}
+
+У вас есть три варианта:
+\begin{enumerate}
+	\item Вы можете полностью отключить новую схему, вернувшись к
+		классическим непредсказуемым именам. Для этого достаточно
+		заблокировать (замаскировать) соответствующий файл правил udev:
+\begin{Verbatim}
+ln -s /dev/null /etc/udev/rules.d/80-net-name-slot.rules
+\end{Verbatim}
+	\item Вы можете вручную назначить интерфейсам наиболее понятные для вас
+		имена (например, +internet0+, +dmz0+, +lan0+). Для этого,
+		подготовьте свои собственные правила, указав в них нужные имена
+		при помощи параметра +NAME+, после чего сохраните их в файл с
+		более высоким приоритетом, чем правила по умолчанию, например,
+		+/etc/udev/rules.d/70-my-net-names.rules+. (Приоритет файлов
+		определяется на основании алфавитной сортировки их имен.)
+	\item Вы можете скорректировать правила, используемые по умолчанию,
+		например, задействовав схему именования интерфейсов по
+		MAC-адресам. Для, этого скопируйте файл правил в каталог +/etc+
+\begin{Verbatim}
+cp /usr/lib/udev/rules.d/80-net-name-slot.rules /etc/udev/rules.d/80-net-name-slot.rules
+\end{Verbatim}
+		после чего измените его так, как считаете нужным.
+\end{enumerate}
+
+\subsection{Как именно работает новая схема?}
+
+Подробности технической реализации описаны в блоке комментариев в
+\href{http://cgit.freedesktop.org/systemd/systemd/tree/src/udev/udev-builtin-net_id.c#n20}%
+{исходном коде net-id built-in}. Ознакомьтесь с ним, если у вас возникают
+вопросы, касающиеся расшифровки новых имен\footnote{Прим. перев.: Далее
+приводится перевод упомянутого блока комментариев. Последним коммитом,
+затронувшим данный файл, на момент перевода является b92be от 24 марта
+2013 г.}.
+
+\begin{Verbatim}
+Предсказуемые имена сетевых интерфейсов формируются на основании:
+ - индексов встроенных в материнскую плату устройств (по информации EFI/BIOS)
+ - индексов hotplug-слотов PCI-E (по информации EFI/BIOS)
+ - физического расположения точки подключения оборудования
+ - MAC-адресов
+
+Первые два символа в имени определяют тип интерфейса:
+  en -- ethernet
+  wl -- wlan
+  ww -- wwan
+
+Последующие символы определяеются используемой схемой:
+  o<index> -- для устройств, встроенных в материнскую плату
+  s<slot>[f<function>][d<dev_id>] -- для hotplug-слотов
+  x<MAC> -- при именовании по MAC-адресу
+  p<bus>s<slot>[f<function>][d<dev_id>] -- на основании физического
+      расположения PCI-устройства
+  p<bus>s<slot>[f<function>][u<port>][..][c<config>][i<interface>]
+      -- идентификационная цепочка для USB-устройств
+
+Все многофункциональные (multi-function) PCI-устройства содержат в своем имени
+номер функции [f<function>] (отсчитываются от нуля).
+
+Для USB-устройства формируется полная цепочка номеров портов хабов, через
+которые оно подключено. Если итоговая строка будет длиннее 15 символов, она
+не экспортируется.
+Стандартные значения config == 1 и interface == 0 опускаются.
+
+Примеры:
+
+Подключенная к PCI сетевая карта, которая идентифцироуется прошивкой
+по индексу "1":
+  ID_NET_NAME_ONBOARD=eno1
+  ID_NET_NAME_ONBOARD_LABEL=Ethernet Port 1
+
+Сетевая карта, включенная в hotplug PCI-слот, который идентифицируется
+прошивкой:
+  /sys/devices/pci0000:00/0000:00:1c.3/0000:05:00.0/net/ens1
+  ID_NET_NAME_MAC=enx000000000466
+  ID_NET_NAME_PATH=enp5s0
+  ID_NET_NAME_SLOT=ens1
+
+Multi-function PCI устройство с двумя портами:
+  /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.0/net/enp2s0f0
+  ID_NET_NAME_MAC=enx78e7d1ea46da
+  ID_NET_NAME_PATH=enp2s0f0
+  /sys/devices/pci0000:00/0000:00:1c.0/0000:02:00.1/net/enp2s0f1
+  ID_NET_NAME_MAC=enx78e7d1ea46dc
+  ID_NET_NAME_PATH=enp2s0f1
+
+Подключенная к PCI wlan-карта:
+  /sys/devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlp3s0
+  ID_NET_NAME_MAC=wlx0024d7e31130
+  ID_NET_NAME_PATH=wlp3s0
+
+Встроенный USB 3G модем:
+  /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.4/2-1.4:1.6/net/wwp0s29u1u4i6
+  ID_NET_NAME_MAC=wwx028037ec0200
+  ID_NET_NAME_PATH=wwp0s29u1u4i6
+
+Подключенный по USB Android-смартфон:
+  /sys/devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/net/enp0s29u1u2
+  ID_NET_NAME_MAC=enxd626b3450fb5
+  ID_NET_NAME_PATH=enp0s29u1u2
+\end{Verbatim}
+
 \section{Специальные файловые системы\sfnote{Перевод статьи
 <<\href{http://www.freedesktop.org/wiki/Software/systemd/APIFileSystems}{API
 File Systems}>> с официального сайта проекта, по состоянию на 2013-01-17