openldap-technical

openldap-technical@openldap.org

24 participants
9804 discussions

How do tool verify certs with ldapi:// ?
by Peter Marschall 28 May '12

28 May '12

Hi, how do the openldap tools technically verfify certificates with ldapi:// ? With ldapi, you don't have a hostname or IP address, so how do the openldap tools do it? I tried to browse the code but got losat somewhere ion the way. Any hints to the code or a short step-by-step explanation will help. Background of this question: I want to implement the feature in perl-ldap. Thanks in advance for your help Peter -- Peter Marschall peter(a)adpm.de

3 13

Re: how can make slave use tls to connect to master for syncrepl (solved)
by zhong ming wu 28 May '12

28 May '12

Never mind. I had to put this line in the sysrepl section of the slave starttls=yes Sorry about the noise. On Sun, May 27, 2012 at 10:29 PM, zhong ming wu <mr.z.m.wu(a)gmail.com> wrote: > Hello > > I am using version 2.4 and in the process of setting up a master/slave > pair using syncrepl. > > This is working as expected if I don't have enforce security and > confidentiality with "security ssf=128" global directive in the > master. > As soon as I turn it on, replication stops working. > > It seems that the slave consumer is not using TLS to connect to > master. However I can use 'ldapsearch' with '-ZZ' option to connect > to master from slave and get all records I want. > > On my slave machine, I also have the following directive > > TLS_CACERT /etc/pki/tls/certs/ca.crt.crl > > in ldap.conf > > Notice that without this line 'ldapXXX' commands with '-ZZ' fails from > slave to master. This confirms that at least 'ldap.conf' is in the > correct location at least as far as 'ldapXXX' commands are concerned. > > Can someone point me in the right direction? I have read many > chapters on this page > > http://www.openldap.org/doc/admin24/index.html > > Both slave and master are on centos 6.2 and openldap software is > standard centos rpm. > > Here are the log entries on the master when slave fails to bind with TLS > > May 27 22:14:53 cat slapd[2456]: conn=1000 fd=13 ACCEPT from > IP=192.168.0.2:41083 (IP=0.0.0.0:389) > May 27 22:14:53 cat slapd[2456]: conn=1000 op=0 BIND > dn="cn=root,dc=example,dc=com" method=128 > May 27 22:14:53 cat slapd[2456]: conn=1000 op=0 RESULT tag=97 err=13 > text=confidentiality required > May 27 22:14:53 cat slapd[2456]: conn=1000 op=1 UNBIND > May 27 22:14:53 cat slapd[2456]: conn=1000 fd=13 closed > > Sincerely > > Mr Wu

1 0

OpenLDAP proxy to Active Directory
by Jonathan van der Wat 28 May '12

28 May '12

Greetings, I'm new to OpenLDAP and am trying to implement the following: User authentication (PAM + SSSD) on CentOS Linux servers via OpenLDAP proxy to Active Directory. I am able to perform the following search from the OpenLDAP proxy without any apparent issues: * [root@openldap ~]# ldapsearch -x -h /mydomaincontroller/ -LLL -b dc=msad,dc=inet,dc=com -D cn=ldap,cn=users,dc=msad,dc=inet,dc=com -W '(sAMAccountName=jonathanv)' cn sAMAccountName Enter LDAP Password: dn: CN=jonathan,CN=Users,DC=msad,DC=inet,DC=com cn: jonathan sAMAccountName: jonathanv # refldap://ForestDnsZones.msad.inet.com/DC=ForestDnsZones,DC=msad,DC=inet,DC… # refldap://DomainDnsZones.msad.inet.com/DC=DomainDnsZones,DC=msad,DC=inet,DC… # refldap://msad.inet.com/CN=Configuration,DC=msad,DC=inet,DC=com* However, when asking the OpenLDAP proxy: *[root@openldap ~]# ldapsearch -x -h /localhost/ -LLL -b dc=msad,dc=inet,dc=com -D cn=ldap,cn=users,dc=msad,dc=inet,dc=com -W '(sAMAccountName=jonathanv)' cn sAMAccountName Enter LDAP Password: # refldap://ForestDnsZones.msad.inet.com/DC=ForestDnsZones,DC=msad,DC=inet,DC… # refldap://DomainDnsZones.msad.inet.com/DC=DomainDnsZones,DC=msad,DC=inet,DC… # refldap://msad.inet.com/CN=Configuration,DC=msad,DC=inet,DC=com* Also, I've configured my CentOS server's using SSSD. When trying to authenticate as user jonathanv, I receive a message that user jonathanv is not found. I am using OpenLDAP server version 2.4.23-20. I am starting the OpenLDAP from the command line as follows: *slapd -f -d 2 -f /etc/openldap/slapd.conf -g ldap -h ldap:/// -l LOCAL4 -u ldap -n slapd-ldap* Here is the output of my slapd.conf file: *# # See slapd.conf(5) for details on configuration options. # This file should NOT be world readable. # include /etc/openldap/schema/corba.schema include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/duaconf.schema include /etc/openldap/schema/dyngroup.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/java.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openldap.schema include /etc/openldap/schema/ppolicy.schema include /etc/openldap/schema/collective.schema # Allow LDAPv2 client connections. This is NOT the default. allow bind_v2 # 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/openldap/slapd.pid argsfile /var/run/openldap/slapd.args # Load dynamic backend modules # - modulepath is architecture dependent value (32/64-bit system) # - back_sql.la overlay requires openldap-server-sql package # - dyngroup.la and dynlist.la cannot be used at the same time # modulepath /usr/lib/openldap # modulepath /usr/lib64/openldap # moduleload accesslog.la # moduleload auditlog.la # moduleload back_sql.la # moduleload chain.la # moduleload collect.la # moduleload constraint.la # moduleload dds.la # moduleload deref.la # moduleload dyngroup.la # moduleload dynlist.la # moduleload memberof.la # moduleload pbind.la # moduleload pcache.la # moduleload ppolicy.la # moduleload refint.la # moduleload retcode.la moduleload rwm.la # moduleload seqmod.la # moduleload smbk5pwd.la # moduleload sssvlv.la # moduleload syncprov.la # moduleload translucent.la # moduleload unique.la # moduleload valsort.la # The next three lines allow use of TLS for encrypting connections using a # dummy test certificate which you can generate by changing to # /etc/pki/tls/certs, running "make slapd.pem", and fixing permissions on # slapd.pem so that the ldap user or group can read it. Your client software # may balk at self-signed certificates, however. # TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt # TLSCertificateFile /etc/pki/tls/certs/slapd.pem # TLSCertificateKeyFile /etc/pki/tls/certs/slapd.pem # 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 * # by self write # by users read # by anonymous auth # # 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! # enable on-the-fly configuration (cn=config) database config access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by * none # enable server status monitoring (cn=monitor) database monitor access to * by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by dn.exact="cn=Manager,dc=my-domain,dc=com" read by * none ####################################################################### # database definitions ####################################################################### database bdb suffix "dc=inet,dc=local" checkpoint 1024 15 rootdn "cn=Manager,dc=inet,dc=local" rootpw xxxxxxxxxxxxxxxx # Cleartext passwords, especially for the rootdn, should # be avoided. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. # rootpw secret # rootpw {crypt}ijFYNcSNctBYg # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain for this database index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub # Our slapd-ldap back end to connect to AD database ldap suffix "dc=msad,dc=inet,dc=com" #subordinate rebind-as-user uri "ldap://172.16.132.253/" chase-referrals yes overlay rwm rwm-suffixmassage dc=msad,dc=inet,dc=com rwm-map attribute uid sAMAccountName rwm-map attribute cn cn rwm-map attribute displayName displayName rwm-map attribute givenName givenName rwm-map attribute sn sn rwm-map attribute mail mail rwm-map attribute userPassword userPassword rwm-map attribute * rwm-map objectclass inetOrgPerson user # Replicas of this database #replogfile /var/lib/ldap/openldap-master-replog #replica host=ldap-1.example.com:389 starttls=critical # bindmethod=sasl saslmech=GSSAPI # authcId=host/ldap-master.example.com(a)EXAMPLE.COM #* Any ideas as to why I'm unable to authenticate my user against the AD? Any advice or info on this topic would be greatly appreciated. Greetings, Jonathan Disclaimer The information contained in this communication from the sender is confidential. It is intended solely for use by the recipient and others authorized to receive it. If you are not the recipient, you are hereby notified that any disclosure, copying, distribution or taking action in relation of the contents of this information is strictly prohibited and may be unlawful. This email has been scanned for viruses and malware, and automatically archived by Mimecast SA (Pty) Ltd, an innovator in Software as a Service (SaaS) for business. Mimecast Unified Email Management (UEM) offers email continuity, security, archiving and compliance with all current legislation. To find out more, visit http://www.mimecast.co.za/uem-ppc.

