- openldap-bugs - openldap.org

(ITS#7249) slapd segfault with memberof overlay on frontend db
by jvcelak＠redhat.com 18 Apr '12

18 Apr '12

Full_Name: Jan Vcelak Version: master OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) Enabling memberof overlay on frontend database causes slapd to SEGFAULT due to stack overflow when renaming an entry. Slapd should not segfault even if the configuration is wrong. Initial server configuration: (slapadd -F /etc/openldap/slapd.d -n 0 -l slapd.ldif) dn: cn=config objectClass: olcGlobal cn: config olcArgsFile: /var/run/slapd.args olcPidFile: /var/run/slapd.pid dn: cn=schema,cn=config objectClass: olcSchemaConfig cn: schema include: file:///etc/openldap/schema/core.ldif dn: olcDatabase=frontend,cn=config objectClass: olcDatabaseConfig olcDatabase: frontend dn: olcDatabase=config,cn=config objectClass: olcDatabaseConfig olcDatabase: config olcAccess: to * by dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,c n=auth" manage by * none dn: olcDatabase=bdb,cn=config objectClass: olcDatabaseConfig objectClass: olcBdbConfig olcDatabase: bdb olcSuffix: dc=my-domain,dc=com olcRootDN: cn=Manager,dc=my-domain,dc=com olcRootPW: secret olcDbDirectory: /var/lib/ldap olcDbIndex: objectClass eq Initial data: (ldapadd -c -H ldap://localhost -x -D cn=manager,dc=my-domain,dc=com -w secret -f data.ldif) dn: dc=my-domain,dc=com objectclass: dcObject objectclass: organization o: Example Org dc: my-domain dn: cn=Manager,dc=my-domain,dc=com objectclass: organizationalRole cn: Manager dn: ou=users,dc=my-domain,dc=com objectclass: organizationalUnit ou: users dn: cn=foo,ou=users,dc=my-domain,dc=com objectclass: organizationalRole cn: foo Enabling overlay: (ldapadd -c -Y EXTERNAL -H ldapi:/// -f data_overlays.ldif) dn: olcOverlay={0}memberof,olcDatabase={-1}frontend,cn=config objectClass: olcOverlayConfig objectClass: olcMemberOf olcOverlay: {0}memberof olcMemberOfDangling: error olcMemberOfDanglingError: constraintViolation olcMemberOfRefInt: TRUE olcMemberOfGroupOC: groupOfNames olcMemberOfMemberAD: member olcMemberOfMemberOfAD: memberOf Renaming the entries, causing segmentation fault: (ldapmodify -c -H ldap://localhost -x -D cn=manager,dc=my-domain,dc=com -w secret -f data_modify.ldif) dn: cn=foo,ou=users,dc=my-domain,dc=com changetype: modrdn newrdn: cn=bar deleteoldrdn: 1 dn: cn=bar,ou=users,dc=my-domain,dc=com changetype: modrdn newrdn: cn=foo deleteoldrdn: 1 Server backtrace: (gdb) bt 6 full #0 0x000000000044f188 in backend_check_restrictions (op=0x0, rs=0x0, opdata=0x0) at ../../../servers/slapd/backend.c:1022 restrictops = 140737153878880 requires = 4515244 opflag = 8413346912 exopflag = 140737311768104 ssfs = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0} ssf = 0xa0bc30 updateop = 0 starttls = 0 session = -184966544 #1 0x000000000043f3cf in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:370 bd = 0x7ffff4f9a180 #2 0x00000000004d9fd4 in overlay_op_walk (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search, oi=0x7fffec104b60, on=0x0) at ../../../servers/slapd/backover.c:671 func = 0x8dc018 rc = 32768 #3 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 oi = 0x7fffec104b60 on = 0x7fffec104d40 be = 0xa0bc30 db = {bd_info = 0x8dbfc0, bd_self = 0xa0bc30, be_ctrls = "\000\001\001\001\000\001\000\000\001\000\000\001\001\000\001\001", '\000' <repeats 16 times>, "\001", be_flags = 67848, be_restrictops = 0, be_requires = 0, be_ssf_set = {sss_ssf = 0, sss_transport = 0, sss_tls = 0, sss_sasl = 0, sss_update_ssf = 0, sss_update_transport = 0, sss_update_tls = 0, sss_update_sasl = 0, sss_simple_bind = 0}, be_suffix = 0xa16380, be_nsuffix = 0xa163b0, be_schemadn = {bv_len = 0, bv_val = 0x0}, be_schemandn = {bv_len = 0, bv_val = 0x0}, be_rootdn = {bv_len = 30, bv_val = 0xa16450 "cn=Manager,dc=my-domain,dc=com"}, be_rootndn = {bv_len = 30, bv_val = 0xa164a0 "cn=manager,dc=my-domain,dc=com"}, be_rootpw = {bv_len = 6, bv_val = 0xa16320 "secret"}, be_max_deref_depth = 15, be_def_limit = {lms_t_soft = 3600, lms_t_hard = 0, lms_s_soft = 500, lms_s_hard = 0, lms_s_unchecked = -1, lms_s_pr = 0, lms_s_pr_hide = 0, lms_s_pr_total = 0}, be_limits = 0x0, be_acl = 0x0, be_dfltaccess = ACL_READ, be_extra_anlist = 0x0, be_update_ndn = {bv_len = 0, bv_val = 0x0}, be_update_refs = 0x0, be_pending_csn_list = 0xbefb60, be_pcl_mutex = {__data = {__lock = 0, __count = 0, __owner = 0, __nusers = 0, __kind = 0, __spins = 0, __list = {__prev = 0x0, __next = 0x0}}, __size = '\000' <repeats 39 times>, __align = 0}, be_syncinfo = 0x0, be_pb = 0x0, be_cf_ocs = 0x8d4c60, be_private = 0xa11e80, be_next = {stqe_next = 0x0}} cb = {sc_next = 0x7ffff4f9a410, sc_response = 0x4d8d5b <over_back_response>, sc_cleanup = 0, sc_private = 0x7fffec104b60} sc = 0x0 rc = 32768 __PRETTY_FUNCTION__ = "over_op_func" #4 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 No locals. #5 0x000000000043f5bb in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:402 bd = 0x7ffff4f9a460 (More stack frames follow...) ... #45535 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 #45536 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 #45537 0x000000000043f5bb in fe_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/search.c:402 #45538 0x00000000004d9fd4 in overlay_op_walk (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search, oi=0x7fffe81050a0, on=0x0) at ../../../servers/slapd/backover.c:671 #45539 0x00000000004da225 in over_op_func (op=0x7ffff5797df0, rs=0x7ffff5797c60, which=op_search) at ../../../servers/slapd/backover.c:723 #45540 0x00000000004da334 in over_op_search (op=0x7ffff5797df0, rs=0x7ffff5797c60) at ../../../servers/slapd/backover.c:750 #45541 0x00000000005abaeb in memberof_isGroupOrMember (op=0x7fffec000940, mci=0x7fffec001420) at ../../../../servers/slapd/overlays/memberof.c:289 #45542 0x00000000005b00c0 in memberof_res_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../../servers/slapd/overlays/memberof.c:1513 #45543 0x000000000045262c in slap_response_play (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:507 #45544 0x0000000000452868 in send_ldap_response (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:582 #45545 0x0000000000453a52 in slap_send_ldap_result (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/result.c:860 #45546 0x000000000050e0a9 in bdb_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../../servers/slapd/back-bdb/modrdn.c:789 #45547 0x00000000004626be in fe_op_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/modrdn.c:314 #45548 0x00000000004d9fd4 in overlay_op_walk (op=0x7fffec000940, rs=0x7ffff57989e0, which=op_modrdn, oi=0x7fffe81050a0, on=0x0) at ../../../servers/slapd/backover.c:671 #45549 0x00000000004da225 in over_op_func (op=0x7fffec000940, rs=0x7ffff57989e0, which=op_modrdn) at ../../../servers/slapd/backover.c:723 #45550 0x00000000004da3b2 in over_op_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/backover.c:768 #45551 0x0000000000461e20 in do_modrdn (op=0x7fffec000940, rs=0x7ffff57989e0) at ../../../servers/slapd/modrdn.c:186 #45552 0x000000000043a9df in connection_operation (ctx=0x7ffff5798b20, arg_v=0x7fffec000940) at ../../../servers/slapd/connection.c:1150 #45553 0x000000000043af9c in connection_read_thread (ctx=0x7ffff5798b20, argv=0x13) at ../../../servers/slapd/connection.c:1286 #45554 0x00000000005d0dd2 in ldap_int_thread_pool_wrapper (xpool=0x9b0170) at ../../../libraries/libldap_r/tpool.c:688 #45555 0x00000034ad607b41 in start_thread (arg=0x7ffff5799700) at pthread_create.c:305 #45556 0x00000034acee0e6d in clone () at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 18 Apr '12

18 Apr '12

> No. Your patch fixes one possible wrong outcome, but the sudo > approach is > still fundamentally wrong and if we only patch this one instance, > someone else > in the future is bound to trip over the sequencing problem again. Fix > the > right bug, otherwise you will have to keep fixing the wrong bugs over > and over > again. OK, thanks for confirmation. I will report a bug for sudo. Jan

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by hyc＠symas.com 18 Apr '12

18 Apr '12

Jan Vcelak wrote: >> Sounds like a simple sequencing bug then. Just initialize the global >> options >> before the first ldap_initialize() call. > > Sudo parses the options in config file and stores them in a table: > http://www.sudo.ws/repos/sudo/file/6fa11e8448b9/plugins/sudoers/ldap.c#l225 > > This table is then iterated and all options are being set. The > problem is that some options are set with LDAP handle provided > and some are not. This means that the handle has to be created > before. The change proposed by you would require the change of > this well-arranged and transparent concept. "Elegance" of code does not make it less wrong. The config is simply driven as a list. They can very easily fix this so that sudo_ldap_set_options() is called twice, first with a NULL ld and only the non-connection-oriented parameters, then create the LDAP handle and call again to set the connection-oriented parameters. > It can be a sequencing bug, but this particular situation is not > described anywhere. Perhaps that should be raised as a separate doc bug then. Global options are copied to a handle at the time the handle is created. Any options not explicitly set globally at that time are set to their default value. > And OpenSSL has a different behavior. My patch > updates Mozilla NSS backend to behave the same as OpenSSL backend. > I still think this should be fixed in OpenLDAP rather than in sudo. No. Your patch fixes one possible wrong outcome, but the sudo approach is still fundamentally wrong and if we only patch this one instance, someone else in the future is bound to trip over the sequencing problem again. Fix the right bug, otherwise you will have to keep fixing the wrong bugs over and over again. -- -- 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#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 18 Apr '12

18 Apr '12

> Sounds like a simple sequencing bug then. Just initialize the global > options > before the first ldap_initialize() call. Sudo parses the options in config file and stores them in a table: http://www.sudo.ws/repos/sudo/file/6fa11e8448b9/plugins/sudoers/ldap.c#l225 This table is then iterated and all options are being set. The problem is that some options are set with LDAP handle provided and some are not. This means that the handle has to be created before. The change proposed by you would require the change of this well-arranged and transparent concept. It can be a sequencing bug, but this particular situation is not described anywhere. And OpenSSL has a different behavior. My patch updates Mozilla NSS backend to behave the same as OpenSSL backend. I still think this should be fixed in OpenLDAP rather than in sudo. Jan

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by hyc＠symas.com 18 Apr '12

18 Apr '12

