Смена владельца после git post-receive

У меня есть следующая установка:

Два пользователя: пример и git

Внутри /home/git/repositories/project.git/hooks/post-receive у меня есть касса /home/example/public_html/dev

Таким образом, при каждом нажатии Git файлы проекта публикуются на http://dev.example.com.

Проблема в том, что проверка выполняется от пользователя git, поэтому все файлы внутри каталога dev принадлежат git: git, а разрешения равны 600.

Таким образом, при посещении http://dev.example.com страница отображаться не будет. так как пользователь apache не имеет к нему доступа.

Кто-то предложил сделать chown внутри хука post-receive. Ну, тогда пользователь git должен быть sudo. Поэтому я добавил пользователя git в качестве sudoer. Следующая проблема была "извините, для запуска sudo требуется tty". Поэтому я закомментировал #Default requiretty, но столкнулся со следующей проблемой.

Делать пользователя git sudoer - это не то, что я хотел (не безопасно), поэтому я вернул все в нормальное состояние.

Есть ли другие более безопасные варианты, чтобы попробовать?

Возможно, пусть хук после получения запускает php-файл внутри папки dev, и этот php-файл будет выполнять проверку?

Или я могу связать папку dev с папкой внутри /home/git так, чтобы apache мог показать их в браузере?


git githooks ownership
person user1755868    schedule 19.07.2013    source источник
comment
Будет ли достаточно, если хук после получения изменит разрешения на 644 без смены владельца?   -  person Slaven Rezic    schedule 20.07.2013
comment
Ну, вам нужно быть sudo для chmod любого файла, верно?   -  person user1755868    schedule 20.07.2013
comment
Нет, не собственные файлы.   -  person Slaven Rezic    schedule 21.07.2013
comment
Прохладный. У меня есть файлы, содержащие пароли mysql и т. д., также в папке dev. Они не перезаписываются во время оформления заказа. Так что мои разработчики могут разрабатывать и тестировать там код, не зная моих паролей. Эти файлы паролей принадлежат пользовательскому примеру. Таким образом, chmod 644 -R /home/example/public_html/dev/* вызовет некоторые ошибки в этих файлах, потому что я не их владелец. Я думаю, что моим окончательным решением будет команда chmod для файлов, принадлежащих только мне (пользователь git), и оставить файлы паролей нетронутыми.   -  person user1755868    schedule 21.07.2013

Ответы (2)


arrow_upward
6
arrow_downward

Решено.

Мой хук после получения выглядит следующим образом:

#!/bin/sh
echo "Deploying to http://dev.example.com"
GIT_WORK_TREE=/home/example/domains/example.com/public_html/dev git checkout -f
cd /home/example/domains/example.com/public_html/dev
find -type f -group 'git' -exec chmod 644 -R {} \;
find -type d -group 'git' -exec chmod 755 -R {} \;

Это будет работать до тех пор, пока нет необходимых для записи каталогов. В противном случае я должен добавить их как дополнительные строки chmod в сценарий ловушки.

person user1755868    schedule 21.07.2013

arrow_upward
-2
arrow_downward

Вы всегда должны нажимать на голый репозиторий, поэтому не возникает вопросов о разрешении.

У вас может быть хук после обновления, который «ssh (открытый ключ)» к вашему DocumentRoot и выполняет git pull. Таким образом, ваши push-уведомления будут мгновенно доступны на веб-сервере.

Хотя этот метод будет работать, но мгновенное извлечение материала в DocumentRoot может быть не очень хорошей идеей, я бы предпочел сделать это в cron, чтобы кэши веб-сервера не обновлялись с непредсказуемым интервалом.

person forvaidya    schedule 20.07.2013
comment
Я нажимаю на репо внутри gitolite. Gitolite работает под пользователем git. Таким образом, хук post-receive также принадлежит пользователю git. Касса GIT_WORK_TREE находится в другом месте. Файлы извлекаются внутри /home/example/public_html/dev, но все файлы принадлежат git:git, а не example:apache. - person user1755868; 20.07.2013