openldap-technical

openldap-technical@openldap.org

9 participants
9902 discussions

RE: BDB Backend: How to force transaction log rotation for log archival based on db_archive
by Reiterer, Horst 25 Jan '17

25 Jan '17

Hi, > Is there a way to force a transaction log rotation to make sure that even changes that do not cause > a new transaction log to be created will get archived at regular intervals? It can be done but the scenario definitely requires code to do so. The internal function __log_newfile can be used to switch to a new log file. After a checkpoint, the old log file will become unused and eligible for archiving. Cheers, Horst

1 0

BDB Backend: How to force transaction log rotation for log archival based on db_archive
by Reiterer, Horst 24 Jan '17

24 Jan '17

Hi, I use OpenLDAP with the Berkeley DB backend and db_archive to move unused transaction logs to a backup location for the purpose of disaster recovery. The intention is to reduce the data loss window to N minutes. Consequently, I execute db_archive every N minutes. If the transaction throughput is high enough so that the maximum transaction log size causes a new transaction log to be created and database checkpoints occur that cause the old log to become unused, that strategy works as expected. If, however, the throughput is minimal, archiving would only occur once the maximum transaction log size is hit and a checkpoint frees the old log. Consequently, those changes cannot be restored because logs are not being archived. Is there a way to force a transaction log rotation to make sure that even changes that do not cause a new transaction log to be created will get archived at regular intervals? By reducing the maximum transaction log size, the situation could be improved but not resolved. All I can come up with is forcing a rotation by writing a custom appropriately sized transaction log entry using the Berkeley DB API DB_ENV->log_put() before triggering a checkpoint and calling db_archive but that still doesn't sound like a production-ready solution. Thanks in advance for any additional info on this subject! Cheers, Horst

1 0

Re: Deleting an user defined object class from openldap 2.4.40
by Quanah Gibson-Mount 24 Jan '17

24 Jan '17

--On Monday, January 23, 2017 4:35 PM +0300 Tamer Ataol <ataoltamer(a)gmail.com> wrote: > Hi, > > I used the below ldif file to add a user defined objectclass in my > openldap 2.4.40 on CentOS 7. Delete support for cn=config will be a part of the OpenLDAP 2.5 release series, as documented. You will need to slapcat your config DB, remove the offending entries, and slapadd it back. --Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Re: use proprietary password hash in "userpassword"
by Quanah Gibson-Mount 24 Jan '17

24 Jan '17

--On Tuesday, January 24, 2017 1:28 PM +0100 Meike Stone <meike.stone(a)googlemail.com> wrote: >>> I don't have to recompile the whole openldap, compiling the module is >>> sufficient? >>> >>> (1) we think about a subscription from symas ... >> >> >> Correct. Any distributor (symas included) should include a development >> package that allows the ability to rebuild a module without rebuilding >> everything. >> > > Ah, ok - it works :-D > If I use a own compiled module and I bought a gold subscription, does > Symas still give full support? Hi Meike, Most often the answer is yes. You would need to work out those details in full as part of the contractual process. You would need to recompile your module against the Symas devel package, as some of the internal structs are larger in the Symas OpenLDAP build. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

2 1

Re: organizationIdentifier ATTRIBUTE mapping
by Quanah Gibson-Mount 24 Jan '17

24 Jan '17

--On Wednesday, January 18, 2017 10:59 AM +0000 Francesco Sordi <f_sordi_1(a)yahoo.it> wrote: > attributeType ( id-at-organizationIdentifier > NAME 'organizationIdentifier' > DESC 'X520 attribute Organization Identifier' > SUP name > EQUALITY caseIgnoreMatch > SUBSTR caseIgnoreSubstringsMatch SINGLE-VALUE ) > > > But i cannot understand which objectclass can use this attribute and how > to add an object using it. You would need to create a custom objectClass that allows this attribute. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

4 8

