Closed Bug 1035910 Opened 8 years ago Closed 8 years ago

stand up shavar service on https://tracking.services.mozilla.com

Categories

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

x86_64
Linux
task
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: mmc, Assigned: ckolos)

References

Details

Attachments

(1 file)

This is a request to stand up our prototype server from https://github.com/monicachew/abp-hostblocking/tree/master/safebrowsing_server at the address above for dogfooding.

Update requests should be served from https://tracking.services.mozilla.com/update?client=SAFEBROWSING_ID&appver=%VERSION%&pver=2.2

Ryan, please point the new ops manager at this bug so it doesn't get lost.
Blocks: 1029886
Component: DOM: Security → Operations: Deployment Requests
Flags: needinfo?(rtilder)
Product: Core → Mozilla Services
Version: Trunk → unspecified
Well now, I guess that's Travis :) Welcome, Travis!
Flags: needinfo?(rtilder)
Flags: needinfo?(tblow)
Thanks!  Looking into this.
Flags: needinfo?(tblow)
Assignee: nobody → ckolos
update on this: just completed the puppet configs; will test deployment monday AM.
as near as I can tell, this app is not working with node v0.10.26. When running the app via the following command line:

node safebrowsing_server/server.js

I'm immediately returned to a command line with no running node process.
:oremj points out that this should run from index.js. Thanks!

Doing so however, results in a EACCESS error as the app is hardcoded to run on port 80.

Can this be modified to run on a non-privileged port?
Done. Please use "./run.sh --port 8080" or "node index.js --port 8080"
DNS has been switched to point at this instance. A cert has been requested and will be installed.


curl http://tracking.services.mozilla.com/list
mozpub-track-digest256
mozpubmini-track-digest256
Requesting QA to look into this.
Flags: needinfo?(ewong)
I've been told that this will not go prod in the current incarnation, so resolve->fix'ing this and clearing qa's needinfo? flag.

Once this app is actually ready for prod, please open a new ticket for deployment/qa.
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(ewong)
Resolution: --- → FIXED
Hey ckolos,

This request was to stand up the non-production server at the final URL that will be used by Firefox, so that client dogfooders don't have to manually modify the updateURL in about:config to point at a test server. Can we still make that happen? The client code is still in Nightly, pref'ed off and far any release date, so the server itself doesn't have to be production ready at this point.

Thanks,
Monica
Flags: needinfo?(ckolos)
Alternatively, if you are more comfortable with a staging address, I could change the client code to match -- but the current dogfood requirements (point a pref at non-ssl http://154.24.xx.xxx) are pretty unreasonable right now.
:mmc, If ssl is a *requirement* here, then I'll need to create a new server for that. If port 80 access alone is acceptable, then this is already running at http://tracking.services.mozilla.com (ref'd in comment 7). Please let me know what you'd prefer.
Status: RESOLVED → REOPENED
Flags: needinfo?(ckolos)
Resolution: FIXED → ---
Flags: needinfo?(mmc)
Hi ckolos,

We have a product-wide requirement that all in-product URLs must be over SSL (bug 771788), so yes please requisition a cert.

Thanks,
Monica
Flags: needinfo?(mmc)
I've respun a server that has the cert installed. curl -vk https://tracking.services.mozilla.com/list returns the following:


$ curl -vk https://tracking.services.mozilla.com/list
* Hostname was NOT found in DNS cache
*   Trying 54.237.113.11...
* Connected to tracking.services.mozilla.com (54.237.113.11) port 443 (#0)
* successfully set certificate verify locations:
*   CAfile: /etc/ssl/certs/ca-certificates.crt
  CApath: none
* SSLv3, TLS handshake, Client hello (1):
* SSLv3, TLS handshake, Server hello (2):
* SSLv3, TLS handshake, CERT (11):
* SSLv3, TLS handshake, Server key exchange (12):
* 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 TLSv1.2 / ECDHE-RSA-AES256-GCM-SHA384
* Server certificate:
*        subject: C=US; ST=CA; L=Mountain View; O=Mozilla Corporation; CN=tracking.services.mozilla.com
*        start date: 2014-07-14 00:00:00 GMT
*        expire date: 2016-07-18 12:00:00 GMT
*        issuer: C=US; O=DigiCert Inc; CN=DigiCert SHA2 Secure Server CA
*        SSL certificate verify ok.
> GET /list HTTP/1.1
> User-Agent: curl/7.37.0
> Host: tracking.services.mozilla.com
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Wed, 16 Jul 2014 21:39:12 GMT
< Content-Type: text/plain
< Transfer-Encoding: chunked
< Connection: keep-alive
< Set-Cookie: debug_id=940805012; expires=Fri, 18 Jul 2014 21:39:12 GMT
< 
mozpub-track-digest256
mozpubmini-track-digest256
* Connection #0 to host tracking.services.mozilla.com left intact


please verify.
Flags: needinfo?(mmc)
Hi ckolos,

We're almost there. After chatting with rtilder on irc yesterday, I changed the client endpoint to downloads instead of update to be more consistent with the safebrowsing spec. Now I'm getting a 404 (attached) because I think the server is expecting a different endpoint.

On the server side, this commit duplicates the request handler for both /update and /downloads

https://github.com/monicachew/abp-hostblocking/commit/3cafc18e44236a13946d93740892f3173a0da5a9

Can you repush with this change?

Thanks,
Monica
Flags: needinfo?(mmc)
(In reply to [:mmc] Monica Chew (please use needinfo) from comment #15)
> Created attachment 8457637 [details]
> Screen Shot 2014-07-16 at 3.40.22 PM.png
> 
> Hi ckolos,
> 
> We're almost there. After chatting with rtilder on irc yesterday, I changed
> the client endpoint to downloads instead of update to be more consistent
> with the safebrowsing spec. Now I'm getting a 404 (attached) because I think
> the server is expecting a different endpoint.

Actually, I am wrong. Georgios tells me that the reason this is 404ing is because the file is not in the right location on disk. It should be in cwd as the server js files.
Here's the current directory listing for safebrowsing_server:

[ckolos@ip-10-69-164-113 safebrowsing_server]$ ls -lrta
total 276
-rw-r--r-- 1 app  app    4003 Jul 16 21:34 server.js
-rwxr-xr-x 1 app  app     116 Jul 16 21:34 run.sh
-rw-r--r-- 1 app  app     126 Jul 16 21:34 index.js
drwxr-xr-x 8 app  app    4096 Jul 16 21:34 ..
-rw-r--r-- 1 app  app  253912 Jul 16 21:34 mozpub-track-digest256
-rw-r--r-- 1 root root   6766 Jul 17 01:07 requestHandlers.js
drwxr-xr-x 2 app  app    4096 Jul 17 01:07 .
Flags: needinfo?(mmc)
I've pulled latest from github and restarted the app as well.
It works.

curl -v -d "mozpub-track-digest256;" https://tracking.services.mozilla.com/downloads | wc -c

curl -v -d "mozpub-track-digest256;" https://tracking.services.mozilla.com/update | wc -c
Thanks ckolos, I verified that it works on Nightly as well!
Status: REOPENED → RESOLVED
Closed: 8 years ago8 years ago
Flags: needinfo?(mmc)
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.