Развертывание приложений Node через Gitolite и хук после получения

Я пытаюсь получить довольно простой процесс развертывания для приложения Node с использованием Gitolite. У меня есть установленный Gitolite, работающий на моем сервере, и я могу нормально нажимать на него.

Gitolite работает под пользователем git, и я настроил пользователя node, которого надеюсь использовать для запуска приложения Node.

Мой план состоит в том, чтобы отправить приложение Node в Gitolite, а затем использовать скрипт ловушки после получения, чтобы переместить файлы приложения в каталог, где находится приложение, в данном случае /var/local/node-apps/my-node-app/. Я создал папку приложения Node следующим образом:

sudo mkdir -p /var/local/node-apps/my-node-app
sudo chown node /var/local/node-apps/my-node-app

Проблема в том, что я новичок в Unix, и у меня нет прав на файлы / папки, и я не знаю.

/var/local/node-apps (а также /var/local/node-apps/my-node-app) принадлежит пользователю node, поэтому, когда пользователь git пытается оформить заказ в этом месте, я получаю кучу ошибок отказа в доступе. Команда, которую я использую в пост-получении:

GIT_WORK_TREE=/var/local/node-apps/my-node-app git checkout -f

И я получаю такие ошибки:

remote: error: git checkout-index: unable to create file XXXX (Permission denied)
remote: fatal: cannot create directory at 'XXXX': Permission denied

Каков наилучший способ решить эту проблему? Нужно ли предоставлять пользователю git права sudo без пароля для su в качестве пользователя node? Или это можно как-то исправить изменением прав групп и папок? Или совсем другой подход? Я потерялся!

Спасибо!


person Jed Richards    schedule 18.09.2012    source источник


Ответы (1)


Использование sudo, безусловно, сработает, у вас есть один пример в "отказано в разрешении на перехват после получения, ошибка «невозможно создать файл»», оборачивая команды git в скрипт.

Пост-получение изменено на:

sudo sh /usr/local/sbin/prgetsimpleappscom

Изменены sudoers с visudo

git ALL = (root) NOPASSWD: /bin/sh /usr/local/sbin/prgetsimpleappscom

Другим подходом может быть задание cron, поскольку пользователь node регулярно извлекает и (если есть новая фиксация) извлекает репозиторий назначения.

person VonC    schedule 18.09.2012
comment
Спасибо! В примере, на который вы ссылаетесь, парень в основном решил свою проблему, добавив в файл sudoers. Есть ли какие-либо последствия для безопасности, которые следует учитывать при его подходе? - person Jed Richards; 18.09.2012
comment
@Wintamute сценарий (упомянутый в файле suoders) должен контролироваться пользователем root (чтобы гарантировать, что его нельзя изменить, чтобы он делал что-то еще, кроме того, что он должен делать). Кроме того, у вас есть обычные плюсы и минусы использования sudo: serverfault.com/questions/140633/ - person VonC; 18.09.2012
comment
А, я вижу, имеет смысл. На самом деле он добавляет три строки к sudoers в своем примере. git ALL = (root) NOPASSWD: /usr/local/sbin/prgetsimpleappscom, git ALL = (root) NOPASSWD: /bin/sh и git ALL = (root) NOPASSWD: /bin/sh /usr/local/sbin/prgetsimpleappscom. Нужны ли все три? - person Jed Richards; 19.09.2012
comment
@Wintamute Я не тестирую напрямую, но я считаю, что они могут понадобиться, чтобы скрипт (и команды git) правильно выполнялись как sudo. - person VonC; 19.09.2012
comment
Я только что сделал быстрый тест, и все, казалось, работало только с последней строкой git ALL = (root) NOPASSWD: /bin/sh /usr/local/sbin/prgetsimpleappscom. Прав ли я, думая, что эта последняя строка ограничивает пользователя git возможностью запускать команду /bin/sh только от имени пользователя root без пароля и только с аргументом /usr/local/sbin/prgetsimpleappscom? В таком случае кажется хорошей идеей свести изменения к sudoers только к этому (с точки зрения безопасности)? - person Jed Richards; 19.09.2012
comment
@Wintamute да, ты прав. В этом случае безопаснее свести к минимуму количество авторизованных команд в sudoers. - person VonC; 19.09.2012