Установка Sun StorageTek Common Array Manager Software прервалась сообщением

SEVERE: Error: This user does not have privilege to run this software.

Штудирование показало, что для корректной установки, необходимо установить пакет ksh

yum install ksh

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

    В частности 1C:Предприятие приятно удивляет своих владельцев сообщением "Ошибка формата потока". Напрашивается законный вопрос: какого потока? и какого формата? В ходе попыток найти объяснимый ответ на эти два вопроса рождаются шаманские рецепты.

    Мне остается пополнить капилку одним рецептом. Оказывается в клиент-серверном варианте сообщение "Ошибка формата потока" может возникнуть у клиента, когда одно из приложений из набора 1С:Предприятия, выполняющихся на сервере, не имеет достаточно дискового пространства в разделе /tmp для размещения временных файлов.

    От одной мысли об этой гремучей связке пробегают по спине мурашки. Тем не менее она начинает встречаться и судя по форумам набирает потихоньку обороты. Периодически всплывают заказы на внедрение/оптимизацию работы 1C или сопряженной с ней базы данных PostgreSQL.

    Описанию процесса внедрения 1C:Предприятия на Linux-сервере посвящена статья «Установка Сервера 1С:Предприятия 8.1 на Linux-сервер (со скриншотами)», которая достаточно полно раскрывает основные вехи установки. Мы позволим себе заострить внимание на внедрении 1C:Предприятия на базе CentOS 5.4 (32 bit). 32_х битная операционная система выбрана из-за отсутствия поддержки 64 бит компанией Aladdin в драйверах HASP.

    Первый момент - установка службы samba. Четкого описания необходимости этой службы для работы 1C:Предприятия не удалось найти. Одно из предположений - задействование сервиса WINS для преобразования имен. Рекомендуем завести отдельный DNS сервер и в нем прописать соответствие или довольствоваться файлом hosts. Мы продолжим рассмотрение на примере имени сервера srv1c.local, который корректно преобразуется в IP-адрес сервера.

    Вторым этапом является установка приложений, обслуживающих защитный ключ. Для их установки необходимо скачать архивы HDD_RPM_RedHat_i386.tar.gz и hasplm_linux_8.30.tgz с сайта ftp.aladdin.com. Распакуем и установим пакеты:

tar xf HDD_RPM_RedHat_i386.tar.gz
tar xzf hasplm_linux_8.30.tgz
rpm -ivh hasplm-redhat-8.30-1.i386.rpm HDD_RPM_RedHat_i386/aksusbd-redhat-1.8.1-2.i386.rpm

    Хочу обратить внимание, что архив HDD_RPM_RedHat_i386.tar.gz является обычным архивом без gzip сжатия. Запустим службы

service hasplm start
service aksusbd start
chkconfig hasplm on
chkconfig aksusbd on

    Базовым костяком необходимых пакетов для 1C:Предприятия являются 1C_Enterprise-common и 1C_Enterprise-server. Официальная зона скачивания находится по адресу users.v8.1c.ru. Неофициальная - forum.ruboard.ru.
    Пакеты 1C_Enterprise-common и 1C_Enterprise-server включают в себя поддержку русского языка. Пакеты содержащие в своем имени nls (Native Language Support) предоставляют поддержку дополнительных языков Болгарского, Украинского, Польского и других. Мы ограничимся установкой базового набора

rpm -ivh 1C_Enterprise-common-8.1.14-72.i386.rpm 1C_Enterprise-server-8.1.14-72.i386.rpm

    До момента установки 1C:Предприятия и базы данных PostgreSQL многие рекомендуют установить системную локаль в ru_RU.utf8. Мы этого делать не рекомендуем. Более красивым решением является установка локали для конкретных приложений без изменения системных настроек. Каждое из приложений: 1C:Предприятие и PostgreSQL,— запускаются с предварительным сбросом привилегий вызовом su, что позволяет прописать экспорт переменной через пользовательский .bash_profile.

    Для 1C:Предприятия при установке регистрируется отдельный пользователь usr1cv81 с домашней директорией /home/usr1cv81. В ней 1C:Предприятие хранит все настройки. Пропишем локаль для 1C:Предприятия

cat <<'EOF' >> /home/usr1cv81/.bash_profile

LANG="ru_RU.utf-8"

export LANG
EOF

    Если до этого 1C:Предприятие запускалось, то файлы конфигурации были созданы с использованием системной локали. Необходимо удалить старые файлы конфигурации и пересоздать их сызнова

service srv1cv81 stop >/dev/null 2>&1
mv /home/usr1cv81/.1cv81 /home/usr1cv81/bkp.1cv81

    Запустим службы 1C:Предприятия

