Восстановить дату последней модификации файла из базы rpmdb позволяет команда:

touch -m --date="`rpm -q --qf '%{FILEMTIMES:date}' -f <filename>`" <filename>

Например, рассмотрим ситуацию

# rpm -V postgresql-server
.......T  c /var/lib/pgsql/.bash_profile
#

У файла поменялась дата модификации в связи с внесением в него временных изменений. Восстановим дату модификации на хранимую в rpmdb

# touch -m --date="`rpm -q --qf '%{FILEMTIMES:date}' -f /var/lib/pgsql/.bash_profile`" /var/lib/pgsql/.bash_profile

Проверим, что изменения имели место быть

# rpm -V postgresql-server
#

Проверка прошла успешно.

Основная часть заметки была написана в 4_ом часу утра 31 марта 2009 непосредственно в момент описываемых событий.

О том, что такое MCE и чем его закусывают мне довелось впервые столкнуться ночью 31 марта 2009. Знамение пришло в виде нескольких неисправимых ошибок на системной консоли следующего содержания (снимок экрана)

HARDWARE ERROR
CPU 5: Machine Check Exception:                     5 Bank 0: b200004000000800
RIP !INEXACT! 10:<ffffffff8006ad64> {default_idle+0x29/0x50}
TSC 1d24d355f8839d
This is not a sotware problem!
Run through mcelog --acsii to decode and contact your hardare vendor

Полагаясь на диагностику операционной системы, а именно сообщение о том, что проблема связана с железом я погрузился в поиски. Как оказалось существуют 2_а подмножества ошибок:

• исправимых (warning error);
• неисправимых (nonrecoverable, fatal exception).

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

Привлек внимание факт, что сбой произошел в «Bank 0». Согласно презентации Bank с нулевого по третий соответствуют процессорам.

Banks
 0-3 CPU internal (DC, IC, BU, LS)
 4 Northbridge: only really interesting one

С другой стороны аналогичные сообщения возникают из-за внутренней несовместимости оборудования. Например, материнская плата SuperMicro X7DB8+ и дисковый контроллер Adaptec не уживаются вместе.

Днем 31 марта 2009 рассматриваемый сервер был выведен из эксплуатации и начались процедуры тестирования. Неоценимую помощь оказал дистрибутив breakin, который позволил нагрузить систему и воспроизвести сбой. Причина была в недостатке охлаждения. При продолжительной работе в пиковых нагрузках система не справлялась с отводом тепла, что вызывало перегрев процессоров. Проблема скрывалась в аппаратной платформе SuperMicro SYS-1025W, в которую необходимо устанавливать процессоры с меньшим тепловыделением и дополнительные вентиляторы для охлаждения. После этого случая вся используемая нами линейка SYS-1025W была модернизирована описанным способом.

Заметка первоначально была начата 08 июля 2007 года, но, к сожалению, так и не получила завершения. Позволю себе опубликовать ее в незаконченном виде, возможно, кто-то подчерпнет для себя полезную информацию.

Исходные данные:

• HP ProLiant DL360 G5 (дисковый контролер HP SmartArray P400i)
• HP ProLiant DL320 G5 (дисковый контролер HP SmartArray E200)
• HP ProLiant DL320s (дисковый контролер HP SmartArray P400)
• HP ProLiant DL380 G4 (дисковый контролер HP Smart Array 6i)
• Red Hat Enterprise Linux AS 4 (Update 4)

Задача: реализация возможности просмотра/изменения в online параметров и статуса аппаратного дискового массива/контроллера
Для настройки массивов компания HP предлагает 4-е прикладных набора:

• ORCA - A simple ROM-based configuration utility
• ACU - Array Configuration Utility
• ACU CLI - Array Configuration Utility Command Line Interface
• CPQONLIN - A menu-based configuration utility specifically for servers using Novell NetWare

Детальная сравнительная таблица возможностей доступна в Руководстве Пользователя к выбранному дисковому контролеру. Мы же бегло пробежимся по их возможностям, а точнее по ограничениям.

Доступ к ORCA возможен только на начальной стадии загрузки сервера (during POST). Разумеется, в production environments это не оправданный простой сервиса. К тому же сам интерфейс достаточно ограничен в возможностях (ряд возможностей в нём просто отсутствует). Соответственно его ниша сильно ограничена первоначальной настройкой системы.
CPQONLIN существует для Novell NetWare. В связи с отсутствием в ближайшем окружении систем с NetWare можно судить лишь по описанию. По возможностям повторяет своих собратьев ACU и ACU CLI.
Основное внимание будет сконцентрировано в эпсилон окрестности ACU и ACU CLI. Обе охватывают весь функционал дисковых контроллеров на заданной платформе Red Hat Enterprise Linux.

