environs/cloudinit: Allow for disabling hostname

environs/cloudinit: Allow for disabling hostname

Step two towards fixing bug #1202163. This sets up "cloud-init" so
that it passes the "--no-check-certificate" flag to wget. I did end up
testing this live, and sshing into the machine to delete the
ca-certificates and verify that with this flag wget works correctly.
(I ran the line in cloud-init and verified that with the flag it
downloads, without the flag it fails.)

https://code.launchpad.net/~jameinel/juju-core/ssl-hostname-cloud-init-1202163/+merge/187707

(do not edit description out of merge proposal)

[jameinel, 2013-09-26 09:56:10]

Please take a look.

[ssmoser, 2013-09-26 14:09:05]

Wouldn't it make more sense to insert the correct certificates into the instance
and trust those certificates than to just ignore them?

Cloud-init has explicit support for inserting certificates into the system:
http://bazaar.launchpad.net/~cloud-init-dev/cloud-init/trunk/view/head:/doc/e...

If juju client knows the certificates, then it can just pass them on to the unit
via cloud-init user-data.

[fwereade, 2013-10-02 09:18:44]

Looks solid -- opinion on comments?

https://codereview.appspot.com/13962043/diff/1/environs/cloudinit.go
File environs/cloudinit.go (right):

https://codereview.appspot.com/13962043/diff/1/environs/cloudinit.go#newcode52
environs/cloudinit.go:52: disableSSLHostnameVerification)
A bit torn here. I think it'd maybe be neater to do it in FinishMachineConfig,
but that is itself a little problematic in that it currently requires a
config.Config but (unless it's a state server) only uses a single field. I
*think* it's still better to do it there but I could probably be argued out of
it.

https://codereview.appspot.com/13962043/diff/1/environs/manual/agent.go
File environs/manual/agent.go (right):

https://codereview.appspot.com/13962043/diff/1/environs/manual/agent.go#newco...
environs/manual/agent.go:74: disableSSLHostnameVerification := false
Shouldn't it be a juju-level config setting?

https://codereview.appspot.com/13962043/diff/1/provider/instance.go
File provider/instance.go (right):

https://codereview.appspot.com/13962043/diff/1/provider/instance.go#newcode50
provider/instance.go:50: // very heavyweight
or we could just do it in FinishMachineConfig. Let's do that, and suck up the
annoyance of separating Finish of bootstrap and normal machine configs later.

[fwereade, 2013-10-02 09:21:50]

On 2013/09/26 14:09:05, ssmoser2 wrote:
> Wouldn't it make more sense to insert the correct certificates into the
instance
> and trust those certificates than to just ignore them?
> 
> Cloud-init has explicit support for inserting certificates into the system:
>
http://bazaar.launchpad.net/%7Ecloud-init-dev/cloud-init/trunk/view/head:/doc...
> 
> If juju client knows the certificates, then it can just pass them on to the
unit
> via cloud-init user-data.

That's the ideal, but I'm not sure we can depend on the hacky self-signed certs
we're dealing with here to not, eg, be randomly changed at arbitrary times. I'd
say the lack of detailed handling for self-signed certs is a low/wishlist bug
myself.

[jameinel, 2013-10-02 10:12:05]

Please take a look.

[fwereade, 2013-10-02 12:38:49]

LGTM, thanks.