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

Status: RESOLVED FIXED

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

Description

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 1

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Sorry, I meant when this bug is fixed, please post the final URL to bug 723280.

Comment 2

[Brandon Burton [:solarce]]

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.

Comment 3

[Corey Shields [:cshields]]

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.

Comment 4

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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?

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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?

Comment 6

[Corey Shields [:cshields]]

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?

Comment 7

[Brandon Burton [:solarce]]

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

Comment 8

[Brandon Burton [:solarce]]

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

Thanks

Comment 9

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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?

Comment 10

[Brandon Burton [:solarce]]

I think https://wiki.mozilla.org/Security/Reviews/Review_Request_Form is the place to start

Comment 11

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Ok, opsec review turned out positive, so fixing this bug is the next step. Is the SSL certificate order already completed?

Comment 12

[Brandon Burton [:solarce]]

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

Comment 13

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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.

Comment 14

[Brandon Burton [:solarce]]

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?

Comment 15

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

It looks to me like PHP's short_open_tag is disabled on that machine:

https://calendar.mozilla.org/update.php?buildID=20120306005628&appABI=x86_64-gcc3&appOS=Linux&locale=en-US&appVersion=14.0&appID={3550f703-e582-4d05-9a08-453d09bdfdc6}

Comment 16

[Brandon Burton [:solarce]]

Correct, RHEL6 ships with it off and it's recommended to stay off for security reasons.

Comment 17

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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?>

Comment 18

[Brandon Burton [:solarce]]

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

Comment 19

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

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 <[e-mail]>
date:        Wed May 09 22:32:09 2012 +0700
summary:     Avoid the need for short_open_tag = On

Comment 20

[Brandon Burton [:solarce]]

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

How's it look?

Comment 21

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Looks good, marking as FIXED.