Closed Bug 523681 Opened 15 years ago Closed 15 years ago

Japanese Tattoo persona can't apply

Categories

(mozilla.org Graveyard :: Server Operations, task)

Product:
mozilla.org Graveyard
Component:
Server Operations
Type:
task
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: stephend, Assigned: oremj)

References

(
URL
)

Details

json validates. I recall that one working yesterday, while a lot of others weren't. Is that the only one?
Raw file isn't showing up. Is it present at /var/www/personas/static/1/0/7610/persona2.jpg ?
Assignee: nobody → telliott
Adding jeremy, he might know where to look.
I'm moving this to IT b/c it's probably due to the migration today.
Assignee: telliott → server-ops
Severity: major → critical
Component: getpersonas.com → Server Operations
Product: Websites → mozilla.org
QA Contact: getpersonas-com → mrz
Version: unspecified → other
Assignee: server-ops → dmoore
I can confirm that the server is sending 404 responses for files which are present on disk. We're investigating.
Actually, I suspect this has been broken for some time. The problem is caused by (among others) this AliasMatch directive in the Apache configuration: AliasMatch /([a-zA-Z-]+/)?persona(.*) /mnt/netapp/personas/server/personadetail.php$2 The regex isn't strict enough. For example, it matches against http://www.getpersonas.com/static/3/6/61136/personas.jpg and rewrites it to a useless value. Any persona which references a filename like "personas.jpg" is likely broken.
Who's responsible for maintaining these aliases? I imagine most of them can by fixed by pinning them to the beginning of the path ( ^/([a-zA-Z-]+/)?persona(.*) ), but I'm not familiar enough to be certain this is appropriate for all 25+ directives.
(In reply to comment #9) > Who's responsible for maintaining these aliases? > > I imagine most of them can by fixed by pinning them to the beginning of the > path ( ^/([a-zA-Z-]+/)?persona(.*) ), but I'm not familiar enough to be certain > this is appropriate for all 25+ directives. They've been modified by a few people over time. I agree, they can probably all be pinned to the beginning of the url. I updated all of the locally and tested. Pages work, but I don't have any personas images on my local machine to verify this fixes this bug. I say we fix that one url by pinning it to the beginning and see if it works.
There should be a static alias right at the start of the config which would override these. Pinning them looks like it should be fine.
I've pinned the regex called out in Comment #8, and it appears to have fixed all reported problems in this bug.
(In reply to comment #12) > I've pinned the regex called out in Comment #8, and it appears to have fixed > all reported problems in this bug. I can confirm/verify that; thanks, Derek.
wfm too. thanks Derek!
Stephen, this can be marked fixed, correct?
(In reply to comment #15) > Stephen, this can be marked fixed, correct? Yeah, then I'll verify it.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Verified FIXED; thanks.
Status: RESOLVED → VERIFIED
Several personas, including Japanese Tattoo are not applying. See thread on forum: http://groups.google.com/group/mozilla-labs-personas/browse_thread/thread/667373dc5f8831a8 I'm able to reproduce.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
It looks like there was a personas update last night which reverted my manual fix. We'll need to get the regex changes approved and checked in to avoid this in the future. I'll manually correct it again, at this point.
Has a bug been filed to automate this in the future?
r54546 adds the 1 change Derek made earlier. Bug 520412 was created to move the aliases to .htaccess files to avoid edits to apache configuration.
Closing this bug, further work will be tracked in bug 520412.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
Re-opening, seems like it keeps getting ovewritten. r54906 adds the ^ to prod tag.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Assignee: dmoore → jeremy.orem+bugs
Derek added the fix to puppet, so it should no longer be overwritten.
Status: REOPENED → RESOLVED
Closed: 15 years ago → 15 years ago
Resolution: --- → FIXED
(In reply to comment #24) > Derek added the fix to puppet, so it should no longer be overwritten. Awesome, thanks!
Verified FIXED again (on prod).
Status: RESOLVED → VERIFIED
Thanks for squishing this bug once and for all!
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.