openldap-technical

openldap-technical@openldap.org

13 participants
9795 discussions

Re: Upgrade from 2.4.44 to 2.4.55
by Quanah Gibson-Mount 05 Feb '21

05 Feb '21

--On Friday, February 5, 2021 10:51 AM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > > We use centOS 7 and rely on base repo. > > > openldap-servers-2.4.44-22.el7.x86_64 : LDAP server > Repo : base > > > > openldap-servers-2.4.44-21.el7_6.x86_64 : LDAP server > Repo : @base Symas provides free drop in replacments for the ancient version of OpenLDAP shipped with RHEL7: <https://repo.symas.com/sofl/rhel7/> I suggest using them. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: Upgrade from 2.4.44 to 2.4.55
by Quanah Gibson-Mount 05 Feb '21

05 Feb '21

--On Friday, February 5, 2021 10:20 AM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > > Quanah, > > > We use binaries from OS distribution / repos, i mean do say can i > directly do an inplace upgrade from 2.4.44 to latest version or do i need > to worry about OS related libraries?. Since 2.4.57 is a very young > release I wanted to play safe :) but eventually we will upgrade to .57. > Also if my current installation is using bdb/hdb can i still continue > with those backends with the latest version? If i want to migrate from > bdb/hdb to mdb when upgrading, are there any migration processes for that? What distribution are you using? -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Context CSN timestamp
by Frédéric Goudal 05 Feb '21

05 Feb '21

Hello, I have a strange problem of synchronization, since yesterday my slave servers have a small difference of 2 or 3 minutes with the master. I mean the context CSN of the slave is 3 mn earlier than contextCSN of the master. My first question is the following : how the timestamp of the contextCSN of the slave is computed ? Is it a copy of the tilmestamp from the master ? Or is it based on the localtime of the slaves ? My second question is that maybe such a small difference is « normal » (as the contextCSN of slave is progressing that means that replication is not fully stopped just a bit delayed) and I should only worry for a greater difference of time than one minute. Thanks in advance. Fred

2 1

Re: Upgrade from 2.4.44 to 2.4.55
by Quanah Gibson-Mount 05 Feb '21

05 Feb '21

--On Thursday, February 4, 2021 5:03 PM -0800 rammohan ganapavarapu <rammohanganap(a)gmail.com> wrote: > > > Is there any upgrade process to upgrade from 2.4.44 to 2.4.55 ? You should upgrade to 2.4.57. I'm not sure what you mean as far as "upgrade process". Are you using binaries you built yourself? Binaries from a distribution? etc. Generally new dot releases are simply a drop in replacement. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

ldapmodify: wrong attributeType at line N
by Harri T. 05 Feb '21

05 Feb '21

Hi Updating the user attribute "shadowWarning" works fine: # cat tmp4.ldif dn: uid=john,ou=People,dc=example,dc=com changetype: modify replace: shadowWarning shadowWarning: 7 # ldapmodify -H ldapi:/// -D cn=admin,dc=example,dc=com -w ******** -f tmp4.ldif modifying entry "uid=john,ou=People,dc=example,dc=com" When I add the attribute "mail" into ldif the update fails: # cat tmp3.ldif dn: uid=john,ou=People,dc=example,dc=com changetype: modify replace: shadowWarning shadowWarning: 7 replace: mail mail: john.doe(a)example.com # ldapmodify -H ldapi:/// -D cn=admin,dc=example,dc=com -w ******** -f tmp3.ldif ldapmodify: wrong attributeType at line 5, entry "uid=john,ou=People,dc=example,dc=com" What's wrong with the file tmp3.ldif? Kind regards, Harri

4 4

Multi-master provider and delta syncrepl
by paul.jc＠yahoo.com 02 Feb '21

02 Feb '21

Hi all, We are setting up multi-master (3 providers) and are curious if it is recommended to use delta syncrepl between the providers vs standard sync. Currently, we have delta-sync set up between consumers and our single provider. Are there any gotchas with using delta syncrepl for provider-provider replication? I am curious if a new provider is added, does/should the accesslog db get sync'd as well, or does each provider get its own unique accesslog db? And if each accesslog db is unique, how do consumers using delta syncrepl deal with a provider that has sync'd the change in its main db but not in the accesslog? Is this a non-issue if all consumers are aware of all providers and would that mean all consumers have to sync from all providers? I'm sure the answer to this is clear but I am missing it in the docs. Any input or clarification is appreciated. Thanks! Paul

2 1

Unable to bind with LDAP DN having encoded chars
by radiatejava 02 Feb '21

02 Feb '21

I am using openldap client library 2.4.44 on Centos 7.3, LDAP v3 setting. I am having an issue with LDAP bind when the DN has encoded representation of special characters like é (e acute). Actual DN is CN=mithun,OU=Groupes de Sécurité,DC=mytest,DC=net and when it is sent by the app (frontend) to our backend, it is coming as CN=mithun,OU=Groupes de S\u00e9curit\u00e9,DC=insaaadev,DC=net. Basically, é comes encoded as \u00e9 which is as per the encoding mentioned here https://www.fileformat.info/info/unicode/char/e9/index.htm To further try out, I directly hardcoded the DN to CN=mithun,OU=Groupes de S\u00e9curit\u00e9,DC=mytest,DC=net and that worked fine. I want to understand why it fails when the DN in the same format comes from the frontend app. Appreciate your help, thanks.

3 4

Backup/Restore Overlays MemberOf
by Lars Päßler 02 Feb '21

02 Feb '21

Hello, I am running OpenLDAP 2.4.47 on Debian 10 for a while and now I enabled the overlay for memberOf. Is there any good option for backup and restore, because slapcat and slapadd aren't working. Thanks and kind regards Lars

3 2

proxied syncrepl: consumers sometimes missing all kinds of entries
by Udo Rader 01 Feb '21

01 Feb '21

Hi, We're using a proxied sync-repl installation to populate various consumers from our single master. For some time now, we've been seeing all kind of strange phenomenons, mostly with missing objects on some (not all consumers). Previously, our consumers and our master hadn't been identical with regards to the OpenLDAP version and the operating system used. While, according to the specs, this should have worked, we decided to rule out one source of trouble and upgrade our infrastructure and so right now, we're using OpenLDAP 2.4.47 on debian buster on all involved boxes: % dpkg -l slapd [...] ii slapd 2.4.47+dfsg-3+deb10u4 amd64 OpenLDAP server (slapd) One of the issue we're currently seeing is that memberOf queries don't work as expected. Different consumers yield different results, which again are different from what the master has. See for example: # on the master root@minerva:~# ldapsearch -b ou=People,dc=example,dc=com -LLL -x uid=ssebastian memberof dn: uid=ssebastian,ou=People,dc=example,dc=com memberOf: cn=ocp-cluster-users,ou=Group,dc=example,dc=com memberOf: cn=ocp-cluster-admins,ou=Group,dc=example,dc=com memberOf: cn=qube,ou=Group,dc=example,dc=com # consumer #1 root@demeter:~# ldapsearch -b ou=People,dc=example,dc=com -LLL -x uid=ssebastian memberof dn: uid=ssebastian,ou=People,dc=example,dc=com # consumer #2 root@peta:~# ldapsearch -b ou=People,dc=example,dc=com -LLL -x uid=ssebastian memberof dn: uid=ssebastian,ou=People,dc=example,dc=com memberOf: cn=ocp-cluster-users,ou=Group,dc=example,dc=com memberOf: cn=ocp-cluster-admins,ou=Group,dc=example,dc=com However, when I investigate the group, I see the user listed in every one of them: # on the master root@minerva:~# ldapsearch -LLL -x cn=qube dn: cn=qube,ou=Group,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: posixGroup cn: qube gidNumber: 1602 [...] member: uid=ssebastian,ou=People,dc=example,dc=com [...] # on consumer #1 root@demeter:~# ldapsearch -LLL -x cn=qube dn: cn=qube,ou=Group,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: posixGroup cn: qube gidNumber: 1602 [...] member: uid=ssebastian,ou=People,dc=example,dc=com [...] # on consumer #2 root@peta:~# ldapsearch -LLL -x cn=qube dn: cn=qube,ou=Group,dc=example,dc=com objectClass: groupOfNames objectClass: top objectClass: posixGroup cn: qube gidNumber: 1602 [...] member: uid=ssebastian,ou=People,dc=example,dc=com [...] The master only shares the relevant part of the DIT to the consumers, so unfortunately I cannot 1:1 compare them using slapcat. But if I again apply a group filter, slapcat delivers correct results on all instances as well (ie slapcat -a 'cn=qube') My first idea was an index issue, but running slapindex didn't change anything. Any ideas what might be wrong and/or how to debug this issue? Additionally - bear with me - we're not using cn=config, but the old style slapd.conf configuration. Thanks Udo -- Udo Rader, CTO BestSolution.at EDV Systemhaus GmbH Eduard-Bodem-Gasse 5-7, A-6020 Innsbruck http://www.bestsolution.at/ Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck

2 2

Re: How to set credential to ldap_gssapi_bind_s?
by Árpád Nagy 29 Jan '21

29 Jan '21

Hello, Thanks for the answer! What function should I use if I must supply username/password and I want to bind using GSSAPI? Is it possible somehow with Open LDAP? Regards, Arpad Quanah Gibson-Mount <quanah(a)symas.com> ezt írta (időpont: 2021. jan. 27., Sze, 18:10): > > > --On Wednesday, January 27, 2021 4:16 PM +0100 Árpád Nagy > <arpadnagy.bp(a)gmail.com> wrote: > > > > > According this it is executed only if 'dn' and 'creds' is NULL. > > My question is how can I set the user name and password which I want to > > authenticate on LDAP server? > > Using GSSAPI implies that the connecting client already has access to a > kerberos5 ticket, which is used for the authentication step and thus there > is no username or password to be supplied. > > If you must supply a username/password, then you're using the wrong > function. > > Regards, > 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