jvcelak(a)redhat.com wrote: > Full_Name: Jan Vcelak > Version: git master > OS: Linux > URL: ftp://ftp.openldap.org/incoming/jvcelak-120412-moznss-hostname-check.patch > Submission from: (NULL) (209.132.186.34) > > > Hello. > > With Mozilla NSS crypto backend, the 'tls_checkpeer no' option in 'sudo' tool > does not work. I have uploaded a patch which fixes the bug. > > But some explanation is necessary: > > sudo initially creates a ldap handle using ldap_initialize() function. Then it > uses ldap_set_option() to set all the settings. The TLS configuration is applied > without passing a LDAP handle, which means the the global options are changed. Sounds like a simple sequencing bug then. Just initialize the global options before the first ldap_initialize() call. > In ldap_int_start_tls(): > > - The ldap_int_tls_connect() is called and the global TLS context is used > (LDAP_INT_GLOBAL_OPT()->ldo_tls_ctx). Which is correct. > > - The ldap_pvt_tls_check_hostname() is called always. "sudo" will set the > ldo_tls_require_cert in global options to LDAP_OPT_X_TLS_NEVER, but the handle > options (ld->ld_options) are used to check whether the verification is supposed > to happen. And ldo_tls_require_cert in handle options is LDAP_OPT_X_TLS_DEMAND > (the default), because it was copied from the global options at the time when > ldap_initialize() was called. > > - With OpenSSL, hostname check (tlso_session_chkhost) will succeed because > tlso_get_cert() will return NULL. This is true because no certificate was > requested when connecting. We do not request the certificate as well in Mozilla > NSS, but it seems that the peer can send it anyway and the library will accept > and store it. In this case, hostname check (tlsm_session_chkhost) might fail > because SSL_PeerCertificate() will return it. > > I've added an additional check, which skips the hostname verification within > tlsm_session_chkhost if we do not request the certificate validation. With this > patch, the behavior is consistent with OpenSSL. > > (Maybe ldap_pvt_tls_check_hostname() should not just be called, because the > global context was used and therefore we should use global options. Not sure > what is expected, but I think that changing this might break some applications. > My fix is safer.) > > Jan > > -- -- 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#7110) cn=config mixes values
by hyc＠symas.com 17 Apr '12

17 Apr '12

Raphaël Ouazana-Sustowski wrote: > Sorry, that was a typo. > >>> Case 2 (inversed values): >>> >>> dn: olcDatabase={3}bdb,cn=config >>> changetype: modify >>> replace: olcAccess >>> olcAccess: {2} to * by dn.base=cn=2,dc=example,dc=com write >>> olcAccess: {1} to * by dn.base=cn=1,dc=example,dc=com write >>> olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write >>> >>> Result: >>> olcAccess: {0} to * by dn.base=cn=0,dc=example,dc=com write >>> olcAccess: {1} to * by dn.base=cn=2,dc=example,dc=com write >>> olcAccess: {2} to * by dn.base=cn=1,dc=example,dc=com write >>> >>> The two last values are incorrectly mixed. >> >> Wrong, this works as designed. See draft-chu-ldap-xordered-xx section >> 3.3. > > I reread intensively this section (xx=00), but I don't find anywhere > where it is specified that lines are read one after one and not > globally. >>>> The ordering-prefix may also be used in Modification requests to specify which values to delete, and in which position values should be added. When processing deletions and insertions, all of the ordinals are recounted after each individual modification. If a value being added does not have an ordering-prefix, it is simply appended to the list and the appropriate ordering-prefix is automatically generated. Likewise if an ordering-prefix is provided that is greater than or equal to the number of existing values. <<<< > Anyway this is not a problem anymore in my software, I modified the > client to send the values in the good order. But I'd like to understand > where it is specified. Else I think this sample case should be added to > the draft. > > Regards, > Raphaël Ouazana. > -- -- 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#7248) Cast to string in back-sql when upper_needs_cast is declared in slapd.conf
by rene.snajder＠i-med.ac.at 17 Apr '12

17 Apr '12

Oh, and I forgot: The attached modifications to OpenLDAP Software are subject to the following notice: Copyright 2012 Rene Snajder Redistribution and use in source and binary forms, with or without modification, are permitted only as authorized by the OpenLDAP Public License.

1 0

