Re: (ITS#4994) Clarify -y option in man pages
by ando＠sys-net.it
rra(a)stanford.edu wrote:
> A Debian user was confused by the -y option and its inclusion of whitespace in
> the password. The current man page text does explain this, but it doesn't make
> a point of it, and I think a bit more explanation would be useful. Here's a
> patch for the ldapcompare.1 man page; if you think this is a good idea, similar
> changes could be made to all the other command-line utilities that take the -y
> option.
I have committed a different clarification that provides a hint to a
portable manner to generate appropriate password files. Please check
and improve; afterwards I'll apply it to other command line tools man pages.
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
---------------------------------------
16 years, 6 months
(ITS#4997) lmpasswd support using gcrypt
by rra＠stanford.edu
Full_Name: Russ Allbery
Version: 2.4 (HEAD)
OS: Debian
URL: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=245341
Submission from: (NULL) (171.66.157.14)
Now that 2.4 has native GnuTLS support, the patch that's been sitting around in
Debian bug #245341 becomes potentially interesting (see the associated URL).
This is a request to support LAN Manager password hashes when OpenLDAP is built
with GnuTLS instead of OpenSSL, thus requiring using libgcrypt to do the DES
work instead of OpenSSL's DES library.
The patch in that bug almost certainly isn't okay in its current form, but I
wanted to get the ITS filed for this feature request so that there's a record in
the database and just in case someone else feels inspired to bring the patch up
to date and clean it up. (Unlikely, I know.) Otherwise, I will probably clean
this patch up for further submission at some point near the 2.4 release (on
which side of it, I'm not sure).
16 years, 6 months
Re: (ITS#4996) Use SRV records to locate local server for command-line clients
by kurt＠OpenLDAP.org
On Jun 2, 2007, at 5:31 AM, rra(a)stanford.edu wrote:
> Full_Name: Russ Allbery
> Version: 2.3.35
> OS: Debian
> URL:
> Submission from: (NULL) (171.66.157.14)
>
>
> A user of the Debian OpenLDAP package requested support in the
> command-line
> utilities for using SRV entries to locate the local LDAP server. My
> understanding of the suggestion is that if one didn't specify -h or
> -H, a SRV
> record lookup would be tried before falling back to localhost.
> (You may not
> want to change the default behavior, though, and add another switch.)
One could use DNS SRV on the domain provided by -H, or by ldap.conf
(5), and
use it present, with (likely best) or without an option to enable the
behavior.
One could also use DNS SRV on the domain associated with the
baseObject/target
DN with an option to enable this behavior. That is, ldapsearch -b
"dc=example,dc=org"
would cause a DNS SRV lookup on example.org. This is what the DNSSRV
backend
does.
Not sure adding to the command line tools would be especially
useful. That is,
I don't think DNS SRV fits well in the common use pattern of command
line tools.
But someone implements this behind an option, it shouldn't do any harm.
Lastly I note that the domain to use DNS SRV should come from the
user (or application
entity), not the local host. Using the local resolver configuration
is a really
bad idea.
-- Kurt
>
> For the full suggestion, see:
>
> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221173
>
> It looks like much of the necessary code is already there in
> libldap, and
> looking at the libldap code, you could also intuit the correct
> server based on
> any search base provided.
>
>
16 years, 6 months
(ITS#4996) Use SRV records to locate local server for command-line clients
by rra＠stanford.edu
Full_Name: Russ Allbery
Version: 2.3.35
OS: Debian
URL:
Submission from: (NULL) (171.66.157.14)
A user of the Debian OpenLDAP package requested support in the command-line
utilities for using SRV entries to locate the local LDAP server. My
understanding of the suggestion is that if one didn't specify -h or -H, a SRV
record lookup would be tried before falling back to localhost. (You may not
want to change the default behavior, though, and add another switch.)
For the full suggestion, see:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=221173
It looks like much of the necessary code is already there in libldap, and
looking at the libldap code, you could also intuit the correct server based on
any search base provided.
16 years, 6 months
slapd with wrong url causes "Error detected by libpthread: Invalid mutex"
by Jean-Luc Wasmer
Hi,
When slapd is started with an invalid url, it looks like it's trying to
destroy an uninitialized mutex:
Program received signal SIGABRT, Aborted.
0xbb87dfff in kill () from /usr/lib/libc.so.12
(gdb) backtrace
#0 0xbb87dfff in kill () from /usr/lib/libc.so.12
#1 0xbb94adb3 in pthread__errorfunc () from /usr/lib/libpthread.so.0
#2 0xbb9491fe in pthread_mutex_destroy () from /usr/lib/libpthread.so.0
#3 0xbbbbd1eb in ldap_pvt_thread_mutex_destroy () from
/usr/pkg/lib/libldap_r-2.3.so.0
#4 0x0805a756 in ?? ()
#5 0x0819e4fc in __ps_strings ()
#6 0x00000002 in ?? ()
#7 0xbfbfe8e8 in ?? ()
#8 0x0805a713 in ?? ()
#9 0x00000286 in ?? ()
#10 0x00000001 in ?? ()
#11 0xbfbfe958 in ?? ()
#12 0x0804e2c1 in ?? ()
#13 0xbfa00000 in ?? ()
#14 0xbb92cdd0 in tzname () from /usr/lib/libc.so.12
#15 0x00000002 in ?? ()
#16 0x00000000 in ?? ()
This was triggered by calling slapd with an invalid URLlist argument:
-h 'ldap://127.0.0.1 ldaps://<external ip>'
with no interfaces on the system configured with <external ip>
16 years, 6 months
(ITS#4995) SampleLDAP.pm w/back_perl appears to be broken
by rra＠stanford.edu
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.
I suspect the code in perl_back_db_open where it does:
dSP; ENTER; SAVETMPS;
PUSHMARK(sp);
XPUSHs( perl_back->pb_obj_ref );
PUTBACK;
#ifdef PERL_IS_5_6
count = call_method("init", G_SCALAR);
#else
count = perl_call_method("init", G_SCALAR);
#endif
The error message is consistent with perl_back->pb_obj_ref being an undefined
value. Why it's undefined, though, I'm not sure.
See also http://www.openldap.org/lists/openldap-software/200705/msg00126.html
16 years, 6 months
(ITS#4994) Clarify -y option in man pages
by rra＠stanford.edu
Full_Name: Russ Allbery
Version: 2.3.35
OS: Debian
URL:
Submission from: (NULL) (171.64.19.147)
A Debian user was confused by the -y option and its inclusion of whitespace in
the password. The current man page text does explain this, but it doesn't make
a point of it, and I think a bit more explanation would be useful. Here's a
patch for the ldapcompare.1 man page; if you think this is a good idea, similar
changes could be made to all the other command-line utilities that take the -y
option.
--- ldapcompare.1 (revision 805)
+++ ldapcompare.1 (working copy)
@@ -106,8 +106,12 @@
Use \fIpasswd\fP as the password for simple authentication.
.TP
.BI \-y \ passwdfile
-Use complete contents of \fIpasswdfile\fP as the password for
-simple authentication.
+Use complete contents of \fIpasswdfile\fP, including any leading or
+trailing whitespace and any final newlines, as the password for
+simple authentication. If the password does not contain a newline,
+be careful when creating this file. Many editors and commands like
+\fBecho\fP will add a trailing newline, which will then be taken as part
+of the password.
.TP
.BI \-H \ ldapuri
Specify URI(s) referring to the ldap server(s); only the protocol/host/port
16 years, 6 months
Re: (ITS#4943) tpool.c pause vs. finish
by h.b.furuseth＠usit.uio.no
hyc(a)symas.com writes:
>hyc(a)symas.com wrote:
>> When we finally get the time to write up a new C API we can worry about
>> where to draw the line between the library and slapd code but for now
>> it's all (philosophically) private to slapd.
>
> (And of course, historically it made sense to put it in the library
> because it was also used by slurpd. But that reason is no longer
> pertinent...)
It was? slurpd uses ldap_pvt_thread_create() directly in both RE23
and openldap-2.0.0. Grepping it for pool finds nothing. However it
does use libldap_r/threads.c, which starts and stops a pool.
Yet another matter, since I'm messing so much with tpool anyway:
It's been confusing to have two types of contexts, thread and user
contexts. I suggest to rename thread contexts to "tasks". They
don't look very contexty to me anyway. As far as I can tell they
are not exposed outside tpool.c, so it won't affect anything else.
User contexts can be renamed back to plain contexts like in RE23.
(The code is confused, too - ldap_int_main_thrctx and my
DELETED_THREAD_CTX are user contexts, not thread contexts.)
--
Regards,
Hallvard
16 years, 6 months
Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com
hyc(a)symas.com wrote:
> When we finally get the time to write up a new C API we can worry about
> where to draw the line between the library and slapd code but for now
> it's all (philosophically) private to slapd.
(And of course, historically it made sense to put it in the library
because it was also used by slurpd. But that reason is no longer
pertinent...)
--
-- 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/
16 years, 6 months
Re: (ITS#4943) tpool.c pause vs. finish
by hyc＠symas.com
h.b.furuseth(a)usit.uio.no wrote:
> Howard Chu writes:
>>> tpool.c breaks if there are multiple pools. The simplest
>>> solution seems to be to remove support for multiple pools.
>>> The problem is thread_keys[]. It is shared between pools, but:
>> slapd only uses a single pool, and that's really the only use case we
>> care about. In fact it makes no sense to support multiple pools,
>> because we have no mechanism to assert scheduling priorities of one
>> pool over another.
>
> I'm afraid I did not think of scheduling priorities at all, only bugs.
> But it certainly makes things simpler if we remove multiple pools.
>
> Simple documentation of how tpool should be used may remove some of
> my concerns - or how it _is_ used, since it's only used in slapd.
> (Several probably only are problems if it is used as a library feature.
> tpool depends on being used the way slapd is using it. I've wondered
> what it's doing in libldap_r/ instead of in slapd/.)
One thing to remember, which has been discussed before - all of
libldap_r exists solely for the benefit of slapd. The only "official"
LDAP API is what was defined in the expired C API draft, and that draft
never addressed reentrancy issues. Any use of libldap_r outside of slapd
is and always will be unsupported; any bugs that might exist solely due
to unintended usage are not our concern.
When we finally get the time to write up a new C API we can worry about
where to draw the line between the library and slapd code but for now
it's all (philosophically) private to slapd.
--
-- 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/
16 years, 6 months