Mark Cave-Ayland wrote:
On 29/06/11 12:59, Howard Chu wrote:
Thanks for the response - this makes a bit more sense now. Just to clarify another point: when you generate schemaConvert.conf, I guess that you need to include *all* schemas in your current cn=config matching the existing order, as well as the new one you are trying to add?
Obviously the config file has to be valid; any schema that the ones you're converting depend on must be loaded.
I understand that part; however when installing the packages for Debian Squeeze the post-installation process preloads the following schemas into cn=schema,cn=config:
{0}core {1}cosine {2}nis {3}inetorgperson
So what I wanted to verify was that if I want to add a new sirius-custom.schema file into the directory I would need to setup schemaConvert.conf to look like this:
include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/sirius-custom.schema
The previous entries are required to ensure that the sirius-custom.schema LDIF would be generated as {4}sirius-custom ready for using ldapadd to load into the directory.
You only need to load those 4 schema files if your sirius-custom.schema file actually depends on all of them. The ordering prefix only needs to be {4} if you really need those others to be parsed first. Otherwise the prefix can be deleted and the config backend will generate it automatically. This is all in the documentation. You should try reading it sometime.
http://www.openldap.org/doc/admin24/slapdconf2.html
However when I then run:
mkdir config&& slaptest -f slapd.conf.tmp -F config
Then I get my {4}sirius-custom.ldif but the top lines look like this:
No.
No.
No.
You're not paying attention. You skipped step 3 of my reply.
And apparently you need to be flamed too. http://www.openldap.org/lists/openldap-technical/201106/msg00085.html
I frankly can't believe that you just asked that question. cn=config is an LDAP database. When you want to change its contents, you use ldapmodify. It takes effect immediately and there is no need to restart the server.
Oh I understand that part - my question was perhaps badly asked. What I really want to know is what should my workflow be when designing new LDAP schemas to be distributed as .schema files? Based upon what you are saying, I guess it should be either:
- Update .schema file
- Generate .ldif using slaptest
- Manually update the relevant attribute in cn=schema using an LDAP
browser to be the new value generated within the .ldif 4) Test
or:
- Update .schema file
- Generate .ldif using slaptest
- Hack the dn within the .ldif to add cn=schema,cn=config suffix
- Remove the entire cn={x}sirius-custom section
- Reload the entire cn={x}sirius-custom section using ldapadd
- Test
Does that sound correct?
No.
As soon as you use the word "hack" you should realize you're doing something wrong. As soon as you use the words "manually update" you should realize you're doing something wrong.