Closed Bug 1003148 Opened 6 years ago Closed 6 years ago

[prod-push] Push latest master to production plugins.m.o

Categories

(Infrastructure & Operations Graveyard :: WebOps: Other, task, P1, critical)

Product:
Infrastructure & Operations Graveyard
Component:
WebOps: Other
Type:
task

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: espressive, Assigned: nmaul)

References

Details

We have the go ahead to push the latest from master to production. Here is the release: https://github.com/mozilla/plugindir/releases/tag/v1.0.0

Please note some additional details in:
https://bugzilla.mozilla.org/show_bug.cgi?id=1000321#c3

Thanks!
:espressive - is this push related to today's firefox release? if not, i'd prefer to defer this push to later in the week because we're expecting higher than average usage on this service right now.
Flags: needinfo?(schalk.neethling.bugs)
(In reply to Chris Turra [:cturra] from comment #1)
> :espressive - is this push related to today's firefox release? if not, i'd
> prefer to defer this push to later in the week because we're expecting
> higher than average usage on this service right now.

Later in the week is fine, thanks Chris.
Flags: needinfo?(schalk.neethling.bugs)
Assignee: server-ops-webops → nmaul
I poked at this and momentarily broke plugins.mozilla.org. I'm trying to get it to operate in our newer directory layout, which has the code one level deeper on the filesystem.

That is, instead of:

/data/www/plugins.mozilla.org/{htdocs,application,...}

it would be:

/data/www/plugins.mozilla.org/plugindir/{htdocs,application,...}


This requires 4 path changes in the Apache config, but strangely this seemed to be insufficient by itself. More testing may be needed.
I meant to say, right now there is a nested copy installed, just so that it "should" work either way. The nested version however is the new one from github, and the outer one is the original one from SVN. Once we're done we'll simply remove the extra files corresponding to the SVN version, and all will be well.
Thanks for the update :jakem
Updated!

The problem was there are some -dist and config files that needed to have their settings set right. I simply copied over the existing ones and all is well.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
(In reply to Jake Maul [:jakem] from comment #6)
> Updated!
> 
> The problem was there are some -dist and config files that needed to have
> their settings set right. I simply copied over the existing ones and all is
> well.

Thanks Jake! One thing though, there are two end points that are called from JS on mozilla.org

The one is https://plugins.mozilla.org/pfs/v2 and the other https://plugins.mozilla.org/plugins_list.json

Now both of these should not be behind LDAP auth and should be publicly accessible. While the first one is, the second one currently prompt for LDAP credentials. Is this something that is configured on the server?
Flags: needinfo?(nmaul)
Do you mean publicly accessible, or just accessible by mozilla.org/plugincheck? (Not the same thing.)
(In reply to Laura Thomson :laura from comment #8)
> Do you mean publicly accessible, or just accessible by
> mozilla.org/plugincheck? (Not the same thing.)

publicly, that is how pfs/v2 works as well.
Any update on this? I am more than willing to assist in any way I can.
Blocks: 985968
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blocks: 1008102
Can you assist with the above?
Flags: needinfo?(gozer)
Severity: normal → critical
Priority: P2 → P1
So, I'm not sure that I can fix the issue without having the file moved to another directory location.  I do note that I can't seem to get this endpoint to work, even after I authenticate.  Is that supposed to be the case?  


cliang-07757:~ cliang$ curl -k -u cliang@mozilla.com https://plugins.mozilla.org/plugins_list.json
Enter host password for user 'cliang@mozilla.com':
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>

<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
<title>Ouch</title>
<base href="http://php.net/" />
</head>
<body>
<div id="framework_error" style="width:42em;margin:20px auto;">
<h3>Ouch</h3>
<style type="text/css">
.south {
    -moz-transform: rotate(30deg);
    -moz-transform-origin: left top;
}
</style>
<p class="south">Something went south...</p>
</div>
</body>
For some reason, that content isn't there...

$> lwp-request -m GET -edsS https://plugins.mozilla.org/plugins_list.json
GET https://plugins.mozilla.org/plugins_list.json
404 File Not Found
Flags: needinfo?(gozer)
I added the following lines to the Apache config for plugins.mozilla.org:

+   <LocationMatch "(?i)(?:en-us/)?plugins_list.json">
+        Satisfy any
+   </LocationMatch>
 
... and pushed out the change.  So, attempting to go to https://plugins.mozilla.org/plugins_list.json no longer prompts for authentication.  However, the file is either missing or the URL is not being handled correctly, since it is still returning an error.
10:38:17 AM cyliang: So, one question I had was: is there supposed to be a plugins_list.json file on the server?  Or does the application produce that?
10:39:08 AM espressive_afk: no, so that is an end point that maps to plugins/plugin_list in the PHP
10:40:01 AM espressive_afk: $config['plugins_list.json'] = 'plugins/plugins_list';
10:42:47 AM espressive_afk: getting the same locally now for some reason
10:42:49 AM espressive_afk: let me look
[...]
10:59:51 AM espressive_afk: I believe I found the problem
11:00:07 AM espressive_afk: can you access https://plugins.mozilla.org/en-us/plugins_list.json without an LDAP prompt
11:00:23 AM cyliang: Let me fire up a fresh browser and try
11:00:27 AM espressive_afk: thx
11:01:01 AM cyliang: Yes, I can connect to it without an LDAP prompt.
11:01:08 AM espressive_afk: and you get JSON right
11:01:12 AM cyliang: Yes.
11:01:26 AM espressive_afk: ok, so for some reason this URL wants the en-us prepended
11:01:32 AM espressive_afk: I swear it worked without that before
11:01:40 AM espressive_afk: anyhow, it works so that bug can be closed 
11:01:41 AM espressive_afk: Thanks!
11:01:43 AM espressive_afk: \o/
Status: REOPENED → RESOLVED
Closed: 6 years ago → 6 years ago
Flags: needinfo?(nmaul)
Resolution: --- → FIXED
Product: Infrastructure & Operations → Infrastructure & Operations Graveyard
You need to log in before you can comment on or make changes to this bug.