389-users November 2015

389-users@lists.fedoraproject.org

28 participants
32 discussions

Problem browsing LDAP with Outlook
by Chris Bryant 26 Aug '20

26 Aug '20

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. Thanks, Chris USA.NET 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.

3 2

Announcing 389 Windows Console 1.1.15
by Noriko Hosoi 23 Feb '16

23 Feb '16

389 Windows Console 1.1.15 The 389 Directory Server team is proud to announce 389-console-win version 1.1.15. Windows installers are available to download from Download 389 Windows Console (32-bit) <http://www.port389.org/binaries/389-Console-1.1.15-i386.msi> and Download 389 Windows Console (64-bit) <http://www.port389.org/binaries/389-Console-1.1.15-x86_64.msi>. Highlights in 389-console-win-1.1.15 * Windows Console now has the same bug fixes and enhancements made for the Fedora 389-console. Installation and Upgrade See Download <http://www.port389.org/docs/389ds/download.html> for information about setting up your yum repositories. To install and update, use Programs and Features on Control Panel. Feedback We are very interested in your feedback! If you find a bug, or would like to see a new feature, file it in our Trac instance: https://fedorahosted.org/389 Detailed Changelogs Please refer 389-console-1.1.19, 389-admin-console-1.1.10 release notes <http://www.port389.org/docs/389ds/releases/release-console-1-1-9.html> and 389-ds-console-1.2.12 and idm-console-framework-1.1.14 release notes <http://www.port389.org/docs/389ds/releases/release-ds-console-1-2-12.html>. http://www.port389.org/docs/389ds/releases/release-windows-console-1-1-15.h…

2 2

nsAccountLock - Server is unwilling to perform
by Mitja Mihelič 15 Dec '15

15 Dec '15

Hi! We are using using nsAccountLock=true to lock user accounts. We also have dovecot authenticating users against the 389DS. If we set nsAccountLock=true, then we get Oct 20 14:39:30 SERVER dovecot: auth: Error: ldap(USERNAME,193.X.Y.Z,<aaaaaaaaaaaaaaaa>): ldap_bind() failed: Server is unwilling to perform Oct 20 14:39:31 SERVER dovecot: auth: ldap(USERNAME,193.X.Y.Z,<aaaaaaaaaaaaaaaa>): Falling back to expired data from cache Dovecot thinks the server is not working properly so it reads login info from its cache and authentication succeeds. Can I set 389DS to return a different response? Something that says: "User is locked" or "Authentication failed"... Kind regards, Mitja -- -- Mitja Mihelič ARNES, Tehnološki park 18, p.p. 7, SI-1001 Ljubljana, Slovenia tel: +386 1 479 8800, fax: +386 1 479 88 99

3 4

Slow search results until cache populated
by Petteri Jekunen 03 Dec '15

03 Dec '15

Hi, Is it just ordinary behavior with 389 DS that search results may take a very loong time just after starting the server when there are no entries in the cache yet? And when the cache is fully saturated (enough cache configured for all the entries) results become dramatically down - for instance from 4 minutes to 4 seconds. If this this is so, is there anything that could be done to fill in the cache automatically after startup? We have some 60 000 entries, RHEL 7.1, 389-Directory/1.3.3.1 B2015.267.1737 on VMWare. We have quite a heavy use of roles, and this seems to be a significant issue especially with them - or at least with them. We have used the Sun DSEE previously and are quite new to 389 DS. The technology seems very similar although. Thanks a lot in advance! Regards, Petteri Jekunen, Tampere University of Applied Sciences

4 7

ldapsearch Max Return Result
by Joel Levin 01 Dec '15

01 Dec '15

Hi: I searched --- probably not effectively --- where is setting for max results returned by ldapsearch? Thanks.

3 3

Re: DS:caseIgnoreOrderingMatch-defaul messages
by ghiureai 25 Nov '15

25 Nov '15

