Re: RE24 testing call (2.4.41)
by Jephte Clain
hello,
it builds fine on debian squeeze LTS 64bits, and the tests are ok
FYI, configure was run with the debian defaults:
./configure --prefix=/usr --libexecdir='${prefix}/lib'
--sysconfdir=/etc --localstatedir=/var --mandir='${prefix}/share/man'
--enable-debug --enable-dynamic --enable-syslog --enable-proctitle
--enable-ipv6 --enable-local --enable-slapd --enable-dynacl
--enable-aci --enable-cleartext --enable-crypt --disable-lmpasswd
--enable-spasswd --enable-modules --enable-rewrite --enable-rlookups
--enable-slapi --enable-slp --enable-wrappers --enable-backends=mod
--disable-ndb --enable-overlays=mod --with-subdir=ldap
--with-cyrus-sasl --with-threads --with-tls=openssl
--with-odbc=unixodbc
regards,
2015-05-01 0:21 GMT+04:00 Quanah Gibson-Mount <quanah(a)zimbra.com>:
> If you know how to build OpenLDAP manually, and would like to participate in
> testing the next set of code for the 2.4.41 release, please do so.
>
> Generally, get the code for RE24:
>
> <http://www.openldap.org/devel/gitweb.cgi?p=openldap.git;a=snapshot;h=refs...>
>
> Configure & build.
>
> Execute the test suite (via make test) after it is built.
>
> Thanks!
>
> --Quanah
>
> --
>
> Quanah Gibson-Mount
> Platform Architect
> Zimbra, Inc.
> --------------------
> Zimbra :: the leader in open source messaging and collaboration
>
--
Jephté CLAIN | Développeur, Intégrateur d'applications
Service Système d'Information
Direction des Systèmes d'Information
Tél: +262 262 93 86 31 || Gsm: +262 692 29 58 24
5 years, 11 months
syncrepl and memberof do not work well together
by John Alex.
I am not sure if this is by design or a bug so I am posting here first.
I have a provider-consumer configuration (both at version 2.4.40) where the consumer uses
simple syncrepl (no delta sync). I am using the memberof overlay in the provider, and,
having read the slapo-memberof manpage and ITS#7400, I made sure to exclude "memberof"
from the synced attributes, and configured the memberof overlay in the consumer too. When
I add or remove a user from a group, the user entry is correctly updated in both provider
and consumer with the addition or removal of the corresponding "memberof" value.
The problem occurs when a user entry is modified in any way, e.g. by changing a password,
adding a description, etc. From what I understand, when a change occurs in an entry,
non-delta syncrepl causes the entire entry to be resynced, not just the modified
attributes. The result is that the "memberof" attributes of this entry on the consumer are
removed.
Is this the intended behavior? Shouldn't the "memberOf" values be restored after the entry
is updated, since no group membership was modified?
5 years, 11 months
debugging
by Craig White
Trying to figure out if this search is being denied. I wouldn't think so but the last 3 lines at the end suggest otherwise.
5552876b conn=1000 fd=21 ACCEPT from IP=172.29.34.47:42310 (IP=0.0.0.0:389)
5552876b conn=1000 op=0 BIND dn="uid=an_admin,ou=People,dc=doesn't_matter,dc=com" method=128
5552876b => bdb_entry_get: found entry: "uid=an_admin,ou=people,dc=doesn't_matter,dc=com"
5552876b => bdb_entry_get: found entry: "cn=defaultpp,ou=policies,dc=doesn't_matter,dc=com"
5552876b => access_allowed: result not in cache (userPassword)
5552876b => access_allowed: auth access to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" "userPassword" requested
5552876b => acl_get: [1] attr userPassword
5552876b => acl_mask: access to entry "uid=an_admin,ou=People,dc=doesn't_matter,dc=com", attr "userPassword" requested
5552876b => acl_mask: to value by "", (=0)
5552876b <= check a_dn_pat: self
5552876b <= check a_dn_pat: anonymous
5552876b <= acl_mask: [2] applying auth(=xd) (stop)
5552876b <= acl_mask: [2] mask: auth(=xd)
5552876b => slap_access_allowed: auth access granted by auth(=xd)
5552876b => access_allowed: auth access granted by auth(=xd)
5552876b conn=1000 op=0 BIND dn="uid=an_admin,ou=People,dc=doesn't_matter,dc=com" mech=SIMPLE ssf=0
5552876b => bdb_entry_get: found entry: "uid=an_admin,ou=people,dc=doesn't_matter,dc=com"
5552876b conn=1000 op=0 RESULT tag=97 err=0 text=
5552876b conn=1000 op=1 BIND anonymous mech=implicit ssf=0
5552876b conn=1000 op=1 BIND dn="uid=an_admin,ou=People,dc=doesn't_matter,dc=com" method=128
5552876b => bdb_entry_get: found entry: "uid=an_admin,ou=people,dc=doesn't_matter,dc=com"
5552876b => bdb_entry_get: found entry: "cn=defaultpp,ou=policies,dc=doesn't_matter,dc=com"
5552876b => access_allowed: result not in cache (userPassword)
5552876b => access_allowed: auth access to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com" "userPassword" requested
5552876b => acl_get: [1] attr userPassword
5552876b => acl_mask: access to entry "uid=an_admin,ou=People,dc=doesn't_matter,dc=com", attr "userPassword" requested
5552876b => acl_mask: to value by "", (=0)
5552876b <= check a_dn_pat: self
5552876b <= check a_dn_pat: anonymous
5552876b <= acl_mask: [2] applying auth(=xd) (stop)
5552876b <= acl_mask: [2] mask: auth(=xd)
5552876b => slap_access_allowed: auth access granted by auth(=xd)
5552876b => access_allowed: auth access granted by auth(=xd)
5552876b conn=1000 op=1 BIND dn="uid=an_admin,ou=People,dc=doesn't_matter,dc=com" mech=SIMPLE ssf=0
5552876b => bdb_entry_get: found entry: "uid=an_admin,ou=people,dc=doesn't_matter,dc=com"
5552876b conn=1000 op=1 RESULT tag=97 err=0 text=
5552876b begin get_filter
5552876b PRESENT
5552876b end get_filter 0
5552876b conn=1000 op=2 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
5552876b conn=1000 op=2 SRCH attr=* + altServer changelog firstChangeNumber lastChangeNumber lastPurgedChangeNumber namingContexts subschemaSubentry supportedAuthPasswordSchemes supportedControl supportedExtension supportedFeatures supportedLDAPVersion supportedSASLMechanisms vendorName vendorVersion
5552876b => test_filter
5552876b PRESENT
5552876b => access_allowed: search access to "" "objectClass" requested
5552876b => slap_access_allowed: backend default search access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: search access granted by read(=rscxd)
5552876b <= test_filter 6
5552876b => access_allowed: read access to "" "entry" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result not in cache (objectClass)
5552876b => access_allowed: read access to "" "objectClass" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result was in cache (objectClass)
5552876b => access_allowed: result not in cache (structuralObjectClass)
5552876b => access_allowed: read access to "" "structuralObjectClass" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result not in cache (configContext)
5552876b => access_allowed: read access to "" "configContext" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result not in cache (namingContexts)
5552876b => access_allowed: read access to "" "namingContexts" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result was in cache (namingContexts)
5552876b => access_allowed: result not in cache (monitorContext)
5552876b => access_allowed: read access to "" "monitorContext" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result not in cache (supportedControl)
5552876b => access_allowed: read access to "" "supportedControl" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result was in cache (supportedControl)
5552876b => access_allowed: result was in cache (supportedControl)
5552876b => access_allowed: result was in cache (supportedControl)
5552876b => access_allowed: result was in cache (supportedControl)
5552876b => access_allowed: result was in cache (supportedControl)
5552876b => access_allowed: result was in cache (supportedControl)
5552876b => access_allowed: result was in cache (supportedControl)
5552876b => access_allowed: result was in cache (supportedControl)
5552876b => access_allowed: result not in cache (supportedExtension)
5552876b => access_allowed: read access to "" "supportedExtension" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result was in cache (supportedExtension)
5552876b => access_allowed: result was in cache (supportedExtension)
5552876b => access_allowed: result was in cache (supportedExtension)
5552876b => access_allowed: result not in cache (supportedFeatures)
5552876b => access_allowed: read access to "" "supportedFeatures" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result was in cache (supportedFeatures)
5552876b => access_allowed: result was in cache (supportedFeatures)
5552876b => access_allowed: result was in cache (supportedFeatures)
5552876b => access_allowed: result was in cache (supportedFeatures)
5552876b => access_allowed: result was in cache (supportedFeatures)
5552876b => access_allowed: result not in cache (supportedLDAPVersion)
5552876b => access_allowed: read access to "" "supportedLDAPVersion" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result not in cache (supportedSASLMechanisms)
5552876b => access_allowed: read access to "" "supportedSASLMechanisms" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result not in cache (entryDN)
5552876b => access_allowed: read access to "" "entryDN" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result was in cache (entryDN)
5552876b => access_allowed: result not in cache (subschemaSubentry)
5552876b => access_allowed: read access to "" "subschemaSubentry" requested
5552876b => slap_access_allowed: backend default read access granted to "uid=an_admin,ou=People,dc=doesn't_matter,dc=com"
5552876b => access_allowed: read access granted by read(=rscxd)
5552876b => access_allowed: result was in cache (subschemaSubentry)
5552876b conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
5552876b begin get_filter
5552876b EQUALITY
5552876b end get_filter 0
5552876b conn=1000 op=3 SRCH base="cn=accesslog" scope=2 deref=0 filter="(uid=global.admin)"
5552876b => access_allowed: search access to "cn=accesslog" "entry" requested
5552876b => acl_get: [1] attr entry
5552876b => acl_mask: access to entry "cn=accesslog", attr "entry" requested
5552876b => acl_mask: to all values by "uid=an_admin,ou=people,dc=doesn't_matter,dc=com", (=0)
5552876b <= check a_dn_pat: cn=admin,dc=doesn't_matter,dc=com
5552876b <= check a_dn_pat: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth
5552876b <= acl_mask: no more <who> clauses, returning =0 (stop)
5552876b => slap_access_allowed: search access denied by =0
5552876b => access_allowed: no more rules
5552876b conn=1000 op=3 SEARCH RESULT tag=101 err=32 nentries=0 text=
So the application is a java application and the developers haven't a clue on how to debug the java ldap side. I am not sure why it's looking at accesslog in the context of this connection, and it shouldn't have access to accesslog but it shouldn't matter anyway, accesslog is database{1} and the actual suffix to be searched is database{3}
User uid=an_admin,ou=People,dc=doesn't_matter,dc=com is pretty much allowed to do anything in the suffixed database {dc=doesn't_matter,dc=com}
My contention is that there isn't an error here but the application isn't happy with the new setup and as I said, they are not knowledgeable about how to debug from the java side.
Does this log indicate an error? (I know err=32 is no such object)
Craig
5 years, 11 months
search in ldap from java is getting stuck
by PRATIK SINGAL
Hi
can anyone help me with java code which will return all the number of data
present in the object class.
Currently search gets stuck when there are more than 3 lakh of data in the
object class.
The java thread becomes dead i guess.
Regards,
Pratik
5 years, 11 months
ACL sanity check
by Brendan Kearney
i am looking to improve my access controls, and wanted to make sure the
below passes muster and sanely implements what i am looking for.
0 - ldap admins get access to the entire directory
{0}to dn.subtree="dc=bpk2,dc=com"
by
group.exact="cn=ldapAdmins,ou=domainGroups,ou=Groups,dc=bpk2,dc=com" manage
by anonymous auth
by * none
1 - kerberos id get only the access they need
{1}to dn.subtree="cn=BPK2.COM,dc=bpk2,dc=com"
by dn="cn=kadmin,dc=bpk2,dc=com" write
by dn="cn=kdc,dc=bpk2,dc=com" read
by * none
2 - dns engineers, admins and dns process accounts get access
{2}to dn.subtree="cn=dns,ou=Daemons,dc=bpk2,dc=com"
by
group.exact="cn=dnsEngineers,ou=domainGroups,ou=Groups,dc=bpk2,dc=com"
manage
by
group.exact="cn=dnsAdmins,ou=domainGroups,ou=Groups,dc=bpk2,dc=com" write
by
group.exact="cn=dnsProcesses,ou=processGroups,ou=Groups,dc=bpk2,dc=com"
write
by * none
3 - dhcp engineers, admins and dhcp process accounts get access
{3}to dn.subtree="cn=DHCP Config,ou=Daemons,dc=bpk2,dc=com"
by
group.exact="cn=dhcpEngineers,ou=domainGroups,ou=Groups,dc=bpk2,dc=com"
manage
by
group.exact="cn=dhcpAdmins,ou=domainGroups,ou=Groups,dc=bpk2,dc=com" write
by
group.exact="cn=dhcpProcesses,ou=processGroups,ou=Groups,dc=bpk2,dc=com"
read
by * none
4 - dhcp engineers, admins and dhcp process accounts get access
{4}to dn.subtree="cn=DHCP Servers,ou=Daemons,dc=bpk2,dc=com"
by
group.exact="cn=dhcpEngineers,ou=domainGroups,ou=Groups,dc=bpk2,dc=com"
manage
by
group.exact="cn=dhcpAdmins,ou=domainGroups,ou=Groups,dc=bpk2,dc=com" write
by
group.exact="cn=dhcpProcesses,ou=processGroups,ou=Groups,dc=bpk2,dc=com"
read
by * none
5 - users can read this ou
{5}to dn.subtree="ou=Computers,dc=bpk2,dc=com"
by users read
by * none
6 - users can read this ou
{6}to dn.subtree="ou=Groups,dc=bpk2,dc=com"
by users read
by * none
7 - users can read this ou
{7}to dn.subtree="ou=Networks,dc=bpk2,dc=com"
by users read
by * none
8 - users can read this ou
{8}to dn.subtree="ou=Users,dc=bpk2,dc=com"
by users read
by * none
are there any specific ACLs that i should have? are there any glaring
issues with the above proposed ACLs?
5 years, 11 months
Openldap password problems
by jeevan kc
Hello all,We've just noticed that when a user authenticates via LDAP, it ignores characters after the right password. For example a user jkc900 has Password Welcome1 But the user can type in Welcome1111 or Welcome12 etc and still can get into the application. Its just checking the first Welcome1 and they can type anything after that and still can log in. We've tested at least 50 users and they all have the same issues. Any clues/ solution for this?
Your inputs are highly appreciated.
Jeevan
5 years, 11 months
OpenLDAP - 2.4.39 , 2-way multimaster replication freezes
by shashidhar v
Hi ,
I am trying to configure and use the openldap 2-WAY Multimaster Replication
setup for high availability(HA), but the HA solution used to freeze very
often. Using ansible tool I have automated the installation and
configuration steps. I tried with manual steps too before using the ansible
for the actual deployment
Following are the env. details used for installation and configuration
Two nodes ldap-test1 and ldap-test2 are running with base OS RHEL7
LDAP rpms installed:
openldap-clients-2.4.39-6.el7.x86_64
openldap-servers-2.4.39-6.el7.x86_64
openldap-2.4.39-6.el7.x86_64
Configuration steps:
1. Added the nis, cosine schemas
ldapadd -Y EXTERNAL -H ldapi:/// -D "cn=config" -f cosine.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -D "cn=config" -f nis.ldif
2. Send the new global configuration settings to slapd
'ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/global_config.ldif
# cat global_config.ldif
dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModuleLoad: syncprov
dn: olcOverlay=syncprov,olcDatabase={0}config,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=com
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=Manager,dc=example,dc=com
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}vAp3OToPGMYnWEkh+76RJEVyfCIdnsDg
dn: cn=config
changetype: modify
replace: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/openldap/certs/cacert.pem
dn: cn=config
changetype: modify
replace: olcTLSCertificateFile
olcTLSCertificateFile: /etc/openldap/certs/slapdcert.pem
dn: cn=config
changetype: modify
replace: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/openldap/certs/slapdkey.pem
dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: -1
dn: olcDatabase={1}monitor,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to * by
dn.base="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read by
dn.base="cn=Manager,dc=example,dc=com" read by * none
dn: cn=config
changeType: modify
add: olcServerID
olcServerID: 1
dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootDN
olcRootDN: cn=admin,cn=config
dn: cn=config
changetype: modify
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}vAp3OToPGMYnWEkh+76RJEVyfCIdnsDg
dn: cn=config
changetype: modify
replace: olcServerID
olcServerID: 1 ldaps://ldap-test1
olcServerID: 2 ldaps://ldap-test2
3. Load base.ldif
ldapadd -x -w redhat7 -D cn=Manager,dc=example,dc=com -f
/etc/openldap/base.ldif
# cat base.ldif
dn: dc=example,dc=com
dc: example
objectClass: top
objectClass: domain
dn: ou=People,dc=example,dc=com
ou: People
objectClass: top
objectClass: organizationalUnit
dn: ou=Group,dc=example,dc=com
ou: Group
objectClass: top
objectClass: organizationalUnit
4. Load hdb_config.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/hdb_config.ldif
#cat hdb_config.ldif
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSuffix
olcSuffix: dc=example,dc=com
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootDN
olcRootDN: cn=Manager,dc=example,dc=com
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {{ ldap_root_password.stdout }}
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcDbIndex
olcDbIndex: entryCSN eq
olcDbIndex: entryUUID eq
5. Load replication.ldif
ldapadd -Y EXTERNAL -H ldapi:/// -f /etc/openldap/replication.ldif
cat replication.ldif
dn: olcOverlay=syncprov,olcDatabase={2}hdb,cn=config
changetype: add
objectClass: olcOverlayConfig
objectClass: olcSyncProvConfig
olcOverlay: syncprov
dn: olcDatabase={2}hdb,cn=config
changetype: modify
replace: olcSyncRepl
olcSyncRepl: rid=101 provider=ldaps://ldap-test1
binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=redhat7
searchbase="dc=example,dc=com" type=refreshAndPersist interval=00:00:00:10
retry="5 5 300 5" timeout=1
olcSyncRepl: rid=102 provider=ldaps://ldap-test2
binddn="cn=Manager,dc=example,dc=com" bindmethod=simple credentials=redhat7
searchbase="dc=example,dc=com" type=refreshAndPersist interval=00:00:00:10
retry="5 5 300 5" timeout=1
-
replace: olcMirrorMode
olcMirrorMode: TRUE
dn: olcDatabase={0}config,cn=config
changetype: modify
replace: olcSyncRepl
olcSyncRepl: rid=101 provider=ldaps://ldap-test1
binddn="cn=admin,cn=config" bindmethod=simple credentials=redhat7
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1
olcSyncRepl: rid=102 provider=ldaps://ldap-test2
binddn="cn=admin,cn=config" bindmethod=simple credentials=redhat7
searchbase="cn=config" type=refreshAndPersist retry="5 5 300 5" timeout=1
-
replace: olcMirrorMode
olcMirrorMode: TRUE
Above configuration steps 1 to 4 are executed parallely on both nodes ,
only step 5 ie. replication.ldif was executed serially one node after the
other
because parallel execution of step 5 causing the solution to freeze
Parallel execution on both nodes :
1. Added the nis, cosine schemas
2. Send the new global configuration settings to slapd
3. Load base.ldif
4. Load hdb_config.ldif , executed on any one of two nodes assuming that
content will replicated automatically on other node once the servers are
replicated
Serial execution : Executed on both nodes one after the other
5. Load replication.ldif
Sometimes LDAP replication is causing the solution to freeze and it may
hung during the deployment , after deployment or while executing some
basic ldap operations like ldapadd/modify/delete etc
1. First thing I would like to know Is there any specific order we need to
follow to avoid solution freeze or ldapadd command hung with two nodes
configuring parallely ?
2. Anything wrong with the configuration attributes used ? If so what
attributes I need to add/update to avoid the command/service hung during
configuration or after the deployment ?
3. To verify the high availability I used to stop ldap service any one of
the two nodes and send the ldap requests to other node, but sometimes the
restart of the service not bringing back the two nodes in Sync. And for
replication I am verifying based on number of connections established
between two servers ( min. 4 , 2 for config replication and 2 for db
replication )
And unittest to verify db replication by creating an ldap user on one
node and search & delete operations on the other node.
4. Whenever the basic ldap commands add/modify etc hung on any one node , I
used to restart the slapd service on the corresponding node, Is it the
right way ?
HA solution is working fine by configuring above steps in the given order,
ldap services are restarted and in Sync, but sometimes the solution used to
freeze when executing basic ldapadd commond on any one node
There are no specific error messages in the logs to understand the reason
for hung.
May 15 22:20:17 ldap-test2 slapd[8538]: daemon: epoll: listen=7
active_threads=0 tvp=zero
May 15 22:20:17 ldap-test2 slapd[8538]: daemon: epoll: listen=8
active_threads=0 tvp=zero
Always a single restart is also not helping to bring the servers back to
sync and available,
sometimes the number of tcp connections are 3 instead of required 4
connections
[root@ldap-test1 openldap]# netstat -a | grep ldaps
tcp 0 0 ldap-test1:ldaps 0.0.0.0:* LISTEN
tcp 0 0 ldap-test1:34854 ldap-test2:ldaps ESTABLISHED
tcp 0 0 ldap-test1:ldaps ldap-test2:48493 ESTABLISHED
tcp 0 0 ldap-test1:34856 ldap-test2:ldaps ESTABLISHED
Used to restart couple of times until 4 tcp connections are established and
servers are replicated properly
5. Can someone please help me to get rid of this situation ?
I didn't find any clue in the archived messages etc for similar kind of
problems.
Thanks & Regards,
Shashi
5 years, 11 months
Server is unwilling to perform trying to remove an overlay
by Angel L. Mateo
Hello,
I have a 2.4.31 openldap server (running in an ubuntu server 14.04)
using cn=config for configuration.
Now, I'm trying to remove an overlay from my database (ppolicy overlay
to be specific) and whenever I run the ldapmodify deleting the entry I get
ldap_delete: Server is unwilling to perform (53)
I have read in older posts in this list that delete operation is not
implemented in cn=config database. Is this still not implemented?
--
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información
y las Comunicaciones Aplicadas (ATICA)
http://www.um.es/atica
Tfo: 868887590
Fax: 868888337
5 years, 11 months
openldap 2.4.40 ldapserach limit
by PRATIK SINGAL
Hello
can any one help me out where to increase the ldapseach size limit.In
2.4.23 there was no issue when i used to search 100000 records but in
2.4.40 it gives me a error
[root@localhost ~]# ldapsearch -x -LLL -b "dc=example,dc=com" -s one
"objectclass" | grep ^dn: | wc -l
Size limit exceeded (4)
500
5 years, 11 months
