openldap-software

openldap-software@openldap.org

2719 discussions

Re: Serverside change of time limit for an operation...
by José Marco 22 May '07

22 May '07

I am inspecting the code and I think the point is that the stoptime for the search is calculated before the first pass through the overlay, thus ignoring later changes in the tlimit. I guess I have to manage with the overlay's private info and process the time myself... If there is an easy shortcut, just tell! Thanks for your attention!

1 0

Serverside change of time limit for an operation...
by José Marco 22 May '07

22 May '07

Hi again. Now I'm trying to change the time limit of a search request inside the server. Concretely, inside the search response of an overlay. The thing is: if the client didn't state a time limit (-l <time>), the time limit in the Operation ( op->oq_search.rs_tlimit ) is set to -1. If I change that number to whatever, the result is "result: 3 Time limit exceeded". It is noticeable that when I set the time limit in the client, I am allowed to change the op->oq_search.rs_tlimit value without getting the same result (everything seems to work ok, although I didn't really test if the change in time limit is actually forced). Am I being too innocent, or I can force the time limit for an operation within the server somehow in this way? Thanks for your attention!

1 0

ACL redundancy
by Shane 21 May '07

21 May '07

I've got a kind of ugly annoying ACL problem I can't seem to get my head around solving ... We've got our users, inactive users, addressbooks etc all under ou=contacts ie: ou=users,ou=contacts ou=inactive_users,ou=contacts ou=clients,ou=contacts The conditions the ACL needs to meet (below example isn't there yet). * A user can edit some of their own attributes * A member of the studio group can edit all of above + a few extra attributes * A member of the tech group can edit pretty much anything * Different "address books" can be made viewable only by certain groups (not implemented yet pretty easy though access to dn.children="ou=users,ou=contacts,dc=rsp,dc=com,dc=au" by group blah write by group otherblah read by * none) My problem at the moment is the amount of duplication of the who rules. Also that I don't necessarily want to give the studio group access to edit anything in say ou=clients,ou=contacts but I do want to for ou=users,ou=contacts - mixing and matching the whats is kinda doing my head in :-) almost need a way to have a what that id both dn.children and attrs but that doesn't seem to be allowed ... access to attrs="telephoneNumber,l,mobile,mozillaSecondEmail,homePostalAddress,displayName" by group="cn=tech,ou=authgroups,dc=rsp,dc=com,dc=au" write by group="cn=studio,ou=authgroups,dc=rsp,dc=com,dc=au" write by self write by * read access to dn.children="ou=users,ou=contacts,dc=rsp,dc=com,dc=au" by group="cn=tech,ou=authgroups,dc=rsp,dc=com,dc=au" write by group="cn=studio,ou=authgroups,dc=rsp,dc=com,dc=au" write by * read access to * by * read Any help in "simplifying" this is greatly appreciated as this is only the beginning of stuff I'm being asked to implement :-) TIA Shane.

1 0

Remote Access
by Gregory P. Ennis 21 May '07

21 May '07

