Bug#655515: Bug in ntp.postinst

[Gerald Turner]

Hello, I dist-upgraded from squeeze to testing and had the exact problem
described by Martin Eichenberg, however the suggestions provided by
Michael Stapelberg didn't help.

I believe I have found the problem:

# dpkg --configure --pending --debug=2
Setting up ntp (1:4.2.6.p5+dfsg-2) ...
D000002: fork/exec /var/lib/dpkg/info/ntp.postinst ( configure 1:4.2.6.p2+dfsg-1+b1 )
dpkg: error processing ntp (--configure):
subprocess installed post-installation script returned error exit status 1
Errors were encountered while processing:
ntp

# sh -x /var/lib/dpkg/info/ntp.postinst configure 1:4.2.6.p2+dfsg-1+b1
+ set -e
+ dpkg-maintscript-helper supports rm_conffile
dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing
dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing
+ dpkg-maintscript-helper supports mv_conffile
dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_NAME missing
dpkg-maintscript-helper: warning: environment variable DPKG_MAINTSCRIPT_PACKAGE missing
+ [ configure = configure ]
+ addgroup --system --quiet ntp

# man addgroup
…
EXIT VALUES
…
1 Creating the user or group failed because it was already present
with other UID/GID than specified. The username or groupname was
rejected because of a mismatch with the configured regular
expressions, see adduser.conf(5). Adduser has been aborted by a
signal. Or for many other yet undocumented reasons which are
printed to console then. You may then consider to remove --quiet to
make adduser more verbose.
…

I hacked around the problem by appending ‘|| true’ expressions to the
postinst addgroup/adduser commands.

After poking around other postinst scripts looking for addgroup/user
usage, I see a better way would probably be something like the bind9
package:

getent group bind >/dev/null 2>&1 || addgroup --system bind
getent passwd bind >/dev/null 2>&1 ||
adduser --system --home /var/cache/bind --no-create-home \
--disabled-password --ingroup bind bind

--
Gerald Turner Email: gtu...@unzane.com JID: gtu...@unzane.com
GPG: 0xFA8CD6D5 21D9 B2E8 7FE7 F19E 5F7D 4D0C 3FA0 810F FA8C D6D5

[Kurt Roeckx]

On Thu, Apr 18, 2013 at 01:26:43PM -0700, Gerald Turner wrote:
> + addgroup --system --quiet ntp
>
> # man addgroup

> ...
> EXIT VALUES
> ...

> 1 Creating the user or group failed because it was already present
> with other UID/GID than specified. The username or groupname was
> rejected because of a mismatch with the configured regular
> expressions, see adduser.conf(5). Adduser has been aborted by a
> signal. Or for many other yet undocumented reasons which are
> printed to console then. You may then consider to remove --quiet to
> make adduser more verbose.

> ...

>
> I hacked around the problem by appending '|| true' expressions to the
> postinst addgroup/adduser commands.

Since we don't say which gid to use, that can't be a reason to
fail. It also never failed here ...

Maybe it's not a system group for you? What does "getent group ntp"
return?

Can you run it without the --quiet option?


Kurt


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

[Gerald Turner]

Kurt Roeckx <ku...@roeckx.be> writes:
> On Thu, Apr 18, 2013 at 01:26:43PM -0700, Gerald Turner wrote:
>> I hacked around the problem by appending '|| true' expressions to the
>> postinst addgroup/adduser commands.
>
> Since we don't say which gid to use, that can't be a reason to fail.
> It also never failed here ...
>
> Maybe it's not a system group for you? What does "getent group ntp"
> return?

# getent group ntp
ntp:x:107:

> Can you run it without the --quiet option?

# addgroup --system ntp ; echo $?
addgroup: The group `ntp' already exists and is not a system group. Exiting.
1

Hmmm...

# grep '^FIRST_SYSTEM' /etc/adduser.conf
FIRST_SYSTEM_UID=123
FIRST_SYSTEM_GID=123

Sorry I forgot about that, a few years ago I was juggling a bunch of Xen
guests, trying to keep system passwd and group entries in sync for a
handful of common daemons and manually bumping adduser.conf.

Perhaps I need to restore those to 100 in order to avoid this type of
"bug" with other postinst scripts.