openldap-technical

openldap-technical@openldap.org

21 participants
9802 discussions

Q: index for operational attributes?
by Ulrich Windl 06 Jul '17

06 Jul '17

Hello! Should I really add an index for modifyTimestamp? I got "slapd[4021]: <= bdb_inequality_candidates: (modifyTimestamp) not indexed!" (No discussions on using BDB, please!) Regards, Ulrich

2 4

RE: client-pr option for meta backend
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Wednesday, July 05, 2017 5:39 PM +0000 laurent2.perrin(a)orange.com wrote: > To sum up: > > Client ==> openLdap (meta backend): Control header is in the searchRequest > OpenLDAP (meta backend) ==> Active Directory: Control header is in the > searchRequest Active Directory ==> OpenLDAP (meta backend): Control > header is in the searchResDone OpenLDAP (meta backend) ==> Client: > Control header is not in the searchResDone > > This control Header should not be passed to client ? No idea. The backend and that code are both experimental, and the author has since retired from the project. What's really necessary is for someone to adopt back-ldap/meta and join the project so development on them can continue. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: client-pr option for meta backend
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Wednesday, July 05, 2017 10:41 AM +0000 laurent2.perrin(a)orange.com wrote: > > > Hello, > > > > I have set up a meta backend with OpenLDAP 2.4.42 on an Ubuntu Server > 16.04. > > > > This is working with some ldapsearch but meta directory will be used by a > VMware vCenter. The vCenter LDAP client uses the pagedResultsControl, > which is disabled by default for the meta backend (according to the > slapd-meta documentation). Hi Luarent, The client-pr code is currently ifdef'd behind LDAP_DEVEL, which means it is not enabled by default. It appears there is a bug here, in that either the feature should be moved out from being behind LDAP_DEVEL or the documentation should be removed from the man page. If you need use of this feature, you need to define SLAPD_META_CLIENT_PR when compiling OpenLDAP. >From back-meta.h: #ifdef LDAP_DEVEL #define SLAPD_META_CLIENT_PR 1 #endif /* LDAP_DEVEL */ --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 05 Jul '17

05 Jul '17

--On Wednesday, July 05, 2017 1:39 AM -0400 btb <btb(a)bitrate.net> wrote: > i've also increased accesslog data retention from 7 days to 14 days, as a > bit of a compensation for the infrequent writes, and i'll implement a > "no-op" cron job as well, as a fail safe. are then any pitfalls i may > not be considering with a 14 day accesslog retention period? is that too > long according to "typical" consensus? It really depends on your specific usage. It's defined as a configurable so it can be adjusted to match the reality of a given deployment. :) --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: redMod with single colon
by Ondřej Kuzník 05 Jul '17

05 Jul '17

On Wed, Jul 05, 2017 at 01:48:06PM +0200, Ulrich Windl wrote: > Ondrej Kuzník <ondra(a)mistotebe.net> schrieb am 28.06.2017 um 17:51 in >> Hi, >> this is intended and how the issue in ITS#6545 has been fixed. >> >> The operation you are looking at has removed some values, then added >> other values for the same attribute straight away as another modify >> within the same op. > > What would break if those "Og==" lines were omitted? ITS#6545: interrupted replication/potential desynchronisation, depending on the operation. See the related changes to the test suite (test063). Regards, -- Ondřej Kuzník Senior Software Engineer Symas Corporation http://www.symas.com Packaged, certified, and supported LDAP solutions powered by OpenLDAP

1 0

client-pr option for meta backend
by laurent2.perrin＠orange.com 05 Jul '17

05 Jul '17

Hello, I have set up a meta backend with OpenLDAP 2.4.42 on an Ubuntu Server 16.04. This is working with some ldapsearch but meta directory will be used by a VMware vCenter. The vCenter LDAP client uses the pagedResultsControl, which is disabled by default for the meta backend (according to the slapd-meta documentation). I tried to enable it with the "olcDbClientPr" option, with this ldif file: dn: olcDatabase={2}meta,cn=config changetype: modify add: olcDbClientPr olcDbClientPr: accept-unsolicited But I get this error message: modifying entry "olcDatabase={2}meta,cn=config" ldap_modify: Other (e.g., implementation specific) error (80) additional info: <olcDbClientPr> handler exited with -1026 Here is the configuration of the meta backend: dn: olcDatabase={2}meta objectClass: olcDatabaseConfig objectClass: olcMetaConfig olcDatabase: {2}meta olcSuffix: dc=meta,dc=local olcLastMod: FALSE olcRootDN: cn=manager,dc=meta,dc=local olcRootPW:: e1NTSEF9S3VmQ2VFUEhUV2tyWWRkQnZLVUdkbEp4QSt6UDU2Zmk= structuralObjectClass: olcMetaConfig entryUUID: 7115068a-f1bb-1036-8e31-07775d6d5e9e creatorsName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth createTimestamp: 20170630083957Z olcSizeLimit: 30000 olcLimits: {0}users size.prtotal=1000 pr.size=1000 entryCSN: 20170704141941.224315Z#000000#000#000000 modifiersName: gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth Is something wrong with this type of configuration ? Regards, [cid:image001.gif@01CBF2E5.34FD28F0] Laurent PERRIN Service Infra aux Projets Orange Applications for Business SCE/OAB/DPO/DT/SF/CLOUDS tel. +33 4 37 24 62 85 Mob : 07 84 12 78 79 laurent2.perrin(a)orange.com<mailto:laurent2.perrin@orange.com> 139 rue Vendôme 69006 Lyon www.orange-business.com<http://www.orange-business.com/> [cid:image002.gif@01CBF2E5.34FD28F0] _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you.

1 0

Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount 04 Jul '17

04 Jul '17

--On Thursday, June 29, 2017 1:41 PM -0400 btb <btb(a)bitrate.net> wrote: > > > On 6/29/17 11:15 AM, Quanah Gibson-Mount wrote: >> --On Thursday, June 29, 2017 2:12 AM -0400 btb <btb(a)bitrate.net> wrote: >> >>> i see, thanks. i tested this, and did a modify on each, but didn't see >>> replication resume. emulating the syncrepl connection with a manual >>> search against each master, there do seem to be accesslog entries now, >>> on both masters: >> >> You may have to restart the consumers (I did when I ran into this). > > i did try a restart on both, but they returned to the same state > >> Also, there are 2 sets of CSNs per master that you need to examine -- >> The CSNs in your database root (i.e., dc=example,dc=org) and your >> accesslog root. > > that would be these, right? > > dsa1 cn=accesslog: > 20161019002438.652359Z#000000#000#000000 > 20170521175113.974560Z#000000#002#000000 > 20170530214415.204052Z#000000#001#000000 > > dsa1 dc=example,dc=org: > 20170520031415.276678Z#000000#000#000000 > 20170530214231.171959Z#000000#002#000000 > 20170530214415.204052Z#000000#001#000000 > > dsa2 cn=accesslog: > 20170520031415.276678Z#000000#000#000000 > 20170521175113.974560Z#000000#002#000000 > 20170628034119.327974Z#000000#001#000000 > > dsa2 dc=example,dc=org: > 20170520031415.276678Z#000000#000#000000 > 20170619014933.531051Z#000000#002#000000 > 20170628034119.327974Z#000000#001#000000 > > why are there three per db, and which is suppose to match which? wow, that's a mess. So #000# is serverID 0, which would be for any entries prior to moving to MMR. The fact that you have different values for #000# on dsa1 accesslog vs the other 3 databases is disturbing. It would appear DSA1 is serverID 1, and its CSNs make sense: 20170530214415.204052Z#000000#001#000000 20170530214415.204052Z#000000#001#000000 However, there's someting serious wrong with dsa2 (assuming it is serverID 2): 20170521175113.974560Z#000000#002#000000 20170619014933.531051Z#000000#002#000000 As this implies the primary DB received a write on 2017/06/19 @ 01:49:33, but the accesslog has not recorded this change, as it says the last time there was a write op to the accesslog DB on #002# was 2017/05/21 @ 17:51:13, nearly a month earlier. So it doesn't seem to think you've done a write op directly against serverID 002. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: package OpenLDAP and lmdb
by Howard Chu 04 Jul '17

04 Jul '17

Michael Ströder wrote: > HI! > > What's the recommendation for keeping package builds for OpenLDAP and mdb_* tools in sync? > > Use the OpenLDAP 2.4.x release and build from there? Sure, the latest LMDB release is always included in the latest OpenLDAP 2.4 release. > AFAICS LTB builds are made like this but they use a different prefix and therefore don't > have a collision with packages coming from OS package upstream. > > Ciao, Michael. > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

package OpenLDAP and lmdb
by Michael Ströder 03 Jul '17

03 Jul '17

HI! What's the recommendation for keeping package builds for OpenLDAP and mdb_* tools in sync? Use the OpenLDAP 2.4.x release and build from there? AFAICS LTB builds are made like this but they use a different prefix and therefore don't have a collision with packages coming from OS package upstream. Ciao, Michael.

1 0

Re: [Q] can I replicate several branches to the same slave from one master?
by Quanah Gibson-Mount 03 Jul '17

03 Jul '17

--On Friday, June 30, 2017 9:08 AM +0300 Zeus Panchenko <zeus(a)ibs.dn.ua> wrote: > Quanah Gibson-Mount <quanah(a)symas.com> wrote: >> >> Wouldn't it be simpler to define ACLs on the master that limit what >> the replication identity has access to that matches your filters? >> > > emm ... I was sure I can not do that on the master side ... just I try > do that, I receive full data ... Then likely your ACLs were incorrect? > looks like some more permittive acl works for the replica ... can I > somehow know which acl matched the replica? But I was trying to place > replABC ACLs to the end of the list and still was not able to limit data > according the filter I suggest reading the slapd.access(5) man page and the OpenLDAP Admin guide. As clearly noted in the documentation, ACLs (generally) stop processing on the *first* match. So, depending on your ACLs, adding your ACLS at the end of the list probably meant they were never evaluated. >> I would also note that your stanza limiting what attrs are replicated >> is missing the operational attributes that are necessary for sync >> replication to function, so I would fully expect errors. > > do you mean entryCSN and entryUUID ? Yes, sorry, I missed them at the start of the list of attributes. ;) So that part seems ok. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical