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.

Well now, I guess that's Travis :) Welcome, Travis!

Thanks! Looking into this.

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.

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.

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

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.

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

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.

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

Actually please update to this one https://github.com/monicachew/abp-hostblocking/commit/914c60024adfd931a779fc09396a0147d1cc3ca2 ASAP

(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 .

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!

closing.