openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

Re: Antw: Re: slapd-meta with olc
by Martin Stejskal 20 Jan '17

20 Jan '17

Hi Ulrich, I totally agree, but I wanted to show "quick and dirty" way. Sometimes you just need to test something, and when everything works it is time to play around ;) Hey Ryan, thanks for advice. Today I played with "osixia/openldap" docker image and at the end of the day I was able to make it work. Just for reference, I'm sending modified part of ".config" file. ====================================================== include /etc/ldap/schema/core.schema include /etc/ldap/schema/cosine.schema include /etc/ldap/schema/inetorgperson.schema include /etc/ldap/schema/openldap.schema include /etc/ldap/schema/nis.schema include /etc/ldap/schema//ppolicy.schema pidfile /var/run/slapd/slapd.pid argsfile /var/run/slapd/slapd.args #ldapmod#modulepath ../servers/slapd/back-ldap/ #ldapmod#moduleload back_ldap.la #metamod#modulepath ../servers/slapd/back-meta/ #metamod#moduleload back_meta.la #monitormod#modulepath ../servers/slapd/back-monitor/ #monitormod#moduleload back_monitor.la modulepath /usr/lib/ldap/ moduleload back_meta.la moduleload rwm.la moduleload back_ldap.la ====================================================== Then just delete old slapd.d and convert .config to slapd.d directory and it is work. But still, it is not proper way through slapadd/slapmodify, which I'm looking for. Best regards Martin Stejskal ________________________________ From: Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> Sent: 19 January 2017 08:45:43 To: Martin Stejskal; openldap-technical(a)openldap.org; michael(a)stroeder.com Subject: Antw: Re: slapd-meta with olc >>> Martin Stejskal <mstejskal(a)alps.cz> schrieb am 17.01.2017 um 09:08 in Nachricht <OS2PR01MB02343BFA404E587BC43468B9B37C0(a)OS2PR01MB0234.jpnprd01.prod.outlook.com> [...] > 3) Simply remove (3A) or configure (3B) "apparmor" to avoid strange start > failure and another "permission denied" errors. Choice is up to you > (security vs convenience) > > 3A) Remove apparrmor > $ sudo apt remove apparmor > > 3B) Configure apparmor [...] I'd recommend to change the "enforce mode" for slapd to "complain mode". Then updating the apparmor profile can be done with the tools provided. Alternatively remove the profile for slapd in apparmor. I would not remove the whole package, because then no appliocation can/will be protected. Regards, Ulrich

1 1

Re: Replication issue in 2.4
by Quanah Gibson-Mount 19 Jan '17

19 Jan '17

--On Thursday, January 19, 2017 10:14 AM +0100 Dieter Klünter <dieter(a)dkluenter.de> wrote: > Am Tue, 17 Jan 2017 18:07:33 +0530 > schrieb PRATIK SINGAL <pratik.singal13(a)gmail.com>: > >> Hello , >> >> Can any one please help me with this.Am using BDB and openldap 2.4 >> with multi master replication >> below is my slapd.conf for replication >> >> syncRepl rid=000 >> provider=ldap://host1:389 >> type=refreshAndPersist >> retry="5 + 5 +" >> searchbase="dc=example,dc=com" >> attrs=* > > operational attributes should also be synchronized. Or to expand a bit, don't define the attrs= bit at all. Just go with the default. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: ContextCSN values in 3-multimaster setup
by Quanah Gibson-Mount 19 Jan '17

19 Jan '17

--On Tuesday, January 17, 2017 2:11 PM +0100 Marc Franquesa <mark(a)l3jane.net> wrote: > In the past I migrated some server, added some other node so is > possible that a 'ghost' provider CSN is still on the DB ? Yes. If you have any entries still in the DB that have an entryCSN from your old provider, it will be a valid contextCSN value. If you want that contextCSN gone, you'll need to slapcat your database and modify the LDIF accordingly before re-importing. I assume that was serverID 006, you would want to find all instances of #006# and replace them with one of #001#, #004#, or #005# (so they are consistent) and then reload all servers. Hope that helps. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

use proprietary password hash in "userpassword"
by Meike Stone 19 Jan '17

19 Jan '17

Hello dear list, we like to migrate an a user database from SQL to LDAP and need to take over the user passwords. Problem is, the passwords are hashed by an known but proprietary algorithm. Is there a possibility, to write an small external binary, that is used by slapd to validate these passwords? (Maybe, we import that in a own attribute?) After password change, we want write a ssha hash, so that we can disable this external binary... Write a openldap modul like pw-sha2 is not the first choice, because we need to compile the openldap after each update on our own and that prevents us to use the distribution packages. Thanks for help, kindly regards Meike

2 1

Replication issue in 2.4
by PRATIK SINGAL 19 Jan '17

19 Jan '17

Hello , Can any one please help me with this.Am using BDB and openldap 2.4 with multi master replication below is my slapd.conf for replication syncRepl rid=000 provider=ldap://host1:389 type=refreshAndPersist retry="5 + 5 +" searchbase="dc=example,dc=com" attrs=* interval=00:00:00:05 schemachecking=on bindmethod=simple binddn="cn=Manager,dc=example,dc=com" credentials=password when the database are empty and i try to import a ldif the replication is working fine.But after that when i add few records in one ldap its not getting replicated to another.below is the difference in contextCSN ldapsearch -x -u -h<host2> -b "dc=example,dc=com" -s base contextCSN -LLL dn: dc=example,dc=com ufn: example.com contextCSN: 20150604060008.504258Z#000000#000#000000 contextCSN: 20170117173528.506070Z#000000#001#000000 contextCSN: 20170117182158.011615Z#000000#002#000000 ldapsearch -x -u -h<host1> -b "dc=example,dc=com" -s base contextCSN -LLL dn: dc=example,dc=com ufn: example.com contextCSN: 20150604060008.504258Z#000000#000#000000 contextCSN: 20170117174748.128319Z#000000#001#000000 contextCSN: 20170117182127.009918Z#000000#002#000000 *Can any one please help me on how to make the sync speedup or any other parameter that i need to tweak.* Regards, Pratik

