[Fedora-directory-users] Proposed new features for 1.3

Sat Apr 11 14:17:02 UTC 2009

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...

>   * 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. 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). 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. At the same time they may be a major
performance hit so the dynamically generated attributes should be considered
with some precautions.

>  * unix socket autobind still does not seem to work (ldapi) -
>> https://www.redhat.com/archives/fedora-directory-users/2009-February/msg00112.html.
>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.fedoraproject.org/pipermail/389-users/attachments/20090411/a8c22403/attachment.html>