openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

(ITS#4818) Please guide me how to configuration LDAP client on Linux and HPUX OS
by sakect＠gmail.com 27 Jan '07

27 Jan '07

Full_Name: Sak Version: 2.3.32 OS: HPUX, Linux URL: Submission from: (NULL) (58.136.93.94) Hi All, I just start to installation and configuration OpenLDAP so please guide me how to configuration. -I install OpenLDAP version 2.3.32 on Linux to create LDAP server and configuration file at slapd.conf I try to use ldapsearch command then it work already. -I create another Linux OS and configuration at /etc/ldap.conf, /etc/openldap/ldap.conf and /etc/nsswitch.conf already but I am not sure it wrong or not because I can not log on by LDAP user in this machine but it can use ldapsearch command. Please give any example and guide to me how to do it. -Please give any example or guid to me how to configuration LDAP client if client site use HPUX or Tru64. Thank you very much for your help. Sak

1 0

Re: (ITS#3593) Contrib: addpartial overlay
by dhawes＠vt.edu 26 Jan '07

26 Jan '07

An updated version of addpartial is available at: ftp://ftp.openldap.org/incoming/david_hawes-addpartial-070126.tgz This version includes changes to work with OpenLDAP 2.3 as well as ensuring syncrepl works properly. david hawes

1 0

Re: (ITS#4817) modify "replace" command firing conflict error where it shouldn't be
by hyc＠symas.com 26 Jan '07

26 Jan '07

Daniel Henninger wrote: > RE23... ;D Does that mean I should wait for the next minor release? Or > shall I pull from CVS/SVN? or? You can pull the current slapd/entry.c from CVS (use the OPENLDAP_REL_ENG_2_3 tag) if you want to patch your current builds. The fix will be in 2.3.34. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4817) modify "replace" command firing conflict error where it shouldn't be
by hyc＠symas.com 26 Jan '07

26 Jan '07

daniel(a)ncsu.edu wrote: > set as many times as I want just fine. I've had "one a day" of these since > upgrading to 2.3.32. (note that we do daily updates) It appears to have > something to do with the order in which I slapadd'd these. Here's the LDIF (via > slapcat) from before I 'fixed' it: > > dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu > objectClass: person > objectClass: inetOrgPerson > objectClass: ncsuPerson > uid: XXX > cn: XXX > sn: XXX > title: Senior > ncsuTwoPartName: XXX > organizationalStatus: registered > o: NC State University > gn: XXX > initials: XXX > displayName: XXX > ncsuAltDisplayName: XXX > ncsuCampusID: XXX > ncsuClassCode: SR > ou: Physics > ncsuCurriculumCode: PY > ou: B S - Philosophy > ncsuCurriculumCode: LSL > mail: XXX(a)unity.ncsu.edu > ncsuPrimaryEMail: XXX(a)unity.ncsu.edu > registeredAddress: XXX > postalAddress: XXX > telephoneNumber: XXX > l: Raleigh > st: NC > postalCode: 27603 > ncsuPrimaryRole: staff > > Obviously I XXX'd out everything sensitive. Note the ordering of ou and > ncsucurriculumcode and ou again and ncsucurriculumcode. (this worked fine in > the 2.2 series which I migrated from, and as far as I can tell is perfectly > legit =) ) Thanks for the report, this now fixed in HEAD and RE23. Just as an fyi, slapcat should never produce a result like this, with attributes interleaved. It's hard to tell from RFC2849 but I'm pretty certain that it's invalid for normal input too, but we accept it anyway (and clean it up, when everything is working right). Unfortunately the grammar in the LDIF spec is inadequate and the text of the spec doesn't make any explicit statements to cover the grammar's deficiencies, so we see a lot of generated LDIF that is questionable... -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

(ITS#4817) modify "replace" command firing conflict error where it shouldn't be
by daniel＠ncsu.edu 26 Jan '07

26 Jan '07

Full_Name: Daniel Henninger Version: 2.3.32 OS: Solaris 8 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (152.1.4.40) Using ldapmodify to replace an attribute, 'ou', with it's new settings (in this case, two ou entries): dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify replace: ou ou: B A - Physics ou: B S - Philosophy - replace: ncsucurriculumcode ncsucurriculumcode: PYA ncsucurriculumcode: LSL Caused an error: Jan 26 08:07:18 uni00ds.unity.ncsu.edu slapd[13230]: [ID 588225 local4.debug] co nn=62 op=4011 RESULT tag=103 err=20 text=modify/replace: ou: value #0 already ex ists (both are multivalued fields and should be fine) The way I had to fix it was to remove the attributes and retry: dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify delete: ou - replace: ou ou: B A - Physics ou: B S - Philosophy - delete: ncsucurriculumcode - replace: ncsucurriculumcode ncsucurriculumcode: PYA ncsucurriculumcode: LSL After that I can perform the original: dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu changetype: modify replace: ou ou: B A - Physics ou: B S - Philosophy - replace: ncsucurriculumcode ncsucurriculumcode: PYA ncsucurriculumcode: LSL set as many times as I want just fine. I've had "one a day" of these since upgrading to 2.3.32. (note that we do daily updates) It appears to have something to do with the order in which I slapadd'd these. Here's the LDIF (via slapcat) from before I 'fixed' it: dn: uid=XXX,ou=students,ou=people,dc=ncsu,dc=edu objectClass: person objectClass: inetOrgPerson objectClass: ncsuPerson uid: XXX cn: XXX sn: XXX title: Senior ncsuTwoPartName: XXX organizationalStatus: registered o: NC State University gn: XXX initials: XXX displayName: XXX ncsuAltDisplayName: XXX ncsuCampusID: XXX ncsuClassCode: SR ou: Physics ncsuCurriculumCode: PY ou: B S - Philosophy ncsuCurriculumCode: LSL mail: XXX(a)unity.ncsu.edu ncsuPrimaryEMail: XXX(a)unity.ncsu.edu registeredAddress: XXX postalAddress: XXX telephoneNumber: XXX l: Raleigh st: NC postalCode: 27603 ncsuPrimaryRole: staff Obviously I XXX'd out everything sensitive. Note the ordering of ou and ncsucurriculumcode and ou again and ncsucurriculumcode. (this worked fine in the 2.2 series which I migrated from, and as far as I can tell is perfectly legit =) ) According to Howard Chu from the mailing list, this appears to have to do with.. well I'll quote him: I see that slapadd is doing a case-sensitive comparison on its input attribute names, when it should be using case-insensitive. That's probably the problem. Once the data's gone into the DB and come out again via slapcat, all of the attribute names are normalized, so any case differences would have disappeared.

1 0

(ITS#4816) slurpd generates invalid ldapadd/modify requests
by gael.roualland＠oleane.net 26 Jan '07

26 Jan '07

Full_Name: Gaël Roualland Version: 2.3.33 OS: Linux URL: ftp://ftp.openldap.org/incoming/gael.roualland-070126.diff Submission from: (NULL) (213.56.0.199) Hello, Slurpd has a bug when replicating, in the way it generates the LDAPMod array of the add and modify operations : if the same attribute is present several times (for add) or in multiple change blocks (for modify) in the replication log, it simply adds all occurences to the LDAPMod array, hence having one or more attributes repeated serveral times which violates the protocol. This is usually fine with slapd because there is code there to accept invalid queries from the updatedn, but it is rejected if you're not using updatedn (which happens to be our case in a custom floating master scenario). The uploaded patch fixes this in slurpd by replacing its LDAPmod logic by one based on ldapmodify which generates proper requests. I know slurpd is considered deprecated, however this might be useful to others still using it and would allow to remove the exception from slapd code. Regards,

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by ando＠sys-net.it 25 Jan '07

25 Jan '07

hyc(a)symas.com wrote: >> The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get >> rid of those "cn=Database X", "cn=Overlay Y" stuff and so. > > One approach would be to add a pointer to the backend struct that points to > its cn=config entry. Then back-monitor can simply pull the DN from there and > strip the cn=config suffix. I think this should be first well integrated with back-config itself; for example, for what concerns private BackendDB structures. One case I've been trying to deal with for a while was the cached instances of back-ldap that are created by slapo-chain. I'm not sure I ever got it working, though. p.

1 0

Re: (ITS#4789) can't add BDB database when monitoring
by hyc＠symas.com 25 Jan '07

25 Jan '07

Pierangelo Masarati wrote: > hyc(a)symas.com wrote: >> hyc(a)OpenLDAP.org wrote: >> >> >>> I presume there's some kind of callback for registering new suffixes >>> but I >>> haven't looked very hard. >>> >> >> This highlights some other issues lurking in here - back-monitor >> basically doesn't deal with dynamic configuration well at all. It >> assumes that all databases and overlays have been fully configured by >> the time it starts - an assumption that was valid for old-style >> slapd.conf use, but not with back-config. >> >> The monitor_subsys_database_init_one() function probably needs to be >> split into separate pieces so that database and overlay info can be >> set up and removed incrementally. >> > The point is that back-monitor has no clean means to detect what > database is serving what naming context, since it was designed way ahead > of back-config. So when time came to introduce monitor customization, > the best mechanism I could find was the extended filter on the naming > context. This is really creating trouble. The best solution would be to > re-design back-monitor so that the database section mimics back-config > using X-ORDERED 'SIBLING' style (and is updated accordingly, especially > when entry renaming will be supported by back-config). > > The X-ORDERED 'SIBLING' could be used throughout back-monitor, to get > rid of those "cn=Database X", "cn=Overlay Y" stuff and so. One approach would be to add a pointer to the backend struct that points to its cn=config entry. Then back-monitor can simply pull the DN from there and strip the cn=config suffix. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4805) memory leak in syncrepl code
by hyc＠symas.com 25 Jan '07

25 Jan '07

ando(a)sys-net.it wrote: > Full_Name: Pierangelo Masarati > Version: HEAD/re23 > OS: irrelevant > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (131.175.154.35) > Submitted by: ando > > > There seems to be few memory leaks in syncrepl code (detected by valgrind when > running test048); one is when parsing an entry and sync "present" or "done". > It's now fixed in HEAD/re23. Others are being investigated I've plugged everything that I saw in test048 in HEAD. As you can tell by the number of commits, there were several loose ends to chase down. Not sure how many are directly relevant to RE23. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Re: (ITS#4810) syncprov follows referrals
by hyc＠symas.com 25 Jan '07

25 Jan '07

dieter(a)dkluenter.de wrote: > Hi, > this is my test setup OK. This was a bug in back-bdb/id2entry.c, syncprov is fine. Fixed in HEAD. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc OpenLDAP Core Team http://www.openldap.org/project/

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs