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.
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:
dn: cn={4}sirius-custom ... cn: {4}sirius-custom
...which then means I still can't add it directly using ldapadd without further processing.
Also that begs another question: what happens if you want to modify an existing schema, e.g. if I need to hack a schema by hand and reload it into openldap so that it takes effect? Normally I would change the schema file on disk, restart slapd and it would just work.
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:
1) Update .schema file 2) Generate .ldif using slaptest 3) Manually update the relevant attribute in cn=schema using an LDAP browser to be the new value generated within the .ldif 4) Test
or:
1) Update .schema file 2) Generate .ldif using slaptest 3) Hack the dn within the .ldif to add cn=schema,cn=config suffix 4) Remove the entire cn={x}sirius-custom section 5) Reload the entire cn={x}sirius-custom section using ldapadd 6) Test
Does that sound correct?
ATB,
Mark.