sudo fails if it cannot resolve the local hostname and no MTA is installed

[Manuel López-Ibáñez]

On behalf of Adam Williamson [*]

adamw@ubuntu510:~$ sudo scp 192.168.2.7:/etc/hosts /etc

adamw@ubuntu510:~$ sudo nano /etc/hosts

sudo: unable to lookup ubuntu510 via gethostbyname()

…yeah, sudo, it’s all very clever until someone loses an eye!

I have a bunch of entries in /etc/hosts because of having four local systems plus a bunch of VMware machines etc. So now when I set up a new VMware machine I just copy the /etc/hosts from the real machine over to the VM then edit a couple of lines to match the VM, instead of re-editing it all from scratch. Only, as you can see, this utterly breaks Ubuntu…all I need to do to fix the sudo problem is edit /etc/hosts so 127.0.0.1 is ‘ubuntu510′ (the name of the VM) rather than ‘zen’ (the name of the real machine), but I can’t do it, because sudo doesn’t work…

the only way out of this that I can see is single-user mode or the recovery console. Not too smart! Surely sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on?

[*] Originally from http://www.happyassassin.net/2006/02/24/how-to-break-ubuntu-in-thirty-seconds/,

If you consider that this is relevant and worth discussing, we can add Adam Williamson to the conversation. Otherwise, just mark it as invalid and forget it.

TEST CASE:
 - This only works (i. e. fails) on a system where /usr/sbin/sendmail does NOT exist (standard Ubuntu installation)
 - open a terminal and do "sudo -i" to get a root shell; do "hostname foo"
 - open another terminal, and try "sudo ls". Hardy final will fail with "unable to resolve host foo" and not run the ls.
 - upgrade sudo to the hardy-proposed version and attempt the same. sudo should still complain, but run the ls command.

[Martin Pitt (pitti)]

I don't regard this as a sudo bug; not being able to resolve your own host name will cause you more trouble than just that.

However, I agree that sudo doesn't need to look up the hostname IF the relevant host part in sudoers is "ALL" anyway.

[Moley Harey (moleyharey)]

I have experience a similar problem, by mistake I removed the hostname of my machine and it was automatically set to 'none', I re-started my computer and then I could not perform any task using sudo cause all the time I received the error: sudo: unable to lookup (none) via gethostbyname()

I had to re-start in rescue mode and add manually as root the correct hostname in the /etc/hostname and /etc/hosts files

Why does sudo need to perform a 'gethostbyname()'?

[jpkotta (jpkotta)]

Related bug: https://launchpad.net/bugs/19553

From what I understand, sudo can perform commands on several different hosts, hence it needs to know what host it's on.

Personally, I keep the root account enabled, because I don't trust sudo.

[Manuel López-Ibáñez (manuellopezibanez)]

Does sudo need to know what host it's on in order to perform commands on the local host?

(Keeping the root account enabled is not a solution because that is not how Ubuntu currently works.)

[Manuel López-Ibáñez (manuellopezibanez)]

Another related bug: https://launchpad.net/bugs/19775

[usen (usen68)]

Yes,I just have experience this problem.And I come here for help,but I can't get help.If you had a solution,please tell me.Thanks.

[harcesz (harcesz)]

just updated to 8.04 and that either messed up my hostname or it's not good for sudo anymore, I'm a bit confused at the moment

[Manuel López-Ibáñez (manuellopezibanez)]

@harcesz

The forums are a better place to get help. Launchpad is for reporting bugs when you find one. Nonetheless, you should be able to boot in rescue-mode and edit /etc/hostname and /etc/hosts files. If you need instructions on how to do this, use the forums.

[Dorin Lazăr (dorin-lazar)]

Perhaps sudo should try to use the name from /etc/hostname when gethostbyname fails? It looks quite simple to do that, and assume that you'll have there 127:0.0.1 (in both IPv4 and v6)?!?!?!

[Steve Langasek (vorlon)]

