I''m trying to get the proper versions of some gems installed on some debian servers. package { "rails": provider => gem, ensure => "1.1.6", } package { "daemons": provider => gem, ensure => "1.0.10", } package { "memcache-client": provider => gem, ensure => "1.0.3", } package { "fastthread ": provider => gem, ensure => "1.0.1", } package { "mongrel": provider => gem, ensure => "1.0.2", } package { "mongrel_cluster ": provider => gem, ensure => "1.0.5", } package { "cached_model": provider => gem, ensure => "1.2.1", } package { "ferret": provider => gem, ensure => "0.11.3", } package { "mongrel_upload_progress": provider => gem, ensure => "0.2.2", } package { "json": provider => gem, ensure => "1.1.2", } package { "contacts": provider => gem, ensure => "1.0.11", } package { "mysql": provider => gem, ensure => "2.7", } package { "mime-types": provider => gem, ensure => installed, } package { "eventmachine": provider => gem, ensure => "0.10.0", } package { "rubyforge": provider => gem, ensure => "0.4.5", } package { "hoe": provider => gem, ensure => "1.5.1", } package { "swiftiply": provider => gem, ensure => "0.6.1.1", } package { "xml-simple": provider => gem, ensure => "1.0.11", } package { "youtube": provider => gem, ensure => "0.8.6", } Most of them are working fine, but here are a few issues I am stumped on. 1. Sequence - swiftiply depends on eventmachine and somehow it is failing on the dependency because eventmachine is not there yet...puppetd reports: puppetd[9293]: (//Node[celina-ss]/app-server/Package[swiftiply]/ensure) change from absent to 0.6.1.1 failed: Could not update: Execution of ''/usr/bin/gem install -v 0.6.1.1 --include-dependencies swiftiply'' returned 256: Select which gem to install for your platform (i486-linux) 1. eventmachine 0.12.0 (ruby) 2. eventmachine 0.12.0 (i386-mswin32) 3. eventmachine 0.10.0 (ruby) 4. eventmachine 0.9.0 (ruby) 5. eventmachine 0.8.1 (ruby) 6. eventmachine 0.8.1 (i386-mswin32) 7. Cancel installation > ERROR: While executing gem ... (NoMethodError) undefined method `strip'' for nil:NilClass at /etc/puppet/manifests/classes/app-server.pp:31 swiftiply installs automatically on the subsequent run (once eventmachine is there). Is this the normal/expected behavior? Or is there a way to specify a sequence order to the packages? I figured it was top-down. 2. More than one version. rubyforge 1.0.0 and 0.4.5 end up installed. This happens with others also (hoe, memcache-client). This in spite of puppetd which reports: puppetd[9894]: (//Node[celina-ss]/app-server/Package[rubyforge]/ensure) ensure changed ''1.0.0'' to ''0.4.5'' 3. Certain gems cannot be installed by specific version (mongrel, fastthread, etc). These are only installable via command-line gem install because they throw up a choice of versions + platform combinations e.g. 1. 1.0.2 (ruby) 2. 1.0.2 (win32) Is there some way around this? Thanks. -- Mark Foster - Sr. Systems Engineer - BitPusher, LLC We push your bits so you don''t have to! http://www.bitpusher.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 -~----------~----~----~----~------~----~------~--~---
Mark Foster wrote:> Is this the normal/expected behavior? Or is > there a way to specify a sequence order to the packages? I figured it > was top-down. >It''s not top down - make use of a resource dependancy chain - require, etc. package { "blah": ensure => latest, provider => gem, require => [ Package[a], Package[b] ]; }> 2. More than one version. rubyforge 1.0.0 and 0.4.5 end up installed. > This happens with others also (hoe, memcache-client). This in spite of > puppetd which reports: > puppetd[9894]: (//Node[celina-ss]/app-server/Package[rubyforge]/ensure) > ensure changed ''1.0.0'' to ''0.4.5'' >Not sure about this one. The gem provider is like a redheaded child in the Puppet world :(> 3. Certain gems cannot be installed by specific version (mongrel, > fastthread, etc). These are only installable via command-line gem > install because they throw up a choice of versions + platform > combinations e.g. > 1. 1.0.2 (ruby) > 2. 1.0.2 (win32) > > Is there some way around this? >Not sure about that one either.. Anyone else? Regards, AJ --~--~---------~--~----~------------~-------~--~----~ 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 Jun 17, 2008, at 5:22 PM, Mark Foster wrote:> > I''m trying to get the proper versions of some gems installed on some > debian servers. > package { "rails": provider => gem, ensure => > "1.1.6", } > package { "daemons": provider => gem, ensure => > "1.0.10", } > package { "memcache-client": provider => gem, ensure => > "1.0.3", }Urgh: Package { provider => gem } package { rails: ensure => "1.1.6"; daemons: ensure => "1.0.10"; memcache-client: => "1.0.3"; ... } Lots more readable, lots less space.> > Most of them are working fine, but here are a few issues I am > stumped on. > 1. Sequence - swiftiply depends on eventmachine and somehow it is > failing on the dependency because eventmachine is not there > yet...puppetd reports: > puppetd[9293]: (//Node[celina-ss]/app-server/Package[swiftiply]/ > ensure) > change from absent to 0.6.1.1 failed: Could not update: Execution of > ''/usr/bin/gem install -v 0.6.1.1 --include-dependencies swiftiply'' > returned 256: Select which gem to install for your platform > (i486-linux) 1. eventmachine 0.12.0 (ruby) 2. eventmachine 0.12.0 > (i386-mswin32) 3. eventmachine 0.10.0 (ruby) 4. eventmachine 0.9.0 > (ruby) 5. eventmachine 0.8.1 (ruby) 6. eventmachine 0.8.1 > (i386-mswin32) 7. Cancel installation > ERROR: While executing > gem ... > (NoMethodError) undefined method `strip'' for nil:NilClass at > /etc/puppet/manifests/classes/app-server.pp:31 > swiftiply installs automatically on the subsequent run (once > eventmachine is there). Is this the normal/expected behavior? Or is > there a way to specify a sequence order to the packages? I figured it > was top-down.Upgrade gems, unfortunately. It''s apparently expected behaviour if you''re the guy who wrote gems, because he sure fought fixing it. :/> > 2. More than one version. rubyforge 1.0.0 and 0.4.5 end up installed. > This happens with others also (hoe, memcache-client). This in spite of > puppetd which reports: > puppetd[9894]: (//Node[celina-ss]/app-server/Package[rubyforge]/ > ensure) > ensure changed ''1.0.0'' to ''0.4.5''No real idea what''s going on here.> > 3. Certain gems cannot be installed by specific version (mongrel, > fastthread, etc). These are only installable via command-line gem > install because they throw up a choice of versions + platform > combinations e.g. > 1. 1.0.2 (ruby) > 2. 1.0.2 (win32)Assuming the gem upgrade doesn''t fix this (i think it does), the only real solution is to download and install the packages manually (or put them on an nfs server or something, always better). -- My favorite was a professor at a University I Used To Be Associated With who claimed that our requirement of a non-alphabetic character in our passwords was an abridgement of his freedom of speech. -- Jacob Haller --------------------------------------------------------------------- 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 Tue, Jun 17, 2008 at 3:22 PM, Mark Foster <mfoster@bitpusher.com> wrote:> > I''m trying to get the proper versions of some gems installed on some > debian servers.<..snip..>> Most of them are working fine, but here are a few issues I am stumped on. > 1. Sequence - swiftiply depends on eventmachine and somehow it is > failing on the dependency because eventmachine is not there > yet...puppetd reports: > puppetd[9293]: (//Node[celina-ss]/app-server/Package[swiftiply]/ensure) > change from absent to 0.6.1.1 failed: Could not update: Execution of > ''/usr/bin/gem install -v 0.6.1.1 --include-dependencies swiftiply'' > returned 256: Select which gem to install for your platform > (i486-linux) 1. eventmachine 0.12.0 (ruby) 2. eventmachine 0.12.0 > (i386-mswin32) 3. eventmachine 0.10.0 (ruby) 4. eventmachine 0.9.0 > (ruby) 5. eventmachine 0.8.1 (ruby) 6. eventmachine 0.8.1 > (i386-mswin32) 7. Cancel installation > ERROR: While executing gem ... > (NoMethodError) undefined method `strip'' for nil:NilClass at > /etc/puppet/manifests/classes/app-server.pp:31 > swiftiply installs automatically on the subsequent run (once > eventmachine is there). Is this the normal/expected behavior? Or is > there a way to specify a sequence order to the packages? I figured it > was top-down.Install a new version of rubygems, and let swiftiply install eventmachine for you if puppet gets the order wrong.> 2. More than one version. rubyforge 1.0.0 and 0.4.5 end up installed. > This happens with others also (hoe, memcache-client). This in spite of > puppetd which reports: > puppetd[9894]: (//Node[celina-ss]/app-server/Package[rubyforge]/ensure) > ensure changed ''1.0.0'' to ''0.4.5''This is an issue with a gem requiring an old version of a library, and your being allowed to have more than one gem version installed at a time. You are liable to wind up with an issue where one of your depenencies breaks with rubyforge 1.0.0, and another requires it in advance.> 3. Certain gems cannot be installed by specific version (mongrel, > fastthread, etc). These are only installable via command-line gem > install because they throw up a choice of versions + platform > combinations e.g. > 1. 1.0.2 (ruby) > 2. 1.0.2 (win32) > > Is there some way around this?Run: rubygems upgrade --system Followed by: cp /usr/bin/gems1.8 /usr/bin/gems Thereby breaking Debian''s incredibly broken rubygems patches, giving you at least a bit of sanity, and a functioning version of gem. Stick that in your your base provider and make it run early. :)> Thanks.We also worked around much of the inherent chaos in rubygems (like out of sync mirrors, for example) by setting up local gem repo''s for all our clients, and using a gem_package { "foo" } definition instead of the native type. Adam -- HJK Solutions - We Launch Startups - http://www.hjksolutions.com Adam Jacob, Senior Partner T: (206) 508-4759 E: adam@hjksolutions.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 -~----------~----~----~----~------~----~------~--~---
Thanks to everyone for the swift and detailed replies. I think we''ll be setting up a local gem server with _just_ the gems we want, that seems like the easiest win. As for the version conflicts, is there another attribute we can pass that says "this version AND ONLY this version" or perhaps adding that ability into the gem provider? I know that gentoo has similar quirks... does the package provider model have something to accommodate such a thing? Adam Jacob wrote:> We also worked around much of the inherent chaos in rubygems (like out > of sync mirrors, for example) by setting up local gem repo''s for all > our clients, and using a gem_package { "foo" } definition instead of > the native type. >This is a custom package provider? --~--~---------~--~----~------------~-------~--~----~ 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 Tue, Jun 17, 2008 at 8:41 PM, Mark Foster <mfoster@bitpusher.com> wrote:>> We also worked around much of the inherent chaos in rubygems (like out >> of sync mirrors, for example) by setting up local gem repo''s for all >> our clients, and using a gem_package { "foo" } definition instead of >> the native type. >> > This is a custom package provider?A definition that calls gem --source http://gems somegem --version X, but only if the gem doesn''t appear in the gem list --local. Hit me up off list and I''ll be happy to share. Adam -- HJK Solutions - We Launch Startups - http://www.hjksolutions.com Adam Jacob, Senior Partner T: (206) 508-4759 E: adam@hjksolutions.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 -~----------~----~----~----~------~----~------~--~---