dITStructureRules/nameForms in subschema subentry for informational purpose
by Michael Ströder
HI!
Discussed this very briefly with Howard at LDAPcon 2007 based on an idea
of Steve:
Support for dITStructureRules and nameForms is still in OpenLDAP's TODO.
In the meanwhile slapd could accept definitions for both in slapd.conf
and simply pass them on to a schema-aware LDAP client for informational
purpose without enforcing them. Same function like rootDSE <file> in
slapd.conf.
Opinions?
Ciao, Michael.
--
Michael Ströder
E-Mail: michael(a)stroeder.com
http://www.stroeder.com
14 years, 2 months
Setting up slapo-pcache with back-config
by Ralf Haferkamp
Hello,
is slapo-pcache supposed to work with back-config with current HEAD? I was not
able to create a working configuration, yet.
As soon as the olcPcacheConfig Entry is added as a child below a back-ldap
Database Entry, slapd tries to open the corresponding bdb/hdb Database for
the pcache overlay, which of course does not yet exist as it has to be a
child object of the olcPcacheConfig Entry.
Any suggestions how this could be fixed?
--
Ralf
15 years, 7 months
[Fwd: LDAP/Samba 4 summary]
by Howard Chu
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/
15 years, 8 months
back-sock in HEAD
by Quanah Gibson-Mount
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
15 years, 8 months
New Appendices
by Gavin Henry
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/
15 years, 8 months
HEADS UP: Attribute changes
by Howard Chu
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/
15 years, 8 months
persistent search and keepalives
by Howard Chu
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/
15 years, 8 months
ITS#4556 ACLs for new entries
by Howard Chu
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/
15 years, 8 months
dynamic groups
by Michał Szulczyński
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.
15 years, 8 months