service srv1cv81 start
chkconfig srv1cv81 on

    Из пакетов для PostgreSQL потребуется установить postgresql-libs, postgresql, postgresql-server и postgresql-contrib. Сборку PostgreSQL необходимо брать исключительно от поставщика 1C. Мы использовали PostgreSQL 8.2.4 с модификациями из материалов для сборки версии СУБД PostgreSQL. Для желающих можем разместить собственную сборку и SRPM.

    Перед выполнением команды service postgresql initdb необходимо выполнить

cat <<'EOF' >> /var/lib/pgsql/.bash_profile

LANG="ru_RU.utf-8"
export LANG
EOF

    После этого выполняем service postgresql initdb. Вносим минимальные изменения в /var/lib/pgsql/data/postgresql.conf

default_with_oids = on
stats_row_level = off

    Описанных изменений достаточно для корректной работы связки 1C:Предприятие и сервера PostgreSQL. Для оптимальной работы требуется более тщательная настройка. Запускаем сервер PostgreSQL

service postgresql start
chkconfig postgresql on

    Изменяем пароль пользователю postgres

cat <<'EOF' | psql -U postgres
ALTER ROLE postgres PASSWORD 'ваш пароль';
EOF

    В качестве альтернативного варианта последнему пункту можно предложить создать отдельного пользователя с правами суперпользователя

cat <<'EOF' | psql -U postgres
CREATE ROLE 'usr1c' WITH SUPERUSER INHERIT CREATEROLE CREATEDB LOGIN PASSWORD 'ваш пароль';
EOF

    На этом описание UNIX части закачивается и повествование переходит к настройке оснастки 1C. Этот этап в полном объеме изложен в параграфе "Создание сервера предприятия" статьи «Установка Сервера 1С:Предприятия 8.1 на Linux-сервер (со скриншотами)».

Сегодня, 29 января, обнаружил еще одно руководство «Установка 1С:Предприятия 8.1 на Red Hat Enterprise Linux 5 (RHEL 5, CentOS 5)».

Ответ на этот вопрос можно найти в статье iostat and disk utilization monitoring nirvana. Вычисление параметра %util iostat производит по формуле:

( (r/s + w/s) * svctm / 1000 ms ) * 100

Говоря обывательским языком, суммарное количество записей и чтений инициированных за секунду (1000 ms) умноженное на среднее время обслуживания запроса. Именование колонок соответствует формату команды iostat -x.

В обычной ситуации достаточно указать в /etc/sysctl.conf параметры

kernel.core_uses_pid = 1
kernel.core_pattern = /var/tmp/core.%p.%e.%s
fs.suid_dumpable = 1

Выполнить

sysctl -p;
ulimit -c unlimited

Перезапустить интересуйщий нас процесс командой service и убидиться в том, что параметры успешно применились командой

cat /proc/`pgrep process_name`/limits

Как показала практика описанного набора действий бывает не всегда достаточно. В частности, если SysV скрипт использует функцию daemon(), описанную в /etc/rc.d/init.d/functions, то заданный ранее явно лимит переопределяется следющей строкой

        corelimit="ulimit -S -c ${DAEMON_COREFILE_LIMIT:-0}"

Полагаясь на ее описание, необходимо для сервисов, использующих для запуска функцию daemon(), дополнительно определять в их SysV конфигурационном файле, обычно расположенном в /etc/sysconfig, директивку

DAEMON_COREFILE_LIMIT=unlimited

Например, одним из сервисов, использующий подход с daemon(), является httpd. Согласно его init-скрипту конфигурационный файл расположен в /etc/sysconfig/httpd. Результирующий набор команд будет выглядеть

cat <<EOF >> /etc/sysconfig/httpd
DAEMON_COREFILE_LIMIT=unlimited
EOF
service httpd restart

Исчерпывающее руководство о установке CentOS с использованием встроенного в сетевую карту PXE загрузчика.

Восстановить дату последней модификации файла из базы 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-файла.

Умыкнуть новую версию IPMIView можно с официального FTP сервера компании SuperMicro ftp://ftp.supermicro.com/utility/IPMIView. Процесс установки тривиален и не будет освещен.

Однако запускаться от обычного пользователя IPMIView наотрез откажется, т.к. всем, за исключением владельца директории с требуемой версией JVM, доступ закрыт. По всей видимости, компания SuperMicro позволяет использовать свое программное обеспечение исключительно пользователю согласившемуся при установке с их соглашением. Для того, чтобы отучить глупышку от этой пагубной зависимости необходимо выполнить:

find /opt/SUPERMICRO/IPMIView/_jvm -type d -exec chmod ugo+x {} \;
find /opt/SUPERMICRO/IPMIView/_jvm/ -perm -u=x -type f -exec chmod go+x {} \;

/opt/SUPERMICRO/IPMIView - путь к установленной IPMIView.