Я всегда боролся с различными pathsфайлами nginxи тем, где они должны быть расположены. Как мы знаем, мы можем изменить, где мы можем припарковать иwwwкаталоги для наших web app, а также связанные с ними logфайлы.
Проблема, которую я обнаружил, заключается в том, что у меня есть bashпользовательские Rubyскрипты как для SSHвызовов, так и crontabскрипты, которым необходим доступ к различным частям этих nginxфайлов, а также запланированные сетевые копии различных файлов, не говоря уже об обновлениях этих файлов.
Я придерживался статических путей, рекомендованных установкой пакетов nginxв различных дистрибутивах, однако я часто сталкивался с permissionsпроблемами, поскольку они pathне были оптимальными с точки зрения доступности. Поэтому я исследовал различные основные linuxпути и выбрал что-то, что было разработано с учетом всего этого, при этом сохраняя хороший уровень безопасности. Я видел разные места, и теперь, когда я снова этим занимаюсь ( crontabsне работает, permissionsпроблемы с различными элементами и т. д.), я подумал, что спрошу, где все это должно быть расположено.
Мои приложения не являются стандартными statichtml-приложениями. У меня есть Rackприложение с app serverзапущенным, Gemfile, а также любые входящие загрузки и т. д.
Я оцениваю два места:
- /usr/локальныйlinuxfoundation.org
- /usr/sharelinuxfoundation.org
Однако...вот что я прочитал в справочнике /usr:
/usr — второй основной раздел файловой системы. /usr — это разделяемые данные, доступные только для чтения. Это означает, что /usr должен быть общим для различных хостов, совместимых с FHS, и в него нельзя записывать данные. Любая информация, которая относится к хосту или меняется со временем, хранится в другом месте.
Большие программные пакеты не должны использовать прямой подкаталог в иерархии /usr.
Так что я запутался. Может ли кто-нибудь порекомендовать место для файлов, доступных для чтения/записи, которые дадут мне минимум хлопот при попытке написать скрипт и cron?
решение1
"Во всех отношениях" правильное место для размещения файлов веб-сайта - /srv/www. Оттуда я обычно "разбиваю" его на каталоги, связанные с доменом.
Итак, в целом /srv/www/example.comимеем следующую структуру/подкаталоги:
publicсохраняет все общедоступные файлы, привязанные к этому домену/веб-сайтуlogsхранит все файлы журналов (будь то NGINX, PHP-FPM и т. д.), привязанные к этому доменуsessionsсохраняет сеансы пользователя, например сеансы PHP
Используете ли вы PHP-FPM или любой другой "сценарий-демон", вы хотите правильно установить разрешения, настроив параметры демона и правильно chmod/chown для файлов. Нет волшебного места, которое защитит вас от необходимостинастроить модель разрешений. ВидетьNGINX и PHP-FPM. Какие у меня должны быть права доступа?- это вполне применимо к большинству настроек веб-сайтов, независимо от PHP-FPM:
- Добавьте отдельного пользователя для каждого веб-сайта, для надлежащей изоляции, например
example - Настройте демон скрипта для запуска от имени этого пользователя.
- Сделайте пользователя вашего веб-сервера (NGINX) членом группы пользователя вашего сайта:
usermod -a -G example nginx. Это позволяет NGINX читать файлы, для которых установлено групповое разрешение на чтение, и вы можете защитить файлы, которые вы не хотите, чтобы он читал (файлы конфигурации), просто удалив бит группового разрешения изchmod
В конце концов, никогда не возникает проблем с правами доступа: все принадлежит и «работает» под одним и тем же пользователем!
решение2
Голосую за закрытие этого вопроса, поскольку он действительно неопределенный. Кроме того, вы пытаетесь обвинить свои инструменты в ситуации, когда они не являются источником проблемы. Вы, в некоторой степени, ограничены в том, что вы можете/должны делать, подсистемой MAC, а также тем, как система управления пакетами обрабатывает файлы конфигурации. Однако, поскольку вы не сказали нам, какой это дистрибутив, мы не знаем, имеет ли это значение, не говоря уже о том, чтобы иметь возможность делать предложения.
При решении этой проблемы вам следует НАЧАТЬ с создания исчерпывающих списков учетных записей пользователей, которым необходим доступ к определенным файлам (прежде чем учитывать, где эти файлы находятся), и разработки соответствующей модели разрешений.
Конечно, КРАЙНЕ маловероятно, что будет целесообразно хранить какие-либо скрипты или контент в /usr.