| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
https://labs.riseup.net/code/issues/4029
|
|
|
|
|
|
|
|
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
|
|
|
|
instead of touching .../restart.txt, which doen't seem to
work with libapache2-mod-passenger 2.2.11debian-2
|
|
|
|
|
|
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>
|
|
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.
|
|
|
|
The puppet::cron::freebsd class is almost identical to the
puppet::cron::openbsd one, but there is no cron job to remove, and the
/etc/rc.conf mechanism doesn't exist yet for FreeBSD.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
We'd like to use this variable in the 'puppet' class since we're
defining the path to another config file, there.
Since puppet::puppetmaster inherits the puppet class, the variable will
be defined appropriately. Just to make sure we get the value from the
right place, let's also use the qualified variable name.
To avoid useless repetitions in the variable name, change the variable
name from $puppet_default_config_dir to $default_config_dir.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
The default ssl directory in FreeBSD is /var/puppet/ssl, not
/usr/local/etc/puppet/ssl
With the previous value, puppet would refuse to run starting from the
second run, stating that the certificates do not match.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
The FreeBSD class was previously defined but not included by the puppet
class in init.pp
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
The linux class installs puppet and facter via puppet itself.
Chances are that they are already installed, since you need puppet
before you can run puppet.
_But_, it enables the $puppet_ensure_version and $facter_ensure_version
features (forcing the installed version). So let's do the same in
FreeBSD.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
The puppet master has one additional config file that needs to be placed
in a different folder under FreeBSD.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
Some pieces of the puzzle are missing for being able to manage puppet in
FreeBSD.
* Add a default puppet client config template for FreeBSD
* In FreeBSD, puppet.conf is not in /etc/puppet/ so let's provide a
value for this variable in init.pp.
* The rc script for starting and stopping puppet is not located in
/etc/rc.d so let's signify this to Service[puppet]
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
|
|
|
|
|
|
Mar 29 14:08:23 puppetmaster puppet-master[26637]: Unrecognised escape sequence '\%' in file /etc/puppet/modules/puppet/manifests/cron/linux.pp at line 17
|
|
|
|
|
|
|
|
https://labs.riseup.net/code/issues/2819
|
|
|
|
|
|
|
|
pulling 2 bytes from /dev/urandom, giving them to od which turns them into unsigned decimals, and then we bitshift the output, either by 5 or 6 depending on if we are replacing $RANDOM/1000*60 (right sift by 5 is the same as dividing by 2^N, or /32) or $RANDOM/2000*60 (range of [0,983])
Thanks to dkg for working through this with me, not only did he come up with it faster than a human brain should be able to function, he had the patience to explain all the individual pieces that I did not understand to me.
|
|
(^err:|^alert:|^emerg:|^crit:) in the output from the puppet run doesn't leave us with a '1' return code from grep.
On Debian Squeeze systems, this problem would result in cron reporting that the cron command failed with an exit status 1:
/USR/SBIN/CRON[24107]: (CRON) error (grandchild #24108 failed with exit status 1)
This was because grep returns a '1' if it fails to find a match. We don't want the failure to find failure messages to produce a failure, so this checks the return code of the grep and fixes it to be '0' if there were no such failure log messages.
This is a bit ugly, if you ask me. We are already, unfortunately, swallowing the puppetd return code with the grep. It seems like these sorts of log messages should be retrieved via reports, logcheck, or something other than this grep of the output of the cronjob.
|
|
done to set a flag so that squeeze has the service stopped, but lenny does not
|
|
$puppet_ensure_version to a backported version and your pinning was setup so
that you dont pull any packages unless explicit (I believe this is the default),
then you will end up seeing things like this:
The following packages have unmet dependencies:
puppet: Depends: puppet-common (= 2.6.2-4~bpo50+1) but 2.6.2-1~bpo50+1 is to be installed
E: Broken packages
at /etc/puppet/modules/puppet/manifests/linux.pp:6
this commit adds the $puppet_ensure_version test in debian.pp to make sure that
the puppet-common package is also following this request
|
|
|
|
|
|
have been a mistake in a merge commit
This reverts commit bb8ede5cfa0bdbdcc0244a590e6453f16d815cb6.
|
|
distinguish between different linux distros
|
