DEB Boostrapping problems: missing cluster name and wrong certificate information

[herrBez]

Elasticsearch Version

Version: 8.1.2, Build: default/deb/31df9689e80bad366ac20176aa7f2371ea5eb4c1/2022-03-29T21:18:59.991429448Z, JVM: 17.0.2

Installed Plugins

No response

Java Version

bundled

OS Version

Linux bez-boostrap-test-19xx 5.4.0-1067-gcp #71~18.04.1-Ubuntu SMP Thu Mar 3 09:50:52 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Problem Description

When following the official boostrapping documentation for deb packages. I faced several problems. Perhaps we can try to improve the documentation to address these challenges or possibly improve the elasticsearch-reconfigure-node procedure.

1. The nodes target of a reconfigure do not set the cluster.name setting in the YAML file (even if the first node did set it). Either should the user be aware that this setting has to added manually on all nodes or it should be possibly set by the elasticsearch-reconfigure-node utility.
   If this setting is not added manually on the new nodes this error is written in the logs (java.lang.IllegalStateException: handshake with [{10.0.0.6:9300}{reHGydZ1TG2V2HrQKfynlQ}{bez-boostrap-test-nnd7}{10.0.0.6:9300}] failed: remote cluster name [mirkoscluster] does not match local cluster name [elasticsearch])
2. When we download elasticsearch from the DEB package the transport.host setting is not set. This setting defaults to localhost. IMHO when an enrollment-token for a node is created with the /usr/share/elasticsearch/bin/elasticsearch-create-enrollment-token -s node utility we should warn the user if the tranport.host setting is not set or set to localhost, so that the user has the possibility to review the network settings if needed. Otherwise the new nodes cannot connect to the existing cluster.
3. The reconfigured node set the discovery.seed_host based on the "nodes_addresses" value coming from the _security/enroll/node API response. However (at least when I tried more than 1 time) it is a list of IP-Adresses:9300, but the transport certificates seems to be only valid for the hostnames. This prevents the new nodes to join the existing cluster, because the new nodes cannot establish an SSL Connection with the existing ones.

Steps to Reproduce

Follow the procedure described here: https://www.elastic.co/guide/en/elasticsearch/reference/current/deb.html#_reconfigure_a_node_to_join_an_existing_cluster .

To reproduce the first bullet point, add the cluster.name setting in the first node before reconfigure the second node.

Logs (if relevant)

No response

[elasticmachine]

Pinging @elastic/es-security (Team:Security)

[elasticmachine]

Pinging @elastic/es-delivery (Team:Delivery)