Re: ldap_int_global_options not initialized (ITS#5109)
by ando＠sys-net.it
damien.doiselet(a)neolane.com wrote:
> My application is multithread.
:)
> I've had a call to ldap_get_option(NULL, LDAP_OPT_API_INFO, &ldapi)
> before spawning threads, but here the crash occurred also in
> ldap_initailize but in ldap_ld_free().
The above sentence is not clear to me; what does the trace below refer
to? Your original application, or the one that calls ldap_get_option
before spawning threads? What does ldap_ld_free() have to do with this?
It never occurs in the trace below.
> I addition, I won't call ldap outside my thread.
Doesn't matter. Global options are global, so multiple threads may find
it uninit'ed, and try to concurrently initialize it.
> The full stack trace is :
> #0 0xb7e93473 in strlen () from /lib/tls/i686/cmov/libc.so.6
> #1 0xb3a191f9 in ber_strdup_x (s=0x6a626f28 <Address 0x6a626f28 out of
> bounds>, ctx=0x0) at memory.c:640
> #2 0xadd2fd66 in ldap_charray_dup (a=0xb313a324) at charray.c:164
> #3 0xadd26883 in ldap_url_dup (ludp=0x8b83798) at url.c:1191
> #4 0xadd26912 in ldap_url_duplist (ludlist=0x8b83798) at url.c:1217
> #5 0xadd11b34 in ldap_create (ldp=0xb32e0dc8) at open.c:149
> #6 0xadd11de1 in ldap_initialize (ldp=0xb32e0ec0, url=0x8946d20
> "ldap://ldap:389") at open.c:225
Please make sure you're calling the desired library objects (libldap &
liblber). Can you post the result of ldd for your application?
> I have same thing with the 2.3.38
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 9 months
Re: ldap_int_global_options not initialized (ITS#5109)
by quanah＠zimbra.com
--On Tuesday, August 28, 2007 3:58 PM +0000 damien.doiselet(a)neolane.com
wrote:
> Thanks
>
> My application is multithread.
> I've had a call to ldap_get_option(NULL, LDAP_OPT_API_INFO, &ldapi)
> before spawning threads, but here the crash occurred also in
> ldap_initailize but in ldap_ld_free().
> I addition, I won't call ldap outside my thread.
Be careful of the LDAP libraries on debian. If they get loaded, you are in
trouble, since they are hacked to touch Gnu TLS, and you'll get all sorts
of fun. This all gets resolved once OpenLDAP 2.4 is released.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 9 months
(ITS#5110) back-ldap, proxy authentication fails when chasing referrals
by f.huiskens＠science-computing.de
Full_Name: Florian Huiskens
Version: 2.3.30
OS: Ubuntu 7.04
URL:
Submission from: (NULL) (85.216.39.101)
I try to set up an environment, where a client communicates with an LDAP-Proxy.
The Proxy forwards the client's query (using the ldap-backend) to an
LDAP-Slave.
The authentication mechanism I use (proxy - slave) is SASL (GSSAPI).
The proxy has a kerberos ticket available.
Proxy Authentication works in general (using PROXAUTHZ), but fails on referrals
(though rebind-as-user is set).
This means that if information is written and the proxy receives a referral to
the master, the bind-informations gets lost.
Thanks for any help, regards
Florian
Config-files:
Master:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel 0
# Where the dynamically loaded modules are stored
modulepath /usr/lib/ldap
moduleload back_bdb
moduleload syncprov
# The maximum number of entries that is returned for a search operation
sizelimit 500
# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 1
backend bdb
checkpoint 512 30
#######################################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database bdb
suffix "dc=idm,dc=local"
# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn "dc=idm,dc=local"
directory "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index objectClass eq
# Save the time that the entry gets modified, for database #1
lastmod on
access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=idm,dc=local" write
by dn="uid=ldap/extubuntu.idm.local,ou=slaves,dc=idm,dc=local" read
by anonymous auth
by * none
access to dn.base="" by * read
access to *
by dn="cn=admin,dc=idm,dc=local" write
by * read
# syncrepl config
overlay syncprov
syncprov-checkpoint 100 1
syncprov-sessionlog 100
# SASL setup
#sasl-host ubuntu-desktop
sasl-authz-policy To
sasl-secprops minssf=56
sasl-realm idm.local
sasl-regexp uid=(.*),cn=idm.local,cn=gssapi,cn=auth
ldap:///dc=idm,dc=local??sub?(|(uid=$1)(cn=$1))
Slave:
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel 0
modulepath /usr/lib/ldap
moduleload back_bdb
sizelimit 500
tool-threads 1
backend bdb
checkpoint 512 30
database bdb
suffix "dc=idm,dc=local"
#rootdn "dc=idm,dc=local"
rootdn "dc=nowhere,dc=nouniverse"
directory "/var/lib/ldap"
dbconfig set_cachesize 0 2097152 0
dbconfig set_lk_max_objects 1500
dbconfig set_lk_max_locks 1500
dbconfig set_lk_max_lockers 1500
index objectClass eq
lastmod on
access to attrs=userPassword,shadowLastChange
by dn="cn=admin,dc=idm,dc=local" write
by anonymous auth
by self write
by * none
# by dn="cn=repl-admin,dc=idm,dc=local" write
access to dn.base="" by * read
access to *
by dn="cn=admin,dc=idm,dc=local" write
by self write
by * read
# by dn="cn=repl-admin,dc=idm,dc=local" write
# by * read
syncrepl rid=1
provider=ldap://ubuntu-desktop:389
searchbase="dc=idm,dc=local"
type=refreshAndPersist
retry="60 10 300 +"
bindmethod=sasl
saslmethod=GSSAPI
updateref ldap://ubuntu-desktop:389
# SASL setup
sasl-authz-policy To
sasl-secprops minssf=56
sasl-realm idm.local
sasl-regexp uid=(.*),cn=idm.local,cn=gssapi,cn=auth
ldap:///dc=idm,dc=local??sub?(|(uid=$1)(cn=$1))
Proxy (running on the same host as the Slave):
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/nis.schema
include /etc/ldap/schema/inetorgperson.schema
pidfile /var/run/slapd/slapd.pid
argsfile /var/run/slapd/slapd.args
loglevel 1
modulepath /usr/lib/ldap
moduleload back_ldap
database ldap
uri ldap://extubuntu.idm.local:390/
suffix "dc=idm,dc=local"
chase-referrals yes
rebind-as-user yes
# SASL setup
sasl-secprops minssf=56
sasl-realm idm.local
sasl-regexp uid=(.*),cn=idm.local,cn=gssapi,cn=auth
ldap:///dc=idm,dc=local??sub?(|(uid=$1)(cn=$1))
idassert-bind bindmethod=sasl
mode=self
authcid=ldap/extubuntu.idm.local # should come from ticket but
does not.
Snippets of an ldapsearch:
debugging information from the proxy
conn=10 fd=9 ACCEPT from IP=127.0.0.1:3380 (IP=0.0.0.0:389)
conn=10 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
conn=10 op=0 SRCH attr=supportedSASLMechanisms
conn=10 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=10 op=1 BIND dn="" method=163
conn=10 op=2 BIND dn="" method=163
conn=10 op=2 RESULT tag=97 err=14 text=
conn=10 op=3 BIND dn="" method=163
conn=10 op=1 RESULT tag=97 err=14 text=
request done: ld 0x81dd960 msgid 3
SASL [conn=10] Error: unable to open Berkeley db /etc/sasldb2: No such file or
directory
conn=10 op=3 BIND authcid="admin(a)idm.local" authzid="admin(a)idm.local"
conn=10 op=3 BIND dn="cn=admin,dc=idm,dc=local" mech=GSSAPI ssf=56
conn=10 op=3 RESULT tag=97 err=0 text=
conn=10 op=4 SRCH base="dc=idm,dc=local" scope=2 deref=0 filter="(cn=fhuisk)"
request done: ld 0x8197038 msgid 1
request done: ld 0x8197038 msgid 2
request done: ld 0x8197038 msgid 3
request done: ld 0x8197038 msgid 4
request done: ld 0x8197038 msgid 5
conn=10 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=10 op=5 UNBIND
conn=10 fd=9 closed
debugging information from the slave
conn=0 op=2 SRCH base="dc=idm,dc=local" scope=2 deref=0
filter="(|(uid=admin)(cn=admin))"
conn=0 op=2 SRCH attr=1.1
<= bdb_equality_candidates: (uid) index_param failed (18)
<= bdb_equality_candidates: (cn) index_param failed (18)
conn=0 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=2 fd=16 ACCEPT from IP=127.0.1.1:2814 (IP=0.0.0.0:390)
conn=2 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
conn=2 op=0 SRCH attr=supportedSASLMechanisms
conn=2 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=2 op=1 BIND dn="" method=163
conn=2 op=2 BIND dn="" method=163
conn=2 op=2 RESULT tag=97 err=14 text=
conn=2 op=3 BIND dn="" method=163
<= bdb_equality_candidates: (uid) index_param failed (18)
<= bdb_equality_candidates: (cn) index_param failed (18)
SASL [conn=2] Error: unable to open Berkeley db /etc/sasldb2: No such file or
directory
conn=2 op=3 BIND authcid="ldap/extubuntu.idm.local(a)idm.local"
authzid="ldap/extubuntu.idm.local(a)idm.local"
conn=2 op=3 BIND dn="uid=ldap/extubuntu.idm.local,ou=slaves,dc=idm,dc=local"
mech=GSSAPI ssf=56
conn=2 op=3 RESULT tag=97 err=0 text=
conn=2 op=4 PROXYAUTHZ dn="cn=admin,dc=idm,dc=local"
conn=2 op=4 SRCH base="dc=idm,dc=local" scope=2 deref=0 filter="(cn=fhuisk)"
<= bdb_equality_candidates: (cn) index_param failed (18)
conn=2 op=4 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=2 op=1 RESULT tag=97 err=14 text=
conn=2 op=5 UNBIND
conn=2 fd=16 closed
ldapsearch call and result
root@extUbuntu:/etc/ldap# ldapsearch cn=fhuisk
SASL/GSSAPI authentication started
SASL username: admin(a)IDM.LOCAL
SASL SSF: 56
SASL installing layers
# extended LDIF
#
# LDAPv3
# base <> with scope subtree
# filter: cn=fhuisk
# requesting: ALL
#
# fhuisk, users, idm.local
dn: cn=fhuisk,ou=users,dc=idm,dc=local
uid: fhuisk
givenName:: RmxvcmlhbiA=
objectClass: top
objectClass: person
objectClass: organizationalPerson
objectClass: inetOrgPerson
sn: Huiskens
cn: fhuisk
userPassword:: dGVzdA==
# search result
search: 5
result: 0 Success
# numResponses: 2
# numEntries: 1
root@extUbuntu:/etc/ldap#
fyi: ldapwhoami
root@extUbuntu:/etc/ldap# ldapwhoami
SASL/GSSAPI authentication started
SASL username: admin(a)IDM.LOCAL
SASL SSF: 56
SASL installing layers
dn:cn=admin,dc=idm,dc=local
Result: Success (0)
root@extUbuntu:/etc/ldap#
Snippets of an ldapmodify
debugging information from the proxy
conn=0 fd=9 ACCEPT from IP=127.0.0.1:3145 (IP=0.0.0.0:389)
conn=0 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
conn=0 op=0 SRCH attr=supportedSASLMechanisms
conn=0 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=0 op=1 BIND dn="" method=163
conn=0 op=2 BIND dn="" method=163
conn=0 op=2 RESULT tag=97 err=14 text=
conn=0 op=3 BIND dn="" method=163
request done: ld 0x81a39f8 msgid 1
conn=0 op=1 RESULT tag=97 err=14 text=
request done: ld 0x81a39f8 msgid 2
SASL [conn=0] Error: unable to open Berkeley db /etc/sasldb2: No such file or
directory
conn=0 op=3 BIND authcid="admin(a)idm.local" authzid="admin(a)idm.local"
conn=0 op=3 BIND dn="cn=admin,dc=idm,dc=local" mech=GSSAPI ssf=56
conn=0 op=3 RESULT tag=97 err=0 text=
conn=0 op=4 MOD dn="cn=fhuisk,ou=users,dc=idm,dc=local"
conn=0 op=4 MOD attr=cn
request done: ld 0x8192200 msgid 1
request done: ld 0x8192200 msgid 2
request done: ld 0x8192200 msgid 3
request done: ld 0x8192200 msgid 4
request done: ld 0x8192200 msgid 7
request done: ld 0x8192200 msgid 5
conn=0 op=4 RESULT tag=103 err=47 text=anonymous proxyAuthz not allowed
conn=0 op=5 UNBIND
conn=0 fd=9 closed
debugging information from the slave
conn=0 fd=13 ACCEPT from IP=127.0.1.1:2862 (IP=0.0.0.0:390)
conn=0 op=0 BIND dn="" method=128
conn=0 op=0 RESULT tag=97 err=0 text=
conn=0 op=1 SRCH base="dc=idm,dc=local" scope=2 deref=0
filter="(|(uid=admin)(cn=admin))"
conn=0 op=1 SRCH attr=1.1
<= bdb_equality_candidates: (uid) index_param failed (18)
<= bdb_equality_candidates: (cn) index_param failed (18)
conn=0 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=1 fd=15 ACCEPT from IP=127.0.1.1:2863 (IP=0.0.0.0:390)
conn=1 op=0 SRCH base="" scope=0 deref=0 filter="(objectClass=*)"
conn=1 op=0 SRCH attr=supportedSASLMechanisms
conn=1 op=0 SEARCH RESULT tag=101 err=0 nentries=1 text=
conn=1 op=1 BIND dn="" method=163
conn=1 op=2 BIND dn="" method=163
conn=1 op=3 BIND dn="" method=163
<= bdb_equality_candidates: (uid) index_param failed (18)
<= bdb_equality_candidates: (cn) index_param failed (18)
SASL [conn=1] Error: unable to open Berkeley db /etc/sasldb2: No such file or
directory
conn=1 op=3 BIND authcid="ldap/extubuntu.idm.local(a)idm.local"
authzid="ldap/extubuntu.idm.local(a)idm.local"
conn=1 op=3 BIND dn="uid=ldap/extubuntu.idm.local,ou=slaves,dc=idm,dc=local"
mech=GSSAPI ssf=56
conn=1 op=2 RESULT tag=97 err=14 text=
conn=1 op=4 PROXYAUTHZ dn="cn=admin,dc=idm,dc=local"
conn=1 op=4 MOD dn="cn=fhuisk,ou=users,dc=idm,dc=local"
conn=1 op=4 MOD attr=cn
conn=1 op=4 RESULT tag=103 err=10 text=
conn=1 op=3 RESULT tag=97 err=0 text=
conn=1 op=1 RESULT tag=97 err=14 text=
conn=1 op=5 UNBIND
conn=1 fd=15 closed
debugging information from the master
conn=1 fd=14 ACCEPT from IP=172.16.82.240:1290 (IP=0.0.0.0:389)
conn=1 op=0 BIND dn="" method=128
conn=1 op=0 RESULT tag=97 err=0 text=
conn=1 op=1 RESULT tag=103 err=47 text=anonymous proxyAuthz not allowed
do_modify: get_ctrls failed
conn=1 op=2 UNBIND
conn=1 fd=14 closed
ldapmodify call and result
root@extUbuntu:/etc/ldap# ldapmodify
SASL/GSSAPI authentication started
SASL username: admin(a)IDM.LOCAL
SASL SSF: 56
SASL installing layers
dn: cn=fhuisk,ou=users,dc=idm,dc=local
changetype: modify
add: cn
cn: newCN
-
modifying entry "cn=fhuisk,ou=users,dc=idm,dc=local"
ldapmodify: Proxy Authorization Failure (47)
additional info: anonymous proxyAuthz not allowed
root@extUbuntu:/etc/ldap#
15 years, 9 months
Re: ldap_int_global_options not initialized (ITS#5109)
by damien.doiselet＠neolane.com
Thanks
My application is multithread.
I've had a call to ldap_get_option(NULL, LDAP_OPT_API_INFO, &ldapi)
before spawning threads, but here the crash occurred also in
ldap_initailize but in ldap_ld_free().
I addition, I won't call ldap outside my thread.
The full stack trace is :
#0 0xb7e93473 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1 0xb3a191f9 in ber_strdup_x (s=0x6a626f28 <Address 0x6a626f28 out of
bounds>, ctx=0x0) at memory.c:640
#2 0xadd2fd66 in ldap_charray_dup (a=0xb313a324) at charray.c:164
#3 0xadd26883 in ldap_url_dup (ludp=0x8b83798) at url.c:1191
#4 0xadd26912 in ldap_url_duplist (ludlist=0x8b83798) at url.c:1217
#5 0xadd11b34 in ldap_create (ldp=0xb32e0dc8) at open.c:149
#6 0xadd11de1 in ldap_initialize (ldp=0xb32e0ec0, url=0x8946d20
"ldap://ldap:389") at open.c:225
I have same thing with the 2.3.38
Damien Doiselet
Pierangelo Masarati a écrit :
> Only issues occurring with either the latest release (now 2.3.28) or HEAD code
> ought to be considered, as they might be related to already known and perhaps
> solved problems. Please check with a fresh build from 2.3.28.
>
> In the meanwhile, it might be worth checking:
>
> - is your application multithread?
>
> - in case it is, is the first call to a libldap routine occurring __before__
> starting multiple threads, or after? If after, then fix your project by adding
> a call to an LDAP routine (e.g. ldap_set_option() with an option that does not
> require a LDAP* handle) __before__ spawning threads.
>
> - can you test your development using a libldap library containing debug
> symbols, in order to provide helpful information?
>
> p.
>
15 years, 9 months
Re: Does libldap.so.2 still exist in the latest version of open-ldap,and if not, what could other applications link to instead?
by Gavin Henry
<quote who="Oliver de Peyer">
> Well, put it this way, it's not a bug with OpenLDAP but it
> is a bug with PINE. This seemed like the most appropriate
> list to post to though since maybe an OpenLDAP user could
> suggest a workaround.
Ok, but we don't provide support for 3rd Party software integration with
OpenLDAP and refer users to the appropriate mailing lists.
> Most people would be used to installing Linux applications
> just using .rpms and will be flummoxed by dependency
> problems, especially if they are home users. The problem is
> that PINE needs a library, libldap.so.2, that the more
> recent versions of OpenLDAP no longer supplies. If there is
> any easy workaround that the OpenLDAP community can suggest
> as a workaround, then PINE users would be very grateful.
The work around would be to get upstream to update there lib dependancies.
> But to be absolutely clear, yes, it's definitely PINE's bug
> not OpenLDAP's!
Of course! ;-) But please, seek help on their lists, there's nothing more
we can do to help, as it's not a bug with our software.
>
> In answer to your second suggestion, yes, if you know what
> you're doing it is quite easily to compile from the PINE
> source and omit OpenLDAP - you can put NOLDAP as a suffix
> on the relevant build command. That's what I did in the
> end.
Understood.
> This doesn't help people who are used to just using .rpms
> though and it doesn't help people who actually want to use
> OpenLDAP with PINE.
Well, we distribute in source, so we don't provide RPMs. RPMs are supplied
for convience by distros, as you know.
>
> I would have posted this to PINE lists as you suggest, but
> as far as I could make out they don't have email lists per
> se but only newsgroups. And one of the things I wanted to
> use PINE was to post to newsgroups... but I couldn't get
> PINE to work...
All things are pointing towards not using PINE then ;-)
> I'll post to their newsgroup from my PC at work, but in the
> meantime, if anybody on this list has any ideas about
> solving this problem from and OpenLDAP perspective, then
> I'd be very grateful.
They look pretty active to me:
http://www.washington.edu/pine/pine-info/
http://mailman1.u.washington.edu/pipermail/pine-info/
http://marc.info/?l=pine-info&w=2&r=1&s=libldap&q=b
Gavin.
15 years, 9 months
(ITS#5109) ldap_int_global_options not initialized
by damien.doiselet＠neolane.com
Full_Name: Damien Doiselet
Version: 2.3.30
OS: Debian 4 (kernel 2.6.20.7)
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (82.243.24.157)
I'm developing an application which use openldap.
I load the library at the runtime with function GetProcAddress
My application work correctly except on one PC. This PC is a Debian 4.0 with a
kernel 2.6.20.7. Ldap library is a 2.3.30.
The library crash, and so my code too in ldap_initialize() (first call of a ldap
function):
#0 0xb7eab3a3 in strlen () from /lib/tls/i686/cmov/libc.so.6
#1 0xb3a2d1f9 in ber_strdup_x (s=0x6a626f28 <Address 0x6a626f28 out of bounds>,
ctx=0x0) at memory.c:640
#2 0xaddcbdf6 in ldap_charray_dup () from /usr/lib/libldap-2.3.so.0
#3 0xaddc2773 in ldap_url_dup () from /usr/lib/libldap-2.3.so.0
#4 0xaddc2802 in ldap_url_duplist () from /usr/lib/libldap-2.3.so.0
#5 0xaddab4dc in ldap_create () from /usr/lib/libldap-2.3.so.0
#6 0xaddab7d1 in ldap_initialize () from /usr/lib/libldap-2.3.so.0
While I was debugging, ldap_int_global_options was not initialized.
Nevertheless, with -lldap compilation with gcc, there is no problem.
15 years, 9 months
Does libldap.so.2 still exist in the latest version of open-ldap, and if not, what could other applications link to instead?
by Oliver de Peyer
I am trying to install PINE on Fedora 7 (and hey, why not? It's good
enough as a command line email program)
So, I get hold of Pine-4.64-1-i386.rpm from the UW website. But when
I try to install this with rpm, it told me I was missing various
dependencies. I managed to download these one by one until I got to
one called libldap.so.2.
I got as far as working out that this is part of open-ldap.
open-ldap.2.3.38 was the latest version I could find and it installed
fine - I know it installed OK because the test scripts etc. run OK.
But, libldap.so.2 is NOT THERE!!
For instance, from the /../ directory,
find -name libldap.so.2 -print
doesn't find anything (but
find -name *so.2 -print
does, so there definitely are similarly named files around)
I searched for libldap.so.2 in the open-ldap archives and all
references to it were a few years ago. It seemed quite possible to me
that libldap.so.2 has perhaps been renamed as something else in
recent versions of open-ldap. Plenty of other libraries were created
when I installed open-ldap.2.3.38, just not one with the exact name
libldap.so.2. Is this some finickity requirement of PINE?
I have got Apt installed but I don't really know how to use it - can
I go look for something as specific as a .so.2 library file?
So, what would people suggest? Can I get hold of this file for PINE
or persuade it to use something else? (and if so, what and how?)
Out of interest, why is PINE interested in libldap.so.2 in the first
place and what does it do?
Thanks in advance,
Sarpeyer
15 years, 9 months
Re: (ITS#5108) SID/RID: decimal or hex?
by hyc＠symas.com
ando(a)sys-net.it wrote:
> Well, in slapd.conf(5) I already put 0-4095, but be can back it out. I
> don't have any preference. Since the max will just slightly increase, I
> don't see a big deal in terms of backwards compatibility. In any case
> 4096 or 1000 is big for a RID, so no-one will be hurt. I was more
> concerned about the 10 limit...
OK. I kind of think they ought to be documented differently, so that people
don't confuse SIDs with RIDs (as often happened in OpenLDAP 2.2) but it's
probably fine the way it is.
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 9 months
Re: (ITS#5108) SID/RID: decimal or hex?
by ando＠sys-net.it
Howard Chu wrote:
> ando(a)sys-net.it wrote:
>> Howard Chu wrote:
>
>>> The SID in the CSN has always been hex (but usually zero). The RID is
>>> not part of the CSN and has always been decimal. Since the RID only
>>> needs to be unique within a particular slapd instance, there's no real
>>> problem there.
>>>
>>
>> Right. but, well, slap_parse_csn_sid() was using strtoul(..., 10). Now
>> fixed.
>
> Yeah, oops. That's good.
>
>> For consistency I've made both behave the same. The user won't
>> basically notice it, so I don't see backward compatibility issues.
>
> So we leave the docs saying RID is 0-999?
Well, in slapd.conf(5) I already put 0-4095, but be can back it out. I
don't have any preference. Since the max will just slightly increase, I
don't see a big deal in terms of backwards compatibility. In any case
4096 or 1000 is big for a RID, so no-one will be hurt. I was more
concerned about the 10 limit...
p.
Ing. Pierangelo Masarati
OpenLDAP Core Team
SysNet s.r.l.
via Dossi, 8 - 27100 Pavia - ITALIA
http://www.sys-net.it
---------------------------------------
Office: +39 02 23998309
Mobile: +39 333 4963172
Email: pierangelo.masarati(a)sys-net.it
---------------------------------------
15 years, 9 months
Re: (ITS#5108) SID/RID: decimal or hex?
by hyc＠symas.com
ando(a)sys-net.it wrote:
> Howard Chu wrote:
>> The SID in the CSN has always been hex (but usually zero). The RID is
>> not part of the CSN and has always been decimal. Since the RID only
>> needs to be unique within a particular slapd instance, there's no real
>> problem there.
>>
>
> Right. but, well, slap_parse_csn_sid() was using strtoul(..., 10). Now
> fixed.
Yeah, oops. That's good.
> For consistency I've made both behave the same. The user won't
> basically notice it, so I don't see backward compatibility issues.
So we leave the docs saying RID is 0-999?
--
-- Howard Chu
Chief Architect, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/
15 years, 9 months