2 3

how can make slave use tls to connect to master for syncrepl
by zhong ming wu 28 May '12

28 May '12

Hello I am using version 2.4 and in the process of setting up a master/slave pair using syncrepl. This is working as expected if I don't have enforce security and confidentiality with "security ssf=128" global directive in the master. As soon as I turn it on, replication stops working. It seems that the slave consumer is not using TLS to connect to master. However I can use 'ldapsearch' with '-ZZ' option to connect to master from slave and get all records I want. On my slave machine, I also have the following directive TLS_CACERT /etc/pki/tls/certs/ca.crt.crl in ldap.conf Notice that without this line 'ldapXXX' commands with '-ZZ' fails from slave to master. This confirms that at least 'ldap.conf' is in the correct location at least as far as 'ldapXXX' commands are concerned. Can someone point me in the right direction? I have read many chapters on this page http://www.openldap.org/doc/admin24/index.html Both slave and master are on centos 6.2 and openldap software is standard centos rpm. Here are the log entries on the master when slave fails to bind with TLS May 27 22:14:53 cat slapd[2456]: conn=1000 fd=13 ACCEPT from IP=192.168.0.2:41083 (IP=0.0.0.0:389) May 27 22:14:53 cat slapd[2456]: conn=1000 op=0 BIND dn="cn=root,dc=example,dc=com" method=128 May 27 22:14:53 cat slapd[2456]: conn=1000 op=0 RESULT tag=97 err=13 text=confidentiality required May 27 22:14:53 cat slapd[2456]: conn=1000 op=1 UNBIND May 27 22:14:53 cat slapd[2456]: conn=1000 fd=13 closed Sincerely Mr Wu

1 0

syncrepl for cn=config, changes fail with "tag=103 err=53 text=shadow context; no update referral"
by Elias Probst 28 May '12

28 May '12

Hi List, I'm trying to setup a master/master replication scenario, starting with getting cn=config replicated properly using OpenLDAP 2.4.30 on Gentoo. I've tried to start with a minimal config which is now up and running on both servers. As long as I start only one of both servers I can edit everything in cn=config just fine, but as soon as they both run at the same time, they get into a state which causes some trouble. Even shutting down one of both doesn't help then, I need to start from scratch again at this point. Submitting any changes results in this error message: RESULT tag=103 err=53 text=shadow context; no update referral There are two servers, connected via OpenVPN: ID 1, 10.44.0.1 ID 2, 10.44.0.7 I use the following configuration file to seed the initial online configuration for each server, before bringing them up both, using: slapd -f /tmp/slapd.conf -F /etc/openldap/slapd.d -u ldap -g ldap -d1 moduleload memberof.so moduleload syncprov.so moduleload refint.so include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/openssh.schema TLSCACertificateFile /etc/ssl/slapd/slapd.cacrt TLSCertificateFile /etc/ssl/slapd/slapd.crt TLSCertificateKeyFile /etc/ssl/slapd/slapd.key TLSVerifyClient allow pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args loglevel 256 access to attrs=userPassword by self write by * auth access to * by * read ServerID 1 ldap://10.44.0.1 ServerID 2 ldap://10.44.0.7 backend bdb database config rootdn cn=config rootpw {SSHA}RI/d8i2R7XXlo2+kf2LcYzYOcIry+qaa syncrepl rid=001 provider="ldap://10.44.0.7" binddn="cn=config" bindmethod="simple" credentials="nothingtoseehere" searchbase="cn=config" type=refreshAndPersist retry="10 +" filter="(!(olcDatabase={0}config))" syncrepl rid=002 provider="ldap://10.44.0.1" binddn="cn=config" bindmethod="simple" credentials="nothingtoseehere" searchbase="cn=config" type=refreshAndPersist retry="10 +" filter="(!(olcDatabase={0}config))" overlay syncprov I don't quite understand the error message, as it somehow indicates the servers would be running in shadow context/MirrorMode, which is set to FALSE. So does anyone have an idea, what's wrong with my setup? Thanks a lot! - Elias

