openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

How to let users change passwords
by robert k Wild 24 Aug '15

24 Aug '15

Hi all, I have an openldap server (centos 6.6) and created a user account and given the user a generic password eg "password123" when my end user logs in there client (centos 6.6) How can i give them an option if they want to, to change their own password or for them to change their password when they login Many thanks Rob -- Regards, Robert K Wild.

1 0

How can I Modify OpenLdap database?
by Jason Long 22 Aug '15

22 Aug '15

Hello. I added some entries to OpenLdap but I want edit them. How can I do it? my "slapcat" output is : # slapcat 55d45334 ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif" 55d45334 ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif" 55d45334 The first database does not allow slapcat; using the first available one (2) 55d45334 hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "dc=linux,dc=dj". dn: dc=linux-d,dc=j objectClass: dcObject objectClass: organization dc: linux-d o: linux-d structuralObjectClass: organization entryUUID: 1c4fa7b0-da8c-1034-91a3-f90dc6355c19 creatorsName: cn=Manager,dc=linux-d,dc=j createTimestamp: 20150819070316Z entryCSN: 20150819070316.921292Z#000000#000#000000 modifiersName: cn=Manager,dc=linux-d,dc=j modifyTimestamp: 20150819070316Z dn: ou=Users,dc=linux-d,dc=j objectClass: organizationalUnit ou: Users structuralObjectClass: organizationalUnit entryUUID: c3dbe28c-da8c-1034-91a4-f90dc6355c19 creatorsName: cn=Manager,dc=linux-d,dc=j createTimestamp: 20150819070758Z entryCSN: 20150819070758.019816Z#000000#000#000000 modifiersName: cn=Manager,dc=linux-d,dc=j modifyTimestamp: 20150819070758Z I want to change "linux-d" to "linux". I edited "/tmp/users.ldif" file and used "ldapmodify -a -D cn=Manager,dc=linux,dc=dj -w hack3rcon -f /tmp/users.ldif" but "slapcat" output still is : slapcat 55d4568e ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={1}monitor.ldif" 55d4568e ldif_read_file: checksum error on "/etc/openldap/slapd.d/cn=config/olcDatabase={2}hdb.ldif" 55d4568e The first database does not allow slapcat; using the first available one (2) 55d4568e hdb_db_open: warning - no DB_CONFIG file found in directory /var/lib/ldap: (2). Expect poor performance for suffix "dc=linux,dc=dj". dn: dc=linux-d,dc=j objectClass: dcObject objectClass: organization dc: linux-d o: linux-d structuralObjectClass: organization entryUUID: 1c4fa7b0-da8c-1034-91a3-f90dc6355c19 creatorsName: cn=Manager,dc=linux-d,dc=j createTimestamp: 20150819070316Z entryCSN: 20150819070316.921292Z#000000#000#000000 modifiersName: cn=Manager,dc=linux-d,dc=j modifyTimestamp: 20150819070316Z dn: ou=Users,dc=linux-d,dc=j objectClass: organizationalUnit ou: Users structuralObjectClass: organizationalUnit entryUUID: c3dbe28c-da8c-1034-91a4-f90dc6355c19 creatorsName: cn=Manager,dc=linux-d,dc=j createTimestamp: 20150819070758Z entryCSN: 20150819070758.019816Z#000000#000#000000 modifiersName: cn=Manager,dc=linux-d,dc=j modifyTimestamp: 20150819070758Z dn: dc=linux,dc=dj objectClass: dcObject objectClass: organization dc: linux o: linux structuralObjectClass: organization entryUUID: e1968706-daa4-1034-82a7-470596994b9c creatorsName: cn=Manager,dc=linux,dc=dj createTimestamp: 20150819100035Z entryCSN: 20150819100035.818429Z#000000#000#000000 modifiersName: cn=Manager,dc=linux,dc=dj modifyTimestamp: 20150819100035Z dn: ou=Users,dc=linux,dc=dj objectClass: organizationalUnit ou: Users structuralObjectClass: organizationalUnit entryUUID: 2a1a366c-daa5-1034-82a8-470596994b9c creatorsName: cn=Manager,dc=linux,dc=dj createTimestamp: 20150819100237Z entryCSN: 20150819100237.477397Z#000000#000#000000 modifiersName: cn=Manager,dc=linux,dc=dj modifyTimestamp: 20150819100237Z As you see, I have "linux-d" . How can I solve it?

