a small patch for back-sql
by Robert Brooks
Pierangelo,
back-sql fails to compile with BACKSQL_TRACE defined, I think this is
the correct fix.
It also appears that objectClass searches fail (with mysql odbc) if
there is no data in the ldap_entry_objclasses table. Just a simple dummy
entry like this is enough to fix the problem.
+----------+----------+
| entry_id | oc_name |
+----------+----------+
| 0 | dcObject |
+----------+----------+
Let me know if you'd like more information.
I believe this is the issue noted here...
http://www.openldap.org/lists/openldap-software/200508/msg00450.html
Regards,
Rob
--
Robert Brooks, Network Manager, Cable & Wireless UK
<robb(a)wtg.cw.com> http://wtg.cw.com/
Tel: +44 (0)20 7339 8600 Fax: +44 (0)20 7339 8601
- "What was your username again?" - BOFH -
16 years, 11 months
Question about conn_max_pending configuration options
by TechnoSophos
On the conn_max_pending and conn_max_pending_auth params, what exactly
is a "pending request"? Is this a request that slapd has not yet
processed? For example, is a search request "pending" if slapd is in
the process of evaluating it, but has not yet returned?
Thanks,
Matt
16 years, 11 months
using jpegPhoto
by Roger Thomas
I came across the . Database Creation and Maintenance Tools at http://www.openldap.org/doc/admin23/dbtools.html which outlined 2 methods of storing jpegPhoto (towards the end of the documentation). One using base64 encode and the other using location indicated by URL:
# Bjorn's Entry
dn: cn=Bjorn J Jensen,dc=example,dc=com
cn: Bjorn J Jensen
cn: Bjorn Jensen
objectClass: person
sn: Jensen
# Base64 encoded JPEG photo
jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD
A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ
ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG
# Jennifer's Entry
dn: cn=Jennifer J Jensen,dc=example,dc=com
cn: Jennifer J Jensen
cn: Jennifer Jensen
objectClass: person
sn: Jensen
# JPEG photo from file
jpegPhoto:< file:///path/to/file.jpeg
Which is the recommended method? Please advise.
--
roger
---------------------------------------------------
Sign Up for free Email at http://ureg.home.net.my/
---------------------------------------------------
16 years, 11 months
Re: Question about conn_max_pending configuration options
by Howard Chu
TechnoSophos wrote:
> Thanks. Your answer was more informative than I had hoped for.
>
> At what point will the server start denying service to incomming
> connections? Or will it ever?
It doesn't do so explicitly. When it runs out of descriptors, obviously
it won't be able to handle any more connections.
>
> Does the timelimit (or limit) directive in slapd.conf apply to those
> requests that are sitting there waiting to be handled? In other words,
> is it possible for a request to time out before it has been handled?
> In this case, I would guess that it would still sit in the queue until
> a thread picks it up, in which case it would immediately return a
> timelimit exceeded error. Is that right?
No, the timelimit controls how long the request actually executes, so it
is based on when the request starts executing. The time the request
spends in various queues is not execution time.
> Also, as long as I'm on the topic of threads, is there a convenient
> way to calculate the cost of adding threads? If I want to double the
> thread pool, how many additional reasources will this take?
There are a number of large chunks of memory allocated per thread. First
is the actual thread stack, which defaults to 1048576 * sizeof(pointer),
so 4MB on a 32 bit machine and 8MB on a 64 bit machine. Also slapd
allocates a 1MB slab per thread for per-operation temporary storage. The
back-bdb/hdb backends also allocate a search stack per thread, for
evaluating indexed filters. As documented in the slapd-bdb(5) manpage,
this defaults to 8MB per thread. Those are the most obvious costs in the
OpenLDAP code; the C library and whatever other libraries you're using
(OpenSSL etc.) have their own per-thread overheads.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 11 months
proxying authentication
by sishkebab
Hi everyone,
consider the following setup:
* A central accounts OpenLDAP directory, where user credentials are stored,
among others.
* An LDAP enabled service using a separate OpenLDAP directory containing
service related attributes for a subject of the user objects contained in
the central directory.
Is it possible to configure my servers so that users connecting to the
service directory can authenticate using the credentials stored in the
central directory, while the proccess stays transparent for the end user?
I know that this may be achieved by replicating user credentials to the
service directory, but it would be prefered if it was done without
replication.
So, is there any way doing it, either using some overlay or some means of
proxy authentication?
Thanks,
Michalis
16 years, 11 months
Still unable to configure glue and rwm overlay correctly
by Andrew Kay
Hi,
I am attempting to configure OpenLDAP such that it acts as a
subordinate to a Microsoft Active Directory server, and presents a
unified directory tree to any applications. The directory tree I am
aiming for is as follows:
ou=XYZ, dc=xyz, dc=com Microsoft Active Directory
ou=Extranet, ou=XYZ, dc=xyz, dc=com OpenLDAP bdb database (subordinate)
I was previously having problems with the rewrite rules required to
ensure that user and group objects within AD were transformed into
inetOrgPerson and groupOfName objects that are being stored in the
"ou=Extranet, ou=XYZ, dc=xyz, dc=com", thanks to Howard Chu's response
I have altered my configuration file and the rewriting now only occurs
to the directory entries stored within the AD portion.
The database section of my configuration file is now as follows:
database bdb
suffix "ou=Extranet, ou=XYZ, dc=xyz, dc=com"
rootdn "cn=Manager, ou=Extranet, ou=XYZ, dc=xyz, dc=com"
rootpw secret
directory /usr/local/var/openldap-data
index objectClass eq
database ldap
suffix "ou=XYZ, dc=xyz, dc=com"
uri "ldap://dc1"
acl-bind
bindmethod=simple
binddn="cn=Andrew Kay, ou=Users, ou=XYZ, dc=xyz, dc=com"
credentials="secret"
idassert-bind
bindmethod=simple
binddn="cn=Andrew Kay, ou=Users, ou=XYZ, dc=xyz, dc=com"
credentials="secret"
mode=none
authzId="dn:cn=Andrew Kay, ou=Users, ou=XYZ, dc=xyz, dc=com"
idassert-authzFrom "dn.children:ou=XYZ, dc=xyz, dc=com"
overlay rwm
rwm-map objectclass inetOrgPerson user
rwm-map objectclass groupOfNames group
rwm-map attribute uid sAMAccountname
rwm-map attribute cn name
rwm-map attribute sn sn
rwm-map attribute mail mail
rwm-map attribute member member
rwm-map attribute *
overlay glue
glue-sub "ou=Extranet, ou=XYZ, dc=xyz, dc=com"
With the above configuration, while the rewrite only occurs to
directory entries stored within the AD portion, the functionality I
expected from the glue overlay no longer appears.
If I perform a search with a base "ou=XYZ, dc=xyz, dc=com" entries
from the "ou=Extranet, ou=XYZ, dc=xyz, dc=com" portion of the
directory are not retrieved, unless I explicility set the search base
to that portion. Obviously in order to unify the two databases I
would wish entries from the "ou=Extranet, ou=XYZ, dc=xyz, dc=com"
portion of the directory to be included along with entries from the AD
portion when the search base is "ou=XYZ, dc=xyz, dc=com".
I am running OpenLDAP version 2.3.30.
I'd greatly appreciate any help I could get in achieving the correct
glue configuration.
Andrew
Below is an example showing how unless the search base is explicitly
set to the "ou=Extranet, ou=XYZ, dc=xyz, dc=com" portion of the
directory, the entries are not retrieved:
extranet:~# ldapsearch -x -D "cn=Manager, ou=Extranet, ou=XYZ,
dc=xyz, dc=com" -W -b "ou=XYZ, dc=xyz, dc=com" "(uid=john.smith)"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=XYZ, dc=xyz, dc=com> with scope subtree
# filter: (uid=john.smith)
# requesting: ALL
#
# search result
search: 2
result: 0 Success
# numResponses: 1
extranet:~# ldapsearch -x -D "cn=Manager, ou=Extranet, ou=XYZ,
dc=xyz, dc=com" -W -b "ou=Extranet, ou=XYZ, dc=xyz, dc=com"
"(uid=john.smith)"
Enter LDAP Password:
# extended LDIF
#
# LDAPv3
# base <ou=Extranet, ou=XYZ, dc=xyz, dc=com> with scope subtree
# filter: (uid=john.smith)
# requesting: ALL
#
# John Smith, Users, Extranet, XYZ, xyz.com
dn: cn=John Smith,ou=Users,ou=Extranet,ou=XYZ,dc=xyz,dc=com
objectClass: inetOrgPerson
cn: John Smith
sn: Smith
uid: john.smith
userPassword:: am9obi5zbWl0aA==
# search result
search: 2
result: 0 Success
# numResponses: 2
# numEntries: 1
extranet:~#
16 years, 11 months
Re: ldapsearch performance debugging
by Howard Chu
Chris Hane wrote:
> Howard,
>
> Thanks! The strace did it. It showed me that it was delaying on a
> poll() event to our dns servers. Once I fixed that, all is working like
> I expect.
Glad to hear it. Please keep all replies on the mailing list, so that
others can also see the resolution of the question.
>
> Thanks again,
> Chris....
>
> Howard Chu wrote:
>> Chris Hane wrote:
>>> When I execute the following command:
>>>
>>> ldapsearch -v -x -b "dc=abmas,dc=biz" -d 5 -h 127.0.0.1
>>>
>>> there is a significant lag between hitting return and when I see the
>>> debug output - 6-8 seconds.
>>>
>>> I'm pretty sure this is a configuration problem or network problem on
>>> my end as this same command in a different environment executes
>>> immediately.
>>>
>>> To help me isolate where the problem is, is there another method to
>>> debug what ldapsearch is doing before I see the first lines listed in
>>> the debug output with -d 5? Or is there another utility I could use
>>> than ldapsearch?
>>
>> Try using strace and see what system calls get executed and where the
>> delay is. Alternatively you could try running ldapsearch under gdb and
>> interrupting it to get a stack trace from where the delay occurs.
>>
>
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc
OpenLDAP Core Team http://www.openldap.org/project/
16 years, 11 months
can't delete userPassword when ppolicy is used
by Andreas Hasenack
openldap-2.3.30
Not sure if this it intended or not, but it seems to be impossible to delete
the userPassword attribute from an entry if the ppolicy overlay is loaded.
I found this out when I accidentally added a userPassword attribute to a
posixGroup entry and discovered I could no longer remove it:
$ ldapmodify -x -D cn=manager,dc=example,dc=com -w secret
dn: cn=ldapusers,ou=group,dc=example,dc=com
changetype: modify
delete: userpassword
modifying entry "cn=ldapusers,ou=group,dc=example,dc=com"
ldap_modify: Internal (implementation specific) error (80)
additional info: Internal Error
If I unload the ppolicy overlay, the operation succeeds.
I have a default policy set which only specified the password attribute:
$ ldapsearch -x -LLL -b "ou=Password Policies,dc=example,dc=com"
dn: ou=Password Policies,dc=example,dc=com
ou: Password Policies
objectClass: organizationalUnit
description: Container for OpenLDAP password policies
dn: cn=default,ou=Password Policies,dc=example,dc=com
cn: default
objectClass: pwdPolicy
objectClass: namedObject
pwdAttribute: userPassword
16 years, 11 months
ldapsearch performance debugging
by Chris Hane
When I execute the following command:
ldapsearch -v -x -b "dc=abmas,dc=biz" -d 5 -h 127.0.0.1
there is a significant lag between hitting return and when I see the
debug output - 6-8 seconds.
I'm pretty sure this is a configuration problem or network problem on my
end as this same command in a different environment executes immediately.
To help me isolate where the problem is, is there another method to
debug what ldapsearch is doing before I see the first lines listed in
the debug output with -d 5? Or is there another utility I could use
than ldapsearch?
The debug out I see starts with and I want to try and figure out what it
happening before this:
[chane@samba ~]$ ldapsearch -v -x -b "dc=abmas,dc=biz" -d 5 -h 127.0.0.1
ldap_initialize( ldap://127.0.0.1 )
ldap_create
ldap_url_parse_ext(ldap://127.0.0.1)
ldap_bind
ldap_simple_bind
ldap_sasl_bind
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP 127.0.0.1:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 127.0.0.1:389
ldap_connect_timeout: fd: 3 tm: -1 async: 0
</snip rest of output>
Thanks,
Chris....
16 years, 11 months
Slapadd Problem
by Ted Johnson
<!-- DIV {margin:0px;}-->Hi;
I ran the following command:
# slapadd -b dc=example,dc=com -l urls.ldif
-f slapd.conf -d 1
Here is what I think is the relevant output:
>>> dnPrettyNormal: <cn=log>
<<< dnPrettyNormal: <cn=log>, <cn=log>
>>> dnPrettyNormal: <uid=root,cn=log>
<<< dnPrettyNormal: <uid=root,cn=log>, <uid=root,cn=log>
bdb_db_init: Initializing BDB database
>>> dnPrettyNormal: <dc=example,dc=com>
<<< dnPrettyNormal: <dc=example,dc=com>, <dc=example,dc=com>
>>> dnPrettyNormal: <cn=admin,dc=example,dc=com>
<<< dnPrettyNormal: <cn=admin,dc=example,dc=com>, <cn=admin,dc=example,dc=com>
>>> dnPrettyNormal: <cn=log>
<<< dnPrettyNormal: <cn=log>, <cn=log>
...and here is the complaint:
slapadd: slap_init no backend for "dc=example,dc=com"
Please advise.
TIA,
Ted
____________________________________________________________________________________
Cheap talk?
Check out Yahoo! Messenger's low PC-to-Phone call rates.
http://voice.yahoo.com
16 years, 11 months
