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 groupCan you explain this a little more?
* support of other virtual attributes generated "on the fly"
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.
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?
* 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.
Yes, you are right, i have just tested it, in the release version 1.2.0 it works. Perfect! Thank you!
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?
* 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)
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...
What sort of information are you looking for? ldapsearch can provide most of the useful information.
* 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
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.
You can do some of that currently with targetattrfilters - see *http://tinyurl.com/3yo88r
* 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...
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
Can you elaborate?
*
* simplify the creation of new syntaxes and their validation/ enforcement (version 11.0? :))
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...
Can you elaborate?
* virtual views allowing to map not only the trees but also the attributes ('cn' instead of 'uid' in a subtree, for example)
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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
