When implementing sssd on SL7 we had to decide how to manage the configuration file (/etc/sssd/sssd.conf) used by sssd. Starting and stopping of the daemon itself is done by systemd. We considered a custom component, but sssd.conf uses an INI-file syntax and LCFG already has lcfg-inifile for just such configuration. Any custom component would be largely duplicating the work done by lcfg-inifile.
It is also quite difficult to write a sensible specific component for something like sssd, where the number of options are many and varied (see sssd.conf(5) and the additional man pages referenced at the end). The danger is that you implement specific resources for the features you personally require and add more and more to this as time passes
(see lcfg-openldap for how this can end up looking). It was thought, in this case, that a more generic approach was better suited.
Intitially we used lcfg-inifile (with a few local modifications, since implemented upstream). What this doesn’t give us, however, is namespace separation (i.e. it would be easy to break sssd when configuring inifile resources for another purpose). We decided to look into sub-classing the lcfg-inifile component in order to use its functionality, and at the same time adding anything specific to sssd on top.
This is surprisingly easy to do, providing the component is written in perl and the component code is delivered in a perl module.
To inherit the resources from the parent component, we added the following to sssd.def:
#include "mutate.h" #include "inifile-2.def" !schema mSET(@LCFG_SCHEMA@)
This means that the sssd component supports all the resources provided by lcfg-inifile.
We also add the following resources:
!files mSET(sssd) file_sssd /etc/sssd/sssd.conf owner_sssd root group_sssd root mode_sssd 0600 purge_sssd no useservice_sssd yes onchange_sssd sssd restart
This essentially hard-codes the configuration file, ownership, permissions and behaviour when the file changes (all of this can of course be overridden).
It would have been nice to have been able to mandate that the sssd.conf file has an [sssd] section, with something like this in sssd.def:
!sssd_sections mSET(sssd)
This doesn’t work as planned, however, as this is a default value and in LCFG these are only applied if the value is not set in any other place. This would mean that any subsequent mutation (e.g. an mADD of other sections) would lead to the default value never being used. Header files will be used for any such initial configuration.
Other than the schema, the other aspect of sub-classing is the code itself. This is implemented using standard perl sub-classing, e.g. For sssd we have no additional code so LCFG::Component::Sssd simply looks like this:
package LCFG::Component::Sssd; # -*- perl -*- use strict; use warnings; use v5.10; our $VERSION = '@LCFG_VERSION@'; use base qw(LCFG::Component::Inifile); 1;
If we require custom code, then we could add our own methods (calling the parent class’s method(s) as required).
One thing which would be nice to be able to add for a sub-classed component is additional validation for some resources. This is quite difficult in this case, as we can’t mandate what resources are named, particularly when taglists are involved. It would probably require a custom, non sub-classed component to be written, with all that this entails. My personal opinion is that a syntax-checking tool [1] is a better approach to a complex system such as sssd.
[1] https://fedorahosted.org/sssd/ticket/2577