Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
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

Exception calling "GetHostAddresses" with "1" argument(s): "No such host is known" #4

Closed
rfontijn opened this issue Mar 23, 2018 · 12 comments

Comments

@rfontijn
Copy link

When executing version 2.0.2 of this task. The error is raised: Exception calling "GetHostAddresses" with "1" argument(s): "No such host is known"

Back to 2.0.0 everything is normal.

@mmajcica
Copy link
Owner

It should be solved in version 2.0.5
Unfortunately, in case of reverse lookup not being possible in DNS, the code in 2.0.2 would fail. Now it is fixed by simply doing only a forward lookup.

@rfontijn
Copy link
Author

rfontijn commented Mar 23, 2018 via email

@mmajcica
Copy link
Owner

@rfontijn thanks!

@rerime
Copy link
Contributor

rerime commented Jun 28, 2018

Same problem in 2.0.6 with function Resolve-HostNameOrAddress

[System.Net.Dns]::GetHostEntry("10.0.0.1")
Exception calling "GetHostEntry" with "1" argument(s): "No such host is known"
At line:1 char:1
+ [System.Net.Dns]::GetHostEntry("10.0.0.1")
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : SocketException

@mmajcica
Copy link
Owner

Hi @rerime ,

I do not see this being an issue. Can you provide some more information?

If I run the following on one of my machines:

PS H:\> ([System.Net.Dns]::GetHostEntry("10.193.151.58")).HostName

nlwpr-bi4621-dtap-lb-md1-70-vip48.nvd.itb.intranet

DNS name of the host is resolved correctly.

Is that your host entry can't be resolved?

Aside of this, I was thinking of getting rid of it completely and imply the machine name or ipaddress as for all other standard MS tasks. I introduced that because I was trying to reach one of my servers via CNAME entry, but since the day one it just gave issues.

@rerime
Copy link
Contributor

rerime commented Jun 29, 2018

@mmajcica
You can try my example.
[System.Net.Dns]::GetHostEntry("10.0.0.1")
It is possible in networks that can be routed, but without records in dns.

If $ComputerName is IP address, why you try to connect by dns name?

 if ([bool]($ComputerName -as [ipaddress]))
        {
            $host1 = [System.Net.Dns]::GetHostEntry($ComputerName)
        }
        else
        {
            $host1 = [System.Net.Dns]::GetHostByName($ComputerName)
        }

        return $host1.HostName

With your current realization you convert IP to DNS, then try to connect. It fails if PTR doesn't exist.

@mmajcica
Copy link
Owner

@rerime

You are right, I'll take care of this issue later in the day. Expect to have a new version of the task ready for tomorrow.

@rerime
Copy link
Contributor

rerime commented Jun 29, 2018

@mmajcica
I created pull request)

@rerime
Copy link
Contributor

rerime commented Jun 29, 2018

@mmajcica
I further thinking about possible problem... if it resolves PTR and then connect to dns, it is possible that you connect to another IP address for records that has multiple records. Example, 9.9.9.9

HostName      Aliases AddressList               
--------      ------- -----------               
dns.quad9.net {}      {149.112.112.112, 9.9.9.9}

I guess better just return IP address like in my first pull request.

@mmajcica
Copy link
Owner

@rerime I'm not an expert on the matter, What you are suggesting sounds valid, but I have no chance to test it. I'll trust you on this one. Can you make another PR and also bump up the task version and try it?

@mmajcica
Copy link
Owner

Also MS task originally support only a IP address or FQDN:

https://github.com/Microsoft/vsts-tasks/blob/e5420d66ee4e6bcd3eeabbc0e6a336fbb70f67cc/Tasks/WindowsMachineFileCopyV2/task.json#L42

And it doesn't perform any check or resolution on it. If then mounting the New-PSDrive succeeds (and it's verification over the provided name succeeds)

https://github.com/Microsoft/vsts-tasks/blob/e5420d66ee4e6bcd3eeabbc0e6a336fbb70f67cc/Tasks/WindowsMachineFileCopyV2/RoboCopyJob.ps1#L173

For him it is all good.

So I would be keen to get rid of all of this name resolution.

@mmajcica
Copy link
Owner

@rerime Done, the new version is on the Marketplace.

Thank you for your contribution.

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

No branches or pull requests

3 participants