2 5

OLC ppolicy
by Jeremy Trammell - DLA 22 Aug '15

22 Aug '15

Greetings, I'm trying to set up a very simple LDAP server using OpenLDAP (via OLC) and it seems hopeless. The sticking point is ppolicy. I have followed several online guides (http://www.ryanfrantz.com/posts/openldap-implementing-the-password-policy-o…, https://www.oostergo.net/node/85, to name a few), all of which seem to essentially detail the same procedure, and have met with no success. Whilst following those instructions, I receive no error messages. All commands complete successfully and do not indicate failures of any kind. Looking at the cn=config and target DITs, all data seems to have been imported as expected. Despite that fact, passwd follows a "mystery policy" which bears no resemblance to the policy that I have specified, and ldappasswd follows "no policy at all you can do whatever you want". Is there some way for me to empirically determine what these commands are doing, and why my policy does nothing? Thanks in advance... cn=module{0},cn=config > objectClass: olcModuleList > cn: module{0} > olcModuleLoad: {0}ppolicy.la > olcModuleLoad: {1}back_hdb > olcModuleLoad: {2}ppolicy > olcModulePath: /usr/lib/ldap olcDatabase={1}hdb,cn=config > objectClass: olcDatabaseConfig > objectClass: olcHdbConfig > olcDatabase: {1}hdb > olcDbDirectory: /var/lib/ldap > olcAccess: {0}to attrs=userPassword,shadowLastChange by self write by > anonymous auth by dn="cn=admin,dc=dla" write by * none > olcAccess: {1}to dn.base="" by * read > olcAccess: {2}to * by self write by dn="cn=admin,dc=dla" write by * read > olcDbCheckpoint: 512 30 > olcDbConfig: {0}set_cachesize 0 2097152 0 > olcDbConfig: {1}set_lk_max_objects 1500 > olcDbConfig: {2}set_lk_max_locks 1500 > olcDbConfig: {3}set_lk_max_lockers 1500 > olcDbIndex: objectClass eq > olcLastMod: TRUE > olcSuffix: dc=dla olcOverlay={0}ppolicy,olcDatabase={1}hdb,cn=config > objectClass: olcOverlayConfig > objectClass: olcPPolicyConfig > olcOverlay: {0}ppolicy > olcPPolicyDefault: cn=passwordDefault,ou=policies,dc=dla > olcPPolicyForwardUpdates: FALSE > olcPPolicyHashCleartext: TRUE > olcPPolicyUseLockout: FALSE cn=passwordDefault,ou=policies,dc=dla > objectClass: person > objectClass: pwdPolicy > objectClass: pwdPolicyChecker > objectClass: top > cn: passwordDefault > pwdAttribute: 2.5.4.35 > sn: passwordDefault > pwdMinLength: 12

3 5

Multi-master syncrepl config: excluding olcSaslHost from replication
by Kyle Brantley 21 Aug '15

21 Aug '15

I'm working on a full multi-master slapd setup, where both the cn=config database as well as the actual database are fully replicated. All access to the slapd instances is gated with GSSAPI (the only notable exception being the syncrepl users, which I'm working on converting over to GSSAPI anyway). However, I need to be able to configure olcSaslHost on a per-server basis. Server A will have a different value for olcSaslHost than server B will. While I want to replicate cn=config, I don't want to replicate the olcSaslHost attribute. I've tried two things, and neither have worked: 1) Configuring exattrs="olcSaslHost" in the olcSyncrepl statements for cn=config. * This allows me to configure the attribute, but as soon as there is any other change to cn=config, it wipes the attribute out across all of the nodes. 2) Updating the ACL for the syncrepl user to not have access to the olcSaslHost attribute. * Unfortunately, this has similar behavior to the above: making a change on one node will wipe the olcSaslHost attribute out of all of the nodes. How best can I go about doing this? I was hoping that olcSaslRealm was multi-value and could be configured in a manner similar to olcServerID, but that isn't the case. I was hoping that denying access to the attributes (via ACL or olcSynrepl config) would make the syncrepl engine ignore the attribute, but because it can't see it on the node where the attribute was changed, but it can see it on the downstream nodes, it wipes the attribute out entirely. Any help / suggestions welcome. Thanks, --Kyle

3 2

