Я хочу делегировать сценарии инициализации SysV каждому пользователю.
Как и в SysV init, каждый элемент в ${HOME}/rc.d начиная с S будет запускаться при запуске сервера с start аргумент. То же самое и с выключением сервера, начиная с K и с stop аргумент.
Я сам думал о написании сценария, но, может быть, там уже есть какая-то реализация1. Таким образом, это будет сценарий в /etc/init.d/ который проходит через всех пользователей и запускает runparts как пользователь на соответствующих скриптах.
Платформа здесь представляет собой Linux (разновидность Debian), но я думаю, что решение будет достаточно переносимым между различными Unix-подобными платформами.
Дело здесь в том, чтобы пользователи могли создавать свои собственные сценарии инициализации, которые должны запускаться от их имени при загрузке системы. Как указал Дэн Карли, службы не смогут получить доступ к каким-либо системным ресурсам (привилегированным портам, системным журналам и т. Д.).
1. Таким образом, мне не нужно так много думать обо всех тонких последствиях для безопасности, таких как, например, тайм-ауты скриптов ...
Ваш вопрос в основном включает ответ ... Сценарий, который будет перебирать подкаталог каждого домашнего пользователя в поисках исполняемых сценариев. Затем sudo -u user /export/home/user/scripts/scriptname.sh start. У вас не будет контроля над тем, что делают скрипты, поэтому вам нужно будет доверять своим пользователям.
Настаивайте на том, чтобы они написали свои сценарии, принимающие stop start restart как параметр $ 1, и что они не должны использовать какие-либо переменные среды, которые были установлены в их файлах .profile, .cshrc или .bashrc. По сути, сценарий должен быть автономным.
#!/usr/bin/bash
run_cmd {
cd /export/home
for HOMEDIR in *; do
for SCRIPT in /export/home/$HOMEDIR/scripts/*; do
if [ -x $SCRIPT ]; then
echo "$ACTION user $HOMEDIR's script $SCRIPT"
sudo -u $HOMEDIR $SCRIPT $ACTION &
fi
done
done
}
case $1 in
start) ACTION=start;
run_cmd;;
stop) ACTION=stop;
run_cmd;;
restart) ACTION=stop;
run_cmd;
sleep 60;
ACTION=start;
run_cmd;;
*) echo "$1 not recognized as valid cmd";;
esac
exit 0
Вам нужно будет настроить это для вашей среды, расположения bash / homedirs и т. Д.
Дело здесь в том, чтобы пользователи могли создавать свои собственные сценарии инициализации, которые должны запускаться от их имени при загрузке системы.
Это уже возможно в большинстве систем, используя cron утилита. Просто попросите своих пользователей сделать следующее:
crontab -e
@reboot /home/user/script argument
Больше информации: http://www.cyberciti.biz/faq/linux-execute-cron-job-after-system-reboot/
Ваше строительство похоже на кошмар :)
Просто дайте своим пользователям sudo доступ к существующим сценариям инициализации по мере необходимости.
Я не совсем уверен в том, чего вы хотите достичь, но для меня это звучит немного похоже на .profile и .bash_logout, которые выполняются, когда пользователь запускает оболочку или выходит из оболочки.
Разница с вашим решением заключается в том, что сценарии запускаются при входе пользователя в систему или запуске новой оболочки, а не при запуске компьютера. Но я должен признать, что мне было бы неудобно позволять пользователям запускать скрипты при запуске ...
Я был бы склонен запретить сценарии и ввести в действие очень строгий короткий список стандартных сценариев и команд, на которые пользователь может ссылаться в простом файле списка, который можно легко проверить во время загрузки. Стандартные сценарии будут храниться в общем месте без прав пользователя на запись. В файле списка будут указаны имя сценария или команды и любые требуемые аргументы. Один из этих распространенных сценариев предоставит пользователю возможность остановки / запуска / перезапуска, если это необходимо после входа в систему.
Причина всей этой паранойи частично связана с безопасностью, но больше с контролем над тем, что происходит во время запуска. Я имею в виду, можете ли вы представить себе, что это был бы за кошмар, если бы ваши пользователи увлеклись запуском всевозможных вещей одновременно «просто потому, что они могут»? Не говоря уже о плохо написанных скриптах.
В противном случае, если вы сможете найти готовое решение, которое решает эти проблемы (это один из критериев, который вы упоминаете в своем вопросе), это будет правильный путь.