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.ase...@gmail.com <mailto:natxo.ase...@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@lists.fedorahosted.org
To unsubscribe send an email
tofreeipa-users-le...@lists.fedorahosted.org
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to
freeipa-users-le...@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
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org
