Greetings, I did try this but ran into issues in my testing when a package had dependencies. I don't remember what the problem was though...I should probably explore this a bit more.
Thanks! On Wednesday, July 23, 2014 1:37:41 AM UTC-5, Jose Luis Ledesma wrote: > > 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] <javascript:>> > 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] <javascript:>. >> 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/bc625f51-8704-43c1-80da-c674fe4b4b12%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
