Open dionysius opened 10 years ago
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?
likewise-open
was installed before you removed it?pbis-open
packages to a local APT repo?Thank you for your time.
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.
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...
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
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.
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?
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).