Внутреннее устройство Linux - Уорд Брайан - Страница 69

9.11.3. Конфигурация менеджера NetworkManager

Основным каталогом конфигурации менеджера NetworkManager обычно является /etc/NetworkManager, и в нем присутствует несколько различных типов конфигурации. Главный файл конфигурации — NetworkManager.conf. Его формат подобен XDG-файлам .desktop и файлам .ini стандарта Microsoft: пары параметров «ключ — значение» распределены по различным секциям. Вы обнаружите, что практически каждый файл конфигурации содержит секцию [main], которая определяет необходимые для использования плагины. Вот простой пример, в котором активизируется плагин ifupdown, применяемый в системах Ubuntu и Debian:

[main]

plugins=ifupdown,keyfile

Плагинами, которые зависят от версии ОС, являются ifcfg-rh (для семейства Red Hat) и ifcfg-suse (для SuSE). Плагин keyfile, который вы также видите здесь, поддерживает собственный файл конфигурации менеджера NetworkManager. При использовании этого плагина можно увидеть опознанные системой подключения в файле /etc/NetworkManager/system-connections.

В большинстве случаев вам не потребуется изменять файл NetworkManager.conf, поскольку специальные параметры конфигурации находятся в других файлах.

Неуправляемые интерфейсы

Несмотря на то что менеджер NetworkManager может вам понадобиться для управления большинством сетевых интерфейсов, иногда возникают ситуации, когда необходимо игнорировать интерфейсы. Например, нет причин для того, чтобы большинству пользователей понадобился какой-либо тип динамической конфигурации интерфейса локального хоста (lo), так как эта конфигурация никогда не меняется. Может также потребоваться настроить этот интерфейс на ранних стадиях процесса загрузки системы, поскольку основные системные службы часто зависят от него. В большинстве версий ОС менеджер NetworkManager не допускается к локальному хосту.

Можно дать указание менеджеру NetworkManager, чтобы он игнорировал какой-либо интерфейс, используя плагины. Если вы применяете плагин ifupdown (например, в Ubuntu и Debian), добавьте конфигурацию интерфейса в файл /etc/network/interfaces, а затем в секции ifupdown файла NetworkManager.conf установите для параметра managed значение false:

[ifupdown]

managed=false

Для плагина ifcfg-rh, который используется в Fedora и Red Hat, поищите строку, подобную приведенной ниже, в каталоге /etc/sysconfig/network-scripts, который содержит конфигурационные файлы ifcfg-*:

NM_CONTROLLED=yes

Если такой строки нет или установлено значение no, менеджер NetworkManager игнорирует данный интерфейс. Например, вы обнаружите, что он деактивизирован в файле ifcfg-lo. Можно также указать адрес аппаратного средства, которое следует игнорировать:

HWADDR=10:78:d2:eb:76:97

Если вы не используете ни одну из этих схем сетевой конфигурации, можно применить плагин keyfile, чтобы указать неуправляемое устройство прямо в файле NetworkManager.conf с помощью адреса MAC. Это могло бы выглядеть так:

[keyfile]

unmanaged-devices=mac:10:78:d2:eb:76:97;mac:1c:65:9d:cc:ff:b9

Диспетчеризация

Одна из завершающих деталей конфигурации менеджера NetworkManager относится к указанию дополнительных системных действий для тех случаев, когда сетевой интерфейс становится активным или отключается. Например, некоторым сетевым демонам для корректной работы необходимо знать, когда начать или завершить прослушивание интерфейса (например, демону защищенной оболочки, о которой пойдет речь в следующей главе).

Когда статус сетевого интерфейса в системе меняется, менеджер NetworkManager запускает все, что находится в каталоге /etc/NetworkManager/dispatcher.d с каким-либо из аргументов, таким как up или down. Это сравнительно просто, однако во многих версиях ОС используются собственные сценарии управления сетью, поэтому в указанном каталоге нет отдельных сценариев диспетчеризации. В Ubuntu, например, применяется всего один сценарий — 01ifupdown, который запускает все, что расположено в соответствующем подкаталоге каталога /etc/network, например в /etc/network/if-up.d.

