Bug 486210 - /etc/hosts does not include `hostname`
/etc/hosts does not include `hostname`
Status: CLOSED CURRENTRELEASE
Product: Fedora Hosted Projects
Classification: Retired
Component: mock (Show other bugs)
unspecified
All Linux
low Severity low
: ---
: ---
Assigned To: Clark Williams
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-02-18 16:22 EST by Richard Franks
Modified: 2013-01-10 00:04 EST (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-09-11 14:45:12 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard Franks 2009-02-18 16:22:17 EST
Description of problem:

This causes mock builds to fail when packages query 'hostname' as part of the build process (e.g. mico), and the hostname itself is defined in the build hosts /etc/hosts file and/or is not resolvable by DNS.

Using the --copyin option on /etc/hosts seems inappropriate, as it may pull in who-knows-what - rather, appending the value of `hostname` to the /etc/hosts entry might be a cleaner solution.
Comment 1 Łukasz Lis 2009-06-14 06:15:19 EDT
This bug makes sudo hang for a while when a DNS server goes down.

How to reproduce:
1. Set up /etc/resolv.conf to an unreachable address, for ex.:
nameserver 192.0.2.1
2. $ sudo echo "This hangs until libpam's NS lookup time-outs"

Expected result: Doesn't hang
How reproducible: Always

There's a related bug with more information:
https://bugzilla.redhat.com/show_bug.cgi?id=479464
Comment 2 Stephen Thorne 2009-07-14 20:14:52 EDT
I believe there are some errors in this bug report. The word 'hang'  is used, but I don't experience a hang, just a finite delay on every sudo command.

How to reproduce:

1. Install a fresh Fedora 11 system from DVD.
2. Set the hostname in the installation to be something that does not resolve, in my case I used 'pearl.thorne.id.au'.
3. Configure sudoers to allow the user to run commands as root with password.
4. $ sudo ls
5. Authenticate.

Expected result:
Immediate directory listing.

Actual Result:
30 second delay before directory listing appears.

Workaround:
Edit /etc/hosts adding 'pearl.thorne.id.au' to the end of the line:
127.0.0.1   localhost localhost.localdomain localhost4 localhost4.localdomain4
Comment 3 Stephen Thorne 2009-07-14 20:18:21 EDT
I made an error in my steps to reproduce, I used Fedora-11-i386-disc1.iso Fedora-11-i386-disc2.iso and Fedora-11-i386-disc3.iso downloaded from: http://mirror.internode.on.net/pub/fedora/linux/releases/11/Fedora/i386/iso/
Comment 4 Ricky Zhou 2009-08-05 13:14:13 EDT
I think there are two mixed issues in this bug report.  The first is a mock issue, which might have been fixed in commit 28027fc26d5258efe5034bb975157a3f61dfcfec upstream (Richard, can you verify if this still happens in the latest version of mock?)

The other issue is that sudo takes a long time (to timeout?) when DNS resolution isn't working.  I'm not sure if that would be considered a bug or not though - bug #479464 was closed NOTABUG (although if you still think this is an bug, it perhaps libpam would be a better package to bring this up against).
Comment 5 Clark Williams 2010-09-11 14:45:12 EDT
marking closed

Note You need to log in before you can comment on or make changes to this bug.