Closed Bug 560343 Opened 14 years ago Closed 14 years ago

Request for a staging server for QMO2

Categories

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

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

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: aakashd, Assigned: fox2mike)

Details

QA is re-building QMO with a Wordpress back-end. Craig Cook is developing it and will need a staging server to build the new site on mozilla.org. We'd like something set up by this Friday (April 23rd).
Let me know when/where the content is, I'll setup a stage site with WP.
Assignee: server-ops → shyam
Still waiting on you guys for content.
Hey Shyam, Craig is still building up the architecture on his end. We're looking at 5/3 to be ready right now. I'll post a comment to this bug if there's any more news before then.

Thanks for following up and I apologize for not giving you an update earlier.
(In reply to comment #3)
 
> Thanks for following up and I apologize for not giving you an update earlier.

Hey Aakash,

Thanks for the update!
Whiteboard: 2010-05-03, Tentative
Whiteboard: 2010-05-03, Tentative → Waiting on QA
Update: Craig is still building up the architecture. I'm going to get more info once I talk to him today or tomorrow.
Hi Shyam, we're ready to go. 

We need to replace QMO's current staging site with the latest released Wordpress 2.9.2 install and give subversion access to Craig Cook's email: craigcook@gmail.com

From my talk with Justin Scott and Craig, this should be the exact same action performed for staging Rock Your Firefox.
Whiteboard: Waiting on QA
Aakash,

Let me know where in the QA repo do you guys usually check in stuff and I'll give him access to that.

Craig did this for RYF :  http://svn.mozilla.org/addons/trunk/rockyourfirefox/wp-content/ 

So we need something similar for qmo so I can check it out and setup stuff.
That's a good question, Paul was the last guy doing major development on QMO. 

Paul, do you know where in the QA repo you've checked stuff into?
(In reply to comment #6)
> We need to replace QMO's current staging site with the latest released
> Wordpress 2.9.2 install

Please don't replace the existing stage site, in case we need to fix something on the Drupal version before the WP version launches.

Craig could create a branch and commit his work here,
http://svn.mozilla.org/projects/quality.mozilla.org/branches/

Once the site is ready to launch, we can replace trunk with the WP branch, and drop the Drupal staging site.
I think Alex answered your question there Aakash :)
Thanks Alex!
Yeah, thanks guys :)
What's the ETA on getting this done, Shyam?
Where is Craig's content? The rest of the setup is 10 mins work for me. Ask him to check it into svn and give me a URL?
(In reply to comment #13)
> Where is Craig's content? The rest of the setup is 10 mins work for me. Ask him
> to check it into svn and give me a URL?

Have I been granted access to the QMO project?

I can't seem to connect at all to Subversion at the moment, on any of the project (I'm getting "ssh_exchange_identification: Connection closed by remote host"). So even if I do have access to QMO there's nothing I can do right now.
rw granted on /projects/quality.mozilla.org/
(In reply to comment #15)
> rw granted on /projects/quality.mozilla.org/

I'm still getting locked out with:

ssh_exchange_identification: Connection closed by remote host
svn: Connection closed unexpectedly

Any idea why this might be? I committed code to another project as recently as yesterday and haven't done anything on my end since then (that I'm aware of, anyway).
yeah.

dm-svn02 sshd[14318]: Invalid user craigcook gmail.com 

This worked :

dm-svn02 sshd[19596]: Accepted publickey for craigcook@gmail.com 

