Раздел: Компьютерная документация -> Операционные системы -> Linux

Случилось мне однажды переводить два десятка станций комплекса АСУТП на новую версию ОС. И предшествующая, и новая ОС принадлежали к семейству RedHat-совместимых. По составу ПО станции абсолютно идентичны и отличаются только аппаратной базой да сетевыми настройками. Станции и ранее поддерживались исключительно методом синхронизации с эталонным образом на сервере, и сейчас я не собирался проводить никаких инсталляций (не считая собственной "экспериментальной" машины, разумеется). Это определяется тем, что между мной и комплексом добрая тысяча километров, а персонал комплекса имеет о Linux очень приблизительные представления (что не мешает им эксплуатировать его год за годом).

Схема проста до примитивности: создаётся новый вариант инсталляции, из него — "эталон" станции на сервере, а персоналу оcтаётся только загрузиться на подготавливаемой станции с livecd и ответить на пяток вопросов. И всё было бы хорошо, если бы некоторые станции не имели по два сетевых интерфейса. Это, как правило, было следствием того, что когда-то, на момент приобретения станции, используемое ядро не поддерживало интегрированную сетевую карту — и станция доукомплектовывалась каким-нибудь более популярным сетевым адаптером от 3Com, Intel или RealTek. Нынешнее же ядро "видит" оба адаптера. Как следствие — два сетевых интерфейса и только один шанс из двух, что портированные настройки eth0 будут принадлежать именно тому адаптеру, к которому физически подключен сетевой кабель.

Нет связи — не могу вмешаться. Полагаю не рациональным вынуждать операторов знакомиться с разнообразием настроек сетевых интерфейсов. Практически, от оператора требуется только: 1) указать задаваемый ip-адрес станции (что он, собственно, делал и раньше) и 2) из двух наличных сетевых адаптеров выбрать один, действующий. Утилиту, сводящую настройку к желаемому минимуму вопросов я не нашёл, а объяснять оператору, что есть профайл, что за IPv6, DNS, DHCP и т.п. считаю излишеством. Так что пришлось написать крошечный скриптик, который всего-то переносил бы нужные настройки с eth0 на eth1 или наоборот.

Однако ни особенности клонирования станций, ни даже собственно конфигурирование сетевых интерфейсов в RedHat-совместимых дистрибутивах, предметом данной заметки не являются. Первое — "технические детали", второе достаточно подробно описано в документации, да и делается, обычно, однажды. А вот что действительно пришлось объяснять по ходу дела наиболее любознательным представителям персонала, так это особенности конфигурационных файлов. Поскольку объяснение сие происходило в письменной форме, то представление его в форме заметки напрашивалось. Может, и пригодится кому...

ifcfg-ethN

Именно так называются файлы конфигурации интерфейсов Ethernet, расположенные в каталогах /etc/sysconfig/network-scripts, /etc/sysconfig/networking/devices и /etc/sysconfig/networking/profiles/default. Содержимое этих файлов (достаточно очевидное, на мой взгляд) описано в Deployment Guide, в разделе "Interface Configuration Files". По три абсолютно идентичных файла на каждый интерфейс. А вот теперь самое забавное: редактировать можно любой из них — изменены будут все. Удаление одного из файлов не отражается на "близнецах" и ещё некоторые "фокусы", имеющие одно общее объяснение: мы имеем дело с так называемыми "жёсткими ссылками" (hardlinks).

Ничего особенного, в общем-то: если имя файла и его содержимое — обособленные объекты (а это, кажется, уже очевидно даже пользователям ms windows), то почему бы одному содержимому не иметь два и более имён? Есть нюанс: второе имя ссылается не на первое, а именно на содержимое файла. Ссылка на первое имя файла/каталога в *-nix-ах называется символической ссылкой (симлинком, symlink), а в ms windows "ярлыком" (link). Разница между подходами в данном случае состоит в том, что для *-nix-ов симлинки — объекты файловой системы (почти во всех смыслах идентичные каталогам/файлам), а для windows — это всего лишь файлы с расширением "lnk", позволяющие некоторым программам адресоваться к источнику ссылки. Правильным названием последних является "windows shell link" — ссылки для оболочки windows (т.е. для windows explorer). Симлинки теряют смысл при удалении источника ссылки, удаление симлинка никак не отражается на "первоисточнике", а изменение его (в зависимости от способа редактирования и прав доступа к источнику ссылки) может приводить как и изменению "первоисточника", так и к появлению нового "реального" объекта на месте симлинка.

Что же касается "жёстких ссылок" (hardlinks), то все они равноправны по отношению к содержимому. Просто: один файл — несколько имён. Отсюда и особенности редактирования ifcfg-ethN: содержимое-то во всех случаях одно и то же. Нечто подобное с некоторых пор существует и в ms windows (правда, только для NTFS), но об этом так мало знают, что и говорить об этом специально не стоит. Возможно, к этому придётся вернуться, когда жёсткие ссылки начнут активно использовать вирусописатели. Посмотрим...

