[#BAM-2386] Perforce not connecting when running Bamboo as a service

Bamboo

Perforce not connecting when running Bamboo as a service

Created: 18/Mar/08 06:55 PM Updated: 19/Mar/08 05:38 PM

Component/s:

Repository (Perforce)

Affects Version/s:

2.0 beta 5

Fix Version/s:

2.0 beta 6

Time Tracking:

Not Specified

Participants:	Brydie McCoy [Atlassian] and Jason Davis
Since last comment:	42 weeks, 1 day ago
Company:	atlassian.com (Find related issues)
Number of comments:	2
Internal Priority:	2. High
Labels:

Description

« Hide

Bamboo perforce connection seems to be behaving differently when bamboo is running as a service as opposed to running in the console

All

Comments

Work Log

Change History

Sort Order:

[ Permlink | « Hide ]

Jason Davis added a comment - 19/Mar/08 09:05 AM

In reproducing this issue - I actually took a look the logs, which I should have done in the first place.

I believe I understand what might be the problem.

When starting Bamboo as a Windows Service and then creating the plan, when Bamboo performs it's initial connection to Perforce, the app is running p4 commands under the context of the SYSTEM account, which is the default startup account of the Windows Service.

INFO | jvm 1 | 2008/03/19 08:41:38 | 2008-03-19 08:41:38,018 INFO [btpool0-1] [CmdLineExecutor] Executing: C:\Program Files\Perforce\p4.exe users
INFO | jvm 1 | 2008/03/19 08:41:38 | 2008-03-19 08:41:38,058 DEBUG [btpool0-1] [Depot] Perforce Command Output:
INFO | jvm 1 | 2008/03/19 08:41:38 | Access for user 'SYSTEM' has not been enabled by 'p4 protect'.
INFO | jvm 1 | 2008/03/19 08:41:38 |
INFO | jvm 1 | 2008/03/19 08:41:38 | 2008-03-19 08:41:38,058 ERROR [btpool0-1] [PerforceManager] com.tek42.perforce.PerforceException: Access for user 'null' has not been enabled by 'p4 protect'
INFO | jvm 1 | 2008/03/19 08:41:38 | 2008-03-19 08:41:38,318 DEBUG [btpool0-1] [AccessLogFilter] END: admin http://testbamboo:8085/build/admin/create/createBuildRepository.action 214303kb+4466kb 510ms

INFO | jvm 1 | 2008/03/19 08:45:37 |
INFO | jvm 1 | 2008/03/19 08:45:37 | 2008-03-19 08:45:37,494 INFO [btpool0-2] [CmdLineExecutor] Executing: C:\Program Files\Perforce\p4.exe workspaces
INFO | jvm 1 | 2008/03/19 08:45:37 | 2008-03-19 08:45:37,584 DEBUG [btpool0-2] [Depot] Perforce Command Output:
.... (a bunch of workspace stuff)
INFO | jvm 1 | 2008/03/19 08:45:37 |
INFO | jvm 1 | 2008/03/19 08:45:37 | 2008-03-19 08:45:37,804 INFO [btpool0-2] [CmdLineExecutor] Executing: C:\Program Files\Perforce\p4.exe files //TITANML-SEC/...
INFO | jvm 1 | 2008/03/19 08:45:37 | 2008-03-19 08:45:37,834 DEBUG [btpool0-2] [AccessLogFilter] END: admin http://testbamboo:8085/build/admin/create/createBuildRepository.action 224570kb-1125kb 729ms
INFO | jvm 1 | 2008/03/19 08:45:37 | 2008-03-19 08:45:37,844 INFO [btpool0-1] [AccessLogFilter] admin http://testbamboo:8085/build/admin/create/addDefaultsForBuilder.action 223288kb
INFO | jvm 1 | 2008/03/19 08:45:38 | 2008-03-19 08:45:38,323 DEBUG [btpool0-1] [AccessLogFilter] END: admin http://testbamboo:8085/build/admin/create/addDefaultsForBuilder.action 223288kb-3492kb 479ms

All I had to do to resolve this problem was give admin privileges to a Perforce account and then switch the user context of the service startup to the Perforce account.

I think this may have only been a possible solution, because we utilize LDAP integration with Perforce. If the service had been started with a non Perforce Windows account, it sounds like it would have failed also.

This may partly explain why the console startup could successfully make the Perforce connections. I am starting the console under my own user account, which happens to exist in Perforce.

I think if it's possible, it would be best to execute the p4 commands in the context of the username/password that is supplied for the Perforce connection in the plan setup.

I hope this is helpful.

[ Show » ]

Jason Davis added a comment - 19/Mar/08 09:05 AM In reproducing this issue - I actually took a look the logs, which I should have done in the first place.

I believe I understand what might be the problem. When starting Bamboo as a Windows Service and then creating the plan, when Bamboo performs it's initial connection to Perforce, the app is running p4 commands under the context of the SYSTEM account, which is the default startup account of the Windows Service. <Starting as Service> INFO | jvm 1 | 2008/03/19 08:41:38 | 2008-03-19 08:41:38,018 INFO [btpool0-1] [CmdLineExecutor] Executing: C:\Program Files\Perforce\p4.exe users INFO | jvm 1 | 2008/03/19 08:41:38 | 2008-03-19 08:41:38,058 DEBUG [btpool0-1] [Depot] Perforce Command Output: INFO | jvm 1 | 2008/03/19 08:41:38 | Access for user 'SYSTEM' has not been enabled by 'p4 protect'. INFO | jvm 1 | 2008/03/19 08:41:38 | INFO | jvm 1 | 2008/03/19 08:41:38 | 2008-03-19 08:41:38,058 ERROR [btpool0-1] [PerforceManager] com.tek42.perforce.PerforceException: Access for user 'null' has not been enabled by 'p4 protect' INFO | jvm 1 | 2008/03/19 08:41:38 | 2008-03-19 08:41:38,318 DEBUG [btpool0-1] [AccessLogFilter] END: admin http://testbamboo:8085/build/admin/create/createBuildRepository.action 214303kb+4466kb 510ms <Starting from Console> INFO | jvm 1 | 2008/03/19 08:45:37 | INFO | jvm 1 | 2008/03/19 08:45:37 | 2008-03-19 08:45:37,494 INFO [btpool0-2] [CmdLineExecutor] Executing: C:\Program Files\Perforce\p4.exe workspaces INFO | jvm 1 | 2008/03/19 08:45:37 | 2008-03-19 08:45:37,584 DEBUG [btpool0-2] [Depot] Perforce Command Output: .... (a bunch of workspace stuff) INFO | jvm 1 | 2008/03/19 08:45:37 | INFO | jvm 1 | 2008/03/19 08:45:37 | 2008-03-19 08:45:37,804 INFO [btpool0-2] [CmdLineExecutor] Executing: C:\Program Files\Perforce\p4.exe files //TITANML-SEC/... INFO | jvm 1 | 2008/03/19 08:45:37 | 2008-03-19 08:45:37,834 DEBUG [btpool0-2] [AccessLogFilter] END: admin http://testbamboo:8085/build/admin/create/createBuildRepository.action 224570kb-1125kb 729ms INFO | jvm 1 | 2008/03/19 08:45:37 | 2008-03-19 08:45:37,844 INFO [btpool0-1] [AccessLogFilter] admin http://testbamboo:8085/build/admin/create/addDefaultsForBuilder.action 223288kb INFO | jvm 1 | 2008/03/19 08:45:38 | 2008-03-19 08:45:38,323 DEBUG [btpool0-1] [AccessLogFilter] END: admin http://testbamboo:8085/build/admin/create/addDefaultsForBuilder.action 223288kb-3492kb 479ms All I had to do to resolve this problem was give admin privileges to a Perforce account and then switch the user context of the service startup to the Perforce account. I think this may have only been a possible solution, because we utilize LDAP integration with Perforce. If the service had been started with a non Perforce Windows account, it sounds like it would have failed also. This may partly explain why the console startup could successfully make the Perforce connections. I am starting the console under my own user account, which happens to exist in Perforce. I think if it's possible, it would be best to execute the p4 commands in the context of the username/password that is supplied for the Perforce connection in the plan setup. I hope this is helpful.

[ Permlink | « Hide ]

Brydie McCoy [Atlassian] added a comment - 19/Mar/08 05:37 PM

Hi Jason,

I'm glad you have it sorted out. The behaviour you were experiencing was due to your particular security setup. In Beta 5, we expected the users command to be able to execute without being logged in, it therefore did not supply the users command with the login details. and hence would try to connect with the system user (see ~~BAM-2366~~).

As we realised that this is not the case, we have changed the validation procedure for Beta 6 so this does not occur. Bamboo should use your supplied login details rather than defaulting to the system user.

Cheers,
Brydie