So your username is coming in to the servers incorrectly.
(In reply to comment #17)
> dm-svn02 sshd[14318]: Invalid user craigcook gmail.com 

D'oh, stupid me, I was sending %20 (space) instead of %40 (@). Silly typo.

Added http://svn.mozilla.org/projects/quality.mozilla.org/branches/wordpress/wp-content

So if you can install WordPress 2.9.2 and give me admin access, I can take it from there with configuring the options and activating the theme and plugins etc.
http://quality-new.stage.mozilla.com/

You also have the admin login details in your email. 

Reopen if you need anything else.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
It's mostly up and running, just need a few more server-side things done.

1. The /wp-content/ folder needs to be writable by the server so we can upload media and update plugins.

2. The root .htaccess file should be updated with: 

<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>

Those rules handle the nice URLs. Or if .htaccess is server-writable, WP can add the rules itself.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
All done.
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
Super, thanks guys!
Sorry, one last thing...

The plugin we're using to syndicate external feeds parses them through MagpieRSS, but the version of Magpie that currently ships with WordPress is outdated. The plugin can upgrade Magpie automatically if /wp-includes/rss.php is writable, or you can upgrade manually by replacing that file with the one that ships with the plugin:

$ cp \
	'/data/www/quality-new.stage.mozilla.com/wp-content/plugins/feedwordpress/MagpieRSS-upgrade/rss.php' \
	'/data/www/quality-new.stage.mozilla.com/wp-includes/rss.php'

The downside of the manual upgrade is that a future update to WordPress could overwrite it and you'd have to repeat the Magpie upgrade, but that might be preferable to making core files server-writable, depending on how secure you want to be.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I don't mind doing this on staging, but how do you plan to handle this in production?
(In reply to comment #23)

> $ cp \
>    
> '/data/www/quality-new.stage.mozilla.com/wp-content/plugins/feedwordpress/MagpieRSS-upgrade/rss.php'
> \
>     '/data/www/quality-new.stage.mozilla.com/wp-includes/rss.php'
> 

This is done, I'd still like to see an answer to comment #24, closing the bug though :)
Status: REOPENED → RESOLVED
Closed: 14 years ago → 14 years ago
Resolution: --- → FIXED
(In reply to comment #25)

> This is done, I'd still like to see an answer to comment #24, closing the bug
> though :)

I'm not sure I understand your question in comment #24... The same upgrade will have to be done in production as well. Or rather, now that the file has been upgraded, pushing the same code to production means it'll already be covered and you won't have to repeat this step. Is there a reason this version of the file can't or shouldn't be installed in production just as it is on stage?
From IT's perspective, it adds an extra step that we have to "remember" about and or document somewhere and carry out *only* for QMO. Out of all the other WP instances we manage, I'm not aware of anyone else doing this. 

That's where the question is coming from. During the setup phase, yes..it's not too hard to fiddle with things. Once stuff goes to prod and 6 months down the line there's a critical WP upgrade, this can be easily overlooked is what I'm bothered about.
(In reply to comment #27)
> From IT's perspective, it adds an extra step that we have to "remember" about
> and or document somewhere and carry out *only* for QMO. Out of all the other WP
> instances we manage, I'm not aware of anyone else doing this. 
> 
> That's where the question is coming from. During the setup phase, yes..it's not
> too hard to fiddle with things. Once stuff goes to prod and 6 months down the
> line there's a critical WP upgrade, this can be easily overlooked is what I'm
> bothered about.

Yeah, it's pretty unusual that a plugin requires changes to WP core files (any decent plugin should be designed to avoid that). In this particular case it's actually a third-party app that gets bundled with WP, not any code from WP itself. But the version WP bundles is really old for some reason. And technically the plugin shouldn't break if MagpieRSS is outdated, it's just strongly recommended to upgrade. Even if the file is overwritten in the future it wouldn't spell disaster.

But that's why there's also the option of making the file writable (probably 644, depending on the server). Then the plugin can restore the upgrade automatically in the event it's overwritten by any future changes to WP. You'd only have to remember to do it manually if you have everything locked down and read-only.

The plugin in question is called FeedWordPress and it's designed to detect the Magpie version and display an alert in the WP dashboard if/when that version is too old. If the file is writable by WP, any site admin can perform the upgrade with a single click. If the file is outdated *and* read-only, the plugin shows a different alert with instructions to either change permissions or upgrade manually (with the command in comment #23), so that's a pretty strong reminder.
Yep, gotta agree with Craig's last paragraph. I'll write this caveat as a note in our QMO release process wiki in the future until it's not necessary. 

Either way, if we do miss it in the future, logging onto our admin dashboard once the site is pushed live will alert us to this rather quickly. I appreciate the concern though, Shyam.
Good news. FeedWordPress released an update a few days ago and it no longer uses MagpieRSS as its parser, switching instead to SimplePie (also included with WP). So the clumsy Magpie upgrade is no longer necessary when installing/activating the plugin, eliminating fears of code being overwritten in future WP updates.
Product: mozilla.org → mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.