]> git.sur5r.net Git - openldap/commitdiff
Merge remote-tracking branch 'origin/master' into OPENLDAP_REL_ENG_2_5
authorQuanah Gibson-Mount <quanah@openldap.org>
Wed, 29 Mar 2017 21:37:38 +0000 (14:37 -0700)
committerQuanah Gibson-Mount <quanah@openldap.org>
Wed, 29 Mar 2017 21:37:38 +0000 (14:37 -0700)
ANNOUNCEMENT [new file with mode: 0644]
CHANGES [new file with mode: 0644]
TODO [new file with mode: 0644]
build/version.var

diff --git a/ANNOUNCEMENT b/ANNOUNCEMENT
new file mode 100644 (file)
index 0000000..cdca5a2
--- /dev/null
@@ -0,0 +1,122 @@
+A N N O U N C E M E N T -- OpenLDAP 2.5
+
+    The OpenLDAP Project is pleased to announce the availability
+    of OpenLDAP Software 2.5, a suite of the Lightweight Directory
+    Access Protocol (v3) servers, clients, utilities, and
+    development tools.
+
+    This release contains the following major enhancements:
+
+General slapd bits:
+#define LDAP_COLLECTIVE_ATTRIBUTES
+#define LDAP_COMP_MATCH
+#define LDAP_SYNC_TIMESTAMP
+#define SLAP_CONTROL_X_WHATFAILED
+#define SLAP_CONFIG_DELETE
+#define SLAP_AUXPROP_DONTUSECOPY
+threadpool queues
+slapmodify
+non-blocking TLS
+gmtime_mutex
+LDAP_TCP_BUFFER
+Simplify write waiter handling
+
+back-bdb: BDB_MONITOR_IDX
+back-ldap: SLAP_AUTH_DN, FEATURE_CANCHAINOPS
+back-mdb: MDB_MONITOR_IDX
+back-meta: SLAP_AUTH_DN, SLAPD_META_CLIENT_PR
+overlays/syncprov: CHECK_CSN
+overlays/pcache: PCACHE_CONTROL_PRIVDB, PCACHE_EXOP_QUERY_DELETE, PCACHE_MONITOR
+
+ldap.h bits:
+#define LDAP_X_TXN                                             "1.3.6.1.4.1.4203.666.11.7" /* tmp */
+#define LDAP_EXOP_X_TXN_START                  LDAP_X_TXN ".1"
+#define LDAP_CONTROL_X_TXN_SPEC                        LDAP_X_TXN ".2"
+#define LDAP_EXOP_X_TXN_END                            LDAP_X_TXN ".3"
+#define LDAP_EXOP_X_TXN_ABORTED_NOTICE LDAP_X_TXN ".4"
+
+libldap
+channel binding support for OpenSSL, GnuTLS
+Elliptic Curve support for OpenSSL
+
+
+    This release includes the following major components:
+
+        * slapd - a stand-alone LDAP directory server
+        * -lldap - a LDAP client library
+        * -llber - a lightweight BER/DER encoding/decoding library
+        * LDIF tools - data conversion tools for use with slapd
+        * LDAP tools - A collection of command line LDAP utilities
+        * Admin Guide, Manual Pages - associated documentation
+
+    In addition, there are some contributed components:
+
+        * LDAPC++ - a LDAP C++ SDK
+        * Various slapd modules and slapi plugins
+
+
+ACKNOWLEDGEMENTS
+
+    OpenLDAP Software is developed by the OpenLDAP Project.  The
+    Project consists of a team of volunteers who use the
+    Internet to coordinate their activities.  The Project is
+    an organized activity of the OpenLDAP Foundation.
+
+    OpenLDAP Software is derived from University of Michigan LDAP,
+    release 3.3.
+
+
+AVAILABILITY
+
+    This software is available under the OpenLDAP Public License,
+    an non-restrictive, "free", open-source license.  Download
+    information is available at:
+
+        http://www.OpenLDAP.org/software/download/
+
+
+SUPPORT
+
+    OpenLDAP Software is user supported:
+
+        http://www.openldap.org/support/
+
+    The OpenLDAP Administrator's Guide, which includes quick
+    start instructions, is available at:
+
+        http://www.openldap.org/doc/admin/
+
+    The project maintains a FAQ which you may find useful:
+
+        http://www.openldap.org/faq/
+
+    In addition, there are also a number of discussion lists
+    related to OpenLDAP Software.  A list of mailing lists is
+    available at:
+
+        http://www.OpenLDAP.org/lists/
+
+    To report bugs, please use project's Issue Tracking System:
+
+        http://www.openldap.org/its/
+
+    The OpenLDAP home page containing lots of interesting information
+    and online documentation is available at this URL:
+
+        http://www.OpenLDAP.org/
+
+
+SUPPORTED PLATFORMS
+
+    This release has been ported to many UNIX (and UNIX-like)
+    platforms including Darwin, FreeBSD, Linux, NetBSD, OpenBSD
+    and most commercial UNIX systems.  The release has also been
+    ported (in part or in whole) to other platforms including
+    Apple MacOS X, IBM zOS, and Microsoft Windows NT/2000/etc.
+
+---
+OpenLDAP is a registered trademark of the OpenLDAP Foundation.
+
+Copyright 1999-2015 The OpenLDAP Foundation, Redwood City,
+California, USA.  All Rights Reserved.  Permission to copy and
+distribute verbatim copies of this document is granted.
diff --git a/CHANGES b/CHANGES
new file mode 100644 (file)
index 0000000..29e8cb7
--- /dev/null
+++ b/CHANGES
@@ -0,0 +1,3 @@
+OpenLDAP 2.5 Change Log
+
+OpenLDAP 2.5.1 Engineering
diff --git a/TODO b/TODO
new file mode 100644 (file)
index 0000000..03d02d9
--- /dev/null
+++ b/TODO
@@ -0,0 +1,61 @@
+Things for 2.5:
+[09:27] <hyc> we also need to audit all of these schema defs
+[09:27] <hyc> we're supposed to have official, non-experimental OIDs for released schema
+[09:28] <hyc> accesslog is still using 666, experimental arc
+[09:29] <hyc> I think this means we should polish up the logschema draft, Informational status, and publish it again as final
+
+[13:57] <hyc> there's a nagging problem though, pcache's entry_release function needs to distinguish between its backend actually freeing the entry, or being a no-op
+[13:57] <hyc> so it can decide whether to return success or continue
+[13:58] <hyc> the patch to translucent sidesteps the question, by avoiding other overlays
+[13:58] <hyc> but we need to revisit this in 2.5
+
+  ITS#7920 fix for slapacl This needs to be streamlined in 2.5, current tool API is a mess.
+
+ITS#7926 - [18:19] <hyc> this is going to be a WONTFIX for 2.4, I think
+[18:20] <hyc> reiniting the listeners array is probably too much of a pain. it will screw with all currently open connections
+
+[10:22] <hyc> and rewriting Bind and Exop result handling
+[10:22] <hyc> so that it's no longer a special case for overlays
+
+[23:34] <hyc> ok, so far heap profile shows that memory use during refresh is normal
+[23:35] <hyc> not wonderful, but normal. mem usage grows because we're recording the present list while receiving entries in the refresh
+[23:36] <hyc> I'm seeing for 1.2GB of data about 235MB of presentlist
+[23:36] <hyc> which is pretty awful, considering presentlist is just a list of UUIDs
+[23:36] <hyc> being stored in an avl tree
+[23:37] <hyc> a btree would have been better here, and we could just use an unsorted segmented array
+[23:42] <hyc> for the accumulation phase anyway. we need to be able to lookup records during the delete pphase
+[00:05] <hyc> this stuff seriously needs a rewrite
+[01:13] <hyc> 2.8M records x 16 bytes per uuid so this should be no more than 48MB of overhead
+[01:13] <hyc> and instead it's 3-400MB
+
+<hyc> we need to merge the rest of Ondrej's slapmodify/slapdelete patches
+<hyc> get lmdb incremental backup working
+<hyc> I need to publish a spec for PREPARE/2-phase commit in LDAP TXNs and integrate that into lmdb and back-mdb
+
+Update slapo-unique to have an option to disable manageDSAit (ITS#8245)
+
+Leftover bits from ITS#8294 -- Drop custom SHA2 code, use default crypto library SHA2 functions instead
+  May need to document minimum crypto library version requirements
+  Can also include sha2.c in slapd-sha2.c and make everything static
+
+Matching rules for olc* attrs, see also ITS#8341
+
+New syslog engine
+
+[12:45] <hyc> I meant regcomp and regexec
+[12:45] <hyc> mainly - compile a pattern, then fill in substitution parameters later
+[12:46] <hyc> yes but the idea is still based on numbered substitution parameters
+[12:47] <hyc> it's a pretty obvious approach, and with regex, time-tested.
+[12:48] <hyc> I may try to sneak it into OpenLDAP 2.5
+
+
+Overhaul overlays and backends, see ITS 6166
+
+(In relation to a discussion about slapo-chain)
+<hyc> anyway, the nicer ting to fix would be in 2.5, push all of the repl consumer code into its own overlay
+<hyc> in that case, updateref would be processed wherever the overlay was configured
+<hyc> so no longer tied to the frontend
+<hyc> it would also make it more feasible to have multiple different consumer configs in a single DB, each with their own provider URL (and thus their own updateref)
+<hyc> I would think we can get rid of the update ref directive entirely, just point all writes to that consumer's provider.
+
+Update dynlist so it works with search filters, so that autogroup can be deleted
index 96cb1980ddb5d506726e560fc74de4b0e8ef1473..2bb00ec353fa02b75e9b902fa0334898c308841e 100644 (file)
@@ -14,9 +14,9 @@
 ## <http://www.OpenLDAP.org/license.html>.
 ol_package=OpenLDAP
 ol_major=2
-ol_minor=X
+ol_minor=5
 ol_patch=X
-ol_api_inc=000000
+ol_api_inc=20501
 ol_api_current=0
 ol_api_revision=0
 ol_api_age=0