Fedora directory users - Apr 2009 - Proposed new features for 1.3

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

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
Open Source Development Corporation
+1 207-985-7880
jsullivan@opensourcedevel.com

http://www.spiritualoutreach.com
Making Christianity intelligible to secular society

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

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

* 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.html)
>
Already on the list
> * 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?
>
> * 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
>

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.

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.

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! :)

How about some Centos and RHEL rpms?

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.


-- 
Orion Poplawski
Technical Manager                     303-415-9701 x222
NWRA/CoRA Division                    FAX: 303-415-9702
3380 Mitchell Lane                  orion@cora.nwra.com
Boulder, CO 80301              http://www.cora.nwra.com

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 ;)
-- 

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo 
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene 
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio 
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto 
della legge in materia di protezione dei dati personali."

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
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo 
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene 
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio 
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto 
della legge in materia di protezione dei dati personali."

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
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo 
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene 
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio 
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto 
della legge in materia di protezione dei dati personali."

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.



-- 

Roberto Polli
Babel S.r.l. - http://www.babel.it
Tel. +39.06.91801075 - fax +39.06.91612446
Tel. cel +39.340.6522736
P.zza S.Benedetto da Norcia, 33 - 00040 Pomezia (Roma)

"Il seguente messaggio contiene informazioni riservate. Qualora questo 
messaggio fosse da Voi ricevuto per errore, Vogliate cortesemente darcene 
notizia a mezzo e-mail. Vi sollecitiamo altresì a distruggere il messaggio 
erroneamente ricevuto. Quanto precede Vi viene chiesto ai fini del rispetto 
della legge in materia di protezione dei dati personali."