Ошибка открытия сеанса su при запуске базы данных Oracle XE

У меня есть сервер RHEL 7.2 с установленной Oracle 11g Express Edition (11.2.0). Установка Oracle создала файл с именем “oracle-xe” в /etc/init.d. Это скрипт bash, который можно использовать для ручного запуска и остановки listener и базы данных. Когда я вошел на сервер, я могу выполнить следующую команду:

dzdo /etc/init.d/oracle-xe start

и listener Oracle и база данных запускаются без проблем. Я могу войти, используя sqlplus, и выполнять команды. Я пытаюсь использовать chkconfig, чтобы oracle-xe выполнялся автоматически при запуске системы, чтобы мне не приходилось вручную запускать listener и базу данных каждый раз, когда сервер перезагружается. Сам скрипт oracle-xe достаточно длинный, но основная его часть содержит следующее:

#!/bin/bash
# chkconfig: 2345 80 05

# Подключение библиотеки функций
if [ -f /lib/lsb/init-functions ]
then
    . /lib/lsb/init-functions
elif [ -f /etc/init.d/functions ]
then
    . /etc/init.d/functions
fi

SU=/bin/su
ORACLE_OWNER=oracle
$ORACLE_HOME=/u01/app/oracle/product/11.2.0/xe
LSNR=$ORACLE_HOME/bin/lsnrctl
SQLPLUS=$ORACLE_HOME/bin/sqlplus
$STARTUP_LOG=/home/tsm/log/oracle-xe.log

echo $(date) >> $STARTUP_LOG    
$SU -s /bin/bash $ORACLE_OWNER -c "$LSNR start" >> $STARTUP_LOG 2>&1
$SU -s /bin/bash $ORACLE_OWNER -c "$SQLPLUS -s /nolog @$ORACLE_HOME/config/scripts/startdb.sql" >> $STARTUP_LOG 2>&1

Я добавил код $STARTUP_LOG и перенаправление вывода >>, чтобы выяснить, что происходит. Я добавил скрипт в chkconfig с помощью следующей команды:

cd /etc/init.d
dzdo chmod 750 oracle-xe
dzdo chkconfig --add oracle-xe
dzdo chkconfig oracle-xe on

Следующая команда выдает следующее (сокращенное) сообщение:

dzdo chkconfig --list

oracle-xe       0:off    1:off   2:on   3:on   4:on   5:on  6:off

Я перезагружаю сервер, и он создает файл журнала в /home/tsm/log/oracle-xe.log со следующим выводом:

Пт 13 янв 15:03:58 CST 2017
su: не удалось открыть сессию: Отказано в доступе
su: не удалось открыть сессию: Отказано в доступе

и как вы могли предположить, в результате этой неудачи su ни listener, ни движок базы данных не запускаются. Поскольку я вижу дату/время перезагрузки в файле журнала, я точно уверен, что скрипт выполняется при загрузке. Мне кажется, что это проблема разрешений, и что какая бы учетная запись ни использовалась для выполнения init-скриптов при старте системы, по какой-то причине не может выполнить su для $ORACLE_OWNER, однако я, как простой администратор, могу делать это без проблем с командной строки. Я думал, что код init выполняется от имени root, и, следовательно, эта команда su должна выполняться без проблемы. Я целый день искал и пробовал различные вещи, чтобы разобраться в этом, и извел все оставшиеся у меня волосы.

Сам сервер использует DirectAuthorize для предоставления прав доступа, поэтому я использую dzdo вместо sudo. Может ли это быть связано с данным вопросом?

Итак, я разобрался, в чем дело. Когда система использует DirectAuthorize, любая учетная запись, которая хочет выполнить su от имени другого пользователя, обязательно должна использовать dzdo вместо этого. Это касается даже root-аккаунта, используемого для запуска любой службы через chkconfig во время загрузки системы. Поэтому я изменил следующие строки в моем скриптовом файле oracle-xe:

$SU -s /bin/bash $ORACLE_OWNER -c "$LSNR start" >> $STARTUP_LOG 2>&1
$SU -s /bin/bash $ORACLE_OWNER -c "$SQLPLUS -s /nolog @$ORACLE_HOME/config/scripts/startdb.sql" >> $STARTUP_LOG 2>&1

на это:

dzdo -s -u $ORACLE_OWNER $LSNR start >> $STARTUP_LOG 2>&1
dzdo -s -u $ORACLE_OWNER $SQLPLUS -s /nolog @ORACLE_HOME/config/scripts/startdb.sql >> @STARTUP_LOG 2>&1

dzdo не является прямой заменой для su, так как у них разные опции и его нельзя просто вставить на место. В частности, нет опции -c для выполнения конкретной команды с dzdo. Вместо этого, команда для выполнения — это все, что появляется в конце выражения. Переключатель -s указывает на выполнение оболочки от имени целевого пользователя. После внесения этих изменений и перезагрузки, listener и экземпляр базы данных запустились от имени пользователя “oracle” без каких-либо проблем.