[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: large ldap server recommendation
On Fri, 2008-02-01 at 06:13 +0100, Tony Earnshaw wrote:
> ram skrev, on 31-01-2008 11:13:
>
> > I am using ldap for authentication & addressbook for a large
> > mailserver setup with around 300k users ( this will grow to 500k )
> >
> > The ldap server is a 8GB Ram box with RHEL-5 with
> > openldap-servers-2.3.27-5
> >
> > I am confused what database type to use ldbm or bdb. Currently I have
> > the users on bdb with lot of problems. The ldap server dies all of a
> > sudden and I have to recover the data to get it started
> >
> >
> > my DB_CONFIG file is
> >
> > ------
> >
> >
> >
> > # Note: most DB_CONFIG settings will take effect only upon rebuilding
> > # the DB environment.
> >
> > set_cachesize 0 524288000 0
> > set_lg_regionmax 1048576
> > set_lg_max 10485760
> > set_lg_bsize 20485760
> > set_tmp_dir /tmp
> >
> >
> > # Note: special DB_CONFIG flags are no longer needed for "quick"
> > # slapadd(8) or slapindex(8) access (see their -q option).
> >
> > set_flags DB_LOG_AUTOREMOVE
> > set_flags DB_LOG_INMEMORY
> > set_flags DB_TXN_NOSYNC
>
> This has been repeated to the point of boredom, nevertheless:
>
> I'm a Red Hat admin and am running RHEL5.1 on a number of machines.
> RHEL5 is a dependable and stable operating system, as are by far most of
> the utilities it comprises. One RHEL5 offering to be avoided at all
> costs is openldap-*-2.3.27. Apart from anything else it is built with
> bdb 4.3.29 support. db4.3 has been condemned as unsuitable by the
> OpenLDAP developers. There are other reason too, but this is the most
> important.
>
> I (and other Red Hat admins in the know) run Buchan Milne's alternative
> which comprise discrete, patched db-4.2.52 and can exist beside the
> RHEL5 offering. This is an utterly stable and dependable product; it is
> available at http://staff.telkomsa.net/packages/rhel5Server/openldap/.
>
Will I have to remove my current db4* rpms to install these ?
> You should always use bdb or hdb as DB, never ldbm.
>
> Best,
>
> --Tonni
>