У меня есть сценарий удара, который использует sudo
несколько раз. Существует несколько странных точек об этом все же.
Вот соответствующие биты сценария.
sudo service apache2 stop
drush sql-dump --root="$SITE_DIR" --structure-tables-key=svn --ordered-dump | grep -iv 'dump completed on' | sudo tee "$DB_DIR/${SITE_NAME}.sql" > /dev/null
sudo svn diff "$DB_DIR" | less
sudo svn commit -m "$MESSAGE" "$DB_DIR"
sudo service apache2 start
Первый пароль состоит в том, чтобы остановить апача, и он работает как ожидалось. Как упомянуто, sudo tee
не 'помнит', что я поднял полномочия, просит пароль снова и повторяет его на экран. Учитывая, что tee
все о повторении для экранирования, я играл вокруг немного с простыми сценариями, которые имеют | sudo tee
, и они все работают как ожидалось.
Править: Я изучил drush
сама команда, и это - файл удара, который называет использование PHP exec
. Это кажется, что могло бы иметь потенциал - какие-либо идеи? Вот строка от drush
.
exec php $SCRIPT_PATH --php=`which php` "$@"
Edit2: искал что-то, чтобы сделать со сценариями Ruby и столкнулся с этим сообщением о поднятых полномочиях в сценариях от serverfault.
Я могу предложить другое решение? Прекратите использовать sudo
в сценариях удара, вместо этого запускает целый скрипт с поднятыми правами.
Можно легко проверить, запущен ли скрипт как корень или нет:
if [[ $(/usr/bin/id -u) -ne 0 ]]; then
echo "$0 must be run as root"
exit 1
fi
Взятый от этого ТАК вопрос.
Можно ли перепроверить Ваш sudo
версия?
Я вижу это в текущем sudo руководстве,
-A
Обычно, если sudo потребует пароля, то он считает его из текущего терминала. Если-A (askpass) опция указан, (возможно графический), программа помощника выполнена, чтобы считать пароль пользователя и произвести пароль к стандартному выводу. Если переменная среды SUDO_ASKPASS установлена, она указывает путь к программе помощника. Иначе значение, указанное askpass опцией в sudoers (5), используется.
и,
SUDO_ASKPASS
Указывает путь к программе помощника, используемой для чтения пароля, если никакой терминал не доступен или если-A опция указана.
Не может вспомнить считавший или использовал это прежде...
От человека 8 sudo примеров:
Заставить список использований каталогов в / разместить раздел. Обратите внимание, что это выполняет команды в подоболочке, чтобы заставить CD и перенаправление файла работать.
$ sudo sh -c "cd /home ; du -s * | sort -rn > USAGE"
И я не знаю то, что "тестирует" Вас, работал с мишенью, но простым случаем:
$ sudo id | sudo tee /tmp/junk
Подсказки для двух паролей сразу и затем их обоих, борьба по входной очереди так никакая принимает пароль (и они завинчивают stty
протокол работы линии так введенные символы отражен).
Обновление: О, Вы хотели знать, почему sudo не относится к конвейеру? Поскольку оболочка должна разветвить от подпроцессов конвейера каждого, который наследовал контекст родительской оболочки. Насколько оболочка затронута, sudo
просто команда, и она выполняет свои аргументы в контексте поднятого полномочия, которое не "течет" вниз канал. Как ряд команд конвейер может быть считан как
drush sql-dump > pipe ; ( grep < pipe ; ( sudo tee file < pipe ) )
который является более точной моделью того, что происходит.
Можно также всегда смотреть на что-то простое как создание FIFO или 'канала' для вывода, который Вы хотите считать
`mkfifo -m 600 /path/to/fifo`
man mkfifo
для большего количества информации. Ваш код теперь считает что-то как:
sudo service apache2 stop
#this will be visible and you can type in your password
stty -echo
# this will now remove echoing of characters to the screen
drush sql-dump --root="$SITE_DIR" --structure-tables-key=svn --ordered-dump | grep -iv 'dump completed on' | sudo tee "$DB_DIR/${SITE_NAME}.sql" > /dev/null
# as you are again looking for visible output, i would use the fifo here
sudo svn diff "$DB_DIR" \> /path/to/fifo &
sleep 4 # or longer
tail /path/to/fifo
sudo svn commit -m "$MESSAGE" "$DB_DIR"
sudo service apache2 start
stty echo