У меня Jenkins 1.6 работает на CentOS 7.2. У меня есть серверы Windows 2012, на которых я хочу получать сборки с сервера Jenkins. Эти серверы Windows не находятся в домене. На них установлен OpenSSH. На сервере Jenkins я вручную создал этот путь (из консоли Linux): /home/jenkins/.ssh/
Я дал папке .ssh полностью открытые права. Затем я запустил задание Jenkins, которое должно выполняться исключительно на самом сервере Linux. Это было задание Execute Shell со следующими командами:
cd /tmp/
ssh-keygen -t rsa -N "" -f great.key
mv great.key.pub /home/jenkins/.ssh/
mv great.key /home/jenkins/.ssh
Команды должны генерировать пару ключей SSH для пользователя Jenkins. Я не знаю, как войти на сервер Linux с пользователем Jenkins. Итак, я пришел к вышесказанному.
Затем я вручную сделал разрешения для каталога .ssh равным 600. Я скопировал содержимое файла .pub в файл authorized_keys на сервере Windows, в частности файл в C: \ Users \ jenkins.ssh \
И файл authorized_keys, и папка .ssh на сервере Windows имеют разрешения безопасности, при этом только группа администраторов имеет полный контроль над файлом и папкой соответственно. Затем я запустил сборку Jenkins, которая представляла собой сценарий Execute Shell. Вот три строчки:
ssh -t -t jenkins@x.x.x.x
echo "something" > foo.txt
exit
Я получаю это в выводе консоли:
... В доступе отказано, попробуйте еще раз. ... На этапе сборки «Выполнить оболочку» сборка отмечена как сбой ...
Как заставить Jenkins работать в Linux для связи с серверами Windows? Я бы предпочел не устанавливать Cygwin на серверы Windows. Есть проблемы с лицензией. На это нужно время, и я думаю, что в этом нет необходимости.
Чтобы исследовать, что происходит, используйте некоторые основные команды как в разделе exec плагина, так и в запущенном скрипте. Сначала вам нужно сравнить пути для развернутого скрипта и для рабочей папки. В моем случае путь развертывания сценария /home/jenkins/deploy и путь к команде exec /home/jenkins. Использовать dirs команда например. Также рассмотрите возможность использования абсолютных путей и / или cd команда.
Затем вы можете заметить, что сценарий, написанный в Windows, имеет окончание строки CRLF, в то время как написанный в Linux имеет только LF. Здесь интерпретатор видит в неродном скрипте лишние вещи и обрабатывает их:
Интерпретатор Linux видит лишнее \r символов перед каждым ожидаемым \n конец строки и обрабатывает их:
как дополнительные параметры в каждой команде. Это может вызвать предупреждение от команды о неожиданном аргументе.
# |normal line-end
echo "something" > foo.txt \r\n
# ^arg pipe^ target^ ^argument of target?
exit
как неизвестная команда в пустых строках
# |normal line-end
\r\n
#^unknown command
Интерпретатор Windows видит лишнее \n символов (и не вижу ожидаемых \r\n) и обрабатывает их все и следующие команды как один список аргументов для первой команды
# |>no line-end
echo "something" > foo.txt \n exit
# ^arg pipe^ target^ ^---^-arguments of target
Я использую плагин Publish Over SSH для Jenkins и инвертированную ситуацию: машина сборки (источник) запускает Windows, а машина развертывания (цель) запускает Linux (Ubuntu).