Куда класть сайт?

Вы не разобрались в технологии разработки.

ага:) но благодарю за критику и во вне $HOME для начала нужно оптимально решить вопрос с удаленным доступом пользователя

В общем случае в $HOME лежит git репа в режиме bare, а публикация в /var/www производится хуком посткоммит.

Как вариант именно так, и что мешает хукам быть в $HOME/path/to/site ?

Или ты прямо в ~ положил?

Ага, прямо в хомяк.

Молодой был, глупый. 😁

Это я сейчас знаю про линк, а в те прекрасные времена я о линках слыхом не слыхивал.

Как вариант именно так, и что мешает хукам быть в $HOME/path/to/site ?

От какого пользователя будет запущен nginx, и от какого ты будешь редактировать файлы? Как будут настроены права на них?

Зачем для локальной разработки использовать системный пакет nginx, когда легкий web-сервер можно поднять средствами разработки не выходя за пределы локального workdir?

Туда куда примонтирован быстрый накопитель.

посоветую еще познать mount --bind это еще круче линка
ибо не меняет путь и можно к примеру выкладывать диры в сетевой (smb, nfs) доступ :).

От какого пользователя будет запущен nginx,

в общем случае nginx

и от какого ты будешь редактировать файлы?

homeuser

Как будут настроены права на них?

Для разработки в общем случае каталоги/файлы: 755/644. Иногда, доступ регулируется вхождением в специальные группы, связанные с правами веб сервера.

Зачем для локальной разработки использовать системный пакет nginx, когда легкий web-сервер можно поднять средствами разработки не выходя за пределы локального workdir?

• git workflow
  • remote push/hooks
• CI
• php-fpm
• nginx можно натравить для чего и куда угодно
• обновление по сути одной командой через git push

Для разработки в общем случае каталоги/файлы: 755/644

Не пойдет, потому что веб-приложение может загружать свои собственные файлы, поэтому ему нужно не только читать но и писать.

В итоге ты начнёшь ставить 777 где ни попадя, а потом с этими конфигами пойдёшь разворачивать прод.

Половина CMS из 2000-х этим страдала.

git workflow, CI..

Много хороших слов, при чём тут системный nginx неясно.

Наоборот для CI-задач например надо иметь воспроизводимую изолированную настройку веб-сервера, которую можно запустить точечно для выполнения конкретного сценария.

А не вести параллельную разработку трёх приложений под одним nginx который настроен под твою конкретную локальную систему. И потом будет «на моей машине с моим nginx всё работало»

Не пойдет, потому что веб-приложение может загружать свои собственные файлы, поэтому ему нужно не только читать но и писать.

в этой схеме и upload работает прекрасно, hint: chgrp, groups

Много хороших слов, при чём тут системный nginx неясно.

и он просто работает, посматривая в назначенный каталог

В итоге ты начнёшь ставить 777 где ни попадя, а потом с этими конфигами пойдёшь разворачивать прод.

Права на выполнение в данном случае нужны в большинстве только для каталогов и только для поиска в них. man SUID/SGID/Sticky

Половина CMS из 2000-х этим страдала.

да, тут не без проблем

Наоборот для CI-задач например надо иметь воспроизводимую изолированную настройку веб-сервера, которую можно запустить точечно для выполнения конкретного сценария.

согласен, здесь напрашиватся контейнеры, но чем не CI, когда push идет на сервер разработки из домашнего каталога, предварительно проверив локально и все это на полуавтомате?

А не вести параллельную разработку трёх приложений под одним nginx который настроен под твою конкретную локальную систему. И потом будет «на моей машине с моим nginx всё работало»

Вот поэтому CI в «полуавтомате»

include /usr/local/nginx/sites-enabled/*;

chgrp, groups

И почему же ты не включил их необходимость в свой первый ответ?

Потому что ничего «прекрасного» в этом подходе нет. Совершенно незачем мешать локальные файлы разработчика с системными файлами веб-сервера.

Вот поэтому CI в «полуавтомате»

include /usr/local/nginx/sites-enabled/*;

python -m http.server 9000 справляется с этой задачей гораздо проще, как и аналогичные утилиты на всех остальных языках.

python -m http.server 9000

darkhttpd ./

Спасибо, а то я http молуль Python юзал

Можешь привести примеры/объяснить, почему держать сайты в $HOME плохо.

Похоже что я чего-то не знаю и нужно срочно останавливать nginx.

А то у меня сейчас порядка 5 ресурсов в хомяке лежит, правда там только статика.

И пару приложений на Go, которые проксируются nginx, но они только отдают контент

И nginx под домашним юзером запускаешь? И гошные сервисы?

Неа. systemctl start nginx от рута.

Получается судя по правилам в сервисе nginx multi-user.target у меня nginx запущен от рута.

Из Go’шных сервисов у меня Gitea, но в сервисе там свой юзер указан.

Юзерские папки не пускают никого кроме юзера (700). Значит с nginx.conf колдовал - выставил там хоумюзера (у которого прав сильно больше по сравнению с юзером nginx)

Как вариант именно так, и что мешает хукам быть в $HOME/path/to/site ?

1. если разработчиков два (со своими логинами) , у кого в $HOME будет лежать сайт?

2. Как бы не забыть его там.

Получается судя по правилам в сервисе nginx multi-user.target у меня nginx запущен от рута.

ps -AF покажет

Выставил на /home/user_name/Sites права на чтение для всех. Знаю что так нельзя), объяснять не нужно, но в хомяке других данных нет.

Куда класть

Так-то не класть, а ложить.

Но вообще, зависит от цели. Обычно сайты поднимают, а ложат их враги человеков доброй воли.

никакой общепринятой стуктуры нет, каждый бесоёбит как может

положи в хомяк @ дай права на чтение через acl