FAQ
Hi Stack,

Not sure if this is doable for you, but maybe you can create a schedule to
schedule your RedHat package removals.

http://docs.puppetlabs.com/references/latest/type.html#schedule

For example create a schedule to run this once a day, or not more than x
times a day and set the package resource defaults in your class
audit::software_remove to this schedule.

class audit::software_remove{

   schedule{ 'rhel_repos':
     period => daily,
     repeat => 3,
   }

   Package{ schedule => 'rhel_repos', }

}

This ties the schedule to the package resource and will apply it only 3
times a day. I use this in our setup to something similar with auditing
resources and the requirements are not to tight that this needs to be
applied in every run.

What can I do when yum or up2date command fails with RHN account has been
disabled for 'Abuse of Service' ?

This occurs when a machine has been flagged as connecting to Red Hat
Network (RHN) more frequently than 100 times per day after the first 1500
check-ins since the system was first registered with Red Hat Network. A
machine that has been registered for a week would be rejected after 2200
check-ins.
There is no advantage to be gained by checking in every 5 minutes that
cannot be achieved by checking in every 60 or 120 minutes. If the default
check-in interval of 240 minutes is not enough, then you can configure cron
jobs or the Red Hat Update Agent daemon to connect with Red Hat Network
every hour or every other hour, which should be sufficient, and is
recommended.
From: https://access.redhat.com/solutions/8165





2014-07-23 8:37 GMT+02:00 José Luis Ledesma <[email protected]>:
Hi,

I dont know if it will work, but have you tried adding provider => rpm in
the package resource?

Regards,
El 23/07/2014 02:37, "Stack Kororā" <[email protected]> escribió:

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. 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). 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. :-(

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":}}
}

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) 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?

Thanks! I appreciate it!
~Stack~

--
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/548784ca-1894-4a00-b98d-b501815c9d0d%40googlegroups.com
<https://groups.google.com/d/msgid/puppet-users/548784ca-1894-4a00-b98d-b501815c9d0d%40googlegroups.com?utm_medium=email&utm_source=footer>
.
For more options, visit https://groups.google.com/d/optout.
--
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/CAF_B3ddAyrZOE2fQv1yG226it1NFbFwCNaAfyVDxMzCCk1Dh_Q%40mail.gmail.com
<https://groups.google.com/d/msgid/puppet-users/CAF_B3ddAyrZOE2fQv1yG226it1NFbFwCNaAfyVDxMzCCk1Dh_Q%40mail.gmail.com?utm_medium=email&utm_source=footer>
.

For more options, visit https://groups.google.com/d/optout.


--
Met vriendelijke groet, Kind Regards,

Martin Willemsma

--
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/CAFcmyyp3r1tTxPVo16oE5rgSO7ozF2AYw4M6Y-cHx%3DCcR4qCUA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 3 of 9 | next ›
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJul 23, '14 at 12:37a
activeJul 24, '14 at 1:38p
posts9
users4
websitepuppetlabs.com

People

Translate

site design / logo © 2023 Grokbase