(ITS#7248) Cast to string in back-sql when upper_needs_cast is declared in slapd.conf
by rene.snajder＠i-med.ac.at 17 Apr '12

17 Apr '12

Full_Name: Rene Snajder Version: 2.4.30 OS: RHEL 6 URL: ftp://ftp.openldap.org/incoming/openldap-upper-strcast.patch Submission from: (NULL) (193.171.77.1) I reported (from my other e-mail address dermaniac(a)gmail.com) a bug report in January. I reported it to the technical mailing list first: http://www.openldap.org/lists/openldap-technical/201201/msg00233.html which I got no reply on. I then posted a ticket here: http://www.openldap.org/its/index.cgi/Incoming?id=7130;page=12 which I got one reply but it didn't fix my problem (and I didn't get further replies). I then took matters in my own hand and found 3 bugs in back-sql which lead to errors when UPPER is applied to integer values. Since there was no reaction here I tried to report it to Redhat (since I'm using RHEL) where the issue finally got some attention. I created a bugfix and they advised me to submit it directly to openldap, so now I'm trying it here again. Strangely, the same day that redhat responded to my patch I got a reply here: http://www.openldap.org/lists/openldap-technical/201204/msg00108.html to which I cannot seem to answer (my mails to the mailing list never seem to make it through). Here are the bugs that I found: 1) It is not checked whether the UPPER function can be applied on a type in the database. Comments in the code itself confirm that this is "currently broken". (see my previous 2 comments) 2) One would assume that the parameter "upper_needs_cast yes" in the slapd.conf would add a string casting statement to every UPPER statement in the SQL queries. In fact, it only does so for one single query (when it queries for "ldap_entries.dn"). All other queries where UPPER is applied still don't use a cast, even though I declare "upper_needs_cast yes" in the main config file. 3) The slapd.conf file lets me declare a "strcast_func" which is the name of the function for a cast to string. This strcast_func is used at some points in the queries, but not consistently. For the one query that actually pays any attention to the "upper_needs_cast" parameter (which i mentioned before) a hardcoded string cast function is used instead. This function is always "(cast ? as varchar(255))". Now these are 3 separate problems in the back-sql code. To fix my particular problem I took a closer look at problem number 2. I attached an patch which can be applied to the version in the GIT repository. When this patch is applied, the hardcoded strcast function from problem number 3 is at least applied to every use of the UPPER function (or at least everywhere where the upper function is applied properly!), effectively fixing problem number 2. This may THEORETICALLY lead to the following problem: IF someone set "upper_needs_cast yes" in their config, with a database backend that does not support the hardcoded strcast function, this patch would break the SQL queries for this user. BUT, in that case using the "upper_needs_cast yes" statement would have been useless - or even causing problems - before this patch anyways - since it was always using the hardcoded function and only at one single point. My patch is here: ftp://ftp.openldap.org/incoming/openldap-upper-strcast.patch For a more detailed description see my bug report in the Redhat Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=809105

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 16 Apr '12

16 Apr '12

Howard Chu wrote: > Michael Ströder wrote: >> hyc(a)symas.com wrote: >>> 4.2.2.2 fedfsFsn >>> IMO name/port should just be an LDAP URL. Also your definition provides >>> absolutely zero information of how the LDAP server should be contacted (e.g. >>> using ldaps or StartTLS) which both can be encoded in an LDAP URL. >> >> Which standard describes how to mandate use of StartTLS with a LDAP URL? >> OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with >> web2ldap. But AFAIK this is not defined in any standard which could be >> referenced in a RFC. > > True but irrelevant. The point is that standardizing on a URL syntax today > future-proofs a spec and allows it to handle new connection mechanisms that > may appear in the future. Host/port is inextricably tied to networking in the > 1980s. I did not want to endorse the use of host/port. I just wanted to point out that one cannot specify the use of StartTLS by LDAP URL in a standard way. Of course nothing prevents somebody to add custom extension to LDAP URLs. Ciao, Michael.

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by hyc＠symas.com 16 Apr '12

16 Apr '12

Michael Ströder wrote: > hyc(a)symas.com wrote: >> 4.2.2.2 fedfsFsn >> IMO name/port should just be an LDAP URL. Also your definition provides >> absolutely zero information of how the LDAP server should be contacted (e.g. >> using ldaps or StartTLS) which both can be encoded in an LDAP URL. > > Which standard describes how to mandate use of StartTLS with a LDAP URL? > OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with > web2ldap. But AFAIK this is not defined in any standard which could be > referenced in a RFC. True but irrelevant. The point is that standardizing on a URL syntax today future-proofs a spec and allows it to handle new connection mechanisms that may appear in the future. Host/port is inextricably tied to networking in the 1980s. > http://www.openldap.org/lists/openldap-devel/200202/msg00060.html > http://www.openldap.org/lists/openldap-devel/200810/msg00034.html > > Ciao, Michael. > -- -- 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#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 16 Apr '12

16 Apr '12

hyc(a)symas.com wrote: > 4.2.2.2 fedfsFsn > IMO name/port should just be an LDAP URL. Also your definition provides > absolutely zero information of how the LDAP server should be contacted (e.g. > using ldaps or StartTLS) which both can be encoded in an LDAP URL. Which standard describes how to mandate use of StartTLS with a LDAP URL? OpenLDAP has its own extension key-word "StartTLS" and I'm also using it with web2ldap. But AFAIK this is not defined in any standard which could be referenced in a RFC. http://www.openldap.org/lists/openldap-devel/200202/msg00060.html http://www.openldap.org/lists/openldap-devel/200810/msg00034.html Ciao, Michael.

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 16 Apr '12

16 Apr '12

On Apr 16, 2012, at 1:09 PM, Howard Chu wrote: > chuck.lever(a)oracle.com wrote: >> Full_Name: Chuck Lever >> Version: All >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (99.26.161.222) >> >> >> I'd like to request the addition of the FedFS schema described in this draft: >> >> http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-11 >> >> as part of the repertoire of schemas that are installed by default for new >> servers. An overview of FedFS can be found here: >> >> http://tools.ietf.org/html/rfc5716 >> >> I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: >> >> http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif > > This gets a 404 for me. > >> This contains the correct IETF boilerplate. The schema is extracted verbatim >> from draft 11. >> >> Addendum: The NSDB draft is in last call, and there have been some changes to >> the schema. I will provide a refresh as soon as the next revision of the draft >> is available. > > From an LDAP perspective I see a few nits that should be cleaned up in this definition. Haven't looked at it from the NFS perspective. > > 4.1 > fedfsNcePrefix is really a DN (not a string) and must conform to DN syntax. That's made clear in the following definition, but this description is misleading. I note that LDAP is still basically X.500, and this informal definition is invalid in pure X.500 terms. You should dispense with the notion of prefix and just make this a regular DN, with a constraint that the DN will be subordinate to the containerInfo entry. > > 4.2.1.1 > I note that LDAP already has a UUID syntax 1.3.6.1.1.16.1 and I don't believe you should be defining yours as inheriting from "name". > > 4.2.1.2/3 > IMO you should define a URL format instead of distinct address/port attributes. > > 4.2.1.14 > XDR blobs? Really? The point of XDR blobs is that a file server doesn't need to un-marshall then re-marshall the pathname data when it generates a referral. Replacement suggestions welcome. > 4.2.1.18... > Single-bit attributes? You seem to be specifying a particular implementation of a file service. IETF specs should define protocols and data interchange formats, but leave implementation-level details to implementors. > > 4.2.2.2 fedfsFsn > IMO name/port should just be an LDAP URL. Also your definition provides absolutely zero information of how the LDAP server should be contacted (e.g. using ldaps or StartTLS) which both can be encoded in an LDAP URL. It also precludes the use of ldapi:// which might be preferred for an inward-facing/local agent. > > I haven't read the rest of the draft but IMO this is premature for a last call. This draft has been in last call for months, I'm surprised there are so many issues. I think there is still an opportunity for discussion on the working group mailing list. We welcome your comments on nfsv4(a)ietf.org. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com

1 0

(ITS#7247) smbk5pwd.c: hdb_generate_key_set_password function changes
by quanah＠OpenLDAP.org 16 Apr '12

16 Apr '12

Full_Name: Quanah Gibson-Mount Version: 2.4.28 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) >From the Debian bug tracker: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=664930 The cause of the problem is that a function declared in a header file in the heimdal package has changed its signature. The old header said: krb5_error_code hdb_generate_key_set_password ( krb5_context /*context*/, krb5_principal /*principal*/, const char */*password*/, Key **/*keys*/, size_t */*num_keys*/); The new version says: krb5_error_code hdb_generate_key_set_password ( krb5_context /*context*/, krb5_principal /*principal*/, const char */*password*/, krb5_key_salt_tuple */*ks_tuple*/, int /*n_ks_tuple*/, Key **/*keys*/, size_t */*num_keys*/);

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 16 Apr '12

16 Apr '12

Corrected URL: http://oss.oracle.com/projects/fedfs-utils/dist/files/fedfs-schema.ldif -- Chuck Lever chuck[dot]lever[at]oracle[dot]com

1 0

Re: (ITS#7246) Addition of FedFS schema LDIF
by hyc＠symas.com 16 Apr '12

16 Apr '12

chuck.lever(a)oracle.com wrote: > Full_Name: Chuck Lever > Version: All > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (99.26.161.222) > > > I'd like to request the addition of the FedFS schema described in this draft: > > http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-11 > > as part of the repertoire of schemas that are installed by default for new > servers. An overview of FedFS can be found here: > > http://tools.ietf.org/html/rfc5716 > > I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: > > http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif This gets a 404 for me. > This contains the correct IETF boilerplate. The schema is extracted verbatim > from draft 11. > > Addendum: The NSDB draft is in last call, and there have been some changes to > the schema. I will provide a refresh as soon as the next revision of the draft > is available. From an LDAP perspective I see a few nits that should be cleaned up in this definition. Haven't looked at it from the NFS perspective. 4.1 fedfsNcePrefix is really a DN (not a string) and must conform to DN syntax. That's made clear in the following definition, but this description is misleading. I note that LDAP is still basically X.500, and this informal definition is invalid in pure X.500 terms. You should dispense with the notion of prefix and just make this a regular DN, with a constraint that the DN will be subordinate to the containerInfo entry. 4.2.1.1 I note that LDAP already has a UUID syntax 1.3.6.1.1.16.1 and I don't believe you should be defining yours as inheriting from "name". 4.2.1.2/3 IMO you should define a URL format instead of distinct address/port attributes. 4.2.1.14 XDR blobs? Really? 4.2.1.18... Single-bit attributes? You seem to be specifying a particular implementation of a file service. IETF specs should define protocols and data interchange formats, but leave implementation-level details to implementors. 4.2.2.2 fedfsFsn IMO name/port should just be an LDAP URL. Also your definition provides absolutely zero information of how the LDAP server should be contacted (e.g. using ldaps or StartTLS) which both can be encoded in an LDAP URL. It also precludes the use of ldapi:// which might be preferred for an inward-facing/local agent. I haven't read the rest of the draft but IMO this is premature for a last call. -- -- 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#7246) Addition of FedFS schema LDIF
by michael＠stroeder.com 16 Apr '12

16 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030305020403080208020708 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable chuck.lever(a)oracle.com wrote: > I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: >=20 > http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif This link does not work: HTTP/1.1 404 Not Found > This contains the correct IETF boilerplate. The schema is extracted ve= rbatim > from draft 11. >=20 > Addendum: The NSDB draft is in last call, and there have been some cha= nges to > the schema. I will provide a refresh as soon as the next revision of t= he draft > is available. I really wonder why 'fedfsUuid' is SUP name instead of being based on LDA= P syntax UUID (see RFC 4530). Ciao, Michael. --------------ms030305020403080208020708 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxNjE2MzUxN1owIwYJKoZIhvcNAQkEMRYE FJYm4uvB6dO0Xfb+VWGOiUGFmjzuMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAXr+lTSmYWrS1gIcELAxFI1MQ2sMnWAtCIkDhV++q2rtHIxv3FMtGDZMVrpVUUJpmLtfM S8qRyiP23ceohvePmIKviVd+imlCn0wYjTYirg2+BVgjt5NyaA1pT7C5GbjcfF5o7+Fbroy3 5wrk+S+P+EjMqT3XLuvVKeWDYN/5pea8kv0QGnFj2xkkRaNFSX1zwsjAzBRuqcRi8M5/DwIg YvUI2oefNktzAOYxW6LGn0YQxQ+WhJj+BzKbwYViiQsRCZR8h6EHSbUzqMC6DZz3NXMkdp4i dlyR0f00tcfu92e7TINj2c/eCbfLrDEA4YqUwUA2yCsx/D5n3Kp/Ln3ilgAAAAAAAA== --------------ms030305020403080208020708--

1 0

(ITS#7246) Addition of FedFS schema LDIF
by chuck.lever＠oracle.com 16 Apr '12

16 Apr '12

Full_Name: Chuck Lever Version: All OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (99.26.161.222) I'd like to request the addition of the FedFS schema described in this draft: http://tools.ietf.org/html/draft-ietf-nfsv4-federated-fs-protocol-11 as part of the repertoire of schemas that are installed by default for new servers. An overview of FedFS can be found here: http://tools.ietf.org/html/rfc5716 I've posted an LDIF containing the FedFS NSDB schema in draft 11 here: http://oss.oracle.com/projects/fedfs-utils/dist/files/91fedfs.ldif This contains the correct IETF boilerplate. The schema is extracted verbatim from draft 11. Addendum: The NSDB draft is in last call, and there have been some changes to the schema. I will provide a refresh as soon as the next revision of the draft is available.

1 0

Re: (ITS#7245) crash when using CSN in cookie
by hyc＠symas.com 16 Apr '12

16 Apr '12

jsoula(a)univ-lille2.fr wrote: > Full_Name: julien soula > Version: 2.4.30 > OS: gentoo/linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (194.254.117.85) > > > hello, > > on a replica, when I use cookie parameter with csn value as : > -c 'rid=101,csn=20120320035618.177820Z#000000#000#000000' > the server crash immediately du to bad free : Thanks for the report, fixed in git master. > > #0 0x00007ffff6ac3a55 in raise () from /lib64/libc.so.6 > #1 0x00007ffff6ac4d55 in abort () from /lib64/libc.so.6 > #2 0x00007ffff6afe972 in ?? () from /lib64/libc.so.6 > #3 0x00007ffff6b03df5 in ?? () from /lib64/libc.so.6 > #4 0x00007ffff6b08d2c in free () from /lib64/libc.so.6 > #5 0x00000000005b78d6 in ber_memfree_x (p=0xd45628, ctx=0x0) at memory.c:152 > #6 0x00000000005b85e4 in ber_bvarray_free_x (a=0xd45660, ctx=0x0) at > memory.c:731 > #7 0x00000000005b8620 in ber_bvarray_free (a=0xd45660) at memory.c:741 > #8 0x00000000004be085 in slap_sync_cookie_free (cookie=0x8f3140, > free_cookie=1) > at ldapsync.c:106 > #9 0x00000000004a3ab1 in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) > at syncrepl.c:675 > #10 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) > at syncrepl.c:1512 > #11 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) > at tpool.c:688 > #12 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 > #13 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 > > After some analyzes, I noticed that the allocation of this block was done with a > not null memory context : > > #0 ber_memalloc_x (s=41, ctx=0xd3ebd0) at memory.c:231 > #1 0x00000000005b7f46 in ber_dupbv_x (dst=0x7fffad9f8350, src=0x7fffad9f8360, > ctx=0xd3ebd0) at memory.c:506 > #2 0x0000000000480ff9 in csnNormalize (usage=2, syntax=0x912160, mr=0x918670, > val=0x7fffad9f8360, normalized=0x7fffad9f8350, ctx=0xd3ebd0) > at schema_init.c:5395 > #3 0x00000000004be94d in slap_parse_sync_cookie (cookie=0x8f3140, > memctx=0xd3ebd0) > at ldapsync.c:342 > #4 0x00000000004a3a6f in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) > at syncrepl.c:671 > #5 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) > at syncrepl.c:1512 > #6 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) > at tpool.c:688 > #7 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 > #8 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 > > but was freed with a null context as seen above. > > If I modify the code to force a null context allocation, it works. > > PS: I shortly took a look at Git code and it seems to be the same. > > Best regards, -- -- 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#7245) crash when using CSN in cookie
by jsoula＠univ-lille2.fr 16 Apr '12

16 Apr '12

Full_Name: julien soula Version: 2.4.30 OS: gentoo/linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (194.254.117.85) hello, on a replica, when I use cookie parameter with csn value as : -c 'rid=101,csn=20120320035618.177820Z#000000#000#000000' the server crash immediately du to bad free : #0 0x00007ffff6ac3a55 in raise () from /lib64/libc.so.6 #1 0x00007ffff6ac4d55 in abort () from /lib64/libc.so.6 #2 0x00007ffff6afe972 in ?? () from /lib64/libc.so.6 #3 0x00007ffff6b03df5 in ?? () from /lib64/libc.so.6 #4 0x00007ffff6b08d2c in free () from /lib64/libc.so.6 #5 0x00000000005b78d6 in ber_memfree_x (p=0xd45628, ctx=0x0) at memory.c:152 #6 0x00000000005b85e4 in ber_bvarray_free_x (a=0xd45660, ctx=0x0) at memory.c:731 #7 0x00000000005b8620 in ber_bvarray_free (a=0xd45660) at memory.c:741 #8 0x00000000004be085 in slap_sync_cookie_free (cookie=0x8f3140, free_cookie=1) at ldapsync.c:106 #9 0x00000000004a3ab1 in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) at syncrepl.c:675 #10 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) at syncrepl.c:1512 #11 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) at tpool.c:688 #12 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 #13 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 After some analyzes, I noticed that the allocation of this block was done with a not null memory context : #0 ber_memalloc_x (s=41, ctx=0xd3ebd0) at memory.c:231 #1 0x00000000005b7f46 in ber_dupbv_x (dst=0x7fffad9f8350, src=0x7fffad9f8360, ctx=0xd3ebd0) at memory.c:506 #2 0x0000000000480ff9 in csnNormalize (usage=2, syntax=0x912160, mr=0x918670, val=0x7fffad9f8360, normalized=0x7fffad9f8350, ctx=0xd3ebd0) at schema_init.c:5395 #3 0x00000000004be94d in slap_parse_sync_cookie (cookie=0x8f3140, memctx=0xd3ebd0) at ldapsync.c:342 #4 0x00000000004a3a6f in do_syncrep1 (op=0x7fffad9f8470, si=0xa0f4d0) at syncrepl.c:671 #5 0x00000000004a6e70 in do_syncrepl (ctx=0x7fffad9f8b60, arg=0xa0c4d0) at syncrepl.c:1512 #6 0x0000000000581c1f in ldap_int_thread_pool_wrapper (xpool=0x924d20) at tpool.c:688 #7 0x00007ffff7645c5c in start_thread () from /lib64/libpthread.so.0 #8 0x00007ffff6b67fcd in clone () from /lib64/libc.so.6 but was freed with a null context as seen above. If I modify the code to force a null context allocation, it works. PS: I shortly took a look at Git code and it seems to be the same. Best regards, -- Julien

1 0

Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file!
by hyc＠symas.com 14 Apr '12

14 Apr '12

napalaniappan(a)paypal.com wrote: > --_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_ > Content-Type: text/plain; charset="us-ascii" > Content-Transfer-Encoding: quoted-printable > > Thanks a lot for the information. I have the following configurations, coul= > d you check and help me to fix the NSS config. No. You've been told multiple times that this is not the place to ask these questions. -- -- 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#7243) sudo: uid 14281 does not exist in the passwd file!
by napalaniappan＠paypal.com 14 Apr '12

14 Apr '12

--_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks a lot for the information. I have the following configurations, coul= d you check and help me to fix the NSS config. # /etc/nsswitch.conf # # An example Name Service Switch config file. This file should be # sorted with the most-used services at the beginning. # # The entry '[NOTFOUND=3Dreturn]' means that the search for an # entry should stop if the search in the previous entry turned # up nothing. Note that if the search failed due to some other reason # (like no NIS server responding) then the search continues with the # next entry. # # Legal entries are: # # nis or yp Use NIS (NIS version 2), also called YP # dns Use DNS (Domain Name Service) # files Use the local files # db Use the local database (.db) files # compat Use NIS on compat mode # hesiod Use Hesiod for user lookups # ldap Use LDAP (only if nss_ldap is installed) # nisplus or nis+ Use NIS+ (NIS version 3), unsupported # [NOTFOUND=3Dreturn] Stop searching if not found so far # # To use db, put the "db" in front of "files" for entries you want to be # looked up first in the databases # # Example: #passwd: db files ldap nis #shadow: db files ldap nis #group: db files ldap nis passwd: files shadow: files group: files #hosts: db files ldap nis dns hosts: files dns # Example - obey only what ldap tells us... #services: ldap [NOTFOUND=3Dreturn] files #networks: ldap [NOTFOUND=3Dreturn] files #protocols: ldap [NOTFOUND=3Dreturn] files #rpc: ldap [NOTFOUND=3Dreturn] files #ethers: ldap [NOTFOUND=3Dreturn] files bootparams: files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files publickey: files automount: files aliases: files [root@ppdoldap01 etc]# uptime 18:02:10 up 230 days, 10:53, 2 users, load average: 0.95, 0.98, 0.92 [root@ppdoldap01 etc]# more nscd.conf # # /etc/nscd.conf # # An example Name Service Cache config file. This file is needed by nscd. # # Legal entries are: # # logfile <file> # debug-level <level> # threads <initial #threads to use> # max-threads <maximum #threads to use> # server-user <user to run server as instead of root> # server-user is ignored if nscd is started with -S parameter= s # stat-user <user who is allowed to request statistics> # reload-count unlimited|<number> # paranoia <yes|no> # restart-interval <time in seconds> # # enable-cache <service> <yes|no> # positive-time-to-live <service> <time in seconds> # negative-time-to-live <service> <time in seconds> # suggested-size <service> <prime number> # check-files <service> <yes|no> # persistent <service> <yes|no> # shared <service> <yes|no> # max-db-size <service> <number bytes> # auto-propagate <service> <yes|no> # # Currently supported cache names (services): passwd, group, hosts # # logfile /var/log/nscd.log # threads 6 # max-threads 128 server-user nscd # stat-user nocpulse debug-level 0 # reload-count 5 paranoia no # restart-interval 3600 enable-cache passwd yes positive-time-to-live passwd 600 negative-time-to-live passwd 20 suggested-size passwd 211 check-files passwd yes persistent passwd yes shared passwd yes max-db-size passwd 33554432 auto-propagate passwd yes enable-cache group yes positive-time-to-live group 3600 negative-time-to-live group 60 suggested-size group 211 check-files group yes persistent group yes shared group yes max-db-size group 33554432 auto-propagate group yes enable-cache hosts yes positive-time-to-live hosts 3600 negative-time-to-live hosts 20 suggested-size hosts 211 check-files hosts yes persistent hosts yes shared hosts yes max-db-size hosts 33554432 [etc]# cat libuser.conf # This is a first-generation configuration file. Eventually I'll rewrite # all of the configuration-reading code to use alchemist, but for now this # will have to do. # Do not modify the default module list if you care about unattended calls # to programs (i.e., scripts) working! [defaults] # The default (/usr/lib*/libuser) is usually correct # moduledir =3D /your/custom/directory skeleton =3D /etc/skel mailspooldir =3D /var/mail modules =3D files shadow create_modules =3D files shadow crypt_style =3D md5 # modules =3D files shadow ldap krb5 # create_modules =3D ldap krb5 [userdefaults] LU_USERNAME =3D %n LU_UIDNUMBER =3D 500 LU_GIDNUMBER =3D %u # LU_USERPASSWORD =3D !! # LU_GECOS =3D %n # LU_HOMEDIRECTORY =3D /home/%n # LU_LOGINSHELL =3D /bin/bash # LU_SHADOWNAME =3D %n # LU_SHADOWPASSWORD =3D !! # LU_SHADOWLASTCHANGE =3D %d # LU_SHADOWMIN =3D 0 # LU_SHADOWMAX =3D 99999 # LU_SHADOWWARNING =3D 7 # LU_SHADOWINACTIVE =3D -1 # LU_SHADOWEXPIRE =3D -1 # LU_SHADOWFLAG =3D -1 [groupdefaults] LU_GROUPNAME =3D %n LU_GIDNUMBER =3D 500 # LU_GROUPPASSWORD =3D !! # LU_MEMBERUID =3D # LU_ADMINISTRATORUID =3D [files] # This is useful for the case where some master files are used to # populate a different NSS mechanism which this workstation uses. # directory =3D /etc [shadow] # This is useful for the case where some master files are used to # populate a different NSS mechanism which this workstation uses. # directory =3D /etc [ldap] # Setting these is always necessary. # server =3D ldap # basedn =3D dc=3Dexample,dc=3Dcom # Setting these is rarely necessary, since it's usually correct. # userBranch =3D ou=3DPeople # groupBranch =3D ou=3DGroup # Set only if your administrative user uses simple bind operations to # connect to the server. # binddn =3D cn=3DManager,dc=3Dexample,dc=3Dcom # Set this only if the default user (as determined by SASL) is incorrect # for SASL bind operations. Usually, it's correct, so you'll rarely need # to set these. # user =3D Manager # authuser =3D Manager [krb5] # Set this only if it differs from the default in /etc/krb5.conf. # realm =3D EXAMPLE.COM # Set this only if the default (currentuser/admin) will be incorrect. # principal =3D example/admin(a)EXAMPLE.COM [sasl] # Set these only if your sasldb is only used by a particular application, a= nd # in a particular domain. The default (all applications, all domains) is # probably correct for most installations. # appname =3D imap # domain =3D EXAMPLE.COM -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: Friday, April 13, 2012 11:22 PM To: VEERASWAMY PALANIAPPAN, NATARRAJAN(VPN) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file! > Full_Name: Natarrajan > Version: 2.2.13-7.4E > OS: RHEL4.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.113.168.128) > > > I am getting the following error frequently in my ldap client machine. > > LDAPCLIENT ~> whoami > whoami: cannot find name for user ID 14281 LDAPCLIENT ~> sudo -u qserv > ls > sudo: uid 14281 does not exist in the passwd file! > > Let me know the fix for the issue. Upgrade (2.2.13 is about 10 years old now; 2.4.30 is the current release). Then, fix the configuration of your nss? p. --_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr= osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" = xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:= //www.w3.org/TR/REC-html40"> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dus-ascii"= > <meta name=3D"Generator" content=3D"Microsoft Word 14 (filtered medium)"> <style></style> </head> <body lang=3D"EN-US" link=3D"blue" vlink=3D"purple"> <div class=3D"WordSection1"> Thanks a lot for the information. I have the foll= owing configurations, could you check and help me to fix the NSS config.<o:= p></o:p> <o:p> </o:p> # /etc/nsswitch.conf<o:p></o:p> #<o:p></o:p> # An example Name Service Switch config file. Thi= s file should be<o:p></o:p> # sorted with the most-used services at the begin= ning.<o:p></o:p> #<o:p></o:p> # The entry '[NOTFOUND=3Dreturn]' means that the = search for an<o:p></o:p> # entry should stop if the search in the previous= entry turned<o:p></o:p> # up nothing. Note that if the search failed due = to some other reason<o:p></o:p> # (like no NIS server responding) then the search= continues with the<o:p></o:p> # next entry.<o:p></o:p> #<o:p></o:p> # Legal entries are:<o:p></o:p> #<o:p></o:p> #       nis or yp&n= bsp;           &nbsp= ;  Use NIS (NIS version 2), also called YP<o:p></o:p> #       dns  &= nbsp;           &nbs= p;      Use DNS (Domain Name Service)<o:p></o= :p> #       files =             &nb= sp;     Use the local files<o:p></o:p> #       db &nb= sp;            =         Use the local database (.db) fil= es<o:p></o:p> #       compat&nbsp= ;            &n= bsp;    Use NIS on compat mode<o:p></o:p> #       hesiod&nbsp= ;            &n= bsp;    Use Hesiod for user lookups<o:p></o:p> #       ldap &= nbsp;           &nbs= p;      Use LDAP (only if nss_ldap is installed)<o= :p></o:p> #       nisplus or = nis+         Use NIS+ (NIS = version 3), unsupported<o:p></o:p> #       [NOTFOUND= =3Dreturn]       Stop searching if not found = so far<o:p></o:p> #<o:p></o:p> <o:p> </o:p> # To use db, put the "db" in front of &= quot;files" for entries you want to be<o:p></o:p> # looked up first in the databases<o:p></o:p> #<o:p></o:p> # Example:<o:p></o:p> #passwd:    db files ldap nis<o:p>= </o:p> #shadow:    db files ldap nis<o:p>= </o:p> #group:     db files ldap nis= <o:p></o:p> <o:p> </o:p> passwd:     files<o:p></o:p><= /p> shadow:     files<o:p></o:p><= /p> group:      files<o:p></= o:p> <o:p> </o:p> #hosts:     db files ldap nis= dns<o:p></o:p> hosts:      files dns<o:= p></o:p> <o:p> </o:p> # Example - obey only what ldap tells us...<o:p><= /o:p> #services:  ldap [NOTFOUND=3Dreturn] files<o= :p></o:p> #networks:  ldap [NOTFOUND=3Dreturn] files<o= :p></o:p> #protocols: ldap [NOTFOUND=3Dreturn] files<o:p></= o:p> #rpc:       ldap [N= OTFOUND=3Dreturn] files<o:p></o:p> #ethers:    ldap [NOTFOUND=3Dretur= n] files<o:p></o:p> <o:p> </o:p> bootparams: files<o:p></o:p> ethers:     files<o:p></o:p><= /p> netmasks:   files<o:p></o:p> networks:   files<o:p></o:p> protocols:  files<o:p></o:p> rpc:        fi= les<o:p></o:p> services:   files<o:p></o:p> netgroup:   files<o:p></o:p> publickey:  files<o:p></o:p> automount:  files<o:p></o:p> aliases:    files<o:p></o:p> [root@ppdoldap01 etc]# uptime<o:p></o:p> 18:02:10 up 230 days, 10:53,  2 users, = load average: 0.95, 0.98, 0.92<o:p></o:p> [root@ppdoldap01 etc]# more nscd.conf<o:p></o:p><= /p> #<o:p></o:p> # /etc/nscd.conf<o:p></o:p> #<o:p></o:p> # An example Name Service Cache config file.&nbsp= ; This file is needed by nscd.<o:p></o:p> #<o:p></o:p> # Legal entries are:<o:p></o:p> #<o:p></o:p> #       logfile&nbs= p;            &= nbsp;   <file><o:p></o:p> #       debug-level=              &l= t;level><o:p></o:p> #       threads&nbs= p;            &= nbsp;   <initial #threads to use><o:p></o:p> #       max-threads=              &l= t;maximum #threads to use><o:p></o:p> #       server-user=              &l= t;user to run server as instead of root><o:p></o:p> #        =        server-user is ignored if nscd is star= ted with -S parameters<o:p></o:p> #       stat-user&n= bsp;           &nbsp= ;  <user who is allowed to request statistics><o:p></o:p> #       reload-coun= t            unlimit= ed|<number><o:p></o:p> #       paranoia&nb= sp;            &nbsp= ;  <yes|no><o:p></o:p> #       restart-int= erval        <time in seconds><o:p= ></o:p> #<o:p></o:p> #       enable-cach= e            <ser= vice> <yes|no><o:p></o:p> #       positive-ti= me-to-live   <service> <time in seconds><o:p></o:p></= p> #       negative-ti= me-to-live   <service> <time in seconds><o:p></o:p></= p> #       suggested-s= ize          <service> &= lt;prime number><o:p></o:p> #       check-files=              &l= t;service> <yes|no><o:p></o:p> #       persistent&= nbsp;           &nbs= p; <service> <yes|no><o:p></o:p> #       shared&nbsp= ;            &n= bsp;    <service> <yes|no><o:p></o:p> #       max-db-size=              &l= t;service> <number bytes><o:p></o:p> #       auto-propag= ate          <service> &= lt;yes|no><o:p></o:p> #<o:p></o:p> # Currently supported cache names (services): pas= swd, group, hosts<o:p></o:p> #<o:p></o:p> <o:p> </o:p> <o:p> </o:p> #       logfile&nbs= p;            &= nbsp;   /var/log/nscd.log<o:p></o:p> #       threads&nbs= p;            &= nbsp;   6<o:p></o:p> #       max-threads=              12= 8<o:p></o:p>        server-= user           &nbsp= ; nscd<o:p></o:p> #       stat-user&n= bsp;           &nbsp= ;  nocpulse<o:p></o:p>         debug-= level           &nbs= p; 0<o:p></o:p> #       reload-coun= t            5<o:p><= /o:p>         parano= ia            &= nbsp;   no<o:p></o:p> #       restart-int= erval        3600<o:p></o:p> <o:p> </o:p>         enable= -cache            pa= sswd          yes<o:p></o:p></= p>         positi= ve-time-to-live   passwd      &nbsp= ;   600<o:p></o:p>         negati= ve-time-to-live   passwd      &nbsp= ;   20<o:p></o:p>         sugges= ted-size          passwd =          211<o:p></o:p>         check-= files           &nbs= p; passwd          yes<o:p></o= :p>         persis= tent           &nbsp= ;  passwd          yes<o:= p></o:p>         shared=             &nb= sp;     passwd      &nbsp= ;   yes<o:p></o:p>         max-db= -size           &nbs= p; passwd          33554432<o:= p></o:p>         auto-p= ropagate          passwd =          yes<o:p></o:p> <o:p> </o:p>         enable= -cache            gr= oup           yes<o:p></o= :p>         positi= ve-time-to-live   group       =     3600<o:p></o:p>         negati= ve-time-to-live   group       =     60<o:p></o:p>         sugges= ted-size          group &= nbsp;         211<o:p></o:p>         check-= files           &nbs= p; group           yes<o:= p></o:p>         persis= tent           &nbsp= ;  group           y= es<o:p></o:p>         shared=             &nb= sp;     group       =     yes<o:p></o:p>         max-db= -size           &nbs= p; group           335544= 32<o:p></o:p>         auto-p= ropagate          group &= nbsp;         yes<o:p></o:p> <o:p> </o:p>         enable= -cache            ho= sts           yes<o:p></o= :p>         positi= ve-time-to-live   hosts       &nbsp= ;   3600<o:p></o:p>         negati= ve-time-to-live   hosts       =     20<o:p></o:p>         sugges= ted-size          hosts &= nbsp;         211<o:p></o:p>         check-= files           &nbs= p; hosts           yes<o:= p></o:p>         persis= tent           &nbsp= ;  hosts           y= es<o:p></o:p>         shared=             &nb= sp;     hosts       =     yes<o:p></o:p>         max-db= -size           &nbs= p; hosts           335544= 32<o:p></o:p> <o:p> </o:p> [etc]# cat libuser.conf<o:p></o:p> # This is a first-generation configuration file.&= nbsp; Eventually I'll rewrite<o:p></o:p> # all of the configuration-reading code to use al= chemist, but for now this<o:p></o:p> # will have to do.<o:p></o:p> <o:p> </o:p> # Do not modify the default module list if you ca= re about unattended calls<o:p></o:p> # to programs (i.e., scripts) working!<o:p></o:p>= <o:p> </o:p> [defaults]<o:p></o:p> # The default (/usr/lib*/libuser) is usually corr= ect<o:p></o:p> # moduledir =3D /your/custom/directory<o:p></o:p>= skeleton =3D /etc/skel<o:p></o:p> mailspooldir =3D /var/mail<o:p></o:p> modules =3D files shadow<o:p></o:p> create_modules =3D files shadow<o:p></o:p> crypt_style =3D md5<o:p></o:p> # modules =3D files shadow ldap krb5<o:p></o:p></= p> # create_modules =3D ldap krb5<o:p></o:p> <o:p> </o:p> [userdefaults]<o:p></o:p> LU_USERNAME =3D %n<o:p></o:p> LU_UIDNUMBER =3D 500<o:p></o:p> LU_GIDNUMBER =3D %u<o:p></o:p> # LU_USERPASSWORD =3D !!<o:p></o:p> # LU_GECOS =3D %n<o:p></o:p> # LU_HOMEDIRECTORY =3D /home/%n<o:p></o:p> # LU_LOGINSHELL =3D /bin/bash<o:p></o:p> <o:p> </o:p> # LU_SHADOWNAME =3D %n<o:p></o:p> # LU_SHADOWPASSWORD =3D !!<o:p></o:p> # LU_SHADOWLASTCHANGE =3D %d<o:p></o:p> # LU_SHADOWMIN =3D 0<o:p></o:p> # LU_SHADOWMAX =3D 99999<o:p></o:p> # LU_SHADOWWARNING =3D 7<o:p></o:p> # LU_SHADOWINACTIVE =3D -1<o:p></o:p> # LU_SHADOWEXPIRE =3D -1<o:p></o:p> # LU_SHADOWFLAG =3D -1<o:p></o:p> <o:p> </o:p> [groupdefaults]<o:p></o:p> LU_GROUPNAME =3D %n<o:p></o:p> LU_GIDNUMBER =3D 500<o:p></o:p> # LU_GROUPPASSWORD =3D !!<o:p></o:p> # LU_MEMBERUID =3D<o:p></o:p> # LU_ADMINISTRATORUID =3D<o:p></o:p> <o:p> </o:p> [files]<o:p></o:p> # This is useful for the case where some master f= iles are used to<o:p></o:p> # populate a different NSS mechanism which this w= orkstation uses.<o:p></o:p> # directory =3D /etc<o:p></o:p> <o:p> </o:p> [shadow]<o:p></o:p> # This is useful for the case where some master f= iles are used to<o:p></o:p> # populate a different NSS mechanism which this w= orkstation uses.<o:p></o:p> # directory =3D /etc<o:p></o:p> <o:p> </o:p> [ldap]<o:p></o:p> # Setting these is always necessary.<o:p></o:p></= p> # server =3D ldap<o:p></o:p> # basedn =3D dc=3Dexample,dc=3Dcom<o:p></o:p> <o:p> </o:p> # Setting these is rarely necessary, since it's u= sually correct.<o:p></o:p> # userBranch =3D ou=3DPeople<o:p></o:p> # groupBranch =3D ou=3DGroup<o:p></o:p> <o:p> </o:p> # Set only if your administrative user uses simpl= e bind operations to<o:p></o:p> # connect to the server.<o:p></o:p> # binddn =3D cn=3DManager,dc=3Dexample,dc=3Dcom<o= :p></o:p> <o:p> </o:p> # Set this only if the default user (as determine= d by SASL) is incorrect<o:p></o:p> # for SASL bind operations.  Usually, it's c= orrect, so you'll rarely need<o:p></o:p> # to set these.<o:p></o:p> # user =3D Manager<o:p></o:p> # authuser =3D Manager<o:p></o:p> <o:p> </o:p> [krb5]<o:p></o:p> # Set this only if it differs from the default in= /etc/krb5.conf.<o:p></o:p> # realm =3D EXAMPLE.COM<o:p></o:p> # Set this only if the default (currentuser/admin= ) will be incorrect.<o:p></o:p> # principal =3D example/admin(a)EXAMPLE.COM<o:p></o= :p> <o:p> </o:p> [sasl]<o:p></o:p> # Set these only if your sasldb is only used by a= particular application, and<o:p></o:p> # in a particular domain.  The default (all = applications, all domains) is<o:p></o:p> # probably correct for most installations.<o:p></= o:p> # appname =3D imap<o:p></o:p> # domain =3D EXAMPLE.COM<o:p></o:p> <o:p> </o:p> -----Original Message----- From: masarati(a)aero.polimi.it [mailto:masarati@aero.polimi.it] Sent: Friday, April 13, 2012 11:22 PM To: VEERASWAMY PALANIAPPAN, NATARRAJAN(VPN) Cc: openldap-its(a)openldap.org Subject: Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file!<= /p> <o:p> </o:p> > Full_Name: Natarrajan<o:p></o:p> > Version: 2.2.13-7.4E<o:p></o:p> > OS: RHEL4.5<o:p></o:p> > URL: <a href=3D"ftp://ftp.openldap.org/incom= ing/">ftp://ftp.openl= dap.org/incoming/</a><o:p></o:p> > Submission from: (NULL) (216.113.168.128)<o:= p></o:p> ><o:p> </o:p> ><o:p> </o:p> > I am getting the following error frequently = in my ldap client machine.<o:p></o:p> ><o:p> </o:p> > LDAPCLIENT ~> whoami<o:p></o:p> > whoami: cannot find name for user ID 14281 L= DAPCLIENT ~> sudo -u qserv <o:p></o:p> > ls<o:p></o:p> > sudo: uid 14281 does not exist in the passwd= file!<o:p></o:p> ><o:p> </o:p> > Let me know the fix for the issue.<o:p></o:p= > <o:p> </o:p> Upgrade (2.2.13 is about 10 years old now; 2.4.30= is the current release).<o:p></o:p> Then, fix the configuration of your nss?<o:p></o:= p> <o:p> </o:p> p.<o:p></o:p> <o:p> </o:p> </div> </body> </html> --_000_4B4F50906B76C1459E6ABD9205FB8DE6A56580RHVEXRDAS51corpeb_--

1 0

Re: (ITS#7229) still not fixed
by michael＠stroeder.com 14 Apr '12

14 Apr '12

hyc(a)symas.com wrote: > Your problem is completely unrelated to ITS#7229, which was about an ENOSPC > error. You're getting ENOMEM, which simply means you've exceeded the > configured size of the DB. Yes, forgot setting maxsize. Sorry. Ciao, Michael.

1 0

Re: (ITS#7229) still not fixed
by hyc＠symas.com 14 Apr '12

14 Apr '12

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms000002080400040504030402 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > HI! > > I'm testing with RE24 (39fb7afe5f5acb48686a41a11ef57aa72a772626) on openS= > USE > 11.4 x86_64 but I'm still getting this error when loading an accesslog DB= > =2E It > is not fixed yet. > > slapadd: could not add entry dn=3D"reqStart=3D20110131134340.000002Z,cn=3D= > accesslog" > (line=3D270877): txn_aborted! Internal error (80) > 4f897bb9 mdb_id2entry_put: mdb_put failed: Cannot allocate memory(12) > "reqStart=3D20110201074944.000001Z,cn=3Daccesslog" Your problem is completely unrelated to ITS#7229, which was about an ENOSPC error. You're getting ENOMEM, which simply means you've exceeded the configured size of the DB. > The problem is that adding most entries does work but the error happens > occasionally no matter whether -q is used or not. > > Ciao, Michael. -- -- 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#7229) still not fixed
by michael＠stroeder.com 14 Apr '12

14 Apr '12

This is a cryptographically signed message in MIME format. --------------ms000002080400040504030402 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HI! I'm testing with RE24 (39fb7afe5f5acb48686a41a11ef57aa72a772626) on openS= USE 11.4 x86_64 but I'm still getting this error when loading an accesslog DB= =2E It is not fixed yet. slapadd: could not add entry dn=3D"reqStart=3D20110131134340.000002Z,cn=3D= accesslog" (line=3D270877): txn_aborted! Internal error (80) 4f897bb9 mdb_id2entry_put: mdb_put failed: Cannot allocate memory(12) "reqStart=3D20110201074944.000001Z,cn=3Daccesslog" The problem is that adding most entries does work but the error happens occasionally no matter whether -q is used or not. Ciao, Michael. --------------ms000002080400040504030402 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxNDEzMzgyOVowIwYJKoZIhvcNAQkEMRYE FKKKmWqR32lsW+TjX16Hc69krw+dMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAbbQYCiOcoNfziXvc8fZxpKVoCT37MQv9Se72yCki6aW7JscIVueaH82mYczG5sba6V94 ayQiMhLeGq+LTlqpN9ZacEm1/SgN8Nfh9NU70F564Zw34YZ78PPVpodxy8e/IB4EX6sV3vaq XGNObPCBUKhMrXIvJ4nmjgzDbDcH9gTxY3WxHfU3JQlzI89s3bwVNVLmb5ET1XEi+3kAbrik CdjO0ysc9abDarLzp9jKkElzVb1Tb3xRygFEyLtPmqfQMktHIhIqUlWkbo3+w9WpoH0obHLd UV9k3F3A7EYSeYVvA9N5mcNcTyDt4SKybNIT9rbMxQzv44DCfJ12MUHXyQAAAAAAAA== --------------ms000002080400040504030402--

1 0

Re: (ITS#7243) sudo: uid 14281 does not exist in the passwd file!
by masarati＠aero.polimi.it 13 Apr '12

13 Apr '12

> Full_Name: Natarrajan > Version: 2.2.13-7.4E > OS: RHEL4.5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (216.113.168.128) > > > I am getting the following error frequently in my ldap client machine. > > LDAPCLIENT ~> whoami > whoami: cannot find name for user ID 14281 > LDAPCLIENT ~> sudo -u qserv ls > sudo: uid 14281 does not exist in the passwd file! > > Let me know the fix for the issue. Upgrade (2.2.13 is about 10 years old now; 2.4.30 is the current release). Then, fix the configuration of your nss? p.

1 0

(ITS#7244) sudo: uid 14281 does not exist in the passwd file!
by napalaniappan＠yahoo.com 13 Apr '12

13 Apr '12

Full_Name: Natarrajan Version: 2.2.13-7.4E OS: RHEL4.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.113.168.128) I am getting the following error frequently in my ldap client machine. LDAPCLIENT ~> whoami whoami: cannot find name for user ID 14281 LDAPCLIENT ~> sudo -u qserv ls sudo: uid 14281 does not exist in the passwd file! Let me know the fix for the issue. Thanks,

1 0

(ITS#7243) sudo: uid 14281 does not exist in the passwd file!
by napalaniappan＠paypal.com 13 Apr '12

13 Apr '12

Full_Name: Natarrajan Version: 2.2.13-7.4E OS: RHEL4.5 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (216.113.168.128) I am getting the following error frequently in my ldap client machine. LDAPCLIENT ~> whoami whoami: cannot find name for user ID 14281 LDAPCLIENT ~> sudo -u qserv ls sudo: uid 14281 does not exist in the passwd file! Let me know the fix for the issue. Thanks,

1 0

Re: (ITS#7242) new -y (Read password from file) does not work
by chris.paul＠rexconsulting.net 13 Apr '12

13 Apr '12

Oh duh. I see now. Thanks! CP On Apr 13, 2012, at 13:59, masarati(a)aero.polimi.it wrote: >> Full_Name: Chris Paul >> Version: ldapsearch 2.4.23 (Dec 7 2011 21:37:03) >> OS: tried both Centos 2.6.32-220.el6.i686 and Cygwin >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (162.119.68.25) >> >> >> I really like the new -y option to read the password from a file but it >> doesn't >> work. Also it broke the old behavior which read it from standard input if >> you >> used -W. >> >> I have a one line password file. I used to use this successfully with a >> command >> like: >> >> $ ldapsearch -x -H $TIM -s sub -b "dc=myorg, dc=org" "(uid=someuid)" uid >> cn < >> ~/.ldappw >> >> Now this command just prompts me for the password. >> >> And when I try -y, it seems that an 0x0a character is added to the >> password >> string (I found this by using tcpdump to capture the packets), so that >> fails >> with "Invalid credentials (49)". > > This is a common user error. The "0x0a" is a newline ('\n') which is > probably present in your file. You need to create a file that contains > exactly the password. For example, to create a file that contains the > password "secret" you need to do > > echo -n "secret" > filename. > > This ITS will be closed. > > p. >

1 0

Re: (ITS#7242) new -y (Read password from file) does not work
by masarati＠aero.polimi.it 13 Apr '12

13 Apr '12

> Full_Name: Chris Paul > Version: ldapsearch 2.4.23 (Dec 7 2011 21:37:03) > OS: tried both Centos 2.6.32-220.el6.i686 and Cygwin > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (162.119.68.25) > > > I really like the new -y option to read the password from a file but it > doesn't > work. Also it broke the old behavior which read it from standard input if > you > used -W. > > I have a one line password file. I used to use this successfully with a > command > like: > > $ ldapsearch -x -H $TIM -s sub -b "dc=myorg, dc=org" "(uid=someuid)" uid > cn < > ~/.ldappw > > Now this command just prompts me for the password. > > And when I try -y, it seems that an 0x0a character is added to the > password > string (I found this by using tcpdump to capture the packets), so that > fails > with "Invalid credentials (49)". This is a common user error. The "0x0a" is a newline ('\n') which is probably present in your file. You need to create a file that contains exactly the password. For example, to create a file that contains the password "secret" you need to do echo -n "secret" > filename. This ITS will be closed. p.

1 0

(ITS#7242) new -y (Read password from file) does not work
by chris.paul＠rexconsulting.net 13 Apr '12

13 Apr '12

Full_Name: Chris Paul Version: ldapsearch 2.4.23 (Dec 7 2011 21:37:03) OS: tried both Centos 2.6.32-220.el6.i686 and Cygwin URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (162.119.68.25) I really like the new -y option to read the password from a file but it doesn't work. Also it broke the old behavior which read it from standard input if you used -W. I have a one line password file. I used to use this successfully with a command like: $ ldapsearch -x -H $TIM -s sub -b "dc=myorg, dc=org" "(uid=someuid)" uid cn < ~/.ldappw Now this command just prompts me for the password. And when I try -y, it seems that an 0x0a character is added to the password string (I found this by using tcpdump to capture the packets), so that fails with "Invalid credentials (49)".

1 0

Re: (ITS#7212) slapmodify support for back-config
by ondrej.kuznik＠acision.com 13 Apr '12

13 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 03/20/2012 11:11 AM, ondrej.kuznik(a)acision.com wrote: > For slapmodify to be usable on a database, that database needs to > implement the bi_tool_dn2id_get and bi_tool_entry_modify > functions, which is not the case of the back-config. I've put > together a minimal (and maybe too naive) implementation of these > for back-config and back-ldif at the above link. Ok, nevermind for now, the implementation was too naive and would break some other things (the slapadd in test005). - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+IMUkACgkQ9GWxeeH+cXtodQCeJdq8IQvH+hWEYTTMt3hn+6UC K20An0uaLb/lmDo6zBJtHm3RL9FMXezq =xnVE -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

Re: (ITS#7088) slapo-accesslog makes OpenLDAP hang
by Pierangelo Masarati 12 Apr '12

12 Apr '12

> The root cause of this bug seems to be related to olcAccessLogOps and > olcAccessLogBase features. If I use one of them to specify I want to log > only "modify" operations: > olcAccessLogOps: modify > or > olcAccessLogBase: modify <suffix> > > Then when I do an "add", slapo-accesslog takes the op_rmutex in > accesslog_op_mod but never release it in accesslog_response. The analysis looks correct. slapo-accesslog(5) was locking the mutex for all write operations, but only releasing it for those that needed to be logged. Should be fixed now in master. Please test. Thanks, p.

1 0

Re: (ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 12 Apr '12

12 Apr '12

> ftp://ftp.openldap.org/incoming/jvcelak-120412-moznss-hostname-check.patch The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7241) [PATCH] unbind: free the socket prior to destroying TLS context
by jvcelak＠redhat.com 12 Apr '12

12 Apr '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-120412-unbind-free-socket-prior-to-… Submission from: (NULL) (209.132.186.34) Hello. I'm proposing uploaded patch which moves ber_sockbuf_free() prior to ldap_int_tls_destroy() in ldap_ld_free(). I sent the reasoning on the openldap-devel list: http://www.openldap.org/lists/openldap-devel/201204/msg00003.html And there is an answer from Howard: http://www.openldap.org/lists/openldap-devel/201204/msg00004.html Please, consider its inclusion. Jan The attached file is derived from OpenLDAP Software. All of the modifications to OpenLDAP Software represented in the following patch(es) were developed by Red Hat. Red Hat has not assigned rights and/or interest in this work to any party. I, Jan Vcelak am authorized by Red Hat, my employer, to release this work under the following terms. Red Hat hereby place the following modifications to OpenLDAP Software (and only these modifications) into the public domain. Hence, these modifications may be freely used and/or redistributed for any purpose with or without attribution and/or other notice.

1 0

(ITS#7240) [PATCH] MozNSS: skip hostname check if peer certificate was not requested
by jvcelak＠redhat.com 12 Apr '12

12 Apr '12

Full_Name: Jan Vcelak Version: git master OS: Linux URL: ftp://ftp.openldap.org/incoming/jvcelak-120412-moznss-hostname-check.patch Submission from: (NULL) (209.132.186.34) Hello. With Mozilla NSS crypto backend, the 'tls_checkpeer no' option in 'sudo' tool does not work. I have uploaded a patch which fixes the bug. But some explanation is necessary: sudo initially creates a ldap handle using ldap_initialize() function. Then it uses ldap_set_option() to set all the settings. The TLS configuration is applied without passing a LDAP handle, which means the the global options are changed. In ldap_int_start_tls(): - The ldap_int_tls_connect() is called and the global TLS context is used (LDAP_INT_GLOBAL_OPT()->ldo_tls_ctx). Which is correct. - The ldap_pvt_tls_check_hostname() is called always. "sudo" will set the ldo_tls_require_cert in global options to LDAP_OPT_X_TLS_NEVER, but the handle options (ld->ld_options) are used to check whether the verification is supposed to happen. And ldo_tls_require_cert in handle options is LDAP_OPT_X_TLS_DEMAND (the default), because it was copied from the global options at the time when ldap_initialize() was called. - With OpenSSL, hostname check (tlso_session_chkhost) will succeed because tlso_get_cert() will return NULL. This is true because no certificate was requested when connecting. We do not request the certificate as well in Mozilla NSS, but it seems that the peer can send it anyway and the library will accept and store it. In this case, hostname check (tlsm_session_chkhost) might fail because SSL_PeerCertificate() will return it. I've added an additional check, which skips the hostname verification within tlsm_session_chkhost if we do not request the certificate validation. With this patch, the behavior is consistent with OpenSSL. (Maybe ldap_pvt_tls_check_hostname() should not just be called, because the global context was used and therefore we should use global options. Not sure what is expected, but I think that changing this might break some applications. My fix is safer.) Jan

1 0

Re: (ITS#7225) back-monitor/ldap crash in test020-proxycache
by ondrej.kuznik＠acision.com 12 Apr '12

12 Apr '12

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 04/04/2012 02:09 PM, h.b.furuseth(a)usit.uio.no wrote: > Full_Name: Hallvard B Furuseth Version: master, > fc1396fa2e94ee2e752fd7c3ea5bb22f6592398a OS: Linux x86_64 URL: > Submission from: (NULL) (129.240.203.186) Submitted by: hallvard > > > back-ldap:ldap_back_monitor_conn_init() calls > monitor_back_register_entry_attrs(,,,nbase=NULL,,) which crashes > at: > > 1093 if ( !BER_BVISNULL( nbase ) ) { > > That checks if nbase->bv_val is NULL, it does not check nbase > itself. Backtrace: > > #0 monitor_back_register_entry_attrs (ndn_in=0x1023d50, > a=0x1092be8, cb=0x10f59b0, nbase=0x0, scope=0, filter=0x0) at > init.c:1093 #1 ldap_back_monitor_conn_init (be=0x104d0c0, > ms=0x1023d28) at monitor.c:658 #2 monitor_back_db_open > (be=0x104d0c0, cr=0x7fff704846e0) at init.c:2365 #3 > backend_startup_one (be=0x104d0c0, cr=0x7fff704846e0) at > backend.c:224 #4 backend_startup (be=0x104d0c0) at backend.c:325 #5 > slap_startup (be=0x0) at init.c:219 I prepared a patch mentioned in the -devel mailing list for the remaining issue not yet fixed in master. - -- Ondrej Kuznik -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+Gsb8ACgkQ9GWxeeH+cXvTvgCfeIIljtQv7XahXE9P2aocg+xu oWoAn0zvQVQ6x3PnL3IhL2SWMo1iSKWo =NZ52 -----END PGP SIGNATURE----- This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you for understanding.

1 0

ITS#7239
by michael＠stroeder.com 12 Apr '12

12 Apr '12

This is a cryptographically signed message in MIME format. --------------ms020908090503080200050809 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable It seems that 'logops all' only fails if an entry is renamed which has an= RDN attribute which is check by slapo-unique. It seems slapo-unique's interna= l search is also logged to accesslog DB. Is that correct behaviour? So this combination does *not* work: ----------------------------------- overlay unique unique_attributes uid overlay accesslog logdb "cn=3Daccesslog" logops all ----------------------------------- This combination works correctly: ----------------------------------- overlay unique unique_attributes uid overlay accesslog logdb "cn=3Daccesslog" logops writes session ----------------------------------- --------------ms020908090503080200050809 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMjA3NTUxOFowIwYJKoZIhvcNAQkEMRYE FNS0/62yD9dzyzS3EyhbuMy09iM7MF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAKMtTuAEUZMWoCtepWolUde61WnPI+6pmWV/PUVJHHx2jvQHE4CTRI10LzG9MDp371Hf9 PhsFUamF1uEZ7zq7uFHqT8ry3Ku4aKZuIWOnaY8qZxPZTGkkeP6krmJwye/FFsldwNo1iQnl goNRG1PmCkAN2J9cVyUSd+2Ls388sSaThAhUZBvRknF8UbOCMazw8gWNypCSR2euR+0DJhhf kUD6YsQvPpe4eWi6ZIb4nhy1UDqxvWeOnnD2j0Ryg5eixL41DLGjfhwsV8GwMqjkBoFEsEec /yjo46BvN6YX5Ow9SGoy2eYbZo6K2aLZ23OvYsiqgRn/k13R71QPht/4eAAAAAAAAA== --------------ms020908090503080200050809--

1 0

Re: (ITS#6656) logging "reqEntryUUID" in accesslog
by michael＠stroeder.com 12 Apr '12

12 Apr '12

This is a cryptographically signed message in MIME format. --------------ms030601000506050202050204 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable masarati(a)aero.polimi.it wrote: >> Please revisit this ITS. I'd like to implement something like "svn rev= ert=3D >> " >> based on accesslog entries. Having the entry's UUID in an indexable at= tri=3D >> bute >> would make this more robust. >> >> This could also be handy for delta-replication if "conflicting" modrdn= >> requests were sent by a client which result in same reqDN. >=20 > Added to master, please test. Thanks. Seems to work. Added support for it in upcoming web2ldap 1.1.12...(searching the accessl= og entries and reverse searching the target entries). Ciao, Michael. --------------ms030601000506050202050204 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQxMjA3NTUxMlowIwYJKoZIhvcNAQkEMRYE FKAXr449YjNzkPdvkc1ruZoD11dbMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAxBqZadPfILnU/3+CI04Q803WcBUbQGGWz1rp9t4aWjOpnDmXwSfoG5kJ+qKJLvo5SGqy CtvlizF3xkVjB4qZJo0x5wRKAV0a8it7YqQbQpwpMC8YX74qJZY0f+3W83WJYiXgLEelkL2p 9AwRnwQS3+MRz5FrO5O7Xr/9csrribOkhJAbEQ+LR4CUNAcNttqkpWeUQ9J4bgW6gUgf7sQ4 SAC3devBI3u1vFxZl7yP8E3H3QQcm9eElvzGIRkX+2aRv2MKev+UzMAO+icTZTl21lnjgAnz KqAYWjKh3FXVoc8RUvMrl5yEuwuc09UV+rQjZmYenHQcWvhauEVOdy46OAAAAAAAAA== --------------ms030601000506050202050204--

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 11 Apr '12

11 Apr '12

This is a multi-part message in MIME format. --------------040402080004020608060006 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 09.04.2012 20:09, Hrvoje Habjanić wrote: > > Hi. > > Two more "hang"s, both in sched_yield(). This is with replacement malloc > (tcmalloc, minimal). > > http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang4.log > http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang5.log > > H. Hi. Attached patch if solving my proglem with "hang" in sched_yield. In general, i do think that there (cache management) is a lot of unnecessary locking and waiting ... And simplifying things there would solve a lot of problems ... Probably. :-) Of course, i'm not shure how will this change influence the rest of the code, but it does work for me (tm). H. p.s. Also available at http://free-zg.t-com.hr/HrvojeHabjanic/openldap/ol.diff --------------040402080004020608060006 Content-Type: text/x-patch; name="ol.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="ol.diff" diff -Nru openldap-d7d1789-org/servers/slapd/back-bdb/cache.c openldap-d7d1789/servers/slapd/back-bdb/cache.c --- openldap-d7d1789-org/servers/slapd/back-bdb/cache.c 2012-04-10 00:47:23.000000000 +0200 +++ openldap-d7d1789/servers/slapd/back-bdb/cache.c 2012-04-11 10:23:43.267461183 +0200 @@ -1361,7 +1361,7 @@ DB_LOCK *lock ) { EntryInfo *ei = BEI(e); - int rc, busy = 0; + int rc, busy = 0, counter = 0; assert( e->e_private != NULL ); @@ -1378,7 +1378,7 @@ bdb_cache_entryinfo_unlock( ei ); - while ( busy ) { + while ( busy && counter < 1000) { ldap_pvt_thread_yield(); busy = 0; bdb_cache_entryinfo_lock( ei ); @@ -1387,6 +1387,13 @@ ei->bei_finders > 0 ) busy = 1; bdb_cache_entryinfo_unlock( ei ); + counter ++; + } + if( busy ) { + bdb_cache_entryinfo_lock( ei ); + ei->bei_state ^= CACHE_ENTRY_DELETED; + bdb_cache_entryinfo_unlock( ei ); + return DB_LOCK_DEADLOCK; } /* Get write lock on the data */ --------------040402080004020608060006--

1 0

Re: ITS#6598
by masarati＠aero.polimi.it 11 Apr '12

11 Apr '12

> --On Saturday, February 18, 2012 12:41 AM +0000 quanah(a)zimbra.com wrote: > >> --On Saturday, February 18, 2012 1:32 AM +0100 masarati(a)aero.polimi.it >> wrote: > >> ah, ok thanks. :) > > > Any particularly reason why the control can't be made critical? No. Now it can. p.

1 0

Re: (ITS#6656) logging "reqEntryUUID" in accesslog
by masarati＠aero.polimi.it 10 Apr '12

10 Apr '12

> Please revisit this ITS. I'd like to implement something like "svn revert= > " > based on accesslog entries. Having the entry's UUID in an indexable attri= > bute > would make this more robust. > > This could also be handy for delta-replication if "conflicting" modrdn > requests were sent by a client which result in same reqDN. Added to master, please test. p.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 10 Apr '12

10 Apr '12

On 4/9/2012 3:42 PM, masarati(a)aero.polimi.it wrote: > I have checked this case (I suspect the same could happen in other schema > items) and I'm about to commit a fix. > Will this be part of 2.4.31? Thank you for the fix!

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> On 4/9/2012 7:01 AM, masarati(a)aero.polimi.it wrote: >>> On 4/6/2012 10:22 AM, Howard Chu wrote: >>>> Find out why oc->oc_names is NULL. It should not be. Seems like you >>>> have an invalid schema definition. >>>> >>> I have fixed the objectClasses that were violating by adding >>> "extensibleObject". >> ObjectClass with OID '1.3.6.1.4.1.6152.10.3.2.16'. Can you provide its >> definition? Apparently, oc_names is NULL, i.e. no names are defined for >> that class. >> > Here is the object class definition. > > Few things to note: > 1. I had added this class temporarily (before I added extensibleObject). > 2. I had forgotten to remove this definition from the schema, after > adding extensibleObject. > > objectclass ( 1.3.6.1.4.1.6152.10.3.2.16 > NAME 'sendmailMTAMAPAlias' > SUP ( sendmailMTAAliasObject $ sendmailMTAMAPObject ) STRUCTURAL > DESC 'Sendmail MTA map alias definition' ) > > > 3. I am re-running the slapadd, without this schema. > > (Will update the bug with more info then) I have created something similar (a structural class inheriting from two existing ones) and I couldn't reproduce your issue. However, I could exactly reproduce it by entirely removing the "NAME 'sendmailMTAMAPAlias'" portion, so I suspect you were using something like that. Slapd is accepting such definition (which I believe is at least bad practice, but it should be legal as we only complain about missing OID). I have checked this case (I suspect the same could happen in other schema items) and I'm about to commit a fix. p.

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by ashish＠sendmail.com 09 Apr '12

09 Apr '12

On 4/9/2012 7:01 AM, masarati(a)aero.polimi.it wrote: >> On 4/6/2012 10:22 AM, Howard Chu wrote: >>> Find out why oc->oc_names is NULL. It should not be. Seems like you >>> have an invalid schema definition. >>> >> I have fixed the objectClasses that were violating by adding >> "extensibleObject". > ObjectClass with OID '1.3.6.1.4.1.6152.10.3.2.16'. Can you provide its > definition? Apparently, oc_names is NULL, i.e. no names are defined for > that class. > Here is the object class definition. Few things to note: 1. I had added this class temporarily (before I added extensibleObject). 2. I had forgotten to remove this definition from the schema, after adding extensibleObject. objectclass ( 1.3.6.1.4.1.6152.10.3.2.16 NAME 'sendmailMTAMAPAlias' SUP ( sendmailMTAAliasObject $ sendmailMTAMAPObject ) STRUCTURAL DESC 'Sendmail MTA map alias definition' ) 3. I am re-running the slapadd, without this schema. (Will update the bug with more info then)

1 0

Re: (ITS#7222) Slapd hangs on high load
by hrvoje.habjanic＠zg.t-com.hr 09 Apr '12

09 Apr '12

On 08.04.2012 13:25, Hrvoje Habjanić wrote: > On 04.04.2012 17:45, Hrvoje Habjanić wrote: >> On 03.04.2012 17:41, Howard Chu wrote: >>> You may be able to avoid this bug by using an alternate malloc >>> library, such as Google tcmalloc. >>> >> Hi. >> >> I did try - using tcmalloc. And this time, i got SIGSEGV. Odd thing is >> that this happened in "pthread_mutex_lock" which is in libpthread.so ...? >> >> Another bug in centos libs? I would appreciate if you could take a look. >> >> Thx. >> >> H. >> >> p.s. url -> http://free-zg.t-com.hr/HrvojeHabjanic/hang3.log > Hi. Two more "hang"s, both in sched_yield(). This is with replacement malloc (tcmalloc, minimal). http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang4.log http://free-zg.t-com.hr/HrvojeHabjanic/openldap/hang5.log H.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by hyc＠symas.com 09 Apr '12

09 Apr '12

michael(a)stroeder.com wrote: > This is a cryptographically signed message in MIME format. > > --------------ms000408080902010107050201 > Content-Type: text/plain; charset=ISO-8859-1 > Content-Transfer-Encoding: quoted-printable > > masarati(a)aero.polimi.it wrote: >> In general, I also prefer to have NO matching rules associated to attrs= > >> designed for purposes that do not require matching > > Why? > > As said it's useful for collision detection in case of a modify. So at le= > ast > every multi-valued attribute should have an EQUALITY matching rule. Every multi-valued attribute already does. They would be unusable otherwise. This discussion is only about single-valued config attributes. -- -- 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#7226) olcAuditlogFile At dos not accept multiple values
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> masarati(a)aero.polimi.it wrote: >> In general, I also prefer to have NO matching rules associated to attrs >> designed for purposes that do not require matching > > Why? In general, configuring a system means to write something as a whole, not bit by bit, since it works as intended only when everything is in place. Changing a small bit can have unexpected semantic impact. There are exceptions (either theoretically, or practically). For example, ACLs: occasionally one needs to tweak ACLs (in this case, small modifications can have tremendous impact on the functionality of totally unrelated parts as well), but ACLs need to evolve and adapt to needs. Another example are indexes. Nonetheless, I believe the best way to modify ACLs is through "replace". Fortunately, the most important aspect of ACLs is their order; in this case, the administrator can leverage the X-ORDERED feature. For exceptions, and for all attrs that may legitimately need to be routinely modified, I concur having a well-defined matching rule is helpful. > As said it's useful for collision detection in case of a modify. So at > least > every multi-valued attribute should have an EQUALITY matching rule. "replace" is your friend when managing configuration. > If in doubt which matching rule to use one could choose the stricter one > as > default, e.g. prefer caseExact over caseIgnore. Well, I'm afraid there will always be someone complaining because we chose caseExact instead of caseIgnore. Of course, my 2c. p.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by michael＠stroeder.com 09 Apr '12

09 Apr '12

This is a cryptographically signed message in MIME format. --------------ms000408080902010107050201 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable masarati(a)aero.polimi.it wrote: > In general, I also prefer to have NO matching rules associated to attrs= > designed for purposes that do not require matching Why? As said it's useful for collision detection in case of a modify. So at le= ast every multi-valued attribute should have an EQUALITY matching rule. If in doubt which matching rule to use one could choose the stricter one = as default, e.g. prefer caseExact over caseIgnore. Ciao, Michael. --------------ms000408080902010107050201 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIFOzCC BTcwggMfoAMCAQICAwl4kDANBgkqhkiG9w0BAQUFADB5MRAwDgYDVQQKEwdSb290IENBMR4w HAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcxIjAgBgNVBAMTGUNBIENlcnQgU2lnbmlu ZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1cHBvcnRAY2FjZXJ0Lm9yZzAeFw0xMDEx MTcxNTQzMzFaFw0xMjExMTYxNTQzMzFaMD8xGDAWBgNVBAMUD01pY2hhZWwgU3Ry9mRlcjEj MCEGCSqGSIb3DQEJARYUbWljaGFlbEBzdHJvZWRlci5jb20wggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDo2SKth5GhtaDrCyfGtyUG+/hAAa/J52L0NFN4SSRvTtdGf9HfWwwd NCtgae0TVGWk2lKDbXA9d5vmyIiRhuwxd90H6FLErhRBeB9G67qtw87E8WUoXt2DwPQEUTWV hqHpPadlmgFw3+i3TGQQTe3O3W9MMMd4GJNhObem2VGRuCD37OXnzBksTcq0FPJgcWAhe3d/ 0ItOkNWBqgq8Mf3p7WFBhaQ0a27BC/mKtH8fI3kPcS305imPRja69Msq3EwUZBc9ToVp6FRQ NYKjfOBybDUzVkmRZl3H8xutQP2w8Zxb8m5f7Q1BfLLrIFScfYvIDgOERxTCd4lab8+/09XH AgMBAAGjggEAMIH9MAwGA1UdEwEB/wQCMAAwVgYJYIZIAYb4QgENBEkWR1RvIGdldCB5b3Vy IG93biBjZXJ0aWZpY2F0ZSBmb3IgRlJFRSBoZWFkIG92ZXIgdG8gaHR0cDovL3d3dy5DQWNl cnQub3JnMEAGA1UdJQQ5MDcGCCsGAQUFBwMEBggrBgEFBQcDAgYKKwYBBAGCNwoDBAYKKwYB BAGCNwoDAwYJYIZIAYb4QgQBMDIGCCsGAQUFBwEBBCYwJDAiBggrBgEFBQcwAYYWaHR0cDov L29jc3AuY2FjZXJ0Lm9yZzAfBgNVHREEGDAWgRRtaWNoYWVsQHN0cm9lZGVyLmNvbTANBgkq hkiG9w0BAQUFAAOCAgEANPf/aLF41eQlvN5dEg3CFnlN//qQK7+EPIXLnHprNWLb4nBwgdPj /E+qa1umT7px4Py3VS0UTKqLmMdWftwid8MOMHWalZwrfx0Z8U3He+EdJhOSnn9vdd/ug7Xd dI/hRjLaBSq9ZhCczEUgL6vTxCYPlIoHF56y/oxSJw59vRBjvRFKXvpBZWseeRkcGACQduNH SNdWC1IqHAbQlgOS9VWQUYlm//BdaLkezRxqnQp5+KJMAcZzHpdNJ3G4SqCJ02Z3n4kk8IKZ AjgiWxisDFNsfXKDb9Ng5ntnnH2ouxrgPoNnW445tgkz50VKHstylx9s5O3G7uUTtg0J+z63 TA8xbN6kzRx7RgAUkEXhl6WEdW+3EVj5tYY38Uy8vleP+gYZfphKEmQJgIQqy9D2+gesbolT QdWYgbUYY2AHJOshskMW7pahYnFX2pZmn/ayaPc+JFJlCEqO0+DcYQjYuv6sntQgZGkok7yZ R4xMbyCp61pTrfGWOufZs/FiScJZg1IWY5qb4URH4VZZjLNMR2pFMRuE4LvgkkMRasbUv7Yv n3Lzv34lTfJKUqYW6nx//L2NS4rN63o0taPwRygnuBK4kp7EYEcwtLeanJhQoIu4b6If9rwy D7CFAp51wIewV9VtZ1Is0irNBcMVyhJogIcuIn+VWY1ff1RxySD/djMxggOUMIIDkAIBATCB gDB5MRAwDgYDVQQKEwdSb290IENBMR4wHAYDVQQLExVodHRwOi8vd3d3LmNhY2VydC5vcmcx IjAgBgNVBAMTGUNBIENlcnQgU2lnbmluZyBBdXRob3JpdHkxITAfBgkqhkiG9w0BCQEWEnN1 cHBvcnRAY2FjZXJ0Lm9yZwIDCXiQMAkGBSsOAwIaBQCgggHoMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDQwOTE0MDMzN1owIwYJKoZIhvcNAQkEMRYE FA/Qy+ARPwJkPevCeC+L6wyIRj0kMF8GCSqGSIb3DQEJDzFSMFAwCwYJYIZIAWUDBAECMAoG CCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIBQDAHBgUrDgMCBzANBggq hkiG9w0DAgIBKDCBkQYJKwYBBAGCNxAEMYGDMIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAc BgNVBAsTFWh0dHA6Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5n IEF1dGhvcml0eTEhMB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwgZMG CyqGSIb3DQEJEAILMYGDoIGAMHkxEDAOBgNVBAoTB1Jvb3QgQ0ExHjAcBgNVBAsTFWh0dHA6 Ly93d3cuY2FjZXJ0Lm9yZzEiMCAGA1UEAxMZQ0EgQ2VydCBTaWduaW5nIEF1dGhvcml0eTEh MB8GCSqGSIb3DQEJARYSc3VwcG9ydEBjYWNlcnQub3JnAgMJeJAwDQYJKoZIhvcNAQEBBQAE ggEAGTlcNhwACV1MtWV3357kkJD4g8XzJiMqBalX91sbDNJB1nMxa0T7bL/9EjphF2x848kZ cigt+EvFku6zt2zYTfhtmO4BS2kapufb5FeWfZ0YhBUFHJapvs91bLo07zkeW22Q2JxEbMhc YFAiulZZz8IunikRpC8HT5tFfj/lbdskKllS7Y7p/4lBjyOf/a98+wKLPLt4AhDG6oIDufSr slldCFo6EQ5Gtj6CoF821/No4zIQRWVjjtx1Xzdy6ie395ebvejF1WuX+vIkbTbSPwR4HAF7 zgrUr5tXwI9W1N/nrYQ1eRLuZ3r4Aot/5CxqJ5UtZntIfXx+RWXZ2TE4hQAAAAAAAA== --------------ms000408080902010107050201--

1 0

Re: (ITS#7224) Core dump while trying to run slapd
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> On 4/6/2012 10:22 AM, Howard Chu wrote: >> >> Find out why oc->oc_names is NULL. It should not be. Seems like you >> have an invalid schema definition. >> > I have fixed the objectClasses that were violating by adding > "extensibleObject". ObjectClass with OID '1.3.6.1.4.1.6152.10.3.2.16'. Can you provide its definition? Apparently, oc_names is NULL, i.e. no names are defined for that class. > Also, the slapadd-ing should not "core", and give the right error message. Allowing us to reproduce and fix the issue would help us prevent issues like this. p.

1 0

Re: (ITS#7226) olcAuditlogFile At dos not accept multiple values
by masarati＠aero.polimi.it 09 Apr '12

09 Apr '12

> quanah(a)zimbra.com wrote: >> --On Thursday, April 05, 2012 7:38 PM +0000 h.b.furuseth(a)usit.uio.no >> wrote: >> >>> On Thu, 5 Apr 2012 13:12:31 GMT, michael(a)stroeder.com wrote: >>>> hyc(a)symas.com wrote: >>>>> michael(a)stroeder.com wrote: >>>>>> 2. add an equality matching rule. >>>>> >>>>> My approach with config attrs has been to skip the equality rule for >>>>> single-valued attrs. Since they are single-valued, there's obviously >>>>> no need >>>>> to allow for comparing multiple values. >>> >>> Users always find more ways to use a feature than its creator >>> imagined. >>> >>> I wish people would give attributes all matching rules they can. >>> Equality, ordering, substring. Except when: >>> - flexibility would be a misfeature, e.g. SUBSTR for userPassword, >>> - or it's unclear which rules to choose, e.g. caseIgnore vs >>> caseExact. >> >> I agree. I think defining matching rules where possible is extremely >> useful. > > Patch welcome. This is a pretty trivial patch to write, but I have more > urgent > things to attend to. In general, I also prefer to have NO matching rules associated to attrs designed for purposes that do not require matching (this is often the case of configuration-specific attributes mostly if not only intended for internal use). Whenever one needs to search them, extensible filtering is your friend. p.

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs