Closed Bug 886529 Opened 12 years ago Closed 12 years ago

please deploy train-2013.06.05-2 to production

Categories

(Cloud Services :: Operations: Deployment Requests - DEPRECATED, task)

x86
macOS
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: jrgm, Assigned: gene)

References

Details

sha: 86782e4663866445065e9d45d8c0af820e487f88 ChangeLog: https://github.com/mozilla/browserid/blob/train-2013.06.05/ChangeLog#L3-L15 Schedule: http://personatra.in/#2013.06.05 Output rpm on r6 build machine: /home/jrgm/workspace/browserid/rpmbuild/RPMS/x86_64/browserid-server-0.2013.06.05-2.el6_116934.x86_64.rpm [Althought, still need to get a thumbs-up on the stage train (from jedp/edwong).] This contains a required fix for dev site not loading dialog on android 2.2 stock ('native' is reserved kw on stock): #3522, #3535 (and two other usability changes for the phone).
edwong gave me the thumbs up for the other issues on b2g. So, gene, this is the rpm to deploy to production stacks for browserid train-2013.06.05. /home/jrgm/workspace/browserid/rpmbuild/RPMS/x86_64/browserid-server-0.2013.06.05-2.el6_116934.x86_64.rpm Same as the one noted above.
Status: NEW → ASSIGNED
I seem to be having an issue with the verifier using scripts/verify-assertion.js. I'm looking to see where the error is coming from and whether it's for real. But Gene could you check that the verifier looks sane (configs, hydrated, errors). The error the verifier is sending back is { status: 'failure', reason: 'can\'t get public key for login.example.com: login.example.com is\ not a browserid primary - non-200 response code to /.well-known/browserid' }
Ya apologies, that was a verifier that failed hydration due to a bug ( https://github.com/mozilla/identity-ops/issues/73 ). I've fixed that host and verified that no hosts in us-east-1 had a problem.
The verifiers seem good to me now. Thanks Gene. Okay, I'm good with these stacks going into production generally. However, I had missed that there was an incompatible change for session cookies from the change in version of the client-sessions module. See https://github.com/mozilla/browserid/issues/3583, and I'm looking for feedback on whether we're all ok with the implications that that has. So we're holding on this going live until I have that feedback.
Okay, we're all settled on issue 3583 and will proceed with the build as-is (and users will need to reauthenticate after that ships). This is good to go to production.
This is live in production
Status: ASSIGNED → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.