On 02/15/2018 07:09 AM, Florence Blanc-Renaud via FreeIPA-users wrote:
On 02/15/2018 11:47 AM, Bret Wortman via FreeIPA-users wrote:
>
>
> 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.
>
Hi,
you can perform the ipa dnsrecord-find --all command, while tail'ing
the access log. I will be interested in the lines containing the
SEARCH with a err=4 (size limit exceeded). For this SEARCH, please
note the connection number (conn=xx) and find the BIND for the same
connection number (it will be located before the SEARCH). For each
line (BIND and SEARCH) both the operation and the RESULT are
interesting, for instance when doing ipa user-find:
[date] conn=514 op=0 BIND dn="" method=sasl version=3 mech=GSS-SPNEGO
[date] conn=514 op=0 RESULT err=0 tag=97 nentries=0 etime=0.0004754873
dn="uid=admin,cn=users,cn=accounts,$BASEDN"
...
[date] conn=514 op=2 SRCH base="cn=users,cn=accounts,$BASEDN" scope=1
filter="(objectClass=posixaccount)" attrs="krbCanonicalName loginShell
sshpubkeyfp gidNumber homeDirectory uidNumber uid givenName title sn
krbPrincipalName mail nsAccountLock telephoneNumber ipaSshPubKey"
[date] conn=514 op=2 RESULT err=0 tag=101 nentries=6 etime=0.0006313857
Flo
> Bret
> _______________________________________________
> FreeIPA-users mailing list -- freeipa-users(a)lists.fedorahosted.org
> To unsubscribe send an email to
> freeipa-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
I did this and it's a massive amount
of information, but no err=4. I've
got err=14 and err=32, but no err=4. I also seem to get numerous SRCH
entries around the same time, and when tailing the log, the info flows
in in bursts. I wait for a gap, execute the command, get more log
entries, then the results all come out of the command, then there's
another burst of log entries. I'm really struggling to tell what's what
but will keep trying.