Roadmap

From 389 Directory Server

This page contains the roadmap and some recent release history for the 389 project.

Contents

[edit]

History

History contains the history of the project, and what features were added when.

[edit]

Next Steps

[edit]

Version 1.2.10

  • Account Usability Control support
  • database transaction pre/post plugins
    • Changelog writes use main database transaction
  • native systemd support
  • slapi_rwlock support replaces direct NSPR PR_RWLock support
[edit]

Version 1.3

The following features are planned for 389 Directory Server 1.3.

  • Auto-generated SLAPI reference
    • generate plugin programmers reference from code + comments (e.g. doxygen)
[edit]

Future

  • AD integration alignment - (in order for RHDS to be used as an identity store for read only Active Directory cross forest trust we need to implement a number of features:
    • Present AD DIT style read-only view of the data stored in the DS part of the tree
      • AD clients see a DIT that looks like an AD DIT, *nix and regular LDAPv3 clients see the usual tree
    • ranged attribute values - e.g. for large static groups - MS supports attrname;M-N where M and N are numbers expressing the range
    • Need ability to specify and ordering for attribute values or the ability to retrieve attributes values in a certain order - control? attr subtype?
      • This may be needed less if the painful tool (Microsoft Managment console) is not used.
  • Schema
  • Security
    • Option to turn off SASL mechanisms
    • Password Policy
      • Make the DS password policy pluggable - be able to support plugins such as cracklib
    • Restrict directory manager bind by host/IP address
    • Get rid of certmap.conf - use SASL mapping (cert auth is really just SASL/EXTERNAL)
  • Improve RFC correctness with respect to the new LDAP RFCs (RFC4511 etc.)
  • Support GUIDs in ACIs to reference entries
    • confirm group filter functionality in 1.2 supports this
  • improve replication conflict handling
    • current handling of conflicts can confuse searches such as KDC. perhaps create separate part of the tree to store conflict entries.
  • Data Compression
    • command line db2ldif/ldif2db can read write to pipe, so you can do db2ldif -n userRoot -a - | gzip > file.ldif.gz
    • ability to import/export compressed files via the task interface
    • ability to store/retrieve compressed attribute values (think large CRLs)
    • ability to request either a compressed value or uncompressed
    • possibly use attr subtypes e.g. ldapsearch .... certRevList;x-gzip
    • need to be able to use compressed values in replication too, especially for replica init
    • bdb may have support for compression
  • Allow authentication without an entry
    • If just using the directory server for authentication, want to allow the directory server to authenticate identities
    • This is mostly applicable for non-password based auth, or cases where the directory server is not the credential store
    • For example, cert based auth; SASL auth (GSSAPI, other cases where you pass off the auth decision to sasl), PAM pass through, other types of pass through auth
    • In this case, you want to allow the auth even if there is no user entry
    • this probably wouldn't work for simple auth (no user entry to retrieve userPassword from)
    • Need to be able to use access control, resource limits, groups/roles, CoS, with these user identities
  • Roles with explicit scoping
    • Ability to define roles/CoS that apply to scopes other than the container subtree
    • e.g. have a roleSubtree or cosSubtree attribute
  • CoS define attribute values based on regex match/substitution
    • For example, be able to define homeDirectory based on uid
    • cosAttribute: uid
    • cosDestinationAttribute: homeDirectory
    • cosRegex: s,(.+),/home/\1,
  • Log compression - compress logs when rotating
  • Log robustness - don't stop working when log volume fills up
  • WinSync attribute mapping configuration
    • support attributes other than hardcoded list
    • be able to split/join attributes
    • be able to define regex match/substitution for attribute value mappings
  • Plug-in support for languages other than C
    • python, Java, perl
  • Support for subtree and one level searches rooted at "" (i.e. null suffix support)
  • Bi-directonally linked attributes similar to memberOf (about a dozen).
  • Atomic and consistent updates for links. This might imply transactions, or some other interesting solution, but everything must be atomic so that the bi-directional links are created in one step and never get out of synch.
  • 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
  • Configuration replication
    • we already replicate schema changes, and configuration stored in the tree (aci, roles, CoS, etc.)
    • typical use case is when adding indexes to a master, you want those indexes replicated to all consumers
    • there are many other types of configuration we might want to replicate - new databases, suffixes, sasl maps, plugin config, etc.
  • logconv.pl enhancements
    • switch to hide unindexed searches in verbose mode
  • regular expressions in ACIs
    • for example, allow a user to add or modify a value just in case the new value matches the regex. Or the group or dn of the user matches the regex...
Retrieved from "http://directory.fedoraproject.org/wiki/Roadmap"
Account