openldap-software

openldap-software@openldap.org

2719 discussions

RE: Logging in OpenLDAP
by knassden 23 May '07

23 May '07

Hi, I'm having problems getting logs with slapd. In my slapd.conf, I have "loglevel 256". In my syslog.conf, I have "local4.* /var/log/ldap.log". I configured openldadp with "--enable-syslog --enable-debug". I start openldap with "/usr/local/libexec/slapd -u _openldap -g _openldap -f /etc/openldap/slapd.conf". I touched /var/log/ldap.log. I get no logs though. This is OpenLDAP 2.3.35 on OpenBSD 4.1. Anyone know what I'm missing here??? Thanks, Mike

2 1

passwd backend operational?
by Jorge Amador Arenas Quezada 23 May '07

23 May '07

Hi: > I'm trying to use openldap service to authenticate users of my openfire > messenger with my already created users in /etc/passwd > > but i have problems and i want help in two things > > 1.- in some information collected in internet found references about the > backend passwd support claiming about not use this module because is > not fully > implemented (the read only condition is not a problem because i only > want to > authenticate my users in passwd) ... my first question is ... is > operational > this module ? > > 2.- if it is operational i have a several errors when i try to > authenticate > users with the message: > > May 20 23:03:01 server slapd[6781]: conn=77 fd=8 ACCEPT from > IP=127.0.0.1:42219 (IP=0.0.0.0:389) > May 20 23:03:01 server slapd[6781]: conn=77 op=0 BIND > dn="cn=root,dc=lachoza,dc=com,dc=mx" method=128 > May 20 23:03:01 server slapd[6781]: conn=77 op=0 RESULT tag=97 err=53 > text=operation not supported within naming context > May 20 23:03:01 server slapd[6781]: conn=77 op=1 UNBIND > May 20 23:03:01 server slapd[6781]: conn=77 fd=8 closed > > > my sldap.conf > > include /etc/openldap/schema/core.schema > include /etc/openldap/schema/cosine.schema > include /etc/openldap/schema/inetorgperson.schema > include /etc/openldap/schema/nis.schema > allow bind_v2 > pidfile /var/run/slapd.pid > argsfile /var/run/slapd.args > database passwd > readonly yes > suffix "dc=lachoza,dc=com,dc=mx" > rootdn "cn=root,dc=lachoza,dc=com,dc=mx" > rootpw $$$$$$$$ > 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 >

2 1

Using OpenLDAP without the support of OpenSSL - reg.
by Aviator LDap 22 May '07

22 May '07

Hi All, I want to develop an application that uses OpenLDAP without OpenSSL functionalities. Can anybody help me to know how to eliminate the openSSL libraries from openLDAP? thanks in advance, regards, dinesh.

3 2

IDL cache and a mix of index/unindexed attrs in a query
by Quanah Gibson-Mount 22 May '07

22 May '07

I'm never 100% sure I understand how the idl cache works, but as I understand it, it caches the index keys of common searches, where the attributes are indexed. Assuming my understanding is correct, my question has to do with how things behave when some of the attributes are indexed, and some aren't. For example, assume: a - indexed eq, a match only returns a single entry in the DB b - unindexed, only has one possible value if present c - unindexed, only has one possible value if present A query of (&(a=x)(b=y)(c=z)) performs very quickly because the a=x filter is applied first, and locates the object, with the remaining pieces of the filter being applied to the entry that was found. My question is, does this query end up in the IDL cache? I played around with this somewhat, and I see no difference in search times between: (a=x) (&(a=x)(b=y)) (&(a=x)(by=y)(c=z)) In this usage case, then, is there really any benefit to indexing b & c? --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

2 1

Re: Building a centralized database from various LDAP servers
by pkoelle＠gmail.com 22 May '07

22 May '07