5 8

more on migrating from 2.3 to 2.4
by Bobby Krupczak 27 May '12

27 May '12

Hi! I did my nfs/nis/ldap/smb/dns swap this morning. I'm struggling with getting my ldap server to work as before. slapd is running and answering anonymous queries (like logging in and checking passwords) from other machines. >From the slapd host, I can do an ldapsearch (over ssl) and everything works. I authenticate as rootdn just fine. >From a different host, I cant do an ldapsearch; I receive an "invalid creditionals (49)" error. I have enabled debugging in ldapsearch and dont see anything interesting. The server ssl cert verifies fine. No config has changed on my client. I'm thinking its ssl, ipv6, and client cert related or maybe ACLs? In my slapd.conf file, I've put TLSVerifyClient never Any suggestions? slapd is 2.4.26-7.fc16.x86_64 Yes I know I'm running the fedora package. As soon as I can get the machine up and running as before I will start migrating. Thanks, Bobby

1 0

question on syncprov
by Steve Reveliotty 25 May '12

25 May '12

Hi, I'm trying to migrate from OpenLDAP 2.3.43-12.el5_6.7 to OpenLDAP 2.4.23-20.el6.x86_6. In 2.3, we currently have one master, replicating changes to 2 consumers via slurpd. I'm trying to configure 2.4 w/ syncrepl, and have tried using refreshAndPersist to mimic that same routine of pushing changes from the master. I'm getting failures though: on the master: ay 25 13:55:25 slapd[6855]: send_search_entry: conn 1064 ber write failed. May 25 13:55:45 slapd[6855]: send_search_entry: conn 1066 ber write failed. May 25 13:56:45 slapd[6855]: send_search_entry: conn 1068 ber write failed. May 25 13:57:45 slapd[6855]: send_search_entry: conn 1078 ber write failed. May 25 13:58:45 slapd[6855]: send_search_entry: conn 1084 ber write failed. May 25 13:59:05 slapd[6855]: send_search_entry: conn 1086 ber write failed. May 25 13:59:15 slapd[6855]: send_search_entry: conn 1087 ber write failed. on a consumer: May 25 13:45:15 slapd[28707]: do_syncrepl: rid=002 rc 68 retrying (9 retries left) May 25 13:45:25 slapd[28707]: syncrepl_entry: rid=002 be_add cn=XXXXXXX,dc=edu failed (68) here are snippets from the master's slapd.conf and from one of the consumers: master - ------- database hdb include /etc/openldap/slapd.access suffix "dc=XXXXdc=edu" checkpoint 1024 5 cachesize 30000 idlcachesize 90000 rootdn "cn=Manager,XXXXX,dc=edu" # NOTE: "updatedn" MUST BE COMMENTED OUT FOR INITIAL CREATION/LOAD OF # ROOT INFO overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. #rootpw secret # needs to be changed to something someone knows. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain # review these index default pres,eq index uid eq,sub index entryUUID,entryCSN index cn,sn,givenName,ou,mail,telephoneNumber pres,eq,sub index employeeNumber,mailAlternateAddress,eduPersonPrincipalName index eduPersonAffiliation,eduPersonPrimaryAffiliation index objectClass,serialNumber eq index isMemberOf eq,subany TLSCertificateFile /etc/openldap/newcert.pem TLSCertificateKeyFile /etc/openldap/newkey.pem TLSCACertificateFile /etc/openldap/chain.pem consumer - ------------------ database hdb suffix "dc=XXXXX=edu" checkpoint 1024 5 cachesize 30000 idlcachesize 90000 rootdn "cn=Manager,dc=XXXX,dc=edu" # NOTE: "updatedn" MUST BE COMMENTED OUT FOR INITIAL CREATION/LOAD OF # ROOT INFO # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapd.conf(5) for details. # Use of strong authentication encouraged. #rootpw secret # needs to be changed to something someone knows. rootpw secret # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/ldap # Indices to maintain # review these index default pres,eq index uid eq,sub index entryUUID,entryCSN index cn,sn,givenName,ou,mail,telephoneNumber pres,eq,sub index employeeNumber,mailAlternateAddress,eduPersonPrincipalName index eduPersonAffiliation,eduPersonPrimaryAffiliation index objectClass,serialNumber eq index isMemberOf eq,subany TLSCertificateFile /etc/openldap/newcert.pem TLSCertificateKeyFile /etc/openldap/newkey.pem TLSCACertificateFile /etc/openldap/chain.pem syncrepl rid=002 provider=ldap://providername-taken-out-here:389 type=refreshAndPersist retry="10 10 60 +" searchbase="dc=XXXX,dc=edu" filter="(objectClass=*)" attrs="*" scope=sub schemachecking=off bindmethod=simple binddn="cn=Replicator,dc=XXXX,dc=edu" credentials="password" updateref ldap://providername-takenout-here:389 the account I"m using to bind from the consumer has read access to everything on the master. Thanks in advance

2 4

slapd keeps crashing
by David Massie 25 May '12

25 May '12

