571021 - Get read-only access to puppet-file store for SeaMonkey machines

Status: RESOLVED FIXED

(Infrastructure & Operations :: RelOps: General, task)

Description

[Robert Kaiser]

If we would have read-only access to bm-sun-xf01:/export/buildlogs/puppet-file on SeaMonkey build machines (user seabld, from community network), that would be incredibly helpful for keeping our machines on the same level as Firefox machines.
Ben has indicated that should be possible.

Comment 1

[[e-mail] (:bhearsum)]

Yep, I'm totally on board with this.

Comment 2

[matthew zeier [:mrz]]

Very very difficult to do.  There's not good way to get connectivity between the SeaMonkey hosts (completely external to RelEng infra) and the NFS store.

Easier if you rsync out on a routine basis.

Comment 3

[[e-mail] (:bhearsum)]

Where can we rsync out to? Currently, the one place we seem to have common access to is stage.mozilla.org, which probably isn't the right place for them.

Comment 4

[matthew zeier [:mrz]]

I'd 302 that question to Robert.  Not sure what he has that would make a good place to push it to.

Comment 5

[Robert Kaiser]

Right now, we don't have a good place to push to, we'd need one to be set up in some way. I'm happy if it's some places we can scp from or so.

Comment 6

[Robert Kaiser]

Could this at least be mounted in some place like stage or the community jumphost, from where our build machines would be able to scp the files when needed?

Comment 7

[Robert Kaiser]

Can bm-sun-xf01:/export/buildlogs/puppet-file be mounted read-only on stage so we can at least scp files from it?

Comment 8

[Derek Moore [:dmoore]]

Mounted on stage at /mnt/puppet-files

Comment 9

[Robert Kaiser]

verified that seabld can use them now, thanks a lot!

Comment 10

[John O'Duinn [:joduinn] (please use "needinfo?" flag)]

(In reply to comment #8)
> Mounted on stage at /mnt/puppet-files

(In reply to comment #9)
> verified that seabld can use them now, thanks a lot!

Mount point taken down because of security leak discovered in bug#635638. We need to find another way to do this which doesn't accidentally leak security sensitive puppet files.

Comment 11

[Derek Moore [:dmoore]]

Mount removed entirely as a short-term fix. Over to cshields for prioritizing the permanent resolution.

Comment 12

[Justin Wood (:Callek)]

See-Also: Bug 639856 if a single solution works for both.

I just need to be able to get relevant (necessary) files in a reasonable timeframe.

Comment 13

[Aki Sasaki (not active)]

A short term plan could be:

a) identify packages which need to be not-shared,
b) verify that the below chown/chmod won't break our own puppet/opsi usage
c) chown INTERNAL_USER [list-of-not-shared-packages]
d) chmod go-rwx [same list]
e) attempt an nfs mount somewhere
f) verify that non-INTERNAL_USER users can't access those packages
g) re-share the nfs mount

h) work on a longer term solution at our leisure

This could also apply to bug 639856.
I'm not sure I'll have time to work on this, but hope the above information is enough to go on should we decide to go this route.

Comment 14

[Aki Sasaki (not active)]

(those should be chown -R and chmod -R respectively)

Comment 15

[Aki Sasaki (not active)]

(or maybe not, depending if puppet keeps perms)

Comment 16

[Justin Wood (:Callek)]

As discussed on IRC, SeaMonkey will ask for individual files on a case-by-case basis in the short-term.

When this is fixed, that practice can cease and the effort required all around will be less.

Comment 17

[Corey Shields [:cshields]]

Pulling in zandr and amy, I'm not sure what the actual request is here between this and bug 635638..  Do you just need an rpm repo for the seamonkey machines?

Comment 18

[Corey Shields [:cshields]]

moving to relops per dustin

Comment 19

[Justin Wood (:Callek)]

(In reply to comment #17)
> Pulling in zandr and amy, I'm not sure what the actual request is here
> between this and bug 635638..  Do you just need an rpm repo for the
> seamonkey machines?

Basically this bug is about making it so SeaMonkey and our machines can get files that are used by puppet [and OPSI to a lesser extent so as not to scope-creep] without RelEng intervention.

The fact that RelEng is ok with getting us files on a case-by-case basis with individual bugs, and I'm ok with doing it that way for now, in the absense of a larger easier solution, this is a very low priority.

Comment 20

[Amy Rich [:arr] [:arich]]

(In reply to comment #10)
> (In reply to comment #8)
> > Mounted on stage at /mnt/puppet-files
> 
> (In reply to comment #9)
> > verified that seabld can use them now, thanks a lot!
> 
> Mount point taken down because of security leak discovered in bug#635638. We
> need to find another way to do this which doesn't accidentally leak security
> sensitive puppet files.

Due to the removal of the mount point, I've also removed the now-obsolete nagios check as well.

Comment 21

[Dustin J. Mitchell [:dustin] (he/him)]

This remains very low priority, and is only in my queue since at some point I hope to work on folding more of the files currently only on the puppet masters into the actual puppet manifests.

Comment 22

[Dustin J. Mitchell [:dustin] (he/him)]

I'm still working toward this, fear not.

Comment 23

[Dustin J. Mitchell [:dustin] (he/him)]

I'm going to close this as both (a) working via the bugzilla+human API (e.g., bug 702054) and (b) a benefit of the structure of the new puppet infra, and not requiring any particular action here in that regard.