On Tuesday, July 22, 2014 7:37:30 PM UTC-5, Stack Kororā wrote:
>
> Greetings,
>
> In my multiple hundred servers, I have <10 that are Red Hat based. We
> recently brought them under the same management as the rest of the servers
> utilizing Puppet. Then we ran into issues because we were hitting RHN too
> frequently and we got our servers banned. :-(
>
> I went digging for the culprit and found it in a section we wrote because
> audit is insistent that some packages should never be installed and they
> want regular checks that the packages are not installed. I rather liked my
> original solution (below) as I have dozens of packages that shouldn't be
> installed and occasionally I get another one to add to the list. This code
> made it really simple to add a new package.
>
> class audit::software_remove (
> ) {
> $removethesepackages = [
> 'telnet-server',
> 'telnet',
> # Dozens removed for sanity :-)
> ]
> case $operatingsystem {
> 'SLES' : { package {$removethesepackages : ensure=>absent,} }
> 'Scientific', 'CentOS', 'RedHat' : { package {$removethesepackages
> : ensure=>purged,} }
> default : {}
> }
> }
>
> Now SLES runs this code amazingly well because zypper just does a check
> against the local install before trying to remove a package and if it isn't
> installed it doesn't do anything at all. One of the many shortcomings of
> yum is that it always hits the repos.
>
But that's what's curious about your issue: it's not normal for yum to hit
the repos to service every request. Yum (by default) maintains local
caches of repo metadata to avoid that. At least on CentOS. I am not
positive that *bona fide* RHEL has the same default, but it certainly has
the same capability.
> Since we have a local repo set up for SLES, Scientific, and CentOS we
> don't care if we beat up on them. However, we discussed the local repo
> caching with Red Hat and it didn't work out (too much complexity for too
> few servers; won't go into details).
>
Have you considered setting up a caching proxy between you and them?
> Not only that, but because every package is a separate transaction, we hit
> the repo /multiple/ times every puppet run. Thus, our servers hit Red Hat
> repos frequently and we get banned. :-(
>
Again, this doesn't make sense. What per-package request(s) is yum
actually making? It does not even request repo metadata for me when I ask
it to remove a package that is not installed (much less any
package-specific data).
> So I went thinking about how to solve both the problem of slamming the
> repo and checking for the package before trying to do a removal.
>
> We have and utilize the pkginventory module[1] (which we have applied the
> waiting patches plus done some of our own since that module hasn't been
> updated in a long while). This gives me a fact of pkg_telnet or
> pkg_telnet_server if those packages are installed. So I decided to utilize
> that and I came up with the code below.
>
> [1] https://forge.puppetlabs.com/ody/pkginventory
>
> class audit::software_remove (
> ) {
> if $pkg_telnet_server {
> case $operatingsystem {
> 'SLES' : { package { 'telnet-server': ensure=>absent,} }
> 'Scientific', 'CentOS', 'RedHat' : { package {'telnet-server'
> : ensure=>purged,} }
> default : {}
> }
> }
> else { notify {"Package telnet-server is not installed":}}
> #----------------
> if $::pkg_telnet {
> case $operatingsystem {
> 'SLES' : { package { 'telnet': ensure=>absent,} }
> 'Scientific', 'CentOS', 'RedHat' : { package {'telnet' :
> ensure=>purged,} }
> default : {}
> }
> }
> else { notify {"Package telnet is not installed":}}
> }
>
> Hrm. It works, but it isn't a good solution in my opinion. Not at all. Too
> much code is being duplicated here. Well, there is some clean up I can do
> though now. Previously I used the case statement because audit wanted us to
> do a "yum purge" if any of the packages are found installed but SLES
> doesn't support "purged" and I don't really see a difference. That is a
> pointless case statement in my opinion with far too much code duplication.
>
> class audit::software_remove (
> ) {
> if $pkg_telnet_server { package { 'telnet-server': ensure=>absent,} }
> else { notify {"Package telnet-server is not installed":}}
> #----------------
> if $pkg_telnet { package { 'telnet': ensure=>absent,} }
> else { notify {"Package telnet is not installed":}}
> }
>
>
How about this:
define audit::forbidden_package () {
$is_present = inline_template(
'<%= scope.lookupvar('::pkg_' + @title.gsub('-', '_')) %>')
if $is_present {
package { $title: ensure => absent }
} else {
notify { "Package $title is not installed": }
}
}
class audit::software_remove (
) {
$forbidden_packages = [
'telnet-server',
'telnet',
# Dozens removed for sanity :-)
]
audit::forbidden_package { $forbidden_packages: }
}
Now you're back to having *no* lines to duplicate.
> Ah. Better. Now there are only 3 lines I have to duplicate (if,else,my
> comment separator I use for my own sanity). Plus, there is a package check
> /before/ the yum command even has a chance to run. I *still* get hit with
> those REALLY annoying double notify messages in the logs (why twice? I
> still do not understand why twice! Ugh...another gripe for another day)
>
I'm uncertain what you're talking about, but maybe it's that the log
records when the notify resource is synced, and the result of syncing it is
to output a message to the log. If you do not specify anything else via
its 'message' parameter, then a notify's message is the same as its title.
You might be able to improve that particular issue by adding "loglevel =>
'debug'" to your Notifies (the theory being that it would suppress logging
the sync, but not the message).
> but at least I don't hit the repo a million times every puppet run and
> that was the real goal here.
>
> So far in my testing environment, things are going well. Puppet runs are
> MUCH faster not having to hit yum all the time. Logs are a bit more crowded
> but at least they don't say "Software_remove/Package[telnet]/ensure:
> created" which was always a confusing statement in the puppet logs (another
> thing I never understood about puppet logging; how is a remove
> "created"...).
>
> Yet even still, there is something bothering me about how much code
> duplication just got added. I feel that there is a simpler and better way
> of doing this. I played with a few things I found online, but either they
> were more complex or they still hit the repo really hard.
>
> So I thought I would ask: Does anyone have any tips/suggestions on how I
> might improve this code a bit more? Any thoughts? Anything jump out at you
> that I could be doing better?
>
>
See above.
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/83848bc3-ed80-4fcd-8604-689da2a5d303%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
