Closed Bug 571021 Opened 12 years ago Closed 10 years ago
Get read-only access to puppet-file store for Sea
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.
Yep, I'm totally on board with this.
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.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WONTFIX
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.
I'd 302 that question to Robert. Not sure what he has that would make a good place to push it to.
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.
Assignee: server-ops → nobody
Component: Server Operations → Release Engineering
QA Contact: mrz → release
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?
Can bm-sun-xf01:/export/buildlogs/puppet-file be mounted read-only on stage so we can at least scp files from it?
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Assignee: nobody → server-ops
Component: Release Engineering → Server Operations
QA Contact: release → mrz
Mounted on stage at /mnt/puppet-files
Status: REOPENED → RESOLVED
Closed: 12 years ago → 11 years ago
Resolution: --- → FIXED
verified that seabld can use them now, thanks a lot!
Status: RESOLVED → VERIFIED
(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.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Mount removed entirely as a short-term fix. Over to cshields for prioritizing the permanent resolution.
Assignee: dmoore → cshields
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.
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.
(those should be chown -R and chmod -R respectively)
(or maybe not, depending if puppet keeps perms)
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.
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?
moving to relops per dustin
Assignee: cshields → server-ops-releng
Component: Server Operations → Server Operations: RelEng
QA Contact: mrz → zandr
(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.
(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.
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.
I'm still working toward this, fear not.
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.
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → FIXED
Component: Server Operations: RelEng → RelOps
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.