HP ACU CLI распространяется как отдельно в виде RPM-пакета, так и в составе ProLiant Support Pack (архив, содержащий в себе актуальные на момент его выхода пакеты различных сетевых, локальных служб и описания к ним). Оба варианта доступны через раздел сайта HP Support & Drivers.

Для рассмотрения был взял актуальный на момент написания RPM-пакет hpacucli-7.80-6.linux.rpm. Для его работы потребовался дополнительный пакет compat-libstdc++-296, входящий в репозиторий дистрибутива. Его установка была произведена командой:

yum -y install compat-libstdc++-296 && rpm -Uvh /path/to/hpacucli-7.80-6.linux.rpm

Первой командой, которую мы настоятельно рекомендуем выполнить hpacucli help и hpacucli shorthand. Последняя отобразит список принятых сокращений. А обе они поведают о всех своим возможностях. Легко заметить простоту синтаксиса:

 <target> <command> [parameter=value]

Рассмотрим наиболее повседневные операции с ориентиром на последующее использование в командных скриптах. Первоначально потребуется определить расположение контроллера(ов), чтобы в последующих командах обращаться к вполне определенному устройству. Выполним команду:

[root@savecore ~]# hpacucli ctrl all show status

Smart Array 6i in Slot 0
   Controller Status: OK
   Cache Status: OK
   Battery Status: OK

[root@savecore ~]# 

Контроллер HP Smart Array 6i расположен в слоте с номером 0. Запрос информации непосредственно о данном контроллере производится явным заданием параметра slot=0:

[root@savecore ~]# hpacucli ctrl slot=0 show detail

Smart Array 6i in Slot 0
   Bus Interface: PCI
   Slot: 0
   Cache Serial Number: P75B20C9SS017I
   RAID 6 (ADG) Status: Disabled
   Controller Status: OK
   Chassis Slot: 
   Hardware Revision: Rev B
   Firmware Version: 2.36
   Rebuild Priority: Low
   Expand Priority: Low
   Surface Scan Delay: 15 sec
   Cache Board Present: True
   Cache Status: OK
   Accelerator Ratio: 50% Read / 50% Write
   Total Cache Size: 192 MB
   Battery Pack Count: 1
   Battery Status: OK
   SATA NCQ Supported: False

[root@savecore ~]# 

Поддерживаемые схемы адресации:

      [controller all|slot=#|wwn=#|chassisname="AAA"|serialnumber=#|chassisserialnumber=#|ctrlpath=#:# 

Централизованная аутентификация с использованием NIS+, LDAP, ... - замечательная штука, товарищи, если реализована со следующими оговорками:

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

Однако любое положительное начало в реальной жизни подпортит небольшая ложка дегтя - NFS. Рассмотрим ситуацию, когда LDAP используется для аутентификации shell-пользователей. В таком постановке задачи сразу назревает вопрос: "как обеспечить централизованное создание домашней директории пользователю, предположим, на десятке серверов? и как обеспечить централизованную синхронизацию информации в домашней директории между машинами?"

Наименее дешевым вариантом оказывается выбор NFS в качестве мастер хранилища и autofs в качестве средства автоматического монтирования. В этом случае пользователь заводится централизованно в каталоге LDAP и одновременно создается его домашняя директория с требуемыми правами. При подключении пользователя к машине по ssh или через getty она автоматически аутентифицирует его через LDAP и с помощью autofs монтирует соответствующую домашнюю директорию.

Все выглядит достаточно радужно, если выбросить из рассмотрения тот момент, что своими же руками мы ввели единую точку отказа - NFS. В случае сетевых проблем, проблем дисковой системы и недоступности NFS хранилища мы сразу обретаем массу незабываемых мгновений беготни с бубном вокруг ошибок возвращаемых системными вызовами при обращении к сетевому хранилищу или просто недоступностью раздела /home в случае монтирования с параметром hard.

Оглянувшись по сторонам на существующие решения можно заметить NBD. Для полноценной эксплуатации потребуется задействование кластерной файловой системы OCFS2 или GFS. И на выходе получится решение аналогичное NFS только вид сбоку.

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

Приходим к проверенному решению с использованием rsync. Файлы по прежнему хранятся на мастер-ноде, но каждая машина с некоторым интервалом забирает их к себе в /home, обеспечивая единое пространство домашних директорий с необходимыми правами.

Из неудобств для пользователей выделяются:

• файлы, хранящиеся на мастер-узле всегда будут перезатирать локальные модификации. Например, если пользователь изменил файл локально и не изменил его на мастер-узле последующий запуск rsync благополучно затрет измения;
• файлы историй, вытекающие плавно из первого пункта. Например, если на мастер-узле по каким-либо причинам остался файл истории .bash_history вся локальная история вызовов будет уходить в пустоту;
• централизованные модификации синхронизируемых файлов необходимо производить на мастер-узле.

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

Очередной этап дневника пройден. Исправлен неприятный жук в CSS, из-за которого дневник разъезжался по швам в современных браузерах (firefox 3.x, konqueror, ...). Верстальщики советовали явно указать ширину элемента <pre> через CSS, что не применимо по соображениям масштабируемости на различные разрешения экранов. Пришлось потратить в общей сумме около трех часов, чтобы найти решение, включая размещение и просмотры отзывов на weblancer.net.
Решение было найдено в явном задании table-layout для центрального элемента. Более детально решение рассмотрено на stackoverflow.com, за что ему отдельное спасибо.

Протестированные браузеры:

• Mozilla Firefox 3.0.15
• Konqueror 3.5.9
• Opera 9.27
• IE 6.0
• Epiphany 2.22.2

Для истории как это выглядело ДО и как стало ПОСЛЕ
Feedback are welcome.

    Изначально предполагал, что оформлю статью в виде стандартного XHTML, однако в последний момент перемудрил с форматированием, написал все в OpenOffice и экспортировал в PDF.
    На растерзание представляется новый опус Hardware RAID vs Linux Software RAID в схватке за симпатии PostgreSQL (PDF).
    Комментарии в ветке приветствуются.

Скрипт ориентируется на расположение конфигурационных файлов принятых в ориентированных на RedHat дистрибутивах. Пример использования:

sh configure-bonding 10.10.10.10 255.255.0.0 eth0 eth2

Запуск объединит два интерфейса eth0 и eth2 в интерфейс bond0, установит для интерфейса bond0 адрес 10.10.10.10 с сетевой маской 255.255.0.0, пропишет необходимые параметры в /etc/modprobe.conf. Сам скрипт выглядит тривиально:

#!/bin/sh

# $Id: configure-bonding 1002 2009-12-10 15:25:28Z root $

addr=$1
netmask=$2
iface1=$3
iface2=$4

if [ x"$addr" = x -o x"$netmask" = x -o x"$iface1" = x -o x"$iface2" = x ]; then
  echo "Usage: $0 address netmask iface1 iface2"
  exit 1
fi

for iface in $iface1 $iface2; do
  hwaddr=`cat /etc/sysconfig/network-scripts/ifcfg-$iface | awk -F= '/HWADDR/ { print $2 }'`
  cat <<EOF > /etc/sysconfig/network-scripts/ifcfg-$iface
DEVICE=$iface
HWADDR=$hwaddr
MASTER=bond0
SLAVE=yes
ONBOOT=yes
EOF
done

cat <<EOF > /etc/sysconfig/network-scripts/ifcfg-bond0
DEVICE=bond0
IPADDR=$addr
NETMASK=$netmask
ONBOOT=yes
EOF

cat <<EOF >> /etc/modprobe.conf
alias bond0 bonding
options bond0 mode=1 miimon=100
EOF

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

Углубимся в тематику и рассмотрим следующую вырезку из .spec файла:

%install
%{__make} DESTDIR=%{buildroot} install
#%makeinstall \
#    incdir="%{buildroot}%{_includedir}/ffmpeg" \
#    shlibdir="%{buildroot}%{_libdir}" \
#    libdir="%{buildroot}%{_libdir}"
 

Как видно макрос %makeinstall закомментирован и все последующие параметры тоже. Данная конструкция успешно собирается rpmbuild. Однако на этапе выполнения mock-сборки вылезают артефакты в виде следующих ошибок:

+ /usr/bin/make prefix=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr exec_prefix=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr bindir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr/bin sbindir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr/sbin sysconfdir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/etc datadir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr/share includedir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr/include libdir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr/lib64 libexecdir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr/libexec localstatedir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/var sharedstatedir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr/com mandir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr/share/man infodir=/var/tmp/ffmpeg-0.5-1-root-mockbuild/usr/share/info install
install -d "/usr/lib64"
install: cannot change permissions of `/usr/lib64': Operation not permitted
make: *** [install-libpostproc-static] Error 1
error: Bad exit status from /var/tmp/rpm-tmp.60290 (%install)

На каком основании скрипт полез в /usr/lib64, когда ему четко была задана переменная DESTDIR и вся установка должна была протекать в окрестности директории %{buildroot}, оставалось загадкой на протяжении нескольких часов исследования всего процесса сборки. В полном отчаянии начал просматривать весь листинг сборки rpmbuild. И заметил, что make install на выполняется дважды.

+ /usr/bin/make DESTDIR=/var/tmp/ffmpeg-0.5-1-root-root install
...[skipped]
+ /usr/bin/make prefix=/var/tmp/ffmpeg-0.5-1-root-root/usr exec_prefix=/var/tmp/ffmpeg-0.5-1-root-root/usr bindir=/var/tmp/ffmpeg-0.5-1-root-root/usr/bin sbindir=/var/tmp/ffmpeg-0.5-1-root-root/usr/sbin sysconfdir=/var/tmp/ffmpeg-0.5-1-root-root/etc datadir=/var/tmp/ffmpeg-0.5-1-root-root/usr/share includedir=/var/tmp/ffmpeg-0.5-1-root-root/usr/include libdir=/var/tmp/ffmpeg-0.5-1-root-root/usr/lib64 libexecdir=/var/tmp/ffmpeg-0.5-1-root-root/usr/libexec localstatedir=/var/tmp/ffmpeg-0.5-1-root-root/var sharedstatedir=/var/tmp/ffmpeg-0.5-1-root-root/usr/com mandir=/var/tmp/ffmpeg-0.5-1-root-root/usr/share/man infodir=/var/tmp/ffmpeg-0.5-1-root-root/usr/share/info install
 

Видно не вооруженным глазом, что второй вызов make потерял переменную DESTDIR. Более того, откуда второй вызов make install?!

Оставшийся вариант, rpmbuild создает второй вызов с неверными параметрами. Заглянув в shell-скрипт

Executing(%install): /bin/sh -e /var/tmp/rpm-tmp.78776

который создается на основе spec-файла при вызове rpmbuild, все стало на свои места. Первоначальный приведенный код с закомментированным макросом %makeinstall разворачивается в следующий псевдокод:

/usr/bin/make DESTDIR=/var/tmp/ffmpeg-0.5-1-root-root install
#
  /usr/bin/make \
        prefix=/var/tmp/ffmpeg-0.5-1-root-root/usr \
        exec_prefix=/var/tmp/ffmpeg-0.5-1-root-root/usr \
        bindir=/var/tmp/ffmpeg-0.5-1-root-root/usr/bin \
        sbindir=/var/tmp/ffmpeg-0.5-1-root-root/usr/sbin \
        sysconfdir=/var/tmp/ffmpeg-0.5-1-root-root/etc \
        datadir=/var/tmp/ffmpeg-0.5-1-root-root/usr/share \
        includedir=/var/tmp/ffmpeg-0.5-1-root-root/usr/include \
        libdir=/var/tmp/ffmpeg-0.5-1-root-root/usr/lib64 \
        libexecdir=/var/tmp/ffmpeg-0.5-1-root-root/usr/libexec \
        localstatedir=/var/tmp/ffmpeg-0.5-1-root-root/var \
        sharedstatedir=/var/tmp/ffmpeg-0.5-1-root-root/usr/com \
        mandir=/var/tmp/ffmpeg-0.5-1-root-root/usr/share/man \
        infodir=/var/tmp/ffmpeg-0.5-1-root-root/usr/share/info \
  install \
#    incdir="/var/tmp/ffmpeg-0.5-1-root-root/usr/include/ffmpeg" \
#    shlibdir="/var/tmp/ffmpeg-0.5-1-root-root/usr/lib64" \
#    libdir="/var/tmp/ffmpeg-0.5-1-root-root/usr/lib64"
 

Соответственно мы получаем два прогона make install. Причем второй вызов ошибочен.

Итого: неиспользуемые макросы подлежат удалению из строчек spec-файла.