Closed Bug 794143 Opened 12 years ago Closed 12 years ago

Find a solution for uid 48 owned files on hgssh1/2

Categories

(Developer Services :: General, task)

All
Other
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: fox2mike, Assigned: bkero)

References

Details

So over the last few weeks, we've had people complaining of permission issues on hg.mozilla.org (when they push). On looking into the issue, we found that several files are owned by uid 48, which has never existed on the system.

Corey cracked this one :

[09:38:51] <@   fox2mike> | digi: we never had apache here dude
[09:38:55] <@   fox2mike> | so this is all super odd
[09:39:03] <       digi> | fox2mike: that is odd
[09:39:03] <@   fox2mike> | unless someone changed something on the netapp
[09:39:20] <@   fox2mike> | but the only place this is rw is on hgssh1 and 2
[09:39:44] <@   cshields> | ohhhhh
[09:39:47] <   cshields> | fox2mike
[09:39:51] <@   fox2mike> | SAY IT
[09:39:56] <@   fox2mike> | TELL ME YOU'VE SOLVED IT
[09:39:58] <@   cshields> | the hgweb nodes are r/w now, for the caching stuff
[09:40:00] <@   cshields> | so...?
[09:40:02] <@   fox2mike> | coz it's driving me nuts
[09:40:04] <@   fox2mike> | they are? 
[09:40:05] <@   cshields> | they would be apache right?
[09:40:08] <@   cshields> | yeah

So that's the problem. The mount is rw on the webheads and the directories are written to by apache.
Assignee: server-ops → server-ops-devservices
Severity: minor → normal
Component: Server Operations → Server Operations: Developer Services
QA Contact: jdow → shyam
will a filesystem acl (setfacl) solve this problem?  Then the webheads could do whatever they want. hgssh1&2 would always honor the proper permissions.
Group: infra
Ben had another solution as well, I forget what it was now.
We plan to add new l10n repositories to releases/l10n/mozilla-aurora and friends in the coming days, early next week the latest, to give that set of locales a good head start on that aurora cycle. Also hard to push out as I'll head out to vacation soon after.
Solution was to add 'user=hg group=hg' processes to wsgidaemonprocess lines in all the apache configs.  Pushing out the update now.
Seems like this is fixed, we might have some permission issues with user repos, but things should be fine, overall.
Assignee: server-ops-devservices → bkero
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Component: Server Operations: Developer Services → General
Product: mozilla.org → Developer Services
You need to log in before you can comment on or make changes to this bug.