- openldap-bugs - openldap.org

Re: (ITS#6257) libldap: getopt flag to return the SASL username
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> libldap should be capable of returning SASL username obtained with > sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of > ldap_get_option() Added to HEAD (LDAP_OPT_X_SASL_USERNAME); please test. Thanks, p.

1 0

Re: (ITS#6259) test020 core dumps
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

Can't reproduce, although I can see memory leaks (in entry duplication). p.

1 0

(ITS#6259) test020 core dumps
by dieter＠dkluenter.de 18 Aug '09

18 Aug '09

Full_Name: Dieter Kluenter Version: HEAD OS: openSUSE-11.1 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.154.40.47) my configure flags CFLAGS="-DLDAP_DEVEL -g -march=athlon64" LIBS="-ltcmalloc" ./configure \ --prefix=${PREFIX} \ --enable-dynamic \ --enable-aci \ --enable-modules \ --enable-rewrite \ --enable-bdb=yes \ --enable-hdb=yes \ --enable-ldap=mod \ --enable-monitor=yes \ --enable-meta=mod \ --enable-perl=mod \ --enable-relay=mod \ --enable-monitor=yes \ --enable-sql=mod \ --enable-overlays=mod make depend && make && cd tests test020 core dumps with Core was generated by `/work/ldap-src/servers/slapd/.libs/lt-slapd -s0 -f /work/ldap-src/tests/testrun'. Program terminated with signal 11, Segmentation fault. backtrace is (gdb) bt #0 free (ptr=0x1100ffffff) at src/tcmalloc.cc:842 #1 0x00007f2479ca1bca in ber_memfree_x (p=0x1100ffffff, ctx=0x0) at memory.c:152 #2 0x00007f24753d03a0 in ?? () from /usr/lib64/libldap-2.4.so.2 #3 0x00007f24753b599f in ?? () from /usr/lib64/libldap-2.4.so.2 #4 0x0000000000af9cc8 in ?? () #5 0x0000000000000000 in ?? () (gdb) frame 1 #1 0x00007f2479ca1bca in ber_memfree_x (p=0x1100ffffff, ctx=0x0) at memory.c:152 152 free( p ); Current language: auto; currently c

1 0

Re: (ITS#6194) Patch - Enhancement - provide LDIF support as libldif
by rmeggins＠redhat.com 18 Aug '09

18 Aug '09

Any ideas about what it would take to make a public LDIF API?

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it wrote: >> You mean an instance of the allowedAttributesEffective with the empty >> value? I'm not seeing anything like that. > > Actually, I confirm I didn't see anything like that, but there was a bug: > the attribute was being added regardless of having any value, and the > a_numvals field was not being filled in any case. Fixing... Yupp, that seems right now. Ciao, Michael.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 18 Aug '09

18 Aug '09

masarati(a)aero.polimi.it wrote: > Michael Ströder wrote: >> There's a special corner-case: >> If the user bound (e.g. anonymous in my test configuration) has no write >> access to any attribute an empty attribute value list is returned for >> 'allowedAttributesEffective'. > > You mean an instance of the allowedAttributesEffective with the empty > value? Yes. Here's the python-ldap trace log: Note the 'allowedAttributesEffective': [] in the result. I can also enable OpenLDAP debugging log if that would be more evidence for you. ---------------------------- snip ---------------------------- *** ldap://localhost:2071 - LDAPObject.search_ext (('ou=schulung,dc=stroeder,dc=local', 0, '(objectClass=*)', ['hasSubordinates', 'entryCSN', 'tokenGroupsGlobalAndUniversal', 'localEntryID', 'createTimestamp', 'uSNCreated', 'fromEntry', 'administrativeRole', 'structuralObjectClass', 'mS-DS-CreatorSID', 'msDS-Approx-Immed-Subordinates', 'nsAccountLock', 'authzTo', 'nsLookthroughLimit', 'GUID', 'authzFrom', '*', 'passwordExpWarned', 'whenChanged', 'modifiersName', 'isMemberOf', 'sDRightsEffective', 'governingStructureRule', 'primaryGroupToken', 'pwdPolicySubentry', 'accountUnlockTime', 'passwordHistory', 'subordinateCount', 'allowedAttributesEffective', 'creatorsName', 'entryUUID', 'aclentry', 'uSNChanged', 'tokenGroupsNoGCAcceptable', 'entryDN', 'passwordRetryCount', 'tokenGroups', 'passwordExpirationTime', 'aci', 'passwordAllowChangeTime', 'whenCreated', 'retryCountResetTime', 'canonicalName', 'entryUSN', 'subschemaSubentry', 'numSubordinates', 'modifyTimestamp'], 0, [], None, 300, 0),{}) => result: 13 *** ldap://localhost:2071 - LDAPObject.result3 ((13, 1, 300),{}) => result: (101, [('ou=schulung,dc=stroeder,dc=local', {'hasSubordinates': ['TRUE'], 'entryCSN': ['20090818120115.850129Z#000000#000#000000'], 'objectClass': ['organizationalUnit'], 'creatorsName': ['uid=diradm,ou=schulung,dc=stroeder,dc=local'], 'entryUUID': ['d0ed3070-150d-4a5a-bec3-5c21e78c31c3'], 'allowedAttributesEffective': [], 'modifiersName': ['uid=diradm,ou=schulung,dc=stroeder,dc=local'], 'createTimestamp': ['20090818120115Z'], 'entryDN': ['ou=schulung,dc=stroeder,dc=local'], 'subschemaSubentry': ['cn=Subschema'], 'structuralObjectClass': ['organizationalUnit'], 'ou': ['schulung'], 'modifyTimestamp': ['20090818120115Z']})], 13, []) ---------------------------- snip ---------------------------- > I'm not seeing anything like that. At which level? >> Indeed this is helpful since my web2ldap can >> then distinguish between this attribute being not available at all or no >> attributes are allowed to be written. But I'm not sure whether that >> complies >> to the LDAP data model. What do you think? > > In any case, I'd consider it an error, which deserves to be fixed. If you fix it with hunking out the empty values list the distinction within web2ldap would be then to look at the schema and decide whether allowedAttributesEffective is available. I can see that attr type description of allowedAttributesEffective is hard-coded in allowed.c so that seems fairly reliable to me. Ciao, Michael.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> You mean an instance of the allowedAttributesEffective with the empty > value? I'm not seeing anything like that. Actually, I confirm I didn't see anything like that, but there was a bug: the attribute was being added regardless of having any value, and the a_numvals field was not being filled in any case. Fixing... p.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 18 Aug '09

18 Aug '09

> I've created a simple Makefile derived from the one for slapo-smbk5pwd for > this I'd like to contribute if appropriate. Please review. I grant *all* > rights to the OpenLDAP project. > > Now for the concrete testing: > > In principle it works. That's great! > > There's a special corner-case: > If the user bound (e.g. anonymous in my test configuration) has no write > access to any attribute an empty attribute value list is returned for > 'allowedAttributesEffective'. You mean an instance of the allowedAttributesEffective with the empty value? I'm not seeing anything like that. > Indeed this is helpful since my web2ldap can > then distinguish between this attribute being not available at all or no > attributes are allowed to be written. But I'm not sure whether that > complies > to the LDAP data model. What do you think? In any case, I'd consider it an error, which deserves to be fixed. p.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 18 Aug '09

18 Aug '09

This is a multi-part message in MIME format. --------------080500010001090702060704 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit masarati(a)aero.polimi.it wrote: >>> HI! >>> >>> I've added support for 'allowedAttributesEffective' in web2ldap recently >>> which >>> works with AD. I tried this overlay but it seg faults with recent >>> OpenLDAP >>> version. Any chance to get this back on the radar? >> >> I've built and tested my copy of allowed.c with HEAD and re24 and it works >> as expected. However, I might have modified it to keep pace with baseline >> code evolution without resubmitting modifications. > > My version was indeed rather modified, that's why it worked. It's now in > HEAD's contrib/slapd-modules/allowed/. It builds fine with HEAD and re24; > it should also build with OL 2.3, although I haven't checked in a while. > Please test and report. I've created a simple Makefile derived from the one for slapo-smbk5pwd for this I'd like to contribute if appropriate. Please review. I grant *all* rights to the OpenLDAP project. Now for the concrete testing: In principle it works. That's great! There's a special corner-case: If the user bound (e.g. anonymous in my test configuration) has no write access to any attribute an empty attribute value list is returned for 'allowedAttributesEffective'. Indeed this is helpful since my web2ldap can then distinguish between this attribute being not available at all or no attributes are allowed to be written. But I'm not sure whether that complies to the LDAP data model. What do you think? Ciao, Michael. --------------080500010001090702060704 Content-Type: text/plain; name="Makefile" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="Makefile" # $OpenLDAP: pkg/ldap/contrib/slapd-modules/allowed/Makefile,v 1.3 2009/08/16 20:55:27 kurt Exp $ # This work is part of OpenLDAP Software <http://www.openldap.org/>. # # Copyright 1998-2009 The OpenLDAP Foundation. # Copyright 2004 Howard Chu, Symas Corp. All Rights Reserved. # # Redistribution and use in source and binary forms, with or without # modification, are permitted only as authorized by the OpenLDAP # Public License. # # A copy of this license is available in the file LICENSE in the # top-level directory of the distribution or, alternatively, at # <http://www.OpenLDAP.org/license.html>. PREFIX=/opt/openldap-HEAD LIBTOOL=../../../libtool OPT=-g -O2 CC=gcc DEFS=-DSLAPD_OVER_ALLOWED=SLAPD_MOD_DYNAMIC LDAP_INC=-I../../../include -I../../../servers/slapd INCS=$(LDAP_INC) LDAP_LIB=-lldap_r -llber -L../../../lib LDAP_LIB= LIBS=$(LDAP_LIB) all: allowed.la allowed.lo: allowed.c $(LIBTOOL) --mode=compile $(CC) $(OPT) $(DEFS) $(INCS) -c $? allowed.la: allowed.lo $(LIBTOOL) --mode=link $(CC) $(OPT) -version-info 0:0:0 \ -rpath $(PREFIX)/lib -module -o $@ $? $(LIBS) clean: rm -f allowed.o allowed.lo allowed.la install: allowed.la mkdir -p $(PREFIX)/libexec/openldap $(LIBTOOL) --mode=install cp allowed.la $(PREFIX)/libexec/openldap $(LIBTOOL) --finish $(PREFIX)/libexec/openldap --------------080500010001090702060704--

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 17 Aug '09

17 Aug '09

>> HI! >> >> I've added support for 'allowedAttributesEffective' in web2ldap recently >> which >> works with AD. I tried this overlay but it seg faults with recent >> OpenLDAP >> version. Any chance to get this back on the radar? > > Michael, > > I've built and tested my copy of allowed.c with HEAD and re24 and it works > as expected. However, I might have modified it to keep pace with baseline > code evolution without resubmitting modifications. My version was indeed rather modified, that's why it worked. It's now in HEAD's contrib/slapd-modules/allowed/. It builds fine with HEAD and re24; it should also build with OL 2.3, although I haven't checked in a while. Please test and report. p.

1 0

Re: (ITS#5178) [feature request] pcache stats & monitoring
by masarati＠aero.polimi.it 17 Aug '09

17 Aug '09

> This is a feature request for stats and monitoring capabilities for > pcache; > basically: > > - the number of cached queries The number of cachedQueryURL values > - the number of cached entries not available; maybe cachedQueryURL could carry a x-nentries=<num> extension > - possibly, a list of cached queries in cachedQueryURL form ditto > - how many times each cached query was used instead of re-running the > request > - the ratio answerable / cacheable for each cacheable query > - some global figure like the average response time (send searchResult > time - > start caching time) for each query, and the overall average. None of the above is available. The first one is interesting, but it would require query information to survive its life, and match by base/scope/filter rather than by queryUUID. > Adding per-query info could be done by either extending the cachedQueryURL > format or by adding a child entry for each cached query (like connections > and > other dynamic info). This second option does not seem to be viable, although interesting. I fear too much overhead. It's not clear yet how all of this stuff will need to cooperate with the new TTR (and bind caching, when available). p.

1 0

RE: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by masarati＠aero.polimi.it 17 Aug '09

17 Aug '09

> The traffic model we are testing contains search and modify operations. > The search response contains usually a single entry about 3KB in LDIF > format. There is only a reduce number of LDAP clients (usually one or > two), that are using async LDAP API and sending a lot of operations per > second (> 1000 TPS per client). The client side is an OS Delta box. > > Under these conditions we have tested that increasing the sending buffer > of the server has improved the performance. That's the reason I am > proposing this feature request. > > Pierangelo's proposal allowing hard-set the buffer sizes looks ok. A patch is in HEAD. Please test. It is enabled by default when LDAP_DEVEL is set (namely, when building HEAD). The patch may need some work on architectures different from Linux. p.

1 0

Re: (ITS#6152) proxycache enhancements
by hyc＠symas.com 17 Aug '09

17 Aug '09

Matthew Hardin wrote: > It might be less intrusive codewise and more flexible if we left the > behavior of cache expiration the same and added a parameter to each > template called "Time to Refresh" (TTR). Then you set long or > unlimited cache expirations, which are always in effect, but set a > shorter TTR that would trigger an asynchronous refresh when the TTR > expired. If the db is not available these refreshes will simply fail, > but the data will remain in the cache at least until it's expired by > the usual means. > > This gives the solution designer the option of deciding how long a > system can run disconnected while still being able to separately > determine how stale the contents of the cache will get when connected. > It also means that pcache itself doesn't need to switch modes based on > whether it thinks it's connected to a db or not, and it fact may not > need to even know if it is connected or not. > > There is still room in this design for a flag that controls whether > pcache should behave as if it's disconnected or connected, but I'm not > sure how useful that is given the changes described above. The TTR feature is now available for testing in HEAD. (As well as the offline mode switch.) The TTR behavior is as follows: 1) default is off 2) refreshes are only performed for regular (positive) queries. Negative queries and sizelimit queries are not refreshed. 3) If a query has been referenced in the time since the last refresh, then the expiration time will be extended. So queries that are actively used can stay in the cache indefinitely. 4) If a query has not been referenced, the expiration time will be left unchanged. The query will continue to be refreshed up till its expiration time, at which point it will be removed as normal. A typical configuration for disconnected operation would use TTLs on the order of a few days, with TTR set at whatever refresh interval makes sense. Still need to look at Bind caching. -- -- Howard Chu CTO, 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#6246) SSL fails over a network unless slapd runs with -d 2
by hyc＠symas.com 17 Aug '09

17 Aug '09

E.M. van Gasteren wrote: >>> server, and the answer is just to upgrade since .12 is rather out of >> >> Hm! I'll see if I can get the 2.4.15 openldap stuff from Fedora 11 >> repo's running on lt2 first. > > I ran into serious problems with lt2 and had to rebuild it. I took the > opportunity to use Fedora 11 with openldap 2.4.15. That seems to have > solved the problem. Thanks for the followup, glad it's working for you. Closing this ITS. -- -- Howard Chu CTO, 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#6246) SSL fails over a network unless slapd runs with -d 2
by Ed＠vanGasteren.net 17 Aug '09

17 Aug '09

On 08/11/2009 01:05 PM, E.M. van Gasteren wrote: > > > On 08/11/2009 04:44 AM, Howard Chu wrote: >> Ed(a)vanGasteren.net wrote: >>> Full_Name: Ed van Gasteren >>> Version: 2.4.12 and 2.4.15 >>> OS: linux (Fedora 10, 11) >>> URL: ftp://ftp.openldap.org/incoming/ >>> Submission from: (NULL) (85.223.76.221) >>> >>> >>> On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server >>> and clients. >>> The configuration is such that things work as expected even with >>> security >>> tightened up to "TLSVerifyClient demand". ldapsearch (either to -H >>> ldaps or with >>> -ZZ), nss and gq with TLS work like a charm. >>> >>> On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), >>> gq and >>> Thunderbird connecting to the server on lt2. TLS/SSL only works if I >>> run slapd >>> with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS >>> trace: >>> SSL_connect:SSLv3 read server certificate A". >>> >>> Seems as if the normal code path has a flaw which gets >>> corrected/bypassed by the >>> debugging code. >> >> Doesn't sound familiar, I've never had this problem. However, the TLS >> code was refactored in rev 2.4.14, and it's always possible we missed >> something in the churn. How does openssl s_client react under the same >> conditions? If it hangs the same way, then that points to a bug on the > > Should have mentioned that. It indeed hangs the same way, in the middle > of getting over the "Acceptable client certificate CA names". -- cut -- >> server, and the answer is just to upgrade since .12 is rather out of > > Hm! I'll see if I can get the 2.4.15 openldap stuff from Fedora 11 > repo's running on lt2 first. I ran into serious problems with lt2 and had to rebuild it. I took the opportunity to use Fedora 11 with openldap 2.4.15. That seems to have solved the problem.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by jonathan＠phillipoux.net 17 Aug '09

17 Aug '09

On 17/08/2009 11:09, michael(a)stroeder.com wrote: > masarati(a)aero.polimi.it wrote: >>> >>> I've added support for 'allowedAttributesEffective' in web2ldap recently >>> which >>> works with AD. I tried this overlay but it seg faults with recent OpenLDAP >>> version. Any chance to get this back on the radar? >> >> I've built and tested my copy of allowed.c with HEAD and re24 and it works >> as expected. However, I might have modified it to keep pace with baseline >> code evolution without resubmitting modifications. I can't check right >> now but I will. If needed, I'll resubmit the modified code, so consider >> it done. >> >> The main reason I didn't put it directly in contrib/ is that at that time >> I was considering the opportunity of packaging all contributions and >> customizations intended for samba4 in something as self contained as >> possible (in the end, supporting all samba4 related extensions may result >> in stacking dozens of overlays, which may result in overhead and possibly >> in incompatibilities, something we might need to deal with at some point). >> >> However, as your interest seems to revitalize this feature, I see no >> objection in putting it at least in contrib (if there's enough consensus). > > I'd highly appreciate to find copy under contrib/. Other people I know also > have interest in that. Many thanks. Absolutely, I for one am very interested. Looking forward to it :) Jonathan

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 17 Aug '09

17 Aug '09

masarati(a)aero.polimi.it wrote: >> >> I've added support for 'allowedAttributesEffective' in web2ldap recently >> which >> works with AD. I tried this overlay but it seg faults with recent OpenLDAP >> version. Any chance to get this back on the radar? > > I've built and tested my copy of allowed.c with HEAD and re24 and it works > as expected. However, I might have modified it to keep pace with baseline > code evolution without resubmitting modifications. I can't check right > now but I will. If needed, I'll resubmit the modified code, so consider > it done. > > The main reason I didn't put it directly in contrib/ is that at that time > I was considering the opportunity of packaging all contributions and > customizations intended for samba4 in something as self contained as > possible (in the end, supporting all samba4 related extensions may result > in stacking dozens of overlays, which may result in overhead and possibly > in incompatibilities, something we might need to deal with at some point). > > However, as your interest seems to revitalize this feature, I see no > objection in putting it at least in contrib (if there's enough consensus). I'd highly appreciate to find copy under contrib/. Other people I know also have interest in that. Many thanks. Ciao, Michael.

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 17 Aug '09

17 Aug '09

> HI! > > I've added support for 'allowedAttributesEffective' in web2ldap recently > which > works with AD. I tried this overlay but it seg faults with recent OpenLDAP > version. Any chance to get this back on the radar? Michael, I've built and tested my copy of allowed.c with HEAD and re24 and it works as expected. However, I might have modified it to keep pace with baseline code evolution without resubmitting modifications. I can't check right now but I will. If needed, I'll resubmit the modified code, so consider it done. The main reason I didn't put it directly in contrib/ is that at that time I was considering the opportunity of packaging all contributions and customizations intended for samba4 in something as self contained as possible (in the end, supporting all samba4 related extensions may result in stacking dozens of overlays, which may result in overhead and possibly in incompatibilities, something we might need to deal with at some point). However, as your interest seems to revitalize this feature, I see no objection in putting it at least in contrib (if there's enough consensus). p.

1 0

Re: (ITS#6258) slaptest -f slapd.conf -F slapd.d returns errors without DB
by masarati＠aero.polimi.it 17 Aug '09

17 Aug '09

> Full_Name: Andrew Bartlett > Version: CVS HEAD > OS: Fedora 10 > URL: > Submission from: (NULL) (59.167.251.137) > > > When running slaptest to convert between slapd.conf and slapd.d format > configuration, before the databases exist, the slaptest returns with an > non-zero > error code and prints warnings. > > If I add -u to the command line, then it does not perform the conversion. > > In Samba4's provision system, I wish to run using cn=config from the very > start, > and so wish to do the conversion before the databases are created. > > I had expected -u to quiet the warnings, but it was unexpected that it > would > also not perform the conversion. (I understand it is also considered a > 'dry > run' parameter). > > Can I have a new parameter added to allow a behaviour of 'do the > conversion, > don't check the database vaildity'? I think having a "dry dun" that does no harm, and a "safe" (although perhaps overconservative) behavior are very important, so I wouldn't favor a modification of their behavior (let alone the implied behavioral change issues). However I don't see any issue in having a specific, well documented behavior implemented within a specific option. Perhaps, given it is a specific and not recommended behavior in normal (read: overconservative) use, it could go under the "-o" switch, which is a catchall for specific options. p.

1 0

(ITS#6258) slaptest -f slapd.conf -F slapd.d returns errors without DB
by abartlet＠samba.org 16 Aug '09

16 Aug '09

Full_Name: Andrew Bartlett Version: CVS HEAD OS: Fedora 10 URL: Submission from: (NULL) (59.167.251.137) When running slaptest to convert between slapd.conf and slapd.d format configuration, before the databases exist, the slaptest returns with an non-zero error code and prints warnings. If I add -u to the command line, then it does not perform the conversion. In Samba4's provision system, I wish to run using cn=config from the very start, and so wish to do the conversion before the databases are created. I had expected -u to quiet the warnings, but it was unexpected that it would also not perform the conversion. (I understand it is also considered a 'dry run' parameter). Can I have a new parameter added to allow a behaviour of 'do the conversion, don't check the database vaildity'? Thanks, Andrew Bartlett

1 0

Re: (ITS#6247)
by daniel＠pluta.biz 16 Aug '09

16 Aug '09

Howard Chu schrieb: > Kurt(a)OpenLDAP.org wrote: >> With that, I leave determination of the technical suitability to the >> Project. @Kurt: my given copyright notices meet my intentions. > I'm not sure why the 2 additional syntaxes are useful. If you want to > define a generalizedTime attribute that cannot be compared for ordering, > simply omit the ORDERING rule from the attribute's definition. I thought, that it is possible to "overwrite" the ORDERING (even if its left empty) by using any kind of syntax-related matching rule assertion... This is a quite old posting from the list but nevertheless I would like to cite it: http://www.openldap.org/lists/openldap-devel/200010/msg00092.html ------8<-------8<------ >Also, I have found this interesting section in RFC 2252: > >----- >8. Matching Rules > > Servers which implement the extensibleMatch filter SHOULD allow all > the matching rules listed in this section to be used in the > extensibleMatch. In general these servers SHOULD allow matching > rules to be used with all attribute types known to the server, when > the assertion syntax of the matching rule is the same as the value > syntax of the attribute. Yes. That is, if the held value is syntax X, one should be able to use any matching rule in which the assertion syntax X. ------8<-------8<------ > The use of negatives is rather confusing. In the example, instead of > "nowNotBefore" and "nowNotAfter" I would simply have called them > "startDate" and "endDate". In general, the names indeed sound quite strange. But that seems only a matter of style. NotAfter and NotBefore is borrowed from ssl certificates' validNotBefore/-After fields. As I've called the module "now" I just replaced "valid" by "now"... On the other hand I wanted to be sure to not collide with some might be existing attribute definitions. > The language is also confusing in other areas, I don't understand what > property you're trying to convey with the terms "dead center attribute" simply the lower and the upper limits of a time period (lower: nowNotBefore, upper: nowNotAfter) > or "syntactically standalone attribute". All I've ment is just a new syntax name to differentiate regarding the special use of "now" and to avoid the possibility regarding my (possibly wrong) assumption that matching rules can be "overwritten". > On a slightly related note, in the context of time-relative ACLs, it > would be worthwhile to define a behavior for time-of-day comparisons > (i.e., just compare hours:minutes:seconds, excluding year/month/day). This kind of feature sounds fine to me, too. Perhaps something like this could be implemented by introducing some kind of officeHourSyntax + matching rule which operates on e.g. "day(s)_of_week#hh:mm:ss#hh:mm:ss" attribute values (just my first thought and very simplified). On the other side, using only one attribute which stores a start as well as an end timestamp is not what I originally wanted for "now" because I would like to have the possibility to track period extensions using the multi-valued upper dead center attribute. > Companies often want to limit access to resources to only a set of > office hours, etc. Of course to properly handle the "office hours" case > would also require day-of-week matching. That may be getting to be too > complicated for this particular submission, but it seems closely related > so I mention it here. In my opinion your suggestion sounds really interesting. I personally just had searched for some kind of solution to get rid of the just-in-time event-triggered dependencies regarding provisioning of interconnected (not replicated) IDM-systems. So "now's" scope targets to longer (more static, not often changing) time-distances. The check for the "office hours case" could be handled by an all-in-wonder (multi-valued) attribute which stores "day(s)#start#end". Many thanks for your feedback. Some additional feedback/clarification regarding the above mentioned "overwriting" of matching rules would be very fine, too (e.g. a link where I can get the detailed specs).

1 0

Re: (ITS#6247)
by masarati＠aero.polimi.it 16 Aug '09

16 Aug '09

> On a slightly related note, in the context of time-relative ACLs, it would > be > worthwhile to define a behavior for time-of-day comparisons (i.e., just > compare hours:minutes:seconds, excluding year/month/day). Companies often > want > to limit access to resources to only a set of office hours, etc. Of course > to > properly handle the "office hours" case would also require day-of-week > matching. That may be getting to be too complicated for this particular > submission, but it seems closely related so I mention it here. Howard, I was also thinking of something like that. Since we basically have a field available in the matching rule (the asserted value), I suggested to add an assertion syntax defaulting to the empty value. I was planning to turn this assertion syntax into a timestamp mask that allows to filter what fractions should be asserted. Another possibly related issue is locale: the time of slapd is supposed to be UTC, but filtering on working hours and so should be done keeping into account timezone, daylight saving and so. The assertion syntax could handle this in a user-friendly manner. Probably, I better step off and formalize things before further coding. p.

1 0

(ITS#6257) libldap: getopt flag to return the SASL username
by michael＠stroeder.com 16 Aug '09

16 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.93.2) libldap should be capable of returning SASL username obtained with sasl_getprop( sasl_context, SASL_USERNAME, ... ) as result of ldap_get_option()

1 0

Re: (ITS#6247)
by hyc＠symas.com 16 Aug '09

16 Aug '09

Kurt(a)OpenLDAP.org wrote: > With that, I leave determination of the technical suitability to the > Project. It took me several passes through this discussion and the README to understand what the intent of this code is. Just to make sure I get it, let me restate what I saw: 3 extended matching rules for comparing a timestamp attribute to the server's current clock. I'm not sure why the 2 additional syntaxes are useful. If you want to define a generalizedTime attribute that cannot be compared for ordering, simply omit the ORDERING rule from the attribute's definition. The use of negatives is rather confusing. In the example, instead of "nowNotBefore" and "nowNotAfter" I would simply have called them "startDate" and "endDate". The language is also confusing in other areas, I don't understand what property you're trying to convey with the terms "dead center attribute" or "syntactically standalone attribute". On a slightly related note, in the context of time-relative ACLs, it would be worthwhile to define a behavior for time-of-day comparisons (i.e., just compare hours:minutes:seconds, excluding year/month/day). Companies often want to limit access to resources to only a set of office hours, etc. Of course to properly handle the "office hours" case would also require day-of-week matching. That may be getting to be too complicated for this particular submission, but it seems closely related so I mention it here. -- -- Howard Chu CTO, 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#6247)
by Kurt＠OpenLDAP.org 15 Aug '09

15 Aug '09

Daniel, While I understand you to have both some IPR concerns and technical concerns with what Ando proposed, I will only concern myself to the IPR issues. Thank you for updating your contribution to provide the required notices. I have provided guidance to Ando on how to create a work derived from your submission which, I believe, mets the terms of the license, the OpenLDAP Public License, you granted. In particular, I provided him guidance on how to properly "retain your copyright statement and notices". Presuming your notices are properly retained, I see no IPR issue here in the project accepting your contribution and/or Ando's derived work, and the Foundation distributing either or both. I do regularly review commits to our source repository to ensure IPR issues are adequately addressed, but do feel free to raise any issue you see in how we handle materials which you have copyright interest in. Beyond that, I leave it to the Project to determine the technical suitability of these contributions and what, if any, modifications should be made prior to inclusion in OpenLDAP Software. Given your license grant, the Foundation sees no obligation to seek further permission from you and hence will not seek additional permission before redistributing your work, with or without modification. If it was your intent to require those redistributing your work, with or without modification, to obtain some additional permission from you, please immediately advise us that your copyright statement and notice do not reflect your intentions. If immediately advised, we will try to honor your intentions. Otherwise, we will continue to assume, as we do now, that your copyright statement and notice reflect your intentions at the time of your contribution was offered. With that, I leave determination of the technical suitability to the Project. Regards, Kurt

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by masarati＠aero.polimi.it 15 Aug '09

15 Aug '09

> HI! > > I've added support for 'allowedAttributesEffective' in web2ldap recently > which > works with AD. I tried this overlay but it seg faults with recent OpenLDAP > version. Any chance to get this back on the radar? Not *now*, possibly shortly. p.

1 0

(ITS#6256) segfault in syncrepl_add
by jonathan＠phillipoux.net 15 Aug '09

15 Aug '09

Full_Name: Jonathan Clarke Version: RE24 and HEAD from today OS: URL: ftp://ftp.openldap.org/incoming/jonathan-clarke-syncrepl-20090815.patch Submission from: (NULL) (88.164.187.72) syncinfo_free attempts: sie->si_cookieState->cs_ref-- Although si_cookieState may be NULL. When adding a syncrepl consumer (either through slapd.conf or online via cn=config), if the syncrepl config line causes a parse error, syncinfo_free is called and makes slapd segfault. Other paths through syncrepl_add may cause this too. The patch above corrects this.

1 0

Re: (ITS#6225) GSSAPI support for client library (fixes)
by mimir＠samba.org 15 Aug '09

15 Aug '09

--fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=iso-8859-2 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jul 24, 2009 at 09:20:46PM -0700, Howard Chu wrote: > mimir(a)samba.org wrote: >> Full_Name: Rafal Szczesniak >> Version: Stable (2.4.16) >> OS: GNU/Linux >> URL: http://www.samba.org/~mimir/gssapi-bugfix.diff >> Submission from: (NULL) (67.51.54.234) >> >> >> This is a bugfix patch for OpenLDAP's gssapi support. >> > One of these patches appears to duplicate ITS#6092. As the original=20 > author of this code, could you also take a look at #6091 and #6093? Yes, will do. Sorry about late reply, but first I was travelling and then I went for a holidays. cheers, --=20 Rafal Szczesniak Samba Team member http://www.samba.org Likewise Software http://www.likewise.com --fUYQa+Pmc3FrFX/N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iD8DBQFKhpcNHvdfyv3qiKkRAnssAKCaoT2CpqhPfHkmx1sATZBQREFgIQCfVKz6 L6ab8DXdz3XlCQqrRsul6Cw= =MklT -----END PGP SIGNATURE----- --fUYQa+Pmc3FrFX/N--

1 0

(ITS#6247)
by daniel＠pluta.biz 15 Aug '09

15 Aug '09

I've just removed four unnecessary Debug() statements (to get rid of the warnings during the build). ftp://ftp.openldap.org/incoming/daniel-pluta-now-090815-2.tgz Please note there are still only dummy values assigned as OIDs.

1 0

(ITS#6247)
by daniel＠pluta.biz 15 Aug '09

15 Aug '09

I've just removed four ugly Debug() statements. ftp://ftp.openldap.org/incoming/daniel-pluta-now-090815-2.tgz BTW: There are still only DUMMY-Values assigned as OIDs.

1 0

(ITS#6247)
by daniel＠pluta.biz 15 Aug '09

15 Aug '09

Dear Pierangelo, (dear Kurt), first of all my special thanks belong to both of you for your contribution to the on going discussions. Secondly I want to take the opportunity just right now to clarify that I do not agree to your idea or suggestion to extend the copyright in direction of a dual-portion-copyright statement. Based on my analysis of your surprisingly fast submitted code sample I came to the following conclusion and justification regarding my decision above: Last but not least I would have appreciated it if you would have contacted me *before* changing the code and not to mention my copyright notice. Thanks Kurt for your intervention. Besides this, as time, discussion and development has continuously moved on (even before your kind of "uncoordinated emergency submit") it seems to me that your sudden sample code does not cover any of my primary intentions already rudimentary contained in "now.c" and mentioned during the discussion: - there's no kind of inheritance of matching rules (all are directly associated to generalizedTime / CSN) - additionally the nowOrLater *and* the nowOrEarlier-rules are associated simultaneously to one and the same attribute (what makes no difference for single-valued attribute and thus could be done. On the other hand this leads to false positively reported valid but indeed invalid entries in case of multi-valued attributes - details see below). - you have not implemented any sort of possibility to allow the definition of separate "syntactically standalone" attributes (derived from generalizedTime/CSN, by independent syntax) to limit LE/GE filtering for both dead center attributes. (limiting search access using ACLs would obviously not work because the extensible search needs to be allowed). - multi-valued upper dead center timestamp attributes can not be handled correctly by your code. I have not investigated in deep but it is clear to me that in case of multiple values whereas one or more timestamp/CSN values are in the past, while at least one is in the future leads to the above mentioned false positive reporting in your code. - It seems to me that you have not tested the behavior of your suggested code properly in this short period of time (your tests have only seem to cover createTimestamp - which btw do not make any sense in concern to now.c's common intention in case the createTimestamp's value has not been faked ;-)). - as your code changes significantly changes the behavior and intention of now.c your submit also lacks any kind of documentation (besides the code, which I had to analyze first). In my opinion your submit sadly does not represent a very useful enhancement nor a functional extension (in the sense of the original goal of now.c) which could be integrated without major adaptations. That's the reason why I'm currently not see any reason to share my copyright notice. Nevertheless, as I've already told you before the discussion with you have always been very helpful for me so I've added you willingly to the acknowledgments section. I hope you understand my explanations and it will be fine for you. Of course I'm available and ready for further technical discussions ... Last but not least and from lessons learn: I think some kind of a formal specification (external to my head ;-)) would be very helpful to understand the design ideas, decisions as well as the new chances (and possible limitations) now.c introduces into LDAP. One or perhaps even more related I-Ds are currently a work in progress here at my side. I've uploaded a new version of now.c (as tgz because it contains various files, e.g. a sample schema in ldif- and schema-format for easier testing and perhaps as a basis for on going discussions). I hope I've correctly updated the IPR statement according my above expressed intention and according the needs of the OpenLDAP foundation. Kurt could you please have a look on it again? The updated version can be obtained from here: ftp://ftp.openldap.org/incoming/daniel-pluta-now-090815.tgz Thanks a lot and best regards Daniel -------- Original-Nachricht -------- Betreff: Re: [OFFLINE] Re: (ITS#6247) Datum: Thu, 13 Aug 2009 08:54:35 -0700 Von: Kurt Zeilenga <kurt(a)OpenLDAP.org> An: masarati(a)aero.polimi.it CC: daniel(a)pluta.biz Referenzen: <200908131112.n7DBCYIx025879(a)boole.openldap.org> <46026.93.149.38.235.1250177284.squirrel(a)www.aero.polimi.it> On Aug 13, 2009, at 8:28 AM, masarati(a)aero.polimi.it wrote: > Daniel (Kurt), > > (Note to Kurt: as there is no affiliation between Daniel and me, we > did > not coordinate anything, so we'll probably better do it now and > start from > scratch, instead of polluting the ITS). This needs to be done in two steps. 1) Daniel needs to address notices issues in his submission. 2) You need to address the notices issues in your derived submission. Daniel should follow the instructions I provide, and then you should follow the instructions I provide. These steps are simple, straight forward, and have a clear result. > I suggest Daniel evaluates the line I'm proposing No. This in no way fulfills the Foundation requirements. The line you are asking Daniel to evaluate is not a formal notice. You actually failed to met his license, which requires you to include a copy of his copyright notice in your work. You copied only an informal acknowledgement, not his copyright notice and license statement. > and, based on the file I > submitted, formalizes a definitive patch with appropriate copyrights > and > submits it along the guidelines of the OpenLDAP foundation. Your submission doesn't met the guidelines of the Foundation as it also doesn't include a notice of origin nor asserts your copyright, and worse, it failed to met the copying requirement Daniel placed on his submission (that his notice be included in copies).

1 0

Re: (ITS#4730) Overlay that generates operational attributes to support GUI interaction
by michael＠stroeder.com 14 Aug '09

14 Aug '09

HI! I've added support for 'allowedAttributesEffective' in web2ldap recently which works with AD. I tried this overlay but it seg faults with recent OpenLDAP version. Any chance to get this back on the radar? Ciao, Michael.

1 0

Re: (ITS#6253) sizelimit is enforced before applying local filters with a translucent overlay
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

Fixed in HEAD; please test. Thanks, p.

1 0

(ITS#6255) translucent remote data overrides local in filter
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.235) Submitted by: ando Consider data as set up by test034; the remote server contains an entry "uid=danger,ou=users,o=translucent" with "cn=danger", while the local database contains the same entry with "cn=henry". Searching for "cn=danger" will return the local entry, whose "cn" is "henry" and not "danger", and thus does not match the search filter. p.

1 0

(ITS#6254) translucent returns all attributes, no matter what's requested
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: Linux x86 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (93.149.38.235) Submitted by: ando I've just noticed that slapo-translucent on search returns the entire entry, regardless of what attrs are requested. Tested with re24 (candidate for 2.4.18) and HEAD. p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 13 Aug '09

13 Aug '09

--On Thursday, August 13, 2009 8:56 PM +0200 masarati(a)aero.polimi.it wrote: > >> A quick hack consists in removing the test for SLAP_GLUE_SUBORDINATE() in >> monitor_subsys_database_init(). This will expose subordinate databases >> and thus should allow back-bdb and back-hdb to hook their cache stats >> stuff. Probably this is the best approach. I would complement it by >> adding a olmIsSubordinate attribute with TRUE value, and/or a >> olmSuperiorSuffix containing the suffix of the superior. > > An even better approach would be to append subordinate databases below the > superior one... but I'd leave this for 2.5 :) Thanks for handling this. :) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

> A quick hack consists in removing the test for SLAP_GLUE_SUBORDINATE() in > monitor_subsys_database_init(). This will expose subordinate databases > and thus should allow back-bdb and back-hdb to hook their cache stats > stuff. Probably this is the best approach. I would complement it by > adding a olmIsSubordinate attribute with TRUE value, and/or a > olmSuperiorSuffix containing the suffix of the superior. An even better approach would be to append subordinate databases below the superior one... but I'd leave this for 2.5 :) p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

> Any chance we can get this fixed for 2.4.18 for the real backends? I > think > making it so you can see the counters per-real backend should definitely > be > in place. How to handle the frontend is interesting and definitely should > be addressed as well but isn't (to me at least) quite as crucial at this > moment. ;) A quick hack consists in removing the test for SLAP_GLUE_SUBORDINATE() in monitor_subsys_database_init(). This will expose subordinate databases and thus should allow back-bdb and back-hdb to hook their cache stats stuff. Probably this is the best approach. I would complement it by adding a olmIsSubordinate attribute with TRUE value, and/or a olmSuperiorSuffix containing the suffix of the superior. p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 13 Aug '09

13 Aug '09

--On Thursday, August 06, 2009 7:25 PM +0200 masarati(a)aero.polimi.it wrote: >> >> >> --On August 5, 2009 7:17:43 PM +0000 masarati(a)aero.polimi.it wrote: >> >>>> This may be specific to glued databases (databases rooted at ""). >>> >>> The problem could be partially addressed by telling back-bdb (who's >>> maintaining this data in the monitor backend) to check subordinates as >>> soon as it discovers it's a glue instance. However, this poses two >>> different problems: >>> >>> - is the aggregate information resulting from adding all glued databases >>> cache usage still useful? >>> >>> - what happens if heterogeneous databases are glued? Significantly, >>> what >>> if the superior database is not bdb/hdb? >>> >>> Probably, the monitor database should also present subordinate databases >>> as separate entries. >> >> Interestingly, in my case, there's only one real database in play for the >> glue as it is, since it's rooted at "". All other database definitions >> come before it (cn=config, cn=accesslog, cn=monitor). > > but... are you actually gluing something? In any case, this is not > specific to the case of empty suffix in the glue database. I could easily > reproduce it with a "normal" glued setup, and I was about to start fixing > things when the two above questions came to my mind. > >> I'm also curious why back-monitor develops stats for the other caches but >> specifically not for entry cache. > > I haven't looked in detail, but it makes sense that some operation occurs > within the glue database which requires caching something, but not > entries. > > - The entry cache monitor shows the value of bdb->bi_cache.c_cursize; > > - the DN cache monitor shows the value of bdb->bi_cache.c_eiused, which > should be the number of entryinfo structures used; > > - the IDL cache monitor shows the value of bdb->bi_idl_cache_size. > > In my very simple tests, I only saw something populating the DN cache, > which means some internal operation required to allocate some entryinfo > structures that remain 'round. > > In any case, it's only showing information related to its database > structure, it is by no means collecting info from the glued databases. Any chance we can get this fixed for 2.4.18 for the real backends? I think making it so you can see the counters per-real backend should definitely be in place. How to handle the frontend is interesting and definitely should be addressed as well but isn't (to me at least) quite as crucial at this moment. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6190) back-meta tls start only works when set before any target specification
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

Fixed in HEAD, please test. Thanks, p.

1 0

Re: (ITS#6253) sizelimit is enforced before applying local filters with a translucent overlay
by hyc＠symas.com 13 Aug '09

13 Aug '09

masarati(a)aero.polimi.it wrote: >> If a 'sizelimit' is required in a query to an LDAP server that uses a >> translucent overlay, and the filter has to be split between a remote >> filter and >> a local filter, and the remote filter returns more than 'sizelimit' >> objects, you >> will get a 'sizelimit' error even if the local filter would have filtered >> out >> enough objects to keep the number of objects under the sizelimit. >> >> In my case I have an LDAP holding basic posixAccount information plus a >> translucent holding Samba information. >> >> The following query: >> % ldapsearch -z 1 -x -s one -b 'ou=Users,dc=hq,dc=eboxhq,dc=com' -H >> 'ldap://127.0.0.1:1390' >> '(&(objectClass=posixAccount)(sambaSID=S-1-5-21-3818554400-921237426-3143208535-5004))' >> uid >> >> only matches one object in the LDAP directory, but it will fail because >> the >> remote LDAP will return every user and then the 'sizelimit' is immediately >> enforced before applying the local (sambaSID) filter. >> >> The result with -z 1 is: >> # search result >> search: 2 >> result: 4 Size limit exceeded >> >> # numResponses: 1 >> >> The result without the -z option is: >> # bar, Users, hq.eboxhq.com >> dn: uid=bar,ou=Users,dc=hq,dc=eboxhq,dc=com >> uid: bar >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> >> I think the 'sizelimit' should only be applied to the last set of results >> and >> not to the number of results in intermediate steps. > > This could be partially cured by removing any size limit while propagating > the request to the remote server. Please note that, however, this would > not prevent the remote server from applying administrative size limits > regardless of what the client is requesting. And I would probably use the unchecked sizelimit within the overlay as well. -- -- Howard Chu CTO, 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#6247)
by Kurt＠OpenLDAP.org 13 Aug '09

13 Aug '09

On Aug 13, 2009, at 7:24 AM, masarati(a)aero.polimi.it wrote: > Please check the code, and see if you agree in the attributions > (significantly, in releasing the copyright to the OpenLDAP > foundation). No. Once Daniel corrects his submission, and the Foundation finds it acceptable, it can be used in OpenLDAP with or without modification. No further of legal agreement with Daniel is needed and hence should not be requested. That is, Daniel's copyright notice must provide and must be relied on to give appropriate license. The notice you include in your submission would (assuming Daniel's submission is accepted, and your submission is derived (in the copyright sense) from his) would be wrong as it doesn't preserve his notice. The end result in OpenLDAP Software would be something like: * Copyright 2009 The OpenLDAP Foundation. * Portions Copyright 2009 Daniel Pluta. * Portions Copyright 2009 Pierangelo Masarati * All rights reserved. ... The PORTIONS COPYRIGHT: comment must be removed. Instead, the ACKNOWLEDGEMENT section should include whatever attribution (in the non-copyright sense) is appropriate in this case. Something like: This work was developed by Pierangelo Masarati based upon a previous work developed by Daniel Pluta. Both this and the previous work were developed for inclusion in OpenLDAP Software. > Also, note that an OID from OpenLDAP's devel arc has been used, but > not > yet allocated. I plan to do it shortly. > > p. > >

1 0

Re: (ITS#6247)
by Kurt＠OpenLDAP.org 13 Aug '09

13 Aug '09

On Aug 12, 2009, at 1:12 PM, daniel(a)pluta.biz wrote: > Hi, > > I've just uploaded an updated version. > > Changes regarding schema: > - Added EQ-Matching rule to both nowNot{Before|After} attributes > - changed attribute nowNotAfter from single- into multi-value > > ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz > This submission, aside from not being in the form of a patch, doesn't include "notice of origin" as required by our contributing guidelines <http://www.openldap.org/devel/contributing.html >. Also, your tarball contains a source file that includes a copyright notice, the tarball includes other file(s). This makes it non-obvious as to whether your copyright notice is intended to apply only to the source file but to the tarball as a whole (including the other file(s)). (This is why our guidelines ask for patches with notices at top, it makes it more clear as to what copyright you are asserting.) As an alternative to reworking your submission as a patch, you can instead include a file called COPYRIGHT which contains both of the required notices. Please revise your contribution so that it may be properly considered. Consideration of Ando's submission will be deferred until such time as your contribution is accepted (as it appears to be based upon yours). -- Kurt

1 0

Re: (ITS#6247)
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

Please see <ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-13-now2.1.c> for a minimal implementation that instantiates a specific syntax (that only allows the empty string) and works for generalizedTime as well as CSN syntaxes. Valid filters are (createTimestamp:nowOrEarlier:=) (entryCSN:nowOrLater:=) Please check the code, and see if you agree in the attributions (significantly, in releasing the copyright to the OpenLDAP foundation). Also, note that an OID from OpenLDAP's devel arc has been used, but not yet allocated. I plan to do it shortly. p.

1 0

Re: (ITS#6253) sizelimit is enforced before applying local filters with a translucent overlay
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

> If a 'sizelimit' is required in a query to an LDAP server that uses a > translucent overlay, and the filter has to be split between a remote > filter and > a local filter, and the remote filter returns more than 'sizelimit' > objects, you > will get a 'sizelimit' error even if the local filter would have filtered > out > enough objects to keep the number of objects under the sizelimit. > > In my case I have an LDAP holding basic posixAccount information plus a > translucent holding Samba information. > > The following query: > % ldapsearch -z 1 -x -s one -b 'ou=Users,dc=hq,dc=eboxhq,dc=com' -H > 'ldap://127.0.0.1:1390' > '(&(objectClass=posixAccount)(sambaSID=S-1-5-21-3818554400-921237426-3143208535-5004))' > uid > > only matches one object in the LDAP directory, but it will fail because > the > remote LDAP will return every user and then the 'sizelimit' is immediately > enforced before applying the local (sambaSID) filter. > > The result with -z 1 is: > # search result > search: 2 > result: 4 Size limit exceeded > > # numResponses: 1 > > The result without the -z option is: > # bar, Users, hq.eboxhq.com > dn: uid=bar,ou=Users,dc=hq,dc=eboxhq,dc=com > uid: bar > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > I think the 'sizelimit' should only be applied to the last set of results > and > not to the number of results in intermediate steps. This could be partially cured by removing any size limit while propagating the request to the remote server. Please note that, however, this would not prevent the remote server from applying administrative size limits regardless of what the client is requesting. p.

1 0

Re: (ITS#6247)
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

> masarati(a)aero.polimi.it wrote: >> As I mentioned in an earlier posting, any generalizedTime-syntax >> attribute >> can use your special matching rules by way of the extensible filter >> mechanism, regardless of having any matching rule in their definition. >> > I thought, that by not assigning any matching rule the EQ/LE/GE > comparison is not possible at all. That's the behavior I would like to > achieve regarding the two minimum-attributes (regardless whether the > probable separation of matching rules and attribute definitions - > disscussed in the above paragraphs). By not assigning a matching rule, that specific matching is not possible using normal filters. However, the extensible filter mechanism overrides this, by allowing to specify the desired matching rule in the AVA. > Yesterday I've noticed that without an EQ-Matching definition I was not > able to add an additional value in case of a multi-valued attribute > definition (so I added EQ-Matching again). I have to admit that I do not > understand this in detail. I also have not investigated in deep... That's a totally different business. If you do not define an equality matching rule, multiple values cannot be checked for duplicates. So the only way to add a value consists in performing a modify:delete and a modify:add within the same modify operation that removes the original values and replaces them with themselves plus the new ones. >> Moreover, attributes can already be defined using >> slapd.conf/back-config, >> so there's no need to hardcode them in your module (except, possibly, >> for >> your specific needs, but this makes the module less general and useful >> to >> others). >> > The oc/attr definition is for demonstration purposes only (I though it's > more compact to include this "demo" and implement it the most restricted > way regard data privacy (especially disallow querying LE/GE for both > attr). > Problably I'll separate the demo into an extra schema file. You should. Please note that for the purpose of testing your code, every entry already has a createTimestamp and a modifyTimestamp attribute. >> But >> the real reason is that "exactly equal to now" makes little sense as >> "now" >> is evanescent: you have no control about exactly when your matching rule >> > hehe that relativistic effects I already had in mind before implementing > this kind of matching rule. That's the reason I originally followed the > approach to manipulate the search requests' filters. This approach could > assure to make use of the "same" now (op->o_time) for all entries. Well, this calls for an extension of the matching API that also passes the Operation pointer. Something for 2.5, if worth the effort (note that value matching and operations are orthogonal, as value matching can also occur outside the scope of a LDAP operation, so passing that pointer would basically be a matter of opportunity if matching rule implementations need it). > By using the matching rule (especially in combination with the filter= > statement in ACLs) "now" will become some kind of "time distance" > instead of a point in time because a search' results get evaluated > sequentially by test_filter(). > > In worst case the second have of a billion search entries are valid > during the search but get "invalid" during acl processing, because time > move's on... ;-) > > On the other side comparing the lines of code of the matching rule > approach to my previous pre-alpha overlay's lines of code, this matching > rule's implementation is about 10 times smaller... If you follow my advice, it'll be 100 times smaller :) >> will be evaluated, so if the difference between "including now" or >> "excluding now" is crucial, then there might be something flawed in the >> policy you're trying to implement. >> > Ok, this in mind I'll at least reduce the matching rules to two but the > problem (now == time_delta) still exists. I concur. >> Getting more into implementation related aspects, I think you should >> really ignore the asserted value, rather than check it's equal to the >> Epoch. I initially suggested to put the Epoch as the asserted value in >> order to use some clearly recognizable, yet valid, value. But this >> should >> be a matter of style rather than a requirement of the matching rule. >> > I regard to some kind of future formal specification I thought about > this, too: in my opinion it seems to be "unnatural" to search (assert) a > non-Timestamp-value to a generalizedTimestamp-Syntax attribute... But > probably that's really only a matter of style. I'm not sure I understand what you mean here. If you mean that anything could fit as the asserted value, this is not correct, because LDAP requires the asserted value to comply with the syntax of the matchingRule. Of course one could define a syntax for asserting generalizedTime values that consists in the empty string, so that (createTimestamp:laterThanNow:=) is a valid filter (note the empty asserted value). >> With respect to OID assignment, as soon as your contribution is >> considered >> of general usefulness, it could receive a temporary OID out of >> OpenLDAP's >> experimental branch. If you intend to formalize this set of matching >> rules somehow, you should apply for IANA assignment of an official OID. >> >> Note that I'm not encouraging nor discouraging you in this sense. >> > I'm currently thinking about this... > > Thanks for your feedback the discussion is very interesting and helpful. p.

1 0

Re: (ITS#6247)
by daniel＠pluta.biz 13 Aug '09

13 Aug '09

masarati(a)aero.polimi.it wrote: >> Hi, >> >> I've just uploaded an updated version. >> >> Changes regarding schema: >> - Added EQ-Matching rule to both nowNot{Before|After} attributes >> - changed attribute nowNotAfter from single- into multi-value >> >> ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz >> > > In order to make your contribution useful to others, I think you should > definitely separate comparison with respect to current time from the rest > of what you need. > In this sense, special matching rules to compare generalizedTime-syntax > attributes with respect to "now" have nothing to do with the declaration > of specific generalizedTime-valued attributes. > I've already thought about this. I'm in two minds about that. > As I mentioned in an earlier posting, any generalizedTime-syntax attribute > can use your special matching rules by way of the extensible filter > mechanism, regardless of having any matching rule in their definition. > I thought, that by not assigning any matching rule the EQ/LE/GE comparison is not possible at all. That's the behavior I would like to achieve regarding the two minimum-attributes (regardless whether the probable separation of matching rules and attribute definitions - disscussed in the above paragraphs). Yesterday I've noticed that without an EQ-Matching definition I was not able to add an additional value in case of a multi-valued attribute definition (so I added EQ-Matching again). I have to admit that I do not understand this in detail. I also have not investigated in deep... > Moreover, attributes can already be defined using slapd.conf/back-config, > so there's no need to hardcode them in your module (except, possibly, for > your specific needs, but this makes the module less general and useful to > others). > The oc/attr definition is for demonstration purposes only (I though it's more compact to include this "demo" and implement it the most restricted way regard data privacy (especially disallow querying LE/GE for both attr). Problably I'll separate the demo into an extra schema file. > But > the real reason is that "exactly equal to now" makes little sense as "now" > is evanescent: you have no control about exactly when your matching rule > hehe that relativistic effects I already had in mind before implementing this kind of matching rule. That's the reason I originally followed the approach to manipulate the search requests' filters. This approach could assure to make use of the "same" now (op->o_time) for all entries. By using the matching rule (especially in combination with the filter= statement in ACLs) "now" will become some kind of "time distance" instead of a point in time because a search' results get evaluated sequentially by test_filter(). In worst case the second have of a billion search entries are valid during the search but get "invalid" during acl processing, because time move's on... ;-) On the other side comparing the lines of code of the matching rule approach to my previous pre-alpha overlay's lines of code, this matching rule's implementation is about 10 times smaller... > will be evaluated, so if the difference between "including now" or > "excluding now" is crucial, then there might be something flawed in the > policy you're trying to implement. > Ok, this in mind I'll at least reduce the matching rules to two but the problem (now == time_delta) still exists. > Getting more into implementation related aspects, I think you should > really ignore the asserted value, rather than check it's equal to the > Epoch. I initially suggested to put the Epoch as the asserted value in > order to use some clearly recognizable, yet valid, value. But this should > be a matter of style rather than a requirement of the matching rule. > I regard to some kind of future formal specification I thought about this, too: in my opinion it seems to be "unnatural" to search (assert) a non-Timestamp-value to a generalizedTimestamp-Syntax attribute... But probably that's really only a matter of style. > With respect to OID assignment, as soon as your contribution is considered > of general usefulness, it could receive a temporary OID out of OpenLDAP's > experimental branch. If you intend to formalize this set of matching > rules somehow, you should apply for IANA assignment of an official OID. > > Note that I'm not encouraging nor discouraging you in this sense. > I'm currently thinking about this... Thanks for your feedback the discussion is very interesting and helpful.

1 0

Re: (ITS#6140) nadf.schema: AttributeType not found: "lastModifiedTime"
by michael＠stroeder.com 13 Aug '09

13 Aug '09

hyc(a)symas.com wrote: > hyc(a)symas.com wrote: >> So it seems the relevance of this schema to anything in use today is >> about nil. > >> If you can find any current, active organizations with a currently maintained >> spec for this schema, we can certainly update it. Otherwise, seems like we >> should drop it. > > There is still an archive of the NADF documents here > http://stats.dante.org.uk/nameflow/ds/nadf.html > > but again, the very difficulty in locating them tends to indicate that they're > not in common use... I'd have no objections against removing that file from OpenLDAP's source distribution. I was just testing including as many schema files as possible and checking dependencies (for interop testing with web2ldap). Ciao, Michael.

1 0

Re: (ITS#6247)
by masarati＠aero.polimi.it 13 Aug '09

13 Aug '09

> Hi, > > I've just uploaded an updated version. > > Changes regarding schema: > - Added EQ-Matching rule to both nowNot{Before|After} attributes > - changed attribute nowNotAfter from single- into multi-value > > ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz In order to make your contribution useful to others, I think you should definitely separate comparison with respect to current time from the rest of what you need. In this sense, special matching rules to compare generalizedTime-syntax attributes with respect to "now" have nothing to do with the declaration of specific generalizedTime-valued attributes. As I mentioned in an earlier posting, any generalizedTime-syntax attribute can use your special matching rules by way of the extensible filter mechanism, regardless of having any matching rule in their definition. Moreover, attributes can already be defined using slapd.conf/back-config, so there's no need to hardcode them in your module (except, possibly, for your specific needs, but this makes the module less general and useful to others). Finally, I don't think having both a "(<)" and a "(<=)" rule makes sense. LDAP only defines "(<=)" since one may construct "<" as "(!(>=))". But the real reason is that "exactly equal to now" makes little sense as "now" is evanescent: you have no control about exactly when your matching rule will be evaluated, so if the difference between "including now" or "excluding now" is crucial, then there might be something flawed in the policy you're trying to implement. Getting more into implementation related aspects, I think you should really ignore the asserted value, rather than check it's equal to the Epoch. I initially suggested to put the Epoch as the asserted value in order to use some clearly recognizable, yet valid, value. But this should be a matter of style rather than a requirement of the matching rule. With respect to OID assignment, as soon as your contribution is considered of general usefulness, it could receive a temporary OID out of OpenLDAP's experimental branch. If you intend to formalize this set of matching rules somehow, you should apply for IANA assignment of an official OID. Note that I'm not encouraging nor discouraging you in this sense. p.

1 0

(ITS#6253) sizelimit is enforced before applying local filters with a translucent overlay
by isaac＠ebox-platform.com 13 Aug '09

13 Aug '09

Full_Name: Isaac Clerencia Version: 2.4.15 OS: Ubuntu URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (87.198.40.13) If a 'sizelimit' is required in a query to an LDAP server that uses a translucent overlay, and the filter has to be split between a remote filter and a local filter, and the remote filter returns more than 'sizelimit' objects, you will get a 'sizelimit' error even if the local filter would have filtered out enough objects to keep the number of objects under the sizelimit. In my case I have an LDAP holding basic posixAccount information plus a translucent holding Samba information. The following query: % ldapsearch -z 1 -x -s one -b 'ou=Users,dc=hq,dc=eboxhq,dc=com' -H 'ldap://127.0.0.1:1390' '(&(objectClass=posixAccount)(sambaSID=S-1-5-21-3818554400-921237426-3143208535-5004))' uid only matches one object in the LDAP directory, but it will fail because the remote LDAP will return every user and then the 'sizelimit' is immediately enforced before applying the local (sambaSID) filter. The result with -z 1 is: # search result search: 2 result: 4 Size limit exceeded # numResponses: 1 The result without the -z option is: # bar, Users, hq.eboxhq.com dn: uid=bar,ou=Users,dc=hq,dc=eboxhq,dc=com uid: bar # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 I think the 'sizelimit' should only be applied to the last set of results and not to the number of results in intermediate steps.

1 0

Re: (ITS#6140) nadf.schema: AttributeType not found: "lastModifiedTime"
by hyc＠symas.com 12 Aug '09

12 Aug '09

hyc(a)symas.com wrote: > So it seems the relevance of this schema to anything in use today is > about nil. > If you can find any current, active organizations with a currently maintained > spec for this schema, we can certainly update it. Otherwise, seems like we > should drop it. There is still an archive of the NADF documents here http://stats.dante.org.uk/nameflow/ds/nadf.html but again, the very difficulty in locating them tends to indicate that they're not in common use... -- -- Howard Chu CTO, 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#6140) nadf.schema: AttributeType not found: "lastModifiedTime"
by hyc＠symas.com 12 Aug '09

12 Aug '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: RE24 > OS: Linux > URL: > Submission from: (NULL) (84.163.124.107) > > > When including nadf.schema slapd does not start and prints error message: > > /opt/openldap-RE24/etc/openldap/schema/nadf.schema: line 111 objectclass: > AttributeType not found: "lastModifiedTime" > /etc/openldap/slapd.conf: line 17:<include> handler exited with 1! > > Analyzing this I found this commented declaration in cosine.schema: > > ## Deprecated in favor of modifyTimeStamp > #attributetype ( 0.9.2342.19200300.100.1.23 NAME 'lastModifiedTime' > # DESC 'RFC1274: time of last modify, replaced by modifyTimestamp' > # OBSOLETE > # SYNTAX 1.3.6.1.4.1.1466.115.121.1.53 > # USAGE directoryOperation ) > > So it seems nadf.schema is not usable at the moment. The comments in the file already state "intended to be used with QUIPU/X.500 and not LDAPv3". Not sure what the point is to maintaining this file any further, the NADF was absorbed by the EMA (Electronic Messaging Association) in 1996[1] and as far as I can see, the EMA has vanished from the web. (www.ema.org now directs to a porn directory here; apparently my network provider Time-Warner is hijacking NXDOMAINs...) [1] http://archive.dante.net/upload/pdf/NameFLOW_Report_1996_Q1.pdf page 31 The X.500 directory structure that the NADF was created to promote was superseded by the DNS-based directory hierarchy proposed in RFC2377 back in 1998. So it seems the relevance of this schema to anything in use today is about nil. If you can find any current, active organizations with a currently maintained spec for this schema, we can certainly update it. Otherwise, seems like we should drop it. -- -- Howard Chu CTO, 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#6251) GnuTLS cipher suite failure
by hyc＠symas.com 12 Aug '09

12 Aug '09

hyc(a)symas.com wrote: > In fact, the list must be colon separated, and the "+" is required. Just > listing the name will cause an error. Also, the actual suite names cannot be > used, only the individual algorithm names are recognized. So instead of the > suite name "TLS_RSA_AES_256_CBC_SHA1" you must specify "+AES-256-CBC:+SHA1". To be precise, you must specify "+RSA:+AES-256-CBC:+SHA1". > This method is more error-prone, because it makes it possible to specify a > list of algorithms that do not conform to any valid suite. > > All in all, it may be best to revert back to using our own suite parser and > ignore the one GnuTLS provides. -- -- Howard Chu CTO, 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#6252) GnuTLS subjectAltNames broken
by hyc＠symas.com 12 Aug '09

12 Aug '09

hyc(a)symas.com wrote: > The bug was reported against Ubuntu jaunty originally, and still exists in > current GnuTLS git. So it appears to affect at least 2.4.2-present. The fix is > trivial and is attached below. I will also submit this to the GnuTLS bug tracker. This is https://savannah.gnu.org/support/index.php?106975 -- -- Howard Chu CTO, 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#6252) GnuTLS subjectAltNames broken
by hyc＠symas.com 12 Aug '09

12 Aug '09

This is a multi-part message in MIME format. --------------060905090106040506040806 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > GnuTLS fails to parse certain subjectAltNames and returns spurious SHORT_BUFFER > error. > > We passed in a buffer size of 1025, and it's internally overwriting it with a > size of only 31 and then complaining that 31 is too small > The bug was reported against Ubuntu jaunty originally, and still exists in current GnuTLS git. So it appears to affect at least 2.4.2-present. The fix is trivial and is attached below. I will also submit this to the GnuTLS bug tracker. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------060905090106040506040806 Content-Type: text/x-patch; name="0001-Fix-XMPP-parsing.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="0001-Fix-XMPP-parsing.patch" >From 436824d8b8a908860688354841b4b082d4239157 Mon Sep 17 00:00:00 2001 From: Howard Chu <hyc(a)symas.com> Date: Wed, 12 Aug 2009 15:48:02 -0700 Subject: [PATCH] Fix XMPP parsing --- lib/x509/x509.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/lib/x509/x509.c b/lib/x509/x509.c index 048ff89..e15531e 100644 --- a/lib/x509/x509.c +++ b/lib/x509/x509.c @@ -1011,6 +1011,7 @@ _gnutls_parse_general_name (ASN1_TYPE src, const char *src_name, return _gnutls_asn2err (result); } + len = *name_size; result = asn1_read_value (c2, "", name, &len); *name_size = len; if (result != ASN1_SUCCESS) -- 1.6.3.rc3 --------------060905090106040506040806--

1 0

(ITS#6252) GnuTLS subjectAltNames broken
by quanah＠zimbra.com 12 Aug '09

12 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) GnuTLS fails to parse certain subjectAltNames and returns spurious SHORT_BUFFER error. We passed in a buffer size of 1025, and it's internally overwriting it with a size of only 31 and then complaining that 31 is too small

1 0

Re: (ITS#6251) GnuTLS cipher suite failure
by hyc＠symas.com 12 Aug '09

12 Aug '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541256 > > OpenLDAP+gnutls worked fine for me for more than a year, but now I have > TLS problems again. It started on my unstable client when libnss-ldap > reported: > > TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1 > > Then I upgraded gnutls and ldap on my server from lenny to unstable and > now even slapd doesn't start: > > TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1. > main: TLS init def ctx failed: -1 > > If I comment out line which defines cipher: > > TLSCipherSuite TLS_RSA_AES_256_CBC_SHA1 > > it works again. > > $ gnutls-cli -l|grep TLS_RSA_AES_256_CBC_SHA1 > TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL3.0 > > ...so I don't see why it shouldn't work. This appears to be caused by our switch to using GnuTLS's cipher suite parsing functions in 2.4.14 (due to ITS#5887). The syntax that GnuTLS uses is quite different from what we were using in 2.4.13 and earlier. Also, the GnuTLS documentation on their format is misleading and just plain wrong on several points. We can treat this as an OpenLDAP doc bug, or we can revert to the pre-ITS#5887 behavior, which still works as expected. (But then we will be incompatible with the behavior described in the current GnuTLS documentation. But of course, the doc is wrong anyway.) For reference, the GnuTLS doc says you can list suite names in a semicolon separated list, and they may optionally be prefixed with "+" or "-" to add or remove particular elements from the list. In fact, the list must be colon separated, and the "+" is required. Just listing the name will cause an error. Also, the actual suite names cannot be used, only the individual algorithm names are recognized. So instead of the suite name "TLS_RSA_AES_256_CBC_SHA1" you must specify "+AES-256-CBC:+SHA1". This method is more error-prone, because it makes it possible to specify a list of algorithms that do not conform to any valid suite. All in all, it may be best to revert back to using our own suite parser and ignore the one GnuTLS provides. -- -- Howard Chu CTO, 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#6215) liblber problems
by h.b.furuseth＠usit.uio.no 12 Aug '09

12 Aug '09

Kurt(a)OpenLDAP.org writes: >On Aug 7, 2009, at 11:16 AM, h.b.furuseth(a)usit.uio.no wrote: > >>> - decode.c is quite lax about what it accepts. Should we tighten >>> that when feasible, or remain "liberal in what we accept"? > > Decoding needs to be liberal here. Otherwise interoperability will > suffer as it is well established that there exists many > implementations which are not strict in what they send. OK. ITS done, then. -- Hallvard

1 0

(ITS#6247)
by daniel＠pluta.biz 12 Aug '09

12 Aug '09

Hi, I've just uploaded an updated version. Changes regarding schema: - Added EQ-Matching rule to both nowNot{Before|After} attributes - changed attribute nowNotAfter from single- into multi-value ftp://ftp.openldap.org/incoming/daniel-pluta-now-090812.tgz Best regards Daniel

1 0

(ITS#6251) GnuTLS cipher suite failure
by quanah＠zimbra.com 12 Aug '09

12 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Debian bug: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=541256 OpenLDAP+gnutls worked fine for me for more than a year, but now I have TLS problems again. It started on my unstable client when libnss-ldap reported: TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1 Then I upgraded gnutls and ldap on my server from lenny to unstable and now even slapd doesn't start: TLS: could not set cipher list TLS_RSA_AES_256_CBC_SHA1. main: TLS init def ctx failed: -1 If I comment out line which defines cipher: TLSCipherSuite TLS_RSA_AES_256_CBC_SHA1 it works again. $ gnutls-cli -l|grep TLS_RSA_AES_256_CBC_SHA1 TLS_RSA_AES_256_CBC_SHA1 0x00, 0x35 SSL3.0 ...so I don't see why it shouldn't work.

1 0

Re: (ITS#6248) Support multiple CA Cert directories
by hyc＠symas.com 11 Aug '09

11 Aug '09

quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.x > OS: NA > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) > > > Both openssl and gnutls support loading CA certs from multiple directories. It > would be handy to be able to do this for slapd and the ldap clients. For > example, zimbra puts its CA certs in /opt/zimbra/conf/ca, but the system it is > installed upon is going to have a different default destination for where its > ldap clients look for CA certs. By having support for the multiple paths, the > configuration can be adjusted to look in both the system location, and any > number of specialized ones. > In light of ITS#5582, this should probably wait until 2.5. I.e., we probably also want to require the OpenSSL default paths to be explicitly enabled when we allow multiple paths to be configured. E.g. we could allow "DEFAULT" to be a specially recognized token for enabling the default path. -- -- Howard Chu CTO, 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#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by Kurt＠OpenLDAP.org 11 Aug '09

11 Aug '09

RFC 3062 specifically says: This operation SHALL NOT be used anonymously. -- Kurt

1 0

Re: (ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by hyc＠symas.com 11 Aug '09

11 Aug '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> Michael Ströder wrote: >>> hyc(a)symas.com wrote: >>>> michael(a)stroeder.com wrote: >>>>> Full_Name: Michael Ströder >>>>> Version: HEAD >>>>> OS: >>>>> URL: >>>>> Submission from: (NULL) (84.163.50.194) >>>>> >>>>> I'd like to request that a Password Modify ext. op. request should succeed on a >>>>> LDAP connection as anonymous if the LDAP client provides the correct old >>>>> password. >>>>> >>>>> E.g. OpenDS implements it like this and it makes sense to me regarding a user >>>>> setting a new password in case of an expired password. >>>> Adding this feature would open up the pwdModify exop as a mechanism for >>>> password guessing attacks. >>> There could be still the bad password counter in effect just like when >>> processing bind requests. >> >> But there is no corresponding lockout action to take when a maxfailure limit >> is reached. I.e., it is impossible to lockout "anonymous". You thus open a >> security hole that cannot be closed. > > The password modify ext.op. request contains the DN (or username) of the entry > to which the old password belongs. > > Since the old password is really checked you could apply the lockout to the > entry for which the password is going to be changed. (It fails with Server is > "unwilling to perform: unwilling to verify old password." even if the user is > bound on that connection.) You're still not thinking this through. One of the basic principles of security design is to reduce the number of possible attack surfaces. You are deliberately opening up a new attack vector with no real benefit. Since grace logins are already supported, your proposal doesn't benefit any real users. It only benefits potential attackers. Closing this ITS. -- -- Howard Chu CTO, 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#6250) Password modify ext.op. - automagically add simpleSecurityObject
by hyc＠symas.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Let's assume the policy for a deployment is that password changes MUST be >>> applied by using password modify ext. op. (e.g. because smbk5pwd is >>> used or >>> similar) and you want to use object class 'account' for user entries. How >>> could the attribute 'userPassword' be added to the user entry then? >>> It's kind >>> of a dead-lock situation. >> >> Then you made a mistake in your data design. > > Nope. Since with a modify request I can achieve the goal by adding object > class 'simpleSecurityObject'. IMO password modify ext.op. should result in > userPassword being added. One could view it as a hen-and-egg problem because > 'simpleSecurityObject' is mandating 'userPassword'. Since the ppolicy overlay already provides the facility for hashing plaintext passwords on Add and Modify, there's no reason you couldn't have just created the objects correctly in the first place. >> You should have chosen an >> objectclass (or set of objectclasses) that supports authentication from >> the outset. To me this is analogous to the usual prohibition against >> changing an object's structural class - you cannot change a car into a >> pencil. You cannot change a non-user into a user. > > Please don't compare apples with pies. It was an analogy, not a literal comparison. Don't lose the main point, which is that changing a non-user into a user is a significant change in the purpose of an object. -- -- Howard Chu CTO, 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#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Howard Chu wrote: >> Michael Ströder wrote: >>> Let's assume the policy for a deployment is that password changes MUST be >>> applied by using password modify ext. op. (e.g. because smbk5pwd is >>> used or >>> similar) and you want to use object class 'account' for user entries. How >>> could the attribute 'userPassword' be added to the user entry then? >>> It's kind >>> of a dead-lock situation. >> Then you made a mistake in your data design. > > Nope. Since with a modify request I can achieve the goal by adding object > class 'simpleSecurityObject'. IMO password modify ext.op. should result in > userPassword being added. One could view it as a hen-and-egg problem because > 'simpleSecurityObject' is mandating 'userPassword'. I agree with Hallvard that this should be made configurable. So the admin could specify whether and which AUXILIARY object class is added. Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Howard Chu wrote: > Michael Ströder wrote: >> Let's assume the policy for a deployment is that password changes MUST be >> applied by using password modify ext. op. (e.g. because smbk5pwd is >> used or >> similar) and you want to use object class 'account' for user entries. How >> could the attribute 'userPassword' be added to the user entry then? >> It's kind >> of a dead-lock situation. > > Then you made a mistake in your data design. Nope. Since with a modify request I can achieve the goal by adding object class 'simpleSecurityObject'. IMO password modify ext.op. should result in userPassword being added. One could view it as a hen-and-egg problem because 'simpleSecurityObject' is mandating 'userPassword'. > You should have chosen an > objectclass (or set of objectclasses) that supports authentication from > the outset. To me this is analogous to the usual prohibition against > changing an object's structural class - you cannot change a car into a > pencil. You cannot change a non-user into a user. Please don't compare apples with pies. 'account' is STRUCTURAL so the user entry represents already a user. 'simpleSecurityObject' is AUXILIARY (not STRUCTURAL) which adds another attribute. The STRUCTURAL object class of the entry is not altered, so no magic change from a car into a pencil here. Ciao, Michael.

1 0

Re: (ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by michael＠stroeder.com 11 Aug '09

11 Aug '09

hyc(a)symas.com wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> michael(a)stroeder.com wrote: >>>> Full_Name: Michael Ströder >>>> Version: HEAD >>>> OS: >>>> URL: >>>> Submission from: (NULL) (84.163.50.194) >>>> >>>> I'd like to request that a Password Modify ext. op. request should succeed on a >>>> LDAP connection as anonymous if the LDAP client provides the correct old >>>> password. >>>> >>>> E.g. OpenDS implements it like this and it makes sense to me regarding a user >>>> setting a new password in case of an expired password. >>> Adding this feature would open up the pwdModify exop as a mechanism for >>> password guessing attacks. >> There could be still the bad password counter in effect just like when >> processing bind requests. > > But there is no corresponding lockout action to take when a maxfailure limit > is reached. I.e., it is impossible to lockout "anonymous". You thus open a > security hole that cannot be closed. The password modify ext.op. request contains the DN (or username) of the entry to which the old password belongs. Since the old password is really checked you could apply the lockout to the entry for which the password is going to be changed. (It fails with Server is "unwilling to perform: unwilling to verify old password." even if the user is bound on that connection.) Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by hyc＠symas.com 11 Aug '09

11 Aug '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: openSUSE Linux 11.1 >>> URL: >>> Submission from: (NULL) (84.163.50.194) >>> >>> >>> If one trys to set the userPassword with a Password Modify ext. op. request but >>> the object classes of the entry does not allow userPassword slapd could add >>> automagically AUXILIARY object class simpleSecurityObject to the entry. >>> >>> (I'm doing this in web2ldap since years when changing the userPassword with a >>> normal modify operation which client-side hashing.) >> >> This request sounds like a mistake to me. The DSA is supposed to enforce the >> data model, not automagically enable you to bypass the model. What clients do >> is a completely separate matter... > > Let's assume the policy for a deployment is that password changes MUST be > applied by using password modify ext. op. (e.g. because smbk5pwd is used or > similar) and you want to use object class 'account' for user entries. How > could the attribute 'userPassword' be added to the user entry then? It's kind > of a dead-lock situation. Then you made a mistake in your data design. You should have chosen an objectclass (or set of objectclasses) that supports authentication from the outset. To me this is analogous to the usual prohibition against changing an object's structural class - you cannot change a car into a pencil. You cannot change a non-user into a user. -- -- Howard Chu CTO, 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#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by hyc＠symas.com 11 Aug '09

11 Aug '09

Michael Ströder wrote: > hyc(a)symas.com wrote: >> michael(a)stroeder.com wrote: >>> Full_Name: Michael Ströder >>> Version: HEAD >>> OS: >>> URL: >>> Submission from: (NULL) (84.163.50.194) >>> >>> I'd like to request that a Password Modify ext. op. request should succeed on a >>> LDAP connection as anonymous if the LDAP client provides the correct old >>> password. >>> >>> E.g. OpenDS implements it like this and it makes sense to me regarding a user >>> setting a new password in case of an expired password. >> >> Adding this feature would open up the pwdModify exop as a mechanism for >> password guessing attacks. > > There could be still the bad password counter in effect just like when > processing bind requests. But there is no corresponding lockout action to take when a maxfailure limit is reached. I.e., it is impossible to lockout "anonymous". You thus open a security hole that cannot be closed. Again - No. -- -- Howard Chu CTO, 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#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: openSUSE Linux 11.1 >> URL: >> Submission from: (NULL) (84.163.50.194) >> >> >> If one trys to set the userPassword with a Password Modify ext. op. request but >> the object classes of the entry does not allow userPassword slapd could add >> automagically AUXILIARY object class simpleSecurityObject to the entry. >> >> (I'm doing this in web2ldap since years when changing the userPassword with a >> normal modify operation which client-side hashing.) > > This request sounds like a mistake to me. The DSA is supposed to enforce the > data model, not automagically enable you to bypass the model. What clients do > is a completely separate matter... Let's assume the policy for a deployment is that password changes MUST be applied by using password modify ext. op. (e.g. because smbk5pwd is used or similar) and you want to use object class 'account' for user entries. How could the attribute 'userPassword' be added to the user entry then? It's kind of a dead-lock situation. Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by h.b.furuseth＠usit.uio.no 11 Aug '09

11 Aug '09

Sorry, sent too early. > It makes sense if you add a config parameter with an LDAP URL or > something describing entries which can be so modified (subject to > ordinary access controls). I imagine one would typically filter for objectClass, e.g. ldap:///???(objectClass=person)

1 0

Re: (ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by michael＠stroeder.com 11 Aug '09

11 Aug '09

hyc(a)symas.com wrote: > michael(a)stroeder.com wrote: >> Full_Name: Michael Ströder >> Version: HEAD >> OS: >> URL: >> Submission from: (NULL) (84.163.50.194) >> >> I'd like to request that a Password Modify ext. op. request should succeed on a >> LDAP connection as anonymous if the LDAP client provides the correct old >> password. >> >> E.g. OpenDS implements it like this and it makes sense to me regarding a user >> setting a new password in case of an expired password. > > Adding this feature would open up the pwdModify exop as a mechanism for > password guessing attacks. There could be still the bad password counter in effect just like when processing bind requests. Ciao, Michael.

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by h.b.furuseth＠usit.uio.no 11 Aug '09

11 Aug '09

hyc(a)symas.com writes: > This request sounds like a mistake to me. The DSA is supposed to > enforce the data model, not automagically enable you to bypass the > model. What clients do is a completely separate matter... It makes sense if you add a config parameter with an LDAP URL or something describing entries which can be so modified (subject to ordinary access controls). -- Hallvard

1 0

Re: (ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by hyc＠symas.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: openSUSE Linux 11.1 > URL: > Submission from: (NULL) (84.163.50.194) > > > If one trys to set the userPassword with a Password Modify ext. op. request but > the object classes of the entry does not allow userPassword slapd could add > automagically AUXILIARY object class simpleSecurityObject to the entry. > > (I'm doing this in web2ldap since years when changing the userPassword with a > normal modify operation which client-side hashing.) This request sounds like a mistake to me. The DSA is supposed to enforce the data model, not automagically enable you to bypass the model. What clients do is a completely separate matter... -- -- Howard Chu CTO, 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#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by hyc＠symas.com 11 Aug '09

11 Aug '09

michael(a)stroeder.com wrote: > Full_Name: Michael Ströder > Version: HEAD > OS: > URL: > Submission from: (NULL) (84.163.50.194) > > > I'd like to request that a Password Modify ext. op. request should succeed on a > LDAP connection as anonymous if the LDAP client provides the correct old > password. > > E.g. OpenDS implements it like this and it makes sense to me regarding a user > setting a new password in case of an expired password. Adding this feature would open up the pwdModify exop as a mechanism for password guessing attacks. In fact, in the next draft of the ppolicy spec I was intending to explicitly forbid this type of usage, to prevent such attacks. http://www.openldap.org/lists/ietf-ldapext/200908/msg00006.html The ppolicy spec provides for grace logins after a password is expired, to give users a few last opportunities to change their password. If they don't take advantage of those grace logins, then they are out of luck and must get help from a password administrator. I'm going to reject this ITS. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6250) Password modify ext.op. - automagically add simpleSecurityObject
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: openSUSE Linux 11.1 URL: Submission from: (NULL) (84.163.50.194) If one trys to set the userPassword with a Password Modify ext. op. request but the object classes of the entry does not allow userPassword slapd could add automagically AUXILIARY object class simpleSecurityObject to the entry. (I'm doing this in web2ldap since years when changing the userPassword with a normal modify operation which client-side hashing.)

1 0

(ITS#6249) Feature request: Password Modify ext. op. and anonymous LDAP connection
by michael＠stroeder.com 11 Aug '09

11 Aug '09

Full_Name: Michael Ströder Version: HEAD OS: URL: Submission from: (NULL) (84.163.50.194) I'd like to request that a Password Modify ext. op. request should succeed on a LDAP connection as anonymous if the LDAP client provides the correct old password. E.g. OpenDS implements it like this and it makes sense to me regarding a user setting a new password in case of an expired password.

1 0

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2
by Ed＠vanGasteren.net 11 Aug '09

11 Aug '09

On 08/11/2009 04:44 AM, Howard Chu wrote: > Ed(a)vanGasteren.net wrote: >> Full_Name: Ed van Gasteren >> Version: 2.4.12 and 2.4.15 >> OS: linux (Fedora 10, 11) >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (85.223.76.221) >> >> >> On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server >> and clients. >> The configuration is such that things work as expected even with security >> tightened up to "TLSVerifyClient demand". ldapsearch (either to -H >> ldaps or with >> -ZZ), nss and gq with TLS work like a charm. >> >> On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), >> gq and >> Thunderbird connecting to the server on lt2. TLS/SSL only works if I >> run slapd >> with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS >> trace: >> SSL_connect:SSLv3 read server certificate A". >> >> Seems as if the normal code path has a flaw which gets >> corrected/bypassed by the >> debugging code. > > Doesn't sound familiar, I've never had this problem. However, the TLS > code was refactored in rev 2.4.14, and it's always possible we missed > something in the churn. How does openssl s_client react under the same > conditions? If it hangs the same way, then that points to a bug on the Should have mentioned that. It indeed hangs the same way, in the middle of getting over the "Acceptable client certificate CA names". The last debug info from s_client suggests it is getting less of the list then in expects: read from 0x8c13300 [0x8c19915] (16384 bytes => 10395 The last one coming across correctly is: /C=US/O=VeriSign, Inc./OU=Class 4 Public Primary Certification Authority - G2/OU=(c) 1998 VeriSign, Inc. - For authorized use only/OU=VeriSign Trust Network The one not coming is: /L=ValiCert Validation Network/O=ValiCert, Inc./OU=ValiCert Class 1 Policy Validation Authority/CN=http://www.valicert.com//emailAddress=info@valicert.com > server, and the answer is just to upgrade since .12 is rather out of Hm! I'll see if I can get the 2.4.15 openldap stuff from Fedora 11 repo's running on lt2 first. > date now. If s_client works, then we probably have to look at our client > code. >

1 0

(ITS#6248) Support multiple CA Cert directories
by quanah＠zimbra.com 10 Aug '09

10 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.x OS: NA URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) Both openssl and gnutls support loading CA certs from multiple directories. It would be handy to be able to do this for slapd and the ldap clients. For example, zimbra puts its CA certs in /opt/zimbra/conf/ca, but the system it is installed upon is going to have a different default destination for where its ldap clients look for CA certs. By having support for the multiple paths, the configuration can be adjusted to look in both the system location, and any number of specialized ones.

1 0

Re: (ITS#6246) SSL fails over a network unless slapd runs with -d 2
by hyc＠symas.com 10 Aug '09

10 Aug '09

Ed(a)vanGasteren.net wrote: > Full_Name: Ed van Gasteren > Version: 2.4.12 and 2.4.15 > OS: linux (Fedora 10, 11) > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (85.223.76.221) > > > On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server and clients. > The configuration is such that things work as expected even with security > tightened up to "TLSVerifyClient demand". ldapsearch (either to -H ldaps or with > -ZZ), nss and gq with TLS work like a charm. > > On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), gq and > Thunderbird connecting to the server on lt2. TLS/SSL only works if I run slapd > with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS trace: > SSL_connect:SSLv3 read server certificate A". > > Seems as if the normal code path has a flaw which gets corrected/bypassed by the > debugging code. Doesn't sound familiar, I've never had this problem. However, the TLS code was refactored in rev 2.4.14, and it's always possible we missed something in the churn. How does openssl s_client react under the same conditions? If it hangs the same way, then that points to a bug on the server, and the answer is just to upgrade since .12 is rather out of date now. If s_client works, then we probably have to look at our client code. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#6247) slapd-modules/now: New matching rules that enable comparisone slapd's current server time against timestamp attributes
by daniel＠pluta.biz 10 Aug '09

10 Aug '09

Full_Name: Daniel Pluta Version: CVS OS: Linux URL: ftp://ftp.openldap.org/incoming/daniel-pluta-now-090810.tgz Submission from: (NULL) (91.12.197.171) Please see the README for details. Currently only a DUMMY_OID is assigned to the matching rules and the limited internal attribute and objectclass definitions. I would appreciate your feedback. Thanks!

1 0

(ITS#6246) SSL fails over a network unless slapd runs with -d 2
by Ed＠vanGasteren.net 10 Aug '09

10 Aug '09

Full_Name: Ed van Gasteren Version: 2.4.12 and 2.4.15 OS: linux (Fedora 10, 11) URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (85.223.76.221) On system lt2 (up to date Fedora 10) I run openldap (2.4.12) server and clients. The configuration is such that things work as expected even with security tightened up to "TLSVerifyClient demand". ldapsearch (either to -H ldaps or with -ZZ), nss and gq with TLS work like a charm. On system lt1 (up to date Fedora 11) I run openldap clients (2.4.15), gq and Thunderbird connecting to the server on lt2. TLS/SSL only works if I run slapd with "-d 2". If I run slapd without it then ldapsearch hangs on "TLS trace: SSL_connect:SSLv3 read server certificate A". Seems as if the normal code path has a flaw which gets corrected/bypassed by the debugging code. What puzzels me is that I find few references (google) to these kind of problems as if nobody uses it this way. - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=412706 There they blame it on GnuTLS. Here the symptoms are similar but GnuTLS is not in the picture. - I have searched the openldap Mailing Lists archives for "ssl;client;server;-d 2". That gives a few hits with very similar problems but the threads provide no solution. I can provide loads of additional detail about my configuration and debug output of the server and the ldapsearch client but I prefer to get some pointers about what to test, look for or provide.

1 0

RE: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST
by evaristo-jose.camarero＠ericsson.com 10 Aug '09

10 Aug '09

=20 It looks that I sent an email that was unreadable. Sorry for that. I recap the content: The traffic model we are testing contains search and modify operations. = The search response contains usually a single entry about 3KB in LDIF = format. There is only a reduce number of LDAP clients (usually one or = two), that are using async LDAP API and sending a lot of operations per = second (> 1000 TPS per client). The client side is an OS Delta box. Under these conditions we have tested that increasing the sending buffer = of the server has improved the performance. That's the reason I am = proposing this feature request. Pierangelo's proposal allowing hard-set the buffer sizes looks ok. Regards, Evaristo ----- Mensaje reenviado ---- De: Pierangelo Masarati <masarati(a)aero.polimi.it> Para: evaristojosec(a)yahoo.es CC: openldap-its(a)openldap.org Enviado: martes, 4 de agosto, 2009 9:54:19 Asunto: Re: (ITS#6234) CONFIGURABLE TCP BUFFERS IN SLAPD FEATURE REQUEST Your message was unreadable, you should use text form for messages sent = to the ITS. In any case, according to many sources, the default values for TCP = buffers can be pretty small. Usually, they can be configured = system-wide at the OS level (see tcp(7)), or even auto-tuned. Personally, I have no objections in optionally allowing to hard-set the = buffer sizes to values one considers appropriate for the intended use of = slapd. Since the optimal size roughly depends on latency and bandwidth, = this may probably need to be configured on a per-listener basis, = actually. However, in deployments where this problem becomes critical, usually = hardware dedicated to slapd is used, so system-wide tuning (and = auto-tuning) would be the preferred option anyway. Manual setting = should be used only when system-wide or auto-tuning is not available or = accessible for some reason. p. =20

1 0

Re: (ITS#6245) back-config allows empty add operation
by quanah＠zimbra.com 08 Aug '09

08 Aug '09

--On Saturday, August 08, 2009 10:07 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.111.29.239) I guess they may be liberally legal.. It also updates the contextCSN and the accesslog database. dn: reqStart=20090808223406.000005Z,cn=accesslog objectClass: auditModify reqStart: 20090808223406.000005Z reqEnd: 20090808223409.000000Z reqType: modify reqSession: 214 reqAuthzID: cn=config reqDN: cn=zimbra reqResult: 0 reqMod: entryCSN:= 20090808223406.630393Z#000000#000#000000 reqMod: modifiersName:= cn=config reqMod: modifyTimestamp:= 20090808223406Z Seems janky to me. :P --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#6245) back-config allows empty add operation
by quanah＠zimbra.com 08 Aug '09

08 Aug '09

Full_Name: Quanah Gibson-Mount Version: 2.4.17 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.111.29.239) [zimbra@freelancer ~]$ ldapmodify -x -H ldapi:/// -D cn=config -W Enter LDAP Password: dn: olcDatabase={2}hdb,cn=config changetype:modify add: modifying entry "olcDatabase={2}hdb,cn=config" dn: olcDatabase={2}hdb,cn=config changetype:modify add: modifying entry "olcDatabase={2}hdb,cn=config" Log shows it happening, too: Aug 8 15:08:50 freelancer slapd[1937]: conn=16 fd=23 ACCEPT from PATH=/opt/zimbra/openldap-2.4.17.8z/var/run/ldapi (PATH=/opt/zimbra/openldap-2.4.17.8z/var/run/ldapi) Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 BIND dn="cn=config" method=128 Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 BIND dn="cn=config" mech=SIMPLE ssf=0 Aug 8 15:08:50 freelancer slapd[1937]: conn=16 op=0 RESULT tag=97 err=0 text= Aug 8 15:08:52 freelancer slapd[1937]: conn=16 op=1 MOD dn="olcDatabase={2}hdb,cn=config" Aug 8 15:08:52 freelancer slapd[1937]: conn=16 op=1 RESULT tag=103 err=0 text= Aug 8 15:08:56 freelancer slapd[1937]: conn=16 op=2 MOD dn="olcDatabase={2}hdb,cn=config" Aug 8 15:08:56 freelancer slapd[1937]: conn=16 op=2 RESULT tag=103 err=0 text= Aug 8 15:09:33 freelancer slapd[1937]: conn=16 fd=23 closed (connection lost)

1 0

Re: (ITS#6215) liblber problems
by Kurt＠OpenLDAP.org 07 Aug '09

07 Aug '09

On Aug 7, 2009, at 11:16 AM, h.b.furuseth(a)usit.uio.no wrote: >> - decode.c is quite lax about what it accepts. Should we tighten >> that when feasible, or remain "liberal in what we accept"? Decoding needs to be liberal here. Otherwise interoperability will suffer as it is well established that there exists many implementations which are not strict in what they send. -- Kurt

1 0

Re: (ITS#6215) liblber problems
by h.b.furuseth＠usit.uio.no 07 Aug '09

07 Aug '09

Fixed the above, including malformed bitstrings and set/sequences. Except: Need decision on decode(bad INTEGER/BOOLEAN) and encode(bad tag): > - decode.c is quite lax about what it accepts. Should we tighten > that when feasible, or remain "liberal in what we accept"? > > E.g. it accepts BER INTEGER length 0 and BOOLEAN length != 1, and > wrong CONSTRUCTED/PRIMITIVE encoding bit. > > - encode.c willingly stores broken identifier octets if passed an > invalid tag, e.g. a single octet with low bits 0x1F implying long tag > format. I'm inclined to leave that alone, caller's responsibility. API matters: I'll export the new function ber_peek_element(). And if nobody disagrees, the matching function ber_skip_element() even though that is nearly a duplicate of ber_get_stringbv(,, LBER_BV_NOTERM). -- Hallvard

1 0

Re: (ITS#6227) autogroup overlay breaks all searches
by ryans＠aweber.com 07 Aug '09

07 Aug '09

I can confirm that the segfault on slapadd, slapcat, and friends were in fact a result of this bug. I don't have the strace handy which confirmed it, but after applying Howard's patch and repackaging the .deb (Ubuntu Jaunty), I see none of the aforementioned segfaults. Regards, Ryan -- Ryan Steele ryans-at-aweber-dot-com Systems Administrator +1 215-825-2196 x758 AWeber Communications http://www.aweber.com

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 06 Aug '09

06 Aug '09

masarati(a)aero.polimi.it wrote: >> http://purgatory.spnet.net/~karavelov/faillog >> > > There is no corruption. What happens is that back-bdb, when returning the > entry from the cache, correctly locates it based on the indexed attrs used > in the filter, but at some point decides that the entry is outside the > scope of your search: > I think it is corruption because when such a fail appears it is not cleaned by slapd restart - after starting it continues to give wrong answers. The fail cleans after deleting the cache between slapd stop and start. Luben

1 0

Re: (ITS#6242) PCache cache corruption
by karavelov＠spnet.net 06 Aug '09

06 Aug '09

masarati(a)aero.polimi.it wrote: >> http://purgatory.spnet.net/~karavelov/faillog >> > > There is no corruption. What happens is that back-bdb, when returning the > entry from the cache, correctly locates it based on the indexed attrs used > in the filter, but at some point decides that the entry is outside the > scope of your search: > > Aug 5 16:44:22 work slapd[17541]: bdb_search: 87 scope not okay > > This should not happen, since your search is performed with exactly the > same parameters used for the original one, and the scope is 1 (onelevel). > > I wonder what happens there. Could you walk through the failing request > with a debugger, and print some values? I'd like to see, from within > bdb_search(), line 780 of back-bdb/search.c of re23, the value of > > op->o_request->oq_search > > base > > *ei->ei_parent > > p. > > OK, I will try to attach a debugger when it happens. Next time I will also copy the BDB database and dump it in order to see the failing record. Luben

1 0

Re: (ITS#6242) PCache cache corruption
by masarati＠aero.polimi.it 06 Aug '09

06 Aug '09

> http://purgatory.spnet.net/~karavelov/faillog There is no corruption. What happens is that back-bdb, when returning the entry from the cache, correctly locates it based on the indexed attrs used in the filter, but at some point decides that the entry is outside the scope of your search: Aug 5 16:44:22 work slapd[17541]: bdb_search: 87 scope not okay This should not happen, since your search is performed with exactly the same parameters used for the original one, and the scope is 1 (onelevel). I wonder what happens there. Could you walk through the failing request with a debugger, and print some values? I'd like to see, from within bdb_search(), line 780 of back-bdb/search.c of re23, the value of op->o_request->oq_search base *ei->ei_parent p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 06 Aug '09

06 Aug '09

--On August 6, 2009 7:25:16 PM +0200 masarati(a)aero.polimi.it wrote: >> I'm also curious why back-monitor develops stats for the other caches but >> specifically not for entry cache. > > I haven't looked in detail, but it makes sense that some operation occurs > within the glue database which requires caching something, but not > entries. > > - The entry cache monitor shows the value of bdb->bi_cache.c_cursize; > > - the DN cache monitor shows the value of bdb->bi_cache.c_eiused, which > should be the number of entryinfo structures used; > > - the IDL cache monitor shows the value of bdb->bi_idl_cache_size. > > In my very simple tests, I only saw something populating the DN cache, > which means some internal operation required to allocate some entryinfo > structures that remain 'round. > > In any case, it's only showing information related to its database > structure, it is by no means collecting info from the glued databases. Ok, this makes sense, as the numbers it was reporting definitely seemed smaller than I was expecting. I bet they are for pieces in the rootDSE. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by masarati＠aero.polimi.it 06 Aug '09

06 Aug '09

> > > --On August 5, 2009 7:17:43 PM +0000 masarati(a)aero.polimi.it wrote: > >>> This may be specific to glued databases (databases rooted at ""). >> >> The problem could be partially addressed by telling back-bdb (who's >> maintaining this data in the monitor backend) to check subordinates as >> soon as it discovers it's a glue instance. However, this poses two >> different problems: >> >> - is the aggregate information resulting from adding all glued databases >> cache usage still useful? >> >> - what happens if heterogeneous databases are glued? Significantly, >> what >> if the superior database is not bdb/hdb? >> >> Probably, the monitor database should also present subordinate databases >> as separate entries. > > Interestingly, in my case, there's only one real database in play for the > glue as it is, since it's rooted at "". All other database definitions > come before it (cn=config, cn=accesslog, cn=monitor). but... are you actually gluing something? In any case, this is not specific to the case of empty suffix in the glue database. I could easily reproduce it with a "normal" glued setup, and I was about to start fixing things when the two above questions came to my mind. > I'm also curious why back-monitor develops stats for the other caches but > specifically not for entry cache. I haven't looked in detail, but it makes sense that some operation occurs within the glue database which requires caching something, but not entries. - The entry cache monitor shows the value of bdb->bi_cache.c_cursize; - the DN cache monitor shows the value of bdb->bi_cache.c_eiused, which should be the number of entryinfo structures used; - the IDL cache monitor shows the value of bdb->bi_idl_cache_size. In my very simple tests, I only saw something populating the DN cache, which means some internal operation required to allocate some entryinfo structures that remain 'round. In any case, it's only showing information related to its database structure, it is by no means collecting info from the glued databases. p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 06 Aug '09

06 Aug '09

--On August 5, 2009 7:17:43 PM +0000 masarati(a)aero.polimi.it wrote: >> This may be specific to glued databases (databases rooted at ""). > > The problem could be partially addressed by telling back-bdb (who's > maintaining this data in the monitor backend) to check subordinates as > soon as it discovers it's a glue instance. However, this poses two > different problems: > > - is the aggregate information resulting from adding all glued databases > cache usage still useful? > > - what happens if heterogeneous databases are glued? Significantly, what > if the superior database is not bdb/hdb? > > Probably, the monitor database should also present subordinate databases > as separate entries. Interestingly, in my case, there's only one real database in play for the glue as it is, since it's rooted at "". All other database definitions come before it (cn=config, cn=accesslog, cn=monitor). I'm also curious why back-monitor develops stats for the other caches but specifically not for entry cache. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 06 Aug '09

06 Aug '09

masarati(a)aero.polimi.it wrote: >> Here are slapd.conf and proxycache.conf as attachments. > > I just wanted to feed back before I leave for a few days. I don't see > anything critical in your files. You explicitly give the rootdn write > permissions, which is useless, but apart from this everything looks fine. > > I've tested a simple setup and it works as expected. I used HEAD and re24 > code; the latter is nearly identical to 2.4.17. I also tested with TLS. > > At this point, I'm a bit clueless. There must be something we're > overlooking. > > p. > Here is some more info, that I just discovered. If my filter rule is '(&(objectClass=sambaSamAccount)(uid=wvk))' the data is cached the first time, but not returned the second and later time. However when my filter rule is (&(objectClass=posixAccount)(uid=wvk))' it works as expected. Jim

1 0

Re: (ITS#6217) proxycache not returning cached data
by masarati＠aero.polimi.it 06 Aug '09

06 Aug '09

> Here are slapd.conf and proxycache.conf as attachments. I just wanted to feed back before I leave for a few days. I don't see anything critical in your files. You explicitly give the rootdn write permissions, which is useless, but apart from this everything looks fine. I've tested a simple setup and it works as expected. I used HEAD and re24 code; the latter is nearly identical to 2.4.17. I also tested with TLS. At this point, I'm a bit clueless. There must be something we're overlooking. p.

1 0

Re: (ITS#6217) proxycache not returning cached data
by w.van.keulen＠few.vu.nl 06 Aug '09

06 Aug '09

This is a multi-part message in MIME format. --------------050103000202040305030502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit masarati(a)aero.polimi.it wrote: > > This tells us you have some ACLs in place. Could you show them? > Actually, could you post your whole slapd.conf, if you're using any, or > the contents of your cn=config database? Of course, after removing any > sensitive information, like passwords. > > p. > Here are slapd.conf and proxycache.conf as attachments. regards, Jim vK --------------050103000202040305030502 Content-Type: text/plain; name="slapd.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="slapd.conf" # oOpenLDAP: pkg/ldap/servers/slapd/slapd.conf,v 1.23.2.5 2002/11/26 18:26:01 kurt Exp $tdn # # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/opt/openldap/schema/DUAConfig.schema include /etc/opt/openldap/schema/misc.schema include /etc/opt/openldap/schema/core.schema include /etc/opt/openldap/schema/cosine.schema include /etc/opt/openldap/schema/inetorgperson.schema include /etc/opt/openldap/schema/solaris-nis.schema include /etc/opt/openldap/schema/solaris.schema include /etc/opt/openldap/schema/samba.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://feathercraft.few.vu.nl logfile /var/log/openldap threads 8 pidfile /var/opt/openldap/slapd.pid argsfile /var/opt/openldap/slapd.args # Load dynamic backend modules: modulepath /opt/openldap/openldap-2.4.16/libexec/openldap moduleload back_bdb.la moduleload back_ldap.la #moduleload back_ldbm.la # # Sample security restrictions # # Disallow clear text exchange of passwords #disallow bind_simple_unprotected # # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind # security ssf=1 update_ssf=112 simple_bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy is: # Allow read by all # # rootdn can always write! gentlehup on #TLSCipherSuite ALL:!EXP:!LOW:!ADH:@STRENGTH #TLSCACertificateFile /usr/local/ssl/certs/few-ca-cert.pem #TLSCACertificatePath /usr/local/ssl/certs #TLSCertificateFile /usr/local/ssl/certs/flits.few.vu.nl-cert.pem #TLSCertificateKeyFile /etc/opt/openldap/private/flits.few.vu.nl-key.rsa #TLSVerifyClient never ####################################################################### # ldbm database definitions ####################################################################### database config rootdn "uid=Admin,cn=config" rootpw * access to dn.subtree="cn=config" by dn.exact="uid=Admin,cn=config" write by * read database monitor rootdn "uid=Admin,cn=Monitor" rootpw * access to dn.subtree="cn=Monitor" by dn.exact="uid=Admin,cn=Monitor" write by * read include /etc/opt/openldap/proxycache.conf --------------050103000202040305030502 Content-Type: text/plain; name="proxycache.conf" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="proxycache.conf" database ldap suffix "dc=few,dc=vu,dc=nl" rootdn cn=Manager,dc=few,dc=vu,dc=nl rootpw * tls start uri ldap://klondike.few.vu.nl acl-bind bindmethod=simple binddn="cn=sambaLdapManager,ou=Special Users,dc=few,dc=vu,dc=nl" credentials=* sizelimit unlimited #loglevel 4095 overlay pcache proxycache bdb 100000 10 1000 100 proxyAttrset 0 uid cn proxyTemplate (&(objectClass=)(uid=)) 0 1800 proxyTemplate (&(uid=)(objectClass=)) 0 1800 cachesize 10000 directory /var/opt/openldap/openldap-data/proxy access to * by * read ## required to support pdb_getsampwnam ## required to support pdb_getsambapwrid() ## uncomment these if you are storing posixAccount and ## posixGroup entries in the directory as well ### required by OpenLDAP index objectclass eq index cn pres,sub,eq index sn pres,sub,eq ### required to support pdb_getsampwnam index uid pres,sub,eq ### required to support pdb_getsambapwrid() index displayName pres,sub,eq ### uncomment these if you are storing posixAccount and ### posixGroup entries in the directory as well index uidNumber eq index gidNumber eq index memberUid eq index sambaSid eq index sambaPrimaryGroupSID eq index sambaDomainName eq index queryId eq index default sub --------------050103000202040305030502--

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by masarati＠aero.polimi.it 05 Aug '09

05 Aug '09

> This may be specific to glued databases (databases rooted at ""). The problem could be partially addressed by telling back-bdb (who's maintaining this data in the monitor backend) to check subordinates as soon as it discovers it's a glue instance. However, this poses two different problems: - is the aggregate information resulting from adding all glued databases cache usage still useful? - what happens if heterogeneous databases are glued? Significantly, what if the superior database is not bdb/hdb? Probably, the monitor database should also present subordinate databases as separate entries. p.

1 0

(ITS#6244) "now" dynacl module
by masarati＠aero.polimi.it 05 Aug '09

05 Aug '09

Full_Name: Pierangelo Masarati Version: re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/pierangelo-masarati-2009-08-05.1.c Submission from: (NULL) (93.149.38.247) Submitted by: ando This simple module implements a dynacl that allows to compare a given generalizedTime-valued attribute with "now", according to generalizedTimeOrderingMatch (greater-or-equal, less-or-equal). p.

1 0

Re: (ITS#6243) back-monitor fails to report entry cache usage
by quanah＠zimbra.com 05 Aug '09

05 Aug '09

--On August 5, 2009 5:35:57 PM +0000 quanah(a)zimbra.com wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.17 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (69.235.224.133) > > > Querying back monitor to examine the values of the various caches reports > the entry cache as empty: > ># Frontend, Databases, Monitor > dn: cn=Frontend,cn=Databases,cn=Monitor > structuralObjectClass: monitoredObject > creatorsName: cn=config > modifiersName: cn=config > createTimestamp: 20090805044038Z > modifyTimestamp: 20090805044038Z > monitoredInfo: frontend > monitorIsShadow: FALSE > namingContexts: > readOnly: FALSE > olmBDBEntryCache: 0 > olmBDBDNCache: 592 > olmBDBIDLCache: 502 > olmDbDirectory: /opt/zimbra/data/ldap/hdb/db/ > entryDN: cn=Frontend,cn=Databases,cn=Monitor > subschemaSubentry: cn=Subschema > hasSubordinates: FALSE This may be specific to glued databases (databases rooted at ""). I see that it's reporting the caches as under the Frontend database, instead of the actual BDB database, which is database 3, and shows no cache information: # Database 3, Databases, Monitor dn: cn=Database 3,cn=Databases,cn=Monitor structuralObjectClass: monitoredObject creatorsName: cn=config modifiersName: cn=config createTimestamp: 20090805044038Z modifyTimestamp: 20090805044038Z monitoredInfo: hdb monitorIsShadow: FALSE namingContexts: readOnly: FALSE monitorOverlay: accesslog monitorOverlay: syncprov entryDN: cn=Database 3,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE I see the same behavior on the replica, where it is Database 2 instead of database 3, as it has no accesslog DB. On the master, the accesslog DB caches are correct: # Database 2, Databases, Monitor dn: cn=Database 2,cn=Databases,cn=Monitor structuralObjectClass: monitoredObject creatorsName: cn=config modifiersName: cn=config createTimestamp: 20090805044038Z modifyTimestamp: 20090805044038Z monitoredInfo: hdb monitorIsShadow: FALSE namingContexts: cn=accesslog readOnly: FALSE monitorOverlay: syncprov olmBDBEntryCache: 297 olmBDBDNCache: 517 olmBDBIDLCache: 9 olmDbDirectory: /opt/zimbra/data/ldap/accesslog/db/ entryDN: cn=Database 2,cn=Databases,cn=Monitor subschemaSubentry: cn=Subschema hasSubordinates: TRUE --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs