Well, for APT in particular, you can configure many daily jobs, such as update. Just look at /etc/cron.daily/apt
for a list of variables you can configure, and check the man page for apt.conf
for how to do it. The ones of most interest to you are these:
# APT::Periodic::Update-Package-Lists "0";
# - Do "apt-get update" automatically every n-days (0=disable)
#
# APT::Periodic::Download-Upgradeable-Packages "0";
# - Do "apt-get upgrade --download-only" every n-days (0=disable)
#
# APT::Periodic::Download-Upgradeable-Packages-Debdelta "1";
# - Use debdelta-upgrade to download updates if available (0=disable)
#
# APT::Periodic::Unattended-Upgrade "0";
# - Run the "unattended-upgrade" security upgrade script
# every n-days (0=disabled)
# Requires the package "unattended-upgrades" and will write
# a log in /var/log/unattended-upgrades
As for upgrading the system, use the package unattended-upgrades
.
Having said all that, I prefer to use Puppet to control what packages must be kept at ensure => latest
, or ensure => version
, as well as controlling pin numbers for various source list and packages.
And, I suppose, one could use a configuration like this:
cron { 'upgrade': command => 'apt-get update && apt-get upgrade' }
Now, you mention doing stuff before calling puppet agent. Do you mean before running puppet agent for the first time? If so, then a solution such as Foreman might do the trick for you.
Here, where I manage my virtual hosts through Ganeti, we have puppet being installed by Ganeti's instance-debootstrap. We also have a small script we use to install puppet on older servers.
In the end, it is not possible to use an automated solution to install Puppet on existing servers unless said automated solution has been already installed. Our own preference is to install puppet first, and distribute anything else through it.