From 78ebb26a645aee2973819b9aac33d3f073884b41 Mon Sep 17 00:00:00 2001 From: nnz1024 <0comffdiz@inbox.ru> Date: Wed, 1 May 2013 20:53:00 +0400 Subject: [PATCH] Version v15.2 (2013-05-01 20:53) [AUTO] --- s4a.tex | 235 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 235 insertions(+) diff --git a/s4a.tex b/s4a.tex index 0056fcf..59653ca 100644 --- a/s4a.tex +++ b/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 -- для устройств, встроенных в материнскую плату + s[f][d] -- для hotplug-слотов + x -- при именовании по MAC-адресу + ps[f][d] -- на основании физического + расположения PCI-устройства + ps[f][u][..][c][i] + -- идентификационная цепочка для USB-устройств + +Все многофункциональные (multi-function) PCI-устройства содержат в своем имени +номер функции [f] (отсчитываются от нуля). + +Для 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