reassign 557004 clock-setup thanks On Wed, Nov 18, 2009 at 10:51:05PM +0100, Sebastian Andrzej Siewior wrote: > A quote from the shadow man page: > | date of last password change > | The date of the last password change, expressed as the number of > | days since Jan 1, 1970. > | > | The value 0 has a special meaning, which is that the user should > | change her pasword the next time she will log in the system. > | > | An empty field means that password aging features are disabled.
> Now: If the system clock isn't set (no or broken rtc) than this field > becomes 0. As you point out later, it's not *just* lack of a usable RTC that causes this problem. You must both be missing an RTC *and* fail to have the time set from the network. > If you choose category desktop in tasksel / D-I than this will fail > later: > |Jan 1 00:38:20 in-target: Setting up avahi-daemon (0.6.23-3lenny1) ... > |Jan 1 00:38:21 groupadd[22520]: new group: name=avahi, GID=109 > |Jan 1 00:38:21 useradd[22524]: new user: name=avahi, UID=104, GID=109, > home=/var/run/avahi-daemon, shell=/bin/false > |Jan 1 00:38:21 usermod[22529]: change user `avahi' password > |Jan 1 00:38:21 chage[22534]: changed password expiry for avahi > |Jan 1 00:38:21 chfn[22537]: pam_unix(chfn:account): expired password for > user root (root enforced) > |Jan 1 00:38:21 in-target: You are required to change your password > immediately (root enforced) > |Jan 1 00:38:21 in-target: chfn: PAM authentication failed > |Jan 1 00:38:21 in-target: adduser: `/usr/bin/chfn -f Avahi mDNS daemon > avahi' returned error code 1. Exiting. > |Jan 1 00:38:21 in-target: dpkg: error processing avahi-daemon (--configure): > |Jan 1 00:38:21 in-target: subprocess post-installation script returned > error exit status 1 > Most packages will be configured properly. Usually this is not a > problem in d-i because clock-setup will update the clock. However if > there is no network available than this will not be done. > My current work around for this rare case is to avoid this check in pam > if we are on day zero. Maybe clock-setup could ask for current time if > we are in the past? Yes, I think this is a clock-setup issue, not a PAM issue. As you point out, pam_unix here is handling the "last password change" field in the only reasonable way, according to the shadow package's documentation of the field: if the date is set to Jan 1, 1970 (or earlier), pam_unix writes a 0 for the field; when reading a 0 from the field, it treats it as an expired password that must be changed immediately. The only suitable fix is to make sure we have a correct system clock setting before pam_unix is invoked. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
