I tried to install the ''mongrel'' gem tonight via puppet in an
attempt to
migrate from webrick to mongrel as described on the puppet site[1]. I
added the following to my manifest:
package {
"rubygems":
ensure => installed;
"mongrel":
ensure => installed,
provider => gem,
require => Package["rubygems"];
}
and then ran puppetd --test by hand.
The first time it ran, I got this error:
err: Could not create mongrel: Parameter provider failed: Provider
''gem''
is not functional on this platform
err: Parameter provider failed: Provider ''gem'' is not
functional on this
platform
Thats interesting, because I asked the mongrel gem to require the package
rubygems (which on Debian contains the /usr/bin/gem program) to be
installed before it attempted to install that gem. Any ideas why this
happened? Later on in the run, puppet installed the ''rubygems''
package,
and so I decided now I just have to run it a second time.
The second run resulted in what appears to be gem prompting me for which
version of mongrel to install. I solved this problem, but in case someone
else runs into it, here is what happened:
err: //kakapo/puppetmaster/Package[mongrel]/ensure: change from absent to
present failed: Execution of ''/usr/bin/gem install
--include-dependencies
mongrel'' returned 256: Bulk updating Gem source index for: http://
gems.rubyforge.org
Select which gem to install for your platform (i486-linux)
1. mongrel 1.1.1 (ruby)
2. mongrel 1.1 (mswin32)
3. mongrel 1.1 (java)
4. mongrel 1.1 (ruby)
5. mongrel 1.0.4 (mswin32)
6. mongrel 1.0.4 (ruby)
7. mongrel 1.0.3 (ruby)
8. mongrel 1.0.2 (mswin32)
9. mongrel 1.0.2 (ruby)
... for about 20 more options....
> ERROR: While executing gem ... (NoMethodError)
undefined method `strip'' for nil:NilClass
Since the gem provider has version support according to the TypeReference
[2], I specified the version in the gem install, and it seemed to figure
it out:
"mongrel":
ensure => "1.1.1",
provider => gem,
require => Package["rubygems"];
}
1. https://reductivelabs.com/trac/puppet/wiki/UsingMongrel
2. http://reductivelabs.com/trac/puppet/wiki/TypeReference#package
On Tue, Nov 13, 2007 at 04:02:01AM +0000, Micah Anderson wrote:> I tried to install the ''mongrel'' gem tonight via puppet in an attempt to > migrate from webrick to mongrel as described on the puppet site[1]. I > added the following to my manifest: > > package { > "rubygems": > ensure => installed; > > "mongrel": > ensure => installed, > provider => gem, > require => Package["rubygems"]; > } > > and then ran puppetd --test by hand. > > The first time it ran, I got this error: > > err: Could not create mongrel: Parameter provider failed: Provider ''gem'' > is not functional on this platform > err: Parameter provider failed: Provider ''gem'' is not functional on this > platform > > Thats interesting, because I asked the mongrel gem to require the package > rubygems (which on Debian contains the /usr/bin/gem program) to be > installed before it attempted to install that gem. Any ideas why this > happened? Later on in the run, puppet installed the ''rubygems'' package, > and so I decided now I just have to run it a second time.The error is being produced *before* the run, because at that time the gem provider isn''t available. I think the only way to solve the problem would be a change to Puppet, to put resources that have invalid providers specified to one side, run all the resources that *can* be run, then try and revalidate the providers and see if any resources that were boned before now have valid providers. Alternately, don''t use gems and stick to Real Packages. I''m pretty sure someone has put together mongrel debs by now. - Matt
On 13/11/2007, at 5.02, Micah Anderson wrote:> Since the gem provider has version support according to the > TypeReference > [2], I specified the version in the gem install, and it seemed to > figure > it out: > > "mongrel": > ensure => "1.1.1", > provider => gem, > require => Package["rubygems"]; > }Thanks! I''ve tried to figure out how to solve this. It looks like this cuts it... -- Med venlig hilsen Juri Rischel Jensen Fab:IT ApS Vesterbrogade 50 DK-1620 København Tlf: 70 202 407 / Fax: 33 313 640 www.fab-it.dk / juri@fab-it.dk
On 13/11/2007, at 5.44, Matt Palmer wrote:> Alternately, don''t use gems and stick to Real Packages. I''m pretty > sure > someone has put together mongrel debs by now.Actually - not that I know of, unfortunately. :-( -- Med venlig hilsen Juri Rischel Jensen Fab:IT ApS Vesterbrogade 50 DK-1620 København Tlf: 70 202 407 / Fax: 33 313 640 www.fab-it.dk / juri@fab-it.dk
computer@cronopios.org
2007-Nov-13 11:38 UTC
module and pluginsinmodules not finding functions
hi, i''ve used the docus * http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation * http://reductivelabs.com/trac/puppet/wiki/PluginsInModules * using the sid (therfore pluginsinmodules-patched) deb of http://packages.debian.org/sid/puppetmaster. ** http://ftp.de.debian.org/debian/pool/main/p/puppet/puppet_0.23.2-13.diff.gz I''ve copied the common module from git://git.black.co.at to /var/lib/puppet/modules/common With the (not mentioned modulepath in puppet.conf (see below)) the puppetmaster finds the module. BUT: "stops" with the following error: err: Could not parse; using old configuration: Unknown function slash_escape at /var/lib/puppet/modules/common/manifests/defines/replace.pp:23 The slash_escape is defined: # grep -ri slash_escape /var/lib/puppet/modules/common/plugins/puppet/parser/functions/slash_escape.rb newfunction(:slash_escape, :type => :rvalue) do |args| I''ve experimented with pluginpath and libdir, but i''m stuck. does anyone sees the missing pieces? Thanks a lot! Andreas ------------------------------------------- /etc/puppet/puppet.conf: [main] logdir=/var/log/puppet vardir=/var/lib/puppet ssldir=/var/lib/puppet/ssl [puppetmasterd] templatedir=/var/lib/puppet/templates storeconfigs=true reports=log modulepath=/var/lib/puppet/modules [puppetd] report=true pluginsync=true pluginsource=puppet://$server/plugins -------------------------------------------
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Juri Rischel Jensen wrote:> On 13/11/2007, at 5.44, Matt Palmer wrote: >> Alternately, don''t use gems and stick to Real Packages. I''m pretty >> sure >> someone has put together mongrel debs by now. > > Actually - not that I know of, unfortunately. :-( >No idea if they are any good or to be trusted but I found these the other day: http://www.repositorios.pr.gov.br/debian/pool/main/m/mongrel/ I don''t speak Portuguese so I can''t guarantee the source but they appear to be compiled by someone in a Brazilian .gov. Regards James Turnbull - -- James Turnbull <james@lovedthanlost.net> - --- Author of Pro Nagios 2.0 (http://www.amazon.com/gp/product/1590596099/) Hardening Linux (http://www.amazon.com/gp/product/1590594444/) - --- PGP Key (http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x0C42DF40) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFHOZFk9hTGvAxC30ARAsyxAKCUkeXOOno+B+6dCYSpI5R4I+Z7aQCgz5/i YjljNLTCz53QrPRonJvqA4E=0wND -----END PGP SIGNATURE-----
On 11/13/2007 5:04 AM, Juri Rischel Jensen wrote:> On 13/11/2007, at 5.44, Matt Palmer wrote: >> Alternately, don''t use gems and stick to Real Packages. I''m pretty >> sure >> someone has put together mongrel debs by now. > > Actually - not that I know of, unfortunately. :-(http://packages.debian.org/lenny/mongrel -- only missing dependencies on a stock Etch system appear to be libgemplugin-ruby and libdaemons-ruby, plus libdaemons-ruby1.8 and libgemplugin-ruby1.8. Those could probably even be grabbed as binary packages from Lenny. I may give that a shot later today. -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University
On 11/12/2007 10:44 PM, Matt Palmer wrote:> Alternately, don''t use gems and stick to Real Packages. I''m pretty sure > someone has put together mongrel debs by now.I''ve just now gotten them built and installed, so no testing yet. But grabbing a few of the binary packages from testing and rebuilding mongrel on etch went without a hitch. Assuming you have an unstable or testing deb-src line in your sources.list, this should work: |> wget http://MIRROR/debian/pool/main/libd/libdaemons-ruby/libdaemons-ruby1.8_1.0.8-1_i386.deb |> wget http://MIRROR/debian/pool/main/libd/libdaemons-ruby/libdaemons-ruby_1.0.8-1_all.deb |> wget http://MIRROR/debian/pool/main/libg/libgemplugin-ruby/libgemplugin-ruby1.8_0.2.2-1_all.deb |> wget http://MIRROR/debian/pool/main/libg/libgemplugin-ruby/libgemplugin-ruby_0.2.2-1_all.deb |> apt-get source mongrel |> apt-get build-dep mongrel |> apt-get install libgems-ruby1.8 |> cd mongrel-1.0.1/ |> dpkg-buildpackage |> cd .. |> dpkg -i libdaemons-ruby*deb libgemplugin-ruby*deb mongrel_1.0.1-1_i386.deb -- Mike Renfro / R&D Engineer, Center for Manufacturing Research, 931 372-3601 / Tennessee Technological University
On Tue, Nov 13, 2007 at 12:38:54PM +0100, computer@cronopios.org wrote:> hi, > i''ve used the docus > * http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation > * http://reductivelabs.com/trac/puppet/wiki/PluginsInModules > * using the sid (therfore pluginsinmodules-patched) deb of > http://packages.debian.org/sid/puppetmaster. > ** > http://ftp.de.debian.org/debian/pool/main/p/puppet/puppet_0.23.2-13.diff.gz > > I''ve copied the common module from git://git.black.co.at to > /var/lib/puppet/modules/common > > With the (not mentioned modulepath in puppet.conf (see below)) the > puppetmaster finds the module. > > BUT: "stops" with the following error: > err: Could not parse; using old configuration: Unknown function > slash_escape at > /var/lib/puppet/modules/common/manifests/defines/replace.pp:23 > > The slash_escape is defined: > # grep -ri slash_escape > /var/lib/puppet/modules/common/plugins/puppet/parser/functions/slash_escape.rb > newfunction(:slash_escape, :type => :rvalue) do |args| > > I''ve experimented with pluginpath and libdir, but i''m stuck. > > does anyone sees the missing pieces?Yes. PluginsInModules doesn''t handle functions, because functions are a Puppetmaster-only thing. Looking at wiki:ModuleOrganisation, I notice that there''s no place to put custom functions in a module. Hooray for short sighted designs. That''ll have to be fixed, but it won''t be a part of PluginsInModules. There''s absolutely no reason to ship functions to all clients through pluginsync, because they''re only ever used on the server. I''ll probably end up just mangling the function loading code to go through $moduledir/*/functions as well as wherever else it''s currently looking. For now, I''d imagine that if you restarted your Puppetmaster it''d probably work, but more by accident than design. - Matt
On Tue, Nov 13, 2007 at 09:15:33AM -0600, Mike Renfro wrote:> On 11/13/2007 5:04 AM, Juri Rischel Jensen wrote: > > On 13/11/2007, at 5.44, Matt Palmer wrote: > >> Alternately, don''t use gems and stick to Real Packages. I''m pretty > >> sure > >> someone has put together mongrel debs by now. > > > > Actually - not that I know of, unfortunately. :-( > > http://packages.debian.org/lenny/mongrel -- only missing dependencies on > a stock Etch system appear to be libgemplugin-ruby and libdaemons-ruby, > plus libdaemons-ruby1.8 and libgemplugin-ruby1.8. Those could probably > even be grabbed as binary packages from Lenny. I may give that a shot > later today.I''m going to put on my swami hat and guess that''ll probably need rebuilding against Etch libs, unless you want to use Lenny''s libc6... - Matt -- "The user-friendly computer is a red herring. The user-friendliness of a book just makes it easier to turn pages. There''s nothing user-friendly about learning to read." -- Alan Kay
On Nov 13, 2007 5:38 AM, computer@cronopios.org <computer@cronopios.org> wrote:> hi, > i''ve used the docus > * http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation > * http://reductivelabs.com/trac/puppet/wiki/PluginsInModules > * using the sid (therfore pluginsinmodules-patched) deb of > http://packages.debian.org/sid/puppetmaster. > ** > http://ftp.de.debian.org/debian/pool/main/p/puppet/puppet_0.23.2-13.diff.gz > > I''ve copied the common module from git://git.black.co.at to > /var/lib/puppet/modules/common > > With the (not mentioned modulepath in puppet.conf (see below)) the > puppetmaster finds the module. > > BUT: "stops" with the following error: > err: Could not parse; using old configuration: Unknown function > slash_escape at > /var/lib/puppet/modules/common/manifests/defines/replace.pp:23 > > The slash_escape is defined: > # grep -ri slash_escape > /var/lib/puppet/modules/common/plugins/puppet/parser/functions/slash_escape.rb > newfunction(:slash_escape, :type => :rvalue) do |args| > > I''ve experimented with pluginpath and libdir, but i''m stuck. > > does anyone sees the missing pieces? > Thanks a lot! > AndreasI ran into this problem as well when I was experimenting with David Schmitt''s repo. For experimentation purposes, I added logic into ~/lib/util/autoload.rb::searchpath to include ~/modules/*/plugins/*, which seemed to make this work. I''m brand new to puppet & ruby so I''m probably missing something and may be doing something dumb. However, The nightly git sources seem to do something like this, but only looking for ~modules/*/lib instead. I''ve attached the patch I used against the debian/testing (0.23.2-12) package, in case its useful. _______________________________________________ Puppet-users mailing list Puppet-users@madstop.com https://mail.madstop.com/mailman/listinfo/puppet-users
>I''m going to put on my swami hat and guess that''ll probably need rebuilding against Etch libs, unless you want to use Lenny''s libc6...I did rebuild mongrel, but that was all. Details in another reply from today. -- Mike Renfro / R&D Engineer, Center for Manufacturing Research 931 372-3601 / Tennessee Technological University
On Nov 13, 2007, at 1:47 PM, Matt Palmer wrote:> > Yes. PluginsInModules doesn''t handle functions, because functions > are a > Puppetmaster-only thing. > > Looking at wiki:ModuleOrganisation, I notice that there''s no place > to put > custom functions in a module. Hooray for short sighted designs.I agree. I should have forced the issue on making it more general, and I''m hoping to refactor it in the near future. Fortunately it''s a very small chunk of code.> That''ll have to be fixed, but it won''t be a part of PluginsInModules. > There''s absolutely no reason to ship functions to all clients through > pluginsync, because they''re only ever used on the server. I''ll > probably end > up just mangling the function loading code to go through > $moduledir/*/functions as well as wherever else it''s currently > looking.Actually, I think Jeff McCune''s patch to add a lib dir to modules should already provide this, and it''s included in the current master branch. -- I am not a vegetarian because I love animals; I am a vegetarian because I hate plants. -- A. Whitney Brown --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Nov 13, 2007, at 3:42 PM, Andrew Garner wrote:> I ran into this problem as well when I was experimenting with David > Schmitt''s repo. For experimentation purposes, I added logic into > ~/lib/util/autoload.rb::searchpath to include ~/modules/*/plugins/*, > which seemed to make this work. I''m brand new to puppet & ruby so > I''m probably missing something and may be doing something dumb. > However, The nightly git sources seem to do something like this, but > only looking for ~modules/*/lib instead. I''ve attached the patch I > used against the debian/testing (0.23.2-12) package, in case its > useful.A similar patch has already been applied by Jeff McCune to the current code base, I just haven''t released it yet. (Really, I''m trying as hard as I can.) -- The hypothalamus is one of the most important parts of the brain, involved in many kinds of motivation, among other functions. The hypothalamus controls the "Four F''s": 1. fighting; 2. fleeing; 3. feeding; and 4. mating. -- Psychology professor in neuropsychology intro course --------------------------------------------------------------------- Luke Kanies | http://reductivelabs.com | http://madstop.com
On Nov 13, 2007 5:02 PM, Luke Kanies <luke@madstop.com> wrote:> On Nov 13, 2007, at 3:42 PM, Andrew Garner wrote: > > > I ran into this problem as well when I was experimenting with David > > Schmitt''s repo. For experimentation purposes, I added logic into > > ~/lib/util/autoload.rb::searchpath to include ~/modules/*/plugins/*, > > which seemed to make this work. I''m brand new to puppet & ruby so > > I''m probably missing something and may be doing something dumb. > > However, The nightly git sources seem to do something like this, but > > only looking for ~modules/*/lib instead. I''ve attached the patch I > > used against the debian/testing (0.23.2-12) package, in case its > > useful. > > A similar patch has already been applied by Jeff McCune to the > current code base, I just haven''t released it yet. (Really, I''m > trying as hard as I can.)This was just "quick fix" to make schmitt''s modules work with the debian/testing+ packages, and I thought it might be useful in the short term (for experimentation purposes). Unless I''m missing something, most of the (really cool) modules at http://reductivelabs.com/trac/puppet/wiki/CompleteConfiguration won''t work, without these plugins being loaded (the original poster''s problem). "My" patch is so similar because I just took Jeff McCune''s solution from the git master branch, and wasn''t intended as an official submission :) Sorry for not being clear on that point.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Tuesday 13 November 2007, Matt Palmer wrote:> On Tue, Nov 13, 2007 at 12:38:54PM +0100, computer@cronopios.org wrote: > > hi, > > i''ve used the docus > > * http://reductivelabs.com/trac/puppet/wiki/ModuleOrganisation > > * http://reductivelabs.com/trac/puppet/wiki/PluginsInModules > > * using the sid (therfore pluginsinmodules-patched) deb of > > http://packages.debian.org/sid/puppetmaster. > > ** > > http://ftp.de.debian.org/debian/pool/main/p/puppet/puppet_0.23.2-13.diff. > >gz > > > > I''ve copied the common module from git://git.black.co.at to > > /var/lib/puppet/modules/common > > > > With the (not mentioned modulepath in puppet.conf (see below)) the > > puppetmaster finds the module. > > > > BUT: "stops" with the following error: > > err: Could not parse; using old configuration: Unknown function > > slash_escape at > > /var/lib/puppet/modules/common/manifests/defines/replace.pp:23 > > > > The slash_escape is defined: > > # grep -ri slash_escape > > /var/lib/puppet/modules/common/plugins/puppet/parser/functions/slash_esca > >pe.rb newfunction(:slash_escape, :type => :rvalue) do |args| > > > > I''ve experimented with pluginpath and libdir, but i''m stuck. > > > > does anyone sees the missing pieces? > > Yes. PluginsInModules doesn''t handle functions, because functions are a > Puppetmaster-only thing. > > Looking at wiki:ModuleOrganisation, I notice that there''s no place to put > custom functions in a module. Hooray for short sighted designs. > > That''ll have to be fixed, but it won''t be a part of PluginsInModules. > There''s absolutely no reason to ship functions to all clients through > pluginsync, because they''re only ever used on the server. I''ll probably > end up just mangling the function loading code to go through > $moduledir/*/functions as well as wherever else it''s currently looking. > > For now, I''d imagine that if you restarted your Puppetmaster it''d probably > work, but more by accident than design.I have to admit, that I just - for the sake of simplicity - develop my functions in the master''s vardir and only moving it to common/plugins/ when done. Still bootstrapping with current deb should be as easy as running puppetd --pluginsync once on the puppetmaster. Regards, David - -- The primary freedom of open source is not the freedom from cost, but the free- dom to shape software to do what you want. This freedom is /never/ exercised without cost, but is available /at all/ only by accepting the very different costs associated with open source, costs not in money, but in time and effort. - -- http://www.schierer.org/~luke/log/20070710-1129/on-forks-and-forking -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFHOubG/Pp1N6Uzh0URAk6lAJ9yvO7As+85cx9QE4tQ+IJkJT06WQCgo/Ck qkz7+O9ZXYNGmZsbyzce2EE=APZo -----END PGP SIGNATURE-----