package openstack-dashboard-ubuntu-theme 2:9.0.0-0ubuntu2 failed to install/upgrade: subprocess installed post-installation script returned error exit status 1

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

Has a workaround been identified for this?

I was able to work around this. May be relative to running on the same host as keystone.

Running "service apache2 status" showed a port conflict and unable to bind on port 5000. I stopped keystone and verified the port was no longer in use, the started apache, reinstalled horizon, then started keystone again. Multiple checks of apache2 status along the way looked OK and after all of that was complete I was able to verify functionality.

Hi Sean, I'm still unable to reproduced this after installing keystone followed by openstack-dashboard. Do you happen to be running keystone API under apache2 with mod_wsgi? I know the xenial package doesn't do that by default, however in yakkety we're moving to do that by default.

Another work-around, and more realistic for production OpenStack deployments, is to not co-locate services. You can still do this on a single machine with kvm, lxc, lxd, etc to isolate services.

I was able to recreate this with the following steps:

1) apt install apache2 libapache2-mod-wsgi
2) systemctl stop apache2
3) apt install openstack-dashboard

The postinst scripts perform a reload of apache2 config files, and this will fail as the bug describes if apache2 is not running.

I think the postinst scripts could be smarter and handle the situation where apache2 is not already running. apache2 reload should be preferred vs apache2 restart to avoid interruption, but if apache2 isn't already running we should attempt to start it.

Looking into this some more, the maintainer scripts are following the Debian guidance for enabling config for Apache 2.4. For example, in openstack-dashboard.postinst we have:

if [ -e /usr/share/apache2/apache2-maintscript-helper ] ; then
  # apache 2.4
  . /usr/share/apache2/apache2-maintscript-helper
  apache2_invoke enconf $CONF || exit $?
elif ...

which follows the guidance from: https://wiki.debian.org/Apache/PackagingFor24

This is intended to exit if the package's apache config can't be enabled when the package is installed, which is the case when apache2 is not running at package install time.

So we are doing the right thing to exit if config can't be enabled. However I wonder if we could help alleviate this bug by attempting to start apache2 if it's not already started. I'll consult with some fellow package maintainers and see what they think.