2010-11-22 1 views
2

СинопсисНастройка пользователя процесса Хадсона на Mac + Tomcat

У меня есть Хадсон настроить на нашем Mac OS Server (Snow Leopard 10.6.5), запускаемых под управлением стандартной Tomcat (так, Tomcat 6), которая включена используя приложение Server Admin.

Я хотел бы иметь возможность запускать мои скрипты Hudson как пользователь/логин Unix, который не является именем Tomcat.

Подробности

Моя Hudson работа фристайл проект, который работает Баш сценариев, которые вызывают xcodebuild (это проект с iPhone), чтобы очистить и построить сборку.

Проблема заключается в том, что, используя эту стандартную настройку, Хадсон (насколько я вижу) работает с пользователем Unc Tomcat, который является _appserver.

Это означает, что _appserver - это пользователь, вызывающий xcodebuild и все скрипты, которые составляют задание.

Я бы предпочел, чтобы у Хадсона был свой собственный вход в систему Unix, в комплекте с домашним каталогом и т. Д. Помимо того, что он немного счастлив в отношении разрешений и т. Д. Входа, который пытается выполнить сборку, сам Xcode предпочитает пользователь должен иметь домашний каталог и журналы сборки заполнены предупреждений, таких как:

2010-11-11 17: 29: 11.729 Interface Builder Cocoa Touch Tool [58771: 1903] CFPreferences: домашний каталог пользователя на file: // localhost/var/empty/Library/Application% 20Support/iPhone% 20Simulator/Пользователь/недоступен. Домены пользователей будут неустойчивыми.

и

Не удалось открыть общие возможности GSCapabilities памяти (Нет такого файла или каталога)

Кроме того, я подозреваю, получать профили выделения ресурсов на работу, чтобы создать устройство сборки будет намного проще, если логин был стандартным входом, который может создавать цели из Xcode.

НО Я полностью не могу найти способ установить учетную запись! Похоже, именно то, что вы хотели бы сделать, но проглотил Интернет для информации безрезультатно. tomcat-users.xml чувствовал, что это может быть полезно, но, похоже, не ссылается на «настоящего» (Unix) пользователя?

Другой подход может заключаться в том, чтобы жить с Happson, являющимся _appserver, но сами скрипты выполняются как пользователь моего проекта. Это, похоже, указывает на использование sudo, но все, кажется, заблокировано. Я не могу найти способ запускать сценарий в качестве другого пользователя, даже один, который я могу заблокировать, чтобы иметь минимальный доступ к безопасности ...?

Надеюсь, вы сможете помочь людям!

ответ

1

Самый простой способ добиться того, что вы хотите (и единственный способ я знаю, как) будет:

Создать новую рабыню в Хадсон, и указать его на сервер Хадсон (ваш мастер-система также будет увеличена новый раб); войдите в систему с помощью SSH, но с учетными данными пользователя, которые вы хотите использовать для сборки (скажем, «hudson»).

Направьте свой проект на рабочую силу. Таким образом, ваша работа не зависит от Tomcat (или ее пользователя), а от входа в подчиненный.

На этапах:

1) Click on 'Build Executor Status' 
2) On the left sidebar, click on New Node 
3) Give the slave a name, click "Dumb Slave", and "OK" 
4) Number of executors = 1 
5) remote FS root = /home/<hudson_user> 
6) Launch method = UNIX SSH or JNLP 
7) If launch = SSH: host = ip address of master, 
    username = hudson, password =  hatever_password 
8) If launch = JNLP, log in as the hudson user, go to hudson and start 
    the web service from your hudson site 
9) Configure your job to use your slave (restrict where this project can be run) 
9a) Possibly, under configuration, turn off all executors on your master, 
    and use the new slave for anything you need to build. 

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

+0

Преимущество этого в том, что вам не нужно возиться с конфигурацией tomcat. – Sagar

+0

Недостатком является то, что вы добавляете довольно много накладных расходов, особенно при архивировании больших артефактов. Кроме того, журнал сборки должен быть скопирован с ведомого на главный. –

+0

Как так? Предполагая, что сборка происходит непосредственно на главном компьютере (что в данном случае), артефакт все равно должен быть скопирован из рабочей области в каталог архивов. Единственное отличие здесь заключается в том, что вместо копирования из рабочей области мастера в архив архива мастера он копируется из рабочей области подчиненного устройства - подчиненный и главный * - это одна и та же система *, поэтому никаких дополнительных накладных расходов нет. – Sagar