So we''re evaluating some configuration management/auditing tools and we''re checking out the open-source avenue. At the moment, we''re looking at BladeLogic ( I''m sure Luke is laughing ... ), HP OpsWare and puppet on the open source side. One question I have that I have not been able to deduce from the documentation or the LISA presentations is how puppet can deal with the unknown. For instance, with packages, how do I prevent or notify about packages that get installed that I don''t want installed, without having to list every package that could ever possibly be installed on the system? I''ve seen the pkgsync cookbook recipe but the problem with this recipe is that you have to have an entire list of packages that you don''t want installed. While in the perfect world, all packages would be installed via puppet, you are going to have people who install packages through other methods, especially in environments that have large sys-admin teams that aren''t always on the exact same page. So in essence, how does puppet deal with remediation of unapproved changes for things it doesn''t have specifically configured in its configs? I can''t see a way to say ''These are the packages I want installed, these optional ones are ok, but anything else, erase if it gets installed''. Does this fall back on having to run an auditing tool and just dealing with the alert manually? ( or then adding it into puppet and saying ''dont allow this xyz package to be installed anymore'' ) This has more applications, such as apache and using an httpd.conf directory. If httpd.conf is a directory, then apache reads all configurations in that directory. What can I do in puppet to prevent someone from dropping in a config file into that directory? Thanks. sh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
hajducko@gmail.com wrote:> So in essence, how does puppet deal with remediation of unapproved > changes for things it doesn''t have specifically configured in its > configs? I can''t see a way to say ''These are the packages I want > installed, these optional ones are ok, but anything else, erase if it > gets installed''. Does this fall back on having to run an auditing tool > and just dealing with the alert manually? ( or then adding it into > puppet and saying ''dont allow this xyz package to be installed > anymore'' )Puppet doesn''t address that at all. Things that are not explicitly managed by Puppet are left as they are. You can write rules for that, though. Maintain a file of all packages that are allowed to be installed, and do something like: exec { "rpm -e `rpm -qa --qf ''%{NAME}\\n'' | fgrep -vx -f allowed_packages`": path => "/bin:/usr/bin", onlyif => "rpm -qa --qf ''%{NAME}\\n'' | fgrep -vx -f allowed_packages"; } (Untested, and assuming you use an RPM based system.) Note however that this can break things when packages get updated. It happens from time to time that a new version of a package gets new dependencies, and updating it pulls in those new packages. If you then let Puppet remove those "unauthorized" packages, you break your system. Similarly, sometimes packages are renamed, for example ethereal to wireshark, or mozilla to seamonkey. So be careful when you do things like this.> This has more applications, such as apache and using an httpd.conf > directory. If httpd.conf is a directory, then apache reads all > configurations in that directory. What can I do in puppet to prevent > someone from dropping in a config file into that directory?This, you should be able to handle with the purge parameter to the file type. /Thomas Bellman --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
> I can''t see a way to say ''These are the packages I want >installed, these optional ones are ok, but anything else, erase if it gets installed''.Back last year while I was playing with pkgsync, I found its -k flag (normally specified) is the key to this part. When absent, it will remove every package not in the ''must'', ''may have'', or dependencies lists. As a result, one day puppet and pkgsync configured some *very* lean cluster nodes with just enough packages to run xemacs21, build-essential, stow, and ssmtp. No ssh, no less, and no ps, to name a few. Pkgsync is not suitable for my needs at the moment, but it may work for you. -- Mike Renfro / R&D Engineer, Center for Manufacturing Research 931 372-3601 / Tennessee Technological University --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 20, 2008, at 3:00 AM, hajducko@gmail.com wrote:> > So we''re evaluating some configuration management/auditing tools and > we''re checking out the open-source avenue. At the moment, we''re > looking at BladeLogic ( I''m sure Luke is laughing ... ), HP OpsWare > and puppet on the open source side.Hey, I''m a happy guy, I''m always laughing. :)> > One question I have that I have not been able to deduce from the > documentation or the LISA presentations is how puppet can deal with > the unknown. For instance, with packages, how do I prevent or notify > about packages that get installed that I don''t want installed, without > having to list every package that could ever possibly be installed on > the system?This is something I''ve long wanted but haven''t taken the time to flesh out. Most of the work is done, but not quite. In looking at the package type, I''ve foolishly set the default value of ''ensure'' to ''installed''. If this weren''t the case, then you could list out all of the packages, optionally specifying ''ensure => installed'' as you want and otherwise just mentioning the package so Puppet knows you care; then, you use the ''resources'' type: resources { package: purge => true } This is a touch clumsy, but it basically says, get rid of any packages that aren''t mentioned in the configuration. I think this is basically what you want. I''ve been meaning to go through the list of types and change them so that none have a default value for ''ensure'', which would make this easier. Really, though, what''s been missing is someone saying, "I want this feature, and I care enough to provide it or pay for it". I can basically promise you that if you spent, say, 25% of the purchase price of either BladeLogic or OpsWare on new development in Puppet, you''d have all the features you want in this area. Probably for a lot less than that.> This has more applications, such as apache and using an httpd.conf > directory. If httpd.conf is a directory, then apache reads all > configurations in that directory. What can I do in puppet to prevent > someone from dropping in a config file into that directory?As Mike said, directories can be easily purged, which means removing any files that aren''t being managed by Puppet. -- While one person hesitates because he feels inferior, the other is busy making mistakes and becoming superior. -- Henry C. Link --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
--On March 20, 2008 11:03:57 AM +0100 Thomas Bellman <bellman@nsc.liu.se> wrote:>> So in essence, how does puppet deal with remediation of unapproved >> changes for things it doesn''t have specifically configured in its >> configs? I can''t see a way to say ''These are the packages I want >> installed, these optional ones are ok, but anything else, erase if it >> gets installed''. Does this fall back on having to run an auditing tool >> and just dealing with the alert manually? ( or then adding it into >> puppet and saying ''dont allow this xyz package to be installed >> anymore'' ) > > Puppet doesn''t address that at all. Things that are not explicitly > managed by Puppet are left as they are.To be clear, Puppet doesn''t address that FOR PACKAGES. Puppet does address this quite well for things like users. You can set user purging to true and any users on the system that wasn''t added or maintained by puppet get removed. You can even set what the min uid is to check (to prevent having to add all system accounts to puppet). -- Digant C Kasundra, Linux Tech Lead Information Technology Services, Stanford University --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 20, 2008, at 1:35 PM, Digant C Kasundra wrote:> To be clear, Puppet doesn''t address that FOR PACKAGES. Puppet does > address > this quite well for things like users. You can set user purging to > true > and any users on the system that wasn''t added or maintained by > puppet get > removed. You can even set what the min uid is to check (to prevent > having > to add all system accounts to puppet).This actually works for any resource type, not just users. Note that ''purge'' will remove any resource that isn''t already being managed by Puppet; please test extensively before you deploy something using this, as it''s inherently destructive. -- Nature and nature''s laws lay hid in night, God said, "Let Newton be," and all was light. It did not last; the devil howling "Ho! Let Einstein be!" restored the status quo. --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
--On March 20, 2008 2:23:42 PM -0500 Luke Kanies <luke@madstop.com> wrote:>> To be clear, Puppet doesn''t address that FOR PACKAGES. Puppet does >> address >> this quite well for things like users. You can set user purging to >> true >> and any users on the system that wasn''t added or maintained by >> puppet get >> removed. You can even set what the min uid is to check (to prevent >> having >> to add all system accounts to puppet). > > > This actually works for any resource type, not just users. Note that > ''purge'' will remove any resource that isn''t already being managed by > Puppet; please test extensively before you deploy something using > this, as it''s inherently destructive.Yup. I recommend running with noop. :) -- Digant C Kasundra, Linux Tech Lead Information Technology Services, Stanford University --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
Sorry, meant to reply back earlier to this and thank everyone for the responses. Definitely helpful. :) As a result of some recent discussions, we''ve basically decided to implement Puppet from the time being for a couple of reasons. a) It''s open source, which means it''s free. b) It''s alot easier to setup and get going with, rather than the extensive process of either OpsWare or BL. c) It''s available now, where as we''d have to go thru the lengthy purchasing of one of those two suites, approval, etc. d) I''m the sysadmin and I don''t have time for my directors to sit around for 3 months to make up their minds while users go rampaging around my systems. In all seriousness, we probably will move from Puppet to one of those two suites eventually ( our parent company is eval''ing them and we''ll probably pick whatever they pick ), but it will like one of those projects that people will always say are going to happen, but never do. Like 3 years ago when we were told that we were moving off AIX and Informix to Linux / Oracle... yeah. :) In the meantime, I''ll have Puppet to save my sanity. Thanks again. -- sh On Mar 20, 4:17 pm, Digant C Kasundra <dig...@stanford.edu> wrote:> --On March 20, 2008 2:23:42 PM -0500 Luke Kanies <l...@madstop.com> wrote: > > >> To be clear, Puppet doesn''t address that FOR PACKAGES. Puppet does > >> address > >> this quite well for things like users. You can set user purging to > >> true > >> and any users on the system that wasn''t added or maintained by > >> puppet get > >> removed. You can even set what the min uid is to check (to prevent > >> having > >> to add all system accounts to puppet). > > > This actually works for any resource type, not just users. Note that > > ''purge'' will remove any resource that isn''t already being managed by > > Puppet; please test extensively before you deploy something using > > this, as it''s inherently destructive. > > Yup. I recommend running with noop. :) > > -- > Digant C Kasundra, Linux Tech Lead > Information Technology Services, Stanford University--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Mar 22, 2008, at 2:48 AM, hajducko@gmail.com wrote:> > Sorry, meant to reply back earlier to this and thank everyone for the > responses. Definitely helpful. :) > > As a result of some recent discussions, we''ve basically decided to > implement Puppet from the time being for a couple of reasons. > > a) It''s open source, which means it''s free. > b) It''s alot easier to setup and get going with, rather than the > extensive process of either OpsWare or BL. > c) It''s available now, where as we''d have to go thru the lengthy > purchasing of one of those two suites, approval, etc. > d) I''m the sysadmin and I don''t have time for my directors to sit > around for 3 months to make up their minds while users go rampaging > around my systems. > > In all seriousness, we probably will move from Puppet to one of those > two suites eventually ( our parent company is eval''ing them and we''ll > probably pick whatever they pick ), but it will like one of those > projects that people will always say are going to happen, but never > do. Like 3 years ago when we were told that we were moving off AIX > and Informix to Linux / Oracle... yeah. :)Well, hopefully you''ll find that Puppet and its community are awesome enough that you don''t need to go with one of the big commercial tools. Either way, in the meantime, welcome to the fun. -- I love deadlines. I like the whooshing sound they make as they fly by. --Douglas Adams --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---
On Thu, 2008-03-20 at 01:00 -0700, hajducko@gmail.com wrote:> One question I have that I have not been able to deduce from the > documentation or the LISA presentations is how puppet can deal with > the unknown. For instance, with packages, how do I prevent or notify > about packages that get installed that I don''t want installed, without > having to list every package that could ever possibly be installed on > the system?I''d think of packages here as a special case - other resources like users, services etc. are probably best kept away with purge => true, but if you follow a similar approach with packages I think you''d wind up in a whack-a-mole situation where sets of available packages and dependencies between them change too frequently to make a similar solution with puppet workable. For packages, I''d address the problem at the source, i.e. your local package server where every client gets its packages from: if you''re on an RPM-based distro, have some internal ''master'' yum repos that contain the packages that are ok to have installed on machines (possibly subdivided into a small number of repos for specific purposes, like secure machines, appservers etc.) and mandate that packages can only be installed from one of these master repos - that can be enforced relatively easily with puppet, since you only need to keep tabs on the config for your package management tool on the clients. You''d feed the master repos out of a local mirror of upstream repos, and define some workflow how upstream packages wind up in your master repos (this also lets you divide your master repos into testing/dev/prod repos etc. with flows between them) For yum, you''d wind up writing some custom scripts, though pulp will hopefully address that eventually - I''d be surprised if there aren''t people on this list who have scripted something like this. David --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com To unsubscribe from this group, send email to puppet-users-unsubscribe@googlegroups.com For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en -~----------~----~----~----~------~----~------~--~---