Bug 106518 - Need to set RHEN profile name during PXE/DHCP kickstart
Summary: Need to set RHEN profile name during PXE/DHCP kickstart
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server   
(Show other bugs)
Version: unspecified
Hardware: i686
OS: Linux
medium
high
Target Milestone: ---
Assignee: Jesus M. Rodriguez
QA Contact: Red Hat Satellite QA List
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2003-10-07 22:06 UTC by Narsi Subramanian
Modified: 2015-03-03 22:38 UTC (History)
8 users (show)

Fixed In Version: RHN 3.x
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-03-02 00:05:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

Description Narsi Subramanian 2003-10-07 22:06:19 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.1) Gecko/20021003

Description of problem:
Systems registered to our satellite server during kickstart come up with a
profile name of localhost.localdomain.  We need the profile names to be the DNS
FQDN.

This specific instance is for kickstarts with WS 3.0 beta 2.

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


How reproducible:
Always

Steps to Reproduce:
1.As stated above
2.
3.
    

Additional info:

Comment 1 Mihai Ibanescu 2003-10-08 15:50:09 UTC
Did you use rhnreg_ks? Did you call it in the %post section of the kickstart
file, or was it run after the fact?
If hostname returns localhost.localdomain, then there is not much one can do
about it. Can you confirm hostname returns valid data?

Comment 2 Tim Kramer 2003-10-08 15:58:57 UTC
It was run in the %post of the kickstart - isn't that where it should run
according to our Satellite documentation on how to use RHEL Satellite in a
KickStart script?  At that point, hostname is still localhost.  We documented
this in the install guide and rhnreg_ks needs to be using the DNS lookup of the
IP address it has.  Otherwise, if a company is deploying 500 new systems, they
will all be localhost and no one knows which system is which.

If we can't add the hostname properly into the Satellite at that point, we
should have another app we can run later that changes the profile name in the
Satellite.



Comment 3 Greg DeKoenigsberg 2003-10-08 16:12:49 UTC
We should consider documenting a workaround for this issue.  

At the point in the %post section in which rhnreg_ks runs, it should be possible
to determine the intended hostname, even if "hostname" itself returns localhost
at this point.  Then use the intended hostname as the profile name, using
rhnreg_ks's --profilename switch.

Would this solve the customer's issue?

Comment 4 Tim Kramer 2003-10-08 16:39:39 UTC
yes it would

Comment 5 Adrian Likins 2003-10-15 00:28:38 UTC
rhn_register-2.8.39 "trys harder" to get a real hostname/ip

if folks could try it and tell me if it tries hard enough,
I'd appreciate it. 

Comment 6 Adrian Likins 2003-10-15 00:30:50 UTC
er, sorry, wrong branch...
2.8.39 doesnt have it yet, pushing it to fedora
as part of say up2date-4.1.6 or higher

if it works, something similar will
probabaly land in rhn_register 2.8.40 or so
for rhel2.1 as well

Comment 7 Matt Jamison 2003-10-15 19:52:37 UTC
so, whats a good way to hide the hostname to make sure rhnreg_ks tries harder. 
aka testplan.

Comment 8 Mahesh Kunjal 2003-10-31 19:22:09 UTC
Any updates...

Comment 9 Mahesh Kunjal 2003-11-07 22:53:17 UTC
Do we have any updates on this. Need to update the customer...

Thanks
Mahesh

Comment 10 Lana Akamine 2003-12-22 01:31:05 UTC
Hi RHN,

Any update on this one?  Dreamworks is now an RHN Beta customer of
ours so would like to update them on this versus having them chase us
for it...

Please advise of an eta?


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