воскресенье, 30 мая 2010 г.

Недостатки инициализации сети в 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...

пятница, 21 мая 2010 г.

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

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

Для резервного копирования настроек сервера можно использовать простенький скрипт, ежедневно отправляющий на почтовый ящик резервную копию настроек сервера (для отправки используется пакет 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.