/etc как репозиторий Mercurial

Безумная идея видавшего виды админа - а почему бы не приделать к Linux хранение истории правок конфигурации? Для воплощения в жизнь используем CentOS 6.3 и Mercurial 1.4 (он показался мне капельку проще, чем Subversion - и к тому же он хранит репозиторий и рабочую копию рядом - т.е. нам не придется создавать никаких дополнительных директорий и усложнять и без того непростую иерархию). Все последующие команды выполняются от имени суперпользователя - ибо в /etc немало файлов, недоступных для чтения другим пользователям:
# cd /etc
# hg init
# hg add *
# hg commit -m 'add /etc' -u root
Теперь во-первых убеждаемся, что изуродованная таким образом система успешно перезагрузится (хотя кому может помешать директория /etc/.hg?), потом не забудем закрыть эту директорию от обычных пользователей - все-таки наш репозиторий содержит немало такого, что им знать не положено:
# chmod 700 /etc/.hg
И проверяем, как у нас все работает:
# groupadd dummies
# useradd -d /home/dummy -g dummies -p h5CVem3AekREA dummy
# hg diff
Любуемся на изменения:

diff -r 2d2839e14225 group
--- a/group Thu Oct 04 14:08:10 2012 +0400
+++ b/group Thu Oct 04 14:24:47 2012 +0400
@@ -33,3 +33,4 @@
 nfsnobody:x:65534:
 sshd:x:74:
 cgred:x:499:
+dummies:x:500:
diff -r 2d2839e14225 gshadow
--- a/gshadow Thu Oct 04 14:08:10 2012 +0400
+++ b/gshadow Thu Oct 04 14:24:47 2012 +0400
@@ -33,3 +33,4 @@
 nfsnobody:!::
 sshd:!::
 cgred:!::
+dummies:!::
diff -r 2d2839e14225 passwd
--- a/passwd Thu Oct 04 14:08:10 2012 +0400
+++ b/passwd Thu Oct 04 14:24:47 2012 +0400
@@ -18,3 +18,4 @@
 rpcuser:x:29:29:RPC Service User:/var/lib/nfs:/sbin/nologin
 nfsnobody:x:65534:65534:Anonymous NFS User:/var/lib/nfs:/sbin/nologin
 sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin
+dummy:x:500:500::/home/dummy:/bin/bash
diff -r 2d2839e14225 shadow
--- a/shadow Thu Oct 04 14:08:10 2012 +0400
+++ b/shadow Thu Oct 04 14:24:47 2012 +0400
@@ -18,3 +18,4 @@
 rpcuser:!!:15617::::::
 nfsnobody:!!:15617::::::
 sshd:!!:15617::::::
+dummy:h5CVem3AekREA:15617:0:99999:7:::
Если все хорошо, записываем их:
# hg commit -m 'add dummy user' -u root
Еще для наглядности можно запустить встроенный веб-сервер:
# hg serve -d
И смотреть на репозиторий станет еще приятнее (только не забудьте сперва закрыть файрволом порт 8000 - ибо едва ли содержимое вашего /etc является зрелищем, достойным внимания всего интернета).

Заработавший rp_filter в CentOS 6.3

Продолжающиеся разборки со свежеустановленной CentOS 6.3 принесли новые неожиданные результаты. Примерная конфигурация такая:
Компьютер администратора имеет ip-адрес 10.1.1.101 в сети 10.1.1.0/24;
Сервер (как раз CentOS 6.3 x86_64) имеет интерфейс eth0 адресом 10.1.1.201 в той же сети и eth1 адресом 10.1.2.201 в сети 10.1.2.0/24.
Маршрутизация между этими сетями настроена, с роутера все три адреса успешно пингуются.
С компьютера администратора пингуется 10.1.1.201, но никак не пингуется 10.1.2.201.
В принципе такое поведение нельзя назвать неправильным - на интерфейсе eth1 оказывается пакет, который по всем правилам должен был прийти на eth0 - и ответа на него не посылается. Другое дело, что за прошлую жизнь админ так привык к неправильному поведению, что правильное ему кажется неудобным. Поиск по настройкам sysctl достаточно скоро находит виновного:
net.ipv4.conf.eth1.rp_filter = 1
Из документа http://linuxgazette.net/issue77/lechnyr.html как раз и явствует что:

