Skip to content

Commit

Permalink
Merge pull request #167 from dhoppe/fix_mdl
Browse files Browse the repository at this point in the history 
Fix several markdown lint issues
  • Loading branch information
@bastelfreak
bastelfreak authored Apr 25, 2020
2 parents 79ccdb1 + f18f13d commit 98867e8
Showing 1 changed file with 79 additions and 21 deletions.
100 changes: 79 additions & 21 deletions README.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -39,9 +39,15 @@ class { 'yum':
}
```

NOTE: The `config_options` parameter takes a Hash where keys are the names of `Yum::Config` resources and the values are either the direct `ensure` value (`gpgcheck` or `debuglevel` in the example above), or a Hash of the resource's attributes (`my_cachedir` or `assumeyes` in the example above). Values may be Strings, Integers, or Booleans. Booleans will be converted to either a `1` or `0`; use a quoted string to get a literal `true` or `false`.
NOTE: The `config_options` parameter takes a Hash where keys are the names of
`Yum::Config` resources and the values are either the direct `ensure` value
(`gpgcheck` or `debuglevel` in the example above), or a Hash of the resource's
attributes (`my_cachedir` or `assumeyes` in the example above). Values may be
Strings, Integers, or Booleans. Booleans will be converted to either a `1` or
`0`; use a quoted string to get a literal `true` or `false`.

If `installonly_limit` is changed, purging of old kernel packages is triggered if `clean_old_kernels` is `true`.
If `installonly_limit` is changed, purging of old kernel packages is triggered
if `clean_old_kernels` is `true`.

### Manage yum.conf entries via defined types

Expand All @@ -57,15 +63,21 @@ yum::config { 'debuglevel':

### Manage a custom repo via Hiera data

Using Hiera and automatic parameter lookup (APL), this module can manage Yumrepos. The `repos` parameter takes a hash of hashes, where the first-level keys are the `Yumrepo` resource names and their value hashes contain parameters and values to feed into the resource definition. **On its own, the `repos` parameter does nothing.** The resource names from the hash must be selected via the `managed_repos` parameter. This example defines a custom repo.
Using Hiera and automatic parameter lookup (APL), this module can manage
Yumrepos. The `repos` parameter takes a hash of hashes, where the first-level
keys are the `Yumrepo` resource names and their value hashes contain parameters
and values to feed into the resource definition. **On its own, the `repos`
parameter does nothing.** The resource names from the hash must be selected via
the `managed_repos` parameter. This example defines a custom repo.

First, include the class.

```puppet
include 'yum'
```

In Hiera data, add the name of the repo to the `yum::managed_repos` key (an Array), and define the repo in the `yum::repos` key:
In Hiera data, add the name of the repo to the `yum::managed_repos` key (an
Array), and define the repo in the `yum::repos` key:

```yaml
---
Expand Down Expand Up @@ -113,9 +125,12 @@ yum::gpgkeys:
### Enable management of one of the pre-defined repos
This module includes several pre-defined Yumrepos for easy management. This example enables management of the EPEL repository using its default settings.
This module includes several pre-defined Yumrepos for easy management. This
example enables management of the EPEL repository using its default settings.
**NOTE:** This only works if the data for the repository is included with the module. Please see the `/data` directory of this module for a list of available repos.
**NOTE:** This only works if the data for the repository is included with the
module. Please see the `/data` directory of this module for a list of available
repos.

```puppet
include 'yum'
Expand All @@ -129,9 +144,12 @@ yum::managed_repos:

### Enable management of one of the pre-defined repos AND modify its settings

Here the Extras repository for CentOS is enabled and its settings are modified. Because the `repos` parameter uses a deep merge strategy when fed via automatic parameter lookup (APL), only the values requiring modification need be defined.
Here the Extras repository for CentOS is enabled and its settings are modified.
Because the `repos` parameter uses a deep merge strategy when fed via automatic
parameter lookup (APL), only the values requiring modification need be defined.

To clear a value set below (from default repos, or lower in the hierarchy), pass it the *knockout prefix*, `--`. This will blank out the value.
To clear a value set below (from default repos, or lower in the hierarchy), pass
it the *knockout prefix*, `--`. This will blank out the value.

```yaml
---
Expand All @@ -145,7 +163,13 @@ yum::repos:
gpgkey: '--'
```

The built-in repos by default have data in `mirrorlist`, but `baseurl` is undefined. Using the knockout prefix won't work with `mirrorlist`, as it requires a valid URL or the value `absent`, as shown at https://puppet.com/docs/puppet/latest/types/yumrepo.html.
The built-in repos by default have data in `mirrorlist`, but `baseurl` is
undefined. Using the knockout prefix won't work with `mirrorlist`, as it
requires a valid URL or the value `absent`.

In case of Puppet 5, you can find more information in the [Puppet docs][1].
Since Puppet 6, this resource type has been moved to the [puppetlabs/yumrepo_core][2]
module.

```yaml
---
Expand All @@ -160,7 +184,10 @@ yum::repos:

### Enable managemnt of multiple repos

The `managed_repos` parameter uses the `unique` Hiera merge strategy, so it's possible to define repos to be managed at multiple levels of the hierarchy. For example, given the following hierarchy and the following two yaml files, the module would receive the array `['base', 'extras', 'debug']`.
The `managed_repos` parameter uses the `unique` Hiera merge strategy, so it's
possible to define repos to be managed at multiple levels of the hierarchy. For
example, given the following hierarchy and the following two yaml files, the
module would receive the array `['base', 'extras', 'debug']`.

```yaml
---
Expand Down Expand Up @@ -188,7 +215,10 @@ yum::managed_repos:

### Negate previously enabled repos

The `repo_exclusions` parameter is used to *exclude* repos from management. It is mainly useful in complex Hiera hierarchies where repos need to be removed from a baseline. Here we define a baseline set of repos in `common.yaml`, but disable one of them for a specific node.
The `repo_exclusions` parameter is used to *exclude* repos from management. It
is mainly useful in complex Hiera hierarchies where repos need to be removed
from a baseline. Here we define a baseline set of repos in `common.yaml`, but
disable one of them for a specific node.

```yaml
---
Expand Down Expand Up @@ -217,9 +247,13 @@ yum::managed_repos:
### Enable management of the default OS Yumrepos
This module includes the boolean helper parameter `manage_os_default_repos` easily select select OS repos. It uses module data to add the appropriate repos to the `managed_repos` parameter based on OS facts. Just like adding them manually, they can be negated via the `repo_exclusions` parameter.
This module includes the boolean helper parameter `manage_os_default_repos`
easily select select OS repos. It uses module data to add the appropriate repos
to the `managed_repos` parameter based on OS facts. Just like adding them
manually, they can be negated via the `repo_exclusions` parameter.
**NOTE:** This only works for operating systems who's Yumrepos are defined in the module's data AND who's default repos are defined in the module's data.
**NOTE:** This only works for operating systems who's Yumrepos are defined in
the module's data AND who's default repos are defined in the module's data.
On a CentOS 7 machine these two snippets are functionally equivalent.
Expand Down Expand Up @@ -248,7 +282,6 @@ class { 'yum':

### Add/remove a GPG RPM signing key using an inline key block


```puppet
yum::gpgkey { '/etc/pki/rpm-gpg/RPM-GPG-KEY-puppet-smoketest1':
ensure => present,
Expand Down Expand Up @@ -277,13 +310,16 @@ yum::plugin { 'versionlock':

### Lock a package with the *versionlock* plugin

Locks explicitly specified packages from updates. Package name must be precisely specified in format *`EPOCH:NAME-VERSION-RELEASE.ARCH`*. Wild card in package name is allowed provided it does not span a field seperator.
Locks explicitly specified packages from updates. Package name must be precisely
specified in format *`EPOCH:NAME-VERSION-RELEASE.ARCH`*. Wild card in package
name is allowed provided it does not span a field seperator.

```puppet
yum::versionlock { '0:bash-4.1.2-9.el6_2.*':
ensure => present,
}
```

Use the following command to retrieve a properly-formated string:

```sh
Expand All @@ -304,7 +340,9 @@ yum::versionlock { '0:bash-4.1.2-9.el6_2.*':

### Install or remove *yum* package group

Install yum [package groups](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sec-working_with_package_groups). To list groups: `yum group list`. Then use that name in your puppet manifest. With support for install_options (e.g. enable repos if disabled by default).
Install yum [package groups][3]. To list groups: `yum group list`. Then use
that name in your puppet manifest. With support for install_options (e.g. enable
repos if disabled by default).

```puppet
yum::group { 'X Window System':
Expand All @@ -314,10 +352,18 @@ yum::group { 'X Window System':
}
```


### Install or remove packages via `yum install`

This is a workaround for [PUP-3323](https://tickets.puppetlabs.com/browse/PUP-3323). It enables the installation of packages from non-repo sources while still providing dependency resolution. For example, say there is a package *foo* that requires the package *bar*. *bar* is in a Yum repository and *foo* is stored on a stand-alone HTTP server. Using the standard providers for the `Package` resource type, `rpm` and `yum`, the `rpm` provider would be required to install *foo*, because only it can install from a non-repo source, i.e., a URL. However, since the `rpm` provider cannot do dependency resolution, it would fail on its own unless *bar* was already installed. This workaround enables *foo* to be installed without having to define its dependencies in Puppet.
This is a workaround for [PUP-3323][4]. It enables the installation of packages
from non-repo sources while still providing dependency resolution. For example,
say there is a package *foo* that requires the package *bar*. *bar* is in a Yum
repository and *foo* is stored on a stand-alone HTTP server. Using the standard
providers for the `Package` resource type, `rpm` and `yum`, the `rpm` provider
would be required to install *foo*, because only it can install from a non-repo
source, i.e., a URL. However, since the `rpm` provider cannot do dependency
resolution, it would fail on its own unless *bar* was already installed. This
workaround enables *foo* to be installed without having to define its
dependencies in Puppet.

From URL:

Expand All @@ -341,9 +387,11 @@ Please note that resource name must be same as installed package name.

### Puppet tasks

The module has a puppet task that allows to run `yum update` or `yum upgrade`. This task needs puppet agent installed on the remote.
The module has a puppet task that allows to run `yum update` or `yum upgrade`.
This task needs puppet agent installed on the remote.

Please refer to the [Bolt documentation](https://puppet.com/docs/bolt/latest/bolt.html) on how to execute a task.
Please refer to the [Bolt documentation][5]
on how to execute a task.

```bash
$ bolt task show yum
Expand All @@ -362,8 +410,18 @@ PARAMETERS:

### Fedora partial support

Support for fedora is minimal at this time. The yum class can be included without error and resources such as `yum::group` can be managed. No repositories or GPG keys are managed by default. Old kernel cleanup is known not to work, and plugins may not work due to different package naming. Pull requests for additional support would be welcomed.
Support for fedora is minimal at this time. The yum class can be included
without error and resources such as `yum::group` can be managed. No repositories
or GPG keys are managed by default. Old kernel cleanup is known not to work, and
plugins may not work due to different package naming. Pull requests for
additional support would be welcomed.

---

This module was donated by CERIT Scientific Cloud, <support@cerit-sc.cz> to Vox Pupuli

[1]: https://puppet.com/docs/puppet/5.5/types/yumrepo.html
[2]: https://github.com/puppetlabs/puppetlabs-yumrepo_core
[3]: https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/system_administrators_guide/sec-working_with_package_groups
[4]: https://tickets.puppetlabs.com/browse/PUP-3323
[5]: ttps://puppet.com/docs/bolt/latest/bolt.html

0 comments on commit 98867e8

Please sign in to comment.