828685 - LDAP Bot account request for pvtbuilds access

Status: RESOLVED FIXED

(Infrastructure & Operations :: Infrastructure: Other, task)

Description

[Michael Burns [:mburns]]

WebQA needs a way to access certain b2g builds (bug 820594) from their Jenkins instance.

The builds are currently hosted at pvtbuilds, which requires LDAP access.

Per bug 823775#c4, please create an LDAP user with access to pvtbuilds, whose password will not expire. Provide :jgriffin / WebQA the credentials. Thank you.

Comment 1

[Shyam Mani [:fox2mike]]

Was this approved by releng and opsec?

Comment 2

[Guillaume Destuynder [:kang] [this account is no longer active]]

Where will the bot be hosted, and which restrictions will the LDAP account have? (ie, this account should be only able to login for this service)

Comment 3

[Justin Dow [:jabba]]

On the technical side, this account should be a minimal account in ou=logins,dc=mozilla, with the mailObject objecClass so that it has a mail address to use as a login name, and the user shall be added to the ldap group that provides access to pvtbuilds. This will have to be done via phpldapadmin.

Comment 4

[u429623]

Seems we've got two very similar discussions going on, so bringing in a piece from bug 823775 comment 7

aiui, it matters greatly which "certain b2g builds" are being accessed, so this ldap account may need to be given several different permissions depending on the build type (unagi vs others).

And, another question to be answered is whether the WebQA environment is secure enough to meet partner obligations regarding these binaries. I.e. everyone with access to webQA machines with these binaries must also be explicitly allowed access to the binaries themselves.

Comment 5

[Brian Hourigan [:digi]]

Access can be granted by IP, too. You may not need a LDAP for this if all you need to do is download.

Comment 6

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Brian Hourigan [:digi] from comment #5)
> Access can be granted by IP, too. You may not need a LDAP for this if all
> you need to do is download.

Thanks!  Static IPs have been set up/assigned for two of the boxes, over in https://bugzilla.mozilla.org/show_bug.cgi?id=829613#c2 -- does that work?

Comment 7

[Brian Hourigan [:digi]]

:stephend

Your build hosts will have automatic access to releng network resources including pvtbuilds from 10.250.48.0/22, which is the releng subnet in MV. I think the best thing to do is to move them to hax0r now and get them on the right vlan.

Comment 8

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Brian Hourigan [:digi] from comment #7)
> :stephend
> 
> Your build hosts will have automatic access to releng network resources
> including pvtbuilds from 10.250.48.0/22, which is the releng subnet in MV. I
> think the best thing to do is to move them to hax0r now and get them on the
> right vlan.

Thanks, Brian.  Our approach is actually to now try for Mountain View's 3.MDF (rather than Haxxor, since our Unagis will need access to EDGE/cell-data which Haxxor shields), and for that we've filed bug 834537.

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

Actually, Dave Hunt reminds me that only our Jenkins master needs to access/download the build, so that would be:

qa-selenium.mv.mozilla.com (10.250.1.143)

Comment 10

[Brian Hourigan [:digi]]

Done in r57108

Comment 11

[Dumitru Gherman [:dumitru]]

FWIW, qa-selenium.mv.mozilla.com gets to the SCL3 cluster via our external IP in the office - corp-240.mv.mozilla.com - so whitelisting 10.250.1.143 has no effect.

Comment 12

[:Atoll]

(In reply to Dumitru Gherman [:dumitru] from comment #11)
> FWIW, qa-selenium.mv.mozilla.com gets to the SCL3 cluster via our external
> IP in the office - corp-240.mv.mozilla.com - so whitelisting 10.250.1.143
> has no effect.

Note that we'll be removing the whitelist entry (in bug 983859) for 10.250.1.143 based on MTV1 going away and comment 11 indicating that it has no effect.

Comment 13

[:Atoll]

(In reply to Stephen Donner [:stephend] from comment #9)
> Actually, Dave Hunt reminds me that only our Jenkins master needs to
> access/download the build, so that would be:
> 
> qa-selenium.mv.mozilla.com (10.250.1.143)

I'm reopening this bug to migrate this ACL to the new Jenkins master in, presumably, MTV2. Could someone help me locate that server?

Comment 14

[Jason Crowe [:jd]]

I think this bug is misfiled, webops has no knowledge of a Jenkins server in MTV2. Unfortunately we don't know where to file it either.

Comment 15

[:Atoll]

Taking back to our queue, it looks like it's been our involvement prior.

Comment 16

[:Atoll]

Hi :stephend,

We spoke about this bug on IRC a couple weeks back. We're unsure which of 2 possible actions to take here (either? both?) and need your guidance to proceed.

(1) Grant an IP ACL to the MTV2 Jenkins master so it can access pvtbuilds without LDAP credentials.
(2) Create an LDAP user for the MTV2 Jenkins master to access pvtbuilds.

It's not clear how you would prefer we proceed, so as of right now no action has been taken. My understanding is that there MAY be work in progress on #2. Is that the case?

Comment 17

[Stephen Donner [:stephend] Not actively reading bugmail]

(In reply to Richard Soderberg [:atoll] from comment #16)
> Hi :stephend,
> 
> We spoke about this bug on IRC a couple weeks back. We're unsure which of 2
> possible actions to take here (either? both?) and need your guidance to
> proceed.
> 
> (1) Grant an IP ACL to the MTV2 Jenkins master so it can access pvtbuilds
> without LDAP credentials.
> (2) Create an LDAP user for the MTV2 Jenkins master to access pvtbuilds.
> 
> It's not clear how you would prefer we proceed, so as of right now no action
> has been taken. My understanding is that there MAY be work in progress on
> #2. Is that the case?

Sorry for the delay; Raymond's working on setting up our new B2G-specific Jenkins in SCL3, so deferring to him.

Comment 18

[raymond [:retornam] (inactive)]

(In reply to Richard Soderberg [:atoll] from comment #16)
> Hi :stephend,
> 
> We spoke about this bug on IRC a couple weeks back. We're unsure which of 2
> possible actions to take here (either? both?) and need your guidance to
> proceed.
> 
> (1) Grant an IP ACL to the MTV2 Jenkins master so it can access pvtbuilds
> without LDAP credentials.
   
 I like option one best. Dave what do you think?
 We'd like access to PVT from the following machines :

    jenkins1.qa.scl3.mozilla.com with IP 10.22.73.155
    selenium.qa.mtv2.mozilla.com with IP 10.252.73.143






> (2) Create an LDAP user for the MTV2 Jenkins master to access pvtbuilds.
> 
> It's not clear how you would prefer we proceed, so as of right now no action
> has been taken. My understanding is that there MAY be work in progress on
> #2. Is that the case?


I

Comment 19

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Our server in MTV2 is currently able to use the existing credentials (username jenkinsqa). Is there a reason these won't work for the new Jenkins master? I've also used it for the Eideticker CI without any issues. I also believe Rob Wood is using this account for endurance/AWSY tests.

If there's a way to allow access to pvtbuilds without authentication then that would certainly be preferable. If so, please also include access from the following machine:

eideticker-ci1.ateam.phx1.mozilla.com

Comment 20

[:Atoll]

My understanding was that the no-authentication setup for MTV1 was a workaround for not being able to use credentials at the time, and that we were migrating to a credentials-based setup.

It sounds like there are now valid credentials in place, being used by all the things. So unless there's a significant workflow penalty for using them, I'd like to resolve this bug.

Is that acceptable?

Comment 21

[raymond [:retornam] (inactive)]

(In reply to Richard Soderberg [:atoll] from comment #20)
> My understanding was that the no-authentication setup for MTV1 was a
> workaround for not being able to use credentials at the time, and that we
> were migrating to a credentials-based setup.
> 
> It sounds like there are now valid credentials in place, being used by all
> the things. So unless there's a significant workflow penalty for using them,
> I'd like to resolve this bug.
> 
> Is that acceptable?

I'm fine with that. I thought the jenkinsqa credential was going away that is why I chose option 1.

Dave, do you have anything to add?

Comment 22

[Dave Hunt [:davehunt] [he/him] ⌚BST]

Nope