Segmentation fault when overwriting a k/v with MDB_RESERVE ?
by Simon Majou 21 Aug '15

21 Aug '15

Hello, I wonder, why do I get a Segmentation fault when I use mdb_put with MDB_RESERVE on a key that already exists ? -- Best regards, Simon Majou

2 9

ClearText Passwords in slapcat: please provide some inputs
by Manuel Afonso 21 Aug '15

21 Aug '15

Hi people, I am using ubuntu and phpldapadmin to manage openldap. I have here a big issue: when using phpldapadmin/openldap, all the times there is (for each user/entry) a field with cleartextPassword: <cleartextpassword> (this is seen in slapcat output) What I want is to put in place a mechanism where there is no plain text field with the password in clear in each entry of openldap. I have read about ppolicy overlay, slappasswd and so on but so far I was not able to figure out how to avoid this annoying clear text password available when I do a slapcat (as root of course) Does anybody had such an issue ? Any ideas or links to point for a solution? Another question: is it possible that this clear text password is somehow needed for the correct operation of openldap? Thanks a lot for your time and (I hope) help. Kind regards, Manuel - Lisbon PT This is what I got for the user mafonso (me) when doing a slapcat > output : (as can be seen there is the field cleartextPassword: with pass in clear text) dn: cn=mafonso,ou=***,dc=***,dc=***,dc=***,dc=pt objectClass: ****Person objectClass: mailAccount objectClass: sambaSamAccount objectClass: posixAccount objectClass: top givenName: Manuel sn: Afonso displayName: Manuel Afonso cn: mafonso mailacceptinguser: 1 maildrop: mafonso(a)***.pt intranetRole: cn=**,ou=**,ou=**,dc=**,dc=**,dc=**,dc=pt ... portalRole: *** ... gidNumber: 516 sambaSID: *** uidNumber: 1399 uid: mafonso homeDirectory: /home/mafonso intranetStatus: U sambaAcctFlags: [UX] loginShell: /bin/false mailacceptinggeneralid: mafonso@**** mailacceptinggeneralid: ***(a)**.**.**.pt userPassword:: e1N.... cleartextPassword: <cleartextpassword> sambaNTPassword: D6... sambaLMPassword: 45...

3 2

LDAP over SSL ( ldaps )
by Aneela Saleem 20 Aug '15

20 Aug '15

Hi all, Can anyone please provide me some link for enabling "ldaps" i have followed many links but continuously failing to do so. I have also tried "startTLS" but its not compatible with Apache Knox. Any help would be appreciated. Thanks

5 28

Re: Slapd is coming down
by Édnei Rodrigues 20 Aug '15

20 Aug '15

