Closed
Bug 731338
Opened 12 years ago
Closed 12 years ago
use read-only database URI for balrog client app
Categories
(mozilla.org Graveyard :: Server Operations, task)
mozilla.org Graveyard
Server Operations
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: bhearsum, Assigned: bburton)
References
Details
I was looking at the admin app setup vs. the client app setup being done on the asu4-dev nodes in bug 719581 and noticed that they're both using the same database URI. In production, the client app is going to be public-facing and since it doesn't require rw access, shouldn't have it. Can we do the same here in the dev environment to keep things consistent?
Assignee | ||
Updated•12 years ago
|
Assignee: server-ops → bburton
Assignee | ||
Updated•12 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 1•12 years ago
|
||
User was created by the DBA and I have an updated config file ready to commit to SVN so puppet can push it, let me know when is a good time to push.
Reporter | ||
Comment 2•12 years ago
|
||
Per IRC, you can do this anytime.
Assignee | ||
Comment 3•12 years ago
|
||
Pushed earlier and confirmed still getting XML back, see below bburton@andesite ~$ curl -v -k "https://aus4-dev.allizom.org/update/3/Firefox/10.0a1/20111108031146/Linux_x86_64-gcc3/en-US/nightly/Linux%203.0.0-12-generic%20%28GTK%202.24.6%29/default/default/update.xml?force=1" * About to connect() to aus4-dev.allizom.org port 443 (#0) * Trying 63.245.217.120... connected * Connected to aus4-dev.allizom.org (63.245.217.120) port 443 (#0) * SSLv3, TLS handshake, Client hello (1): * SSLv3, TLS handshake, Server hello (2): * SSLv3, TLS handshake, CERT (11): * SSLv3, TLS handshake, Server finished (14): * SSLv3, TLS handshake, Client key exchange (16): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSLv3, TLS change cipher, Client hello (1): * SSLv3, TLS handshake, Finished (20): * SSL connection using RC4-SHA * Server certificate: * subject: C=US; ST=California; L=Mountain View; O=Mozilla Corporation; OU=AUS4-DEV; CN=aus4-dev.allizom.org * start date: 2011-11-10 18:50:52 GMT * expire date: 2016-11-08 18:50:52 GMT * common name: aus4-dev.allizom.org (matched) * issuer: C=US; ST=California; L=Mountain View; O=Mozilla Corporation; OU=Mozilla Corporation Root Certificate Services; CN=Mozilla Root CA; emailAddress=hostmaster@mozilla.com * SSL certificate verify result: unable to get local issuer certificate (20), continuing anyway. > GET /update/3/Firefox/10.0a1/20111108031146/Linux_x86_64-gcc3/en-US/nightly/Linux%203.0.0-12-generic%20%28GTK%202.24.6%29/default/default/update.xml?force=1 HTTP/1.1 > User-Agent: curl/7.21.4 (universal-apple-darwin11.0) libcurl/7.21.4 OpenSSL/0.9.8r zlib/1.2.5 > Host: aus4-dev.allizom.org > Accept: */* > < HTTP/1.1 200 OK < Date: Thu, 01 Mar 2012 20:06:54 GMT < Server: Apache < X-Backend-Server: node268 < Content-Length: 515 < Content-Type: text/xml; charset=utf-8 < <?xml version="1.0"?> <updates> <update type="minor" version="13.0a1" extensionVersion="13.0a1" buildID="20120301031135" > <patch type="complete" URL="http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/03/2012-03-01-03-11-35-mozilla-central/firefox-13.0a1.en-US.linux-x86_64.complete.mar" hashFunction="sha512" hashValue="b2684e879b62050fae60f7b2e2a6adea71b1f61255cd51fe3a677cfa8bf605af907b6984a92ac53b4cc28b2694a7aff38c530cb046061cfa59cbfbdcf3afeed6" size="20174395"/> </update> * Connection #0 to host aus4-dev.allizom.org left intact * Closing connection #0 * SSLv3, TLS alert, Client hello (1): </updates>%
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Reporter | ||
Comment 4•12 years ago
|
||
Thanks!
Updated•9 years ago
|
Product: mozilla.org → mozilla.org Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•