openldap-devel

openldap-devel@openldap.org

1443 discussions

HEADS UP: Attribute changes
by Howard Chu 24 Sep '07

24 Sep '07

I'm adding counters to the Attribute and Modification structures, a_numvals and sm_numvals to track the number of values in each. I've added an attr_valadd() routine that will add arrays of values to an attribute and update the counter. This can eliminate most of the empty for loops we're using to count these values at various points. But it means other code that assembles Attributes manually needs to be updated. Fortunately most of these are easy to spot now since they generally have to use attr_alloc(). I believe I have them all. This is the first stage in a larger transition, to using sorted arrays for multivalued attributes. I haven't quite decided how the next steps will play out just yet. Note that we already do a sort on incoming attributes, but that code currently has ORDER_PRESERVING defined so after duplicate checks are done we discard the sort info. That preserves the existing/historical slapd behavior. However, I'm pretty sure this is going to have to change. Using sorted arrays will allow us to use binary search to find values, which will be a big win for attributes with very many values. This will speed up test_filter, Compare, ACL processing, etc. etc... We can also implement this without any user-visible change, if we keep an auxiliary ordering array, the way the current sorter does. But it seems to me that that will be too much memory overhead. It also makes add/remove that much more tedious... -- -- 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/

2 6

persistent search and keepalives
by Howard Chu 23 Sep '07

23 Sep '07

Following on from ITS#5133, there are a couple different scenarios to deal with... 1) the remote network segment has disappeared (or the remote server has crashed) 2) an intervening firewall has killed the connection Neither case is really distinguishable from the consumer side. In the case of a hardware failure, where either the remote host or the network to the host has failed, there's little to be gained by setting an aggressive retry policy. Failures of that sort tend to take a non-trivial amount of time to repair. I've seen some app guides recommending keepalives be sent once a minute or so; to me that is way overdoing things. In the case of a firewall closing an idle connection, you really have to ask yourself what you're trying to accomplish - are you trying to send probes frequently enough to prevent the connection from closing, or are you just trying to detect that it has closed? This may be giving too much credit to the firewall admins, but I'd guess that they've set an idle timeout that is appropriate for the load that their networks see. Artificially inflating traffic on a connection to prevent it from appearing idle would just be an abuse of network resources. It's also possible that a stateful firewall will start dropping connections because it's been overwhelmed by traffic, and simply doesn't have the memory to track all the live connections. Keeping the connection open in these circumstances would just make a bad situation worse. As such, it seems to me that you don't really want to be setting very short keepalive timeouts anywhere. The default of 2 hours that most systems use seems pretty reasonable. On the other hand, it would probably be useful to be able to prod the consumer and have it kick the connection on request. In the past I've implemented this sort of thing using Search requests with magic filters. I.e., treat the Search operation as an RPC call, the target object is simply an embedded method, and the AVAs in the filter comprise a named parameter list. So e.g. one might do a search on "cn=Sync Consumers,cn=monitor" with filter (|(objectclass=*)(kick=TRUE)) to cause every active consumer to probe its connections. I like this approach a lot better than Modifying an object, because you can hit many objects at once with a Search request, and receive all of their execution results as attributes of the returned entries. -- -- 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/

3 2

ITS#4556 ACLs for new entries
by Howard Chu 21 Sep '07

21 Sep '07

Revisiting this topic - DITStructureRules are not a solution to this problem. E.g. in cn=config, now that you can grant write access to arbitrary users, it becomes pretty critical to be able to prevent certain users from creating certain types of objects. E.g., I may want to allow someone to be able to create one type of child object under cn=config (e.g., databases) but not some other type (e.g., modules). So at the very least we need to be able to use ACL filters on new entries. -- -- 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

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

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

18 Sep '07

