Comments 20
Какая же дичь. Ну серьёзно.
Когда мы запускаем git pull с помощью PHP, команда выполняется не из root пользователя. Поэтому Bitbucket не распознает наш SSH-ключ. Из-за этого возникает ошибка доступа, если репозиторий закрытый.
Какая прелесть.
Это не дичь, это действительно так. Попробуйте запулить из под PHP ключом рута.
Я полагаю, что автор комментария назвал "дичью" то, что вы работает с git под рутом (иначе откуда эти ожидания, что подтянется ssh ключ именно его).
Ну пусть будет не рут, а другой пользователь. От этого суть не меняется.
Вы реально не понимаете в чем суть?
PHP Запускается от того пользователя которым вы запускаете. Поэтому совершенно ОЧЕВИДНО, что ssh ключ нужно настраивать для того пользователя, под которым вы работаете. Ни рут ни что-то еще в этом контексте не должен упоминаться в принципе. Если вы не можете контролировать свои действия и понимать под каким юзером вы запускаете программы, это как бы и есть дичь. К этому и претензия.
Ваша же фраза выглядит как
я вот сижу под пользователем USER, но когда запускаю php "myscript", оно выполняется не от рута.
Дичь же?
Суть не меняется, но проект под рутом дичью быть не перестает. Прямо каким-то ЛОР-ом из дремучих нулевых повеяло.
А почему бы для сайта не сделать отдельного пользователя? Настроить чтоб nginx от него работал, и git тоже. И не надо будет так веселиться с правами.
Да, тоже можно. Но разве это не займет больше времени, чем мой вариант?
Ну у меня нет, у меня все так изначально настроено, у каждого сайта свой пользователь, даже если он один на ВПС. Так проще обновлять, зашел на сервер по ключам под этим пользователем, перешел в нужную папку и набрал git pull (ну или заходить под рутом и переключаться на нужного юзера если несколько сайтов и лень всем делать ключи и настраивать Патти). Ну и деплой по вэбхуку мне бы точно было проще настроить, только реализовать метод контроллера с нужными действиями.
Ну он и делает примерно то же самое.
Ну точнее он выясняет, под каким пользователем работает php-fpm, и дальше создает ключ для этого пользователя. В целом, система немного гибче получается. У интерактивного пользователя свой ключ, у какого-нибудь www-data — свой.
А в чем гибкость? Придется извращаться с правами на файлы чтоб обновлять. И как я помню у www-data нет домашней директории, куда он ключи сохраняет и git конфиг? Как по мне лучше отдельный пользователь, не надо так веселится с правами и конфигами. Всё настраивается под него, и удобно работать, сайт создаёт файлы под тем же пользователем (загрузка, генерация, и т.п.). Удобно редактировать кронтаб для этого пользователя и запускать консольные скрипты находясь в нужной директории нужным пользователем.
Да, вы правы.
Ну почему нет домашней директории. Для www-data ключ создается в /var/www, там и можно конфиг файл гита создать.
Когда несколько сайтов как по мне безопасней когда каждый под своим пользователем, если какой-то взломают, то хоть до других по файловой системе не доберуться. Ну и еще мелочь: на www-data нельзя переключиться sudo -u www-data -i. Особенно если много нужно сделать в файлах мне например неудобно каждый раз писать sudo -u www-data mcedit .... Но это на любителя. У меня в хозяйстве один такой сайт, так админ заказчика настоял. Радует что ковыряться на том сервере приходится раз в год.
Кстати, есть решение, чтобы переключаться на пользователя, для которого не предусмотрен логин.
Вот да. Тем более, что делается это элементарно (о чем я узнал только на старости лет): www-data добавляется в группу пользователя и домашней папочке ставится 750. Учитывая что fpm и так под юзером, получается полное разграничение.
Для это существует bitbucket pipelines, а не велосипеды через хуки
Писать скрипт который будет обновлять по хттп запросу. Играть с секурностью. Дебажить...
Или написать несколько строк пайплайна в том же битбаккете
Простой автодеплой средствами Bitbucket Webhooks и PHP