openldap-devel August 2007

openldap-devel@openldap.org

21 participants
48 discussions

dynamic groups
by Michał Szulczyński 18 Sep '07

18 Sep '07

Hello, My name is Michał Szulczyński, and I'm a student at Warszawska Wyższa Szkoła Informatyki in Poland. I'm on a practice at the company where Aleksander Adamowski works. As he said, I will try to implement dynamic list member 'caching'. The general idea is to "materialize" the member attribute of the dynamic group using existing static attribute values infrastructure (including indexes) and update them automatically when there is a add/modify/modrdn/delete operation on an object that matches the dynlist memberURL filter. The operation of dynlist overlay would be identical as it is now without specifying an additional dynlist configuration option. The plan is to, depending on the additional, optional dynlist-attrset configuration parameter, grab the dynamic list entries for that dynlist configuration from the database, and put them into a memory-resident list (which would hold all the dynamic groups that we are interested in, ie. the ones with the additional configuration option set). When there is a add/mod/modrdn/delete operation on any entry, we would check this list for a matching dynlist filter, and add/modify/delete the member attribute of the dynamic list for that entry. Much like a static group, but with automated addition/deletion to/from it, effectively making it a dynamic group. Manual updates to the member attribute would be prevented and would raise an error. First, in addition to dynlist_info_t we would need to hold the pointer to our memory-resident dynamic group list per dynlist overlay instance. That's for speed optimization, since searching for all dynamic lists on each update operation would have a huge performance impact. As we can only hold only one backend-specific config data in Operation->o_bd->bd_info->on_bi.bi_private, we wold need to hold both pointers (dynlist_info_t and the pointer to our list) in an additional struct, and store that. But this method would mean changing much of the existing codebase, and I don't know if that would be good. If there would be another place where we could store the pointer to the dynamic group list, that would be better. Second, I would like to know if there is a function to test whether one DN is contained in another DN (i.e. one DN is a descendant to another DN). I need this to compare the base DN of the dynamic group, and the added/modified/deleted/modrdn'ed entry (eg: if the entry DN <uid=test,l=City,ou=People,o=MyOrg> is in the dynamic group's member URL's base DN <ou=People,o=MyOrg>). I think that comparing the normalized DN's stringwise backwards from the strings' end would work, but I'm not sure. Third: * can we do an add-or-replace with BackendDB->be_modify * when doing a LDAP_MOD_DELETE on a single attribute's value can we ignore a case where that attribute value does not exist in the entry (so we can avoid checking for its presence and save an unnecessary read operation)? -- Michał Szulczyński Praktykant Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Chłodna 51 Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione. Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message.

4 7

dynamic group caching for member -> dynlist search - new implementor
by Aleksander Adamowski 03 Sep '07

03 Sep '07

Hello! Regarding the discussion about implementing dynamic group caching so that we can search on member for dynamic groups (not only static, like currently), let me introduce Michal Szulczynski (michal.szulczynski(a)altkom.pl). He's working on an implementation and I'm his mentor. He works on CVS HEAD, and will most probably have several questions about OpenLDAP codebase, since the only available development documentation are sparse comments in the source... BTW, the current HEAD version was segfaulting at startup for us, but the simple fix for dynlist.c (see attached patch) has remedied it. -- Best Regards, Aleksander Adamowski GG#: 274614 ICQ UIN: 19780575 http://olo.org.pl -- Aleksander Adamowski Administrator systemów korporacyjnych; Instruktor Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Chłodna 51 kom. 0-601-318-080 Sąd Rejonowy dla m.st. Warszawy w Warszawie, XII Wydział Gospodarczy Krajowego Rejestru Sądowego, KRS: 0000120139, NIP 118-00-08-391, Kapitał zakładowy: 1000 000 PLN. Adres rejestrowy Firmy - ul. Stawki 2, 00-193 Warszawa. Niniejsza wiadomość zawiera informacje zastrzeżone i stanowiące tajemnicę przedsiębiorstwa firmy Altkom Akademia S.A. Ujawnianie tych informacji osobom trzecim lub nieuprawnione wykorzystanie ich do własnych celów jest zabronione. Jeżeli otrzymaliście Państwo niniejszą wiadomość omyłkowo, prosimy o niezwłoczne skontaktowanie się z nadawcą oraz usunięcie wszelkich kopii niniejszej wiadomości. This message contains proprietary information and trade secrets of Altkom Akademia S.A. company. Unauthorized use or disclosure of this information to any third party is prohibited. If you received this message by mistake, please contact the sender immediately and delete all copies of this message.