fresh (distro's) installation and cn=config password
by lejeczek 24 Jan '17

24 Jan '17

hi everybody, this must be one of the most ancient questions - but browsing (centos') local docs reveal nothing. I'd imagine passwords is that first & most important thing everybody does to make sure slapd is secured, something like "mysql_secure_installation" I'm trying to do something I'd think is simple and should just work, but, I'm wrong, so I do: slapadd -v -n0 <<EOL dn: olcDatabase={0}config,cn=config objectClass: olcDatabaseConfig olcDatabase: {0}config olcRootDN: cn=admin,cn=config olcRootPW:: exxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx EOL and I get in return: slapadd: could not add entry dn="olcDatabase={0}config,cn=config" (line=1): autocreation of "olcDatabase={-1}frontend" failed So that question - how does one secure ldap installation? But I'd insist on not referring something like "slaptest and convert old school to ..." or .. edit config file(s) What I think is - I have a clean installation which is configured in probably best possible way but missing is: olcRootDN, olcRootPW How to use slapadd for it? Is slapadd not the right tool for this? many thanks, L.

3 2

MDB map size = maxsize ?
by Tamás Rébeli-Szabó 24 Jan '17

24 Jan '17

Hello, we are using 2.4.41, and have run into MDB_MAP_FULL: Environment mapsize limit reached(-30792) " Checking database size we see: [openldap@soa-srv]$ grep maxsize slapd.conf maxsize 4294967296 [openldap@soa-srv]$ mdb_stat -e openldap-data Environment Info Map address: (nil) Map size: 1073741824 I was under the impression that maxsize is the same as map size. However, map size here is 1GB, whereas maxsize is 4GB, even after slapd is restarted. Why this apparent discrepancy? Thanks, tamas

2 1

Re: use proprietary password hash in "userpassword"
by Meike Stone 24 Jan '17

24 Jan '17

>> I don't have to recompile the whole openldap, compiling the module is >> sufficient? >> >> (1) we think about a subscription from symas ... > > > Correct. Any distributor (symas included) should include a development > package that allows the ability to rebuild a module without rebuilding > everything. > Ah, ok - it works :-D If I use a own compiled module and I bought a gold subscription, does Symas still give full support? Thanks Meike

1 0

Re: fresh (distro's) installation and cn=config password
by Ulrich Windl 24 Jan '17

24 Jan '17

(Copy for the list) >>> Ulrich Windl <Ulrich.Windl(a)rz.uni-regensburg.de> schrieb am 24.01.2017 um 13:19 in Nachricht <58875475.ED38.00A1.0(a)rz.uni-regensburg.de>: >>>> lejeczek <peljasz(a)yahoo.co.uk> schrieb am 23.01.2017 um 17:59 in Nachricht > <ff479edd-d352-2357-9275-9a66ed520be0(a)yahoo.co.uk>: > > hi everybody, > > this must be one of the most ancient questions - but > > browsing (centos') local docs reveal nothing. > > I'd imagine passwords is that first & most important thing > > everybody does to make sure slapd is secured, something like > > "mysql_secure_installation" > > > > I'm trying to do something I'd think is simple and should > > just work, but, I'm wrong, so I do: > > > > slapadd -v -n0 <<EOL > > dn: olcDatabase={0}config,cn=config > > objectClass: olcDatabaseConfig > > olcDatabase: {0}config > > > > olcRootDN: cn=admin,cn=config > > olcRootPW:: exxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx > > > > EOL > > > > and I get in return: > > slapadd: could not add entry > > dn="olcDatabase={0}config,cn=config" (line=1): autocreation > > of "olcDatabase={-1}frontend" failed > > What about: > dn: cn=config > objectClass: olcGlobal > cn: config > [...] > dn: cn=schema,cn=config > objectClass: olcSchemaConfig > cn: schema > [...] > dn: olcDatabase={-1}frontend,cn=config > objectClass: olcDatabaseConfig > olcAccess: ... > [...] > dn: olcDatabase={0}config,cn=config > objectClass: olcDatabaseConfig > olcDatabase: {0}config > olcAccess: ... > [...] > olcRootDN: cn=config > olcRootPW: {SSHA}... > > Regards, > Ulrich > > > > > So that question - how does one secure ldap installation? > > But I'd insist on not referring something like "slaptest and > > convert old school to ..." or .. edit config file(s) > > What I think is - I have a clean installation which is > > configured in probably best possible way but missing is: > > olcRootDN, olcRootPW > > How to use slapadd for it? Is slapadd not the right tool for > > this? > > > > many thanks, > > L. > > > >

1 0

Re: openldap slowness after restoration
by Quanah Gibson-Mount 23 Jan '17

23 Jan '17

--On Thursday, January 19, 2017 2:43 PM +0530 PRATIK SINGAL <pratik.singal13(a)gmail.com> wrote: > > Hello all, > > > After performing restoration the openldap server is performing slow. > > > openldap 2.4.40 with bdb. > > > Can any one suggest me on what to check which might cause the slowness. Using bdb will certainly cause slowness. I would note that to tune BDB is generally a dark art. You would be better served running a current version of OpenLDAP and using the back-mdb backend, which does not require fine tuning to be performant. Overall, you do not provide any of the necessary information to really provide any type of useful information on how to proceed. What does "slowness" even mean? I.e., how are you measuring "slowness" and where/how are you seeing it? Have you set up a DB_CONFIG file for BDB that is appropriate for your deployment? Have you tuned the various bits in slapd that's necessary on top of DB_CONFIG to correctly run a system with a BDB based backend? etc. Regards, Quanah -- Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: <http://www.symas.com>

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical