Describing features of a system

Recently I have added a new concept to the sysinfo component which allows admins to describe general features of a system. These are simple arbitrary flags which indicate the presence (or possibly lack) of some feature on a system. The aim of the sysinfo component has always been to provide a place in which all general information can be gathered. Previously we had support for an extensible list of standard paths along with a static set of parameters which describe things such as the operating system, the architecture and various inventory information. Notably there was a lack of a locally extensible way of describing other general features.

To understand why this is useful it helps to see where this requirement came from in the SL7 project. A while back we became aware of a problem with the way we generate logrotate configuration files for LCFG components on SL7 (see bug#812). Whenever a component configure method is called the ngeneric framework attempts to build an associated logrotate configuration file using a template. Annoyingly, due to the way we have the permissions set on our log directories (which grant write access to the lcfg group) the latest version of logrotate requires the use of a new su directive. There are various ways we could have approached this problem. We could have made this optional based on the version of the OS (e.g. on for SL7 but off for SL6) but this runs the risk of the newer version of logrotate being added to the next minor release of SL6 (it also reduces platform-independence if not done carefully). We could also have made this optional based on the version of logrotate, this seems quite sensible but we’ve learnt the hard way that Redhat like to backport software features without changing the major version (just incrementing the package release string instead). This makes it very hard to spot that some new feature is required. So, we introduced the new sysinfo concept of features and the first feature is logrotate_needs_su. The ngeneric framework queries sysinfo to check for that feature and the template is then processed appropriately to include (or not) that configuration directive. A nice bonus here is that if we ever decide to stop granting write access for the lcfg group on that directory we can just remove the feature and everything will work correctly.

Further information is provided on the LCFG wiki describing the sysinfo resources and how to query sysinfo from LCFG components and scripts.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply