Red Hat Bugzilla – Bug 498356
[PATCH] rhn-bootstrap: set specific profilename during registration process if it's given
Last modified: 2010-10-23 05:18:03 EDT
Created attachment 341860 [details] A patch to add an option to specify profilename of client systems to bootstrap scripts Description of problem: The profile name of client systems registered to the satellite server sometimes becomes "unknown" depends on environments. This patch can solve this problem and makes it configurable by administrators who can generate and edit bootstrap scripts. Version-Release number of selected component (if applicable): 5.2.0 Additional info: I posted almost the same patch on the spacewalk-devel list: https://www.redhat.com/archives/spacewalk-devel/2009-April/msg00080.html
Applied: http://git.fedorahosted.org/git/spacewalk.git?p=spacewalk.git;a=commit;h=ecbc4697a686531e7d5f1cb1ea66e56e1c7c0454
ON_QA
need a testplan... although.. I suspect this is *not* recreatable
TESTPLAN: * Generate the bootstrap.sh from Satellite's GUI. * Verify that the PROFILENAME variable is in the bootstrap.sh script: # ex. PROFILENAME="foo.example.com" # For specific clinet system # PROFILENAME=`hostname -s` # Short hostname # PROFILENAME=`hostname -f` # FQDN PROFILENAME="" # Empty by default to let it be set automatically. * Set the variable to something random and unique: PROFILENAME="testing498356.rhndev.redhat.com" * execute the bootstrap.sh on a client * Verify that the profilename matches the variable specified.
This was missing a cherry-pick into vader. resolving and should be in next ISO
verified... works w/ custom prof name 6/19
ran the script [root@rlx-3-06 ~]# bash bootstrap.sh RHN Satellite Server Client bootstrap script v4.0 and it worked properly and set the new profile name
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-1434.html