Adam Brandizzi schrieb: > Hi! > > On 5/22/07, pkoelle(a)gmail.com <pkoelle(a)gmail.com> wrote: >> I'd setup the central server as a syncrepl consumer to all the branch >> offices, with one database context for each. Optionally those can be >> glued together with back-ldap. > > I tried it, but I've tried to replicate subtrees using SyncRepl, which > does not work. Since then, I was thinking OpenLDAP 2.3 does not suport > multiple SyncRepl configurations at all, but now I am wondering > whether it is possible to create one SyncRepl instance for each > database context... So, does LDAP support one SyncRepl directives for > each database context? from http://www.openldap.org/doc/admin23/syncrepl.html#Syncrepl%20Details If a syncrepl specification is included in a database definition, slapd (8) launches a syncrepl engine as a slapd (8) thread and schedules its execution. I read this as each database definition can have its own syncrepl statement. Hence the schema would be something like: database bdb directory /var/lib/ldap/sub1 suffix dc=sub1,dc=example,dc=com ....more config.... syncrepl rid=001 ...more syncrepl stuff... database bdb directory /var/lib/ldap/sub2 suffix dc=sub2,dc=example,dc=com ....more config.... syncrepl rid=002 ...more syncrepl stuff... > > Anyway, this configuration seems to have a problem: AFAIK back-bdb > (which is the backend we are using for actually storing the data) does > not support multiple database contexts on OpenLDAP 2.3. Im I wrong? If > not, has anyone an idea about how to handle it? Use one "database" statement for each naming context >> Using the chain overlay on the central >> server, writes will be internally redirected to the branch office and >> you won't have to deal with referrals manually. Of course, if the branch >> is down writes will fail... > > But why should I redirect the write requests to the branch? Actually, > the branchs will receive the write requests, and replicate it to the > central. Am I missing something? Sorry, I am a bit newbie :) That's just if you need to write to the central server (which is a slave from a replication point of view) and don't want to deal with referrals manually[1]. If you only write to the branch offices; no need for the chain overlay. hth Paul [1] If you try to write to a slave you'll get back a referral (hopefully) which is just a ldap URL which points to the master and you have to manually rebind to the master and retry the operation. It's hard to support referrals in a general way because you would need to make assumptions about the identities to use for the rebind etc., Hence most clients don't support referrals and the chain overlay is a very handy solution;)

1 0

Doubts about callback sequence and attribute retrieval...
by José Marco 22 May '07

22 May '07

Hi all! I'm observing some unexpected (not surprising, though) behaviour with overlays. I programmed a subgroup expansion overlay. It takes a DN in an attribute and copies one of its attributes to the containing entry (much in the same way as ExpandURL) Now I'm trying to use that overlay together with dynlist: Let dynlist expand an URL attribute into the entry and then let the new overlay explore the retrieved DNs. My idea is to let the callback do the work: just chain both overlays... The resutls are not as expected: no matter the order a use in the overlay stack, my overlay won't see the values retrieved by dynlist. I think it has to do with the way the attribute values are retrieved. I have tried backend_attribute(...) an fe_acl_attribute(...) in my code but both seem to skip the overlay chain. I guess they take the attribute values from the backend thus ignoring the ones retrieved "artificially" by dynlist... So the question is: is there an easy way of searching the attribute values from an Entry itself instead of against the backend? Does anyone remember any example in the official code where I can look? And, by the way, what does the final _ex in some function names mean? Thanks for your attention!

2 1

syncrepl and subordinate databases
by Raphaël 'SurcouF' Bordet 22 May '07

22 May '07

Hi, I'm using OpenLDAP 2.3.35 with a distributed architectures with many databases in the same naming context. I've designed a scheme of my architecture for easier understanding : http://img370.imageshack.us/img370/693/architectureldapossaud3.png I've three OpenLDAP servers (more in the near future) named for this example like this following list : - META-ANNUAIRE : this server host many databases which have subordinate relations between them, - FRONT-END : One of the two front-end LDAP servers which have only one database: a replica (over syncrepl) of the top database of META-ANNUAIRE, - OSSA : a server of an sub-organization which provides (over syncrepl) a branch of the context naming to META-ANNUAIRE. META-ANNUAIRE is a syncprov provider and a syncrepl consumer. Database "dc=linagora,dc=com" is provided by syncprov. Others databases are provided by servers of sub-organizations using a synrecpl definition. Theses databases are subordinate to the first database using the directive named "subordinate". I've already set glue overlay for this database because of syncprov overlay. I can't retreive datas from servers like OSSA with FRONT-END servers as I can with META-ANNUAIRE. The database "dc=sp,dc=linagora,dc=com" isn't yet replicated by syncrepl but I've the same problem with theses datas. Can I replicate over syncrepl a database with many databases that are subordinate to the first with all datas ? Regards, PS: I'm using OpenLDAP 2.3.35 under Solaris 10. -- Raphaël 'SurcouF' Bordet

