In general, we can find out the DNS server addresses we are using by cat /etc/resolve.conf. However, after dnsmasq is installed, the DNS server address becomes 127.0.0.1 in the file /etc/resolve.conf. How can I find out the real DNS server addresses in this case?
Well, recently I finally find out the way to see which DNS servers are using.
cat /var/log/kern.log | grep nameserver will show the DNS server configuration received by the NetworkManager.
nmcli dev show <IF> | grep DNS will also do that.
cat /var/log/syslog | grep dnsmasq will also tell you which upstream nameservers dnsmasq is using. This may be the most accurate way.
cat /var/run/NetworkManager/resolv.conf also works for me.
Related
I got a MongoDB instance running inside a container inside WSL2.
When I try to do a request in my browser at localhost:27017 it works even if it's display an error because I try to access to the db with a HTTP protocol.
But when I'm trying to access to my db from Compass with hostname localhost and port 27017, I got a timeout after 30000ms and I can't access to it.
Someone got an idea why, please ?
I was able to connect mongoDB instance only using WSL2 IP address.
You can get it by running this one inside WSL:
ip addr show eth0 | grep 'inet\b' | awk '{print $2}' | cut -d/ -f1
or this one in powershell on windows host:
[Regex]::Match((wsl -- ip addr show eth0), 'inet (?<IP>\d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3})\/').Groups["IP"].Value
Bad news: this IP changes on every WSL2 restart. There is a go-wsl2-host that adds a host for this IP and keeps it updated. But I never used it.
I made some research and can't find a solution, I'm starting to think this is not possible.
I'm running arp -a in my terminal and I'd like to get the hostnames of the LAN devices.
host x.x.x.x returns:
Host x.x.x.x.in-addr.arpa. not found: 3(NXDOMAIN)
nslookup x.x.x.x returns:
** server can't find x.x.x.x.in-addr.arpa: NXDOMAIN
Is there a way to do this?
arp -a does the reverse DNS by default on linux machines. On macOS I guess you will have to run nslookup on each entry returned by arp -a table.
I found a way thanks to #gordon-davisson who set me on the right path.
First I get the gateway IP with: route get default | grep gateway
Then for every LAN device I run: host LAN_IP Gateway_IP
This returns:
Using domain server:
Name: 192.168.x.x
Address: 192.168.x.x#x
Aliases:
x.x.168.192.in-addr.arpa domain name pointer LAN-host-name.
I parse the response to get the name displayed at the end.
Side note: it still doesn't display the LAN host-names with arp -a after that.
I have trouble with dnsmasq - it does not resolve directly defined name.
$ sudo dnsmasq -d -A /test/172.17.0.2 --log-queries &
dnsmasq: started, version 2.48 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus no-I18N DHCP TFTP "--bind-interfaces with SO_BINDTODEVICE"
dnsmasq: read /etc/hosts - 2 addresses
$ ping test
ping: unknown host test
What is wrong?
You only set up a server. Your system's resolver (which is used by ping, your browser, and all other applications on your machine) must first know that this server exists and that it should be used. This can be done by modifying /etc/resolv.conf. For first, make sure, this line is in that file:
nameserver 127.0.0.1
But beware: modern systems auto-generate this file and potentially overwrite your changes. So watch out for "DO NOT EDIT THIS FILE BY HAND" comments in that file and instead do what's recommended in the file.
Is it possible for one to modify files on the host machine during the vagrant up process? For example, adding an entry to the host machine's /etc/hosts file to avoid having to do this manually?
The solution is to use vagrant-hostsupdater
vagrant plugin install vagrant-hostsupdater
This plugin adds an entry to your /etc/hosts file on the host system.
On up and reload commands, it tries to add the information, if its not
already existant in your hosts file. If it needs to be added, you will
be asked for an administrator password, since it uses sudo to edit the
file.
On halt, suspend and destroy, those entries will be removed again.
OK, so now the guy sitting next to you at the coffee shop can most likely ssh to port 2222 (EDIT: changed on newer versions of vagrant, unless you explicitly enable external access) on your computer, login as vagrant with the insecure key, modify your Vagrantfile, since it's mounted read-write and owned by the vagrant user, insert arbitrary ruby code to run in the host environment, and now it looks like they've got root access on the host environment as well. Brilliant.
I hope people run firewalls on their development machines.
EDIT:
So after writing the above, I bugged the author of Vagrant, the default has been changed so that port 2222 is not open by default on the external interface. Big improvement (though still something to be careful of, since external access is often opened up for various reasons).
So, having put in effort to get the situation fixed since making this comment, I'm now getting down votes, apparently because the comment is out of date. Damn. It was correct when written.
EDIT:
In response to Steve Buzonas, the point is that if there's any likelhihood of the virtual machine being compromised then giving the vagrant up process elevated permissions represents a serious risk to the security of the host environment, and also being able to modify the /etc/hosts environment file is dangerous, even without general root access. As I've pointed out, vagrant's approach to keeping the VM secure is not particularly rigorous.
I don't want to depend on some plug in to vagrant. It should be standard feature in Vagrant!!!! Untill then I use a shell script to propagate VM's in my cluster of new VMs. The key lines are :
# Obtain the hostkey based on the IP-address and add it to the known_host list
ssh-keyscan -t ecdsa ${START}.${OFFSET} >> /home/vagrant/.ssh/known_hosts
# obtain the hostname, because you might not know it yet, with the IP address:
EXTERNAL_HOSTNAME=`ssh ${START}'.'${OFFSET} 'hostname'`
# obtain the key ot the new other VM based on hostname and also add to known_hosts
ssh-keyscan -t ecdsa ${EXTERNAL_HOSTNAME} >> /home/vagrant/.ssh/known_hosts
# so now you have the IP address and the corresponding hostname
# add to /etc/hosts without being asked for "yes/no"
echo ${START}'.'${OFFSET}' '${EXTERNAL_HOSTNAME} >> /etc/hosts
Where IPADRRESS is the IP address of the master VM in the cluster with several slave node VM's with succeedding ip-addresses. (IPADDRESS=IPADDRESS + 1 untill no successfull ping)
IPADDRESS=`ip addr show eth1 | grep 'inet ' | cut -d ' ' -f 6 | cut -d '/' -f1`
START=`echo ${IPADDRESS} | cut -d '.' -f1,2,3`
OFFSET=`echo ${IPADDRESS} | cut -d '.' -f4`
And then I loop trough the next IP addresses until no more succesfull pings.
I do not want to hardcode anything (ip-address or hostname), but to find out itself.
Resulting /etc/hosts file (after
sort /etc/hosts | uniq > /tmp/hosts.uniq && sudo sh -c 'mv /tmp/hosts.uniq /etc/hosts'
:
[vagrant#master ~]$ cat /etc/hosts
127.0.0.1 localhost localhost.localdomain localhost4 localhost4.localdomain4
127.0.0.1 master.RHEL70.local master
192.168.1.50 master.RHEL70.local
192.168.1.51 node01.RHEL70.local
192.168.1.52 node02.RHEL70.local
::1 localhost localhost.localdomain localhost6 localhost6.localdomain6
Previously I didn't know how to vagrant edit my etc/host file. But when i reinstalled window and vagrant, this feature disappeared.
Working on a shell script that takes a machine name as an argument and then determines if the host is on the local network (same network as the machine that ran the script).
How can I get the IP address from the machine name? Once I get that I should be able to compare that IP with the local one to see if they're on the same subnet.
You can use nslookup (http://linux.die.net/man/1/nslookup), dig (http://linux.die.net/man/1/dig) or host (http://linux.die.net/man/1/host) command-line utilities.
For example, here is the result of running host for getting A-records for stackoverflow.com from DNS server:
$ host -tA stackoverflow.com
stackoverflow.com has address 69.59.197.21
What do you mean by local network? subnet or (windows) domain or within LAN?
You may also have a look at traceroute utility.