Additional Platform Fields

Heiko W.Rupp hrupp at redhat.com
Thu Oct 18 09:14:27 UTC 2012


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

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

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 203 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20121018/038df49c/attachment.sig>


More information about the rhq-devel mailing list