Our slapd instance keeps crashing. We do not see an obvious reason for the crashes. I am posting the crash report in the hope that someone will see something and can point us in the right direction. Thanks, Dave Massie Duplicate check ===== Common information ===== package ----- architecture ----- x86_64 kernel ----- 2.6.32-220.13.1.el6.x86_64 Additional information ===== uid ----- 0 time ----- 1337786308 executable ----- /var/services/openldap/libexec/slapd component ----- hostname ----- aaaprod-master.uis.georgetown.edu username ----- root reason ----- Process /var/services/openldap/libexec/slapd was killed by signal 6 (SIGABRT) analyzer ----- CCpp maps ----- 00400000-00624000 r-xp 00000000 fd:00 3675557 /var/services/openldap/libexec/slapd 00824000-00831000 rw-p 00224000 fd:00 3675557 /var/services/openldap/libexec/slapd 00831000-008d6000 rw-p 00000000 00:00 0 0104f000-012eb000 rw-p 00000000 00:00 0 012eb000-01441000 rw-p 00000000 00:00 0 394f800000-394f820000 r-xp 00000000 fd:00 1703938 /lib64/ld-2.12.so 394fa1f000-394fa20000 r--p 0001f000 fd:00 1703938 /lib64/ld-2.12.so 394fa20000-394fa21000 rw-p 00020000 fd:00 1703938 /lib64/ld-2.12.so 394fa21000-394fa22000 rw-p 00000000 00:00 0 394fc00000-394fd86000 r-xp 00000000 fd:00 1703939 /lib64/libc-2.12.so 394fd86000-394ff86000 ---p 00186000 fd:00 1703939 /lib64/libc-2.12.so 394ff86000-394ff8a000 r--p 00186000 fd:00 1703939 /lib64/libc-2.12.so 394ff8a000-394ff8b000 rw-p 0018a000 fd:00 1703939 /lib64/libc-2.12.so 394ff8b000-394ff90000 rw-p 00000000 00:00 0 3950000000-3950002000 r-xp 00000000 fd:00 1703950 /lib64/libdl-2.12.so 3950002000-3950202000 ---p 00002000 fd:00 1703950 /lib64/libdl-2.12.so 3950202000-3950203000 r--p 00002000 fd:00 1703950 /lib64/libdl-2.12.so 3950203000-3950204000 rw-p 00003000 fd:00 1703950 /lib64/libdl-2.12.so 3950400000-3950417000 r-xp 00000000 fd:00 1703943 /lib64/libpthread-2.12.so 3950417000-3950616000 ---p 00017000 fd:00 1703943 /lib64/libpthread-2.12.so 3950616000-3950617000 r--p 00016000 fd:00 1703943 /lib64/libpthread-2.12.so 3950617000-3950618000 rw-p 00017000 fd:00 1703943 /lib64/libpthread-2.12.so 3950618000-395061c000 rw-p 00000000 00:00 0 3950800000-395081d000 r-xp 00000000 fd:00 1703962 /lib64/libselinux.so.1 395081d000-3950a1c000 ---p 0001d000 fd:00 1703962 /lib64/libselinux.so.1 3950a1c000-3950a1d000 r--p 0001c000 fd:00 1703962 /lib64/libselinux.so.1 3950a1d000-3950a1e000 rw-p 0001d000 fd:00 1703962 /lib64/libselinux.so.1 3950a1e000-3950a1f000 rw-p 00000000 00:00 0 3951400000-3951416000 r-xp 00000000 fd:00 1703956 /lib64/libresolv-2.12.so 3951416000-3951616000 ---p 00016000 fd:00 1703956 /lib64/libresolv-2.12.so 3951616000-3951617000 r--p 00016000 fd:00 1703956 /lib64/libresolv-2.12.so 3951617000-3951618000 rw-p 00017000 fd:00 1703956 /lib64/libresolv-2.12.so 3951618000-395161a000 rw-p 00000000 00:00 0 3951c00000-3951c15000 r-xp 00000000 fd:00 1703994 /lib64/libz.so.1.2.3 3951c15000-3951e14000 ---p 00015000 fd:00 1703994 /lib64/libz.so.1.2.3 3951e14000-3951e15000 r--p 00014000 fd:00 1703994 /lib64/libz.so.1.2.3 3951e15000-3951e16000 rw-p 00015000 fd:00 1703994 /lib64/libz.so.1.2.3 3952000000-3952007000 r-xp 00000000 fd:00 1703999 /lib64/libcrypt-2.12.so 3952007000-3952207000 ---p 00007000 fd:00 1703999 /lib64/libcrypt-2.12.so 3952207000-3952208000 r--p 00007000 fd:00 1703999 /lib64/libcrypt-2.12.so 3952208000-3952209000 rw-p 00008000 fd:00 1703999 /lib64/libcrypt-2.12.so 3952209000-3952237000 rw-p 00000000 00:00 0 3952400000-395245d000 r-xp 00000000 fd:00 1703997 /lib64/libfreebl3.so 395245d000-395265c000 ---p 0005d000 fd:00 1703997 /lib64/libfreebl3.so 395265c000-395265d000 r--p 0005c000 fd:00 1703997 /lib64/libfreebl3.so 395265d000-395265e000 rw-p 0005d000 fd:00 1703997 /lib64/libfreebl3.so 395265e000-3952662000 rw-p 00000000 00:00 0 3952c00000-3952d6f000 r-xp 00000000 fd:00 1703948 /lib64/libdb-4.7.so 3952d6f000-3952f6e000 ---p 0016f000 fd:00 1703948 /lib64/libdb-4.7.so 3952f6e000-3952f74000 rw-p 0016e000 fd:00 1703948 /lib64/libdb-4.7.so 3953000000-3953019000 r-xp 00000000 fd:00 2361953 /usr/lib64/libsasl2.so.2.0.23 3953019000-3953218000 ---p 00019000 fd:00 2361953 /usr/lib64/libsasl2.so.2.0.23 3953218000-3953219000 r--p 00018000 fd:00 2361953 /usr/lib64/libsasl2.so.2.0.23 3953219000-395321a000 rw-p 00019000 fd:00 2361953 /usr/lib64/libsasl2.so.2.0.23 3953c00000-3953c2a000 r-xp 00000000 fd:00 1703964 /lib64/libk5crypto.so.3.1 3953c2a000-3953e29000 ---p 0002a000 fd:00 1703964 /lib64/libk5crypto.so.3.1 3953e29000-3953e2b000 r--p 00029000 fd:00 1703964 /lib64/libk5crypto.so.3.1 3953e2b000-3953e2c000 rw-p 0002b000 fd:00 1703964 /lib64/libk5crypto.so.3.1 3954000000-3954002000 r-xp 00000000 fd:00 1703952 /lib64/libkeyutils.so.1.3 3954002000-3954201000 ---p 00002000 fd:00 1703952 /lib64/libkeyutils.so.1.3 3954201000-3954202000 r--p 00001000 fd:00 1703952 /lib64/libkeyutils.so.1.3 3954202000-3954203000 rw-p 00002000 fd:00 1703952 /lib64/libkeyutils.so.1.3 3954400000-395440a000 r-xp 00000000 fd:00 1703963 /lib64/libkrb5support.so.0.1 395440a000-3954609000 ---p 0000a000 fd:00 1703963 /lib64/libkrb5support.so.0.1 3954609000-395460a000 r--p 00009000 fd:00 1703963 /lib64/libkrb5support.so.0.1 395460a000-395460b000 rw-p 0000a000 fd:00 1703963 /lib64/libkrb5support.so.0.1 3955800000-395583f000 r-xp 00000000 fd:00 1703977 /lib64/libgssapi_krb5.so.2.2 395583f000-3955a3f000 ---p 0003f000 fd:00 1703977 /lib64/libgssapi_krb5.so.2.2 3955a3f000-3955a40000 r--p 0003f000 fd:00 1703977 /lib64/libgssapi_krb5.so.2.2 3955a40000-3955a42000 rw-p 00040000 fd:00 1703977 /lib64/libgssapi_krb5.so.2.2 3955c00000-3955cd4000 r-xp 00000000 fd:00 1703973 /lib64/libkrb5.so.3.3 3955cd4000-3955ed4000 ---p 000d4000 fd:00 1703973 /lib64/libkrb5.so.3.3 3955ed4000-3955edd000 r--p 000d4000 fd:00 1703973 /lib64/libkrb5.so.3.3 3955edd000-3955edf000 rw-p 000dd000 fd:00 1703973 /lib64/libkrb5.so.3.3 3956800000-3956973000 r-xp 00000000 fd:00 2363773 /usr/lib64/libcrypto.so.1.0.0 3956973000-3956b73000 ---p 00173000 fd:00 2363773 /usr/lib64/libcrypto.so.1.0.0 3956b73000-3956b8c000 r--p 00173000 fd:00 2363773 /usr/lib64/libcrypto.so.1.0.0 3956b8c000-3956b96000 rw-p 0018c000 fd:00 2363773 /usr/lib64/libcrypto.so.1.0.0 3956b96000-3956b9a000 rw-p 00000000 00:00 0 3957800000-3957853000 r-xp 00000000 fd:00 2363947 /usr/lib64/libssl.so.1.0.0 3957853000-3957a53000 ---p 00053000 fd:00 2363947 /usr/lib64/libssl.so.1.0.0 3957a53000-3957a56000 r--p 00053000 fd:00 2363947 /usr/lib64/libssl.so.1.0.0 3957a56000-3957a5b000 rw-p 00056000 fd:00 2363947 /usr/lib64/libssl.so.1.0.0 7f70d8000000-7f70d80e8000 rw-p 00000000 00:00 0 7f70d80e8000-7f70dc000000 ---p 00000000 00:00 0 7f70e0000000-7f70e8000000 rw-p 00000000 00:00 0 7f70e8000000-7f70ed94c000 rw-p 00000000 00:00 0 7f70ed94c000-7f70f0000000 ---p 00000000 00:00 0 7f70f4000000-7f70ffff8000 rw-p 00000000 00:00 0 7f70ffff8000-7f7100000000 ---p 00000000 00:00 0 7f7100000000-7f7100458000 rw-p 00000000 00:00 0 7f7100458000-7f7104000000 ---p 00000000 00:00 0 7f7108000000-7f7110000000 rw-p 00000000 00:00 0 7f7110000000-7f7118000000 rw-p 00000000 00:00 0 7f7118000000-7f711c69d000 rw-p 00000000 00:00 0 7f711c69d000-7f7120000000 ---p 00000000 00:00 0 7f7120000000-7f7124000000 rw-p 00000000 00:00 0 7f7128000000-7f7130000000 rw-p 00000000 00:00 0 7f7130000000-7f7135fe7000 rw-p 00000000 00:00 0 7f7135fe7000-7f7138000000 ---p 00000000 00:00 0 7f7138000000-7f7140000000 rw-p 00000000 00:00 0 7f7140000000-7f7148000000 rw-p 00000000 00:00 0 7f7148000000-7f714fa52000 rw-p 00000000 00:00 0 7f714fa52000-7f7150000000 ---p 00000000 00:00 0 7f7150000000-7f7158000000 rw-p 00000000 00:00 0 7f7158000000-7f715e575000 rw-p 00000000 00:00 0 7f715e575000-7f7160000000 ---p 00000000 00:00 0 7f7160000000-7f7168000000 rw-p 00000000 00:00 0 7f7168000000-7f716c000000 rw-p 00000000 00:00 0 7f716c000000-7f7170000000 rw-p 00000000 00:00 0 7f7170000000-7f7174000000 rw-p 00000000 00:00 0 7f71777ff000-7f7177800000 ---p 00000000 00:00 0 7f7177800000-7f7178000000 rw-p 00000000 00:00 0 7f7178000000-7f717bfff000 rw-p 00000000 00:00 0 7f717bfff000-7f717c000000 ---p 00000000 00:00 0 7f717c000000-7f717cd6a000 rw-p 00000000 00:00 0 7f717cd6a000-7f7180000000 ---p 00000000 00:00 0 7f7180000000-7f7180d78000 rw-p 00000000 00:00 0 7f7180d78000-7f7184000000 ---p 00000000 00:00 0 7f7186fff000-7f7188000000 rw-p 00000000 00:00 0 7f7188000000-7f7188dab000 rw-p 00000000 00:00 0 7f7188dab000-7f718c000000 ---p 00000000 00:00 0 7f718cffd000-7f7190000000 rw-p 00000000 00:00 0 7f7190000000-7f7190d8d000 rw-p 00000000 00:00 0 7f7190d8d000-7f7194000000 ---p 00000000 00:00 0 7f71947fc000-7f71977ff000 rw-p 00000000 00:00 0 7f71977ff000-7f7197800000 ---p 00000000 00:00 0 7f7197800000-7f7198000000 rw-p 00000000 00:00 0 7f7198000000-7f719c000000 rw-p 00000000 00:00 0 7f719c7fb000-7f719e7fd000 rw-p 00000000 00:00 0 7f719e7fd000-7f719e7fe000 ---p 00000000 00:00 0 7f719e7fe000-7f719effe000 rw-p 00000000 00:00 0 7f719effe000-7f719efff000 ---p 00000000 00:00 0 7f719efff000-7f719f7ff000 rw-p 00000000 00:00 0 7f719f7ff000-7f719f800000 ---p 00000000 00:00 0 7f719f800000-7f71a0000000 rw-p 00000000 00:00 0 7f71a0000000-7f71a0d21000 rw-p 00000000 00:00 0 7f71a0d21000-7f71a4000000 ---p 00000000 00:00 0 7f71a4000000-7f71a8000000 rw-p 00000000 00:00 0 7f71a87fa000-7f71a87fb000 ---p 00000000 00:00 0 7f71a87fb000-7f71a8ffb000 rw-p 00000000 00:00 0 7f71a8ffb000-7f71a8ffc000 ---p 00000000 00:00 0 7f71a8ffc000-7f71a97fc000 rw-p 00000000 00:00 0 7f71a97fc000-7f71a97fd000 ---p 00000000 00:00 0 7f71a97fd000-7f71a9ffd000 rw-p 00000000 00:00 0 7f71a9ffd000-7f71a9ffe000 ---p 00000000 00:00 0 7f71a9ffe000-7f71ab7ff000 rw-p 00000000 00:00 0 7f71ab7ff000-7f71ab800000 ---p 00000000 00:00 0 7f71ab800000-7f71ac000000 rw-p 00000000 00:00 0 7f71ac000000-7f71b0000000 rw-p 00000000 00:00 0 7f71b0000000-7f71b133a000 rw-p 00000000 00:00 0 7f71b133a000-7f71b4000000 ---p 00000000 00:00 0 7f71b47fc000-7f71b67fe000 rw-p 00000000 00:00 0 7f71b67fe000-7f71b67ff000 ---p 00000000 00:00 0 7f71b67ff000-7f71b8000000 rw-p 00000000 00:00 0 7f71b8000000-7f71be8e6000 rw-p 00000000 00:00 0 7f71be8e6000-7f71c0000000 ---p 00000000 00:00 0 7f71c0000000-7f71c7ffd000 rw-p 00000000 00:00 0 7f71c7ffd000-7f71c8000000 ---p 00000000 00:00 0 7f71c8000000-7f71d0000000 rw-p 00000000 00:00 0 7f71d0000000-7f71d4000000 rw-p 00000000 00:00 0 7f71d47fb000-7f71d47fc000 ---p 00000000 00:00 0 7f71d47fc000-7f71d4ffc000 rw-p 00000000 00:00 0 7f71d4ffc000-7f71d4ffd000 ---p 00000000 00:00 0 7f71d4ffd000-7f71d67fe000 rw-p 00000000 00:00 0 7f71d67fe000-7f71d67ff000 ---p 00000000 00:00 0 7f71d67ff000-7f71d8000000 rw-p 00000000 00:00 0 7f71d8000000-7f71dc000000 rw-p 00000000 00:00 0 7f71dc000000-7f71e0000000 rw-p 00000000 00:00 0 7f71e0000000-7f71e0021000 rw-p 00000000 00:00 0 7f71e0021000-7f71e4000000 ---p 00000000 00:00 0 7f71e4253000-7f71e5254000 rw-p 00000000 00:00 0 7f71e5254000-7f71e5255000 ---p 00000000 00:00 0 7f71e5255000-7f71e5a55000 rw-p 00000000 00:00 0 7f71e5a55000-7f71e5a56000 ---p 00000000 00:00 0 7f71e5a56000-7f71e7257000 rw-p 00000000 00:00 0 7f71e7257000-7f71e7258000 ---p 00000000 00:00 0 7f71e7258000-7f71ece46000 rw-p 00000000 00:00 0 7f71ece46000-7f71ece4e000 rw-s 00000000 fd:00 3675649 /var/services/openldap/var/openldap-data/__db.006 7f71ece4e000-7f71ed230000 rw-s 00000000 fd:00 3675587 /var/services/openldap/var/openldap-data/__db.005 7f71ed230000-7f71ed470000 rw-s 00000000 fd:00 3675569 /var/services/openldap/var/openldap-data/__db.004 7f71ed470000-7f722d470000 rw-s 00000000 fd:00 3675566 /var/services/openldap/var/openldap-data/__db.003 7f722d470000-7f722f722000 rw-s 00000000 fd:00 3675035 /var/services/openldap/var/openldap-data/__db.002 7f722f722000-7f722f9e3000 rw-p 00000000 00:00 0 7f722f9e3000-7f722f9e7000 r-xp 00000000 fd:00 2360495 /usr/lib64/sasl2/libanonymous.so.2.0.23 7f722f9e7000-7f722fbe6000 ---p 00004000 fd:00 2360495 /usr/lib64/sasl2/libanonymous.so.2.0.23 7f722fbe6000-7f722fbe7000 r--p 00003000 fd:00 2360495 /usr/lib64/sasl2/libanonymous.so.2.0.23 7f722fbe7000-7f722fbe8000 rw-p 00004000 fd:00 2360495 /usr/lib64/sasl2/libanonymous.so.2.0.23 7f722fbe8000-7f722fbec000 r-xp 00000000 fd:00 2364158 /usr/lib64/sasl2/libplain.so.2.0.23 7f722fbec000-7f722fdeb000 ---p 00004000 fd:00 2364158 /usr/lib64/sasl2/libplain.so.2.0.23 7f722fdeb000-7f722fdec000 r--p 00003000 fd:00 2364158 /usr/lib64/sasl2/libplain.so.2.0.23 7f722fdec000-7f722fded000 rw-p 00004000 fd:00 2364158 /usr/lib64/sasl2/libplain.so.2.0.23 7f722fded000-7f722fdf2000 r-xp 00000000 fd:00 2360498 /usr/lib64/sasl2/libsasldb.so.2.0.23 7f722fdf2000-7f722fff1000 ---p 00005000 fd:00 2360498 /usr/lib64/sasl2/libsasldb.so.2.0.23 7f722fff1000-7f722fff2000 r--p 00004000 fd:00 2360498 /usr/lib64/sasl2/libsasldb.so.2.0.23 7f722fff2000-7f722fff3000 rw-p 00005000 fd:00 2360498 /usr/lib64/sasl2/libsasldb.so.2.0.23 7f722fff3000-7f722fff7000 r-xp 00000000 fd:00 2364155 /usr/lib64/sasl2/liblogin.so.2.0.23 7f722fff7000-7f72301f6000 ---p 00004000 fd:00 2364155 /usr/lib64/sasl2/liblogin.so.2.0.23 7f72301f6000-7f72301f7000 r--p 00003000 fd:00 2364155 /usr/lib64/sasl2/liblogin.so.2.0.23 7f72301f7000-7f72301f8000 rw-p 00004000 fd:00 2364155 /usr/lib64/sasl2/liblogin.so.2.0.23 7f72301f8000-7f7230231000 rw-p 00000000 00:00 0 7f7230231000-7f723023d000 r-xp 00000000 fd:00 1704002 /lib64/libnss_files-2.12.so 7f723023d000-7f723043d000 ---p 0000c000 fd:00 1704002 /lib64/libnss_files-2.12.so 7f723043d000-7f723043e000 r--p 0000c000 fd:00 1704002 /lib64/libnss_files-2.12.so 7f723043e000-7f723043f000 rw-p 0000d000 fd:00 1704002 /lib64/libnss_files-2.12.so 7f723043f000-7f7230445000 rw-p 00000000 00:00 0 7f7230445000-7f7230448000 r-xp 00000000 fd:00 1703972 /lib64/libcom_err.so.2.1 7f7230448000-7f7230647000 ---p 00003000 fd:00 1703972 /lib64/libcom_err.so.2.1 7f7230647000-7f7230648000 r--p 00002000 fd:00 1703972 /lib64/libcom_err.so.2.1 7f7230648000-7f7230649000 rw-p 00003000 fd:00 1703972 /lib64/libcom_err.so.2.1 7f7230649000-7f723064d000 rw-p 00000000 00:00 0 7f723064d000-7f7230656000 r-xp 00000000 fd:00 2371184 /usr/lib64/libltdl.so.7.2.1 7f7230656000-7f7230855000 ---p 00009000 fd:00 2371184 /usr/lib64/libltdl.so.7.2.1 7f7230855000-7f7230856000 rw-p 00008000 fd:00 2371184 /usr/lib64/libltdl.so.7.2.1 7f7230856000-7f7230857000 rw-p 00000000 00:00 0 7f7230857000-7f723085d000 rw-s 00000000 fd:00 3674284 /var/services/openldap/var/openldap-data/__db.001 7f723085d000-7f723085e000 rw-p 00000000 00:00 0 7fffe0384000-7fffe0399000 rw-p 00000000 00:00 0 [stack] 7fffe03f9000-7fffe03fa000 r-xp 00000000 00:00 0 [vdso] ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] cmdline ----- /var/services/openldap/libexec/slapd -h 'ldap://*:389 ldaps://*:636' -f /var/services/openldap/etc/openldap/slapd.conf os_release ----- Red Hat Enterprise Linux Server release 6.2 (Santiago) environ ----- REMOTEHOST=10.212.141.90 HOSTNAME=aaaprod-master.uis.georgetown.edu SELINUX_ROLE_REQUESTED= HOST=aaaprod-master.uis.georgetown.edu TERM=vt100 SHELL=/bin/bash 'SSH_CLIENT=10.212.141.90 62167 22' SELINUX_USE_CURRENT_RANGE= SSH_TTY=/dev/pts/0 GROUP=wheel USER=dhm24.a LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:mi=01;05;37;41:su=37;41:sg=30;43:ca=30;41:tw=30;42:ow=34;42:st=37;44:ex=01;32:*.tar=01;31:*.tgz=01;31:*.arj=01;31:*.taz=01;31:*.lzh=01;31:*.lzma=01;31:*.tlz=01;31:*.txz=01;31:*.zip=01;31:*.z=01;31:*.Z=01;31:*.dz=01;31:*.gz=01;31:*.lz=01;31:*.xz=01;31:*.bz2=01;31:*.tbz=01;31:*.tbz2=01;31:*.bz=01;31:*.tz=01;31:*.deb=01;31:*.rpm=01;31:*.jar=01;31:*.rar=01;31:*.ace=01;31:*.zoo=01;31:*.cpio=01;31:*.7z=01;31:*.rz=01;31:*.jpg=01;35:*.jpeg=01;35:*.gif=01;35:*.bmp=01;35:*.pbm=01;35:*.pgm=01;35:*.ppm=01;35:*.tga=01;35:*.xbm=01;35:*.xpm=01;35:*.tif=01;35:*.tiff=01;35:*.png=01;35:*.svg=01;35:*.svgz=01;35:*.mng=01;35:*.pcx=01;35:*.mov=01;35:*.mpg=01;35:*.mpeg=01;35:*.m2v=01;35:*.mkv=01;35:*.ogm=01;35:*.mp4=01;35:*.m4v=01;35:*.mp4v=01;35:*.vob=01;35:*.qt=01;35:*.nuv=01;35:*.wmv=01;35:*.asf=01;35:*.rm=01;35:*.rmvb=01;35:*.flc=01;35:*.avi=01;35:*.fli=01;35:*.flv=01;35:*.gl=01;35:*.dl=01;35:*.xcf=01;35:*.xwd=01;35:*.yuv=01;35:*.cgm=01;35:*.emf=01;35:*.axv=01;35:*.anx=01;35:*.ogv=01;35:*.ogx=01;35:*.aac=01;36:*.au=01;36:*.flac=01;36:*.mid=01;36:*.midi=01;36:*.mka=01;36:*.mp3=01;36:*.mpc=01;36:*.ogg=01;36:*.ra=01;36:*.wav=01;36:*.axa=01;36:*.oga=01;36:*.spx=01;36:*.xspf=01;36: HOSTTYPE=x86_64-linux MAIL=/var/spool/mail/dhm24.a PATH=/opt/ruby-enterprise/bin:/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/bin:/bin:/usr/bin PWD=/ LANG=en_US.UTF-8 SELINUX_LEVEL_REQUESTED= KRB5CCNAME=FILE:/tmp/krb5cc_0.1 SHLVL=4 HOME=/root OSTYPE=linux VENDOR=unknown MACHTYPE=x86_64 LOGNAME=dhm24.a CVS_RSH=ssh 'SSH_CONNECTION=10.212.141.90 62167 141.161.152.76 22' 'LESSOPEN=|/usr/bin/lesspipe.sh %s' G_BROKEN_FILENAMES=1 _=/var/services/openldap/libexec/slapd

