On Wednesday, July 23, 2014 6:26:00 PM UTC-5, Stack Kororā wrote:
>
> Greetings!
>
> Thank you so much John. I just learned something new about Puppet. Utilizing
> inline_template is a heck of a lot easier then how I first attempted that
> variable substitution. I might have to go back and fix some of my older code
> later....
>
>
> Here are a few other notes in response to your email:
> > Have you considered setting up a caching proxy between you and them?
>
> We have discussed doing a caching proxy, but haven't ever had the
> time/inclination to implement one yet.
>
> ----
>
> > What per-package request(s) is yum actually making?
>
> I explored the yum thing a bit more. Running puppet-3.6.2-1.el6.noarch on
> both server and client using CentOS6 as my test systems. I started a puppet
> run in one terminal and ran this code in a second:
> $ while [ "$(pgrep puppet)" != "" ]; do pgrep yum; done | uniq
>
> If I just do this:
> package { 'telnet' : ensure=>absent,}
>
> Nothing triggers.
>
> If I do it this way:
> $removethesepackages = [
> 'telnet-server',
> 'telnet',
> ]
> package {$removethesepackages : ensure=>absent,}
>
> Then I get a yum PID per package. For every PID I get a line in the puppet
> log like this:
> Notice: /Stage[main]/audit::Software_disabled/Package[telnet]/ensure: created
>
> (there is that weird error message again where an absent is "created").
>
> I don't know why. Both work as expected, but the second triggers a yum call
> the first doesn't.
>
>
I find it surprising -- and in fact unlikely -- that using an array
resource title produces different behavior than does a sequence of separate
resource declaration for each of the packages. If that is in fact the case
then I encourage you to file a bug report, but I'm pretty sure you're mixed
up. In particular, Puppet will *never* invoke 'yum' to ensure a package
'absent' -- the 'yum' provider intentionally uses 'rpm -e' for that.
Puppet uses 'yum remove' only to ensure a package 'purged'.
In any case, the issue is not so much whether Puppet spawns yum processes;
rather it is what yum *does* once spawned. Yum should not be hitting RHN
to service a request to remove a package, whether that package is in fact
installed or not. Furthermore, the number of RHN requests needed to serve
all other package management needs should be minimized by yum's metadata
caching. Even if you instructed Puppet to clear yum metadata on each run,
you should hit RHN only once per Puppet run, except when you install or
update a package. If you see different behavior then you should
investigate yum's own configuration.
> So I thought, 'Maybe it is hitting local cache and not actually going out to
> the repo'. I dug around in the logs on our local repo and found this:
> [IP REMOVED] - - [23/Jul/2014:14:07:58 -0500] "GET
> /puppetlabs/6/products/x86_64/repodata/repomd.xml HTTP/1.1" 200 2529 "-"
> "urlgrabber/3.9.1 yum/3.2.29"
>
> It isn't one per package, but it is one per puppet run. Something about that
> method calls yum differently I guess. Not sure why.
>
>
Puppet executes a "yum list --all" once per run so it can tell what to do
with packages ensured anything other than 'absent' or 'purged'. This is
part of a strategy to avoid needlessly running yum to install packages that
aren't available or to update a packages that are already at the latest
available version. But it should be served from yum's cache most of the
time. If you see these frequently going out to RHN, then again, something
is weird about your yum configuration.
> ---
>
> The double notice I was referring to is this:
> Notice: Package telnet is not installed
> Notice:
> /Stage[main]/audit::Software_disabled/audit::Forbidden_package[telnet]/Notify[Package
> telnet is not installed]/message: defined 'message' as 'Package telnet is
> not installed'
>
> I am told three times in two lines (more with wrap around on a console) that
> telnet isn't installed. I find it annoying and haven't found a solution to
> removing it yet and leaving just the first Notice. If you know of one I would
> be /very/ grateful.
>
>
So that's just what I supposed you might be talking about. Did you try my
suggestion to set "loglevel => 'debug'" on the Notice resources?
> ----
> I implemented your code and it is working brilliantly. I made two changes.
> 1) I placed the define in init.pp so I can reference it anywhere in the audit
> class easily.
>
>
Sorry, I didn't intend to imply a specific file to put the define in. The
standard place for a define named audit::forbidden_package would be <module
path>/audit/manifests/forbidden_package.pp (same rule as for classes).
Putting it there is even more likely to ensure that Puppet can always find
it. If you follow that pattern systematically then it also helps *you*
find it.
> 2) I changed:
> '<%= scope.lookupvar('::pkg_' + @title.gsub('-', '_')) %>')
> to:
> "<%= scope.lookupvar('::pkg_' + @title.gsub('-', '_')) %>")
>
> Using the single quotes gave me the error:
> Error: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Syntax error at '::pkg_'; expected ')' at
> /etc/puppet/modules/audit/manifests/software_disabled.pp:8 on node
> centos6.testing.puppet
> Warning: Not using cache on failed catalog
> Error: Could not retrieve catalog; skipping run
>
>
Oops. Sorry about that.
> But now it is working really well in my dev environment! I push to production
> tomorrow...We will see how pleased I am with my code changes at the end of
> the day after this fix + 4 other "minor" changes roll out. :-D
>
>
Great! I'm glad it's working for you.
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 puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/7a770d55-3200-4972-bc39-3f0ec5e59725%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
