Recieving error requiring an additional package 'pbis-open-update'

[dionysius]

Hi

Ubuntu 14.04, x64, puppet from repo, puppet-pbis using latest git. Though its not a clean install, there was likewise-open installed before it got removed from the official repos (https://bugs.launchpad.net/ubuntu/+source/likewise-open/+bug/1295031)

I am recieving following error on my laptop:

"dpkg: dependency problems prevent configuration of pbis-open:
pbis-open depends on pbis-open-upgrade; however:
Package pbis-open-upgrade is not installed."

I think, this will not happen, when it was a clean install of the os. But want to add, that i left the domain, removed the package and its config files in /etc before trying to install - I think the registry files still are anywhere.

I invite you to discuss the implementation of this case. An idea: Change package to a array (so we can define multiple packages) and allow overriding it - though we might maybe expect an issue that these packages are referencing each other and by default puppet can install them only one at a time (as far i know).

[benwebber]

Thanks for identifying this problem. I suspect other Trusty users will experience the same issue.

You're right about passing in the package list as an array: Puppet will not do any dependency management in that case.

A hacky and decidedly anti-Puppet solution would be to include an upgrade parameter.

if $upgrade {
  package { 'pbis-open-upgrade':
    ensure => installed,
  }
  package { 'pbis-open':
    ensure  => installed,
    require => Package['pbis-open-upgrade'],
  }
}

We could handle this better if we can establish why pbis-open wants to install pbis-open-upgrade (i.e., if it is detecting specific files leftover on the system).

We'll need to spin up a few Ubuntu VMs for testing. To establish test parameters, could you answer the following questions?

1. Did you upgrade this Ubuntu 14.04 machine from a previous version? If so, which version?
2. Which version of likewise-open was installed before you removed it?
3. Did you use Puppet's built-in fileserver, or add the pbis-open packages to a local APT repo?

[dionysius]

Thank you for your time.

1. Unfortunately I dont know exactly, that laptop was setup by a friend. I expect that it was a 14.04 beta.
2. It was a likewise-open v6.1 package - the last available from ubuntu repositories (see https://bugs.launchpad.net/ubuntu/+source/likewise-open/+bug/1295031)
3. I used puppets build-in fileserver

As a little clarify my class override

        class { 'pbis':
                ad_domain => 'DIRECTORY.XXXXXXXXXX.XX',
                bind_username => 'domainjoin',
                bind_password => 'XXXXXXXX',
                user_domain_prefix => 'DIRECTORY',
                home_dir_template => '%H/%U',
                login_shell_template => '/bin/zsh',
                service_name => 'lwsmd'
        }

Additionally, I'll have today time to pin down the circumstances about when it needes which packages. I'll add results later here.

[dionysius]

So, fresh Ubuntu Server 14.04 minimal install. Downloaded pbis v8.0.1.2029_amd64.

# dpkg -i pbis-open_8.0.1.2029_amd64.deb 
...
dpkg: dependency problems prevent configuration of pbis-open:
  pbis-open depends on pbis-open-upgrade; however:
    Package pbis-open-upgrade is not installed.
...

So lets try to install only pbis-open-upgrade

# dpkg -i pbis-open-upgrade_8.0.1.2029_amd64.deb 
...
Setting up pbis-open-upgrade (8.0.1.2029) ...

So at least we found out that pbis-open-upgrade can be installed before pbis-open. When I install pbis-open now, its successful

dpkg -i pbis-open_8.0.1.2029_amd64.deb 
...
Setting up pbis-open (8.0.1.2029) ...
Importing registry...

[dionysius]

Just deployed a fresh minimal 12.04 Ubuntu server installation. The behavior is exact the same. So it is not because of the OS version, its because of pbis-open forces us to do so. At least when using v8.0.1. What version do you use to deploy pbis-open? And how should we handle this in the future?

Can we consider, that all pbis-open versions are handling this behavior? If yes, we could hardcode the packages and all we need to do is to extend the dpkg installation variant using preceeded pbis-open-upgrade package.

If I'm going to have time today I will try to implement this in my fork

[benwebber]

Excellent, thank you for the extensive troubleshooting.

I went back and tested previous versions from the Beyond Trust site. This requirement was introduced in 7.1.1. Version 7.1.0.1203 does not depend on pbis-open-upgrade.

The last version version I tested against was 7.0. Admittedly, I no longer use this module at my current workplace and do not keep up with the latest releases.

Seeing as 7.1.0 is now over a year old, it would not be callous to require both packages moving forward. We would simply need to document the change and tag a new release.

[dionysius]

I just saw an old commit about the support of the newer service name. Do you know when exactly this got introduced?
Since we consider now current pbis-open installation we may want to change the default service name to the new one?