The README suggests that setting a sufficiently high `loglevel` metaparameter
value will squelch the `Exec[apt_update]` resource's corrective changes from
agent reports. This is not true. Correct and clarify this statement to limit
its scope to log output, and link to MODULES-10763 for context on the exec
resource's false-positive reporting of corrective changes as a known issue.
mdklapwijk [Wed, 27 May 2020 17:25:03 +0000 (19:25 +0200)]
patch-acng-ssl-support
Support for https repositories via caching proxy apt-cacher-ng using the "tell-me-what-you-need" method as described in the documentation:
- https://www.unix-ag.uni-kl.de/~bloch/acng/html/howtos.html#ssluse
gimmy [Fri, 13 Mar 2020 12:09:41 +0000 (14:09 +0200)]
(maint) Update apt custom facts
This commit updates apt custom facts because the evaluation
of custom facts code has changed between facter 2 and facter 4.
In facter 2, when a custom fact is loaded, the code in `add` block
was not executed.
In facter 4, when a custom fact is loaded, the code outside `setcode`
block is executed(same as Facter 3).
Antoine Beaupré [Wed, 11 Mar 2020 13:58:15 +0000 (09:58 -0400)]
do not specify file modes unless relevant
MODULES-10583 makes a good point: "why are you messing with my file
permissions"? In my case, the entire reason I made the following
change (in PR #906):
... is exactly *because* Puppet was changing the file modes from under
me. I was migrating from our own in-house APT module to the forge one,
and our module did *not* intervene in those file modes: it left the
file resources alone. Which means we could have a directive like this:
... which made all files readonly by default. So when I migrated to
the Puppetlabs APT module, modes were changed to be writable, which I
did not want.
As I reasoned in MODULES-10548, having files readonly provides an
excellent indicator that a file is managed by Puppet, even if some
module does not add a warning header - either because it forgot or
because it's impossible. But I also understand if people do not like
that policy.
I think the proper way of doing this is not specifying a mode at all,
and let local site-specific policies apply. I specifically proppose
this as an alternative to #921 because I believe adding more
parameters to the resources will needlessly complicate the script,
when we have a native, Puppet-DSL supported way of changing those
modes according to the right scope and context.
In a similar way, we might want to reconsider user and group ownership
of the files, but that can be done in a later time.
Prior to this commit the provision file referenced the old
waffleimage repo for CI docker images to use. This commit
updates the file to point at litmusimage, which is the repo
the latest images are released to.
Antoine Beaupré [Wed, 12 Feb 2020 19:23:33 +0000 (14:23 -0500)]
MODULES-10548: make files readonly
Files created by the apt module are mode writable by the
owner. Because those files are managed by Puppet, they should really
not be writable by anyone, even root. While root can bypass those
warnings, having files readonly does provide an immediate and reliable
indication that a file should not be edited on site, on top of the
usual top of file warnings.
This also fixes a problem with sources.list.d being non-executable,
which Puppet seems to ignore, but seems better to keep consistent.
Antoine Beaupré [Wed, 12 Feb 2020 19:03:15 +0000 (14:03 -0500)]
only consider lsbdistcodename for apt-transport-https
It does not matter if we have *one* older source from (say) jessie or
stretch, we could still be running buster or later. The latter is more
reliably indicated by the fact than by the provided "release"
parameter, which is really just an arbitrary string that does not
necessarily match a Debian suite, especially for third-party
repositories.
I have had a problem with this setting when deploying a "stretch"
repository on a "buster" system because I needed to keep MongoDB
running (which is gone from buster). The "stretch" line triggered this
line, which conflicted with a `ensure_packages` I had elsewhere in our
code base, to *remove* the `apt-transport-https` package from buster
and later.
An alternative implementation might prefer to remove the package
unconditionnally if we run a newer release, but I figured I would keep
the changes to a minimum.
Antoine Beaupré [Tue, 11 Feb 2020 16:40:06 +0000 (11:40 -0500)]
MODULES-10543: remove sources.list file on purging
The current sources.list purge behavior is inconsistent with the
preferences behavior. The former creates a file with a comment, the
latter removes the file.
This harmonizes this behavior between the two files and simply drops
the file if it is to be purged.
Sascha Rüssel [Wed, 6 Nov 2019 13:47:19 +0000 (14:47 +0100)]
include module apt in backports
Otherwise there can be issues with undef values.
like:
Evaluation Error: Operator '[]' is not applicable to an Undef Value. (file: /etc/puppetlabs/code/environments/production/modules/apt/manifests/backports.pp, line: 73, column: 18) on node …
Glenn Sarti [Tue, 5 Nov 2019 05:03:29 +0000 (13:03 +0800)]
(PDK-1501) Fix acceptance stages in Travis CI
Previously the Travis CI file was brought under PDK control, however the
sync.yml did not contain the stage settings for the Litmus jobs which meant
that they did not run. This commit fixes that error and runs PDK Update again
This commit updates the readme to remove the language marking litmus
as an experimental tool as well as clarifying the instructions for
running acceptance tests and noting the schedule for the IA Content
office hours.
Prior to this commit the only provisioners included in
the provision lists were docker and vmpooler, neither
of which are particularly accessible to folks developing
on Windows outside of Puppet.
This commit adds a list which leverages the vagrant
provisioner.
Code Review / puppet-modules / puppetlabs-apt.git / log