Closed
Bug 1018202
Opened 12 years ago
Closed 11 years ago
can't access cvs anymore
Categories
(Developer Services :: General, task)
Developer Services
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: fubar)
Details
I tried to checkout a CVS module yesterday and found that I was getting rejected due to ssh:
➜ master cvs co -d aus mozilla/webtools/aus
Permission denied (publickey,gssapi-with-mic).
cvs [checkout aborted]: end of file from server (consult above messages if any)
I'm not 100% sure, but I _think_ this is related to my ssh key change from bug 995951.
Filing as critical, because it impacts my ability to perform emergency throttling or other update changes.
Updated•12 years ago
|
Assignee: server-ops → pdang
Updated•12 years ago
|
Assignee: pdang → server-ops
Component: Server Operations: Account Requests → Server Operations
QA Contact: moconnor → shyam
Updated•12 years ago
|
Assignee: server-ops → server-ops-webops
Component: Server Operations → WebOps: Source Control
Product: mozilla.org → Infrastructure & Operations
QA Contact: shyam → nmaul
Updated•12 years ago
|
Assignee: server-ops-webops → nmaul
Comment 1•12 years ago
|
||
Hal volunteered to manage this sort of thing manually for now... I've given him access to the CVS nodes so he can take care of it.
Hal, the nodes are cvs1.dmz.scl3.mozilla.com and cvs2.dmz.scl3.mozilla.com. Your user 'hwine' should be able to SSH in and use sudo.
Assignee: nmaul → hwine
Flags: needinfo?(hwine)
bhearsum now has access to cvs1 (the current primary).
As soon as hwine gets access to cvs2, he'll fix that as well.
Flags: needinfo?(hwine) → needinfo?(nmaul)
Jake - I still don't have access to 'cvs2' -- please assign back to me when you've got that done, and I'll finish up:
$ ssh -l hwine cvs2.dmz.scl3.mozilla.com
Permission denied (publickey).
Assignee: hwine → server-ops-webops
Severity: critical → normal
| Assignee | ||
Comment 4•11 years ago
|
||
cvs2 is noticeably behind cvs1 as far as system pkgs/updates go; the pam configuration, in particular, is whack thus causing hal to not be able to access his account afaict. rather than going down the rat hole of updating them, I've given him access via root, as we've done with hg hosts.
Assignee: server-ops-webops → klibby
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Updated•11 years ago
|
Component: WebOps: Source Control → General
Product: Infrastructure & Operations → Developer Services
You need to log in
before you can comment on or make changes to this bug.
Description
•