Adding /etc/hosts entry to host machine on vagrant up - vagrant

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.

Related

Ubuntu terminal ssh to same ip after device changed

I ssh to a device that gets attached to a test bench with the following:ssh root#1.2.3.4
Because the actual device has been changed since the last time I connected to that IP I get:WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! all as expected. The warning tells me that I can easily fix this with ssh-keygen -f "/home/myuser/.ssh/known_hosts" -R "1.2.3.4"
I do find it repeating the same thing over and over, there must be some way to improve this. I know this IP and it is internal to my company.
I started working on trying to use something like !!:s/find/replace but the spaces in the replace is making my life difficult.
What is the easiest way to automate this, maybe create an alias?
Thank you
Jack
I asked a senior dev at my company and he suggested that I just update my ~/.ssh.config file. I added:
Host 1.2.3.*
User root
UserKnownHostsFile /dev/null
StrictHostKeyChecking no
No more having to copy and paste the line to update my known_host file

git ssh fails to access host but succeed when direct IP is used (Windows 10)

I am using git/bash in Windows 10 and try to clone a repository.
When I use the command: git clone username#hostname, I get:
ssh: Could not resolve hostname stbcmgit: Name or service not known
However, when I use a direct IP address instead of the hostname (git clone username#x.x.x.x), the access is successful and the clone starts.
Notes:
"known_hosts" file is located at c:\Users\myname\.ssh
The file is taken from my Linux account where everything works fine there.
The .ssh folder contains also the id_rsa and id_rsa.pub keys (copied also from Linux).
When I use 'ls $HOME/.ssh', I see these files listed.
Using Windows 10.
Thanks.
You should check /etc/hosts and add such a line if it doesn't exist:
x.x.x.x hostname
If the host's IP doesn't change, you can simplify the whole command by creating $HOME/.ssh/config like this
Host YourHost
HostName x.x.x.x
User username
IdentityFile ~/.ssh/id_rsa
PubKeyAuthentication yes
Now you can run these commands:
git clone YourHost:repo
ssh YourHost
In Windows 10 and after the latest updates concerning the "Windows Subsystem for linux" aka "Bash" now you MUST assign any desired hostname with its relative IP Address by editing this file:
C:\Windows\System32\drivers\etc\hosts
P.S: on your linux please check /etc/hosts and not the 'known_hosts' file
~/.ssh/config may contain such definitions.
These definitions contain port numbers also (I think /etc/hosts can't).

dnsmasq does not resolve directly specified name

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.

Mac OSX changing /etc/hosts has no effect even after killing mDNSResolver

I have not had a similar issue in Windows (10) and nothing I've searched on docs seems to indicate why, if this does not work, that that is the case
I open up terminal and edit /etc/hosts (which I've done many times on a PC and a few years back on an OSX too)
Just for grins if that doesn't work I type in sudo killall -HUP mDNSResponder
Then for more grins I reboot
This has absolutely no effect. Can anyone point me to why? Thanks.
UPDATE: The embarrassing fact of the matter is that the lines I entered in /etc/hosts were in reverse, i.e. domain first, as:
mydomain.com 192.168.33.10 #wrong
192.168.33.10 mydomain.com #what it should have been
The accepted answer, however, is well-written and appreciated.
I've seen two common problems with using /etc/hosts on macOS (/OS X):
Incorrect formatting: each entry in the /etc/hosts file must be an IP address followed by a space or tab, followed by the name, then a linefeed at the end of the line. Try printing the hosts file with cat -vet /etc/hosts to make normally invisible characters visible. Each line should look like one of these:
127.0.0.1^Iwww.example.com$
127.0.0.1 www.example.com$
(The "^I" is a tab, and the "$" is the linefeed at the end of the line.) It's also ok if the entry has multiple names listed (also separated by spaces or tabs).
If you see a "^M" (carriage return) just before the "$", you have DOS/Windows formatted text and you need to remove the carriage return(s).
Incorrect testing: Don't use the command-line tools dig, host, and nslookup, since they all test DNS directly and therefore bypass the /etc/hosts file. Browsers sometimes cache things, which can give misleading results. The "right" way to test the system's name resolution system is with the dscacheutil command:
dscacheutil -q host -a name www.example.com
...but since that's annoyingly verbose, I tend to just use ping, and see what address it says it's going to test.
I came across this thread to try and solve the same issue on macOS Catalina and was not successful. This is because macOS Catalina has another thing going; it will only make changes in the hosts file effective if you change them as the root user (this is not done with the sudo command) !!
By default there is not a root user on your system so here's a link with a step by step guide to do so:
https://support.apple.com/en-us/HT204012
then I was able to:
su
nano /etc/hosts
for more information:
https://discussions.apple.com/thread/250805304
Below steps worked for me
flushing DNS sudo killall -HUP mDNSResponder (or kill DNS in activity monitor and let it reload)
2.Changing read-write permissions of /etc/host file should be -rw-r--r-- .Use commands $ sudo chmod g+r /etc/hosts and $ sudo chmod o+r /etc/hosts
Adding entry u want to add in host file with ipxxx.xx.xx.com
moved these 2 lines in the end
255.255.255.255 broadcasthost
::1 localhost Administrators-MacBook-Pro.local
Step 1 again

Can we set easy-to-remember hostnames for EC2 instances?

I'm running a couple of standard Fedora instances on EC2. I feel the public hostnames of the instances assigned by Amazon are too weird and hard to remember. I'd like to change them to something short (like red/blue/green/etc).
Is there any draw back in doing this? And how do I set it up such that it persists after reboots?
Thanks.
Before you get started, try running hostname and hostname --fqdn and take note of what the responses are.
You can edit /etc/hostname and set a hostname, which will stick around after rebooting. You can force the hostname to be "reloaded" by using hostname -F /etc/hostname to read that value into the hostname. The bash prompt will change after you logout and login.
warning / note:
Yes, it is nice to have the hostname in the bash prompt set to something more useful than ip-123-123-123-123 but I've decided to leave mine (at least for now) because it seems like a lot of things really count on having the hostname on ec2 instances set in a standard way. After editing /etc/hostname and changing the hostname to webserver a lot of the services seems to fail because the hostname would not resolve, and apache wouldn't start. Next I edited /etc/hosts and added in
127.0.0.1 webserver
as the second line. Apache would then start but complained that it couldn't find the FQDN. I confirmed that running hostname --fqdn no longer worked.
Next I consulted man hostname and learned that while you can set the hostname it appears that the FQDN is what is returned via a DNS lookup.
THE FQDN
You can't change the FQDN (as returned by hostname --fqdn) or the DNS domain name (as returned by dnsdomainname) with this command. The FQDN of the system is the name that the resolver(3) returns for the host name.
Technically: The FQDN is the name getaddrinfo(3) returns for the host name returned by gethostname(2). The DNS domain name is the part after the first dot.
Therefore it depends on the configuration (usually in /etc/host.conf) how you can change it. Usually (if the hosts file is parsed before DNS or NIS) you can change it in /etc/hosts.
I think it might be possible to set the system / fool the system into return the FQDN, something like ip-123-123-123-123.ec2.internal even though the hostname is webserver but at this point it started to seem like more trouble than it was worth, and that for me to have a nicer bash prompt might cause a lot software and configuration problems down the road and so I decided to give up.
I also learned that a lot of amazon ec2 instances use something called cloud-init:
cloud-init is the Ubuntu package that handles early initialization of a cloud instance. It is installed in the Ubuntu Cloud Images and also in the official Ubuntu images available on EC2.
Some of the things it configures are:
setting a default locale
setting hostname
generate ssh private keys
adding ssh keys to user's .ssh/authorized_keys so they can log in
setting up ephemeral mount points
cloud-init's behavior can be configured via user-data. User-data can be given by the user at instance launch time. This is done via the --user-data or --user-data-file argument to ec2-run-instances
I also found this which talks about how the hostname is configured with cloud-init:
On EBS instances, a shutdown and later start would end up with a different IP address.
In the case where the user has not modified /etc/hostname from its original value (seeded by metadata's 'local-hostname'), then cloud-init will again set the hostname and update /etc/hostname.
In the case where the user has modified /etc/hostname, it will remain user managed.
Additionally, if /etc/cloud/cloud.cfg contains 'preserve_hostname' value set to a True value, then /etc/hostname will not ever be touched.
The interesting takeaway is that if you don't change the hostname the cloud-init package will keep it up to date for you.
If someone else has a workaround or can address some of the issues mentioned and help reassure that nothing will break on ec2 instances because of changing the hostname I would be happy to hear it.
Another way is to simply edit ~/.bashrc and prepend PS1 with the nickname of the machine.
Edit: perhaps more correctly, machine-wide, e.g. on the AWS Linux AMI (an example) (paste this into console or add to your arbitrary install .sh):
cat << EOF | sudo tee /etc/profile.d/ps1.sh
if [ "$PS1" ]; then
PS1="[\u#myinst1:\l \t \! \W]\\$ "
fi
EOF
Edit /etc/sysconfig/network as root.
Replace
HOSTNAME=localhost.localdomain
with
HOSTNAME=hostname.DOMAIN_NAME
Then, either reboot or run /etc/init.d/network restart
The server then should report its name as a FQDN.
From this site:
Change the hostname on a running system
On any Linux system you can change its hostname with the command hostname (surprised?)…
Here are some quick usages of the command line hostname:
$> hostname
without any parameter it will output the current hostname of the system.
$> hostname --fqd
it will output the fully qualified domain name (or FQDN) of the system.
$> hostname NEW_NAME
will set the hostname of the system to NEW_NAME.
You can also edit /etc/hostname (at least on Ubuntu).
To make sure it stays after a reboot in AWS, either add the command in /etc/rc.local so it runs when the machine starts.
There's also a way to set the hostname dynamically via USER_DATA:
USER_DATA=`/usr/bin/curl -s http://169.254.169.254/latest/user-data`
HOSTNAME=`echo $USER_DATA`
IPV4=`/usr/bin/curl -s http://169.254.169.254/latest/meta-data/public-ipv4`
hostname $HOSTNAME
echo $HOSTNAME > /etc/hostname
To change the system hostname to a public DNS name
Follow this procedure if you already have a public DNS name registered
Open the /etc/sysconfig/network configuration file in your favorite text editor and change the HOSTNAME entry to reflect the fully qualified domain name (such as webserver.mydomain.com).
HOSTNAME=webserver.mydomain.com
Reboot the instance to pick up the new hostname.
[ec2-user ~]$ sudo reboot
Log into your instance and verify that the hostname has been updated. Your prompt should show the new hostname (up to the first ".") and the hostname command should show the fully qualified domain name.
[ec2-user#webserver ~]$ hostname
webserver.mydomain.com
To change the system hostname without a public DNS name
Open the /etc/sysconfig/network configuration file in your favorite text editor and change the HOSTNAME entry to reflect the desired system hostname (such as webserver).
HOSTNAME=webserver.localdomain
Open the /etc/hosts file in your favorite text editor and add an entry beginning with 127.0.1.1 (on DHCP systems) or eth0's address (on static IP systems) to match the example below, substituting your own hostname. (127.0.0.1 should be left as the localhost line.)
127.0.0.1 localhost localhost.localdomain
127.0.1.1 webserver.example.com webserver
Reboot the instance to pick up the new hostname.
[ec2-user ~]$ sudo reboot
Log into your instance and verify that the hostname has been updated. Your prompt should show the new hostname (up to the first ".") and the hostname command should show the fully qualified domain name.
[ec2-user#webserver ~]$ hostname
webserver.localdomain
Note: You can also change the shell prompt without affecting the hostname. Refer to this AWS documentation.
Sure, you can do that if you have your own domain (setup a CNAME to point to the Amazon hostname). Otherwise, you're pretty much stuck with the one they give you (or an Elastic IP, if you set one of those up).
The /etc/rc.local solution worked for me for a basic hostname but does not give me a FQDN.
In my Linux AMI (a snapshot of other instance).. none of the above formula worked. Then, I simply changed HOSTNAME field in file: /etc/init.d/modifyhostname and did a normal reboot.
You will need to do multiple things to set the hostname:
hostname newname - sets the hostname, but is volatile
edit /etc/hostname - sets the hostname for the next reboot
edit /etc/hosts - to keep sudo from complaining
I put these together into a script and uploaded it as a gist:
https://gist.github.com/mnebuerquo/5443532036af8b48995547e2817dba85
sudo hostname *yourdesiredhostnamehere*
sudo /etc/init.d/networking restart
then the hostname is changed. On my server all other services like apache and postfix works. Server is Ubuntu 12.04 LTS

Resources