Have a question on TLS replication with 4 LDAP servers.
Each of the 4 LDAP servers has its own CA cert (each with a unique
nickname and serial number).
If I install just one of the CA certs onto the master and then initialize
one of its consumers, its fine. But if I install a second CA cert on the
master and try to initialize either of the consumers, replication fails to
both with error Can't Contact LDAP server, Error Code -1
I am really confused. Can I not have multiple CAs installed on my master?
I'm a little confused about the different versions of 389 that are available.
I followed the documentation on the Downloads page and I see the newest version of ds-base available is 188.8.131.52-1.el6 (for RHEL6), but I also see a bunch of 1.3.x versions on the main page (including release builds?). Is there a difference?
389 Directory Server 184.108.40.206
The 389 Directory Server team is proud to announce 389-ds-base version
Fedora packages are available from the Fedora 20 Testing and Rawhide
The new packages and versions are:
A source tarball is available for download at
Highlights in 220.127.116.11
* Various bugs were fixed.
Installation and Upgrade
See Download <http://directory.fedoraproject.org/wiki/Download> for
information about setting up your yum repositories.
To install, use *yum install 389-ds* yum install 389-ds After install
completes, run *setup-ds-admin.pl* to set up your directory server.
To upgrade, use *yum upgrade* yum upgrade After upgrade completes, run
*setup-ds-admin.pl -u* to update your directory server/admin
server/console information. setup-ds-admin.pl -u
<http://directory.fedoraproject.org/wiki/Install_Guide> for more
information about the initial installation, setup, and upgrade
See Source <http://directory.fedoraproject.org/wiki/Source> for
information about source tarballs and SCM (git) access.
We are very interested in your feedback!
Please provide feedback and comments to the 389-users mailing list:
If you find a bug, or would like to see a new feature, file it in our
Trac instance: https://fedorahosted.org/389
Detailed Changelog since 18.104.22.168
* Ticket 346 - Slow ldapmodify operation time for large quantities of
multi-valued attribute values
* Ticket 47446 - logconv.pl memory continually grows
* Ticket 47538 - RFE: repl-monitor.pl plain text output, cmdline
* Ticket 47541 - Replication of the schema may overwrite consumer
'attributetypes' even if consumer definition is a superset
* Ticket 47640 - Fix coverity issues - part 3
* Ticket 47670 - Aci warnings in error log
* Ticket 47676 - Replication of the schema fails 'master branch' ->
1.2.11 or 1.3.1
* Ticket 47704 - invalid sizelimits in aci group evaluation
* Ticket 47707 - 389 DS Server crashes and dies while handles paged
searches from clients
* Ticket 47713 - Logconv.pl with an empty access log gives lots of errors
* Ticket 47720 - Normalization from old DN format to New DN format
doesnt handel condition properly when there is space in a suffix
after the seperator operator.
* Ticket 47721 - Schema Replication Issue
* Ticket 47722 - Fixed filter not correctly identified
* Ticket 47722 - rsearch filter error on any search filter
* Ticket 47732 - ds logs many "SLAPI_PLUGIN_BE_TXN_POST_DELETE_FN
plugin returned error" messages
* Ticket 47733 - ds logs many "Operation error fetching Null DN" messages
* Ticket 47734 - Change made in resolving ticket #346 fails on Debian
* Ticket 47735 - e_uniqueid fails to set if an entry is a conflict entry
* Ticket 47740 - Coverity Fixes (Mark - part 1)
* Ticket 47740 - Coverity issue in 1.3.3
* Ticket 47740 - Crash caused by changes to certmap.c
* Ticket 47740 - Fix coverity erorrs - Part 4
* Ticket 47740 - Fix coverity issues - Part 5
* Ticket 47740 - Fix coverity issues(part 7)
* Ticket 47740 - Fix coverity issues: null deferences - Part 6
* Ticket 47740 - Fix sync plugin resource leaks
* Ticket 47743 - Memory leak with proxy auth control
* Ticket 47748 - Simultaneous adding a user and binding as the user
could fail in the password policy check
* Ticket 47750 - Creating a glue fails if one above level is a
conflict or missing
* Ticket 47759 - Crash in replication when server is under write load
* Ticket 47763 - winsync plugin modify is broken
* Ticket 47764 - Problem with deletion while replicated
* Ticket 47766 - Tombstone purging can crash the server if the backend
* Ticket 47767 - Nested tombstones become orphaned after purge
* Ticket 47770 - #481 breaks possibility to reassemble memberuid list
* Ticket 47771 - Move parentsdn initialization to avoid crash
* Ticket 47772 - empty modify returns LDAP_INVALID_DN_SYNTAX
* Ticket 47773 - mem leak in do_bind when there is an error
* Ticket 47774 - mem leak in do_search - rawbase not freed upon
* Ticket 47779 - Need to lock server list when removing list
* Ticket 47779 - Part of DNA shared configuration is deleted after
* Ticket 47779 - Potential deadlock after startup if a dna
configuration change is made
* Ticket 47780 - Some VLV search request causes memory leaks
* Ticket 47782 - Parent numbordinate count can be incorrectly updated
if an error occurs
* Ticket 47787 - A replicated MOD fails (Unwilling to perform) if it
targets a tombstone
* Ticket 47792 - database plugins need a way to call betxn plugins
* Ticket 47793 - Server crashes if uniqueMember is invalid syntax and
memberOf plugin is enabled.
* Ticket 47804 - db2bak.pl error with changelogdb
* Ticket 47806 - Failed deletion of aci: no such attribute
* Ticket 47808 - If be_txn plugin fails in ldbm_back_add, adding entry
is double freed.
* Ticket 47809 - find a way to remove replication plugin errors
messages "changelog iteration code returned a dummy entry with csn
%s, skipping ..."
* Ticket 47813 - managed entry plugin fails to update member pointer
on modrdn operation
* Ticket 47815 - Add operations rejected by betxn plugins remain in cache
* Ticket 47817 - The error result text message should be obtained just
prior to sending result
* Ticket 47821 - deref plugin cannot handle complex acis
* Ticket 47831 - server restart wipes out index config if there is a
* Ticket 47839 - 389-ds production segfault: __memcpy_sse2_unaligned...
Retrieved from "http://directory.fedoraproject.org/wiki/Releases/22.214.171.124"
I encounter a problem with 389 Directory Server. When the password for
Directory Manager contains leading and/or trailing spaces (' ', ASCII
setup-ds.pl ignores them. I'm then able to authenticate with stripped
but not with the original one.
Is this behavior intentional or should I file a bug report for that? If
it's intentional is it documented somewhere?
Thanks in advance!
I'm working on a PoC migration of an OpenLDAP infrastructure to 389.
Our existing directory has periods in all of the usernames, e.g.
dave.page. However, this seems to cause problems with the org chart
interface, which complains with:
"." is not allowed in search filters.
when clicking on the org chart icon for a user. The same issue is seen
when using directory express and clicking the org chart link.
How can I resolve this, without changing hundreds of usernames (which
is not an option)?
The server is running on CentOS 6.5, x86_64 with all updates applied,
installed from EPEL:
[root@389-ds ~]# rpm -qa |grep 389
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
we're going to migrate from CentOS5/389ds v126.96.36.199 to RHEL7/CentOS7.
We are running three replicated master 389ds server in a busy production
environment (~30000 entries, ~20 requests/sec on each master) with several
plugins activated (memberOf, referential integrity, pam passthroughcat,
uniqueness, usn) and a lot of custom indexes.
What is the current stable recommended version for production on RHEL7? We
are compiling the binaries from sources, so we are not limited by the
availability of rpms.
I see that there are three git branches maintained : 1.2.11, 1.3.1 and
1.3.2, there is also an "official" rpm package 1.3.1 in RHEL7.
Does it mean that 1.3.1 is considered as stable version for RHEL7? As I can
see, not all the fixes are back-ported from 1.3.2 to 1.3.1 (ex
https://fedorahosted.org/389/ticket/47313#comment:20). So is there any
reason to use 1.3.2 instead of 1.3.1 or 1.3.2 is still not considered
I've just installed 389 on a fresh, fully patched CentOS 6.5 x86_64
box from EPEL and am seeing the attached display issue when accessing
the Directory Server Gateway. My client machine is a Mac running OS X
10.9.3, on which I've tested with:
I also see the issue on Firefox 24.6.0 running on RHEL 7.
EnterpriseDB UK: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
Kind 389 devs,
i am on 188.8.131.52 and for my environment - it’s been great!
I have been watching the tickets with respect to 184.108.40.206 and I am curious as to when this release may be available? There are a few items pertaining to my environment which we would so dearly appreciate. 346 would be a HUGE win for us. We are seeing periodic problems which seem to indicate 47773/4 may address as well. I recognize you guys bust your butts and I truly hate asking this question - but please know your work is so appreciated.
thank you so much!
I'm suddenly stumped by self-signed certs.
I used the setupssl2.sh script to generate my certs and install them into
my ldap. I end up with this --
# certutil -L -d .
Certificate Nickname Trust Attributes
CA certificate CTu,u,u
getent is able to see my ldap accounts and ldapsearch -ZZ returns
successfully. But I can't authenticate successfully unless I add
TLS_ReqCert allow to my ldap configs on my client. But what is weird is I
*know* that this has worked in the past.
OS 2.6.39-300.26.1.el6uek.x86_64 6.5 (Santiago)
When I try to authenticate I get this error message:
Jul 3 13:03:03 myserver nslcd: [495cff] ldap_result() failed:
Can't contact LDAP server
Googling this it looks like it doesn't trust my CA. But I *KNOW* that
this has worked in the past. But we have patched our clients recently and
have newer release of openssl. Does anyone have any idea of how I can get