Okay isn't this always how it works... Just as I submitted this question, a dim light bulb went off in my head and I remembered something about the pty terminal Fabric uses causing problems every now and then. Found this is in the Fabric docs for run()
:
You may pass pty=False to forego
creation of a pseudo-terminal on the
remote end in case the presence of one
causes problems for the command in
question.
Well, sure enough if I amend the sudo
statement in my task as follows:
sudo("mount -a", pty=False)
Everything works just fine.
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.
Best Answer
You can have a look at the execute() function. You can use it to override on which hosts you run a task and pass extra arguments.
You probably need something along the lines of