To clarify, the reason that sudo looks up the local hostname is that /etc/sudoers is designed to be shareable between multiple hosts. (/etc/hosts is too, but this doesn't work if you share an /etc/hosts that gives you no way to look up your own hostname.) In order to know which of the commands in /etc/sudoers are permitted on the present machine, you must be able to figure out which machine is the present machine.

This can include the stacking of more specific *deny* rules together with rules that allow other access on all hosts; so even if sudo were fixed to be more lenient, the most lenient it could be is to discard all rules past the first non-ALL "host" spec. That doesn't prevent fixing this issue for the default Ubuntu /etc/sudoers, but it does show that the requirement for the host lookup is not spurious.

[Dorin Lazăr (dorin-lazar)]

I don't know how this sharing is supposed to be done, but whatever the usecase for it, denying user login because the local hostname cannot be resolved should definitely not be allowed here. The reason that I don't think you need to lookup the hostname is because the hostname is specified nowhere in the sudoers file, so it's wrong to simply lookup something that is not specified there. Perhaps it was easier to have a general approach of this matter, but you do have to admit the fact that sudo is looking up something that shouldn't be looked up. If we look a bit at the results (the machine being locked up for management, and a reboot required), I think that this general approach simply failed, and should be updated. Just my 0.02€.

[Alexander Rødseth (alexanro)]

I have a wirless PCI card that is only partially supported in Ubuntu. During the installation and trial of drivers for that card, it has happened several times that sudo just stopped working, in the same manner as described here. This is highly frustrating. If I could "touch /etc/sudo_only_on_this_machine", or something similar that would tell sudo that I was only using it on one machine, I would be happy. In fact, this should be the default.

[Martin Pitt (pitti)]

I tried to reproduce this. I opened two terminal windows, and did "sudo -i" in one of them to get a root shell (#), the other is a normal user shell ($)

$ sudo id
[sudo] password for martin:
uid=0(root) gid=0(root) Gruppen=0(root)
0 martin@donald:~
$ sudo -k

so by default, sudo works. Now let's mangle the hostname:

# hostname foobar

On Dapper I now get:

$ sudo id
sudo: unable to lookup foobar via gethostbyname()

while on current Hardy I get:

$ sudo id
sudo: unable to resolve host foobar
[sudo] password for martin:
uid=0(root) gid=0(root) Gruppen=0(root)

i. e. it still warns me, but doesn't fail any more. Now, when I reset the hostname with

  # hostname `cat /etc/hostname`

everything works again on both dapper and hardy.

So this seems to be fixed for me. However, some of the recent duplicates (like bug 197494) seem to indicate that it is still a problem in hardy.

I sanyone actually able to reproduce this? Can you please post a recipe here?

For the record, I'm using the default sudoers:

$ sudo grep -v '^#' /etc/sudoers | grep -v '^$'
Defaults env_reset
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL

Or, asked the other way round, can you please check if it is fixed for you as well on current Hardy?

Thanks in advance to all!

[mon (javiermon-deactivatedaccount)]

Hi
Yesterday I did a dist-upgrade from gutsy, I haven't touched my sudoers file:

sudo grep -v '^#' /etc/sudoers | grep -v '^$'
Defaults !lecture,tty_tickets,!fqdn
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL

I found the bug and had to add a manual entry in etc/hosts:
127.0.0.1 cube

This happens both on my laptop and desktop computer (both upgraded from gutsy to hardy)

thanks

[mon (javiermon-deactivatedaccount)]

Hi

Changing
Defaults !lecture,tty_tickets,!fqdn
to
Defaults env_reset

and now it works as martin says

thanks

[Martin Pitt (pitti)]

kmon [2008-03-13 20:49 -0000]:
> Changing
> Defaults !lecture,tty_tickets,!fqdn
> to
> Defaults env_reset
>
> and now it works as martin says

Aah - so it only happens if fqdn is switched off? Interesting, since
that should actually be the case when sudo does *not* use
gethostbyname and thus not care about broken hostnames. I'll give this
a try, thanks for the hint.

[Martin Pitt (pitti)]

I tried to change sudoers to "Defaults !lecture,tty_tickets,!fqdn" and get the same sudo behavior, i. e. it warns, but does not fail. Thus I can still not reproduce the bug in Hardy. Can anyone else?

[B. Clausius (barcc)]

    I can reproduce the bug in Hardy:

barcc:~$ sudo grep -v '^#' /etc/sudoers | grep -v '^$'
Defaults !lecture,tty_tickets,!fqdn,timestamp_timeout = 15
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL

root:~# hostname foobar

barcc:~$ sudo id
sudo: unable to resolve host foobar
    It warns and fails

    But if i start aptitude ->Actions->Become root, i get:
barcc:~$ aptitude
sudo: unable to resolve host foobar
[sudo] password for barcc:
    And now in aptitude i am root.

    Now i changed sudoers:
barcc:~$ sudo grep -v '^#' /etc/sudoers | grep -v '^$'
Defaults env_reset
root ALL=(ALL) ALL
%admin ALL=(ALL) ALL
    But i get the same results
barcc:~$ sudo id
sudo: unable to resolve host foobar

[asmoore82 (asmoore82)]

I can confirm similar behavior on Hardy Alpha6 to what's shown above, _but_ I say that there is no bug here.

The behavior stems from the fact that the hostname is preset in 3 locations:
1. "/etc/hosts" 2. "/etc/hostname" which, in turn, sets the precedent for 3. The kernel itself and/or "the Environment"
If you change the hostname from within the `network-admin` tool, you have no issues with `sudo`
_and_ the tool warns you that your system will be in an inconsistent state until the next reboot.

Steps to confirm the lack of a bug:
I, too, use 2 terminals, 1 in a `sudo -s` session as a failsafe and a second to test for breakage of `sudo` in general.
The commands are posted in the order I execute them and you can use the leading '$' or '#' to distinguish between the 2 terminals:

-----
# hostname
pickles
$ sudo true
[sudo] password for asmoore:
$ sudo -k
# sed -i "s/pickles/foobar/g" /etc/hosts
$ sudo true
sudo: unable to resolve host pickles
# hostname foobar
$ sudo -k
$ sudo true
[sudo] password for asmoore:
-----

Observe that `sudo` went from working, to "broken", to working again as I restored the system to a semi-consistent state
by having `hostname` and "/etc/hosts" agree. Note that, had I rebooted right after, `sudo` and many other things would've
been "broken" again because "/etc/hosts" and "/etc/hostname" do _not_ agree; this, too, is _not_ a bug.

The original "bug" reporter needs to understand that:
1. His system is broken simply because he broke it.
2. Freedom means "free to do anything, even if it is destructive."
3. A "blog post" does not a "bug report" make.

IMHO, this bug report is akin to "`sudo rm -rf` hosed my system!"

Adam sM, "ubuntuforums.org" member, my first "launchpad.net" posting.

[asmoore82 (asmoore82)]

Sorry for the double-post, but in a more direct response to the YELLING in the topic:

If sudo behaved differently, it would become vulnerable to some sort of `HOSTNAME=foobar sudo ...` attack.

[Martin Pitt (pitti)]

asmoore82 [2008-03-15 19:17 -0000]:
> $ sudo -k
> # sed -i "s/pickles/foobar/g" /etc/hosts
> $ sudo true
> sudo: unable to resolve host pickles

In your comment further down you said that this broke. Why do you
think so? The -k actually worked, since in the next sudo command you
had to enter your password again:

> # hostname foobar
> $ sudo -k
> $ sudo true
> [sudo] password for asmoore:

I advise you to test sudo with something that gives visual feedback
about whether it worked or not (which is not the case with 'true' and
-k). I recommend "sudo id" and verifying that you get output adequate
for root (user id 0).

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

My 5 today: #198129 (tzdata), #189854 (gst-pulse), #200739 (bind9),
#200785 (xserver-xorg-video-nv), #189995 (langpack-locales, belocs-
locales-bin)
Do 5 a day - every day! https://wiki.ubuntu.com/5-A-Day

[asmoore82 (asmoore82)]

@Martin

> $ sudo true
> sudo: unable to resolve host pickles

^^ This is where sudo was broken. I can re-run the test using `sudo id` when I get back to my Hardy box;
But, again, I feel there is no bug here:
Not being able to resolve the local hostname is a broken and unsupportable state for any *X system.

[B. Clausius (barcc)]

@asmoore82
> But, again, I feel there is no bug here:
Maybe you are right if you have a new installation of hardy. But consider there is a different behavior in hardy compared to previous releases (e.g. gutsy) where a different hostname in /etc/hostname and /etc/hosts is accepted. If this is kept there is an gutsy-hardy update problem.

[Alexander Rødseth (alexanro)]

sudo does not work by default if your network card is only partially supported, as opposed to logging in with root.

[asmoore82 (asmoore82)]

> But consider there is a different behavior in hardy compared to previous releases (e.g. gutsy)
> where a different hostname in /etc/hostname and /etc/hosts is accepted

accepted by `sudo` or accepted "in general" ??

I can get away with that on my Gutsy box, but it _is_ a misconfiguration and
causes certain programs(such as `gnome-terminal`) to take much longer to open.

[Dorin Lazăr (dorin-lazar)]

Just because applications like gnome-terminal or mc are broken doesn't mean that on your local box there should definitely be no resolving done. Or if there is some kind of resolving done, resolve 127.0.0.1 or localhost (just to be not so IP-minded)
But I see NO reason for sudo to make any DNS resolving unless necessary. And it's not necessary for any kind of local work. There is no sane use-case for sudo to resolve the localhost unless enforced by policy, but even then the policy is wrong.
Why is it wrong? You're on your local machine, you definitely need no network working, there definitely shouldn't be ANY networking done, and any networking done during local privileges raising should be seen as a security threat.
mc is wrong to resolve hostnames during startup because, well, it doesn't start with a network view. gnome-terminal is simply broken if it needs to resolve any kind of hostname during startup.
Just because it's a general solution doesn't mean it's a good solution. What's local should stay local, and I might suspect a security flaw in sudo if it does DNS resolving for localhost :)

