Hello, in my organization I have a master ldap server based on openLDAP. Now I have installed a new ldap server (slave) based on Fedora Directory Server. The openLDAP server have a replica directive in the cenfiguration file to replicate the modify to FDS server. Modify entry that exist on master server work fine. The problem in the insert of e new user into the master server. When I try to insert e new user from the followind ldif, i see an error in the insert.
testuser.ldif:
dn: uid=testuser, dc=studenti, dc=unipmn,dc=it givenName: TEST postalCode: 1920 objectClass: top objectClass: person objectClass: inetOrgPerson objectClass: posixAccount userPassword:: e21kNX0rcmM3V2xoeE9QcnZLc0MvdlJtRlZnPT0= mail: roberto.pinna@studenti.unipmn.it uid: testuser uidNumber: 6763578 cn: TEST USER carLicense: PNNRRT73B26A182A loginShell: /bin/bash gidNumber: 100 homeDirectory: /home/test sn: TEST
Error from FDS error log:
Entry "uid=testuser,dc=studenti,dc=unipmn,dc=it" -- attribute "structuralobjectclass" not allowed
Error from slurpd (on master openLDAP server):
Error: ldap_add_s failed adding DN "uid=testuser,dc=studenti,dc=unipmn,dc=it": attribute "structuralobjectclass" not allowed
Information from reject file of the surpd:
ERROR:: T2JqZWN0IGNsYXNzIHZpb2xhdGlvbjogYXR0cmlidXRlICJzdHJ1Y3R1cmFsb2JqZWN0Y2 xhc3MiIG5vdCBhbGxvd2VkCg== replica: db.mfn.unipmn.it:389 time: 1189156318.0 dn: uid=testuser,dc=studenti,dc=unipmn,dc=it changetype: add givenName: TEST postalCode: 1920 objectClass: top objectClass: person objectClass: inetOrgPerson objectClass: posixAccount userPassword:: e21kNX0rcmM3V2xoeE9QcnZLc0MvdlJtRlZnPT0= uid: testuser mail: roberto.pinna@studenti.unipmn.it uidNumber: 6763578 cn: TEST USER carLicense: PNNRRT73B26A182A loginShell: /bin/bash gidNumber: 100 homeDirectory: /home/test sn: TEST structuralObjectClass: inetOrgPerson entryUUID: 21363b50-f16e-102b-96d1-e14b33466425 creatorsName: cn=manager,dc=unipmn,dc=it createTimestamp: 20070907091157Z entryCSN: 20070907091157Z#000000#00#000000 modifiersName: cn=manager,dc=unipmn,dc=it modifyTimestamp: 20070907091157Z
I have see that the structuralobjectclass is not defined in the attributes available in FDS.... how can resolve the probem?
Thank's in advance
-------------------------------------------------------------- Matteo Angelino Dipartimento di Informatica Via Bellini 25\G 15100 Alessandria ITALY Tel: +39 0131 360375 Email: matteo.angelino@mfn.unipmn.it --------------------------------------------------------------
Matteo Angelino wrote:
Hello, in my organization I have a master ldap server based on openLDAP. Now I have installed a new ldap server (slave) based on Fedora Directory Server. The openLDAP server have a replica directive in the cenfiguration file to replicate the modify to FDS server. Modify entry that exist on master server work fine. The problem in the insert of e new user into the master server. When I try to insert e new user from the followind ldif, i see an error in the insert.
testuser.ldif:
dn: uid=testuser, dc=studenti, dc=unipmn,dc=it givenName: TEST postalCode: 1920 objectClass: top objectClass: person objectClass: inetOrgPerson objectClass: posixAccount userPassword:: e21kNX0rcmM3V2xoeE9QcnZLc0MvdlJtRlZnPT0= mail: roberto.pinna@studenti.unipmn.it uid: testuser uidNumber: 6763578 cn: TEST USER carLicense: PNNRRT73B26A182A loginShell: /bin/bash gidNumber: 100 homeDirectory: /home/test sn: TEST
Error from FDS error log:
Entry "uid=testuser,dc=studenti,dc=unipmn,dc=it" -- attribute "structuralobjectclass" not allowed
Error from slurpd (on master openLDAP server):
Error: ldap_add_s failed adding DN "uid=testuser,dc=studenti,dc=unipmn,dc=it": attribute "structuralobjectclass" not allowed
Information from reject file of the surpd:
ERROR:: T2JqZWN0IGNsYXNzIHZpb2xhdGlvbjogYXR0cmlidXRlICJzdHJ1Y3R1cmFsb2JqZWN0Y2 xhc3MiIG5vdCBhbGxvd2VkCg== replica: db.mfn.unipmn.it:389 time: 1189156318.0 dn: uid=testuser,dc=studenti,dc=unipmn,dc=it changetype: add givenName: TEST postalCode: 1920 objectClass: top objectClass: person objectClass: inetOrgPerson objectClass: posixAccount userPassword:: e21kNX0rcmM3V2xoeE9QcnZLc0MvdlJtRlZnPT0= uid: testuser mail: roberto.pinna@studenti.unipmn.it uidNumber: 6763578 cn: TEST USER carLicense: PNNRRT73B26A182A loginShell: /bin/bash gidNumber: 100 homeDirectory: /home/test sn: TEST structuralObjectClass: inetOrgPerson entryUUID: 21363b50-f16e-102b-96d1-e14b33466425 creatorsName: cn=manager,dc=unipmn,dc=it createTimestamp: 20070907091157Z entryCSN: 20070907091157Z#000000#00#000000 modifiersName: cn=manager,dc=unipmn,dc=it modifyTimestamp: 20070907091157Z
I have see that the structuralobjectclass is not defined in the attributes available in FDS.... how can resolve the probem?
I suggest adding an operational attribute called 'structuralObjectClass' to Fedora DS. Maybe you can just copy the definition of it from openldap.
Thank's in advance
Matteo Angelino Dipartimento di Informatica Via Bellini 25\G 15100 Alessandria ITALY Tel: +39 0131 360375 Email: matteo.angelino@mfn.unipmn.it
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Richard Megginson wrote:
I have see that the structuralobjectclass is not defined in the attributes available in FDS.... how can resolve the probem?
I suggest adding an operational attribute called 'structuralObjectClass' to Fedora DS. Maybe you can just copy the definition of it from openldap.
Since the structuralObjectClass attribute is supposed to have a very special meaning for the DSA (RFC 4512), just adding it as a user attribute seems to me quite a broken approach. Provided you're running a decent version of OpenLDAP, you should be able to filter out undesired attributes from the replication process. For example, in slapd.conf (from slapd.conf(5) man page of OpenLDAP 2.3, but the feature exists since OpenLDAP 2.1, I think)
replica [...] attr!=structuralObjectClass
will prevent slurpd from replicating the negated attribute list.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Since the structuralObjectClass attribute is supposed to have a very special meaning for the DSA (RFC 4512), just adding it as a user attribute seems to me quite a broken approach. Provided you're running a decent version of OpenLDAP, you should be able to filter out undesired attributes from the replication process. For example, in slapd.conf (from slapd.conf(5) man page of OpenLDAP 2.3, but the feature exists since OpenLDAP 2.1, I think)
replica [...] attr!=structuralObjectClass
will prevent slurpd from replicating the negated attribute list.
Just for the records: a custom patch in this sense was developed by SysNet back in the old times of OpenLDAP 2.0 exactly for the purpose of replicating an OpenLDAP server to a proprietary LDAP server that didn't like many operational attributes slurpd was willing to push in. It also provided partial subtree replication capabilities.
A similar patch was prepared in the meanwhile by Symas and the two merged into OpenLDAP 2.1.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Thank's I have used the first solution, I hv added the followin line in my slapd.conf
attr!=structuralObjectClass
I have added othe two line in my slapd.conf
attr!=entryUUID attr!=entryCSN
with this 3 line the replication work fine.
On Sep 7, 2007, at 6:20 PM, Pierangelo Masarati wrote:
Pierangelo Masarati wrote:
Since the structuralObjectClass attribute is supposed to have a very special meaning for the DSA (RFC 4512), just adding it as a user attribute seems to me quite a broken approach. Provided you're running a decent version of OpenLDAP, you should be able to filter out undesired attributes from the replication process. For example, in slapd.conf (from slapd.conf(5) man page of OpenLDAP 2.3, but the feature exists since OpenLDAP 2.1, I think) replica [...] attr!=structuralObjectClass will prevent slurpd from replicating the negated attribute list.
Just for the records: a custom patch in this sense was developed by SysNet back in the old times of OpenLDAP 2.0 exactly for the purpose of replicating an OpenLDAP server to a proprietary LDAP server that didn't like many operational attributes slurpd was willing to push in. It also provided partial subtree replication capabilities.
A similar patch was prepared in the meanwhile by Symas and the two merged into OpenLDAP 2.1.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
-------------------------------------------------------------- Matteo Angelino Dipartimento di Informatica Via Bellini 25\G 15100 Alessandria ITALY Tel: +39 0131 360375 Email: matteo.angelino@mfn.unipmn.it --------------------------------------------------------------
Matteo Angelino wrote:
Thank's I have used the first solution, I hv added the followin line in my slapd.conf
attr!=structuralObjectClass
I have added othe two line in my slapd.conf
attr!=entryUUID attr!=entryCSN
with this 3 line the replication work fine.
Great! I've added this information here - http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
On Sep 7, 2007, at 6:20 PM, Pierangelo Masarati wrote:
Pierangelo Masarati wrote:
Since the structuralObjectClass attribute is supposed to have a very special meaning for the DSA (RFC 4512), just adding it as a user attribute seems to me quite a broken approach. Provided you're running a decent version of OpenLDAP, you should be able to filter out undesired attributes from the replication process. For example, in slapd.conf (from slapd.conf(5) man page of OpenLDAP 2.3, but the feature exists since OpenLDAP 2.1, I think) replica [...] attr!=structuralObjectClass will prevent slurpd from replicating the negated attribute list.
Just for the records: a custom patch in this sense was developed by SysNet back in the old times of OpenLDAP 2.0 exactly for the purpose of replicating an OpenLDAP server to a proprietary LDAP server that didn't like many operational attributes slurpd was willing to push in. It also provided partial subtree replication capabilities.
A similar patch was prepared in the meanwhile by Symas and the two merged into OpenLDAP 2.1.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Matteo Angelino Dipartimento di Informatica Via Bellini 25\G 15100 Alessandria ITALY Tel: +39 0131 360375 Email: matteo.angelino@mfn.unipmn.it
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Richard Megginson wrote:
Great! I've added this information here - http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
Rich, I've cleaned up that entry, please check.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Richard Megginson wrote:
Great! I've added this information here - http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
Rich, I've cleaned up that entry, please check.
Excellent. Thanks!
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Pierangelo Masarati wrote:
Richard Megginson wrote:
Great! I've added this information here - http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
Rich, I've cleaned up that entry, please check.
That entry would make more sense if it began with:
There are ways to sync data from OpenLDAP to Fedora DS. NOTE: sync is one way only.
instead of:
There are ways to sync data between OpenLDAP and Fedora DS. NOTE: sync is one way only.
"between X and Y" implies two way, but then in the next sentence you say that it is one way only -- which way is supported and which way is not, is not specified.
... and I'm making the assumption that "slapd.conf" refers to the OpenLDAP slapd.conf file, and that the sync is from OpenLDAP to FDS, but like I said, that's not specified in the article.
Del wrote:
Pierangelo Masarati wrote:
Richard Megginson wrote:
Great! I've added this information here - http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
Rich, I've cleaned up that entry, please check.
That entry would make more sense if it began with:
There are ways to sync data from OpenLDAP to Fedora DS. NOTE: sync is one way only.
instead of:
There are ways to sync data between OpenLDAP and Fedora DS. NOTE: sync is one way only.
"between X and Y" implies two way, but then in the next sentence you say that it is one way only -- which way is supported and which way is not, is not specified.
But there are ways to sync data from Fedora DS to OpenLDAP also. You just can't do both directions at the same time. How could I word that appropriately?
... and I'm making the assumption that "slapd.conf" refers to the OpenLDAP slapd.conf file,
Is there another one?
and that the sync is from OpenLDAP to FDS, but like I said, that's not specified in the article.
The section heading is "Replication from OpenLDAP to Fedora DS" - how should this be specified?
Richard Megginson wrote:
Great! I've added this information here - http://directory.fedoraproject.org/wiki/Howto:OpenldapIntegration
Rich, I've cleaned up that entry, please check.
That entry would make more sense if it began with:
There are ways to sync data from OpenLDAP to Fedora DS. NOTE: sync is one way only.
instead of:
There are ways to sync data between OpenLDAP and Fedora DS. NOTE: sync is one way only.
"between X and Y" implies two way, but then in the next sentence you say that it is one way only -- which way is supported and which way is not, is not specified.
I've added a bit more wording to that page to make things clear.
Richard Megginson wrote:
But there are ways to sync data from Fedora DS to OpenLDAP also. You just can't do both directions at the same time. How could I word that appropriately?
Can you elaborate on that? From the Wiki, it seems that there are some, but they're undocumented.
The other way 'round (OL => FDS), one could try out OpenLDAP's slapo-accesslog(5) in the changelog-like variant (haven't tested, could need some hacking). THis should work fine with changelog (Retro Changelog).
Or (and it would probably be a big plus for RFC 4533) FDS could be added a plugin that makes use of LDAP Sync. I note that, for applications that do not want to reinvent the wheel, OpenLDAP's libldap that ships with 2.4 provides a ldap_sync API that hides RFC 4533 details, so one only needs to deal with making use of the results of the various phases of the sync replication.
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it ---------------------------------------
Pierangelo Masarati wrote:
Richard Megginson wrote:
But there are ways to sync data from Fedora DS to OpenLDAP also. You just can't do both directions at the same time. How could I word that appropriately?
Can you elaborate on that? From the Wiki, it seems that there are some, but they're undocumented.
I haven't had time to properly test and document this, but there are at least 3 ways that I know of. 1) Enable audit logging, and use a process to periodically read from the audit log and send those changes to another ldap server. 2) Enable audit logging, but use a named pipe instead of a file. 1 and 2 could probably be a Net::LDAP perl script or a python-ldap script - read in the LDIF change records from the audit log, convert to LDAP add/modify/delete commands. 3) Use the Retro Changelog in conjunction with persistent search. This could also be a script (if the LDAP client implementation understands Fedora DS persistent search) that does basically the same thing as 1 and 2 above.
The other way 'round (OL => FDS), one could try out OpenLDAP's slapo-accesslog(5) in the changelog-like variant (haven't tested, could need some hacking). THis should work fine with changelog (Retro Changelog).
Or (and it would probably be a big plus for RFC 4533) FDS could be added a plugin that makes use of LDAP Sync. I note that, for applications that do not want to reinvent the wheel, OpenLDAP's libldap that ships with 2.4 provides a ldap_sync API that hides RFC 4533 details, so one only needs to deal with making use of the results of the various phases of the sync replication.
That's good to know. Thanks!
p.
Ing. Pierangelo Masarati OpenLDAP Core Team
SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it
Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati@sys-net.it
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
389-users@lists.fedoraproject.org
-
Del -
Matteo Angelino -
Pierangelo Masarati -
Rich Megginson