| Age | Commit message (Collapse) | Author |
|---|
|
|
|
Closes: Redmine#3467.
|
|
This is implemented by adding a "package" parameter to apt::preferences_snippet,
so that define names can be kept unique while the package names are
not necessarily.
Closes: Redmine#3468.
|
|
In newer puppet releases the old way to name class/modules with a -,
won't anymore be supported.
Conflicts:
manifests/unattended_upgrades.pp
|
|
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
|
|
Most of us are likely to use and test against the former.
|
|
|
|
|
|
|
|
CODENAME-updates.
Take this into account in the Debian sources.list template:
- go on using volatile.d.o for <= Lenny sources lines
- start using CODENAME-updates for Squeeze and newer.
Reference: http://lists.debian.org/debian-volatile/2011/01/msg00008.html
|
|
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.
|
|
|
|
|
|
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] }
|
|
|
|
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
|
|
instead of $debian_release, also expand it to allow for site-apt sources
|
|
|
|
Just so people are clear that they do not need to specify a $custom_key_dir to manage the debian archive keyring, I've added some clarifying text so you know that this is not necessary
|
|
The README described a few things that were not true relating to the
apt/preferences file.
First of all it said you could ship a 'file', but preferences.pp very clearly
uses the 'content => $custom_preferences' parameter, which will not take file
sources, only templates.
Secondly, it seemed to imply that you could just drop the custom preferences
into your site-apt and it would work. But you actually need to set the
$custom_preferences to indicate the content source.
Lastly, it said that you could specify a host-specific file in the site-apt
module, but there is no facility for this (nor can you use files).
Perhaps this is where this module is going eventually, once we have a
preferences.d possibility? Until then, it makes more sense to have it reflect
the current situation.
|
|
Before you only had the choice of setting a 03clean apt configuration for either
all hosts, or every single host. Setting it to have the recommended settings for
vservers for all hosts meant that you were setting it for non-vservers as well
as vservers. The other option you had was to set it per host. This was a bit
annoying if you have any more than one vserver because you would need to create
a 03clean for every single vserver guest.
This change auto-detects if the node is a vserver, and if it is it automatically
installs the 03clean_vserver file, with the recommended DSelect::Clean settings,
and allows you to override this for all of your vservers, or for specific hosts.
|
|
|
|
|
|
Conflicts:
README
files/preferences
templates/Debian/sources.list.deb-src.erb
templates/Debian/sources.list.volatile.erb
templates/Ubuntu/sources.list.backports.erb
templates/Ubuntu/sources.list.deb-src.erb
|
|
Conflicts:
README
manifests/custom_sources.pp
manifests/default_preferences.pp
manifests/init.pp
manifests/unattended_upgrades.pp
templates/Debian/sources.list.volatile.erb
|
|
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
Include new classes and defines and move things around for a little bit
of consistency.
Also remove the now unused variables.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
Integrate no custom preference into our new
way to manage the preferences.
Conflicts:
README
manifests/default_preferences.pp
manifests/init.pp
|
|
The current code makes it mandatory to have a file /etc/apt/preferences
present. In the event that this file is empty or contains a space,
apt-get update cannot execute.
Add a case with the special value "false" that ensures the file does not
exist.
Signed-off-by: Gabriel Filion <lelutin@gmail.com>
|
|
|
|
|
|
Now, we have the possibility to externally add snippes, so that
we can preferences for packages that are for example only in backports
or unstable.
|
|
|
|
This allows other modules to add lines there too.
|
|
|
|
This will help merging with Nadir's changes.
|
|
The templates already made use of it, but the code didn't set a default value.
|
|
|
|
|
|
|
|
The previous default pinning preferences only supported tracking stable.
Tracking squeeze or sid is now possible.
|
|
|
|
|
|
changed and we don't need a separate apt-key for it now
|