3 5

UNKNOWN attributeDescription
by Douglas B. Jones 22 May '07

22 May '07

I have an older ldap, 2.3.27, and I recently added a new ldap attribute called gpcmailxfergroup. Here is the schema line: attributetype ( 1.3.6.1.4.1.17432.1.20 NAME 'gpcmailxfergroup' DESC 'which group a mail id is in for the mail xfer' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) and I added it to the objectclass for us (called gpcentry) as I have added a number before. When I do a slapcat, I get: UNKNOWN attributeDescription "GPCMAILXFERGROUP" inserted. I apologize if this should be posted at umich ldap group, but I was not sure if this might be an openldap issue. If I am wrong, I will be glad to repost. Thanks!

2 1

Building a centralized database from various LDAP servers
by Adam Brandizzi 22 May '07

22 May '07

Hi, people! My company asks me to build an LDAP server network where there is a big central server storing data from all the company and various minor servers, one for each branch office, where only the sensitive data for the office is stored. The good way is to do some replication with slurpd or syncrepl, copying data registered on the central server to the minor, local servers. The problem is that they've requested me to follow the bad way: it was required that the data must be stored on the minor, local server first, and replicated to the central server after. I know it is multimaster replication and it is dangerous, not kosher and whatnot, but they insist on using this topology. Also, they don't want to use some other external application. The problem is that the Internet links are very unstable here, and expecting a write on the central server and its posterior replication can stop an office for some days. So, I've followed the ugly way, doing some complex workarounds with slurpd and imposing some restrictions to the data. However, it is clear that what I have done is not correct: it is very hard to understand and to maintain, it uses some undocumented OpenLDAP features, it makes impossible to use TLS for authentication etc. So, I'd like to ask: does anyone have some tip on what to do in this situation? Does anyone have an idea about how to implement this exotic replication model on a reasonably simple way? I hope so... :) Thanks in advance!

2 1

Access control entries problem
by Vincent Batoufflet 22 May '07

22 May '07

Hi everyone, I try to setup some access rules for some openldap servers but I am experiencing some difficulties with Access Control Entries. I want to allow anonymous access to a specific branch of my ldap tree (autofs mount points): ou=mount,o=organization,dc=domain,dc=com This rule works perfectly if I comment all others rules, but when at least one of them is commented out, it isn't working anymore. Do you have any idea ? Thanks. See above my ldap access rules: # Default access rule defaultaccess search # Access to passwords access to attrs=userPassword by dn="cn=replication,ou=role,dc=domain,dc=com" write by dn="cn=system,ou=role,dc=domain,dc=com" read by dn="cn=ftp-client,ou=role,dc=domain,dc=com" read by self write by * auth # FTP access access to dn.subtree="ou=ftp,o=organization,dc=domain,dc=com" by dn="cn=replication,ou=role,dc=domain,dc=com" write by dn="cn=ftp-manager,ou=role,dc=domain,dc=com" read by dn="cn=ftp-client,ou=role,dc=domain,dc=com" read # AutoFS access acces to dn.subtree="ou=mount,o=organization,dc=domain,dc=com" by dn="cn=replication,ou=role,dc=domain,dc=com" write by anonymous read # Global accesses access to * by dn="cn=replication,ou=role,dc=domain,dc=com" write by dn="cn=system,ou=role,dc=domain,dc=com" read by dn="cn=extranet,ou=role,dc=domain,dc=com" read # Access to the base (prevent SASL problems) access to dn.base="" by * read -- Vincent Batoufflet Buf Compagnie 3 rue Roquepine 75008 Paris, FRANCE tel +33 1 42 68 18 28 - fax +33 1 42 68 18 29

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