On to, 15 helmi 2018, Florence Blanc-Renaud via FreeIPA-users 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.
I think we can also add 2 to
nsslapd-errorlog-level to see a trace log
which is used by the reslimit code.
You can achieve this with ipa-ldap-updater easily:
# cat ./50-errorlog-on.update
dn: cn=config
replace: nsslapd-errorlog-level:16384::16386
# ipa-ldap-updater ./50-errorlog-on.update
Update complete
The ipa-ldap-updater command was successful
16384 is the default log level in 389-ds. If you already have something
else, add 2 to that value and update the file. To revert back, place the
numbers in the file in the opposite order and re-run ipa-ldap-updater.
Now retry your ldapsearch and see if there are any reslimit-related
messages in the /var/log/dirsrv/slapd-INSTANCE/errors
--
/ Alexander Bokovoy