Re: (ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by quanah＠zimbra.com
--On Saturday, June 02, 2007 4:43 AM +0000 rra(a)stanford.edu wrote:
> Full_Name: Russ Allbery
> Version: 2.3.35
> OS: Debian
> URL:
> Submission from: (NULL) (171.66.157.14)
>
>
> While investigating another issue with back_perl, I tried to use the
> SampleLDAP.pm module that comes with the OpenLDAP source. I added the
> following to my slapd.conf:
>
> moduleload back_perl
>
># ...
>
> database perl
> suffix "o=AnyOrg,c=US"
> perlModulePath /home/eagle/SampleLDAP.pm
> perlModule SampleLDAP
>
> The result of slapd -d 1 is:
> ...
> WARNING: No dynamic config support for database perl.
> config_build_entry: "olcDatabase={2}perl"
> backend_startup_one: starting "dc=Stanford,dc=EDU"
> bdb_db_open: unclean shutdown detected; attempting recovery.
> bdb_db_open: dbenv_open(/var/lib/ldap)
> backend_startup_one: starting "o=AnyOrg,c=US"
> Can't call method "init" on an undefined value.
Using the SampleLDAP perl module supplied with the OpenLDAP source works
just fine for me on Stanford's LDAP servers.
ldap-uat00:/usr/local/etc/openldap# more slapd.conf
#
# See slapd.conf(5) for details on configuration options.
# This file should NOT be world readable.
#
include /usr/local/etc/openldap/schema/core.schema
include /usr/local/etc/openldap/schema/cosine.schema
include /usr/local/etc/openldap/schema/inetorgperson.schema
loglevel 0
threads 8
password-hash {CLEARTEXT}
# Define global ACLs to disable default read access.
pidfile /var/run/slapd.pid
argsfile /var/run/slapd.args
#
# Load dynamic backend modules:
# Note: back-null is statically-linked.
modulepath /usr/local/lib/openldap
moduleload back_perl.la
access to dn="" by * read
access to *
by anonymous read
by users read
by self write
# if no access controls are present, the default policy is:
# Allow read by all
#
# rootdn can always write!
tool-threads 2
#######################################################################
# perl database definitions
#######################################################################
database perl
suffix "o=AnyOrg,c=US"
perlModulePath /usr/local/etc/openldap
perlModule SampleLDAP
Output from slapd -d -1
slapd startup: initiated.
backend_startup_one: starting "cn=config"
config_back_db_open
config_build_entry: "cn=config"
config_build_entry: "cn=include{0}"
config_build_entry: "cn=include{1}"
config_build_entry: "cn=include{2}"
config_build_entry: "cn=module{0}"
config_build_entry: "cn=schema"
config_build_entry: "cn={0}core"
config_build_entry: "cn={1}cosine"
config_build_entry: "cn={2}inetorgperson"
config_build_entry: "olcDatabase={-1}frontend"
config_build_entry: "olcDatabase={0}config"
WARNING: No dynamic config support for database perl.
config_build_entry: "olcDatabase={1}perl"
backend_startup_one: starting "o=AnyOrg,c=US"
slapd starting
daemon: added 4r listener=(nil)
daemon: added 7r listener=0x6010e0
daemon: epoll: listen=7 active_threads=0 tvp=NULL
daemon: activity on 1 descriptor
daemon: activity on:
daemon: epoll: listen=7 active_threads=0 tvp=NULL
So I am unable to reproduce this issue.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 11 months
Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Howard Chu writes:
>> Hallvard B Furuseth wrote:
>>> hyc(a)symas.com writes:
>>>> h.b.furuseth(a)usit.uio.no wrote:
>>>>> * When a thread is finishing, make it go active for context_reset().
>>>>> Should make slapi module destructors safer, and I don't see that it
>>>>> can hurt.
>>>> I don't understand this.
>>> Let me dig a bit back in the ITS...
>>> "context_reset() can call connection_fake_destroy(), which via
>>> slapi_int_free_object_extensions() calls slapi module destructors,
>>> which can do who-knows-what."
>> context_reset() can only be called from the main thread. It can (must)
>> never be called by anything running from the pool.
>
> It's called from pool_wrapper(). pool_wrapper() could go active so
> there can be no pause while that context_reset() call is running.
Oh, ok. This is pretty much a non-issue because threads in the pool stay live
until slapd shuts down. The one exception is for a cn=config modify that
decreases the size of the pool to below the number of currently active threads,
in which case some number of threads will exit immediately. I don't see any
potential for conflict here.
>>>>> * Scheduling: If several threads call pool_pause(), (...)
>
> (need to check out how it should work...)
>
>>>>> - pool_context() breaks if several ldap_pvt_thread_t bit patterns can
>>>>> represent the same thread ID: TID_HASH() would give different hashes
>>>>> for the same thread, and pool_context() stops searching when it hits
>>>>> a slot with ctx == NULL. (My previous bug report was a bit wrong.)
>>>> How can a single thread ID be represented by multiple bit patterns?
>>> A struct/union with padding bytes seems the least unlikely possibility.
>
> Note that I did say "least unlikely" rather than "most likely":
> It's not that I expect to encounter it, more that I'd prefer not to be
> surprised in the form of a slapd malfuntion.
>
> So in that respect, my preference (not for RE23) is to cast to an
> integer for the hash, and also to add pthread_<set/get>specific() so
> thread_keys[] and its hash will only be a fallback solution.
Casting to an int only works with simple types, the point of using the hash was
to provide a solution that works for both simple and structured thread IDs. If
you want to #ifdef the code so the two cases are handled differently, then just
get rid of TID_HASH for the integral case.
I'm still leary of the pthread TLS support, and making that change will require
us to update all of the other thread package support, some of which I don't
have access to build/test any more (e.g. SunOS4 LWP).
>>>> The best fix may be to just use the address of the thread's stack as the
>>>> thread ID. That's actually perfect for our purpose.
>>> How does a function called from somewhere inside the thread know that
>>> address? That's almost what the user context is, and thus what
>>> thread_keys[] maps the thread ID to.
>> It requires some degree of machine-dependence, which is why I never
>> bothered to code it. The principle is simple though - all of our thread
>> stacks are some multiple of 1MB in size. Take the address of any local
>> variable, mask off the low 20 bits, and you have a unique thread ID (+/-
>> some additional masking/shifting based on the actual thread stack size).
>
> I'm not sure how to determine _which_ multiple of 1MB - start two
> threads and compare their stack addresses, maybe? In any case, I
> agree it sounds rather more machine-dependent than the current code.
That's what the LDAP_PVT_THREAD_STACK_SIZE macro tells you. It's really not
hard. If we were to disallow increasing the number of threads at runtime, we
could simply allocate a block of thread stacks all at once, which would then
allow our thread IDs to be simple integers from 0-N.
--
-- 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, 11 months
Re: (ITS#5019) slapd: ldbm/gdbm, cache.c core dump
by quanah＠zimbra.com
--On Thursday, June 14, 2007 8:59 PM +0000 asedlack(a)mailfoundry.com wrote:
> Full_Name: Aron Sedlack
> Version: 2.3.35
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (66.18.18.14)
>
LDBM is deprecated, and has been removed from the source tree. Bugs
against LDBM will not be fixed, because of its inherent flaws. Upgrade
your configuration to use one of the supported database mechanisms,
back-bdb or back-hdb. :)
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 11 months
Re: (ITS#5019) slapd: ldbm/gdbm, cache.c core dump
by hyc＠symas.com
asedlack(a)mailfoundry.com wrote:
> Full_Name: Aron Sedlack
> Version: 2.3.35
> OS: Linux
> URL: ftp://ftp.openldap.org/incoming/
> Submission from: (NULL) (66.18.18.14)
>
>
> Platform: Linux, OpenLDAP-2.3.35
> Compiled with: ./configure --enable-dynamic --enable-wrappers --enable-bdb=no
> --enable-hdb=no --enable-ldbm --enable-ldbm-api=gdbm --with-threads --with-tls
> --with-threads=no
> gcc version 3.3.4, gdbm 1.8.3, OpenSSL 0.9.8e
>
> slapd core dumps with a corrupted stack, SIGABRT.
> slapd: cache.c:111: cache_return_entry_rw: Assertion `e->e_private != (( void
> *)0)' failed..
>
> Happens every time ldif is loaded...
> $ ldapmodify -a -f ./mf.ldif -D "cn=Root,dc=mf" -w secret
> adding new entry "dc=mf"
>
> adding new entry "dc=iana,dc=mf"
> ldap_result: Can't contact LDAP server (-1)
1) ldbm is deprecated, don't use it.
2) if you insist on using it, get a debug stack trace for the abort
3) note that ldbm is still tested regularly in the 2.3 builds, and no one else
has reported this occurrence, so there's probably something odd in your
configuration. Providing your slapd.conf might help.
But the ldbm code has been removed for 2.4; support for it is disappearing fast.
--
-- 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, 11 months
Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by quanah＠zimbra.com
--On Thursday, June 14, 2007 10:02 PM +0000 h.b.furuseth(a)usit.uio.no wrote:
> Quanah Gibson-Mount writes:
>> It should be as simple as changing:
>> passwd.c:#define SALT_SIZE 4
>> to
>> passwd.c:#define SALT_SIZE 8
>
> I don't get this. I don't know ssha1, but...
Right, see my follow-up. I had the wrong string in my data when I did a
cut and paste. ;) It actually works as it should.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 11 months
Re: (ITS#4837) SunLDAP to OpenLDAP migration problem
by h.b.furuseth＠usit.uio.no
Quanah Gibson-Mount writes:
> It should be as simple as changing:
> passwd.c:#define SALT_SIZE 4
> to
> passwd.c:#define SALT_SIZE 8
I don't get this. I don't know ssha1, but...
That's for generating ssha1 hashes in hash_ssha1(), it is not used for
decoding them in chk_ssha1() - which I assume is what he needs when
moving _to_ OpenLDAP.
chk_ssha1() looks independent of salt size - it base64-decodes the
provided salt+hash and finds expects the salt to start at position
LUTIL_SHA1_BYTES (from include/lutil_sha1.h) in that string.
--
Regards,
Hallvard
15 years, 11 months
Re: (ITS#4837)
by quanah＠zimbra.com
--On Thursday, June 14, 2007 9:23 PM +0000 quanah(a)zimbra.com wrote:
> Kurt,
>
> Zimbra has run into this issue in helping a customer who was running
> SunDS migrate to OpenLDAP. It does not work at all, unfortunately.
> Changing code to use an 8-bit salt does work.
Never mind, the 8-bit salt works just fine. I had bad data in my cut &
paste buffer last night when I tried this. Trying with the correct data
works just fine. yeah! I'll mark this ITS as invalid, and note in the
comments that 8-bit salted SSHA passwords work just fine.
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 11 months
Re: (ITS#4936) default modulepath
by ando＠sys-net.it
ando(a)sys-net.it wrote:
> Yes, I figured that out. I'll fix this later.
Fixed; please test. 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, 11 months
Re: (ITS#4837)
by quanah＠zimbra.com
Kurt,
Zimbra has run into this issue in helping a customer who was running SunDS
migrate to OpenLDAP. It does not work at all, unfortunately. Changing
code to use an 8-bit salt does work.
So, I'd be happy to fix this, but a general design question --
(a) Should this be implemented as a "ssha-salt" option in slapd.conf
or
(b) Should OpenLDAP try decrypting the password first as a 4-bit salt, and
then try an 8-bit salt, then fail?
(a) would be fairly portable across many salt settings, but AFAIK we've
only hit 4 & 8
(b) would allow mixed salt values to be in userPassword, and I'd think that
over time as people changed their passwords, it would allow the 8-bit salts
to go away.
Thoughts welcome. :)
--Quanah
--
Quanah Gibson-Mount
Principal Software Engineer
Zimbra, Inc
--------------------
Zimbra :: the leader in open source messaging and collaboration
15 years, 11 months
Re: (ITS#5014) syncrepl failure syslog
by ando＠sys-net.it
donn(a)u.washington.edu wrote:
> Hard to tell why syncrepl isn't working, if it discards error messages.
This patch was not submitted according to the guidelines of usual
contributions, which makes it hard to apply. In any case, it appears to
be incorrect, since the response code should not be extracted that
early, namely before getting the message type. AFAIK, only an
LDAP_RES_SEARCH_RESULT could contain an error, and that value is already
parsed out and stored in "err". What's missing is a log in case "err"
indicates an error. So what's really relevant in your patch, and
missing from the code, is a test for "err" after the "done" label. I
have applied something along those lines to the code. Please test.
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, 11 months