[asmoore82 (asmoore82)]

@Dorin
> Perhaps sudo should try to use the name from /etc/hostname when gethostbyname fails?
> It looks quite simple to do that, and assume that you'll have there 127:0.0.1 (in both IPv4 and v6)?!?!?!

You seem to be confused.

That's _exactly_ what `sudo` is doing: it's using the known _local_ hostname which would've been set in "/etc/hostname."
It has to resolve this _local_ hostname and does so with the _local_ "/etc/hosts" file.

> gnome-terminal is simply broken if it needs to resolve any kind of hostname during startup.

you are aware that the X Window System is a client-server setup over the loopback interface aren't you?!?
Apps should _always_ be able to resolve the _local_ hostname and some have come to rely on this fact.

@everyone
*_There is no bug here_*
The original "bug reporter" in the _blog_ overwrote his "/etc/hosts" file and in doing so broke his _local_ host configuration.
`sudo` errors were merely the first symptom he noticed of his newly broken system.

*_To prove that something is wrong with sudo_*
you would need to show a situation where `sudo` does _not_ work but the following does:

~$ grep `hostname` /etc/hosts

***Revised Proof: Same machine, 2 terminals; root breaks and fixes the system; asmoore tests sudo:

-----
asmoore@pickles:~$ grep `hostname` /etc/hosts
127.0.1.1 pickles
asmoore@pickles:~$ sudo id
[sudo] password for asmoore:
uid=0(root) gid=0(root) groups=0(root)
asmoore@pickles:~$ sudo -k

root@pickles:~# sed -i "s/pickles/foobar/g" /etc/hosts

