I was actually doing some quick labs exercise when I noticed this issue where is ping to an internal IP works but if I ping with machine name it does not work. Here is what I did:
a.) Create a GCP project. Leave all the default firewall rules in place
b.) Create a VM in us-central-1 (any region) call it - mynet-us-vm
c.) Create a VM in eu-west-1 (any region) - call it - mynet-eu-vm
d.) SSH to mynet-us-vm from the console
e.) Run this commands : ping -c 3 <Enter mynet-eu-vm's internal IP here>- It works
f.) Run this command: ping -c 3 mynet-eu-vm - Does not work! Getting below error
Getting Error:
"ping: mynet-eu-vm: Name or service not known"
For Internal DNS resolution to work there are multiple factors that affect this:
On the client Instance running ping the resolv.conf file must have the metadata server (169.254.169.254) as it’s nameserver and the search domains must be set similarly to the example on the documentation, if using a Google provided image this configuration should already be set correctly.
Additionally, verify the hostname registered for the Instance “mynet-eu-vm” this can be done by running curl against the metadata server, the output to this will be the full FQDN which will confirm whether the resolv.conf file should be set to Zonal DNS or Global DNS and if the hostname for the Instance is the same as the one being used with ping.
If running “dig FQDN #169.254.169.254” works but ping still fails this would mean that the Instance is trying to resolve against a different nameserver, or that the search list on resolv.conf is incorrect.
If the above steps fail I suggest raising a support case with Google Cloud Platform or opening a new Public Issue Tracker since following the steps provided does not result in the same behavior and likely it’s something specific to your setup.
Related
I'm in the process of testing GC DNS and have created zones and records. However, doing nslookup (windows/command line) times out when querying assigned Google NS directly:
> www.some_domain_A_record.com.
Server: ns-cloud1.googledomains.com
Addresses: 2001:4860:4802:32::6e
216.239.32.110
DNS request timed out.
timeout was 2 seconds.
DNS request timed out.
timeout was 2 seconds.
*** Request to ns-cloud-e1.googledomains.com timed-out
Does anyone have any advice/input on this?
Notes:
I am only using Cloud DNS for this project (no GCE/GAE/VM, etc.), essentially "just DNS". I'm looking to migrate from some existing DNS (only) provider to Google cloud DNS
This means resources (A, CNAME, MX, etc.) aren't necessarily related to any GC hosted app or service (some could be - e.g. Google Apps/Work, etc.). In other words "typical" DNS zone/records.
This is for an existing/live domain/zone
I have not made any changes at the registrar level (I'm testing first) and querying the google ns assigned for the zone directly
To SO community:
Completely understood that this isn't a programming question. Its just that this is the "Bronze" level support area for Google.
Update
Using Mac terminal actually succeeds
> server
Default server: ns-cloud1.googledomains.com
Address: 216.239.32.106#53
> gcloud-test.some_domain_I_have.com.
Server: ns-cloud1.googledomains.com
Address: 216.239.32.106#53
gcloud-test.some_domain_I_have.com canonical name = the_right_target.com.
Name: the_right_target.com
Address: 1.2.3.4
Will dig some more, seems something to do with Windows nslookup..weird...it's not some firewall, I can nslookup some other domain using whatever specific (or public) name server.
Update 2
Getting weirder - Windows (10 not that it should matter) on same Mac (vm/parallels) above works fine as well...
Update 3
As of today 9-24-2015 it seems the odd behavior on Windows nslookup (interactive mode) when querying your assigned Google ns directly is resolved.
Bottom line: All's good and running quite smoothly! To the Google Cloud I go :)
On (all*) Windows - it just seems that if you have/want to query your assigned Google NS directly, you have to do nslookup in non-interactive mode (aka "one liner") as shown below. You'll do this if you want to check/query resources before DNS propagation (after which, you don't really need to query your assigned NS directly).
Alternatively, you could nslookup interactive mode if you use the IP address of your assigned Google NS (sample also below).
*"all Windows" - meaning host/pc and OS. As above, Windows on Mac (VM/Parallels) is strangely unaffected by this weirdness - you can use nslookup interactive mode and query your ns directly just fine...Mac/OSX terminal is fine/unaffacted
Partial answer, scoped to Windows:
To make it work,
use nslookup in non-interative mode: nslookup name-of-resource the-google-ns
e.g. nslookup foo.com ns-cloud1.googledomains.com
or
use the IP address of the google ns in interactive mode:
c:\nslookup
> server 216.239.32.106
Default Server: ns-cloud-a1.googledomains.com
Address: 216.239.32.106
> the_resource_to_lookup
As to "why", I'll defer to network folk - haven't worn that hat in years -seems something to do with PTR/reverse lookup, but that's just a guess...
Looking at your inquiries, on your Windows you're using ns-cloud-e1.googledomains.com as the name server, however on your Mac you're using ns-cloud1.googledomains.com which is ns-cloud-a1.googledomains.com.
If both inquiries are for the same zone, then time-out on the first nslookup inquiry makes sense. Your workaround used a correct DNS server for the nslookup inquiry.
The solution is modifing your Windows DNS settings from ns-cloud-e1.googledomains.com to ns-cloud-a1.googledomains.com (same DNS settings of your Mac).
Using the Developers Console, under Cloud DNS you can verify what DNS servers your zone is associated to.
This is probably a very basic question for you, but I'm just getting into consul and for testing purposes, I wanna run multiple servers on my PC. For example, I run the first server with
consul agent -server -bootstrap-expect=1 -dc=dev -data-dir=/tmp/consul -ui-dir="c:/consul 0.5.2/dist"
and then I try to run the second server with
consul agent -server -data-dir=/tmp/consul2 -dc=dc2
but it returns
==> Error starting agent: Failed to start Consul server: Failed to start RPC lay
er: listen tcp 0.0.0.0:8300: bind: Only one usage of each socket address (protoc
ol/network address/port) is normally permitted.
What am I missing from my command?
You are launching two consul servers using mostly default values. In this case the problem is that you use default ports.
When you read the error message you will notice that your second consul server tries to bind to port 8300. But your first server is already using this port, causing the second server to fail at startup. (note: consul binds to a variety of ports, each having another purpose and default setting. Take a look at the documentation).
As suggested by LenW, you can use Vagrant to set your environment. You could follow the consul tutorial.
If you do not want to use vagrant or set up any virtual machines on your own. You could change the defaults of the second server.
If you are trying to simulate a production topology on your dev machine I would look at using Vagrant in combination with VirtualBox to simulate a couple of machines for testing.
I'm using ansible (ansible 1.9.0.1).
I'm running ansible-playbook to perform some operations on a target / remote machine using it's hostname.
My inventory file has an entry for a hostname i.e. appserver01.newdomainname.com
When I run ansible-playbook to just do a simple (hello world example), it doesn't resolve the hostname. If in the inventory file, I have the x.x.x.x IP, then it works!!!!
So, it seems like the nameserver or search in my source machine's /etc/resolv.conf is not resolving the remote hostname using it's fully qualified domain name i.e. appserver01.newdomainname.com
Is there any way I can call ansible-playbook and pass the new/local DNS server so that ansible can resolve the hostname (in the inventory file) from that DNS first (instead of reading / resolving it from the /etc/resolv.conf).
PS: I can't add this new/local DNS nameserver xx.xx.yy.zz to /etc/resolv.conf.
One way you could work around this would be to use the attribute ansible_ssh_host in your inventory file. This is not the same as connecting to your local DNS, but its kind of like transporting the DNS records with your inventory. This way you can still refer to your servers by their hostnames and you don't have to put anything in your servers hosts file. So it would look like this:
[myservers]
appserver01.newdomainname.com ansible_ssh_host=x.x.x.x
You could even move these mappings out to a host_vars file and keep a different list of IPs for each of your deployment environments.
If you deleted a VM on Google Compute Engine on a Centos 6 Cpanel server and then create it with the same disk, you often are assigned a new local IP address even if you kept the static IP. This does not properly update in the NAT configuration on Cpanel/WHM servers.
This stops any sites from working and the only way to fix it is manually edit the http.conf file. Inside Web Host Manager you can fix the public facing IP, but there is no place to edit the local IP. Does anyone know how to edit the nat configuration on centos 6 on Google Compute Engine to fix the local IP so that all new sites created will have the correct local IP in the http.conf?
Here is a pic of the current nat configuration on my Centos 6 server.
Here is a pic showing my correct local IP in Compute Engine, you can see it does not match the one Cpanel has, which causes the http.conf file to generate new virtual hosts with the wrong IP.
Its a configuration issue within WHM/Cpanel that can not be corrected with any configuration settings in the interfaces. I contacted Cpanel Support and they provided me with a command line shell script to run from root to fix the issue. It worked flawlessly:
# /scripts/build_cpnat
This resolved the issue, but they gave this additional info if that does not solve your problem:
If this does not resolve your issue, please review our NAT
documentation and ensure that your server is configured in a supported
1:1 NAT configuration:
http://documentation.cpanel.net/display/ALD/1%3A1+NAT
The Compute Engine does not allow you to create an instance with a specific network IP address. You will have to use a combination of routes and an instance's --can-ip-forward ability to add an IP address as a static network IP address that then maps to your desired virtual machine instance.
For example, if you want to assign 10.1.1.1 specifically as a network IP address to a virtual machine instance, you can create a static route that sends traffic from 10.1.1.1 to your instance, even if the instance's network IP address assigned by Compute Engine doesn't match your desired network IP address.
Take a look at this link: https://cloud.google.com/compute/docs/instances-and-network#staticnetworkaddress
The best and the simplest solution for this is to use the WHM/Cpanel IP Migration Wizard option to change the existing Private IP with the new one and then wait for few hours to make those changes propagate and you will see the new Private IP and Public IP in sync in your WHM platform.
I had the same issue with AWS and CentOS 7 hosting latest WHM/ cPanel. each time the instance restarts then a new private/ local IP address. I deleted cpnat from /var/cpanel/.
So I disabled the NAT, then I created another eth so I can configure it with static IP which is the Public IP, then for the main account only which own the hostname and domain name for WHM I assigned it to the local IP address, but as the local IP address keep changing so I created a script fires up at the start after each boot collecting the new local IP address and assign it automatically to the main account and if there is no new local IP address then the script exit without doing anything.
here are the steps been done:
nano /etc/sysconfig/network-scripts/ifcfg-eth0:cp1
and inside that file put the following: (change IPADDR & DNS)
DEVICE="eth0:cp1"
BOOTPROTO="static"
ONBOOT="yes"
IPADDR="13.54.100.XX"
NETMASK="255.255.255.0"
DNS1="172.31.0.2"
TYPE="Ethernet"
IPV6INIT="no"
now we would like this interface to stay upon reboot and start on the reboot so run:
ifup eth0:cp1
then restart the network service by:
service network restart
now disable NAT mode by deleting the file cpnat in /var/cpanel
now check the file /var/cpanel/mainip and make sure our external ip is there 13.54.100.XX
create the following file with nano:
nano /etc/init.d/fixdhcp
add the following to the file and save it:
#!/bin/bash
# # This script assigns available DHCP IP to ACCOUNT-NAME user on Reboot or Restart, please change ACCOUNT-NAME to the main WHM domain account name
# apache service will restart when done.
/scripts/rebuildippool
export mydhcp10=$(cat /etc/ipaddrpool)
echo $mydhcp10
# Exit if no available IPs
if [ "${mydhcp10}" == "" ]; then
echo "ipaddrpool is empty" && exit 1
else
echo "ipaddrpool is not empty"
fi
/usr/local/cpanel/bin/setsiteip -u ACCOUNT-NAME $mydhcp10
chmod +x /etc/rc.d/rc.local
echo finished now restarting services
/scripts/rebuildhttpdconf
/scripts/rebuildippool
/scripts/cleandns
/scripts/fixvaliases
/scripts/modify_accounts --theme=paper_lantern --all-users
/usr/local/cpanel/scripts/updateuserdomains
service httpd restart
make the file excutable:
chmod +x /etc/init.d/fixdhcp
add it to rc.d
nano /etc/rc.local
then add it like this:
/etc/init.d/fixdhcp
save then run:
chmod +x /etc/rc.d/rc.local
If it still won't change, try this:
(i.e. when you List Accounts you see the old internal IP listed for each account)
WHM -> List Accounts expand desired account (+)
=> Change IP Address
=> select the IP address (even if it is the same external IP)
=> click change.
repeat for each affected account.
output:
The remote dns zone is not consistent with the httpd.conf.
The current ip in httpd.conf is: 10.240.0.3.
The current ip in the dns zone is: 104.154.68.68!
104.154.68.68 will be switched to the new ip as well!
The local dns zone is not consistent with the httpd.conf.
The current ip in httpd.conf is: 10.240.0.3.
The current ip in the dns zone is: 10.240.0.2!
10.240.0.2 will be switched to the new ip as well!
Warning, serious database inconsistency. httpd.conf, local dns, and remote dns all
have different ideas about what the ip address of this site really is. They will now all be changed
to the new ip: 10.240.0.2!
Changed all instances of [10.240.0.3,104.154.68.68] -> [104.154.68.68] in dcmetroc.kellen.hosting
Changed all instances of [10.240.0.3,104.154.68.68] -> [104.154.68.68] in dcmetrocollaborative.org
Updating httpd.conf....Done
System has 0 free ips.
if you're using nginx, don't forget to rebuild vhosts in ngnix plugin!
I just needed to change the local IP with the new one in:
/var/cpanel/cpnat
/etc/hosts
/etc/ips.dnsmaster
I have confirmed with that it's not possible to get DNS Name and environment details (staging vs production) without certificate & management API.
However let's consider my case in that my startuptask(exe) consume REST service to post some data so in that REST service can i do some trick to get DNS name?
I have tried with following
HttpContext.Current.Request.UserHostName however it is same as
HttpContext.Current.Request.UserHostAddress
Please give me suggestion if anyone have you did this type of trick.
Update
Using HostName & HostAddress i am able to get IP of that webrole (confirmed with browser request) but when i try that with nslookup command then it says me that Non-existent domain
Does Azure not support reverse lookup?
Thanks in Advance.
After I study the above details I would say that using above trick, you are getting the external facing VIP address about your service.
Lets consider in that case it would be something as below and if you have port 80 configured with your application you could use this IP address in any browser to verify and you did:
65.52.14.112
Now let's run nslook on IP address and it sure returns what you said:
C:\myTools>nslookup 65.52.14.112
Server: router.belkin
Address: 192.168.2.1
*** router.belkin can't find 65.52.14.112: Non-existent domain
Now for a second lets consider you know the hosted service name (it is my service and I know the name) so lets try to use nslookup with that:
C:\myTools>nslookup azurevmassistant.cloudapp.net
Server: router.belkin
Address: 192.168.2.1
Non-authoritative answer:
Name: azurevmassistant.cloudapp.net
Address: 65.52.14.112
As you can see above the hostname resolves the IP address and that's it. Also you would need to understand in both of the above case you were hitting the Windows Azure loadbalancer not the service itself.
I am able to verify that as of now the Windows Azure does not support "reverse lookup" and if you think that is important it is great chance to let your voice heard and submit the request here: http://www.mygreatwindowsazureidea.com/pages/34192-windows-azure-feature-voting