Howard Chu wrote: > One last question that may need an answer: > what groups does user X belong to? > > Obviously you need to perform a search to determine this. And with the current > indexing mechanisms, dynamic groups will fail to be matched since they don't > actually contain an indexed static member list. If this is the question you're > trying to answer, the solution is simply to maintain a list of dynamic group > objects (as your current code already does) but not to populate them. Instead, > just use a search response callback and see if "member" is a part of the > filter. If it is, iterate through the dynamic groups and test the entry whose > DN is in the filter assertion against all of the dynamic group filters. This > solution will use far less memory than your approach, and it will run > efficiently for just about all use cases. This was actually the first idea we thought of, we concluded that it would slow the search down, because then the algorithmic complexity of the search would be O(n), with n as the number of dynamic groups. We think this would be somewhat against the idea of LDAP directories, where the number of search operations far outweigh the number of updates. It is a trade-off between update speed and search speed, but we think that the search speed is essential, and the update operations are not our primary concern speed-wise. -- Michał Szulczyński Praktykant Altkom Akademia S.A. http://www.altkom.pl Warszawa, ul. Chłodna 51 kom. +48 603-338-373 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.

2 1

imporvement to slapo-constraint (ITS#4987)
by manu＠netbsd.org 18 Sep '07

18 Sep '07

Hello I modified my patch to slapo-constaint. The constraint can now be written as a LDAP url, which allows much more flexibility: Usage example: constraint_attribute title uri ldap:///cn=titlecat,dc=example,dc=net?title?sub? Here is the new patch: ftp://ftp.openldap.org/incoming/manu-070918.patch Comments are welcome. I'll now write a man page. -- Emmanuel Dreyfus http://hcpnet.free.fr/pubz manu(a)netbsd.org

1 0

Re: imporvement to slapo-constraint (ITS#4987)
by Howard Chu 18 Sep '07

18 Sep '07

manu(a)netbsd.org wrote: > Gavin Henry <ghenry(a)suretecsystems.com> wrote: > >> It would be best to move this dicussion to openldap-devel(a)openldap.org now. > > Let's go... > > Summarry: I've added a new feature to slapo-constraint for constraining > a value attribute the the existing values of another attribute. The idea > is that you can have a catalog of allowed values (eg: for titles: Mr, > Mrs, Miss) and constraint an attribute to these values > > Before working further on this patch (style, dod), I'd like some feeback > on: > 1) the way it's implemented: is there rought bugs, or is the logic fine? I haven't looked at the patch yet. > 2) configuration syntax: do we keep this one or do we swtich to > something else? Something like constraint-reference attr1 attr2 might be better. For simple directives, it's better to use positional parameters and no tag words. -- -- 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/

3 3

Trouble with Bind/overlays/callbacks
by Howard Chu 17 Sep '07

17 Sep '07

In slapd just about all of the operation handlers send their results from the backend directly to the client. The notable exception is for the Bind operation, which sends failures directly to the client, but has to return successes to the frontend to allow final processing to occur there. This difference causes a fair bit of complexity when writing Bind handlers in backends and overlays. In 2.3 we ran into other sequencing issues that could only be solved by moving some of the Bind cleanup into a callback (connection_bind_cb). We have an opportunity now to move all of the postprocessing into that callback, allowing us to remove all special case handling of Binds in the backends and overlays. Of course, making this change will touch every backend that handles Bind operations. It may impact overlays that intercept Binds as well. In particular, overlays that insert response callbacks on Bind operations can potentially break in the current code. I.e., if an overlay inserts a callback at the head of the stack (instead of at the end) then currently it will simply not get called in the case of a successful Bind, because the overlay framework tears down the callback stack before it returns to the frontend. If the callback was inserted using malloc'd memory then it will cause a memory leak as well. I plan to file an ITS on this for RE24, not sure how soon I'll get to the actual changes though. -- -- 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

Re: commit: ldap/doc/man/man5 slapd-meta.5
by Pierangelo Masarati 13 Sep '07

13 Sep '07

ando(a)OpenLDAP.org wrote: > HEADS-UP: now the list of URIs is better set by using separate arguments The new behavior should be the only documented one. It allows to get rid of the long-lasting, quite annoying "tabs-separated URI list" issue. The old syntax is fully recognized, but it should just be forgotten. 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 ---------------------------------------

1 0

rfc45xx in RE23?
by Gavin Henry 13 Sep '07

13 Sep '07

Hi all, Why don't we have any 45XX rfcs in doc/rfc/ ? Thanks. -- 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 8

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel