Re: Unable to start

2010-08-18 Thread Dieter Kluenter
VANTASSLE, GEORDON M (ATTSI) gv2...@att.com writes:

 I finally got everything compiled, and the make test worked like a
 charm.  However, when I try to manually start LDAP via the rc.openldap
 script, I get:
 $ ./test.rc.openldap start
 Starting test.rc.openldap service(s) -
 Tue-Aug-17-14.23.51-2010 -
 STATUS: LDAP start attempt logged to
 /opt/app/ivr/openldap/openldap-2.4.11/var/logs/SystemOut.log
 STATUS: Waiting for ldap to finish the start sequence
 STATUS: Waiting for ldap to finish the start sequence
 STATUS: Waiting for ldap to finish the start sequence
 STATUS: Waiting for ldap to finish the start sequence
 STATUS: Waiting for ldap to finish the start sequence
 STATUS: Waiting for ldap to finish the start sequence
 ERROR: Unable to successfully start ldap within time limit
 - Tue-Aug-17-14.24.54-2010
 -


 Is there some way that I can see what is going on with this?  I don't
 know anything about LDAP, but my client requires it for one of their
 apps, so I would appreciate the help.

run slapd in debugging mode, something like

./slapd -h ldap:///; -F /path/to/slapd.d -f /path/to/slapd.conf -u
user -g group -d 256

for more info see man slapd(8), on loglevel see slapd.conf(5)

-Dieter

-- 
Dieter Klünter | Systemberatung
sip: 7770...@sipgate.de 
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6


Maximum ldap search filter string length ?

2010-08-18 Thread Arjan Filius

Hello openldap-technical ML.

Is there a clear answer to the question about the
maximum ldap search filter length ?

Dit hava a look at the ldapsearch code (2.4.19) and all seems dynamicaly 
allocated, and therefore no hard/fixed limit.


ldap_search_ext/ldap_search (manpage) doesn't talk about limits too.
filter is about: RFC 4515 as extended by RFC 4526, but doesn't mention 
maximum size as far i read.


That leaves me to the conclusion that the filter size is dependent on 
archite4cture (32/64 bits), available memory systemwide, and available 
memory within a proces.


Can someone confirm or deny this is correct, and perhaps is there a 
(rough) guide/best practice about max filter string length's ?


Thanks in Advance,

--
Arjan Filius
mailto:iafil...@xs4all.nl


Re: Openldap2.4.16 performance issue

2010-08-18 Thread Dieter Kluenter
Singh, Devender (GE Capital, consultant) devender.sin...@ge.com writes:

 Hi Dieter,

  I need to tune any parameter in DB_CONFIG file for this or not? Because 
 I am using default DB_CONFIG file.

Just edit DB_CONFIG
set_log_dir /mountpoint/path/to/

-Dieter

-- 
Dieter Klünter | Systemberatung
sip: 7770...@sipgate.de 
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6


Re: replication from child to Parent domain

2010-08-18 Thread owen nirvana
parent is customer

suffix  dc=SCNCA,dc=ROOTCA
rootdncn=admin,dc=SCNCA,dc=ROOTCA
rootpwsecret

checkpoint  512 30

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

ServerID 000

syncrepl rid=001
provider=ldap://${SON_LDAP_ADDRESS}:${SON_LDAP_PORT}
type=refreshOnly
# five minutes, you should do syncrepl once a day in practice
interval=00:01:00:00
searchbase=${SON_BASE}
filter=(objectClass=*)
scope=sub
schemachecking=off
bindmethod=simple
binddn=${SON_ADMIN}
credentials=${SON_PASSWD}
retry=5 5 300 +

mirrormode on



son is provider

suffix  dc=sonCA,dc=SCNCA,dc=ROOTCA
rootdncn=admin,dc=sonCA,dc=SCNCA,dc=ROOTCA
rootpwsecret

checkpoint  512 30

overlay syncprov
syncprov-checkpoint 100 10
syncprov-sessionlog 100

ServerID 001


and son's log is


 dnPrettyNormal: dc=sonca,dc=scnca,dc=rootca,
dc=sonca,dc=scnca,dc=rootca
SRCH dc=sonca,dc=scnca,dc=rootca 2 00 0 0
ber_scanf fmt (m) ber:
ber_dump: buf=010E1060 ptr=010E109C end=010E1136 len=154
  :  87 0b 6f 62 6a 65 63 74  43 6c 61 73 73 30 06 04
..objectClass0..
  0010:  01 2a 04 01 2b a0 81 82  30 62 04 18 31 2e 33 2e
.*..+...0b..1.3.
  0020:  36 2e 31 2e 34 2e 31 2e  34 32 30 33 2e 31 2e 39
6.1.4.1.4203.1.9
  0030:  2e 31 2e 31 04 46 30 44  0a 01 01 04 3c 72 69 64
.1.1.F0Drid
  0040:  3d 30 30 31 2c 73 69 64  3d 30 30 30 2c 63 73 6e
=001,sid=000,csn
  0050:  3d 32 30 31 30 30 38 31  33 30 37 34 38 34 36 2e
=20100813074846.
  0060:  34 35 37 32 37 39 5a 23  30 30 30 30 30 30 23 30
457279Z#00#0
  0070:  30 30 23 30 30 30 30 30  30 01 01 ff 30 1c 04 17
00#00...0...
  0080:  32 2e 31 36 2e 38 34 30  2e 31 2e 31 31 33 37 33
2.16.840.1.11373
  0090:  30 2e 33 2e 34 2e 32 01  01 ff
0.3.4.2...
filter: (objectClass=*)
ber_scanf fmt ({M}}) ber:
ber_dump: buf=010E1060 ptr=010E10A9 end=010E1136 len=141
  :  00 06 04 01 2a 04 01 2b  a0 81 82 30 62 04 18 31
*..+...0b..1
  0010:  2e 33 2e 36 2e 31 2e 34  2e 31 2e 34 32 30 33 2e
.3.6.1.4.1.4203.
  0020:  31 2e 39 2e 31 2e 31 04  46 30 44 0a 01 01 04 3c
1.9.1.1.F0D
  0030:  72 69 64 3d 30 30 31 2c  73 69 64 3d 30 30 30 2c
rid=001,sid=000,
  0040:  63 73 6e 3d 32 30 31 30  30 38 31 33 30 37 34 38
csn=201008130748
  0050:  34 36 2e 34 35 37 32 37  39 5a 23 30 30 30 30 30
46.457279Z#0
  0060:  30 23 30 30 30 23 30 30  30 30 30 30 01 01 ff 30
0#000#00...0
  0070:  1c 04 17 32 2e 31 36 2e  38 34 30 2e 31 2e 31 31
...2.16.840.1.11
  0080:  33 37 33 30 2e 33 2e 34  2e 32 01 01 ff
3730.3.4.2...
= get_ctrls
ber_scanf fmt ({m) ber:
ber_dump: buf=010E1060 ptr=010E10B4 end=010E1136 len=130
  :  30 62 04 18 31 2e 33 2e  36 2e 31 2e 34 2e 31 2e
0b..1.3.6.1.4.1.
  0010:  34 32 30 33 2e 31 2e 39  2e 31 2e 31 04 46 30 44
4203.1.9.1.1.F0D
  0020:  0a 01 01 04 3c 72 69 64  3d 30 30 31 2c 73 69 64
rid=001,sid
  0030:  3d 30 30 30 2c 63 73 6e  3d 32 30 31 30 30 38 31
=000,csn=2010081
  0040:  33 30 37 34 38 34 36 2e  34 35 37 32 37 39 5a 23
3074846.457279Z#
  0050:  30 30 30 30 30 30 23 30  30 30 23 30 30 30 30 30
00#000#0
  0060:  30 01 01 ff 30 1c 04 17  32 2e 31 36 2e 38 34 30
0...0...2.16.840
  0070:  2e 31 2e 31 31 33 37 33  30 2e 33 2e 34 2e 32 01
.1.113730.3.4.2.
  0080:  01 ff
..
ber_scanf fmt (m) ber:
ber_dump: buf=010E1060 ptr=010E10D0 end=010E1136 len=102
  :  00 46 30 44 0a 01 01 04  3c 72 69 64 3d 30 30 31
.F0Drid=001
  0010:  2c 73 69 64 3d 30 30 30  2c 63 73 6e 3d 32 30 31
,sid=000,csn=201
  0020:  30 30 38 31 33 30 37 34  38 34 36 2e 34 35 37 32
00813074846.4572
  0030:  37 39 5a 23 30 30 30 30  30 30 23 30 30 30 23 30
79Z#00#000#0
  0040:  30 30 30 30 30 01 01 ff  30 1c 04 17 32 2e 31 36
0...0...2.16
  0050:  2e 38 34 30 2e 31 2e 31  31 33 37 33 30 2e 33 2e
.840.1.113730.3.
  0060:  34 2e 32 01 01 ff
4.2...
= get_ctrls: oid=1.3.6.1.4.1.4203.1.9.1.1 (noncritical)
ber_scanf fmt ({i) ber:
ber_dump: buf=010E10D2 ptr=010E10D2 end=010E1118 len=70
  :  30 44 0a 01 01 04 3c 72  69 64 3d 30 30 31 2c 73
0Drid=001,s
  0010:  69 64 3d 30 30 30 2c 63  73 6e 3d 32 30 31 30 30
id=000,csn=20100
  0020:  38 31 33 30 37 34 38 34  36 2e 34 35 37 32 37 39
813074846.457279
  0030:  5a 23 30 30 30 30 30 30  23 30 30 30 23 30 30 30
Z#00#000#000
  0040:  30 30 30 01 01 ff
000...
ber_scanf fmt (m) ber:
ber_dump: buf=010E10D2 ptr=010E10D7 end=010E1118 len=65
  :  04 3c 72 69 64 3d 30 30  31 2c 73 69 64 3d 30 30
.rid=001,sid=00
  0010:  30 2c 63 73 6e 3d 32 30  31 30 30 38 31 33 30 37
0,csn=2010081307
  0020:  34 38 34 36 2e 34 35 37  32 37 39 5a 23 30 30 30
4846.457279Z#000
  0030:  30 30 30 23 30 30 30 23  30 30 30 30 30 30 01 01
000#000#00..
  0040:  ff
.
ber_scanf fmt (b) ber:
ber_dump: buf=010E10D2 ptr=010E1115 end=010E1118 len=3
  :  00 01 ff
...
ber_scanf fmt (}) ber:
ber_dump: buf=010E10D2 ptr=010E1118 end=010E1118 len=0

ber_scanf fmt ({m) ber:
ber_dump: buf=010E1060 ptr=010E1118 

RE: Openldap2.4.16 performance issue

2010-08-18 Thread Singh, Devender (GE Capital, consultant)
Hi Dieter,

 I need to tune any parameter in DB_CONFIG file for this or not? Because I 
am using default DB_CONFIG file.

Thanks  Regards,
Devender Singh
Senior Unix Administrator,
(SOA Support Team)

SDG Software India Pvt. Ltd
A-10, Sector 2, Noida 201301, U.P, India
M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020
website : www.sdgc.com

Please Note: The e-mail content is intended for the sole use of the intended 
recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY 
INFORMATION. Any review or reliance by others or copying or distribution or 
forwarding of any or all of the contents in this message is STRICTLY 
PROHIBITED. If you have erroneously received this message, please delete it 
immediately and notify the sender. Before opening any attachments please check 
them for viruses and defects.

-Original Message-
From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Dieter Kluenter
Sent: Tuesday, August 17, 2010 1:12 PM
To: openldap-technical@openldap.org
Subject: Re: Openldap2.4.16 performance issue

Singh, Devender (GE Capital, consultant) devender.sin...@ge.com writes:

 Hi All,

 I need help for openldap slapd 200% cpu utilization issue.

 I have configured three openldap servers(2 Masters and 1 Slave). I have

 configure PEN load balancer for failover setup on 2 master openldap servers.It

 means application server first of all hit the loadbalancer port and than PEN 
 LB

 will forwad that request to Master 1 or 2 openldap server.

 Hardware configuration on all boxes:

 OS: RHEL5(x86_64)

 RAM: 2GB

 Number of CPU: 2(Intel(R) Xeon(R)2.00GHz)

 Number of BDB databases: 2

 Databse1: 

 Number of users : 83

 Number of dns: 83

 Database2:

 Number of users: 2000

 Number of dns: 80

 My Application1 using Databse1 and Application2 using Databse2.

 Application2 just authenticating the users and store last 10 password history

 only, It means Application1 is not using openldap too much.

 In Application2(90% dependent on openldap) every user have 1000+ sub leafs

 entries. when I want to do major changes(number of leafs write) into this, 
 it.s

 got hanged and got socket closed error in application logs and CPU utilization

 goes 200% and RAM 52%. My DB_CONFIG file is below:

Most likely to many concurrent write operations. You should move the
db logfiles onto a different disk.

-Dieter

-- 
Dieter Klünter | Systemberatung
sip: 7770...@sipgate.de 
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6


ldap_add: Invalid syntax (21)

2010-08-18 Thread Cole
Hello.  I'm trying to set up a computer cluster for a school project, and I
am following a guide at debianclusters.org http://www.debianclusters.org.
 I'm trying to set up LDAP and I've followed the tutorial, but I keep
getting this error.  I saw this error in the FAQ, but I'm not sure how to
fix it.  Any ideas on what I am doing wrong?

Here is a link to the tutorial:
http://debianclusters.org/index.php/LDAP_Server

r...@durnik:/usr/share/migrationtools# ./migrate_all_online.sh
Enter the X.500 naming context you wish to import into: [dc=muncc,dc=loc]
Enter the hostname of your LDAP server [ldap]: durnik
Enter the manager DN: [cn=admin,dc=muncc,dc=loc]:
Enter the credentials to bind with:
Do you wish to generate a DUAConfigProfile [yes|no]? no

Importing into dc=muncc,dc=loc...

Creating naming context entries...
Migrating aliases...
Migrating groups...
Migrating hosts...
Migrating networks...
Migrating users...
Migrating protocols...
Migrating rpcs...
Migrating services...
Migrating netgroups...
Migrating netgroups (by user)...
Migrating netgroups (by host)...
Importing into LDAP...
adding new entry ou=Hosts,dc=muncc,dc=loc

adding new entry ou=Rpc,dc=muncc,dc=loc

adding new entry ou=Services,dc=muncc,dc=loc

adding new entry nisMapName=netgroup.byuser,dc=muncc,dc=loc

adding new entry ou=Mounts,dc=muncc,dc=loc

adding new entry ou=Networks,dc=muncc,dc=loc

adding new entry ou=People,dc=muncc,dc=loc

adding new entry ou=Group,dc=muncc,dc=loc

adding new entry ou=Netgroup,dc=muncc,dc=loc

adding new entry ou=Protocols,dc=muncc,dc=loc

adding new entry ou=Aliases,dc=muncc,dc=loc

adding new entry nisMapName=netgroup.byhost,dc=muncc,dc=loc

adding new entry cn=mailer-daemon,ou=Aliases,dc=muncc,dc=loc
ldap_add: Invalid syntax (21)
additional info: objectClass: value #0 invalid per syntax

/usr/bin/ldapadd: returned non-zero exit status: saving failed LDIF to
/tmp/nis.ldif.ImwnfdMVQr



Re: ldap_add: Invalid syntax (21)

2010-08-18 Thread Dieter Kluenter
Cole colewash...@gmail.com writes:

 Hello.  I'm trying to set up a computer cluster for a school project, and I 
 am following a
 guide at debianclusters.org.  I'm trying to set up LDAP and I've followed the 
 tutorial, but I
 keep getting this error.  I saw this error in the FAQ, but I'm not sure how 
 to fix it.  Any
 ideas on what I am doing wrong?
[...]
 adding new entry cn=mailer-daemon,ou=Aliases,dc=muncc,dc=loc
 ldap_add: Invalid syntax (21)
 additional info: objectClass: value #0 invalid per syntax

 /usr/bin/ldapadd: returned non-zero exit status: saving failed LDIF to /tmp/
 nis.ldif.ImwnfdMVQr

please post the above mentioned LDIF file.

-Dieter

-- 
Dieter Klünter | Systemberatung
sip: 7770...@sipgate.de 
http://www.dpunkt.de/buecher/2104.html
GPG Key ID:8EF7B6C6


multi / standby master: incomplete replication after downtime (?)

2010-08-18 Thread Elmar Marschke

Hi all,

i set up a multi master scenario using 2.4.21 on two servers. Online 
config (slapd.d) and ldap content is replicated fine, as long as both 
servers are up (means: i can change objects using ANY of the servers; 
and changes are transferred immediately to the other one. (Later in 
production, there will just one server be used actively, the other one 
shall be used by the clients just in case of failure)).


Then i shut down one of the servers, and do changes on the remaining 
one. I expect the switched-off server to get ALL the latest changes from 
the online-server as soon as it's up again. But this seems to happen 
only partially; for example:
 - deletion of a user object works ( = shows up on the former 
switched-off server immediately after coming up again)

 - adding of a user does not
 - changing just subordinate attributes of user objects, like telephone 
number, does not show up. It just gets replicated to the former 
switched-off machine, when something else of that object is changed 
while both servers are alive.


So finally i end up with different content on every machine...
Did i miss something about how that works ??
Or is my config wrong for that; example:

syncrepl rid=001
 provider=ldap://ldapmaster.local.site;
 type=refreshAndPersist
 retry=5 +
 searchbase=dc=local,dc=site
 bindmethod=simple
 binddn=cn=replicator,dc=local,dc=site
 credentials=secret

Thanks for help...

PS: my setup / slapd.conf is according to the book openLDAP 2.4 by 
Oliver Liebel  John Martin Ungar.


--
elmar


Re: multi / standby master: incomplete replication after downtime (?)

2010-08-18 Thread Oliver Liebel

Am 18.08.2010 11:01, schrieb Elmar Marschke:

Hi all,

i set up a multi master scenario using 2.4.21 on two servers. Online 
config (slapd.d) and ldap content is replicated fine, as long as both 
servers are up (means: i can change objects using ANY of the servers; 
and changes are transferred immediately to the other one. (Later in 
production, there will just one server be used actively, the other one 
shall be used by the clients just in case of failure)).


Then i shut down one of the servers, and do changes on the remaining 
one. I expect the switched-off server to get ALL the latest changes 
from the online-server as soon as it's up again. But this seems to 
happen only partially; for example:
 - deletion of a user object works ( = shows up on the former 
switched-off server immediately after coming up again)

 - adding of a user does not
 - changing just subordinate attributes of user objects, like 
telephone number, does not show up. It just gets replicated to the 
former switched-off machine, when something else of that object is 
changed while both servers are alive.


So finally i end up with different content on every machine...
Did i miss something about how that works ??
Or is my config wrong for that; example:

syncrepl rid=001
 provider=ldap://ldapmaster.local.site;
 type=refreshAndPersist
 retry=5 +
 searchbase=dc=local,dc=site
 bindmethod=simple
 binddn=cn=replicator,dc=local,dc=site
 credentials=secret

Thanks for help...

did you setup the serverids correctly, e.g.:

ServerID1   ldap://master1.local.site;
ServerID2   ldap://master2.local.site;

you also need a separate syncrepl section for every server
in your multimaster-setup




PS: my setup / slapd.conf is according to the book openLDAP 2.4 by 
Oliver Liebel  John Martin Ungar.


--
elmar






Re: multi / standby master: incomplete replication after downtime (?)

2010-08-18 Thread Elmar Marschke

Hello Jonathan  Oliver,

thanks for your answers... because you both are asking about config 
details, i'll try to answer but you can find my complete slapd.conf 
below, so that you can take a look by yourself.


On 18.08.2010 11:57, Jonathan Clarke wrote:

Hi,



Does your config also contain appropriate SID definitions and a syncrepl
consumer for each master? With mirrormode set to TRUE?


i think so; please see my complete slapd.conf below. @Oliver: Server 
ID's are different, and i think i have also a separate syncrepl section 
for every server.



Are the servers tightly time synchronized, via NTP or equivalent?


I'm in doubt about that. Of course ntp is configured and works on both 
servers, but the offset from their master timeserver differs quite a bit:

ldapmaster:
 remote   refid   offset
=
 LOCAL(0).LOCL.0.000
*ns1.at.signintr 192.168.220.82   48.630
+a891lx03.schenk 192.168.220.82   188.350

ldapslave:
 remote   refid   offset
=
 LOCAL(0).LOCL.   0.000
*a890lx03.schenk 192.168.220.82   7.553
+ns2.at.signintr 192.168.220.82   132.635

I have read recommendations, that the offset of both servers should not 
differ more than one or two milliseconds, but i don't know how i could 
achieve / influence that. Both machines are in the same subnet and 
physically in the same location; and hardware and ntpd setup is the same.



What error messages (if any) are given when running with olcLogLevel:
sync, on either nodes?


It logs a lot, and i don't know for what to look exactly. Please give me 
some time to arrange it into a readable form...


Here's my complete slapd.conf:


loglevel16384
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /etc/openldap/schema/core.schema
include /etc/openldap/schema/cosine.schema
include /etc/openldap/schema/nis.schema
include /etc/openldap/schema/inetorgperson.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referral   ldap://root.openldap.org

pidfile /var/run/slapd/slapd.pid
argsfile/var/run/slapd/slapd.args

# Load dynamic backend modules:
# modulepath/usr/local/libexec/openldap
# moduleloadback_bdb.la
# moduleloadback_hdb.la
# moduleloadback_ldap.la

# Sample security restrictions
#   Require integrity protection (prevent hijacking)
#   Require 112-bit (3DES or better) encryption for updates
#   Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#   Root DSE: allow anyone to read it
#   Subschema (sub)entry DSE: allow anyone to read it
#   Other DSEs:
#   Allow self write access
#   Allow authenticated users read access
#   Allow anonymous users to authenticate
#   Directives needed to implement policy:

access to dn.base=
by * read

access to dn.base=cn=Subschema
by * read

access to attrs=userPassword,userPKCS12
by self write
by * auth

access to attrs=shadowLastChange
by self write
by * read

access to *
by * read

#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., access to * by * read)
#
# rootdn can always read and write EVERYTHING!

## server-ids/urls fuer mmr ###

ServerID1   ldap://ldapmaster.local.site;
ServerID2   ldap://ldapslave.local.site;


###
databaseconfig
rootdn  cn=config
rootpw  {SSHA}4PvZLcpQ7s1CyQG+yworyl5DcrFTn78q

### syncrepl- direktiven fuer mmr der olc ###
syncreplrid=003
provider=ldap://ldapmaster.local.site;
searchbase=cn=config
type=refreshAndPersist
retry=5 +
bindmethod=simple
binddn=cn=config
credentials=secret
filter=(!(olcDatabase={0}config))

syncreplrid=004
provider=ldap://ldapslave.local.site;
searchbase=cn=config
type=refreshAndPersist
retry=5 +
bindmethod=simple
binddn=cn=config
credentials=secret
filter=(!(olcDatabase={0}config))

overlay syncprov
MirrorMode  On

###
# BDB database definitions
###

databasehdb
suffix  dc=local,dc=site
rootdn  

Re: multi / standby master: incomplete replication after downtime (?)

2010-08-18 Thread Oliver Liebel

the mmr config was tested many times and should work as expected,
but your clockskew below may be to great for mmr to work as intended

are your servers are physical/paravirt vms or full emulated vms?
if they are full emulated (eg vmware server), you will always run into
major clock skews.

check out / set  some of your ntp settings, e.g.
- tinker panic 0
- server   minpoll value maxpoll value




Am 18.08.2010 13:21, schrieb Elmar Marschke:

Hello Jonathan  Oliver,

thanks for your answers... because you both are asking about config 
details, i'll try to answer but you can find my complete slapd.conf 
below, so that you can take a look by yourself.


On 18.08.2010 11:57, Jonathan Clarke wrote:

Hi,



Does your config also contain appropriate SID definitions and a syncrepl
consumer for each master? With mirrormode set to TRUE?


i think so; please see my complete slapd.conf below. @Oliver: Server 
ID's are different, and i think i have also a separate syncrepl 
section for every server.



Are the servers tightly time synchronized, via NTP or equivalent?


I'm in doubt about that. Of course ntp is configured and works on both 
servers, but the offset from their master timeserver differs quite a bit:

ldapmaster:
 remote   refid   offset
=
 LOCAL(0).LOCL.0.000
*ns1.at.signintr 192.168.220.82   48.630
+a891lx03.schenk 192.168.220.82   188.350

ldapslave:
 remote   refid   offset
=
 LOCAL(0).LOCL.   0.000
*a890lx03.schenk 192.168.220.82   7.553
+ns2.at.signintr 192.168.220.82   132.635

I have read recommendations, that the offset of both servers should 
not differ more than one or two milliseconds, but i don't know how i 
could achieve / influence that. Both machines are in the same subnet 
and physically in the same location; and hardware and ntpd setup is 
the same.



What error messages (if any) are given when running with olcLogLevel:
sync, on either nodes?


It logs a lot, and i don't know for what to look exactly. Please give 
me some time to arrange it into a readable form...


Here's my complete slapd.conf:


loglevel 16384
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include/etc/openldap/schema/core.schema
include/etc/openldap/schema/cosine.schema
include/etc/openldap/schema/nis.schema
include/etc/openldap/schema/inetorgperson.schema

# Define global ACLs to disable default read access.

# Do not enable referrals until AFTER you have a working directory
# service AND an understanding of referrals.
#referralldap://root.openldap.org

pidfile /var/run/slapd/slapd.pid
argsfile/var/run/slapd/slapd.args

# Load dynamic backend modules:
# modulepath/usr/local/libexec/openldap
# moduleloadback_bdb.la
# moduleloadback_hdb.la
# moduleloadback_ldap.la

# Sample security restrictions
#Require integrity protection (prevent hijacking)
#Require 112-bit (3DES or better) encryption for updates
#Require 63-bit encryption for simple bind
# security ssf=1 update_ssf=112 simple_bind=64

# Sample access control policy:
#Root DSE: allow anyone to read it
#Subschema (sub)entry DSE: allow anyone to read it
#Other DSEs:
#Allow self write access
#Allow authenticated users read access
#Allow anonymous users to authenticate
#Directives needed to implement policy:

access to dn.base=
by * read

access to dn.base=cn=Subschema
by * read

access to attrs=userPassword,userPKCS12
by self write
by * auth

access to attrs=shadowLastChange
by self write
by * read

access to *
by * read

#
# if no access controls are present, the default policy
# allows anyone and everyone to read anything but restricts
# updates to rootdn.  (e.g., access to * by * read)
#
# rootdn can always read and write EVERYTHING!

## server-ids/urls fuer mmr ###

ServerID1ldap://ldapmaster.local.site;
ServerID2ldap://ldapslave.local.site;


###
databaseconfig
rootdn  cn=config
rootpw  {SSHA}4PvZLcpQ7s1CyQG+yworyl5DcrFTn78q

### syncrepl- direktiven fuer mmr der olc ###
syncreplrid=003
provider=ldap://ldapmaster.local.site;
searchbase=cn=config
type=refreshAndPersist
retry=5 +
bindmethod=simple
binddn=cn=config
credentials=secret
filter=(!(olcDatabase={0}config))

syncreplrid=004
provider=ldap://ldapslave.local.site;
searchbase=cn=config
type=refreshAndPersist
retry=5 +
bindmethod=simple
binddn=cn=config
  

Re: multi / standby master: incomplete replication after downtime (?)

2010-08-18 Thread Elmar Marschke

On 18.08.2010 15:10, Oliver Liebel wrote:

the mmr config was tested many times and should work as expected,
but your clockskew below may be to great for mmr to work as intended

are your servers are physical/paravirt vms or full emulated vms?
if they are full emulated (eg vmware server), you will always run into
major clock skews.

check out / set some of your ntp settings, e.g.
- tinker panic 0
- server  minpoll value maxpoll value


yes, the time thing looks suspect to me also. I will try to get that 
better working; thanks for your hints.


But now, here's some log stuff; as announced ;) :

logfile excerpts from MASTER (hostname: ldapmaster) and STANDBY 
(hostname: ldapslave). I tried to make it as clearly arranged as 
possible by inserting self-explaining (hopefully ;)) tags into the 
logfiles. Here's what i did; and where:


 - started both machines in a well working state (replication fine in 
every detail; freshly converted slapd.conf, freshly replicated). Both 
machines up.
 - insert tag ===_BEGIN_CHANGES_WHILE_BOTH_UP_=== into logfiles on 
both machines (script based)


 - MASTER: deleted user hcallahan (using jxplorer)
 - MASTER: added user mmouse (using ldapadd)
 - MASTER: changed attribute telephone number user vcorleone to 
0800-mafia (using jxplorer)

 - MASTER: insert tag ===_END_CHANGES_WHILE_BOTH_UP_===

 - insert tag ===_END_CHANGES_WHILE_BOTH_UP_=== into logfiles on both 
machines


 - STANDBY: rcldap stop

 - insert tag ===_BEGIN_CHANGES_WHILE_STANDBY_DOWN_===

 - MASTER: delete user jmcclane
 - MASTER: add user ggoofy
 - MASTER: change telephone number user ckent to 0800-superman

 - insert tag ===_END_CHANGES_WHILE_STANDBY_DOWN_===
 - insert tag ===_BEGIN_STANDBY_COMING_BACK_===

 - STANDBY: rcldap start

 - insert tag ===_END_STANDBY_COMING_BACK_===

The tags are in MASTER's and STANDBY's logfile, so one can compare 
what's going on at the same point in time.


The result on STANDBY at the end again is as i wrote before:
STANDBY:
 - every operation while it was up was successfully replicated
 - the operations while it was down are partially replicated after 
coming up again:

 -- deletion user jmcclane: OK
 -- adding user ggoofy: obviously did not happen; not available on STANDBY
 -- changing phone number ckent: did not happen; on STANDBY it's the 
same as before (means it differs now from the value it has on MASTER).


Here's the logfile of MASTER:

===_BEGIN_CHANGES_WHILE_BOTH_UP_===
Aug 18 15:30:04 ldapmaster slapd[8017]: slap_queue_csn: queing 
0x7f00f317b580 20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: slap_graduate_commit_csn: 
removing 0x7f00fb4ee230 20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=001 
cookie=rid=001,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=001 CSN too 
old, ignoring 20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=002 
cookie=rid=002,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=002 CSN too 
old, ignoring 20100818133004.663851Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: slap_queue_csn: queing 
0x7f00f397d060 20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: slap_graduate_commit_csn: 
removing 0x7f00fb4ed9d0 20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=001 
cookie=rid=001,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=001 CSN too 
old, ignoring 20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=002 
cookie=rid=002,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=002 CSN too 
old, ignoring 20100818133025.570081Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: slap_queue_csn: queing 
0x7f00f497e0f0 20100818133045.686887Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133045.686887Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: slap_graduate_commit_csn: 
removing 0x7f00ec114bd0 20100818133045.686887Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133045.686887Z#00#000#00
Aug 18 

Re: multi / standby master: incomplete replication after downtime (?)

2010-08-18 Thread Jonathan CLARKE

On 18/08/2010 16:28, Elmar Marschke wrote:

On 18.08.2010 15:10, Oliver Liebel wrote:

the mmr config was tested many times and should work as expected,
but your clockskew below may be to great for mmr to work as intended

are your servers are physical/paravirt vms or full emulated vms?
if they are full emulated (eg vmware server), you will always run into
major clock skews.

check out / set some of your ntp settings, e.g.
- tinker panic 0
- server  minpoll value maxpoll value


yes, the time thing looks suspect to me also. I will try to get that
better working; thanks for your hints.

But now, here's some log stuff; as announced ;) :

logfile excerpts from MASTER (hostname: ldapmaster) and STANDBY
(hostname: ldapslave). I tried to make it as clearly arranged as
possible by inserting self-explaining (hopefully ;)) tags into the
logfiles. Here's what i did; and where:

- started both machines in a well working state (replication fine in
every detail; freshly converted slapd.conf, freshly replicated). Both
machines up.
- insert tag ===_BEGIN_CHANGES_WHILE_BOTH_UP_=== into logfiles on both
machines (script based)

- MASTER: deleted user hcallahan (using jxplorer)
- MASTER: added user mmouse (using ldapadd)
- MASTER: changed attribute telephone number user vcorleone to
0800-mafia (using jxplorer)
- MASTER: insert tag ===_END_CHANGES_WHILE_BOTH_UP_===

- insert tag ===_END_CHANGES_WHILE_BOTH_UP_=== into logfiles on both
machines

- STANDBY: rcldap stop

- insert tag ===_BEGIN_CHANGES_WHILE_STANDBY_DOWN_===

- MASTER: delete user jmcclane
- MASTER: add user ggoofy
- MASTER: change telephone number user ckent to 0800-superman

- insert tag ===_END_CHANGES_WHILE_STANDBY_DOWN_===
- insert tag ===_BEGIN_STANDBY_COMING_BACK_===

- STANDBY: rcldap start

- insert tag ===_END_STANDBY_COMING_BACK_===

The tags are in MASTER's and STANDBY's logfile, so one can compare
what's going on at the same point in time.

The result on STANDBY at the end again is as i wrote before:
STANDBY:
- every operation while it was up was successfully replicated
- the operations while it was down are partially replicated after coming
up again:
-- deletion user jmcclane: OK
-- adding user ggoofy: obviously did not happen; not available on STANDBY
-- changing phone number ckent: did not happen; on STANDBY it's the same
as before (means it differs now from the value it has on MASTER).

Here's the logfile of MASTER:

===_BEGIN_CHANGES_WHILE_BOTH_UP_===
Aug 18 15:30:04 ldapmaster slapd[8017]: slap_queue_csn: queing
0x7f00f317b580 20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: slap_graduate_commit_csn:
removing 0x7f00fb4ee230 20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: syncprov_sendresp:
cookie=rid=001,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: syncprov_sendresp:
cookie=rid=001,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=001
cookie=rid=001,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=001 CSN too
old, ignoring 20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=002
cookie=rid=002,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=002 CSN too
old, ignoring 20100818133004.663851Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: slap_queue_csn: queing
0x7f00f397d060 20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: syncprov_sendresp:
cookie=rid=001,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: slap_graduate_commit_csn:
removing 0x7f00fb4ed9d0 20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: syncprov_sendresp:
cookie=rid=001,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=001
cookie=rid=001,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=001 CSN too
old, ignoring 20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=002
cookie=rid=002,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=002 CSN too
old, ignoring 20100818133025.570081Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: slap_queue_csn: queing
0x7f00f497e0f0 20100818133045.686887Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: syncprov_sendresp:
cookie=rid=001,csn=20100818133045.686887Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: slap_graduate_commit_csn:
removing 0x7f00ec114bd0 20100818133045.686887Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: syncprov_sendresp:
cookie=rid=001,csn=20100818133045.686887Z#00#000#00
Aug 18 15:30:45 

Re: multi / standby master: incomplete replication after downtime (?)

2010-08-18 Thread Oliver Liebel

please sync the time first as exact as possible,
and make an initial resync with a fresh test-database


Am 18.08.2010 16:28, schrieb Elmar Marschke:

On 18.08.2010 15:10, Oliver Liebel wrote:

the mmr config was tested many times and should work as expected,
but your clockskew below may be to great for mmr to work as intended

are your servers are physical/paravirt vms or full emulated vms?
if they are full emulated (eg vmware server), you will always run into
major clock skews.

check out / set some of your ntp settings, e.g.
- tinker panic 0
- server  minpoll value maxpoll value


yes, the time thing looks suspect to me also. I will try to get that 
better working; thanks for your hints.


But now, here's some log stuff; as announced ;) :

logfile excerpts from MASTER (hostname: ldapmaster) and STANDBY 
(hostname: ldapslave). I tried to make it as clearly arranged as 
possible by inserting self-explaining (hopefully ;)) tags into the 
logfiles. Here's what i did; and where:


 - started both machines in a well working state (replication fine in 
every detail; freshly converted slapd.conf, freshly replicated). Both 
machines up.
 - insert tag ===_BEGIN_CHANGES_WHILE_BOTH_UP_=== into logfiles on 
both machines (script based)


 - MASTER: deleted user hcallahan (using jxplorer)
 - MASTER: added user mmouse (using ldapadd)
 - MASTER: changed attribute telephone number user vcorleone to 
0800-mafia (using jxplorer)

 - MASTER: insert tag ===_END_CHANGES_WHILE_BOTH_UP_===

 - insert tag ===_END_CHANGES_WHILE_BOTH_UP_=== into logfiles on 
both machines


 - STANDBY: rcldap stop

 - insert tag ===_BEGIN_CHANGES_WHILE_STANDBY_DOWN_===

 - MASTER: delete user jmcclane
 - MASTER: add user ggoofy
 - MASTER: change telephone number user ckent to 0800-superman

 - insert tag ===_END_CHANGES_WHILE_STANDBY_DOWN_===
 - insert tag ===_BEGIN_STANDBY_COMING_BACK_===

 - STANDBY: rcldap start

 - insert tag ===_END_STANDBY_COMING_BACK_===

The tags are in MASTER's and STANDBY's logfile, so one can compare 
what's going on at the same point in time.


The result on STANDBY at the end again is as i wrote before:
STANDBY:
 - every operation while it was up was successfully replicated
 - the operations while it was down are partially replicated after 
coming up again:

 -- deletion user jmcclane: OK
 -- adding user ggoofy: obviously did not happen; not available on 
STANDBY
 -- changing phone number ckent: did not happen; on STANDBY it's the 
same as before (means it differs now from the value it has on MASTER).


Here's the logfile of MASTER:

===_BEGIN_CHANGES_WHILE_BOTH_UP_===
Aug 18 15:30:04 ldapmaster slapd[8017]: slap_queue_csn: queing 
0x7f00f317b580 20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: slap_graduate_commit_csn: 
removing 0x7f00fb4ee230 20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=001 
cookie=rid=001,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=001 CSN too 
old, ignoring 20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=002 
cookie=rid=002,csn=20100818133004.663851Z#00#000#00
Aug 18 15:30:04 ldapmaster slapd[8017]: do_syncrep2: rid=002 CSN too 
old, ignoring 20100818133004.663851Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: slap_queue_csn: queing 
0x7f00f397d060 20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: slap_graduate_commit_csn: 
removing 0x7f00fb4ed9d0 20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=001 
cookie=rid=001,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=001 CSN too 
old, ignoring 20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=002 
cookie=rid=002,csn=20100818133025.570081Z#00#000#00
Aug 18 15:30:25 ldapmaster slapd[8017]: do_syncrep2: rid=002 CSN too 
old, ignoring 20100818133025.570081Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: slap_queue_csn: queing 
0x7f00f497e0f0 20100818133045.686887Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: syncprov_sendresp: 
cookie=rid=001,csn=20100818133045.686887Z#00#000#00
Aug 18 15:30:45 ldapmaster slapd[8017]: slap_graduate_commit_csn: 
removing 0x7f00ec114bd0 

Re: multi / standby master: incomplete replication after downtime (?)

2010-08-18 Thread Elmar Marschke

Am 18.08.2010 17:16, schrieb Rein Tollevik:

On 08/18/2010 04:28 PM, Elmar Marschke wrote:


Here's the logfile of MASTER:

===_BEGIN_CHANGES_WHILE_BOTH_UP_===
Aug 18 15:30:04 ldapmaster slapd[8017]: slap_queue_csn: queing
0x7f00f317b580 20100818133004.663851Z#00#000#00


Your ServerID setting is incorrect, and you are using the default
ServerID=0 on both systems.  The ServerID is included in the csn value,
the second to last number (#000# here).  Ensure that the ServerID URL is
the exact hostname of the systems it runs on, or that slapd is able to
select the correct sid based on its -h listener argument.

Start slapd with -d config and verify that both logs lines with
differing SID= values.

Rein



hey folks,
thanks a lot; hope is coming back ;)
Unfortunately i'll be out of office from now on until 25th august, 
because of relocation. My testservers in the office are already switched 
off, and i'm at home already. So i can't check anything right now.. But 
/etc/hosts should be correct on both systems; i've written the names in 
there. I'd be glad to come back to you next wednesday ..:)

best regards
elmar


Notification of userPassword change in OpenLDAP?

2010-08-18 Thread Tom Leach
I'm trying to work on a password sync scheme between OpenLDAP and some 
systems that use flat Unix passwd/shadow files.  I have been able to 
update the LDAP server when someone changes their password on the 
standalone Unix systems, but I'm having problems trying to get any kind 
of notification from the LDAP server if someone from a system using the 
LDAP directory changes their password.


So far, I'm looking at searching the LDAP directory every few minutes 
for any entries that have had their modifyTimestamp attribute change 
since the last time the search ran, then checking to see if the 
userPassword attribute in the LDAP directory is different then the 
shadow file on the Unix system.  This seems like a real stupid scheme, 
especially when passwords are changed infrequently.  I just don't want a 
long delay between syncing the directory and flat files in case someone 
changes their password on an LDAP client, then tries to log into the 
flat file system.


Ideally, there could be some option in OpenLDAP that could call an 
external program when some attribute(s) have changed.  That program 
could then perform the necessary searches and update the flat files if 
appropriate.  So far, I've found nothing indicating that this is 
possible so I figured I'd ask and see if anyone else has tried this and 
what they found.

Thanks!
Tom Leach
le...@coas.oregonstate.edu


Re: Re: pwdMustChange and pwdExpireWarning

2010-08-18 Thread weigao88

Hello Buchan

I am running the rpm package openldap server 2.3 that comes with CentOS 5.4  
and my ldap client is CentOS 4. Looks like there is no ldapwhoami -e  
ppolicy option on CentOS4 client, as you can see below. I also copy and  
paste the client's /etc/pam.d/system-auth below.



[us...@ldapclient ~]$ ldapwhoami -e ppolicy
Invalid general control name: ppolicy
Issue LDAP Who am I? operation to request user's authzid

usage: ldapwhoami [options]
Common options:
-d level set LDAP debugging level to `level'
-D binddn bind DN
-e [!]ext[=extparam] general extensions (! indicates criticality)
[!]assert=filter (an RFC 2254 Filter)
[!]authzid=authzid (dn:dn or u:user)
[!]manageDSAit
[!]noop
[!]postread[=attrs] (a comma-separated attribute list)
[!]preread[=attrs] (a comma-separated attribute list)
-h host LDAP server
-H URI LDAP Uniform Resource Indentifier(s)
-I use SASL Interactive mode
-n show what would be done but don't actually do it
-O props SASL security properties
-o opt[=optparam] general options
-p port port on LDAP server
-Q use SASL Quiet mode
-R realm SASL realm
-U authcid SASL authentication identity
-v run in verbose mode (diagnostics to standard output)
-V print version info (-VV only)
-w passwd bind password (for simple authentication)
-W prompt for bind password
-x Simple authentication
-X authzid SASL authorization identity (dn:dn or u:user)
-y file Read password from file
-Y mech SASL mechanism
-Z Start TLS request (-ZZ to require successful response)



[us...@ldapclient ~]$ cat /etc/pam.d/system-auth
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required /lib/security/$ISA/pam_env.so
auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
auth required /lib/security/$ISA/pam_deny.so

account required /lib/security/$ISA/pam_unix.so broken_shadow
account sufficient /lib/security/$ISA/pam_localuser.so
account sufficient /lib/security/$ISA/pam_succeed_if.so uid  100 quiet
account [default=bad success=ok user_unknown=ignore]  
/lib/security/$ISA/pam_ldap.so

account required /lib/security/$ISA/pam_permit.so

#password requisite /lib/security/$ISA/pam_cracklib.so retry=3
password requisite /lib/security/$ISA/pam_cracklib.so retry=3 lcredit=-1  
ucredit=-1 dcredit=-1 ocredit=-1
password sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5  
shadow

password sufficient /lib/security/$ISA/pam_ldap.so use_authtok
password required /lib/security/$ISA/pam_deny.so

session required /lib/security/$ISA/pam_limits.so
session required /lib/security/$ISA/pam_unix.so
session optional /lib/security/$ISA/pam_ldap.so


Do you see anything configured wrong in my /etc/pam.d/system-auth? Thanks  
so much for your help with this issue.


Regards
Wei



On Aug 17, 2010 4:43am, Buchan Milne bgmi...@staff.telkomsa.net wrote:

On Monday, 16 August 2010 23:02:41 Wei Gao wrote:




 Hello Buchan









 I set pwdReset manually and it worked. Thank you.








 For my issue regarding pwdExpireWarning not displaying warning message  
when



 I ssh into my systems, I still can't figure out what I did wrong. Here  
is




 my default policy:









 dn: cn=default,ou=Policies,dc=example,dc=company




 objectClass: top




 objectClass: device




 objectClass: pwdPolicy




 cn: default




 pwdAllowUserChange: TRUE




 pwdAttribute: userPassword




 pwdCheckQuality: 2




 pwdExpireWarning: 1209600




 pwdFailureCountInterval: 0




 pwdGraceAuthNLimit: 0




 pwdInHistory: 24




 pwdLockout: TRUE




 pwdLockoutDuration: 0




 pwdMaxAge: 5184000




 pwdMaxFailure: 3




 pwdMinLength: 12




 pwdMustChange: TRUE




 pwdSafeModify: FALSE









So, test your policy with ldapwhoami (with appropriate options, see man  
page),




with -e ppolicy option to display ppolicy controls in the response.







 pwdMaxAge works perfectly and so does every other attribute, except




 pwdExpireWarning. pwdExpireWarning is the only one I am having issues




 now. Not sure what I did wrong. Do you need to know any other details?






If ldapwhoami with -e ppolicy works correctly, your problem is your PAM  
stack.




This will not be the only pam_ldap feature (host-based authorization with



pam_check_host_attr will not be adhered to) that doesn't work due to  
incorrect




PAM authorization settings. See my previous reply:






You need to supply your PAM configuration if anyone is to assist you  
further.






   expire in 12 days, how come I don't see a warning message when I  
ssh to




 




  my




 




   system?




 




  Misconfigured PAM stack probably (authorization, IOW account lines).




  There have




  been previous solutions in previous threads on this topic, and without




  any details of your system it isn't possible to assist further.










Regards,




Buchan






Re: pwdMustChange and pwdExpireWarning

2010-08-18 Thread Buchan Milne
On Wednesday, 18 August 2010 22:26:38 weiga...@gmail.com wrote:
 Hello Buchan
 
 I am running the rpm package openldap server 2.3 that comes with CentOS 5.4

So test this client from the server.

 and my ldap client is CentOS 4. Looks like there is no ldapwhoami -e
 ppolicy option on CentOS4 client, as you can see below. I also copy and
 paste the client's /etc/pam.d/system-auth below.
 
 
 [us...@ldapclient ~]$ ldapwhoami -e ppolicy
 Invalid general control name: ppolicy
 Issue LDAP Who am I? operation to request user's authzid
 
 usage: ldapwhoami [options]

You will of course actually have to *read* the usage instructions, and supply 
suitable options/values.

 [us...@ldapclient ~]$ cat /etc/pam.d/system-auth
 #%PAM-1.0
 # This file is auto-generated.
 # User changes will be destroyed the next time authconfig is run.
 auth required /lib/security/$ISA/pam_env.so
 auth sufficient /lib/security/$ISA/pam_unix.so likeauth nullok
 auth sufficient /lib/security/$ISA/pam_ldap.so use_first_pass
 auth required /lib/security/$ISA/pam_deny.so
 
 account required /lib/security/$ISA/pam_unix.so broken_shadow
 account sufficient /lib/security/$ISA/pam_localuser.so
 account sufficient /lib/security/$ISA/pam_succeed_if.so uid  100 quiet
 account [default=bad success=ok user_unknown=ignore]
 /lib/security/$ISA/pam_ldap.so
 account required /lib/security/$ISA/pam_permit.so

I usually go for something more like:

account required pam_unix.so broken_shadow
account sufficient pam_localuser.so
account sufficient pam_ldap.so
account required pam_deny.so

But, if you aren't going to bother to learn how PAM works, you probably 
shouldn't be taking advice from random strangers on the internet.

Regards,
Buchan


Re: Notification of userPassword change in OpenLDAP?

2010-08-18 Thread Howard Chu

Tom Leach wrote:

I'm trying to work on a password sync scheme between OpenLDAP and some
systems that use flat Unix passwd/shadow files.  I have been able to
update the LDAP server when someone changes their password on the
standalone Unix systems, but I'm having problems trying to get any kind
of notification from the LDAP server if someone from a system using the
LDAP directory changes their password.

So far, I'm looking at searching the LDAP directory every few minutes
for any entries that have had their modifyTimestamp attribute change
since the last time the search ran, then checking to see if the
userPassword attribute in the LDAP directory is different then the
shadow file on the Unix system.  This seems like a real stupid scheme,
especially when passwords are changed infrequently.  I just don't want a
long delay between syncing the directory and flat files in case someone
changes their password on an LDAP client, then tries to log into the
flat file system.

Ideally, there could be some option in OpenLDAP that could call an
external program when some attribute(s) have changed.  That program
could then perform the necessary searches and update the flat files if
appropriate.  So far, I've found nothing indicating that this is
possible so I figured I'd ask and see if anyone else has tried this and
what they found.
Thanks!
Tom Leach
le...@coas.oregonstate.edu

In the old Symas Connexitor EMS product we simply put a slapd on top of 
/etc/passwd, /etc/shadow, and /etc/group (that is, these flat files provide 
the backing store for the database that this slapd exposes) and then replicate 
account updates to it from a central master. You could accomplish much the 
same thing today using a client reading an accesslog DB.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


Re:

2010-08-18 Thread Buchan Milne
On Tuesday, 17 August 2010 17:35:49 VANTASSLE, GEORDON M (ATTSI) wrote:
 I'm at a loss as to what to do next.  I'm running on RHEL 5

There are pre-built packages of OpenLDAP 2.4 for RHEL5 available. They might 
not be absolutely current, but they are much newer than 2.4.11, and more or 
less work out-the-box (as long as you take into account the versioning of 
files/directories/packages).

 and
 installing as a non-root user. I get the following message when trying
 to start a fresh install of openLdap:
 
 $ ./slapd
 ./slapd: error while loading shared libraries: libltdl.so.3: cannot open
 shared object file: No such file or directory
 $ locate libltdl.so.3
 /usr/local/lib/libltdl.so.3
 /usr/local/lib/libltdl.so.3.1.4
 /usr/share/libtool/libltdl/.libs/libltdl.so.3
 /usr/share/libtool/libltdl/.libs/libltdl.so.3.1.4


This is a really basic software installation question. Please consult your OS 
documentation. Reasonable place to start may be 'man ld.so' 'man ldconfig' and 
'man ldd'.

Regards,
Buchan


Re: Unable to start

2010-08-18 Thread Buchan Milne
On Tuesday, 17 August 2010 20:48:22 VANTASSLE, GEORDON M (ATTSI) wrote:
 I finally got everything compiled, and the make test worked like a
 charm.  However, when I try to manually start LDAP via the rc.openldap
 script, I get:
 $ ./test.rc.openldap start

Where did you get this init script? It certainly doesn't seem to be a 
standard one.

 Starting test.rc.openldap service(s) -
 Tue-Aug-17-14.23.51-2010 -
 STATUS: LDAP start attempt logged to
 /opt/app/ivr/openldap/openldap-2.4.11/var/logs/SystemOut.log
 STATUS: Waiting for ldap to finish the start sequence
 STATUS: Waiting for ldap to finish the start sequence
 STATUS: Waiting for ldap to finish the start sequence
 STATUS: Waiting for ldap to finish the start sequence
 STATUS: Waiting for ldap to finish the start sequence
 STATUS: Waiting for ldap to finish the start sequence
 ERROR: Unable to successfully start ldap within time limit

I am not aware of slapd producing any messages like this, maybe the init 
script isn't testing correctly whether slapd has started.


 Is there some way that I can see what is going on with this?

Yes, run your init script with debug mode (e.g. sh -x test.rc.openldap start)

 I don't
 know anything about LDAP, but my client requires it for one of their
 apps, so I would appreciate the help.

We don't know anything about your init script 

(this really doesn't have much to do with LDAP at all IMHO ).

Regards,
Buchan


Re: Openldap2.4.16 performance issue

2010-08-18 Thread Howard Chu

Singh, Devender (GE Capital, consultant) wrote:

Hi Chu,

Please help me on my below issue. It’s very urgent.


If you have a support contract with us, you can contact us at 
supp...@symas.com for help.


Otherwise, people help on this list as their time and interest allows.


Thanks  Regards,//

*Devender Singh*

Senior Unix Administrator,//

*From:* openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] *On Behalf Of *Singh,
Devender (GE Capital, consultant)
*Sent:* Tuesday, August 17, 2010 5:12 AM
*To:* openldap-technical@openldap.org
*Subject:* Openldap2.4.16 performance issue

Hi All,



I need help for openldap slapd 200% cpu utilization issue.


--
  -- Howard Chu
  CTO, Symas Corp.   http://www.symas.com
  Director, Highland Sun http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/


RE: Openldap2.4.16 performance issue

2010-08-18 Thread Siddhartha Jain
Off the top of my head:

1.   What indexes have been created? Do they match the attributes that your 
applications use most often?

2.   In this age of cheap RAM, 2GB RAM for a server seems puny. Latest Dell 
R710s come packed with 32-64GB RAM. Consider a hardware upgrade.

3.   Configure LB for active-active instead of active-passive?

4.   Turn on logging (any), run a small sample from the application and see 
what transactions eat up most cycles on the LDAP server.

5.   Upgrade from 2.4.16 to 2.4.xx?





From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh, Devender 
(GE Capital, consultant)
Sent: Wednesday, August 18, 2010 3:15 PM
To: h...@symas.com
Cc: openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

Hi Chu,

 Please help me on my below issue. It's very urgent.

Thanks  Regards,
Devender Singh
Senior Unix Administrator,

From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh, Devender 
(GE Capital, consultant)
Sent: Tuesday, August 17, 2010 5:12 AM
To: openldap-technical@openldap.org
Subject: Openldap2.4.16 performance issue


Hi All,



I need help for openldap slapd 200% cpu utilization issue.



I have configured three openldap servers(2 Masters and 1 Slave). I have

configure PEN load balancer for failover setup on 2 master openldap servers.It

means application server first of all hit the loadbalancer port and than PEN LB

will forwad that request to Master 1 or 2 openldap server.



Hardware configuration on all boxes:



OS: RHEL5(x86_64)

RAM: 2GB

Number of CPU: 2(Intel(R) Xeon(R)2.00GHz)



Number of BDB databases: 2



Databse1:



Number of users : 83

Number of dns: 83



Database2:



Number of users: 2000

Number of dns: 80



My Application1 using Databse1 and Application2 using Databse2.

Application2 just authenticating the users and store last 10 password history

only, It means Application1 is not using openldap too much.



In Application2(90% dependent on openldap) every user have 1000+ sub leafs

entries. when I want to do major changes(number of leafs write) into this, it.s

got hanged and got socket closed error in application logs and CPU utilization

goes 200% and RAM 52%. My DB_CONFIG file is below:



# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/12/18 11:53:27

ghenry Exp $

# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases.

#

# See the Oracle Berkeley DB documentation

#   
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html

# for detail description of DB_CONFIG syntax and semantics.

#

# Hints can also be found in the OpenLDAP Software FAQ

#   http://www.openldap.org/faq/index.cgi?file=2

# in particular:

#   http://www.openldap.org/faq/index.cgi?file=1075



# Note: most DB_CONFIG settings will take effect only upon rebuilding

# the DB environment.



# one 0.25 GB cache

set_cachesize 0 268435456 1



# Data Directory

#set_data_dir db



# Transaction Log settings

set_lg_regionmax 262144

set_lg_bsize 2097152

#set_lg_dir logs



# Note: special DB_CONFIG flags are no longer needed for quick

# slapadd(8) or slapindex(8) access (see their -q option).



Please help me here that what I need to do for better performance. Thanks in

advance.



My contact number is +919650477441


Thanks  Regards,
Devender Singh
Senior Unix Administrator,


RE: Openldap2.4.16 performance issue

2010-08-18 Thread Chris Jacobs
Devender,

You did see this email reply, right:

Singh, Devender (GE Capital, consultant) 
devender.sin...@ge.commailto:devender.sin...@ge.com writes:



 Hi Dieter,



  I need to tune any parameter in DB_CONFIG file for this or not? Because 
 I am using default DB_CONFIG file.



Just edit DB_CONFIG

set_log_dir /mountpoint/path/to/



-Dieter



--

Dieter Klünter | Systemberatung

sip: 7770...@sipgate.demailto:7770...@sipgate.de

http://www.dpunkt.de/buecher/2104.html

GPG Key ID:8EF7B6C6

Have you tried that yet?  Any change?

- chris

From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh, Devender 
(GE Capital, consultant)
Sent: Wednesday, August 18, 2010 3:15 PM
To: h...@symas.com
Cc: openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

Hi Chu,

 Please help me on my below issue. It's very urgent.

Thanks  Regards,
Devender Singh
Senior Unix Administrator,

From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh, Devender 
(GE Capital, consultant)
Sent: Tuesday, August 17, 2010 5:12 AM
To: openldap-technical@openldap.org
Subject: Openldap2.4.16 performance issue


Hi All,



I need help for openldap slapd 200% cpu utilization issue.



I have configured three openldap servers(2 Masters and 1 Slave). I have

configure PEN load balancer for failover setup on 2 master openldap servers.It

means application server first of all hit the loadbalancer port and than PEN LB

will forwad that request to Master 1 or 2 openldap server.



Hardware configuration on all boxes:



OS: RHEL5(x86_64)

RAM: 2GB

Number of CPU: 2(Intel(R) Xeon(R)2.00GHz)



Number of BDB databases: 2



Databse1:



Number of users : 83

Number of dns: 83



Database2:



Number of users: 2000

Number of dns: 80



My Application1 using Databse1 and Application2 using Databse2.

Application2 just authenticating the users and store last 10 password history

only, It means Application1 is not using openldap too much.



In Application2(90% dependent on openldap) every user have 1000+ sub leafs

entries. when I want to do major changes(number of leafs write) into this, it.s

got hanged and got socket closed error in application logs and CPU utilization

goes 200% and RAM 52%. My DB_CONFIG file is below:



# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/12/18 11:53:27

ghenry Exp $

# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases.

#

# See the Oracle Berkeley DB documentation

#   
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html

# for detail description of DB_CONFIG syntax and semantics.

#

# Hints can also be found in the OpenLDAP Software FAQ

#   http://www.openldap.org/faq/index.cgi?file=2

# in particular:

#   http://www.openldap.org/faq/index.cgi?file=1075



# Note: most DB_CONFIG settings will take effect only upon rebuilding

# the DB environment.



# one 0.25 GB cache

set_cachesize 0 268435456 1



# Data Directory

#set_data_dir db



# Transaction Log settings

set_lg_regionmax 262144

set_lg_bsize 2097152

#set_lg_dir logs



# Note: special DB_CONFIG flags are no longer needed for quick

# slapadd(8) or slapindex(8) access (see their -q option).



Please help me here that what I need to do for better performance. Thanks in

advance.



My contact number is +919650477441


Thanks  Regards,
Devender Singh
Senior Unix Administrator,


This message is private and confidential. If you have received it in error, 
please notify the sender and remove it from your system.



RE: Openldap2.4.16 performance issue

2010-08-18 Thread Singh, Devender (GE Capital, consultant)
Yes I did it, but not getting good performance. I restart slapd every time when 
cpu goes 200%. 

 

Thanks  Regards,

Devender Singh

Senior Unix Administrator,

 

From: Chris Jacobs [mailto:chris.jac...@apollogrp.edu] 
Sent: Thursday, August 19, 2010 4:17 AM
To: Singh, Devender (GE Capital, consultant); h...@symas.com
Cc: openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

 

Devender,

 

You did see this email reply, right:

Singh, Devender (GE Capital, consultant) devender.sin...@ge.com writes:

 

 Hi Dieter,

 

  I need to tune any parameter in DB_CONFIG file for this or not? Because 
 I am using default DB_CONFIG file.

 

Just edit DB_CONFIG

set_log_dir /mountpoint/path/to/

 

-Dieter

 

-- 

Dieter Klünter | Systemberatung

sip: 7770...@sipgate.de 

http://www.dpunkt.de/buecher/2104.html

GPG Key ID:8EF7B6C6

 

Have you tried that yet?  Any change?

 

- chris

 

From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh, Devender 
(GE Capital, consultant)
Sent: Wednesday, August 18, 2010 3:15 PM
To: h...@symas.com
Cc: openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

 

Hi Chu,

 

 Please help me on my below issue. It's very urgent.

 

Thanks  Regards,

Devender Singh

Senior Unix Administrator,

 

From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh, Devender 
(GE Capital, consultant)
Sent: Tuesday, August 17, 2010 5:12 AM
To: openldap-technical@openldap.org
Subject: Openldap2.4.16 performance issue

 

Hi All,
 
I need help for openldap slapd 200% cpu utilization issue.
 
I have configured three openldap servers(2 Masters and 1 Slave). I have
configure PEN load balancer for failover setup on 2 master openldap servers.It
means application server first of all hit the loadbalancer port and than PEN LB
will forwad that request to Master 1 or 2 openldap server.
 
Hardware configuration on all boxes:
 
OS: RHEL5(x86_64)
RAM: 2GB
Number of CPU: 2(Intel(R) Xeon(R)2.00GHz)
 
Number of BDB databases: 2
 
Databse1: 
 
Number of users : 83
Number of dns: 83
 
Database2:
 
Number of users: 2000
Number of dns: 80
 
My Application1 using Databse1 and Application2 using Databse2.
Application2 just authenticating the users and store last 10 password history
only, It means Application1 is not using openldap too much.
 
In Application2(90% dependent on openldap) every user have 1000+ sub leafs
entries. when I want to do major changes(number of leafs write) into this, it.s
got hanged and got socket closed error in application logs and CPU utilization
goes 200% and RAM 52%. My DB_CONFIG file is below:
 
# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/12/18 11:53:27
ghenry Exp $
# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases.
#
# See the Oracle Berkeley DB documentation
#   
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html
 
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/db_config.html
 
# for detail description of DB_CONFIG syntax and semantics.
#
# Hints can also be found in the OpenLDAP Software FAQ
#   http://www.openldap.org/faq/index.cgi?file=2 
http://www.openldap.org/faq/index.cgi?file=2 
# in particular:
#   http://www.openldap.org/faq/index.cgi?file=1075 
http://www.openldap.org/faq/index.cgi?file=1075 
 
# Note: most DB_CONFIG settings will take effect only upon rebuilding
# the DB environment.
 
# one 0.25 GB cache
set_cachesize 0 268435456 1
 
# Data Directory
#set_data_dir db
 
# Transaction Log settings
set_lg_regionmax 262144
set_lg_bsize 2097152
#set_lg_dir logs
 
# Note: special DB_CONFIG flags are no longer needed for quick
# slapadd(8) or slapindex(8) access (see their -q option).
 
Please help me here that what I need to do for better performance. Thanks in
advance.
 
My contact number is +919650477441

 

 

Thanks  Regards,

Devender Singh

Senior Unix Administrator,

 



This message is private and confidential. If you have received it in error, 
please notify the sender and remove it from your system.





RE: Openldap2.4.16 performance issue

2010-08-18 Thread Quanah Gibson-Mount



--On August 19, 2010 4:23:31 AM +0530 Singh, Devender (GE Capital, 
consultant) devender.sin...@ge.com wrote:





Yes I did it, but not getting good performance. I restart slapd every
time when cpu goes 200%.


What is the size of your *.bdb files?  Are you on a 32-bit or 64-bit server?

--Quanah

--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration



RE: Openldap2.4.16 performance issue

2010-08-18 Thread Singh, Devender (GE Capital, consultant)
Please find the below answers:

[r...@abc openldap-data-ge_cw]# du -sh *.bdb
3.6Mbr.bdb
72K cn.bdb
32K displayName.bdb
234Mdn2id.bdb
104Kgr.bdb
419Mid2entry.bdb
56K mail.bdb
1.4MobjectClass.bdb
2.9Mpf.bdb
212Kpr.bdb
72K sn.bdb
72K uid.bdb

[r...@abc openldap-data-ge_cw]# getconf LONG_BIT
32

Thanks  Regards,
Devender Singh
Senior Unix Administrator,
(SOA Support Team)


SDG Software India Pvt. Ltd
A-10, Sector 2, Noida 201301, U.P, India
M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020
website : www.sdgc.com


Please Note: The e-mail content is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying
or distribution or forwarding of any or all of the contents in this
message is STRICTLY PROHIBITED. If you have erroneously received this
message, please delete it immediately and notify the sender. Before
opening any attachments please check them for viruses and defects.


-Original Message-
From: Quanah Gibson-Mount [mailto:qua...@zimbra.com] 
Sent: Thursday, August 19, 2010 4:34 AM
To: Singh, Devender (GE Capital, consultant); Chris Jacobs
Cc: openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue



--On August 19, 2010 4:23:31 AM +0530 Singh, Devender (GE Capital, 
consultant) devender.sin...@ge.com wrote:



 Yes I did it, but not getting good performance. I restart slapd every
 time when cpu goes 200%.

What is the size of your *.bdb files?  Are you on a 32-bit or 64-bit
server?

--Quanah

-- 
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration



RE: Openldap2.4.16 performance issue

2010-08-18 Thread Singh, Devender (GE Capital, consultant)
Please find the answers:

 

1.   What indexes have been created? Do they match the attributes
that your applications use most often? --- All required attributes
related application indexed(equality)

2.   In this age of cheap RAM, 2GB RAM for a server seems puny.
Latest Dell R710s come packed with 32-64GB RAM. Consider a hardware
upgrade.-We can increase it by 3-4 GB only

3.   Configure LB for active-active instead of active-passive?-I
have configured PEN LB as a active-active(both master are active-active)

4.   Turn on logging (any), run a small sample from the application
and see what transactions eat up most cycles on the LDAP server.(I have
configured loglevel 256, if I set  loglevel -1, it will slow the read
write speed from/to openldap server and also eating cpu. )

5.   Upgrade from 2.4.16 to 2.4.xx?---I don't think that up
gradation will solve this issue. 

 

Here my concern is:

 

I think I need to set below parameter in DB_CONFIG file:
set_cachesize (but what should be the tuned value according to my data?)

 

Thanks  Regards,

Devender Singh

Senior Unix Administrator,

(SOA Support Team)




SDG Software India Pvt. Ltd

A-10, Sector 2, Noida 201301, U.P, India

M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020

website : www.sdgc.com http://www.sdgc.com/ 




Please Note: The e-mail content is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying
or distribution or forwarding of any or all of the contents in this
message is STRICTLY PROHIBITED. If you have erroneously received this
message, please delete it immediately and notify the sender. Before
opening any attachments please check them for viruses and defects.

 

From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Siddhartha
Jain
Sent: Thursday, August 19, 2010 4:17 AM
To: openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

 

Off the top of my head:

6.   What indexes have been created? Do they match the attributes
that your applications use most often?

7.   In this age of cheap RAM, 2GB RAM for a server seems puny.
Latest Dell R710s come packed with 32-64GB RAM. Consider a hardware
upgrade.

8.   Configure LB for active-active instead of active-passive?

9.   Turn on logging (any), run a small sample from the application
and see what transactions eat up most cycles on the LDAP server.

10.   Upgrade from 2.4.16 to 2.4.xx?

 

 

 

 

From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh,
Devender (GE Capital, consultant)
Sent: Wednesday, August 18, 2010 3:15 PM
To: h...@symas.com
Cc: openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

 

Hi Chu,

 

 Please help me on my below issue. It's very urgent.

 

Thanks  Regards,

Devender Singh

Senior Unix Administrator,

 

From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh,
Devender (GE Capital, consultant)
Sent: Tuesday, August 17, 2010 5:12 AM
To: openldap-technical@openldap.org
Subject: Openldap2.4.16 performance issue

 

Hi All,
 
I need help for openldap slapd 200% cpu utilization issue.
 
I have configured three openldap servers(2 Masters and 1 Slave). I have
configure PEN load balancer for failover setup on 2 master openldap
servers.It
means application server first of all hit the loadbalancer port and than
PEN LB
will forwad that request to Master 1 or 2 openldap server.
 
Hardware configuration on all boxes:
 
OS: RHEL5(x86_64)
RAM: 2GB
Number of CPU: 2(Intel(R) Xeon(R)2.00GHz)
 
Number of BDB databases: 2
 
Databse1: 
 
Number of users : 83
Number of dns: 83
 
Database2:
 
Number of users: 2000
Number of dns: 80
 
My Application1 using Databse1 and Application2 using Databse2.
Application2 just authenticating the users and store last 10 password
history
only, It means Application1 is not using openldap too much.
 
In Application2(90% dependent on openldap) every user have 1000+ sub
leafs
entries. when I want to do major changes(number of leafs write) into
this, it.s
got hanged and got socket closed error in application logs and CPU
utilization
goes 200% and RAM 52%. My DB_CONFIG file is below:
 
# $OpenLDAP: pkg/ldap/servers/slapd/DB_CONFIG,v 1.3.2.4 2007/12/18
11:53:27
ghenry Exp $
# Example DB_CONFIG file for use with slapd(8) BDB/HDB databases.
#
# See the Oracle Berkeley DB documentation
#
http://www.oracle.com/technology/documentation/berkeley-db/db/ref/env/d
b_config.html

RE: Openldap2.4.16 performance issue

2010-08-18 Thread Quanah Gibson-Mount



--On August 19, 2010 4:41:14 AM +0530 Singh, Devender (GE Capital, 
consultant) devender.sin...@ge.com wrote:

5.   Upgrade from 2.4.16 to 2.4.xx?---I don’t think that up
gradation will solve this issue.



I disagree, I think it could have a significant result in your issue.


Here my concern is:


I think I need to set below parameter in DB_CONFIG file:

set_cachesize (but what should be the tuned value according to my data?)


Based on what you wrote before, I'd set it to use 500MB

--Quanah

--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration



RE: Openldap2.4.16 performance issue

2010-08-18 Thread Singh, Devender (GE Capital, consultant)
If you want any other information, I can give you. I need permanent solution:)

Thanks  Regards,
Devender Singh
Senior Unix Administrator,
(SOA Support Team)

SDG Software India Pvt. Ltd
A-10, Sector 2, Noida 201301, U.P, India
M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020
website : www.sdgc.com

Please Note: The e-mail content is intended for the sole use of the intended 
recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY 
INFORMATION. Any review or reliance by others or copying or distribution or 
forwarding of any or all of the contents in this message is STRICTLY 
PROHIBITED. If you have erroneously received this message, please delete it 
immediately and notify the sender. Before opening any attachments please check 
them for viruses and defects.


-Original Message-
From: Quanah Gibson-Mount [mailto:qua...@zimbra.com] 
Sent: Thursday, August 19, 2010 4:59 AM
To: Singh, Devender (GE Capital, consultant); Siddhartha Jain; 
openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue



--On August 19, 2010 4:41:14 AM +0530 Singh, Devender (GE Capital, 
consultant) devender.sin...@ge.com wrote:
 5.   Upgrade from 2.4.16 to 2.4.xx?---I don’t think that up
 gradation will solve this issue.


I disagree, I think it could have a significant result in your issue.

 Here my concern is:


 I think I need to set below parameter in DB_CONFIG file:

 set_cachesize (but what should be the tuned value according to my data?)

Based on what you wrote before, I'd set it to use 500MB

--Quanah

-- 
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc

Zimbra ::  the leader in open source messaging and collaboration



RE: Openldap2.4.16 performance issue

2010-08-18 Thread Singh, Devender (GE Capital, consultant)
As per the client requirement there is no need of substring indexing

Thanks  Regards,
Devender Singh
Senior Unix Administrator,
(SOA Support Team)


SDG Software India Pvt. Ltd
A-10, Sector 2, Noida 201301, U.P, India
M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020
website : www.sdgc.com


Please Note: The e-mail content is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying
or distribution or forwarding of any or all of the contents in this
message is STRICTLY PROHIBITED. If you have erroneously received this
message, please delete it immediately and notify the sender. Before
opening any attachments please check them for viruses and defects.


-Original Message-
From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Keutel,
Jochen
Sent: Thursday, August 19, 2010 5:26 AM
To: openldap-technical@openldap.org
Subject: Re: Openldap2.4.16 performance issue

Hi,
   are you sure that just equality index is sufficient? Most 
applications do substring searches, e.g. sn=sin*.

I'd recommend to add substr to the often used attributes.

Regards,  Jochen.

Am 19.08.2010 01:11, schrieb Singh, Devender (GE Capital, consultant):
 Please find the answers:

 1. What indexes have been created? Do they match the attributes that
 your applications use most often? --- All required attributes related
 application indexed(equality)

 2. In this age of cheap RAM, 2GB RAM for a server seems puny. Latest
 Dell R710s come packed with 32-64GB RAM. Consider a hardware
upgrade.-We
 can increase it by 3-4 GB only

 3. Configure LB for active-active instead of active-passive?-I have
 configured PEN LB as a active-active(both master are active-active)

 4. Turn on logging (any), run a small sample from the application and
 see what transactions eat up most cycles on the LDAP server.(I have
 configured loglevel 256, if I set loglevel -1, it will slow the read
 write speed from/to openldap server and also eating cpu. )

 5. Upgrade from 2.4.16 to 2.4.xx?---I don't think that up gradation
will
 solve this issue.

 Here my concern is:

 I think I need to set below parameter in DB_CONFIG file:

 */set_cachesize (/*but what should be the tuned value according to my
data?)

 Thanks  Regards,//

 *Devender Singh*

 Senior Unix Administrator,//

 (SOA Support Team)//


/___
_///

 *SDG Software India Pvt. Ltd*//

 A-10, Sector 2, Noida 201301, U.P, India//

 M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020//

 website : www.sdgc.com http://www.sdgc.com///


/___
_///

 *Please Note:* The e-mail content is intended for the sole use of the
 intended recipient/s and may contain material that is CONFIDENTIAL AND
 PRIVATE COMPANY INFORMATION. Any review or reliance by others or
copying
 or distribution or forwarding of any or all of the contents in this
 message is STRICTLY PROHIBITED. If you have erroneously received this
 message, please delete it immediately and notify the sender. Before
 opening any attachments please check them for viruses and defects.

 *From:* openldap-technical-boun...@openldap.org
 [mailto:openldap-technical-boun...@openldap.org] *On Behalf Of
 *Siddhartha Jain
 *Sent:* Thursday, August 19, 2010 4:17 AM
 *To:* openldap-technical@openldap.org
 *Subject:* RE: Openldap2.4.16 performance issue

 Off the top of my head:

 6. What indexes have been created? Do they match the attributes that
 your applications use most often?

 7. In this age of cheap RAM, 2GB RAM for a server seems puny. Latest
 Dell R710s come packed with 32-64GB RAM. Consider a hardware upgrade.

 8. Configure LB for active-active instead of active-passive?

 9. Turn on logging (any), run a small sample from the application and
 see what transactions eat up most cycles on the LDAP server.

 10. Upgrade from 2.4.16 to 2.4.xx?

 *From:* openldap-technical-boun...@openldap.org
 [mailto:openldap-technical-boun...@openldap.org] *On Behalf Of *Singh,
 Devender (GE Capital, consultant)
 *Sent:* Wednesday, August 18, 2010 3:15 PM
 *To:* h...@symas.com
 *Cc:* openldap-technical@openldap.org
 *Subject:* RE: Openldap2.4.16 performance issue

 Hi Chu,

 Please help me on my below issue. It's very urgent.

 Thanks  Regards,//

 *Devender Singh*

 Senior Unix Administrator,//

 *From:* openldap-technical-boun...@openldap.org
 [mailto:openldap-technical-boun...@openldap.org] *On Behalf Of *Singh,
 Devender (GE 

RE: Openldap2.4.16 performance issue

2010-08-18 Thread Siddhartha Jain
In that case, you should ask the *client* to give you a solution. Seriously, if 
you do not have complete control over LDAP configuration or if *client* 
dictates certain config parameters then it is best to report this as a bug to 
your application team.

Do you have a test instance to do test config changes on? 



-Original Message-
From: openldap-technical-boun...@openldap.org 
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh, Devender 
(GE Capital, consultant)
Sent: Wednesday, August 18, 2010 5:02 PM
To: Keutel, Jochen; openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

As per the client requirement there is no need of substring indexing


-Original Message-
From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Keutel,
Jochen
Sent: Thursday, August 19, 2010 5:26 AM
To: openldap-technical@openldap.org
Subject: Re: Openldap2.4.16 performance issue

Hi,
   are you sure that just equality index is sufficient? Most 
applications do substring searches, e.g. sn=sin*.

I'd recommend to add substr to the often used attributes.

Regards,  Jochen.

Am 19.08.2010 01:11, schrieb Singh, Devender (GE Capital, consultant):
 Please find the answers:

 1. What indexes have been created? Do they match the attributes that
 your applications use most often? --- All required attributes related
 application indexed(equality)

 2. In this age of cheap RAM, 2GB RAM for a server seems puny. Latest
 Dell R710s come packed with 32-64GB RAM. Consider a hardware
upgrade.-We
 can increase it by 3-4 GB only

 3. Configure LB for active-active instead of active-passive?-I have
 configured PEN LB as a active-active(both master are active-active)

 4. Turn on logging (any), run a small sample from the application and
 see what transactions eat up most cycles on the LDAP server.(I have
 configured loglevel 256, if I set loglevel -1, it will slow the read
 write speed from/to openldap server and also eating cpu. )

 5. Upgrade from 2.4.16 to 2.4.xx?---I don't think that up gradation
will
 solve this issue.

 Here my concern is:

 I think I need to set below parameter in DB_CONFIG file:

 */set_cachesize (/*but what should be the tuned value according to my
data?)

 Thanks  Regards,//

 *Devender Singh*

 Senior Unix Administrator,//

 (SOA Support Team)//


/___
_///

 *SDG Software India Pvt. Ltd*//

 A-10, Sector 2, Noida 201301, U.P, India//

 M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020//

 website : www.sdgc.com http://www.sdgc.com///


/___
_///

 *Please Note:* The e-mail content is intended for the sole use of the
 intended recipient/s and may contain material that is CONFIDENTIAL AND
 PRIVATE COMPANY INFORMATION. Any review or reliance by others or
copying
 or distribution or forwarding of any or all of the contents in this
 message is STRICTLY PROHIBITED. If you have erroneously received this
 message, please delete it immediately and notify the sender. Before
 opening any attachments please check them for viruses and defects.

 *From:* openldap-technical-boun...@openldap.org
 [mailto:openldap-technical-boun...@openldap.org] *On Behalf Of
 *Siddhartha Jain
 *Sent:* Thursday, August 19, 2010 4:17 AM
 *To:* openldap-technical@openldap.org
 *Subject:* RE: Openldap2.4.16 performance issue

 Off the top of my head:

 6. What indexes have been created? Do they match the attributes that
 your applications use most often?

 7. In this age of cheap RAM, 2GB RAM for a server seems puny. Latest
 Dell R710s come packed with 32-64GB RAM. Consider a hardware upgrade.

 8. Configure LB for active-active instead of active-passive?

 9. Turn on logging (any), run a small sample from the application and
 see what transactions eat up most cycles on the LDAP server.

 10. Upgrade from 2.4.16 to 2.4.xx?

 *From:* openldap-technical-boun...@openldap.org
 [mailto:openldap-technical-boun...@openldap.org] *On Behalf Of *Singh,
 Devender (GE Capital, consultant)
 *Sent:* Wednesday, August 18, 2010 3:15 PM
 *To:* h...@symas.com
 *Cc:* openldap-technical@openldap.org
 *Subject:* RE: Openldap2.4.16 performance issue

 Hi Chu,

 Please help me on my below issue. It's very urgent.

 Thanks  Regards,//

 *Devender Singh*

 Senior Unix Administrator,//

 *From:* openldap-technical-boun...@openldap.org
 [mailto:openldap-technical-boun...@openldap.org] *On Behalf Of *Singh,
 Devender (GE Capital, consultant)
 *Sent:* Tuesday, August 17, 2010 5:12 AM
 *To:* openldap-technical@openldap.org
 *Subject:* Openldap2.4.16 performance issue

 Hi All,



 I need help for openldap slapd 200% cpu utilization issue.



 I have configured three openldap servers(2 Masters and 1 Slave). I
have

 configure PEN load 

RE: Openldap2.4.16 performance issue

2010-08-18 Thread Singh, Devender (GE Capital, consultant)
Before migration, the application was running fine without any issue on
IBM Tivoli directory server 5.2.

Yes we have a test server. Please suggest me configuration level
changes.

Thanks  Regards,
Devender Singh
Senior Unix Administrator,
(SOA Support Team)


SDG Software India Pvt. Ltd
A-10, Sector 2, Noida 201301, U.P, India
M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020
website : www.sdgc.com


Please Note: The e-mail content is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying
or distribution or forwarding of any or all of the contents in this
message is STRICTLY PROHIBITED. If you have erroneously received this
message, please delete it immediately and notify the sender. Before
opening any attachments please check them for viruses and defects.


-Original Message-
From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Siddhartha
Jain
Sent: Thursday, August 19, 2010 5:58 AM
To: openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

In that case, you should ask the *client* to give you a solution.
Seriously, if you do not have complete control over LDAP configuration
or if *client* dictates certain config parameters then it is best to
report this as a bug to your application team.

Do you have a test instance to do test config changes on? 



-Original Message-
From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh,
Devender (GE Capital, consultant)
Sent: Wednesday, August 18, 2010 5:02 PM
To: Keutel, Jochen; openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

As per the client requirement there is no need of substring indexing


-Original Message-
From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Keutel,
Jochen
Sent: Thursday, August 19, 2010 5:26 AM
To: openldap-technical@openldap.org
Subject: Re: Openldap2.4.16 performance issue

Hi,
   are you sure that just equality index is sufficient? Most 
applications do substring searches, e.g. sn=sin*.

I'd recommend to add substr to the often used attributes.

Regards,  Jochen.

Am 19.08.2010 01:11, schrieb Singh, Devender (GE Capital, consultant):
 Please find the answers:

 1. What indexes have been created? Do they match the attributes that
 your applications use most often? --- All required attributes related
 application indexed(equality)

 2. In this age of cheap RAM, 2GB RAM for a server seems puny. Latest
 Dell R710s come packed with 32-64GB RAM. Consider a hardware
upgrade.-We
 can increase it by 3-4 GB only

 3. Configure LB for active-active instead of active-passive?-I have
 configured PEN LB as a active-active(both master are active-active)

 4. Turn on logging (any), run a small sample from the application and
 see what transactions eat up most cycles on the LDAP server.(I have
 configured loglevel 256, if I set loglevel -1, it will slow the read
 write speed from/to openldap server and also eating cpu. )

 5. Upgrade from 2.4.16 to 2.4.xx?---I don't think that up gradation
will
 solve this issue.

 Here my concern is:

 I think I need to set below parameter in DB_CONFIG file:

 */set_cachesize (/*but what should be the tuned value according to my
data?)

 Thanks  Regards,//

 *Devender Singh*

 Senior Unix Administrator,//

 (SOA Support Team)//


/___
_///

 *SDG Software India Pvt. Ltd*//

 A-10, Sector 2, Noida 201301, U.P, India//

 M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020//

 website : www.sdgc.com http://www.sdgc.com///


/___
_///

 *Please Note:* The e-mail content is intended for the sole use of the
 intended recipient/s and may contain material that is CONFIDENTIAL AND
 PRIVATE COMPANY INFORMATION. Any review or reliance by others or
copying
 or distribution or forwarding of any or all of the contents in this
 message is STRICTLY PROHIBITED. If you have erroneously received this
 message, please delete it immediately and notify the sender. Before
 opening any attachments please check them for viruses and defects.

 *From:* openldap-technical-boun...@openldap.org
 [mailto:openldap-technical-boun...@openldap.org] *On Behalf Of
 *Siddhartha Jain
 *Sent:* Thursday, August 19, 2010 4:17 AM
 *To:* openldap-technical@openldap.org
 *Subject:* RE: Openldap2.4.16 performance issue

 Off 

RE: Openldap2.4.16 performance issue

2010-08-18 Thread Quanah Gibson-Mount
1) You seriously need to use OpenLDAP 2.4.23.  I don't care if you don't 
think that'll solve the issue or not. ;)


2) You need to state which backend you are using (back-hdb, back-bdb, etc)

3) You need to state your updated DB_CONFIG, based on the cachesize info I 
suggested earlier


4) You need to state what version of BDB back-hdb/back-bdb is using. This 
is critical to know


5) You need to state if you have modified the threads setting for 
slapd.conf or related for cn=config, depending which you are using.


--Quanah

--On August 19, 2010 6:05:19 AM +0530 Singh, Devender (GE Capital, 
consultant) devender.sin...@ge.com wrote:



Before migration, the application was running fine without any issue on
IBM Tivoli directory server 5.2.

Yes we have a test server. Please suggest me configuration level
changes.

Thanks  Regards,
Devender Singh
Senior Unix Administrator,
(SOA Support Team)


SDG Software India Pvt. Ltd
A-10, Sector 2, Noida 201301, U.P, India
M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020
website : www.sdgc.com


Please Note: The e-mail content is intended for the sole use of the
intended recipient/s and may contain material that is CONFIDENTIAL AND
PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying
or distribution or forwarding of any or all of the contents in this
message is STRICTLY PROHIBITED. If you have erroneously received this
message, please delete it immediately and notify the sender. Before
opening any attachments please check them for viruses and defects.


-Original Message-
From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Siddhartha
Jain
Sent: Thursday, August 19, 2010 5:58 AM
To: openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

In that case, you should ask the *client* to give you a solution.
Seriously, if you do not have complete control over LDAP configuration
or if *client* dictates certain config parameters then it is best to
report this as a bug to your application team.

Do you have a test instance to do test config changes on?



-Original Message-
From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Singh,
Devender (GE Capital, consultant)
Sent: Wednesday, August 18, 2010 5:02 PM
To: Keutel, Jochen; openldap-technical@openldap.org
Subject: RE: Openldap2.4.16 performance issue

As per the client requirement there is no need of substring indexing


-Original Message-
From: openldap-technical-boun...@openldap.org
[mailto:openldap-technical-boun...@openldap.org] On Behalf Of Keutel,
Jochen
Sent: Thursday, August 19, 2010 5:26 AM
To: openldap-technical@openldap.org
Subject: Re: Openldap2.4.16 performance issue

Hi,
   are you sure that just equality index is sufficient? Most
applications do substring searches, e.g. sn=sin*.

I'd recommend to add substr to the often used attributes.

Regards,  Jochen.

Am 19.08.2010 01:11, schrieb Singh, Devender (GE Capital, consultant):

Please find the answers:

1. What indexes have been created? Do they match the attributes that
your applications use most often? --- All required attributes related
application indexed(equality)

2. In this age of cheap RAM, 2GB RAM for a server seems puny. Latest
Dell R710s come packed with 32-64GB RAM. Consider a hardware

upgrade.-We

can increase it by 3-4 GB only

3. Configure LB for active-active instead of active-passive?-I have
configured PEN LB as a active-active(both master are active-active)

4. Turn on logging (any), run a small sample from the application and
see what transactions eat up most cycles on the LDAP server.(I have
configured loglevel 256, if I set loglevel -1, it will slow the read
write speed from/to openldap server and also eating cpu. )

5. Upgrade from 2.4.16 to 2.4.xx?---I don't think that up gradation

will

solve this issue.

Here my concern is:

I think I need to set below parameter in DB_CONFIG file:

*/set_cachesize (/*but what should be the tuned value according to my

data?)


Thanks  Regards,//

*Devender Singh*

Senior Unix Administrator,//

(SOA Support Team)//



/___
_///


*SDG Software India Pvt. Ltd*//

A-10, Sector 2, Noida 201301, U.P, India//

M: +91-9910024231 O: +91.120.401.4000 F: +91.120.401.4020//

website : www.sdgc.com http://www.sdgc.com///



/___
_///


*Please Note:* The e-mail content is intended for the sole use of the
intended recipient/s and may contain material that is