Hello quanah! Yes, I know, my SO killed the slapd because it was configured. But I don't have any other service in the server, only the openldap. Quanah, below follow the information: - Openldap-syncrepl: 2 GB - Openldap-translucent: 567 MB Now, about the slapd process. The strange is the size in the memory: - Server 1 Tasks: 110 total, 1 running, 109 sleeping, 0 stopped, 0 zombie Cpu(s): 0.3%us, 0.3%sy, 0.0%ni, 99.2%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 12248128k total, 5686580k used, 6561548k free, 223244k buffers Swap: 2097148k total, 88940k used, 2008208k free, 4488408k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4965 ldap 20 0 4692m 777m 527m S 1.0 6.5 101:16.12 slapd 1460 ldap 20 0 9700m 2.1g 1.9g S 0.3 18.0 1174:58 slapd ldap 1460 1 2 Jul12 ? 19:34:58 /usr/local/openldap/libexec/slapd -h ldap://127.0.0.1:1389 ldaps:// 127.0.0.1:1636 -f /usr/local/openldap/etc/openldap/slapd-syncrepl.conf -u ldap -g ldap -l local3 ldap 4965 1 10 Aug19 ? 01:41:19 /usr/local/openldap/libexec/slapd -h ldap://*:389 ldaps://*:636 -f /usr/local/openldap/etc/openldap/slapd.conf -u ldap -g ldap -l local4 root 14399 14157 0 09:12 pts/0 00:00:00 grep ldap - Server 2 Tasks: 113 total, 1 running, 112 sleeping, 0 stopped, 0 zombie Cpu(s): 0.0%us, 0.2%sy, 0.0%ni, 99.7%id, 0.2%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 12194476k total, 8111400k used, 4083076k free, 213632k buffers Swap: 2097148k total, 7344k used, 2089804k free, 7225108k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 30907 ldap 20 0 8832m 2.3g 2.2g S 0.0 19.9 11:10.55 slapd 30956 ldap 20 0 4486m 502m 339m S 0.0 4.2 7:34.95 slapd ldap 30907 1 1 Aug19 ? 00:11:10 /usr/local/openldap/libexec/slapd -h ldap://127.0.0.1:1389 ldaps:// 127.0.0.1:1636 -f /usr/local/openldap/etc/openldap/slapd-syncrepl.conf -u ldap -g ldap -l local3 ldap 30956 1 0 Aug19 ? 00:07:39 /usr/local/openldap/libexec/slapd -h ldap://*:389 ldaps://*:636 -f /usr/local/openldap/etc/openldap/slapd.conf -u ldap -g ldap -l local4 Otherwise, in the few days, the slapd process increase the consumption until remain nothing! And it is the why the oom-killer kill the slapd, because your bad score. Why is the slapd consuming many memory? Do you need more information? Thank you! Em 19/08/2015 14:11, "Quanah Gibson-Mount" <quanah(a)zimbra.com> escreveu: > --On Wednesday, August 19, 2015 2:39 PM -0300 Édnei Rodrigues < > ednei.felipe.rodrigues(a)gmail.com> wrote: > > >> Hello Guys, how are you doing ? >> > > Aug 19 09:51:44 ds1openldap2h kernel: Out of memory: Kill process 21760 >> (slapd) score 957 or sacrifice child >> Aug 19 09:51:44 ds1openldap2h kernel: Killed process 21760, UID 55, >> (slapd) total-vm:18314360kB, anon-rss:11646816kB, file-rss:680kB >> > > Your OS killed it, slapd didn't "come down". You don't give any useful > information, so it's hard to provide guidance. I've often seen this when > other processes (particularly java based) are using up memory, and slapd > goes to alloc new memory, so the OS kills it. Useful details besides your > version (2.4.39, per the log) would be: > > database backend > database size > slapd process size after DB is fully in memory > > etc > > --Quanah > > > -- > > Quanah Gibson-Mount > Platform Architect > Zimbra, Inc. > -------------------- > Zimbra :: the leader in open source messaging and collaboration >

2 1

ACL rule: getting crazy with it.
by Simone Taliercio 20 Aug '15

20 Aug '15

Hi All, I've Jasig CAS connected to OpenLDAP for users authentication. My LDAP Schema is the following: dc=com dc=companyA,dc=com ou=user,dc=companyA,dc=com dc=companyB,dc=com ou=user,dc=companyB,dc=com I would like to give to a specific user (cn=admin,ou=user,dc=companyB,dc=com) the ability to create inetOrgPerson objetcs under ou=user,dc=companyA,dc=com and the restriction to have only search access to ou=user,dc=companyB,dc=com where actually some attributes should be hidden (such as userPassword). I tried several ACL but always with one strange problem: a user is able to login via CAS. Then, he/she logouts and if try with a different account then LDAP returns DN_RESOLUTION_FAILURE. That issue is occurring even with a simple ACL such as: access to * by self write by anonymous auth by users search The only way to workaround that issue is removing any ACL or leaving "by users read". As DN bind I'm using dc=com. Any suggestion? I cannot understand if focusing on CAS for this issue, or ACL LDAP side. Thanks a LOT for the support! Simone

2 2

Slapd is coming down
by Édnei Rodrigues 19 Aug '15

19 Aug '15

Hello Guys, how are you doing ? In the last weeks, my openldaps servers were suffering with many come down. I have a peak about the 400 connections per peer ( We have 2 ldap servers ). Although I has added more memory (4 GB), the problem decreased, but not resolved. So, How Could I troubleshooting it ? My enviroment: - Two Red Hat Enterprise Linux Server release 6.6 (Santiago) - Two processors and 12 GB of RAM - Both environments are virtualized. *************************************** My slapd.conf: moduleload back_ldap moduleload translucent moduleload dynlist moduleload back_monitor backend mdb backend ldap allow bind_v2 allow bind_anon_dn database mdb directory /usr/local/openldap/var/openldap-translucent suffix "*****" rootdn "*************" rootpw **************************** maxsize 4294967296 sizelimit 100000 overlay translucent uri "ldap://localhost:1389/" translucent_bind_local on translucent_pwmod_local on translucent_local ****************************** idassert-bind bindmethod=none overlay dynlist dynlist-attrset groupOfURLs memberURL member:uniqueMember ************************** My slapd-syncrepl.conf: allow bind_v2 allow bind_anon_dn moduleload syncprov moduleload dynlist # Definicoes da base primaria database mdb suffix "**" rootdn "******" directory /usr/local/openldap/var/openldap-syncrepl rootpw ****** sizelimit 100000 maxsize 8589934592 overlay dynlist dynlist-attrset groupOfURLs memberURL member:uniqueMember loglevel sync stats idletimeout 0 # ACLs include /usr/local/openldap/etc/openldap/schema/sicredi.acl overlay syncprov # Começo do Consumidor index entryUUID eq # syncrepl directives syncrepl rid=0 provider=ldap://MASTER_Production:389 bindmethod=simple binddn="************" credentials=**** searchbase="****" logbase="cn=accesslog" logfilter="(&(objectClass=auditWriteObject)(reqResult=0))" type=refreshAndPersist retry="60 +" syncdata=accesslog # Refer updates to the master updateref ldap://MASTER_Production:389 ***** My openldap version: openldap-ltb-2.4.39-1.el6.x86_64 And What I saw in the logs: Aug 19 09:51:43 ds1openldap2h kernel: slapd invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0 Aug 19 09:51:43 ds1openldap2h kernel: slapd cpuset=/ mems_allowed=0 Aug 19 09:51:43 ds1openldap2h kernel: Pid: 4233, comm: slapd Not tainted 2.6.32-504.23.4.el6.x86_64 #1 Aug 19 09:51:43 ds1openldap2h kernel: Call Trace: Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff810d4241>] ? cpuset_print_task_mems_allowed+0x91/0xb0 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff81127500>] ? dump_header+0x90/0x1b0 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff8122ee7c>] ? security_real_capable_noaudit+0x3c/0x70 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff81127982>] ? oom_kill_process+0x82/0x2a0 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff811278c1>] ? select_bad_process+0xe1/0x120 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff81127dc0>] ? out_of_memory+0x220/0x3c0 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff811346ff>] ? __alloc_pages_nodemask+0x89f/0x8d0 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff8116c9aa>] ? alloc_pages_current+0xaa/0x110 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff811248f7>] ? __page_cache_alloc+0x87/0x90 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff811242de>] ? find_get_page+0x1e/0xa0 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff81125897>] ? filemap_fault+0x1a7/0x500 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff8114ed04>] ? __do_fault+0x54/0x530 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff8114f2d7>] ? handle_pte_fault+0xf7/0xb00 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff8109ec20>] ? autoremove_wake_function+0x0/0x40 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff8114ff79>] ? handle_mm_fault+0x299/0x3d0 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff8104d096>] ? __do_page_fault+0x146/0x500 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff81529a1e>] ? thread_return+0x4e/0x7d0 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff8153001e>] ? do_page_fault+0x3e/0xa0 Aug 19 09:51:44 ds1openldap2h kernel: [<ffffffff8152d3d5>] ? page_fault+0x25/0x30 Aug 19 09:51:44 ds1openldap2h kernel: Mem-Info: Aug 19 09:51:44 ds1openldap2h kernel: Node 0 DMA per-cpu: Aug 19 09:51:44 ds1openldap2h kernel: CPU 0: hi: 0, btch: 1 usd: 0 Aug 19 09:51:44 ds1openldap2h kernel: CPU 1: hi: 0, btch: 1 usd: 0 Aug 19 09:51:44 ds1openldap2h kernel: Node 0 DMA32 per-cpu: Aug 19 09:51:44 ds1openldap2h kernel: CPU 0: hi: 186, btch: 31 usd: 0 Aug 19 09:51:44 ds1openldap2h kernel: CPU 1: hi: 186, btch: 31 usd: 0 Aug 19 09:51:44 ds1openldap2h kernel: Node 0 Normal per-cpu: Aug 19 09:51:44 ds1openldap2h kernel: CPU 0: hi: 186, btch: 31 usd: 10 Aug 19 09:51:44 ds1openldap2h kernel: CPU 1: hi: 186, btch: 31 usd: 0 Aug 19 09:51:44 ds1openldap2h kernel: active_anon:2571953 inactive_anon:399686 isolated_anon:0 Aug 19 09:51:44 ds1openldap2h kernel: active_file:305 inactive_file:604 isolated_file:0 Aug 19 09:51:44 ds1openldap2h kernel: unevictable:0 dirty:1 writeback:0 unstable:0 Aug 19 09:51:44 ds1openldap2h kernel: free:29811 slab_reclaimable:2307 slab_unreclaimable:7010 Aug 19 09:51:44 ds1openldap2h kernel: Node 0 DMA free:15276kB min:80kB low:100kB high:120kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:14884kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes Aug 19 09:51:44 ds1openldap2h kernel: lowmem_reserve[]: 0 3000 12090 12090 Aug 19 09:51:44 ds1openldap2h kernel: Node 0 DMA32 free:53124kB min:16748kB low:20932kB high:25120kB active_anon:2127764kB inactive_anon:559804kB active_file:0kB inactive_file:152kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:3072096kB mlocked:0kB dirty:0kB writeback:0kB mapped:128kB shmem:0kB slab_reclaimable:8kB slab_unreclaimable:12kB kernel_stack:0kB pagetables:900kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Aug 19 09:51:44 ds1openldap2h kernel: lowmem_reserve[]: 0 0 9090 9090 Aug 19 09:51:44 ds1openldap2h kernel: Node 0 Normal free:51016kB min:50752kB low:63440kB high:76128kB active_anon:8160048kB inactive_anon:1038940kB active_file:1224kB inactive_file:2052kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:9308160kB mlocked:0kB dirty:4kB writeback:0kB mapped:1288kB shmem:0kB slab_reclaimable:9220kB slab_unreclaimable:28028kB kernel_stack:1392kB pagetables:44504kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no Aug 19 09:51:44 ds1openldap2h kernel: lowmem_reserve[]: 0 0 0 0 Aug 19 09:51:44 ds1openldap2h kernel: Node 0 DMA: 1*4kB 1*8kB 2*16kB 2*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 3*4096kB = 15276kB Aug 19 09:51:44 ds1openldap2h kernel: Node 0 DMA32: 2599*4kB 1163*8kB 354*16kB 75*32kB 28*64kB 15*128kB 9*256kB 12*512kB 9*1024kB 0*2048kB 1*4096kB = 53236kB Aug 19 09:51:44 ds1openldap2h kernel: Node 0 Normal: 846*4kB 640*8kB 413*16kB 236*32kB 119*64kB 48*128kB 28*256kB 10*512kB 2*1024kB 0*2048kB 0*4096kB = 50760kB Aug 19 09:51:44 ds1openldap2h kernel: 5598 total pagecache pages Aug 19 09:51:44 ds1openldap2h kernel: 4605 pages in swap cache Aug 19 09:51:44 ds1openldap2h kernel: Swap cache stats: add 1173695, delete 1169090, find 121530/123860 Aug 19 09:51:44 ds1openldap2h kernel: Free swap = 0kB Aug 19 09:51:44 ds1openldap2h kernel: Total swap = 2097148kB Aug 19 09:51:44 ds1openldap2h kernel: 3145712 pages RAM Aug 19 09:51:44 ds1openldap2h kernel: 97157 pages reserved Aug 19 09:51:44 ds1openldap2h kernel: 797 pages shared Aug 19 09:51:44 ds1openldap2h kernel: 3014707 pages non-shared Aug 19 09:51:44 ds1openldap2h kernel: [ pid ] uid tgid total_vm rss cpu oom_adj oom_score_adj name Aug 19 09:51:44 ds1openldap2h kernel: [ 441] 0 441 2795 0 0 -17 -1000 udevd Aug 19 09:51:44 ds1openldap2h kernel: [ 1251] 0 1251 47346 150 0 0 0 vmtoolsd Aug 19 09:51:44 ds1openldap2h kernel: [ 1290] 0 1290 23283 37 1 -17 -1000 auditd Aug 19 09:51:44 ds1openldap2h kernel: [ 1326] 65 1326 107809 573 1 0 0 nslcd Aug 19 09:51:44 ds1openldap2h kernel: [ 1340] 0 1340 62279 388 1 0 0 rsyslogd Aug 19 09:51:44 ds1openldap2h kernel: [ 1353] 0 1353 2707 46 0 0 0 irqbalance Aug 19 09:51:44 ds1openldap2h kernel: [ 1369] 32 1369 4744 15 1 0 0 rpcbind Aug 19 09:51:44 ds1openldap2h kernel: [ 1380] 81 1380 5881 36 1 0 0 dbus-daemon Aug 19 09:51:44 ds1openldap2h kernel: [ 1413] 0 1413 1020 0 1 0 0 acpid Aug 19 09:51:44 ds1openldap2h kernel: [ 1423] 68 1423 10041 151 0 0 0 hald Aug 19 09:51:44 ds1openldap2h kernel: [ 1424] 0 1424 5100 2 1 0 0 hald-runner Aug 19 09:51:44 ds1openldap2h kernel: [ 1456] 0 1456 5630 2 1 0 0 hald-addon-inpu Aug 19 09:51:44 ds1openldap2h kernel: [ 1470] 68 1470 4502 2 1 0 0 hald-addon-acpi Aug 19 09:51:44 ds1openldap2h kernel: [ 1510] 55 1510 2488944 50131 1 0 0 slapd Aug 19 09:51:44 ds1openldap2h kernel: [ 1572] 28 1572 241540 244 1 0 0 nscd Aug 19 09:51:44 ds1openldap2h kernel: [ 1597] 0 1597 16081 20 1 -17 -1000 sshd Aug 19 09:51:44 ds1openldap2h kernel: [ 1606] 38 1606 6566 72 1 0 0 ntpd Aug 19 09:51:44 ds1openldap2h kernel: [ 1629] 0 1629 28188 2 0 0 0 abrtd Aug 19 09:51:44 ds1openldap2h kernel: [ 1637] 0 1637 28131 23 1 0 0 abrt-dump-oops Aug 19 09:51:44 ds1openldap2h kernel: [ 1651] 0 1651 51804 2959 1 0 0 osad Aug 19 09:51:44 ds1openldap2h kernel: [ 1661] 0 1661 28742 18 1 0 0 crond Aug 19 09:51:44 ds1openldap2h kernel: [ 1771] 497 1771 257947 665 1 0 0 icinga2 Aug 19 09:51:44 ds1openldap2h kernel: [ 1795] 0 1795 25232 26 1 0 0 rhnsd Aug 19 09:51:44 ds1openldap2h kernel: [ 1804] 0 1804 27085 23 0 0 0 rhsmcertd Aug 19 09:51:44 ds1openldap2h kernel: [ 1818] 0 1818 1016 1 0 0 0 mingetty Aug 19 09:51:44 ds1openldap2h kernel: [ 1820] 0 1820 1016 1 0 0 0 mingetty Aug 19 09:51:44 ds1openldap2h kernel: [ 1822] 0 1822 1016 1 0 0 0 mingetty Aug 19 09:51:44 ds1openldap2h kernel: [ 1824] 0 1824 1016 1 0 0 0 mingetty Aug 19 09:51:44 ds1openldap2h kernel: [ 1826] 0 1826 1016 1 0 0 0 mingetty Aug 19 09:51:44 ds1openldap2h kernel: [ 1828] 0 1828 2794 0 1 -17 -1000 udevd Aug 19 09:51:44 ds1openldap2h kernel: [ 1829] 0 1829 2794 0 1 -17 -1000 udevd Aug 19 09:51:44 ds1openldap2h kernel: [ 1830] 0 1830 1016 1 0 0 0 mingetty Aug 19 09:51:44 ds1openldap2h kernel: [21760] 55 21760 4578590 2911874 1 0 0 slapd Aug 19 09:51:44 ds1openldap2h kernel: [16962] 0 16962 3105 113 1 0 0 nmon_x86_64_rhe Aug 19 09:51:44 ds1openldap2h kernel: [20314] 0 20314 3059 113 0 0 0 nmon_x86_64_rhe Aug 19 09:51:44 ds1openldap2h kernel: Out of memory: Kill process 21760 (slapd) score 957 or sacrifice child Aug 19 09:51:44 ds1openldap2h kernel: Killed process 21760, UID 55, (slapd) total-vm:18314360kB, anon-rss:11646816kB, file-rss:680kB Thanks for your attention. -- Atenciosamente, Édnei Rodrigues

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical