canmove, Confirmed users
1,394
edits
ReleaseEngineering/PuppetAgain/Modules/packages: Difference between revisions
Jump to navigation
Jump to search
ReleaseEngineering/PuppetAgain/Modules/packages (view source)
Revision as of 14:36, 31 July 2012
, 31 July 2012no edit summary
No edit summary |
|||
| Line 4: | Line 4: | ||
"Installation" here is taken to mean getting the package installed, along with any supporting files (e.g., NRPE plugins). | "Installation" here is taken to mean getting the package installed, along with any supporting files (e.g., NRPE plugins). | ||
= Implementation = | = Implementation = | ||
In general, package management resources get set up in the 'packagesetup' stage (see [ReleaseEngineering/PuppetAgain#Stages]), so that subsequent uses of the package manager can assume it is configured. This is done with an invocation of ''packages::setup'' from the ''toplevel::base'' class. | In general, package management resources get set up by the ''packages::setup'' class in the 'packagesetup' stage (see [ReleaseEngineering/PuppetAgain#Stages]), so that subsequent uses of the package manager can assume it is configured. This is done with an invocation of ''packages::setup'' from the ''toplevel::base'' class. | ||
== CentOS == | == CentOS == | ||
| Line 19: | Line 15: | ||
Yum caches repository metadata on clients for a default of six hours. This can cause problems when trying to land package changes, as the change will not be visible on clients for this time. A cache reload can be forced by incrementing '''$repoflag''' in modules/packages/manifests/setup.pp, working around the problem. | Yum caches repository metadata on clients for a default of six hours. This can cause problems when trying to land package changes, as the change will not be visible on clients for this time. A cache reload can be forced by incrementing '''$repoflag''' in modules/packages/manifests/setup.pp, working around the problem. | ||
= Setup = | === Setup === | ||
The ''packages::yumrepo'' class is used from ''packages::setup'' to install yum repositories. It takes | The ''packages::yumrepo'' class is used from ''packages::setup'' to install yum repositories. It takes | ||
| Line 27: | Line 23: | ||
; $gpg_key: (optional) puppet location of the gpg key for the repo | ; $gpg_key: (optional) puppet location of the gpg key for the repo | ||
; $gpg_key_pkg: (required if $gpg_key given) gpg-pubkey package that appears when the key is installed (use 'rpm -q gpg-pubkey' to find this) | ; $gpg_key_pkg: (required if $gpg_key given) gpg-pubkey package that appears when the key is installed (use 'rpm -q gpg-pubkey' to find this) | ||
== Darwin == | |||
There is no setup required for darwin packages. Each package is installed using ''packages::pkgdmg'': | |||
packages::pkgdmg { | |||
screenresolution: | |||
version => "1.6"; | |||
} | |||
This define automatically calculates the DMG path and uses the puppet pkgdmg provider to install it. | |||
In cases where a DMG is publicly available, a comment in the manifest file should indicate the source. In the more common case where a DMG must be built by hand, a shell script named ''$pkg-dmg.sh'' that builds the DMG should be included next to the manifest file, e.g., ''modules/packages/manifests/wget-dmg.sh''. This allows others to see changes from version to version of the DMG via 'hg diff', and also records the origin of the DMG so others can upgrade it. | |||
Since most software is not available in a pre-made DMG, we often find ourselves building DMGs for software like wget. If the software is not customized or patched, then the manifest and shell script should be in ''modules/packages/manifests''. If the package is customized or patched, it should be in the ''mozilla'' subdirectory, as described below for "Mozilla-Custom Packages". | |||
= Packages = | = Packages = | ||
See http://hg.mozilla.org/build/puppet/file/tip/modules/packages/manifests for the current list of packages. The names should be self-explanatory, right? | See http://hg.mozilla.org/build/puppet/file/tip/modules/packages/manifests for the current list of non-customized packages. The names should be self-explanatory, right? | ||
== Mozilla- | == Mozilla-Custom Packages == | ||
In many cases, we want customized or patched packages. Those should be under ''packages::mozilla''. Packages in this space have more requirements, since they are not simply pulling in a publicly available package. See [[ReleaseEngineering/PuppetAgain/HowTo/Hack on PuppetAgain#Custom Packages]]. | In many cases, we want customized or patched packages. Those should be under ''packages::mozilla''. Packages in this space have more requirements, since they are not simply pulling in a publicly available package. See [[ReleaseEngineering/PuppetAgain/HowTo/Hack on PuppetAgain#Custom Packages]]. | ||
| Line 70: | Line 81: | ||
=== packages::mozilla::screenresolution === | === packages::mozilla::screenresolution === | ||
This installs the jford's tool to set the screen resolution on a Mac in /usr/local/bin/screenresolution. The | This installs the jford's tool to set the screen resolution on a Mac in /usr/local/bin/screenresolution. The screenresolution class uses this on Darwin. | ||