Find a place to put the update.rdf PHP script for Calendar

RESOLVED FIXED

Status

RESOLVED FIXED
7 years ago
5 years ago

People

(Reporter: Fallen, Assigned: bburton)

Tracking

Details

Calendar wants nightly updates in bug 322522 so it needs to serve an update.rdf type script and make its nightlys point there.

This means we need a server somewhere that can host the php script you can find in bug 723273. It doesn't require any databases or such, the script is very simple and self contained.

The script isn't on any repository yet, but if you want I can stick it into github or my mozilla user repo.

The server needs to host this script via https. It should not be possible to acess it via http. If you want to avoid buying a new ssl cert, I guess we could stick this onto a momo server for now and then use whatever new cert will be bought when momo does the transition to moco servers in 2 months.

When this bug is fixed, please post the final URL to bug 723273.
(Assignee)

Updated

7 years ago
Assignee: server-ops → bburton
Status: NEW → ASSIGNED
Sorry, I meant when this bug is fixed, please post the final URL to bug 723280.
Summary: Find a place to put the update.rdf script for Calendar → Find a place to put the update.rdf PHP script for Calendar
(Reporter)

Updated

7 years ago
Blocks: 723280
No longer blocks: 723273
(Assignee)

Comment 2

7 years ago
I've looked into this and I'm not seeing a place it would fit on our generic site cluster, since it requires SSL

Right now the best option I can suggest is to discuss seeing if it could fit into the AUS or MoMo for now.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WONTFIX
we can keep this open until we find out who to hand it off to, or figure out a way to fit it into aus.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
So jhopkins tells me the MoMo servers are going away and bhearsum tells me he thinks AUS isn't the best place to put this. Do you have any other suggestions, or can CC someone who might know a solution?
Ping, any updates here? I'd really like to get this rolling. If no existing server can be found, maybe we should bite the bullet and get a new SSL cert for this?
If this is just a simple php script we can throw this on the generic cluster.  Can you link the bug where this has had its opsec review?
(Assignee)

Comment 7

7 years ago
So we can get an SSL certificate for a new mozilla.org subdomain.  

Does just having it be on https://calendar.mozilla.org/ sound good?

We could have / redirect to http://www.mozilla.org/projects/calendar/ if that'd be best, and have the php script exempt from the rewrite

Let me know and I'll get the SSL order going

Additionally, as Corey mentioned above, the script will need an opsec review before we can put it up in production
(Assignee)

Comment 8

7 years ago
Ping, :Fallen, let me know on the URL and redirect and I'll get this going.

Thanks
https://calendar.mozilla.org/ sounds good, as does the redirect of /.

I'll file an extra bug for opsec review after I do some tweaks I could imagine they'd complain about :) Is there a guideline somewhere, what opsec will be looking for?
(Assignee)

Updated

7 years ago
Depends on: 742552
(Reporter)

Updated

7 years ago
Depends on: 743944
Ok, opsec review turned out positive, so fixing this bug is the next step. Is the SSL certificate order already completed?
(Assignee)

Comment 12

7 years ago
It's ready, just needs to be installed, I can setup things next week, ping me on Monday

Also, is there a repo where the script is?

Thanks
I've uploaded the script to this repo:

http://hg.mozilla.org/users/mozilla_kewis.ch/calendar-buildconfig/

If you need it to be some else (buildbot-configs repo maybe?) we can take care on Monday.
(Assignee)

Comment 14

7 years ago
This has been pushed live and https://calendar.mozilla.org/update.php gives me an error because I"m not giving it any parameters.

Can you test it out and let me know how it looks?
Status: REOPENED → ASSIGNED
(Assignee)

Comment 16

7 years ago
Correct, RHEL6 ships with it off and it's recommended to stay off for security reasons.
I see. So I take it you are not interested in turning it on just for that script? I personally find <?=$foo?> much easier to read inbetween HTML than <?php echo $foo?>
(Assignee)

Comment 18

7 years ago
As a rule, we try to avoid breaking with RHEL's base security related configuration whenever possible. 

We had to make a number of changes to our Mediawiki skin for wiki.mozilla.org to eliminate it's use of short tags, so we understand it requires some code changes, but knowing our systems are following RHEL's standards helps keep AppSec and OpSec happy.

If having short tags off is going to cause you a big rewrite, I can look into if we could disable it for your vhost only
Ok, lets go with long open tags then.

repo:        http://hg.mozilla.org/users/mozilla_kewis.ch/calendar-buildconfig/
changeset:   1:bbe23b8b2e48
tag:         tip
user:        Philipp Kewisch <mozilla@kewis.ch>
date:        Wed May 09 22:32:09 2012 +0700
summary:     Avoid the need for short_open_tag = On
(Assignee)

Comment 20

7 years ago
Updated to hangeset:   1:bbe23b8b2e48 and pushed live to the cluster of web servers

How's it look?
Looks good, marking as FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago7 years ago
Resolution: --- → FIXED
Component: Server Operations: Web Operations → WebOps: Other
Product: mozilla.org → Infrastructure & Operations
You need to log in before you can comment on or make changes to this bug.