[Puppet Users] Re: Template Help Please
On Jan 24, 7:14 am, "ollies...@googlemail.com"
wrote:
> On Jan 23, 9:07 pm, Guy Matz wrote:
>
> > Is your issue resolved? It looks like you don't have the correct erb
> > syntax in your loop
>
> > *<%=* scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
>
> > I think should be
>
> > *<%* scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
>
> Thanks Gary, the split now works. Although I get an line break.
>
> # more /etc/resolv.conf
> # File managed by puppet
> domain example.com
> searchpath example.com example2.com
>
> nameserver 10.10.10.10
>
> nameserver 11.11.11.11
No worries sorted that with:-
<% scope.lookupvar('resolver::params::resolvers').split(/\s+/).each do
| ns | -%>
nameserver <%= ns %>
<% end -%>
Thanks to all for the help.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Template Help Please
On Jan 23, 9:07 pm, Guy Matz wrote:
> Is your issue resolved? It looks like you don't have the correct erb
> syntax in your loop
>
> *<%=* scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
>
> I think should be
>
> *<%* scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
>
Thanks Gary, the split now works. Although I get an line break.
# more /etc/resolv.conf
# File managed by puppet
domain example.com
searchpath example.com example2.com
nameserver 10.10.10.10
nameserver 11.11.11.11
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] I just discovered I cannot resource-purge yumrepos -- Is there another way ?
This is sort of hackish but not too bad... set a list of file resources
that are the resultant names of the /etc/yum.repos.d/.repo files, and
purge everything else in that directory.
class yum::cleanup {
# shorthand for the repo directory
$rd = "/etc/yum.repos.d"
# clean the yum.repos.d directory of any non-managed files
file { "$rd": ensure => directory, purge => true, recurse => true }
# NOTE: If you add a new yumrepo, make a matching file resource here!
file { [ "$rd/local.repo",
"$rd/os.repo",
"$rd/base.repo", ] :
ensure => present,
}
}
class yum::repositories {
require yum::cleanup
yumrepo { "os"
etc ...
}
}
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/62XjufqJOh8J.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Module to mount LUKS encrypted drives
I've created a module to manage mounting LUKS encrypted devices at
https://github.com/jaredcurtis/puppet-encmount
It's a wrapper around the existing mount type and accepts the
additional input needed to unlock the LUKS device (key and mapper
name). It's untested outside of CentOS and does use some hard-coded
paths so it may not be 100% portable. But if anyone finds an issue it
should be simple to patch it up.
The module does depend on another module I created, cryptsetup, which
is also on my github page. This module is nothing more than a simple
cryptsetup installer.
Puppet-encmount does a not so good thing in that it does copy the key
to /dev/shm/ so that it can be used by the cryptsetup program.
Once the mapper device is created though the key is deleted and will
not be recreated unless the mapper is removed. I understand that this
is not 100% secure but I do set file permissions securely and clear
the file as soon as it's done being used.
If anyone has any suggestions or finds any errors let me know and I'll
patch it up.
Example:
encmount::mount { '/mnt/test':
fstype => 'ext3',
device => '/dev/sdb1',
mapper => 'enc_sdb1',
key=> '1234!@#$',
}
This will unlock the sdb1 partition using the key 1234!@#$, create a
device called enc_sdb1 in /dev/mapper, and finally mount the mapper
at /mnt/test.
I'm considering expanding this to become more of a general LUKS
management class but as of right now this fits my need.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.
Nigel,
Just so we understand the requirements of this - what would it take to make
a function that
is usable in way that a few of us have mentioned - something that lets us
say "If a class
is included in this host, then X". It seems like this would be desirable
functionality and so
far everything I've heard has been a clumsy workaround for this base kind
of functionality.
What I don't understand is why defined creates a parse order dependency and
why it's not
able to search through the entire catalog to see if the class is defined.
This is totally my
lack of understanding of the code shining through but what stops this being
possible?
Is it just the case that you don't want to rely on a class in the future
has hasn't yet been
processed because it might fail and therefore, for the purposes of puppet,
not be defined?
On Mon, Jan 23, 2012 at 7:57 PM, Nigel Kersten wrote:
>
>
> On Mon, Jan 23, 2012 at 5:15 AM, Felix Frank <
> felix.fr...@alumni.tu-berlin.de> wrote:
>
>> Hi,
>>
>> On 01/20/2012 11:34 PM, Cody wrote:
>> > Defining all somewhat common packages in a central location becomes
>> > unrealistic when you no longer "control" the code that is in every
>> > module you use. If you obtain five modules from the forge and they
>> > all require a specific package and so all define that package your not
>> > going to convince, nor is it a good design to require everyone to move
>> > the package definitions from that collection of modules. They need to
>> > function as a collection out of the box.
>>
>> Agreed. How can this be accomplished?
>>
>
> Felix, could you take this to a new thread please? I'd really like to keep
> this one focused on the topic at hand if possible :)
>
>
>
>>
>> Perhaps there needs to be some kind of "Forge common" module that by
>> policy can only ever declare virtual resources (packages are a prominent
>> example).
>> A user who wishes to retain the capability of using modules from the
>> Forge would be required to install this common module, and replace their
>> own resource declarations with realizations of the common resources.
>> For this to work, it's definitely a plus that you can override
>> attributes in collections:
>> Package<| title == "apache2": |> { ensure => "2.2.12" }
>> ...although that does bear some caveats. Does this still work in recent
>> versions?
>>
>> If we can take this for granted, all Forge modules can adhere to that
>> same standard.
>>
>> Yes, it's quite a hassle.
>>
>> No, I didn't think this through very thoroughly ;-)
>>
>> Just another pair of cents.
>>
>> Cheers,
>> Felix
>>
>> --
>> 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+unsubscr...@googlegroups.com.
>> For more options, visit this group at
>> http://groups.google.com/group/puppet-users?hl=en.
>>
>>
>
>
> --
> Nigel Kersten
> Product Manager, Puppet Labs
>
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.
On Mon, Jan 23, 2012 at 5:15 AM, Felix Frank <
felix.fr...@alumni.tu-berlin.de> wrote:
> Hi,
>
> On 01/20/2012 11:34 PM, Cody wrote:
> > Defining all somewhat common packages in a central location becomes
> > unrealistic when you no longer "control" the code that is in every
> > module you use. If you obtain five modules from the forge and they
> > all require a specific package and so all define that package your not
> > going to convince, nor is it a good design to require everyone to move
> > the package definitions from that collection of modules. They need to
> > function as a collection out of the box.
>
> Agreed. How can this be accomplished?
>
Felix, could you take this to a new thread please? I'd really like to keep
this one focused on the topic at hand if possible :)
>
> Perhaps there needs to be some kind of "Forge common" module that by
> policy can only ever declare virtual resources (packages are a prominent
> example).
> A user who wishes to retain the capability of using modules from the
> Forge would be required to install this common module, and replace their
> own resource declarations with realizations of the common resources.
> For this to work, it's definitely a plus that you can override
> attributes in collections:
> Package<| title == "apache2": |> { ensure => "2.2.12" }
> ...although that does bear some caveats. Does this still work in recent
> versions?
>
> If we can take this for granted, all Forge modules can adhere to that
> same standard.
>
> Yes, it's quite a hassle.
>
> No, I didn't think this through very thoroughly ;-)
>
> Just another pair of cents.
>
> Cheers,
> Felix
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>
--
Nigel Kersten
Product Manager, Puppet Labs
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] best practices for caching packages on EC2
On Mon, Jan 23, 2012 at 5:14 PM, Michael Stahnke wrote: > How would Puppet handle it? It would still have to either cache the > package locally (eating lots of disk space) or point to a proxy, which > you can do with Puppet already. Your simplest solution might be to > look for a mirror hosted in EC2, which I assume there are some. Hi Michael, I knew that I could point to a proxy - but I am looking for ways to automate the setup. Hardcoding yum or apt proxies is not a very "Puppet" way of setting things up. If someone has 100 machines on EC2, then I am sure it would be way more efficient to pull the package once into EC2, cache it on the puppet master, and then redistribute it to all of the 100 machines. And when the master finds that every machine has the package installed, it can retire the package and free up space (with an ordinary proxy it is harder to do the retirement part) - of course if it is needed again it needs to be pulled in again. If the package provider layer can handle all the work of caching, then that would save lots of time - not every site wants to reinvent the wheel of package caching. Rayson = Open Grid Scheduler / Grid Engine http://gridscheduler.sourceforge.net/ Scalable Grid Engine Support Program http://www.scalablelogic.com/ > > Another option would be to build up a squid proxy via puppet and then > configure a client-side usage of that cache, but that's no different > in EC2 vs any other setup. > -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] best practices for caching packages on EC2
On Mon, Jan 23, 2012 at 1:21 PM, Rayson Ho wrote: > While Puppet allows us to manage a large number of instances on EC2, > what are the best practices for caching packages on EC2?? > > Instead of manually configuring yum or apt proxies on each node, it > would save us lots of time if caching could be "somehow" handled by > Puppet. Are there any plans to add the ability to handle caching in > the package providers?? How would Puppet handle it? It would still have to either cache the package locally (eating lots of disk space) or point to a proxy, which you can do with Puppet already. Your simplest solution might be to look for a mirror hosted in EC2, which I assume there are some. Another option would be to build up a squid proxy via puppet and then configure a client-side usage of that cache, but that's no different in EC2 vs any other setup. > > Rayson > > = > Open Grid Scheduler / Grid Engine > http://gridscheduler.sourceforge.net/ > > Scalable Grid Engine Support Program > http://www.scalablelogic.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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] difficulty installing dashboard.
What version of rubygems do you have? I suspect there is some type of mismatch somewhere, but I could be wrong. More information would be great: OS ruby version rubygems version gem list Thanks stahnma On Mon, Jan 23, 2012 at 9:07 AM, Peter Berghold wrote: > Using the instructions I found here: > http://docs.puppetlabs.com/guides/installing_dashboard.html > I've run into a snag at the point where you run: > > rake RAILS_ENV=production db:migrate > > It fails with the following error: > > puppet-dashboard]# rake RAILS_ENV=production db:migrate (in > /root/puppet-dashboard) > rake aborted! > undefined method `requirement' for # > > > > so I ran it with the --trace option and got > > puppet-dashboard]# rake --trace RAILS_ENV=production db:migrate > (in /root/puppet-dashboard) > ** Invoke db:migrate (first_time) > ** Invoke environment (first_time) > ** Execute environment > rake aborted! > undefined method `requirement' for # > /root/puppet-dashboard/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:81:in > `add_load_paths' > /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:301:in > `add_gem_load_paths' > /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:301:in > `each' > /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:301:in > `add_gem_load_paths' > /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:132:in > `process' > /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:113:in > `send' > /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:113:in > `run' > /root/puppet-dashboard/config/environment.rb:14 > /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in > `gem_original_require' > /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' > /root/puppet-dashboard/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in > `require' > /root/puppet-dashboard/vendor/rails/activesupport/lib/active_support/dependencies.rb:547:in > `new_constants_in' > /root/puppet-dashboard/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in > `require' > /root/puppet-dashboard/vendor/rails/railties/lib/tasks/misc.rake:4 > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:635:in `call' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:635:in `execute' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:630:in `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:630:in `execute' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:596:in > `invoke_with_call_chain' > /usr/lib/ruby/1.8/monitor.rb:238:in `synchronize' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:589:in > `invoke_with_call_chain' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:606:in > `invoke_prerequisites' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:603:in `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:603:in > `invoke_prerequisites' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:595:in > `invoke_with_call_chain' > /usr/lib/ruby/1.8/monitor.rb:238:in `synchronize' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:589:in > `invoke_with_call_chain' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:582:in `invoke' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2050:in `invoke_task' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2028:in `top_level' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2028:in `each' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2028:in `top_level' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2067:in > `standard_exception_handling' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2022:in `top_level' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2000:in `run' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2067:in > `standard_exception_handling' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1997:in `run' > /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake:31 > /usr/bin/rake:19:in `load' > /usr/bin/rake:19 > > > So... what do I do about this? > > > -- > Peter L. Berghold > Owner, Shark River Technical Solutions LLC > > -- > 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+unsubscr...@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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] best practices for caching packages on EC2
While Puppet allows us to manage a large number of instances on EC2, what are the best practices for caching packages on EC2?? Instead of manually configuring yum or apt proxies on each node, it would save us lots of time if caching could be "somehow" handled by Puppet. Are there any plans to add the ability to handle caching in the package providers?? Rayson = Open Grid Scheduler / Grid Engine http://gridscheduler.sourceforge.net/ Scalable Grid Engine Support Program http://www.scalablelogic.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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Template Help Please
Is your issue resolved? It looks like you don't have the correct erb
syntax in your loop
*<%=* scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
I think should be
*<%* scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
On Mon, Jan 23, 2012 at 4:00 PM, ollies...@googlemail.com <
paul.seym...@barcap.com> wrote:
>
>
> On Jan 23, 4:32 pm, Felix Frank
> wrote:
> > On 01/23/2012 02:48 PM, ollies...@googlemail.com wrote:
> >
> > > host: parse of /etc/resolv.conf failed
> > > ./resolver/templates/resolv.conf.erb:7:in `result': compile error
> > > (SyntaxError)
> > > ./resolver/templates/resolv.conf.erb:4: syntax error
> > > _erbout.concat(( scope.lookupvar('resolver::params::resolvers').split(/
> > > \s+/).each do | ns | ).to_s); _erbout.concat "\n"
> >
> > > ^
> > > ./resolver/templates/resolv.conf.erb:7: syntax error
> > > _erbout
> >
> > Uhuh. Just a wild guess, but: *Does* your template end in a newline
> > character?
> > If not, add one. If in doubt, loose the '-%>' and substitute '%>'
> instead.
> >
> > HTH,
> > Felix
>
> Looks about right to me.
>
> Thanks for the continued help.
>
> Cheers
> Paul
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Template Help Please
On Jan 23, 4:32 pm, Felix Frank
wrote:
> On 01/23/2012 02:48 PM, ollies...@googlemail.com wrote:
>
> > host: parse of /etc/resolv.conf failed
> > ./resolver/templates/resolv.conf.erb:7:in `result': compile error
> > (SyntaxError)
> > ./resolver/templates/resolv.conf.erb:4: syntax error
> > _erbout.concat(( scope.lookupvar('resolver::params::resolvers').split(/
> > \s+/).each do | ns | ).to_s); _erbout.concat "\n"
>
> > ^
> > ./resolver/templates/resolv.conf.erb:7: syntax error
> > _erbout
>
> Uhuh. Just a wild guess, but: *Does* your template end in a newline
> character?
> If not, add one. If in doubt, loose the '-%>' and substitute '%>' instead.
>
> HTH,
> Felix
Looks about right to me.
Thanks for the continued help.
Cheers
Paul
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] I just discovered I cannot resource-purge yumrepos -- Is there another way ?
That the problem is known is a comfort.
I will trash my way around it one way or another, and if I come up with any
neato tricks for removal of a repo, I will contact the list and/or the Feature
Assignee :)
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
- Stefan Schulte wrote:
> On Mon, Jan 23, 2012 at 03:09:49PM +, Dan White wrote:
> > I added a bunch of yumrepo resources to my node definitions and thought I'd
> > finish it with a
> >
> > resources { 'yumrepo': purge => true, }
> >
> > But when I tried to run it, I get this:
> >
> > err: Failed to apply catalog: Parameter purge failed: Purging is only
> > supported on types that accept 'ensure' at /etc/puppet/manifests/nodes/
> >
>
> While I don't have a workaround for you, there is a featurerequest to
> accomplish resource purging
>
> http://projects.puppetlabs.com/issues/9293
>
> -Stefan
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] I just discovered I cannot resource-purge yumrepos -- Is there another way ?
On Mon, Jan 23, 2012 at 03:09:49PM +, Dan White wrote:
> I added a bunch of yumrepo resources to my node definitions and thought I'd
> finish it with a
>
> resources { 'yumrepo': purge => true, }
>
> But when I tried to run it, I get this:
>
> err: Failed to apply catalog: Parameter purge failed: Purging is only
> supported on types that accept 'ensure' at /etc/puppet/manifests/nodes/
>
While I don't have a workaround for you, there is a featurerequest to
accomplish resource purging
http://projects.puppetlabs.com/issues/9293
-Stefan
pgpIyFUcsR7FZ.pgp
Description: PGP signature
Re: [Puppet Users] Another Discovered/Undocumented feature of yumrepo - and a workaround
- R.I.Pienaar wrote: > - Original Message - > > Hey there, > > > > If you're going through all that, and are trying to get a purge-able > > directory of resources, would you find it easier to declare the > > /etc/yum.repos.d directory with purge => true, and then declare your > > repos as file declarations? An exec of 'yum -makecache' set to > > refreshonly => true could be notified by each file resource. > > > > Does that help get what you need? > > I've tried something along these lines and at least on 2.6.x if you just > remove repo files mid run the yum provider gets quite unhappy, logs about > missing files etc. > > having this provider support an ensure => absent option rather than just > something that sets enable=0 in the repo would be really nice > The "enable=0" option is there, and works, but I am trying to deal with the complete removal of the repo info. I am tinkering with the Python-yum api and I have a script to list packages/repos - #!/usr/bin/python -tt # -tt => issue errors about inconsistent tab usage import yum my = yum.YumBase() pkgs = my.rpmdb i=0 for ipkg in sorted(pkgs): apkgs = my.pkgSack.searchPkgTuple(ipkg.pkgtup) if len(apkgs) >= 1: apkg = apkgs[0] print 'Repo: %s - Package: %s' % (apkg.repoid, ipkg) i += 1 print str(i) + " packages" --- I just need to add some more code because this script would pass over an "orphaned" package. “Sometimes I think the surest sign that intelligent life exists elsewhere in the universe is that none of it has tried to contact us.” Bill Waterson (Calvin & Hobbes) -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Another Discovered/Undocumented feature of yumrepo - and a workaround
Yes, I could do it that way and I did before i realized that there was a
yumrepo resource.
Let me try a different approach: Is there something in the yumrepo resource
definition that will let me remove the info from the system ? I can live with
just disabling the repo, but I have some rabid security types that want the
repo removed entirely.
The puppet resource seems geared toward adding repos only.
Interesting problem. I am thinking it would be nice to be able to gather all
the necessary info from the yum database so that you would know that you have
"orphaned" rpm's. I found the Python-yum api and whipped up a script that
lists all packages and their source repo, but it ignores "orphans". Still
learning !
- Gary Larizza wrote:
> Hey there,
>
> If you're going through all that, and are trying to get a purge-able
> directory of resources, would you find it easier to declare the
> /etc/yum.repos.d directory with purge => true, and then declare your repos
> as file declarations? An exec of 'yum -makecache' set to refreshonly =>
> true could be notified by each file resource.
>
> Does that help get what you need?
>
> On Monday, January 23, 2012, Dan White wrote:
> > I was working with yumrepo, defining new entried and seeing them appear
> in /etc/yum.repos.d
> >
> > After considerable tinkering, and with the sad discovery that resource {
> 'yumrepo': purge => true } does not work,
> > I moved my working /etc/yum.repos.d to /etc/yum.repos.d-old and re-ran my
> catalog.
> >
> > To my surprise, the repo entried were appended to /etc/yum.conf
> >
> > Long story short:
> > I needed to add
> >file { '/etc/yum.repos.d': ensure => directory, }
> > -- require => File["/etc/yum.repos.d"] -- was added to eack yumrepo
> resource
> > AND "reposdir=/etc/yum/repos.d" explicitly set in /etc/yum.conf
> > to get what I wanted.
> >
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] difficulty installing dashboard.
Using the instructions I found here: http://docs.puppetlabs.com/guides/installing_dashboard.html I've run into a snag at the point where you run: rake RAILS_ENV=production db:migrate It fails with the following error: puppet-dashboard]# rake RAILS_ENV=production db:migrate (in /root/puppet-dashboard) rake aborted! undefined method `requirement' for # so I ran it with the --trace option and got puppet-dashboard]# rake --trace RAILS_ENV=production db:migrate (in /root/puppet-dashboard) ** Invoke db:migrate (first_time) ** Invoke environment (first_time) ** Execute environment rake aborted! undefined method `requirement' for # /root/puppet-dashboard/config/../vendor/rails/railties/lib/rails/gem_dependency.rb:81:in `add_load_paths' /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:301:in `add_gem_load_paths' /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:301:in `each' /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:301:in `add_gem_load_paths' /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:132:in `process' /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:113:in `send' /root/puppet-dashboard/config/../vendor/rails/railties/lib/initializer.rb:113:in `run' /root/puppet-dashboard/config/environment.rb:14 /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `gem_original_require' /usr/lib/ruby/site_ruby/1.8/rubygems/custom_require.rb:31:in `require' /root/puppet-dashboard/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in `require' /root/puppet-dashboard/vendor/rails/activesupport/lib/active_support/dependencies.rb:547:in `new_constants_in' /root/puppet-dashboard/vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in `require' /root/puppet-dashboard/vendor/rails/railties/lib/tasks/misc.rake:4 /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:635:in `call' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:635:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:630:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:630:in `execute' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:596:in `invoke_with_call_chain' /usr/lib/ruby/1.8/monitor.rb:238:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:589:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:606:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:603:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:603:in `invoke_prerequisites' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:595:in `invoke_with_call_chain' /usr/lib/ruby/1.8/monitor.rb:238:in `synchronize' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:589:in `invoke_with_call_chain' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:582:in `invoke' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2050:in `invoke_task' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2028:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2028:in `each' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2028:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2067:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2022:in `top_level' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2000:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2067:in `standard_exception_handling' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:1997:in `run' /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/bin/rake:31 /usr/bin/rake:19:in `load' /usr/bin/rake:19 So... what do I do about this? -- Peter L. Berghold Owner, Shark River Technical Solutions LLC -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: windows filepath error
On Mon, Jan 23, 2012 at 6:55 AM, tborthwick wrote: > Thanks, I didn't realize it had to be a local file. I've updated the package description on the Windows wiki page: http://projects.puppetlabs.com/projects/puppet/wiki/Puppet_Windows?version=63 Josh -- Josh Cooper Developer, Puppet Labs -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Template Help Please
On 01/23/2012 02:48 PM, ollies...@googlemail.com wrote:
> host: parse of /etc/resolv.conf failed
> ./resolver/templates/resolv.conf.erb:7:in `result': compile error
> (SyntaxError)
> ./resolver/templates/resolv.conf.erb:4: syntax error
> _erbout.concat(( scope.lookupvar('resolver::params::resolvers').split(/
> \s+/).each do | ns | ).to_s); _erbout.concat "\n"
>
> ^
> ./resolver/templates/resolv.conf.erb:7: syntax error
> _erbout
Uhuh. Just a wild guess, but: *Does* your template end in a newline
character?
If not, add one. If in doubt, loose the '-%>' and substitute '%>' instead.
HTH,
Felix
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Another Discovered/Undocumented feature of yumrepo - and a workaround
- Original Message - > Hey there, > > If you're going through all that, and are trying to get a purge-able > directory of resources, would you find it easier to declare the > /etc/yum.repos.d directory with purge => true, and then declare your > repos as file declarations? An exec of 'yum -makecache' set to > refreshonly => true could be notified by each file resource. > > Does that help get what you need? I've tried something along these lines and at least on 2.6.x if you just remove repo files mid run the yum provider gets quite unhappy, logs about missing files etc. having this provider support an ensure => absent option rather than just something that sets enable=0 in the repo would be really nice -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Another Discovered/Undocumented feature of yumrepo - and a workaround
Hey there,
If you're going through all that, and are trying to get a purge-able
directory of resources, would you find it easier to declare the
/etc/yum.repos.d directory with purge => true, and then declare your repos
as file declarations? An exec of 'yum -makecache' set to refreshonly =>
true could be notified by each file resource.
Does that help get what you need?
On Monday, January 23, 2012, Dan White wrote:
> I was working with yumrepo, defining new entried and seeing them appear
in /etc/yum.repos.d
>
> After considerable tinkering, and with the sad discovery that resource {
'yumrepo': purge => true } does not work,
> I moved my working /etc/yum.repos.d to /etc/yum.repos.d-old and re-ran my
catalog.
>
> To my surprise, the repo entried were appended to /etc/yum.conf
>
> Long story short:
> I needed to add
>file { '/etc/yum.repos.d': ensure => directory, }
> -- require => File["/etc/yum.repos.d"] -- was added to eack yumrepo
resource
> AND "reposdir=/etc/yum/repos.d" explicitly set in /etc/yum.conf
> to get what I wanted.
>
> “Sometimes I think the surest sign that intelligent life exists elsewhere
in the universe is that none of it has tried to contact us.”
> Bill Waterson (Calvin & Hobbes)
>
> --
> 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+unsubscr...@googlegroups.com.
> For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
>
>
--
Gary Larizza
Professional Services Engineer
Puppet Labs
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Another Discovered/Undocumented feature of yumrepo - and a workaround
I was working with yumrepo, defining new entried and seeing them appear in
/etc/yum.repos.d
After considerable tinkering, and with the sad discovery that resource {
'yumrepo': purge => true } does not work,
I moved my working /etc/yum.repos.d to /etc/yum.repos.d-old and re-ran my
catalog.
To my surprise, the repo entried were appended to /etc/yum.conf
Long story short:
I needed to add
file { '/etc/yum.repos.d': ensure => directory, }
-- require => File["/etc/yum.repos.d"] -- was added to eack yumrepo resource
AND "reposdir=/etc/yum/repos.d" explicitly set in /etc/yum.conf
to get what I wanted.
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] What's the proper puppet way to reference definition resource WITHOUT calling it from site/node.pp
The way my environment setup is that we have puppet dashboard handles ALL node registration as well as class assignment. We simply declare different groups, assign them with classes, and assign nodes into those groups for different roles. So we have zero usage for another node resources and we would like to keep it that way. The pro puppet book example for utilizing the apache definition shows that you simply call the definition in node.pp with proper parameters, and I want to do something similar without calling it in a separate node.pp file. In term of approach what I can think of right now is to create another class (let's say apache-invoke), and I would have template parameters created via puppet dashboard's parameter (on some nodes/groups), and have this new class call the apache definition. Then I can have whatever nodes I need to have apache to be part of this new groups. I'm not sure if there are another way that's better/proper. Please let me know, thx. --KL This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] I just discovered I cannot resource-purge yumrepos -- Is there another way ?
I added a bunch of yumrepo resources to my node definitions and thought I'd
finish it with a
resources { 'yumrepo': purge => true, }
But when I tried to run it, I get this:
err: Failed to apply catalog: Parameter purge failed: Purging is only supported
on types that accept 'ensure' at /etc/puppet/manifests/nodes/
Is there an alternative, non-messy way to do what that statement should do for
me ?
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin & Hobbes)
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: windows filepath error
Thanks, I didn't realize it had to be a local file.
On Jan 20, 5:07 pm, Josh Cooper wrote:
> Hi,
>
>
>
>
>
>
>
>
>
> On Fri, Jan 20, 2012 at 2:47 PM, tborthwick wrote:
> > Hello,
>
> > I've set up a puppetmaster on red hat and a client on windows 7
> > (puppet version 2.7.9 on both), and I'm getting this error when I run
> > puppet agent --server --waitforcert 60 --test:
>
> > info: Applying configuration version '1327098121'
> > err: /Stage[main]/Win_test/Package[win_test]/ensure: change from
> > absent to present failed: The source parameter is required when using
> > the MSI provider.
>
> > My manifest looks like this:
>
> > class win_test {
> > package { win_test: ensure => present }
> > file { "c:/test/win_test_file":
> > ensure => 'file',
> > owner = 'Administrator',
> > source => 'puppet:///modules/win_test/win_test_file',
> > require => Package["win_test"]
> > }
> > }
>
> > I have a file at /etc/puppet/modules/win_test/files/win_test_file.
>
> You need a source parameter in your package resource, from which msiexec
> can install the msi. At present, this must be a local file (or mapped
> drive).
>
> Presumably, the msi you want to install, is the one you downloaded from
> your module? If so, then you just need:
>
> package { 'win_test':
> ensure => 'installed',
> source => 'c:/test/win_test_file'
>
> }
>
> Josh
>
> --
> Josh Cooper
> Developer, Puppet Labs
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Template Help Please
On Jan 23, 1:32 pm, Felix Frank
wrote:
> Absolutely beats me.
>
> Is this a verbatim paste from your template?
> Are you certain that the template is the source of the error?
> Does it say anything beyond "syntax error"?
>
> Just pasting puppet output would be ideal.
>
host: parse of /etc/resolv.conf failed
./resolver/templates/resolv.conf.erb:7:in `result': compile error
(SyntaxError)
./resolver/templates/resolv.conf.erb:4: syntax error
_erbout.concat(( scope.lookupvar('resolver::params::resolvers').split(/
\s+/).each do | ns | ).to_s); _erbout.concat "\n"
^
./resolver/templates/resolv.conf.erb:7: syntax error
_erbout
^from /usr/lib/ruby/1.8/erb.rb:741:in `value'
from /usr/lib/ruby/1.8/erb.rb:741:in `result'
from /usr/lib/ruby/site_ruby/1.8/puppet/parser/
templatewrapper.rb:106:in `result'
from /usr/lib/ruby/site_ruby/1.8/puppet/util.rb:185:in
`benchmark'
from /usr/lib/ruby/site_ruby/1.8/puppet/parser/
templatewrapper.rb:103:in `result'
from /usr/lib/ruby/site_ruby/1.8/puppet/parser/functions/
template.rb:18:in `function_template'
from /usr/lib/ruby/site_ruby/1.8/puppet/parser/functions/
template.rb:10:in `collect'
from /usr/lib/ruby/site_ruby/1.8/puppet/parser/functions/
template.rb:10:in `function_template'
... 62 levels...
from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:401:in
`exit_on_fail'
from /usr/lib/ruby/site_ruby/1.8/puppet/application.rb:306:in
`run'
from /usr/lib/ruby/site_ruby/1.8/puppet/util/command_line.rb:
69:in `execute'
from /usr/bin/puppet:4
#
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: client not getting updates no error message
guys any other suggestions ?still i am not able to find the error.
On Jan 22, 12:02 am, bhagyesh wrote:
> [root@PROXY-03 puppet]# puppet apply networking/manifests/init.pp -d -
> e 'include networking::resolver'
> debug: importing '/etc/puppet/modules/networking/manifests/init.pp' in
> environment production
> debug: Automatically imported networking::resolver from networking
> into production
> debug: Failed to load library 'rubygems' for feature 'rubygems'
> debug: Puppet::Type::File::ProviderMicrosoft_windows: feature
> microsoft_windows is missing
> debug: Creating default schedules
> debug: Failed to load library 'ldap' for feature 'ldap'
> debug: Puppet::Type::User::ProviderLdap: feature ldap is missing
> debug: Puppet::Type::User::ProviderDirectoryservice: file /usr/bin/
> dscl does not exist
> debug: Puppet::Type::User::ProviderUser_role_add: file roledel does
> not exist
> debug: Puppet::Type::User::ProviderPw: file pw does not exist
> debug: /File[/var/lib/puppet/ssl/private_keys]: Autorequiring File[/
> var/lib/puppet/ssl]
> debug: /File[/var/lib/puppet/ssl/private_keys/
> proxy-03.carnation.in.pem]: Autorequiring File[/var/lib/puppet/ssl/
> private_keys]
> debug: /File[/var/lib/puppet/client_yaml]: Autorequiring File[/var/lib/
> puppet]
> debug: /File[/var/lib/puppet/ssl/public_keys]: Autorequiring File[/var/
> lib/puppet/ssl]
> debug: /File[/var/lib/puppet/state/state.yaml]: Autorequiring File[/
> var/lib/puppet/state]
> debug: /File[/var/lib/puppet/state/last_run_summary.yaml]:
> Autorequiring File[/var/lib/puppet/state]
> debug: /File[/var/lib/puppet/ssl/public_keys/
> proxy-03.carnation.in.pem]: Autorequiring File[/var/lib/puppet/ssl/
> public_keys]
> debug: /File[/var/lib/puppet/client_data]: Autorequiring File[/var/lib/
> puppet]
> debug: /File[/var/lib/puppet/state]: Autorequiring File[/var/lib/
> puppet]
> debug: /File[/var/lib/puppet/ssl/certificate_requests]: Autorequiring
> File[/var/lib/puppet/ssl]
> debug: /File[/var/lib/puppet/state/graphs]: Autorequiring File[/var/
> lib/puppet/state]
> debug: /File[/var/lib/puppet/facts]: Autorequiring File[/var/lib/
> puppet]
> debug: /File[/var/lib/puppet/clientbucket]: Autorequiring File[/var/
> lib/puppet]
> debug: /File[/var/lib/puppet/state/last_run_report.yaml]:
> Autorequiring File[/var/lib/puppet/state]
> debug: /File[/var/lib/puppet/ssl/certs/proxy-03.carnation.in.pem]:
> Autorequiring File[/var/lib/puppet/ssl/certs]
> debug: /File[/var/lib/puppet/ssl/crl.pem]: Autorequiring File[/var/lib/
> puppet/ssl]
> debug: /File[/var/lib/puppet/ssl/private]: Autorequiring File[/var/lib/
> puppet/ssl]
> debug: /File[/var/lib/puppet/ssl/certs/ca.pem]: Autorequiring File[/
> var/lib/puppet/ssl/certs]
> debug: /File[/var/lib/puppet/lib]: Autorequiring File[/var/lib/puppet]
> debug: /File[/var/lib/puppet/ssl/certs]: Autorequiring File[/var/lib/
> puppet/ssl]
> debug: /File[/var/log/puppet/http.log]: Autorequiring File[/var/log/
> puppet]
> debug: /File[/var/lib/puppet/ssl]: Autorequiring File[/var/lib/puppet]
> debug: Finishing transaction 23673548974640
> debug: Loaded state in 0.00 seconds
> debug: Loaded state in 0.00 seconds
> info: Applying configuration version '1327172288'
> notice: /Stage[main]/Networking::Resolver/File[/tmp/resolv.conf]/
> ensure: created
> debug: Finishing transaction 23673547908420
> debug: Storing state
> debug: Stored state in 0.01 seconds
> notice: Finished catalog run in 0.03 seconds
> [root@PROXY-03 puppet]#
>
> On Jan 21, 7:14 am, Christopher McCoy wrote:
>
>
>
> > What happens when you run this:
> > puppet apply networking/manifests/init.pp -d -e 'include
> > networking::resolver'
>
> > On Fri, Jan 20, 2012 at 8:41 PM, bhagyesh wrote:
> > > file/manifest/init.pp is a class but its not yet included in the
> > > templete so can be left alone as of now
>
> > > and the file /tmp/resolve.conf dosent exist but still I am not getting
> > > any output
>
> > > On Jan 21, 3:46 am, Christopher McCoy wrote:
> > > > Ok, so I'm looking at this again.
>
> > > > what is in file/manifests/init.pp?
> > > > you ran a puppet apply on it, but never showed us what is in it, so it
> > > > could just be class file { }
>
> > > > And lastly, does the file /tmp/resolv.conf already exist? If so you
> > > > won't
> > > > see anything output.
>
> > > > On Fri, Jan 20, 2012 at 3:50 PM, bhagyesh wrote:
> > > > > whenever i run a test from client it finishes sucessfully but client
> > > > > is not getting any configuration changes from server
>
> > > > > [root@PROXY-02 tmp]# puppetd --noop --test
> > > > > notice: Ignoring --listen on onetime run
> > > > > info: Caching catalog for proxy-02.carnation.in
> > > > > info: Applying configuration version '1327091881'
> > > > > notice: Finished catalog run in 0.02 seconds
>
> > > > > [root@PROXY-03 modules]# puppet apply file/manifests/init.pp -d
> > > > > debug: Creating default schedules
> > > > > debug: Failed to load library 'ldap' for feature 'ldap'
> > > > > debug: Puppet::Type::User::Provid
Re: [Puppet Users] Template Help Please
Absolutely beats me.
Is this a verbatim paste from your template?
Are you certain that the template is the source of the error?
Does it say anything beyond "syntax error"?
Just pasting puppet output would be ideal.
Cheers,
Felix
On 01/23/2012 12:57 PM, ollies...@googlemail.com wrote:
> I have this in the template now:-
> <%= scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
> do | ns | %>
> nameserver <%= ns %>
> <% end -%>
>
> Which is throwing a syntax error. Can't for the life of me work out
> whats wrong. Probably not had enough coffee yet.
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Template Help Please
On Jan 23, 1:17 pm, Denmat wrote: > Hi, > > Is that variable declaration copied correctly? > > > $resolvers = "10.10.10.10 11.11.11.11.12.12.12.12" > > Should be> $resolvers = "10.10.10.10 11.11.11.11 12.12.12.12" > > what's that do for you? > That was a typo in my original mail. The syntax problem remains as it would still be a split on the spaces. Thanks Paul -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Template Help Please
Hi,
Is that variable declaration copied correctly?
> $resolvers = "10.10.10.10 11.11.11.11.12.12.12.12"
Should be
> $resolvers = "10.10.10.10 11.11.11.11 12.12.12.12"
what's that do for you?
Cheers
Den
On 23/01/2012, at 22:57, "ollies...@googlemail.com"
wrote:
> Hello,
>
> I am trying to setup a template with data being passed in as a long
> string of data which is being returned via extlookup()
>
> i.e. $resolvers = "10.10.10.10 11.11.11.11.12.12.12.12"
>
> The template should split those up and put a nameserver entry per line
> in /etc/resolv.conf
>
> I have this in the template now:-
> <%= scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
> do | ns | %>
> nameserver <%= ns %>
> <% end -%>
>
> Which is throwing a syntax error. Can't for the life of me work out
> whats wrong. Probably not had enough coffee yet.
>
> Any ideas ?
>
> Thanks
> Paul
>
> --
> 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+unsubscr...@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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: RFC: Deprecate defined() function for Telly.
Hi,
On 01/20/2012 11:34 PM, Cody wrote:
> Defining all somewhat common packages in a central location becomes
> unrealistic when you no longer "control" the code that is in every
> module you use. If you obtain five modules from the forge and they
> all require a specific package and so all define that package your not
> going to convince, nor is it a good design to require everyone to move
> the package definitions from that collection of modules. They need to
> function as a collection out of the box.
Agreed. How can this be accomplished?
Perhaps there needs to be some kind of "Forge common" module that by
policy can only ever declare virtual resources (packages are a prominent
example).
A user who wishes to retain the capability of using modules from the
Forge would be required to install this common module, and replace their
own resource declarations with realizations of the common resources.
For this to work, it's definitely a plus that you can override
attributes in collections:
Package<| title == "apache2": |> { ensure => "2.2.12" }
...although that does bear some caveats. Does this still work in recent
versions?
If we can take this for granted, all Forge modules can adhere to that
same standard.
Yes, it's quite a hassle.
No, I didn't think this through very thoroughly ;-)
Just another pair of cents.
Cheers,
Felix
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Template Help Please
Hello,
I am trying to setup a template with data being passed in as a long
string of data which is being returned via extlookup()
i.e. $resolvers = "10.10.10.10 11.11.11.11.12.12.12.12"
The template should split those up and put a nameserver entry per line
in /etc/resolv.conf
I have this in the template now:-
<%= scope.lookupvar('resolver::params::resolvers').split(/\s+/).each
do | ns | %>
nameserver <%= ns %>
<% end -%>
Which is throwing a syntax error. Can't for the life of me work out
whats wrong. Probably not had enough coffee yet.
Any ideas ?
Thanks
Paul
--
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+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Augeas lens for zabbix agent config files?
Thanks for the pointers Dominic, I'll check them out later this week and report back with my findings! On Mon, Jan 23, 2012 at 11:34, Dominic Cleal wrote: > Hi Walter, > > [ CCing the augeas-devel list, as that's the best place for Augeas lens > problems and help ] > > On 22/01/12 20:48, Walter Heck wrote: >> Hi all, >> >> I'm trying to come up with a lens for the zabbix agent config files. I >> find the lens language untransparent at best, so I'm struggeling to >> figure out what's up. The debugging possibilities are extremely >> limited. Here's what I have now: > > For debugging, I'd strongly recommend creating a test file, which you > can do this simply with your existing Zabbix config. I've created a > sample here that uses the head -n25 output you pasted - I suggest you > fill in the rest: > https://gist.github.com/1662040 > > Store it in lenses/tests/test_zabbix_agent.aug and then you can run: > augparse -I lenses/ lenses/tests/test_zabbix_agent.aug > > (with your new lens under the lenses directory) > > No output means the lens has checked out fine and the output tree (in > the bottom half of the test) matches the input file at the top. > >> And the augeas output (all empty): >> == >> [/etc/puppet] # augparse /usr/share/augeas/lenses/contrib/zabbix_agent.aug >> [/etc/puppet] # augtool -e ls /files/etc/zabbix/zabbix_agentd.conf >> == > > Since the output of head -n25 works perfectly for me, I suspect the > problem might be parsing something in the remainder of the file. > > Try running "print /augeas//error" from within augtool and see if you > get /files/etc/zabbix/zabbix_agentd.conf listed. This wiki page > explains how to parse the parse errors: > http://augeas.net/page/Tracking_down_errors > > There are some other useful tutorials about creating lenses, the > ambiguity problems you might hit and other subjects on the wiki: > http://augeas.net/page/Main_Page > > If you manage to solve it, please do consider sending your new lens (and > accompanying test) upstream to the augeas-devel list, we'd love to > include it. > > Hope that helps. > > -- > Dominic Cleal > Red Hat Consulting > m: +44 (0)7817 878113 -- Walter Heck -- follow @walterheck on twitter to see what I'm up to! -- Check out my new startup: Server Monitoring as a Service @ http://tribily.com Follow @tribily on Twitter and/or 'Like' our Facebook page at http://www.facebook.com/tribily -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Augeas lens for zabbix agent config files?
Hi Walter, [ CCing the augeas-devel list, as that's the best place for Augeas lens problems and help ] On 22/01/12 20:48, Walter Heck wrote: > Hi all, > > I'm trying to come up with a lens for the zabbix agent config files. I > find the lens language untransparent at best, so I'm struggeling to > figure out what's up. The debugging possibilities are extremely > limited. Here's what I have now: For debugging, I'd strongly recommend creating a test file, which you can do this simply with your existing Zabbix config. I've created a sample here that uses the head -n25 output you pasted - I suggest you fill in the rest: https://gist.github.com/1662040 Store it in lenses/tests/test_zabbix_agent.aug and then you can run: augparse -I lenses/ lenses/tests/test_zabbix_agent.aug (with your new lens under the lenses directory) No output means the lens has checked out fine and the output tree (in the bottom half of the test) matches the input file at the top. > And the augeas output (all empty): > == > [/etc/puppet] # augparse /usr/share/augeas/lenses/contrib/zabbix_agent.aug > [/etc/puppet] # augtool -e ls /files/etc/zabbix/zabbix_agentd.conf > == Since the output of head -n25 works perfectly for me, I suspect the problem might be parsing something in the remainder of the file. Try running "print /augeas//error" from within augtool and see if you get /files/etc/zabbix/zabbix_agentd.conf listed. This wiki page explains how to parse the parse errors: http://augeas.net/page/Tracking_down_errors There are some other useful tutorials about creating lenses, the ambiguity problems you might hit and other subjects on the wiki: http://augeas.net/page/Main_Page If you manage to solve it, please do consider sending your new lens (and accompanying test) upstream to the augeas-devel list, we'd love to include it. Hope that helps. -- Dominic Cleal Red Hat Consulting m: +44 (0)7817 878113 -- 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+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
