Howdy, Before I go about writing one myself, anyone out there written a software inventory module/fact for gathering a list of all installed rpms/debs on a system? Got a few ideas floating around in my head, but wanted to see if/what other folks have done .. -- I''ve seen things you people wouldn''t believe. Attack ships on fire off the shoulder of Orion. I watched C-beams glitter in the dark near the Tannhauser gate. All those moments will be lost in time... like tears in rain... Time to die. -- 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 Wed, Sep 21, 2011 at 9:45 AM, Glenn Bailey <replicant@dallaslamers.org>wrote:> Howdy, > > Before I go about writing one myself, anyone out there written a > software inventory module/fact for gathering a list of all installed > rpms/debs on a system? Got a few ideas floating around in my head, but > wanted to see if/what other folks have done .. >you can already do this with: puppet resource package this will generate a manifests that represents all of the packages installed on a system.> -- > I''ve seen things you people wouldn''t believe. Attack ships on fire off > the shoulder of Orion. I watched C-beams glitter in the dark near the > Tannhauser gate. All those moments will be lost in time... like tears > in rain... Time to die. > > -- > 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. > >-- "Join us for PuppetConf <http://bit.ly/puppetconfsig>, September 22nd and 23rd in Portland, OR." <http://bit.ly/puppetconfsig> -- 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.
Well, puppet does include a native facility for doing this... try running and see if the output meets your needs: "puppet resource package" I guess the question before extending this to a module, is what exactly do you want to do with the data? -Brian On Wed, Sep 21, 2011 at 12:45 PM, Glenn Bailey <replicant@dallaslamers.org>wrote:> Howdy, > > Before I go about writing one myself, anyone out there written a > software inventory module/fact for gathering a list of all installed > rpms/debs on a system? Got a few ideas floating around in my head, but > wanted to see if/what other folks have done .. > > -- > I''ve seen things you people wouldn''t believe. Attack ships on fire off > the shoulder of Orion. I watched C-beams glitter in the dark near the > Tannhauser gate. All those moments will be lost in time... like tears > in rain... Time to die. > > -- > 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. > >-- <http://aws.amazon.com/solutions/solution-providers/brandorr/> -- 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.
>> Before I go about writing one myself, anyone out there written a >> software inventory module/fact for gathering a list of all installed >> rpms/debs on a system? Got a few ideas floating around in my head, but >> wanted to see if/what other folks have done .. > > you can already do this with: > > puppet resource package > > this will generate a manifests that represents all of the packages installed > on a system.Let me re-phrase a bit, I''m trying to get a fact setup to collect this information and I can report of my Puppet DB. Was just thinking of doing an auto-increment so it would be something like "package0 => package_name-version" "package1 => package_name-version" etc. Parsing "puppet resource package" will make it easier for writing a single module for rpm/deb .. -- 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.
its also pretty easy to programatically access the information, which could make parsing it easier:>require ''puppet'' >Puppet::Type.type(:package).instancesOn Wed, Sep 21, 2011 at 10:53 AM, Glenn Bailey <replicant@dallaslamers.org>wrote:> >> Before I go about writing one myself, anyone out there written a > >> software inventory module/fact for gathering a list of all installed > >> rpms/debs on a system? Got a few ideas floating around in my head, but > >> wanted to see if/what other folks have done .. > > > > you can already do this with: > > > > puppet resource package > > > > this will generate a manifests that represents all of the packages > installed > > on a system. > > Let me re-phrase a bit, I''m trying to get a fact setup to collect this > information and I can report of my Puppet DB. Was just thinking of > doing an auto-increment so it would be something like "package0 => > package_name-version" "package1 => package_name-version" etc. Parsing > "puppet resource package" will make it easier for writing a single > module for rpm/deb .. > > -- > 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. > >-- "Join us for PuppetConf <http://bit.ly/puppetconfsig>, September 22nd and 23rd in Portland, OR." <http://bit.ly/puppetconfsig> -- 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 Sep 21, 10:53 am, Glenn Bailey <replic...@dallaslamers.org> wrote:> >> Before I go about writing one myself, anyone out there written a > >> software inventory module/fact for gathering a list of all installed > >> rpms/debs on a system? Got a few ideas floating around in my head, but > >> wanted to see if/what other folks have done .. > > > you can already do this with: > > > puppet resource package > > > this will generate a manifests that represents all of the packages installed > > on a system. > > Let me re-phrase a bit, I''m trying to get a fact setup to collect this > information and I can report of my Puppet DB. Was just thinking of > doing an auto-increment so it would be something like "package0 => > package_name-version" "package1 => package_name-version" etc. Parsing > "puppet resource package" will make it easier for writing a single > module for rpm/deb ..You could distribute a custom fact like this one: https://github.com/ripienaar/facter-facts/tree/master/facts-dot-d Then you can use a cron job that runs "rpm -qa" and populates /etc/ facts.d/pkgs.txt like so: pkg0=httpd-2.2.15-5.el6.centos.x86_64 pkg1=nscd-2.12-1.7.el6.x86_64 . . or even pkgs=httpd-2.2.15-5.el6.centos.x86_64:nscd-2.12-1.7.el6.x86_64:other_pkgs_colon_seperated Either way, it doesn''t look elegant if a large number of packages is installed. If you care about certain packages only, you can populate the file with those package names. Or you can populate it with the output of "yum check-update" or "apt- get upgrade -V" -- 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.
----- Original Message -----> its also pretty easy to programatically access the information, which > could make parsing it easier: > > >require ''puppet'' > >Puppet::Type.type(:package).instancesthe puppetral mcollective agent does something similar in a generic fashion so you can just query the network and gather this info. -- 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 Wed, Sep 21, 2011 at 7:45 PM, Glenn Bailey <replicant@dallaslamers.org> wrote:> Howdy, > > Before I go about writing one myself, anyone out there written a > software inventory module/fact for gathering a list of all installed > rpms/debs on a system? Got a few ideas floating around in my head, but > wanted to see if/what other folks have done ..Not sure what exactly you are looking for, but a few years ago I wrote a rails [1] app to collect and show/search etc all packages across all hosts etc in a db Ohad [1] https://github.com/ohadlevy/dish> > -- > I''ve seen things you people wouldn''t believe. Attack ships on fire off > the shoulder of Orion. I watched C-beams glitter in the dark near the > Tannhauser gate. All those moments will be lost in time... like tears > in rain... Time to die. > > -- > 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. > >-- 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.
Does anyone else have any concern about populating custom facts that list ALL packages installed on a system? My sense is that it has the potential to create a lot of overhead for facter, and in turn puppet itself. (A typical linux system will have hundreds of packages installed). I also don''t think putting the data in facter as key value pairs necessarily presents the data in a useful form, but that may be in the eye of the beholder. -Brian On Sep 21, 3:14 pm, Ashay <ashay.hum...@gmail.com> wrote:> On Sep 21, 10:53 am, Glenn Bailey <replic...@dallaslamers.org> wrote: > > > >> Before I go about writing one myself, anyone out there written a > > >> software inventory module/fact for gathering a list of all installed > > >> rpms/debs on a system? Got a few ideas floating around in my head, but > > >> wanted to see if/what other folks have done .. > > > > you can already do this with: > > > > puppet resource package > > > > this will generate a manifests that represents all of the packages installed > > > on a system. > > > Let me re-phrase a bit, I''m trying to get a fact setup to collect this > > information and I can report of my Puppet DB. Was just thinking of > > doing an auto-increment so it would be something like "package0 => > > package_name-version" "package1 => package_name-version" etc. Parsing > > "puppet resource package" will make it easier for writing a single > > module for rpm/deb .. > > You could distribute a custom fact like this one:https://github.com/ripienaar/facter-facts/tree/master/facts-dot-d > > Then you can use a cron job that runs "rpm -qa" and populates /etc/ > facts.d/pkgs.txt like so: > > pkg0=httpd-2.2.15-5.el6.centos.x86_64 > pkg1=nscd-2.12-1.7.el6.x86_64 > . > . > > or even > > pkgs=httpd-2.2.15-5.el6.centos.x86_64:nscd-2.12-1.7.el6.x86_64:other_pkgs_colon_seperated > > Either way, it doesn''t look elegant if a large number of packages is > installed. > > If you care about certain packages only, you can populate the file > with those package names. > > Or you can populate it with the output of "yum check-update" or "apt- > get upgrade -V"-- 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 Wed, Sep 21, 2011 at 9:45 AM, Glenn Bailey <replicant@dallaslamers.org> wrote:> Howdy, > > Before I go about writing one myself, anyone out there written a > software inventory module/fact for gathering a list of all installed > rpms/debs on a system? Got a few ideas floating around in my head, but > wanted to see if/what other folks have done ..We''ve written some custom facts that return a JSON string and then we wrote a custom function that uses PSON.parse() to process and return the native data. Since puppet supports arrays and dictionaries, this works well. One problem is if you have any Nones/Nulls in your JSON, PSON.parse() doesn''t handle them right. Once bubbled up to puppet, they don''t come out as undef.. they come out as some strange type that puppet doesn''t recognize as false yet has no value. So we post process the PSON.parse() and clean out the Ruby nil''s and just make them "". -- 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 Wed, Sep 21, 2011 at 2:29 PM, Brian Gupta <brian.gupta@brandorr.com> wrote:> Does anyone else have any concern about populating custom facts that > list ALL packages installed on a system? My sense is that it has the > potential to create a lot of overhead for facter, and in turn puppet > itself. (A typical linux system will have hundreds of packages > installed). I also don''t think putting the data in facter as key value > pairs necessarily presents the data in a useful form, but that may be > in the eye of the beholder.Filling this use case was a big driver behind moving catalog requests from GET to POST in Puppet 2.7.x In earlier versions you''ll often run into limitations with the amount of data being sent to the server with thousands of packages, but I did some tests in early 2.7.x with real-world Linux installs and facts for every installed package, and it worked reasonably well.> > -Brian > > On Sep 21, 3:14 pm, Ashay <ashay.hum...@gmail.com> wrote: >> On Sep 21, 10:53 am, Glenn Bailey <replic...@dallaslamers.org> wrote: >> >> > >> Before I go about writing one myself, anyone out there written a >> > >> software inventory module/fact for gathering a list of all installed >> > >> rpms/debs on a system? Got a few ideas floating around in my head, but >> > >> wanted to see if/what other folks have done .. >> >> > > you can already do this with: >> >> > > puppet resource package >> >> > > this will generate a manifests that represents all of the packages installed >> > > on a system. >> >> > Let me re-phrase a bit, I''m trying to get a fact setup to collect this >> > information and I can report of my Puppet DB. Was just thinking of >> > doing an auto-increment so it would be something like "package0 => >> > package_name-version" "package1 => package_name-version" etc. Parsing >> > "puppet resource package" will make it easier for writing a single >> > module for rpm/deb .. >> >> You could distribute a custom fact like this one:https://github.com/ripienaar/facter-facts/tree/master/facts-dot-d >> >> Then you can use a cron job that runs "rpm -qa" and populates /etc/ >> facts.d/pkgs.txt like so: >> >> pkg0=httpd-2.2.15-5.el6.centos.x86_64 >> pkg1=nscd-2.12-1.7.el6.x86_64 >> . >> . >> >> or even >> >> pkgs=httpd-2.2.15-5.el6.centos.x86_64:nscd-2.12-1.7.el6.x86_64:other_pkgs_colon_seperated >> >> Either way, it doesn''t look elegant if a large number of packages is >> installed. >> >> If you care about certain packages only, you can populate the file >> with those package names. >> >> Or you can populate it with the output of "yum check-update" or "apt- >> get upgrade -V" > > -- > 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. > >-- Nigel Kersten Product Manager, Puppet Labs Join us for PuppetConf <http://www.bit.ly/puppetconfsig> Sept 22/23 Portland, Oregon, USA. -- 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.
>> Before I go about writing one myself, anyone out there written a >> software inventory module/fact for gathering a list of all installed >> rpms/debs on a system? Got a few ideas floating around in my head, but >> wanted to see if/what other folks have done .. > > We''ve written some custom facts that return a JSON string and then we > wrote a custom function that uses PSON.parse() to process and return > the native data. Since puppet supports arrays and dictionaries, this > works well. > > One problem is if you have any Nones/Nulls in your JSON, PSON.parse() > doesn''t handle them right. Once bubbled up to puppet, they don''t come > out as undef.. they come out as some strange type that puppet doesn''t > recognize as false yet has no value. So we post process the > PSON.parse() and clean out the Ruby nil''s and just make them "".This was sorta my original thought but just doing a ; delimited string with all the packages. I avoided this as the "value" field in the "fact_values" table by default is a text field which only supports 65535 characters. Doing a quick wc on the rpm -qa shows me only 15300 characters, although on some systems this may double. I originally didn''t wanna muck w/the default scheme, but I don''t see how changing the field to a mediumtext would cause much harm, I may just try that. But the json idea is awesome, way more robust than a simple ; delimited idea, think I''ll give that a shot, thanks! -- 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.