openldap-devel

openldap-devel@openldap.org

1418 discussions

si_presentlist could use a single malloc instead of two :)
by Pierangelo Masarati 02 Oct '07

02 Oct '07

Bervals stored in si_presentlist could use a single malloc instead of two if the berval and the payload are malloc'ed in one shot. This would be allowed by the very well confined use that is made of those data. Any objection? 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

[Fwd: LDAP/Samba 4 summary]
by Howard Chu 02 Oct '07

02 Oct '07

Yesterday afternoon at the CIFS Workshop we had a meeting to discuss Samba 4's use of LDAP going forward, and what obstacles remained. Among the attendees that I can remember were Andrew Bartlett, Andrew Tridgell, Simo Sorce, Stefan Metzmacher, and (one more, I've forgotten the name) from the Samba team. Nicole Jacque and another (sorry, don't remember the name) from Apple/OpenDirectory, Pete Rowley from FedoraDS, and myself and Marty Heyman for OpenLDAP and Symas. The upshot is that both the Samba and the LDAP sides have work to do, but there are no major roadblocks. LDAP will be Samba 4's default/recommended data store. As for OpenLDAP, most of what Samba 4 needs is either already implemented, or in progress. Schema design tends to still be a stumbling block; in a separate conversation we discussed some design issues in MIT's new Kerberos schema as well as missing features in Heimdal's existing Kerberos schema. That's a bit outside this openldap-devel scope but I've committed to working with the Samba and Kerberos communities to draft some changes to unify these two Kerberos schemas. -- -- 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

Re: commit: ldap/servers/slapd/overlays accesslog.c dynlist.c pcache.c syncprov.c
by Gavin Henry 30 Sep '07

30 Sep '07

ralf(a)OpenLDAP.org wrote: > Update of /repo/OpenLDAP/pkg/ldap/servers/slapd/overlays > > Modified Files: > Tag: OPENLDAP_REL_ENG_2_4 > accesslog.c 1.37.2.7 -> 1.37.2.8 > dynlist.c 1.20.2.6 -> 1.20.2.7 > pcache.c 1.88.2.5 -> 1.88.2.6 > syncprov.c 1.147.2.7 -> 1.147.2.8 > > Log Message: > /tmp/msg > > CVS Web URLs: > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/ > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/accesslog.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/dynlist.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/pcache.c > http://www.openldap.org/devel/cvsweb.cgi/servers/slapd/overlays/syncprov.c > > Changes are generally available on cvs.openldap.org (and CVSweb) > within 30 minutes of being committed. What's with all the double commit e-mails with /tmp/msg in them? Just curious. -- Kind Regards, Gavin Henry. OpenLDAP Engineering Team. E ghenry(a)OpenLDAP.org Community developed LDAP software. http://www.openldap.org/project/

2 1

back-sock in HEAD
by Quanah Gibson-Mount 26 Sep '07

26 Sep '07

back-sock has been added to HEAD by Howard. However, AFAIK it remains untested, so I won't be putting that bit of work into 2.4 for now. If people could poke at it with a sharp stick and follow up with any issues via the ITS that would be great. I'll do some testing on it as well. ;) --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

3 3

New Appendices
by Gavin Henry 26 Sep '07

26 Sep '07

Here's the Appendix Title list I was thinking about: * "Common Errors" (port from FAQ-O-MATIC) - Possibly with a section discussing LDAP spec errors codes to cover all the error 49 questions we *always* get - Linked to from the Troubleshooting section in the main body of the Guide * "Real World Deployments/Examples" (or a better title, as just listing config files like the current placeholder isn't good enough) * Contrib Modules/tools, as some users aren't aware of this in our source That's all I can remember just now, my notes are back home. Chat soon, 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/

1 0

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-devel