----- Original Message -----
Richard,
> I have a requirement to display some a additional on the platform
> in RHQ.
> • Make
> • Model
> • Asset Tag
> • Function
> • Notes
> Would it be ok to add these as additional fields to the Resource so
> that users can manually enter the values?
Not sure if you mean this: The Resource.class is a bad place, as this
is used for all the resources
in the system and thus the fields would also apply to services like a
war file.
What you could do though is to use the configuration object(s) for
this purpose and just e.g. add
a resource configuration object of the Linux type in the platform
plugin, which can then be filled by
hand or via the plugin. It is not exactly the right place, but a
place that already exists.
I was thinking in the past about adding some location area to the
platforms as well (geographical and/or
building/room/rack/... ), so one could even add (attention: more
work) a new configuration for this purpose
that is also shown on the inventory tab, but a different subtab.
I was also wondering in the past, if we could just have a generic
configuration definition, where
we'd provide some fields out of the box (e.g. "location" for a
platform) and where the admin could
then per resource type in the admin section of RHQ define additional
fields. So those additional
fields would then not be defined in the plugin descriptor, but
dynamically - and could also only set
manually and not through plugin code (as this may not even know about
the existence of the field).
This sounds like something you could use tags for?
> I have investigated populating Make and Model from the BIOS. This
> can be done on Linux using dmidecode. This does mean the agent
> would need to run as root though.
These sounds like traits?
This is something which is already in some places I think and which
we may see more often.
Could it make sense to not call dmidecode directly from the
plugin/agent, but via some intermediary that
is small and runs suid root so that the agent does not need to run as
root?
I wonder if we should start writing SELinux policies for those
routines close to the operating system.
Heiko
--
Reg. Adresse: Red Hat GmbH, Technopark II, Haus C,
Werner-von-Siemens-Ring 14, D-85630 Grasbrunn
Handelsregister: Amtsgericht München HRB 153243
Geschaeftsführer: Mark Hegarty, Charlie Peters, Michael Cunningham,
Charles Cachera
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/rhq-devel