- openldap-bugs - openldap.org

RE: (ITS#4864) -r option "redirects" to logfile, breaks replication
by Chris.Eubank＠gov.bc.ca 13 Mar '07

13 Mar '07

OK I understand if the -r switch (to slurpd, not slapd) redirects the output to a file for debugging purposes, this is just not apparent in the man pages. The man pages to not tell me that slurpd will be "redirecting" with the -r switch. It is just usual replication I was setting up originally. This is the variable I was using in an "openldaprc" file: # -r replication-log-file. Directory must be created. #SLURPD_REPL_LOG_FILE=/var/openldap-slurp/log When uncommenting this line, the result is that it does not open network connections to the replication slaves. _All_ data goes to the file, none to the slaves. This isn't documented correctly, it took me a long time to figure out why the replication was not happening. Chris -----Original Message----- From: Pierangelo Masarati [mailto:ando@sys-net.it] Sent: Sun, March 11, 2007 11:52 PM To: Eubank, Chris LCS:EX Cc: openldap-its(a)openldap.org Subject: Re: (ITS#4864) -r option "redirects" to logfile, breaks replication [please keep the ITS in CC] Eubank, Chris LCS:EX wrote: > Am running Solaris 10, and the version I stuck in the log. > > When I created an "openldaprc" and used the variable for the > replication log, What is the "variable for the replication log"? All one usually needs to do is define a replogfile in slapd.conf(5) > (which ends up obviously running the slurpd daemon with the -r > switch), Again: there's no need to use -r if replogfile is in slapd.conf(5); if there is no replogfile in slapd.conf(5), slapd(8) will not generate any log, so slurpd(8) will have nothing to do > it sent the replication data to the logfile and not to the replication > hosts being specified. Who sent the replication data to the logfile? slapd(8) is supposed to write replication data to the file specified in replogfile (sladp.conf(5)); slurpd(8) is supposed to read that file (whose existence and location is known by parsing slapd.conf(5)), copy the content it is able to process to its own replication log, which resides in slurpd's working directory (default or passed with -t) and is called slurpd.replog, send that content to the slaves, and remove the data that has been handled from slapd's replication log. This is how things are expected to work. As you may see, -r never comes into play; it's intended to be used to force slurpd processing of a different file, which may be required for special purposes. Do you have any special needs, or are you simply trying to set up usual replication? > Does that make more sense? See comments above. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by raphael.ouazana＠linagora.com 13 Mar '07

13 Mar '07

Le Lun 12 mars 2007 06:37, Pierangelo Masarati a écrit : > I don't see so much similarity: set_chase() is intended to use the > gatherer to fetch objects and extract a value from them, including > "closure" (recursion). Sublevel does not require fetching, and takes a > negative digit as extra argument, rather than an attribute type, so > you'd need to add an outer test before calling set_chase() anyway, > extend the interface of set_chase() to allow an AttributeDescription and > an integer, and so on, while you don't need any callback capability to > fetch an object or expand values or so. I'd keep it simple as it is now. OK. You'll find a new version here: ftp://ftp.openldap.org/incoming/raphael-ouazana-070313.patch It takes care of your notices. Regards, Raphael Ouazana.

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by vargok＠yahoo.com 13 Mar '07

13 Mar '07

>----- Original Message ---- >From: Pierangelo Masarati <ando(a)sys-net.it> >To: vargok(a)yahoo.com >Cc: openldap-its(a)openldap.org >Sent: Monday, March 12, 2007 4:52:04 PM >Subject: Re: (ITS#4868) Binary Attribute Patch(es) > > >> These address the use of Binary-valued attributes (#3113, #3386): >> >> For example, inetOrgPerson.userCertificate is usually transferred with the >> ";binary" directive. ";binary" is not handled by OpenLDAP/Back-SQL. > >Well, the solution you propose is not correct, since you are altering >schema data, which is supposed to be read-only. In any case, the point is: Yeah; I think the actual submission found the ";binary" and reset the reference to it, not actually doing anything to it. >- if we decide that back-sql should ignore tags, then the solution >consists in using the canonical name of the underlying AttributeType >when looking up data; > >- however, this would destroy the possibility to use different storages >for differently encoded data; for example, a column for "cn;lang-en" and >a column for "cn;lang-jp". I don't know how many users would prefer one >solution over another, but in any case either we find a solution that >preserves both capabilities or we choose one. I'd vote in favor of >ignoring ";binary" since it's obsolete and related to transport only, >but in favor of honoring language tags. Sounds great to me. I just want support for ";binary" both on storage and retrieval to be supported. I'll accept that it's obsolete -- I'll also put forth that a lot of things still use it (e.g. Lotus Domino v6). >> There remains an issue with selecting attributes using, e.g., >> "userCertificate;binary" -- nothing is returned. Someone with a better >> understanding of the attribute-processing method would be much more effective in >> terms of finding the correct place to remove the ";binary" from the >> "attribute-name." (i.e. "userCertificate;binary" is NOT the attribute-name; >> "userCertificate" is the attribute-name, ";binary" is a transport directive (see >> #3113). > >In fact, "userCertificate;binary" is the attribute description. The >attribute name is in ad_type->sat_cname. And, in fact, none of what I did appears to have been sufficient. I'm still looking at why selecting "userCertificate;binary" as part of an ldapsearch attribute-list doesn't pull the data. "userCertificate" does. The issue appears to be related to the ad_inlist verification on the search-supplied attribute -- "userCertificate;binary" doesn't resolve. If you know where I can look to figure this out, that would help. I've been through some areas and not found exactly where just yet. Thanks for your assistance. Kevin Vargo ____________________________________________________________________________________ The fish are biting. Get more visitors on your site using Yahoo! Search Marketing. http://searchmarketing.yahoo.com/arp/sponsoredsearch_v2.php

1 0

Re: (ITS#4869) config creates base64 encoded rootdn
by hyc＠symas.com 13 Mar '07

13 Mar '07

dieter(a)dkluenter.de wrote: > Howard Chu <hyc(a)symas.com> writes: > >> What is the original rootdn? >> > cn=admin,o=avci,c=de > > -Dieter > I don't see anything like that here. You'll probably have to post your slapd.conf. Have you checked for extraneous white space in the original rootdn config? -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4869) config creates base64 encoded rootdn
by dieter＠dkluenter.de 13 Mar '07

13 Mar '07

Howard Chu <hyc(a)symas.com> writes: > What is the original rootdn? > cn=admin,o=avci,c=de -Dieter -- Dieter Klünter | Systemberatung http://www.dkluenter.de GPG Key ID:8EF7B6C6

1 0

(ITS#4872) Non-portable comparison in wait4msg() (result.c) causes infinite loop
by carsten.agger＠tietoenator.com 13 Mar '07

13 Mar '07

Full_Name: Carsten Agger Version: 2.3.20 OS: OSE URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.237.142.21) On our architecture (OSE running on an AXE processor), time_t is an unsigned int. This means that this code, as found in the wait4msg function in libraries/libldap/result.c, will break: > > if ( rc == LDAP_MSG_X_KEEP_LOOKING && tvp != NULL ) { > tmp_time = time( NULL ); > tv0.tv_sec -= ( tmp_time - start_time ); > if ( tv0.tv_sec <= 0 ) { > rc = 0; /* timed out */ > ld->ld_errno = LDAP_TIMEOUT; > break; > } > tv.tv_sec = tv0.tv_sec; > ... > } Why? Because if (start_time > tmp_time), the condition ( tv0.tv_sec <= 0 ) will never evaluate to TRUE, and the break will never be executed - yielding an infinite loop. Solution: rewrite in a portable way, e.g. (as suggested by Pierangelo Masarati on the bugs mailing list) by testing if the value of tv_sec would be negative after subtracting ( tmp_time - start_time ) before assigning it.

1 0

Bug causing infinite loop in result.c
by Carsten.Agger＠tietoenator.com 13 Mar '07

13 Mar '07

We have found a bug in libraries/libldap/result.c which may cause an infinite loop in some situations. The error is this, in the function wait4msg(): if ( rc == LDAP_MSG_X_KEEP_LOOKING && tvp != NULL ) { tmp_time = time( NULL ); tv0.tv_sec -= ( tmp_time - start_time ); if ( tv0.tv_sec <= 0 ) { rc = 0; /* timed out */ ld->ld_errno = LDAP_TIMEOUT; break; } tv.tv_sec = tv0.tv_sec; ... } The problem is this: The check ( tv0.tv_sec <= 0 ) is always true, since tv_sec (on our system, at least) is an unsigned int. The problem is fixed by casting it to int: if ( (int) tv0.tv_sec <= 0 ) { ... } however this might not be the most suitable way to fix it. best regards, Carsten Agger Software Consultant, TietoEnator A/S, Denmark http://www.tietoenator.dk

2 2

(ITS#4871) index directive & slapd.conf(5)
by quanah＠stanford.edu 12 Mar '07

12 Mar '07

Full_Name: Quanah Gibson-Mount Version: 2.3/2.4/HEAD OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (171.66.155.86) The slapd.conf(5) man page talks about the various ways in which indices can be tuned, such as index_substr_if_maxlen, but it does not actually mention the index directive. It may be worthwhile to have text like [b]index[/b] See the man page for the specific backend you are using for more information about the index directive {ex: slapd-bdb(5)} so that users can more easily find that information (and the necessity to run slapindex on bdb, for example) etc.

1 0

(ITS#4870) superfluous int declarations in bconfig.c
by bret.lambert＠gmail.com 12 Mar '07

12 Mar '07

Full_Name: Bret Lambert Version: HEAD OS: URL: ftp://ftp.openldap.org/incoming/bret-lambert-070312.patch Submission from: (NULL) (70.179.123.124) Superfluous redeclarations of 'int i' in bconfig.c Found via lint(1) on OpenBSD.

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by ando＠sys-net.it 12 Mar '07

12 Mar '07

vargok(a)yahoo.com wrote: > These address the use of Binary-valued attributes (#3113, #3386): The proposed patches have been applied (with changes) to HEAD code (you should be able to easily generate the diffs between HEAD and re23 code); please test. In detail, please check the solution for the ";binary" issue. If you report the behavior as satisfactory, backporting to re23 could be an option, since the fix should be well isolated, and it configures as borderline between new feature and bug fix. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4868) Binary Attribute Patch(es)
by ando＠sys-net.it 12 Mar '07

12 Mar '07

Few preliminary comments follow. vargok(a)yahoo.com wrote: > Version: 2.3.32 You should rather patch HEAD code instead of released, and even not the latest. However, given the development rate of back-sql (~0), it shouldn't really matter > These address the use of Binary-valued attributes (#3113, #3386): > > For example, inetOrgPerson.userCertificate is usually transferred with the > ";binary" directive. ";binary" is not handled by OpenLDAP/Back-SQL. Well, the solution you propose is not correct, since you are altering schema data, which is supposed to be read-only. In any case, the point is: - if we decide that back-sql should ignore tags, then the solution consists in using the canonical name of the underlying AttributeType when looking up data; - however, this would destroy the possibility to use different storages for differently encoded data; for example, a column for "cn;lang-en" and a column for "cn;lang-jp". I don't know how many users would prefer one solution over another, but in any case either we find a solution that preserves both capabilities or we choose one. I'd vote in favor of ignoring ";binary" since it's obsolete and related to transport only, but in favor of honoring language tags. > As well, > the data itself, when stored in the database is not properly read out -- all > data is read as SQL_C_CHAR data. This supports SQL_C_BINARY-based data. This is just fine. > There remains an issue with selecting attributes using, e.g., > "userCertificate;binary" -- nothing is returned. Someone with a better > understanding of the attribute-processing method would be much more effective in > terms of finding the correct place to remove the ";binary" from the > "attribute-name." (i.e. "userCertificate;binary" is NOT the attribute-name; > "userCertificate" is the attribute-name, ";binary" is a transport directive (see > #3113). In fact, "userCertificate;binary" is the attribute description. The attribute name is in ad_type->sat_cname. > Additionally, I included to the patch to remove the "assert(0)" in Back-SQL's > verification that a search filter and ldap-data don't mis-match on suffix. Fine, but already fixed. > Tags: OpenLDAP, Back-SQL, MySQL, userCertificate, Binary Attributes, Client > Certificates > > > (1) > ./servers/slapd/back-sql/search.c.patch > Addressed ITS#4856 -- I think you already fixed this > > (2) > ./servers/slapd/back-sql/back-sql.h.patch > ./servers/slapd/back-sql/entry-id.c.patch > ./servers/slapd/back-sql/sql-wrap.c.patch > Address ITS#3113, ITS#3386 > Support for binary attribute values > > (3) > ./servers/slapd/back-sql/schema-map.c.patch > Addresses issue with accessing attributes that have been provided with > ";binary" directive > > note that I have no doubts whatso ever that there are many better ways to do > (3). You made an extensive use of C++ style comments, which are non portable. Obviously you didn't read the contribution guidelines. I'm testing (and improving) it. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4866) Can we list Null Value Attributes
by hyc＠symas.com 12 Mar '07

12 Mar '07

The ITS is not for general software usage questions. Use the ldap(a)umich.edu mailing list for general LDAP questions. This ITS will be closed. maruthigsr(a)gmail.com wrote: > Full_Name: Maruthi Gullapudi > Version: > OS: AIX > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.221.133.211) > > > Hi, > > I wanted to list all the users based on the value of one attribute using the > LDAPSEARCH Command. The value of that attribute is NULL. I dont know whether > LDAPSEARCH will capture null values. > > Can anyone tell me how to list users from an LDAP directory based on a NUll > valued attribute. > > Thanks in Advance > Maruthi > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#4869) config creates base64 encoded rootdn
by hyc＠symas.com 12 Mar '07

12 Mar '07

What is the original rootdn? dieter(a)dkluenter.de wrote: > Full_Name: Dieter Kluenter > Version: 2.4.4alpha > OS: linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (84.142.235.193) > > > When running slapd with -F -f to create a new config database, olcRootDN value > is created base64 encoded > > => ldap_bv2dn(p,0) > ldap_err2string > <= ldap_bv2dn(p)=-4 Decoding error > ldap_err2string > olcRootDN: value #0: <olcRootDN> invalid DN 21 (Invalid syntax) > config error processing olcDatabase={1}hdb,cn=config: <olcRootDN> invalid DN 21 > > (Invalid syntax) > send_ldap_result: conn=-1 op=0 p=0 > send_ldap_result: err=19 matched="" text="" > slapd destroy: freeing system resources. > slapd stopped. > > -Dieter > > > . > -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#4869) config creates base64 encoded rootdn
by dieter＠dkluenter.de 12 Mar '07

12 Mar '07

Full_Name: Dieter Kluenter Version: 2.4.4alpha OS: linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (84.142.235.193) When running slapd with -F -f to create a new config database, olcRootDN value is created base64 encoded => ldap_bv2dn(p,0) ldap_err2string <= ldap_bv2dn(p)=-4 Decoding error ldap_err2string olcRootDN: value #0: <olcRootDN> invalid DN 21 (Invalid syntax) config error processing olcDatabase={1}hdb,cn=config: <olcRootDN> invalid DN 21 (Invalid syntax) send_ldap_result: conn=-1 op=0 p=0 send_ldap_result: err=19 matched="" text="" slapd destroy: freeing system resources. slapd stopped. -Dieter

1 0

Re: example: OpenLDAP with SASL/DIGEST-MD5 authentication (ITS#4867)
by ando＠sys-net.it 12 Mar '07

12 Mar '07

Piotr.Golonka(a)cern.ch wrote: > Indeed, 2.2.13 may be historical, It is. It's not an opinion, but a fact. Even 2.2.30, the latest 2.2 release, is historical. > yet this is the version used in large > production systems (e.g. RedHat Enterprise Linux). I believe the problem is not ours. I think we did our best by pushing out 2.2 up to 2.2.30, then 2.3 up to 2.3.34, and now 2.4. If distributions don't catch up I don't think anyone can blame OpenLDAP (and I don't think you are; I'm just trying to make the point). > I'll try to have a look at what's in 2.4. I hope I get my point: every contribution is welcome, but not every contribution may be useful. Writing howtos for code that was released ages ago, and is not maintained may be considered little useful. This is an opinion, of course. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: example: OpenLDAP with SASL/DIGEST-MD5 authentication (ITS#4867)
by Piotr.Golonka＠cern.ch 12 Mar '07

12 Mar '07

On Monday 12 March 2007 18:04, you wrote: > 2.2.13 is historical. ldap_sasl_bind(3) eventually got documented (only > the prototype in 2.3, more docs in 2.4). Please check current 2.4 > documentation and, in case, adapt your contribution to it. In fact, that > man page does not contain any coding example, as we usually refer to client > tools implementations. Please feel free to submit your contribution, lined > up to active code, as a FAQ entry <http://www.openldap.org/faq/>. The FAQ > is interactive. Hi, thanx for reply. Indeed, 2.2.13 may be historical, yet this is the version used in large production systems (e.g. RedHat Enterprise Linux). I'll try to have a look at what's in 2.4. best regards: Piotr

1 0

(ITS#4868) Binary Attribute Patch(es)
by vargok＠yahoo.com 12 Mar '07

12 Mar '07

Full_Name: Kevin Vargo Version: 2.3.32 OS: Linux (RH-EL4) URL: ftp://ftp.openldap.org/incoming/openldap-2.3.32-kv1-patch_support-binary-at… Submission from: (NULL) (128.237.242.55) These address the use of Binary-valued attributes (#3113, #3386): For example, inetOrgPerson.userCertificate is usually transferred with the ";binary" directive. ";binary" is not handled by OpenLDAP/Back-SQL. As well, the data itself, when stored in the database is not properly read out -- all data is read as SQL_C_CHAR data. This supports SQL_C_BINARY-based data. There remains an issue with selecting attributes using, e.g., "userCertificate;binary" -- nothing is returned. Someone with a better understanding of the attribute-processing method would be much more effective in terms of finding the correct place to remove the ";binary" from the "attribute-name." (i.e. "userCertificate;binary" is NOT the attribute-name; "userCertificate" is the attribute-name, ";binary" is a transport directive (see #3113). Additionally, I included to the patch to remove the "assert(0)" in Back-SQL's verification that a search filter and ldap-data don't mis-match on suffix. Tags: OpenLDAP, Back-SQL, MySQL, userCertificate, Binary Attributes, Client Certificates (1) ./servers/slapd/back-sql/search.c.patch Addressed ITS#4856 -- I think you already fixed this (2) ./servers/slapd/back-sql/back-sql.h.patch ./servers/slapd/back-sql/entry-id.c.patch ./servers/slapd/back-sql/sql-wrap.c.patch Address ITS#3113, ITS#3386 Support for binary attribute values (3) ./servers/slapd/back-sql/schema-map.c.patch Addresses issue with accessing attributes that have been provided with ";binary" directive note that I have no doubts whatso ever that there are many better ways to do (3).

1 0

(ITS#4867) example: OpenLDAP with SASL/DIGEST-MD5 authentication
by Piotr.Golonka＠CERN.CH 12 Mar '07

12 Mar '07

Full_Name: Piotr.Golonka(a)CERN.CH Version: 2.2.13 OS: Linux URL: ftp://ftp.openldap.org/incoming/golonka-pkg-070312.tgz Submission from: (NULL) (137.138.170.170) Hi, the documentation of the ldap_sasl_bind* family of functions is missing, and getting the actual DIGEST-MD5 authentication in your C code working seems to be completely undocumented. I went through the complete code of ldapsearch.c and extracted the minimal code that succesfully demonstrates DIGEST-MD5 authentication. In my case, I authenticated against ActiveDirectory server. I uploaded the example into your FTP server as golonka-pkg-070312.tgz I hope it may be useful to publish it as a short "Howto" material... regards Piotr Golonka CERN

1 0

(ITS#4866) Can we list Null Value Attributes
by maruthigsr＠gmail.com 12 Mar '07

12 Mar '07

Full_Name: Maruthi Gullapudi Version: OS: AIX URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.221.133.211) Hi, I wanted to list all the users based on the value of one attribute using the LDAPSEARCH Command. The value of that attribute is NULL. I dont know whether LDAPSEARCH will capture null values. Can anyone tell me how to list users from an LDAP directory based on a NUll valued attribute. Thanks in Advance Maruthi

1 0

Re: (ITS#4864) -r option "redirects" to logfile, breaks replication
by ando＠sys-net.it 11 Mar '07

11 Mar '07

[please keep the ITS in CC] Eubank, Chris LCS:EX wrote: > Am running Solaris 10, and the version I stuck in the log. > > When I created an "openldaprc" and used the variable for the > replication log, What is the "variable for the replication log"? All one usually needs to do is define a replogfile in slapd.conf(5) > (which ends up obviously running the slurpd daemon > with the -r switch), Again: there's no need to use -r if replogfile is in slapd.conf(5); if there is no replogfile in slapd.conf(5), slapd(8) will not generate any log, so slurpd(8) will have nothing to do > it sent the replication data to the logfile and > not to the replication hosts being specified. Who sent the replication data to the logfile? slapd(8) is supposed to write replication data to the file specified in replogfile (sladp.conf(5)); slurpd(8) is supposed to read that file (whose existence and location is known by parsing slapd.conf(5)), copy the content it is able to process to its own replication log, which resides in slurpd's working directory (default or passed with -t) and is called slurpd.replog, send that content to the slaves, and remove the data that has been handled from slapd's replication log. This is how things are expected to work. As you may see, -r never comes into play; it's intended to be used to force slurpd processing of a different file, which may be required for special purposes. Do you have any special needs, or are you simply trying to set up usual replication? > Does that make more sense? See comments above. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4860) Sets' enhancement
by ando＠sys-net.it 11 Mar '07

11 Mar '07

raphael.ouazana(a)linagora.com wrote: > Fixing these issues, I saw that set_parent will be very similar to > set_chase. Do you think I should create a new gatherer instead of ? I don't see so much similarity: set_chase() is intended to use the gatherer to fetch objects and extract a value from them, including "closure" (recursion). Sublevel does not require fetching, and takes a negative digit as extra argument, rather than an attribute type, so you'd need to add an outer test before calling set_chase() anyway, extend the interface of set_chase() to allow an AttributeDescription and an integer, and so on, while you don't need any callback capability to fetch an object or expand values or so. I'd keep it simple as it is now. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

Re: (ITS#4864) -r option "redirects" to logfile, breaks replication
by ando＠sys-net.it 10 Mar '07

10 Mar '07

chris.eubank(a)gov.bc.ca wrote: > Full_Name: Chris Eubank > Version: 2.3.31 (Jan 7 2007 08:51:37) > OS: Solaris 10 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (142.32.230.251) > > > If the -r option is used with the 'slurpd' daemon it breaks the replication > function and sends the replication data to the specified logfile instead. What does this mean? According to the documentation, -r must point to slapd's replog file, namely the file where replications are logged by the producer. Of course, if you point it to a file that is not a valid replication log, the behavior will be unexpected. > This behaviour is not documented in the manpage for slurpd. Please describe what behavior you obtain and how it differs from documented. Note that regular users are not supposed to use the -r switch, since slurpd typically knows where to get the replog file. Also, note that slurpd is deprecated; syncrepl should be used instead. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.n.c. Via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it ------------------------------------------ Office: +39.02.23998309 Mobile: +39.333.4963172 Email: pierangelo.masarati(a)sys-net.it ------------------------------------------

1 0

(ITS#4865) double declaration of variable in slapd/main.c
by bret.lambert＠gmail.com 09 Mar '07

09 Mar '07

Full_Name: Bret Lambert Version: -HEAD OS: OpenBSD URL: ftp://ftp.openldap.org/incoming/bret-lambert-070309.patch Submission from: (NULL) (70.179.123.124) There are two declarations of "int i;" in main.c main(). The patch listed removes the second (spurious) declaration of the variable. Found via lint(1) on OpenBSD

1 0

(ITS#4864) -r option "redirects" to logfile, breaks replication
by chris.eubank＠gov.bc.ca 09 Mar '07

09 Mar '07

Full_Name: Chris Eubank Version: 2.3.31 (Jan 7 2007 08:51:37) OS: Solaris 10 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (142.32.230.251) If the -r option is used with the 'slurpd' daemon it breaks the replication function and sends the replication data to the specified logfile instead. This behaviour is not documented in the manpage for slurpd.

1 0

(ITS#4863) 2.3 Administrator's Guide uses deprecated "attr=" statement (typo)
by meburr＠gmail.com 09 Mar '07

09 Mar '07

Full_Name: Michael Burr Version: 2.3.30 OS: Debian 4.0 (sid) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (70.145.225.250) Referring to the Administrator's Guide hosted at openldap.org, in the "Access Control" section (http://www.openldap.org/doc/admin23/slapdconf2.html#Access%20Control), if I copy this statement: olcAccess: to attr=member,entry by dnattr=member selfwrite directly into my configuration (replacing "olcAccess: " with "access to"), slaptest complains: slapd.conf: line 40: "attr" is deprecated (and undocumented); use "attrs" instead. config file testing succeeded As is suggested by the output, slaptest returns with success (0).

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs