If one should happen to have redirected /usr/bin/gpg to run GnuPG 2.x
rather than the more usual GnuPG 1.x, the apt_key provider fails with
the following error:
Could not prefetch apt_key provider 'apt_key': invalid date
This is because the output of "--with-colons" defaults to using
"fixed-list-mode" in 2.x but did not do so for 1.x. This new format
gives much more information about keys and also uses timestamps in
seconds from 1970-01-01 (UNIX epoch) rather than dates in the format
YYYY-MM-DD.
This patch adds "--fixed-list-mode" when calling apt-key, and adjusts
the code to parse the timestamps instead. This actually has several
advantages:
- Works the same with GnuPG 1.x and 2.x.
- More accurate expiry time tracking, not just entire days.
- No need to require 'date' any longer.
- Will allow the provider to expose more key information in future.
Tested on:
- Debian Wheezy (Puppet 2.7.23, Ruby 1.8.7p358)
- Debian Jessie (Puppet 3.7.2, Ruby 2.1.5p273)
better attempt at gpg version checking
adding in key length warning
removing version check, adding key check
adding tests
clean up the code
small changes
use commands
documentation updates
The /usr/lib/update-notifier/apt-check script returns its output
to STDERR but a recent change to the script redirects STDERR to
/dev/null. This will cause the array to always be empty.
Combined with that problem, while we were checking for the result
being nil, we never checked for an invalid array. As a result,
the apt_has_updates was always true and the apt_updates and
apt_security_updates facts were trying to read from an empty array
and failing.
- fix spec tests to include osfamily fact
- add spec tests to verify current default behavior unimpacted.
- manage the update-stamp file in puppet via content rather than a served file.
- update custom fact to return -1 if the file doesn't exist
- add spec test for custom fact
- refactor to use a variable vs a collector/override
- document parameters a bit more verbosely
- remove empty unconstrained fact
- Add osfamily fact to backports tests to facilitate functional tests on non-debian hosts
Making use of the apt-check command from the 'update-notifier-common'
package (if available) display the number of available updates, number of
security updates as well as the update package names.
For some reason, even though our own tests pass with `require
puppet_x/apt_key/patch_openuri` every other module that depends on
puppetlabs-apt is now breaking in tests claiming it can't load that
module.
Somewhere along the way something is probably messing with LOADPATH
causing this to trip up. This should fix the issues for everyone.
This commit affects:
* puppetlabs/puppetlabs-apt#229
* puppetlabs/puppetlabs-postgresql#391
This commits introduces:
* The apt_key type;
* The apt_key provider;
* Unit tests for the type;
* Beaker/acceptance tests for the type/provider.
The idea behind apt_key is that apt::key will simply become a wrapper
that uses apt_key. Being a native type/provider apt_key is a lot less
error prone than the current exec behaviour of apt::key and adds a few
nice bonuses like inventory capabilities for mcollective users.