I had to write my own schema for my application and I was struggling to figure out how to import the schema I wrote to cn=config. I had though I was missing something until I found this.
https://gist.github.com/jaseg/8577024
Notice the name of the script. Someone had to write this because there's no tool that you can use to import schemas when the slapd is configured with cn=config. You can get away with it by using include directive with slapd.conf. I know there's a way to do it with slaptest, but that method is just unacceptable. So, how I understood is, either you have to use slaptest to rebuild the entirety of the schema in ldif format, or you have to handcraft the schema in ldif by figuring out with {} index to start with. This is all backwards.
slapadd and slapmodify are just cranky tools you can only use in specific cases(eg: restoring from mdb_copy backup data). In most cases, using those tools to manipulate cn=config is near impossible.
I like the idea behind cn=config, but I believe that calling slapd.conf deprecated is just unfair with problems like these. Is there a set date/version for the drop of support for slapd.conf? I'd like to stick with slapd.conf if it's not going to happen in like 5 years time.
--On Saturday, April 2, 2022 4:33 PM +0800 David Timber dxdt@dev.snart.me wrote:
I had to write my own schema for my application and I was struggling to figure out how to import the schema I wrote to cn=config. I had though I was missing something until I found this.
https://gist.github.com/jaseg/8577024
Notice the name of the script. Someone had to write this because there's no tool that you can use to import schemas when the slapd is configured with cn=config.
This is incorrect. You can use ldapadd to import schema to an existing cn=config database. Just like you add entries to any other database. It's generally clear the person who wrote the "tool" you are referring to is utterly clueless in how to use OpenLDAP.
Regards, Quanah
Le 02/04/2022 à 09:33, David Timber a écrit :
I had to write my own schema for my application and I was struggling to figure out how to import the schema I wrote to cn=config. I had though I was missing something until I found this.
https://gist.github.com/jaseg/8577024
Notice the name of the script. Someone had to write this because there's no tool that you can use to import schemas when the slapd is configured with cn=config.
Note that Fusion Directory project provides an utility for this: https://manpages.debian.org/bullseye/fusiondirectory-schema/fusiondirectory-...
You can get away with it by using include directive with slapd.conf.
You can use olcInclude with cn=config.
On 4/4/22 23:02, Clément OUDOT wrote:
Le 02/04/2022 à 09:33, David Timber a écrit :
I had to write my own schema for my application and I was struggling to figure out how to import the schema I wrote to cn=config. I had though I was missing something until I found this.
https://gist.github.com/jaseg/8577024
Notice the name of the script. Someone had to write this because there's no tool that you can use to import schemas when the slapd is configured with cn=config.
Note that Fusion Directory project provides an utility for this: https://manpages.debian.org/bullseye/fusiondirectory-schema/fusiondirectory-...
You can get away with it by using include directive with slapd.conf.
You can use olcInclude with cn=config.
https://www.openldap.org/doc/admin26/slapdconf2.html#cn=config
I don't see olcInclude in the doc.
https://lists.openldap.org/hyperkitty/list/openldap-commit@openldap.org/mess...
This is an undocumented feature. I'm not writing/using any script. I'm not using slaptest to convert schema to ldif.
On 4/4/22 23:00, Quanah Gibson-Mount wrote:
--On Saturday, April 2, 2022 4:33 PM +0800 David Timber dxdt@dev.snart.me wrote:
I had to write my own schema for my application and I was struggling to figure out how to import the schema I wrote to cn=config. I had though I was missing something until I found this.
https://gist.github.com/jaseg/8577024
Notice the name of the script. Someone had to write this because there's no tool that you can use to import schemas when the slapd is configured with cn=config.
This is incorrect. You can use ldapadd to import schema to an existing cn=config database. Just like you add entries to any other database. It's generally clear the person who wrote the "tool" you are referring to is utterly clueless in how to use OpenLDAP.
Regards, Quanah
https://www.linuxquestions.org/questions/linux-server-73/how-to-add-a-new-sc...
This is all I can find. I'm not doing that. Are you saying I can just use ldapadd? Care to elaborate?
--On Tuesday, April 5, 2022 12:24 AM +0800 David Timber dxdt@dev.snart.me wrote:
https://www.openldap.org/doc/admin26/slapdconf2.html#cn=config
I don't see olcInclude in the doc.
https://lists.openldap.org/hyperkitty/list/openldap-commit@openldap.org/m essage/EBTNZ6QPDTU3YJUT4LSU3FDIOICVKZ2T/
This is an undocumented feature. I'm not writing/using any script. I'm not using slaptest to convert schema to ldif.
It's include, not olcInclude, if you're using slapadd. Example:
https://gist.github.com/quanah/4c6e477c9946442889b9f84de2091fbf#file-gistfile1-txt-L16
This is incorrect. You can use ldapadd to import schema to an existing cn=config database. Just like you add entries to any other database. It's generally clear the person who wrote the "tool" you are referring to is utterly clueless in how to use OpenLDAP.
Regards, Quanah
https://www.linuxquestions.org/questions/linux-server-73/how-to-add-a-new -schema-to-openldap-2-4-11-a-700452/
This is all I can find. I'm not doing that. Are you saying I can just use ldapadd? Care to elaborate?
As long as the schema file being imported is in cn=config format, you can use ldapadd to add it. All schema shipped with OpenLDAP are provided in both slapd.conf ("x.schema") and cn=config ("x.ldif") formats. If you are using a pre cn=config "x.schema" file, you need to convert it to cn=config format first. The "slaptest" utility explicitly allows one to do this.
So assuming you have a cn=config formatted ldif file:
ldapadd .... -f inetorgperson.ldif
Regards, Quanah
You didn't read my original mail. Let me clearify again.
The point was that why I have to make a separate conf file to feed it to slaptest to generate ldif whereas with slapd.conf you can just use include. And another problem with cn=config is that if you wanna add a schema, you have to either rebuild the entire schema attributes or handcraft ldif with proper starting {} index(ldapadd will not do this for you).
cn=config: 1 text editor, 2 tools, 2 files involved slapd.conf: 1 text editor involved
to achieve the same goal.
If you don't see a problem here, just stay out of it.
On 5 April 2022 12:21:37 am AWST, Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Tuesday, April 5, 2022 12:24 AM +0800 David Timber dxdt@dev.snart.me wrote:
https://www.openldap.org/doc/admin26/slapdconf2.html#cn=config
I don't see olcInclude in the doc.
https://lists.openldap.org/hyperkitty/list/openldap-commit@openldap.org/m essage/EBTNZ6QPDTU3YJUT4LSU3FDIOICVKZ2T/
This is an undocumented feature. I'm not writing/using any script. I'm not using slaptest to convert schema to ldif.
It's include, not olcInclude, if you're using slapadd. Example:
https://gist.github.com/quanah/4c6e477c9946442889b9f84de2091fbf#file-gistfile1-txt-L16
This is incorrect. You can use ldapadd to import schema to an existing cn=config database. Just like you add entries to any other database. It's generally clear the person who wrote the "tool" you are referring to is utterly clueless in how to use OpenLDAP.
Regards, Quanah
https://www.linuxquestions.org/questions/linux-server-73/how-to-add-a-new -schema-to-openldap-2-4-11-a-700452/
This is all I can find. I'm not doing that. Are you saying I can just use ldapadd? Care to elaborate?
As long as the schema file being imported is in cn=config format, you can use ldapadd to add it. All schema shipped with OpenLDAP are provided in both slapd.conf ("x.schema") and cn=config ("x.ldif") formats. If you are using a pre cn=config "x.schema" file, you need to convert it to cn=config format first. The "slaptest" utility explicitly allows one to do this.
So assuming you have a cn=config formatted ldif file:
ldapadd .... -f inetorgperson.ldif
Regards, Quanah
--On Tuesday, April 5, 2022 8:44 AM +0800 David Timber dxdt@dev.snart.me wrote:
You didn't read my original mail. Let me clearify again.
The point was that why I have to make a separate conf file to feed it to slaptest to generate ldif whereas with slapd.conf you can just use include. And another problem with cn=config is that if you wanna add a schema, you have to either rebuild the entire schema attributes or handcraft ldif with proper starting {} index(ldapadd will not do this for you).
cn=config: 1 text editor, 2 tools, 2 files involved slapd.conf: 1 text editor involved
to achieve the same goal.
If you don't see a problem here, just stay out of it.
I did read your email, I understood it perfectly, but it's abundantly clear you were unable to grasp my answer.
To be clear, cn=config is a DATABASE it is NOT A TEXT FILE. You should never be using a text editor on the contents under cn=config. If you need to manipulate a text version of it, EXPORT it to LDIF with slapcat.
If you have a cn=config LDIF file you will be loading via slapadd, you can trivially use an "include" line just like in the gist I linked you. Otherwise, if you're online, you can simply use ldapadd. As far as ORDERING is concerned, you can use weights to tweak the order when you ldapadd it, but you would have to mildly tweak the input LDIF file (so then an editor is involved). For example, using the java.ldif file:
dn: {3}cn=java,cn=schema,cn=config objectClass: olcSchemaConfig cn: {3}java ....
And you're literally missing the point that a ".schema" file is a syntax specific to slapd.conf and a ".ldif" file is a syntax specific to cn=config. Just as you cannot load a ".schema" file into cn=config, you cannot load a ".ldif" file into slapd.conf. The two things are *equivalent* representations for their respective configuration types. In the future, expect only ".ldif" files to get shipped once we finalize deprecating slapd.conf.
You seem to lack a fundamental concept of what cn=config is and of how to correctly utilize it. That's not the projects faults and I'd expect you actually spend some time learning how things operating before criticizing it out of ignorance.
Regards, Quanah
Quanah, I think I've pissed you off. I apologise. Well, if you don't see the problem, then that's fine. No need to get pissed off. You don't have to reply. That's fine. Just chill, man. It's not good for you. I read the whole admin guide and man pages. I'm not complaining just because out of ignorance. That kind of assumption is just a personal attack, not very nice of you(thf, I started it. Sorry). I'm making this point because I care about OpenLDAP and I want it to be better. I don't understand why we have to get emotional here.
I know how to import schemas with cn=config. That was never a question. I was just complaining because it's a tedious process and I believe that it shouldn't be like this. The whole cn=config matter was not even my question in the first place. My concern was that I'm not happy with how cn=config handles schemas and I want to stick with "deprecated" slapd.conf. slaptest has to be used to convert schema to ldif, which is in no way intuitive and convenient.
On 5/4/22 12:27, Quanah Gibson-Mount wrote:
And you're literally missing the point that a ".schema" file is a syntax specific to slapd.conf and a ".ldif" file is a syntax specific to cn=config. Just as you cannot load a ".schema" file into cn=config, you cannot load a ".ldif" file into slapd.conf. The two things are *equivalent* representations for their respective configuration types. In the future, expect only ".ldif" files to get shipped once we finalize deprecating slapd.conf.
The format of schema is defined in RFC 4512. It's universal. OpenLDAP has no right to be difficult in incorporating schemas. Forcing users to convert it to ldif to just fit into the OpenLDAP specific cn=config format is not just fair, especially for the sake of compatibility. I'd have been happy if I could just use include: attribute to load .schema.
To anyone else, just forget everything I said. I just wanted to know when the slapd.conf support will be dropped. THAT was my question.
And, don't get me wrong. cn=config is a great idea!
--On Tuesday, April 5, 2022 3:10 PM +0800 David Timber dxdt@dev.snart.me wrote:
slaptest has to be used to convert schema to ldif, which is in no way intuitive and convenient.
As Ondrej noted, it does not in fact have to be used to convert schema from the older slapd.conf format to cn=config format, he provided a trivial example of how to do so with perl.
The issue you seem to be unhappy about is that not everyone who provides schema for use with OpenLDAP has taken the time to provide both slapd.conf and cn=config formatted versions. There's nothing the project can do about that other than what it has already done -- Provide a tool to do a one time conversion process. But it is not the only way to do this.
Regards, Quanah
On 4/5/22 08:10, David Timber wrote:
I know how to import schemas with cn=config. That was never a question. I was just complaining because it's a tedious process and I believe that it shouldn't be like this.
I also think that cn=config should not be so complicated. And I've looked into supporting this schema in web2ldap.
For now I'm just happy that static slapd.conf is still supported. It's still the most DevOps-friendly way to configure OpenLDAP.
Ciao, Michael.
Michael, hello.
On 5 Apr 2022, at 16:01, Michael Ströder wrote:
On 4/5/22 08:10, David Timber wrote:
I know how to import schemas with cn=config. That was never a question. I was just complaining because it's a tedious process and I believe that it shouldn't be like this.
I also think that cn=config should not be so complicated. And I've looked into supporting this schema in web2ldap.
Can you say a little more about how slapd.d is complicated? I ask because I've never used slapd.conf, and I'm worried I'm missing something, or that there's an interestingly different perspective on how to configure openldap, which I could usefully learn about.
If I want to set up a new (testing?) instance, or test a tweaked configuration, then I blow away any pre-existing slapd.d, slapadd slapd.ldif, upload a dump of the live database (which takes a few seconds with -q), start slapd, and off we go.
All of the configuration is in that single slapd.ldif file. I might occasionally make live tweaks to the configuration with ldapmodify, but after testing I would freeze them in the version-controlled slapd.ldif.
I can see that there's a way of working where the 'live' cn=config tree is the source of truth, and one backs that up carefully, but that doesn't seem an entirely comfortable way of working, to me. And I can see that if there were a very high volume of writes, then the few seconds of primary-server downtime here could become intricate. But if one had a setup like that, then presumably one has a multi-master configuration, so that the primaries could have their configurations updated from a single slapd.ldif in rotation.
For now I'm just happy that static slapd.conf is still supported. It's still the most DevOps-friendly way to configure OpenLDAP.
I'm not really sure what devops-friendly means here. I think my problem -- the source of my puzzlement -- is that I can't see much significant difference between slapd.conf and slapd.ldif other than details of the syntax (which to my eyes is less weird in the latter case than the former).
Or: what would I be losing if support for slapd.conf disappeared tomorrow?
Best wishes,
Norman
--On Tuesday, April 5, 2022 5:34 PM +0100 Norman Gray gray@nxg.name wrote:
I'm not really sure what devops-friendly means here. I think my problem -- the source of my puzzlement -- is that I can't see much significant difference between slapd.conf and slapd.ldif other than details of the syntax (which to my eyes is less weird in the latter case than the former).
Or: what would I be losing if support for slapd.conf disappeared tomorrow?
The only thing that comes to mind is the ability to have comments in the configuration. Other than that, nothing. Even internally, slapd.conf is converted to a cn=config db by slapd. What cn=config does that slapd.conf doesn't do, is help ensure correctness in configurations.
--Quanah
On 4/5/22 17:34, Norman Gray wrote:
I've never used slapd.conf, and I'm worried I'm missing something, or that there's an interestingly different perspective on how to configure openldap, which I could usefully learn about.
Don't worry about missing something magical. slapd.conf and cn=config are supposed to be identical regarding features.
If I want to set up a new (testing?) instance, or test a tweaked configuration, then I blow away any pre-existing slapd.d, slapadd slapd.ldif, upload a dump of the live database (which takes a few seconds with -q), start slapd, and off we go. All of the configuration is in that single slapd.ldif file.
Basically you're imitating the behaviour of a static configuration by using some extra command-line step. IMHO that's fine if it already works for you. And it allows clean staging.
I can see that there's a way of working where the 'live' cn=config tree is the source of truth, and one backs that up carefully, but that doesn't seem an entirely comfortable way of working, to me.
Not comfortable for me either.
And I can see that if there were a very high volume of writes, then the few seconds of primary-server downtime here could become intricate. But if one had a setup like that, then presumably one has a multi-master configuration, so that the primaries could have their configurations updated from a single slapd.ldif in rotation.
The latter has been also my argument for years.
Well, depending on which schema changes you're doing updating replicas one after the other might not work. But this also applies to updating the live config.
I'm not really sure what devops-friendly means here.
All config management systems comes with a decent templating engine for creating text files, let a service validate them and have a notification system for restarting the service in case of a config change. This is very simple to understand and idempotent without extra procedure.
Ciao, Michael.
Michael Ströder wrote:
On 4/5/22 17:34, Norman Gray wrote:
I'm not really sure what devops-friendly means here.
All config management systems comes with a decent templating engine for creating text files, let a service validate them and have a notification system for restarting the service in case of a config change. This is very simple to understand and idempotent without extra procedure.
You're talking 1970s style config file management. There's no good reason to force a restart of a mission-critical service just to modify its configuration.
We've had this debate before so I won't comment further on this topic in this thread.
On 4/5/22 20:34, Howard Chu wrote:
You're talking 1970s style config file management. There's no good reason to force a restart of a mission-critical service just to modify its configuration.
In the same spirit I can answer: You're talking about a 1970s style system architecture with one monolithic big iron.
Ciao, Michael.
On Tue, Apr 05, 2022 at 05:01:44PM +0200, Michael Ströder wrote:
On 4/5/22 08:10, David Timber wrote:
I know how to import schemas with cn=config. That was never a question. I was just complaining because it's a tedious process and I believe that it shouldn't be like this.
I also think that cn=config should not be so complicated. And I've looked into supporting this schema in web2ldap.
Hi Michael, are you also talking about schema or something else here? So far this thread hasn't shown much that's complicated about the schema. True, we haven't touched on operational attributes and other parts of the schema compiled into slapd/loadable modules but my guess that's not what you're talking about either since they are no different from slapd.conf.
For now I'm just happy that static slapd.conf is still supported. It's still the most DevOps-friendly way to configure OpenLDAP.
We're not the outliers here, every major DB engine does the same thing. PostgreSQL and MySQL/MariaDB don't have an option to have a plain text file driving large parts of their configuration at all. How come people cope with that just fine and they can't do the same with OpenLDAP?
Regards,
On Tue, Apr 05, 2022 at 02:10:37PM +0800, David Timber wrote:
I know how to import schemas with cn=config. That was never a question. I was just complaining because it's a tedious process and I believe that it shouldn't be like this. The whole cn=config matter was not even my question in the first place. My concern was that I'm not happy with how cn=config handles schemas and I want to stick with "deprecated" slapd.conf. slaptest has to be used to convert schema to ldif, which is in no way intuitive and convenient.
Hi David, you're right, it doesn't have to be like this, and it's quite trivial to bypass slaptest as I showed earlier. The contents of the schema are the same they just have to be encapsulated in attributes and an LDAP entry.
On 5/4/22 12:27, Quanah Gibson-Mount wrote:
And you're literally missing the point that a ".schema" file is a syntax specific to slapd.conf and a ".ldif" file is a syntax specific to cn=config. Just as you cannot load a ".schema" file into cn=config, you cannot load a ".ldif" file into slapd.conf. The two things are *equivalent* representations for their respective configuration types. In the future, expect only ".ldif" files to get shipped once we finalize deprecating slapd.conf.
The format of schema is defined in RFC 4512. It's universal. OpenLDAP has no right to be difficult in incorporating schemas. Forcing users to convert it to ldif to just fit into the OpenLDAP specific cn=config format is not just fair, especially for the sake of compatibility. I'd have been happy if I could just use include: attribute to load .schema.
Again, the contents of e.g. attributetype and olcAttributeTypes: are identical, both using the same RFC 4512 format as you rightly referenced. You probably want to explain again where you are coming from as I see no issue here.
Regards,
David Timber wrote:
Quanah, I think I've pissed you off. I apologise. Well, if you don't see the problem, then that's fine. No need to get pissed off. You don't have to reply. That's fine. Just chill, man. It's not good for you. I read the whole admin guide and man pages. I'm not complaining just because out of ignorance. That kind of assumption is just a personal attack, not very nice of you(thf, I started it. Sorry). I'm making this point because I care about OpenLDAP and I want it to be better. I don't understand why we have to get emotional here.
I know how to import schemas with cn=config. That was never a question.
No. You've demonstrated that you don't understand at all.
I was just complaining because it's a tedious process and I believe that it shouldn't be like this.
It isn't. You've made more than one factual error describing its requirements.
The whole cn=config matter was not even my question in the first place. My concern was that I'm not happy with how cn=config handles schemas and I want to stick with "deprecated" slapd.conf. slaptest has to be used to convert schema to ldif, which is in no way intuitive and convenient.
On 5/4/22 12:27, Quanah Gibson-Mount wrote:
And you're literally missing the point that a ".schema" file is a syntax specific to slapd.conf and a ".ldif" file is a syntax specific to cn=config. Just as you cannot load a ".schema" file into cn=config, you cannot load a ".ldif" file into slapd.conf. The two things are *equivalent* representations for their respective configuration types. In the future, expect only ".ldif" files to get shipped once we finalize deprecating slapd.conf.
The format of schema is defined in RFC 4512. It's universal. OpenLDAP has no right to be difficult in incorporating schemas. Forcing users to convert it to ldif to just fit into the OpenLDAP specific cn=config format is not just fair, especially for the sake of compatibility. I'd have been happy if I could just use include: attribute to load .schema.
To anyone else, just forget everything I said. I just wanted to know when the slapd.conf support will be dropped. THAT was my question.
And, don't get me wrong. cn=config is a great idea!
David Timber wrote:
You didn't read my original mail. Let me clearify again.
The point was that why I have to make a separate conf file to feed it to slaptest to generate ldif whereas with slapd.conf you can just use include.
And another problem with cn=config is that if you wanna add a schema, you have to either rebuild the entire schema attributes or handcraft ldif with proper starting {} index(ldapadd will not do this for you).
That's completely false.
cn=config: 1 text editor, 2 tools, 2 files involved slapd.conf: 1 text editor involved
to achieve the same goal.
If you don't see a problem here, just stay out of it.
If you don't want to listen to the developers of the software explain to you how the software works, just stay out of it and use something else.
On 5 April 2022 12:21:37 am AWST, Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Tuesday, April 5, 2022 12:24 AM +0800 David Timber <dxdt@dev.snart.me> wrote: https://www.openldap.org/doc/admin26/slapdconf2.html#cn=config I don't see olcInclude in the doc. https://lists.openldap.org/hyperkitty/list/openldap-commit@openldap.org/m essage/EBTNZ6QPDTU3YJUT4LSU3FDIOICVKZ2T/ This is an undocumented feature. I'm not writing/using any script. I'm not using slaptest to convert schema to ldif. It's include, not olcInclude, if you're using slapadd. Example: <https://gist.github.com/quanah/4c6e477c9946442889b9f84de2091fbf#file-gistfile1-txt-L16> This is incorrect. You can use ldapadd to import schema to an existing cn=config database. Just like you add entries to any other database. It's generally clear the person who wrote the "tool" you are referring to is utterly clueless in how to use OpenLDAP. Regards, Quanah https://www.linuxquestions.org/questions/linux-server-73/how-to-add-a-new -schema-to-openldap-2-4-11-a-700452/ This is all I can find. I'm not doing that. Are you saying I can just use ldapadd? Care to elaborate? As long as the schema file being imported is in cn=config format, you can use ldapadd to add it. All schema shipped with OpenLDAP are provided in both slapd.conf ("x.schema") and cn=config ("x.ldif") formats. If you are using a pre cn=config "x.schema" file, you need to convert it to cn=config format first. The "slaptest" utility explicitly allows one to do this. So assuming you have a cn=config formatted ldif file: ldapadd .... -f inetorgperson.ldif Regards, Quanah
You don't see the problem, too. That's fine. I just wanna know when you'll pull slapd.conf off the shelf, please.
On 5 April 2022 4:22:45 pm AWST, Howard Chu hyc@symas.com wrote:
David Timber wrote:
You didn't read my original mail. Let me clearify again.
The point was that why I have to make a separate conf file to feed it to slaptest to generate ldif whereas with slapd.conf you can just use include.
And another problem with cn=config is that if you wanna add a schema, you have to either rebuild the entire schema attributes or handcraft ldif with proper starting {} index(ldapadd will not do this for you).
That's completely false.
cn=config: 1 text editor, 2 tools, 2 files involved slapd.conf: 1 text editor involved
to achieve the same goal.
If you don't see a problem here, just stay out of it.
If you don't want to listen to the developers of the software explain to you how the software works, just stay out of it and use something else.
On 5 April 2022 12:21:37 am AWST, Quanah Gibson-Mount quanah@fast-mail.org wrote:
--On Tuesday, April 5, 2022 12:24 AM +0800 David Timber <dxdt@dev.snart.me> wrote: https://www.openldap.org/doc/admin26/slapdconf2.html#cn=config I don't see olcInclude in the doc. https://lists.openldap.org/hyperkitty/list/openldap-commit@openldap.org/m essage/EBTNZ6QPDTU3YJUT4LSU3FDIOICVKZ2T/ This is an undocumented feature. I'm not writing/using any script. I'm not using slaptest to convert schema to ldif. It's include, not olcInclude, if you're using slapadd. Example: <https://gist.github.com/quanah/4c6e477c9946442889b9f84de2091fbf#file-gistfile1-txt-L16> This is incorrect. You can use ldapadd to import schema to an existing cn=config database. Just like you add entries to any other database. It's generally clear the person who wrote the "tool" you are referring to is utterly clueless in how to use OpenLDAP. Regards, Quanah https://www.linuxquestions.org/questions/linux-server-73/how-to-add-a-new -schema-to-openldap-2-4-11-a-700452/ This is all I can find. I'm not doing that. Are you saying I can just use ldapadd? Care to elaborate? As long as the schema file being imported is in cn=config format, you can use ldapadd to add it. All schema shipped with OpenLDAP are provided in both slapd.conf ("x.schema") and cn=config ("x.ldif") formats. If you are using a pre cn=config "x.schema" file, you need to convert it to cn=config format first. The "slaptest" utility explicitly allows one to do this. So assuming you have a cn=config formatted ldif file: ldapadd .... -f inetorgperson.ldif Regards, Quanah-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
On Mon, Apr 04, 2022 at 11:24:36PM +0800, David Timber wrote:
This is all I can find. I'm not doing that. Are you saying I can just use ldapadd? Care to elaborate?
If you have a slapd.conf style file you have to convert it first, but it's not rocket science, this is a simple filter I came up with after 5 minutes and it seems to process all the schema files in OpenLDAP sources just fine (YMMV):
sed -e 's/^\t+/ /' | \ perl -p0e 's/\n //g' | \ sed \ -e "1i\cn=$name,cn=schema,cn=config\nobjectClass: olcSchemaConfig\ncn: $name" \ -e '/^#.*//' \ -e '/^[\s]*$/d' \ -e 's/^attributetype\s+/olcAttributeTypes: /i' \ -e 's/^objectclass\s+/olcObjectClasses: /i' \ -e 's/^ditcontentrule\s+/olcDitContentRules: /i' \ -e 's/^ldap-syntax\s+/olcLdapSyntaxes: /i' \ -e 's/^objectidentifier\s+/olcObjectIdentifier: /i'
Regards,
--On Monday, April 4, 2022 8:30 PM +0200 Ondřej Kuzník ondra@mistotebe.net wrote:
On Mon, Apr 04, 2022 at 11:24:36PM +0800, David Timber wrote:
This is all I can find. I'm not doing that. Are you saying I can just use ldapadd? Care to elaborate?
If you have a slapd.conf style file you have to convert it first, but it's not rocket science, this is a simple filter I came up with after 5 minutes and it seems to process all the schema files in OpenLDAP sources just fine (YMMV):
sed -e 's/^\t+/ /' | \ perl -p0e 's/\n //g' | \ sed \ -e "1i\cn=$name,cn=schema,cn=config\nobjectClass: olcSchemaConfig\ncn: $name" \ -e '/^#.*//' \ -e '/^[\s]*$/d' \ -e 's/^attributetype\s+/olcAttributeTypes: /i' \ -e 's/^objectclass\s+/olcObjectClasses: /i' \ -e 's/^ditcontentrule\s+/olcDitContentRules: /i' \ -e 's/^ldap-syntax\s+/olcLdapSyntaxes: /i' \ -e 's/^objectidentifier\s+/olcObjectIdentifier: /i'
As I noted, we already ship all official schema in LDIF format, so there's really no reason to have to do this. I guess it's useful for custom schema if using slaptest is too technically challenging.
--Quanah
David Timber wrote:
I had to write my own schema for my application and I was struggling to figure out how to import the schema I wrote to cn=config. I had though I was missing something until I found this.
https://gist.github.com/jaseg/8577024
Notice the name of the script. Someone had to write this because there's no tool that you can use to import schemas when the slapd is configured with cn=config. You can get away with it by using include directive with slapd.conf. I know there's a way to do it with slaptest, but that method is just unacceptable. So, how I understood is, either you have to use slaptest to rebuild the entirety of the schema in ldif format,
or you have to handcraft the schema in ldif by figuring out with {} index to start with. This is all backwards.
No. cn=config autogenerates these {} indices. This has been documented since 2007. https://openldap.org/doc/admin24/slapdconf2.html
"Some of the entries listed above have a numeric index "{X}" in their names. While most configuration settings have an inherent ordering dependency (i.e., one setting must take effect before a subsequent one may be set), LDAP databases are inherently unordered. The numeric index is used to enforce a consistent ordering in the configuration database, so that all ordering dependencies are preserved. In most cases the index does not have to be provided; it will be automatically generated based on the order in which entries are created."
slapadd and slapmodify are just cranky tools you can only use in specific cases(eg: restoring from mdb_copy backup data). In most cases, using those tools to manipulate cn=config is near impossible.
Using slapadd to add a single schema LDIF is trivial. So is using ldapadd. cn=config is just an LDAP database, you use standard LDAP operations on it.
openldap-technical@openldap.org
-
Andy Dorman -
Clément OUDOT -
David Timber -
Howard Chu -
Michael Ströder -
Norman Gray -
Ondřej Kuzník -
Quanah Gibson-Mount