Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Transport's publish address should report its hostname #39970

Closed
DaveCTurner opened this issue Mar 12, 2019 · 1 comment · Fixed by #45662
Closed

Transport's publish address should report its hostname #39970

DaveCTurner opened this issue Mar 12, 2019 · 1 comment · Fixed by #45662
Assignees
Labels
>bug :Distributed Coordination/Network Http and internode communication implementations

Comments

@DaveCTurner
Copy link
Contributor

DaveCTurner commented Mar 12, 2019

There are situations in which the hostname of the transport's publish address is important. For instance, if node-to-node TLS is enabled including full certificate verification then it is the hostname of the node's publish address that we are verifying.

I suspect that #32729 was raised because we hide the hostname of the publish address. This log message was quoted as an example of the problem:

[2018-07-02T00:45:20,095][INFO ][o.e.t.TransportService   ] [data-0] publish_address {10.0.0.6:9300}, bound_addresses {10.0.0.6:9300}

However this does not indicate that the hostname is lost. We simply don't show it. The same is true in the output from GET _nodes:

...
  "transport": {
    "bound_address": [
      "127.0.0.1:9300"
    ],
    "publish_address": "127.0.0.1:9300",
    "profiles": {}
  },
...

Similar to #32806, I think we should expose the hostname in these addresses to clarify that it's still there and to aid troubleshooting when setting up full certificate verification.

@DaveCTurner DaveCTurner added >bug :Distributed Coordination/Network Http and internode communication implementations labels Mar 12, 2019
@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-distributed

@andrershov andrershov self-assigned this Aug 15, 2019
andrershov pushed a commit to andrershov/elasticsearch that referenced this issue Aug 15, 2019
andrershov pushed a commit to andrershov/elasticsearch that referenced this issue Aug 15, 2019
andrershov pushed a commit that referenced this issue Aug 16, 2019
This commit adds CNAME reporting for transport.publish_address same way
it's done for http.publish_address.

Relates #32806
Relates #39970
andrershov pushed a commit that referenced this issue Aug 16, 2019
This commit adds CNAME reporting for transport.publish_address same way
it's done for http.publish_address.

Relates #32806
Relates #39970

(cherry picked from commit e0a2558)
andrershov pushed a commit that referenced this issue Aug 22, 2019
…erty is specified (#45662)

Follow-up of #45626.
Now we always output transport.publish_address with CNAME and log
deprecation warning if es.transport.cname_in_publish_address property
is specified.
This commit also adds a test which will fail once Elasticsearch version is
changed to 9, to make sure we remove the property when doing
reversioning.

Closes #39970
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>bug :Distributed Coordination/Network Http and internode communication implementations
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants