[SERVER-34769] Server detects wrong FQDN when running Windows on AWS Created: 01/May/18 Updated: 27/Oct/23 Resolved: 19/Jun/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Networking |
| Affects Version/s: | 3.6.4 |
| Fix Version/s: | None |
| Type: | Bug | Priority: | Critical - P2 |
| Reporter: | David Golub | Assignee: | Andrew Morrow (Inactive) |
| Resolution: | Works as Designed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Operating System: | ALL |
| Steps To Reproduce: | Launch a Windows host of type windows-64-vs2015-small. Download and install MongoDB onto the VM and start a MongoDB process. From the Mongo shell, run the following command: db.runCommand({ serverStatus: 1, advisoryHostFQDNs: 1 }) The advisoryHostFQDNs field in the resulting document will contain the incorrect hostname. |
| Participants: |
| Description |
|
When running on a Windows box on AWS, the server will detect an FQDN of the form WIN-T1NSTPV2UDM.ec2.internal, which is not correct. The correct hostnames for such an AWS box are WIN-T1NSTPV2UDM and ip-10-122-16-56.ec2.internal. This bug is blocking us from being able to run our E2E tests on Windows on Evergreen, so please prioritize. CC justin.moses mark.benvenuto |
| Comments |
| Comment by Andrew Morrow (Inactive) [ 15/May/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
david.golub - Could you please clarify if the correct FQDNs are also returned, or are you only getting back the "invalid" one? Could you please post the complete contents of the advisoryHostFQDNs field returned by the runCommand posted above? | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by David Golub [ 14/May/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The failure is Windows-specific, and we're now beginning to run these tests on Windows, which we haven't done until now. It's not a regression. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by David Golub [ 11/May/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
The Monitoring Agent uses this field for discovery, so if it contains a hostname that can't be resolved, then it will attempt to monitor (and potentially automate) a host that doesn't exist and that it will never be able to reach. It's failing our tests, and I expect that it would cause problems for any customers who try to import an existing deployment if it's running on Windows hosts on AWS. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Andrew Morrow (Inactive) [ 11/May/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
david.golub - Perhaps we should take a step back and discuss what it is that you hope to do with this data? I really wouldn't want to filter out things based on resolvability: the goal of the feature is to return more information, not less, with an understanding some or all of the returned information may be incorrect. In theory we could return some sort of data structure that annotated each returned FQDN with whether or not it succeeded at forward resolution, but that would be format change to the command response, and I'm not particularly interested in adding new options to this command or more complexity to what it already does. The information returned is advisory, not reliable, as the command states. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by David Golub [ 10/May/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
How about performing a DNS lookup to ensure that the generated FQDN actually can be resolved and, if not, omitting it? If it's handled that way, discovery should fall back to the ordinary hostname, which the Monitoring Agent should be able to see. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Comment by Mark Benvenuto [ 01/May/18 ] | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
This is a tricky issue given that this is how the Windows hosts are configured. We try to get the FQDN so we avoid returning any DNS name that lacks a period "." so we would drop the NETBIOS name if we got it. On EC2 Windows hosts, we see do return WIN-T1NSTPV2UDM.ec2.internal because this is the host name + DNS suffix configured for the machine. On Linux machines, the hostname is configured as "ip-10-122-18-157" which produces the FQDN "ip-10-122-18-157.ec2.internal" but not on Windows. Detailed information:
If we dump the information via Powershell, we see that this is simply the DNS configuration of the machine.
|