Bug#452780: Another new upstream version (1.6.2)

[Berg, Michael]

Just updating this report since there has been no response to the
original wishlist bug in over a year an a half, and a few new versions
have been made available since then (the most recent is 1.6.2).

http://www.ossp.org/pkg/lib/uuid/



-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org

Bug#411301: [OTR-dev] Re: Bug#411301: gaim DNS children die when gaim-otr is installed

[Berg, Michael]

> Has this been resolved in the debian package?  The upstream source has a
> "Makefile.static" that statically links libgcrypt into pidgin-otr.so.
> 
> [D'oh.  The version of Makefile.static in the 3.2.0 release forgot to
> link in the new tooltipmenu.o file.  It's fixed in cvs.]
> 
>- Ian

I just tested with the latest pidgin 2.4.2-2 and
pidgin-otr 3.1.0-1 from Debian unstable.
The problem just is still present.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#478980: libsqlite3-0: undefined reference to dlsym/dlerror/dlopen/dlclose

[Berg, Michael]

Laszlo Boszormenyi wrote:
> package libsqlite3-0
> severity 478980 normal
> thanks
> 
> Hi Michael,
> 
> On Thu, 2008-05-01 at 19:35 -0600, Michael Berg wrote:
>> Package: libsqlite3-0
>> Version: 3.5.8-2
>> Severity: important
>>
>> When trying to link some code I'm writing against libsqlite3-0 3.5.8-2,
>> I get the following error messages from the linker:
>> =
>> /usr/lib/libsqlite3.so.0: undefined reference to `dlsym'
>> /usr/lib/libsqlite3.so.0: undefined reference to `dlerror'
>> /usr/lib/libsqlite3.so.0: undefined reference to `dlopen'
>> /usr/lib/libsqlite3.so.0: undefined reference to `dlclose'
>> =
>>
>> The same code properly compiles and links against libsqlite3-0 3.5.8-1
>> and earlier versions of the package under Debian.

>  These symbols was never in SQLite3 itself, they are provided by the
> dynamic linker. Please specify -ldl in your LDFLAGS for the linker.
> Please report back if your problem remains or not; in the former case,
> can you give me your project for testing?
> 
> Regards,
> Laszlo/GCS
> 


Adding -ldl allows my code to link, but I still view this to be a bug in
the libsqlite3-0 3.5.8-1 package.

$ ldd /usr/lib/libsqlite3.so.0.8.6
linux-vdso.so.1 =>  (0x7fffaf9fd000)
libpthread.so.0 => /lib/libpthread.so.0 (0x2acefb4c3000)
libc.so.6 => /lib/libc.so.6 (0x2acefb6de000)
/lib64/ld-linux-x86-64.so.2 (0x4000)

libsqlite3.so.0.8.6 uses libpthread.so.0, but I don't have to specify
-lpthread when I link against libsqlite3 (because libsqlite3 is already
linked against it).

Sine the requirement for libdl is coming from libsqlite3, libsqlite3
should link against libdl.





-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#456806: clamav-freshclam: freshclam created files can only be read by clamav user

[Berg, Michael]

Stephen Gran wrote:
> Do you set umask in /etc/profile or in a pam setting or something?

My /etc/profile actually has the line "umask 022" in it.

However, I did just track down a "pam_umask.so umask=0077" in one of the
pam session files.  I can't remember if I or a package made that setting
at some point in the past, but at any rate, the bug can be closed.

Thanks for your help and sorry for the trouble.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#456806: clamav-freshclam: freshclam created files can only be read by clamav user

[Berg, Michael]

Stephen Gran wrote:
> I have to say that's very strange.  Can you strace a startup of
> freshclam for me?  I don't remember any umask calls in the database
> writing code, but maybe I'm missing something.
> 
> Thanks,

Stephen,

Sorry for the delay on this (Christmas, New Year, etc), but I finally
had some time to do more debugging.  I did a purge of all clamav
packages again and a fresh install.

After a fresh install, I have the following:

# ls -ld /var/lib/clamav/
drwxr-xr-x 3 clamav clamav 67 2008-01-04 19:15 /var/lib/clamav/

# ls -l /var/lib/clamav/
-rw--- 1 clamav clamav   513074 2008-01-04 19:15 daily.cvd
-rw-r--r-- 1 root   root   11347852 2008-01-04 19:15 main.cvd
-rw--- 1 clamav clamav   52 2008-01-04 19:15 mirrors.dat

I stopped the running freshclam process with
/etc/init.d/clamav-freshclam stop

If I remove daily.cvd to force a fresh download and then run freshclam
manually (as root), the permission on the newly downloaded file is
correct (unlike the original right after install).

# ls -l /var/lib/clamav/
-rw-r--r-- 1 clamav clamav   513074 2008-01-04 19:19 daily.cvd
-rw-r--r-- 1 root   root   11347852 2008-01-04 19:15 main.cvd
-rw--- 1 clamav clamav  156 2008-01-04 19:19 mirrors.dat

So it doesn't look like a problem with freshclam itself.

However, in /etc/init.d/clamav-freshclam, freshclam is started on line
197 with the command
=
su "$DatabaseOwner" -p -s /bin/sh -c ". /lib/lsb/init-functions &&
start_daemon $DAEMON -d --quiet"
=

$DatabaseOwner is "clamav", and I see the following behavior if I
manually try that action broken up into several steps:

# id
uid=0(root) gid=0(root) groups=0(root)
# umask
0022

# su clamav -p -s /bin/sh
$ id
uid=108(clamav) gid=108(clamav) groups=108(clamav)
$ umask
0077

If I then remove daily.cvd and run freshclam from this clamav shell, the
resulting daily.cvd has mode 600.

So the source of the problem appears to be the umask changing to 0077
when the script su's to the clamav user.



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#437978: Problem Found

[Berg, Michael]

I spent some time going through /var/lib/dpkg/info/monotone-server.postinst
and noticed that all user:group and permissions settings on lines
124-148 were getting done except for the "if"-block on lines 126-140.
The if-block that isn't getting done is
==
if [ -z "`id -u monotone 2>/dev/null`" ]; then
   ...
==

After purging the installed monotone-server package, the monotone user
and group where still present on the system -- so when I would reinstall
 monotone-server, none of the user:group or permissions settings in that
if-block were being done on the newly created directories.

The monotone user and group were still present because of the section in
/var/lib/dpkg/info/monotone-server.postrm starting at line 80 with the
description:
==
# if deluser/delgroup exist, remove the server user and group.
# do not do this if /var/lib/monotone still exists (so that it
# will still have a named user owning it).
==

I use a key name for the monotone server that is different from the
auto-generated one, so there was still that key file in
/var/lib/monotone/keys, so /var/lib/monotone was still present and
prevented the monotone user and group from being removed, messing up
directory permissions on a reinstall.

Once I manually removed the user and group, installing monotone-server
sets the user:group and permissions correctly.


As one potential solution, would it work to move the "chown" and "chmod"
lines to just after the "`id -u monotone 2>/dev/null`" if-block down to
with all the other "chown" and "chmod" lines being done on a new install?

That way the monotone user and group being present would only effect the
"adduser" command and not the settings for the newly created directories.

Potential patch is attached.


- Michael Berg

--- monotone-server.postinst	2007-11-03 23:49:54.0 -0600
+++ monotone-server.postinst.fixed	2007-11-03 23:51:31.0 -0600
@@ -127,18 +127,18 @@
 	   adduser --system --group --home $MTN_HOME \
 	   --no-create-home --disabled-password --quiet\
 	   --gecos "Monotone" monotone
-	   
-	   chown monotone:monotone $MTN_HOME
-   chown monotone:monotone $MTN_CONFDIR
-   chown monotone:monotone $MTN_KEYDIR
-   chown monotone:monotone /var/log/monotone
-   chown monotone:monotone /var/run/monotone
-
-   chmod 0750 $MTN_HOME
-   chmod 0750 $MTN_CONFDIR
-   chmod 0750 $MTN_KEYDIR
fi
 
+   chown monotone:monotone $MTN_HOME
+   chown monotone:monotone $MTN_CONFDIR
+   chown monotone:monotone $MTN_KEYDIR
+   chown monotone:monotone /var/log/monotone
+   chown monotone:monotone /var/run/monotone
+
+   chmod 0750 $MTN_HOME
+   chmod 0750 $MTN_CONFDIR
+   chmod 0750 $MTN_KEYDIR
+
chown monotone:monotone /etc/monotone/write-permissions
chown monotone:monotone /etc/monotone/read-permissions
chown monotone:monotone /etc/monotone/hooks.lua

Bug#437978: can't reproduce this with 0.37-1 either

[Berg, Michael]

> * By any chance is /bin/sh provided by dash on the machine you're
> using?  The maintainer scripts have a number of bashisms in them.
> (This will be fixed in 0.37-2.)

No.  dash is not even installed on this system.

As a regular user:
$ realpath /bin/sh
/bin/bash

As root:
# realpath /bin/sh
/bin/bash


> * Could I get you to check out the tip of
> net.venge.monotone.debian-diff (server monotone.ca) ...

Right now I don't have time to do this, but some additional information
and thoughts are below.

I recently upgraded to the 0.37 package with no problems, but after
receiving email I purged and reinstalled as a test.

==
# aptitude install monotone-server
... dialog questions ...

Selecting previously deselected package monotone-server.
(Reading database ... 225657 files and directories currently installed.)
Unpacking monotone-server (from .../monotone-server_0.37-1_all.deb) ...
Setting up monotone-server (0.37-1) ...

Creating config file /etc/monotone/write-permissions with new version

Creating config file /etc/monotone/read-permissions with new version

Creating config file /etc/monotone/hooks.lua with new version
Creating Monotone database...
Creating Monotone server keypair...
enter passphrase for key ID [EMAIL PROTECTED]:
confirm passphrase for key ID [EMAIL PROTECTED]:
Monotone database created successfully.
Starting Monotone Server: monotone
monotone configured in /etc/default/monotone not to start.
Reading package lists... Done
Building dependency tree
Reading state information... Done
Reading extended state information
Initializing package states... Done
Writing extended state information... Done
==

# ls -ld /var/run/monotone/
drwxr-xr-x 2 root root 6 2007-11-01 13:01 /var/run/monotone/

So I'm still getting hit by this on a new installed on this system.

>From a previous entry in this bug report:
> It may be that the problem was due to the monotone user not
> being present for some reason.

I'm using LDAP for user authentication on this system in addition to
/etc/password and /etc/shadow.

monotone is in /etc/passwd as
monotone:x:118:126:Monotone,,,:/var/lib/monotone:/bin/false

Maybe using an authentication system beyond the standard password files
is causing some kind of problem during monotone-server installation.




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#437978: monotone-server: Incorrect user and group on /var/run/monotone/

[Berg, Michael]

Ludovic Brenta wrote:
> I investigated the problem but the postinst script explicitly sets the
> owner of /var/run/monotone to monotone:monotone.
> 
> It may be that the problem was due to the monotone user not being
> present for some reason.
> 
> Please try again with 0.36-1 (which I just uploaded) and tell us if
> the problem is gone.  Zack has made some changes to the postinst
> script in this release to correct several problems, one of which may
> be the cause for this bug.

I'm still experiencing the problem.  I purged my install of monotone-server
and installed the new 0.36 package.

$ ls -ld /var/run/monotone
drwxr-xr-x 2 root   root  6 2007-08-24 11:19 monotone

- Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379480: Mouse and partial keyboard freeze also, but not only on AMD64

[Berg, Michael]

I did some follow-up troubleshooting.  I upgraded all X packages to the
versions in experimental -- and both bugs #379480 and #403822 are still
present.

I set the time backward -- mouse clicks and keyboard shortcuts become
non-responsive.  I tried setting the time forward again, and it fixed the
problem -- mouse clicks and keyboard shortcuts worked again.

I have a correction/clarification to my previous bug report.
I can continue to type in the xterm I set the clock back from as long as I
don't mouse click on another window to try and change focus.  Before I just
tried changing focus with window manager keyboard shortcuts which had no
effect.  Clicking on another window seems to corrupt some state somewhere
and all key input gets hosed (Ctrl-Alt-Backspace and Ctrl-Alt-Fx no longer
work).

$ apt-show-versions | grep xorg | sort
xorg/unstable uptodate 1:7.1.0-18
xserver-xorg-core/unstable uptodate 2:1.3.0.0.dfsg-3
xserver-xorg/experimental uptodate 1:7.2-2
xserver-xorg-input-all/experimental uptodate 1:7.2-2
xserver-xorg-input-evdev/experimental uptodate 1:1.1.5-1
xserver-xorg-input-kbd/experimental uptodate 1:1.1.1-1
xserver-xorg-input-mouse/experimental uptodate 1:1.1.2-1
xserver-xorg-input-synaptics/unstable uptodate 0.14.6-1
xserver-xorg-input-wacom/unstable uptodate 0.7.4.1-6
xserver-xorg-video-all/unstable uptodate 1:7.1.0-18
xserver-xorg-video-apm/experimental uptodate 1:1.1.1-5+b1
xserver-xorg-video-ark/experimental uptodate 1:0.6.0-5+b1
xserver-xorg-video-ati/experimental uptodate 1:6.6.3-5
xserver-xorg-video-chips/experimental uptodate 1:1.1.1-6+b1
xserver-xorg-video-cirrus/experimental uptodate 1:1.1.0-5+b1
xserver-xorg-video-cyrix/experimental uptodate 1:1.1.0-6+b1
xserver-xorg-video-dummy/experimental uptodate 1:0.2.0-5+b1
xserver-xorg-video-fbdev/experimental uptodate 1:0.3.1-2
xserver-xorg-video-glint/experimental uptodate 1:1.1.1-5
xserver-xorg-video-i128/experimental uptodate 1:1.2.1-1
xserver-xorg-video-i810/unstable uptodate 2:2.0.0-1
xserver-xorg-video-intel/unstable uptodate 2:2.0.0-1
xserver-xorg-video-mga/unstable uptodate 1:1.4.6.1.dfsg.1-2
xserver-xorg-video-neomagic/experimental uptodate 1:1.1.1-6
xserver-xorg-video-nv/unstable uptodate 1:2.0.2-1
xserver-xorg-video-rendition/experimental uptodate 1:4.1.3.dfsg.1-1
xserver-xorg-video-s3/experimental uptodate 1:0.5.0-1
xserver-xorg-video-s3virge/experimental uptodate 1:1.9.1-5
xserver-xorg-video-savage/experimental uptodate 1:2.1.2-4
xserver-xorg-video-siliconmotion/experimental uptodate 1:1.4.2-1
xserver-xorg-video-sis/experimental uptodate 1:0.9.3-1
xserver-xorg-video-sisusb/experimental uptodate 1:0.8.1-5
xserver-xorg-video-tdfx/experimental uptodate 1:1.3.0-2
xserver-xorg-video-tga/experimental uptodate 1:1.1.0-5
xserver-xorg-video-trident/experimental uptodate 1:1.2.3-2
xserver-xorg-video-tseng/experimental uptodate 1:1.1.0-5
xserver-xorg-video-v4l/experimental uptodate 0.1.1-5
xserver-xorg-video-vesa/experimental uptodate 1:1.3.0-2
xserver-xorg-video-vga/experimental uptodate 1:4.1.0-5
xserver-xorg-video-via/experimental uptodate 1:0.2.2-1
xserver-xorg-video-voodoo/experimental uptodate 1:1.1.1-1


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379480: Mouse and partial keyboard freeze also, but not only on AMD64

[Berg, Michael]

Bug #379480 is still partially present.

When I set my system clock back a few minutes, X becomes non-responsive to
mouse click events (I can't open menus or change window focus).
Window manager (openbox) hotkeys I have for opening new xterms or opening
the application menu list don't work after setting the clock back either.

However, I can still type into the xterm I changed system time from, and
Ctrl-Alt-Backspace now kills X (so I could recover easier).

Here's what I have installed
xserver-xorg-core   1.3.0.0.dfsg-3

I'm currently up-to-date with sid/unstable.

I've using a USB keyboard and mouse if that makes any difference.

When I set the clock back, I still experienced bug #403822 as well.
(hitting enter on the "date -s ..." command resulted in several extra
new-lines appearing in my xterm)

- Michael


Brice Goglin wrote:
> Hi,
> 
> If this Xorg/keyboard/mouse freeze is related to time skew, it could be
> fixed with the current version unstable (xserver-xorg-core 1.3). We had
> several bug reports about a crash occurring when changing the date
> backwards, and I think most of them have been reported as fixed now.
> Please let me know if you can reproduce now.
> 
> Brice
> 


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#411301: gaim DNS children die when gaim-otr is installed

[Berg, Michael]

Sorry, small correction.  I *thought* I'd run valgrind in my chroot, but I
hadn't.  When I run "valgrind gaim" in my Debian i386 chroot, I get the
same pages upon pages of
=
  by 0x5C5617D: (within /usr/lib/libsoftokn3.so.0d)
=
related output as I did on the laptop.

Oh, and just to avoid any possibly confusion for people not familiar with
these, libnss3.so.0d and libnss_ldap-2.3.6.so are of no relation.

libnss_ldap-2.3.6.so is in the libnss-ldap package, which is the
"NSS module for using LDAP as a naming service"

libnss3.so.0d is in the libnss3-0d package, which is a
"Network Security Service libraries" that came out of Netscape/Mozilla

- Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#411301: gaim DNS children die when gaim-otr is installed

[Berg, Michael]

Steve Langasek wrote:
> Well, this problem indeed doesn't seem to be reproducible on i386 or amd64
> when not using nss_ldap.  Given that users of other gnutls- or gcrypt-using
> packages aren't reporting similar problems, it seems likely that this is a
> bug in gaim-otr or libotr, but I don't think it's one that should block the
> package from being released; it is generally usable, just not in certain
> system configurations.

Yeah, I do have a system configuration that you don't run across every day ;-)


Ian Goldberg wrote:
> Is it reproducible on other systems that *do* use nss_ldap?  Can you
> turn nss_ldsp on on one of those other systems you tested, and try
> again?

I did a clean install of Debian unstable onto a x86 (32-bit) laptop, tested
gaim with and without gaim-otr installed.  gaim and gaim+otr both worked
properly.

Then I installed libnss-ldap and libpam-ldap and configured them for my
network setup.  gaim (without otr) worked, but gaim+otr had the same errors
as I reported for my amd64 system (and the 32-bit chroot I also tested
there).  So I can duplicate the bug when nss_ldap is in use.

Valgrind output is attached for the following 4 test cases:
1) gaim (without otr or nss_ldap): gaim.9110.gz
2) gaim+otr (without nss_ldap):gaim+otr.9180.gz
3) gaim with nss_ldap in use:  gaim+ldap.10134.gz
4) gaim+otr with nss_ldap in use:  gaim+otr+ldap.10038.gz

Unfortunately, all of these valgrind runs on that x86 laptop have a TON of
=
Conditional jump or move depends on uninitialised value(s)
  at 0x5C55DC7: (within /usr/lib/libsoftokn3.so.0d)
  by 0x5C5617D: (within /usr/lib/libsoftokn3.so.0d)
  by 0x5C56243: (within /usr/lib/libsoftokn3.so.0d)
  by 0x5C56471: (within /usr/lib/libsoftokn3.so.0d)
  by 0x5C566D8: (within /usr/lib/libsoftokn3.so.0d)
  by 0x5C445C4: (within /usr/lib/libsoftokn3.so.0d)
  by 0x5C44721: (within /usr/lib/libsoftokn3.so.0d)
  by 0x5B9B7C2: (within /usr/lib/libnss3.so.0d)
  by 0x5B9B8C2: (within /usr/lib/libnss3.so.0d)
  by 0x5BA4133: SECMOD_LoadModule (in /usr/lib/libnss3.so.0d)
  by 0x5BA428A: SECMOD_LoadModule (in /usr/lib/libnss3.so.0d)
  by 0x5B8342D: (within /usr/lib/libnss3.so.0d)
=
that occur in each capture.
I didn't see these on the amd64 system or the x86 chroot I set up on that
system.  Do you guys get pages and pages of that output when you run
valgrind on gaim on a 32-bit x86 system?  If not, I'll try to figure out
what's causing it on that freshly installed laptop.

- Michael


gaim.9110.gz
Description: application/gzip


gaim+otr.9180.gz
Description: application/gzip


gaim+ldap.10134.gz
Description: application/gzip


gaim+otr+ldap.10038.gz
Description: application/gzip

Bug#411301: gaim DNS children die when gaim-otr is installed

[Berg, Michael]

> Is it reproducible on other systems that *do* use nss_ldap?  Can you
> turn nss_ldsp on on one of those other systems you tested, and try
> again?

I'll do this tonight.  I did a clean install of Debian unstable onto a
laptop this weekend - but I got busy and wasn't able to test gaim on it yet
(still have to copy over my user account and such).

When I get home tonight, I'll test without nss_ldap first, and then I'll
change it to use nss_ldap for the home network and try again.

It's an i386 system, and I'll provide valgrind output for the following
test cases:
1) gaim, no OTR, no nss_ldap
2) gaim+OTR, no nss_ldap
3) gaim, no OTR, with nss_ldap
4) gaim+OTR, with nss_ldap

That covers all combinations and should provide some useful comparison
points.  If there is anything else you'd like for debugging purposes, let
me know (specific options to valgrind, etc) and I'll put them in the queue
for when I get home.

- Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379480: (reopen) Bug still present

[Berg, Michael]

Bug #379480 is still present.  My system froze up last week, and it froze
up again today about half an hour ago.  I have been tracking sid during
this whole time (I keep fairly current with sid for testing purposes).

When I checked the status of this bug and saw that it had been closed on
Dec 20, I tested the time skew again was was still able to reliably freeze X.

Jiri's message on Dec 20 also pointed to a new bug #403822.
When I tested the time skew, I actually experienced both of these bugs.
When I hit Enter on the command "date -s 'Sun Jan  7 ...'", I had about
five extra new lines appear in my xterm.  That xterm was still responsive
to keyboard activity, but my mouse-over window focus no longer worked.  And
when I tried to click on another window, X became completely unresponsive
to all keyboard and mouse activity (no Ctrl-Alt-Backspace, Ctrl-Alt-F1, etc).

So this bug is still present and reproducible on my system, in addition to
experiencing bug #403822 when I trigger bug #379480.

Versions of packages xserver-xorg-core depends on:
ii  libc6   2.3.6.ds1-9
ii  libfontenc1 1.0.2-2
ii  libgcc1 4.1.1-21
ii  libxau6 1.0.1-2
ii  libxdmcp6   1.0.1-2
ii  libxfont1   1.2.2-1
ii  x11-common  7.1.0-9
ii  xkb-data0.9-4
ii  xserver-xorg7.1.0-9

Additionally:
$ apt-show-versions | grep xserver | sort
xserver-xorg-core/unstable uptodate 2:1.1.1-13
xserver-xorg-input-all/unstable uptodate 1:7.1.0-9
xserver-xorg-input-evdev/unstable uptodate 1:1.1.2-6
xserver-xorg-input-kbd/unstable uptodate 1:1.1.0-4
xserver-xorg-input-mouse/unstable uptodate 1:1.1.1-3
xserver-xorg-input-synaptics/unstable uptodate 0.14.6-1
xserver-xorg-input-wacom/unstable uptodate 0.7.4.1-5
xserver-xorg/unstable uptodate 1:7.1.0-9
xserver-xorg-video-all/unstable uptodate 1:7.1.0-9
xserver-xorg-video-apm/unstable uptodate 1:1.1.1-3
xserver-xorg-video-ark/unstable uptodate 1:0.6.0-3
xserver-xorg-video-ati/unstable uptodate 1:6.6.3-2
xserver-xorg-video-chips/unstable uptodate 1:1.1.1-4
xserver-xorg-video-cirrus/unstable uptodate 1:1.1.0-3
xserver-xorg-video-cyrix/unstable uptodate 1:1.1.0-4
xserver-xorg-video-dummy/unstable uptodate 1:0.2.0-3
xserver-xorg-video-fbdev/unstable uptodate 1:0.3.1-1
xserver-xorg-video-glint/unstable uptodate 1:1.1.1-3
xserver-xorg-video-i128/unstable uptodate 1:1.2.0-3
xserver-xorg-video-i810/unstable uptodate 2:1.7.2-3
xserver-xorg-video-mga/unstable uptodate 1:1.4.4.dfsg.1-2
xserver-xorg-video-neomagic/unstable uptodate 1:1.1.1-4
xserver-xorg-video-nv/unstable uptodate 1:1.2.0-3
xserver-xorg-video-rendition/unstable uptodate 1:4.1.0.dfsg.1-4
xserver-xorg-video-s3/unstable uptodate 1:0.4.1-5
xserver-xorg-video-s3virge/unstable uptodate 1:1.9.1-3
xserver-xorg-video-savage/unstable uptodate 1:2.1.2-3
xserver-xorg-video-siliconmotion/unstable uptodate 1:1.4.1-4
xserver-xorg-video-sis/unstable uptodate 1:0.9.1-4
xserver-xorg-video-sisusb/unstable uptodate 1:0.8.1-3
xserver-xorg-video-tdfx/unstable uptodate 1:1.3.0-1
xserver-xorg-video-tga/unstable uptodate 1:1.1.0-3
xserver-xorg-video-trident/unstable uptodate 1:1.2.3-1
xserver-xorg-video-tseng/unstable uptodate 1:1.1.0-3
xserver-xorg-video-v4l/unstable uptodate 0.1.1-3
xserver-xorg-video-vesa/unstable uptodate 1:1.3.0-1
xserver-xorg-video-vga/unstable uptodate 1:4.1.0-3
xserver-xorg-video-via/unstable uptodate 1:0.2.1-6
xserver-xorg-video-voodoo/unstable uptodate 1:1.1.0-4



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#379480: X Key/Mouse Freeze might be time/clock based

[Berg, Michael]

Several of my friends and I have been having similar problems - X
keyboard/mouse input occasionally freezing.

The problem has been encountered on both i386 and AMD64 systems, with both
nvidia and ati video cards, with both free and proprietary drivers.

The interesting thing is that most of our systems would "freeze" at almost
the exact same time each time it happened (once every few months).  It
happened again today, and three of our systems (in various locations around
the city and state) all froze up during the same 1-2 minute period.

So I started really looking into time-based triggers.  During my
troubleshooting experiments, I found that if the system clock is adjusted
even a few seconds backward, X input will freeze up a few seconds later.

For example:
1. Make sure any NTP software is turned off (since we want to know what
changes are being made to the clock).

2. Execute the date command and then adjust the time back slightly (about 2
minutes backward is used in this example).

  # date
  Sat Sep 30 15:02:22 MDT 2006

  # date -s 'Sat Sep 30 15:00:00 MDT 2006'

