Bug 126481 - RFE: add info on how to handle broken DNS
RFE: add info on how to handle broken DNS
Status: CLOSED CURRENTRELEASE
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Documentation (Show other bugs)
unspecified
All Linux
medium Severity medium
: ---
: ---
Assigned To: Clay Murphy
Fanny Augustin
: Documentation, FutureFeature
Depends On:
Blocks: 128275
  Show dependency treegraph
 
Reported: 2004-06-22 06:15 EDT by Patrick C. F. Ernzer
Modified: 2009-08-19 23:05 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2004-09-15 10:36:51 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 Patrick C. F. Ernzer 2004-06-22 06:15:52 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-us) AppleWebKit/125.2 (KHTML, like Gecko) Safari/125.8

Description of problem:
In the field we see quite often that a customer has broken DNS in the form that 'dig <IP of Satellite Server>' will fail.

This makes the Sat inastaller bail out.

We should include a section in the docs highlighting the test to be done by the user and a solution

Version-Release number of selected component (if applicable):
3.2.0-12

How reproducible:
Always

Steps to Reproduce:
1. have a DNS that cannot rfesolve backward
2. try to run the Satellite installer
3. get to the point where installer tries to resolve the IP of itself
    

Actual Results:  sat-install Registration of the system viaRHN failed.Return value: 1Standard-out: �Standard-err: Traceback (innermost last): �File "/usr/sbin/rhnreg_ks", line 326, in ? �� main() �File "/usr/sbin/rhnreg_ks", line 289, in main �� hardwareList = hardware.Hardware() �File "/usr/share/rhn/register/hardware.py", line 383, in Hardware �� ret = read_network() �File "/usr/share/rhn/register/hardware.py", line 305, inread_network �� hostname, ipaddr = findHostByRoute() �File "/usr/share/rhn/register/hardware.py", line 276, infindHostByRoute �� server_port = rhnreg.getProxySettings()NameError: rhnreg �

Expected Results:  error message that informs the user that backward lookup failed and a dialog that offers to edit /etc/hosts

Additional info:

filing under documentation as we should fiorst include this in docs, I guess the dialog can be considered part of the next rewrite that includes more friendly error messages (i.e. reassigen when doc part done)

Suggested text.

If at the installer bails out when clicking next in the 'RHN Account Information' screen and you get a traceback containing "sat-install Registration of the system viaRHN failed.Return value: 1Standard-out: �Standard-err: Traceback (innermost last): �File "/usr/sbin/rhnreg_ks", line 326, in ? �� main() �File "/usr/sbin/rhnreg_ks", line 289, in main �� hardwareList = hardware.Hardware() �File "/usr/share/rhn/register/hardware.py", line 383, in Hardware �� ret = read_network() �File "/usr/share/rhn/register/hardware.py", line 305, inread_network �� hostname, ipaddr = findHostByRoute() �File "/usr/share/rhn/register/hardware.py", line 276, infindHostByRoute �� server_port = rhnreg.getProxySettings()NameError: rhnreg", please follow these steps.


1. exit from the installer
2. edit /etc/hosts, it should contain:
[start]
127.0.0.1 localhost.localdomain localhost
1.2.3.4 mysatellite.example.com mysatellite
[end]
Note that the 127 line only contains localhost, not the name of the satellite, after all we do not want the name of the sat to point at 127.0.0.1.
Please only do this edit if you are experiencing the error.
3. re-start the Satellite installer, all previously entered data should be pre-filled in the fields.
Comment 1 Clay Murphy 2004-06-23 15:12:10 EDT
Hi Patrick. We already cover this solution within the Troubleshooting
chapter. See:
https://rhn.redhat.com/help/satellite/host-not-found.html

I didn't realize DNS errors were so common during installation. We
already stipulate working DNS in the Additional Requirements section.
Will it suffice to mention the error within the appropriate section of
the Installation chapter (registration confirmation) with a
cross-reference to the above troubleshooting item for the solution?

This way, we avoid duplicate steps and isolate troubleshooting to a
single area. What'cha think?
Comment 2 Clay Murphy 2004-06-23 15:15:23 EDT
Regardless of the change we agree upon, I'll address in the next
release. Aligning to the 350 doc tracking bug and updating the version
and cust-facing fields.
Comment 3 Patrick C. F. Ernzer 2004-06-28 03:19:11 EDT
Clay,

my bad, should have checked the Troubleshooting chapter.

Yes, pointing to that part of the Troubleshooting chapter in te
Installation chapter is absolutely sufficient.

(I see broken DNS with about 10-20% of the customers, mostly it is
reverse-lookup not working)

Once the link to the relevant troublesooting section is made, I will
move this bug (or just make a new one), as in the long run I'd like to
have a dialog pop up for those users not even reading the Installation
Chapter.
Comment 4 Clay Murphy 2004-07-20 21:37:40 EDT
Moving blocker from the 350 hosted doc bug to the 350 sat doc bug,
since that is when this documentation change will appear.
Comment 5 Clay Murphy 2004-08-09 15:33:11 EDT
Alright, I've addressed in the brand new Installation chapter by
adding a line to the RHN Entitlement Certificate step that reads, "If
you receive errors related to DNS, ensure your Satellite is configured
correctly. Refer to the (cross-reference to the above-mentioned
Troubleshooting section)."
Comment 6 Fanny Augustin 2004-08-12 11:54:46 EDT
Looks good on QA.

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