2 5

Memory leak in 2.4.31 w/ hdb and MMR?
by Brandon Hume 25 May '12

25 May '12

I've got my two-node setup up and running, MMR w/ delta-syncrepl. Node 1 is up and running with ~340k entries in the main DIT. It consumes about 4G of VM on a Redhat AS6 box, and the data dir is around 2.3G on-disk (including __db.* and the one log.* file...), and another 100M in cn=accesslog. I'm bringing up node 2 after nuking the data dir, and letting it syncrepl from nothing. I was tracking a SIGBUS error, but that turned out to be olcLogLevel=Stats+Sync generating a huge amount of logging and filling up the disk. Fixed that, moved on. Now, it's still crashing... but that's because slapd is bloating up hugely and causing the machine to run out of VM and kill the process. I've added about 8G of temporary swap, and it's still going. slapd on node2 is 5.5G resident, and nearly 15G in size total now. On-disk the hdb is only around 1.6G, so it still has a long ways to go. Can I assume this is not the way it should be? vmstat shows a lot of swap-out but almost no swap-in, so it's not thrashing. pmap shows a large number of 64M "anon" segments. 140 of those at one point, and 157 when I checked just now. It looks a lot like a memory leak, though I can't tell offhand whether the problem is in OpenLDAP (2.4.31) or in BerkeleyDB (5.3.15). When it finishes, I'm planning on turning off delta-syncrepl and pave/rebuild again, and see if it behaves the same. I could also give mdb a shot, but since this is a mirror I'd have to rebuild both sides. Any suggestions as to where I could start looking for the source of the problem? Obviously I'm not planning on rebuilding this node on a regular basis (and certainly not all via syncrepl) but I'm concerned that over an extended period of time it'll leak memory even during normal use. I'm including my DB_CONFIG, just in case. I can supply more of the config as necessary. DB_CONFIG: set_cachesize 0 536870912 0 set_lg_regionmax 10485760 set_lg_max 104857600 set_lg_bsize 26214400 set_lk_max_locks 4096 set_lk_max_objects 4096 set_flags DB_LOG_AUTOREMOVE (If anything looks particularly stupid in here, even unrelated to the leak, I'd love the advice...)

3 7

Multi Master syncrepl issue
by Neil Mcbennett 25 May '12

25 May '12

Hello, This is my first post to this list and unfortunately I come here with a problem. I'm not new to LDAP but I am new to OpenLDAP especially the 2.4 release. I am trying to get multi master replication working and I've read the documentation several times. I did wonder if this might be a bug but I still think it's probably a misunderstanding on my part. I have 2 servers configured for multi master replcation which I will refer to as server A and B. If I start both servers I can make changes on server A which are immediately replicated to server B. However if I then start making changes to server B I don't see replication back to A. The same thing happens if I initiate replication from B, then replication to A works but not the other way around. i.e. replication only works in 1 direction which is determined by which server I make changes on first. I am using slapd.conf as I didn't want to complicate matters by introducing online config. The specific version is 2.4.31. Connectivity between the servers is working fine - I can perform LDAP operations in both directions. If someone could take a look at my config I'd much appreciate it. Thanks Neil #slapd.conf Server A (10.5.1.110) pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args include /usr/local/openldap/etc/schema/core.schema include /usr/local/openldap/etc/schema/cosine.schema include /usr/local/openldap/etc/schema/solaris.schema include /usr/local/openldap/etc/schema/inetorgperson.schema include /usr/local/openldap/etc/schema/DUAConfigProfile.schema include /usr/local/openldap/etc/schema/sudo.schema modulepath /usr/local/openldap/libexec moduleload syncprov.la access to attrs=userPassword by self write by * auth by dn="cn=ldapclient,ou=profile,dc=example,dc=com" write access to dn.base="" by * read access to * by self write by users read by anonymous read serverID 1 database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw {SSHA}pnqaqMcoMhnDbSRa9WAgDbhBMr/QnUGY lastmod on directory /usr/local/openldap/var/openldap-data index objectclass,uid,uidNumber,memberUid,entryCSN,entryUUID,automountKey eq index cn,sn,gn,mail eq,sub syncrepl rid=001 provider=ldap://10.7.82.3 type=refreshAndPersist searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=manager,dc=example,dc=com" credentials="secret" mirrormode TRUE overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 ####################################################### #slapd.conf server B (10.7.82.3) pidfile /usr/local/openldap/var/run/slapd.pid argsfile /usr/local/openldap/var/run/slapd.args include /usr/local/openldap/etc/schema/core.schema include /usr/local/openldap/etc/schema/cosine.schema include /usr/local/openldap/etc/schema/solaris.schema include /usr/local/openldap/etc/schema/inetorgperson.schema include /usr/local/openldap/etc/schema/DUAConfigProfile.schema include /usr/local/openldap/etc/schema/sudo.schema modulepath /usr/local/openldap/libexec moduleload syncprov.la access to attrs=userPassword by self write by * auth by dn="cn=ldapclient,ou=profile,dc=example,dc=com" write access to dn.base="" by * read access to * by self write by users read by anonymous read serverID 2 database hdb suffix "dc=example,dc=com" rootdn "cn=Manager,dc=example,dc=com" rootpw {SSHA}pnqaqMcoMhnDbSRa9WAgDbhBMr/QnUGY lastmod on directory /usr/local/openldap/var/openldap-data index objectclass,uid,uidNumber,memberUid,entryCSN,entryUUID,automountKey eq index cn,sn,gn,mail eq,sub syncrepl rid=001 provider=ldap://10.5.1.110 type=refreshAndPersist searchbase="dc=example,dc=com" attrs="*,+" bindmethod=simple binddn="cn=manager,dc=example,dc=com" credentials="secret" mirrormode TRUE overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 #######################################################

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical