У меня есть веб-приложение с базой данных. У меня есть несколько служебных скриптов, которые используются для инициализации базы данных. Я хочу включить эти сценарии в пакет Debian, но они опасны, поскольку отбрасывают схему и воссоздают заново.
Поэтому я не хочу помещать эти сценарии в каталог в PATH. Куда идут сценарии такого типа в системе Debian? (Обратите внимание, что эти сценарии не являются сценариями сопровождающего пакета.)
Общим местом для исполняемых файлов, встроенных в программу, является /usr/lib/program/ .
(Старые системы Debian используют /usr/libexec/ , но это не соответствует FHS.)
Можно также изменить сценарии, например, предупредить пользователя и выход , если --force не дано в командной строке.
У Debian довольно всеобъемлющая политика, поэтому обычно стоит обратиться к ней. Я думаю, что это покрывает это,
9.1.1 Структура файловой системы
Расположение всех файлов и каталогов должно соответствовать Стандарту иерархии файловых систем (FHS), версия 2.3, с исключениями, отмеченными ниже, и за исключением случаев, когда это нарушает другие условия Политики Debian.
И проверяя FHS, мы находим,
/usr/lib: библиотеки для программирования и пакетов
Цель
/usr/lib содержит объектные файлы, библиотеки и внутренние двоичные файлы, которые не предназначены для непосредственного выполнения пользователями или сценариями оболочки. [22]
Приложения могут использовать один подкаталог в каталоге /usr/lib. Если приложение использует подкаталог, все зависящие от архитектуры данные, используемые исключительно приложением, должны быть помещены в этот подкаталог.
затем вернемся к политике Debian,
Изменено требование к объектным файлам, внутренним двоичным файлам и библиотекам, включая libc.so. *, размещаться непосредственно в /lib {, 32} и /usr /lib {, 32}, позволяя вместо этого устанавливать файлы в /lib /triplet и /usr /lib /triplet, где triplet - это значение, возвращаемое dpkg-architect -qDEB_HOST_MULTIARCH для архитектуры пакета. Пакеты не могут устанавливать файлы по какому-либо триплетному пути, отличному от того, который соответствует архитектуре этого пакета; например, пакет Architecture: amd64, содержащий 32-разрядные библиотеки x86, может не устанавливать эти библиотеки в /usr /lib /i386-linux-gnu. [69]
Приложения могут также использовать один подкаталог в /usr /lib /triplet.
Линкер / загрузчик времени выполнения, ld *, все еще должен быть доступен в существующем расположении в /lib или /lib64, так как это является частью ELF ABI для архитектуры.
Где твой установочный рут? Если бы я находился в /usr /local, я бы лично поместил их в каталог /usr /local /sbin или /usr /local /etc /scripts. Обычные пользователи не должны иметь sbin в своей переменной PATH, и определенно ничего в ней и т.д. Если она находится в /opt, то вы даже в большей безопасности, так как люди должны будут явно добавить /opt /WHATEVER /bin в свою PATH, и вы можно положить их куда угодно, кроме мусорного ведра.
Ваши сценарии даже должны иметь установленный бит выполнения? Если вы заставите людей запускать bash my_schema_loader.sh вместо того, чтобы запускать my_schema_loader.sh это предотвратит большинство непреднамеренных использований, но не сильно помешает преднамеренному использованию.
