Bug 130675 - [RHN Sat] up2date -p enhanced to update nodename/ip also.
Summary: [RHN Sat] up2date -p enhanced to update nodename/ip also.
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: API   
(Show other bugs)
Version: 520
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Pradeep Kilambi
QA Contact: Fanny Augustin
URL: IT_42853
Whiteboard: None
Keywords: FutureFeature, Triaged
Depends On:
TreeView+ depends on / blocked
Reported: 2004-08-23 17:31 UTC by Don Howard
Modified: 2018-10-20 00:52 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-20 19:06:18 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Don Howard 2004-08-23 17:31:17 UTC
Hi Summer, 
I noticed that when a machine who is already registered with satellite gets s 
new name/ipaddress; that when the command: 
up2date -p is executed it will update the satellite server with a list of 
packages that the machines local rpm database knows of. 
The man page says it'll update the profile which the satellite server has in 
terms of  the package list associated with the machine. 
I was hoping that the PROFILE could also update satellites knowledge of other 
profile pieces like a nodes name/ip address pairs. 
Is this available in version 3 and if not could this possibly be received as 
an enhancement request for future. 
It'll alalow machines to relocate and as such reflect the new node name in 
satellite once relocated. It'll also make it easy for a satellite admin to 
find (in the satellite interface) a node if it's name is correctly aligned in 
satellite with the actual name of the machine deployed. 
Action by: ssexton 
Hi Nick, 
I am pretty sure the newer Satellite also behaves the same (i.e. profile is 
only a package profile).  For this feature request, please provide the impact 
of this not happening currently, as well as a proposed timeframe and reason 
for that timeframe. 
Assigning to Julia for feature tracking. 
Thanks and regards, 
jhoskins assigned to issue for Nortel/CSC. 
Category set to: RHN::Satelite 
Status set to: Waiting on Client 
Action by: nstuyt 
Hi Summer, 
On the NN account System Admin functions are separated into groups whose main 
function is to provide a service. For example there are groups whose main 
purpose is to support NIS/DNS/DHCP infrastructure and nothing more. Other 
groups are tasked with Desktop support and yet others with Server support 
Since satellite lists the nodes via node name AND we cannot sort the list by 
for example registration date; earliest/latest (Another request perhaps) then 
sifting through a list to find the node after it's name has been changed is 
going to be a nightmare; especially if there are hundreds if not thousands of 
Because of internal churn the Desktop system administrators may need to change 
a given nodes nodename/ipaddress. Churn is movement of machines from project 
to project or dept to dept. This could happen more often in a lab environment 
for example. Laptops could also be configured with DHCP and as such could have 
different ipaddresses (and possibly name) as they move around. 
Deployments is another area where the machines node name will first change. 
First it'll be called "some name associated with the cloning shop". Then when 
cloned the node will be deployed to the desktop where some post install steps 
will include the machines name change. If we chose to patch in the lab then 
satellite will have the cloning labs node name known to it. The cloner would 
then need to have an account on satellite to remove the machine from 
satellites database. Also on the node itself the cloner would have to remove 
the /etc/sysconfig/rhn/systemid file. Then after delivering the node at the 
users desk the machine would need to be re-registered again. This makes more 
work for the cloner and margin for error (what if (s)he removes the wrong node 
from satellite?). Registering and patching at the users desk could be an 
option but then the user would need to wait until the machine has finished 
patching before they could use it. We want the machine to be cloned and 
patched before delivery the the end user. 
For these reasons (And others I haven't thought of I'm sure) I think it a good 
feature that up2date/rhn_check could request the satellite server to update 
the profile about a given node with more than just package data but also node 
name information. There exists a hardware refresh feature; but there too it 
seems we cannot change the node name in satellite associated with the machine. 
To answer your time frame question, I guess I cannot ask anything else except 
that it be made available in future releases. However as part of our ability 
to query satellite and create reports we may need to work with redhat to 
create an sql statement (or statements) to collect data out of the database. 
If the web interface is not telling us truthfully what a nodes name is then 
perhaps sql statements will.

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