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
Related
I tried to use /etc/hosts file to redirect some websites to localhost.
To do so, I opened it in terminal using sudo nano /etc/hosts then I modified the file, and saved it. As the last step I flushed the DNS cache with sudo killall -HUP mDNSResponder.
Here's what my hosts file looks like:
$ cat /etc/hosts
##
# Host Database
#
# localhost is used to configure the loopback interface
# when the system is booting. Do not change this entry.
##
127.0.0.1 somethig.com
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
This simply doesn't work. I tried to reboot, without luck. I also did a lot of research but did not find any working answers on the internet. Does the OS still use this file, or will this never really work?
I'm using macOS 10.13.
I believe that you need to also override the IPv6 address for "something.com". Do this by adding the additional line "::1 somethig.com". So far as I can figure out, restarting Safari is also required. (You may also need to flush the DNS cache via the method you mentioned.)
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.
I've tried to run my first objective-c code in Xcode... Compilation process was successfully, however an error returns " invalid host string: 'localhost' ".
After some Googling, I found out and connected the points that it might had something to do with the hosts file I recently deleted.
Now I cannot recreate the /etc/hosts through terminal using:
sudo cat >/etc/hosts <
#
Host Database
#
localhost is used to configure the loopback interface
when the system is booting. Do not change this entry.
#
127.0.0.1 localhost
255.255.255.255 broadcasthost
::1 localhost
fe80::1%1o0 localhost
EOD
sudo: /private/etc/sudoers is mode 0666, should be 0440
Thanks in advance for any workaround.
You have broken your system by making inappropriate changes.
First, you need to fix the permissions on /etc/sudoers. You might try opening Disk Utility, selecting the system volume, and clicking Repair Disk Permissions. I am not sure that will change the sudoers permissions. If it does not, reboot your system and immediately press and hold the Command and S keys. This boots to single-user mode. When the command prompt appears, enter these commands:
mount -uw /
chmod 0666 /etc/sudoers
reboot
When the system boots, your sudo command might be working again, if you have not otherwise broken it. At this point, you may be able to recreate /etc/hosts. In addition to restoring its contents, you may need to set its ownership and permissions:
sudo chown root:wheel /etc/hosts
sudo chmod u=rw,go=r /etc/hosts
You could also restore /etc/hosts while in single-user mode, rather than booting normally and using the sudo command. Before the reboot command, use cat (or cp to copy from a file you prepared previously) to recreate /etc/hosts, then execute the chown and chmod commands (without sudo), then reboot.
I cannot guarantee these commands will suffice or that there are no errors; diagnosing problems such as this remotely is troublesome.
Stop tinkering with your system without making backups that you know work or taking other steps to be able to revert your changes.
I've been trying to figure out how to use postfix on my Mac and something has gone horribly wrong and I can't seem to fix it.
I believe the problem is related to starting Postfix.
Basically, the Mac seems to refuse to change its hostname. In bash, the user appears as "admin#(null)", if I type 'hostname' I'm given "(null)" also.
Changing the hostname in Sharing from System Preferences causes the second example to change (where it says, for example, "Other users can access shared folders on this computer, and administrators all volumes, at afp://null/ or “lion2”.") but the first stays as null.
I've even tried /etc/hostconfig manually setting hostname but nothing works.
Is there somewhere else the hostname is trying to be set but is perhaps corrupt? Or contains an invalid character or something?
This is causing Postfix not to work and report:
postfix: warning: valid_hostname: invalid character 40(decimal): (null)
postfix: fatal: unable to use my own hostname
Please, I really hope someone can help me fix this. I've been trying for hours now.
Cheers,
Scott
Have you tried scutil?
sudo scutil --get pref will show the current value and sudo scutil --set pref name will set the value to name. pref can be one of these:
ComputerName The user-friendly name for the system.
LocalHostName The local (Bonjour) host name.
HostName The name associated with hostname(1) and gethostname(3).
Here's what I get on my machine:
$ sudo scutil --get ComputerName
SteveBook2
$ sudo scutil --get LocalHostName
SteveBook2
$ sudo scutil --get HostName
HostName: not set
You should have tried running /bin/hostname directly to set the hostname on the unix/bsd layer, the values from scutil are SystemConfiguration settings which is a higher layer that unix is oblivious to.
It is perfectly normal for sudo scutil --get HostName to return not set even if running /bin/hostname shows you a hostname.
To set the hostname run sudo hostname Foo.bar (this is basically identical to sethostname() BSD call in the code given by another answer)
Optionally you could then run sudo scutil --set HostName Foo.bar to keep the SystemConfiguration settings in sync
NOTE:
The HostName in SystemConfiguration can be different from the LocalHostName and ComputerName , it can also be different from what /bin/hostname returns but it is best that they are all in sync, so you could also do :
sudo scutil --set LocalHostName Foo
sudo scutil --set ComputerName Foo
All other answers and help was much appreciated, however after much investigation, the problem appears to lie with my router and iMac: router not allowing the iMac to change its hostname client-side OR possibly sending a weird hostname to the iMac for it to use.
If you run this tiny program before starting postfix, does it work?
#include <unistd.h>
int main(int argc, char* argv[]) {
char host[] = "newhostname";
sethostname(host, sizeof(host));
return 0;
}
I don't presume to know what else might depend upon your old hostname -- do some testing on all your services after running this.
Details at: http://developer.apple.com/library/mac/#documentation/Darwin/Reference/ManPages/man3/gethostname.3.html
Update
To compile and run this little program, save its contents to a file (/tmp/newhostname.c will do) then run:
cd /tmp
make newhostname
sudo ./newhostname
At least I assume your make(1) knows how to compile from C sources to runnable binaries with default rules.
If the compiler isn't already installed maybe someone else will have a better idea.
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