opuppet/module-puppetlabs-apt
5
0
Fork 0
Code Issues Pull requests Releases Wiki Activity
module-puppetlabs-apt/README.md

338 lines
15 KiB
Markdown
Raw Normal View History

Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
apt
===
First commit
2010-04-27 22:38:28 +02:00
Update travis config file This commit adds ruby 1.9.3, puppet 3.0.2 support and a build status image to the README.
2013-02-02 10:19:21 +01:00
[![Build Status](https://travis-ci.org/puppetlabs/puppetlabs-apt.png?branch=master)](https://travis-ci.org/puppetlabs/puppetlabs-apt)
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Overview
--------
First commit
2010-04-27 22:38:28 +02:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
The apt module provides a simple interface for managing APT source, key, and definitions with Puppet.
First commit
2010-04-27 22:38:28 +02:00
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Module Description
------------------
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
The apt module automates obtaining and installing software packages on \*nix systems.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
***Note:** While this module allows the use of short keys, we **strongly** recommend that you **do not use short keys**, as they pose a serious security issue by opening you up to collision attacks.
Add security warning re: short keys
2014-04-07 19:56:20 +02:00
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Setup
-----
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
**What apt affects:**
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
* package/service/configuration files for APT
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
* NOTE: Setting the `purge_preferences` or `purge_preferences_d` parameters to 'true' will destroy any existing configuration that was not declared with Puppet. The default for these parameters is 'false'.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
* your system's `sources.list` file and `sources.list.d` directory
* NOTE: Setting the `purge_sources_list` and `purge_sources_list_d` parameters to 'true' will destroy any existing content that was not declared with Puppet. The default for these parameters is 'false'.
* system repositories
* authentication keys
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
### Beginning with apt
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
To begin using the apt module with default parameters, declare the class.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
include apt
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
Puppet code that uses anything from the apt module requires that the core apt class be declared.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Usage
-----
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
Using the apt module consists predominantly of declaring classes that provide the desired functionality and features.
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
### apt
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
`apt` provides a number of common resources and options that are shared by the various defined types in this module, so you **must always** include this class in your manifests.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
The parameters for `apt` are not generally required and are predominantly for development environment use cases.
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
class { 'apt':
Update readme.md - Syntax of apt class We have to use => and no dollar sign
2012-10-20 23:18:19 +02:00
always_apt_update => false,
- add bits for updating apt - 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
2014-08-18 22:12:55 +02:00
apt_update_frequency => undef,
Update readme.md - Syntax of apt class We have to use => and no dollar sign
2012-10-20 23:18:19 +02:00
disable_keys => undef,
proxy_host => false,
proxy_port => '8080',
purge_sources_list => false,
purge_sources_list_d => false,
add an updates_timeout option to apt::params (PR fix)
2013-10-02 14:24:30 +02:00
purge_preferences_d => false,
Implement fancy progress bars configuration. Ubuntu 14.04 ships with apt 0.9.15, has a ``fancy progress bar'', which is a green bar that shows at the bottom of the terminal showing progress throughout install. This patch enables the progress bar, which is usually done by running echo 'Dpkg::Progress-Fancy "1";' > /etc/apt/apt.conf.d/99progressbar
2014-04-24 09:52:12 +02:00
update_timeout => undef,
fancy_progress => undef
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
}
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
Puppet will manage your system's `sources.list` file and `sources.list.d` directory but will do its best to respect existing content.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Updated readme to indicate danger of setting preference purge options
2014-05-03 00:06:23 +02:00
If you declare your apt class with `purge_sources_list`, `purge_sources_list_d`, `purge_preferences` and `purge_preferences_d` set to 'true', Puppet will unapologetically purge any existing content it finds that wasn't declared with Puppet.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
### apt::builddep
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Installs the build depends of a specified package.
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
apt::builddep { 'glusterfs-server': }
added builddep command.
2011-07-25 00:12:25 +02:00
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
### apt::force
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
Forces a package to be installed from a specific release. This class is particularly useful when using repositories, like Debian, that are unstable in Ubuntu.
apt::force: Added 2 parameters for automatic configuration file handling; fixes #modules-1306 when updating or installing newer packages with apt::force and you have changed previous configuration files aptitude or apt-get will prompt what to do. You can suppress that by pre-define the action with cfg_files parameter (new, old or unchanged and its backward compatible if not defined). With a second optional parameter cfg_missing you can force your provider to install missing configuration files as well. Signed-off-by: Martin Seener <martin@seener.de> apt::force: Changed selectors used in force.pp to case statements; refs #module-1306 Signed-off-by: Martin Seener <martin@seener.de> apt::force: rspec: fixed the failing tests and added validate_re for cfg_files and validate_bool for cfg_missing. Also removed default values for both case statements and only allow pre-defined values or true/false. Furthermore enhanced the README refs #module-1306 Was able to fix the failing rspec tests for the patch. Thanks to Morgan Haskel. Signed-off-by: Martin Seener <martin@seener.de> Despite the puppetlabs-stdlib documentation says validation_re supports 3 arguments the tests failed telling that only 2 are supported. Fixed this by removing the 3 optional argument; refs #modules-1306 Signed-off-by: Martin Seener <martin.seener@barzahlen.de> apt::force: updated readme refs #module-1306 Signed-off-by: Martin Seener <martin@seener.de>
2014-09-05 10:14:08 +02:00
The cfg_files parameter controls wether newer or older configuration files should be used or only unchanged configuration files should be updated. Cfg_missing forces the provider to install all missing configuration files. Both are optional.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
apt::force { 'glusterfs-server':
apt::force: Added 2 parameters for automatic configuration file handling; fixes #modules-1306 when updating or installing newer packages with apt::force and you have changed previous configuration files aptitude or apt-get will prompt what to do. You can suppress that by pre-define the action with cfg_files parameter (new, old or unchanged and its backward compatible if not defined). With a second optional parameter cfg_missing you can force your provider to install missing configuration files as well. Signed-off-by: Martin Seener <martin@seener.de> apt::force: Changed selectors used in force.pp to case statements; refs #module-1306 Signed-off-by: Martin Seener <martin@seener.de> apt::force: rspec: fixed the failing tests and added validate_re for cfg_files and validate_bool for cfg_missing. Also removed default values for both case statements and only allow pre-defined values or true/false. Furthermore enhanced the README refs #module-1306 Was able to fix the failing rspec tests for the patch. Thanks to Morgan Haskel. Signed-off-by: Martin Seener <martin@seener.de> Despite the puppetlabs-stdlib documentation says validation_re supports 3 arguments the tests failed telling that only 2 are supported. Fixed this by removing the 3 optional argument; refs #modules-1306 Signed-off-by: Martin Seener <martin.seener@barzahlen.de> apt::force: updated readme refs #module-1306 Signed-off-by: Martin Seener <martin@seener.de>
2014-09-05 10:14:08 +02:00
release => 'unstable',
version => '3.0.3',
cfg_files => 'unchanged',
cfg_missing => true,
require => Apt::Source['debian_unstable'],
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
}
apt::force: Added 2 parameters for automatic configuration file handling; fixes #modules-1306 when updating or installing newer packages with apt::force and you have changed previous configuration files aptitude or apt-get will prompt what to do. You can suppress that by pre-define the action with cfg_files parameter (new, old or unchanged and its backward compatible if not defined). With a second optional parameter cfg_missing you can force your provider to install missing configuration files as well. Signed-off-by: Martin Seener <martin@seener.de> apt::force: Changed selectors used in force.pp to case statements; refs #module-1306 Signed-off-by: Martin Seener <martin@seener.de> apt::force: rspec: fixed the failing tests and added validate_re for cfg_files and validate_bool for cfg_missing. Also removed default values for both case statements and only allow pre-defined values or true/false. Furthermore enhanced the README refs #module-1306 Was able to fix the failing rspec tests for the patch. Thanks to Morgan Haskel. Signed-off-by: Martin Seener <martin@seener.de> Despite the puppetlabs-stdlib documentation says validation_re supports 3 arguments the tests failed telling that only 2 are supported. Fixed this by removing the 3 optional argument; refs #modules-1306 Signed-off-by: Martin Seener <martin.seener@barzahlen.de> apt::force: updated readme refs #module-1306 Signed-off-by: Martin Seener <martin@seener.de>
2014-09-05 10:14:08 +02:00
You can additionally set the following attributes:
* `cfg_files`: "new", "old", "unchanged" or "none" (default). "new" will overwrite all existing configuration files with newer ones, "old" will force usage of all old files and "unchanged" only updates unchanged config files whereas setting "none" will don't do anything but providing backward-compatability with existing puppet manifests.
* `cfg_missing`: "true" or "false". Setting cfg_missing to false will provide backward compatability whereas setting true will add an aptitude/apt-get parameter which checks and installs missing configuration files for the selected package.
Update the README about apt_key and apt::key.
2014-03-05 15:02:06 +01:00
### apt_key
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
A native Puppet type and provider for managing GPG keys for APT is provided by this module.
Update the README about apt_key and apt::key.
2014-03-05 15:02:06 +01:00
apt_key { 'puppetlabs':
ensure => 'present',
(DOC-1230) Update all short key examples to use the long key id
2014-09-10 22:21:07 +02:00
id => '1054B7A24BD6EC30',
Update the README about apt_key and apt::key.
2014-03-05 15:02:06 +01:00
}
You can additionally set the following attributes:
* `source`: HTTP, HTTPS or FTP location of a GPG key or path to a file on the
target host;
* `content`: Instead of pointing to a file, pass the key in as a string;
* `server`: The GPG key server to use. It defaults to *keyserver.ubuntu.com*;
* `keyserver_options`: Additional options to pass to `--keyserver`.
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
Because apt_key is a native type, it can be used in and queried for with MCollective.
Update the README about apt_key and apt::key.
2014-03-05 15:02:06 +01:00
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
### apt::key
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
Adds a key to the list of keys used by APT to authenticate packages. This type uses the aforementioned `apt_key` native type. As such, it no longer requires
the `wget` command on which the old implementation depended.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
apt::key { 'puppetlabs':
(DOC-1230) Update all short key examples to use the long key id
2014-09-10 22:21:07 +02:00
key => '1054B7A24BD6EC30',
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
key_server => 'pgp.mit.edu',
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
}
First commit
2010-04-27 22:38:28 +02:00
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
apt::key { 'jenkins':
(DOC-1230) Update all short key examples to use the long key id
2014-09-10 22:21:07 +02:00
key => '9B7D32F2D50582E6',
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
key_source => 'http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key',
}
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
### apt::pin
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Adds an apt pin for a certain release.
apt::pin { 'karmic': priority => 700 }
apt::pin { 'karmic-updates': priority => 700 }
apt::pin { 'karmic-security': priority => 700 }
Improve apt::pin example
2013-06-19 09:13:08 +02:00
Note you can also specifying more complex pins using distribution properties.
apt::pin { 'stable':
priority => -10,
originator => 'Debian',
release_version => '3.0',
component => 'main',
label => 'Debian'
}
apt::pin: Allow for packages to be an array.
2014-02-14 16:13:14 +01:00
If you wish to pin a number of packages you may specify the packages as a space
delimited string using the `packages` attribute or pass in an array of package
names.
apt::hold: Add a mechanism to hold a package. I am aware this can be done with `dpkg --set-selections`, `apt-mark` or `ensure => 'held'` on a package resource. The changes to the README include the full rationale for wanting another mechanism.
2014-03-05 10:13:42 +01:00
### apt::hold
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
When you wish to hold a package in Puppet, it should be done by passing in
apt::hold: Add a mechanism to hold a package. I am aware this can be done with `dpkg --set-selections`, `apt-mark` or `ensure => 'held'` on a package resource. The changes to the README include the full rationale for wanting another mechanism.
2014-03-05 10:13:42 +01:00
'held' as the ensure attribute to the package resource. However, a lot of
public modules do not take this into account and generally do not work well
with an ensure of 'held'.
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
Moreover, when Puppet is told to hold a package, it holds it at the current version installed; there is no way to tell it to both install a specific version **and** hold that version, unless you use an exec resource that wraps `dpkg --set-selections` or `apt-mark`.
apt::hold: Add a mechanism to hold a package. I am aware this can be done with `dpkg --set-selections`, `apt-mark` or `ensure => 'held'` on a package resource. The changes to the README include the full rationale for wanting another mechanism.
2014-03-05 10:13:42 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
At first glance, it seems this issue could also be solved by passing the version required to the ensure attribute---but that only means that Puppet will install that
version after it processes the package. It does not inform apt that we want
- add bits for updating apt - 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
2014-08-18 22:12:55 +02:00
this package to be held; that is, should another package want to upgrade this one (because of a version requirement in a dependency, for example), we want apt to refuse.
apt::hold: Add a mechanism to hold a package. I am aware this can be done with `dpkg --set-selections`, `apt-mark` or `ensure => 'held'` on a package resource. The changes to the README include the full rationale for wanting another mechanism.
2014-03-05 10:13:42 +01:00
- add bits for updating apt - 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
2014-08-18 22:12:55 +02:00
To solve this issue, use apt::hold. Implement this by creating a preferences file with a priority of 1001. Under normal circumstances, this preference will always win. Because the priority is > 1000, apt will maintain the required version, downgrading the current package if necessary.
apt::hold: Add a mechanism to hold a package. I am aware this can be done with `dpkg --set-selections`, `apt-mark` or `ensure => 'held'` on a package resource. The changes to the README include the full rationale for wanting another mechanism.
2014-03-05 10:13:42 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
With this, you can now set a package's ensure attribute to 'latest' but get the version specified by apt::hold:
apt::hold: Add a mechanism to hold a package. I am aware this can be done with `dpkg --set-selections`, `apt-mark` or `ensure => 'held'` on a package resource. The changes to the README include the full rationale for wanting another mechanism.
2014-03-05 10:13:42 +01:00
apt::hold { 'vim':
version => '2:7.3.547-7',
}
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
Alternatively, if you want to hold Vim at version 7.3.*, you can pass in a version with a glob:
apt::hold: Add a mechanism to hold a package. I am aware this can be done with `dpkg --set-selections`, `apt-mark` or `ensure => 'held'` on a package resource. The changes to the README include the full rationale for wanting another mechanism.
2014-03-05 10:13:42 +01:00
apt::hold { 'vim':
version => '2:7.3.*',
}
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
### apt::ppa
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Adds a ppa repository using `add-apt-repository`.
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
apt::ppa { 'ppa:drizzle-developers/ppa': }
First commit
2010-04-27 22:38:28 +02:00
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
### apt::release
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Sets the default apt release. This class is particularly useful when using repositories, like Debian, that are unstable in Ubuntu.
First commit
2010-04-27 22:38:28 +02:00
Fix apt::release example in readme
2013-05-29 23:46:32 +02:00
class { 'apt::release':
release_id => 'precise',
}
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
### apt::source
First commit
2010-04-27 22:38:28 +02:00
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Adds an apt source to `/etc/apt/sources.list.d/`.
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
apt::source { 'debian_unstable':
Update apt::source example in README.md for #311 This patch updates the apt::source example to include a comment (see #311)
2014-06-23 04:47:52 +02:00
comment => 'This is the iWeb Debian unstable mirror',
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
location => 'http://debian.mirror.iweb.ca/debian/',
release => 'unstable',
repos => 'main contrib non-free',
required_packages => 'debian-keyring debian-archive-keyring',
(DOC-1230) Update all short key examples to use the long key id
2014-09-10 22:21:07 +02:00
key => '8B48AD6246925553',
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
key_server => 'subkeys.pgp.net',
pin => '-10',
Update hold.pp fix for default debian installations all files in /etc/apt/preferences without _ will be silently ignore according to debian manpage. Addionally its not a good idea to write versionnumber in filename cause there is no way to delete this files if you increase versionumber Update source_spec.rb add a way to include debsrc only (useful for debian/ubuntu build server ... jenkins ect) Update source_spec.rb var rename Update source.list.erb add include_deb "switch" Update source.pp "include_deb" defaultvalue = true Update hold_spec.rb change the name of the preferences file (hold) Update source_spec.rb Update README.md Doku: 'include_deb' included next to 'include_src' in examples Update README.md typo
2014-07-18 10:51:32 +02:00
include_src => true,
include_deb => true
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
}
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
If you would like to configure your system so the source is the Puppet Labs APT repository:
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
apt::source { 'puppetlabs':
location => 'http://apt.puppetlabs.com',
repos => 'main',
(DOC-1230) Update all short key examples to use the long key id
2014-09-10 22:21:07 +02:00
key => '1054B7A24BD6EC30',
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
key_server => 'pgp.mit.edu',
}
Add PL Repo source to README Prior to this commit, the only information about the Puppet Labs repository source was in the tests folder. This commit adds example usage for apt::source to the README for the Puppet Labs APT repository.
2012-10-02 19:55:35 +02:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
### apt::update
- add bits for updating apt - 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
2014-08-18 22:12:55 +02:00
Runs `apt-get update`, updating the list of available packages and their versions without installing or upgrading any packages.
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
The update runs on the first Puppet run after you include the class, then whenever `notify => Exec['apt_update']` occurs---this should happen when config files get updated or other relevant changes occur. If you set the `always_apt_update` parameter, the update will run on every Puppet run.
add facts showing available updates 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.
2014-06-26 15:50:11 +02:00
### Facts
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
There are a few facts included in the apt module describing the state of the apt system:
add facts showing available updates 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.
2014-06-26 15:50:11 +02:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
* `apt_updates` --- the number of updates available on the system
* `apt_security_updates` --- the number of updates which are security updates
* `apt_package_updates` --- the package names that are available for update. In Facter 2.0 and later, this will be a list type; in earlier versions, it is a comma-delimited string.
- add bits for updating apt - 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
2014-08-18 22:12:55 +02:00
* `apt_update_last_success` --- The date in epochtime that `apt-get update` last ran successfully. This is determined by reading the mtime of the file `/var/lib/apt/periodic/update-success-stamp`. That file is generated by the `/etc/apt/apt.conf.d/15update-stamp` file.
Add ability to specify hash of apt sources in hiera This patch uses create_resources() to call apt::source which lets you specify your sources in hiera.
2013-12-04 19:05:26 +01:00
#### Hiera example
<pre>
apt::sources:
'debian_unstable':
location: 'http://debian.mirror.iweb.ca/debian/'
release: 'unstable'
repos: 'main contrib non-free'
required_packages: 'debian-keyring debian-archive-keyring'
(DOC-1230) Update all short key examples to use the long key id
2014-09-10 22:21:07 +02:00
key: '9AA38DCD55BE302B'
Add ability to specify hash of apt sources in hiera This patch uses create_resources() to call apt::source which lets you specify your sources in hiera.
2013-12-04 19:05:26 +01:00
key_server: 'subkeys.pgp.net'
pin: '-10'
include_src: 'true'
Update hold.pp fix for default debian installations all files in /etc/apt/preferences without _ will be silently ignore according to debian manpage. Addionally its not a good idea to write versionnumber in filename cause there is no way to delete this files if you increase versionumber Update source_spec.rb add a way to include debsrc only (useful for debian/ubuntu build server ... jenkins ect) Update source_spec.rb var rename Update source.list.erb add include_deb "switch" Update source.pp "include_deb" defaultvalue = true Update hold_spec.rb change the name of the preferences file (hold) Update source_spec.rb Update README.md Doku: 'include_deb' included next to 'include_src' in examples Update README.md typo
2014-07-18 10:51:32 +02:00
include_deb: 'true'
Add ability to specify hash of apt sources in hiera This patch uses create_resources() to call apt::source which lets you specify your sources in hiera.
2013-12-04 19:05:26 +01:00
'puppetlabs':
location: 'http://apt.puppetlabs.com'
repos: 'main'
(DOC-1230) Update all short key examples to use the long key id
2014-09-10 22:21:07 +02:00
key: '1054B7A24BD6EC30'
Add ability to specify hash of apt sources in hiera This patch uses create_resources() to call apt::source which lets you specify your sources in hiera.
2013-12-04 19:05:26 +01:00
key_server: 'pgp.mit.edu'
</pre>
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
### Testing
(#12823) Add apt::key defined type and modify apt::source to use it Adding this defined type allows puppet to add keys to the apt keystore without needing to add a corresponding source; it also adds the "key_source" parameter for wget'ing keys from arbitrary URLs, and allows for keys to be explicity removed. apt::key allows a key to be ensured present multiple times to account for apt::source resources that all reference the same key. However, this means that it is possible for a given key to be defined multiple times with differing source parameters. e.g. apt::key { "Add key: 4BD6EC30 from Apt::Source bunny": key => "4BD6EC30", key_server => "pgp.mit.edu", } apt::key { "Add key: 4BD6EC30 from Apt::Source rabbit": key => "4BD6EC30", key_server => "keyserver.ubuntu.com", } The defined type will accept both definitions and will create multiple exec resources. This was deemed preferable to the alternative (creating only one exec resource) in that one broken definition won't hose an entire catalog. If one definition fails to install the key because of a bad "key_server", the next apt::key that uses the key will get it done.
2012-02-24 19:10:03 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
The apt module is mostly a collection of defined resource types, which provide reusable logic that can be leveraged to manage APT. It provides smoke tests for testing functionality on a target system, as well as spec tests for checking a compiled catalog against an expected set of resources.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
#### Example Test
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
This test will set up a Puppet Labs APT repository. Start by creating a new smoke test, called puppetlabs-apt.pp, in the apt module's test folder. In this test, declare a single resource representing the Puppet Labs APT source and GPG key:
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
apt::source { 'puppetlabs':
location => 'http://apt.puppetlabs.com',
repos => 'main',
(DOC-1230) Update all short key examples to use the long key id
2014-09-10 22:21:07 +02:00
key => '1054B7A24BD6EC30',
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
key_server => 'pgp.mit.edu',
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
}
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
This resource creates an APT source named puppetlabs and gives Puppet information about the repository's location and the key used to sign its packages. Puppet leverages Facter to determine the appropriate release, but you can set this directly by adding the release type.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
Check your smoke test for syntax errors:
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
$ puppet parser validate tests/puppetlabs-apt.pp
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
If you receive no output from that command, it means nothing is wrong. Then, apply the code:
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
$ puppet apply --verbose tests/puppetlabs-apt.pp
notice: /Stage[main]//Apt::Source[puppetlabs]/File[puppetlabs.list]/ensure: defined content as '{md5}3be1da4923fb910f1102a233b77e982e'
info: /Stage[main]//Apt::Source[puppetlabs]/File[puppetlabs.list]: Scheduling refresh of Exec[puppetlabs apt update]
notice: /Stage[main]//Apt::Source[puppetlabs]/Exec[puppetlabs apt update]: Triggered 'refresh' from 1 events>
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
The above example uses a smoke test to lay out a resource declaration and apply it on your system. In production, you might want to declare your APT sources inside the classes where they’re needed.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Implementation
--------------
Use include instead of parameterized class when no params are given. Instead of perpetuating the use of parameterized classes, which we do not want to do in light of Puppet v3 with Hiera integration, this change invites people to use 'include' instead of the parameterized class syntax when no params are present.
2013-11-21 15:33:00 +01:00
### apt::backports
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Adds the necessary components to get backports for Ubuntu and Debian. The release name defaults to `$lsbdistcodename`. Setting this manually can cause undefined behavior (read: universe exploding).
MODULES-1259: added info on apt::update + edits to readme.md Added apt::update information to the Readme file. Also general copy editing throughout for clarity and consistent style.
2014-09-17 01:51:24 +02:00
By default this class drops a Pin-file for Backports, pinning it to a priority of 200. This is lower than the normal Debian archive, which gets a priority of 500 to ensure that packages with `ensure => latest` don't get magically upgraded from Backports without your explicit permission.
backports: Allow setting a custom priority. The module used to always pin backports to a priority of 200. This default is still retained but is now configurable. Additionally the default is now an Integer, not a 'quoted Integer' and the tests have been updated to reflect this. This matters for future parser as it will now kick people if they pass in a stringified integer as priority.
2014-03-26 17:13:08 +01:00
If you raise the priority through the `pin_priority` parameter to *500*, identical to the rest of the Debian mirrors, normal policy goes into effect and the newest version wins/becomes the candidate apt will want to install or upgrade to. This means that if a package is available from Backports it and its dependencies will be pulled in from Backports unless you explicitly set the `ensure` attribute of the `package` resource to `installed`/`present` or a specific version.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Limitations
-----------
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
This module should work across all versions of Debian/Ubuntu and support all major APT repository management features.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Development
------------
Puppet Labs modules on the Puppet Forge are open projects, and community contributions are essential for keeping them great. We can’t access the huge number of platforms and myriad of hardware, software, and deployment configurations that Puppet is intended to serve.
We want to keep it as easy as possible to contribute changes so that our modules work in your environment. There are a few guidelines that we need contributors to follow so that we can have a chance of keeping on top of things.
You can read the complete module contribution guide [on the Puppet Labs wiki.](http://projects.puppetlabs.com/projects/module-site/wiki/Module_contributing)
README/LICENSE: Fix licensing. Closes #152
2014-02-21 18:39:39 +01:00
License
-------
The original code for this module comes from Evolving Web and was licensed under the MIT license. Code added since the fork of this module is licensed under the Apache 2.0 License like the rest of the Puppet Labs products.
The LICENSE contains both licenses.
Updated content to conform to README best practices template *Note: I thought this was small enough to forgo a TOC. Please let me know if one is desired and I can add it in.* Before alterations, this content was the module author- determined description of and instructions for use of the module. As part of a joint Forge/Docs team effort to standardize formatting and encourage quality module documentation, a best practices README template was created via internal and external user testing. That template was then applied to this module. I pulled in content from the original README on GitHub. Standard headings were added (Overview, Module Description, Setup, Usage, Implementation, etc.) to organize content, existent content was moved under its appropriate heading and edited for tone/flow/clarity, and basic formatting was done to adhere to template standards.
2013-02-16 02:51:44 +01:00
Contributors
------------
A lot of great people have contributed to this module. A somewhat current list follows:
* Ben Godfrey <ben.godfrey@wonga.com>
* Branan Purvine-Riley <branan@puppetlabs.com>
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
* Christian G. Warden <cwarden@xerus.org>
* Dan Bode <bodepd@gmail.com> <dan@puppetlabs.com>
Add ability to specify hash of apt sources in hiera This patch uses create_resources() to call apt::source which lets you specify your sources in hiera.
2013-12-04 19:05:26 +01:00
* Daniel Tremblay <github@danieltremblay.ca>
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
* Garrett Honeycutt <github@garretthoneycutt.com>
* Jeff Wallace <jeff@evolvingweb.ca> <jeff@tjwallace.ca>
* Ken Barber <ken@bob.sh>
* Matthaus Litteken <matthaus@puppetlabs.com> <mlitteken@gmail.com>
* Matthias Pigulla <mp@webfactory.de>
* Monty Taylor <mordred@inaugust.com>
* Peter Drake <pdrake@allplayers.com>
* Reid Vandewiele <marut@cat.pdx.edu>
* Robert Navarro <rnavarro@phiivo.com>
* Ryan Coleman <ryan@puppetlabs.com>
* Scott McLeod <scott.mcleod@theice.com>
* Spencer Krum <spencer@puppetlabs.com>
* William Van Hevelingen <blkperl@cat.pdx.edu> <wvan13@gmail.com>
* Zach Leslie <zach@puppetlabs.com>
apt::hold: Add a mechanism to hold a package. I am aware this can be done with `dpkg --set-selections`, `apt-mark` or `ensure => 'held'` on a package resource. The changes to the README include the full rationale for wanting another mechanism.
2014-03-05 10:13:42 +01:00
* Daniele Sluijters <github@daenney.net>
Add dpaulus to the contributors list
2014-05-05 14:39:25 +02:00
* Daniel Paulus <daniel@inuits.eu>
- add bits for updating apt - 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
2014-08-18 22:12:55 +02:00
* Wolf Noble <wolf@wolfspyre.com>
Reference in a new issue Copy permalink