Description of problem: Need validation checking for missing and incorrectly configured DNA attributes. When DNA configurations are loading during start up - there should be validation of the attributes. specifically: * Missing required attributes * Invalid attributes based on contraints Upon start of services - invalid configurations should not be loaded and appropriate messages logged. Version-Release number of selected component (if applicable): DS 8.1 - DNA Plugin How reproducible: Always Steps to Reproduce (example of missing required attribute dnaType): 1. Enable the DNA plugin (nsslapd-pluginEnabled's value for dn: cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config) 2. Add the following configuration: dn: cn=Account UIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: Account UIDs dnamaxvalue: 1000 dnamagicregen: 0 dnathreshold: 100 dnafilter: (objectclass=posixAccount) dnascope: dc=example,dc=com dnasharedcfgdn: cn=Account UIDs,ou=Ranges,dc=example,dc=com dnanextvalue: 500 3. Restart the services. 4. Search the configuration for cn=Account UIDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config Actual results: configuration exists and no error in log Expected results: Oject doesn't exist Error log message explaining the issue Additional info:
To clarify, we need to prevent one from adding invalid configuration dynamically over LDAP at the pre-operation phase. If we detect invalid config, we can refuse it before storing it. We currently do all validation in the post-op phase. At server startup, we do validate config and should print messages to the error log at the default log level when we detect something invalid. Some config errors are non-fatal though (such as the shared config DN not existing).
Created attachment 319306 [details] CVS Diffs These diffs add additional DNA configuration validation. More detailed log messages will be written describing why a particular configuration entry is invalid. I also added some checks for things like the dnaNextRange overlapping with the currently active range. To check if dynamic configuration changes are valid, I made the pre-op callback validate cojnfig changes and reject them if they are found to be invalid. TO do this, I exposed a private function that applies an array of LDAPMod objects to a Slapi_Entry. This seems like a good general purpose helper function.
Checked into ldapserver (HEAD). Thanks to Noriko for her review! Checking in ldap/servers/plugins/dna/dna.c; /cvs/dirsec/ldapserver/ldap/servers/plugins/dna/dna.c,v <-- dna.c new revision: 1.10; previous revision: 1.9 done Checking in ldap/servers/slapd/entry.c; /cvs/dirsec/ldapserver/ldap/servers/slapd/entry.c,v <-- entry.c new revision: 1.18; previous revision: 1.17 done Checking in ldap/servers/slapd/slapi-plugin.h; /cvs/dirsec/ldapserver/ldap/servers/slapd/slapi-plugin.h,v <-- slapi-plugin.h new revision: 1.31; previous revision: 1.30 done Checking in ldap/servers/slapd/slapi-private.h; /cvs/dirsec/ldapserver/ldap/servers/slapd/slapi-private.h,v <-- slapi-private.h new revision: 1.27; previous revision: 1.26 done
Nathan: Can you be more specific as to what you are validating? The only missing required attributes seem to be erroring out and logging error messages. Thanks
Here are some details on how a DNA config entry is validated: Required Attributes: - dnaType - dnaNextValue - dnaFilter - dnaScope Other Validation: - The filter specified in dnaFilter must be a valid LDAP filter. - The entry that dnaSharedCfgDn points to must exist. - The value of dnaNextRange must be in the form "<lower>-<upper>", where "<lower>" and "<upper>" are replace with the numeric values defining the range. The upper value must be greater than the lower value. In addition, the range specified by dnaNextRange must not overlap with the active range that is defined by dnaNextvalue and dnaMaxValue.
thank you
fix verified and being regression tested by automated DNA acceptance testing
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHEA-2009-0455.html