asmoore@pickles:~$ grep `hostname` /etc/hosts
asmoore@pickles:~$ sudo id
sudo: unable to resolve host pickles
asmoore@pickles:~$ sudo -k
sudo: unable to resolve host pickles

root@pickles:~# hostname foobar

asmoore@pickles:~$ grep `hostname` /etc/hosts
127.0.1.1 foobar
asmoore@pickles:~$ sudo id
[sudo] password for asmoore:
uid=0(root) gid=0(root) groups=0(root)
asmoore@pickles:~$ sudo -k

root@pickles:~# hostname `cat /etc/hostname`
root@pickles:~# sed -i "s/foobar/pickles/g" /etc/hosts

asmoore@pickles:~$ grep `hostname` /etc/hosts
127.0.1.1 pickles
asmoore@pickles:~$ sudo id
[sudo] password for asmoore:
uid=0(root) gid=0(root) groups=0(root)
asmoore@pickles:~$ sudo -k
-----

Adam sM

[Thomas Butter (tbutter)]

Of course it is no bug in the sense that it breaks any specified contract, but ubuntu does not have a password for root and sudo is the only way to repair a wrong /etc/hosts. On systems with root passwords this would be a non-issue.

[Dorin Lazăr (dorin-lazar)]

@asmoore
I am not confused at all.
I actually am certain that raising privileges on the local machine should not require networking bits at all. There is no real reason why that should be done. No real dependency of the network, unlike the X system that is actually meant and thought for networking. That, however, doesn't mean that other applications that use X are broken. If gnome-terminal starts in 60 seconds and xclock in .001 seconds, and you blame it on X, you might very well have a diagnosis problem.

Going back to this bug: this happened to me when I upgraded to one of the alphas of ubuntu. However, instead of seeing only the problem in the network settings, I want to point the design mistake in sudo. What would've happened if my hostname was actually other machine's? does that mean that I could've sudo stuff on other machine even if the local policy disallowed it?
And once again, my point of view: raising privileges on the LOCAL machine should NOT require networking bits. NEVER.

[Martin Pitt (pitti)]

Dorin Lazăr [2008-03-20 7:44 -0000]:
> Going back to this bug: this happened to me when I upgraded to one
> of the alphas of ubuntu. However, instead of seeing only the problem
> in the network settings, I want to point the design mistake in sudo.
> What would've happened if my hostname was actually other machine's?
> does that mean that I could've sudo stuff on other machine even if
> the local policy disallowed it?

If you configure your local sudoers in a way that you have privileges
on a machine 'foo', and no privs on a machine 'bar', and you change
your hostname from 'bar' to 'foo', then yes, you'll get privileges.
That's exactly what host-based sudo configuration is meant to do.
(This is not the default, but it's convenient for sharing sudo
configuration amongst multiple machines).

[Dorin Lazăr (dorin-lazar)]

Convenient, no doubt - but I see it as a positive side effect of a defective behaviour rather than something intentional and positive.

[asmoore82 (asmoore82)]

> I actually am certain that raising privileges on the local machine should not require networking bits at all.
> There is no real reason why that should be done. No real dependency of the network,
> unlike the X system that is actually meant and thought for networking.

In your own terms: The `sudo` system _IS_ "meant and thought for networking!"
And even so, resolving the _LOCAL_ hostname is not "networking bits."

> And once again, my point of view: raising privileges on the LOCAL machine should NOT require networking bits. NEVER.

You are willfully ignorant of and blurring the line between _LOCAL_ hostname and "networking bits."
The _LOCAL_ hostname _IS_ mandatory and does not constitute "networking bits."

> Of course it is no bug in the sense that it breaks any specified contract, but
> ubuntu does not have a password for root and sudo is the only way to repair a wrong /etc/hosts.

Precisely, I say that this non- bug can be closed/resolved/cancelled!
Discussion of repairing the _local_ hostname configuration is already here: https://bugs.launchpad.net/ubuntu/+source/rescue/+bug/19553

[Dorin Lazăr (dorin-lazar)]

Sir, I seriously think that sudo is meant to raise/change privileges of the current user, and this has nothing to do with the network. The manual page makes this short description: "sudo, sudoedit - execute a command as another user".
But I am certain that you can explain me who says that the local hostname is mandatory, and in what circumstances.
My strong belief, as an expert computer user, is that if no host was specified in the command line or sudoers file, there should be no resolving whatsoever.
Please fix bugs, don't bloat the software! I don't want my system to become more fragile than Windows 95.

[Kristleifur Daðason (kristleifur)]

The sudo+hostname bug/inconvenience happened to me. I hosed my hosts file when upgrading from 7.04 to 8.04. Sudo didn't want to do anything, but gksudo worked fine. The network-dependent sudo failed, but the X11-dependent gksudo was OK. Redundancy saves the day.

[steve (steveranthony)]

I was getting the same problem, "sudo: unable to resolve host ABIT", where "ABIT" is my HOST NAME. I fixed this problem by going to System==>Administration==>Network, under the General tab, I put my Domain Name as "home.local"
,

[LarryJ (larry-foxgulch)]

I fixed my error
 "sudo: unable to resolve host lian-ubuntu-beta"
by making entries in System->Administration->Network
such that afterward the files /etc/hostname and /etc/hosts read:

$ cat /etc/hostname
lian-ubuntu-beta
lj@lian-ubuntu-beta:~$ cat /etc/hosts
127.0.0.1 localhost lian-ubuntu-beta
127.0.1.1 lian-ubuntu-beta
192.168.1.103 lian3.foxgulch.net lian3

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Specifically System->Administration->Networking Unlock Then Authenticate then In the Hosts Tab
highlight the "127.0.0.1 localhost" line
click properties
make it read
IP address: 127.0.0.1
Aliases : localhost
              lian-ubuntu-beta

In the General Tab
Hostname: lian-ubuntu-beta
Domain Name: (nothing or blank)

[illusionactor (illusionactor+launchpad)]

This is a link to the Ubuntu forums that shows how to do what LarryJ states above.

http://ph.ubuntuforums.com/showthread.php?p=4480244

Quick and very easy fix.

[agent 8131 (agent-8131)]

I ran into this recently. My use case was copying virtual machines and then changing the hostname by editing the /etc/hostname and running hostname -F. I was surprised to see sudo stop working following this and requiring me to boot into single user mode to fix. My surprise was because there was no reason for sudo to be doing a hostname lookup. In fact I'm not convinced that sudo should ever be doing a hostname lookup. The only case where one could argue the necessity is if one uses an IP address as a Host_Alias. I've never done that, and don't see much sense in it. But certainly if an IP address is not specified as a Host_Alias there's no reason to be doing a lookup. This raises my curiosity as to exactly what sudo is doing and whether it can be exploited.

> Not being able to resolve the local hostname is a broken and unsupportable state for any *X system.

I beg to differ. No Ubuntu system thus far has required the local hostname to be /etc/hosts. None of the desktop systems I am using running Gutsy have such an entry. Thus, if this is not fixed, assuming that Hardy is not going to modify the /etc/hosts file, this bug has the potential to break a large number of systems when they attempt to upgrade. I'd be very careful and get this resolved correctly.

[Hernan Giovagnoli (hernaaan)]

I confirm this bug in a dist-upgrade from Kubuntu Gutsy to Hardy (18/04/2008), without touching any config file.

[Derick Eisenhardt (zephyrxero)]

I upgraded to 8.04 today and am having the same problem. Whenever I use sudo I get the error:
"sudo: unable to resolve host" <hostname>

[Martin Pitt (pitti)]

Accepted into hardy-proposed. Please test and give some feedback here. Thank you!

[B. Clausius (barcc)]

Works for me, thanks.

barcc:~$ sudo id
sudo: unable to resolve host foobar
[sudo] password for barcc:
uid=0(root) gid=0(root) Gruppen=0(root)

[Brian Murray (brian-murray)]

I recreated the bug using the test case provided on Hardy Heron with sudo version 1.6.9p10-1ubuntu3. I then installed 1.6.9p10-1ubuntu3.1 from hardy-proposed and was then able to use sudo. However, I did notice that 'unable to resolve host' showed up 2x. Like:

sudo: unable to resolve host bob
sudo: unable to resolve host bob
[sudo] password for bdmurray:

[Naveen (naveenkhanna)]

Works when tested with and without a domain name, however the "unable to resolve host ..." message still gets printed

[Houser (helmut-hauser)]

Bug recreated:
VMWare - occurs at the time of network changing via GUI (e.g. switching from host only to NAT and reverse)
I cannot reproduce it with ifconfig ethX.
Looks like the culprit is the 127.0.1.1 entry at/in the GUI network configuration - I can reproduce it by deleting the line and sudo gets mad.
BTW /etc/hosts is ok for me IMHO it is GUI vs config file

[Asa Zernik (asaz989)]

Pasi wrote on 2008-04-26: (permalink)

I find this very serious problem since ubuntu relies so heavily on sudo (the lack of root account) and if that command fails there is no way to do anything. sudo should not depend on network configurations. It sounds very very dangerous!
--------------------------------------------------------

What do you mean, "lack of a root account"? I go to my terminal, do

xxx@xxx:$ su root

, enter my password for the first ("admin") user created in the Ubuntu setup, and I immediately get a command line

root@xxx:$

Just for kicks, I went into the User Management dialog and changed my root password to something other than my non-root password.

And then, I go to the graphical log-in screen, type in "root" for username and my root password for password, and tada! I'm logged in to a full graphical Ubuntu session as root user. Just because the root user isn't easily visible doesn't mean it doesn't exist. Indeed, I find it hard to figure out how ANY *X system could function without an account with root priveleges, if only for booting purposes.

Just saying, it's not like Ubuntu is any more dependent on sudo than any other *X system.

[Andreas Ntaflos (daff)]

Quoting Asa Zernik:
Just saying, it's not like Ubuntu is any more dependent on sudo than any other *X system.
--

Well by default the root user (UID 0) has no password set and is as such effectively disabled ("passwd -l root"). Sure you can "sudo su" or "sudo -s" but that is a function of sudo and nothing else. Logging in as root via a virtual console is, by default, not possible. So yes, Ubuntu depends exclusively on sudo if you haven't every set up the root user by doing "passwd root".

[Martin Pitt (pitti)]

Hi Brian,

