In Ubuntu, I have this line present in /etc/resolv.conf:
search example.com uk.example.com se.example.com
Now when I type host svr1.uk I get the record for svr1.uk.example.com
If I ping svr1.uk, I see pings from svr1.uk.example.com.
However, If I try to ping svr1.uk on a mac with the same search line present in /etc/resolv.conf I get "ping: cannot resolve svr1.uk: Unknown host" although I do see the record for srv1.uk.example.com from the host command.
Does any one have a way to make whichever lookup method ping uses properly resolve the domain suffixes in the order presented in /etc/resolv.conf?
This doesn't work for El Capitan anymore. If you upgrade to El Capitan you need to do this:
defaults write /Library/Preferences/com.apple.mDNSResponder.plist AlwaysAppendSearchDomains -bool true
Reboot
See the mDNSResponder man page for more details.
OSX does not use /etc/resolv.conf for DNS configuration. Instead check out networksetup.
To set the search domains:
sudo networksetup -setsearchdomains <network-interface> example.com uk.example.com se.example.com
To list the network interfaces/services:
networksetup -listallnetworkservices
On OS X 10.7-8
Look for these lines (Around line 16; 10.8 starts around line 17), and add the third line on the end, then save the file
<string>/usr/sbin/mDNSResponder</string>
<string>-launchd</string>
<string>-AlwaysAppendSearchDomains</string>
On OS X 10.9
This is still around line 17 and will need to be re-edited after an OS upgrade. The "-launchd" line won't exist, so just append the alwaysappend line.
Restart the responder:
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
On OS X 10.10.1
The file is now called com.apple.discoveryd.plist, and you need to add a very similar item below the ProgramArguments tag. Add in <string>--AlwaysAppendSearchDomains</string> (note, there are two hyphens) to the items in the tag. Run a similar pair of load/unload commands but referencing this new plist
Related
"dhcp35:~ user$" has appeared in my mac terminal instead of the usual "My-MacBook-Pro:~ user$".
Is this an indication of anything malicious?
I've been messing around cliclick to automate key presses from terminal, so not sure if this has resulted from my messing or from something I might have downloaded.
dhcp is documented as part of the terminal server user guide, but I can't work out the significance.
I suspect you are connected to a DHCP server that sets the hostname along with giving an IP assignment:
https://www.rfc-editor.org/rfc/rfc2132#section-3.14
One way to stop the hostname from changing is to do the following from a Terminal window (assuming you want to name your computer donald). You may need to preface these commands with sudo:
scutil --set ComputerName donald
scutil --set HostName donald
scutil --set LocalHostName donald
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
After upgrading to MacOS Sierra (10.12), my sudo command seems to be acting differently. See the following test case:
# Run in terminal pane #1: (should prompt for password)
sudo -v
# Run in terminal pane #2: (should NOT prompt for password)
sudo -v
The above works as expected on earlier versions of OS X. However, on Sierra, the second command prompts for the password again. It does not prompt for the password within the same terminal pane. This seems to only happen for the root user; the following works as expected on all OS versions including Sierra:
# Run in terminal pane #1: (prompts for password)
sudo -v -u "$USER"
# Run in terminal pane #2: (does not prompt for password)
sudo -v -u "$USER"
Looking at /ect/sudoers, the timestamp_timeout value is not set to 0. I've briefly looked over the changelog for 1.7 to 1.8 but could not come up with anything significant other than there being a mention of a policy plugin for Sierra when running sudo -V.
Can anybody help me figure out what has changed? I have a script that relies on the sudo timeout value for a keepalive and on Sierra it is prompting for the password constantly since it seems to no longer use a timestamp for the root user.
After a ton of searching and comparing the sudo configuration on older OS versions to Sierra's (sudo su; sudo -V), it seems that Sierra enables tty_tickets by default now, causing the issues mentioned above. As far as I can tell, this was an undocumented change. To fix, the following needs to be added to the /etc/sudoers file via running sudo visudo,
Defaults !tty_tickets
TLDR; BAD IDEA. This old behavior, while an option to sudo, is used as a default by NO OTHER UNIX-y OS that I have ever encountered. The reason being that it's trivial to exploit, and when exploited, the malignant code doing so will have full control of your system.
Original very long rant-y post, correctly pointed out to be blahdiblah:
LOL, this is funny. I came here from googling because I couldn't remember how I would change the old behavior to this new, correct one (used by every other UNIX-y OS out there). Hadn't even noticed my new Sierra Mac now behaved properly.
I wrote on the Mac forums earlier about this previous behavior which is a gaping security hole. I even supplied a three-line proof-of-concept script that would simply sit around (as a regular user) waiting for a sudo event to appear anywhere, then instantly gain root access to the system. I was booed out of the thread by the fanboys, then got banned from it from calling out lies. Seems Apple were listening, though. Good job, for once, Cupertino. Bad, BAD idea to try to get the old behavior back.
For reference, here's the three-liner. It doesn't do anything malignant, just adds a dummy file to the root of the filesystem once gaining sudo. Run it in a script (or just paste it somewhere which doesn't already have sudo), then either do a sudo in another terminal app/window or app which uses sudo (e.g. TrueCrypt/VeraCrypt or similar), then watch it work.
tail -f -n 0 /var/log/system.log | grep -m 1 -E 'sudo\[[0-9]+\]:\s+'$USER
echo "Gonna play around with root privs ..."
sudo touch /kilroy-was-here
I am getting a error while accessing the firefox using X11Forwarding.
[root#station2 ~]# firefox
KiTTY X11 proxy: wrong authorisation protocol attemptedKiTTY X11 proxy: wrong authorisation protocol attemptedError: cannot open display: localhost:10.0
setup the following values: /etc/ssh/sshd_config
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
** Installed the package**
#yum install xorg-x11-xauth
#yum -y install xauth
[root#station2 .ssh]# echo $DISPLAY
localhost:10.0
#mkxauth -c
adding key for station2.example.com to /root/.Xauthority ... done
export XAUTHORITY=$HOME/.Xauthority
This fix worked for me
There is a hard, if not even impossible, to find (by search engine) scenario that may may cause that error message.
Preliminary note: The topic of this answer is not to discuss if it is a safety
risc or recommondable at all to use a graphical desktop as root on an remote, display-less, webserver.
Scenario:
A remote internet connected Linux server S has assigned the domain
name example.com to it's public IP4-address 192.0.2.1.
The /etc/hostname file on S contains the single line example.
The /etc/hosts
file on S contains the line 127.0.0.1 localhost example.com example.
The (remote) ssh access to S is by (sshd-) configuration (on S) forbidden
for root by the line DenyUsers root in /etc/ssh/sshd_config, but
allowed for a dummy user user1. From a client computer C a ssh
connection, using the ssh parameter -X or -Y, is established to S
as user user1.
Then, in a remote terminal on S owned by user1,
if any X11 related command is tried to be executed as root, may it be by
su, then trying to start the X11 desktop environment
or, as in the concrete case executing a script containing
#!/bin/bash
su --preserve-environment -c "xfce4-session &" root
the error message
X11 connection rejected because of wrong authentication.
is output and the start of any X11 related program fails.
The DISPLAY variable of root's environment contains
example.com:10.0
then.
One solution to the problem is, in this special case, to modify the line
127.0.0.1 localhost example.com example
in /etc/hosts to
127.0.0.1 localhost
Solution: run the application with the same user you are SSHing.
I have also encounter such errors while using X11.
The source of my problem was that i used SSH with my own username (which was not root).
Then, once logged in i tired running stuff with X11 while doing "su" or doing "sudo",
the problem with that is that the SSH session is configured with your own username - e.g: Raj, but then you switch to user root which is not part of the X11 session.
So what you should do is simply try to run the application (firefox in your case) with the same user you started the X11 session.
Hope this helps.
Talel.
I ran into this running gvim over ssh -t -Y and the solution that worked for me was:
xauth add $(xauth -f ~<logon_user>/.Xauthority list | tail -1) ; export NO_AT_BRIDGE=1 # gvim X11 fix for remote GUI failure after su
I do not know where I stumbled on this answer so I cannot give credit to the author.
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.