Problem browsing LDAP with Outlook
by Chris Bryant
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.
2 years, 9 months
nsAccountLock - Server is unwilling to perform
by Mitja Mihelič
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
7 years, 5 months
Slow search results until cache populated
by Petteri Jekunen
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
7 years, 6 months
ldapsearch Max Return Result
by Joel Levin
Hi:
I searched --- probably not effectively --- where is setting for max
results returned by ldapsearch?
Thanks.
7 years, 6 months
Re: DS:caseIgnoreOrderingMatch-defaul messages
by ghiureai
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
7 years, 6 months
Re: multimaster replication and index corruption
by Rich Megginson
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...
>>>>>
>>>>> 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
>>>
>>
>
7 years, 6 months
Re: multimaster replication and index corruption
by ghiureai
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...
>>
>> 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
7 years, 6 months
DS:caseIgnoreOrderingMatch-defaul messages
by ghiureai
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
7 years, 6 months
ACI Strategy
by Joel Levin
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.
7 years, 6 months
