openldap-technical

openldap-technical@openldap.org

3 participants
9937 discussions

Lazy ACLs and keeping your DIT as flat as possible
by Gavin Henry 16 Aug '12

16 Aug '12

Hi All, I'm pretty sure that this isn't possible, but wanted to check as my head hurts now. I have dynamic lists using slapo-dynlist with the Organization attribute of 'o' and I am trying to keep my DIT as flat as possible. I want to create an ACL that is "by group", which is fine. But....I don't want to hardcode a group. I want to "capture" o via a regex and use that in the "by group" like so: access to dn.subtree="ou=Users,dc=suretec,dc=co,dc=uk" attrs=o val.regex="(.+)" attrs=children,entry by group.expand="cn=$1,ou=Groups,dc=suretec,dc=co,dc=uk" read by self write or something like the following using a previous capture: access to filter=(&(objectClass=inetOrgPerson)(o=$1)) by group/groupOfURLs/memberURL.expand="cn=$1,ou=Groups,dc=suretec,dc=co,dc=uk" read by self write by * none Issue is you can't pass captures between "access by" statements and my ACLs are flawed based on what you're searching for, which would be perfect. The goal being users in the same group can only see users on ou=Users of that group, with out hard coding group name in the conf. I guess I'll have to create branches to split up users. Then again, I'm adding a group to ou=Groups, why shouldn't I at the same time add a new ACL via cn=config? Cheers. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk Did you see our API? http://www.surevoip.co.uk/api

1 1

pass-through authentication and base64
by sergio 16 Aug '12

16 Aug '12

Hello. Is it possible to ask openldap not to encode magic tokens for pass-through authentication? Now ldapsearch shows: userPassword:: e1NBU0x9dXNlcm5hbWVAcmVhbG0K== but I'd like to see: userPassword:: {SASL}username@realm instead. -- sergio.

7 16

Fwd: pass-through authentication and base64
by Brett Maxfield 16 Aug '12

16 Aug '12

> This decodes ok as > > {SASL}username@realm > > (omit the trailing ==, before decoding) > > So you mean to delegate auth to a sasl realm called 'realm', containing a user called 'username' ? > > Have you literally added this example value to an ldap entry and dumped it with slapcat ? > > On 15/08/2012, at 10:22 PM, sergio <mailbox(a)sergio.spb.ru> wrote: > >> On 08/15/2012 06:12 PM, Emmanuel Lécharny wrote: >> >>> e1NBU0x9dXNlcm5hbWVAcmVhbG0K== >> >> ONCE AGAIN: >> >> This is my bad example. Real values in the database have no newline or >> some other non-ASCII non printable characters. >> >> It even can't be correctly decoded. >> >> >> -- >> sergio. >

1 0

openldap 2.2 - slapd monitor not showing cachesize, dncachsize etc.
by ping-shin ching 16 Aug '12

16 Aug '12

Hi, I've configured slapd.conf for monitoring with the config below. The backend is bdb ====database monitoraccess to * by * read==== Now when I do the search below, I see a lot of information, but do not see the attibutes 'cachesize', 'dncachesize' etc. ldapsearch -x -D 'cn=Manager,o=bigpond,c=au' -W -b 'cn=Monitor' -s base '(objectClass=*)' '*' '+' version: 1dn: cn=MonitorobjectClass: monitorServerstructuralObjectClass: monitorServercn: Monitordescription: This subtree contains monitoring/managing objects.description: This object contains information about this server.createTimestamp: 20120814040144ZmodifyTimestamp: 20120814040144ZmonitoredInfo: @(#) $OpenLDAP: slapd 2.2.30- (Aug 13 2012 11:53:25) $subschemaSubentry: cn=SubschemahasSubordinates: TRUE dn: cn=Overlay,cn=MonitorobjectClass: monitorContainerstructuralObjectClass: monitorContainercn: OverlaycreateTimestamp: 20120814040144ZmodifyTimestamp: 20120814040144ZsubschemaSubentry: cn=SubschemahasSubordinates: FALSE

2 1

delta-syncrepl stopped receiving changes
by David Hawes 15 Aug '12

15 Aug '12

My environment consists of 1 provider and 6 consumer machines using delta-syncrepl for replication. For some reason, one of the consumer machines stopped receiving changes for several days and did not resume syncing until a restart (SIGKILL). All machines are running 2.4.30 with BerkeleyDB 4.7.25 (plus patches), the hdb backend, and tcmalloc. I notice that 2.4.31 has several syncrepl fixes, and I intend to upgrade in the near future, but my issue seems different than the ITS issues listed in the change log. I'm posting here to determine if this has been fixed or if I need to create a new ITS issue. When I noticed one of the machines was not syncing properly I first ensured that I could still query it. When I verified that, I decided to change the LogLevel to 'any' to make sure I wasn't missing any logs that would help me figure out what the issue was. Unfortunately, this LDAP modify caused OpenLDAP to hang. The operation never finished, and new queries using ldapsearch would simply hang as well. At this point I got a gdb backtrace and db_stat from BDB. db_stat -c: ===== Default locking region information: 640 Last allocated locker ID 0x7fffffff Current maximum unused locker ID 9 Number of lock modes 3000 Maximum number of locks possible 1500 Maximum number of lockers possible 1500 Maximum number of lock objects possible 80 Number of lock object partitions 47 Number of current locks 1262 Maximum number of locks at any one time 19 Maximum number of locks in any one bucket 0 Maximum number of locks stolen by for an empty partition 0 Maximum number of locks stolen for any one partition 340 Number of current lockers 341 Maximum number of lockers at any one time 44 Number of current lock objects 683 Maximum number of lock objects at any one time 6 Maximum number of lock objects in any one bucket 0 Maximum number of objects stolen by for an empty partition 0 Maximum number of objects stolen for any one partition 3799M Total number of locks requested (3799770221) 3799M Total number of locks released (3799714045) 0 Total number of locks upgraded 73 Total number of locks downgraded 73M Lock requests not available due to conflicts, for which we waited (73026840) 5165 Lock requests not available due to conflicts, for which we did not wait 50963 Number of deadlocks 0 Lock timeout value 0 Number of locks that have timed out 0 Transaction timeout value 0 Number of transactions that have timed out 1MB 400KB The size of the lock region 70M The number of partition locks that required waiting (1%) 15M The maximum number of times any partition lock was waited for (0%) 15018 The number of object queue operations that required waiting (0%) 54M The number of locker allocations that required waiting (2%) 0 The number of region locks that required waiting (0%) 6 Maximum hash bucket length ===== The number of deadlocks was pretty shocking; I've never seen that value non-zero. I also have db_stat -C A output if that helps. gdb (syncrepl thread): ===== Thread 12 (Thread 0x444a9950 (LWP 16336)): #0 0x00007f5e087f2b99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x00007f5e08a274fb in __db_pthread_mutex_lock () from /apps/local/depend/BerkeleyDB-4.7.25p4/lib/libdb-4.7.so #2 0x00007f5e08aa5dec in __lock_get_internal () from /apps/local/depend/BerkeleyDB-4.7.25p4/lib/libdb-4.7.so #3 0x00007f5e08aa6d6a in __lock_vec () from /apps/local/depend/BerkeleyDB-4.7.25p4/lib/libdb-4.7.so #4 0x00007f5e08aa72db in __lock_vec_pp () from /apps/local/depend/BerkeleyDB-4.7.25p4/lib/libdb-4.7.so #5 0x000000000054da72 in hdb_cache_entry_db_relock (bdb=0xaec000, txn=0x1031c20, ei=0x3d5e240, rw=1, tryOnly=0, lock=0x444a7b30) at cache.c:198 #6 0x000000000054fe9e in hdb_cache_modify (bdb=0xaec000, e=0x7f5ccb945f58, newAttrs=0x7f5ccf4c1ec0, txn=0x1031c20, lock=0x444a7b30) at cache.c:1231 #7 0x00000000004fc2bd in hdb_modify (op=0x444a86d0, rs=0x444a8040) at modify.c:711 #8 0x00000000004db66f in overlay_op_walk (op=0x444a86d0, rs=0x444a8040, which=op_modify, oi=0xace000, on=0x0) at backover.c:671 #9 0x00000000004db899 in over_op_func (op=0x444a86d0, rs=0x444a8040, which=op_modify) at backover.c:723 #10 0x00000000004db9de in over_op_modify (op=0x444a86d0, rs=0x444a8040) at backover.c:762 #11 0x00000000004c8c59 in syncrepl_message_to_op (si=0xb22000, op=0x444a86d0, msg=0x7f5cf7df5f80) at syncrepl.c:2316 #12 0x00000000004c40dd in do_syncrep2 (op=0x444a86d0, si=0xb22000) at syncrepl.c:986 #13 0x00000000004c61a6 in do_syncrepl (ctx=0x444a8df0, arg=0xb768c0) at syncrepl.c:1522 #14 0x0000000000449003 in connection_read_thread (ctx=0x444a8df0, argv=0x31) at connection.c:1288 #15 0x0000000000591269 in ldap_int_thread_pool_wrapper (xpool=0xa741c0) at tpool.c:688 #16 0x00007f5e087ee3f7 in start_thread () from /lib/libpthread.so.0 #17 0x00007f5e0794dbbd in clone () from /lib/libc.so.6 #18 0x0000000000000000 in ?? () ===== gdb (thread modifying cn=config): ===== Thread 3 (Thread 0x48cb2950 (LWP 29597)): #0 0x00007f5e087f2b99 in pthread_cond_wait@@GLIBC_2.3.2 () from /lib/libpthread.so.0 #1 0x0000000000592806 in ldap_pvt_thread_cond_wait (cond=0xa74220, mutex=0xa741c8) at thr_posix.c:277 #2 0x000000000059162f in handle_pause (tpool=0x8b5420, pause_type=96) at tpool.c:788 #3 0x00000000005916fa in ldap_pvt_thread_pool_pause (tpool=0x8b5420) at tpool.c:831 #4 0x0000000000433ac4 in config_back_modify (op=0x7f5cdc507800, rs=0x48cb1c90) at bconfig.c:5837 #5 0x0000000000468e52 in fe_op_modify (op=0x7f5cdc507800, rs=0x48cb1c90) at modify.c:303 #6 0x0000000000468761 in do_modify (op=0x7f5cdc507800, rs=0x48cb1c90) at modify.c:177 #7 0x0000000000448a65 in connection_operation (ctx=0x48cb1df0, arg_v=0x7f5cdc507800) at connection.c:1150 #8 0x0000000000448fe7 in connection_read_thread (ctx=0x48cb1df0, argv=0x15) at connection.c:1286 #9 0x0000000000591269 in ldap_int_thread_pool_wrapper (xpool=0xa741c0) at tpool.c:688 #10 0x00007f5e087ee3f7 in start_thread () from /lib/libpthread.so.0 #11 0x00007f5e0794dbbd in clone () from /lib/libc.so.6 #12 0x0000000000000000 in ?? () ===== I also have bt full output if needed. Since restarting I have seen no issues with any of the instances and the failed instance synced without issue. Let me know if I should create an ITS. Thanks, Dave

