Где лучше всего хранить файлы веб-сайтов совместно используемых разработчиков в иерархии linux?
Обслуживание html и php файлов
Я только начал размещать файлы для веб-сайта на моем сервере, и я не уверен, где находится подходящее место для их хранения, чтобы обеспечить доступ для нескольких пользователей.
Когда я начал хостинг сайта, я поместил файлы сайта в: /var/www/name.of.virtualhost.site/www/,
Я для удобства и простоты развертываю прямо из извлеченного репозитория, чтобы обновить кодовую базу сайта другого разработчика, или мне нужно только проверить последнюю версию файлов, чтобы все было в курсе (используя git, в этом дело). Однако в корне репозитория есть файлы, которые я предпочитаю не публиковать.
Сейчас это явно не так, потому что все, что находится ниже конечной публичной папки / www /, также доступно в домене по умолчанию или в ip, так как содержимое / var / www / content по умолчанию уже обслуживается apache. Например, /var/www/name.of.virtualhost.site/docs/site_policies.txt доступен через какой-то URL defaultsite.com/name.of.virtualhost.site/docs/site_policies.txt,
Так где же лучшее место для хранения файлов сайта в Linux?
Когда это сайт, который только я разрабатываю, я могу просто вставить их в /home/my_username/sites/name.of.virtualhost.site/ , но это не работает, когда я хочу, чтобы другие разработчики проверяли хранилище, а иногда и редактировали файлы сайта. И я использую стек LAMP, не то чтобы я ожидал, что это будет иметь значение.
5 ответов
Существует не один размер подходит для всех ответов на вашу проблему. /tmp будет доступен для всех пользователей, но это плохое место для размещения таких файлов.
Я не уверен, почему вы не используете надлежащий контроль версий, поэтому все разработчики разрабатывают в своих соответствующих средах разработки, а затем отправляют в главный репозиторий.
Если вы имеете в виду блок разработки (о котором вы не говорите), то создайте каталог в каком-то месте, например / usr / local / src, и сделайте его доступным для записи группой, к которой принадлежат все разработчики. Затем создайте сценарий развертывания, который помещает файлы, которые должны быть общедоступными, в корневой веб-каталог.
Я действительно не понимаю, что вы спрашиваете.
Файлы, обслуживаемые с сервера, должны быть /srv в соответствии с FHS. Но зачем нескольким пользователям доступ к ним?
Я предлагаю вам начать использовать контроль версий и предоставить разработчикам доступ к этому.
Затем автоматизируйте развертывание с помощью скрипта или func или capistrano.
Дайте тем, кому нужно право инициировать развертывание. Возможно использование непрерывной интеграции, чтобы это было возможно только после прохождения всех тестов.
/srv начал использоваться для таких вещей, как веб-серверы. Однако, поскольку вы используете apache, вы можете заблокировать доступ к /var/www/www.example.com на виртуальном сервере по умолчанию.
С Apache вы можете ограничить доступ к каталогу по каталогу либо по ip, либо по паролю. При необходимости вы также можете запросить соответствующий IP-адрес и пароль. Если вы не изменяете файлы из процесса на веб-сервере, каталоги и файлы не должны принадлежать или записываться идентификатором пользователя сервера apache.
/home/<user>/<repo> проверка каждого пользователя
/srv/git/<repo> для вашего основного репо (укажите Redmine/ Trac на этот)
/usr/local/bin/deploy.sh очень простой скрипт для "развертывания" из центрального репозитория git в реальной среде веб-сервера. Попытайтесь или держать это под 5 линиями bash, или заглянуть в Capistrano.
/srv/www/<vhost>/ для вашего сайта