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
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
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.