Howard Chu writes: > For backends that support the olcDbDirectory keyword, we should also > define a write-only olcDbMkdir attribute. If it's provided when > ldapadd'ing an olcDatabase entry, or when ldapmodifying, then its > values are treated as pathnames that we will attempt to create before > processing any other parts of the request. This attribute would not be > persisted in the cn=config backing store, so it will only take effect > on dynamic operations, not when reloading the config on a subsequent > startup.
This sounds equivalent to a control, but in a more convenient format Which sounds good to me, but I think this should be visible from the attribute name and maybe OID arc. E.g. names starting with 'olcCtrl'. I'm not quite sure why not persist it, however. auto-mkdir during a possibly failed attempt to load a config would be excessive, but the mkdirs could be delayed until the new database is opened. Actually, there could be an ;openldap-ephemeral option which (if supported for an attribute+backend) would prevent it from being stored. > It may still be worthwhile to provide a global setting defining the > filesystem locations that are allowed to be used. (Of course, anyone > with back-config's rootdn credentials can set it to anything they > want, anyway.) Well, I still think that "of course" part would make more sense if it was reversed. A small metaconfig file outside slapd, which would be unavailable or read-only under cn=config. Though that doesn't preclude another meatconfig level which can be written via cn=config. -- Hallvard
