Bug 486210

Summary: /etc/hosts does not include `hostname`
Product: [Retired] Fedora Hosted Projects Reporter: Richard Franks <spontificus>
Component: mockAssignee: Clark Williams <williams>
Status: CLOSED CURRENTRELEASE QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: unspecifiedCC: dcantrell, rzhou, stephen, volpe.pl
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2010-09-11 18:45:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Richard Franks 2009-02-18 21:22:17 UTC
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 10:15:19 UTC
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-15 00:14:52 UTC
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-15 00:18:21 UTC
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 17:14:13 UTC
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 18:45:12 UTC
marking closed