locksmith incorrectly requires etcd_certfile and etcd_keyfile when using endpoint

[dlamotte]

Issue Report

Bug

locksmithd requires etcd_certfile and etcd_keyfile to be set when setting endpoint.

From cloud-config user-data:

...
etcd2:
    initial-cluster: ...
    cert-file: /etc/kubernetes/ssl/etcd.pem
    key-file: /etc/kubernetes/ssl/etcd-key.pem
    trusted-ca-file: /etc/kubernetes/ssl/ca.pem
    peer-cert-file: /etc/kubernetes/ssl/etcd.pem
    peer-key-file: /etc/kubernetes/ssl/etcd-key.pem
    peer-client-cert-auth: true
    peer-trusted-ca-file: /etc/kubernetes/ssl/ca.pem

    name: controller0
    advertise-client-urls: https://$private_ipv4:2379
    listen-client-urls: https://$private_ipv4:2379,https://127.0.0.1:2379
    listen-peer-urls: https://$private_ipv4:2380
    initial-advertise-peer-urls: https://$private_ipv4:2380
    heartbeat-interval: 500
    election-timeout: 2500
...
  locksmith:
    endpoint: https://127.0.0.1:2379
    etcd_cafile: /etc/kubernetes/ssl/ca.pem
    etcd_certfile: /etc/kubernetes/ssl/etcd.pem
    etcd_keyfile: /etc/kubernetes/ssl/etcd-key.pem
...

Notice how I have etcd2 setup to serve over TLS however I don't require client key auth for clients (I do for peers).

CoreOS Version

On channel: Stable

$ cat /etc/os-release
NAME=CoreOS
ID=coreos
VERSION=1068.10.0
VERSION_ID=1068.10.0
BUILD_ID=2016-08-23-0220
PRETTY_NAME="CoreOS 1068.10.0 (MoreOS)"
ANSI_COLOR="1;32"
HOME_URL="https://coreos.com/"
BUG_REPORT_URL="https://github.com/coreos/bugs/issues"

Environment

What hardware/cloud provider/hypervisor is being used to run CoreOS? AWS

Expected Behavior

I expect that I can tell locksmith where to find the etcd endpoint without requiring use of client auth when etcd doesn't require it.

Actual Behavior

Client auth certs are required to be specified or you get:

$ systemctl status locksmithd
● locksmithd.service - Cluster reboot manager
   Loaded: loaded (/usr/lib64/systemd/system/locksmithd.service; disabled; vendor preset: disabled)
  Drop-In: /run/systemd/system/locksmithd.service.d
           └─20-cloudinit.conf
   Active: active (running) since Wed 2016-08-31 21:37:00 UTC; 1min 22s ago
 Main PID: 2708 (locksmithd)
    Tasks: 7
   Memory: 1.3M (limit: 32.0M)
      CPU: 7ms
   CGroup: /system.slice/locksmithd.service
           └─2708 /usr/lib/locksmith/locksmithd

Aug 31 21:37:00 ip-192-168-32-4.ec2.internal systemd[1]: Started Cluster reboot manager.
Aug 31 21:37:00 ip-192-168-32-4.ec2.internal locksmithd[2708]: locksmithd starting currentOperation="UPDATE_STATUS_IDLE" strategy="etcd-lock"
Aug 31 21:37:05 ip-192-168-32-4.ec2.internal locksmithd[2708]: Unlocking old locks failed: error setting up lock: Error initializing etcd client: Require both cert and key path. Retrying in 10s.
Aug 31 21:37:15 ip-192-168-32-4.ec2.internal locksmithd[2708]: Unlocking old locks failed: error setting up lock: Error initializing etcd client: Require both cert and key path. Retrying in 20s.
Aug 31 21:37:35 ip-192-168-32-4.ec2.internal locksmithd[2708]: Unlocking old locks failed: error setting up lock: Error initializing etcd client: Require both cert and key path. Retrying in 40s.

[mischief]

are you able to try with coreos alpha 1153.0.0? locksmith has been updated to 0.4.0 there, and uses the newer etcd client library.

[dlamotte]

@mischief sure, will do and get back to you

[dlamotte]

@mischief wasn't able to boot up alpha with my cloud config. From looking at the code though, it appears to fail here on master: https://github.com/coreos/locksmith/blob/master/locksmithctl/locksmithctl.go#L195

I'm not very familiar with the standard go build system so I couldn't figure out how to get it building. But the logic seems to assume that if any of those are set, it builds the client auth whereas it should probably do another check. This is on master.

If you can give me a pointer on how to build it, I'll write a pull request and test the change.

[crawford]

@dlamotte you should just be able to run the ./build script (Go doesn't have a build system yet).