Here are some features we are considering for the next major version (tentatively called 1.3). These are not in any particular order, and this is quite an ambitious list, so we're not likely to complete all of these in a single release. We would appreciate your help in prioritizing this list, filling in any missing details, helping with requirements/design/coding/testing/docs, and letting us know if there are other features which would be nice to have.
In addition, we are considering using GIT instead of CVS for our SCM.
On Tue, 31 Mar 2009, Rich Megginson wrote:
Here are some features we are considering for the next major version (tentatively called 1.3). These are not in any particular order, and this is quite an ambitious list, so we're not likely to complete all of these in a single release. We would appreciate your help in prioritizing this list, filling in any missing details, helping with requirements/design/coding/testing/docs, and letting us know if there are other features which would be nice to have.
The "Security Enhancements" section contains several particularly important items, particularly the ability to disallow plain text binds. That gets asked for quite frequently on IRC.
The named pipe for logging is needed, too; I helped one FDS user who was using my Fedora DS Graph, but FDS produced such an enormous volume of log information that the Perl File::Tail module I use in Fedora DS Graph literally couldn't read the entire log before it was rotated. I remember mentioning that using a named pipe could very well solve the problem -- particularly if it could be put on a RAM disk, e.g.
If syntax validation checking is added (which I support), there should be three modes, much like SELinux: Enforcing (syntax checking enabled, invalid values not allowed), Permissive (syntax checking enabled, invalid values permitted but a warning raised in the log), and Disabled. Additionally, there should be a way to check entire branches of an LDAP tree for syntax compliance -- i.e., a comprehensive auditing tool beyond just enabling Permissive mode and watching the logs.
Thanks for all your hard work on this!
Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University
Chris St. Pierre wrote:
On Tue, 31 Mar 2009, Rich Megginson wrote:
Here are some features we are considering for the next major version (tentatively called 1.3). These are not in any particular order, and this is quite an ambitious list, so we're not likely to complete all of these in a single release. We would appreciate your help in prioritizing this list, filling in any missing details, helping with requirements/design/coding/testing/docs, and letting us know if there are other features which would be nice to have.
The "Security Enhancements" section contains several particularly important items, particularly the ability to disallow plain text binds. That gets asked for quite frequently on IRC.
The named pipe for logging is needed, too; I helped one FDS user who was using my Fedora DS Graph, but FDS produced such an enormous volume of log information that the Perl File::Tail module I use in Fedora DS Graph literally couldn't read the entire log before it was rotated. I remember mentioning that using a named pipe could very well solve the problem -- particularly if it could be put on a RAM disk, e.g.
If syntax validation checking is added (which I support), there should be three modes, much like SELinux: Enforcing (syntax checking enabled, invalid values not allowed), Permissive (syntax checking enabled, invalid values permitted but a warning raised in the log), and Disabled. Additionally, there should be a way to check entire branches of an LDAP tree for syntax compliance -- i.e., a comprehensive auditing tool beyond just enabling Permissive mode and watching the logs.
Thanks - I've added these notes to http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
Anyone else? C'mon - surely you have an opinion about a new feature.
Thanks for all your hard work on this!
Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
On Wed, 2009-04-08 at 10:18 -0600, Rich Megginson wrote: <snip>
Anyone else? C'mon - surely you have an opinion about a new feature.
<snip> Certainly - the ability to move a populated container is very high on our list. Thanks for the invitation - John
John A. Sullivan III wrote:
On Wed, 2009-04-08 at 10:18 -0600, Rich Megginson wrote:
<snip>
Anyone else? C'mon - surely you have an opinion about a new feature.
<snip> Certainly - the ability to move a populated container is very high on our list. Thanks for the invitation - John
Yep - that's what we're calling "Subtree Rename" on the roadmap.
The new features/adjustments that would be very useful for us (most of them are already on the wish list): * subtree rename (should not change nsUniqueId) * internal (plug-in, like memberOf) operations should not change the modifiersName, modifyTimestamp operational attribute (or it should be configurable) of an entry, otherwise it becomes very difficult to trace the activity of users * the server should be able to return the members of dynamic groups, the membership attribute should be configurable - uniqueMember, member or another
Thanks - I've added these notes to
http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
Anyone else? C'mon - surely you have an opinion about a new feature.
Thanks for all your hard work on this!
Chris St. Pierre Unix Systems Administrator Nebraska Wesleyan University
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
I continue with my list
* the server should be able to return the members of dynamic groups "on the fly" as if it were real members, the membership attribute should be configurable - uniqueMember, member or another
* support of other virtual attributes generated "on the fly"
* pam passthrough plug-in should take into account at least the account activation/desactivation (bug *470684*https://bugzilla.redhat.com/show_bug.cgi?id=470684). There is a comment about some additional useful features it in th README file of this plug-in :
We need to worry about account expiration or lockout e.g. the user's credentials are valid but the user has been locked out of his/her account, or the password has expired, or something like that. Some of
this can be handled by LDAP e.g. returning password policy control values when the password has expired.
* a way to synchronise the configuration of indexes (each time we add an index on one of the replicated servers we need to make it manually on all the others) and some other parameters in "cn=config" between the replicated servers (a little like the "configuration" partition in active directory), the schema changes are already replicated which is very good
* enforced attribute syntax validation
* re-verify and validate conformance of the syntaxes, case sensitivity and their matching rules to RFC ( https://www.redhat.com/archives/fedora-directory-users/2008-July/msg00041.ht... )
* unix socket autobind still does not seem to work (ldapi) - https://www.redhat.com/archives/fedora-directory-users/2009-February/msg0011.... It could be very useful for various maintenance scripts running on the server.
* 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)
* 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
* 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...
* simplify the creation of new syntaxes and their validation/ enforcement (version 11.0? :))
* virtual views allowing to map not only the trees but also the attributes ('cn' instead of 'uid' in a subtree, for example)
* enable regex in certmap.conf for mapping the CNs of the certificates during the certificate authentification of users
Other than that i just want to emphasize the great job you are doing adding new features and especially the fantastic reactivity in fixing some critical server bugs (usually it takes only one or two days to have the necessary diff in bugzilla!)
Thank you and please continue the development of this directory server!
Thanks - I've added these notes to
http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
Anyone else? C'mon - surely you have an opinion about a new feature.
Thanks for all your hard work on this!
Andrey Ivanov wrote:
I continue with my list
Thanks - I've added many of these to the list - questions below.
- the server should be able to return the members of dynamic groups
"on the fly" as if it were real members, the membership attribute should be configurable - uniqueMember, member or another
I put this on the Future list: Dynamic group expansion
* 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?
- pam passthrough plug-in should take into account at least the
account activation/desactivation (bug *470684* https://bugzilla.redhat.com/show_bug.cgi?id=470684 ). There is a comment about some additional useful features it in th README file of this plug-in : We need to worry about account expiration or lockout e.g. the user's credentials are valid but the user has been locked out of his/her account, or the password has expired, or something like that. Some of
this can be handled by LDAP e.g. returning password policy control values when the password has expired.
- a way to synchronise the configuration of indexes (each time we add
an index on one of the replicated servers we need to make it manually on all the others) and some other parameters in "cn=config" between the replicated servers (a little like the "configuration" partition in active directory), the schema changes are already replicated which is very good
I'm calling this feature "Configuration replication" - I think it could be useful for other sorts of configuration.
- enforced attribute syntax validation
Already on the list - Syntax validation checking
- re-verify and validate conformance of the syntaxes, case sensitivity
and their matching rules to RFC (https://www.redhat.com/archives/fedora-directory-users/2008-July/msg00041.ht...)
Already on the list
- unix socket autobind still does not seem to work (ldapi) -
https://www.redhat.com/archives/fedora-directory-users/2009-February/msg0011.... 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?
- 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?
- 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.
- 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
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. *
- simplify the creation of new syntaxes and their validation/
enforcement (version 11.0? :))
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)
Can you elaborate?
- enable regex in certmap.conf for mapping the CNs of the certificates
during the certificate authentification of users
This is on the list as Get rid of certmap.conf - use SASL mapping (cert auth is really just SASL/EXTERNAL) The sasl mapping code uses regular expressions
Other than that i just want to emphasize the great job you are doing adding new features and especially the fantastic reactivity in fixing some critical server bugs (usually it takes only one or two days to have the necessary diff in bugzilla!)
Thank you and please continue the development of this directory server!
And thank you for your suggestions.
Thanks - I've added these notes to http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3 Anyone else? C'mon - surely you have an opinion about a new feature. Thanks for all your hard work on this!
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
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/msg0011.... 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.
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@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
* 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).
Yes, i remember this reasoning - i was following quite closely the development of this plug-in as it was sine qua non for our production environment...
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.
Yep.You're talking about the drawbacks concerning the difficulty of the code development. But for us the sub-tree application that was an essential limitation of Roles - we couldn't use it to make the same thing as memberof, that's why i was looking forward eagerly for the memberof plugin...
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?
For example, automatic generation of a virtual attribute describing the location (or type) of the person by applying regex to his/her telephoneNumber (first n digits). But then again you are right about indexing and filters with these attributes... Another example: in our production environment we have a "ou" attribute containing the DNs of the units where the person belongs. It would be nice to convert it automatically to an attribute "displayOu" with slashes instead of ",ou=":
ou: ou=lpp,ou=lab,ou=dgar,ou=dg,ou=organisation,dc=example,dc=com displayOu: LPP/LAB/DGAR/DG
Today we are using scripts. This type of attribute conversion can easily be made inside an application if you write it internally, otherwise one needs to add this type of "converted" attributes...
Andrey Ivanov wrote:
* 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).
Yes, i remember this reasoning - i was following quite closely the development of this plug-in as it was sine qua non for our production environment...
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.
Yep.You're talking about the drawbacks concerning the difficulty of the code development. But for us the sub-tree application that was an essential limitation of Roles - we couldn't use it to make the same thing as memberof, that's why i was looking forward eagerly for the memberof plugin...
Do you want to do something like this dc=example,dc=com +ou=people +ou=roles ++cn=my role
And have cn=my role be a role that applies to users under ou=people? e.g. by adding a roleSubtree: ou=people,dc=example,dc=com to the role definition?
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?
For example, automatic generation of a virtual attribute describing the location (or type) of the person by applying regex to his/her telephoneNumber (first n digits). But then again you are right about indexing and filters with these attributes... Another example: in our production environment we have a "ou" attribute containing the DNs of the units where the person belongs. It would be nice to convert it automatically to an attribute "displayOu" with slashes instead of ",ou=":
ou: ou=lpp,ou=lab,ou=dgar,ou=dg,ou=organisation,dc=example,dc=com displayOu: LPP/LAB/DGAR/DG
Today we are using scripts. This type of attribute conversion can easily be made inside an application if you write it internally, otherwise one needs to add this type of "converted" attributes...
Ok. So something like CoS, but with a couple of additional attributes: cosDestinationAttribute - grab the value from cosAttribute, but write to this attribute instead cosRegex - apply this regex to the value e.g. cosAttribute: ou cosDestinationAttribute: displayOu cosRegex: s|ou=(\S)+,ou=(\S)+,ou=(\S+),ou=(\S+)|\1/\2/\3/\4/|
It would be difficult to create indexes on these (e.g. if you wanted to do searches like (displayOu=LPP/*)
Something like that would be useful for posix homeDirectory too cosAttribute: uid cosDestinationAttribute: homeDirectory cosRegex: s,(.+),/home/\1,
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
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.
Yep.You're talking about the drawbacks concerning the difficulty of the code development. But for us the sub-tree application that was an essential limitation of Roles - we couldn't use it to make the same thing as memberof, that's why i was looking forward eagerly for the memberof plugin...
Do you want to do something like this dc=example,dc=com +ou=people +ou=roles ++cn=my role
And have cn=my role be a role that applies to users under ou=people? e.g. by adding a roleSubtree: ou=people,dc=example,dc=com to the role definition?
Yes. An attribute like that is already a good step forward that would permit to organise the roles in the way that is independent of the sub-trees to which they are applied.
For example, automatic generation of a virtual attribute describing the
location (or type) of the person by applying regex to his/her telephoneNumber (first n digits). But then again you are right about indexing and filters with these attributes... Another example: in our production environment we have a "ou" attribute containing the DNs of the units where the person belongs. It would be nice to convert it automatically to an attribute "displayOu" with slashes instead of ",ou=":
ou: ou=lpp,ou=lab,ou=dgar,ou=dg,ou=organisation,dc=example,dc=com displayOu: LPP/LAB/DGAR/DG
Today we are using scripts. This type of attribute conversion can easily be made inside an application if you write it internally, otherwise one needs to add this type of "converted" attributes...
Ok. So something like CoS, but with a couple of additional attributes:
cosDestinationAttribute - grab the value from cosAttribute, but write to this attribute instead cosRegex - apply this regex to the value e.g. cosAttribute: ou cosDestinationAttribute: displayOu cosRegex: s|ou=(\S)+,ou=(\S)+,ou=(\S+),ou=(\S+)|\1/\2/\3/\4/|
Yes, something like that.
It would be difficult to create indexes on these (e.g. if you wanted to do searches like (displayOu=LPP/*)
Exactly. That why i have told that it is not a high-order priority for us but it would be a nice feature in one of the future versions...
Something like that would be useful for posix homeDirectory too cosAttribute: uid cosDestinationAttribute: homeDirectory cosRegex: s,(.+),/home/\1,
yes, in our production environment we often need attributes that are generated automatically from other ones...
Thank you for taking your time to understand our needs and to formalize the requests! :)
Anthony Giggins wrote:
How about some Centos and RHEL rpms?
You can use the Fedora Core 6 rpms on Centos/RHEL 5.3
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Better log handling:
- Compress old logs - Don't stop working when log volume fills up.
On lunedì 20 aprile 2009 23:49:53 Orion Poplawski wrote:
Better log handling:
- Compress old logs
- Don't stop working when log volume fills up.
- put logs on another partition ;)
One of my pet peeves .. a plugin that can compress/decompress binary data.
When we store large binary data (that can be easily compressed and stored ) in attributes , for example CRLs, I would like to see a ds plugin that compresses the data prior to storage. stores in compressed form. When asked to retrieve, decompress it on-the-fly.
On Tue, 2009-03-31 at 20:29 -0600, Rich Megginson wrote:
Here are some features we are considering for the next major version (tentatively called 1.3). These are not in any particular order, and this is quite an ambitious list, so we're not likely to complete all of these in a single release. We would appreciate your help in prioritizing this list, filling in any missing details, helping with requirements/design/coding/testing/docs, and letting us know if there are other features which would be nice to have.
In addition, we are considering using GIT instead of CVS for our SCM.
http://directory.fedoraproject.org/wiki/Roadmap#Version_1.3
-- Fedora-directory-users mailing list Fedora-directory-users@redhat.com https://www.redhat.com/mailman/listinfo/fedora-directory-users
Chandrasekar Kannan wrote:
One of my pet peeves .. a plugin that can compress/decompress binary data.
When we store large binary data (that can be easily compressed and stored ) in attributes , for example CRLs, I would like to see a ds plugin that compresses the data prior to storage. stores in compressed form. When asked to retrieve, decompress it on-the-fly.
BerkeleyDB (the storage manager used by FDS) has a feature (added after the DS was developed) that allows compression of the data stored. This might give you what you want, and it could also be handy in compressing entries in general. As far as I know nobody has tried to enable it with the DS. Perhaps it's been testing with OpenLDAP, I'm not sure.
If I'm in late it's good for 1.4 ;)
* the ability to set attribute values using a set of internal functions (eg. timestamp, incremental log value)
* search in subtrees of view: when I create a view (eg. a view of domains) I can't search in its subentries (eg. in ou=people, dc=domain)
Peace, R.
Roberto Polli wrote:
If I'm in late it's good for 1.4 ;)
- the ability to set attribute values using a set of internal functions (eg.
timestamp, incremental log value)
- search in subtrees of view: when I create a view (eg. a view of domains) I
can't search in its subentries (eg. in ou=people, dc=domain)
Peace, R.
I'm not sure I understand these - can you explain them more?
On venerdì 01 maggio 2009 18:38:21 Rich Megginson wrote:
- the ability to set attribute values using a set of internal functions
(eg. timestamp, incremental log value)
sql supports function. eg. INSERT INTO mytable VALUES (NOW()); UPDATE mytable(mydoc, revision) SET revision=revision+1
this enables the ability to use custom attributes for storing timestamp, as modifyTimestamp is unmodifiable.
- search in subtrees of view: when I create a view (eg. a view of
domains) I can't search in its subentries (eg. in ou=people, dc=domain)
base tree: dc=example.com, o=example ltd, dc=top dc=example.net, o=example ltd, dc=top dc=company.com, o=company ltd, dc=top
using views I can create a tree of all domains, no matter which organization: ou=domainView, dc=top nsViewFilter: (dc=*)
so under ou=domainView I got all domains dc=example.com,ou=domainView dc=company.com,ou=domainView ...
imagine I'd like to search a user under domain example.com dn: uid=jondoe,dc=example.com,o=example ltd,dc=top
I could search straight in dc=example.com,ou=domainView,dc=top
or pick directly uid=jondoe,dc=example.com,ou=domainView,dc=top
but it's not possible.
hoping to have been clear... Thx+Peace, R.
Roberto Polli wrote:
On venerdì 01 maggio 2009 18:38:21 Rich Megginson wrote:
- the ability to set attribute values using a set of internal functions
(eg. timestamp, incremental log value)
sql supports function. eg. INSERT INTO mytable VALUES (NOW()); UPDATE mytable(mydoc, revision) SET revision=revision+1
this enables the ability to use custom attributes for storing timestamp, as modifyTimestamp is unmodifiable.
We could do something like this for a very specific and limited set of attribute values. The problem with general purpose use is that we have no "procedural" or "functional" programming language with which to define functions or operations (e.g. revision=revision+1) in the directory server (except for C - but I don't think that's what you mean). I think the Apache Directory Server project has done some research into something like stored procs and triggers.
- search in subtrees of view: when I create a view (eg. a view of
domains) I can't search in its subentries (eg. in ou=people, dc=domain)
base tree: dc=example.com, o=example ltd, dc=top dc=example.net, o=example ltd, dc=top dc=company.com, o=company ltd, dc=top
using views I can create a tree of all domains, no matter which organization: ou=domainView, dc=top nsViewFilter: (dc=*)
so under ou=domainView I got all domains dc=example.com,ou=domainView dc=company.com,ou=domainView ...
imagine I'd like to search a user under domain example.com dn: uid=jondoe,dc=example.com,o=example ltd,dc=top
I could search straight in dc=example.com,ou=domainView,dc=top
or pick directly uid=jondoe,dc=example.com,ou=domainView,dc=top
but it's not possible.
It's not possible to do a search like ldapsearch -s sub -b "dc=top" "(uid=jondoe)" ?
hoping to have been clear... Thx+Peace, R.
On lunedì 04 maggio 2009 18:01:18 Rich Megginson wrote:
- search in subtrees of view: when I create a view (eg. a view of
domains) I can't search in its subentries (eg. in ou=people, dc=domain)
base tree: dc=example.com, o=example ltd, dc=top dc=example.net, o=example ltd, dc=top dc=company.com, o=company ltd, dc=top
using views I can create a tree of all domains, no matter which organization: ou=domainView, dc=top nsViewFilter: (dc=*)
so under ou=domainView I got all domains dc=example.com,ou=domainView dc=company.com,ou=domainView ...
imagine I'd like to search a user under domain example.com dn: uid=jondoe,dc=example.com,o=example ltd,dc=top
I could search straight in dc=example.com,ou=domainView,dc=top
or pick directly uid=jondoe,dc=example.com,ou=domainView,dc=top
but it's not possible.
imho the behavior I suggest is more intuitive, as you can find in the view non only the given entries but their subtrees - and that's usually what software expects from an entry. In that way I have no different behavior between the original entry and the view one.
It's not possible to do a search like ldapsearch -s sub -b "dc=top" "(uid=jondoe)" ?
yes, but does a smaller basedn slower the search in case of thousands of entries?
there's one more case where that behavior can be useful: in the above example, if I got o=example ltd is a dblink to server1 and o=company ltd is a dblink on server2
searching on dc=top would result in a search on two servers, while searching in the right tree will search only on the "right" one - except for a fast search for domain - and in mail environment we always know the domain.
Hope it helps+Peace, R.
389-users@lists.fedoraproject.org