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

241 lines
8.6 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)
First commit
2010-04-27 22:38:28 +02:00
## Description
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
First commit
2010-04-27 22:38:28 +02:00
Provides helpful definitions for dealing with Apt.
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
Merge remote-tracking branch 'lauren/master' Conflicts: README.md
2013-02-16 04:16:31 +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
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
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
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
------------------
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
APT 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
Setup
-----
**What APT affects:**
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
* package/service/configuration files for 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
* 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
* wget (optional)
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
### 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
To begin using the APT module with default parameters, declare the class
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
Puppet code that uses anything from the APT module requires that the core apt class be declared/\s\+$//e
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
-----
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
Using the APT module consists predominantly in declaring classes that provide desired functionality and features.
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
`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.
The parameters for `apt` are not required in general 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,
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,
update_timeout => 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
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
If you declare your apt class with `purge_sources_list` and `purge_sources_list_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
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
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 { 'glusterfs-server':
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
release => 'unstable',
version => '3.0.3',
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
}
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
Adds a key to the list of keys used by APT to authenticate packages.
apt::key { 'puppetlabs':
key => '4BD6EC30',
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':
key => 'D50582E6',
key_source => 'http://pkg.jenkins-ci.org/debian/jenkins-ci.org.key',
}
Note that use of `key_source` requires wget to be installed and working.
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.
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':
location => 'http://debian.mirror.iweb.ca/debian/',
release => 'unstable',
repos => 'main contrib non-free',
required_packages => 'debian-keyring debian-archive-keyring',
Update out-of-date Debian signing key in remaining files.
2014-02-18 22:57:01 +01:00
key => '46925553',
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',
Improve documentation of the core apt class usage
2012-10-19 03:28:05 +02:00
include_src => true
}
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
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',
key => '4BD6EC30',
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
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
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
The APT module is mostly a collection of defined resource types, which provide reusable logic that can be leveraged to manage APT. It does provide 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.
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
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
This test will set up a Puppet Labs apt repository. Start by creating a new smoke test in the apt module's test folder. Call it puppetlabs-apt.pp. Inside, declare a single resource representing the Puppet Labs APT source and gpg key
apt::source { 'puppetlabs':
location => 'http://apt.puppetlabs.com',
repos => 'main',
key => '4BD6EC30',
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
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
This resource creates an apt source named puppetlabs and gives Puppet information about the repository's location and key used to sign its packages. Puppet leverages Facter to determine the appropriate release, but you can set it directly by adding the release type.
Check your smoke test for syntax errors
$ puppet parser validate tests/puppetlabs-apt.pp
If you receive no output from that command, it means nothing is wrong. Then apply the code
$ 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>
README: Fix white space / mixed indents.
2014-02-21 18:39:52 +01:00
The above example used a smoke test to easily lay out a resource declaration and apply it on your system. In production, you may 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).
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>
* 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>
Reference in a new issue Copy permalink