6 8

ldap.conf uri syntax
by Ezra Taylor 15 Aug '12

15 Aug '12

Hello All: Is there a difference between the below uri syntax? Thanks for your help. uri ldap://rhino.bull.com/ ldap://bull.blah.com/ uri ldap://rhino.bull.com ldap://bull.blah.com -- Ezra Taylor

1 1

write an acl with sets and compare connecting peername.ip with ipHost entry (ipHostNumber)
by Uwe Werler 15 Aug '12

15 Aug '12

Hallo all, is it possible to write an ACL (with sets) which extracts the peername.ip from within an existing entry of ipHost an then compares the connecting peername.ip? My idea is to only allow access to this entry by connecting peername.ip 192.168.1.1: dn: cn=myhost.wdf.sap.corp,ou=HOSTS objectClass: ipHost objectClass: device cn: myhost.wdf.sap.corp ipHostNumber: 192.168.1.1 Background: I want to use ovleray nssov and therefore I need all host information at each host locally in ldap. 'cause we have several thousands of hosts I dont want to replicate all ipHosts to each local database. Thanks for any advice/hint. Regards Uwe

1 0

OpenLDAP and virtual directory
by Gilles Tual 14 Aug '12

14 Aug '12

Hi, I was wondering if I could use OpenLDAP backend to simulate a virtual directory for a project. Is it possible ? If yes, is there documentation on it, or help (i'm not a pro on LDAP and virtual directory). Thanks a lot, have a nice day !

2 1

Re:
by Gavin Henry 14 Aug '12

14 Aug '12

Excellent. Thanks for following up. -- Kind Regards, Gavin Henry. Managing Director. T +44 (0) 1224 279484 M +44 (0) 7930 323266 F +44 (0) 1224 824887 E ghenry(a)suretec.co.uk Open Source. Open Solutions(tm). http://www.suretecsystems.com/ Suretec Systems is a limited company registered in Scotland. Registered number: SC258005. Registered office: 24 Cormack Park, Rothienorman, Inverurie, Aberdeenshire, AB51 8GL. Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html Do you know we have our own VoIP provider called SureVoIP? See http://www.surevoip.co.uk On 14 Aug 2012, at 10:25, "非人協會" <hkuhaorg(a)gmail.com> wrote: Dear Henry, Thanks for the kindness follow up. The problem has fixed. The root cause of the problem is the wrongly configured slapd.conf Thanks and Regards, Donald 2012/8/10 Gavin Henry <ghenry(a)suretecsystems.com> > On 8 August 2012 04:59, 非人協會 <hkuhaorg(a)gmail.com> wrote: > > Dear All, > > I am new to ldap, I would like to have your kindness assistance in > setting > > up the directory. > > > > We are working on move our old ldap server to a new openldap server, I > have > > install the openldap in Solaris 10 x86 successfully. However I am not > able > > to browse the content using the ldap browser, it shows "Invalid > > Credentials". > > Hi Donald, > > All fixed? > > -- > Kind Regards, > > Gavin Henry. > Managing Director. > > T +44 (0) 1224 279484 > M +44 (0) 7930 323266 > F +44 (0) 1224 824887 > E ghenry(a)suretecsystems.com > > Open Source. Open Solutions(tm). > > http://www.suretecsystems.com/ > > Suretec Systems is a limited company registered in Scotland. Registered > number: SC258005. Registered office: 24 Cormack Park, Rothienorman, > Inverurie, > Aberdeenshire, AB51 8GL. > > Subject to disclaimer at http://www.suretecgroup.com/disclaimer.html > > Do you know we have our own VoIP provider called SureVoIP? See > http://www.surevoip.co.uk > > Did you see our API news? > http://www.surevoip.co.uk/news-events/surevoip-launches-innovative-api >

1 0

Re: representing file pathnames
by Chuck Lever 14 Aug '12

14 Aug '12

Hi- On Aug 9, 2012, at 7:22 PM, Howard Chu wrote: > Michael Ströder wrote: >> Chuck Lever wrote: >>> On Aug 9, 2012, at 2:46 PM, Howard Chu wrote: >>>> Michael Ströder wrote: >>>>> Chuck Lever wrote: >>>>>> We could also use an NFS URL, which would allow us to express the server >>>>>> hostname, a port number, and the pathname in a single string. But both the >>>>>> hostname and pathname are enocded in US-ASCII, not UTF-8, and the NFS URL >>>>>> format employs a fixed pathname separator character. >>>>> >>>>> That's what I would prefer. Think of file browsers which can open the NFS >>>>> mount point just by clicking on it. Same encoding steps as with file URLs. >>>> >>>> This seems the most obvious and natural solution (NFS URL). After all, you are >>>> specifying an NFS resource... >>> >>> I've looked more closely at this idea. While it's got some surface appeal, >>> NFS URLs (RFC 2224) don't specify a generic NFS resource. They specify a >>> webDAV like resource that can be accessed with NFS, called WebNFS (RFC >>> 2054, RFC 20550), which gives clients access via a so-called "public file >>> handle," which is a degenerate NFS FH. >>> >>> WebNFS is defined only for legacy versions of NFS, not for NFSv4. >>> Referrals are supported only in NFSv4. In fact, section 4 of RFC 2224 >>> specifies that clients try version 3 then version 2. NFS version 4 is not >>> discussed. >>> >>> Thus, the form of an NFS URL might be rich enough, but the existing >>> semantics are not equivalent. >> >> I see no reason why it should not be able to use NFS URLs and define the exact >> usage of them for NFSv4. Maybe I'm overlooking something though. > > Agreed. AFAICS the semantics of the URL are for your actual application to > define. We're not talking about URLs that are meant to be served up by an HTTP > server. > > IMO RFC2224 is defective in that it specifies both the URL format and its > associated access methods. URL formats are meant to be "Uniform" which should > mean they are independent of their access methods. In order to use the NFS URL format, I think we would be compelled to correct RFC 2224, probably by issuing an RFC that supersedes it. While certainly possible, I'm not sure the NFSv4 working group is prepared to hold up the NSDB draft for such an undertaking at this point. Naturally there may be simpler alternatives. That said, I can present this design choice (the use of an NFS URL to represent an fs_locations entry in LDAP) to them for discussion. Thanks for the excellent feedback. -- Chuck Lever chuck[dot]lever[at]oracle[dot]com

2 3

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openldap-technical