| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
That is, silence it (and avoid nagging the administrators with email)
when all hosts are OK, and puppetlast exits with return code 0.
|
|
That is, install it as /etc/cron.d/puppetlast,
and cleanup the old buggy /etc/cron.d/puppetlast.cron.
As cron(8) says about /etc/cron.d/: "For example, any file containing dots will
be ignored."
|
|
|
|
|
|
|
|
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
|
|
|
|
|
|
|
