openldap-technical January 2014

openldap-technical@openldap.org

74 participants
92 discussions

Re: MDB_BAD_RSLOT while executing slapacl
by Francesco Malvezzi 13 Jan '14

13 Jan '14

This is a follow-up of: https://www.openldap.org/lists/openldap-technical/201312/msg00119.html I have observed in the wild the "MDB_BAD_RSLOT while executing slapacl" error on two different servers: [...] 52d3c079 <= check a_group_pat: cn=agentsgroup,ou=groups,dc=example,dc=org 52d3c079 mdb_opinfo_get: err MDB_BAD_RSLOT: Invalid reuse of reader locktable slot(-30783) 52d3c079 <= check a_group_pat: cn=admins,ou=groups,dc=example,dc=org 52d3c079 mdb_opinfo_get: err MDB_BAD_RSLOT: Invalid reuse of reader locktable slot(-30783) [...] On the other hand, I am not able to reproduce the error with the example data given by Igor. The slapacl returns 'ALLOW'. Might be of interest my config yielding the error? thank you, Francesco /usr/local/openldap-2.4/libexec/slapd -V @(#) $OpenLDAP: slapd 2.4.38 (Dec 4 2013 11:26:00) $ francesco@c1:/usr/local/src/openldap-2.4.38/servers/slapd

2 1

syncrepl will update, and delete, but won't create entries
by Andrew LaPierre 10 Jan '14

10 Jan '14

Before I give too many details that you don't need, is there something that would cause this behavior? Both servers have: Ubuntu 10.04 OpenLDAP 2.4.21 I'm using RefreshAndPersist. I can make changes and delete entries, and the changes and deletions happen on the consumer, but if I create somebody on the provider, they never show up on the consumer. Please let me know what additional information I can give you guys to help. Thanks for the help! -- Andrew LaPierre

3 2

configuring mdb maxsize
by Paul B. Henson 09 Jan '14

09 Jan '14

I'd like to clarify the requirements for the mdb maxsize parameter. According to the current admin guide: "This should be the largest that the database is ever anticipated to grow" Which would seem to imply it cannot later be changed without completely rebuilding the database. According to the slapd-mdb manpage: "Note: It is important to set this to as large a value as possible, (relative to anticipated growth of the actual data over time) since growing the size later may not be practical when the system is under heavy load." It can possibly be changed later, but maybe not ;). Based on unauthoritative postings I've read, it seems that if you shut down openldap, you can change it to whatever you want, and when you restart openldap, the additional size will immediately be available with no problems. It also seems that if you're using cn=config, you can change it live and it will immediately take effect. I haven't seen any postings indicating a problem that occurred while changing it live. Are there any restrictions for changing it while the server is down? What restrictions, or problems, if any, are involved when changing it while the server is up? Thanks much.

3 4

optimal mdb flags
by Paul B. Henson 09 Jan '14

09 Jan '14

So if it's not obvious, we're working on migrating our openldap deployment to mdb from hdb :), I apologize for the flurry of questions, this will be the last, at least for today ;). I'm trying to evaluate the optimal configuration for mdb; it seems like for the most part you can just set maxsize and move on if you don't have performance issues, but one flag I've seen frequently mentioned for improving performance is writemap. This seems like a win all around, unless there is some bug that results in erroneous writes into the mapped region, in which case it could potentially cause major database corruption. For those that have been running mdb in the field for a while, are you using writemap? Have you ever run into any corruption because of it? The other flag that seems to be popular is nometasync. As opposed to nosync, which might cause loss of some number of transactions in case of a crash, nometasync only risks one? And the benefit is that it is "slightly faster"? Again, any recommendations from field experience on this? Also, if you do enable it, do you need a checkpoint directive, or is that only necessary for nosync? Thanks.

3 5

Port 636 and SLAPD(8)
by jumpgroup＠aol.com 08 Jan '14

08 Jan '14

Hello Experts, In need of a little guidance please. I'm installed OpenLdap 2.4.23 on RHEL in a sandbox and would like to enable SSL on port 636. All documentation references SLAPD(5), but since I'm using SLAPD(8), I do not know have the slapd.conf file. Looking for the current SLAPD(8) method of configuring this along with starting the service to support port 636. Thanks in advance! Jeff P.

5 5

mdb searchstack parameter
by Paul B. Henson 08 Jan '14

08 Jan '14

>From reading the documentation, it sounds like when configuring this parameter you need to strike a balance between potential performance impact if it is too low, and wasted memory if it is too high. While running, is there any way to tell whether or not a search exceeded your configured value and required additional allocation? Whether via the monitor backend, or a log entry, or? Ideally, it would be nice to be able to tell if your configured value was too low and adjust as necessary. Thanks.

2 2

mdb_stat
by Paul B. Henson 08 Jan '14

08 Jan '14

Where does one typically acquire the mdb_stat binary for use with openldap? It appears to be part of liblmdb. openldap includes a bundled copy of liblmdb, but does not actually build mdb_stat. Is the intention for distributions to have a separate package for liblmdb, which would include mdb_stat, which one would then install to acquire it (even though the library isn't needed for openldap itself)? I can obviously just compile it myself :), but plan to open a bug with my distribution (Gentoo) to see about making it available, and I'm not sure whether it would be better to compile the one within openldap and install that as part of the openldap package, or create a new package for liblmdb. Given it is still under relatively early development, would it be better to install the bundled one as ol_mdb_stat or something like that, to make sure it corresponds to the version actually used by the installed openldap? What are other distributions doing? Thanks.

2 2

replicating central NSS data (was: DBIS - new IETF drafts)
by Michael Ströder 08 Jan '14

08 Jan '14

(I take this point to openldap-technical(a)openldap.org since it discusses OpenLDAP-specific things.) Howard Chu wrote: > The discussion of caching here > http://www.ietf.org/id/draft-bannister-dbis-mapping-02.txt is one such example > - this is purely a client-side implementation issue. Also you give nscd as an > example, and nscd has been thoroughly discredited and is well known to be > unsuitable for real use. Critical deployments can use a local LDAP server with > a replica of the central data, to avoid error-prone caching implementations. > This is a commonly recommended approach when using OpenLDAP nssov, for example. I really wonder how this replication approach works in practice without disclosing too much data on a system more exposed to attacks from the outside. In theory one could implement partial replication based on systems's bind identity. But in practice I have some doubts because in a really paranoid setup you don't even want to disclose replication meta data and intermediate entries of the tree structure. Ciao, Michael.

2 1

Problem with back-mdb
by Grégory T 08 Jan '14

08 Jan '14

Hello, before starting, we wish a happy new year to the community ! Now, we start with presentation. We have compiled the Openldap build version 2.4.38 on a ubuntu 12.04. This openldap server is a dual processor Intel Xeon with 4 Gb Memory. This machine is virtualized (vmware). Openldap is configured with back-mdb, overlays memberof and syncprov, and envflags writemap and nosync. We encounter a problem with a callback procedure in a perl script. This script have to remove a couple of attributes for each entry (~120 000). In order to save memory consumption, we use a callback function to treat each entry one after one. Everything works with back-bdb but ... there are mistakes with back-mdb. In ldap.log, this kind of message appears many times : ldapserver slapd[7264]: connection_input: conn=1014 deferring operation: awaiting write ldapserver last message repeated 55 times And suddenly, ldapserver slapd[7264]: conn=1014 fd=14 closed (connection lost) Our script result in "connection reset by peer" message. The script stop around the 1040 entry. Although the connection was closed by server, it still continue to run. However, no explicit message in ldap.log. If we run the script once again, the next ~1040 entries will be treated and the script stop. We have try with envflags writemap and nosync deactivated ... but unsuccessful. This is the ldapsearch request : my $result=$ldapMaster->search(base=>$baseDN,scope=>'sub',filter=>$filter,typesonly=>'1',callback=>\&callback); And this is the callback function : sub callback{ my ($search,$ent)=@_; return unless defined $ent; my $entry = $search->shift_entry(); my @tabAttribToDel=(); if (defined $entry){ my $dn=$entry->dn(); $countDN++; foreach my $attrib($entry->attributes){ if ($attrib ~~ @tabOldAttrib){ $countAttrib++; push (@tabAttribToDel,$attrib); } } if (($SUPPR==1) && (@tabAttribToDel)) { $countTrace++; my $result = $ldapMaster->modify($dn,delete => \@tabAttribToDel); warn "(nbEntry:$countTrace, nbAttr:$countAttrib) Error with $dn: ".$result->error."\n" if $result->code; } } } Why is this script working well with back-bdb but not with back-mdb ? Thanks, -- Grégory Trucy Ingénieur système et réseau Aix-Marseille Université

3 2

replication of databases with different backends???
by lux-integ 08 Jan '14

08 Jan '14

Greetings, I have two computers with these:- host 1: --cpu amd64 3 cores --os blfs linux-3.10.24, openldap-2.4.33 with bdb backend host 2: --cpu amd64 3 cores --os blfs linux-3.10.24, openldap-2.4.33 with sql backend QUESTION: can I replicate these databases over each host (in other words can I for example do N-ray multimaster syncrepl ( http://www.openldap.org/doc/admin24/replication.html ) or another type of replication in view of the different backends ? thanks in advance sincerely luxnteg

4 3

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical January 2014