Вопрос или проблема
У меня проблема с использованием Jenkins для создания папки на удаленном хосте.
Удаленный хост в данном случае — это стандартный EC2 сервер с Ubuntu 20.04 AMI с пользователем по умолчанию ubuntu.
Я подключаюсь к удаленному серверу с помощью пользователя ubuntu с помощью кода ниже:
sshagent(credentials : [branchConfig.SSH_CREDENTIALS_NAME]) {
sh 'ssh -o StrictHostKeyChecking=no ' + branchConfig.SSH_USER + '@' + branchConfig.DOCKER_HOST + ' "echo \"running whoami\" && whoami && echo \"running groups\" && groups && install --directory --mode 0755 --owner ' + branchConfig.SSH_USER + ' --group ' + branchConfig.SSH_USER + ' ~/importengine"'
}
Это выводит следующую ошибку:
+ ssh -o StrictHostKeyChecking=no [email protected] echo running whoami && whoami && echo running groups && groups && install --directory --mode 0755 --owner ubuntu --group ubuntu ~/importengine
Warning: Permanently added 'x.x.x.x' (ECDSA) to the list of known hosts.
running whoami
ubuntu
running groups
ubuntu docker
install: cannot change owner and permissions of ���/home/ubuntu/importengine���: Operation not permitted
Я вижу, что папка создается, но у нее следующие права:
drwxr-xr-x 2 root root 4.0K Oct 13 11:12 importengine
Если я удалю папку и выполню следующую команду (входя как ubuntu):
install --directory --mode 0755 --owner ubuntu --group ubuntu ~/importengine
…то папка создается с следующими правами:
drwxr-xr-x 2 ubuntu ubuntu 4.0K Oct 13 11:24 importengine
Вопрос
Почему папка создается с владельцем root с самого начала? В конце концов, я явно вижу, что whoami выводит ubuntu, а не root в выводе ошибки, так что папка должна создаваться от имени пользователя ubuntu.
В конечном итоге я не смог выяснить, что вызывает проблему, поэтому мне пришлось обойти ее, создав папку с файлами локально, а затем скопировав их с помощью scp, что сработало. Например:
sshagent(credentials : [SSH_CREDENTIALS_NAME]) {
// скопировать .env файл в подпапку. Нужно использовать scp из-за странной проблемы с правами.
sh 'mkdir -p ~/importengine && cp ' + ENV_FILEPATH + ' ~/importengine/.env'
sh 'scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -r ~/importengine ' + SSH_USER + '@' + DOCKER_HOST + ':~/.'
}
Примечание
Эта проблема действительно сбивала с толку меня и моих коллег. Я понимаю, что это должно быть специфично для Jenkins. Я не смог воспроизвести эту проблему, выполняя любые шаги вручную с моего Linux-устройства (например, вне Jenkins).
Ответ или решение
Проблема с разрешениями при создании папки на удаленном хосте с Jenkins
Введение
В процессе работы с Jenkins для автоматизации развертывания на удаленном сервере Ubuntu 20.04 возникла сложность, связанная с созданием папки с неправильными правами доступа. Данная проблема, описанная в ваших сообщениях, может быть связана с различными аспектами, включая конфигурацию Jenkins, настройки пользователя, использующего SSH, и даже могут влиять некоторые факторы окружения.
Основная проблема
Вы указали, что папка, создаваемая с помощью команды install, получается с владельцем root и правами доступа drwxr-xr-x 2 root root. Несмотря на то, что команда whoami возвращает ubuntu, фактический результат показывает, что права на папку и её владелец являются исключительными.
Это может происходить по нескольким причинам:
-
Суперпользы: Jenkins может работать под пользователем, который имеет привилегии суперпользователя (root), если конфигурация настроена соответствующим образом (например, через sudo). В таком случае, даже если вы подключаетесь как пользователь
ubuntu, создание директории может автоматически происходить с правами суперпользователя. -
SSH-ключи и конфигурация: Убедитесь, что SSH-ключи, используемые Jenkins для аутентификации на удаленном сервере, соответствуют пользователю
ubuntu. Неверная конфигурация SSH может привести к ошибкам прав. -
Ошибки с переменными окружения: Возможно, переменные окружения, связанные с пользователем Jenkins, не инициализируют вашу сессию как предполагается. Попробуйте удалить или изменить определённые опции, такие как
StrictHostKeyChecking.
Решения
С учетом вышеизложенных моментов, предложим несколько возможных подходов к решению проблемы:
-
Проверка пользователя Jenkins: Убедитесь, что Jenkins запускается от пользователя, который действительно имеет доступ и соответствует вашей конфигурации SSH. Это легко сделать, добавив временные команды
whoamiиecho $USERв задачу Jenkins для отладки. -
Использование sudo: Если вы предполагаете необходимость выполнения задачи от имени суперпользователя, попробуйте выполнить команды с использованием sudo (например,
sudo install --directory ...). Не забудьте настроить sudoers файл, чтобы обеспечить выполнение без запроса пароля. -
Основывайтесь на SCP: Как вы уже упомянули в альтернативном решении, используя SCP для передачи уже созданных папок вместе с файлами. Это может оказаться более безопасным и простым подходом:
sshagent(credentials : [branchConfig.SSH_CREDENTIALS_NAME]) { sh 'mkdir -p ~/importengine && cp ' + ENV_FILEPATH + ' ~/importengine/.env' sh 'scp -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -r ~/importengine ' + branchConfig.SSH_USER + '@' + branchConfig.DOCKER_HOST + ':~/.' } -
Логирование и вывод: Добавьте больше логирования к вашим командам, чтобы лучше понять, на каком этапе происходит ошибка. Например, добавьте вывод информации о текущих переменных окружения (
env), когда выполняете команды через Jenkins.
Заключение
Изучив данную проблему, мы можем подтвердить, что ошибки в создании потенциально связаны с конфигурацией Jenkins и механизмами аутентификации при работе с удаленными серверами. Обратив внимание на вышеописанные шаги и рекомендации, вы сможете более целенаправленно устранить проблему и настроить автоматизацию без лишних задержек.