FW: libpam-ldap upgrade breaks pam_ldap.conf and can't login

2007-02-21 Thread Jamie ffolliott
Package: libpam-ldap
Version: 180-1.6

3rd report - can we please get an acknowledgement from somebody?

The package is still broken in how it handles existing settings upon
upgrades, and these settings are critical to authentication working.

-Original Message-
From: Jamie ffolliott [mailto:[EMAIL PROTECTED] 
Sent: Monday, February 05, 2007 11:00 PM
To: 'debian-release@lists.debian.org'
Cc: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]'
Subject: FW: libpam-ldap upgrade breaks pam_ldap.conf and can't login

Package: libpam-ldap
Version: 180-1.5

I've sent the following email and did not receive a response from the
libpam-ldap maintainer.  I've upgraded another sarge box since and confirmed
the bug still exists. This is a serious problem for upgrades from sarge, or
any package update, so please fix it before release.

-Original Message-
From: Jamie ffolliott [mailto:[EMAIL PROTECTED]
Sent: Saturday, January 20, 2007 5:59 PM
To: '[EMAIL PROTECTED]'
Subject: libpam-ldap upgrade breaks pam_ldap.conf and can't login

Package: libpam-ldap
Version: 180-1.4

After an apt-get upgrade, the libpam-ldap packate updated, and in doing so
it rewrote parts of the /etc/pam_ldap.conf file as follows
- rewrote host, base, ldap_version, pam_password
- commented out the uri setting, which is an alternative setting to host
that supports ldap over ssl.

Since I don't use unencrypted logins to my ldap server, and I'm not sure who
would do such a thing, I cannot use the host setting.  The latter step that
comments out uri in fact breaks authentication to this machine.

I've tried dpkg-reconfigure libpam-ldap and there's no option to preserve my
URI setting, which must be set to ldaps://ldap.mydomain.com for logins to
succeed.

Even if I leave host blank, it will still disable the uri setting - and
this is the heart of the issue, I can't avoid breaking the existing
libpam-ldap config.

Luckily I have ssh's pub key authentication setup, so I can get in to fix,
but without that this debian client would be rendered useless upon upgrade
from sarge to etch.

Please consider this critical, I don't want all my servers to be rendered
inaccessible after upgrading to etch which I hope to do upon release.  It
locks out access to the box completely.

Thx!


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



libnss-ldap update breaks authentication

2007-02-21 Thread Jamie ffolliott
package: libnss-ldap
version: 251-7.2
 
Also refering to libpam-ldap_180-1.6
 
Hi Stephen,
 
I just updated in debian testing today, on a system using pam-ldap for
authentication, and now I've got new issues that broke authentiation for
this server.  It seems debian has saved certain configurations and
overwritten one or both of these settings:
1) /etc/libnss-ldap.conf : rootbinddn
2) the password in etc/libnss-ldap.secret
This breaks the authentication credentials when libnss tries to bind to the
slapd server.  Certainly the debian package cannot assume during an upgrade
that the password or bind DN is still the same as the original install, and
should instead leave current settings alone on an upgrade unless it prompts
me for the current settings or warns me it will change them.
 
The libpam-ldap update has also overwritten the uri setting in
/etc/pam_ldap.conf, and enabled the host setting (which is not compatible
with uri).  This breaks connectivity to the slapd server.  I should at least
have an option of using host or uri, and at least be prompted before you
update the conf file on an upgrade.
 
None of what you are doing is apparent on an apt-get update/upgrade.  There
was no prompt whatsoever that you were about to break access to my system.
Even most packages I've used in the last 7-8 years on debian do not
overwrite critical settings on an upgrade unless they warn me it's
happening.
 
I consider these very serious issues.  If it were not for debian testing,
there would be no excuse to defend use of debian in a live environment,
however this is a very late stage before release and you should be aware of
these obvious sorts of problems.  I've emailed you about the uri problem
twice in the last two months.  What gives?
 
Jamie
 


FW: libpam-ldap upgrade breaks pam_ldap.conf and can't login

2007-02-05 Thread Jamie ffolliott
Package: libpam-ldap
Version: 180-1.5

I've sent the following email and did not receive a response from the
libpam-ldap maintainer.  I've upgraded another sarge box since and confirmed
the bug still exists. This is a serious problem for upgrades from sarge, or
any package update, so please fix it before release.

-Original Message-
From: Jamie ffolliott [mailto:[EMAIL PROTECTED] 
Sent: Saturday, January 20, 2007 5:59 PM
To: '[EMAIL PROTECTED]'
Subject: libpam-ldap upgrade breaks pam_ldap.conf and can't login

Package: libpam-ldap
Version: 180-1.4

After an apt-get upgrade, the libpam-ldap packate updated, and in doing so
it rewrote parts of the /etc/pam_ldap.conf file as follows
- rewrote host, base, ldap_version, pam_password
- commented out the uri setting, which is an alternative setting to host
that supports ldap over ssl.

Since I don't use unencrypted logins to my ldap server, and I'm not sure who
would do such a thing, I cannot use the host setting.  The latter step that
comments out uri in fact breaks authentication to this machine.

I've tried dpkg-reconfigure libpam-ldap and there's no option to preserve my
URI setting, which must be set to ldaps://ldap.mydomain.com for logins to
succeed.

Even if I leave host blank, it will still disable the uri setting - and
this is the heart of the issue, I can't avoid breaking the existing
libpam-ldap config.

Luckily I have ssh's pub key authentication setup, so I can get in to fix,
but without that this debian client would be rendered useless upon upgrade
from sarge to etch.

Please consider this critical, I don't want all my servers to be rendered
inaccessible after upgrading to etch which I hope to do upon release.  It
locks out access to the box completely.

Thx!


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