openldap-technical October 2011

openldap-technical@openldap.org

85 participants
99 discussions

Abwesenheit: openldap-technical Digest, Vol 47, Issue 22
by tkircht＠ipodion.at 22 Oct '11

22 Oct '11

Ich bin vom 21.10.2011 bis einschließlich 2.11.2011 nicht in Wien. Ich werde meine Mailbox in dieser Zeit nur sporadisch abfragen können. Bitte wenden Sie sich mit Ihren Anfragen in dieser Zeit an unser Büro unter office(a)ipodion.at bzw. der Telefonnummer 01/21632985-00. Vielen Dank Thomas Kirchtag

1 0

Abwesenheit: openldap-technical Digest, Vol 47, Issue 21
by tkircht＠ipodion.at 21 Oct '11

21 Oct '11

1 0

Overlays : Cache - Entry - AttributeDescription
by Johan Jakus 21 Oct '11

21 Oct '11

Hi everyone, I’m still working on my overlay for an OpenLDAP server, and I’ve a few questions, I hope you could help me with: 1. In my overlay, I search for the attribute of a parent (recursively) and then, I return it in the response using the “attr_merge” function as used in the “content” overlay. But, this seems to be a permanent change, the server will always return that attribute, till I restart the server. It’s like if the “attr_merge” function add the attribute in some kind of cache that is only cleared when the server shuts down. I ‘would like my attribute to be return only when I ask it, is there some other function that allow this or maybe a way to clear that cache? 2. I need to free some variables at the end of the request. It seems that the server goes through the response function one last time at the end of the request with an empty entry, I used that condition to free my variable. This seems to work perfectly, but is there may be another way to do that? 3. To determine what attribute I need to look up for parent’s attributes, I use a symbol before the attribute in the search request (ex: “_street”). This means that when the attribute arrives in the search function, it has no attribute description because the attribute name isn’t valid of course! So, I change the name, save the attribute name for later use and then use the “slap_str2ad” function do add the attribute description! But this means that the server as to go look for that attribute description again and this means decreasing the performance. My question is: Is there a way to change and saved the attribute name before the server loads the attribute descriptions and calls the search function? Since I’ve found a workarounds for question 2 and 3, question 1 is my biggest problem to make my overlay work properly! Thanks for your coming answers! Johan Jakus

2 4

Re: howto view slapd configuration : ldapsearch VS slapcat
by Howard Chu 20 Oct '11

20 Oct '11

Olivier Guillard wrote: > Thanks Howard, > >> you can't ask for just a specific list of attributes. slapcat always >> returns whole entries. > > That's what I didn't get : thanks. The slapcat(8) manpage says: The entry records will include all (user and operational) attributes stored in the database. >> You haven't shown an example of the command you attempted > > I tried almost the same with the attribute that I try to retreive included : > >> slapcat -H "ldap:///cn=config??sub?(olcDatabase=*)" > slapcat -H "ldap:///cn=config?olcAccess?sub?(olcDatabase=*)" > >> but obviously you did it wrong. > > You are obviously right since I get this : > > usage: slapcat [-v] [-d debuglevel] [-f configfile] [-F configdir] [-o > <name>[=<value>]] [-c] > [-g] [-n databasenumber | -b suffix] [-l ldiffile] [-a filter] [-s > subtree] [-H url] > > I thought that my URI was correct though. The slapcat(8) manpage says: -H URI use dn, scope and filter from URI to only handle matching entries. It says nothing about using an attribute list in the URI. Did you think we were just joking? That what the docs say is not what is actually meant? -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: howto view slapd configuration : ldapsearch VS slapcat
by Sébastien Bernard 20 Oct '11

20 Oct '11

Le 19/10/2011 15:51, Olivier Guillard a écrit : > Hi Seb, > > Isn't there any way to pass filters to slapcat see spécific > part of the configuration ? > >>> ldapsearch -x -LLL -D uid=admin,cn=config -W -s sub -b "cn=config" >>> "(olcDatabase=*)" olcAccess > [snip ...] Unfortunately not. Slapcat is meant to dump the whole context. You can eventualy use a small perl script to sort the relevant nodes afterwards. Else ldapsearch with '*' '+' should give you all the attributes included in the database. ldapsearch -x -LLL -D uid=admin,cn=config -W -s sub -b "cn=config" "(olcDatabase=*)" '*' '+' The '+' adds the operational attributes. S. Bernard

3 4

Query filter on number of values in multi-valued attributes
by Nick Milas 19 Oct '11

19 Oct '11

A quick question: Is there a way to formulate a query filter to say: "Find all entries which include two or more values (or exactly n values) in attribute xYZ" or we must create a script to test? Thanks, Nick

2 1

syncrepl + slapd-relay + slapo-rwm some clarification needed
by Jeffrey Crawford 19 Oct '11

19 Oct '11

Hello all, We have a need to populate one of our replicas with mapped attributes long story short, using a ldap proxy to perform the mapping will not be sufficient since the attributes are being used by OpenLDAP itself. I've found that when setting up a slapd-relay to virtualize the suffix and then use rwm to perform the mapping I get the desired view. However when trying to replicate the content using a replication account things start acting weird I think mostly because syncrepl processes changes via logs and update instructions from the provider to the consumer. That being the case the syncrepl RefreshAndPersist actually changes the values from the original update instruction. Ergo the replica looking at the virtualized suffix (using relay) actually gets the attribute populated that I wanted mapped. Meaning the replica and the relay view don't agree rather the replica and the original data agree. I've found that if I use the syncrepl RefreshOnly the replica yields the desired results however that is performed on intervals so the data isn't immediately available. So Have I missed something on the RefreshAndPersist method that would also yield the desired results? Or is RefreshAndPersist always going to see the original change being made even if the underlying relay view shows the mapped attributes? Ugh the above is so complex to describe Below is an example to facilitate a quick explanation. ### Provider hdb database dn: cn=record,dc=suffix,dc=org cn: record attr1: value1 attr2: value2 attr3: value3 ### Provider relay database dn: cn=record,dc=suffix,dc=org,cn=mapped cn: record attr1: value1 attr2: value3 | | attr3: value2 | Values switched | #### { Replica Section } ##################################### ### replica from cn=mapped using RefreshAndPersist (Undesired) dn: cn=record,dc=suffix,dc=org cn: record attr1: value1 attr2: value2 attr3: value3 ### replica from cn=mapped using RefreshOnly (Desired) dn: cn=record,dc=suffix,dc=org,cn=mapped cn: record attr1: value1 attr2: value3 | | attr3: value2 | Values switched |

2 2

howto view slapd configuration : ldapsearch VS slapcat
by Olivier 19 Oct '11

19 Oct '11

Hello, I have trouble to use slapcat to browse in my slapd configuration? For example, with ldapsearch I use this to see ACL : ldapsearch -x -LLL -D uid=admin,cn=config -W -s sub -b "cn=config" "(olcDatabase=*)" olcAccess What would be the equivalent with slapcat (run with "-F /etc/openldap/slapd.d") ? Thanks --- Olivier

2 1

syncrepl provider not working after upgrade to 2.4.26
by Nick Milas 19 Oct '11

19 Oct '11

Hi, I have a syncrepl provider v2.4.22 working fine (the only provider in our organization). I upgraded with the same configuration to v2.4.26 and provider is not working (neither over ldaps: nor over ldap:). Otherwise connectivity is fine (with any ldap client) both with ldap and with ldaps. I get (in all consumers): Oct 17 21:21:32 vmail slapd[14621]: do_syncrep2: rid=111 LDAP_RES_SEARCH_RESULT Oct 17 21:21:32 vmail slapd[14621]: do_syncrep2: rid=111 LDAP_RES_SEARCH_RESULT (53) Server is unwilling to perform Oct 17 21:21:32 vmail slapd[14621]: do_syncrep2: rid=111 (53) Server is unwilling to perform Oct 17 21:21:32 vmail slapd[14621]: do_syncrepl: rid=111 rc -2 retrying How can I troubleshoot the issue further? Current config on the provider is: overlay syncprov syncprov-checkpoint 100 10 syncprov-sessionlog 100 and on consumers: syncrepl rid=111 provider=ldaps://ldap.example.com tls_reqcert=never type=refreshAndPersist retry="60 +" searchbase="dc=example,dc=com" schemachecking=off bindmethod=simple binddn="cn=someuser,dc=example,dc=com" credentials="password" Thanks, Nick

4 6

Loading LDAP schema files into cn=config
by Mark Cave-Ayland 19 Oct '11

19 Oct '11

Hi all, Having started to look at the changes required to migrate from a slapd.conf setup to a cn=config setup, one of things I'm struggling with is how to load new LDAP schemas into cn=config. I've seen the guides similar to this one here: http://blogger.ziesemer.com/2011/01/ldap-authentication-for-samba.html which suggest hacking together a temporary slapd.conf file containing just the include directives, run slaptest, and then hack the output so that it can be loaded into cn=config using ldapadd. Given that this is a quite a common task, is there no way of generating the LDIF directly to be loaded into the directory, e.g. slaptest -s /etc/ldap/schema/myschema.schema [ -n <schemanum> ] -l myschema.ldif Or then again, is this functionality already there but I just haven't managed to find it yet? I'd be grateful if someone could point me in the right direction and/or give me some hints as to the best way to manage schemas in the new regime. Many thanks, Mark. -- Mark Cave-Ayland - Senior Technical Architect PostgreSQL - PostGIS Sirius Corporation plc - control through freedom http://www.siriusit.co.uk t: +44 870 608 0063 Sirius Labs: http://www.siriusit.co.uk/labs

13 49

← 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 October 2011