Every time I tried this, X keyboard and mouse input would freeze up a few
seconds later.  Desktop applets like the system clock, CPU monitor, network
activity, etc would all still be actively displaying (so the screen is
still updating), but I would be unable to mouse between windows, hot-key
between windows, type into the currently focused xterm, Ctrl-Alt-backspace
to kill X, or Ctrl-Alt-F2 to a terminal window.

ssh'ing in from another computer and then stopping gdm and/or X would allow
me to recover, restart X and run other test scenarios.

Can those of you who are also having this problem try the clock adjustment
test above and see if you have the same results?

How many of you who are experiencing the problem are running NTP
synchronization software on your system?

I should also note that I could adjust the clock forward as much as I
wanted with no adverse effects (I had test cases of moving forward a few
seconds, a few minutes, a few hours, and almost an entire day), but any
adjustment of the clock backward from its current setting triggered the
problem.

I'm running openbox, and my friends were both running GNOME (one on top of
openbox and one on top of metacity).

I had the same results in my tests whether the X session was started
through GDM or from startx on the command line, and the same results
whether xscreensaver was running or not.

My theory on the three computers having having the problem at the same time
is that a small backward re-adjustment may have propagated through the NTP
servers we're using - which triggered the problem.

For those of you who are experiencing this problem more frequently, if you
have worse than average clock drift and are running NTP software, your
system would probably be having to "skip" the clock back more often than
most on most systems.  Or you may be using a very "jittery" NTP server.
People who aren't running NTP probably wouldn't encounter the problem.
But please respond to this if you are experiencing this and don't use NTP
(every data point can help track down a bug).

Anyway, hopefully this helps track down the problem.

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#376426: libnss-ldap: Can't login even as local user

[Berg, Michael]

> Steinar H. Gunderson wrote:
>>> With libnss-ldap 238-1.2 installed
>>>
>>> $ cat /proc/sys/kernel/random/entropy_avail; \
>>>   getent passwd user_in_ldap; \
>>>   cat /proc/sys/kernel/random/entropy_avail
>>> 3585
>>> passwd entry here
>>> 129
>> Are you sure it's not falling back to non-TLS here? Or local files somehow? I
>> can't see a reason why it would fail any better than 251, given that a
>> failure is still a failure and the relevant change is what it does after the
>> fact...
> 
> I'm rather certain it's not falling back to non-TLS.  There are NO
> configuration file changes when I switch back and forth between versions
> 238 and 251. ...

I forgot to address the "falling back to local files" part of your question
in my previous email.

The ldap relevant parts of my /etc/nsswitch.conf are
==
passwd: files ldap
group:  files ldap
shadow: files ldap
==

I have files first so that when there are problems with ldap (which
happens), root will be more likely to be able to log in since the local
files are checked first.

And while I was executing back-to-back "getent passwd" commands with
libnss-ldap version 238 installed, each command continued to return user
accounts that are only present in LDAP (and so could not have come from
local files).

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#376426: libnss-ldap: Can't login even as local user

[Berg, Michael]

Steinar H. Gunderson wrote:
>> With libnss-ldap 238-1.2 installed
>>
>> $ cat /proc/sys/kernel/random/entropy_avail; \
>>   getent passwd user_in_ldap; \
>>   cat /proc/sys/kernel/random/entropy_avail
>> 3585
>> passwd entry here
>> 129
> 
> Are you sure it's not falling back to non-TLS here? Or local files somehow? I
> can't see a reason why it would fail any better than 251, given that a
> failure is still a failure and the relevant change is what it does after the
> fact...

I'm rather certain it's not falling back to non-TLS.  There are NO
configuration file changes when I switch back and forth between versions
238 and 251.

My /etc/ldap/ldap.conf files on various hosts all contain
==
TLS_CIPHER_SUITEHIGH:!ADH
TLS_CACERT  /etc/ssl/certs/my_CA_cert.pem
TLS_REQCERT demand
TLS_CRLCHECKnone
==
And according to the manual page
TLS_REQCERT 
   demand | hard
These  keywords  are  equivalent.
The server certificate is requested. If no
certificate is provided, or a bad certificate is provided,
the  session  is immediately terminated.
This is the default setting.


And then in my /etc/ldap/slapd.conf I have the lines
==
TLSCipherSuite  HIGH:!ADH
TLSCACertificateFile/etc/ssl/certs/my_CA_cert.pem
TLSCertificateFile  /etc/ssl/certs/ldap.my_domain.pem
TLSCertificateKeyFile   /etc/ldap/private/ldap.my_domain.pem
TLSCRLCheck none
TLSVerifyClient never

securityssf=128
==

According to the manual page, "security ssf=128"
"specifies the overall security strength factor" as being at least 128 bit
encryption for all operations.


I have had these configuration settings in place for at least a year in
order to explicitly prevent non-TLS operation of both the clients and the
server.

I have also verified TLS operation with my currently installed (and
working) libnss-ldap version 238 by capturing loopback traffic with
wireshark/ethereal and performing multiple back-to-back "getent passwd"
commands which (as documented previously) exercises libnss-ldap and slapd
and drain the entropy pool.  The only non-encrypted LDAP traffic in the
captures is when certificates information is being exchanged as part of the
STARTTLS and I can see the strings from my CA info going back and forth.

Michael


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#362684: is not resolved

[Berg, Michael]

gaim 1:2.0.0+beta3.1-3 has entered unstable, but gaim can not be upgraded
without uninstalling gaim-otr.

gaim-otr 3.0.0-2 has the following in its depends list
"gaim (>= 1:1.5), gaim (<< 1:2.0)"

Attempting to install both gaim and gaim-otr results in the following error
message: "gaim-otr: Depends: gaim (< 1:2.0) but 1:2.0.0+beta3.1-3 is to be
installed"

So this bug is no longer resolved.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#376426: libnss-ldap: Can't login even as local user

[Berg, Michael]

A low entropy pool may be a contributing factor, but something definitely
changed between libnss-ldap 238 and 251.

With libnss-ldap 238-1.2 installed

$ cat /proc/sys/kernel/random/entropy_avail; \
  getent passwd user_in_ldap; \
  cat /proc/sys/kernel/random/entropy_avail
3585
passwd entry here
129

So with libnss-ldap 238, you see the same drain on the entropy pool
(from ~3500 down to ~200).

However, you don't experience the same problems with libnss-ldap 238 as you
do with libnss-ldap 251 (mainly everything getting a SIGPIPE with 251).



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381788: Any progress on Bug #381788

[Berg, Michael]

Has there been any progress on Bug #381788?
There hasn't been any word from the package maintainers since my post on
August 13.

I am still experiencing this bug, and today I received an email from
another individual who is also experiencing this problem.  The person who
contacted me wanted to know if I'd found a solution and also had two other
work-around -- which aren't really usable for either of us.

The first work-around this individual reported to me was to disable
start_tls support.  Since the problem is in the SSL handshake when TLS is
being started, this avoid the problem.  However, this is not an acceptable
work-around for either of us.  I'm using slapd to authenticate users, so
passwords are being exchanged with the server. (Running slapd as root is
probably a lower security risk than sending all user passwords in the clear).

The second work-around this individual reported to me was to take "ldap"
out of the group line in nsswitch.conf.  This is a more targeted action
than removing "ldap" from every line in nsswitch.conf (that I documented in
my previous email).  Again, this work-around is unacceptable since I have
groups in LDAP being used by other services on the system.

The work-around I previously documented of running slapd as root (which
avoids the gnutls variant of the ldap client libraries from being loaded)
seems to be the best work-around at the moment.  Although I still want to
run slapd as a non-root user for security reasons.

Could one of the maintainers please comment on the status of this bug?

Thanks.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381788: slapd: TLS connections fail when running as non-root

[Berg, Michael]

Quanah, Thank you for all your help on this!

