Hi,
I dont know if it will work, but have you tried adding provider => rpm in the package resource?
Regards,
--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/548784ca-1894-4a00-b98d-b501815c9d0d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
schedule{ 'rhel_repos':
period => daily,
repeat => 3,
}
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.To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/CAF_B3ddAyrZOE2fQv1yG226it1NFbFwCNaAfyVDxMzCCk1Dh_Q%40mail.gmail.com.
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.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
class audit::software_remove{
Package{ schedule => 'rhel_repos', }schedule{ 'rhel_repos': period => daily, repeat => 3, }
}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.
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.
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. :-(
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?
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. 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. ---
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. ---- 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. 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 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 Thank you to everyone who has chimed in. These responses are exactly what I was looking for. I have learned more about puppet and have a few new tricks to use. I really do appreciate it. Thanks! ~Stack~
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.
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.
---
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.
---- 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.
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
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