OpenLDAP ldapsearch issue
by Shashi Ranjan
Hi,
I have a problem in OpenLDAP 2.4.11 with BDB backend.
I search an LDIF entry using ldapsearch command. It is giving me correct result and fetching the entry as given below.
ldapsearch -x -D cn=Manager,dc=my-domain,dc=COM -w secret -b ou=TEST,ou=people,dc=my-domain,dc=COM -s sub '(&(objectClass=organizationalUnit)(ou=test*))' -H ldap://localhost:1399
# extended LDIF
#
# LDAPv3
# base <ou=TEST,ou=people,dc=my-domain,dc=COM> with scope subtree
# filter: (objectclass=organizationalUnit)
# requesting: ALL
#
# TEST, people, my-domain.COM
dn: ou=TEST,ou=people,dc=my-domain,dc=COM
ou: TEST
companyName: test
objectClass: top
objectClass: organizationalUnit
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
But when I am searching the same request from ldapbrowser it is giving me error code 32 - No Such object.
Below is the short dump of slapd debugging logs:
############################################################################################
SRCH "ou=people,dc=my-domain,dc=COM" 1 0 20000 3600 0
begin get_filter
AND
begin get_filter_list
begin get_filter
EQUALITY
ber_scanf fmt ({mm}) ber:
ber_dump: buf=0x8f59820 ptr=0x8f59856 end=0x8f59903 len=173
0000: a3 21 04 0b 6f 62 6a 65 63 74 43 6c 61 73 73 04 .!..objectClass.
0010: 12 6f 72 67 61 6e 69 7a 61 74 69 6f 6e 61 6c 55 .organizationalU
0020: 6e 69 74 a4 0c 04 02 6f 75 30 06 80 04 54 4f 55 nit....ou0...TES
0030: 53 30 7a 04 02 6f 75 04 0b 63 6f 6d 70 61 6e 79 T0z..ou..company
0040: 4e 61 6d 65 04 08 63 6f 64 65 44 49 53 45 04 11 Name..codeDISE..
0050: 66 72 65 65 4c 61 62 65 6c 61 64 64 49 6e 66 6f freeLabeladdInfo
0060: 31 04 11 66 72 65 65 4c 61 62 65 6c 61 64 64 49 1..freeLabeladdI
0070: 6e 66 6f 32 04 11 66 72 65 65 4c 61 62 65 6c 61 nfo2..freeLabela
0080: 64 64 49 6e 66 6f 33 04 11 66 72 65 65 4c 61 62 ddInfo3..freeLab
0090: 65 6c 61 64 64 49 6e 66 6f 34 04 11 66 72 65 65 eladdInfo4..free
00a0: 4c 61 62 65 6c 61 64 64 49 6e 66 6f 35 LabeladdInfo5
end get_filter 0
begin get_filter
SUBSTRINGS
begin get_ssa
ber_scanf fmt ({m) ber:
ber_dump: buf=0x8f59820 ptr=0x8f59879 end=0x8f59903 len=138
0000: 00 0c 04 02 6f 75 30 06 80 04 54 4f 55 53 30 7a ....ou0...test0z
0010: 04 02 6f 75 04 0b 63 6f 6d 70 61 6e 79 4e 61 6d ..ou..companyNam
0020: 65 04 08 63 6f 64 65 44 49 53 45 04 11 66 72 65 e..codeDISE..fre
0030: 65 4c 61 62 65 6c 61 64 64 49 6e 66 6f 31 04 11 eLabeladdInfo1..
0040: 66 72 65 65 4c 61 62 65 6c 61 64 64 49 6e 66 6f freeLabeladdInfo
0050: 32 04 11 66 72 65 65 4c 61 62 65 6c 61 64 64 49 2..freeLabeladdI
0060: 6e 66 6f 33 04 11 66 72 65 65 4c 61 62 65 6c 61 nfo3..freeLabela
0070: 64 64 49 6e 66 6f 34 04 11 66 72 65 65 4c 61 62 ddInfo4..freeLab
0080: 65 6c 61 64 64 49 6e 66 6f 35 eladdInfo5
ber_scanf fmt (m) ber:
ber_dump: buf=0x8f59820 ptr=0x8f59881 end=0x8f59903 len=130
0000: 80 04 54 4f 55 53 30 7a 04 02 6f 75 04 0b 63 6f ..test0z..ou..co
0010: 6d 70 61 6e 79 4e 61 6d 65 04 08 63 6f 64 65 44 mpanyName..codeD
0020: 49 53 45 04 11 66 72 65 65 4c 61 62 65 6c 61 64 ISE..freeLabelad
0030: 64 49 6e 66 6f 31 04 11 66 72 65 65 4c 61 62 65 dInfo1..freeLabe
0040: 6c 61 64 64 49 6e 66 6f 32 04 11 66 72 65 65 4c laddInfo2..freeL
0050: 61 62 65 6c 61 64 64 49 6e 66 6f 33 04 11 66 72 abeladdInfo3..fr
0060: 65 65 4c 61 62 65 6c 61 64 64 49 6e 66 6f 34 04 eeLabeladdInfo4.
0070: 11 66 72 65 65 4c 61 62 65 6c 61 64 64 49 6e 66 .freeLabeladdInf
0080: 6f 35 o5
INITIAL
end get_ssa
end get_filter 0
end get_filter_list
end get_filter 0
filter: (&(objectClass=organizationalUnit)(ou=test*))
ber_scanf fmt ({M}}) ber:
ber_dump: buf=0x8f59820 ptr=0x8f59887 end=0x8f59903 len=124
0000: 00 7a 04 02 6f 75 04 0b 63 6f 6d 70 61 6e 79 4e .z..ou..companyN
0010: 61 6d 65 04 08 63 6f 64 65 44 49 53 45 04 11 66 ame..codeDISE..f
0020: 72 65 65 4c 61 62 65 6c 61 64 64 49 6e 66 6f 31 reeLabeladdInfo1
0030: 04 11 66 72 65 65 4c 61 62 65 6c 61 64 64 49 6e ..freeLabeladdIn
0040: 66 6f 32 04 11 66 72 65 65 4c 61 62 65 6c 61 64 fo2..freeLabelad
0050: 64 49 6e 66 6f 33 04 11 66 72 65 65 4c 61 62 65 dInfo3..freeLabe
0060: 6c 61 64 64 49 6e 66 6f 34 04 11 66 72 65 65 4c laddInfo4..freeL
0070: 61 62 65 6c 61 64 64 49 6e 66 6f 35 abeladdInfo5
attrs: ou companyName codeDISE freeLabeladdInfo1 freeLabeladdInfo2 freeLabeladdInfo3 freeLabeladdInfo4 freeLabeladdInfo5
conn=1 op=1 SRCH base="ou=people,dc=my-domain,dc=COM" scope=1 deref=0 filter="(&(objectClass=organizationalUnit)(ou=test*))"
conn=1 op=1 SRCH attr=ou companyName codeDISE freeLabeladdInfo1 freeLabeladdInfo2 freeLabeladdInfo3 freeLabeladdInfo4 freeLabeladdInfo5
=> bdb_search
bdb_dn2entry("ou=people,dc=my-domain,dc=com")
=> access_allowed: disclose access to "dc=my-domain,dc=COM" "entry" requested
<= root access granted
=> access_allowed: disclose access granted by manage(=mwrscxd)
send_ldap_result: conn=1 op=1 p=3
send_ldap_result: err=10 matched="dc=my-domain,dc=COM" text=""
send_ldap_response: msgid=4803 tag=101 err=32
ber_flush2: 31 bytes to sd 13
0000: 30 1d 02 02 12 c3 65 17 0a 01 20 04 10 64 63 3d 0.....e... ..dc=
0010: 4f 52 41 4e 47 45 2c 64 63 3d 43 4f 4d 04 00 my-domain,dc=COM..
ldap_write: want=31, written=31
0000: 30 1d 02 02 12 c3 65 17 0a 01 20 04 10 64 63 3d 0.....e... ..dc=
0010: 4f 52 41 4e 47 45 2c 64 63 3d 43 4f 4d 04 00 my-domain,dc=COM..
conn=1 op=1 SEARCH RESULT tag=101 err=32 nentries=0 text=
daemon: activity on 1 descriptor
daemon: activity on: 13r
daemon: read active on 13
############################################################################################
Can you please tell me what is the problem in these two?
Thanks
Shashi Ranjan
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
6 years, 8 months
RE: Antw: replication issue with MDB in ldapadd
by Gurjot Kaur
Yes, I agree with you. My basic question is that how come the same scenario is supported in the older version but not in latest OpenLDAP 2.4.44 with MDB backend.
During this scenario, contextCSNs of both the MM1 and MM2 get updated correctly on MDB (OpenLDAP 2.4.44) and BDB (OpenLDAP 2.4.11)
See below the contextCSN values of MM1 and MM2.
#########################
MM1 on BDB (OpenLDAP 2.4.11)
#########################
contextCSN: 20160718052917.405929Z#000000#000#000000
contextCSN: 20160718053109.639168Z#000000#001#000000
contextCSN: 20160718053249.495430Z#000000#002#000000
#########################
MM2 on BDB (OpenLDAP 2.4.11)
#########################
contextCSN: 20160718052917.405929Z#000000#000#000000
contextCSN: 20160718053249.495430Z#000000#002#000000
contextCSN: 20160718053109.639168Z#000000#001#000000
#########################
MM1 on MDB (OpenLDAP 2.4.44)
#########################
contextCSN: 20160717234101.093387Z#000000#000#000000
contextCSN: 20160717234320.498152Z#000000#001#000000
contextCSN: 20160717234453.544103Z#000000#002#000000
#########################
MM2 on MDB (OpenLDAP 2.4.44)
#########################
contextCSN: 20160717234101.093387Z#000000#000#000000
contextCSN: 20160717234320.498152Z#000000#001#000000
contextCSN: 20160717234453.544103Z#000000#002#000000
>From the contextCSNs values on both backends I got that MM1 and MM2 are in sync.
When I did slapcat on BDB, I found that LDIF entries with entryCSN equals to three contextCSN with i.e. server id #000, #001 and #002 are present in the LDIF files (attached files 'slapcatExportMM1_BDB.ldif' and 'slapcatExportMM2_BDB.ldif').
When I did slapcat on MDB, I found that LDIF entries with entryCSN equals to contextCSN with i.e. server id #000 and #002 are present in the LDIF file (exported file) but LDIF with entryCSN equals to contextCSN with server id #001 is not present in LDIF files (attached files 'slapcatExportMM1_MDB.ldif' and 'slapcatExportMM2_MDB.ldif').
Is it possible that contextCSN value is updated in the MDB but LDIF entry is not present in the DB corresponding to the same contextCSN?
Thanks
Gurjot Kaur
-----Original Message-----
From: Ulrich Windl [mailto:Ulrich.Windl@rz.uni-regensburg.de]
Sent: Friday, July 15, 2016 4:56 PM
To: Gurjot Kaur <gurjot.kaur(a)aricent.com>; openldap-technical(a)openldap.org
Subject: Antw: replication issue with MDB in ldapadd
>>> Gurjot Kaur <gurjot.kaur(a)aricent.com> schrieb am 15.07.2016 um 11:39
>>> in
Nachricht
<KL1PR04MB1205CDDF22D4A812AA099785E1330(a)KL1PR04MB1205.apcprd04.prod.outlook.com>
> Hello,
>
> I have encountered with a problem in OpenLDAP2.4.44 with MDB backend.
> I have two LDAP servers in Multi Master Mode MM1 and MM2. I am doing
> the following steps:
> 1. Both the LDAP DBs MM1 and MM2 have existing LDIF entries.
> 2.Start MM1. Stop MM2.
> 3. Add an entry A to MM1 using ldapadd. Stop MM1.
> 4. Start MM2. Add LDIF entry B to MM2 using ldapadd.
> 5. Start MM1.
>
> I am getting the below result.
> The last added entry i.e. B in MM2 gets replicated to MM1. But LDIF
> entry A doesn't get replicated to MM2.
> But this scenario works fine in OpenLDAP 2.4.11 with BDB backend. It
> replicates entry A to MM2 and entry B to MM1 correctly.
>
> How the above scenario with MBD in 2.4.44 can be avoided? As this is
> very common scenario.
It is a very common scenario that both LDAP servers are down at the same time? It is very common that one server is down?
I think replication basically works like this: If a consumer gets an update from a provider, it is assumed to be up to date regarding that provider. I'm not sure whether your situation can be resolved.
Ulrich
>
> Thanks
> Gurjot Kaur
>
> "DISCLAIMER: This message is proprietary to Aricent and is intended
> solely for the use of the individual to whom it is addressed. It may
> contain privileged or confidential information and should not be
> circulated or used for any purpose other than for what it is intended.
> If you have received this message in error, please notify the
> originator immediately. If you are not the intended recipient, you are
> notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message.
> Aricent accepts no responsibility for loss or damage arising from the
> use of the information transmitted by this email including damage from virus."
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
6 years, 8 months
sssd.conf bug using parameter ldap_uri
by Kaveh Ehsani
I have filed this bug report with centos as I believe sssd has a bug with regard to ldap_uri as it does not change value affter initial starting of sssd, another words when I change the ldap_uri to another server and restart sssd it maintains the original value. Wonder if anyone else has the same encountered the same problem.
Within sssd.conf on the client side of a ldapserver I have set :
ldap_uri = simple-provider.example.com
ldap_backup_uri = clone-provider.example.com
It works fine, but when I take down the simple-provider.example.com (all are virtual boxes), it fails to change over to the back up or secondary which is clone-provider.example.com.
I clean the cahce sss_cache -E, I delete all the files under /var/lib/sss/db, and I even change the ldap_uri = clone-provider.example.com and restart sssd I still have :
[838cb2] <group/member="root"> ldap_start_tls_s() failed (uri=ldaps://simple-provider.example.com): Can't contact LDAP server: Transport endpoint
It is still looking at the old server simple-provider and not clone-provider. It seems once set, it can not be reconfigured.
Steps To Reproduce On a virtual box, inside /etc/sssd/sssd.conf
ldap_uri = simple-provider.example.com
ldap_backup_uri = clone-provider.example.com
initially, and start sssd, then either swith them or simply put ldap_uri = clone-provider.example.com and restart sssd, the uri = .... does not change.
Additional Information authconfig --ldapserver=simple-provider.example,clone-provider.example.com has the same issue, but if you switch the two servers it will accept the first one. sssd does not seem to do so.
This is the link for authconfig bug report on redhat:
https://bugzilla.redhat.com/show_bug.cgi?id=1142830 [^<https://bugzilla.redhat.com/show_bug.cgi?id=1142830>]
6 years, 8 months
replication issue with MDB in ldapadd
by Gurjot Kaur
Hello,
I have encountered with a problem in OpenLDAP2.4.44 with MDB backend.
I have two LDAP servers in Multi Master Mode MM1 and MM2. I am doing the following steps:
1. Both the LDAP DBs MM1 and MM2 have existing LDIF entries.
2.Start MM1. Stop MM2.
3. Add an entry A to MM1 using ldapadd. Stop MM1.
4. Start MM2. Add LDIF entry B to MM2 using ldapadd.
5. Start MM1.
I am getting the below result.
The last added entry i.e. B in MM2 gets replicated to MM1. But LDIF entry A doesn't get replicated to MM2.
But this scenario works fine in OpenLDAP 2.4.11 with BDB backend. It replicates entry A to MM2 and entry B to MM1 correctly.
How the above scenario with MBD in 2.4.44 can be avoided? As this is very common scenario.
Thanks
Gurjot Kaur
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
6 years, 8 months
ContextCSN doesn't get updated correctly
by Gurjot Kaur
Hi,
I have a doubt in the difference of contextCSN of two OpenLDAP servers where one is installed with BDB backend (version 2.4.11) and the other one is installed with MDB backend (version 2.4.44).
An LDIF entry "dn: ou=grp_71,ou=people,dc=my-domain,dc=com" was already existing in both the DBs.
The following two LDIF entries were added again using slapadd with -w option enabled.
dn: ou=grp_71,ou=people,dc=my-domain,dc=com [ Old entry ]
dn: ou=alpha,ou=people,dc=my-domain,dc=com [ New entry ]
In BDB backend LDAP server, contextCSN gets updated with the latest added entryCSN ( i.e. entryCSN of "dn: ou=alpha,ou=people,dc=my-domain,dc=com").
But in MDB backend LDAP server, contextCSN doesn't get updated with the latest added entryCSN. Rather it still has the old entryCSN value ( i.e. entryCSN of "dn: ou=grp_71,ou=people,dc=my-domain,dc=com")
Please let me know, why is it so? Is this correct?
Below is the short dump of slapcat from both the servers.
###################################################
BDB backend (version 2.4.11)
###################################################
dn: dc=my-domain,dc=com
dc: my-domain
objectClass: dcObject
objectClass: organization
o: my-domain
structuralObjectClass: organization
entryUUID: 3a896474-dba7-1035-95f9-abdba6d92f92
creatorsName: cn=Manager,dc=my-domain,dc=com
createTimestamp: 20160711113452Z
entryCSN: 20160711113452.876767Z#000000#000#000000
modifiersName: cn=Manager,dc=my-domain,dc=com
modifyTimestamp: 20160711113452Z
contextCSN: 20160711113900.374218Z#000000#000#000000
dn: cn=Manager,dc=my-domain,dc=com
objectClass: organizationalRole
cn: Manager
structuralObjectClass: organizationalRole
entryUUID: 3a8ae100-dba7-1035-95fa-abdba6d92f92
creatorsName: cn=Manager,dc=my-domain,dc=com
createTimestamp: 20160711113452Z
entryCSN: 20160711113452.886601Z#000000#000#000000
modifiersName: cn=Manager,dc=my-domain,dc=com
modifyTimestamp: 20160711113452Z
dn: ou=people,dc=my-domain,dc=com
ou: people
objectClass: organizationalUnit
objectClass: top
companyName: aricent
structuralObjectClass: organizationalUnit
entryUUID: 3a8b836c-dba7-1035-95fb-abdba6d92f92
creatorsName: cn=Manager,dc=my-domain,dc=com
createTimestamp: 20160711113452Z
entryCSN: 20160711113452.890761Z#000000#000#000000
modifiersName: cn=Manager,dc=my-domain,dc=com
modifyTimestamp: 20160711113452Z
dn: ou=grp_71,ou=people,dc=my-domain,dc=com
ou: grp_71
objectClass: organizationalUnit
companyName: aricent4
structuralObjectClass: organizationalUnit
entryUUID: 9231b848-dba7-1035-9211-3f7458963df7
creatorsName: cn=Manager,dc=my-domain,dc=com
createTimestamp: 20160711113719Z
entryCSN: 20160711113719.941790Z#000000#000#000000
modifiersName: cn=Manager,dc=my-domain,dc=com
modifyTimestamp: 20160711113719Z
dn: ou=alpha,ou=people,dc=my-domain,dc=com
ou: alpha
objectClass: organizationalUnit
companyName: aricent2
structuralObjectClass: organizationalUnit
entryUUID: ce0e7de2-dba7-1035-86a6-852dc551e076
creatorsName: cn=Manager,dc=my-domain,dc=com
createTimestamp: 20160711113900Z
entryCSN: 20160711113900.374218Z#000000#000#000000
modifiersName: cn=Manager,dc=my-domain,dc=com
modifyTimestamp: 20160711113900Z
###################################################
MDB backend (version 2.4.44)
###################################################
dn: dc=my-domain,dc=com
dc: my-domain
objectClass: dcObject
objectClass: organization
o: my-domain
structuralObjectClass: organization
entryUUID: 95197aa4-db76-1035-8cd9-9f963a69ea08
creatorsName: cn=Manager,dc=my-domain,dc=com
createTimestamp: 20160711054639Z
entryCSN: 20160711054639.476247Z#000000#000#000000
modifiersName: cn=Manager,dc=my-domain,dc=com
modifyTimestamp: 20160711054639Z
contextCSN: 20160711054904.666167Z#000000#000#000000
dn: cn=Manager,dc=my-domain,dc=com
objectClass: organizationalRole
cn: Manager
structuralObjectClass: organizationalRole
entryUUID: 951bbbde-db76-1035-8cda-9f963a69ea08
creatorsName: cn=Manager,dc=my-domain,dc=com
createTimestamp: 20160711054639Z
entryCSN: 20160711054639.491130Z#000000#000#000000
modifiersName: cn=Manager,dc=my-domain,dc=com
modifyTimestamp: 20160711054639Z
dn: ou=people,dc=my-domain,dc=com
ou: people
objectClass: organizationalUnit
objectClass: top
companyName: aricent
structuralObjectClass: organizationalUnit
entryUUID: 951d7f64-db76-1035-8cdb-9f963a69ea08
creatorsName: cn=Manager,dc=my-domain,dc=com
createTimestamp: 20160711054639Z
entryCSN: 20160711054639.502690Z#000000#000#000000
modifiersName: cn=Manager,dc=my-domain,dc=com
modifyTimestamp: 20160711054639Z
dn: ou=grp_71,ou=people,dc=my-domain,dc=com
ou: grp_71
objectClass: organizationalUnit
companyName: aricent4
structuralObjectClass: organizationalUnit
entryUUID: eba3afca-db76-1035-9667-b5e8d6738a99
creatorsName: cn=Manager,dc=my-domain,dc=com
createTimestamp: 20160711054904Z
entryCSN: 20160711054904.666167Z#000000#000#000000
modifiersName: cn=Manager,dc=my-domain,dc=com
modifyTimestamp: 20160711054904Z
dn: ou=alpha,ou=people,dc=my-domain,dc=com
ou: alpha
objectClass: organizationalUnit
companyName: aricent2
structuralObjectClass: organizationalUnit
entryUUID: 27ed19c6-db77-1035-82e2-f54af7597a9e
creatorsName: cn=Manager,dc=my-domain,dc=com
createTimestamp: 20160711055045Z
entryCSN: 20160711055045.810589Z#000000#000#000000
modifiersName: cn=Manager,dc=my-domain,dc=com
modifyTimestamp: 20160711055045Z
Please let me know, why is it so? Is this correct?
Best Regards,
Gurjot Kaur
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
6 years, 8 months
AttributeType not found but I have this attribute
by Jose Legido
Hello.
I'm trying to modify schema (importing from AD) but i have a problem
whith some objectclasses:
ldap_initialize( ldapi:///??base )
add olcobjectClasses:
( 1.2.840.113556.1.5.263 NAME 'msImaging-PostScanProcess' SUP top
STRUCTURAL MUST ( displayName $ msImaging-PSPIdentifier ) MAY
(serverName $ msImaging-PSPString ) )
modifying entry "cn={1}core,cn=schema,cn=config"
modify complete
But when I do a test:
57850fb8 olcObjectClasses: value #447 olcObjectClasses: AttributeType
not found: "displayName"
57850fb8 config error processing cn={1}core,cn=schema,cn=config:
olcObjectClasses: AttributeType not found: "displayName"
slaptest: bad configuration file!
But I have this attribute:
ldapsearch -LLL -H ldap://127.0.0.1 -x -s base -b "CN=Subschema"
attributetypes -v
attributeTypes: ( 2.16.840.1.113730.3.1.241 NAME 'displayName' DESC 'RFC2798:
preferred name to be used when displaying entries' EQUALITY caseIgnoreMatch S
UBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-V
ALUE )
I have openldap 2.4.40 with mode config and inetorgperson.ldif in cn=schema
Thank you!
6 years, 8 months
ContextCSN showing Junk Characters
by scn_73＠yahoo.com
Hi,
My ldapmaster ContextCSN showing Junk Characters. Please advice how can reset to valid one.
contextCSN:: 0CKRuTQrAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA=
CentOS 5.8Openldap Version is OpenLDAP: slapd 2.3.43
- Sachin
6 years, 8 months
How does a client changes from provider to consumer when provider is down
by Kaveh Ehsani
I have setup a provider/replicator(consumer) with a client and all functioning well. Except when I switch off the provider, the client does not read from the consumer. Of course I have not told the client to do so any where, not sure where to do this. I can set it up manually but there has to be a way for a switch to take place automatically. Thanks, for all the feedbacks.
6 years, 8 months
MDB data replication issues
by Gurjot Kaur
Hi,
I am using a OpenLDAP 2.4.44 Multi master configuration with two slapd servers, master and replica using MDB backend. I got a problem in replicating when the data is added using slapadd.
I have two slapd with ports 2016 and 2017. slapd.conf file for both the servers are attached.
Scenario 1:
When an LDIF entry is added using ldapadd or deleted using ldapdelete, it gets replicated in the replica server correctly.
Below is the ldapsearch result om Master server:
GURKES254 linus> ldapsearch -h xx.xx.xx.xx -p 2016 -b "dc=my-domain,dc=com" "ou=Test9"
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=com> with scope subtree
# filter: ou=Test9
# requesting: ALL
#
# Test9, people, my-domain.com
dn: ou=Test9,ou=people,dc=my-domain,dc=com
ou: Test9
objectClass: organizationalUnit
companyName: Test9Grp
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Below is the ldapsearch result om replica server:
GURKES254 linus> ldapsearch -h xx.xx.xx.xx -p 2017 -b "dc=my-domain,dc=com" "ou=Test9"
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=com> with scope subtree
# filter: ou=Test9
# requesting: ALL
#
# Test9, people, my-domain.com
dn: ou=Test9,ou=people,dc=my-domain,dc=com
ou: Test9
objectClass: organizationalUnit
companyName: Test9Grp
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Scenario 2:
When an LDIF entry is imported using slapadd, it doesn't get replicated in the replica server at all.
Below is the ldapsearch result om Master server:
GURKES254 linus> ldapsearch -h xx.xx.xx.xx -p 2016 -b "dc=my-domain,dc=com" "ou=Test9"
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=com> with scope subtree
# filter: ou=Test9
# requesting: ALL
#
# Test9, people, my-domain.com
dn: ou=Test9,ou=people,dc=my-domain,dc=com
ou: Test9
objectClass: organizationalUnit
companyName: Test9Grp
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
Below is the ldapsearch result om replica server:
GURKES254 linus> ldapsearch -h xx.xx.xx.xx -p 2017 -b "dc=my-domain,dc=com" "ou=Test9"
# extended LDIF
#
# LDAPv3
# base <dc=my-domain,dc=com> with scope subtree
# filter: ou=Test9
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
Please let me know in case any other information is required.
Br
Gurjot Kaur
"DISCLAIMER: This message is proprietary to Aricent and is intended solely for the use of the individual to whom it is addressed. It may contain privileged or confidential information and should not be circulated or used for any purpose other than for what it is intended. If you have received this message in error, please notify the originator immediately. If you are not the intended recipient, you are notified that you are strictly prohibited from using, copying, altering, or disclosing the contents of this message. Aricent accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus."
6 years, 8 months
