package 389-admin 1.1.43-1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

[Emilio]

package 389-admin 1.1.43-1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

ProblemType: Package
DistroRelease: Ubuntu 16.10
Package: 389-admin 1.1.43-1
ProcVersionSignature: Ubuntu 4.8.0-32.34-generic 4.8.11
Uname: Linux 4.8.0-32-generic x86_64
ApportVersion: 2.20.3-0ubuntu8.2
AptOrdering:
 libpam-cgfs:amd64: Install
 NULL: ConfigurePending
Architecture: amd64
Date: Sun Dec 25 03:21:17 2016
ErrorMessage: subprocess installed post-installation script returned error exit status 1
InstallationDate: Installed on 2016-11-26 (28 days ago)
InstallationMedia: Ubuntu 16.10 "Yakkety Yak" - Release amd64 (20161012.2)
RelatedPackageVersions:
 dpkg 1.18.10ubuntu1
 apt 1.3.3
SourcePackage: 389-admin
Title: package 389-admin 1.1.43-1 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1
UpgradeStatus: No upgrade log present (probably fresh install)

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Boris Kheyfets (kheyfboris)]

Same on Zesty. Installing 389-admin on a clean install doesn't work.

[Tilman Baumann (tilmanbaumann)]

I can confirm this bug on Zesty.

As far as I understand the situation, the following is the case.

The package leases the service in a un-configured state. There is no /etc/dirsrv/admin-serv/adm.conf and /var/log/dirsrv/admin-serv/ does not exist.
This is why the service doesn't start. The service is started by automatic dh_helpers code, and that is why the package doesn't install.

389-admin.postinst
#!/bin/sh
set -e
# Automatically added by dh_systemd_enable
if deb-systemd-helper debian-installed dirsrv-admin.service; then
        # This will only remove masks created by d-s-h on package removal.
        deb-systemd-helper unmask dirsrv-admin.service >/dev/null || true

        if deb-systemd-helper --quiet was-enabled dirsrv-admin.service; then
                # Create new symlinks, if any.
                deb-systemd-helper enable dirsrv-admin.service >/dev/null || true
        fi
fi

Removing that automated code is one way. Let the user enable the service once he has been set it up correctly. setup-ds-admin is as far as I know the command to use for creating this config.

However, that is not expected behaviour in debian. The 'correct' fix would be to pre-configure the service in a way that allows it to start sucesfully. I don't know this software enough to make a judgment if that is feasible.

[Timo Aaltonen (tjaalton)]

auto-configuring it is not possible because it needs a dirsrv instance around in order to work

the fix is to use an error-handler for postinst like for 389-ds-base, then it would still fail to start the service of course but that would not fail the install

[Tilman Baumann (tilmanbaumann)]

This wasn't exactly the section of postinst that was causing the issue.

I have a workaround for it in debian/rules:
override_dh_installinit: dh_installinit --name dirsrv-admin -- defaults 15 85
vs
override_dh_installinit: dh_installinit --name dirsrv-admin --no-start -- defaults 15 85

And a PPA that contains this exact workaround.
https://launchpad.net/~tilmanbaumann/+archive/ubuntu/389-admin-fix-1652476/

If actually setting up the service at install time is not the plan, then this would I guess be the ticket.
There is a adm.conf in the debian directory. But it doesn't seem to be used. Incomplete implementation?

[Timo Aaltonen (tjaalton)]

--no-start would leave it stopped on upgrade

adm.conf example is indeed useless, I'll purge it..

[Launchpad Janitor (janitor)]

This bug was fixed in the package 389-admin - 1.1.46-2

---------------
389-admin (1.1.46-2) unstable; urgency=medium

  * Don't bump compat to 10, breaks the order of autoreconf and applying
    patches.

 -- Timo Aaltonen <email address hidden> Sat, 07 Oct 2017 08:04:20 +0300