Age | Commit message (Collapse) | Author |
|
also, the $puppet_majorversion variable was empty because it was not
fully qualified.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
Conflicts:
manifests/cron.pp
manifests/linux.pp
take the changes from puppet_cron
|
|
This simplifies the hierarchy and fixes the problem that going from
puppet::cron to puppet under debian doesn't remove the cron file.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
github.com/cafuego/check_puppetmaster
|
|
|
|
|
|
https://labs.riseup.net/code/issues/4029
|
|
|
|
https://labs.riseup.net/code/issues/4029
|
|
Conflicts:
manifests/puppetmaster/passenger.pp
|
|
Conflicts:
manifests/puppetmaster/debian.pp
manifests/puppetmaster/linux.pp
manifests/puppetmaster/package/debian.pp
|
|
|
|
|
|
on each run:
notice: /Stage[main]/Puppet::Base/Service[puppet]/ensure: ensure changed 'stopped' to 'running'
When running in cron mode, you do not want the puppet service enabled, nor do
you want it 'running'. When enabling the cron mode, the first part of
puppet::cron::base does a Service override on the puppet service to set enable
=> false. That is a good thing, but all it does is make the service setup so it
wont be run on boot.
Unfortunately, the puppet service definition also has a 'ensure => running'
which does an /etc/init.d/puppet status and then starts the service if it is not
running. In a cron-only setup, the 'status' command results in a failure,
because the daemon is not running, and then puppet attempts to start it, which
goes nowhere because the /etc/default/puppet is configured not to start.
So, looking further at puppet::cron::base we see there is a case switch, testing
on operatingsystem and if its debian/ubuntu (or openbsd) it falls out of the
case. If it is not one of those, it continues and does a test to see if the
version of puppet is 2.6 and if so then it does an additional puppet Service
override to set ensure=> stopped which keeps the service from being checked to
see if it is running, and if it is not starting it.
So to fix this, we remove debian/ubuntu from the case, so it will continue
through and then we change the $puppet_majorversion test to look for anything
greater than or equal to '2.6', since 2.7 and later are also versions we want
this to work with.
After this change, we no longer get the attempt to restart puppet on every run.
|
|
on each run:
notice: /Stage[main]/Puppet::Base/Service[puppet]/ensure: ensure changed 'stopped' to 'running'
When running in cron mode, you do not want the puppet service enabled, nor do
you want it 'running'. When enabling the cron mode, the first part of
puppet::cron::base does a Service override on the puppet service to set enable
=> false. That is a good thing, but all it does is make the service setup so it
wont be run on boot.
Unfortunately, the puppet service definition also has a 'ensure => running'
which does an /etc/init.d/puppet status and then starts the service if it is not
running. In a cron-only setup, the 'status' command results in a failure,
because the daemon is not running, and then puppet attempts to start it, which
goes nowhere because the /etc/default/puppet is configured not to start.
So, looking further at puppet::cron::base we see there is a case switch, testing
on operatingsystem and if its debian/ubuntu (or openbsd) it falls out of the
case. If it is not one of those, it continues and does a test to see if the
version of puppet is 2.6 and if so then it does an additional puppet Service
override to set ensure=> stopped which keeps the service from being checked to
see if it is running, and if it is not starting it.
So to fix this, we remove debian/ubuntu from the case, so it will continue
through and then we change the $puppet_majorversion test to look for anything
greater than or equal to '2.6', since 2.7 and later are also versions we want
this to work with.
After this change, we no longer get the attempt to restart puppet on every run.
|
|
Because passenger mode doesn't have its own daemon, it was a hack before to have the service definition for 'puppetmaster' be actually looking in the process list for 'apache2'. This sort of worked, but not if you need to notify the service for a restart.
It also didn't actually work, because the hasstatus parameter was set to true, which meant that on every run, puppet did a /etc/init.d/puppetmaster status and found that it was not running and then tried to start it by doing /etc/init.d/puppetmaster start. That doesn't work because its turned off in /etc/default/puppetmaster when puppetmaster_mode='passenger'.
So... this commit removes that hacky service definition and instead just requires the apache::base class, providing the apache service monitoring that is needed when you are running puppetmaster_mode='passenger'. It also has to pull up the Service[puppet] override which was adding the puppetmaster service, which makes no sense because there is no service.
Finally, in order to notify it for changes, we need to use a selector to determine how to reload things based on puppetmaster_mode.
Conflicts:
manifests/puppetmaster/linux.pp
|
|
have the service definition for 'puppetmaster' be actually looking in the process list for 'apache2'. This sort of worked, but not if you need to notify the service for a restart.
It also didn't actually work, because the hasstatus parameter was set to true, which meant that on every run, puppet did a /etc/init.d/puppetmaster status and found that it was not running and then tried to start it by doing /etc/init.d/puppetmaster start. That doesn't work because its turned off in /etc/default/puppetmaster when puppetmaster_mode='passenger'.
So... this commit removes that hacky service definition and instead just requires the apache::base class, providing the apache service monitoring that is needed when you are running puppetmaster_mode='passenger'. It also has to pull up the Service[puppet] override which was adding the puppetmaster service, which makes no sense because there is no service.
Finally, in order to notify it for changes, we need to use a selector to determine how to reload things based on puppetmaster_mode.
|
|
otherwise you now get following error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Could not find resource(s) Package[puppetmaster] for overriding on node
flea.leap.se
see https://leap.se/code/issues/198
|
|
for debian
|
|
are not doing any overrides, instead we can just include the classes that we also want to load
|
|
needed or not, this is handled by the apt::preferences_snippet and debian's package dependency resolution now
stop inheriting puppet::master::package::base from puppet::puppetmaster::package::debian, it is no longer needed, because we are no longer overriding anything
|
|
puppet::puppetmaster::linux
provide a warning message if you have tried to specify $puppetmaster_ensure_version on an operatingsystem that is not supported
|
|
applications. This is likely not to work with older versions of passenger
|
|
The preferences snippet requires that we set the package parameter to 'puppet*' to pull in the correct dependencies.
We set the priority to 2000 because according to apt_preferences(5):
P > 1000 causes a version to be installed even if this constitutes a downgrade of the package
which is the desired behavior.
This should resolve issue #2928
|
|
|
|
to eliminate deprecation warnings
|
|
|
|
|
|
|
|
instead of touching .../restart.txt, which doen't seem to
work with libapache2-mod-passenger 2.2.11debian-2
|
|
|
|
Conflicts:
manifests/cron.pp
manifests/puppetmaster/package/debian.pp
|
|
|
|
|
|
|
|
puppet::cron.
The module should make sure that the cron file is not there if you aren't using
the cron method, otherwise the daemon and the cronjob could both run.
Used suggested change from jcharaoui in #3513
|
|
puppet::cron.
The module should make sure that the cron file is not there if you aren't using
the cron method, otherwise the daemon and the cronjob could both run.
Used suggested change from jcharaoui in #3513
|
|
The two package providers for FreeBSD are not able to ensure that a
specific version of a package is installed because of how ports/pkg_add
work. They can only ensure the version from the specified FreeBSD
release is installed or absent.
For more information, see:
http://docs.puppetlabs.com/references/stable/type.html#features-4
To make the class easier to understand, let's not do something that
users don't expect when they're requesting installation of a specific
version. We'll explicitly fail and tell users why so that they can
adjust how they use the class/module.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
$puppetmaster_ensure_version is not set
|
|
way it is"
This reverts commit d38e7cf64902ff55138e5f85cc7c3b880ea5fb74.
Current puppet package in Squeeze does not start by default => no need to
special case it.
|
|
Patch by pietro.
|