Andrey Ivanov wrote:
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.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).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/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.txtand 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/run/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/run/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/run/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/run/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/run/dirsrv/slapd-ens.pid -w /Local/dirsrv/var/run/dirsrv/slapd-ens.startpidMaybe 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/3yo88rYes, we already use it - for example, to enforce the entered telephone numbers to start with a certain prefix etcWe 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@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
<<attachment: smime.p7s>>
-- Fedora-directory-users mailing list Fedora-directory-users@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-directory-users
