[389-users] Re: CentOS-Directory/8.1.0 B2009.134.1334 ldapsearch problem

[Mark Reynolds]

On 08/18/2017 10:18 AM, Kirk MacDonald wrote:
> Hello,
>
> I'm working on migrating from CentOS-Directory/8.1.0 B2009.134.1334 to 
> 389-Directory/1.3.5.10 B2017.145.2037.
>
> What I'm finding is that the Database Export functions in the 
> CentOS-Directory/8.1.0 B2009.134.1334 Console as well as ldapsearches aren't 
> returning all entries. Specifically an objectclass=* search filter for a 
> given ou fails to output all entries. However if the search filter is for an 
> attribute which exists, all applicable entries are returned.
>
> The Console also does not show entries that might otherwise be found with a 
> ldapsearch and a specific search filter.
>
> Based on some experience I have with another LDAP system this feels like an 
> ancestorid problem.
>
> Can anyone offer any tips/thoughts or questions to clarify my problem?
Sounds like an indexing issue, try running:

db2index.pl -n userroot -D "cn=directory Manager" -w YOUR_PASSWORD
>
> Thank you
> Kirk MacDonald
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] CentOS-Directory/8.1.0 B2009.134.1334 ldapsearch problem

[Kirk MacDonald]

Hello,

I'm working on migrating from CentOS-Directory/8.1.0 B2009.134.1334 to 
389-Directory/1.3.5.10 B2017.145.2037.

What I'm finding is that the Database Export functions in the 
CentOS-Directory/8.1.0 B2009.134.1334 Console as well as ldapsearches aren't 
returning all entries. Specifically an objectclass=* search filter for a given 
ou fails to output all entries. However if the search filter is for an 
attribute which exists, all applicable entries are returned.

The Console also does not show entries that might otherwise be found with a 
ldapsearch and a specific search filter.

Based on some experience I have with another LDAP system this feels like an 
ancestorid problem.

Can anyone offer any tips/thoughts or questions to clarify my problem?

Thank you
Kirk MacDonald
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Problem adding users to group.

[Lucas Diedrich]

Thanks Willian and David,

The first tunning already helped on making the database more responsive,
now i'm going to make the others changes and monitor the environment.

Thanks a lot.

Em qui, 17 de ago de 2017 às 20:50, William Brown 
escreveu:

> On Thu, 2017-08-17 at 10:53 +1000, William Brown wrote:
> > On Tue, 2017-08-15 at 13:15 +, Lucas Diedrich wrote:
> > > Willian,
> > >
> > > Cache values from cn=config + cn=userRoot:
> > > https://paste.fedoraproject.org/paste/ZqmA2wUkQDcSUaUIcpGDhg
> > > free -h + lspcu:
> > > https://paste.fedoraproject.org/paste/Br8Vz5-quxtcatiDyMy3QA
> > >
> > > I'll check it out the docs for the optimization + wait until your
> response,
> > > i think it will more secure.
> >
> > Hey mate,
> >
> > Those values are all default of 10MB. You probably want to change:
> >
> > dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> > nsslapd-cachememsize: 10485760
> > nsslapd-dncachememsize: 10485760
> >
> > and
> >
> > dn: cn=config,cn=ldbm database,cn=plugins,cn=config
> > nsslapd-dbcachesize: 1000
> >
> > Looking at your values of free/cpu, I would recommend something like:
> >
> > dn: cn=userRoot,cn=ldbm database,cn=plugins,cn=config
> > nsslapd-cachememsize: 268435456
> > nsslapd-dncachememsize: 67108864
> >
> > and
> >
> > dn: cn=config,cn=ldbm database,cn=plugins,cn=config
> > nsslapd-dbcachesize: 536870912
> >
> >
> > That should help you as a start, and you can tweak these up and down as
> > needed.
> >
>
> I was forwarded this from another list user too:
>
> Lucas,
>
> You may  also want to make additional modifications below in
> addition to what William provided.
>
> You currently have transactions building up and until you hit 60
> seconds the commits are being held in durability transaction log.
> Below setting will keep durability transaction log on, BUT only 1
> transaction will be held until 60 seconds
> nsslapd-db-transaction-batch-val: 0
>
> to be
>
> nsslapd-db-transaction-batch-val: 1
>
> If you are not doing ldif2db transactions as part of normal
> operation have discovered over the
> Years that disabling import-cache-autosize helps with memory
> management.  Historically 389ds will fence this
> Memory not use it and never release it back to OS.
> nsslapd-import-cache-autosize: -1
> nsslapd-import-cachesize: 2000
>
> to be
>
> nsslapd-import-cache-autosize: 0
> nsslapd-import-cachesize: 2000
>
>
> Make sure you check cachesize values for change after each directory
> restart.  They are dynamic based on available memory on OS at time of
> service start.
> If you have something else running on host with memory leak
> Directory Server slowly will be starved and eventually crash.
> Memory allocations for each directory instance you have running on
> host are cumulative so be aware what else is running on host before
> modifying the cachesize settings especially if you leave autosize
> enabled.
>
>
> David M. Partridge
> Identity Management and Security Engineer
> Tangible Security Inc
> 2010 Corporate Ridge, Suite 250
> McLean, VA 22102
>
>
>
> I hope this helps you too,
>
>
> --
> Sincerely,
>
> William Brown
> Software Engineer
> Red Hat, Australia/Brisbane
>
> ___
> 389-users mailing list -- 389-users@lists.fedoraproject.org
> To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org
>
___
389-users mailing list -- 389-users@lists.fedoraproject.org
To unsubscribe send an email to 389-users-le...@lists.fedoraproject.org

[389-users] Re: Choice of version?

[Jeff Smith]

William,

Thanks for the note.  Our system is running CentOS 7.3 but the version of 
directory server is 1.3.5.10.  Is this just a timing issue and 1.3.6 will be 
released shortly for CentOS7.3?

J

[root@eng-ldap-test01 ~]# cat /etc/redhat-release CentOS Linux release 7.3.1611 
(Core) 

 [root@eng-ldap-test01 ~]# /usr/sbin/ns-slapd -v
389 Project
389-Directory/1.3.5.10 B2017.145.2037

 [root@eng-ldap-test01 ~]# yum update
Loaded plugins: fastestmirror
base

  | 3.6 kB  00:00:00 
epel/x86_64/metalink

  |  10 kB  00:00:00 
epel

  | 4.3 kB  00:00:00 
extras  

  | 3.4 kB  00:00:00 
updates 

  | 3.4 kB  00:00:00 
(1/3): epel/x86_64/updateinfo   

  | 808 kB  00:00:00 
(2/3): epel/x86_64/primary_db   

  | 4.7 MB  00:00:00 
(3/3): extras/7/x86_64/primary_db   

  | 191 kB  00:00:00 
Loading mirror speeds from cached hostfile
 * base: centos.mirror.ca.planethoster.net
 * epel: mirror.cs.princeton.edu
 * extras: mirror.its.dal.ca
 * updates: mirror.gpmidi.net
No packages marked for update

[root@eng-ldap-test01 ~]# yum clean all
Loaded plugins: fastestmirror
Cleaning repos: base epel extras updates Cleaning up everything Cleaning up 
list of fastest mirrors
[root@eng-ldap-test01 ~]# yum update
Loaded plugins: fastestmirror
base

  | 3.6 kB  00:00:00 
epel/x86_64/metalink

  | 9.7 kB  00:00:00 
epel

  | 4.3 kB  00:00:00 
extras  

  | 3.4 kB  00:00:00 
updates 

  | 3.4 kB  00:00:00 
(1/7): base/7/x86_64/group_gz   

  | 155 kB  00:00:00 
(2/7): epel/x86_64/group_gz 

  | 170 kB  00:00:00 
(3/7): epel/x86_64/updateinfo   

  | 808 kB  00:00:00 
(4/7): extras/7/x86_64/primary_db   

  | 191 kB  00:00:00 
(5/7):