RE: Using TLS
by Quanah Gibson-Mount
--On Monday, June 26, 2017 4:59 PM +0000 Daniel Le <daniel.le(a)exfo.com>
wrote:
> int opt;
> opt = LDAP_OPT_X_TLS_NEVER;
> ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, &opt);
>
> -And-
>
> int new_ctx = 0;
> ldap_set_option(ld, LDAP_OPT_X_TLS_NEWCTX, &new_ctx);
Hi Daniel,
This case is specifically tested in my TLS test suite in test067. It works
correctly, as expected. I would note that I use ldap_int_tls_config
(RE24)/ldap_pvt_tls_config (2.5/master) for setting
LDAP_OPT_X_TLS_REQUIRE_CERT rather than ldap_set_option.
--Quanah
--
Quanah Gibson-Mount
Product Architect
Symas Corporation
Packaged, certified, and supported LDAP solutions powered by OpenLDAP:
<http://www.symas.com>
6 years, 4 months
Slave won't send referrals
by Jon C Kidder
Ok, this should be simple right? I have a 2.4.44 slave with olcUpdateRef pointing to the master. Replication works fine and the slave reflects any changes made to the master. The slave is also accepting modify operations without complaining and without returning a referral. I've compared my configuration with the configuration generated for test022. I have the needful extra stuff in my configuration and everything looks correct to me. I've attached the modify command line and result, the slave configuration, and the log of the operation for reference.
Any insight into what I'm overlooking would be greatly appreciated!!
Thanks,
-Jon C. Kidder
American Electric Power
Complex - Middleware Engineering.
zip renamed as txt to avoid mail scrubbing.
6 years, 4 months
Q: index for operational attributes?
by Ulrich Windl
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
6 years, 4 months
RE: client-pr option for meta backend
by Quanah Gibson-Mount
--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>
6 years, 4 months
Re: client-pr option for meta backend
by Quanah Gibson-Mount
--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>
6 years, 4 months
Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount
--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>
6 years, 4 months
Re: redMod with single colon
by Ondřej Kuzník
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
6 years, 4 months
client-pr option for meta backend
by laurent2.perrin＠orange.com
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.
6 years, 4 months
Re: mmr pair stops replicating: "consumer state is newer than provider"
by Quanah Gibson-Mount
--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>
6 years, 5 months
