Relation between Landscape client and server should include config info

[Xav Paice]

When configuring a relation between landscape-server and landscape-client, we need to add the following config items manually in order to make the connection:

* if using the selfsigned cert, we get the cert from /var/lib/haproxy/default.pem on the landscape-haproxy unit
* we then configure that with juju config landscape-client ssl-public-key=$(cat default.pem | openssl base64 -e)
* set ping-url and url with the IP taken from the landscape-haproxy unit

Surely this is info that would be better gained from a relation rather than writing a script to do this every deployment.

[Ante Karamatić (ivoks)]

Totally agree. In fact I already started working on this, so expect some patches soon.

[Xav Paice (xavpaice)]

Note that according to https://help.landscape.canonical.com/LDS/SSL we CANNOT use a self signed cert - we have to use a self signed CA and then make a cert from that. The charm does none of this and so when we want to make a fresh environment we wind up ditching the cert created by the charm.

[Nobuto Murata (nobuto)]

@Xav,

FWIW, here are steps I used to register clients in previous deployments:

$ landscape_ip=$(juju run \
     --application haproxy 'unit-get private-address')
$ landscape_crt=$(juju run \
     --application haproxy \
     'sudo openssl x509 -in /var/lib/haproxy/default.pem' | base64)
$ juju config landscape-client \
    account-name=standalone \
    url="https://${landscape_ip}/message-system" \
    ping-url="http://${landscape_ip}/ping" \
    ssl-public-key="base64:${landscape_crt}"

It worked at least in February 2017.

[Xav Paice (xavpaice)]

What I had to do in this instance, though I didn't test your approach:

    - Create a CA, and make a cert from that rather than a straight
      self-signed cert. https://help.landscape.canonical.com/LDS/SSL is accurate.
    - Add the cert itself and key to the landscape-server and landscape-haproxy
      charm config, base64 encoded.
    - Add the CA cert to the landscape-client charm, base64 encoded and
      prefixed with base64:
    - Manually go to the haproxy box and restart haproxy.

The fact remains, the charm should do all of this. If we need a CA, then the docs are correct and the charm won't ever work. If we can work with self-signed certs, then the charm needs the fix Ante has put together, and the docs need to be fixed as well.

[Uros Jovanovic (uros-jovanovic)]

After investigation, solution does not really require creating CA.

[Drew Freiberger (afreiberger)]

I concur that Nobuto's approach is best. I've been struggling with any other method of making this relation work and what I've found is that relating landscape-client to landscape-server:registration is that if you have landscape-server in HA mode, the registration code pins you to one of the landscape-servers and half of them work great and half die on the vine.

This relation must also go hand-in-hand with a relation to the haproxy service for url, ping-url, and ssl-public-key as is noted in comment #3.

This extra step is not needed if you register an SSL cert for an externally queryable FQDN beforehand, nail an IP in MAAS for the HAproxy unit to match the externally queryable name (or use the maas auto-dns name), and place the ca and full external DNS name for the landscape-haproxy units into the landscape-client configs.

[Xav Paice (xavpaice)]

I've subscribed field-medium here.

https://code.launchpad.net/~cpe-consulting/landscape-charm/client-relation/+merge/322015 is a fork which is used on a number of clouds in order to address this issue, although there are inconsistent results with some landscape-client units remaining with the 'Need computer-title and juju-info to proceed' status.