hardlinks

Раз уж пришлось с этим столкнуться, то кое-какие средства работы с жёсткими ссылками придётся освоить. Прежде всего определим: является ли имя файла жёсткой ссылкой. Так, в нашем частном случае это можно сделать так:

[root@station network-scripts]# ls -l ifcfg-*

-rw-r--r-- 3 root root 201 Авг  4  2008 ifcfg-eth0

-rw-r--r-- 1 root root 254 Июн 21  2001 ifcfg-lo

Именно "длинная" (-l) форма команды ls сообщит нам (во втором поле вывода), что файл ifcfg-eth0 имеет целых три имени, тогда как файл ifcfg-lo — лишь одно.

Логично было бы определить, где именно лежит содержимое файла (так называемый inod). Всё та же ls даст нам эту информацию, если обнаружит среди параметров ключ -i. После чего команда find поможет найти все имена, ссылающиеся на данный inod. Примерно так:

[root@station network-scripts]# ls -li ifcfg-eth0

15204362 -rw-r--r-- 3 root root 201 Авг  4  2008 ifcfg-eth0

[root@station network-scripts]# find /etc -inum 15204362

/etc/sysconfig/networking/devices/ifcfg-eth0

/etc/sysconfig/networking/profiles/default/ifcfg-eth0

/etc/sysconfig/network-scripts/ifcfg-eth0

Обратите внимание, что для поиска find задан каталог /etc: предполагаем, что мы пока не знаем, где расположены остальные две жёстких ссылки. Поскольку количество найденных имён совпадает с их общим количеством, то можно быть уверенным, что мы нашли все интересующие нас хардлинки.

Можно и проще. Команда find имеет специальную опцию для поиска всех жёстких ссылок на файл. Тогда так:

[root@station network-scripts]# find /etc -samefile ifcfg-eth0

/etc/sysconfig/networking/devices/ifcfg-eth0

/etc/sysconfig/networking/profiles/default/ifcfg-eth0

/etc/sysconfig/network-scripts/ifcfg-eth0

О том, что редактировать с одинаковым успехом можно любой из "вычисленных" файлов, сказано выше. А вот для фактического удаления файла (с освобождением места на диске), полезно будет вспомнить о существовании команды xarg и возможности составления конвейеров. Всё вместе это будет выглядеть как:

[root@cmk network-scripts]# find /etc -samefile ifcfg-eth0 | xarg rm

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

Если вы работаете сразу с несколькими файловыми системами, примонтированными к вашей корневой, то не лишним для find может оказаться параметр -xdev. Этот параметр не позволит выйти за пределы "своей" ФС. Весьма разумно, если речь идёт о поиске по inod-ам.

Для полноты картины укажем ещё и на возможность создания дополнительного интерфейса (например: eth1), если такое когда-нибудь потребуется:

[root@station network-scripts]# touch ./ifcfg-eth1

[root@station network-scripts]# ln ./ifcfg-eth1 ../networking/devices/ifcfg-eth1

[root@station network-scripts]# ln ./ifcfg-eth1 ../networking/profiles/default/ifcfg-eth1

Здесь для создания жёстких ссылок используется команда ln без ключей.

Зачем?

У пользователей *-nix-ов такой вопрос обычно не возникает: если о жёстких ссылках ещё иногда приходится рассказывать, не так часто они применяются (и данная заметка — иллюстрация тому), то симлинки — как раз из тех удобств, которые *-nix-пользователь осваивает в первую очередь. Включение каталогов в качестве подкаталогов DocumentRoot web-сервера, общие конфигурационные файлы для многих пользователей, обеспечение совместимости с различными представлениями об архитектуре файловой системы — мало ли? А о том, насколько активно использует ссылки сама ОС, даже говорить не приходится: просто загляните в /etc/rc.d любого дистрибутива, использующего SysV-инициализацию.

Что касается пользователей ms windows, то если вы не создаёте до сих пор "ярлыки", то всё это действительно лишнее. Подобный пользователь, однако, вряд ли дочитает до этого абзаца. Остальным же порекомендую ознакомиться хотя бы с этим. Количество комментариев и оживлённость обсуждения показывают, что для определённой категории пользователей использование ссылок интерес представляет. То же обсуждение, правда, характеризует качество исполнения механизма ссылок в ms windows. Но, тут уж, "чем богаты...". Для заинтересованных — ещё одна ссылка на win-утилиту, максимально эмулирующую вышеупомянутую ln.

Пожалуй, всё...

Автор: Владимир Попов
Источник: www.citkit.ru