Brian Murray [2008-04-30 21:56 -0000]:
> I recreated the bug using the test case provided on Hardy Heron with
> sudo version 1.6.9p10-1ubuntu3. I then installed 1.6.9p10-1ubuntu3.1
> from hardy-proposed and was then able to use sudo. However, I did
> notice that 'unable to resolve host' showed up 2x. Like:
>
> sudo: unable to resolve host bob
> sudo: unable to resolve host bob
> [sudo] password for bdmurray:

Hm, it doesn't show up twice for me, I wonder how you got that. Do you
also get it twice in auth.log?

Anyway, since this problem is so serious (breaking sudo entirely), do
you think it is 'good enough' for now?

Thanks,

Martin

--
Martin Pitt | http://www.piware.de
Ubuntu Developer (www.ubuntu.com) | Debian Developer (www.debian.org)

[Prince (pkarlos-76)]

See http://www.cpqlinux.com/hostname.html to fix the issue in your /etc/hosts and /etc/hostname files

[yell0w (yellowbloc+ubuntulaunchpad)]

I happened to have my hostname a fqdn.
I changed the values of /etc/hosts around and ended up borking my sudo. I was mortified since it's a remote machine.
After trying a few things suggested here and elsewhere, I ended up changing the A record for my hostname to 127.0.1.1 and that got sudo working again.
Saved me a few hours of driving.
Cheers!

[Neal McBurnett (nealmcb)]

Note that the underlying bug seems to be a race condition and another workaround may be to try the command 10 or 20 times as noted in

 https://bugs.edge.launchpad.net/ubuntu/+source/hostname/+bug/113778

[Martin Pitt (pitti)]

yell0w, did you try the package in hardy-proposed? It should fix this issue.

[Martin Pitt (pitti)]

This got three 'works for me's, and I am using it on both of my hardy boxes, too, and verified that it works correctly there.

[Launchpad Janitor (janitor)]

This bug was fixed in the package sudo - 1.6.9p12-1ubuntu1

