openldap-devel

openldap-devel@openldap.org

1416 discussions

Some "long" standing ITSes
by masarati＠aero.polimi.it 19 Apr '10

19 Apr '10

I think there are a few "long" standing ITSes, or candidate ones, that need some discussion as they have -devel implications. ITS#6505: add "const" to attrs in libldap search API: not a big deal, it would change a consolidated API, but the change should be harmless. ITS#6482: the issue is not easily reproducible; the proposed patch sounds a bit naive; perhaps bi_tool_entry_next() could be strengthened by trying a bit harder to get the next ID. Not sure how, the first guess would be to increment the last ID and use DB_SET instead of DB_NEXT until something is found (as naive as the proposed one). Suggestions for better strategies? In any case, I think backend-specific issues should be hidden in the backend tool helpers rather than attempted by slaptools themselves. ITS#6477: the reported case story can be dealt with by detecting the error and re-running slaptest with -d; however, there might be cases where the exact knowledge of the cause of a TLS error may be useful in syslog's logs; this would require to change the way those errors are logged by the client library. Comments? p.

2 1

Re: commit: ldap/servers/slapd syncrepl.c
by masarati＠aero.polimi.it 19 Apr '10

19 Apr '10

> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > syncrepl.c 1.505 -> 1.506 > > Log Message: > alreadyExists is a legitimate result code (further improve ITS#6472 > commit; also fix ITS#6528) Two comments: 1) syncrepl_add_glue() and syncrepl_add_glue_ancestors() should be renamed slapd_add_glue() and slapd_add_glue_ancestors(); the latter should be exposed as well, as it may be useful to other modules. 2) syncrepl_add_glue_ancestors() returning alreadyExists when the immediate parent entry exists is pointless, as it does not indicate an error, while the existence of a non-immediate ancestor would not be notified to the caller. BTW, this caused ITS#6528 (my fault, of course). p.

2 2

Re: commit: ldap/servers/slapd/back-ldap chain.c
by masarati＠aero.polimi.it 15 Apr '10

15 Apr '10

> Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/back-ldap > > Modified Files: > chain.c 1.76 -> 1.77 > > Log Message: > add support for don't use copy in SASL auxprops lookup/store (ITS#6475; > TODO: document new directives) Please note that the relatively minor modifications to slapo-chain(5) are not conditioned on #define SLAP_AUXPROP_DONTUSECOPY, because I think they are generally useful, and I've checked they don't break anything (I could check so far). Please report any inconvenience. p.

1 0

Re: commit: ldap/servers/slapd sl_malloc.c zn_malloc.c
by Quanah Gibson-Mount 15 Apr '10

15 Apr '10

--On Friday, January 15, 2010 5:53 PM +0000 hallvard(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > sl_malloc.c 1.67 -> 1.68 > zn_malloc.c 1.14 -> 1.15 > > Log Message: > Gentler message when falling back to ch_malloc > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/ > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/sl_malloc.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/zn_malloc.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. The new error message doesn't make sense, English wise. It doesn't even parse. - "slap_sl_malloc of %lu bytes failed, using ch_malloc\n", + "slap_sl_malloc of %lu bytes falling back to ch_malloc\n", I.e., what would get logged is: slap_sl_malloc of 700 bytes falling back to ch_malloc Which really gives the end user no idea what is wrong. I would suggest something like: + "slap_sl_malloc of %lu bytes failed, falling back to ch_malloc\n", Similar with the slap_zn_malloc error message. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 2

Re: commit: ldap/libraries/libldap tls.c
by Quanah Gibson-Mount 14 Apr '10

14 Apr '10

--On Sunday, January 24, 2010 6:16 PM +0000 ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/libraries/libldap > > Modified Files: > tls.c 1.167 -> 1.168 > > Log Message: > skip the serial, whatever its length (ITS#6460) > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/ > http://www.openldap.org/devel/cvsweb.cgi/libraries/libldap/tls.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. This fix is wrong. tls.c is deprecated and no longer used. In RE24, there is: tls2.c tls_g.c (gnutls) tls_m.c (moznss) tls_o.c (openssl) I am re-opening the ITS. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

nssov change proposal
by Kean Johnston 14 Apr '10

14 Apr '10

If this is the incorrect list to discuss nssov on please accept my apologies and point me in the right direction. the docs don't indicate a better place. First let me start with saying what I am trying to achieve. If there is an alternate way to do this using memberof/dynlist I have not been able to figure it out. I am trying to get host access based on group membership working. Consider the following definition for 2 hosts: dn: cn=host1,ou=hosts,dc=example,dc=com objectClass: ipHost objectClass: myHostAccessObject cn: host1 ipHostNumber: 10.1.2.3 hostAccessGroup: admins hostAccessGroup: dbas authorizedService: sshd dn: cn=host2,ou=hosts,dc=example,dc=com objectClass: ipHost objectClass: myHostAccessObject cn: host2 ipHostNumber: 10.2.3.4 hostAccessGroup: hrpeople hostAccessGroup: dbas authorizedService: sshd The hostAccessGroup refers to the name of a group whose users can access the machine. For example: dn: cn=admins,ou=access,dc=example,dc=com objectClass: groupOfNames cn: admins member: uid=user1,ou=people,dc=example,dc=com member: uid=user2,ou=people,dc=example,dc=com dn: cn=dbas,ou=access,dc=example,dc=com objectClass: groupOfNames cn: dbas member: uid=user1,ou=people,dc=example,dc=com member: uid=user3,ou=people,dc=example,dc=com dn: cn=hrpeople,ou=access,dc=example,dc=com objectClass: groupOfNames cn: hrpeople member: uid=user1,ou=people,dc=example,dc=com member: uid=user4,ou=people,dc=example,dc=com Given the above, user1, user2 and user3 will be able to access host1, and user1 and user4 will be able to access host2. It seems to me access based on group membership should be easy to do but I have struggled with it immensely. I am new to LDAP so it is most likely a lack of knowledge on my behalf but I have done a lot of research and have not been able to find a way to do what I want. I know the nssov documentation says the prefered mechanism is to use hostservice, and I would like to, but I can't see how to create an ACL that would implement the above. An alternative would be to use some existing group entry, such as a posixGroup but that has even more complications as the memberUid is just the UID and not a DN for a person. Given that I can't see a way I would like to propose either extending nssov or perhaps writing a dynacl module that could help implement this. Before I rush off and attempt a design I would like input from this list to see if you think its a worthwhile idea. Thank you for your time. Kean.

3 3

Possible bug in acl.c
by Kean Johnston 13 Apr '10

13 Apr '10

Assumption: the following ACL should result in $0 being expanded for the set: access to dn.one="ou=hosts,dc=example,dc=com" attrs=authorizedService by set.expand="[cn=access,$0]/member* & user" compare by * =rsdx break Reason for assumption: man slapd.access states: Forms of the <what> clause other than regex may provide submatches as well. The base(object), the sub(tree), the one(level), and the chil- dren forms provide $0 as the match of the entire string. The sub(tree), the one(level), and the children forms also provide $1 as the match of the rightmost part of the DN as defined in the <what> clause. Bug: does not work as expected. The reason is that in slap.h slap_style_t starts with ACL_STYLE_REGEX = 0, so any structure that uses slap_style_t and uses memset to null out the structure will have its default style be ACL_STYLE_REGEX. In acl.c there are 4 places where you test for ACL_STYLE_REGEX on a->acl_attrval_style without checking if an actual attribute value was supplied. The patch below fixes those cases. The better (arguably) fix would be to change slap_style_t to start with ACL_STYLE_NONE = 0, and then explicitly set the style when it is encountered in aclparse.c. However, I did not want to change slap.h in case it changes some ABI and the change to aclparse.c is larger. As things currently stand, dn.expand, set.expand and group.expand will not expand $0 and $1 as documented if you use dn.{base,one,sub,children} in the what clause. If my assumptions are correct and this should work, I will file a proper bug in ITS. Kean --- acl.c.jkj 2010-04-13 07:06:12.000000000 -0500 +++ acl.c 2010-04-13 07:09:56.000000000 -0500 @@ -794,7 +794,8 @@ MATCHES_MEMSET( &tmp_matches ); tmp_data = &tmp_matches.dn_data[0]; - if ( a->acl_attrval_style == ACL_STYLE_REGEX ) + if ( a->acl_attrval.bv_len && + ( a->acl_attrval_style == ACL_STYLE_REGEX ) ) tmp_matchesp = matches; else switch ( a->acl_dn_style ) { case ACL_STYLE_REGEX: @@ -861,7 +862,8 @@ bv.bv_val = buf; /* Expand value regex */ - if ( a->acl_attrval_style == ACL_STYLE_REGEX ) + if ( a->acl_attrval.bv_len && + ( a->acl_attrval_style == ACL_STYLE_REGEX ) ) tmp_matchesp = matches; else switch ( a->acl_dn_style ) { case ACL_STYLE_REGEX: @@ -1548,7 +1550,8 @@ rc = 0; - if ( a->acl_attrval_style == ACL_STYLE_REGEX ) + if ( a->acl_attrval.bv_len && + ( a->acl_attrval_style == ACL_STYLE_REGEX ) ) tmp_matchesp = matches; else switch ( a->acl_dn_style ) { case ACL_STYLE_REGEX: @@ -1638,7 +1641,8 @@ rc = 0; - if ( a->acl_attrval_style == ACL_STYLE_REGEX ) + if ( a->acl_attrval.bv_len && + ( a->acl_attrval_style == ACL_STYLE_REGEX ) ) tmp_matchesp = matches; else switch ( a->acl_dn_style ) { case ACL_STYLE_REGEX:

1 0

back-perl config
by Howard Chu 11 Apr '10

11 Apr '10

back-perl has not been migrated to support cn=config yet. Conversion looks pretty straightforward, but for one detail. Currently slapd.conf will send any unrecognized keywords to the perl module's config handler to give it a chance to implement whatever it needs. I suggest adding a new perlconfig keyword for this purpose instead. Also, it's not clear that we have any way to convey dynamic config changes (mainly deletes) to the perl module. Suggestions? -- -- 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

Fwd: [Berkeley DB Announce] Berkeley DB 11gR2 (11.2.5.0.21) - New Release, Major Revision
by Howard Chu 01 Apr '10

01 Apr '10

Looks like the major addition is the SQLite work-alike API. Not much of interest to us here, possibly some of the lock bugs they fixed may be relevant. -------- Original Message -------- Subject: [Berkeley DB Announce] Berkeley DB 11gR2 (11.2.5.0.21) - New Release, Major Revision Date: Wed, 31 Mar 2010 14:17:56 -0700 (PDT) From: Announcements related to the Berkeley DB product family. <bdb(a)oracle.com> Reply-To: bdb(a)oss.oracle.com To: bdb(a)oss.oracle.com Berkeley DB 11gR2 (11.2.5.0.21) http://www.oracle.com/database/berkeley-db/ http://www.oracle.com/technology/products/berkeley-db/ http://www.oracle.com/technology/products/berkeley-db/sql.html Berkeley DB 11gR2 (11.2.5.0.21) is a major new release. Berkeley DB now includes a SQL API for relational data storage based on SQLite. This release uses the Oracle standard marketing naming (11gR2), however the revision number's last three components map to the historic versioning pattern (5.0.21) to help maintain consistency. NEW IN THIS RELEASE: * SQL * SQL/Relational access via integration with SQLite * Support for SQL92, ODBC and JDBC * Drop-in replacement for any SQLite-based solution * New Documentation covering the SQL API * SQL Performance * 10s of thousands of INSERTS/UPDATES/DELETES per-second * 100s of thousands of SELECTs per-second * Approximately as fast as SQLite for reads (within 10%) * About 3X faster than SQLite for updates/writes * Has fine grained locking which leads to better read/write concurrency * 6-8x more transactions/second compared to SQLite when using multiple threads * Other Features * Support for DTrace/SystemTap performance monitoring * Automatic resource management: close open database and cursor handles on environment close * Transaction priorities * Compact to reclaim unused spaces in hash databases to match similar existing feature for btrees * Log file portability across different endian machines * High Availability * Client-to-client synchronization * Read-after-write consistency on replicas * Integration with other Oracle Products * Synchronization with Oracle Database Server using Oracle Mobile Sync Server The complete list of changes can also be found in the change log page. http://www.oracle.com/technology/documentation/berkeley-db/db/installation/… QUOTES: "Oracle Berkeley DB 11gR2 combines seamlessly the benefits of SQLite's ubiquitous API with Berkeley DB's concurrency and performance into an easy-to-use product. SQLite users can now benefit from enhanced concurrency and performance, and Oracle Berkeley DB users can now benefit from an easy-to-use SQL API." - Dr. Richard Hipp, architect, SQLite "Berkeley DB's new SQLite-compatible SQL API offers powerful features not only for its users but to the SQLite community at large. Berkeley DB developers now have a proven embedded SQL engine to make application development even easier. SQLite users now have the option of a powerful, industry-supported storage engine that is built from the ground up for high-concurrency, and which includes powerful features like built-in replication and hot backups. The combination of the two technologies provides all developers with tremendous flexibility in that a single SQL/API can now be used across a broad spectrum of applications ranging from the embedded space all the way up to large-scale transaction processing. Oracle has done a fantastic job of not only integrating the technologies, but also being an exemplary participant in the open source community by contributing time, expertise and resources to the SQLite project." - Mike Owens, author of "The Definitive Guide to SQLite" "Berkeley DB 11gR2 is a very interesting product mainly because it combines the familiar SQLite sqlite3() API with the powerful, proven Berkeley DB data storage technology. I was able to re-compile my SQLiteManager product against the Berkeley DB library without any major issues in very little time. I have now a product that is fully able to manage Berkeley DB databases without changing a single line of my code. So far performance and concurrency are excellent and I am thrilled to think about the future improvements of this great product." - Marco Bambini, CEO of SQLabs "Berkley DB 11gR2 is, in my experience, a fully drop-in replacement for SQLite3. I was hugely surprised at just how easy it was; I'd had zero experience in using Berkeley DB in products before, but within a couple hours I had my application powered by Berkeley DB. From there onwards, you can enjoy all the benefits of Berkeley DB including concurrency and long term stability compared to SQLite3 from an API you're already familiar with. It's quite simply amazing." - Liam McLoughlin, Chromium OS independent developer DOWNLOAD: http://www.oracle.com/technology/software/products/berkeley-db http://www.oracle.com/technology/software/products/berkeley-db/db Berkeley DB .tar.gz, with AES encryption http://download.oracle.com/berkeley-db/db-5.0.21.tar.gz Berkeley DB .zip, with AES encryption http://download.oracle.com/berkeley-db/db-5.0.21.zip Berkeley DB .msi Windows installer, with AES encryption http://download.oracle.com/berkeley-db/db-5.0.21.msi Berkeley DB NC.tar.gz , without encryption http://download.oracle.com/berkeley-db/db-5.0.21.NC.tar.gz Berkeley DB .NC.zip, without encryption http://download.oracle.com/berkeley-db/db-5.0.21.NC.zip EDUCATION: Documentation page: http://www.oracle.com/technology/documentation/berkeley-db/db You may find an answer on our product FAQ page: http://www.oracle.com/technology/products/berkeley-db/faq/db_faq.html Join OTN today and participate in the Berkeley DB Support Forum and discussions. General Questions http://forums.oracle.com/forums/forum.jspa?forumID=271 Questions on HA/Replication http://forums.oracle.com/forums/forum.jspa?forumID=272 For further information, please contact us at: mailto:berkeleydb-info_us@oracle.com Thank you for your support of Berkeley DB. -greg Greg Burd | Product Manager | Oracle Berkeley DB _______________________________________________ BDB mailing list BDB(a)oss.oracle.com http://oss.oracle.com/mailman/listinfo/bdb

1 0

User-level network stack
by Howard Chu 30 Mar '10

30 Mar '10

Quite a while back I talked about optimizing select/epoll/whatever using mmap'd memory shared between user space and the kernel for the event table. http://www.openldap.org/lists/openldap-devel/200411/msg00088.html These guys have gone even further, and use mapped memory to bring the entire network stack up to user level: http://www.openonload.org/openonload-google-talk.pdf Their paper talks about the work they did with two particular 10Gbit NICs. I find this interesting because in these benchmarks I ran http://connexitor.com/blog/pivot/entry.php?id=191 the NIC interrupt overhead was 100% of a CPU core, and that was only on 1Gbit ethernet. Clearly for heavy-load deployments a better network solution is needed. It sounds like maybe the OpenOnload guys have a better approach. -- -- 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

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel