When configuring Microsoft Outlook (not Outlook Express) to access an LDAP directory, there is an option to 'Enable Browsing (requires server support)'. If this option is chosen and the directory server supports it, then you should be able to open the LDAP address book and page up and down through the results. I have been unable to get this working properly with 389 DS.
When I try to browse from Outlook against the 389 DS directory, I am able to see the first page of results perfectly. However, if I move to the next page, only the first object returned will have any attributes included, and all of the rest of the objects in the page will have no attributes. I have a test perl script that duplicates this functionality as well.
I can get this to work properly with an older version of Netscape Directory Server, and I can get it working with OpenDS. Since 389 DS advertises support for the controls that are required for this to work, just like the other two servers, then I would expect it to work there also.
Has anyone out there gotten this to work with 389 DS? If so, can you share if there was anything special that you needed to do to get this to work? I'm trying to determine if this is a bug in the server, or if I'm just missing something in the configuration.
You Run Your Business. We'll Run Your Email.
This message is for the sole use of the intended recipient(s) and may contain confidential and/or privileged information of USA.NET, Inc. Any unauthorized review, use, copying, disclosure, or distribution is prohibited. If you are not the intended recipient, please immediately contact the sender by reply email and delete all copies of the original message.
I have seen the following message in the errors log file, when I set MMR agreements up:
[10/Aug/2010:11:46:44 -0400] NSMMReplicationPlugin - repl_set_mtn_referrals: could not set referrals for replica o=base: 1
[10/Aug/2010:11:46:44 -0400] NSMMReplicationPlugin - multimaster_be_state_change: replica o=base is going offline; disabling replication
[10/Aug/2010:11:46:46 -0400] - somehow, there are still 20 entries in the entrycache. :/
[10/Aug/2010:11:46:46 -0400] - WARNING: Import is running with nsslapd-db-private-import-mem on; No other process is allowed to access the database
[10/Aug/2010:11:46:48 -0400] - BAD CACHE ASSERTION at ../ldap/servers/slapd/back-ldbm/cache.c/765: e->ep_refcnt > 0
[10/Aug/2010:11:46:52 -0400] - Fedora-Directory/1.1.2 B2009.090.1643 starting up
[10/Aug/2010:11:46:52 -0400] - Detected Disorderly Shutdown last time DirectoryServer was running, recovering database.
After I re-initialize the database from the supplier (setting attribute nsds5BeginReplicaRefresh to start of the agreement object), the database gets correctly imported.
Any idea, what is going on?
one of our clients wants to use GOSA (https://oss.gonicus.de/labs/gosa/)
as a frontend for the 389 DS.
I found a number of postings that configuring GOSA to work with the 398
DS isn't easy.
Therefore my question is whether anyone has a working combination and
might publish a howto on it?
Otherwise I would have to find my way through it and write the docu on it.
Thanks for any hints & suggestions,
I've run into a situation where one of the files in /var/lib/dirsrv/<instance>/changelogdb has grown almost as large as the partition it's on. In my directory server configs, I noticed I was keeping an unlimited changelog, so I set that to what seems like a reasonably long amount of time (18 weeks) but didn't see any decrease in the file size. I'm wondering now about the best course of action. I can
a) move the whole dirsrv directory to another partition with more space available and symlink the old location to the new, which worked when I tested it, but I wanted to make sure I wouldn't be hosing something up the next time I upgrade.
b) find some means of manually shrinking the *.db ( can you even do that?)
c) point dirsrv at a new location, and reinitialize the consumers (which doesn't seem all that desirable)
Has anyone else found it necessary to shrink your changelogdb?
i had problems with "too many fds open" on some instances and after digging a bit i've found that ns-slapd dont die.
i got 5 similar installations and this is happening just in two of them and i can't identify what is about.
i've been recollecting process informations and i know for sure that the only process that keep increasing is ns-slapd and eventually, after some weeks, 389 starts refusing new connections and i got the "too many fds open" message.
i can increase max fds but the problem of processes keeping alive is still there.
anyone facing similar situation?
Regarding superior attributes, I found this email from 4 years ago:
In it, "Mike" said "Seems that my schema conversion tool doesn't support
attribute inheritance...[snip]...I will keep this in mind for a feature
rfc2252 defines superior attributes, and it was something I was using in my
schema definition since I have a lot of new attributes and all but 4 of them
had one of 5 different configs of "EQUALITY|ORDERING" and "SYNTAX". Not
only was it cleaner to be able to just inherit the syntax and matching
rules, it also was faster ;) Obviously, it doesn't keep me from doing
Was this ever looked at again for a feature enhancement? Is it already
available, if I do X thing?
During the schema reload, I got this error (for context):
dse - The entry cn=schema in file
/etc/dirsrv/slapd-(server)/schema/97hosting.ldif is invalid, error code 21
(Invalid syntax) - attribute type nocastr128: Missing parent attribute
I got it because I was using "SUP nocastr128" in an attributeType, after
defining an attributeType of nocastr128 with the base components I wanted to
ps - I have 2 more emails I'm sending; since they are on different subjects,
I thought I'd break them into different emails. Please let me know if this
was a bad idea and I won't do it again.
I am testing the 389 latest git version. There is one thing i have
noticed concerning Outlook browsing of LDAP and VLV indexes. Though i
think the change has happened already some time ago, in one of the
To make the LDAP Outlook browsing work correctly i've always used the steps described in the
dn: cn=Outlook Browse,cn=userRoot,cn=ldbm database,cn=plugins,cn=config
cn: Outlook Browse
dn: cn=Outlook Browse Index,cn=Outlook Browse,cn=userRoot,cn=ldbm database,cn=
cn: Outlook Browse Index
This creates a VLV index, sorts the entries by cn and shows them in Outlook :
[24/Aug/2010:16:42:19 +0200] conn=24 op=2 SRCH base="ou=utilisateurs,dc=id,dc=polytechnique,dc=edu" scope=2 filter="(&(mail=*)(cn=*))" attrs="cn cn mail roleOccupant display-name displayName sn sn co o o givenName legacyexchangedn objectClass uid mailnickname title company physicalDeliveryOfficeName telephoneNumber"
[24/Aug/2010:16:42:19 +0200] conn=24 op=2 SORT cn
[24/Aug/2010:16:42:19 +0200] conn=24 op=2 VLV 0:0:xac 7860:8001 (0)
[24/Aug/2010:16:42:19 +0200] conn=24 op=2 RESULT err=0 tag=101 nentries=1 etime=0.009000
[24/Aug/2010:16:42:19 +0200] conn=24 op=3 SRCH base="ou=utilisateurs,dc=id,dc=polytechnique,dc=edu" scope=2 filter="(&(mail=*)(cn=*))" attrs="cn cn mail roleOccupant display-name displayName sn sn co o o givenName legacyexchangedn objectClass uid mailnickname title company physicalDeliveryOfficeName telephoneNumber"
[24/Aug/2010:16:42:19 +0200] conn=24 op=3 SORT cn
[24/Aug/2010:16:42:19 +0200] conn=24 op=3 VLV 0:27:7859:8001 7860:8001 (0)
[24/Aug/2010:16:42:19 +0200] conn=24 op=3 RESULT err=0 tag=101 nentries=28 etime=0.019000
In (relatively old) previous versions of the server the sorting took
into account the accentuated letters (like é, for example). The CNs
with these letters were sorted correctly (that is, é after d and
before f). So the entries were sorted by VLV like this :
Tén Toys <<<--
With the recent versions the server orders the CN strictly according to ASCII
(i think) :
Tén Toys <<<--
That is, all the diacritical letters appear after "z".
I have looked into the vlv#outlookbrowseindex.db4 file by dbscan and
the order corresponds exactly to what Outlook shows.
The questions are :
-whether it is how it should work and
-how do i revert to the old server behavior.
The sorting with collation (that is, smth like
my $sort_control = Net::LDAP::Control::Sort -> new( order => "cn:2.16.840.1.113718.104.22.168.18.1.6", critical => 1)
) works perfectly (i.e. é is after d and before f).
I've tried several ideas to return to the old behavior :
*) i've tried to add collation rules to vlv index entries but putting
the value of the attribute vlvSort to
"cn:2.16.840.1.113722.214.171.124.18.1.6" or to "cn:fr" does not work
either. Instead of changing the sorting order it produces some strange
contents in the index vlv#outlookbrowseindex.db4 file.
**) then i thought that maybe i should change the cn index ordering
and i have added "nsMatchingRule: 2.16.840.1.1137126.96.36.199.18.1" to the
cn indexes in dse.ldif. However reindexing does not actually change
the order (even after reindexing by smth explicit like db2index -n
userRoot -t cn:eq,pres,sub:2.16.840.1.1137188.8.131.52.18.1 ) in the index
Direction des Systemes d'Information
91128 Palaiseau CEDEX
I have a Fedora DS + SSSD setup in Fedora 13 and it is working fine.
However, I found out the alias object is not functioning. Is that anything
I miss in the configuration?
The deferencing works fine in OpenLDAP.
Chau Chee Yang
Running 389-server 1.2.5 on RHEL 5 (Intel)
We have a single master replicating to two consumers. When I update the
ACIs on the master using ldapmodify, the ACIs are applied to the
supplier without error ...
[31/Aug/2010:09:18:37 -0300] conn=100572906 fd=81 slot=81 connection
from 184.108.40.206 to 220.127.116.11
[31/Aug/2010:09:18:37 -0300] conn=100572906 op=0 BIND dn="cn=directory
manager" method=128 version=3
[31/Aug/2010:09:18:37 -0300] conn=100572906 op=0 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=directory manager"
[31/Aug/2010:09:18:37 -0300] conn=100572906 op=1 MOD dn="dc=unb,dc=ca"
[31/Aug/2010:09:18:37 -0300] conn=100572906 op=1 RESULT err=0 tag=103
nentries=0 etime=0 csn=4c7cf31d000000010000
[31/Aug/2010:09:18:37 -0300] conn=100572906 op=2 UNBIND
[31/Aug/2010:09:18:37 -0300] conn=100572906 op=2 fd=81 closed - U1
One the consumer, I get the following ...
[31/Aug/2010:09:18:36 -0300] conn=30854964 fd=66 slot=66 connection from
18.104.22.168 to 22.214.171.124
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=0 BIND dn="cn=replication
manager, cn=config" method=128 version=3
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=0 RESULT err=0 tag=97
nentries=0 etime=0 dn="cn=replication manager,cn=config"
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=1 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=1 RESULT err=0 tag=101
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=2 SRCH base="" scope=0
filter="(objectClass=*)" attrs="supportedControl supportedExtension"
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=2 RESULT err=0 tag=101
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=3 EXT
oid="2.16.840.1.1137126.96.36.199" name="Netscape Replication Start Session"
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=3 RESULT err=0 tag=120
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=4 SRCH
scope=0 filter="(objectClass=*)" attrs="nsDS5ReplicaId"
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=4 RESULT err=32 tag=101
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=5 MOD dn="dc=unb,dc=ca"
[31/Aug/2010:09:18:36 -0300] conn=30854964 op=5 RESULT err=0 tag=103
nentries=0 etime=0 csn=4c7cf31d000000010000
[31/Aug/2010:09:18:38 -0300] conn=30854964 op=6 EXT
oid="2.16.840.1.1137188.8.131.52" name="Netscape Replication End Session"
[31/Aug/2010:09:18:38 -0300] conn=30854964 op=6 RESULT err=0 tag=120
[31/Aug/2010:09:19:38 -0300] conn=30854964 op=7 UNBIND
[31/Aug/2010:09:19:38 -0300] conn=30854964 op=7 fd=66 closed - U1
Of particular interest is the err=32 on the search for the
nsDS5ReplicaId. All other replication, including schema, is working as
expected. For some reason, just the ACI won't replicate. Any thoughts?
Terry Soucy, Systems Analyst Integrated Technology Services
University of New Brunswick, Fredericton Campus http://www.unbf.ca/its
Voice: 506.447.3018 Fax: 506.453.3590 E-mail: tsoucy(a)unb.ca
** ITS is a scent-reduced workplace - www.unbf.ca/its/policies **
It’s been a year since I announced the 1.0 release of my little open source project CN=Monitor (LDAP Monitoring) here on the 389 Users list.
A lot of features and improvements have been added since then.
If you are running 389 DS / CentOS DS or Red Hat DS and needs a web application to monitor your directory server environment(s) you should download the today released stable version 1.3.
* Live monitoring to view current load
* Collect historical events and view trends
* Replication, Cache status verification
* Verify server performance and load balancing
* Mobile phone GUI support
Best Regards - Andreas Andersson