openldap-bugs

openldap-bugs@openldap.org

1 participants
20960 discussions

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 18 Aug '09

18 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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs