Hi,
having a strange warning:
# /usr/sbin/slapcat -b dc=foo,dc=bar,com
583422d0 /etc/ldap/slapd.d: line 1: "attr" is deprecated (and
undocumented); use "attrs" instead.
Then, the normal output of slapcat follows.
The thing is, /etc/ldap/slapd.d is a *folder* and in the entire
/etc/ldap folder, including subdirs, the string "attr" does not occur.
Btw, The contents of /etc/ldap/slapd.d are:
-rw------- 1 openldap openldap 2386 Jun 5 13:51 cn=config.ldif
drwxr-x--- 6 openldap openldap 4096 …
[View More]Nov 20 20:32 cn=config
Can anyone give me a hint, what is going on?
Best, Kilian
[View Less]
Hello,
I'm using a simple setup on CentOS Linux release 7.2.1511
(Core)/openldap-servers-2.4.40-9 /cn=config/mdb : one provider with the
syncprov overlay and 2 syncrepl consumers. The DIT itself is about 10000
dn in size (about 3000 active users).
Everything works fine except that sometimes, some clients report
(temporary) failure to reach the consumers (NAS servers for instance).
All I see in the logs is that when this happens, the time windows
loosely match a moment where log rate …
[View More]limiting is dropping messages (for
debugging purpose, I disabled journald ratelimiting and doubled default
rsyslog one - still some drops occur on a regular basis).
So I assume it happens when slapd is kind of busy...
Here are some question about that :
- First tuning attempt :
-------------------------
I noticed that olcDbMaxReaders value was set to 0 (not by me!)
I changed it to olcDbMaxReaders: 512
I thought the problem didn't occur anymore but I was wrong.
-> Is there any guideline about how to setup MaxReaders ?
- Second tuning attempt :
-------------------------
I thought maybe replication was responsible (I'm using refreshAndPersist
mode) so I raised the size of the sessionLog (from 100 to 800).
I read the doc again and I'd like to know if the following understanding
is correct :
- thanks to contextCSN and the sync cookies, replication CAN be stateless
- if we want it stateless, syncprov HAS TO use the present phase, which
basically is like sending the whole DIT except that for unchanged
entries, only names are sent
- if and ONLY IF a state is used (in the form of a sessionLog), then
delete phase can be used (and if the sessionLog can hold enough since
the last sync)
As a matter of fact, at the opposite of the present phase, in the delete
phase, syncprov has to 'remember' (i.e store in a sessionLog) which
entries has been deleted.
-> this assumes that delete phase is more efficient than the present
phase, right ?
-> if for some reason (for instance sessionLog being too small, delete
phase can not be used) syncprov HAS TO fall back to present phase, correct ?
-> does using the sessionLog MAKE SENSE AT ALL when using
refreshAndPersist mode ?
-> is there any guideline to choose the right size for the sessionLog ?
- Third tuning attempt
-------------------------
I also raised the checkpoint values.
-> Is there any guideline here as well ?
Thanks.
--
Thomas HUMMEL
[View Less]
Hi all,
I have now the same problem, but with back-perl. We have so one kind of LDAP broker implemented. Reason is to split authentication and authorization by sending the LDAP-bind to one server(Authentication) and LDAP-search for group membership to another (Authorization).
Unfortunately one of 6 authorization server is a Microsoft Active Directory, expects LDAP_MATCHING_RULE_IN_CHAIN, and so I get "Bad filter, "(?=undefined)".
It is possible to implement a similar workaround as in the …
[View More]back-meta bellow?
I think a generally config option to deactivate the filters sanity check were very useful, not for me only.
Kind regards
Waldemar
-------------------------------------------------------------------------------
Hi all,
I had exactly the same problem last June. Pierangelo Masarati helped me
understanding the problem. He even provided the code for a contrib
module to solve this issue. You can search the list for the subject
"back_meta does not like my LDAP_MATCHING_RULE_IN_CHAIN filter".
I have "packed" all of it into a github repo at
https://github.com/cbueche/openldap-passthru and announced it to the
list on 6.6.2014. It would be nice if the maintainer take it over to the
official openldap tarball within contrib/slapd-modules/mr_passthru/ so
future needs are "officially" covered. I think the
LDAP_MATCHING_RULE_IN_CHAIN filters will find their use for many other
people.
Markus: I can help you for the implementation if needed. Feel free to
provide for more functionality.
Regs,
Charles
On 23.10.14 08:17, Markus.Storm(a)t-systems.com wrote:
> Hi Howard,
>
> have you had a chance to look into this?
> We're a bit desperate over here, short of alternative solutions.
>
> Regards
> Markus
>
>> -----Original Message-----
>> From: Storm, Markus
>> Sent: Thursday, September 18, 2014 8:44 AM
>> To: 'Howard Chu'; openldap-technical(a)openldap.org
>> Subject: AW: allow to pass on "undefined" filters in meta
>>
>>> -----Ursprüngliche Nachricht-----
>>> Von: Howard Chu [mailto:hyc@symas.com]
>>> Gesendet: Mittwoch, 17. September 2014 18:17
>>> An: Storm, Markus; openldap-technical(a)openldap.org
>>> Betreff: Re: allow to pass on "undefined" filters in meta
>>>
>>> Markus.Storm(a)t-systems.com wrote:
>>>> Hi
>>>> I've run into a problem trying to deploy back-meta in front of an
>>>> Active Directory target.
>>> What is the exact filter you are trying to use?
>> a filter such as
>>
>> (&(objectclass=user)
>> (|(memberOf:1.2.840.113556.1.4.1941:=CN=GRP_AAA_ADM,OU=Groups,OU=AAA,OU=Se
>> rvers,DC=lab,DC=net)
>> (memberOf:1.2.840.113556.1.4.1941:=CN=GRP_BBB_ADM,OU=Groups,OU=AAA,OU=Serv
>> ers,DC=lab,DC=net)))
>>
>> The problem is with the matching rule to be used :1.2.840.113556.1.4.1941:
>> That translates into LDAP_MATCHING_RULE_IN_CHAIN which makes the server
>> recursively check for nested group membership. That's a feature in AD but
>> not supported in OpenLDAP (or at least not by simply specifying that matching
>> rule, and to rework the query is no option).
>>
>>>> I believe that to resolve it, I need to get a new option implemented.
>>>> I need to issue a request through a back-meta proxy . That query
>>>> happens to contain a matching rule which is not implemented in
>>>> OpenLDAP so slapd does not know to evaluate the query. The target
>>> that
>>>> the query will ultimately be passed on to (an Active Directory) does
>>> know to process the query, though.
>>>> OpenLDAP, however, considers the filter to be "undefined" and thus
>>>> on relaying the request to the AD target, back-meta replaces a
>>>> portion
>>> of
>>>> the original query with a "(?=undefined)" filter as documented in
>>> e.g.
>>>> slapd-meta manpage "noundeffilter" option.
>>>> But I need the original query to be passed on. It's in fact a
>>>> _valid_ LDAP request, just OpenLDAP happens to be unable to parse it.
>>>> But at least in my setup, slapd does not have to do _/anything/_
>>>> about the query other than to pass it on, so I find it inacceptable
>>>> that it replaces the query just because it doesn't understand it.
>>>> Please, can you add an option switch to the code to allow for
>>>> passing on original queries *without* replacing undefined portions ?
>>>> I have not found any other solution to my problem. I tried to make
>>>> OpenLDAP aware of the undefined portion by adding the matching rule
>>> to
>>>> the schema but I failed. Seems that would need to be planted into
>>>> the code, and not being a programmer, that's not as easy as it is
>>>> with expanding the schema by some new attributes.
>>>> Also, while of course any parser/feature enhancement will always be
>>>> appreciated, I would think that to implement the matching rule is
>>> not
>>>> the best way of fixing things: I believe there will always be
>>>> situations where OpenLDAP cannot parse the input while another LDAP
>>> server can.
>>>> For a proof of concept, I hacked servers/slapd/back-meta/map.c
>>> (around
>>>> line 581as of 2.4.39) and but - again, I'm not a programmer - I
>>> feel
>>>> incapable of turning this into a full-blown patch free of side
>>>> effects, also I want the modification to become available to anyone.
>>>> So I'm hoping for you to implement the switch mentioned above, maybe
>>>> as a third possible setting for the "noundeffilter" option.
>>>> Thanks a lot in advance,
>>>> best regards
>>>> Markus Storm
[View Less]
Hi folks -
Just a quick question I couldn't quite find the answer to in the oldap documentation.
We have a multi-master oldap with three nodes. One node is on a physical machine, and we are planning on doing a physical to virtual migration soon. All three nodes are part of a DNS round robin. We will take the physical node out of the DNS round robin, do the migration and bring the virtual back in.
My question regards synchronization. We are using "refreshandpersist" for syncrepl. For the …
[View More]hour or so it takes to do the migration, users will be changing Passwords - that should be the only oldap changes made in that time. Will the password changes that get written to the two existing nodes sync over to the third node when we bring it back up, or will they be lost and we would be out of sync?
Thanks for any clarification.
Norman Singley
Directory Services
University of Montana
406 243 6799
Norman.singley(a)mso.umt.edu
[View Less]
Tim Uckun wrote:
> Hi.
>
> Sorry for being so dense but...
> The document says
>
> The transaction handle is freed. It and its cursors must not be used again
> after this call, except with mdb_cursor_renew().
>
>
> I am still very confused about reusing transactions.
Keep reading.
> If I commit or abort a read write transaction I can't reuse the transaction
> but I can re use the cursor? In the cursor documentation it says
>
> Cursors that are only …
[View More]used in read-only transactions may be re-used, to avoid
> unnecessary malloc/free overhead.
>
> So this indicates only read only cursors can be reused right?
Yes.
>
> So can you confirm my understanding? This is what I get from reading the docs.
>
> A transaction can either be read write or read only.
>
> If a transaction is read only you can commit or abort the transaction and then
> re-open it again for further use.
No. Once a transaction is committed or aborted it is freed and cannot be
reused. Period, end of story. Both the commit() and abort() docs are quite
explicit about this.
> If a transaction is read write then it can't be used again after you commit or
> abort the transaction.
>
>
>
>
>
> On Tue, Nov 22, 2016 at 3:17 PM, Howard Chu <hyc(a)symas.com
> <mailto:hyc@symas.com>> wrote:
>
> Tim Uckun wrote:
>
>
>
> No. You can perform multiple write operations in a single transaction.
>
>
> But once the commit has been called the next write operation has to be
> a newly
> opened transaction right? The write transactions can't be re-opened.
>
> http://lmdb.tech/doc/group__mdb.html#ga846fbd6f46105617ac9f4d76476f6597
> <http://lmdb.tech/doc/group__mdb.html#ga846fbd6f46105617ac9f4d76476f6597>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
[View Less]
Tim Uckun wrote:
> The language is Crystal which is still a very young language. It does not have
> threading at this time so there should be no issues with mutexes. While
> writing the code I never opened up a database but did repeatedly open up the
> environment and if the app ran into an error while coding didn't properly
> close the environment.
I didn't ask about languages, I asked about OS and LMDB version.
LMDB uses mutexes internally to serialize write transactions.
…
[View More]>
> Howard while I have you on the line....
>
> The documentation says to be very careful about closing databases and says
> it's not normally necessary. I am going to omit those calls from my wrapper.
> Is this OK? I will probably omit a bunch of other calls too at least from the
> first release but I want to make sure I don't omit anything crucial.
Probably a good idea to omit dbi_close.
>
> Thanks.
>
> On Tue, Nov 22, 2016 at 7:42 AM, Howard Chu <hyc(a)symas.com
> <mailto:hyc@symas.com>> wrote:
>
> Tim Uckun wrote:
>
> Hi All.
>
> I am writing a wrapper for Lmdb for the Crystal language. During the
> process
> of writing my code started hanging when attempting to open a
> transaction. At
> first I thought I was calling the C functions wrong but it turned out
> to be
> some sort of a corruption in the database itself. I deleted the database
> directory and the code started working fine again.
>
>
> Sounds like you're not using robust mutexes. Just a guess, since you
> didn't provide any info about your OS / platform or LMDB version.
>
> --
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
> <http://www.openldap.org/project/>
>
>
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
[View Less]
Tim Uckun wrote:
> Another question regarding my wrapper for lmdb.
>
> The comments say it's possible to reuse read only transactions but says
> nothing about reusing the read write transactions. Does this mean every write
> operation needs a fresh transaction?
No. You can perform multiple write operations in a single transaction.
> Is there any downsides to not
> implementing the reuse functions for the wrapper?
There is a performance gain from reusing read …
[View More]transactions.
> I figure the use case is
> quite limited and frankly I would have to manage all the transaction pointers
> to make sure they were being used property.
>
> Also I noticed that every call to mdb_txn_id returns 1 even for different
> transactions. Is this normal?
http://lmdb.tech/doc/group__internal.html#a26512036328af11cdaeb6c9880859290
> Thanks.
--
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
[View Less]