Closed
Bug 598750
Opened 14 years ago
Closed 14 years ago
Provide access to Socorro staging and production for devs
Categories
(mozilla.org Graveyard :: Server Operations, task)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: laura, Assigned: jabba)
References
Details
As discussed at the 1.8 postmortem, devs should have access to staging. The list is: laura lars ozten rsnyder rhelmer deinspanjer
Updated•14 years ago
|
Assignee: server-ops → jdow
Reporter | ||
Comment 1•14 years ago
|
||
Just expanding this to cover read access to prod as well. Jabba, can you give me an ETA on this please?
Summary: Provide access to Socorro staging for devs → Provide access to Socorro staging and production for devs
Assignee | ||
Comment 2•14 years ago
|
||
I configured pm-collector-stage1 and dm-breakpad-stage01 to use ldap configs for ssh access. This means that anyone with a posixAccount attribute (test: can you log into khan?) should be able to log into these two boxes now. Is sudo access required as well for the staging boxes? I'm currently unsure about providing access to mrapp-stage02, which is where the webapp-php lives. If that is required, it might be better to move that to a different box.
Reporter | ||
Comment 3•14 years ago
|
||
We should get access to the webapp. I assume the hesitation is because other webapps are hosted on mrapp-stage02. I'll defer to mrz here but I thought the general trend was to give access for webdevs to staging.
Comment 4•14 years ago
|
||
I was able to successfully login to both servers. Thanks!
Assignee | ||
Comment 5•14 years ago
|
||
(In reply to comment #3) > We should get access to the webapp. I assume the hesitation is because other > webapps are hosted on mrapp-stage02. I'll defer to mrz here but I thought the > general trend was to give access for webdevs to staging. That is correct. I think, though, that the general access to staging will be planned out and deployed at a later date, so I think for now I'll move the webapp to a different server.
Assignee | ||
Comment 6•14 years ago
|
||
The webapp has been moved to pm-collector-stage1. So now dm-breakpad-stage01 and pm-collector-stage1 contain the entirety of stage.
Assignee | ||
Comment 7•14 years ago
|
||
I've got users and ssh keys in puppet and pushed out to the collectors: still needed are the processor/monitor boxes and the middleware boxes. Also need ssh access opened up. Filed bug 605683 for that.
Assignee | ||
Comment 8•14 years ago
|
||
We are going to run into the same issue that we ran into for stage here for the PHP webapp. It is on shared infrastructure. Not sure how to handle access there. mrz: how should this part be handled?
Comment 9•14 years ago
|
||
Which infra is this?
Assignee | ||
Comment 10•14 years ago
|
||
mrz: This resides on the generic cluster.
Assignee | ||
Comment 11•14 years ago
|
||
Access has been granted to pm-app-collector01 - 06 ; cm-breakpad02, 03 and 04 and dm-bp-mware01. We are going to have to WONTFIX granting access to the servers that the reporter resides on.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 12•14 years ago
|
||
OK, what can we do to get better insight into the reporter? Can we get logs mirrored to a box we do have access to? (khan?)
Assignee | ||
Comment 13•14 years ago
|
||
The kohana logs, or the apache logs?
Reporter | ||
Comment 14•14 years ago
|
||
(In reply to comment #13) > The kohana logs, or the apache logs? Both?
Comment 15•14 years ago
|
||
Don't the logs on mpt-vpn://var/log/clusterlogs get you want you want?
Updated•9 years ago
|
Product: mozilla.org → mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•