[Fedora-directory-users] Proposed new features for 1.3
Rich Megginson
rmeggins at redhat.com
Mon Apr 13 19:11:42 UTC 2009
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/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.
>
>
>
> ------------------------------------------------------------------------
>
> --
> Fedora-directory-users mailing list
> Fedora-directory-users at redhat.com
> https://www.redhat.com/mailman/listinfo/fedora-directory-users
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3258 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/fedora-directory-users/attachments/20090413/08d7d480/attachment.bin>
More information about the Fedora-directory-users
mailing list