1xDed/s4a
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
nnz1024
2013-05-01 20:53:00 +04:00
parent df098ff4c1
commit 78ebb26a64
1 changed files with 235 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

235
s4a.tex
View File

@@ -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