Hi,
I am running a v2.4.31 consumer on CentOS 5.8 to serve user accounts (and aliases) on a Postfix mail server running locally. It has been running for a long time without problems.
Today, after a user sent (on 14:53:39) a mass mail (through a group alias, implemented using ldap dynlist), Postfix stalled and the server (a VM under KVM) became overloaded. I noticed that openldap was using all the cpu:
# top top - 15:30:01 up 81 days, 2:11, 1 user, load average: 113.58, 114.36, 104.02 Tasks: 460 total, 3 running, 457 sleeping, 0 stopped, 0 zombie Cpu(s): 98.9%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 1.1%hi, 0.0%si, 0.0%st Mem: 3089988k total, 3074912k used, 15076k free, 12180k buffers Swap: 2064376k total, 92k used, 2064284k free, 1909976k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2209 ldap 18 0 577m 17m 8952 S 93.4 0.6 55:03.67 slapd ...
I had to stop and restart openldap manually, and after that I only found in the log (nothing has been logged earlier):
Sep 28 15:00:07 mail slapd[2209]: connection_input: conn=14847 deferring operation: too many executing Sep 28 15:00:38 mail slapd[2209]: connection_input: conn=19285 deferring operation: too many executing Sep 28 15:32:46 mail slapd[2209]: connection_input: conn=19419 deferring operation: binding Sep 28 15:32:47 mail slapd[2209]: connection_input: conn=19419 deferring operation: binding Sep 28 15:32:57 mail slapd[4484]: [INFO] Using /etc/default/slapd for configuration Sep 28 15:32:57 mail slapd[4489]: [INFO] Halting OpenLDAP... Sep 28 15:32:57 mail slapd[2209]: daemon: shutdown requested and initiated. Sep 28 15:32:57 mail slapd[2209]: slapd shutdown: waiting for 1 operations/tasks to finish Sep 28 15:33:03 mail slapd[2209]: slapd stopped. Sep 28 15:33:05 mail slapd[4510]: [OK] OpenLDAP stopped after 7 seconds Sep 28 15:33:05 mail slapd[4511]: [INFO] No data backup done Sep 28 15:33:12 mail slapd[4529]: [INFO] Using /etc/default/slapd for configuration Sep 28 15:33:12 mail slapd[4534]: [INFO] Launching OpenLDAP configuration test... Sep 28 15:33:16 mail slapd[4568]: [OK] OpenLDAP configuration test successful Sep 28 15:33:16 mail slapd[4578]: [INFO] No db_recover done Sep 28 15:33:16 mail slapd[4579]: [INFO] Launching OpenLDAP... Sep 28 15:33:16 mail slapd[4580]: [OK] File descriptor limit set to 1024 Sep 28 15:33:17 mail slapd[4581]: @(#) $OpenLDAP: slapd 2.4.31 (Apr 26 2012 19:53:11) $ clement@localhost.localdomain:/home/clement/build/BUILD/openldap-2.4.31/servers/slapd
...
Possibly, a number of parallel group alias uses, caused a large number of LDAP queries by Postfix. Can you please advise on what may have caused OpenLDAP overloading, and on how can we avoid it from happening again? Any config changes?
My config follows.
Thanks in advance for your time and assistance.
Regards, Nick
# cat /usr/local/openldap/var/openldap-data/DB_CONFIG #==================================================================== # BDB configuration # # Provided by LTB-project (http://www.ltb-project.org) #====================================================================
#==================================================================== # Cache size for DB files #==================================================================== set_cachesize 1 0 1
#==================================================================== # Flags #==================================================================== #set_flags DB_TXN_WRITE_NOSYNC #set_flags DB_TXN_NOSYNC set_flags DB_LOG_AUTOREMOVE
#==================================================================== # Logs #==================================================================== # Size set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152
# Directory set_lg_dir /usr/local/berkeleydb/openldap-logs
************************************************************************
# cat /usr/local/openldap/etc/openldap/slapd.conf # include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/eduperson.schema include /usr/local/openldap/etc/openldap/schema/postfix.schema include /usr/local/openldap/etc/openldap/schema/dyngroup.schema include /usr/local/openldap/etc/openldap/schema/misc.schema include /usr/local/openldap/etc/openldap/schema/ppolicy.schema include /usr/local/openldap/etc/openldap/schema/schac-20090326-1.4.0.schema include /usr/local/openldap/etc/openldap/schema/dnsdomain2.schema include /usr/local/openldap/etc/openldap/schema/proftpd-quota.schema include /usr/local/openldap/etc/openldap/schema/kerberos.schema include /usr/local/openldap/etc/openldap/schema/localemail.schema include /usr/local/openldap/etc/openldap/schema/entryaccess.schema
pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args
modulepath /usr/local/openldap/lib64
loglevel sync
sizelimit unlimited timelimit unlimited
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /usr/local/openldap/etc/openldap/cacerts/chain.pem TLSCertificateFile /usr/local/openldap/etc/openldap/cacerts/cert.pem TLSCertificateKeyFile /usr/local/openldap/etc/openldap/cacerts/key.pem
TLSVerifyClient never
####################################################################### # ldbm and/or bdb database definitions #######################################################################
database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret
######## # ACLs # ######## include /usr/local/openldap/etc/openldap/acl.conf
directory /usr/local/openldap/var/openldap-data
index objectClass eq,pres index employeeType pres,eq index cn eq,pres,sub index sn,givenname eq,pres,sub index mail eq,pres,sub index uid eq,pres index ou eq,pres index mailacceptinggeneralid eq,pres index owner eq index entryCSN,entryUUID eq index vacationActive eq index associatedDomain pres,eq,sub index dc eq index emailLocalAddress eq,pres,sub
overlay dynlist dynlist-attrset nisMailAlias labeledURI dynlist-attrset groupOfURLs labeledURI member
syncrepl rid=111 provider=ldaps://ldap.example.com tls_reqcert=never type=refreshAndPersist retry="60 15 180 +" searchbase="dc=example,dc=com" schemachecking=off bindmethod=simple binddn="uid=FullReplAcc1,ou=System,dc=example,dc=com" credentials="mypassword"
database monitor
access to * by dn.exact="cn=Manager,dc=example,dc=com" read by * none
*********************************************************************
# ls -la /usr/local/openldap/var/openldap-data/ total 14120 drwxr-xr-x 2 ldap ldap 4096 Sep 28 15:33 . drwxr-xr-x 4 ldap ldap 4096 Apr 26 20:56 .. -rw-r--r-- 1 ldap ldap 4096 Sep 28 15:33 alock -rw------- 1 ldap ldap 1261568 Sep 28 15:32 associatedDomain.bdb -rw------- 1 ldap ldap 512000 Sep 28 15:32 cn.bdb -rw------- 1 ldap ldap 24576 Sep 28 15:33 __db.001 -rw------- 1 ldap ldap 1294336 Sep 28 16:12 __db.002 -rw------- 1 ldap ldap 32776192 Sep 28 16:12 __db.003 -rw------- 1 ldap ldap 3145728 Sep 28 16:11 __db.004 -rw------- 1 ldap ldap 729088 Sep 28 16:12 __db.005 -rw------- 1 ldap ldap 32768 Sep 28 16:11 __db.006 -rw-r--r-- 1 ldap ldap 924 Apr 26 21:01 DB_CONFIG -rw------- 1 ldap ldap 845 Apr 26 20:56 DB_CONFIG.example -rw------- 1 ldap ldap 61440 Sep 28 15:32 dc.bdb -rw------- 1 ldap ldap 339968 Sep 28 15:33 dn2id.bdb -rw------- 1 ldap ldap 212992 Sep 28 15:33 emailLocalAddress.bdb -rw------- 1 ldap ldap 20480 Sep 28 15:33 employeeType.bdb -rw------- 1 ldap ldap 118784 Sep 28 15:33 entryCSN.bdb -rw------- 1 ldap ldap 81920 Sep 28 15:33 entryUUID.bdb -rw------- 1 ldap ldap 90112 Sep 28 15:32 givenName.bdb -rw------- 1 ldap ldap 2457600 Sep 28 15:33 id2entry.bdb -rw------- 1 ldap ldap 24576 Jul 9 13:13 mailacceptinggeneralid.bdb -rw------- 1 ldap ldap 212992 Sep 28 15:33 mail.bdb -rw------- 1 ldap ldap 266240 Sep 28 15:33 objectClass.bdb -rw------- 1 ldap ldap 40960 Sep 28 15:33 ou.bdb -rw------- 1 ldap ldap 8192 Sep 28 15:32 owner.bdb -rw------- 1 ldap ldap 253952 Sep 28 15:32 sn.bdb -rw------- 1 ldap ldap 28672 Sep 28 15:33 uid.bdb -rw------- 1 ldap ldap 8192 Sep 25 2011 vacationActive.bdb
***************************************************************************
2012/9/28 Nick Milas nick@eurobjects.com:
Hi,
I am running a v2.4.31 consumer on CentOS 5.8 to serve user accounts (and aliases) on a Postfix mail server running locally. It has been running for a long time without problems.
Today, after a user sent (on 14:53:39) a mass mail (through a group alias, implemented using ldap dynlist), Postfix stalled and the server (a VM under KVM) became overloaded. I noticed that openldap was using all the cpu:
# top top - 15:30:01 up 81 days, 2:11, 1 user, load average: 113.58, 114.36, 104.02 Tasks: 460 total, 3 running, 457 sleeping, 0 stopped, 0 zombie Cpu(s): 98.9%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 1.1%hi, 0.0%si, 0.0%st Mem: 3089988k total, 3074912k used, 15076k free, 12180k buffers Swap: 2064376k total, 92k used, 2064284k free, 1909976k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 2209 ldap 18 0 577m 17m 8952 S 93.4 0.6 55:03.67 slapd ...
I had to stop and restart openldap manually, and after that I only found in the log (nothing has been logged earlier):
Sep 28 15:00:07 mail slapd[2209]: connection_input: conn=14847 deferring operation: too many executing Sep 28 15:00:38 mail slapd[2209]: connection_input: conn=19285 deferring operation: too many executing Sep 28 15:32:46 mail slapd[2209]: connection_input: conn=19419 deferring operation: binding Sep 28 15:32:47 mail slapd[2209]: connection_input: conn=19419 deferring operation: binding Sep 28 15:32:57 mail slapd[4484]: [INFO] Using /etc/default/slapd for configuration Sep 28 15:32:57 mail slapd[4489]: [INFO] Halting OpenLDAP... Sep 28 15:32:57 mail slapd[2209]: daemon: shutdown requested and initiated. Sep 28 15:32:57 mail slapd[2209]: slapd shutdown: waiting for 1 operations/tasks to finish Sep 28 15:33:03 mail slapd[2209]: slapd stopped. Sep 28 15:33:05 mail slapd[4510]: [OK] OpenLDAP stopped after 7 seconds Sep 28 15:33:05 mail slapd[4511]: [INFO] No data backup done Sep 28 15:33:12 mail slapd[4529]: [INFO] Using /etc/default/slapd for configuration Sep 28 15:33:12 mail slapd[4534]: [INFO] Launching OpenLDAP configuration test... Sep 28 15:33:16 mail slapd[4568]: [OK] OpenLDAP configuration test successful Sep 28 15:33:16 mail slapd[4578]: [INFO] No db_recover done Sep 28 15:33:16 mail slapd[4579]: [INFO] Launching OpenLDAP... Sep 28 15:33:16 mail slapd[4580]: [OK] File descriptor limit set to 1024 Sep 28 15:33:17 mail slapd[4581]: @(#) $OpenLDAP: slapd 2.4.31 (Apr 26 2012 19:53:11) $ clement@localhost.localdomain:/home/clement/build/BUILD/openldap-2.4.31/servers/slapd ...
Possibly, a number of parallel group alias uses, caused a large number of LDAP queries by Postfix. Can you please advise on what may have caused OpenLDAP overloading, and on how can we avoid it from happening again? Any config changes?
My config follows.
Thanks in advance for your time and assistance.
Regards, Nick
# cat /usr/local/openldap/var/openldap-data/DB_CONFIG #==================================================================== # BDB configuration # # Provided by LTB-project (http://www.ltb-project.org) #====================================================================
#==================================================================== # Cache size for DB files #==================================================================== set_cachesize 1 0 1
#==================================================================== # Flags #==================================================================== #set_flags DB_TXN_WRITE_NOSYNC #set_flags DB_TXN_NOSYNC set_flags DB_LOG_AUTOREMOVE
#==================================================================== # Logs #==================================================================== # Size set_lg_regionmax 1048576 set_lg_max 10485760 set_lg_bsize 2097152
# Directory set_lg_dir /usr/local/berkeleydb/openldap-logs
# cat /usr/local/openldap/etc/openldap/slapd.conf # include /usr/local/openldap/etc/openldap/schema/core.schema include /usr/local/openldap/etc/openldap/schema/cosine.schema include /usr/local/openldap/etc/openldap/schema/inetorgperson.schema include /usr/local/openldap/etc/openldap/schema/nis.schema include /usr/local/openldap/etc/openldap/schema/eduperson.schema include /usr/local/openldap/etc/openldap/schema/postfix.schema include /usr/local/openldap/etc/openldap/schema/dyngroup.schema include /usr/local/openldap/etc/openldap/schema/misc.schema include /usr/local/openldap/etc/openldap/schema/ppolicy.schema include /usr/local/openldap/etc/openldap/schema/schac-20090326-1.4.0.schema include /usr/local/openldap/etc/openldap/schema/dnsdomain2.schema include /usr/local/openldap/etc/openldap/schema/proftpd-quota.schema include /usr/local/openldap/etc/openldap/schema/kerberos.schema include /usr/local/openldap/etc/openldap/schema/localemail.schema include /usr/local/openldap/etc/openldap/schema/entryaccess.schema
pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args
modulepath /usr/local/openldap/lib64
loglevel sync
sizelimit unlimited timelimit unlimited
TLSCipherSuite HIGH:MEDIUM:+SSLv2
TLSCACertificateFile /usr/local/openldap/etc/openldap/cacerts/chain.pem TLSCertificateFile /usr/local/openldap/etc/openldap/cacerts/cert.pem TLSCertificateKeyFile /usr/local/openldap/etc/openldap/cacerts/key.pem
TLSVerifyClient never
####################################################################### # ldbm and/or bdb database definitions #######################################################################
database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret
######## # ACLs # ######## include /usr/local/openldap/etc/openldap/acl.conf
directory /usr/local/openldap/var/openldap-data
index objectClass eq,pres index employeeType pres,eq index cn eq,pres,sub index sn,givenname eq,pres,sub index mail eq,pres,sub index uid eq,pres index ou eq,pres index mailacceptinggeneralid eq,pres index owner eq index entryCSN,entryUUID eq index vacationActive eq index associatedDomain pres,eq,sub index dc eq index emailLocalAddress eq,pres,sub
overlay dynlist dynlist-attrset nisMailAlias labeledURI dynlist-attrset groupOfURLs labeledURI member
syncrepl rid=111 provider=ldaps://ldap.example.com tls_reqcert=never type=refreshAndPersist retry="60 15 180 +" searchbase="dc=example,dc=com" schemachecking=off bindmethod=simple binddn="uid=FullReplAcc1,ou=System,dc=example,dc=com" credentials="mypassword"
database monitor
access to * by dn.exact="cn=Manager,dc=example,dc=com" read by * none
# ls -la /usr/local/openldap/var/openldap-data/ total 14120 drwxr-xr-x 2 ldap ldap 4096 Sep 28 15:33 . drwxr-xr-x 4 ldap ldap 4096 Apr 26 20:56 .. -rw-r--r-- 1 ldap ldap 4096 Sep 28 15:33 alock -rw------- 1 ldap ldap 1261568 Sep 28 15:32 associatedDomain.bdb -rw------- 1 ldap ldap 512000 Sep 28 15:32 cn.bdb -rw------- 1 ldap ldap 24576 Sep 28 15:33 __db.001 -rw------- 1 ldap ldap 1294336 Sep 28 16:12 __db.002 -rw------- 1 ldap ldap 32776192 Sep 28 16:12 __db.003 -rw------- 1 ldap ldap 3145728 Sep 28 16:11 __db.004 -rw------- 1 ldap ldap 729088 Sep 28 16:12 __db.005 -rw------- 1 ldap ldap 32768 Sep 28 16:11 __db.006 -rw-r--r-- 1 ldap ldap 924 Apr 26 21:01 DB_CONFIG -rw------- 1 ldap ldap 845 Apr 26 20:56 DB_CONFIG.example -rw------- 1 ldap ldap 61440 Sep 28 15:32 dc.bdb -rw------- 1 ldap ldap 339968 Sep 28 15:33 dn2id.bdb -rw------- 1 ldap ldap 212992 Sep 28 15:33 emailLocalAddress.bdb -rw------- 1 ldap ldap 20480 Sep 28 15:33 employeeType.bdb -rw------- 1 ldap ldap 118784 Sep 28 15:33 entryCSN.bdb -rw------- 1 ldap ldap 81920 Sep 28 15:33 entryUUID.bdb -rw------- 1 ldap ldap 90112 Sep 28 15:32 givenName.bdb -rw------- 1 ldap ldap 2457600 Sep 28 15:33 id2entry.bdb -rw------- 1 ldap ldap 24576 Jul 9 13:13 mailacceptinggeneralid.bdb -rw------- 1 ldap ldap 212992 Sep 28 15:33 mail.bdb -rw------- 1 ldap ldap 266240 Sep 28 15:33 objectClass.bdb -rw------- 1 ldap ldap 40960 Sep 28 15:33 ou.bdb -rw------- 1 ldap ldap 8192 Sep 28 15:32 owner.bdb -rw------- 1 ldap ldap 253952 Sep 28 15:32 sn.bdb -rw------- 1 ldap ldap 28672 Sep 28 15:33 uid.bdb -rw------- 1 ldap ldap 8192 Sep 25 2011 vacationActive.bdb
Hi,
try to set sortvals parameter like this:
sortvals uniqueMember
See http://www.openldap.org/lists/openldap-technical/200808/msg00033.html
Clément.
On 28/9/2012 5:08 μμ, Clément OUDOT wrote:
try to set sortvals parameter like this:
sortvals uniqueMember
Thank you for the suggestion. Does this apply to dynamic list attributes too?
For example, in:
dn: cn=allstaff,ou=Aliases,dc=example,dc=com cn: allstaff objectClass: nisMailAlias objectClass: labeledURIObject owner: cn=Admins,ou=Groups,dc=example,dc=com labeledURI: ldap:///ou=People,dc=example,dc=com?uid?one?(&(ou=staff)(!(ou=system))) mailacceptinggeneralid: allstaff@example.com
Can/Should we use: "sortvals uid" ??
Note however that even our dynlists do not have more than 300 members. (It is a small directory as Howard observed.)
Nick
2012/9/28 Nick Milas nick@eurobjects.com:
On 28/9/2012 5:08 μμ, Clément OUDOT wrote:
try to set sortvals parameter like this:
sortvals uniqueMember
Thank you for the suggestion. Does this apply to dynamic list attributes too?
For example, in:
dn: cn=allstaff,ou=Aliases,dc=example,dc=com cn: allstaff objectClass: nisMailAlias objectClass: labeledURIObject owner: cn=Admins,ou=Groups,dc=example,dc=com labeledURI: ldap:///ou=People,dc=example,dc=com?uid?one?(&(ou=staff)(!(ou=system))) mailacceptinggeneralid: allstaff@example.com
Can/Should we use: "sortvals uid" ??
Yes.
Note however that even our dynlists do not have more than 300 members. (It is a small directory as Howard observed.)
So sortvals will maybe not save your life, but it cannot be bad to set it.
Clément.
Nick Milas wrote:
Hi,
I am running a v2.4.31 consumer on CentOS 5.8 to serve user accounts (and aliases) on a Postfix mail server running locally. It has been running for a long time without problems.
Today, after a user sent (on 14:53:39) a mass mail (through a group alias, implemented using ldap dynlist), Postfix stalled and the server (a VM under KVM) became overloaded. I noticed that openldap was using all the cpu:
# top top - 15:30:01 up 81 days, 2:11, 1 user, load average: 113.58, 114.36, 104.02 Tasks: 460 total, 3 running, 457 sleeping, 0 stopped, 0 zombie Cpu(s): 98.9%us, 0.0%sy, 0.0%ni, 0.0%id, 0.0%wa, 1.1%hi, 0.0%si, 0.0%st Mem: 3089988k total, 3074912k used, 15076k free, 12180k buffers Swap: 2064376k total, 92k used, 2064284k free, 1909976k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND2209 ldap 18 0 577m 17m 8952 S 93.4 0.6 55:03.67 slapd ...
Your load average was really 113? I don't see any "threads" setting in your config. By default slapd only uses 16 threads, so by itself it could never drive the load average above 16. Something else is going quite wrong on your system.
Your database looks pretty small. But still, I see no cachesize configuration in it. That might help. Or just switch to MDB and continue to not worry about cache sizes.
database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw secret
######## # ACLs # ######## include /usr/local/openldap/etc/openldap/acl.conf
directory /usr/local/openldap/var/openldap-data
index objectClass eq,pres index employeeType pres,eq index cn eq,pres,sub index sn,givenname eq,pres,sub index mail eq,pres,sub index uid eq,pres index ou eq,pres index mailacceptinggeneralid eq,pres index owner eq index entryCSN,entryUUID eq index vacationActive eq index associatedDomain pres,eq,sub index dc eq index emailLocalAddress eq,pres,sub
overlay dynlist dynlist-attrset nisMailAlias labeledURI dynlist-attrset groupOfURLs labeledURI member
syncrepl rid=111 provider=ldaps://ldap.example.com tls_reqcert=never type=refreshAndPersist retry="60 15 180 +" searchbase="dc=example,dc=com" schemachecking=off bindmethod=simple binddn="uid=FullReplAcc1,ou=System,dc=example,dc=com" credentials="mypassword"
database monitor
access to * by dn.exact="cn=Manager,dc=example,dc=com" read by * none
# ls -la /usr/local/openldap/var/openldap-data/ total 14120 drwxr-xr-x 2 ldap ldap 4096 Sep 28 15:33 . drwxr-xr-x 4 ldap ldap 4096 Apr 26 20:56 .. -rw-r--r-- 1 ldap ldap 4096 Sep 28 15:33 alock -rw------- 1 ldap ldap 1261568 Sep 28 15:32 associatedDomain.bdb -rw------- 1 ldap ldap 512000 Sep 28 15:32 cn.bdb -rw------- 1 ldap ldap 24576 Sep 28 15:33 __db.001 -rw------- 1 ldap ldap 1294336 Sep 28 16:12 __db.002 -rw------- 1 ldap ldap 32776192 Sep 28 16:12 __db.003 -rw------- 1 ldap ldap 3145728 Sep 28 16:11 __db.004 -rw------- 1 ldap ldap 729088 Sep 28 16:12 __db.005 -rw------- 1 ldap ldap 32768 Sep 28 16:11 __db.006 -rw-r--r-- 1 ldap ldap 924 Apr 26 21:01 DB_CONFIG -rw------- 1 ldap ldap 845 Apr 26 20:56 DB_CONFIG.example -rw------- 1 ldap ldap 61440 Sep 28 15:32 dc.bdb -rw------- 1 ldap ldap 339968 Sep 28 15:33 dn2id.bdb -rw------- 1 ldap ldap 212992 Sep 28 15:33 emailLocalAddress.bdb -rw------- 1 ldap ldap 20480 Sep 28 15:33 employeeType.bdb -rw------- 1 ldap ldap 118784 Sep 28 15:33 entryCSN.bdb -rw------- 1 ldap ldap 81920 Sep 28 15:33 entryUUID.bdb -rw------- 1 ldap ldap 90112 Sep 28 15:32 givenName.bdb -rw------- 1 ldap ldap 2457600 Sep 28 15:33 id2entry.bdb -rw------- 1 ldap ldap 24576 Jul 9 13:13 mailacceptinggeneralid.bdb -rw------- 1 ldap ldap 212992 Sep 28 15:33 mail.bdb -rw------- 1 ldap ldap 266240 Sep 28 15:33 objectClass.bdb -rw------- 1 ldap ldap 40960 Sep 28 15:33 ou.bdb -rw------- 1 ldap ldap 8192 Sep 28 15:32 owner.bdb -rw------- 1 ldap ldap 253952 Sep 28 15:32 sn.bdb -rw------- 1 ldap ldap 28672 Sep 28 15:33 uid.bdb -rw------- 1 ldap ldap 8192 Sep 25 2011 vacationActive.bdb
On 28/9/2012 5:14 μμ, Howard Chu wrote:
But still, I see no cachesize configuration in it. That might help.
Hmm, I guess you mean (in DB_CONFIG):
set_cachesize 0 26214400 0
(I figured out that 25 MB would be fine in our case.)
I should also probably add (coz it's missing) in slapd.conf:
checkpoint 64 10
(I think the above would be fine as db changes are small and infrequent.)
Right?
And... when we can put it on schedule, we'll be considering moving to MDB.
Thanks, Nick
Nick Milas wrote:
On 28/9/2012 5:14 μμ, Howard Chu wrote:
But still, I see no cachesize configuration in it. That might help.
Hmm, I guess you mean (in DB_CONFIG):
You sound like someone who has never read slapd-bdb(5).
Right?
And... when we can put it on schedule, we'll be considering moving to MDB.
Hello,
I'm setting up my openldap server and I would like an advice from experimented users.
My domain is dc=mycompany,dc=org
My company will have: - employees - clients - partners
How should I organise my tree ? for example ? o=MyCompany, dc=mycompany,dc=org o=Client1, dc=mycompany,dc=org o=Client2, dc=mycompany,dc=org o=Partner1, dc=mycompany,dc=org
Or can I group clients ? o=Client1, ??=Clients, dc=mycompany,dc=org o=Client2, ??=Clients, dc=mycompany,dc=org What would be "??" if I want to make a group called Clients ?
Or my approach is not good ? If someone has advices (or links that describe a real life case) I'll be more than happy to read them.
Thank you
On 09/28/12 18:40 +0100, Mik J wrote:
Hello,
I'm setting up my openldap server and I would like an advice from experimented users.
My domain is dc=mycompany,dc=org
My company will have:
- employees
- clients
- partners
How should I organise my tree ? for example ? o=MyCompany, dc=mycompany,dc=org o=Client1, dc=mycompany,dc=org o=Client2, dc=mycompany,dc=org o=Partner1, dc=mycompany,dc=org
Or can I group clients ? o=Client1, ??=Clients, dc=mycompany,dc=org o=Client2, ??=Clients, dc=mycompany,dc=org What would be "??" if I want to make a group called Clients ?
Or my approach is not good ? If someone has advices (or links that describe a real life case) I'll be more than happy to read them.
I personally prefer breaking up my DIT by function, rather than by company organization, e.g.:
uid=user1@companydomain1,ou=people,dc=mycompany,dc=org uid=userx@companydomain2,ou=people,dc=mycompany,dc=org cn=mygroup,ou=groups,dc=mycompany,dc=org cn=myalias,ou=aliases,dc=mycompany,dc=org
Then, if I need to restrict an ldap search to one or more organizations, I do so by placing an identifying attribute within the user's entry, and find them with a filter.
Filters are generally a more flexible way to organize your users than a base.
De : Dan White dwhite@olp.net
À : Mik J mikydevel@yahoo.fr
On 09/28/12 18:40 +0100, Mik J wrote:
Hello,
I'm setting up my openldap server and I would like an advice from
experimented users.
My domain is dc=mycompany,dc=org
My company will have:
- employees
- clients
- partners
How should I organise my tree ? for example ? o=MyCompany, dc=mycompany,dc=org o=Client1, dc=mycompany,dc=org o=Client2, dc=mycompany,dc=org o=Partner1, dc=mycompany,dc=org
Or can I group clients ? o=Client1, ??=Clients, dc=mycompany,dc=org o=Client2, ??=Clients, dc=mycompany,dc=org What would be "??" if I want to make a group called Clients ?
Or my approach is not good ? If someone has advices (or links that describe a real life case) I'll be
more than happy to read them.
I personally prefer breaking up my DIT by function, rather than by company organization, e.g.:
uid=user1@companydomain1,ou=people,dc=mycompany,dc=org uid=userx@companydomain2,ou=people,dc=mycompany,dc=org cn=mygroup,ou=groups,dc=mycompany,dc=org cn=myalias,ou=aliases,dc=mycompany,dc=org
Then, if I need to restrict an ldap search to one or more organizations, I do so by placing an identifying attribute within the user's entry, and find them with a filter.
Filters are generally a more flexible way to organize your users than a base.
Hello Dan, Thank you for your advice. I will consider this option seriously. I would also like to hear other people's implementation. Have a nice week
De : Mik J mikydevel@yahoo.fr
À : "openldap-technical@openldap.org" openldap-technical@openldap.org
De : Dan White dwhite@olp.net
À : Mik J mikydevel@yahoo.fr
On 09/28/12 18:40 +0100, Mik J wrote:
Hello,
I'm setting up my openldap server and I would like an advice from
experimented users.
My domain is dc=mycompany,dc=org
My company will have:
- employees
- clients
- partners
How should I organise my tree ? for example ? o=MyCompany, dc=mycompany,dc=org o=Client1, dc=mycompany,dc=org o=Client2, dc=mycompany,dc=org o=Partner1, dc=mycompany,dc=org
Or can I group clients ? o=Client1, ??=Clients, dc=mycompany,dc=org o=Client2, ??=Clients, dc=mycompany,dc=org What would be "??" if I want to make a group called Clients ?
Or my approach is not good ? If someone has advices (or links that describe a real life case)
I'll be
more than happy to read them.
I personally prefer breaking up my DIT by function, rather than by company organization, e.g.:
uid=user1@companydomain1,ou=people,dc=mycompany,dc=org uid=userx@companydomain2,ou=people,dc=mycompany,dc=org cn=mygroup,ou=groups,dc=mycompany,dc=org cn=myalias,ou=aliases,dc=mycompany,dc=org
Then, if I need to restrict an ldap search to one or more organizations, I do so by placing an identifying attribute within the user's entry, and
find
them with a filter.
Filters are generally a more flexible way to organize your users than a base.
Hello Dan, Thank you for your advice. I will consider this option seriously. I would also like to hear other people's implementation. Have a nice week
Hello Dan,I've started to think about your way to implement this and I've notice that having a uid that looks like an email address is mandatory to achieve what I want. Right now my uids don't look like an email address but more like one_letter+family name Because you use emails as uids and you do filtering based on regex applied to emails, do you need groups ? Thank you
On 10/01/12 20:12 +0100, Mik J wrote:
De : Dan White dwhite@olp.net
I personally prefer breaking up my DIT by function, rather than by company organization, e.g.:
uid=user1@companydomain1,ou=people,dc=mycompany,dc=org uid=userx@companydomain2,ou=people,dc=mycompany,dc=org cn=mygroup,ou=groups,dc=mycompany,dc=org cn=myalias,ou=aliases,dc=mycompany,dc=org
Then, if I need to restrict an ldap search to one or more organizations, I do so by placing an identifying attribute within the user's entry, and find them with a filter.
Filters are generally a more flexible way to organize your users than a base.
Hello Dan,I've started to think about your way to implement this and I've notice that having a uid that looks like an email address is mandatory to achieve what I want. Right now my uids don't look like an email address but more like one_letter+family name Because you use emails as uids and you do filtering based on regex applied to emails, do you need groups ?
I maintain ldap groups to store unix group membership, and for ACL enforcement.
I do not typically use groups for user authentication and authorization.
openldap-technical@openldap.org
-
Clément OUDOT -
Dan White -
Howard Chu -
Mik J -
Nick Milas