Skip to content
This repository has been archived by the owner on Feb 5, 2020. It is now read-only.

Fix external etcd with TLS #2969

Closed
wants to merge 6 commits into from

Conversation

lblackstone
Copy link
Contributor

Fixes #2841

This series of changes fixes external etcd with TLS enabled for the OpenStack platform (and possibly other platforms). I tested both self-hosted and external etcd + TLS successfully on OpenStack.

Note that external etcd with TLS is also broken on the master branch, so the relevant fixes should probably be cherry-picked after this merges.

/cc @squat

@coreosbot
Copy link

Can one of the admins verify this patch?

1 similar comment
@coreosbot
Copy link

Can one of the admins verify this patch?

@sym3tri
Copy link
Contributor

sym3tri commented Feb 19, 2018

Hey @lblackstone. We need to resync the track-1 branch to the 1.8.7 branch. This will happen once we ship the release (any day now). So you may need to do some rebasing once that happens. Sorry for the inconvenience. We'll keep you posted.

@lblackstone
Copy link
Contributor Author

Rebased on track-1 with 1.8.7 changes merged in

Levi Blackstone added 6 commits March 12, 2018 09:16
Recent versions of sshd already set `UsePrivilegeSeparation sandbox`
by default, and this option is deprecated.
The dropin file for the etcd-member service was inadvertently
overwriting the existing RKT_RUN_ARGS set in the service
unit file. This prevented the uuid-file-save from being set, which
then prevented the service from being restarted correctly on reboot, etc.
The conditional check for self-hosted etcd was not handling the
disabled case correctly (using external etcd).
The required TLS assets were not being copied to the location
expected by the control plane manifests, so external etcd was
not working if tectonic_etcd_tls_enabled was true.
The coreos-metadata service was failing to restart correctly on
reboot, preventing the etcd-member service from restarting.
It doesn't look like the etcd-member service was actually using
metadata, and disabling the service appears to fix the problem.
TLS certs for etcd are generated based on this variable. Previously, this
was using the bare IP addresses rather than DNS names, which is less
robust, and was causing TLS failures for external etcd.
@lblackstone
Copy link
Contributor Author

@squat Can these be reviewed now? Looks like the 1.8.7 sync may be done now?

@lblackstone lblackstone deleted the external-etcd-tls branch March 26, 2018 20:00
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

External etcd with TLS not working
3 participants