On 02/15/2018 04:50 AM, Florence Blanc-Renaud wrote:
On 02/15/2018 10:08 AM, Florence Blanc-Renaud via FreeIPA-users
wrote:
> On 02/14/2018 05:58 PM, Bret Wortman wrote:
>> On 02/14/2018 10:22 AM, Florence Blanc-Renaud wrote:
>>> On 02/14/2018 12:52 PM, Bret Wortman via FreeIPA-users wrote:
>>>> I did figure out that I can use
>>>>
>>>> # ldapsearch -D 'directory manager' -W -E pr=20000 -b
>>>> idnsname=damascusgrp.com,cn=dns,dc=damascusgrp,dc=com
>>>>
>>>> to list out all the entries, but the format isn't what I'm
expecting.
>>>>
>>>> What I'm actually trying to do is move our whole infrastructure
>>>> from one set of old & busted servers to some shiny new VMs. We'd
>>>> like to extract the data and start fresh, as our replication
>>>> agreements just don't seem to be working as expected. Changes to
>>>> one don't always make it to the other and vice versa. While I'd
>>>> love to dig in and solve that, it's easier right now to try to
>>>> extract the data and reload it into a new server, build new
>>>> replicas, then unbind & re-bind every client to the new server
>>>> using ansible since we also lost our internal CA in the process.
>>>>
>>>> So while our current configuration is a mess, we can't afford to
>>>> lose all the host/user/dns/hbac data in our servers. Thus, I've
>>>> been capturing the output to text using various ipa *-find
>>>> commands and have parsers to turn those back into new entries on
>>>> the fresh hosts. DNS is the only thing that's holding me up.
>>>>
>>>>
>>>> Bret
>>>>
>>>>
>>>> On 02/14/2018 06:33 AM, Bret Wortman wrote:
>>>>>
>>>>> Also, this doesn't solve the fact that the Web UI always produces
>>>>> an error dialog whenever accessing our primary zone.
>>>>>
>>>>>
>>>>> On 02/13/2018 02:19 PM, Natxo Asenjo via FreeIPA-users wrote:
>>>>>>
>>>>>>
>>>>>> On Tue, Feb 13, 2018 at 8:13 PM, Natxo Asenjo
>>>>>> <natxo.asenjo(a)gmail.com
<mailto:natxo.asenjo@gmail.com>> wrote:
>>>>>>
>>>>>>
>>>>>> the canonical way to do this is using ldap paging, with
>>>>>> ldapsearch you could try using the -E pr=xxxx parameter,
where
>>>>>> xxxx could be 1000 for instance. That way you know you are
>>>>>> always
>>>>>> under the limit imposed by the server.
>>>>>>
>>>>>>
>>>>>> if you use -E pr=1000/noprompt, it will not prompt to continue,
>>>>>> nicer for scripts obviously.
>>>>>>
>>>>>> --
>>>>>> Groeten,
>>>>>> natxo
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> FreeIPA-users mailing list
--freeipa-users(a)lists.fedorahosted.org
>>>>>> To unsubscribe send an email
>>>>>> tofreeipa-users-leave(a)lists.fedorahosted.org
>>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
>>>> To unsubscribe send an email to
>>>> freeipa-users-leave(a)lists.fedorahosted.org
>>>>
>>> Hi Bret,
>>>
>>> the search limits can be set at multiple levels:
>>> - for the whole 389-ds server
>>> nsslapd-sizelimit (in cn=config)
>>> nsslapd-lookthroughlimit (in cn=config,cn=ldbm
>>> database,cn=plugins,cn=config)
>>>
>>> - for operations performed through ipa * commands (or the webGUI):
>>> ipaSearchRecordsLimit (in cn=ipaConfig,cn=etc,$BASEDN)
>>>
>>> - for each user:
>>> nssizelimit and nsLookThroughLimit attributes (in
>>> uid=$USER,cn=users,cn=accounts,$BASEDN)
>>>
>>> You are probably hitting one of these limits in your ipa *-find
>>> command.
>>>
>>> HTH,
>>> Flo
>>>
>>
>> So I found almost all of these:
>>
>> # ldapsearch -D 'cn=directory manager' -W -b 'cn=config'
cn=config |
>> grep nsslapd-sizelimit
>> nsslapd-sizelimit: 2000
>>
>> # ldapsearch -D 'cn=directory manager' -W -b 'cn=config,cn=ldbm
>> database,cn=plugins,cn=config' | grep lookthroughlimit
>> nsslapd-lookthroughlimit: 100000
>>
>> # ldapsearch -D 'cn=directory manager' -W -b
>> 'cn=ipaConfig,cn=etc,dc=damascusgrp,dc=com' | grep
>> ipaSearchRecordsLimit
>> ipaSearchRecordsLimit: 99999
>>
>> # ldapsearch -D 'cn=directory manager' -W -b
>> 'uid=admin,cn=users,cn=accounts,dc=damascusgrp,dc=com' | grep -i limit
>> (returns data but nothing matches)
>>
> Hi,
>
> nsSizeLimit and nsLookThroughLimit are operational attributes,
> meaning that a standard ldapsearch will not return them. You need
> either to specifically request them by providing them in the
> attributes list:
>
> $ ldapsearch -D 'cn=directory manager' -W -b $BASE nssizelimit
> nslookthroughlimit
>
> or you can also specify + instead of the attributes in order to get
> all operational attributes:
> $ ldapsearch -D 'cn=directory manager' -W -b $BASE +
>
> HTH,
> Flo
>
>> The first doesn't seem to be something I can change. It's stuck at
>> 2000, but since my issue occurs at 5000, I'm not worried about it. I
>> believe that I'm missing something in the fourth search that might
>> point me toward the attributes you mentioned but I'm not sure where.
>>
The 5000 limit rings a bell to me. It is the anonymous size limit. Can
you check:
$ ldapsearch -D 'cn=directory manager' -W -b cn=config -s base
nsslapd-anonlimitsdn
it will provide you with a DN of the entry defining the anonymous
limits (usually cn=anonymous-limits,cn=etc,$BASEDN), then:
$ ldapsearch -D 'cn=directory manager' -W -b
cn=anonymous-limits,cn=etc,$BASEDN nsSizeLimit nsLookThroughLimit
Now we should check the access log (/var/log/dirsrv/slapd-xxx/access)
corresponding to your command to retrieve the DNS entries, and ensure
which user identity is actually performing the search.
Flo
>>
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-users-leave(a)lists.fedorahosted.org
Both those limits are 5000.
What should I be looking for in the access log? It gets a lot of traffic
and narrowing down exactly which entry represents the original search is
challenging. I'd rather not post the whole thing because it's pretty
large & noisy.
Bret