The rp_filter can reject incoming packets if their source address doesn't match the network interface that they're arriving on, which helps to prevent IP spoofing.

Установка:
net.ipv4.conf.eth1.rp_filter = 0
приводит к тому, что желанный пинг появляется.
А напоследок - как всегда - самое смешное. В CentOS 5-ой ветки, на которых автор этих строк собственно и успел пристраститься к "неправильным" пингам, установки net.ipv4.conf.*.rp_filter по умолчанию - точно такие же, как и в 6.3. Только не вызывают они заявленного поведения. Одно из двух - либо давно объявленную фичу наконец-то заставили работать, либо где-то таится еще какая-то настройка, которая говорит системе, реагировать ей на rp_filter - или нет.

Неуловимый LANG в CentOS 6.3

При установке CentOS 6.3 с образа minimal меня удивили сообщения на русском языке (при установке был явно выбран английский). Переменная LANG действительно содержала ru_RU.UTF-8, но рекурсивный поиск в /etc и $HOME не давал ответа, каким образом подобное значение устанавливается - такой подстроки просто-напросто не было в файлах этих директорий. Проблема выглядела невероятной, пока не был произведен рекурсивный поиск слова LANG. Ответ нашелся в файле /etc/ssh/sshd_config:
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE \\
 LC_MONETARY LC_MESSAGES
(Это одна строка - переноса в оригинальном файле нет)
Т.е. получается, что установки языка передавались на сервер с моего компьютера по ssh. Действительно, если убрать LANG из этой строки, то при следующем входе в систему языком сообщений делается английский.
Следует добавить, что аналогичные настройки имеются и в клиентском файле /etc/ssh/ssh_config:
SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE \\
LC_MONETARY LC_MESSAGES
Так что, вероятно, наиболее правильным решением проблемы является как раз изменение SendEnv на том компьютере, откуда производится вход по ssh - а то вдруг другие администраторы сервера захотят видеть русский интерфейс? Хотя - с другой стороны - а что им мешает явно установить LANG в своих профайлах?
Ну а самое смешное заключается в том, что данная строка имеется в /etc/ssh/sshd_config и в более ранних версиях CentOS (например, в 5.3) - но там она почему-то никак на язык консольных сообщений не влияет. 

Хост VirtualBox на сервере CentOS без GUI