2 1

Re: Antw: Re: ContextCSN values in 3-multimaster setup
by Quanah Gibson-Mount 18 Jan '17

18 Jan '17

--On Thursday, January 19, 2017 8:50 AM +0100 Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> wrote: > Can't it be done online (using ldapmodify), and wouldn't it be > re-replicated back? It won't remove the contextCSN from the root entry if you do it online. I missed noting that step was necessary as well. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: ContextCSN values in 3-multimaster setup
by PRATIK SINGAL 18 Jan '17

18 Jan '17

Hi if you are using syncReply then its ideally contextcsn#rid#sid#00000# also you can have a look at slap -c option you get some more idea about it. Regards, Pratik On 19-Jan-2017 03:29, "Marc Franquesa" <mark(a)l3jane.net> wrote: Hi all I finally got working a new setup with 3-node multimaster replication for both the main DIT and cn=config tree. Now I'm trying to monitor the replication status or all the nodes so I focused on examining the contextCSN value of the root of the DBs, and although I googled and reviewed other posts on the mailing list I'm still not sure to understand correctly its use. As far as I understood (please correct me if I'm wrong): - Each DB backend which is replicated will have its own and independent contextCSN at the root of the replicated DN (so I have 2 DBs: cn=config, and dc=domain,dc=net, each one will have its own contextCSN attribute). - Each master which is running as a sync provider will update one value on the contextCSN values. So, as I have multi-master replication between 3 nodes (3 providers), I should have 3 different values of contextCSN in each DB. ... so, why I'm seeing 4 values (identical on all servers as they are in sync): contextcsn: 20170111084028.692133Z#000000#001#000000 contextcsn: 20161228225757.121969Z#000000#004#000000 contextcsn: 20160201102250.543748Z#000000#005#000000 contextcsn: 20150917152138.054326Z#000000#006#000000 In the past I migrated some server, added some other node so is possible that a 'ghost' provider CSN is still on the DB ? Another point is the syntax of that value... Has any special meaning? It seems that the first part is a timestamp with milisecond resolution, but I would like to know the meaning of the 3 digits between #xxx# Are they the ServerId ? or the rid in the replication ? Please enlight me Thanks for any details

1 0

Re: Replication issue in 2.4
by Quanah Gibson-Mount 18 Jan '17

18 Jan '17

--On Tuesday, January 17, 2017 6:07 PM +0530 PRATIK SINGAL <pratik.singal13(a)gmail.com> wrote: > > Hello , > > > Can any one please help me with this.Am using BDB and openldap 2.4 with > multi master replication > below is my slapd.conf for replication OpenLDAP version? There are many point releases in the 2.4 series. 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: slapd-meta with olc
by Quanah Gibson-Mount 18 Jan '17

18 Jan '17

--On Wednesday, January 11, 2017 10:23 AM +0000 Martin Stejskal <mstejskal(a)alps.cz> wrote: I'll fix this LDIF for you, although I don't know the answers to the rest of your questions. > $ cat add_meta_backend.ldif > dn: cn=module{},cn=config > objectClass: olcModuleList > cn: module{} > olcModulePath: /usr/lib/ldap > olcModuleLoad: back_meta > olcModuleLoad: back_ldap > olcModuleLoad: rwm As for olc attribute names, you can trivially grab these out of the source code. Or, you can use slaptest to convert a slapd.conf to cn=config to see the corresponding configuration. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 5

Odd ldapsearch behavior
by Frank Swasey 18 Jan '17

18 Jan '17

I have discovered that I have a development server that is giving back multiple copies of the entryDN and subschemaSubentry values when operational attributes are requested. However, my production server (running the same locally compiled version of 2.4.44) does not. My question is what the dickens have I misconfigured that would cause this? Examples: $ ldapsearch -x -H ldaps://production_server -D cn=manager,dc=example,dc=com -y password_file -b 'dc=example,dc=com' -s base '(objectclass=*)' '+' dn: dc=example,dc=com creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20020531160527Z modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20020531160527Z structuralObjectClass: organization entryUUID: b745df88-a640-1027-9374-fb1dd3799b92 entryCSN: 20031108140804.000000Z#000017#000#000000 contextCSN: 20161004102449.402212Z#000000#000#000000 contextCSN: 20170111164206.727511Z#000000#001#000000 contextCSN: 20161219150039.213065Z#000000#002#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema auditContext: cn=accesslog hasSubordinates: TRUE $ ldapsearch -x -H ldaps://development_server -D cn=manager,dc=example,dc=com -y password_file -b 'dc=example,dc=com' -s base '(objectclass=*)' '+' dn: dc=example,dc=com creatorsName: cn=Manager,dc=example,dc=com createTimestamp: 20020531160527Z modifiersName: cn=Manager,dc=example,dc=com modifyTimestamp: 20020531160527Z structuralObjectClass: organization entryUUID: b745df88-a640-1027-9374-fb1dd3799b92 entryCSN: 20031108140804.000000Z#000017#000#000000 contextCSN: 20161004102449.402212Z#000000#000#000000 contextCSN: 20170111013201.758363Z#000000#001#000000 contextCSN: 20161219150039.213065Z#000000#002#000000 entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema hasSubordinates: TRUE entryDN: dc=example,dc=com subschemaSubentry: cn=Subschema auditContext: cn=accesslog - Frank Swasey

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical