openldap-bugs

openldap-bugs@openldap.org

1 participants
20967 discussions

Re: (ITS#6700) memberOf overlay does not handle MODRDN correctly
by raphael.ouazana＠linagora.com 03 Jan '11

03 Jan '11

Le Sam 1 janvier 2011 19:37, masarati(a)aero.polimi.it a écrit : >> raphael.ouazana(a)linagora.com wrote: >> >>> When using memberOf overlay, a MODRDN request on a member does not >>> update >>> correctly the matching group, even if the memberof-refint option is set >>> to >>> true. >>> >>> In my little understanding, memberof_value_modify calls >>> op->o_bd->be_modify >>> which calls back the overlay code, and finally never reach the backend. >> >> Guess what, modrdn is the only operation test052 does not check :( >> WOrking at it. Thanks, p. > > Fixed in HEAD; please test and report. Please note that test052 and the > corresponding expected output data have been modified to check modrdn. Thank you very much. Tested r1.33->r1.34, and this works fine, great! Regards, Raphaël Ouazana.

1 0

Re: (ITS#6684)
by norbert＠pueschel.net 03 Jan '11

03 Jan '11

Am 30.12.10 18:28, schrieb Howard Chu: > norbert(a)pueschel.net wrote: >> Updated TAR-file with (hopefully) sufficient copyright notice... >> >> http://www.pueschel.net/openldap/norbert-pueschel-autogroup-27102010.tar > > Your code does a string compare againset "memberOf" to detect those > filter references. > 1) it should simply be comparing the AttributeDescription pointers > 2) since the "memberof" attribute is actually configurable in the > memberof overlay, there's no guarantee that this is the correct > attribute to be looking for. It should also be configurable in your > patch. > You are right, of course. The problem is, I do not understand enough of internal structures to find the correct pointer... I would need to detect the memberof-overlay and find the correct string or pointer to compare to. I will gladly do so if you can give me some hints where to look. > You're using strcasecmp, but your inputs are already normalized > values. You should just use ber_bvcmp. > Right, see above. > Replying to the original: > >> 1) Using non-DN-valued URIs for autogroup does not work correctly, even >> with the latest version from HEAD. Especially changing group member is >> not tracked. > > I don't see why this should ever work or be supported. LDAP groups > list DNs. > Wrong. If you really think so, why did you accept Raphael Ouazana's patch, which is all about making this case work? Also see below. >> 2) Using the memberOf-overlay for constructing autogroups does not work > > I don't see any reason why this should work. The memberof overlay is > not used to construct groups, it is only used to report on group > memberships that have already been defined. Well, consider the following construction (which I am using in our ldap directory and which is the reason I started work on the autogroup overlay): dn: cn=admins,ou=access,dc=networker-gmbh,dc=de objectClass: groupOfNames cn: admins member: uid=xxxxx,ou=people,dc=networker-gmbh,dc=de member: uid=yyyyyy,ou=people,dc=networker-gmbh,dc=de dn: cn=admins(a)networker-gmbh.de,ou=aliases,dc=networker-gmbh,dc=de objectClass: nisMailAlias objectClass: labeledURIObject cn: admins(a)networker-gmbh.de labeledURI: ldap:///ou=people,dc=networker-gmbh,dc=de?mail?one?(&(objectClass=inetOrgPerson)(memberOf=cn=admins,ou=access,dc=networker-gmbh,dc=de)) dn: cn=admins,ou=groups,dc=networker-gmbh,dc=de objectClass: posixGroup objectClass: labeledURIObject cn: admins gidNumber: 10100 labeledURI: ldap:///ou=people,dc=networker-gmbh,dc=de?uid?one?(&(objectClass=posixAccount)(memberOf=cn=admins,ou=access,dc=networker-gmbh,dc=de)) Additionally, consider this relevant excerpt from slapd.conf: overlay dynlist dynlist-attrset groupOfNames labeledURI member dynlist-attrset nisMailAlias labeledURI rfc822MailMember:mail overlay autogroup autogroup-attrset posixGroup labeledURI memberUid As you can see, I use memberOf the construct mail aliases and posix group memberships from a groupOfNames master-list. For the mail aliases, dyngroup is sufficient, but the posix groups also need reverse lookups, which is why I'm using the autogroup overlay for this. Also, I cannot use a dn-valued list for the posix groups, as the Solaris NSS-libraries require the uid attribute to not contain a full dn.

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by B.Candler＠pobox.com 03 Jan '11

03 Jan '11

On Sun, Jan 02, 2011 at 07:40:25PM -0800, Howard Chu wrote: > >(1) Stick more or less with the current behaviour, and change the > >documentation to say that you'll get > > uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth > >for foreign realms. > > > >However, the odd thing about the current behaviour is that setting > >olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into > >the auth DN, regardless of whether it's local or foreign. That's not very > >useful. > > Note that it's not the OpenLDAP code that's sticking this in there; > it's the Cyrus code that's returning this realm in the callback. IMO > our job is to faithfully return what the Cyrus library gave us. The Cyrus library is faithfully passing on the *default* user_realm that you originally passed to sasl_server_new() in servers/slapd/sasl.c (which is global_realm, a.k.a. olcSaslRealm) Then OpenLDAP is sticking it into the authDN, in slap_sasl_getdn() > >I think it would make more sense, if olcSaslRealm is present, to use it to > >*qualify* usernames which don't have a realm. > > That decision is made by the Cyrus library, not us. It does not mandate what you do with the user_realm. You are free to ignore it, use it to qualify usernames which have no realm, or whatever. The documentation for canon_user (in include/sasl.h) says: * If user_realm is non-empty and an * unqualified user name is supplied, then the canon_user facility is * expected to append "@" and user_realm to the user name. The canon_user * facility may treat other characters such as "%" as equivalent to "@". Here is _canonuser_internal from lib/canonusr.c in Cyrus SASL: static int _canonuser_internal(const sasl_utils_t *utils, const char *user, unsigned ulen, unsigned flags __attribute__((unused)), char *out_user, unsigned out_umax, unsigned *out_ulen) ... /* Need to append realm if necessary (see sasl.h) */ if(sconn && sconn->user_realm && !strchr(user, '@')) { u_apprealm = (unsigned) strlen(sconn->user_realm) + 1; } /* Now Copy */ memcpy(out_user, begin_u, MIN(ulen, out_umax)); if(sconn && u_apprealm) { if(ulen >= out_umax) return SASL_BUFOVER; out_user[ulen] = '@'; memcpy(&(out_user[ulen+1]), sconn->user_realm, MIN(u_apprealm-1, out_umax-ulen-1)); } out_user[MIN(ulen + u_apprealm,out_umax)] = '\0'; > >(2) Change the OpenLDAP behaviour so that it matches the documentation at > >http://www.openldap.org/doc/admin24/sasl.html#GSSAPI > > > >To do this, the canonicalize function would have to parse the username, > >splitting it on '@' to separate username from realm, so that you would get > > > > uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth > > > >If the username doesn't contain '@', but olcSaslRealm is set, then I suggest > >you insert that instead: > > > > uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth > > > >And if there's no '@' and no olcSaslRealm, then just leave it alone: > > > > uid=kurt,cn=gssapi,cn=auth > > This has been discussed at great length, read the -devel archives > from 9 or 10 years ago. The fact is that the SASL specification > doesn't reserve '@' as a special character and there is no guarantee > that this is actually a realm separator. There are plenty of > authentication mechanisms where '@' is an integral part of the > username. This suggestion simply won't fly. I suspect that's why canon_user was made pluggable in the first place; if you have your own idea of what constitutes a username with or without a realm then you code for it there. In Cyrus-SASL, plugins/gssapi.c has it hard-coded: if (strchr((char *) name_token.value, (int) '@') != NULL) { ... /* cut off string at '@' */ (strchr(name_without_realm.value,'@'))[0] = '\0'; I agree that non-Kerberos SASL mechanisms might have different username formats; and hence, without additional configuration, OpenLDAP cannot split arbitrary SASL usernames into uid=user,cn=realm. However the current behaviour of olcSaslRealm isn't useful either, since it just gives you uid=user[@realm],cn=olcSaslRealm. I think the most appropriate behaviour for olcSaslRealm would be for it to qualify usernames that don't contain '@' - and if your app doesn't use usernames with '@', then don't set olcSaslRealm. > I don't believe we have any freedom to make any code changes here; > feel free to suggest verbiage changes for the documentation. No problem. I propose the following to bring the docs in line with behaviour. --- sasl.sdf.orig 2011-01-03 09:45:55.754879001 +0000 +++ sasl.sdf 2011-01-03 10:07:34.808208000 +0000 @@ -135,25 +135,35 @@ For the purposes of authentication and authorization, {{slapd}}(8) associates an authentication request DN of the form: -> uid=<primary[/instance]>,cn=<realm>,cn=gssapi,cn=auth +> uid=<primary[/instance][@realm]>,cn=gssapi,cn=auth + +The realm is omitted by Cyrus SASL if it's equal to the default realm of the +server in {{FILE:/etc/krb5.conf}}. Continuing our example, a user with the Kerberos principal {{EX:kurt@EXAMPLE.COM}} would have the associated DN: -> uid=kurt,cn=example.com,cn=gssapi,cn=auth +> uid=kurt,cn=gssapi,cn=auth and the principal {{EX:ursula/admin@FOREIGN.REALM}} would have the associated DN: -> uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth +> uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth -The authentication request DN can be used directly ACLs and +The authentication request DN can be used directly in ACLs and {{EX:groupOfNames}} "member" attributes, since it is of legitimate LDAP DN format. Or alternatively, the authentication DN could be mapped before use. See the section {{SECT:Mapping Authentication Identities}} for details. +If you configure olcSaslRealm then it is always inserted as an extra +component in the authorization DN, regardless of the realm of the client. +For example, if you set olcSaslRealm to {{EX:example.com}} then you will +get: + +> uid=kurt,cn=example.com,cn=gssapi,cn=auth +> uid=ursula/admin(a)foreign.realm,cn=example.com,cn=gssapi,cn=auth H3: KERBEROS_V4

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by hyc＠symas.com 02 Jan '11

02 Jan '11

Brian Candler wrote: > Now, if my understanding of the user_realm parameter is correct, I think > there are two ways to make OpenLDAP's behaviour consistent with its > documentation. > > (1) Stick more or less with the current behaviour, and change the > documentation to say that you'll get > uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth > for foreign realms. > > However, the odd thing about the current behaviour is that setting > olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into > the auth DN, regardless of whether it's local or foreign. That's not very > useful. Note that it's not the OpenLDAP code that's sticking this in there; it's the Cyrus code that's returning this realm in the callback. IMO our job is to faithfully return what the Cyrus library gave us. > I think it would make more sense, if olcSaslRealm is present, to use it to > *qualify* usernames which don't have a realm. That decision is made by the Cyrus library, not us. > uid=kurt,cn=gssapi,cn=auth > ---> uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth > > i.e. change the canonicalize function to append @user_realm if the username > doesn't contain '@'. > > This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of > stripping off the default realm. > > (2) Change the OpenLDAP behaviour so that it matches the documentation at > http://www.openldap.org/doc/admin24/sasl.html#GSSAPI > > To do this, the canonicalize function would have to parse the username, > splitting it on '@' to separate username from realm, so that you would get > > uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth > > If the username doesn't contain '@', but olcSaslRealm is set, then I suggest > you insert that instead: > > uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth > > And if there's no '@' and no olcSaslRealm, then just leave it alone: > > uid=kurt,cn=gssapi,cn=auth This has been discussed at great length, read the -devel archives from 9 or 10 years ago. The fact is that the SASL specification doesn't reserve '@' as a special character and there is no guarantee that this is actually a realm separator. There are plenty of authentication mechanisms where '@' is an integral part of the username. This suggestion simply won't fly. I don't believe we have any freedom to make any code changes here; feel free to suggest verbiage changes for the documentation. -- -- 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#6766) memberOf does not replicate specially crafted modifications
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

Full_Name: Pierangelo Masarati Version: HEAD/re24 OS: irrelevant URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (2.40.10.16) Submitted by: ando If a modification deletes and recreates a member, something like dn: cn=group changetype: modify delete: member member: cn=user - add: member member: cn=user - the operation succeeds on the provider, but only the delete is replicated. This occurs because the operation, within the memberOf overlay, results in two separate operations: dn: cn=user changetype: modify delete: memberOf memberOf: cn=group dn: cn=user changetype: modify add: memberOf memberOf: cn=group with the same CSN, although corresponding to different operations, so the consumer ignores the second (btw, the CSN is the same of the modification that affects the "cn=group" entry). There may be two solutions: recognize that both operations affect the same entry, and group them, or change the CSN. p.

1 0

Re: (ITS#6757) SASL canonicalize doesn't work as documented
by B.Candler＠pobox.com 02 Jan '11

02 Jan '11

I've been doing some analysis of the Cyrus SASL code. When you say "we're using the parameters as documented by Cyrus", I presume the documentation you refer to is the comments within the source, in which case this all hinges on one line in include/sasl.h: * user_realm -- the user realm (may be NULL in case of client) (in the parameter list for the SASL_CB_CANON_USER callback). So what's meant by "the user realm"? When the callback is actually made (in lib/canonusr.c), the value passed is sconn->user_realm. This appears to be the value you get from sasl_getprop() with SASL_DEFUSERREALM. The user_realm value can be set in sasl_server_new (lib/server.c) and sasl_setprop (lib/common.c). There is a further description of realms in sasl/include.h: * IMPORTANT NOTE: server realms / username syntax * ... A single server may support multiple realms. If the * server knows the realm at connection creation time (e.g., a server * with multiple IP addresses tightly binds one address to a specific * realm) then that realm must be passed in the user_realm field of * the sasl_server_new call. If user_realm is non-empty and an * unqualified user name is supplied, then the canon_user facility is * expected to append "@" and user_realm to the user name. That is: it seems to me fairly clear that the purpose of user_realm is to provide a *default* realm which can be appended to the username when canonicalizing it. As a specific example, the code in _canonuser_internal() appends @<user_realm> if the username doesn't contain '@'. Furthermore, it's also clear from this that the username (SASL_USERNAME) is intended to include '@' and a realm; Cyrus is not designed to split it into a username part and a realm part. This matches what I see when using Cyrus SASL's standalone "sample-server" and "sample-client" programs, with GSSAPI and a client with a kerberos ticket from a different realm to the server: ... Negotiation complete Username: student(a)REALM3.WS.NSRC.ORG << sasl_getprop SASL_USERNAME Realm: (NULL) << sasl_getprop SASL_DEFUSERREALM SSF: 56 ... There's a full transcript of this example at http://lists.andrew.cmu.edu/pipermail/cyrus-sasl/2010-December/002177.html Next, looking at plugins/gssapi.c: AFAICS it doesn't make use of user_realm, but does ask GSSAPI if the name without realm is the same as the name with realm, and if so returns the name with the realm stripped off. /* If the id contains a realm get the identifier for the user without the realm and see if it's the same id (i.e. tmartin == tmartin(a)ANDREW.CMU.EDU. If this is the case we just want to return the id (i.e. just "tmartin" */ So, there is code in the GSSAPI plugin to *strip* the realm if it's the same as the default, but I don't think there's code to *separate* the username from the realm if the realm is foreign. Putting all this together: it seems to me that the "user_realm" you see is really just the configured default realm for the session; and that when you query SASL_USERNAME for a Kerberos client, you will see "username" if it's in the default realm, and "username(a)foreign.realm" for other realms. And this matches what I observe when testing this in OpenLDAP. As you suggested, I did bring this up on the cyrus-sasl mailing list (archive URL above), but no replies have been forthcoming so far. Now, if my understanding of the user_realm parameter is correct, I think there are two ways to make OpenLDAP's behaviour consistent with its documentation. (1) Stick more or less with the current behaviour, and change the documentation to say that you'll get uid=ursula/admin(a)foreign.realm,cn=gssapi,cn=auth for foreign realms. However, the odd thing about the current behaviour is that setting olcSaslRealm always sticks a static value (...,cn=<olcSaslRealm>,...) into the auth DN, regardless of whether it's local or foreign. That's not very useful. I think it would make more sense, if olcSaslRealm is present, to use it to *qualify* usernames which don't have a realm. uid=kurt,cn=gssapi,cn=auth ---> uid=kurt@<olcsaslrealm>,cn=gssapi,cn=auth i.e. change the canonicalize function to append @user_realm if the username doesn't contain '@'. This would be useful if you want to undo the Cyrus SASL GSSAPI behaviour of stripping off the default realm. (2) Change the OpenLDAP behaviour so that it matches the documentation at http://www.openldap.org/doc/admin24/sasl.html#GSSAPI To do this, the canonicalize function would have to parse the username, splitting it on '@' to separate username from realm, so that you would get uid=ursula/admin,cn=foreign.realm,cn=gssapi,cn=auth If the username doesn't contain '@', but olcSaslRealm is set, then I suggest you insert that instead: uid=kurt,cn=<olcsaslrealm>,cn=gssapi,cn=auth And if there's no '@' and no olcSaslRealm, then just leave it alone: uid=kurt,cn=gssapi,cn=auth Regards, Brian.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

>> If yes, do I need to produce other infos related to my environment? > > Hi, I have fixed a couple of bugs in reqControls validation. However a > problem remains: the validator expects control values to consist in > hexadecimal digits (0-9, a-f), while your values in some cases aren't. > This could be related to interoperation issues between different slapd > versions, although I couldn't go back to the point where this change in > syntax occurred, if any. Spotted (and fixed) the bug in the enconding part of control values. It shouldnow be fixed. Please test and report. p.

1 0

Re: (ITS#6652) accesslog anomaly in db drop/re-import
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

> Full_Name: Marco Pizzoli > Version: 2.4.23 > OS: Linux x86_64 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (193.41.84.11) > > > Hi, > I had a problem with my Accesslog database. > I was investigating an anomaly that I had and, in doing this, I tried to: > - backup (slapcat) my accesslog db > - drop the entire db (rm -f alock, *.bdb, log.*, __db*) > - slapadd the db > > In slapadd I obtained this error: > > --- BEGIN > /usr/sbin/slapadd -b "cn=log,dc=mycorp.it" -l > /srv/bck/dump_db_log.ldif.20100916 > . 0.00% eta 08h35m elapsed spd 90.2 > k/s > str2entry: invalid value for attributeType reqControls #0 (syntax > 1.3.6.1.4.1.4203.666.11.5.3.1) > slapadd2.4: could not parse entry (line=4907) > - 0.01% eta 05h58m elapsed spd 205.7 > k/s > Closing DB... > --- END > > I went to that line and found this entry: > > --- BEGIN > dn: reqStart=20100913065628.000008Z,cn=log,dc=mycorp.it > objectClass: auditSearch > structuralObjectClass: auditSearch > reqStart: 20100913065628.000008Z > reqEnd: 20100913065628.000009Z > reqType: search > reqSession: 1129 > reqAuthzID: > cn=syncrepl-ldap04,ou=utenze_tecniche_openldap,ou=Gestori,dc=mycorp.it > reqControls: {0}{1.3.6.1.4.1.4203.1.9.1.1 controlValue > "30440K0103043M7269643N > 3030332M7369643N3030342M63736O3N32303130303931333036353130362O3932343735355K2 > 330303030303023303033233030303030300001PP"} > reqControls: {1}{2.16.840.1.113730.3.4.2 criticality TRUE} > reqDN: dc=mycorp.it > reqResult: 0 > reqScope: base > reqDerefAliases: never > reqAttrsOnly: TRUE > reqFilter: (objectclass=*) > reqAttr: 1.1 > reqEntries: 0 > reqTimeLimit: -1 > reqSizeLimit: 1 > entryUUID: 2beb0bd0-ba32-4a00-93da-748ef2177cc7 > creatorsName: cn=Manager,cn=log,dc=mycorp.it > createTimestamp: 20100913065628Z > entryCSN: 20100913065628.167225Z#000000#003#000000 > modifiersName: cn=Manager,cn=log,dc=mycorp.it > modifyTimestamp: 20100913065628Z > --- END > > Having produced this ldif using slapcat and not having "touched" the > environment > in between could I assume this to be a bug? > The entry showed is related to an access made by another OL server of my > deployment, which is in mirrormode(=true). > This OL is 2.4.23 with BDB4.8.30. Other OLs are 2.4.22 with BDB4.8.26 > > > I deleted this entry and retried the import. > Now I have the following error: > --- BEGIN > /usr/sbin/slapadd2.4 -b "cn=log,dc=mycorp.it" -l > /tmp/dump_db_log.ldif.20100916_Corrected > " 4.69% eta 01h07m elapsed 03m19s spd 542.3 > k/s > str2entry: invalid value for attributeType reqRespControls #0 (syntax > 1.3.6.1.4.1.4203.666.11.5.3.1) > slapadd2.4: could not parse entry (line=3099715) > * 4.70% eta 01h07m elapsed 03m20s spd 979.8 > k/s > Closing DB... > --- END > > The "corrupted" entry is this one: > > --- BEGIN > dn: reqStart=20100913093021.000000Z,cn=log,dc=mycorp.it > objectClass: auditBind > structuralObjectClass: auditBind > reqStart: 20100913093021.000000Z > reqEnd: 20100913093021.000001Z > reqType: bind > reqSession: 2746 > reqAuthzID: > reqControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1} > reqRespControls: {0}{1.3.6.1.4.1.42.2.27.8.5.1 controlValue "3000"} > reqDN: uid=pe1597,ou=People,dc=mycorp.it > reqResult: 0 > reqVersion: 3 > reqMethod: SIMPLE > entryUUID: 192cbddf-4b5c-431d-a92e-c2f84fa4b7be > creatorsName: cn=Manager,cn=log,dc=mycorp.it > createTimestamp: 20100913093021Z > entryCSN: 20100913093021.411398Z#000000#003#000000 > modifiersName: cn=Manager,cn=log,dc=mycorp.it > modifyTimestamp: 20100913093021Z > --- END > > Is this a software bug? > > If yes, do I need to produce other infos related to my environment? Hi, I have fixed a couple of bugs in reqControls validation. However a problem remains: the validator expects control values to consist in hexadecimal digits (0-9, a-f), while your values in some cases aren't. This could be related to interoperation issues between different slapd versions, although I couldn't go back to the point where this change in syntax occurred, if any. p.

1 0

Re: (ITS#6749) Shut up "configure monitor database to enable"
by masarati＠aero.polimi.it 02 Jan '11

02 Jan '11

> Full_Name: Hallvard B Furuseth > Version: 2.4.23 > OS: > URL: > Submission from: (NULL) (129.240.6.233) > Submitted by: hallvard > > > Please don't give the "configure monitor database to enable" message > by default. > > Either just remove it, or better, stop cn=config from adding a default > olcMonitoring: TRUE attribute to olcDatabase objects. (The flag value > can still default to True if the attribute is absent.) Then you can > give the message if the _admin_ has explicitly asked for monitoring, > instead of if slapd has asked for it. I disagree; it is not cn=config that defaults database monitoring to TRUE; actually, it's back-bdb/back-hdb that sets its own monitoring to TRUE as soon as back-monitor support is compiled and the specific backend monitoring is successfully initilized. Maybe this warning can be demoted to LDAP_DEBUG_CONFIG instead of LDAP_DEBUG_ANY. I understand that one could presume that the lack of database monitor in the configuration indicates that monitoring is not desired; this warning, however, tries to address a typical configuration error, when admins just forget to configure it. p.

1 0

Re: (ITS#6700) memberOf overlay does not handle MODRDN correctly
by masarati＠aero.polimi.it 01 Jan '11

01 Jan '11

> raphael.ouazana(a)linagora.com wrote: > >> When using memberOf overlay, a MODRDN request on a member does not >> update >> correctly the matching group, even if the memberof-refint option is set >> to >> true. >> >> In my little understanding, memberof_value_modify calls >> op->o_bd->be_modify >> which calls back the overlay code, and finally never reach the backend. > > Guess what, modrdn is the only operation test052 does not check :( > WOrking at it. Thanks, p. Fixed in HEAD; please test and report. Please note that test052 and the corresponding expected output data have been modified to check modrdn. p.

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