Т.к. репозитории CentOS не содержат пакетов VirtualBox, то RPM для RHEL5 берется с https://www.virtualbox.org/wiki/Linux_Downloads - каких-то невероятных зависимостей он не требует, только для установки модулей ядра необходимо иметь kernel-devel.
Ниже описывается работа с виртуальными машинами с помощью CLI утилиты VBoxManage. Подробная справка по ее опциям (на английском) имеется здесь: https://www.virtualbox.org/manual/ch08.html
Смотрим допустимые типы машин:
$ VBoxManage list ostypes
Создаем и регистрируем машину для solaris:
$ VBoxManage createvm --name sol11 --ostype OpenSolaris_64 --register --basefolder $HOME/vbox-sol11/
(последняя опция необязательна, но мне кажется, лучше всегда явно задавать, где будут храниться наши машины).
Какие ресурсы выделены машине по умолчанию, можно увидеть командой:
$ VBoxManage list -l vms
Наверняка нам захочется что-нибудь поменять. Придаем машине 2 процессора, 1 Гб памяти, системные часы, идущие по Гринвичу, и вторую сетевую карту типа bridge (первая типа nat создается автоматически):
$ VBoxManage modifyvm sol11 --memory 1024 --cpus 2 --rtcuseutc on --nic2 bridged --bridgeadapter2 eth1
(последняя опция указывает сетевой интерфейс хост-машины, к которому прицепится виртуальный интерфейс).
Если машин много, лучше смотреть настройки конкретной машины командой:
$ VBoxManage showvminfo sol11
Дисковый контроллер (в нашем случае - SCSI) добавляется командой:
$ VBoxManage storagectl sol11 --name scsi0 --add scsi
Создаем жесткий диск на 10 Гб (тип образа по умолчанию - vdi):
$ VBoxManage createhd --filename $HOME/vbox-sol11/sd0 --size 10240
и прицепляем его на контроллер:
$ VBoxManage storageattach sol11 --storagectl scsi0 --medium $HOME/vbox-sol11/sd0.vdi --port 1 --type hdd
Потом прицепляем образ загрузочного CD-ROM:
$ VBoxManage storagectl sol11 --name ide0 --add ide
(IDE контроллер пришлось создать, потому что диск типа dvddrive почему-то отказался присоединяться к SCSI)
$ VBoxManage storageattach sol11 --storagectl ide0 --medium $HOME/tmp/oi-dev-151a-text-x86.iso --device 0 --port 0 --type dvddrive
На время инсталляции придадим машине RDP-консоль:
$ VBoxManage modifyvm sol11 --vrde on --vrdeport 3389 --vrdeaddress 10.10.10.10
(две последних опции необязательны)
Для того, чтобы работал VRDP возможно придется установить Extension Pack - скачивается он там же, откуда мы брали rpm, и ставится командой:
$ VBoxManage extpack install
Теперь машину можно запускать:
$ VBoxManage startvm sol11 --type headless
Остановка машины:
$ VBoxManage controlvm sol11 poweroff
(еще возможные действия: acpipowerbutton, acpisleepbutton, pause, reset, resume, savestate)
Отцепить ненужный более cdrom можно командой:
$ VBoxManage storageattach sol11 --storagectl ide0 --port 0 --device 0 --medium none
(вместо none можно сделать emptydrive - такая операция допустима на запущенной машине).
Если понадобится проброс ssh c NAT-интерфейса на порт хост-машины (в данном случае 127.0.0.1:2222), то он делается так:

$ VBoxManage modifyvm sol11 --natpf1 sshd,tcp,127.0.0.1,2222,,22

init.d скрипт для UTM5 на Linux

Скрипт для запуска-останова порта UTM5 (версия 5.2.1) на rpm-based Linux сложно назвать работоспособным - в нем отсутсвует крвйне нужная в хозяйстве команда restart, да и stop попросту не работает - приходится вручную искать процесс и убивать его с помощью kill -9
Скрипт был переписан заново и принял такой вид:

#!/bin/sh
# chkconfig: 2345 10 80
# description: UTM Billing System Core
trap '' 1 2 3 15

ulimit -c 0

pid_file=/var/run/utm5_core.pid
utm_exec=safe_utm5_core
err_log=/netup/utm5/log/utm5_core.log
exec_dir=/netup/utm5/bin

start() {
      if [ -x $exec_dir/$utm_exec ]
      then
              echo "Starting utm5_core"
              $exec_dir/$utm_exec start &
      else
              echo $exec_dir/$utm_exec no such file
      fi
}

stop() {
      echo "Stopping utm5_core"
      pid=`ps ax -o pid,command |\
 awk '{if ($2 ~ /sh$/ && $3 ~ /safe_utm5_core$/) {print $1}}'`
      if [ -n "$pid" ]
      then
              kill -9 $pid
              sleep 5
      fi
      pid=`ps ax -o pid,command |\
 awk '{if ($2 ~ /utm5_core$/) {print $1}}'`
      if [ -n "$pid" ]
      then
              kill -9 $pid
      fi
}

case "$1" in
restart)
      stop
      start
      ;;
start)
      start
      ;;
stop)
      stop
      ;;
*)
      echo "Usage: `basename $0` {start|stop|restart}" >&2
      exit 64
      ;;
esac

Задача соответствия стандартам на init.d скрипты не ставилась - было не до эстетизма.
Тестировался на Mandriva 2009.0 и CentOS 5.2

Ручная доработка CentOS 5.2 под дисковый контроллер Fibrochannel QLogic

Собственно проблемы большой нет - CentOS 5.2 из коробки успешно загружается на Blade-сервере IBM с контроллером QLogic QMI2472 - беда в том, что длится загрузка на этом железе примерно 13 (!) минут. Больше половины этого времени занимает device-mapper, вызываемый из /etc/rc.sysinit, - он что-то пытается сделать с дисками массива, недоступными данному хосту. Никаких правильных путей его загасить я не нашел - потому грубо правил сам файл - строку:
if [ -c /dev/mapper/control ]; then
заменил на:
if [ 0 = 1 -a -c /dev/mapper/control ]; then
(или у кого какие еще варинты заведомо невыполнимого условия?) - после этого загрузка явно пошустрела.
Еще одна не очень приятная особенность CentOS - она монтирует файловые системы не по имени устройства, а по LABEL (причем, LABEL - это просто точка монтирования - /, /var и т. д.) Если у нас на контроллере есть диски для нескольких хостов - то как быть? Быть так. Метку правим такой командой:
# tune2fs -L MY-UNIQUE-LABEL /dev/sd??
и потом исправляем метку со стандартной на нашу в файлах /etc/fstab (первый столбец) и /boot/grub/menu.lst (строка kernel аргумент root=LABEL=MY-UNIQUE-LABEL).

Обновление приложений во FreeBSD и в CentOS

Старая как мир задача - что-то где-то обновилось (напр. clamav), нужно броситься вдогонку за новой версией. Что делаем? (только pls не ищите ниже очередного гундения на тему, что круче - линух или фря - это просто записки на память) Версии систем у меня такие: FreeBSD 7.0 и CentOS 5.2.

FreeBSD

• Если нет никакого еще дерева портов (это кажется не наш случай, но на всякий пожарный), то # portsnap fetch extract update;
• Если уже запускался ранее portsnap(8) (искать его следы в /var/db/portsnap - если командой portsnap не пользовались, то он будет пустой), то # portsnap fetch update;
• Если есть старое дерево портов и supfile для портов (болванку брать в /usr/share/examples/cvsup/ports-supfile), то # csup ports-supfile;

Потом:
# cd /usr/ports/dir/ourport
# make deinstall reinstall clean

Если какие-то пакеты зависят от нашего, make reinstall не обращает на это никакого внимания, толтко сообщает о несчастных в консоль (чтобы потом не забыли похоронить трупы и эвакуировать выживших ;)

Если обновляли демона - не забыть:
# /usr/local/etc/rc.d/ourdaemon restart
и смотреть в логи на результаты

CentOS

Ищем где-нибудь на просторах инета нужный src.rpm (допустимые платформы rhel или centos - желательно, fc - фопустимо, с mdv и suse лучше не связываться). Для начала можно попробовать поискать на офинциальных зеркалах - напр. тут, но там мало чего есть. Порой помогает rpmfind или сайты приложений). Допустим, нашли:

# rpm -i myprog.src.rpm
# cd /usr/src/redhat/SPECS
ищем specfile нашего приложения - и нещадно правим. Потом:
# rpmbuild -bb myprog.spec
установочный пакадж образуется в папке ../RPMS/arch (arch может быть noarch, i386, i586 и т. д.), его и ставим:
# rpm -U ../RPMS/myarch/myprog.rpm
Если это был демон, перзапускаем:
# /etc/init.d/mydaemon restart
и тоже идем читать логи ;)
Удалить srpm, если исходники уже не нужны, можно командой:
# rpmbuild --rmsource myprog.spec