Missing hostname in /etc/hosts causes sudo to fail

Bug #19775 reported by Dennis Kaarsemaker
26
This bug affects 1 person
Affects Status Importance Assigned to Milestone
netcfg (Ubuntu)
Confirmed
Medium
Unassigned

Bug Description

As active helper in #ubuntu I encountered the following issue several times already:

Sometimes the installer does not add the hostname given in the install to
/etc/hosts correctly.
The line that should read

127.0.0.1 localhost.localdomain localhost myhostname

only reads

127.0.0.1 localhost.localdomain localhost

As a consequence, sudo fails to work.

The only info I have is that all systems where this occurs are fresh installs
(the owners never
have been able to use sudo).

Revision history for this message
Vincent Fourmond (fourmond) wrote :

(In reply to comment #0)
> As active helper in #ubuntu I encountered the following issue several times
already:
>
> Sometimes the installer does not add the hostname given in the install to
> /etc/hosts correctly.
> The line that should read
>
> 127.0.0.1 localhost.localdomain localhost myhostname
>
> only reads
>
> 127.0.0.1 localhost.localdomain localhost
>
> As a consequence, sudo fails to work.
>
> The only info I have is that all systems where this occurs are fresh installs
> (the owners never
> have been able to use sudo).

  I can confirm that this problem also occurs on fresh installs in debian sarge.
Whereas it is not a problem in debian, because of the existence of a root
password, it makes the whole problem difficult to solve in Ubuntu (try sudo bash
or sudo nano /etc/hosts) when the hostname is not in /etc/hosts...

  It might come (untested) from the fact that the network wasn't configured
properly (in case, for instance, of a ppp network).

  Thanks...

Revision history for this message
Wolf-Michael Bolle (wolf-michael-bolle) wrote :

Happened to me with a Kubuntu AMD64 release candidate install

Revision history for this message
Dani Alonso (dalonso) wrote :

I can confirm the bug being present in dapper. Nevertheless the fix Vincent proposed is not enough.

In fact, /etc/hosts has two diferent layouts depending on the computer is being connected to a network or not.

Case 1: No network. Should read only 1 line:

127.0.0.1 localhost.localdomain localhost myhostname

Case 2: Network. Should read 2 lines:

127.0.0.1 localhost.localdomain localhost
x.x.x.x myhostname

where x.x.x.x is the ip assigned to the interface.

In fact, dhclient3 should be responsible of updating /etc/hosts every time a new lease is acquired over the default network interface.

Revision history for this message
Odd A Olsen (oao) wrote :

This problem came up when I did a fresh install, and entered the network menu to check if ndiswrapper was supported in any way. As it was not I got back to the main menu (pressing ESC?) without doing any other network install, and then selected the next install step.

Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

This seems widely confirmed

Changed in netcfg:
status: Unconfirmed → Confirmed
Revision history for this message
Manuel López-Ibáñez (manuellopezibanez) wrote :

Related bug: sudo shouldn’t ABSOLUTELY NEED to look up the host it’s running on https://launchpad.net/bugs/32906

Revision history for this message
corey (anyfox-gmail) wrote :

yes, the sudo failed on getnamebyhost()。

This is maybe terrible, because you must get the root power by grub (recover mode)
and fix the /etc/hosts file to correctly. Or you almost can't do anything(a lot of things need use the sudo command).

Revision history for this message
Vincenzo Ciancia (vincenzo-ml) wrote :

The missing hostname also causes problems when using prevu, it fails on prevu-init.

Colin Watson (cjwatson)
Changed in netcfg:
assignee: kamion → nobody
Revision history for this message
usen (usen68) wrote :

The problem come up when I have installed VSFTPD.
But how to solve it,this is why I come here.
The sudo and su command unenabled,how to solve.
I am fresh man,I hope get help from here.However I can't.

Revision history for this message
20after4 (twentyafterfour) wrote :

Not the most elegant solution but this will make sure that the hosts file is correct, even if you change your host name:

I made a simple little script that can generate the hosts file based on the current /etc/hostname, you could run this in your /etc/rc.local like so:

/path/to/mkhosts.sh > /etc/hosts

Revision history for this message
Yura Tolstik (yltsrc) wrote :

i am today update 2 pc with ubuntu 7.10 to 8.04rc
and i have this bug too

when hostname not in hosts.conf sudo doesn't work.

Revision history for this message
juggler885 (juggler885) wrote :

I just upgraded from from 7.10 to 8.04 (using the updated manager in KDE) and had this problem too. The solution was to add my hostname to the /etc/hosts file on the end of the line containing 127.0.0.1. I was able to open up /etc/hosts as root by using the command:

su -c "nano /etc/hosts"

Revision history for this message
flopin (flopin) wrote :

I confirm this bug. It started when upgrading from 7.10 to 8.04 (kubuntu), but when i call sudo, it shows this error, but otherwise it looks like it's function is unaffected. Adding record to /etc/hosts solves the problem

Revision history for this message
gary_inNYC (wat-gary) wrote :

Here's another related link that got my issue fixed:

http://ph.ubuntuforums.com/showthread.php?t=719252

In particular, take a look at comments from "dcstar" and "InfinityCircuit" . I can now sudo as normal and be a part of a Windows workgroup as I intended when I modified network configuration manually.

- Gary_inNYC

Revision history for this message
Glenn Ramsey (glennr) wrote :

This happened to me on upgrading from 7.10 to 8.04 on an AMD64 box.

I had edited /etc/hosts by hand on this machine, perhaps it has something to do with that?

Revision history for this message
gary_inNYC (wat-gary) wrote :

Scratch my initial post...

I noticed that without manually typing in a workgroup name in domain, I can't access a windows workgroup. If I do fill in a workgroup name in domain, I can join the windows workgroup and access its shares, however, I can't use sudo.

If I leave the domain field blank and manually modify the localhost aliases in "Network Settings" "hosts" tab, I could join the workgroup, but then I can't see the shares themselves, though windows computers can see my shares.

This issue did not exist in Gutsy (clean install). I believe it's an issue with Hardy itself, as I did a clean install for this latest LTS release as well (same computer).

- Gary_inNYC

Revision history for this message
gary_inNYC (wat-gary) wrote : SOLVED: Re: Missing hostname in /etc/hosts causes sudo to fail

A recent update released has since fixed sudo's functionality with regard to hosts resolution. The only issue that remains is more a cosmetic one, as I still receive the "unresolved hosts" message in terminal, but at least you can still sudo successfully in spite of it. Thanks for getting this fix released, as now I can do what I sought out to do (join and share between windows workgroups) without any real averse effects.

- Gary_inNYC

Revision history for this message
Denny (lockanload77) wrote :

 Dani Alonso

I'm a new guy and I thank you. Easy, short and right on!!!

Den

Revision history for this message
gary_inNYC (wat-gary) wrote :

Now that sudo works after the patch, I am now (unable) to start synaptic, or change software sources from the System, Administration menu. What's going on? I can still use apt get from terminal, but I can't use synaptic through gui menus. Ugh! As soon as I rid the domain entry from manual network configuration, I am able to run Synaptic through the gui menus again.

After removing that entry, everything works normally (synaptic through gui worked, sudo worked, browsing windows workgroups worked)...

But as soon as I reboot, I can't access the Windows workgroup, (But synaptic works from gui since the domain field was left blank) This is getting really frustrating because it's throwing me in circles.

- Gary_inNYC

Revision history for this message
Frank_C (fmcola) wrote :

I'm a little late to this conversation, but here is my problem, my fix and my comment...
 I updated from Guitsy to 8.04 LTS on my desktop .... I could not hook up with my XP laptop in Gutsy (shared files could not be displayed on either computer) but when i upgraded, i could instantly see all shares from each computer on the other.... BUT, no apps needing Administrative password would work!!

etc/hosts: 127.0.0.1 localhost
                 127.0.1.1 frank-desktop.mshome

 After searching many web sites, i found some fixes... the on that worked was deleting the .mshome from thw second line using network tools/hosts...

now, all works well and i can still "network" fully!! WIERD!!!

Revision history for this message
Matthew Hawkins (darthmdh) wrote :

I got this with a fresh install of 8.04 too, and I've had to help a few people on IRC who have been bitten by it. My solution was as follows:

boot into recovery console (the only way to get root now since sudo is broken)
edit /etc/hosts and add the shortname - I added it to both the 127.0.0.1 and the 127.0.1.1 lines. At this stage I don't do IPv6 so don't know about that one
chmod 0444 /etc/hosts (this is necessary because shortly after rebooting some idiot process will erase the fix unless this file is read-only)

Revision history for this message
goto (gotolaunchpad) wrote :

Erm, why not just have:

127.0.0.1 localhost.localdomain localhost myhostname
10.20.21.22 myhostname

like at http://www.faqs.org/docs/securing/chap9sec95.html

Revision history for this message
Thomas Hood (jdthood) wrote :

Dennis Kaarsemaker wrote:
> The line that should read
> 127.0.0.1 localhost.localdomain localhost myhostname

No it should not. Read section 10.4 of the Debian reference which also applies to Ubuntu.

    http://www.debian.org/doc/manuals/reference/ch-gateway.en.html

In general, it is important that the current system hostname be resolvable in /etc/hosts
to an IP address and back from that IP address to the same hostname or to a fully
qualified variant thereof.

This will not happen if the hostname is included as an alias for "localhost" because then
the hostname -> IP address -> canonical hostname lookup sequence will yield "localhost".

In other words, in /etc/hosts, the "127.0.0.1" line should look like this:

    127.0.0.1 localhost

Do not put "localhost.localdomain" on this line. That is a RedHat-ism. It is not needed
in Debian and Ubuntu.

Assign the current system hostname (e.g., "foo") a permanent IP address if the machine
has one, e.g.,

    138.64.21.258 foo.bar.com foo

and assign it the loopback address 127.0.1.1 if it does not:

    127.0.1.1 foo

Note the difference between 127.0.1.1 and 127.0.0.1.

To those who suggest putting the system hostname ("foo" in our example) on both
the 127.0.0.1 line and the 127.0.1.1 line: No, that is an invalid configuration. Each
host name should be associated in /etc/hosts with a single IP address.

What I describe above are /etc/hosts configuration standards for Debian and Ubuntu.
In the real world many people are confused about how /etc/hosts should be set up
and this includes many Debian and Ubuntu developers, and even those developing
and packaging network configuration tools. I haven't looked recently, but up until
two years ago there was no network configurator that even came close to writing
valid network configuration files in Debian and Ubuntu. For a very long time I have
avoid installing or starting network configuration tools in Debian and Ubuntu.

Revision history for this message
Thomas Hood (jdthood) wrote :

goto wrote:
> Erm, why not just have:
>
> 127.0.0.1 localhost.localdomain localhost myhostname
> 10.20.21.22 myhostname
>
> like at http://www.faqs.org/docs/securing/chap9sec95.html

One reason for not doing that is that the FAQ is for RedHat, not for Ubuntu.

Another reason for not doing that is that it fails to specify unambiguously
what the IP address of "myhostname" is. If the resolver decides that
127.0.0.1 is the IP address for myhostname (because that line happens
to come first?) then a reverse lookup will yield the result that "localhost"
is the canonical hostname for "myhostname".

People should also read hosts(5).

Revision history for this message
Thomas Hood (jdthood) wrote :

Should be marked as a duplicate of 32906.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.