package vsftpd 2.2.2-3ubuntu6 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

This bug was fixed in the package vsftpd - 2.3.0~pre2-4ubuntu2

---------------
vsftpd (2.3.0~pre2-4ubuntu2) maverick; urgency=low

  * debian/vsftpd.postinst: Check that the group exists first, then
    the user, then try adding the user to the group, LP: #629234
 -- Dustin Kirkland <email address hidden> Fri, 03 Sep 2010 08:32:27 -0600

Patch attached.

ACK from SRU team.

Accepted vsftpd into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

Verification for Lucid:
The version of vsftpd 2.2.2-3ubuntu7.1 in -proposed doesn't completely fix the issue. If a user whose name starts with ftp exists then the installation still fails.

To reproduce:
$ adduser ftpuser
$ apt-get install vsftpd

Using getent passwd ${_USERNAME} and getent group ${_USERNAME} instead of using grep should do the trick.

Marking as verification-failed.

btw, the same problem still exists in maverick.

Attached two patches for Maverick and Lucid. Do these look alright?

And for Lucid...

Subscribing ubuntu-sponsors.

This was fixed in Natty but a little bit differently, see bug #656415 . Should the fix be taken from there and SRU'd back to Maverick and Lucid or is the above patch sufficient (or maybe even better) ?

In Natty there is this for checking if the user/group exists:

if ! getent passwd | grep -q "^${_USERNAME}:"
if ! getent group | grep -q "^${_USERNAME}:"

And in this bugreport the fix being suggested in comment #6 is using getent to find the entry, without using grep. If nothing else, it feels cleaner:

if ! getent passwd ${_USERNAME} >/dev/null 2>&1
if ! getent group ${_USERNAME} >/dev/null 2>&1

Imre, I like the single call to getent better than the grep as well. There is an added benefit, which is that this key is taken literally, while passing it to grep may actually cause false positives by parsing as a regular expression. For instance, if you have a user

ftpuser

and you input

ftp.ser

As the user during configuration of vsftpd, it will match the . against the u and NOT create the user.

Should this then be corrected in Natty also and then it can be SRU'd ?

Imre,
  You're right. What we really should do is
a.) open a new bug against vsftp in natty regarding the issue mentioned in comment 12.
b.) forward that bug to debian, with appropriate patch against debian

Then, we should apply that patch here.
We could then close this bug and request that one be SRU'd to hardy. I would think , though, it would be sufficient to simply fix hardy correctly under this bug.

I opened debian bug 607129.
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=607129

You could potentially work around the regex misinterpretation issue by using some more complex combinations of grep and awk and so forth, but there's a better reason to not use getent | grep.

If /etc/nsswitch.conf is configured with a user or group database that doesn't support enumerating users (Hesiod, for instance, and probably LDAP under bad configurations), then the test will return false *negatives* and then try to create a user that already exists.

The debian bug is reported fixed in 2.3.2-7.

The patch in comment 9 seems to be a bit different from the one that was sent to Debian, also does it remove a few changelog entries. Can somebody please have a look at it?

Failed SRU, been in -proposed for > 100 days, I removed the proposed package.

Since this failed SRU and interested parties have not commented on this bug for several weeks, is there still an intent to SRU this for lucid? If not, please adjust to "Won't Fix". Thanks!

Unsubscribing ubuntu-sponsors for now. Please resubscribe if an acceptable SRU patch is submitted.

There are two conflicting vsftpd uploads in the lucid-proposed queue:

 vsftpd (2.2.2-3ubuntu6.1) lucid-proposed; urgency=low
 .
   * debian/vsftpd.postinst: (LP: #709194)
     - Update conditional to fix upgrade issue when user exists, but group does not

 vsftpd (2.2.2-3ubuntu6.1) lucid-proposed; urgency=low
 .
   [ Andres Rodriguez ]
   * debian/vsftpd.upstart:
     - Fix typo. Thanks to JÃŒrgen Kreileder (LP: #577165)
     - Fix start of vsftpd even if not in standalone mode. Thanks to
       Stephane Chazelas (LP: #648202)
 .
   [ Dustin Kirkland, Serge Hallyn ]
   * debian/vsftpd.postinst: Check that the group exists first, then the user,
     then try adding the user to the group. (LP: #629234, LP: #677764)

I rejected them both. Please reupload a merged version. Thanks!

Hi Martin,

I've marked bug #709194 as duplicate of this bug given that this bug bus reported earlier. Another reason for my decision is that the patch proposed is *not* the same fix that currently exists in natty. In turn the fix I'm proposing is indeed the same fix.

Could you please re-upload the proposed branch/lucid SRU linked to this bug report?

Thank you again!

Re-uploading Andres branch based on the previous comment.

APPROVED: the package version 2.2.2-3ubuntu6.2 uploaded to lucid-proposed should be accepted.

Accepted vsftpd into lucid-proposed, the package will build now and be available in a few hours. Please test and give feedback here. See https://wiki.ubuntu.com/Testing/EnableProposed for documentation how to enable and use -proposed. Thank you in advance!

I think this bug was corrected by the fix for bug #677764 . If that's the case, the package from -proposed is working (see comment #20 from that bugreport).

This bug was fixed in the package vsftpd - 2.2.2-3ubuntu6.2

---------------
vsftpd (2.2.2-3ubuntu6.2) lucid-proposed; urgency=low

  * debian/vsftpd.upstart:
    - Fix typo. Thanks to Jürgen Kreileder (LP: #577165)
    - Fix start of vsftpd even if not in standalone mode. Thanks to
      Stephane Chazelas (LP: #648202)

  [ Dustin Kirkland, Serge Hallyn ]
  * debian/vsftpd.postinst: Check that the group exists first, then the user,
    then try adding the user to the group. (LP: #629234, LP: #677764)
 -- Andres Rodriguez <email address hidden> Wed, 13 Apr 2011 18:34:25 -0400