RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1545850 - rhel-guest-image contains a resolv.conf with an address
Summary: rhel-guest-image contains a resolv.conf with an address
Keywords:
Status: CLOSED DUPLICATE of bug 1623913
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: rhel-guest-image
Version: 7.5
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Nobody
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-02-15 17:20 UTC by Alex Schultz
Modified: 2021-12-10 15:41 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-10-18 11:18:00 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Alex Schultz 2018-02-15 17:20:13 UTC
Description of problem:
While investigating BZ1545842 we found that a nameserver of 192.168.122.1 is being shipped in the guest images.  We noticed that with a recent change in to ifup-post[0] in 7.5 the provided nameserver is being kept after we configure the host.  This can lead to weird delays if the provided nameserver is not valid.  This is a different interaction then what was in 7.4.  Either way we probably shouldn't be shipping a resolv.conf with nameservers in the guest image. 


[0] https://github.com/fedora-sysv/initscripts/commit/4da9dbaffba4af74eb632d1a5d10e5c366475516#diff-0d62530925abcdd252ce22c42fdeff8c

Version-Release number of selected component (if applicable):
rhel-guest-image-7.5-106.x86_64.qcow2


How reproducible:


Steps to Reproduce:
1. download rhel-guest-image-7.5-106.x86_64.qcow2
2. inspect existing of /etc/resolv.conf with nameserver 192.168.122.1 defined
3.

Actual results:


Expected results:


Additional info:

Comment 4 Sandro Bonazzola 2018-03-30 13:14:54 UTC
Yuval, can you please check if this affects also rhvm-appliance?

Comment 7 Sandro Bonazzola 2018-03-30 15:04:21 UTC
Alex, 192.168.122.1 is the dns provided by libvirt, used during the image compose. Almost every existing cloud image contains an /etc/resolv.conv with that nameserver, including CentOS images for example.

I would suggest to revert the change in https://github.com/fedora-sysv/initscripts because I think almost everybody relies on the file being written by NetworkManager / ifup when the DHCP replies to network activation.

Moving to networking sst.

Comment 8 Alex Schultz 2018-04-02 16:22:03 UTC
We've updated the openstack image build process to remove these lines in the mean time. I do think we shouldn't be shipping any content in /etc/resolv.conf as it's something that should be specific to the deployed environment. I'd assume this would fall under similar categories as /etc/machine-id or other things that can be cleaned out by running virt-sysprep on the image.  One solution is to revert the initscript change, but I think the correct solution would be to ensure we properly clean images after building them.

Comment 9 sushil kulkarni 2018-04-30 14:56:08 UTC
Removing the sst_networking setting since it affects Bugzilla-Jira mirroring.. Need to move this to the correct group in networking.

-Sushil

Comment 17 Wei Shi 2018-10-18 11:18:00 UTC

*** This bug has been marked as a duplicate of bug 1623913 ***


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