---------------
sudo (1.6.9p12-1ubuntu1) intrepid; urgency=low

  * Merge from debian unstable, remaining changes:
   - debian/rules: Disable lecture, enable tty_tickets by default. (Ubuntu
     specific)
   - Add debian/sudo_root.8: Explanation of root handling through sudo.
     Install it in debian/rules. (Ubuntu specific)
   - sudo.c: If the user successfully authenticated and he is in the 'admin'
     group, then create a stamp ~/.sudo_as_admin_successful. Our default bash
     profile checks for this and displays a short intro about sudo if the
     flag is not present. (Ubuntu specific)
   - env.c: Add "http_proxy" to initial_keepenv_table, so that it is kept
     for "sudo apt-get ...". (Ubuntu specific EBW hack, should disappear at
     some point)
  * logging.c: Ignore SIGPIPE when creating an error email, so that non-fatal
    error messages (like "unable to resolve local host name") do not lead to
    being killed with SIGPIPE if /usr/bin/sendmail does not exist or crashes.
    Forwarded upstream to http://www.gratisoft.us/bugzilla/show_bug.cgi?id=285
    (LP: #32906)
  * env.c: Do not clobber $HOME when not specifying -H or -s. Patch taken from
    upstream CVS. (LP: #221395)
  * debian/postinst: put "NOPASSWD" example at the bottom, so that
    uncommenting it will actually work (later entries override former ones).
    (LP: #131399)

sudo (1.6.9p12-1) unstable; urgency=low

  * new upstream version, closes: #464890

sudo (1.6.9p11-3) unstable; urgency=low

  * patch for configure to fix FTBFS on GNU/kFreeBSD, closes: #465956

sudo (1.6.9p11-2) unstable; urgency=low

  * update version compared in preinst when removing obsolete init.d,
    closes: #459681
  * implement pam session config suggestions from Elizabeth Fong,
    closes: #452457, #402329

sudo (1.6.9p11-1) unstable; urgency=low

  * new upstream version

 -- Martin Pitt <email address hidden> Mon, 05 May 2008 20:31:58 +0200

[Martin Pitt (pitti)]

Copied to hardy-updates.

[foucault (michel-foucault)]

why doesn't it find the host anyway? Isn't this a bug as well?

[Martin Pitt (pitti)]

chodo [2008-05-06 23:31 -0000]:
> why doesn't it find the host anyway? Isn't this a bug as well?

No, that's usually a local configuration error, if /etc/hostname does
not have an entry in /etc/hosts.

[JaddJadd (triplezone3-gmail-deactivatedaccount)]

I can confirm that the update fixed this bug, sudo is no longer dysfunctional.

[dark (pwnedbydark)]

i had the problem today (hardy 8.04 32 bit install), with all the updates installed...
so i believe there is still some problem

however I fixed it by using

gksu gedit /etc/hosts
and just adding the hostname in front of 127.0.0.1 (as mentioned earler)

is there a way that any configuration dump will help. the please mention it
don't ask for hosts file, i believe that is not the problem.

The problem occurred because i overwritten my /etc/hosts with someone else's hosts file (don't ask why!), so as i said the hosts file is just fine.

[agent 8131 (agent-8131)]

I noticed this as well. It looks like 1.6.9p10-1ubuntu3.2 reintroduced this problem, at least on 32-bit. I didn't get to do much testing on it but I did notice that it had returned. I can provide more details when I get the chance to test but I'd say this problem is no longer fixed.

[Vikas Bhasin (vikasb)]

agreed , also experience the same issue when trying to install the updates
for the hardy.
have checked the local host file, few of the software are not being able to
install like alamin-server , its asking for the partial updates, but nothing
is been installed.
Hope it will be sorted out.

On Fri, May 23, 2008 at 2:41 PM, agent 8131 <email address hidden> wrote:

> I noticed this as well. It looks like 1.6.9p10-1ubuntu3.2 reintroduced
> this problem, at least on 32-bit. I didn't get to do much testing on it
> but I did notice that it had returned. I can provide more details when
> I get the chance to test but I'd say this problem is no longer fixed.
>
> --
> sudo fails if it cannot resolve the local hostname and no MTA is installed
> https://bugs.launchpad.net/bugs/32906
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

--
Vikas

[Lance Berry (dunixdude)]

I had this problem as well.

Another fix

I fixed mine by modifying the alias in the /etc/hosts file. When the Network wizard added my host to /etc/host, it forced itself to add the fully qualified domain name (myhost.ubuntu.com), while sudo is looking for the short name (myhost).

I booted into Recovery mode, modified /etc/hosts to reflect the correct alias, i.e.
{ipaddress} {Fully qualified name} {alias}
113.23.42.21 myhost.ubuntu.com myhost

Now Synaptic works fine for me.

[Paul Smith (psmith-gnu)]

This bug is specifically about sudo (or gksudo etc.) failing completely. The fix described here solves that problem.

You may still see some messages or warnings being printed; that should be fixed but it's not this bug.

You may also see some programs "corrupting" your /etc/hosts file; that is also a bug that needs to be fixed, but it's not this bug either.

It only counts as this bug if you get a message about looking up hostnames, AND THE OPERATION FAILS, stranding you without any way to gain superuser privileges on the system (short of booting off CD and tweaking the disk partition out of band). If you run sudo etc. and the operation succeeds, then it's not this bug.

[tinod (tino-defranco)]

I dont know if I just took the easy way. The only thing I had to do to fix this problem was left click on my network connection icon on the top left hand corner of the screen and go to manual configuration. Then I unlocked. Then I went to the hosts tab. I deleted everyting out of the hosts tab and, only in the host tab. Then I closed it. Then I recycled my modem by right-clicking on the network connection icon on the top left hand corner of the screen unchecking enable networking and then going and rechecking enable networking on the network connection icon on the top left hand corner of the screen. Then I went back into the host tab went to unlock, went to add, typed 127.0.0.1 as the IP address and put my username-desktop as Aliases. Then I went to close. This completely solved the prob. I now get no errors when trying to run sudo!!!!!!!!!!

You might have to put your username-laptop as Aliases or whatever.

[tinod (tino-defranco)]

i wrote "left click on my network connection icon"

Im sorry this icon is at the right side of the screen.

[osxdude (osxdude999)]

This has happened to me ever since I upgraded from 7.10 to 8.04. Once I go into network-admin and add "jonolaptop-linux" to Aliases sudo seems to work. This solution isn't permanent though.

[Pablo Estigarribia (pablodav)]

I fixed this also when I put in hosts file:

127.0.0.1 localhost hostname
127.0.1.1 hostname

[Scotty (miller-scott-j)]

Figure I'll try and get this right now that I've posted this in seemingly nothing but duplicate bug reports:

So I've followed just about all tips, and none prove fruitful to me. The following is a copy of my /etc/hosts file:

127.0.0.1 scotty
127.0.1.1 scotty-laptop

# The following lines are desirable for IPv6 capable hosts
::1 ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
ff02::3 ip6-allhosts

Now when I try to run sudo commands from the shell, they produce the typical:

sudo: unable to resolve host

But I can still edit files. In fact, it produced that when I did a:

sudo nano /etc/hosts

yet I was able to modify it, and save it (and yes, it did save). Yet I still cannot run GUI administrator tools (change the time, system settings, etc...). Any ideas?

now when i try to do a call of host name I get a blank line for a return:

[code]
scotty@:~$ hostname

scotty@:~$
[/code]

Any idea what the cause of this is?

[Steve Langasek (vorlon)]

For the benefit of others who come across this bug:

  127.0.0.1 scotty

Don't do this. 127.0.0.1 should always resolve to 'localhost', not to any other name.

  scotty@:~$ hostname

  scotty@:~$

This indicates that no hostname is set. To fix this temporarily, run:

  sudo hostname <my_hostname>

e.g.,

  sudo hostname scotty-laptop

The name you specify here should match the name mapped to 127.0.1.1 in /etc/hosts.

To fix it permanently, edit the /etc/hostname to show the same name.

The problem of being unable to run the GUI tools may be a result of not having all important system updates installed from hardy-updates. Once your hostname is fixed, you should install these updates - to prevent this problem from recurring in the future for you, and to address many other bugs that have been fixed since the release of 8.04.

[Charles Hackman (chhackm)]

I'm an ignorant newbie who just installed Ubuntu 8.04.1 Kernel 2.6.24-19 generic on an Advent 4211B (? = MSI Wind). One of my (fruitless) attempts to get the wifi card working was with Ndiswrapper. I had previously been using a wired connection to my Linksys WRT54G router, which connected to the internet via a cable modem and Telstra Bigpond as a service provider.

The above problem came up accompanied by 2-3 minute pauses before any application would run. I fixed it using the suggestion from Serenity:
"go to the System Control Panel in the GUI:
"->Admin -->Network ---> UNLOCK ----General: Remove Domain Name
"Go to Hosts (Under Network) - delete 127.0.1.1
"Add 127.0.1.1"

However - and this is reason for this post - I was fascinated to find that "Hosts" had contained references to Telstra which must have been acquired somehow by the network/wifi driver from some interrogation of the router. Since the problems only started after running ndiswrapper, I presume that this is responsible, but just how I cannot imagine.

[Brian Fallik (bfallik)]

Charles,

Your computer is using DHCP to acquire an IP address from the router.
As part of this transaction, the DHCP server typically also provides
DNS server addresses so that your computer knows where to ask for
translations from host name to ip addresses. Since you're connected
to a Telstra network, it's not surprising that your router is
configured to use their DNS servers. In fact, your router may be
using the DHCP to acquire its IP address and DNS information from
Telstra.

The 2-3 second pauses sound like an application (or set of them) is
blocking while waiting to perform a DNS lookups. Even on a single
host, the desktop uses many networking protocols for interprocess
communication. If the lookup for 'localhost' fails, these messages
can get stuck.

Thanks,
brian

On Wed, Sep 17, 2008 at 9:17 AM, Charles Hackman
<email address hidden> wrote:
> I'm an ignorant newbie who just installed Ubuntu 8.04.1 Kernel 2.6.24-19
> generic on an Advent 4211B (? = MSI Wind). One of my (fruitless)
> attempts to get the wifi card working was with Ndiswrapper. I had
> previously been using a wired connection to my Linksys WRT54G router,
> which connected to the internet via a cable modem and Telstra Bigpond as
> a service provider.
>
> The above problem came up accompanied by 2-3 minute pauses before any application would run. I fixed it using the suggestion from Serenity:
> "go to the System Control Panel in the GUI:
> "->Admin -->Network ---> UNLOCK ----General: Remove Domain Name
> "Go to Hosts (Under Network) - delete 127.0.1.1
> "Add 127.0.1.1"
>
> However - and this is reason for this post - I was fascinated to find
> that "Hosts" had contained references to Telstra which must have been
> acquired somehow by the network/wifi driver from some interrogation of
> the router. Since the problems only started after running ndiswrapper,
> I presume that this is responsible, but just how I cannot imagine.
>
> --
> sudo fails if it cannot resolve the local hostname and no MTA is installed
> https://bugs.launchpad.net/bugs/32906
> You received this bug notification because you are a direct subscriber
> of a duplicate bug.
>

[Bob Vincent (pillarsdotnet)]

My desktop computer has a public IP address that is reachable from the local network as well as the internet at large.

When I set my hostname to "razor.pillars.net" then I always get the sudo warning, regardless of any /etc/hosts or /etc/sudoers modifications. Believe me; I've tried all possible permutations suggested in this thread, plus a few of my own.

Setting the hostname to "razor" (without the domain) eliminates the warning as long as there is a matching entry in /etc/hosts.

What puzzles me is that "razor.pillars.net" resolves via dns, both internally (I run djbdns on localhost) and externally. However, no amount of twiddling the /etc/hosts file or the /etc/resolv.conf file will eliminate the warning from sudo.

Can someone explain why gethostbyname() is broken if hostname is fully-qualified? Is this a glibc problem or a sudo problem?

[Juan Sebastián Marulanda (juanchito2006)]

I'm still having this issue on Karmic, always I run a command as super user:

sudo: unable to resolve host (my host)

The system seen unable to resolve my host even if my /etc/hosts seems OK.

[Martin Pitt (pitti)]

This has been fixed long ago. Can you please open a new report?

[SteveLoughran (steve-loughran)]

Martin, which version is it nominally fixed for? I see it in 9.04, on my laptop whose hostname only resolves when it is in a location where the local DNS server knows of it (this is deliberate, as I do not want my hostname to map to 127.0.0.1 and its IP address changes).

[Martin Pitt (pitti)]

Steve, the bug was fixed during 8.10 development and backported to 8.04.

[ray (arkibott)]

is this really fixed and gone for good? i see this in precise again.
i don't want sudo to make network lookups. i want a option to restrict it to local operation only. for now only because it is annoying to wait for the lookup. you already discussed the issues.
the networking features are nice but should not be default.

[Avio (aviopene)]

I agree, this bug isn't fixed in Quantal (as it wasn't in Precise):

#> sudo hostname just-modified-my-hostname
#> sudo whoami
sudo: unable to resolve host just-modified-my-hostname
root
#> sudo cat /etc/lsb-release
sudo: unable to resolve host just-modified-my-hostname
DISTRIB_ID=Ubuntu
DISTRIB_RELEASE=12.10
DISTRIB_CODENAME=quantal
DISTRIB_DESCRIPTION="Ubuntu 12.10"

[Steve Langasek (vorlon)]

No, that's not this bug. This bug is about sudo *failing* if it can't resolve the hostname, which is not what you have happening.