add apt::key resource to deploy arbitrary keys

the rationale of this is that isn't useful for third party modules,
because they cannot inject keys in there without some serious apt
class hijacking

2 files changed, 30 insertions, 0 deletions

diff --git a/README b/README
index 8333be2..835db79 100644
--- a/README
+++ b/README
@@ -478,6 +478,23 @@ Example:
                 'puppet:///modules/site_apt/company_internals.list' ],
   }
 
+apt::key
+--------
+
+Deploys a secure apt OpenPGP key. This usually accompanies the
+sources.list snippets above for third party repositories. For example,
+you would do:
+
+  apt::key { 'neurodebian.key':
+    source => 'puppet:///modules/site_apt/neurodebian.key',
+  }
+
+This deploys the key in the `${apt_base_dir}/keys` directory (as
+opposed to `$custom_key_dir` which deploys it in `keys.d`). The reason
+this exists on top of `$custom_key_dir` is to allow a more
+decentralised distribution of those keys, without having all modules
+throw their keys in the same directory in the manifests.
+
 apt::upgrade_package
 --------------------
 
diff --git a/manifests/key.pp b/manifests/key.pp
new file mode 100644
index 0000000..0ef9721
--- /dev/null
+++ b/manifests/key.pp
@@ -0,0 +1,13 @@
+define apt::key ($source) {
+  file {
+    "${apt::apt_base_dir}/${name}":
+      source  => $source;
+    "${apt::apt_base_dir}/keys":
+      ensure  => directory;
+  }
+  exec { "apt-key add ${apt::apt_base_dir}/${name}":
+    subscribe   => File["${apt::apt_base_dir}/${name}"],
+    refreshonly => true,
+    notify      => Exec['refresh_apt'],
+  }
+}