526517 - Move personas stage behind zlb-stage01

Status: RESOLVED FIXED

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

Description

[Ryan Doherty (:rdoherty)]

In order to better replicate Persona's production environment, sm-personas01.mozilla.org should be moved behind zeus and given the same configuration as production.

This does need to happen soon as Firefox 3.6 is just around the corner and getpersonas.com needs to be ready for the onslaught of traffic.

Comment 1

[matthew zeier [:mrz]]

(changing summary - not clear if sm-personas01 is really the right stage location)

Comment 2

[Ryan Doherty (:rdoherty)]

(In reply to comment #1)
> (changing summary - not clear if sm-personas01 is really the right stage
> location)

It's what we have now, if a new stage box should be setup, wfm.

Comment 3

[Ryan Doherty (:rdoherty)]

Any updates for this? Getting bug 526518 working would be awesome for 3.6, otherwise all the traffic to getpersonas.com will hit the webheads directly.

Comment 4

[Jeremy Orem [:oremj]]

http(s)://personas.stage.mozilla.com points to zlb-stage01 which points to sm-personas01.

Comment 5

[Ryan Doherty (:rdoherty)]

Not sure if I'm seeing a regression or some cached dns, but I don't see any x-served-by or cache headers from sm-personas01.mozilla.org:

Date	Thu, 31 Dec 2009 00:47:54 GMT
Server	Apache/2.2.3 (CentOS)
X-Powered-By	PHP/5.1.6
Connection	close
Transfer-Encoding	chunked
Content-Type	text/html; charset=UTF-8

It's also not gzipped, which I think is on by default for zeus & netscalers?

Comment 6

[matthew zeier [:mrz]]

Not on by default.  Just turned it on.

Comment 7

[Ryan Doherty (:rdoherty)]

reopening, clicking on 'sign in' puts me in an infinite loop.

https://personas.stage.mozilla.com/en-US/signin

Also don't see a 'via' header to confirm it is behind zeus.

Comment 8

[Jeremy Orem [:oremj]]

Hmmm, apache is handling those requests. If I dump all requests to port 81 (where https goes) I see:

GET /en-US/signin HTTP/1.1
User-Agent: curl/7.19.4 (universal-apple-darwin10.0) libcurl/7.19.4 OpenSSL/0.9.8k zlib/1.2.3
Accept: */*
SSLClientCertStatus: NoClientCert
SSLClientCipher: SSL_RSA_WITH_RC4_128_SHA, version=TLSv1, bits=128
Host: personas.stage.mozilla.com
SSLSessionID: 6E41B0ACFB277DF460FE26DE867B161A3FC62928D7452E3A60E9C1B98CFB07D0
X-Cluster-Client-Ip: 208.75.43.97


HTTP/1.1 302 Found
Date: Thu, 31 Dec 2009 18:39:18 GMT
Server: Apache/2.2.3 (CentOS)
Location: https://personas.stage.mozilla.com/en-US/signin
Content-Length: 322
Connection: close
Content-Type: text/html; charset=iso-8859-1

Comment 9

[Ryan Doherty (:rdoherty)]

I remember there being some extra setup on sm-personas01 for ssl and redirection if a page is requested without it. Zandr and/or Toby would have more information, they set it up.

Comment 10

[Jeremy Orem [:oremj]]

Found "RewriteRule ^/([a-zA-Z-]+/)?signin https://%{SERVER_NAME}/$1signin [R,L]" in the vhost. Changed it to:

 RewriteCond %{HTTP:SSLSessionID} !.+
 RewriteRule ^/([a-zA-Z-]+/)?signin https://%{SERVER_NAME}/$1signin [R,L]

Fixed now.

I've also turned on verbose caching:

webcache!verbose

    The X-Cache-Info header is added to every HTTP response, showing whether the request and/or the response was cacheable. It may have one of the following values, where the first two values correspond to a response being cached while the others explain why it is not cacheable.

        * cached
        * caching
        * not cacheable; request had a content length
        * not cacheable; request wasn't a GET or HEAD
        * not cacheable; request specified "Cache-Control: no-store"
        * not cacheable; request contained Authorization header
        * not cacheable; response had too large vary data
        * not cacheable; response file size too large
        * not cacheable; response code not cacheable
        * not cacheable; response contains "Vary: *"
        * not cacheable; response specified "Cache-Control: no-store"
        * not cacheable; response specified "Cache-Control: private"
        * not cacheable; response specified "Cache-Control: no-cache"
        * not cacheable; response specified max-age <= 0
        * not cacheable; response specified "Cache-Control: no-cache=..."
        * not cacheable; response has already expired
        * not cacheable; response is 302 without expiry time
        * not cacheable; meta data too large