HI William and list , here is the result for ldapsearch as per your request: sudo -i rpm -V 389-ds-base .M....G.. /etc/dirsrv ldapsearch -x -H ldap://localhost -D 'cn=Directory Manager' -W -b cn=config '(nsslapd-pluginInitfunc=cis_init)' Enter LDAP Password: # extended LDIF # # LDAPv3 # base <cn=config> with scope subtree # filter: (nsslapd-pluginInitfunc=cis_init) # requesting: ALL # # Case Ignore String Syntax, plugins, config dn: cn=Case Ignore String Syntax,cn=plugins,cn=config objectClass: top objectClass: nsSlapdPlugin objectClass: extensibleObject cn: Case Ignore String Syntax nsslapd-pluginPath: libsyntax-plugin nsslapd-pluginInitfunc: cis_init nsslapd-pluginType: syntax nsslapd-pluginEnabled: on nsslapd-pluginId: directorystring-syntax nsslapd-pluginVersion: 1.2.11.15 nsslapd-pluginVendor: 389 Project nsslapd-pluginDescription: DirectoryString attribute syntax plugin # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1

2 1

Re: multimaster replication and index corruption
by Rich Megginson 24 Nov '15

24 Nov '15

On 11/24/2015 10:28 AM, ghiureai wrote: > On 11/24/2015 09:11 AM, Rich Megginson wrote: >> On 11/24/2015 10:02 AM, ghiureai wrote: >>> >>> >>> Rich and the List Thank for your continue support, >>> >>> We are still seeing a index issues with memberof plugging, we are >>> not sure at this point if this is related to our software or the >>> plugin cfg behavior, I see 2 entries files.db4 for memberof plugin >>> see bellow, is this correct? >>> the 389-admin GUI shows only the memberof indexed, when I try to >>> check for index corruption and run >>> >>> -rw------- 1 ldap-ds ldap-ds 4005888 Oct 20 13:01 memberOf.db4 >>> --rw------- 1 ldap-ds ldap-ds 3915776 Nov 23 07:58 memberof.db4 >> >> That's very bad. I thought we fixed that case issue with db files a >> long time ago. > So, how do I fix this 2 files for memberof ? Try shutting down the server, then remove those two files, then use db2index to recreate the memberof index. >> >>> >>> when I try to check for index values and use either memberof or >>> memberOf files for the following attribute fails, what I am missing? >>> >>> >>> dbscan -f /var/lib/dirsrv/slapd-ldap/db/userRoot/memberof.db4 >>> -k "dc=xxx,dc=com" >>> Can't find key 'dc=xxx,dc=com' >>> >> >> Not sure. Try doing dbscan -f >> /var/lib/dirsrv/slapd-ldap/db/userRoot/memberof.db4 first, to see >> what the keys look like > > >> >>> same for >>> >>> >>> memberOf.db4 file >>> >> >> >>> >>> >>> Thank you >>> Isabella >>> >>> On 11/10/2015 11:12 AM, ghiureai wrote: >>>> Rich, thank you for all support for last day , unfortunately there is a >>>> strong wave in developers team:" the multimaster replication is creating >>>> issues with UI" ( I do not totally agree since can not be reproduce+ >>>> full describe the issues). >>>> Is been decided to moved down to master slave, please I need to know if >>>> I still need to exclude member of plugin from replication in this case ? >>>> >>>> >>>> >>>> Thanks a lot >>>> Isabella >>>> On 11/10/2015 09:23 AM, Rich Megginson wrote: >>>>> On 11/10/2015 10:14 AM, Adrian Damian wrote: >>>>>> Rich, >>>>>> >>>>>> Thanks for your help. Let me jump in with more details. >>>>>> >>>>>> We've seen index corruption on a number of occasions. It seems to >>>>>> affect searchable attributes for which there are indexes. Queries on >>>>>> an attribute in LDAP that used to work suddenly stopped working. They >>>>>> would return incomplete results and no results at all, although the >>>>>> data on the server was the same. The fix on those situations was to >>>>>> drop the index corresponding to the attribute and re-create it. >>>>> So in this case, you have some sort of LDAP search client, and you are >>>>> doing a search for '(indexed_attribute=known_value)' and you are not >>>>> seeing a result, and this is what you mean by "index corruption"? >>>>> >>>>> Are you aware of the dbscan tool? >>>>> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/h… >>>>> >>>>> This tool allows you to examine the index file in the database directly. >>>>> >>>>> dbscan -f >>>>> /var/lib/dirsrv/slapd-instance_name/db/userRoot/indexed_attribute.db4 -k >>>>> known_value >>>>> >>>>> This will allow you to look at the indexed_attribute index directly for >>>>> the value "known_value". >>>>> >>>>>> We've run the db fix script that the LDAP distribution comes with >>>>> What db fix script? Do you have a link to it, or a link to the product >>>>> documentation for the script? >>>>> >>>>>> and there are no reports of corruption when this problem occurs. That >>>>>> makes it very hard to detect. We don't know what else to look for when >>>>>> we run into this again and more importantly, we don't know what >>>>>> triggers it and how to prevent it. >>>>>> >>>>>> Mind you we are currently doing active development changing both the >>>>>> software clients that access the LDAP servers as well as the >>>>>> configurations of the servers. It is possible to had been written to >>>>>> both masters in the master replication configuration when the problem >>>>>> occurred but because there were multiple clients concurrently >>>>>> accessing the servers it is hard to figure out what triggered the issue. >>>>>> >>>>>> >>>>>> Adrian >>>>>> >>>>>> >>>>>> >>>>>> On 11/09/2015 05:06 PM, Rich Megginson wrote: >>>>>>> On 11/09/2015 05:47 PM, Ghiurea, Isabella wrote: >>>>>>>> Hi Rich, >>>>>>>> Thank you for your feedback , as always greatly appreciate when >>>>>>>> comes from 389-DS RH support. >>>>>>>> We are not using vm just plain hardware, here is the description >>>>>>>> I got from developers team related to the issues they are seeing >>>>>>>> when running integration tests with multimaster replication : >>>>>>>> "index corruption: put content, run tests: OK, do more stuff (reads, >>>>>>>> writes, etc), ru tests: FAIL, notice "missing attributes", rebuild >>>>>>>> index(ices), run tests: OK. " >>>>>>> What does this mean? What program is printing these index corruption >>>>>>> messages? Is it some tool provided by Red Hat? >>>>>>> >>>>>>>> Unfortunately, I understood this cases/issue can not be reproduce >>>>>>>> on regular basis, no mode details can be provide at this time >>>>>>>> >>>>>>>> All reads and writes are going to only the master replication DS, >>>>>>>> not slave . >>>>>>>> I totally agree with your this is the way to cfg and maintain >>>>>>>> Directory Server in a operation critical env: multmaster >>>>>>>> replication only one master for writes. >>>>>>>> Here is the DS version: >>>>>>>> rpm -qa | grep 389-ds >>>>>>>> 389-ds-console-doc-1.2.6-1.el6.noarch >>>>>>>> 389-ds-base-libs-1.2.11.15-34.el6_5.x86_64 >>>>>>>> 389-ds-1.2.2-1.el6.noarch >>>>>>>> 389-ds-base-1.2.11.15-34.el6_5.x86_64 >>>>>>> This is quite an old version of 389-ds-base. I suggest upgrading to >>>>>>> RHEL 6.7 with latest patches. >>>>>>> >>>>>>>> 389-ds-console-1.2.6-1.el6.noarch >>>>>>>> >>>>>>>> >>>>>>>> Thank you >>>>>>>> Isabella >>>>>>>> >>>>>>>> FWD: >>>>>>>> >>>>>>>> >>>>>>>> We have cfg multimaster replication /fractional replication memberof >>>>>>>> plugging excluded , we are seeing from time to time index corruption >>>>>>>> with some indexes , there is a strong feeling from developers this >>>>>>>> are related to DS multimaster replication internal settings. >>>>>>>> What version of 389? rpm -q 389-ds-base >>>>>>>> I'm assuming you are not using IPA. >>>>>>>> What does "index corruption" mean? What exactly do you see? >>>>>>>> >>>>>>>> Are you running in virtual machines? If so, what kind? vmware? kvm? >>>>>>>> Are you using virtual disks or dedicated physical devices/paravirt? >>>>>>>> >>>>>>>> We are writing to only one DS , same server at all time but reading >>>>>>>> from all DS 's cfg for mutlmaster. >>>>>>>> Are you seeing "index corruption" on the write master or on all >>>>>>>> servers? >>>>>>>> >>>>>>>> >>>>>>>> Are other people seen this kind of issues with multimaster rep cfg , >>>>>>>> should we start avoiding this replication cfg at all ? >>>>>>>> >>>>>>>> This is the recommended way to deploy. If this is not working for >>>>>>>> you, either you have a configuration problem, or there is some sort >>>>>>>> of vm or hardware problem, or there is a serious bug that requires >>>>>>>> fixing ASAP. >>>>>>>> >>>>>>>> We choose the multimaster for the fast and reliable option to switch >>>>>>>> between master DS's , moving one step down to master/slave may >>>>>>>> require some down time when switching DS's back. >>>>>>>> Isabella >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Hi Rich, >>>>>>>> Thank you for your feedback , as always greatly appreciate when >>>>>>>> comes from 389-DS RH support. >>>>>>>> We are not using vm just plain hardware, here is the description >>>>>>>> I got from developers team related to the issues they are seeing >>>>>>>> when running tests with multimaster replication :index corruption: >>>>>>>> put content, run tests: OK, do more stuff (reads, writes, etc), ru >>>>>>>> tests: FAIL, notice "missing attributes", rebuild index(ices), run >>>>>>>> tests: OK. >>>>>>>> >>>>>>>> I belive we the reads and writes right now are only the master >>>>>>>> replication DS , not slave . >>>>>>>> I totally agree with your this is the way to cfg and maint DS in a >>>>>>>> operation env: multmaster replication with one master for writes. >>>>>>>> More comments , imput I appreciate >>>>>>>> rpm -qa | grep 389-ds >>>>>>>> 389-ds-console-doc-1.2.6-1.el6.noarch >>>>>>>> 389-ds-base-libs-1.2.11.15-34.el6_5.x86_64 >>>>>>>> 389-ds-1.2.2-1.el6.noarch >>>>>>>> 389-ds-base-1.2.11.15-34.el6_5.x86_64 >>>>>>>> 389-ds-console-1.2.6-1.el6.noarch >>>>>>>> 389-dsgw-1.1.11-1.el6.x86_64 >>>>>>>> >>>>>>>> ________________________________________ >>>>>>>> From: ghiureai [isabella.ghiurea(a)nrc-cnrc.gc.ca] >>>>>>>> Sent: Monday, November 09, 2015 1:05 PM >>>>>>>> To:389-users@lists.fedoraproject.org >>>>>>>> Subject: multimaster replication and index corruption >>>>>>>> >>>>>>>> Hi List, >>>>>>>> We have cfg multimaster replication /fractional replication memberof >>>>>>>> plugging excluded , we are seeing from time to time index corruption >>>>>>>> with some indexes , there is a strong feeling from developers this are >>>>>>>> related to DS multimaster replication internal settings. >>>>>>>> We are writing to only one DS , same server at all time but reading >>>>>>>> from all DS 's cfg for mutlmaster. >>>>>>>> Are other people seen this kind of issues with multimaster rep cfg , >>>>>>>> should we start avoiding this replication cfg at all ? >>>>>>>> We choose the multimaster for the fast and reliable option to switch >>>>>>>> between master DS's , moving one step down to master/slave may require >>>>>>>> some down time when switching DS's back. >>>>>>>> Isabella >>>>>>> -- >>>>>>> 389 users mailing list >>>>>>> 389-users(a)lists.fedoraproject.org >>>>>>> https://admin.fedoraproject.org/mailman/listinfo/389-users >>> >> >

1 0

Re: multimaster replication and index corruption
by ghiureai 24 Nov '15

24 Nov '15

Rich and the List Thank for your continue support, We are still seeing a index issues with memberof plugging, we are not sure at this point if this is related to our software or the plugin cfg behavior, I see 2 entries files.db4 for memberof plugin see bellow, is this correct? the 389-admin GUI shows only the memberof indexed, when I try to check for index corruption and run -rw------- 1 ldap-ds ldap-ds 4005888 Oct 20 13:01 memberOf.db4 --rw------- 1 ldap-ds ldap-ds 3915776 Nov 23 07:58 memberof.db4 when I try to check for index values and use either memberof or memberOf files for the following attribute fails, what I am missing? dbscan -f /var/lib/dirsrv/slapd-ldap/db/userRoot/memberof.db4 -k "dc=xxx,dc=com" Can't find key 'dc=xxx,dc=com' same for memberOf.db4 file Thank you Isabella On 11/10/2015 11:12 AM, ghiureai wrote: > Rich, thank you for all support for last day , unfortunately there is a > strong wave in developers team:" the multimaster replication is creating > issues with UI" ( I do not totally agree since can not be reproduce+ > full describe the issues). > Is been decided to moved down to master slave, please I need to know if > I still need to exclude member of plugin from replication in this case ? > > > > Thanks a lot > Isabella > On 11/10/2015 09:23 AM, Rich Megginson wrote: >> On 11/10/2015 10:14 AM, Adrian Damian wrote: >>> Rich, >>> >>> Thanks for your help. Let me jump in with more details. >>> >>> We've seen index corruption on a number of occasions. It seems to >>> affect searchable attributes for which there are indexes. Queries on >>> an attribute in LDAP that used to work suddenly stopped working. They >>> would return incomplete results and no results at all, although the >>> data on the server was the same. The fix on those situations was to >>> drop the index corresponding to the attribute and re-create it. >> So in this case, you have some sort of LDAP search client, and you are >> doing a search for '(indexed_attribute=known_value)' and you are not >> seeing a result, and this is what you mean by "index corruption"? >> >> Are you aware of the dbscan tool? >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/10/h… >> >> This tool allows you to examine the index file in the database directly. >> >> dbscan -f >> /var/lib/dirsrv/slapd-instance_name/db/userRoot/indexed_attribute.db4 -k >> known_value >> >> This will allow you to look at the indexed_attribute index directly for >> the value "known_value". >> >>> We've run the db fix script that the LDAP distribution comes with >> What db fix script? Do you have a link to it, or a link to the product >> documentation for the script? >> >>> and there are no reports of corruption when this problem occurs. That >>> makes it very hard to detect. We don't know what else to look for when >>> we run into this again and more importantly, we don't know what >>> triggers it and how to prevent it. >>> >>> Mind you we are currently doing active development changing both the >>> software clients that access the LDAP servers as well as the >>> configurations of the servers. It is possible to had been written to >>> both masters in the master replication configuration when the problem >>> occurred but because there were multiple clients concurrently >>> accessing the servers it is hard to figure out what triggered the issue. >>> >>> >>> Adrian >>> >>> >>> >>> On 11/09/2015 05:06 PM, Rich Megginson wrote: >>>> On 11/09/2015 05:47 PM, Ghiurea, Isabella wrote: >>>>> Hi Rich, >>>>> Thank you for your feedback , as always greatly appreciate when >>>>> comes from 389-DS RH support. >>>>> We are not using vm just plain hardware, here is the description >>>>> I got from developers team related to the issues they are seeing >>>>> when running integration tests with multimaster replication : >>>>> "index corruption: put content, run tests: OK, do more stuff (reads, >>>>> writes, etc), ru tests: FAIL, notice "missing attributes", rebuild >>>>> index(ices), run tests: OK. " >>>> What does this mean? What program is printing these index corruption >>>> messages? Is it some tool provided by Red Hat? >>>> >>>>> Unfortunately, I understood this cases/issue can not be reproduce >>>>> on regular basis, no mode details can be provide at this time >>>>> >>>>> All reads and writes are going to only the master replication DS, >>>>> not slave . >>>>> I totally agree with your this is the way to cfg and maintain >>>>> Directory Server in a operation critical env: multmaster >>>>> replication only one master for writes. >>>>> Here is the DS version: >>>>> rpm -qa | grep 389-ds >>>>> 389-ds-console-doc-1.2.6-1.el6.noarch >>>>> 389-ds-base-libs-1.2.11.15-34.el6_5.x86_64 >>>>> 389-ds-1.2.2-1.el6.noarch >>>>> 389-ds-base-1.2.11.15-34.el6_5.x86_64 >>>> This is quite an old version of 389-ds-base. I suggest upgrading to >>>> RHEL 6.7 with latest patches. >>>> >>>>> 389-ds-console-1.2.6-1.el6.noarch >>>>> >>>>> >>>>> Thank you >>>>> Isabella >>>>> >>>>> FWD: >>>>> >>>>> >>>>> We have cfg multimaster replication /fractional replication memberof >>>>> plugging excluded , we are seeing from time to time index corruption >>>>> with some indexes , there is a strong feeling from developers this >>>>> are related to DS multimaster replication internal settings. >>>>> What version of 389? rpm -q 389-ds-base >>>>> I'm assuming you are not using IPA. >>>>> What does "index corruption" mean? What exactly do you see? >>>>> >>>>> Are you running in virtual machines? If so, what kind? vmware? kvm? >>>>> Are you using virtual disks or dedicated physical devices/paravirt? >>>>> >>>>> We are writing to only one DS , same server at all time but reading >>>>> from all DS 's cfg for mutlmaster. >>>>> Are you seeing "index corruption" on the write master or on all >>>>> servers? >>>>> >>>>> >>>>> Are other people seen this kind of issues with multimaster rep cfg , >>>>> should we start avoiding this replication cfg at all ? >>>>> >>>>> This is the recommended way to deploy. If this is not working for >>>>> you, either you have a configuration problem, or there is some sort >>>>> of vm or hardware problem, or there is a serious bug that requires >>>>> fixing ASAP. >>>>> >>>>> We choose the multimaster for the fast and reliable option to switch >>>>> between master DS's , moving one step down to master/slave may >>>>> require some down time when switching DS's back. >>>>> Isabella >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Hi Rich, >>>>> Thank you for your feedback , as always greatly appreciate when >>>>> comes from 389-DS RH support. >>>>> We are not using vm just plain hardware, here is the description >>>>> I got from developers team related to the issues they are seeing >>>>> when running tests with multimaster replication :index corruption: >>>>> put content, run tests: OK, do more stuff (reads, writes, etc), ru >>>>> tests: FAIL, notice "missing attributes", rebuild index(ices), run >>>>> tests: OK. >>>>> >>>>> I belive we the reads and writes right now are only the master >>>>> replication DS , not slave . >>>>> I totally agree with your this is the way to cfg and maint DS in a >>>>> operation env: multmaster replication with one master for writes. >>>>> More comments , imput I appreciate >>>>> rpm -qa | grep 389-ds >>>>> 389-ds-console-doc-1.2.6-1.el6.noarch >>>>> 389-ds-base-libs-1.2.11.15-34.el6_5.x86_64 >>>>> 389-ds-1.2.2-1.el6.noarch >>>>> 389-ds-base-1.2.11.15-34.el6_5.x86_64 >>>>> 389-ds-console-1.2.6-1.el6.noarch >>>>> 389-dsgw-1.1.11-1.el6.x86_64 >>>>> >>>>> ________________________________________ >>>>> From: ghiureai [isabella.ghiurea(a)nrc-cnrc.gc.ca] >>>>> Sent: Monday, November 09, 2015 1:05 PM >>>>> To: 389-users(a)lists.fedoraproject.org >>>>> Subject: multimaster replication and index corruption >>>>> >>>>> Hi List, >>>>> We have cfg multimaster replication /fractional replication memberof >>>>> plugging excluded , we are seeing from time to time index corruption >>>>> with some indexes , there is a strong feeling from developers this are >>>>> related to DS multimaster replication internal settings. >>>>> We are writing to only one DS , same server at all time but reading >>>>> from all DS 's cfg for mutlmaster. >>>>> Are other people seen this kind of issues with multimaster rep cfg , >>>>> should we start avoiding this replication cfg at all ? >>>>> We choose the multimaster for the fast and reliable option to switch >>>>> between master DS's , moving one step down to master/slave may require >>>>> some down time when switching DS's back. >>>>> Isabella >>>> -- >>>> 389 users mailing list >>>> 389-users(a)lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/389-users

3 2

DS:caseIgnoreOrderingMatch-defaul messages
by ghiureai 21 Nov '15

21 Nov '15

HI LIst, I am looking for clues to solve this messages after a export or DS reboot we are seeing this messages, I checked the 2 plugins: caseExactString and CaseIgnore String theya re both enabled , where else should I look? DS version: 389-ds-console-1.2.6-1.el6.noarch [18/Nov/2015:21:59:04 -0800] - line 98: collation en "" "" 3 3 2.16.840.1.113730.3.3.2.11.3 [18/Nov/2015:21:59:04 -0800] plugin_mr_find - Error: matching rule plugin for [caseIgnoreOrderingMatch-default] not found [18/Nov/2015:21:59:04 -0800] plugin_mr_find - Error: matching rule plugin for [caseIgnoreSubstringMatch-default] not found [18/Nov/2015:21:59:04 -0800] plugin_mr_find - Error: matching rule plugin for [caseIgnoreOrderingMatch-default] not found [18/Nov/2015:21:59:04 -0800] plugin_mr_find - Error: matching rule plugin for [caseIgnoreSubstringMatch-default] not found [18/Nov/2015:21:59:04 -0800] plugin_mr_find - Error: matching rule plugin for [caseIgnoreSubstringMatch-default] not found [18/Nov/2015:21:59:04 -0800] - Backend Instance(s): Thank you Isabella

3 4

ACI Strategy
by Joel Levin 21 Nov '15

21 Nov '15

Hi All: We have a fairly newly installed 389 running ---- although early days, the ACI is getting cumbersome to manage/audit. Would anyone know of strategy articles to manage ACIs? Thanks.

2 1

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

389-users November 2015