Что касается остальной конфигурации менеджера NetworkManager, подробности сценариев не так уж важны; вам необходимо знать лишь о том, как определить соответствующее местоположение, если вам потребуется внести изменения. И, как обычно, заглядывайте в сценарии собственной системы.

9.12. Разрешение имени хоста

Одной из заключительных задач любого сетевого конфигурирования является разрешение имени хоста с помощью службы DNS. Вы уже видели инструмент host, который переводит имя, такое как www.example.com, в IP-адрес вроде 10.23.2.132.

Служба DNS отличается от рассмотренных нами элементов сети, так как она расположена на прикладном уровне, полностью в пространстве пользователя. Технически она немного не на своем месте в данной главе, рядом с обсуждением интернет-уровня и физического уровня. Но при неправильной конфигурации DNS ваше интернет-подключение практически бесполезно. Никто не станет рекламировать IP-адреса вместо имен сайтов и адресов электронной почты, поскольку IP-адрес хоста может измениться, да и набор чисел запомнить непросто. Автоматические службы сетевой конфигурации, такие как DHCP, почти всегда содержат конфигурацию DNS.

Практически все сетевые приложения в Linux выполняют поиски DNS. Процесс разрешения имен обычно протекает следующим образом.

1. Приложение вызывает функцию, чтобы выяснить IP-адрес, который стоит за именем хоста. Эта функция находится в совместно используемой системной библиотеке, поэтому приложению не нужно знать подробности о том, как она работает, или об изменениях в ее реализации.

2. Когда эта функция запускается, она действует в соответствии с набором правил (расположенных в файле /etc/nsswitch.conf), чтобы установить план действий при поисках. Например, такие правила обычно говорят о том, что перед переходом к DNS следует проверить ручное переопределение в файле /etc/hosts.

3. Когда функция решает использовать службу DNS для поиска имени, она обращается к дополнительному файлу конфигурации, чтобы найти сервер имен DNS. Сервер имен представлен в виде IP-адреса.

4. Функция отправляет DNS-запрос на поиск (по сети) серверу имен.

5. Сервер имен сообщает в ответ IP-адрес имени хоста, а функция возвращает этот IP-адрес приложению.

Это упрощенный вариант. В типичной современной системе присутствует больше исполнителей, которые стремятся ускорить трансакцию и/или добавить гибкость. Пока проигнорируем их и более подробно рассмотрим основные составляющие.

9.12.1. Файл /etc/hosts

В большинстве систем можно переопределить параметры поиска имен хоста с помощью файла /etc/hosts. Обычно это выглядит так:

127.0.0.1       localhost

10.23.2.3       atlantic.aem7.net       atlantic

10.23.2.4       pacific.aem7.net        pacific

Практически всегда вы увидите здесь запись для локального хоста (см. раздел 9.13).

примечание

В старые недобрые времена был единственный центральный хост-файл, который каждый пользователь копировал на собственный компьютер, чтобы данные были самыми свежими (см. Рабочие предложения № 606, 608, 623 и 625), однако с развитием сетей ARPANET/Internet это быстро стало ненужным.

9.12.2. Файл resolv.conf

Традиционным файлом конфигурации для серверов DNS является файл /etc/resolv.conf. Когда все было проще, типичный пример мог выглядеть так (здесь 10.32.45.23 и 10.3.2.3 — это адреса серверов имен у поставщика интернет-услуг):

search mydomain.example.com example.com

nameserver 10.32.45.23

nameserver 10.3.2.3

Строка search определяет правила для неполных хост-имен (то есть для первой части имени хоста; например, myserver вместо myserver.example.com). Здесь библиотека с функцией разрешения имен попыталась бы поискать имена host.mydomain.examp­le.com и host.example.com. Однако теперь все, как правило, не настолько просто. В конфигурации службы DNS сделано много улучшений и изменений.