Make it possible to download/install Debian packages from a local mir…

[Castaglia]

…ror.

This is quite useful in cases where the destination node does not have
Internet egress access.

Changes

This change provides variables for overriding the URLs to the Debian apt repo and its key, so that they can be pointed at local mirrors when needed.

Verify

Add any steps on how to verify the changes work as intended

---

Add any relevant fixes or closes to reference github issues

[Castaglia]

I'm very confused by this build failure. In the Travis build logs, we see:

fatal: [localhost]: FAILED! => {"changed": false, "msg": "Failed to validate the SSL certificate for repos.influxdata.com:443. Make sure your managed systems have a valid CA certificate installed. If the website serving the url uses SNI you need python >= 2.7.9 on your managed machine  (the python executable used (/usr/bin/python) is version: 2.7.6 (default, Nov 23 2017, 15:49:48) [GCC 4.8.4]) or you can install the `urllib3`, `pyOpenSSL`, `ndg-httpsclient`, and `pyasn1` python modules to perform SNI verification in python >= 2.6. You can use validate_certs=False if you do not need to confirm the servers identity but this is unsafe and not recommended. Paths checked for this platform: /etc/ssl/certs, /etc/pki/ca-trust/extracted/pem, /etc/pki/tls/certs, /usr/share/ca-certificates/cacert.org, /etc/ansible. The exception msg was: [Errno 1] _ssl.c:510: error:14077410:SSL routines:SSL23_GET_SERVER_HELLO:sslv3 alert handshake failure."}

which suggests a cert validation issue.

OK, so let's see what server certificate is being presented, so we can see its issuer, see if it's one commonly found in the CA cert bundles:

$ curl -kv https://repos.influxdata.com
* Rebuilt URL to: https://repos.influxdata.com/
*   Trying 54.192.117.205...
* Connected to repos.influxdata.com (54.192.117.205) port 443 (#0)
* SSL peer handshake failed, the server most likely requires a client certificate to connect
* Closing connection 0
curl: (35) SSL peer handshake failed, the server most likely requires a client certificate to connect

Well, that's not quite what I expected. Rather rude behavior for a repo, I think.

What about using plain HTTP?

$ curl -kv http://repos.influxdata.com
* Rebuilt URL to: http://repos.influxdata.com/
*   Trying 54.192.117.205...
* Connected to repos.influxdata.com (54.192.117.205) port 80 (#0)
> GET / HTTP/1.1
> Host: repos.influxdata.com
> User-Agent: curl/7.43.0
> Accept: */*
> 
< HTTP/1.1 301 Moved Permanently
< Server: CloudFront
< Date: Wed, 21 Feb 2018 17:15:39 GMT
< Content-Type: text/html
< Content-Length: 183
< Connection: keep-alive
< Location: https://repos.influxdata.com/
< X-Cache: Redirect from cloudfront
< Via: 1.1 ff555a0cc6346f82fe74596f8ed6cc33.cloudfront.net (CloudFront)
< X-Amz-Cf-Id: sdcpqXvqg7Rm92yvETlV8sl3mm7ULNq9id0_nv9we6M3REB1L5O2lg==

No good -- you're redirected back to the HTTPS location. (And no, the trailing / does not change the behavior.):

$ curl -kv https://repos.influxdata.com/
*   Trying 54.192.117.131...
* Connected to repos.influxdata.com (54.192.117.131) port 443 (#0)
* SSL peer handshake failed, the server most likely requires a client certificate to connect
* Closing connection 0
curl: (35) SSL peer handshake failed, the server most likely requires a client certificate to connect

I don't know if this is a transient issue, or whether the particular URL configured in that playbook has never been exercised in this manner.