I am installing openldap for the first time and having some difficulties getting it working on remote networks. I have been able to have it work perfectly inside a network, but unable to get two other networks communicating properly. This is surely an newbie question, but I have not been able to find the problem. I am running a fedora core 5 system with iptables opened for port 389, I have selinux set to permissive, I have the firewall opened to every port on the specified remote ip addresses. (replaced with "##.##.##.##" below. Would appreciate your help. Greg Ennis My log entry for a network successful connection is as follows: May 20 16:05:59 DeGw slapd[20378]: daemon: activity on 1 descriptor May 20 16:05:59 DeGw slapd[20378]: daemon: activity on: May 20 16:05:59 DeGw slapd[20378]: May 20 16:05:59 DeGw slapd[20378]: >>> slap_listener(ldap:///) May 20 16:05:59 DeGw slapd[20378]: daemon: listen=8, new connection on 12 May 20 16:05:59 DeGw slapd[20378]: daemon: added 12r (active) listener=(nil) May 20 16:05:59 DeGw slapd[20378]: conn=2 fd=12 ACCEPT from IP=10.0.0.12:41669 (IP=0.0.0.0:389) May 20 16:05:59 DeGw slapd[20378]: daemon: epoll: listen=7 active_threads=0 tvp=NULL .................................... ................................... My log entry for a remote connect failure is as follows: May 20 15:20:05 DeGw slapd[20378]: daemon: activity on 1 descriptor May 20 15:20:05 DeGw slapd[20378]: daemon: activity on: May 20 15:20:05 DeGw slapd[20378]: May 20 15:20:05 DeGw slapd[20378]: >>> slap_listener(ldap:///) May 20 15:20:05 DeGw slapd[20378]: daemon: listen=8, new connection on 12 May 20 15:20:05 DeGw slapd[20378]: fd=12 DENIED from unknown (##.###.##.###) May 20 15:20:05 DeGw slapd[20378]: daemon: closing 12 May 20 15:20:05 DeGw slapd[20378]: daemon: epoll: listen=7 active_threads=0 tvp=NULL May 20 15:20:05 DeGw slapd[20378]: daemon: epoll: listen=8 active_threads=0 tvp=NULL

2 2

Problem with OpenLDAP 2.3.19-4
by Eugenia Candida Oliveira de Moura 20 May '07

20 May '07

Hi, I'm testing API "JLDAP - LDAP Class Libraries will be Java" with the version of the openldap 2.3.19-4. I configured openldap and executed the ExtendSchema.java example then I got the following error: Error: LDAPException: Invalid Attribute Syntax (21) Invalid Attribute Syntax LDAPException: Server Message: attributeTypes: value #0 invalid per syntax LDAPException: Matched DN: at com.novell.ldap.LDAPResponse.getResultException(Unknown Source) at com.novell.ldap.LDAPResponse.chkResultCode(Unknown Source) The syntax generated for the API LDAPAttributeSchema is the following one: ( 2.5.4.130 NAME 'cesmic' DESC 'testing' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) The problem is not accurately in this syntax, therefore I obtain to add to an attribute using a LDIF that this same syntax. When use one ldif, the error above does not appear. I'm only trying to add attributeTypes using API JLDAP. Any idea on what's going on?

1 0

slapd hanging on startup, apparently in BDB mutex lock?
by Greg Earle 19 May '07

19 May '07

Hi folks, In 25 years of using UNIX I've seen my share of baffling problems but this is right up there with the best of them. We run slapd (2.1.22 - they are under Configuration Management freezes for Operations) on 2 Solaris 9 systems, master & replicant, and things had been running just fine. After experiencing some NFS issues with our NetApp, we made the decision to copy the file systems that the LDAP servers (also our NIS servers) depend on to local disk on those two systems. A few days ago my officemate noticed the replicant "slapd" wasn't accepting connections. I looked and it showed the ldap port 389 as being in BOUND state, not LISTEN. The master was still LISTENing but queries to it would return results and then hang. "lsof" of that server showed that these connections ended up being stuck in CLOSE_WAIT state. At some point both machines were rebooted, and now each one has the same problem - "slapd" isn't coming up all the way. It gets as far (running in debug -1 mode) as this: slapd startup: initiated. bdb_db_open: dc=my,dc=top,dc=level,dc=domain bdb_db_open: dbenv_open(/opt/openldap/var/openldap-data) If I run it under truss, the last thing I see before it appears to hang is it opening one of the .bdb files: 1333: open64("/opt/openldap/var/openldap-data/dn2id.bdb", O_RDWR) = 11 It then does a write() and a few brk()'s and then hangs in an LWP. If I ^\ it, it dumps core and the traceback is ldap1:1:195 [/usr/local/src/networking/OpenLDAP/openldap-2.1.22] # adb /opt/openldap/libexec/slapd core core file = core -- program ``/opt/openldap/libexec/slapd'' on platform SUNW,Ultra-60 SIGQUIT: Quit $C ffbff430 libc.so.1`___lwp_cond_wait+8(fea38cd0, fea38cb8, 0, 9c1ac, b97ac, 13e6b0) ffbff490 libdb-4.1.so`__db_pthread_mutex_lock+0xac(13c838, fea38cb8, 1, fea38cd0, ff2cb824, 0) ffbff4f0 libdb-4.1.so`__lock_get_internal+0xbf4(1397e8, 0, 0, 0, 1, 1397e8) [...] ffbff7e8 bdb_last_id+0x138(0, 0, 87100, 103178, 4, 0) ffbff890 bdb_db_open+0x384(0, 87000, 58000, 9e510, 41, 9e534) ffbff908 backend_startup+0x25c(9f000, 1, 800, 0, 0, f57c8) ffbff978 main+0x6a4(9, ffbffa54, 1, 76388, 88, 9d000) ffbff9f0 _start+0x5c(0, 0, 0, 0, 0, 0) It never gets as far as seeing 'slapd starting' so the listeners never put the socket(s) into LISTEN state. It looks to me like the "slapd" startup is stuck down in the BerkeleyDB (4.1.25) code waiting on some kind of a pthreads mutex lock. I've stared at the relevant routine (mutex/mut_pthread.c) but have no clue what the holdup is. (Though I note ominously that it contains several "#ifdef HAVE_MUTEX_SOLARIS_LWP" clauses.) I have no idea what changed to cause this to happen or why it's waiting on the lock, much less know what to do about it to solve it. Any ideas??? Should I try rebuilding BerkeleyDB 4.1.25 with a different mutex that doesn't use Solaris LWP's? Thanks in advance, - Greg

3 2

sql-test901-syncrepl fails UGH
by will＠nanomaterialsdiscovery.com 19 May '07

19 May '07

Hello list: This is using all the latest versions on Ubuntu or Debian linux. SLAPD_USE_SQL='mysql' SLAPD_USE_SQLWRITE='yes' make sql failed (exit 1) sql-test901-syncrepl failed created this log and this message apparently mysql does not support writes; skipping... >>>>> Test succeeded backend_startup_one: starting "dc=example,dc=com" ==>backsql_db_open(): testing RDBMS connection backsql_db_open(): datasource name not specified (use "dbname" directive in slapd.conf) backend_startup_one: bi_db_open failed! (1) slapd shutdown: initiated Why oh why. Wct

2 1

[OpenLDAP 2.3.*] Modify Schema
by Eugenia Candida Oliveira de Moura 18 May '07

18 May '07

Hi, I'm using ldif below and when I seat he executes gives it the following error: ldapadd: invalid format (line 5) entry: "cn=schema,cn=config" LDIF: dn: cn=schema,cn=config changetype: modify add: olcAttributeTypes olcAttributeTypes: ( 2.5.4.123 NAME 'name' DESC 'description' EQUALITY caseIgnoreMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) What problem with LDIF? Thanks.

2 3

slurpd replication problem
by David Browning 18 May '07

18 May '07

I have tried to review all possible documentation and read through all mailing list archives relevant to this problem. My apologies if this has been covered before and I have missed it. No matter what kind of change I make I continue to get err=19 when I try to replicate. May 17 23:25:35 ldap2 slapd[3097]: conn=1 op=8 MOD attr=description entryCSN modifiersName modifyTimestamp May 17 23:25:35 ldap2 slapd[3097]: conn=1 op=8 RESULT tag=103 err=19 text=entryCSN: no user modification allowed I am running Fedora Core 5 with ldap version openldap-servers-2.3.30-2.fc5 on both the master and slave. I currently am using the rootdn simply because there shouldn't be any restrictions on that user. I was using a different user previously with the exact same results. Both systems have an exact copy of the same LDAP db. Here is my master LDAP slapd.conf file. include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/officeperson.schema include /etc/openldap/schema/RADIUS-LDAPv3.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/pki/tls/certs/ldap.intelligraphics.com-crt.crt TLSCertificateKeyFile /etc/pki/tls/certs/ldap.intelligraphics.com-key.pem access to attrs=userPassword,sambaLMPassword,sambaNTPassword by group="cn=ldapadmins,ou=Groups,dc=intelligraphics,dc=com" write by self write by anonymous auth by * none access to attrs=uid by group="cn=ldapadmins,ou=Groups,dc=intelligraphics,dc=com" write by * read access to attrs=mail,homeemail,telephonenumber,homephone,mobile,ipphone,facsimiletelephonenumber,postaladdress,l,st,postalcode,c,comment,description by group="cn=phoneadmins,ou=Groups,dc=intelligraphics,dc=com" write by group="cn=ldapadmins,ou=Groups,dc=intelligraphics,dc=com" write by self write by * read access to attrs=o by group="cn=phoneadmins,ou=Groups,dc=intelligraphics,dc=com" write by group="cn=ldapadmins,ou=Groups,dc=intelligraphics,dc=com" write by self write by * read access to * by group="cn=ldapadmins,ou=Groups,dc=intelligraphics,dc=com" write by self write by * read database bdb suffix "dc=intelligraphics,dc=com" rootdn "cn=Manager,dc=intelligraphics,dc=com" rootpw password directory /var/lib/ldap index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq replogfile /var/lib/ldap/openldap-master-replog replica uri=ldap://ldap2.intelligraphics.com binddn="cn=Manager,dc=intelligraphics,dc=com" bindmethod=simple credentials=password Here is my slave LDAP slapd.conf file. include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/samba.schema include /etc/openldap/schema/officeperson.schema include /etc/openldap/schema/RADIUS-LDAPv3.schema allow bind_v2 pidfile /var/run/openldap/slapd.pid argsfile /var/run/openldap/slapd.args TLSCACertificateFile /etc/pki/tls/certs/ca-bundle.crt TLSCertificateFile /etc/pki/tls/certs/openvpn.intelligraphics.com-cert.pem TLSCertificateKeyFile /etc/pki/tls/certs/openvpn.intelligraphics.com-key.pem access to attrs=userPassword,sambaLMPassword,sambaNTPassword by group="cn=ldapadmins,ou=Groups,dc=intelligraphics,dc=com" write by self write by anonymous auth by * none access to attrs=uid by group="cn=ldapadmins,ou=Groups,dc=intelligraphics,dc=com" write by * read access to attrs=mail,homeemail,telephonenumber,homephone,mobile,ipphone,facsimiletelephonenumber,postaladdress,l,st,postalcode,c,comment,description by group="cn=phoneadmins,ou=Groups,dc=intelligraphics,dc=com" write by group="cn=ldapadmins,ou=Groups,dc=intelligraphics,dc=com" write by self write by * read access to attrs=o by group="cn=phoneadmins,ou=Groups,dc=intelligraphics,dc=com" write by group="cn=ldapadmins,ou=Groups,dc=intelligraphics,dc=com" write by self write by * read access to * by group="cn=ldapadmins,ou=Groups,dc=intelligraphics,dc=com" write by self write by * read database bdb suffix "dc=intelligraphics,dc=com" rootdn "cn=Manager,dc=intelligraphics,dc=com" rootpw password directory /var/lib/ldap index objectClass eq,pres index ou,cn,mail,surname,givenname eq,pres,sub index uidNumber,gidNumber,loginShell eq,pres index uid,memberUid eq,pres,sub index nisMapName,nisMapEntry eq,pres,sub index sambaSID,sambaPrimaryGroupSID,sambaDomainName eq updatedn="cn=Manager,dc=intelligraphics,dc=com" updateref="ldap://ldap.intelligraphics.com" Does anyone have any ideas on what to try? David Browning david.browning(a)intelligraphics.com

3 4

caching authentication proxy
by pkoelle＠gmail.com 18 May '07

18 May '07

Hi list, I need to replicate information from a remote LDAP server, however the target server populates the userPassword field with '*********' and stores credentials in a custom SASL backend to auth SASL binds and simple binds. What I need is: a) enable clients to do simple binds to my openldap server b) the openldap server should continue to work when the network link/remote server is down. The solution to point a) would be using back-ldap with rebind-as-user=yes as all identities exist on the remote server (no idassert necessary right?). Point b) seems trickier however. The proxycache overlay might provide some redundancy when the remote server is down but this is far from ideal since high values for cache ttl will prevent changes on the remote server to be visible. What I don't know is whether proxy-cache caches bind information. If it doesn't, this setup is a nogo ;( Ideally, slapd would try to authenticate the client locally and if that fails ask the remote server and update the local entry on success. But this smells like it needs an overlay. I apologize if the description is a bit vague, or my assumptions are wrong. I haven't explored all possibilities yet but would like to avoid errors early in the design. thanks Paul

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-software