Недостатки инициализации сети в CentOS

На днях пытался настроить сеть в CentOS по образу и подобию того, как я делал это ранее в статьях Два VPN-подключения к Уфанет и VPN-подключение к Уфанет и локальные ресурсы через Ethernet. Попробовал и понял: приличных средств для реализации такой настройки нет.

Для начала - у меня на компьютере имеются два интерфейса Ethernet, определились они под именами eth0 и eth1, как и положено. Только вот мне вдруг невтерпёж захотелось их поменять именами. Сказано - сделано, в RedHat и им подобным (включая CentOS) для привязки интерфейса к MAC-адресу кошерно использовать не udevd, а опцию HWADDR. Прописал необходимое значение этой опции в файлах /etc/sysconfig/network-scripts/ifcfg-eth0 и /etc/sysconfig/network-scripts/ifcfg-eth1. Попытки применить настройки скриптами инициализации сети и udev ни к чем не привели, поэтому пришлось перезагрузиться. После перезагрузки интерфейсы получили необходимые имена.

К слову, смена MAC-адреса на сетевой карте осуществляется с помощью опции MACADDR, но совместное использование HWADDR и MACADDR не допускается, т.к. может привести к непредсказуемым последствиям. То ли дело в Debian, где привязки имён интерфейсов к MAC-адресам осуществляются автоматически с помощью udev, а для смены привязок достаточно отредактировать уже имеющиеся правила. Для смены MAC-адреса в файле /etc/network/interfaces можно прописать опцию hwaddress ether XX:XX:XX:XX:XX:XX, а для надёжности, чтобы udevd не присвоил интерфейсу с этим MAC-адресом другое имя интерфейса, скопипастить одно правило udevd, прописав в него новый MAC-адрес, так что интерфейс с этими MAC-адресами будет иметь одно и то же имя.

Далее, хотел отключить прописывание маршрута по умолчанию, полученного по DHCP с помощью опции DHCLIENT_IGNORE_GATEWAY=yes. Игнорировать маршрут от DHCP? Отвечаем "да". Как бы не так. Я не сразу понял, почему оно не работает, а не работает оно из-за бага: /sbin/dhclient-script gets DHCLIENT_IGNORE_GATEWAY test backwards, который зарепорчен аж 16 февраля 2010 года, да ещё и актуальной в тот момент версией CentOS была 5.4, а я обнаружил этот баг в 5.5. Может не хотят исправлять ради сохранения совместимости с Enterprise-системой от Red Hat? Это, дескать, не баг, а фича.

Далее. Для настройки собственных маршрутов и правил маршрутизации можно создавать файлы /etc/sysconfig/network-scripts/route-* и /etc/sysconfig/network-scripts/rule-*. При чём для файла маршрутов есть два формата: устаревший и актуальный. Устаревшим считается формат, в котором можно было прописывать команды ip route, а новым - жалкие пронумерованные по порядку переменные ADDRESSn, NETMASKn, GATEWAYn. Захотел в новом формате удалить или закомментировать какой-нибудь маршрут из середины, как перед тобой встаёт выбор: либо все следующие маршруты перестанут работать, либо тебе нужно перенумеровать все оставшиеся маршруты так, чтобы их нумерация не прерывалась и шла строго по порядку.

Казалось бы - наплюй на этот новый формат, да воспользуйся вменяемым старым. Но нет! Я хотел написать нечто такое:

81.30.176.0/20 via $GATEWAY dev $DEVICE src $IPADDR table main

а в правила - нечто такое:

from $IPADDR table lunlim

думая, что переменные $GATEWAY, $IPADDR, $DEVICE должны быть определены и взяты либо из файла /etc/sysconfig/network-scripts/ifcfg-eth0, либо получены по DHCP. Нет! Этих переменных там нет!

Ну что я могу сказать? Это Enterprise, детка. Для настройки маршрутов используются графические конфигурялки, баги признают фичами, а в скриптах не допускается самодеятельность, дабы не ввести в заблуждение железобетонную логику системы. Всё как у военных - строго по уставу, не важно что квадратное приходится катать, а круглое таскать.

Может среди прочитавших эту заметку попадутся знатоки Red Hat, CentOS и Fedora? Люди, будьте добры, подскажите, можно ли сделать то, что я хочу, какими-нибудь простыми средствами?

Видимо придётся воспользоваться для настройки маршрутов всё теми-же нестандартными скриптами dhcp-клиента и скриптами /etc/ppp/ip-up.local и /etc/ppp/ip-down.loclal.

Источники:
1. Interface Configuration Files
2. Files in /etc/sysconfig
3. Как избежать неправильной нумерации сетевых карт в системах Red Hat Enterprise Linux с несколькими сетевыми интерфейсами?
4. Как настроить дополнительные маршруты в Red Hat Enterprise Linux?
5. Настройка сети в Linux через конфиг-файлы, ч.1

Дополнение от 30 мая 2010.

При попытке настроить нестандартный скрипт dhclient наступил на selinux, ударивший меня в лоб: он запрещал dhclient'у обращаться к каким-то левым, по мнению selinux, файлам. Разбираться с политиками selinux я не стал и просто отключил его. dhclient после этого сработал нормально. Прописал все настройки pptp, скрипты для добавления и удаления маршрутов. Попытался поднять соединение и обломился: про pptp-клиент я-то забыл. Ну, думаю, сейчас из репов поставлю и всё нормально. Поискал в репах, а pptp-клиента нет! Вот чёрт, опять Enterprise...

Резервная копия настроек сервера

Всё написанное ниже ни в коем случае не стоит воспринимать как руководство к действию, это лишь информация к размышлению.

Для резервного копирования настроек сервера можно использовать простенький скрипт, ежедневно отправляющий на почтовый ящик резервную копию настроек сервера (для отправки используется пакет biabam). Главное достоинство таких резервных копий - их малый объём, а процесса резервного копирования - очень высокая скорость. Сам скрипт может быть, например, таким:

#!/bin/sh

DATE=`date "+%Y-%m-%d"`

dpkg --get-selections > /root/backups/dpkg.list
mysqldump -u root --password=password --all-databases > /root/backups/mysql.sql

tar -cjvf /root/backup-$DATE.tbz --files-from=- << END
/etc//root/bin/
/home/stupin/bin/
/usr/local/bin/
/var/cache/bind/
/var/spool/cron/crontabs/
/root/backups/dpkg.list
/root/backups/mysql.sql
END
rm /root/backups/dpkg.list /root/backups/mysql.sql

echo "This is a Backup of your Debian Server!!! Keep this!" |\
  biabam /root/backup-`date "+%Y-%m-%d"`.tbz \
    -s "Daily backup Debian Server Configs: $DATE" stupin@mydomain.ru
rm /root/backup-$DATE.tbz

Будьте осторожны, т.к. злоумышленник, получивший доступ к этому сообщению, фактически получает полный доступ к серверу.

Файлик dpkg.list позволяет быстро установить все необходимые пакеты (перед этим лучше сначала перенести учётные записи).

# dpkg --set-selections < dpkg.list
# apt-get dselect-upgrade

Файлик mysql.sql позволяет быстро восстановить состояние БД mysql:

$ mysql -u root --password=password < mysql.sql

Что делать с остальными файлами - я думаю вы догадаетесь сами. Можно, например, сделать rsync нужных каталогов:

$ rsync /root/backup/var/cache/bind/ /var/cache/bind/

Можно сделать rsync каталога /etc/, но тут стоит соблюдать осторожность. Если восстановление происходит на другом оборудовании, то как минимум не стоит бездумно копировать /etc/fstab и /etc/udev/. Если перенос осуществляется ещё и на другую систему, то стоит подумать также о том, можно ли безболезненно скопировать /etc/passwd и /etc/shadow.

Переименование фотографий по EXIF-тегам

В августе-сентябре прошлого года я ездил в отпуск в компании из пяти человек. На всю компанию было два цифровых фотоаппарата. Отдыхали в другом часовом поясе и в середине отпуска мне приспичило выставить на своём фотоаппарате второе время. По приезду из отпуска мы обменялись фотографиями. Я слил все фотографии в один каталог, попутно переименовав их в соответствии со временем из EXIF-тегов.

Время на фотоаппаратах несколько различалось в начале поездки, поэтому итоговые фотографии были слегка перемешаны, к чему я был готов. Но вот что было неожиданным, так это то, что функция двойного времени на моём фотоаппарате не прописывала оба времени в снимок. Если задано одно время, то в EXIF-теги прописывалась информация о первом времени, а если заданы оба времени, то в EXIF-теги прописывалась информация из второго времени. Поэтому кроме небольшого перемешивания в начале, с некоторого момента фотографии с разных фотоаппаратов перемешались с разницей в 2 часа.

Для начала я решил всё вернуть на место и разделить фотографии по фотоаппаратам. Один из фотоаппаратов прописывал в EXIF-теги название модели "Canon PowerShot A560", поэтому я выделил с помощью grep и xargs все фотографии с этого фотоаппарата в отдельный каталог:

$ mkdir canon
$ grep -Ul "Canon PowerShot A560" | xargs -n1 -I'{}' mv '{}' canon/

Оставшиеся фотографии были с первого фотоаппарата и я поместил их в другой каталог под именем olympus.

Далее, просматривая фотографии, я сначала нашёл тот момент, когда я прописал второе время. А затем нашёл два практически одинаковых снимка, сделанных с разных фотоаппаратов, но в разных ракурсах. Так я узнал разницу в синхронизации часов - она составляла 36 секунд.

Теперь о главном. В результате поиска инструмента, который бы мог перевести время в EXIF-тегах, я нашёл утилиту exiftool. Оказалось, что эта утилита не только умеет менять время в EXIF-тегах, но и умеет переименовывать фотографии в соответствии с тегами. Она также поддерживает редактирование не только EXIF-информации из JPEG-файлов, но и редактирование тегов музыкальных файлов, например MP3. Подробнее об утилите можно прочитать здесь: http://www.sno.phy.queensu.ca/~phil/exiftool/. Я же остановлюсь на тех полезных функциях, которые мне пригодились именно для решения моих проблем: корректировка времени в EXIF-тегах и переименование.

Для начала поставим пакет с утилитой:

# aptitude install libimage-exiftool-perl

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

$ exiftool "-AllDates-=0:0:0 0:0:36" olympus/moscow-time/
$ exiftool "-AllDates-=0:0:0 0:0:36" olympus/ufa-time/

Потом я ещё раз скорректировал время (ликвидировав разницу в часовых поясах между снимками):

$ exiftool "-AllDates+=0:0:0 2:0:0" olympus/moscow-time/

Знак плюс или минус говорит о том, нужно ли прибавить разницу к показаниям часов или отнять её. Следующие шесть цифр, разделённых двоеточиями и пробелами, указывают разницу в годах, месяцах, днях, часах, минутах и секундах.

И так, теперь время во всех EXIF-тегах фотоснимков синхронизировано и нужно их переименовать. Раньше я это делал с помощью пакета exifprobe, в соответствии с этой статьёй: Цифровые фотографии. Наводим порядок. Однако exiftool оказался способен заменить эту статью одной строчкой:

$ exiftool -r -d %Y%m%d-%H%M%S%%-c.jpg "-filename<DateTimeOriginal" .

Опция -r означает, что фотографии нужно искать и в подкаталогах указанного каталога - рекурсивно.

Строка %Y%m%d кодирует 4 цифры года, две цифры месяца, две цифры дня. Строка %H%M%S кодирует две цифры часов в 24-часовом формате, две цифры минут, две цифры секунд. Строка %%-c используется при наличии нескольких файлов с одинаковым именем, при повторах она добавляет знак минус и номер файла. Строка .jpg указывает расширение файла.

Теперь все фотографии синхронизированы по времени, переименованы в соответствии с датой и временем, одновременно сделанные фотографии снабжены номером.