[Puppet Users] Re: [Puppet-dev] Converting to Ruby DSL
On Dec 8, 2010, at 11:09 AM, Ken Barber wrote:
> (cross posting here as I originally posted in puppet-users - I figure the
> question is more of a dev one then for puppet-users)
>
> Hi everyone,
>
> I'm experimenting with converting some of my live puppet content to
> Ruby DSL and have found a few gaps I wouldn't mind some advice on. I'm
> not sure how many of you have already experimented in this arena yet.
>
> I've already read Dan Bode's excellent blog article on the subject:
>
> http://www.puppetlabs.com/blog/ruby-dsl/
>
> I know the Ruby DSL is quite new - but I figured perhaps some of these
> items deserve to be tickets (or perhaps documented) and I thought I'd
> ask first :-).
Thanks for testing this. As you say, it's still quite new, and definitely
incomplete, but as with most things we do, I wanted to get a simple thing out
and in the wild rather than wait for perfection before shipping. This kind of
feedback is exactly what we need (although of course patches are even better).
> 1. Defaults
>
> How do I set defaults in Ruby DSL? For example what is the ruby DSL
> equivalent to this:
>
> Service {
> hasstatus => true
> }
This is one of the things I left out of my initial implementation.
You might be able to figure out how to add it by patching one of the files in
lib/puppet/dsl.
> 2. Top scope
>
> I notice the convenience methodology does not work at 'top scope' for
> example
> this will fail:
>
> file "/tmp/zzz", :content => "foo"
>
> But this will not:
>
> node "default" do
> file "/tmp/zzz", :content => "foo"
> end
>
> Is there a proper way to call resources without using the convenience
> methods? Or
> perhaps is there a way to define elements that reside in top scope?
I made a decision when I did this not to pollute the top namespace - both for
cleanliness, and also for simplicity of implementation. This has come up a few
times, though, so it's something that I'm happy to revisit.
> 3. Class resource
>
> I think Dan Bode already raised this as a bug:
>
> https://projects.puppetlabs.com/issues/5236
>
> The following returns an error 'method_missing':
>
> hostclass :foo do
> notify "bar"
> end
> node "default" do
> hostclass "foo", :stage => "baz"
> end
>
> This is because hostclass has not been defined as a convenience method
> it would seem. Just like issues 2 If someone knows
> a way to call a resource directly without requiring the convenience
> method that would be a decent enough work-around.
Hmm. It should be, but it looks like this is failing somewhere and has been
marked as a high priority bug. :/
> 4. exec Resource
>
> The 'exec' resource as a convenience method is overlapping with the
> ruby 'exec'
> method. So if you do this:
>
> node "default" do
> exec "ls", :command => "/bin/ls"
> end
>
> You get:
>
> can't convert Hash into String on node obelisk.usr.bob.sh
>
> Returned from the Kernel.exec call.
You should be able to use 'create_resource :exec, ...' here.
> 5. Referencing other resources
>
> I'm not quite clear how to reference other resources that already
> exist. This is obviously a problem for the 'require' attribute:
>
> node "default" do
> package "foo", :ensure => "installed"
> service "foo", :enable => "true", :ensure => "running", :require
> => ???
> end
I believe the internal implementation allows you to do 'require => [:package,
"foo"]'. I couldn't find a reasonable syntax for this, without a lot more work
making, e.g., Package["foo"] work, which was my ideal.
> 6. Chaining Resources
>
> Is there a syntactical equivalent to this in Ruby DSL yet? For
> example:
>
> Stage[pre] -> Stage[main] -> Stage[post]
>
> Without knowing how to solve 5 I'm kind of stuck when it comes to
> defining dependencies :-).
There isn't.
The DSL is obviously still a subset of the "full" Puppet language (ironic,
given how small the language is).
--
Computers are not intelligent. They only think they are.
-
Luke Kanies -|- http://puppetlabs.com -|- +1(615)594-8199
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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 using puppet on partially installed systems.
Much appreciated, the good advice. Thanks. That makes total sense, -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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 using puppet on partially installed systems.
On Fri, Dec 10, 2010 at 15:00, Kevin Beckford wrote:
> So, my configuration attempts are aimed at Linodes. Ubuntu 10.10 to be exact.
> Linodes are libcloud enabled as well as basically provisioned. What I seek
> to do is add to that, not build from nothing, since libcloud et. al. give me
> a base to work with.
> What is the canonical way to manage this situation?
I can't necessarily speak to the "canonical" way, but the process we
use for our infrastructure is relatively similar. Debian based,
private cloud type facility, but the starting point is more or less
where the libcloud puppet example puts things - Debian, with puppet
installed.
> For example:
> $ puppet resource package --verbose openssh-client
> package { 'openssh-client':
> ensure => '1:5.5p1-4ubuntu4'
> }
> Does my manifest need to take this and similar into account?
Puppet has a policy that if you don't tell it about something one way
or another it will leave it the heck alone. (This is worth mentioning
because other tools in the space take the view that if they don't
know, get rid of it.)
So, to answer the specific question: it depends. You could just
ignore it, and have faith that the pre-installed package was doing the
right thing. Personally, I would have "package { 'openssh-client':
ensure => latest }" in there because upgrades to it are smooth,
typically security related, and have a long history of not breaking
things.
In terms of the bigger philosophical question: I would advise that you
define in puppet what the machines should look like. That means that
if you care about ssh as a service you should specify that it is
installed, at least. When the package is already there puppet will
see that, and take no further action. OTOH, if it doesn't install on
some random machine for who knows what reason, or some typo purges it,
puppet will restore the machine to the way it should be.
OTOH, I probably left 95 percent of the "base" system packages out of
my manifests, because they were just there and there was no benefit to
writing out hundreds of "just in case" declarations.
Regards,
Daniel
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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 using puppet on partially installed systems.
So, my configuration attempts are aimed at Linodes .
Ubuntu 10.10 to be exact.
Linodes are libcloud enabled as well as basically provisioned. What I
seek to do is add to that, not build from nothing, since libcloud et.
al. give me a base to work with.
What is the canonical way to manage this situation?
For example:
$ puppet resource package --verbose openssh-client
package { 'openssh-client':
ensure => '1:5.5p1-4ubuntu4'
}
Does my manifest need to take this and similar into account?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: quick basics to install functioning ubuntu system?
Ah, What I was looking for originally was a higher level of granularity besides modules. Classes, in particular seems to be what I was originally seeking. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] puppet fileserver
On Thu, Dec 9, 2010 at 5:38 PM, R.I.Pienaar wrote: > > > On 10 Dec 2010, at 00:55, Nigel Kersten wrote: > >> On Thu, Dec 9, 2010 at 1:34 PM, Brice Figureau >> wrote: >>> On 09/12/10 21:36, Chris C wrote: I planned on moving to Passenger very soon. What about the file server? Is there any worth in moving from nfs/autofs to puppet fileserver? >>> >>> The only reason I can see is security, access control and auditing. >>> Every access is protected through SSL, can be logged and passes through >>> the authorization layer (ie fileserver.conf). >> >> I think there's another big benefit to using the internal fileserver. >> >> Your manifest and file source changes are synchronized in lock-step. >> >> When you're using anything else with it's own replication periods, you >> can end up with frustrating situations where a manifest has updated >> but a file hasn't. > > > You get this anyway unless you have the ability to update your entire > checkout atomically. It's actually even worse because based on the typical > update-a-checkout pattern that people use you can't even be guaranteed the > you get a sane set of manifests compiled. You can update the entire checkout atomically, but yeah, I agree that most people don't tend to do this, and they should. It's much harder to do with another system entirely, and becomes close to impossible once you add replication across sites into the mix. > Worse the config version feature is unaware of file server changes making it > pointless as an aid to almost anything that would matter. I think we've already agreed that bug needs to be fixed haven't we? :) > > >> >> >> >> >>> In terms of performance I don't think it would have any impact (provided >>> you run 2.6) on your master and client (but that mostly depends on your >>> access patterns). And you can still use file content offloading (see one >>> of my blog post for more information). >>> -- >>> Brice Figureau >>> My Blog: http://www.masterzen.fr/ >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Puppet Users" group. >>> To post to this group, send email to puppet-us...@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 - Puppet Labs - http://www.puppetlabs.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-us...@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-us...@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 - Puppet Labs - http://www.puppetlabs.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-us...@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] some files are getting errors during source => "puppet:///..."
I get the following error: ... Failed to retrieve current state of resource: Could not retrieve information from source(s) ... My understanding is that the file server had trouble pulling the metadata for the file (on the server side). This could be due to a connectivity issue, or a permissions issue. What other reasons are there? Does the target affect it as well? Where in the puppet code does all this happen? (for instance that error is coming from type/ file/source.rb, so what gets to that code?). I have verified all my permissions (both of files and directories). All the connections are fine. However, some of my files work fine and others do not. The same files in both cases, every time. The files that work are ones that were done back when I had one modules directory in my module_path. However, now I have several. The ones that are in modules I have added since I split my modules directories are the ones that do not work. The old ones work even though I moved them into the new modules directories. This is driving me crazy. Any thoughts? -eric -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] puppet fileserver
On 10 Dec 2010, at 00:55, Nigel Kersten wrote: > On Thu, Dec 9, 2010 at 1:34 PM, Brice Figureau > wrote: >> On 09/12/10 21:36, Chris C wrote: >>> I planned on moving to Passenger very soon. >>> >>> What about the file server? Is there any worth in moving from >>> nfs/autofs to puppet fileserver? >> >> The only reason I can see is security, access control and auditing. >> Every access is protected through SSL, can be logged and passes through >> the authorization layer (ie fileserver.conf). > > I think there's another big benefit to using the internal fileserver. > > Your manifest and file source changes are synchronized in lock-step. > > When you're using anything else with it's own replication periods, you > can end up with frustrating situations where a manifest has updated > but a file hasn't. You get this anyway unless you have the ability to update your entire checkout atomically. It's actually even worse because based on the typical update-a-checkout pattern that people use you can't even be guaranteed the you get a sane set of manifests compiled. Worse the config version feature is unaware of file server changes making it pointless as an aid to almost anything that would matter. > > > > >> In terms of performance I don't think it would have any impact (provided >> you run 2.6) on your master and client (but that mostly depends on your >> access patterns). And you can still use file content offloading (see one >> of my blog post for more information). >> -- >> Brice Figureau >> My Blog: http://www.masterzen.fr/ >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Puppet Users" group. >> To post to this group, send email to puppet-us...@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 - Puppet Labs - http://www.puppetlabs.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-us...@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-us...@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] puppet fileserver
On Thu, Dec 9, 2010 at 1:34 PM, Brice Figureau wrote: > On 09/12/10 21:36, Chris C wrote: >> I planned on moving to Passenger very soon. >> >> What about the file server? Is there any worth in moving from >> nfs/autofs to puppet fileserver? > > The only reason I can see is security, access control and auditing. > Every access is protected through SSL, can be logged and passes through > the authorization layer (ie fileserver.conf). I think there's another big benefit to using the internal fileserver. Your manifest and file source changes are synchronized in lock-step. When you're using anything else with it's own replication periods, you can end up with frustrating situations where a manifest has updated but a file hasn't. > In terms of performance I don't think it would have any impact (provided > you run 2.6) on your master and client (but that mostly depends on your > access patterns). And you can still use file content offloading (see one > of my blog post for more information). > -- > Brice Figureau > My Blog: http://www.masterzen.fr/ > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@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 - Puppet Labs - http://www.puppetlabs.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-us...@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] Setting txqueuelen in Puppet
On Fri, Dec 10, 2010 at 09:02, Sid wrote: > We would like to set the txqueuelen on an ethernet interface in a > Linux box using Puppet. Has anyone done this before? No, though I have done other similar level things. I would very strongly advice that you use the network tools supplied with the OS, and only ship their configuration through puppet to make them do this. (eg: on Debian, in the /etc/network/interfaces file) That way you will not, for example, have the tx queue the wrong size at reboot until your first puppet run. :) Regards, Daniel -- ✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707 ♽ made with 100 percent post-consumer electrons -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Python pip package provider
Thats good news, then. Great news, in fact! -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Setting txqueuelen in Puppet
Hi, We would like to set the txqueuelen on an ethernet interface in a Linux box using Puppet. Has anyone done this before? Sid -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] puppet fileserver
On 09/12/10 21:36, Chris C wrote: > I planned on moving to Passenger very soon. > > What about the file server? Is there any worth in moving from > nfs/autofs to puppet fileserver? The only reason I can see is security, access control and auditing. Every access is protected through SSL, can be logged and passes through the authorization layer (ie fileserver.conf). In terms of performance I don't think it would have any impact (provided you run 2.6) on your master and client (but that mostly depends on your access patterns). And you can still use file content offloading (see one of my blog post for more information). -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Python pip package provider
On Thu, Dec 9, 2010 at 12:12 PM, Kevin Beckford wrote: > distribute2 is the way forward, not pip, I believe. Distribute is taking over for setuptools for building packages. Pip is taking over for easy_install for installing packages from the central PyPI repository. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] puppet fileserver
I planned on moving to Passenger very soon. What about the file server? Is there any worth in moving from nfs/autofs to puppet fileserver? /C On Thu, Dec 9, 2010 at 2:25 PM, Patrick wrote: > > On Dec 9, 2010, at 9:45 AM, Chris C wrote: > > > How robust and secure is the embedded fileserver in puppet? > > > > So far my environment consists of 15 nodes with about 80 checks per node. > I'm doing alot of md5 checks on files. I anticipate ~150 nodes. I am > currently using autofs and the source for my files is > /net/netapp/puppet/files/ > > > > Right now I'm not compelled to change this but I was just wondering... > > In my experience, Webrick (the default webserver) will fail very badly > under that load meaning you'll need to move to Mongral or Passenger. > > -- > You received this message because you are subscribed to the Google Groups > "Puppet Users" group. > To post to this group, send email to puppet-us...@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-us...@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: Python pip package provider
distribute2 is the way forward, not pip, I believe. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: quick basics to install functioning ubuntu system?
Thanks. I did see those before. At the time of my original question, I was looking for sets of modules, which do not seem to exist per se. The urgency has passed, I did it by hand. This however is a terrible way to think ;) so I am relearning puppet for the next time. I think I get it now, what I was looking for is what I'll build today. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] puppet fileserver
On Dec 9, 2010, at 9:45 AM, Chris C wrote: > How robust and secure is the embedded fileserver in puppet? > > So far my environment consists of 15 nodes with about 80 checks per node. > I'm doing alot of md5 checks on files. I anticipate ~150 nodes. I am > currently using autofs and the source for my files is > /net/netapp/puppet/files/ > > Right now I'm not compelled to change this but I was just wondering... In my experience, Webrick (the default webserver) will fail very badly under that load meaning you'll need to move to Mongral or Passenger. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] apt-get -t lenny-backports
On 09/12/10 19:19, Patrick wrote: > > On Dec 9, 2010, at 10:07 AM, Brice Figureau wrote: > >> On 09/12/10 03:38, Daniel Pittman wrote: >>> Sadly, no. I very much missed the feature. We ended up using the apt >>> preferences file to implement that behaviour >>> >>> If I was doing it over I would use a define that added the package >>> resource and also used concat to automatically build up the preferences >>> entry. >> >> I have a define called apt::source that at the same time adds a source >> to sources.list.d and creates a fragment of apt preferences (with a >> carefully set pin priority), which when all concatenated form the >> central apt preferences file. >> >> This works flawlessly :) > > I would love to get my hands on that. Any chance you could post it? Here it is: https://gist.github.com/21ec1c202b7614a23086 It is not the complete apt class I'm using but should be a good start for you. It's some old code I wrote 2 years ago, so the code style is not perfect :) It uses two definitions coming from David Schmidtt, concatenate_file which handles the fragment pattern and config_file which is just a file with the correct perms/backup... Oh and bonus, this also handles custom apt keys. Hope that helps, -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: The puppet model
Helpful indeed. While reading the description, one thing puzzled me. Is it true that "the required resource will be instantiated after the requiring resource" when building the dependency graph model? I would have expected it to be the other way around... Thanks, Kenn -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] apt-get -t lenny-backports
On Dec 9, 2010, at 10:07 AM, Brice Figureau wrote: > On 09/12/10 03:38, Daniel Pittman wrote: >> Sadly, no. I very much missed the feature. We ended up using the apt >> preferences file to implement that behaviour >> >> If I was doing it over I would use a define that added the package >> resource and also used concat to automatically build up the preferences >> entry. > > I have a define called apt::source that at the same time adds a source > to sources.list.d and creates a fragment of apt preferences (with a > carefully set pin priority), which when all concatenated form the > central apt preferences file. > > This works flawlessly :) I would love to get my hands on that. Any chance you could post it? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Could not evaluate: 'test' is not executable
On Dec 9, 2010, at 9:14 AM, luke.bigum wrote:
> Interesting, I've noticed that puppet runs triggered from a daemonised
> puppetd aren't affected by the problem (as Dashboard and /var/log/
> messages says their is no errors), but when run from the command line
> as puppetd --test it fails as usual for me:
>
> err: /Stage[main]/Fh_freetds/Exec[change /etc/freetds.conf version]:
> Could not evaluate: 'grep' is not executable
>
> Can't spot any difference in the environments so far.
Here's something to try, can you reproduce this problem using the local
"puppet" program that directly evaluates the manifest. Not the client
"puppetd". If so, that's a lot less code you've narrowed to down to.
> On Dec 9, 4:42 pm, "luke.bigum" wrote:
>> Hi Rudy,
>>
>> I'm not sure if you fixed this yet, but I ran into the same problem
>> using grep in an unless parameter of an exec resource.
>>
>> I went looking through the Ruby code, in /usr/lib/ruby/site_ruby/1.8/
>> puppet/type/exec.rb on line 571. I changed these four lines:
>>
>> unless FileTest.executable?(exe)
>> raise ArgumentError,
>> "'#{exe}' is not executable"
>> end
>>
>> To just a single line like the one above:
>>
>> raise ArgumentError, "'#{exe}' is not executable" unless
>> FileTest.executable?(exe)
>>
>> And then Puppet stopped complaining. I thought this doesn't make any
>> sense at all, so I changed it back... Puppet still worked. I removed
>> and reinstalled the RPM, Puppet is back to complaining about grep not
>> being executable. I then just touched exec.rb and the problem is
>> magically fixed again.
>>
>> I don't know very much about Ruby, so I'm just going to back away
>> very, very slowly, arms raised in the air to ward off evil ;)
>>
>> But seriously, is there a Ruby guru who might know what's going on
>> here? I can even reproduce the issue by uninstalling and reinstalling
>> the puppet RPM - not sure how long it's going to stay broken though,
>> we'll see.
>>
>> -Luke
>>
>> On Dec 2, 10:30 am, Rudy Gevaert wrote:
>>
>>> Hi
>>
>>> I'm seeing a strange thing here. I only have this on one machine! 3
>>> others that are 'identical' don't have that issue...
>>
>>> err: /Stage[main]/Vim/Exec[update-alternatives --set editor /usr/bin/
>>> vim.basic]: Could not evaluate: 'test' is not executable
>>
>>> class vim{
>>
>>> $vim_package= "vim"
>>
>>> package {
>>> $vim_package:
>>> ensure => installed,
>>> provider => $operatingsystem ? {
>>> "Solaris" => 'pkgutil',
>>> default => undef
>>> }
>>> }
>>
>>> case $operatingsystem{
>>> "Debian": {
>>> exec { "update-alternatives --set editor /usr/bin/vim.basic":
>>> path => "/bin:/sbin:/usr/bin:/usr/sbin",
>>> unless => "test /etc/alternatives/editor -ef /usr/bin/
>>> vim.basic"
>>> }
>>> }
>>> }
>>
>>> }
>>
>>> Manual output:
>>
>>> r...@cyrprd1:~# puppet agent --test
>>> info: Retrieving plugin
>>> info: Loading facts in ugentinfo
>>> info: Loading facts in configured_ntp_servers
>>> info: Loading facts in ugentinfo
>>> info: Loading facts in configured_ntp_servers
>>> info: Caching catalog for cyrprd1.ugent.be
>>> info: Applying configuration version '1291285388'
>>> notice: /Stage[main]/Debian_os/Exec[apt-get-update]/returns: executed
>>> successfully
>>> notice: /Stage[main]/Mailstore/Package[cyrus-ugent]/ensure: ensure
>>> changed '0.1-33' to '0.1-34'
>>> err: /Stage[main]/Vim/Exec[update-alternatives --set editor /usr/bin/
>>> vim.basic]: Could not evaluate: 'test' is not executable
>>> notice: Finished catalog run in 7.66 seconds
>>
>>> r...@cyrprd1:~# test /etc/alternatives/editor -ef /usr/bin/vim.basic
>>> r...@cyrprd1:~# which test
>>> /usr/bin/test
>>> r...@cyrprd1:~# ls -l /usr/bin/test
>>> -rwxr-xr-x 1 root root 30136 Apr 28 2010 /usr/bin/test
>>> r...@cyrprd1:~#
>>
>>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] apt-get -t lenny-backports
On 09/12/10 03:38, Daniel Pittman wrote: > Sadly, no. I very much missed the feature. We ended up using the apt > preferences file to implement that behaviour > > If I was doing it over I would use a define that added the package > resource and also used concat to automatically build up the preferences > entry. I have a define called apt::source that at the same time adds a source to sources.list.d and creates a fragment of apt preferences (with a carefully set pin priority), which when all concatenated form the central apt preferences file. This works flawlessly :) -- Brice Figureau My Blog: http://www.masterzen.fr/ -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] puppet fileserver
How robust and secure is the embedded fileserver in puppet? So far my environment consists of 15 nodes with about 80 checks per node. I'm doing alot of md5 checks on files. I anticipate ~150 nodes. I am currently using autofs and the source for my files is /net/netapp/puppet/files/ Right now I'm not compelled to change this but I was just wondering... Thanks, /Chris Callegari -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Calling class defines in pure ruby DSL
Let's say I have a define in class 'foo' called 'foo::bar':
define foo::bar ($var1, $var2) {
...
}
Then I have a ruby hostclass
hostclass :foo do
...
}
I see I can successfully set the parameters by doing:
environment.known_resource_types.definitions['foo::bar'].set_arguments :var1 =>
'val1', :var2 => 'val2'
But this raises two problems.
1) foo::bar doesn't exist in known_resource_types.definitions unless you add it
manually or it exists in the same rb file as the class. So how I do an auto
load?
2) How do I actually call it?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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: Could not evaluate: 'test' is not executable
Interesting, I've noticed that puppet runs triggered from a daemonised
puppetd aren't affected by the problem (as Dashboard and /var/log/
messages says their is no errors), but when run from the command line
as puppetd --test it fails as usual for me:
err: /Stage[main]/Fh_freetds/Exec[change /etc/freetds.conf version]:
Could not evaluate: 'grep' is not executable
Can't spot any difference in the environments so far.
On Dec 9, 4:42 pm, "luke.bigum" wrote:
> Hi Rudy,
>
> I'm not sure if you fixed this yet, but I ran into the same problem
> using grep in an unless parameter of an exec resource.
>
> I went looking through the Ruby code, in /usr/lib/ruby/site_ruby/1.8/
> puppet/type/exec.rb on line 571. I changed these four lines:
>
> unless FileTest.executable?(exe)
> raise ArgumentError,
> "'#{exe}' is not executable"
> end
>
> To just a single line like the one above:
>
> raise ArgumentError, "'#{exe}' is not executable" unless
> FileTest.executable?(exe)
>
> And then Puppet stopped complaining. I thought this doesn't make any
> sense at all, so I changed it back... Puppet still worked. I removed
> and reinstalled the RPM, Puppet is back to complaining about grep not
> being executable. I then just touched exec.rb and the problem is
> magically fixed again.
>
> I don't know very much about Ruby, so I'm just going to back away
> very, very slowly, arms raised in the air to ward off evil ;)
>
> But seriously, is there a Ruby guru who might know what's going on
> here? I can even reproduce the issue by uninstalling and reinstalling
> the puppet RPM - not sure how long it's going to stay broken though,
> we'll see.
>
> -Luke
>
> On Dec 2, 10:30 am, Rudy Gevaert wrote:
>
> > Hi
>
> > I'm seeing a strange thing here. I only have this on one machine! 3
> > others that are 'identical' don't have that issue...
>
> > err: /Stage[main]/Vim/Exec[update-alternatives --set editor /usr/bin/
> > vim.basic]: Could not evaluate: 'test' is not executable
>
> > class vim{
>
> > $vim_package= "vim"
>
> > package {
> > $vim_package:
> > ensure => installed,
> > provider => $operatingsystem ? {
> > "Solaris" => 'pkgutil',
> > default => undef
> > }
> > }
>
> > case $operatingsystem{
> > "Debian": {
> > exec { "update-alternatives --set editor /usr/bin/vim.basic":
> > path => "/bin:/sbin:/usr/bin:/usr/sbin",
> > unless => "test /etc/alternatives/editor -ef /usr/bin/
> > vim.basic"
> > }
> > }
> > }
>
> > }
>
> > Manual output:
>
> > r...@cyrprd1:~# puppet agent --test
> > info: Retrieving plugin
> > info: Loading facts in ugentinfo
> > info: Loading facts in configured_ntp_servers
> > info: Loading facts in ugentinfo
> > info: Loading facts in configured_ntp_servers
> > info: Caching catalog for cyrprd1.ugent.be
> > info: Applying configuration version '1291285388'
> > notice: /Stage[main]/Debian_os/Exec[apt-get-update]/returns: executed
> > successfully
> > notice: /Stage[main]/Mailstore/Package[cyrus-ugent]/ensure: ensure
> > changed '0.1-33' to '0.1-34'
> > err: /Stage[main]/Vim/Exec[update-alternatives --set editor /usr/bin/
> > vim.basic]: Could not evaluate: 'test' is not executable
> > notice: Finished catalog run in 7.66 seconds
>
> > r...@cyrprd1:~# test /etc/alternatives/editor -ef /usr/bin/vim.basic
> > r...@cyrprd1:~# which test
> > /usr/bin/test
> > r...@cyrprd1:~# ls -l /usr/bin/test
> > -rwxr-xr-x 1 root root 30136 Apr 28 2010 /usr/bin/test
> > r...@cyrprd1:~#
>
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] my first template
On Thu, 09 Dec 2010 15:28:22 +0100
Felix Frank wrote:
> On 12/09/2010 03:12 PM, Arnau Bria wrote:
> > Hi all,
> >
> > thanks for your replies.
> >
> > So doc is confusing here:
> >
> > http://projects.puppetlabs.com/projects/1/wiki/Puppet_Templating
> > [...]
> > content => template("tracsite.erb"),
> > [...]
>
> Ah, but that document assumes that your templates are directly inside
> your $templatesdir, not in a module.
yep. for that reason I said confusing and not wrong :-)
> That can indeed be confusing. You may want to take a look and see if
> there is a good place in there to add a warning about this.
I'll create my user and do the edit.
> Cheers,
> Felix
Cheers,
Arnau
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Puppet in a virtual environment
> > On Dec 8, 2010, at 4:13 AM, john maclean wrote: > >> Morning chaps, >> >> From my understanding the puppet master must have a hostname of >> "puppet". Is this correct? I'd like to be able to call this box >> whatever I like. I think that I can do that within >> /etc/puppet/puppet.conf. >> >> >> >> -- >> John Maclean >> MSc (DIC) >> >> Enterprise Linux Systems Engineer >> What I do is name my server what ever I want and then DNS I add a "puppet" CNAME record to point to my server's real name. It saves me a lot headaches both in puppet and the rest of my infrastructure. Evan -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Could not evaluate: 'test' is not executable
Hi Rudy,
I'm not sure if you fixed this yet, but I ran into the same problem
using grep in an unless parameter of an exec resource.
I went looking through the Ruby code, in /usr/lib/ruby/site_ruby/1.8/
puppet/type/exec.rb on line 571. I changed these four lines:
unless FileTest.executable?(exe)
raise ArgumentError,
"'#{exe}' is not executable"
end
To just a single line like the one above:
raise ArgumentError, "'#{exe}' is not executable" unless
FileTest.executable?(exe)
And then Puppet stopped complaining. I thought this doesn't make any
sense at all, so I changed it back... Puppet still worked. I removed
and reinstalled the RPM, Puppet is back to complaining about grep not
being executable. I then just touched exec.rb and the problem is
magically fixed again.
I don't know very much about Ruby, so I'm just going to back away
very, very slowly, arms raised in the air to ward off evil ;)
But seriously, is there a Ruby guru who might know what's going on
here? I can even reproduce the issue by uninstalling and reinstalling
the puppet RPM - not sure how long it's going to stay broken though,
we'll see.
-Luke
On Dec 2, 10:30 am, Rudy Gevaert wrote:
> Hi
>
> I'm seeing a strange thing here. I only have this on one machine! 3
> others that are 'identical' don't have that issue...
>
> err: /Stage[main]/Vim/Exec[update-alternatives --set editor /usr/bin/
> vim.basic]: Could not evaluate: 'test' is not executable
>
> class vim{
>
> $vim_package= "vim"
>
> package {
> $vim_package:
> ensure => installed,
> provider => $operatingsystem ? {
> "Solaris" => 'pkgutil',
> default => undef
> }
> }
>
> case $operatingsystem{
> "Debian": {
> exec { "update-alternatives --set editor /usr/bin/vim.basic":
> path => "/bin:/sbin:/usr/bin:/usr/sbin",
> unless => "test /etc/alternatives/editor -ef /usr/bin/
> vim.basic"
> }
> }
> }
>
> }
>
> Manual output:
>
> r...@cyrprd1:~# puppet agent --test
> info: Retrieving plugin
> info: Loading facts in ugentinfo
> info: Loading facts in configured_ntp_servers
> info: Loading facts in ugentinfo
> info: Loading facts in configured_ntp_servers
> info: Caching catalog for cyrprd1.ugent.be
> info: Applying configuration version '1291285388'
> notice: /Stage[main]/Debian_os/Exec[apt-get-update]/returns: executed
> successfully
> notice: /Stage[main]/Mailstore/Package[cyrus-ugent]/ensure: ensure
> changed '0.1-33' to '0.1-34'
> err: /Stage[main]/Vim/Exec[update-alternatives --set editor /usr/bin/
> vim.basic]: Could not evaluate: 'test' is not executable
> notice: Finished catalog run in 7.66 seconds
>
> r...@cyrprd1:~# test /etc/alternatives/editor -ef /usr/bin/vim.basic
> r...@cyrprd1:~# which test
> /usr/bin/test
> r...@cyrprd1:~# ls -l /usr/bin/test
> -rwxr-xr-x 1 root root 30136 Apr 28 2010 /usr/bin/test
> r...@cyrprd1:~#
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Feature request: queued triggers
On 08-12-10 21:10, Jason Lavoie wrote: > On 12/08, Martijn Grendelman wrote: >> I would like to have the possibility to tell Puppet to queue the trigger, >> and when the currently running catalog run is finished, process it and do >> another run. >> >> Does this sound like a good idea? > > I thought so, and proposed a similar feature a while back: > > http://projects.puppetlabs.com/issues/2763 Ah, I didn't bother to check the issue tracker. Updated by Luke Kanies about 1 year ago: "of course, a relatively low priority" I wonder what 'relatively' means in this respect ;-) Cheers, Martijn. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] class name size
BTWmy normal check in time is 12 secs.not 76 secs. ;)
I was running a mysql query on that box in another terminal.
/C
On Thu, Dec 9, 2010 at 9:58 AM, Chris C wrote:
> Good thinking Felix.
>
> I changed the class name to syslogngcrctesting and wahlah! the client pulls
> and applies the catalog.
>
>
> [r...@syslogng ~]# puppetd --test --verbose
> notice: Ignoring --listen on onetime run
> info: Caching catalog for syslogng.akc.org
> info: Applying configuration version '1291906551'
> notice: /Stage[main]/All_hosts_redhat/Service[nfslock]/ensure: ensure
> changed 'stopped' to 'running'
> notice: /Stage[main]/All_hosts_redhat/Service[nfs]/ensure: ensure changed
> 'running' to 'stopped'
> notice: /Stage[main]/All_hosts_redhat/Service[atd]/ensure: ensure changed
> 'running' to 'stopped'
> notice: /Stage[main]/All_hosts_redhat/Service[autofs]/ensure: ensure
> changed 'stopped' to 'running'
> notice: /Stage[main]/All_hosts_redhat/Service[syslog]/ensure: ensure
> changed 'running' to 'stopped'
> info: /Stage[main]/All_hosts_redhat/Service[syslog]: Scheduling refresh of
> Service[syslog-ng]
> notice: /Stage[main]/Syslogngcrctesting/Service[syslog-ng]/ensure: ensure
> changed 'stopped' to 'running'
> notice: /Stage[main]/Syslogngcrctesting/Service[syslog-ng]: Triggered
> 'refresh' from 1 events
> notice: Finished catalog run in 76.44 seconds
> [r...@syslogng ~]#
>
>
> /Chris C
>
>
>
> On Thu, Dec 9, 2010 at 9:27 AM, Felix Frank <
> felix.fr...@alumni.tu-berlin.de> wrote:
>
>> > [r...@puppetmaster manifests]# cat site.pp
>> > import "classes/redhat/prod/inf/syslogng/class.pp"
>> >
>> > node syslogng {
>> > include syslogng
>> > }
>>
>> Maybe an issue with classname == nodename?
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Puppet Users" group.
>> To post to this group, send email to puppet-us...@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-us...@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: Certificate verify failed
Found out the error. Both the master and client were showing the same time. But they happened to be on different time zones. AHH! On Dec 8, 1:19 pm, Kikanny wrote: > Hi Nan > > Thanks for your response. I tried that. But it says that everything is > okay. I get "verify return 1" instead of saying why there is a > verification error > > On Dec 8, 10:54 am, Nan Liu wrote: > > > On Wed, Dec 8, 2010 at 6:20 AM, Kikanny wrote: > > > So there is something wrong with the date of the certificate. When I > > > do "openssl x509 -text -in -noout /etc/puppet/ssl/certs/client.pem | > > > grep -A2 Validity", I get: > > > > Validity > > > Not Before: Dec 7 14:08:10 2010 GMT > > > Not After : Dec 6 14:08:10 2015 GMT > > > > However, the current date of the client is Dec 8 which is well within > > > the valid range. The date is also the same as master server. But when > > > I change the date of the client to Dec 9, everything works fine and I > > > don't get that certificate verify failed error anymore. This is > > > baffling! Any idea how to fix this? Thanks! > > > Let's use openssl to debug this and see if we can get a better error > > message indicating why the cert is rejected. In the command below > > replace the certs and ca to the appropriate path on your system: > > > openssl s_client -host puppet -port 8140 -cert > > /var/lib/puppet/ssl/certs/puppet.training.pem -key > > /var/lib/puppet/ssl/private_keys/puppet.training.pem -CAfile > > /var/lib/puppet/ssl/certs/ca.pem > > > A successful connection: > > CONNECTED(0003) > > depth=1 /CN=puppet.training > > verify return:1 > > depth=0 /CN=puppet.training > > verify return:1 > > ... > > > Here, I intentionally set the system time to 2009 and the error > > message show why the cert was rejected. > > CONNECTED(0003) > > depth=1 /CN=puppet.training > > verify error:num=9:certificate is not yet valid > > notBefore=Sep 20 08:01:21 2010 GMT > > verify return:0 > > > Hope this helps. Thanks, > > > Nan > > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Howto check if augeas is available
I made a small mistake. Please see at the bottom.
On 09-12-10 15:30, Martijn Grendelman wrote:
> An example: add the following to
>
> /modules//lib/facter/augeas_available.rb
>
> -- cut here --
> require 'facter'
>
> Facter.add("augeas_available") do
>
> setcode do
>
> avail = "no"
> Dir.glob("/usr/lib/libaugeas*") { |filename|
> avail = "yes"
> }
> avail
> end
> end
> -- cut here --
>
> It simple looks for files named /usr/lib/libaugeas*. I am not sure if that
> is appropriate for CentOS too, but it works on Debian. Of course, this is
> no guarantee that the Ruby-bindings are also available, so this is still
> not idiot-proof.
>
> After installing the fact, you can do something like this in a manifest:
>
> if $augeas_availabe {
>
> augeas { "foo":
> }
>
> }
Sorry, that should be:
if $augeas_availabe == "yes" {
}
Regards,
Martijn.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] class name size
Good thinking Felix.
I changed the class name to syslogngcrctesting and wahlah! the client pulls
and applies the catalog.
[r...@syslogng ~]# puppetd --test --verbose
notice: Ignoring --listen on onetime run
info: Caching catalog for syslogng.akc.org
info: Applying configuration version '1291906551'
notice: /Stage[main]/All_hosts_redhat/Service[nfslock]/ensure: ensure
changed 'stopped' to 'running'
notice: /Stage[main]/All_hosts_redhat/Service[nfs]/ensure: ensure changed
'running' to 'stopped'
notice: /Stage[main]/All_hosts_redhat/Service[atd]/ensure: ensure changed
'running' to 'stopped'
notice: /Stage[main]/All_hosts_redhat/Service[autofs]/ensure: ensure changed
'stopped' to 'running'
notice: /Stage[main]/All_hosts_redhat/Service[syslog]/ensure: ensure changed
'running' to 'stopped'
info: /Stage[main]/All_hosts_redhat/Service[syslog]: Scheduling refresh of
Service[syslog-ng]
notice: /Stage[main]/Syslogngcrctesting/Service[syslog-ng]/ensure: ensure
changed 'stopped' to 'running'
notice: /Stage[main]/Syslogngcrctesting/Service[syslog-ng]: Triggered
'refresh' from 1 events
notice: Finished catalog run in 76.44 seconds
[r...@syslogng ~]#
/Chris C
On Thu, Dec 9, 2010 at 9:27 AM, Felix Frank wrote:
> > [r...@puppetmaster manifests]# cat site.pp
> > import "classes/redhat/prod/inf/syslogng/class.pp"
> >
> > node syslogng {
> > include syslogng
> > }
>
> Maybe an issue with classname == nodename?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] Invalid parameter when assigning parameterized class to a node
Hi Felix, > You want to include httpd, not inherit it. > > Or are there any resource overrides in your vhost classes? I > shouldn't think so. You are right. There is no reason to override the httpd class with vhost classes. I now include the httpd class and after that include the neccessary vhost classes. Problem solved by using a better structure then before. Thanks! Regards Sebastian -- *Sebastian Hempel* Veilchenweg 4 · 95195 Röslau · Germany eMail: sebast...@hempel-roeslau.de -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Howto check if augeas is available
On 09-12-10 09:44, Hubert Krause wrote:
> Hello,
>
> Am Wednesday 08 December 2010 22:22:10 schrieb Patrick:
>> What distro are you using?
>
> CentOS and Debian. New server will always be Debian. Our Puppet Server is
> CentOS at the moment.
>
>> Why not just install Augeas when you install puppet? That's usually much
>> easier.
>
> Yes, but I want something Idiot proof (I am the idiot in case of doubt). At
> the moment we install our server by hand. In future we want to use some sort
> of automatic install, but not at the moment.
>
> We get errormessages verry instantly If we forget to install augeas, so we
> have not that big pressure to implement automatic augeas detection. But it
> would be nice.
An example: add the following to
/modules//lib/facter/augeas_available.rb
-- cut here --
require 'facter'
Facter.add("augeas_available") do
setcode do
avail = "no"
Dir.glob("/usr/lib/libaugeas*") { |filename|
avail = "yes"
}
avail
end
end
-- cut here --
It simple looks for files named /usr/lib/libaugeas*. I am not sure if that
is appropriate for CentOS too, but it works on Debian. Of course, this is
no guarantee that the Ruby-bindings are also available, so this is still
not idiot-proof.
After installing the fact, you can do something like this in a manifest:
if $augeas_availabe {
augeas { "foo":
}
}
Best regards,
Martijn.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] my first template
On 12/09/2010 03:12 PM, Arnau Bria wrote:
> Hi all,
>
> thanks for your replies.
>
> So doc is confusing here:
>
> http://projects.puppetlabs.com/projects/1/wiki/Puppet_Templating
> [...]
> content => template("tracsite.erb"),
> [...]
Ah, but that document assumes that your templates are directly inside
your $templatesdir, not in a module.
That can indeed be confusing. You may want to take a look and see if
there is a good place in there to add a warning about this.
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-us...@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] class name size
> [r...@puppetmaster manifests]# cat site.pp
> import "classes/redhat/prod/inf/syslogng/class.pp"
>
> node syslogng {
> include syslogng
> }
Maybe an issue with classname == nodename?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] class name size
Thanks for reminding me about this
[r...@puppetmaster manifests]# cat classes/redhat/prod/inf/syslogng/class.pp
class syslogng inherits all_hosts_redhat {
$dir = "redhat/prod/inf/syslogng"
file { "check_logserver":
name => "/usr/lib64/nagios/plugins/check_logserver.py",
ensure => present,
mode => 750,
owner=> root,
group=> root,
checksum => md5,
source =>
"/net/puppetmaster/etc/puppet/manifests/files/$dir/check_logserver.py"
}
}
[r...@puppetmaster manifests]# cat site.pp
import "classes/redhat/prod/inf/syslogng/class.pp"
node syslogng {
include syslogng
}
[r...@puppetmaster manifests]# puppet
classes/redhat/prod/inf/syslogng/class.pp
[r...@puppetmaster manifests]#
[r...@syslogng ~]# puppetd --test --verbose
notice: Ignoring --listen on onetime run
err: Could not retrieve catalog from remote server:
warning: Not using cache on failed catalog
err: Could not retrieve catalog; skipping run
err: Could not send report:
[r...@syslogng ~]#
As soon as I change the syslogng class to slng the class works and syslogng
can pull the catalog and apply.
Wierd...
/Chris C
On Wed, Dec 8, 2010 at 9:06 AM, Felix Frank wrote:
> On 12/06/2010 01:12 AM, Chris C wrote:
> > Hi folks,
> > Is anyone noticing an issue with the length of a class name? If I call
> > the class syslogng the class fails. If I call the class slng the class
> > works. Strangely a class named all_hosts works.
>
> I remember a weird occurence when a class was outright ignored. When I
> had lost sanity after some hours of debugging, I renamed it and it worked.
>
> Puppet is picky where names are concerned ;-(
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] my first template
Hi all,
thanks for your replies.
So doc is confusing here:
http://projects.puppetlabs.com/projects/1/wiki/Puppet_Templating
[...]
content => template("tracsite.erb"),
[...]
Cheers,
Arnau
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Invalid parameter when assigning parameterized class to a node
>> What exactly do you need class inheritance for in your case? You may >> be able to circumvent the inheritance using additional parameters. > > I want to assign the different virtual hosts to the nodes. By assigning > the class for the virtual host I want to have the base configuration of > the httpd daemon done automatically. You want to include httpd, not inherit it. Or are there any resource overrides in your vhost classes? I shouldn't think so. 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-us...@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] Invalid parameter when assigning parameterized class to a node
Hi Frank,
> Heh - this is not at all what you originally presented.
That's right. Old problem of a developer who diggs through the problem
bit by bit and when asks a questions about a concrete detail.
> There are two different definitions of class base? This can't be
> right. Please try and illustrate the structure more pointedly.
I have a module (init.pp) with the definition of the base class, which
is parameterized.
class httpd($certEMail, $certOU) {
hostCert { "$fqdn":
certEMail => "$certEMail",
certOU=> "$certOU",
require => Package["mod_ssl"]
}
The two parameters are handed to a define which creates a key and a
certification request for the httpd server. The other ressources in the
class are used to install the package, ensure that the service is
started and that certain directories and files are created.
For each virtual host I use a sub-class which installs the configuration
file of the host and sets other necessary links and directories.
class httpd {
class virtual1 inherits httpd {
...
}
}
As I write this I see, that you are right. There are two different
definitions for the class base.
Would it be correct to define the virtual1 class this way?
class httpd::virtual1 inherits base {
}
> Otherwise, I believe I remember reading about issues with
> inheritance and class parameters. The two concepts may not mix.
I was thinking about this when I was searching for the "inheritance" of
the class parameters from the base class.
> What exactly do you need class inheritance for in your case? You may
> be able to circumvent the inheritance using additional parameters.
I want to assign the different virtual hosts to the nodes. By assigning
the class for the virtual host I want to have the base configuration of
the httpd daemon done automatically.
A circumvent would be to assign the class with the configuration of the
httpd daemon and separately assign the classes of the different virtual
hosts.
As I see, I should explain the whole problem and not the detail, that I
think causes the problem. As already said: old problem of a developer. :-)=
Best regards
Sebastian
--
*Sebastian Hempel*
Veilchenweg 4 · 95195 Röslau · Germany
eMail: sebast...@hempel-roeslau.de
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Invalid parameter when assigning parameterized class to a node
> class base($param1, $param2) {
> ...
> }
>
> class base {
> class first inherits base {
> }
> }
Heh - this is not at all what you originally presented.
There are two different definitions of class base? This can't be right.
Please try and illustrate the structure more pointedly.
Otherwise, I believe I remember reading about issues with inheritance
and class parameters. The two concepts may not mix.
What exactly do you need class inheritance for in your case? You may be
able to circumvent the inheritance using additional parameters.
Regards,
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-us...@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] Invalid parameter when assigning parameterized class to a node
Hi Felix, > What are the versions of your master and client, btw? I'm running the latest version 2.6.4 both on the master and the client / agent. Regards Sebastian -- *Sebastian Hempel* Veilchenweg 4 · 95195 Röslau · Germany eMail: sebast...@hempel-roeslau.de -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Invalid parameter when assigning parameterized class to a node
Hi Daniel,
> Can you verify that works for you? Obviously, change my node name
> to your test node name; I just wrote that to test.pp and ran 'puppet
> test.pp' to verify. :)
I copied the class and node to a file test.pp and run 'puppet test.pp'
which successfully displayed the notice.
The mechanism of parameterized classes works on the system. So I have to
look at my module definition what makes puppet think that the parameters
are not defined.
Is it possible, that parameterized classes with class inheritance and
nested classes might be the problem? The class with parameters is the
base class of three other classes, that should be assigned to a node.
class base($param1, $param2) {
...
}
class base {
class first inherits base {
}
}
Best regards
Sebastian
--
*Sebastian Hempel*
Veilchenweg 4 · 95195 Röslau · Germany
eMail: sebast...@hempel-roeslau.de
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] my first template
On Thu, Dec 9, 2010 at 23:17, Arnau Bria wrote:
> content => template("baculafd.erb"); }
content => template('computing_bacula/baculafd.erb')
You need to prefix the template with the module name, which is what
puppet uses to locate it.
Regards,
Daniel
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] my first template
On 12/09/2010 01:17 PM, Arnau Bria wrote:
> Hi all,
>
> I'd like to start using templates and I'm doing some test with one of
> my already working class (bacula).
>
> Following dir structure:
> module_name/manifests/init.pp
>/templates/file.erb
>
>
> my template wants to copy a file and change a value for client hostname:
>
> init.pp:
> [...]
> '/etc/bacula/bacula-fd.conf.template':
> ensure => present,
> content => template("baculafd.erb"); }
> [...]
>
>
> cat templates/baculafd.erb
>
> [...]
> FileDaemon {
> Name = <%= hostname %=>
> FDport = 9102 # where we listen for the director
> WorkingDirectory = /var/lib/bacula
> Pid Directory = /var/run
> Maximum Concurrent Jobs = 20
> }
> [...]
>
> Doc says:
> "Templates are always evaluated by the parser, not by the client. This
> means that if you are using puppetmasterd, then the templates only need
> to be on the server, and you never need to download them to the client."
>
> But when I run puppet, client complains :
>
> # puppetd --test --server ser01.pic.es
> err: Could not retrieve catalog from remote server: Error 400 on
> SERVER: Could not find template 'baculafd.erb'
> at
> /etc/puppet/manifests/services/workernode/modules/computing_bacula/manifests/init.pp:27
> on node X
>
> Why is it complaining if dir structure is correct?
>
> ar...@lx-arnau
> ~/puppet/manifests/services/workernode/modules/computing_bacula $ ls
> files manifests templates
> ar...@lx-arnau
> ~/puppet/manifests/services/workernode/modules/computing_bacula $ ls
> templates/
> baculafd.erb
Hi,
according to http://docs.puppetlabs.com/guides/modules.html,
you should be using
content => template("computing_bacula/baculafd.erb");
including the module name in the template path.
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-us...@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] my first template
Hi all,
I'd like to start using templates and I'm doing some test with one of
my already working class (bacula).
Following dir structure:
module_name/manifests/init.pp
/templates/file.erb
my template wants to copy a file and change a value for client hostname:
init.pp:
[...]
'/etc/bacula/bacula-fd.conf.template':
ensure => present,
content => template("baculafd.erb"); }
[...]
cat templates/baculafd.erb
[...]
FileDaemon {
Name = <%= hostname %=>
FDport = 9102 # where we listen for the director
WorkingDirectory = /var/lib/bacula
Pid Directory = /var/run
Maximum Concurrent Jobs = 20
}
[...]
Doc says:
"Templates are always evaluated by the parser, not by the client. This
means that if you are using puppetmasterd, then the templates only need
to be on the server, and you never need to download them to the client."
But when I run puppet, client complains :
# puppetd --test --server ser01.pic.es
err: Could not retrieve catalog from remote server: Error 400 on
SERVER: Could not find template 'baculafd.erb'
at
/etc/puppet/manifests/services/workernode/modules/computing_bacula/manifests/init.pp:27
on node X
Why is it complaining if dir structure is correct?
ar...@lx-arnau ~/puppet/manifests/services/workernode/modules/computing_bacula
$ ls
files manifests templates
ar...@lx-arnau ~/puppet/manifests/services/workernode/modules/computing_bacula
$ ls templates/
baculafd.erb
TIA,
Arnau
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Invalid parameter when assigning parameterized class to a node
On 12/09/2010 11:24 AM, Sebastian Hempel wrote:
> Hello,
>
> I searched through the archive of the google group but did not found any
> solution or hint for my problem.
>
> I want to assign the following parameterized class to a node.
>
> class httpd($certMail, $certOU) {
> ...
> }
>
> This is the node statement to assign the class to a node.
>
> node "someserver" inherits basenode {
> class { httpd:
> certEMail => "an.em...@address",
> certOU=> "organizational unit";
> }
> }
>
> When running puppet I get the following error:
>
> err: Could not retrieve catalog from remote server: Error 400 on SERVER:
> Invalid parameter certEMail at
> /var/lib/puppet/abnahme/manifests/nodes.pp:118 on node someserver
>
> The line 118 contains the end bracket } of the class statement.
>
> I tried to use different names for the parameters - lower cases only,
> mixed upper / lower cases - but the error message is always the same.
>
> Do you have any idea what is wrong with my class definition / assignment?
What are the versions of your master and client, btw?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Invalid parameter when assigning parameterized class to a node
On Thu, Dec 9, 2010 at 21:57, Sebastian Hempel
wrote:
>> Here you have cert *NO E* Mail, and later you use it with an E, so I
>> suspect a simple typo.
>
> I changed that typo - thanks - and also changed all characters to lower
> case. But the error described did not disappear.
>
> Any ideas left?
This works for me, as a local test:
class httpd($certemail, $certou) {
notice("email $certemail for ou $certou")
}
node "ea" {
class { httpd:
certemail => "an.em...@address",
certou=> "organizational unit";
}
}
Can you verify that works for you? Obviously, change my node name to
your test node name; I just wrote that to test.pp and ran 'puppet
test.pp' to verify. :)
Regards,
Daniel
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Invalid parameter when assigning parameterized class to a node
Hi Daniel, > Here you have cert *NO E* Mail, and later you use it with an E, so I > suspect a simple typo. I changed that typo - thanks - and also changed all characters to lower case. But the error described did not disappear. Any ideas left? Best regards Sebastian -- *Sebastian Hempel* Veilchenweg 4 · 95195 Röslau · Germany eMail: sebast...@hempel-roeslau.de -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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: Passenger Problems
On 10/26/2010 10:46 PM, Andrew Forgue wrote: > On Oct 26, 1:00 pm, Taylor Leese wrote: >> Patrick, >> >> Any idea if people are using versions > 2.2.5 in the wild >> successfully? I tried to revert back to 2.2.2 previously, but I >> received a number of compilation errors when running passenger-install- >> apache2-module so it seems like moving up may be my only option. > > I am using 2.2.15 without issue on around 1000 nodes. > > -Andrew > I'm not managing our master, but this is what's running on top of puppetmaster 0.25.5: libapache2-mod-passenger 2.2.11debian-1~bpo50+1 It's sort of recent, but no problems so far. About 200 Clients. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Invalid parameter when assigning parameterized class to a node
On Thu, Dec 9, 2010 at 21:24, Sebastian Hempel
wrote:
> Hello,
>
> I searched through the archive of the google group but did not found any
> solution or hint for my problem.
>
> I want to assign the following parameterized class to a node.
>
> class httpd($certMail, $certOU) {
Here you have cert *NO E* Mail, and later you use it with an E, so I
suspect a simple typo.
> I tried to use different names for the parameters - lower cases only,
> mixed upper / lower cases - but the error message is always the same.
Sometimes puppet can be strange about case, but if you tested all
lower case I strongly suspect my invisible typo theory. (I know I can
never see those things. :)
Regards,
Daniel
--
✣ Daniel Pittman ✉ dan...@rimspace.net ☎ +61 401 155 707
♽ made with 100 percent post-consumer electrons
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] apt-get -t lenny-backports
On 08/12/10 10:54, Adrian wrote:
> Hello everybody,
>
>
> Is there a way when installing a package like this :
>
> package { "rubygems":
> ensure => installed,
> }
>
> to pass -t parameter to apt-get in order to use a specific apt
> source ? EG : apt-get install -t lenny-backports rubygems
>
> Ideally I would not use exec ...
>
> I am on a Debian and I want to find a clean way to upgrade
> rubygems ...
I went with the slightly messy solution of adding the requested repo to
the package name:
package { rubygems:
name => $operatingsystemrelease ? {
/^5\.0\./ => 'rubygems/lenny-backports',
default => 'rubygems',
},
ensure => latest,
}
This causes puppet to 'spam' an "ensure created" line each run and a
wasted call to apt-get.
A temporary solution until squeeze appears and preferences.d is supported.
There is an old puppet issue for this feature request but no solution
was produced: http://projects.puppetlabs.com/issues/2406
Dan
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] Class execution order
Try using "before" or "require" in your classes like so:
class one {
exec { "echoone":
command => "/bin/echo $var1",
before => Class["two"],
}
}
class two {
exec { "echotwo":
command => "/bin/echo $var2",
before => Class["three"],
}
}
class three {
exec { "echothree":
command => "/bin/echo $var3",
}
}
Best,
Brandt
--
J. Brandt Buckley
Systems Integration Engineer
CRBS
bra...@ucsd.edu http://crbs.ucsd.edu
M: +1 858 480 1010 F: +1 858 524 7497
Center for Research in Biological Systems
University of California, San Diego
9500 Gilman Drive
Basic Sciences Building #1000
La Jolla, Ca. 92093-0608
On Wed, Dec 8, 2010 at 4:29 AM, sergey arlashin wrote:
> Hi!
> I'm trying to make puppet execute classes in a certain order for a
> particular node.
> So this is my test config:
>
> class one {
>exec { "echoone":
> command => "/bin/echo $var1",
>}
> }
>
> class two {
>exec { "echotwo":
> command => "/bin/echo $var2",
>}
> }
>
> class three {
>exec { "echothree":
> command => "/bin/echo $var3",
>}
> }
>
> node "client-tpl-puppet.localnet" {
>$var1 = "1"
>$var2 = "2"
>$var3 = "3"
>include one, two, three
> }
>
> But when I launch puppet client on the node "client-tpl-
> puppet.localnet" I see that all the classes execute in an absolutely
> random order. The documentation says I should use stages, but I cannot
> figure out how to use them in this particular case.
> Could you show an example?
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-us...@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-us...@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] Invalid parameter when assigning parameterized class to a node
Hello,
I searched through the archive of the google group but did not found any
solution or hint for my problem.
I want to assign the following parameterized class to a node.
class httpd($certMail, $certOU) {
...
}
This is the node statement to assign the class to a node.
node "someserver" inherits basenode {
class { httpd:
certEMail => "an.em...@address",
certOU=> "organizational unit";
}
}
When running puppet I get the following error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Invalid parameter certEMail at
/var/lib/puppet/abnahme/manifests/nodes.pp:118 on node someserver
The line 118 contains the end bracket } of the class statement.
I tried to use different names for the parameters - lower cases only,
mixed upper / lower cases - but the error message is always the same.
Do you have any idea what is wrong with my class definition / assignment?
Best regards
Sebastian
--
*Sebastian Hempel*
Veilchenweg 4 · 95195 Röslau · Germany
eMail: sebast...@hempel-roeslau.de
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@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] apt-get -t lenny-backports
On Dec 8, 2010, at 11:45 PM, Felix Frank wrote: > On 12/09/2010 05:13 AM, Patrick wrote: >> >> On Dec 8, 2010, at 6:38 PM, Daniel Pittman wrote: >> >>> Sadly, no. I very much missed the feature. We ended up using the apt >>> preferences file to implement that behaviour >>> >>> If I was doing it over I would use a define that added the package >>> resource and also used concat to automatically build up the >>> preferences entry. >>> >>> Regards, Daniel. >>> >> >> That's an interestring idea. >> >> I have one bit of advice about this. Make sure your source file >> requires your preferences file. If you don't, it's possible one day to >> get very unlucky and have only your source file pushed with nasty results. > > Also note that starting with Squeeze, Debian ships a version of apt that > supports an /etc/apt/preferences.d/. This makes pinning various packages > using puppet feasible. In theory you could cook something up with puppet_concat, but that does make things a lot easier. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@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] Howto check if augeas is available
Hello, Am Wednesday 08 December 2010 22:22:10 schrieb Patrick: > What distro are you using? CentOS and Debian. New server will always be Debian. Our Puppet Server is CentOS at the moment. > Why not just install Augeas when you install puppet? That's usually much > easier. Yes, but I want something Idiot proof (I am the idiot in case of doubt). At the moment we install our server by hand. In future we want to use some sort of automatic install, but not at the moment. We get errormessages verry instantly If we forget to install augeas, so we have not that big pressure to implement automatic augeas detection. But it would be nice. Best regards, Hubert -- Hubert Krause Risk & Fraud Division INFORM GmbH, Pascalstraße 23, 52076 Aachen, Germany Phone: +49 24 08 - 94 56 5145 E-Mail: hubert.kra...@inform-ac.com, Web: http://www.inform-ac.com INFORM Institut fuer Operations Research und Management GmbH Registered AmtsG Aachen HRB1144 Gfhr. Adrian Weiler signature.asc Description: This is a digitally signed message part.
Re: [Puppet Users] Directory and File Permissions
On 12/07/2010 08:52 PM, Douglas Garstang wrote:
> If I'm pushing out a bunch of files in a directory, like this...
>
> file {
> "/usr/local/lg/bin/":
> source => "puppet://${server}/usr/local/lg/bin",
> mode => 755,
> owner => "root",
> group => "root",
> recurse => true,
> ignore => ".svn";
> }
>
> This sets both the directory _and_ file perms to 755. How can I see the
> directory to 755, and the files beneath it to something else (I want the
> files to be 700) ?
If you manage the tree recursively, pick one mode. Having the root dir
755 and all others 700 is not going to be possible any time soon, I wager.
Regards,
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-us...@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.