I think this round of debugging finally found the problem!
(which looks like either a "libldap-2.3-0 vs. libldap2" or a "gnutls vs.
openssl" conflict in the Debian packages).


Here are the answers to the questions from Howard Chu.

> [13:21] Howard Chu: have you checked permissions on /dev/random or
> /dev/urandom ?

Yes,  here's a copy of the output

$ ls -l /dev/*random
crw-rw-rw- 1 root root 1, 8 2006-08-12 21:46 /dev/random
crw-rw-rw- 1 root root 1, 9 2006-08-12 21:47 /dev/urandom


> [13:21] Howard Chu: have you checked to see if libssl is dynamically
> linked, and the root user is getting a different library path than the
> openldap user?

libssl is dynamically linked.

The attached files slapd-maps-root.txt.gz and slapd-maps-openldap.txt.gz
are the gzip'd contents of /proc/PID/maps for slapd running as root and
slapd running as openldap respectively (for the PID of slapd each time).
They show all files that are memory mapped into the process's address space
(which includes all the linked libraries and the database files).

Due to the basic address randomization in the kernel, a diff between these
files isn't very informative.  But if you pull out just the unique file
paths with

$ zcat slapd-maps-root.txt.gz | awk '{print $6}' | sort -u > root.txt
$ zcat slapd-maps-openldap.txt.gz | awk '{print $6}' | sort -u > openldap.txt

And then do a "diff -u root.txt openldap.txt", you get the following extra
libraries listed in the version running as openldap.

/lib/libnss_ldap-2.3.6.so
/usr/lib/libgcrypt.so.11.2.1
/usr/lib/libgnutls.so.13.0.7
/usr/lib/libgpg-error.so.0.2.0
/usr/lib/liblber.so.2.0.130
/usr/lib/libldap_r.so.2.0.130
/usr/lib/libtasn1.so.3.0.5


Both the root and openldap versions include
/usr/lib/libssl.so.0.9.8
/usr/lib/libcrypto.so.0.9.8
/usr/lib/liblber-2.3.so.0.2.13
/usr/lib/libldap_r-2.3.so.0.2.13
(among many other libraries)

Here's the associated package for each of these files

Files linked to in both the root and openldap versions:
/usr/lib/libssl.so.0.9.8-> package libssl0.9.8
/usr/lib/libcrypto.so.0.9.8 -> package libssl0.9.8
/usr/lib/liblber-2.3.so.0.2.13  -> package libldap-2.3-0
/usr/lib/libldap_r-2.3.so.0.2.13-> package libldap-2.3-0

Files only linked to in the openldap version:
/lib/libnss_ldap-2.3.6.so   -> package libnss-ldap
/usr/lib/libgcrypt.so.11.2.1-> package libgcrypt11
/usr/lib/libgnutls.so.13.0.7-> package libgnutls13
/usr/lib/libgpg-error.so.0.2.0  -> package libgpg-error0
/usr/lib/liblber.so.2.0.130 -> package libldap2
/usr/lib/libldap_r.so.2.0.130   -> package libldap2
/usr/lib/libtasn1.so.3.0.5  -> package libtasn1-3


I remember reading somewhere that in Debian, libldap-2.3-0 currently links
against libssl0.9.8 and is only suppose to be used by slapd.  While
libldap2 links against libgnutls13 and is for use by all other ldap client
software.

I'm pretty sure libgnutls13 and the others got pulled in by libnss-ldap.

My system is using ldap for user accounts.  So when slapd is running as a
non-root user, I'm guessing that it looks up the UID/GID for "openldap" and
ends up pulling in libnss-ldap, libgnutls, etc (even though the "openldap"
user and group are in the passwd/shadow and group files).

Then there is probably some conflict between either
"libldap_r-2.3.so.0.2.13 and libldap_r.so.2.0.130" or
"libssl.so.0.9.8 and libgnutls.so.13.0.7"
that is causing the problems I've been experiencing.

This also explains why slapd worked correctly after a fresh reinstall of
that package, but failed on the next reboot.  To avoid system breakage
(like apt not working correctly, not being able to start new shells, etc),
I had to disable user lookup in ldap before I purged and reinstalled slapd.
 I then re-enabled it once slapd was back up.  So slapd didn't pull in
libnss-ldap when it started up - and everything worked fine until I rebooted.

I just confirmed this.  If I comment out all "ldap" entries in my
/etc/nsswitch.conf file and then restart slapd with user and group
"openldap", then "ldapsearch -x -ZZ" successfully returns everything that
it should.  And if I then uncomment, the "ldap" entries in nsswitch.conf
again, my system works - but slapd will have problems the next time it is
restarted with these settings.

So problem found - now it just needs to be either fixed or worked around.


slapd-maps-root.txt.gz
Description: application/gzip


slapd-maps-openldap.txt.gz
Description: application/gzip

Bug#382429: Additional info for #382429

[Berg, Michael]

The output of "smbd -d 10 -i" contains the following

==
...
lp_file_list_changed()
file /etc/samba/smb.conf -> /etc/samba/smb.conf  last mod_time: Wed Aug  9
21:35:55 2006

sys_gethostbyname: Unknown host. lo
can't determine netmask for lo
sys_gethostbyname: Unknown host. int0
can't determine netmask for int0
WARNING: no network interfaces found
Netbios name list:-
my_netbios_names[0]="SERVER"
loaded services
...
==

NOTE: "int0" is a standard Ethernet "eth0" or "eth1" that has been renamed
via udev (based on MAC) to avoid eth0 and eth1 naming ambiguity when one
module got loaded before the other.


ifconfig returns the following information for lo and int0:

int0  Link encap:Ethernet  HWaddr 00:14:85:35:F1:78
  inet addr:172.30.1.1  Bcast:172.30.1.255  Mask:255.255.255.0
  inet6 addr: 2001:5c0:82e4:1::1/64 Scope:Global
  inet6 addr: fe80::214:85ff:fe35:f178/64 Scope:Link
  UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
  RX packets:18589 errors:0 dropped:0 overruns:0 frame:0
  TX packets:25319 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:1000
  RX bytes:2024427 (1.9 MiB)  TX bytes:20873800 (19.9 MiB)
  Interrupt:217 Base address:0xc000

loLink encap:Local Loopback
  inet addr:127.0.0.1  Mask:255.0.0.0
  inet6 addr: ::1/128 Scope:Host
  UP LOOPBACK RUNNING  MTU:16436  Metric:1
  RX packets:778679 errors:0 dropped:0 overruns:0 frame:0
  TX packets:778679 errors:0 dropped:0 overruns:0 carrier:0
  collisions:0 txqueuelen:0
  RX bytes:179261083 (170.9 MiB)  TX bytes:179261083 (170.9 MiB)




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381788: [Pkg-openldap-devel] Re: Bug#381788: slapd: TLS connections fail when running as non-root

[Berg, Michael]

> ... what does the output from "slapd -d -1" show in the following bits:
> 
> (a) running as root, up until waiting for a connection
> (b) running as root, getting a problem connection
> (c) running as openldap user, up until waiting for a connection
> (d) running as openldap user, getting a problem connection

(a) and (b) are in the attached file slapd-root.txt
(c) and (d) are in the attached file slapd-openldap.txt
In both files I put some whitespace and a comment line to indicate where
slapd started waiting for a connection.

(a) and (b) output was generated and captured using (all on one line):
# /usr/sbin/slapd -h 'ldap://127.0.0.1/ ldaps://127.0.0.1/ ldap://[::1]/
ldaps://[::1]/ ldap://ldap.misumasu.dyndns.org/
ldaps://ldap.misumasu.dyndns.org/' -d 1 > /tmp/slapd-root.txt 2>&1

(c) and (d) output was generated and captured using (all on one line):
# /usr/sbin/slapd -h 'ldap://127.0.0.1/ ldaps://127.0.0.1/ ldap://[::1]/
ldaps://[::1]/ ldap://ldap.misumasu.dyndns.org/
ldaps://ldap.misumasu.dyndns.org/' -u openldap -g openldap -d 1 >
/tmp/slapd-openldap.txt 2>&1

Running "ldapsearch -x -ZZ" generated thousands of lines of output in the
root versioon, so to keep this tractable, I targeted the search command as
$ ldapsearch -x -ZZ '(sambaDomainName=MISUMASU)'
This command was run to trigger the (b) and (d) cases.


Running "diff -u slapd-root.txt slapd-openldap.txt" is interesting.
The interesting chunks before they completely diverge (root returning a
result vs. openldap returning an error) are:

--- slapd-root.txt  2006-08-09 18:52:49.0 -0600
+++ slapd-openldap.txt  2006-08-09 18:53:00.0 -0600
...
 >>> dnNormalize: 
 <<< dnNormalize: 
+ldap_create
+ldap_url_parse_ext(ldap://ldap.misumasu.dyndns.org/)
+ldap_create
+ldap_url_parse_ext(ldap://ldap.misumasu.dyndns.org/)
+ldap_extended_operation_s
+ldap_extended_operation
+ldap_send_initial_request
+ldap_new_connection 1 1 0
+ldap_int_open_connection
+ldap_connect_to_host: TCP ldap.misumasu.dyndns.org:389
+ldap_new_socket: 12
+ldap_prepare_socket: 12
+ldap_connect_to_host: Trying 172.30.1.1:389
+ldap_connect_timeout: fd: 12 tm: 30 async: 0
+ldap_ndelay_on: 12
+ldap_is_sock_ready: 12
+ldap_is_socket_ready: error on socket 12: errno: 111 (Connection refused)
+ldap_close_socket: 12
+ldap_unbind
 matching_rule_use_init
...
 TLS trace: SSL_accept:SSLv3 read client hello A
 TLS trace: SSL_accept:SSLv3 write server hello A
 TLS trace: SSL_accept:SSLv3 write certificate A
-TLS trace: SSL_accept:SSLv3 write server done A
+TLS trace: SSL_accept:SSLv3 write certificate request A
 TLS trace: SSL_accept:SSLv3 flush data
 TLS trace: SSL_accept:error in SSLv3 read client certificate A
 TLS trace: SSL_accept:error in SSLv3 read client certificate A
 connection_get(15): got connid=0
 connection_read(15): checking for input on id=0


So right before SSL fails, the root version "writes server done" while the
openldap version "writes certificate request".
@(#) $OpenLDAP: slapd 2.3.25 (Aug  4 2006 01:06:05) $
[EMAIL 
PROTECTED]:/build/buildd/openldap2.3-2.3.25/debian/build/servers/slapd
daemon_init: listen on ldap://127.0.0.1/
daemon_init: listen on ldaps://127.0.0.1/
daemon_init: listen on ldap://[::1]/
daemon_init: listen on ldaps://[::1]/
daemon_init: listen on ldap://ldap.misumasu.dyndns.org/
daemon_init: listen on ldaps://ldap.misumasu.dyndns.org/
daemon_init: 6 listeners to open...
ldap_url_parse_ext(ldap://127.0.0.1/)
daemon: listener initialized ldap://127.0.0.1/
ldap_url_parse_ext(ldaps://127.0.0.1/)
daemon: listener initialized ldaps://127.0.0.1/
ldap_url_parse_ext(ldap://[::1]/)
daemon: listener initialized ldap://[::1]/
ldap_url_parse_ext(ldaps://[::1]/)
daemon: listener initialized ldaps://[::1]/
ldap_url_parse_ext(ldap://ldap.misumasu.dyndns.org/)
daemon: listener initialized ldap://ldap.misumasu.dyndns.org/
ldap_url_parse_ext(ldaps://ldap.misumasu.dyndns.org/)
daemon: listener initialized ldaps://ldap.misumasu.dyndns.org/
daemon_init: 6 listeners opened
slapd init: initiated server.
slap_sasl_init: initialized!
bdb_back_initialize: initialize BDB backend
bdb_back_initialize: Sleepycat Software: Berkeley DB 4.2.52: (December  3, 2003)
bdb_db_init: Initializing BDB database
>>> dnPrettyNormal: 
<<< dnPrettyNormal: , 

>>> dnNormalize: <>
<<< dnNormalize: <>
>>> dnNormalize: 
<<< dnNormalize: 
matching_rule_use_init
1.2.840.113556.1.4.804 (integerBitOrMatch): matchingRuleUse: ( 
1.2.840.113556.1.4.804 NAME 'integerBitOrMatch' APPLIES ( supportedLDAPVersion 
$ uidNumber $ gidNumber $ olcConcurrency $ olcConnMaxPending $ 
olcConnMaxPendingAuth $ olcIdleTimeout $ olcIndexSubstrIfMinLen $ 
olcIndexSubstrIfMaxLen $ olcIndexSubstrAnyLen $ olcIndexSubstrAnyStep $ 
olcLocalSSF $ olcMaxDerefDepth $ olcReplicationInterval $ olcSockbufMaxIncoming 
$ olcSockbufMaxIncomingAuth $ olcThreads $ olcToolThreads $ 
mailPreferenceOption $ shadowLastChange $ shadowMin $ shadowMax $ shadowWarning 
$ shadowInactive $ shadowExpire $ shadowFlag $ ipServicePor

Bug#381788: [Pkg-openldap-devel] Re: Bug#381788: slapd: TLS connections fail when running as non-root

[Berg, Michael]

> Okay, hm.  Can you try this, preferably with daemontools:
> 
> /usr/bin/setuidgid openldap /bin/cat 
> 
> for every cert you believe the server should be able to read.  It really
> seems like the "openldap" user/group doesn't have permission to
> something that it should.

I don't have daemontools on this system, but I temporarily changed the
shell for the openldap user from /bin/false to /bin/bash and then su'd to
openldap.

$ id
uid=100(openldap) gid=121(openldap) groups=121(openldap)

Certificate Authority public cert was successful:
$ /bin/cat /etc/ssl/certs/misumasu.dyndns.org_CA.pem
-BEGIN CERTIFICATE-
...
-END CERTIFICATE-

LDAP server public cert was successful:
$ /bin/cat /etc/ssl/certs/ldap.misumasu.dyndns.org.pem
-BEGIN CERTIFICATE-
...
-END CERTIFICATE-

LDAP server private key cert was successful:
$ /bin/cat /etc/ldap/private/ldap.misumasu.dyndns.org.pem
-BEGIN RSA PRIVATE KEY-
...
-END RSA PRIVATE KEY-


The PID file and args files used by Debian were accessible
/var/run/slapd/slapd.pid
/var/run/slapd/slapd.args

And all the database files were accessible
$ ls -l /var/lib/ldap/
total 1852
-rw-r--r-- 1 openldap openldap  96 Aug  5 21:30 DB_CONFIG
-rw--- 1 openldap openldap8192 Aug  5 21:30 __db.001
-rw--- 1 openldap openldap 2629632 Aug  5 21:30 __db.002
-rw--- 1 openldap openldap   98304 Aug  5 21:30 __db.003
-rw--- 1 openldap openldap  868352 Aug  5 21:30 __db.004
-rw--- 1 openldap openldap   24576 Aug  5 21:30 __db.005
-rw-r--r-- 1 openldap openldap2048 Aug  8 22:40 alock
-rw--- 1 openldap openldap   16384 Aug  8 22:15 cn.bdb
-rw--- 1 openldap openldap   16384 Aug  5 23:55 displayName.bdb
-rw--- 1 openldap openldap   16384 Aug  8 22:40 dn2id.bdb
-rw--- 1 openldap openldap8192 Aug  8 22:39 gidNumber.bdb
-rw--- 1 openldap openldap   65536 Aug  8 22:40 id2entry.bdb
-rw--- 1 openldap openldap  817172 Aug  8 22:40 log.01
-rw--- 1 openldap openldap8192 Aug  8 22:39 memberUid.bdb
-rw--- 1 openldap openldap8192 Aug  8 22:39 objectClass.bdb
-rw--- 1 openldap openldap8192 Aug  8 22:39 sambaDomainName.bdb
-rw--- 1 openldap openldap8192 Aug  5 23:55 sambaPrimaryGroupSID.bdb
-rw--- 1 openldap openldap8192 Aug  8 22:39 sambaSID.bdb
-rw--- 1 openldap openldap8192 Aug  5 23:55 sn.bdb
-rw--- 1 openldap openldap8192 Aug  8 22:39 uid.bdb
-rw--- 1 openldap openldap8192 Aug  8 22:39 uidNumber.bdb




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381788: [Pkg-openldap-devel] Re: Bug#381788: slapd: TLS connections fail when running as non-root

[Berg, Michael]

> Does it work if you use "-h localhost" (similar to what you were doing
> with the openssl command)?
> 
> Generally, you must provide the fully qualified domain name to the "-h"
> parameter for SSL/TLS to work.
> 
> For example, "-h ldap" doesn't work for me, but "-h ldap.stanford.edu"
> does.

My FQDN is "server.misumasu.dyndns.org", which also has a CNAME of
"ldap.misumasu.dyndns.org" (this CNAME is what the SSL cert is issued to).

$ ldapsearch -h ldap.misumasu.dyndns.org -x -ZZ
$ ldapsearch -h ldap -x -ZZ
$ ldapsearch -h server.misumasu.dyndns.org -x -ZZ
$ ldapsearch -h server -x -ZZ
$ ldapsearch -h localhost.localdomain -x -ZZ
$ ldapsearch -h localhost -x -ZZ
$ ldapsearch -h 127.0.0.1 -x -ZZ

all produce the exact same error message when slapd is running as non-root).

And my /etc/ldap/ldap.conf file contains the line
"URI ldap://ldap.misumasu.dyndns.org";
so the default when running "ldapsearch -x -ZZ"
is equivalent to running
"ldapsearch -H 'ldap://ldap.misumasu.dyndns.org' -x -ZZ"


Just to be thorough,

$ openssl s_client -connect ldap.misumasu.dyndns.org:636
$ openssl s_client -connect ldap:636
$ openssl s_client -connect server.misumasu.dyndns.org:636
$ openssl s_client -connect server:636

also all fail with the same error messages when slapd is running as non-root.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381788: [Pkg-openldap-devel] Re: Bug#381788: slapd: TLS connections fail when running as non-root

[Berg, Michael]

> This error is coming straight from the OpenSSL libraries.
> Have you tried connecting with openssl s_client?

Yes.

I am running slapd listening on both ports 389 (using starttls) and port
636 (SSL only to support some software that doesn't support starttls).

As pointed out in my original bug report, I have run
"openssl s_client -connect 127.0.0.1:636"
to connect to the SSL only port.

When slapd is running as root, s_client successfully establishes a
connection.  When slapd is running as non-root, I get the error messages
==
25159:error:14094410:SSL routines:SSL3_READ_BYTES:sslv3 alert handshake
failure:s3_pkt.c:1057:SSL alert number 40
25159:error:140790E5:SSL routines:SSL23_WRITE:ssl handshake
failure:s23_lib.c:188:
==

The manual page for s_client says that the only supported keywords for the
"-starttls " option are currently "smtp" and "pop3", so I can't
use s_client to test ldap port 389+starttls.

But "ldapsearch -x -ZZ" (which is configured to use port 389+starttls)
gives the following error message when slapd is running as non-root
==
ldap_start_tls: Connect error (-11)
additional info: error:14094410:SSL routines:SSL3_READ_BYTES:sslv3
alert handshake failure
==
and the "error:14094410:SSL" is the same as the error returned by s_client
on the SSL only port.

Again, these errors only happen when slapd is running as non-root.
s_client to the SSL port and ldapsearch to port 389+starttls both work
perfectly when slapd is running as root.


> 
> 
> This link also notes someone hitting this issue in the past.

Same error messages, but somewhat different problem.
The link is someone trying to use client certificates and it not working.

I am *not* trying to use client certificates, and have
"TLSVerifyClient never" in my slapd.conf.

However, (based on the error messages) it seems that slapd is still
requiring a client certificate - and only when running as non-root for some
reason.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#381788: slapd: TLS connections fail when running as non-root

[Berg, Michael]

I spent some more time debugging, and here is some additional info.

I ran slapd with debugging again ('-d 7' to match the previous ldapsearch
debug output), and this time I spotted something that I must have missed
before.

In the interest of space, I removed the pages-upon-pages of output
generated from parsing the schema files.  The first line in the attached
debug output is when slapd is opening the Certificate Authority's public
cert.  I've also inserted some blank lines and comments (started with a #
character) into the debug output to show relevant events.

Toward the end, there are error messages about:
"TLS trace: SSL_accept:error in SSLv3 read client certificate A"
and
"TLS: error:140890C7:SSL routines:SSL3_GET_CLIENT_CERTIFICATE:peer did not
return a certificate s3_srvr.c:2455"

This supports the web searches that tied ldapsearch's error of
"error:14094410:SSL" to client certificates.  But as previously stated, I
have "TLSVerifyClient never" specified in my slapd.conf (maybe it's not
being respected when running as non-root though).

Anyway, I hope this helps in tracking down the problem.  As always, if
there is any additional info I can provide that would help, just let me know.

...
open("/etc/ssl/certs/misumasu.dyndns.org_CA.pem", O_RDONLY) = 12
fstat(12, {st_mode=S_IFREG|0644, st_size=1094, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2abf1855
read(12, "-BEGIN CERTIFICATE-\nMIIC"..., 4096) = 1094
read(12, "", 4096)  = 0
close(12)   = 0
munmap(0x2abf1855, 4096)= 0
open("/usr/lib/ssl/cert.pem", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/etc/ssl/certs/misumasu.dyndns.org_CA.pem", O_RDONLY) = 12
fstat(12, {st_mode=S_IFREG|0644, st_size=1094, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2abf1855
read(12, "-BEGIN CERTIFICATE-\nMIIC"..., 4096) = 1094
read(12, "", 4096)  = 0
close(12)   = 0
munmap(0x2abf1855, 4096)= 0
open("/etc/ldap/private/ldap.misumasu.dyndns.org.pem", O_RDONLY) = 12
fstat(12, {st_mode=S_IFREG|0640, st_size=887, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2abf1855
read(12, "-BEGIN RSA PRIVATE KEY-\n"..., 4096) = 887
close(12)   = 0
munmap(0x2abf1855, 4096)= 0
open("/etc/ssl/certs/ldap.misumasu.dyndns.org.pem", O_RDONLY) = 12
fstat(12, {st_mode=S_IFREG|0644, st_size=1131, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2abf1855
read(12, "-BEGIN CERTIFICATE-\nMIID"..., 4096) = 1131
close(12)   = 0
munmap(0x2abf1855, 4096)= 0
rt_sigaction(SIGUSR1, {0x41e850, [], SA_RESTORER|SA_RESTART, 0x2abf16f4f500}, 
{SIG_DFL}, 8) = 0
rt_sigaction(SIGUSR2, {0x41e870, [], SA_RESTORER|SA_RESTART, 0x2abf16f4f500}, 
{SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_DFL}, 8) = 0
rt_sigaction(SIGHUP, {0x41e870, [], SA_RESTORER|SA_RESTART, 0x2abf16f4f500}, 
{SIG_DFL}, 8) = 0
rt_sigaction(SIGINT, {0x41e870, [], SA_RESTORER|SA_RESTART, 0x2abf16f4f500}, 
{SIG_DFL}, 8) = 0
rt_sigaction(SIGTERM, {0x41e870, [], SA_RESTORER|SA_RESTART, 0x2abf16f4f500}, 
{SIG_DFL}, 8) = 0
rt_sigaction(SIGTRAP, {0x41e870, [], SA_RESTORER|SA_RESTART, 0x2abf16f4f500}, 
{SIG_DFL}, 8) = 0
rt_sigaction(SIGCHLD, {0x411530, [], SA_RESTORER|SA_RESTART, 0x2abf16f4f500}, 
{SIG_DFL}, 8) = 0
rt_sigaction(SIGPIPE, {SIG_IGN}, {SIG_IGN}, 8) = 0
open("/var/run/slapd/slapd.pid", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 12
fstat(12, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2abf1855
write(12, "24540\n", 6) = 6
close(12)   = 0
munmap(0x2abf1855, 4096)= 0
open("/var/run/slapd/slapd.args", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 12
fstat(12, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x2abf1855
write(12, "/usr/sbin/slapd -h ldap://127.0.";..., 182) = 182
close(12)   = 0
munmap(0x2abf1855, 4096)= 0
time([1155086433])  = 1155086433
write(2, "slapd startup: initiated.\n", 26slapd startup: initiated.
) = 26
write(2, "backend_startup_one: starting \"c"..., 42backend_startup_one: 
starting "cn=config"
) = 42
write(2, "config_back_db_open\n", 20config_back_db_open
)   = 20
write(2, "config_build_entry: \"cn=config\"\n", 32config_build_entry: 
"cn=config"
) = 32
write(2, "config_build_entry: \"cn=include{"..., 36config_build_entry: 
"cn=include{0}"
) = 36
write(2, "config_build_entry: \"cn=include{"..., 36config_build_entry: 
"cn=include{1}"
) = 36
write(2, "config_build_entry: \"cn=include{"..., 36config_build_entry: 
"cn=include{2}"
) = 36

Bug#381788: [Pkg-openldap-devel] Bug#381788: slapd: TLS connections fail when running as non-root

[Berg, Michael]

>> And just for completeness, here are the contents of my ldap.conf file
>> ==
>> BASE dc=mydomain,dc=dyndns,dc=org
>> URI  ldap://ldap.mydomain.dyndns.org
>> TLS_CIPHER_SUITE HIGH:!ADH
>> TLS_CACERT   /etc/ssl/certs/mydomain.dyndns.org_CA.pem
>> TLS_REQCERT  demand
>> TLS_CRLCHECK none
>> ==
>>
> This is the complete content of ldap.conf on the clients ?

Those are the only uncommented lines in my ldap.conf files.


>> I even tried purging slapd, reinstalling it, and re-populating it from 
>> scratch
>> (I didn't just reload a DB backup).
>>
>> The fresh install worked fine as non-root until a reboot - at which point the
>> problem described above returned and TLS connections fail.
>>
> That's strange.

I thought so too.


> Can you please send the output of: ldapsearch -x -ZZ -d 7

Output is attached.
ldap_create
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP ldap.misumasu.dyndns.org:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying 172.30.1.1:389
ldap_connect_timeout: fd: 3 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush: 31 bytes to sd 3
  :  30 1d 02 01 01 77 18 80  16 31 2e 33 2e 36 2e 31   0w...1.3.6.1  
  0010:  2e 34 2e 31 2e 31 34 36  36 2e 32 30 30 33 37  .4.1.1466.20037   
ldap_write: want=31, written=31
  :  30 1d 02 01 01 77 18 80  16 31 2e 33 2e 36 2e 31   0w...1.3.6.1  
  0010:  2e 34 2e 31 2e 31 34 36  36 2e 32 30 30 33 37  .4.1.1466.20037   
ldap_result ld 0x5101e0 msgid 1
ldap_chkResponseList ld 0x5101e0 msgid 1 all 1
ldap_chkResponseList returns ld 0x5101e0 NULL
wait4msg ld 0x5101e0 msgid 1 (infinite timeout)
wait4msg continue ld 0x5101e0 msgid 1 all 1
** ld 0x5101e0 Connections:
* host: ldap.misumasu.dyndns.org  port: 389  (default)
  refcnt: 2  status: Connected
  last used: Mon Aug  7 19:31:48 2006

** ld 0x5101e0 Outstanding Requests:
 * msgid 1,  origid 1, status InProgress
   outstanding referrals 0, parent count 0
** ld 0x5101e0 Response Queue:
   Empty
ldap_chkResponseList ld 0x5101e0 msgid 1 all 1
ldap_chkResponseList returns ld 0x5101e0 NULL
ldap_int_select
read1msg: ld 0x5101e0 msgid 1 all 1
ber_get_next
ldap_read: want=8, got=8
  :  30 0c 02 01 01 78 07 0a0x..  
ldap_read: want=6, got=6
  :  01 00 04 00 04 00  ..
ber_get_next: tag 0x30 len 12 contents:
read1msg: ld 0x5101e0 msgid 1 message type extended-result
ber_scanf fmt ({eaa) ber:
read1msg: ld 0x5101e0 0 new referrals
read1msg:  mark request completed, ld 0x5101e0 msgid 1
request done: ld 0x5101e0 msgid 1
res_errno: 0, res_error: <>, res_matched: <>
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 0 1
ldap_free_connection: refcnt 1
ldap_parse_extended_result
ber_scanf fmt ({eaa) ber:
ldap_parse_result
ber_scanf fmt ({iaa) ber:
ber_scanf fmt (}) ber:
ldap_msgfree
TLS trace: SSL_connect:before/connect initialization
tls_write: want=118, written=118
  :  80 74 01 03 01 00 4b 00  00 00 20 00 c0 19 00 c0   .tK... .  
  0010:  18 00 c0 17 00 c0 14 00  c0 13 00 c0 12 00 c0 0f     
  0020:  00 c0 0e 00 c0 0d 00 c0  0a 00 c0 09 00 c0 08 00     
  0030:  c0 05 00 c0 04 00 c0 03  00 00 39 00 00 38 00 00   ..9..8..  
  0040:  35 00 00 33 00 00 32 00  00 2f 00 00 16 00 00 13   5..3..2../..  
  0050:  00 00 0a 07 00 c0 8d 7f  9d 7d 45 b3 0c e1 2b 10   .}E...+.  
  0060:  27 1d 46 9c 0d d5 80 a2  04 56 de 71 e5 6b 1f 41   '.F..V.q.k.A  
  0070:  0b 2c 15 18 a8 86  .,
TLS trace: SSL_connect:SSLv2/v3 write client hello A
tls_read: want=7, got=7
  :  16 03 01 00 4a 02 00   J..   
tls_read: want=72, got=72
  :  00 46 03 01 44 d7 e9 84  26 c1 84 5c 39 64 71 f4   .F..D...&..\9dq.  
  0010:  da 78 00 9a 6d 68 6b be  33 b3 6f 8a 0c 93 4a 41   .x..mhk.3.o...JA  
  0020:  ca c0 53 c5 20 3c ab 22  1d 54 70 7b a0 e1 95 4e   ..S. <.".Tp{...N  
  0030:  3f 2d 1d 07 69 18 ac 14  8c 9d 94 0b 58 22 8c 18   ?-..i...X"..  
  0040:  13 59 66 85 d6 00 35 00.Yf...5.  
TLS trace: SSL_connect:SSLv3 read server hello A
tls_read: want=5, got=5
  :  16 03 01 06 28 ( 
tls_read: want=1576, got=1576
  :  0b 00 06 24 00 06 21 00  03 1b 30 82 03 17 30 82   ...$..!...0...0.  
  0010:  02 82 a0 03 02 01 02 02  01 02 30 0b 06 09 2a 86   ..0...*.  
  0020:  48 86 f7 0d 01 01 05 30  81 89 31 0b 30 09 06 03   H..0..1.0...  
  0030:  55 04 06 13 02 55 53 31  11 30 0f 06 03 55 04 0a   UUS1.0...U..  
  0040:  13 08 6d 69 73 75 6d 61  73 75 31 1e 30 1c 06 03   ..misumasu1.0...  
  0050:  55 04 0b 13 15 43 65 72  74 69 66 6

Bug#210926: Bug #210926 can be closed

[Berg, Michael]

Was checking on old bugs, and #210926 can probably be closed as between the
recent versions of selinux-utils and libselinux1-dev, there are now man
pages for the binaries in selinux-utils.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#302296: libnss-ldap 238-1 causes "login: pthread_mutex_lock.c:78" error

[Berg, Michael]

I had a little time to do some debugging tonight.  Here are the results.

I logged in as root on the console (with the functional libnss-ldap_220-1
installed), upgraded to libnss-ldap_238-1 (which I'm having problems with),
and then started a new login process inside gdb.

When root attempts to log in through the debugged login process, here are
the results:

...(snip)...

login: pthread_mutex_lock.c:78: __pthread_mutex_lock: Assertion
`mutex->__data.__owner == 0' failed.
---Type  to continue, or q  to quit---

(I hit  to continue)

Program received signal SIGABRT, Aborted.
[Switching to Thread -1208270176 (LWP 8911)]
0xe410 in __kernel_vsyscall ()



I then ran a stack backtrace and obtained the following:

#0  0xe410 in __kernel_vsyscall ()
#1  0x41041805 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0x41042f82 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0x4103b2a8 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0x411799fc in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0
#5  0x410fcaef in pthread_mutex_lock () from /lib/tls/i686/cmov/libc.so.6
#6  0xb7dfdca1 in ldap_start_tls_s () from /usr/lib/libldap.so.2
#7  0x41daed03 in gcry_sexp_canon_len () from /usr/lib/libgcrypt.so.11
#8  0x41daee41 in gcry_sexp_canon_len () from /usr/lib/libgcrypt.so.11
#9  0x41dbbb3e in gcry_randomize () from /usr/lib/libgcrypt.so.11
#10 0x41db76b5 in gcry_md_algo_name () from /usr/lib/libgcrypt.so.11
#11 0x41db77b2 in gcry_md_open () from /usr/lib/libgcrypt.so.11
#12 0x41c4cffc in _gnutls_hash_init () from /usr/lib/libgnutls.so.11
#13 0x41c467f1 in gnutls_handshake () from /usr/lib/libgnutls.so.11
#14 0xb7c5dcb5 in gnutls_SSL_free () from /usr/lib/libldap_r.so.2
#15 0xb7c5ddda in gnutls_SSL_connect () from /usr/lib/libldap_r.so.2
#16 0xb7c5b68e in ldap_pvt_tls_init_def_ctx () from /usr/lib/libldap_r.so.2
#17 0xb7c5c696 in ldap_int_tls_start () from /usr/lib/libldap_r.so.2
#18 0xb7c5cb18 in ldap_start_tls_s () from /usr/lib/libldap_r.so.2
#19 0xb7c6962e in ?? () from /lib/libnss_ldap.so.2
#20 0x080a0218 in ?? ()
...(a whole lot of "?? ()" entries like #20 followed)...



Hopefully this will help in tracking down the problem.  If there are any
additional tests or debugger output you would like, let me know.


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#302296: libnss-ldap 238-1 causes "login: pthread_mutex_lock.c:78" error

[Berg, Michael]

> Are you using libpam-ldap too?

Yes, I'm using libpam-ldap too.  Both packages were upgraded at the same
time.  I tried all four combinations of previous and new versions of both
packages.  The problems occurred in both cases where the new libnss-ldap
was installed and didn't occur in either case with the old libnss-ldap
installed.

> Does gdm log anything interesting about why it's
> failing, or is it failing when logging in as root?

When the new libnss-ldap is installed, gdm fails (regardless of who is
attempting to log in).  There does not appear to be anything interesting in
the gdm logs.  The logs when users can't log in are identical to when users
could previously log in.  I haven't tried running gdm through a debugger
yet, but I think gdm might be crashing as it momentarily dumps me back to a
console and then the gdm login screen restarts.

Similarly, there are not entries in /var/log/auth.log or /var/log/syslog
when root tried to log in on the console.

> Basically, are you sure the gdm issue is the same as the root login on 
> console issue?

I'm not absolutely sure, but both problems start when I install the new
libnss-ldap and both problems go away when I revert to the old version.
It is possible that there are different bugs in both login and gdm, but if
that is the case, the new libnss-ldap is at least a common trigger.

> What does your /etc/nsswitch.conf look like?


passwd: files ldap
group:  files ldap
shadow: files ldap

hosts:  files dns dns6
networks:   files

protocols:  db files
services:   db files
ethers: db files
rpc:db files

netgroup:   nis


> What about your /etc/libnss-ldap.conf?

I've stripped all comment lines to conserve space and sanitized internal
"ou" strings to "example.com"

host ldap.example.com
base dc=example,dc=com

ldap_version 3
pam_password clear

nss_base_passwd ou=Users,dc=example,dc=com?one
nss_base_shadow ou=Users,dc=example,dc=com?one
nss_base_group  ou=Groups,dc=example,dc=com?one

ssl start_tls
tls_checkpeer yes
tls_cacertfile /etc/ssl/certs/example.com_CA.pem
tls_ciphers HIGH:!ADH


> What specific version of glibc, what kernel are
> you using, do you know if NPTL is enabled or not?

glibc = libc6 and libc6-i686 from debian unstable (both at version
2.3.2.ds1-20).  For the benefit of anyone at PADL not familiar with debian,
the libc6-i686 package redirects linking to i686 optimized versions of the
C libraries while utilizing all the manual pages, timezone info, and other
common files from the libc6 package.

kernel = 2.6.11.6 from kernel.org, compiled for an AMD-XP (K7)

NPTL is enabled (on by default with a 586 or higher optimized libc6 on a
2.6.x kernel)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]

Bug#296062: Bug has been fixed in 0.8.7-2

[Berg, Michael]

This bug appears to have been fixed in smbldap-tools_0.8.7-2 and can be closed.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]