This one kinda cought me by surprise. Commas! The lowdown:
After I started trying out in.xfingerd, part of the openldap package that
came with RedHat 6.2, and the latest version, I noticed this in syslogs:
Apr 28 22:00:22 king in.xfingerd[3234]: connection from localhost
(127.0.0.1)
Apr 28 22:00:26 king inetd[3230]: pid 3234: exit signal 11
Looking at the manpages I found in.xfingerd -i would run it in interactive
mode which is good for debugging, so I installed the SRPMS for the latest
version recompiled in.xfingerd (so I could use a non-stripped version) and
after countless sessions of gdb experimenting I tracked the problem down to
the comma character. Regardless of how many or where they commas crash
in.xfingerd and probably cause other chaos because here is what gdb showed:
(gdb) run -i
Starting program:
/usr/src/redhat/BUILD/openldap-1.2.9/clients/finger/./in.xfingerd -i
OpenLDAP Finger Service...
,
Program received signal SIGSEGV, Segmentation fault.
0x8053975 in ldap_strdup (s=0x0) at strdup.c:21
21 if ( (p = (char *) malloc( strlen( s ) + 1 )) == NULL )
The most unfortunate thing is that ldap_strdup is a function in the libldap
so theoretically any other programs that use functions that use ldap_strdup
from libldap could have similar crashing problems.
-Stan Bubrouski

Great. I applied the patch to the current SRPM recompiled and problem was
solved. The latest CVS devel branch on openldap.org has it fixed as well.
Thanks for submitting the ITS to openldap.org, I was waiting for my ISP to get my
e-mail accounts working again...can't access my most used one because of mail
server upgrades. Couple things I thought of in regards to running openldap as a
regular user on RedHat:
1. group ldap should be created to allow reading but not writing to global
configuration files in /etc/openldap and write access to ldap group only to /var/
lib/ldap in order to create/read/modify temp files there.
2. Currently several of the smaller servers which come with openldap handle their
own logging and log to syslog facilities like local3.* local4.* etc....ones not
normally configured by default on most RedHat and probably other machines. When
I say small servers I'm refering to ones like in.xfngerd go500 mail500 etc...and
others. Check out ITS #524. Anyway it would seem best to configure logging in
all such applications using the ber_set_option(NULL, LBER_OPT_LOG_PRINT_FN, ...)
function the maintainer mentions in the ITS plus their should be some sort of
option to configure the other utilites through the ldap initscript or something
because otherwise things like in.xfingerd have to be added to inetd.conf by hand
or rcpt500 whatever server has to have an entry added to /etc/aliases file by
hand (though bad example because I'm not sure that it is safe doing as the
manpage suggests when I look at the program itself)
Just some thoughts.
-Stan Bubrouski
e-mail: satan@fastdial.net

Having slapd execute as a non-root user is in the CVS tree for 2.x, but I've had
trouble backporting it to the 1.2.x tree. There's some strange thread-related
problem (only one thread changes its uid after it binds to the proper port).
I'm not quite sure what you mean when you refer to /etc/aliases. Did you mean
the inetd config file instead?

Sorry about the spacing of the last message, sometimes I forget what
a text-box is ;) When I was refering to /etc/aliases I was refering
to rcpt500 manpage which is part of the of the openldap package in
the clients directory. Quote:
If you are using sendmail(8), you could add the following
line to the aliases(5) file (/etc/aliases) to have rcpt500 invoked
whenever mail is sent to the address namelookup on your host:
namelookup: "|/usr/sbin/rcpt500 -l"
That is what I was refering to. It's not a critical service just one
of the little ones hidden away in the clients directory, I was just
wondering why bother even compiling them if the proper stuff isn't easily
added to the config files when the package is installed anyway. Chances
are if people had a use for them then they'd prolly expect them to be
configured when the openldap package is installed IMHO (which is often
times not so humble because so much spare time has left me conceded beyond
repair ;)
-Stan Bubrouski