| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
In newer puppet releases the old way to name class/modules with a -,
won't anymore be supported.
|
|
Conflicts:
README
|
|
|
|
|
|
|
|
sources_list doesn't currently force puppet to run 'apt-get update'
after creating/modifying/removing files in sources.list.d.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
The .d directories are only managed by the main 'apt' class. However,
both 'sources_list' and 'apt_conf' defines depend on those directories.
So in practice, the defines have an implicit need for those directories
to be somehow managed.
Let's turn this into an explicit relation, and include the directories
in the defines.
This makes it possible to use both defines without having to include the
main 'apt' class. (maybe when using puppet apply?)
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
|
|
|
|
|
|
as we use $lsbdistcodename as source we cannot name the sources
which should be used to update "stable". -> Fix it by deploying
a per lsbdistcodename configfile. This can also be used as a pre-
work for the #2681 shared modules bug.
|
|
This reverts commit 3c0499b78d1f671fcce13127ef14b1b662a48c5a.
This was already provided by sources_list.pp.
|
|
|
|
|
|
This makes this class' behaviour consistent with the apt::dist_upgrade one
and prevents stalled upgrades due to dpkg asking questions to a dumb robot.
|
|
|
|
|
|
|
|
Not doing this breaks big parts of functionality, such as aptitude why.
|
|
-y instead of --force-yes. this way we are acting in the same way as the dist_upgrade class
|
|
things that are unrelated to the task at hand, such as deinstalling automatically installed packages, which can be undesirable behavior
|
|
|
|
This implements the "update initiator" pattern suggested by
http://projects.puppetlabs.com/projects/puppet/wiki/Debian_Patterns.
This feature is useful when one does not want to setup a fully automated upgrade
process but still needs a way to manually trigger full upgrades of any number of
systems at scheduled times.
|
|
|
|
|
|
|
|
namespace like that
|
|
|
|
The latter is only a wrapper around the former and it seems we want to remove
the latter from our shared common module.
|
|
This define was previously broken unless dctrl-tools and apt-show-versions were
installed.
|
|
Move this Exec to a dedicated class that is not included by default i.e. we
default not to "apt-get update" on every Puppet run.
We now make use of this class in the apt::upgrade_package define to make sure
APT indexes are up-to-date before attempting package upgrades.
One may now use the following to ensure current packages are installed by
Package resources:
include apt::update
Package { require => Exec[apt_updated] }
|
|
... because Exec[update_apt] is currently never run since we set it refreshonly.
Better solutions are being thought of, but in the meantime the least we can do
is somehow repair apt::upgrade_package.
|
|
|
|
|
|
|
|
|
|
non-interactively
|
|
Lenny's APT does not support pinning like this:
Pin: release o=Debian,n=<%= codename %>
We therefore switched (in commit ef2ebdffd) to:
Pin: release o=Debian,a=<%= release %>
With such a pinning setup, when Squeeze is released, systems using this module
with $apt_use_next_release set to true would immediately switch to prefer
packages from Squeeze. If an automated upgrade process is setup, they would be
automatically upgraded to Squeeze.
This does not sound safe to me, so let's use the release version number as an
additional selection criterion to prevent upgrades to Squeeze to happen behind
our back:
Pin: release o=Debian,a=<%= release %>,v=<%= release_version %>*
Note that the trailing '*' is intentional and necessary to match stable
point-releases.
|
|
|
|
This class installs a daily cronjob that checks if a package upgrade
requires the system to be rebooted; if so, cron sends a notification
email to root.
|
|
|
|
|
|
|
|
upgrade_package functionality, because you get an email when the package has been upgraded.
|
|
Why apticron, when we have cron-apt already? Some people have different preferences, we use apticron along with the upgrade_package functionality in this module. I know someone who uses cron-apt to run the upgrades, but apticron for notifications, because apticron's notifications are much nicer (cron-apt just gives you the output of apt-get upgrade)
|
|
|
|
|
|
a single source referenced by the README, and clarify the README to indicate how you can pass the preseed contents directly
|
