Andrey Ivanov wrote:
Another thought regarding subtree/modrdn with a different parent
renames - referential integrity and memberOf attributes should be
adjusted during these renames, it adds a certain difficulty to the
realisation, maybe even rewriting some parts of referential integrity
and memberof plugins...
Yes . . . It would be nice to get away from using full DNs
for group and
group member references, and use instead some sort of unique ID. But in
the short term, these are going to be problems we have to solve.
* Define a dynamic group, and have the member/uniqueMember attribute
of this group automatically be populated by the server
* clients can then just search for member like with a regular static
posix group
* support of other virtual attributes generated "on the fly"
Can you explain this a little more?
For example, the memberOf attribute now generated by memberOf plugin
and written into the db could be generated dynamically.
For the particular case of
memberOf, we decided against using virtual
attributes. One reason is that it's harder to do filtering/indexing on
virtual attributes e.g. supporting searches like (memberof=somegroup).
The attributes like entryLevelRights and attributeLevelRights are
already created dynamically, nsRole/CoS also (one of the main
drawbacks of the roles is that they are only applicable to a sub-tree).
One of the
drawbacks of groups is that they do not apply to the sub-tree
- makes it difficult in general to replicate them. Roles/CoS are scoped
along with the data they apply to, so they go along with replication
quite easily.
I'm talking about this type of "virtual" attributes
generated by some
filters or regular expressions or plug-ins, maybe creation of some
sort of framework or mechanism to generalize the creation of such
attribiutes.
There already is a framework, but not many want to delve into the C
code.
Can you provide some examples of what you mean?
At the same time they may be a major performance hit so the
dynamically generated attributes should be considered with some
precautions.
Most virtual attribute schemes using caching of some sort to make
searches go quickly.
* unix socket autobind still does not seem to work (ldapi) -
https://www.redhat.com/archives/fedora-directory-users/2009-February/msg0....
It could be very useful for various maintenance scripts
running on the server.
We tested this with 1.2.0 and it seems to work. You tested a
build from source? Did you use --enable-autobind with configure?
Did you restart the server after configuring your autobind and
sasl mapping?
Yes, you are right, i have just tested it, in the release version
1.2.0 it works. Perfect! Thank you!
* verification of the server from the viewpoint of memory
leaks. Th size of the memory used by the server grows with
time (normally we don't restart the sevrr during several
months, so i can follow the stats)
We regularly run the server test suite with valgrind enabled. I'm
not aware of any per connection or per operation leaks. What
exactly are you seeing?
I have made a simple cron like this :
5 0,12 * * * root ps auxww |grep slapd|grep -v grep >> /Admin/memory.txt
and i see that the VSZ/RSS of the server grows constantly though very
slowly (without a change in the number of entries but with regular
modifications). Example (time span ~ 2 months) :
ldap 23920 0.7 10.3 1452432 417464 ? Sl Feb17 19:36
/Local/dirsrv/sbin/ns-slapd -D /Local/dirsrv/etc/dirsrv/slapd-ens -i
/Local/dirsrv/var/r
un/dirsrv/slapd-ens.pid -w /Local/dirsrv/var/run/dirsrv/slapd-ens.startpid
...
ldap 23920 0.5 13.6 1517968 550568 ? Sl Feb17 105:16
/Local/dirsrv/sbin/ns-slapd -D /Local/dirsrv/etc/dirsrv/slapd-ens -i
/Local/dirsrv/var/r
un/dirsrv/slapd-ens.pid -w /Local/dirsrv/var/run/dirsrv/slapd-ens.startpid
...
ldap 23920 0.7 13.7 1517968 554696 ? Sl Feb17 220:58
/Local/dirsrv/sbin/ns-slapd -D /Local/dirsrv/etc/dirsrv/slapd-ens -i
/Local/dirsrv/var/r
un/dirsrv/slapd-ens.pid -w /Local/dirsrv/var/run/dirsrv/slapd-ens.startpid
...
ldap 23920 0.9 13.8 1517968 559328 ? Sl Feb17 351:14
/Local/dirsrv/sbin/ns-slapd -D /Local/dirsrv/etc/dirsrv/slapd-ens -i
/Local/dirsrv/var/r
un/dirsrv/slapd-ens.pid -w /Local/dirsrv/var/run/dirsrv/slapd-ens.startpid
...
ldap 23920 0.7 14.0 1517968 569804 ? Sl Feb17 448:17
/Local/dirsrv/sbin/ns-slapd -D /Local/dirsrv/etc/dirsrv/slapd-ens -i
/Local/dirsrv/var/r
un/dirsrv/slapd-ens.pid -w /Local/dirsrv/var/run/dirsrv/slapd-ens.startpid
Maybe it's just the change of the data size anyway...
* logconv.pl - very useful script, add some more options/
adjustments (for example, a switch to hide unindexed searches
in verbose mode). We use it as logwatch.
* a perl script to show the replication statistics (there is
one for the we page generation statistics, something more
basic, text-only would be very welcome) in text mode - to
receiveth reports by mail once per day like logwatch for example
What sort of information are you looking for? ldapsearch can
provide most of the useful information.
The same stats as provided by repl-monitor.pl. But in a simple text
file form, without any bells and whistles. But you are right, simple
ldapsearch formatted by perl can do the thing.
* regular expressions in ACIs (i know, it is very difficult to
do, so maybe somewhere in the timescale of the version 10.0 ?
:)) - for example, allow a user to add or modify a value just
in case the new value mathes the regex. Or the group or dn of
the user matches the regex...
You can do some of that currently with targetattrfilters - see
*http://tinyurl.com/3yo88r
Yes, we already use it - for example, to enforce the entered telephone
numbers to start with a certain prefix etc
We added support in 1.2.0 to allow you to specify group membership
with LDAP search specifications, which does allow some
wildcarding, so that might help too.
Yep
*
* simplify the creation of new syntaxes and their validation/
enforcement (version 11.0? :))
Can you elaborate?
Today if i remember right from reading the docs one needs to write a
plug-in or a library to add some new syntaxes. It would be nice, for
example, to have a possibility to define a new custom syntax by a
simple regex. As for the matching rules for this new syntax, i agree,
it's a bit more difficult...
* virtual views allowing to map not only the trees but also
the attributes ('cn' instead of 'uid' in a subtree, for example)
Can you elaborate?
some LDAP-enabled programs/applications (example: Onboard
Administrator of the HP c3000/c7000 Blades Enclosure) expect a
pre-defined hard-coded naming attribute (RDN) that cannot be changed
(for the HP c7000 it is "cn", i think they tested mainly against
Active Directory). In our FDS installation the naming attribute is
uid. So if we could have a virtual subtree view with the changed
naming attribute we would be able use our LDAP to serve as an
authentification/autorization back-end for that soft. It is something
like the "Present AD DIT style read-only view of the data stored in
the DS part of the tree " feature on the Roadmap page but with larger
mapping possibilities.
------------------------------------------------------------------------
--
Fedora-directory-users mailing list
Fedora-directory-users(a)redhat.com
https://www.redhat.com/mailman/listinfo/fedora-directory-users