OpenLDAP version: 2.3.43-12 (CentOS 5.5), 64-bit.
In order to enable ppolicy overlay, I am trying to create the relevant
entries, as specified in
I import two LDIFs, first:
sn: dummy value
The first loads OK.
When I try to import the second, I receive this diagnostics:
Could not add object cn=default,ou=Policies,dc=itelsib,dc=com
Message: Invalid syntax
Error code: 0x15 (LDAP_INVALID_SYNTAX)
Error description: An invalid attribute value was specified.
Could someone suggest what's wrong with the attribute name?
the ppolicy.schema is specified in /etc/slapd.conf.
Could someone direct me to the source of wisdom to solve this: I have
set correctly the fields (attributes)
to make the account expired (OpenLDAP used to run NT domain), but when I
ssh to a server using pam_ldap authentication, it is still allowed to login.
How pam_ldap should be instructed to take the expiration attributes ito
i want to use unique overlay with the following config:
the attribute uniqueness for the people tree's uri works, but not the one for the group tree.
i found out the when i do an ldapsearch for a group and filter for gid=xy i get an empty result
ldapsearch -Y EXTERNAL -b 'ou=Groups,dc=abc,dc=net' 'gid=32011'
the log file says:
conn=18817 op=1 SRCH base="ou=Groups,dc=abc,dc=net" scope=2 deref=0 filter="(?gid=32011)"
why is the filter ?gid=32011
could this be the problem?
thanks for any hint.
> Run slapadd as the same user that slapd runs as. This is no different than
> running slapadd without shared memory segments, where you will have the same
> issue with the created BDB caching files (i.e., same results whether it is
> in memory or on disk).
Thanks, yes you are right. This issue I've never seen on my server,
because SuSE automatically makes
automaticly (via start script) a chown in the different backend
database directorys ...
I use shm_key in my database definition and its working fine.
But after using slappadd (stopped slapd), the process use the same
shm_key like the slapd (read from slapd.conf)
After the slapadd is finished, the shared memory remains reserved in
RAM with owner root. (ipcs -m)
So after slapadd, I cant start slapd, I have to delete these shared
memory with ipcrm.
Is there a possibility, that the slapadd deletes the shared memory
before ending or is there a reason that it remain?
I have two different LDAP servers containing different information
about my users. In one of them, I'm trying to configure dynlist overlay
to dinamically add attributes for users, so I have configured dynlist.
I'm using the labeledURI attribute with a value like this:
Whenever I look for a user I get the error:
Jan 10 13:07:07 canis12 slapd: dynlist_prepare_entry("<userDN>"):
If I remove the server part of the URI, like:
but, obviously, I'm not getting the additional attributes (because this
LDAP directory doesn't have them).
What am I doing wrong? Could I use a LDAP URI directed to another LDAP
Angel L. Mateo Martínez
Sección de Telemática
Área de Tecnologías de la Información _o)
y las Comunicaciones Aplicadas (ATICA) / \\
There is a discussion of solaris threads socket read/write locking issues and some workarounds at: http://omniorb.sourceforge.net/omni40/omnithread.html
See "6 Threaded I/O shutdown for Unix"
On 08/01/2011, at 9:55 AM, Howard Chu <hyc(a)symas.com> wrote:
> Doug Leavitt wrote:
>> On 01/ 7/11 08:01 AM, Rein Tollevik wrote:
>>> On 06.01.11 22.48, Quanah Gibson-Mount wrote:
>>>> --On Thursday, January 06, 2011 7:40 PM +0100 Rein Tollevik
>>>> <rein(a)OpenLDAP.org> wrote:
>>>>> On 04.01.11 23.34, Quanah Gibson-Mount wrote:
>>>>>> Please test RE24 heavily.
>>>>> test039 deadlocks for me on 64bit solaris10, both x86 and sparc :-( It
>>>>> hangs in the monitor, triggered by the new swamp -SS option added to
>>>>> slapd-tester. It works if run with -S or -SSS. It is the third server
>>>>> that hangs, and it does so quite consistently with the same stack trace
>>>>> every time. A gdb trace is at at:
>>>> Does this happen on both HEAD and RE24, or RE24 only?
>>> Both, as well as when running the head tests suite with the 2.4.23
>>> release. Looks as if the swamp additions have tripped into an
>>> existing problem, not anything new. Leave it out of RE24 until if
>>> have been resolved?
>>> Btw, any other Solaris test runs out there? I´t like to know if it is
>>> a real Solaris problem or just me..
> I'm seeing a similar failure on 32 bit Sparc Solaris 10. But it actually locks up in test036 for me, I never get as far as test039. The gdb trace looks much the same as what you posted.
> Looks like for some reason threads that are blocked waiting for their sockets to become writable are never getting waken up. A regular SIGINT shuts down slapd cleanly so it doesn't appear to be a problem with the condvars being used to manage the threads. That kinda points to select() simply not returning the writable status.
> I haven't used this Solaris machine much, but in fact (looking at the remnants of other files in my source tree on this box) this appears to have been a problem since at least last August. (I.e., it looks like I was investigating this same problem back then but dropped it and never got back to it.)
>> I'm currently testing Solaris11 (Nevada) and not seeing any issues in
>> either 32 or 64
>> bit builds using both RE24 and HEAD. I have not had any failures on
>> x86 yet.
>> Testing is still underway for sparc and other internal system testing on
>> both platforms.
> -- Howard Chu
> CTO, Symas Corp. http://www.symas.com
> Director, Highland Sun http://highlandsun.com/hyc/
> Chief Architect, OpenLDAP http://www.openldap.org/project/
With 2.4.23, i ran into the bug in IDS#6607 "Forwarded bind failure messages cause success", but was able to fix it by applying the minor diff of back-ldap/chain.c rev 1.77 (as was mentioned in the bug follow-up).
I've downloaded RE24 as of today & compiled it up. However, the bug is still there. Is this fix going to make it into 2.4.24 by any chance?
Maybe I¹m just being delusional in thinking that this should work... I¹m
running OpenLDAP 2.4.23 on IBM AIX for authentication on a variety of AIX,
Linux and web applications.
As we need to use both Posixgroup and groupOfNames objects with the same
membership, the dynamic list overlay seems like an ideal approach. This
configuration appeared to work fine for our linux hosts and web
applications, but not so well for our AIX hosts:
dynlist-attrset posixGroup labeledURI memberUid:uid
However, the AIX hosts do a search for (memberUid=jbagley)¹ to determine
group membership and the ldap server does not return the above object. I¹m
guessing that I was wrong in assuming the overlay would handle this type of
application and that I will have to find another way. Anyone have any
helpful tips? Advice? Condolences if I now have to manage twice as many
James Bagley Jr
State of Oregon Data Center
I am trying to install OpenLDAP in GNU/Linux:
Linux jupnms1 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux
I downloaded openldap version 2.4.23
I also installed BerkelyDB version 5.1.19 . Since the location of this db is not the default I set the proper environment variables for configure to find it:
Additionally, I have updated the link to db.h to propperly point to the new Berkely DB:
/usr/include/db.h -> /usr/local/BerkeleyDB.5.1/include/db.h because it was pointing to an old one.
However after all these changes I still get an error.
The command I ran is:
./configure --prefix /opt/COTS/ldap
The results is attached.
I really appretiate your help on this matter. I am currently evaluating different options for Authentication/Authorization data storage and have never worked with LDAP. LDAP is being proposed as the prefered way to store this data, however I need to prototype some solutions to present to management.