3 2

LDAP_REL_ENG_2_4
by Quanah Gibson-Mount 01 Sep '07

01 Sep '07

OpenLDAP Release Engineering 2.4 has been sync'd with HEAD. Please check it out and test that builds and functionality work as expected. I've tested so far on MAC OS X x86. Thanks! --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

4 10

Performance issue with In-Memory BDB
by Suhel Momin 31 Aug '07

31 Aug '07

Hi, I have made changes such that backend BDB ( ver 4.5 ) resides in memory instead of on disk . This is with default slapd configuration. I was hoping to have a better performance with this. But what I now see is that do_add takes much more time then what it use to take when BDB was on-Disk. Indexing is done on objectclass in both the cases. Any pointers on why this could be an issue? Regards, Suhel

3 2

Reminder: 10 Year Anniversary next year
by Gavin Henry 27 Aug '07

27 Aug '07

Dear All, Just a reminder for next year for us to think of something grand to do! ;-) Gavin. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretecsystems.com Open Source. Open Solutions(tm). http://www.suretecsystems.com/

5 7

Re: commit: openldap-guide/ preamble.sdf
by Gavin Henry 26 Aug '07

26 Aug '07

<quote who="kurt(a)OpenLDAP.org"> > Update of /repo/OpenLDAP/pkg/openldap-guide > > Modified Files: > preamble.sdf 1.90 -> 1.91 > > Log Message: > Don't comment on software produced by others. Those who desire to use a > network analyzer are likely to know which ones are or are not "great". Understood, but how far does that go? Does that mean we can't talk about "tail", as it "wasn't made here"? It's a debugging section so I think referencing Open Source tools should be allowed. My 2 pence. Night. > > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/?cvsroot=OpenLDAP-guide > http://www.openldap.org/devel/cvsweb.cgi/preamble.sdf?cvsroot=OpenLDAP-guide > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. >

2 1

Re: commit: openldap-guide/admin troubleshooting.sdf
by Gavin Henry 26 Aug '07

26 Aug '07

<quote who="kurt(a)OpenLDAP.org"> > Update of /repo/OpenLDAP/pkg/openldap-guide/admin > > Modified Files: > troubleshooting.sdf 1.9 -> 1.10 > > Log Message: > Don't comment on software produced by others. Those who desire to use a > network analyzer are likely to know which ones are or are not "great". I should have discussed and understood the charter. Same reasons why we link to the TLS FAQ entry. Gavin. > > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/admin/?cvsroot=OpenLDAP-guide > http://www.openldap.org/devel/cvsweb.cgi/admin/troubleshooting.sdf?cvsroot=… > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. >

1 0

Is contextCSN SINGLE-VALUE?
by Pierangelo Masarati 26 Aug '07

26 Aug '07

I'm seeing it multiple-valued in some bulk testing I'm doing; does it make any sense? Its specification, in schema_prep.c, doesn't explicitly set the SINGLE-VALUE constraint. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 6

Re: commit: ldap/servers/slapd filterentry.c
by Pierangelo Masarati 26 Aug '07

26 Aug '07

hyc(a)OpenLDAP.org wrote: > Log Message: > test_filter() should use ordered_value_match() Shouldn't that go almost everywhere? I'm not sure about component match, which is probably broken, but MRA should be affected as well. Only explicit entryDN and hasSubordinates tests should be unaffected. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

2 1

Re: commit: ldap/servers/slapd bconfig.c ldapsync.c slapadd.c syncrepl.c
by Howard Chu 26 Aug '07

26 Aug '07

ando(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd > > Modified Files: > bconfig.c 1.295 -> 1.296 > ldapsync.c 1.43 -> 1.44 > slapadd.c 1.45 -> 1.46 > syncrepl.c 1.346 -> 1.347 > > Log Message: > improve previous commit; fix ITS#5108 by letting both SID and RID be 0..4095, > input/output in decimal, but consistently handled in hexadecimals within CSN Expanding the range of the RID is not necessary. The two numbers serve completely different purposes. There's no need to incur the doc impact of making this change. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel August 2007