2:15 p.m.
Dear people of OpenLDAP,
I have a Univention Corporate Server (UCS) running at a local site, with a well-populated
LDAP.
I have a VM on the Internet, providing some web services.
I’d like to just clone the LDAP data from the local UCS machine to the VM regularly.
While copying the database is a no-brainer (scp & ssh-key), I currently fail at
importing the UCS-specific LDAP schemas into the LDAP of the VM. The schema conversion
created a {0}core.ldif as starting point. Importing this into openldap failed because I
have not the right to modification to core (of course).
Any hints?
Kind regards,
Jens
8:19 a.m.
--On Saturday, June 01, 2019 12:15 AM +0200 Jens Bürger
<jbuerger(a)arcor.de> wrote:
While copying the database is a no-brainer (scp & ssh-key), I
currently
fail at importing the UCS-specific LDAP schemas into the LDAP of the VM.
The schema conversion created a {0}core.ldif as starting point. Importing
this into openldap failed because I have not the right to modification to
core (of course).
Hi,
Unfortunately this information is rather vague, so it's hard to comment.
Generally one exports a database (whether it is the cn=config configuration
database or a binary backend) via slapcat, and imports it via slapadd.
Without more information, there's not much more guidance I can offer beyond
that.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
11:56 a.m.
[…]
Unfortunately this information is rather vague, so it's hard to
comment. Generally one exports a database (whether it is the cn=config configuration
database or a binary backend) via slapcat, and imports it via slapadd. Without more
information, there's not much more guidance I can offer beyond that.
The UCS has the cn=config backend. I did an export via slapcat. When I try to import it,
something like this happens:
slapadd -l export.ldif
5cfab27a <= str2entry: str2ad(univentionObjectType): attribute type undefined
Thus, the target server misses schemas defined by the univention guys. So the question is:
how can I export the database so that it contains the schemas or alternatively import all
the univention-specific schemas once at the target server.
Thanks in advance,
Jens
8:31 p.m.
--On Friday, June 07, 2019 9:56 PM +0200 Jens Bürger <jbuerger(a)arcor.de>
wrote:
slapadd -l export.ldif
5cfab27a <= str2entry: str2ad(univentionObjectType): attribute type
undefined
That would not be valid for importing a cn=config export, as there is no -n
0 option provided.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
8:47 a.m.
Hi Jens,
not sure if I understood completely, what you wish to do (a one time
clone and no continuous replication?), but as to schema, it should not
be too difficult. On the UCS server all schema needed should be stored
below /usr/share/univention-ldap/schema (see /etc/openldap/slapd.conf
and look for include commands if you cannot find the schema files). If
you convert all those files from slapd.conf format (xx.schema) to
cn=config (xx.ldif) format, which you seem to know how to do it, and
put them in the appropriate location of the target system (below
/etc/openldap/slapd.d/cn=schema/) renaming the files to cn={<running
number>}xx.ldif and restart the server it should work. The cleaner way
to do it, is instead of copying the files yourself with the danger to
make mistakes, to ldapadd the single ldif files, e.g.
ldapadd -x -D <binddn> -w <password> -f xx.ldif
(you can create a small shellscript for that)
Then the server creates those funny files below slapd.d/cn=schema by
itself. and there would not be any need to restart the server.
There is no need to change core.ldif nor to ldapadd that, because it is
already installed!
Hope this helped.
Cheers,
Peter
Am 31.05.19 um 23:15 schrieb Jens Bürger:
Dear people of OpenLDAP,
I have a Univention Corporate Server (UCS) running at a local site, with a well-populated
LDAP.
I have a VM on the Internet, providing some web services.
I’d like to just clone the LDAP data from the local UCS machine to the VM regularly.
While copying the database is a no-brainer (scp & ssh-key), I currently fail at
importing the UCS-specific LDAP schemas into the LDAP of the VM. The schema conversion
created a {0}core.ldif as starting point. Importing this into openldap failed because I
have not the right to modification to core (of course).
Any hints?
Kind regards,
Jens
--
Peter Gietz, CEO
DAASI International GmbH
Europaplatz 3
D-72072 Tübingen
Germany
phone: +49 7071 407109-0
fax: +49 7071 407109-9
email: peter.gietz(a)daasi.de
web: www.daasi.de
Sitz der Gesellschaft: Tübingen
Registergericht: Amtsgericht Stuttgart, HRB 382175
Geschäftsleitung: Peter Gietz
1:05 p.m.
Hi Peter,
thanks for your answer.
[…]
not sure if I understood completely, what you wish to do (a one time
clone and no continuous replication?),
A continuous replication in terms of maybe a daily copy-over.
but as to schema, it should not be too difficult. On the UCS server
all schema needed should be stored below /usr/share/univention-ldap/schema (see
/etc/openldap/slapd.conf and look for include commands if you cannot find the schema
files). If you convert all those files from slapd.conf format (xx.schema) to cn=config
(xx.ldif) format, which you seem to know how to do it, and put them in the appropriate
location of the target system (below /etc/openldap/slapd.d/cn=schema/) renaming the files
to cn={<running number>}xx.ldif and restart the server it should work. The cleaner
way to do it, is instead of copying the files yourself with the danger to make mistakes,
to ldapadd the single ldif files, e.g.
I now copied them. I had a look at this manual to convert the schemas:
https://www.lisenet.com/2015/convert-openldap-schema-to-ldif/
<https://www.lisenet.com/2015/convert-openldap-schema-to-ldif/>
As the UCS has ~40 schemas, editing them (removing the {} and the trailing lines) all
would consume too much time.
I copied the schemas under the respective directory. OpenLDAP seems to run with the
schemas now. But the problem I have is another one:
When trying to add the exported ldif I get the following error:
adding new entry „dc=my-domain,dc=tld"
ldap_add: Constraint violation (19)
additional info: structuralObjectClass: no user modification allowed
Jens
8:30 p.m.
--On Friday, June 07, 2019 11:05 PM +0200 Jens Bürger <jbuerger(a)arcor.de>
wrote:
When trying to add the exported ldif I get the following error:
adding new entry „dc=my-domain,dc=tld"
ldap_add: Constraint violation (19)
additional info: structuralObjectClass: no user modification allowed
As I stated originally, one uses slapadd to add data exported via slapcat.
slapadd is also substantially faster.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
12:21 p.m.
Jens Bürger <jbuerger(a)arcor.de> writes:
Hi Peter,
thanks for your answer.
[…]
not sure if I understood completely, what you wish to do (a one time clone and no
continuous replication?),
A continuous replication in terms of maybe a daily copy-over.
but as to schema, it should not be too difficult. On the UCS server all schema needed
should be stored below
/usr/share/univention-ldap/schema (see /etc/openldap/slapd.conf and look for include
commands if you cannot find the
schema files). If you convert all those files from slapd.conf format (xx.schema) to
cn=config (xx.ldif) format, which you seem to
know how to do it, and put them in the appropriate location of the target system (below
/etc/openldap/slapd.d/cn=schema/)
renaming the files to cn={<running number>}xx.ldif and restart the server it
should work. The cleaner way to do it, is instead of
copying the files yourself with the danger to make mistakes, to ldapadd the single ldif
files, e.g.
I now copied them. I had a look at this manual to convert the schemas:
https://www.lisenet.com/2015/convert-openldap-schema-to-ldif/
As the UCS has ~40 schemas, editing them (removing the {} and the trailing lines) all
would consume too much time.
I copied the schemas under the respective directory. OpenLDAP seems to run with the
schemas now. But the problem I have is
another one:
When trying to add the exported ldif I get the following error:
adding new entry „dc=my-domain,dc=tld"
ldap_add: Constraint violation (19)
additional info: structuralObjectClass: no user modification allowed
Frankly, ist is a long time ago that i have been engaged in
Kolab3/Univention systems, but i believe that UCS still is based on
Kolab3.
At that time the openldap source code had been modified. In particular
schema.c, schema_init.c and schema_prep.c. This modification required a
new private core.schema file.
With regard to your your effort to modify config database, the
appropriate database naming context is cn=config,cn=schema
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
1:25 a.m.
[…]
Frankly, ist is a long time ago that i have been engaged in
Kolab3/Univention systems, but i believe that UCS still is based on
Kolab3.
At that time the openldap source code had been modified. In particular
schema.c, schema_init.c and schema_prep.c. This modification required a
new private core.schema file.
But doesn't that mean it's basically impossible to run a stock OpenLDAP by copying
the UCS schemas and data?
With regard to your your effort to modify config database, the
appropriate database naming context is cn=config,cn=schema
I am not sure what this exactly means for my task :)
I am currently trying to import the UCS exported LDIF into the other (stock) OpenLDAP.
Interestingly, I now cannot add anything because of this error:
mdb_id2entry_put: mdb_put failed: MDB_KEYEXIST: Key/data pair already exists(-30799)
„dc=my-domain,dc=mytld“
When I slapcat the target LDAP, I see one entry regarding the dc. If I try to delete it
using ldapdelete, this fails with „no such object“.
Thanks in advance,
Jens
9:51 a.m.
Jens Bürger <jbuerger(a)arcor.de> writes:
[…]
Frankly, ist is a long time ago that i have been engaged in
Kolab3/Univention systems, but i believe that UCS still is based on
Kolab3.
At that time the openldap source code had been modified. In particular
schema.c, schema_init.c and schema_prep.c. This modification required a
new private core.schema file.
But doesn't that mean it's basically impossible to run a stock OpenLDAP by
copying the UCS schemas and data?
Yes, because stock OpenLDAP has built in some standard attribute
types. See schema_prep.c for static built in object classes and
attribute types.
[...]
-Dieter
--
Dieter Klünter | Systemberatung
http://sys4.de
GPG Key ID: E9ED159B
53°37'09,95"N
10°08'02,42"E
1384
days inactive
1397
days old
openldap-technical@openldap.org
9 comments
4 participants
participants (4)
-
Dieter Kluenter -
Jens Bürger -
Peter Gietz -
Quanah Gibson-Mount