I recently ran into a curious issue on my Ubuntu system where using `sudo` would hang for several minutes after my VPN's kill-switch kicked in. I discovered that `sudo` tries to resolve the hostname to the system's Fully Qualified Domain Name (FQDN) by default on Ubuntu, since it's compiled with the `--with-fqdn` flag. At some point, I altered my system hostname, but `etc/hosts` didn't get updated automatically, leading to a mismatch with the new hostname. When my VPN's kill-switch blocked DNS requests, the hostname resolution failed, resulting in `sudo` hanging while it waited for a timeout.
I'm looking for thoughts on this situation:
- Should tools like `hostnamectl` or the Settings app automatically update `etc/hosts` when the hostname changes, or at least notify the user?
- Is it wise for `sudo` to have FQDN resolution enabled by default, as it is on Ubuntu? It seems like it introduces an avoidable point of failure for such an essential tool. For instance, Fedora doesn't activate this option by default, and Debian is thinking about removing it as well.
5 Answers
I agree with rebuilding, but I get that it’s not feasible for everyone. Usually, changing a DNS entry is all that’s needed rather than a hostname change.
That’s quite the issue! If you didn’t update `etc/hostname`, what exactly did you change? Were you modifying the static entries in `etc/hosts` or messing with DNS settings?
Exactly! Plus, not every system is a server; some are just workstations. It might not be as critical to change those.
It sounds like a classic DNS problem! I’ve had similar experiences, especially when logging in via SSH with faulty DNS. Always a headache.
Changing a hostname on an established server isn’t usually a good idea. It can lead to all sorts of complications like this. Typically, it's better to rebuild the system than to just change the hostname.
Related Questions
Can't Load PhpMyadmin On After Server Update
Redirect www to non-www in Apache Conf
How To Check If Your SSL Cert Is SHA 1
Windows TrackPad Gestures