On Thursday, November 12, 2015 at 7:40:30 PM UTC-6, Stefan Lasiewski wrote:
>
> Hello Everyone,
>
> I am running Puppet 3.8 on CentOS 6. I'm trying to install a yum
> repository from an RPM package, as well as modify the contents of the .repo
> file after the package is installed.
>
> My example manifest is below. In my `yumrepo {'remi-safe':}` class, I
> require `require => Package['remi-release'],` so that the Package will be
> installed before the yumrepo class is called.
>
>
> # Install the REMI repo for some PHP software
> class stefanl::remi (
> $ensure = 'latest',
> $enabled = true,
> $priority = '80',
> ) {
>
> package { 'remi-release':
> ensure => $ensure,
> }
>
> yumrepo { 'remi-safe':
> enabled => $enabled,
> priority => $priority,
> require => Package['remi-release'],
> }
>
> }
>
>
> Instead, what seems to happen is that:
>
> 1. `yumrepo {'remi-safe':}` is called first, creates a file named
> `/etc/yum.repos.d/remi-safe.repo`
> 2. Then `package { 'remi-release':}` is called. I guess that since
> `/etc/yum.repos.d/remi-safe.repo` was already created, remi-release doesn't
> bother to install /etc/yum.repos.d/remi-safe.repo from the RPM, and I end
> up with a useless .repo file.
>
>
That chain of events seems unlikely. In the first place, I'm not prepared
to believe that when applying a catalog corresponding to the declarations
you presented, the agent fails to successfully apply Package['remi-release']
before it applies Yumrepo['remi-safe']. If you truly observe such behavior
-- via the agent's log output, for example -- then it follows that the
catalog applied was not built based on those declarations.
In the second place, it would be surprising, but not impossible, for RPM
installation to behave as you suggest. Ordinarily, one would expect one or
more .repo files to be packaged *as files* in the RPM, in which case
successful package installation will definitely result in those files being
installed on the system.
Under some circumstances, however, the RPM's version of the files might be
installed with an additional .rpmnew extension to avoid replacing
pre-existing versions of the same file. If you happen to also be doing
something like purging unmanaged files from /etc/yum.repos.d then perhaps
you would overlook that. Alternatively, if the latest available version of
package remi-release were already installed on the system, then the Package
resource would have no effect, even if files belonging to the package no
longer match their packaged versions.
Also, use of files in /etc/yum.repos.d is only one alternative for
installing a repo. Repo descriptions can also be installed directly in
/etc/yum.conf, though that somewhat problematic approach is not commonly
used. More commonly, multiple repositories -- normally related to each
other -- can be recorded in the same file in /etc/yum.repos.d.
>
> [root@webhost yum.repos.d]# cat remi-safe.repo
> [remi-safe]
> enabled=true
> priority=80
> [root@webhost yum.repos.d]#
>
>
>
> I'm a little confused why this is happening. Can I use `yumrepo` to modify
> a file installed by `package`?
>
>
Yes, you can. I do so, albeit not with the same version of Puppet.
Your confusion arises first and foremost because what you have concluded is
happening is surely not what's actually happening. Things to check:
- Is the class you presented being applied to the affected node?
Successfully?
- Is the RPM in question indeed installed? If so, then
- Does it pass verification (rpm --verify remi-release)?
- Is /etc/yum.repos.d/remi-safe.repo in its file list (rpm -ql
remi-release)?
- If you start with the package not installed and no relevant repo
declaration in place, and from that state install the package manually (yum
install remi-release), what changes result?
- Are there any in-scope resource defaults for Yumrepo resources?
It is conceivable that your Yumrepo resource is clobbering unmanaged
properties of the managed repository. That would constitute a bug and a
regression, and you can test for it by installing the release package
manually, verifying it good, and then applying the specified class to the
node and observing damage to the repo definition. There are any number of
other possibilities, but I decline to speculate further.
John
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/5d3ee60a-45fd-438f-8d8d-a2ec135cb89c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
