Drop apt::cron::download, and turn $apt_cron_hours into a class parameter for ap…
…t::cron::dist_upgrade.
I've introduced apt::cron::download, am not using it anymore, and have
never seen anyone else submit a bug or a merge request for it. Thus,
I feel pretty confident in dropping it.
And this allows me to trivially get rid of the $apt_cron_hours global
variable noticed by LeLutin in #13.
(I've mistakenly marked !44 as merged)
See merge request !47
I've introduced apt::cron::download, am not using it anymore, and have
never seen anyone else submit a bug or a merge request for it. Thus,
I feel pretty confident in dropping it.
And this allows me to trivially get rid of the $apt_cron_hours global
variable noticed by LeLutin in #13.
Update the README to use markdown
This module's documentation is pretty good, but god plain text is awful when a document gets this long.
I _really_ dislike Gitlab's markdown flavor, but IMHO bad markdown is better than no markdown.
You can see the result here: https://gitlab.com/sogeecom/apt/blob/master/README.md
--
pollo
See merge request !41
The logic in specifying the default value for apt::repos is in the wrong
place: it should be in apt::params since this is exactly what this
latter class is for.
There's no special case that can involve making default the value follow
the value of another parameter so there's no point in having that logic
in the main class.
backports_url was already set to the same value than debian_url by
default, but it was set to the default value of debian_url. this meant
that when giving a url to the debian_url parameter to the apt class, the
backports_url would not follow and would still be using the default
value for debian_url.
with this change, when backports_url is not specified, but debian_url
is, then both of them take on the value given to the debian_url. of
course if backports_url is also given a value, then it keeps the value
given by the user.
Remove loglevel directive from Exec[update_apt]
When using puppet apply (v 3.7), loglevel 'info'
won't show the output on error. This is bad for
debugging.
micah, assigning to you because this has already bitten me while debugging a failed `apt-get update` for the leap_platform.
See merge request !39
Manage unattended-upgrades log directory
In some situations, the log directory for unattended-upgrades might not
exist. In those cases, packages will not get upgraded!
unattended-upgrades crashes with a python backtrace because the log dir
is not present.
See merge request !38
In some situations, the log directory for unattended-upgrades might not
exist. In those cases, packages will not get upgraded!
unattended-upgrades crashes with a python backtrace because the log dir
is not present.
The `disable_update` parameter has been removed. The main apt class
defaults to *not* run an `apt-get update` on every run anyway so
this parameter seems useless.
You can include the `apt::update` class if you want it to be
run every time.
`apt-get autoclean` should not be run on every puppetrun when
including `apt::update`, but rather be configured as a `APT::Periodic`
task that is run by cron, see
https://wiki.debian.org/UnattendedUpgrades.
Before, there were two Execs that did an `apt-get update`,
`Exec[refresh_apt]` and `Exec[apt_updated]`, which were triggered
by different resources.
This changes gets rid of the first one, and all resources now depend
on `Exec[apt_updated]`.
When pinning packages with apt::preferences_snippet,
we need to make sure these get deployed before an
`apt-get update` is triggered, so pinned packages can
get installed in the right way with a single puppetrun.
Beaker together with docker is a very fast way to do
acceptance testing.
This commit adds basic beaker/docker support:
- Add a debian jessie nodeset
- Test if the module applies idempotentially, so it doesn't
change resources on a second run with the same parameters.
https://github.com/puppetlabs/beaker/blob/master/docs/Docker-Support.md
[feat] Enable gitlab CI builds, simplify Gemfile
Test this module using existing rspec test, using gitlab CI on gitlab.com shared runners.
See https://gitlab.com/varac/apt/builds/473836 for the CI build of this merge req.
See merge request !33
[feat] Don't run an additional apt-get update
When adding custom keys, an additional `apt-get update` would
be run before the Exec['refresh_apt'], which don't make sense.
See merge request !31
I noticed this behaviour because $::debian_nextcodename was
"squeeze" on a wheezy host.
For debugging, i inserted a "puts codenames" in
lib/facter/debian_nextcodename.rb, and it turned out that it
was sorted differently on wheezy and jessie hosts:
On wheezy:
buster
stretch
jessie
wheezy
squeeze
lenny
On jessie:
lenny
squeeze
wheezy
jessie
stretch
buster
So i decided to rewrite this so this doesn't happen again.
requirering the facter/util/debian.rb module causes
puppet warnings on wheezy hosts, and custom facts like
`$::debian_codename` cannot be evaluated.
warning: Could not load fact file
/srv/dev/projects/puppet/shared-modules//apt/lib/facter/debian_nextcodename.rb:
no such file to load -- facter/util/debian
Removing the require line solves this.
