I am really struk with this issue. Could you help me?
In the makefile generated by the configure scipt, the TLS_LIBS value has
been assigned as -lssl.a -lcrypto.a. From which location, the system finds
the corresponding libssl.a and libcrypto.a?
Thanks in advance!!!
> Please keep replies on the list.
> Nikos Voutsinas wrote:
>> Indeed, a plain command line ldapseach with objectclass=*, works for me
>> Only with LDAP_Studio (an ldap browser written in java) I get this type
>> behavior, and I would normally ignore it, but it still troubles me
>> of the segfaults I am getting when ever I am trying to browse the real
>> naming context with this client. This makes me think that sth goes wrong
>> either with my config or slapd.
> If the problem only appears with a specific client, I suggest you try to
> single out what that client is doing differently from command-line
> tools, starting from the server logs at "stats" level to check the
> sequence of operations (if they're meaningless to you, you can post them
> to the list). Please restrict logs to what's strictly required. Only
> if nothing relevant appears, you might need to make the logs more
> verbose, e.g. by adding "args" and "trace".
Please note, that it is the slapd which segfaults and not the client. This
shouldn't have happened no matter what the client is doing.
With the relay,massage combination, slapd ends up looking for a non-existent
db key (only when searching is done through the real naming context) and
with the overlay,suffixmassage combination slapd seagfaults.
So, if the usage of "overlay,suffixmassage", instead of the "relay <>
massage", is "legal" and if there isnt anything obviously wrong in the rest
of the configuration, I might even start with debugging the segmentation
fault on slapd
Kindly look at the following snippet of the Makefile.
*TLS_LIBS = -lssl -lcrypto*
*SECURITY_LIBS = $(SASL_LIBS) $(KRB_LIBS) $(TLS_LIBS) $(AUTH_LIBS)*
After this, nowhere the SECURITY_LIBS or TLS_LIBS is used in the make file.
Then how the libraries -lssl and -lcrypto are linked with openLDAP build
Any kind of clarification is hugely appreciated.
Thanks and regards,
There is some diferences betwen the version 2.3 and 2.2, when we configured
the clients files, cause i have noticed that now when i do ldapsearch -x,
slapd dont showme information about users, machines...anything...and before
i could see all database, and now Im doing id user...and it give me backan
error saying that the user dont exists...and it's in teh database...
the conf is the same that i had when i had openldap 2.2.x installed
How did you upgrade to 2.3?
The backend databases are not compatible between minor versions (i.e. 2.2 -> 2.3) so if you did a 'slapcat' before the upgrade, deleted the DB and used 'slapadd' after the upgrade you should be OK; however if you just upgraded without exporting/importing the data you could be in trouble...
From: Chechu Ironman [mailto:firstname.lastname@example.org]
Sent: Monday, May 28, 2007 6:18 AM
Subject: diferences with openldap2.3
There is some diferences betwen the version 2.3 and 2.2, when we configured the clients files, cause i have noticed that now when i do ldapsearch -x, slapd dont showme information about users, machines...anything...and before i could see all database, and now Im doing id user...and it give me backan error saying that the user dont exists...and it's in teh database...
the conf is the same that i had when i had openldap 2.2.x installed
I continue to have trouble with getting a freshly started server to be
responsive. One problem in particular is one that I thought had been
resolved some time ago but is apparently biting me right now...
With the hdb backend (at least in OL 2.3.34 and OL 2.3.35) if you perform
a search with a search base deeper than the root suffix, the search takes
a very long time to complete if the cache hasn't been established. In my
case the difference is less than a second versus several hours. I'm not
sure yet which bit of cache needs to be primed. I can switch back and
forth searching with the same filter in the root and then a child search
base with the same results.
Is this a bug recursion or something that I just hadn't been noticing?
What would be the best search to perform to prepare whatever cache is
getting hit to make searches outside of the root DN faster?
Eric Irrgang - UT Austin ITS Unix Systems - (512)475-9342
On 5/25/07, Quanah Gibson-Mount <quanah(a)zimbra.com> wrote:
> --On Friday, May 25, 2007 2:31 AM -0700 Howard Chu <hyc(a)symas.com> wrote:
> > Quanah Gibson-Mount wrote:
> >> --On Thursday, May 24, 2007 8:03 PM -0400 Pedro Espinoza
> >> <raindoctor(a)gmail.com> wrote:
> >>> Gurus:
> >>> I am newbie to this ldap thing. I followed garytt's installation
> >>> When I tried to start "slapd", I got the following error. I searched
> >>> net, but in vain. Can you shed some light on it, and how to rectify
> >>> /usr/local/etc/openldap/schema/core.schema: line 77: Duplicate
> >>> attributeType: "184.108.40.206"
> >> Ignore this warning, it is harmless.
> > Actually it most likely indicates that you're using an older core.schema
> > file with a newer slapd, and it's not just a warning, it's a fatal
> Oh, I was thinking of those annoying schema warning messages that have
> going on in 2.3 for a while.
I have figured out: my slapd.conf contains two entries for core.schema. I
removed the other one, it is working,
I am newbie to this ldap thing. I followed garytt's installation guide. When
I tried to start "slapd", I got the following error. I searched on net, but
in vain. Can you shed some light on it, and how to rectify it.
/usr/local/etc/openldap/schema/core.schema: line 77: Duplicate
My Provider settings are
#updateref the ldap server to which clients submit update requests
#Provider (master) must be implemeneted as an overlay
#syncprov-checkpoint <ops> <minutes>
syncprov-checkpoint 100 10
On May 24, 2007, at 7:23 PM, Gavin Henry wrote:
> What are your provider settings?
> On 24/05/07, Steven Bambling <steven.bambling(a)sunrocket.com> wrote:
>> I am in the process of setting up replication between 2 ldap
>> servers...I am moving from the older slupd to syncrepl. Wh I try to
>> start the ldap server after adding in the necessary config into
>> slapd.conf file I get this error.
>> syncrepl: database already shadowed
>> Below is the parameters that I am using for syncrepl any help or a
>> point in the correct direction would be much appreciated.
>> #Replication Stuff#
>> #updated=the DN allowed to make changes to the replica (masteer)
>> updatedn "cn=copycat,dc=srtest,dc=com
>> #updateref the ldap server to which clients submit update requests
>> updateref ldap://pi.sunrocket.com
>> #syncrepl rid=replica ID
>> syncrepl rid=420
>> #Address of the provider (master) ldap server
>> #retry=<retry interval> <# of retries>
>> retry=60 10 300 3
>> #searchbase=<base DN>
>> #filter=<filter string
>> #attrs=<attr list>