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

Allow expressed url parameters to influence implicit servers. #409

Merged
merged 3 commits into from
Nov 25, 2018

Conversation

derekcollison
Copy link
Member

When a connected server returns information on other server, we can selectively use the information.

Two cases:

  1. When the connected server was expressed as a hostname and we are doing TLS but
    the other implicit servers are bare IPs. Use the hostname during TLS.
  2. When a connected server url had username and password, we can re-use those
    on implicit servers if it was not already defined.

Signed-off-by: Derek Collison [email protected]

When a connected server returns information on other server, we
can selectively use the information. Two cases here.

1. When the connected server was expressed as a hostname and we are doing TLS but
   the other implicit servers are bare IPs. Use the hostname during TLS.
2. When a connected server url had username and password, we can re-use those
   on implicit servers if it was not already defined.

Signed-off-by: Derek Collison <[email protected]>
@coveralls
Copy link

coveralls commented Nov 25, 2018

Coverage Status

Coverage decreased (-0.07%) to 93.045% when pulling f7e6452 on tls into 092fa9c on master.

Copy link
Member

@kozlovic kozlovic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

nats.go Outdated
}
// If its blank we will override it with the current host
if tlsCopy.ServerName == _EMPTY_ {
s := nc.srvPool[0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

0 for reconnects correspond indeed to the current url in the pool, but not in the case of initial connect. I wonder if instead of having nc.url for the current url we should have stored nc.srv for the current *srv, from which we can then access url or tlsName.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be a good idea. Let me look into that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confused. You did save current and replaced everywhere but still are using srvPool[0] here?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uug, too early in the morning. Will fix.

nats.go Outdated
// the current hostname we are connected to.
if nc.Opts.Secure {
if addr := net.ParseIP(u.Hostname()); addr != nil {
if caddr := net.ParseIP(nc.url.Hostname()); caddr == nil {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not big of a deal, but addURLToPool is called with implicit == true from the processing of INFO with an array of urls. So it could be that we do this parseIP check many times for the same nc.url. Wonder if this could be moved to processInfo instead?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You mean the one about the current connected correct? We could move it but we need the tlsName for when we create the *srv struct.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

processInfo() is the only one to call addURLToPool with implicit == true. processInfo runs under connection lock (when processing async INFO). The current nc.url cannot change while this processing is taking place, so I was suggesting that this net.ParseIP(nc.url.Hostname() be done once before the loop that calls addURLToPool(). But again, no big deal.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well I may look to hoist *srv instead of just url to nc.

@@ -0,0 +1,21 @@
# TLS config file
# Cert has no IPs, so we use an IP here to simulate a single hostname cluster.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Travis also has support to set custom hostnames which may help to simulate setup further https://docs.travis-ci.com/user/hosts/

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice I did not know that! Would prefer a test that can be run locally as well. What is best way to have a test understand if it is running on Travis?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we could check whether os.Getenv("TRAVIS") == "true" which is one of the default environment variables and skip locally if not defined for example.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point. For now I think we are ok, we are using cert with localhost and no IPs defined, so is testing what we want.

Copy link
Member

@kozlovic kozlovic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still using srvPool[0]?

nats.go Outdated
}
// If its blank we will override it with the current host
if tlsCopy.ServerName == _EMPTY_ {
s := nc.srvPool[0]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confused. You did save current and replaced everywhere but still are using srvPool[0] here?

@@ -649,3 +652,73 @@ func TestReconnectBufSize(t *testing.T) {
}
nc.Buffered()
}

// When a cluster is fronted by a single DNS name (desired) but communicates IPs to clients (also desired),
// and we TLS, we want to make sure we do the right thing connecting to an IP directly for TLS to work.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we use TLS?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

will fix.

Signed-off-by: Derek Collison <[email protected]>
Copy link
Member

@kozlovic kozlovic left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@derekcollison derekcollison merged commit a94ae76 into master Nov 25, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants