Re: [Puppet Users] Reopening sqlite3 db
On Tue, Nov 15, 2011 at 7:16 PM, Klaus Ethgen klaus+use...@ethgen.de wrote: Hello, I am not sure if I trigger a bug and if so it could also be in ruby sqlite3 backend. However, maybe I do something totally wrong. I have the following part in puppet.conf: [master] storeconfigs = true dblocation = /var/lib/puppet/state/clientconfigs.sqlite3 dbadapter = sqlite3 Now every time a client (agent in puppet speak) is run I get one more connection to the database: lsof -np $(pgrep puppet) ... puppet 23542 puppet 7u IPv4 1180771 0t0 TCP *:8140 (LISTEN) puppet 23542 puppet 9w REG 252,1 71 2621 /var/log/puppet/rails.log puppet 23542 puppet 10u REG 252,1 156672 2684 /var/lib/puppet/state/clientconfigs.sqlite3 puppet 23542 puppet 11u REG 252,1 156672 2684 /var/lib/puppet/state/clientconfigs.sqlite3 Next run: lsof -np $(pgrep puppet) ... puppet 23542 puppet 7u IPv4 1180771 0t0 TCP *:8140 (LISTEN) puppet 23542 puppet 9w REG 252,1 71 2621 /var/log/puppet/rails.log puppet 23542 puppet 10u REG 252,1 156672 2684 /var/lib/puppet/state/clientconfigs.sqlite3 puppet 23542 puppet 11u REG 252,1 156672 2684 /var/lib/puppet/state/clientconfigs.sqlite3 puppet 23542 puppet 12u REG 252,1 156672 2684 /var/lib/puppet/state/clientconfigs.sqlite3 And so on until the maximum is reached and the puppetmaster do not work anymore. I encountered this bug with many versions on different linux distributions. For example: Ubuntu 10.04 Puppet 2.7.6 libsqlite3-ruby1.8 1.2.4-2.1 Do anybody has an idea what I can do to handle that? which version of activerecord? might wan tot try upgrading it -- Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -- 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] yumrepo absent not working on 2.6.12
Ok, thnaks a lot. 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-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] Knowing if a file is managed by puppet
On 11/16/2011 12:39 AM, Iain Sutton wrote: +1 for tangled strings On 16 November 2011 04:03, Ken Barber k...@puppetlabs.com mailto:k...@puppetlabs.com wrote: Depends on why you want this info ... but its available in the catalog on the box for 'grepping' (more or less). Something I recommend to some people: http://www.tenshu.net/2010/08/adventures-in-puppet-tangled-strings.html Which does more or less that ... but shows a banner in VIM for users to warn them the file is puppet managed before they modify it. A mild word of warning: tangledstrings is distributed as a Vimball, which works well in (most? all?) Linux flavours of Vim, but you may run into support problems in other OS's (such as OpenBSD, *grumble grumble*). That said, tangledstrings does exactly what it's supposed to do: act as a very handy warning layer. -- Daniel Maher With listening comes wisdom, with speaking repentance. -- 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 is the offical variable scope best practice?
I read the guide at http://docs.puppetlabs.com/guides/scope_and_puppet.htmland others' mail, i am a little confused now, below is my understanding: 1. top scope only refers to site.pp, not include node definitions and facts. 2. in puppet class, using variables not local, must specify the namespace, like $class::variable, if it's a top scope variable or a fact variable or a variable in node definition, using $::variable. 3. in template erb files, always using scope.lookupvar(class::variable) to get the value, even if the erb and the variable used in the same module or it is a fact variable are these points correct? btw, only some of my old code give dynamic lookup warnings under puppet 2.7, does this mean the others not need to modify? -- System Administrator, Focus on System Management and Basic Development -- 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] Rounding in variable expressions
Alternatively the cheap and hacky approach: $foo = inline_template(%= (processorcount.to_i * 0.8).floor -%) That looks direct and sexy to me. -- 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] Reopening sqlite3 db
On Wed, Nov 16, 2011 at 12:41 PM, Klaus Ethgen klaus+use...@ethgen.de wrote: Ohad Levy ohadl...@gmail.com schrieb: I encountered this bug with many versions on different linux distributions. For example: Ubuntu 10.04 Puppet 2.7.6 libsqlite3-ruby1.8 1.2.4-2.1 Do anybody has an idea what I can do to handle that? which version of activerecord? might wan tot try upgrading it How do I find the version? On ubuntu there is no separate activerecord package. On SuSI where I have the same problem, activerecored is version 2.1.2 try with the gem command. 2.1.x is fairly old and is probably the cause for your problems Ohad -- Klaus -- Klaus Ethgen http://www.ethgen.ch/ pub 4096R/4E20AF1C 2011-05-16 Klaus Ethgen kl...@ethgen.de Fingerprint: 85D4 CA42 952C 949B 1753 62B3 79D0 B06F 4E20 AF1C -- 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: Adding users by using 'spaceship' syntax
RADIUS is something I haven't used for a long time (and my last use
was AAA for DSL subscribers, not for Linux), but that is a
possibility. The only issue I'll have there is that I am working with
internal machines that live in a private 'cloud' network @ the office
and a set of private, and customer, servers in the Amazon cloud. I
would probably end up, due to security restrictions, setting up RADIUS
for our private machines (it could be one for the internal network and
one for the Amazon network of our servers only), and then one RADIUS
server for each customer, in order to ensure separation. Since we have
only two, three, or four servers (typically) for each customer,
setting up one more server for authentication seems a bit overkill
(for customers.) But the user base is mostly the same across all
servers, with a few exceptions.
Thanks for your feedback.
On Nov 15, 6:58 pm, Stephan stephan.eckwei...@admin.ox.ac.uk wrote:
Hmm, I see. We went another avenue. We create all users on all systems
and then let another instance decide which users to let log in to
which machine. RADIUS servers or Kerberos servers are capable of this.
But depending on the surroundings this might be overkill.
So I agree that for you the spaceship makes sense. But am afraid won't
be of much help. Am still struggling myself to get my head around it,
and must admit, am not really overly impressed by it so far. But rule
1 with open source: contribute nothing, expect nothing
On Nov 15, 7:30 pm, Justin Spies jus...@thespies.org wrote:
On Nov 15, 12:27 pm, Stephan stephan.eckwei...@admin.ox.ac.uk wrote:
Hi Justin,
So I'd like to avoid having to type the user titles in the call to
users::create. Is there a way to do this using the 'User | group ==
'ssh' |' syntax to select what I want?
Unfortunately the spaceship operator can't contain anything other than
== and !=, and doesn't accept anything but simple variables.
Actually I doubt User | group == 'ssh' | will work that well. During
past tests I did, it only found the first member of an array. So if
you had a user defined like this:
users::define_ssh {'jspies':
[...]
group = ['group1','ssh'],
}
it wouldn't be realized by User | group == 'ssh' |, because ssh is
at the second position of the group parameter. Maybe that wasn't
discovered yet over at this wiki you mentioned.
Or do I need to just define an
array in the sshusers.pp file and pass the array to the users::create?
May I ask what your reason is for not ensuring that users should be
present right away? Sounds like you want to add all your new users
right away. In this case you don't have to have separate user::define
and user::create groups. Would be enough just to have the ensure =
present inside the user::define and then include or require it in your
node, eg. your default node.
Hi Stephan, thanks for the reply. The example I'm following / using
ishttp://projects.puppetlabs.com/projects/puppet/wiki/Module_Ssh_Auth_P...
Great question regarding 'why', and it made me think hard about what
I'm trying to accomplish.
My reason for not realizing users immediately is because I wanted to
define a user in one place (sshusers.pp) and then realize those users
on most (but not all) of my servers (let's say there are 20 servers.)
So the users are defined virtually in sshusers.pp using the
users::define_ssh and then they are realized (inside of each node
definition) using users::create based on which users go on each
server. I would prefer to add users to a group and then in the node
definition, specify to the server 'ensure that all users who are a
member of group ssh are created'. A better example, perhaps, would be
if you think in terms of a DBA group. I only want to add the DBA
users, who are in the DBA group, to the database servers.
So for a web server node, I would have 'user::create{ User | group ==
'webservers' |: ensure = present }' and 'user::create{ User | group
== 'dba' |: ensure = absent }'. That would create the web server
admins on the web server, and ensure the DBA users were not there
(admittedly, I'm not sure what the results would be if I had one user
in both groups). On the DB server, I would just reverse the value of
the ensure parameter so that the web server users are not created and
the DBA users are created.
I am not stuck on the use of the spaceship syntax, it was just my
starting point. I was hoping to just extract an array of users some
how and pass that to the users::create definition. I am also open to
suggestions on how to better structure this if I'm going off in some
crazy direction. I am new to Puppet and am still getting a grasp on
how it works and how to properly code up classes and defines.
Thanks again.
Hope that helps
Stephan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
[Puppet Users] Re: Editing a variable defined in the same scope
On Nov 15, 3:42 pm, Justin Lloyd jstn...@gmail.com wrote:
I tried the following (names changed to protect the innocent and guilty):
class myclass ( $param ) {
$myvar = [ foo, bar ]
if $param == special {
$myvar += [ blah ]
}
}
and got the message ...Cannot append, variable myvar is defined in this
scope According to the docs, variables cannot be modified in the same
scope because of the declarative nature of
Puppethttp://docs.puppetlabs.com/guides/language_guide.html
.
However, if I change the plus-signment statment to
$myclass::myvar += [ blah ]
it works fine. Can someone explain this aspect of scoping? (Or is this
possibly a bug...?)
Do check whether you are seeing the behavior Christopher reports.
It is a Puppet axiom that you cannot modify the value of any variable
once it is set. Even += doesn't really do that: that's why the
appended values are not seen outside the scope where the += is
performed.
I recommend you just come up with another way to do what you want. In
fact, I recommend you avoid += even in situations where it works.
Here's one way:
class myclass ( $param ) {
if $param == special {
$myvar = [ foo, bar, blah ]
} else {
$myvar = [ foo, bar ]
}
}
There are also a couple of ways you could concatenate arrays in
Puppet. If you want to do that a lot then I'd write a custom
function, but for the odd one-off you could hack together something
using inline_template() and split().
John
--
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] Multiple nodes.pp files
Dear community, I would like to know if it is possible to use different files for the nodes.pp Can we use in nodes.pp the following syntax : include nodes2.pp nodes2.pp could contain host definition eactly as nodes.pp but for a particular platform. This would allow more readable configuration file. I didn't find anything on the internet. Thank you. hugo -- 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: What is the offical variable scope best practice?
On Nov 16, 3:59 am, flex frostyn...@gmail.com wrote: I read the guide athttp://docs.puppetlabs.com/guides/scope_and_puppet.htmlandothers' mail, i am a little confused now, below is my understanding: 1. top scope only refers to site.pp, not include node definitions and facts. Top scope refers to anything outside all class and node definitions. Top scope variables can appear in any manifest file, but site.pp is a very good choice because it is always processed, and first. Top scope variables in most other locations may sometimes fail to be visible in manifests other than the ones where they appear. If you put a class or node definition in site.pp, that class's or node's variables are not in top scope. Facts certainly are in top scope; in some manifest sets they are the *only* variables in top scope. 2. in puppet class, using variables not local, must specify the namespace, like $class::variable, if it's a top scope variable or a fact variable or a variable in node definition, using $::variable. For Puppet 2.7.x and below, this is not always the case: you can access variables in the current dynamic scope by their simple names. Top scope variables are always in the current dynamic scope, but a narrower scope might define a variable having the same simple name, so it is always safest to use $::variable when that's what you mean. Dynamic scope can apply to class variables, too, but again it's safest to use refer to non-local variables by their fully-qualified names. Starting in Puppet 2.8, however, it will be mandatory to refer to non- local variables by their fully-qualified names. In preparation for that, Puppet 2.7.x emits warning when your manifests resolve non-local variables from the dynamic scope. 3. in template erb files, always using scope.lookupvar(class::variable) to get the value, even if the erb and the variable used in the same module or it is a fact variable The docs suggest that templates can use all the simple variable names that can be resolved in the scope where they are invoked, but I cannot independently confirm that. Certainly, wherever you need or want to use a qualified name, scope.lookupvar() is your tool. are these points correct? btw, only some of my old code give dynamic lookup warnings under puppet 2.7, does this mean the others not need to modify? I doubt it would be safe to say that manifests that do not elicit dynamic lookup warnings will not need any modification to work with Puppet 2.8. Also, do understand that it is not necessarily the case that every manifest is processed for every client, so you have to take care in judging which code gives warnings and which doesn't. John -- 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: What is the offical variable scope best practice?
On 11/16/11 3:54 PM, jcbollinger wrote: On Nov 16, 3:59 am, flexfrostyn...@gmail.com wrote: I read the guide athttp://docs.puppetlabs.com/guides/scope_and_puppet.htmlandothers' mail, i am a little confused now, below is my understanding: 1. top scope only refers to site.pp, not include node definitions and facts. Top scope refers to anything outside all class and node definitions. Top scope variables can appear in any manifest file, but site.pp is a very good choice because it is always processed, and first. Top scope variables in most other locations may sometimes fail to be visible in manifests other than the ones where they appear. If you put a class or node definition in site.pp, that class's or node's variables are not in top scope. Facts certainly are in top scope; in some manifest sets they are the *only* variables in top scope. 2. in puppet class, using variables not local, must specify the namespace, like $class::variable, if it's a top scope variable or a fact variable or a variable in node definition, using $::variable. For Puppet 2.7.x and below, this is not always the case: you can access variables in the current dynamic scope by their simple names. Top scope variables are always in the current dynamic scope, but a narrower scope might define a variable having the same simple name, so it is always safest to use $::variable when that's what you mean. Dynamic scope can apply to class variables, too, but again it's safest to use refer to non-local variables by their fully-qualified names. Starting in Puppet 2.8, however, it will be mandatory to refer to non- local variables by their fully-qualified names. In preparation for that, Puppet 2.7.x emits warning when your manifests resolve non-local variables from the dynamic scope. 3. in template erb files, always using scope.lookupvar(class::variable) to get the value, even if the erb and the variable used in the same module or it is a fact variable The docs suggest that templates can use all the simple variable names that can be resolved in the scope where they are invoked, but I cannot independently confirm that. Certainly, wherever you need or want to use a qualified name, scope.lookupvar() is your tool. are these points correct? btw, only some of my old code give dynamic lookup warnings under puppet 2.7, does this mean the others not need to modify? I doubt it would be safe to say that manifests that do not elicit dynamic lookup warnings will not need any modification to work with Puppet 2.8. Also, do understand that it is not necessarily the case that every manifest is processed for every client, so you have to take care in judging which code gives warnings and which doesn't. If you use Geppetto you will get validation of all variable references in any .pp file irrespective if it gets evaluated or not. Geppetto is using the rules that John described above. The rules as far as I have understood them wrt. unqualified variables are that they may reference: * a locally scoped variable * a top level scoped variable * a (local) class or definition parameter * an inherited class parameter (somewhat unclear on the rules here) * (before 2.8 a dynamically scoped variable, warning in 2.7) * a meta variable ($name, $title, $module_name, $0-$n) * an assigned meta parameter (in definitions) Regards - henrik -- 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: Virtual Define-based resources can only be realized once
On Nov 15, 7:05 am, Stephan stephan.eckwei...@admin.ox.ac.uk wrote:
Hi all,
here is what I have:
A module that is responsible to roll out and configure TSM (a backup
tool). Basically I need a text file that mentions all directories that
have to be backed up. I want to make it a virtual resource and let
other modules configure which parts of it have to be backed up, e.g.
configure in the apache module that the apache logs of each defined
virtual server have to be backed up:
The node.pp is configured like this:
apache::config {virtualserver1:
blah}
apache:config {virtualserver2:
blah
}
@tsm::config { $hostname:
tsm_backup = [/custdir1,/custdir2]
}
The @ means this is a virtual Define-based resource, so it is not
implemented until it gets realized.
/custdir1 and /custdir2 denote custom directories that have to be
backed up, but aren't managed by other puppet modules.
One module is supposed to add some directories to tsm_backup, I use
this configuration inside the apache module's config.pp:
Tsm::Config| title == $hostname | {
tsm_backup + [$apache_logs,$docroot],
}
I can then use this array in the template for the conf file (dsm.sys,
virtualmountpoint and Domain, for those who know TSM). Up until here
it all works fine. The config file will contain /custdir1, /custdir2, /
apache/virtualserver1/logs, /apache/virtualserver2/logs, apache/
virtualserver1/docroot, apache/virtualserver2/docroot
But when I want to configure another module to also add its
directories to tsm_backup, so basically have another module, say
postfix config.pp which contains this:
Tsm::Config| title == $hostname | {
tsm_backup + [$postfix_logs],
}
It will either contain the apache backup dirs OR the postfix backup
dirs, depending on which | | it finds first, but never both.
This is unexpected, since if I use the same construct for non define-
based virtual resources, like a user
(seehttps://groups.google.com/group/puppet-users/browse_thread/thread/c13...
)
Does anybody have an idea?
Your realizations conflict with each other. One says realize
Tsm::config[$hostname] with the *declared* groups plus $apache_logs
and $docroot, whereas the other says realize Tsm::config[$hostname]
with the *declared* groups plus $postfix_logs. There is no
qualitative difference from overriding via the = operator, which I'm
sure you will agree would not work either.
I would be surprised if the approach worked for built-in resources.
It was not obvious from the thread you referenced that the same
situation applies; if it does, then I recommend that you check whether
it is having the desired effect. Even if so, I would not personally
be comfortable with it. Because it's both undocumented and
semantically questionable, I would assess a high risk of it breaking
from one version of puppet to another.
As for how to achieve your goal, I'd recommend one of
1) target the original resource declaration, applying whatever logic
or external data is needed to declare all the needed backup
directories in the first place, or
2) rework your design so that each module can declare its own,
independent Tsm::Config instead of relying on resource overrides.
That could be built around a fragment-based approach to building the
needed config file, or it could leverage the configuration language's
mechanism for interpolating other files, if it has one.
John
--
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] working thru tutorial
Hi all,
I'm working thru the tutorial (http://docs.puppetlabs.com/learning/
manifests.html) using the VM provided (http://www.puppetlabs.com/
downloads/learning/learn_puppet_centos_ovf.2011.07.15.tar.bz). When
asked to write a manifest that ensures httpd is running, I wrote:
service { 'httpd':
ensure = running,
enable = true,
}
I named this manifest httpd.pp. When I ran `puppet apply httpd.pp`
nothing happens. If I rename this manifest to something else `puppet
apply` works as I would expect.
This was/is extremely confusing. I figured what better way to name the
manifest than to name the service it's ensuring. Is this a known
issue? Documentation problem? Something else?
Thanks for you help.
Matthew
--
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] define-type resources default parameters not available under scope.catalog.resources
Hi All,
I have a define-type resource, which gets called from multiple classes, on
which I would like to read its parameters from a template. This works for
parameters added to the call of the resource but not for those which have a
default value on its definition.
On the example below, I can read the parameter from Webdir[c] but not from
a and b.
If webdir would be a class type instead (and with the restriction of being
able to call it only once) it would work, since
resource(Webdir[a]).parameters includes the ones set by default on the
class definition.
Is this intended or a bug ?
I know that using a native define-type (those written in ruby) I can access
the parameters as intended but, like the example below, it is nice to have
the simplicity for doing the same on define-type resources when they
contain other resources such as file, services, vcsrepo, etc.
Here is some minimalist puppet file and template of what I'm trying to do :
== site.pp ==
define webdir (
$dirname = $name,
$access_mode = private
) {
file { /tmp/${dirname}: ensure = 'directory', }
}
class webhost {
file { /tmp/apache.conf:
ensure = 'present',
content = template('/tmp/apache.erb'),
}
}
node 'centos1' {
webdir { 'a': }
webdir { 'b': }
webdir { 'c': access_mode = 'private', }
include webhost
}
=== apache.erb ===
Virtualhost *:80
blablabla
%
scope.catalog.resource_keys.select { |r,name| r == Webdir}.each do
|r,name|
-%
Alias /webdir/%= name % /tmp/%= name %
Directory /tmp/%= name -%
% if scope.findresource(#{r}[#{name}])['access_mode'] == private
then -%
require valid-user
% end -%
/Directory
% end -%
/Virtualhost
=== output of apache.erb ===
Virtualhost *:80
blablabla
Alias /webdir/c /tmp/c
Directory /tmp/c
require valid-user
/Directory
Alias /webdir/a /tmp/a
Directory /tmp/a
/Directory
Alias /webdir/b /tmp/b
Directory /tmp/b
/Directory
/Virtualhost
===
Cheers,
Theo
--
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] working thru tutorial
On Tue, Nov 15, 2011 at 04:40:29PM -0800, Matthew O'Connor wrote:
Hi all,
I'm working thru the tutorial (http://docs.puppetlabs.com/learning/
manifests.html) using the VM provided (http://www.puppetlabs.com/
downloads/learning/learn_puppet_centos_ovf.2011.07.15.tar.bz). When
asked to write a manifest that ensures httpd is running, I wrote:
service { 'httpd':
ensure = running,
enable = true,
}
I named this manifest httpd.pp. When I ran `puppet apply httpd.pp`
nothing happens. If I rename this manifest to something else `puppet
apply` works as I would expect.
puppet apply --debug --verbose httpd.pp
If the service is already running and enabled then puppet won't do anything.
This was/is extremely confusing. I figured what better way to name the
manifest than to name the service it's ensuring. Is this a known
issue? Documentation problem? Something else?
I don't know that filenames of manifests affect anything. Running with debug
and verbose flags as above will show you more about what's going on.
Thanks for you help.
Matthew
--
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: What is the offical variable scope best practice?
Very thanks for your detailed explanation :) For the last question, what doubt me is only fact variables in a template which is invoked by a define will throw the warning, if the template is invoked by a class, everything is ok. On Wed, Nov 16, 2011 at 10:54 PM, jcbollinger john.bollin...@stjude.orgwrote: On Nov 16, 3:59 am, flex frostyn...@gmail.com wrote: I read the guide athttp:// docs.puppetlabs.com/guides/scope_and_puppet.htmlandothers' mail, i am a little confused now, below is my understanding: 1. top scope only refers to site.pp, not include node definitions and facts. Top scope refers to anything outside all class and node definitions. Top scope variables can appear in any manifest file, but site.pp is a very good choice because it is always processed, and first. Top scope variables in most other locations may sometimes fail to be visible in manifests other than the ones where they appear. If you put a class or node definition in site.pp, that class's or node's variables are not in top scope. Facts certainly are in top scope; in some manifest sets they are the *only* variables in top scope. 2. in puppet class, using variables not local, must specify the namespace, like $class::variable, if it's a top scope variable or a fact variable or a variable in node definition, using $::variable. For Puppet 2.7.x and below, this is not always the case: you can access variables in the current dynamic scope by their simple names. Top scope variables are always in the current dynamic scope, but a narrower scope might define a variable having the same simple name, so it is always safest to use $::variable when that's what you mean. Dynamic scope can apply to class variables, too, but again it's safest to use refer to non-local variables by their fully-qualified names. Starting in Puppet 2.8, however, it will be mandatory to refer to non- local variables by their fully-qualified names. In preparation for that, Puppet 2.7.x emits warning when your manifests resolve non-local variables from the dynamic scope. 3. in template erb files, always using scope.lookupvar(class::variable) to get the value, even if the erb and the variable used in the same module or it is a fact variable The docs suggest that templates can use all the simple variable names that can be resolved in the scope where they are invoked, but I cannot independently confirm that. Certainly, wherever you need or want to use a qualified name, scope.lookupvar() is your tool. are these points correct? btw, only some of my old code give dynamic lookup warnings under puppet 2.7, does this mean the others not need to modify? I doubt it would be safe to say that manifests that do not elicit dynamic lookup warnings will not need any modification to work with Puppet 2.8. Also, do understand that it is not necessarily the case that every manifest is processed for every client, so you have to take care in judging which code gives warnings and which doesn't. John -- 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. -- System Administrator, Focus on System Management and Basic Development -- 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] Multiple nodes.pp files
On Wed, 16 Nov 2011 15:32:41 +0100 Hugo Deprez wrote: Dear community, Hi Hugo, I would like to know if it is possible to use different files for the nodes.pp Can we use in nodes.pp the following syntax : include nodes2.pp we have several node files but use import. [...] Thank you. hugo HTH, 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-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] Execute command on another agent
Hello,
I have this setup but don't know how to implement it in puppet. There are 3
servers: puppetmaster, agent1, agent2
In order to setup agent1, I need to run a command on agent2 and return the
data.
I know file can generate() function to run a command. However, it runs on
the puppetmaster but I need it to run on agent2 instead. Is it possible
with puppet? How? Thanks
file { /tmp/setup_data:
content = generate(
/bin/sh,
/tmp/script_on_puppetmaster.sh,
$myvar,
)
}
--
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/-/kYGRX3e0B1kJ.
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] Gem provider can tell properly if correct version is installed.
Im using puppet 2.7.6 and gem 1.5.2 debug: Puppet::Type::Package::ProviderGem: Executing '/usr/local/bin/gem list --remote nokogiri$' debug: /Stage[main]/Hadoop::Gems/Package[nokogiri]/ensure: nokogiri 1.5.0 is installed, latest is 1.5.0 ruby java x86-mingw32 x86-mswin32-60 debug: Package[nokogiri](provider=gem): Executing '/usr/local/bin/gem install --include-dependencies --no-rdoc --no-ri nokogiri' Seems as if installed != latest marks it as to be installed but latest includes which VM it works with Cheers, Tom -- 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] How to debug intermittent puppet catalog failure
Jo Rhett wrote: Are you running the latest centos or redhat-based kernel? If so, 274.7.1 is corked. Backgrade from 274.7.1 to 274.3.1 and the problem will disappear. This is documented in https://projects.puppetlabs.com/issues/10418 And RedHat bug https://bugzilla.redhat.com/show_bug.cgi?id=751214 Thanks for filing that Jo. I've found the same issue on my CentOS systems. Can you mark that bug as public or ask the RHEL folks to do so? Right now, it's not accessible to most folks -- myself included. As one of the EPEL puppet maintainers, I'd very much like to be able to follow the discussion there. Perhaps if the bug can't be made public, I could get on the Cc? Thanks, -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ If God had meant for us to be naked, we would have been born that way. pgpFWNhwC3Cjt.pgp Description: PGP signature
Re: [Puppet Users] Multiple nodes.pp files
- Arnau Bria arnaub...@pic.es wrote: On Wed, 16 Nov 2011 15:32:41 +0100 Hugo Deprez wrote: Dear community, Hi Hugo, I would like to know if it is possible to use different files for the nodes.pp Can we use in nodes.pp the following syntax : include nodes2.pp we have several node files but use import. So, to be certain I understand properly, you have : manifests/node.pp manifests/node1.pp manifests/node2.pp ... and manifests/node.pp contains: import node1 import node2 ... Is that it ? “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] working thru tutorial
When I run `puppet apply --verbose --debug httpd.pp`, the last lines
printed are:
debug: Finishing transaction -608038528
debug: Loaded state in 0.00 seconds
info: Applying configuration version '1321356508'
debug: Service[httpd](provider=redhat): Executing 'ps -ef'
debug: Service[httpd](provider=redhat): PID is 17243
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
httpd'
debug: Finishing transaction -608222128
debug: Storing state
debug: Stored state in 0.01 seconds
When I run `puppet apply --verbose --debug start.pp`, the last lines
printed are:
debug: Finishing transaction -607971218
debug: Loaded state in 0.00 seconds
info: Applying configuration version '1321356691'
debug: Service[httpd](provider=redhat): Executing 'ps -ef'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
httpd'
debug: Service[httpd](provider=redhat): Executing '/sbin/service httpd
start'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
httpd'
notice: /Stage[main]//Service[httpd]/ensure: ensure changed 'stopped' to
'running'
debug: Finishing transaction -608154818
debug: Storing state
debug: Stored state in 0.01 seconds
I made sure to stop `httpd` before each run. `start.pp` and `httpd.pp` have
the same contents.
Any other thoughts?
On Wed, Nov 16, 2011 at 9:00 AM, Christopher Wood
christopher_w...@pobox.com wrote:
On Tue, Nov 15, 2011 at 04:40:29PM -0800, Matthew O'Connor wrote:
Hi all,
I'm working thru the tutorial (http://docs.puppetlabs.com/learning/
manifests.html) using the VM provided (http://www.puppetlabs.com/
downloads/learning/learn_puppet_centos_ovf.2011.07.15.tar.bz). When
asked to write a manifest that ensures httpd is running, I wrote:
service { 'httpd':
ensure = running,
enable = true,
}
I named this manifest httpd.pp. When I ran `puppet apply httpd.pp`
nothing happens. If I rename this manifest to something else `puppet
apply` works as I would expect.
puppet apply --debug --verbose httpd.pp
If the service is already running and enabled then puppet won't do
anything.
This was/is extremely confusing. I figured what better way to name the
manifest than to name the service it's ensuring. Is this a known
issue? Documentation problem? Something else?
I don't know that filenames of manifests affect anything. Running with
debug and verbose flags as above will show you more about what's going on.
Thanks for you help.
Matthew
--
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.
--
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] working thru tutorial
Do you have another http daemon running, by chance? If I'm reading this
right, the first run seems to think it found another httpd server on PID
17243 - what's running on that process?
On Wed, Nov 16, 2011 at 9:37 AM, Matthew O'Connor
thegreendra...@gmail.comwrote:
When I run `puppet apply --verbose --debug httpd.pp`, the last lines
printed are:
debug: Finishing transaction -608038528
debug: Loaded state in 0.00 seconds
info: Applying configuration version '1321356508'
debug: Service[httpd](provider=redhat): Executing 'ps -ef'
debug: Service[httpd](provider=redhat): PID is 17243
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
httpd'
debug: Finishing transaction -608222128
debug: Storing state
debug: Stored state in 0.01 seconds
When I run `puppet apply --verbose --debug start.pp`, the last lines
printed are:
debug: Finishing transaction -607971218
debug: Loaded state in 0.00 seconds
info: Applying configuration version '1321356691'
debug: Service[httpd](provider=redhat): Executing 'ps -ef'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
httpd'
debug: Service[httpd](provider=redhat): Executing '/sbin/service httpd
start'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
httpd'
notice: /Stage[main]//Service[httpd]/ensure: ensure changed 'stopped' to
'running'
debug: Finishing transaction -608154818
debug: Storing state
debug: Stored state in 0.01 seconds
I made sure to stop `httpd` before each run. `start.pp` and `httpd.pp`
have the same contents.
Any other thoughts?
On Wed, Nov 16, 2011 at 9:00 AM, Christopher Wood
christopher_w...@pobox.com wrote:
On Tue, Nov 15, 2011 at 04:40:29PM -0800, Matthew O'Connor wrote:
Hi all,
I'm working thru the tutorial (http://docs.puppetlabs.com/learning/
manifests.html) using the VM provided (http://www.puppetlabs.com/
downloads/learning/learn_puppet_centos_ovf.2011.07.15.tar.bz). When
asked to write a manifest that ensures httpd is running, I wrote:
service { 'httpd':
ensure = running,
enable = true,
}
I named this manifest httpd.pp. When I ran `puppet apply httpd.pp`
nothing happens. If I rename this manifest to something else `puppet
apply` works as I would expect.
puppet apply --debug --verbose httpd.pp
If the service is already running and enabled then puppet won't do
anything.
This was/is extremely confusing. I figured what better way to name the
manifest than to name the service it's ensuring. Is this a known
issue? Documentation problem? Something else?
I don't know that filenames of manifests affect anything. Running with
debug and verbose flags as above will show you more about what's going on.
Thanks for you help.
Matthew
--
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.
--
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: Multiple nodes.pp files
I think it's fairly common to put something like this in your site.pp
if you like separate node files which I prefer.
import nodes/*.pp
You can also use regex in your node files to further simplify though
if you're doing a lot of logic here you should probably start thinking
about an ENC.
fe.pp
node /^fe\d+(.*)/ inherits basenode {
case $::fqdn {
/(.*)stage|demo(.*)/: {
include hostgroup::frontend::stage
}
default: {
include hostgroup::frontend::prod
}
}
}
Ramin
On Nov 16, 6:32 am, Hugo Deprez hugo.dep...@gmail.com wrote:
Dear community,
I would like to know if it is possible to use different files for the nodes.pp
Can we use in nodes.pp the following syntax :
include nodes2.pp
nodes2.pp could contain host definition eactly as nodes.pp but for a
particular platform.
This would allow more readable configuration file.
I didn't find anything on the internet.
Thank you.
hugo
--
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] working thru tutorial
I looked for that. There's not any other http daemon running. The PID that
the first returns changes every time (now at 23052, 23139, etc.). The
second one never returns a PID (unless there's actually an httpd running).
On Wed, Nov 16, 2011 at 10:54 AM, Russell Van Tassell
russel...@gmail.comwrote:
Do you have another http daemon running, by chance? If I'm reading this
right, the first run seems to think it found another httpd server on PID
17243 - what's running on that process?
On Wed, Nov 16, 2011 at 9:37 AM, Matthew O'Connor
thegreendra...@gmail.com wrote:
When I run `puppet apply --verbose --debug httpd.pp`, the last lines
printed are:
debug: Finishing transaction -608038528
debug: Loaded state in 0.00 seconds
info: Applying configuration version '1321356508'
debug: Service[httpd](provider=redhat): Executing 'ps -ef'
debug: Service[httpd](provider=redhat): PID is 17243
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
httpd'
debug: Finishing transaction -608222128
debug: Storing state
debug: Stored state in 0.01 seconds
When I run `puppet apply --verbose --debug start.pp`, the last lines
printed are:
debug: Finishing transaction -607971218
debug: Loaded state in 0.00 seconds
info: Applying configuration version '1321356691'
debug: Service[httpd](provider=redhat): Executing 'ps -ef'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
httpd'
debug: Service[httpd](provider=redhat): Executing '/sbin/service httpd
start'
debug: Puppet::Type::Service::ProviderRedhat: Executing '/sbin/chkconfig
httpd'
notice: /Stage[main]//Service[httpd]/ensure: ensure changed 'stopped' to
'running'
debug: Finishing transaction -608154818
debug: Storing state
debug: Stored state in 0.01 seconds
I made sure to stop `httpd` before each run. `start.pp` and `httpd.pp`
have the same contents.
Any other thoughts?
On Wed, Nov 16, 2011 at 9:00 AM, Christopher Wood
christopher_w...@pobox.com wrote:
On Tue, Nov 15, 2011 at 04:40:29PM -0800, Matthew O'Connor wrote:
Hi all,
I'm working thru the tutorial (http://docs.puppetlabs.com/learning/
manifests.html) using the VM provided (http://www.puppetlabs.com/
downloads/learning/learn_puppet_centos_ovf.2011.07.15.tar.bz). When
asked to write a manifest that ensures httpd is running, I wrote:
service { 'httpd':
ensure = running,
enable = true,
}
I named this manifest httpd.pp. When I ran `puppet apply httpd.pp`
nothing happens. If I rename this manifest to something else `puppet
apply` works as I would expect.
puppet apply --debug --verbose httpd.pp
If the service is already running and enabled then puppet won't do
anything.
This was/is extremely confusing. I figured what better way to name the
manifest than to name the service it's ensuring. Is this a known
issue? Documentation problem? Something else?
I don't know that filenames of manifests affect anything. Running with
debug and verbose flags as above will show you more about what's going on.
Thanks for you help.
Matthew
--
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.
--
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.
--
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] working thru tutorial
On Wed, Nov 16, 2011 at 2:14 PM, Matthew O'Connor
thegreendra...@gmail.com wrote:
I looked for that. There's not any other http daemon running. The PID that
the first returns changes every time (now at 23052, 23139, etc.). The second
one never returns a PID (unless there's actually an httpd running).
Add hasstatus so it uses service instead of ps -ef for checking the service:
service { 'httpd':
ensure = running,
enable = true,
hasstatus = true,
}
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-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] working thru tutorial
That fixed it.
Oh, I think I see what's going on:
When I run `puppet httpd.pp`, it runs `ps` and finds a process with `httpd`
in the name and so concludes the service is running. If I rename the script
to something else then Puppet no longer finds any process with 'httpd' in
its name.
Perhaps Puppet should have a check that prevents thinking it is the
satisfying service?
Thanks,
Matt
On Wed, Nov 16, 2011 at 12:54 PM, Nan Liu n...@puppetlabs.com wrote:
On Wed, Nov 16, 2011 at 2:14 PM, Matthew O'Connor
thegreendra...@gmail.com wrote:
I looked for that. There's not any other http daemon running. The PID
that
the first returns changes every time (now at 23052, 23139, etc.). The
second
one never returns a PID (unless there's actually an httpd running).
Add hasstatus so it uses service instead of ps -ef for checking the
service:
service { 'httpd':
ensure = running,
enable = true,
hasstatus = true,
}
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-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] working thru tutorial
You can setup a pattern with a regular expression to weed-out the process
list if you don't use hasstatus
http://docs.puppetlabs.com/references/latest/type.html#service
...but, sounds like you nailed it.
On Wed, Nov 16, 2011 at 12:18 PM, Matthew O'Connor thegreendra...@gmail.com
wrote:
That fixed it.
Oh, I think I see what's going on:
When I run `puppet httpd.pp`, it runs `ps` and finds a process with
`httpd` in the name and so concludes the service is running. If I rename
the script to something else then Puppet no longer finds any process with
'httpd' in its name.
Perhaps Puppet should have a check that prevents thinking it is the
satisfying service?
Thanks,
Matt
On Wed, Nov 16, 2011 at 12:54 PM, Nan Liu n...@puppetlabs.com wrote:
On Wed, Nov 16, 2011 at 2:14 PM, Matthew O'Connor
thegreendra...@gmail.com wrote:
I looked for that. There's not any other http daemon running. The PID
that
the first returns changes every time (now at 23052, 23139, etc.). The
second
one never returns a PID (unless there's actually an httpd running).
Add hasstatus so it uses service instead of ps -ef for checking the
service:
service { 'httpd':
ensure = running,
enable = true,
hasstatus = true,
}
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-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.
--
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] Duplicate resource problem for localhost
On Wed, Nov 16, 2011 at 1:19 AM, Karen Loomans ka...@loomans.org wrote:
Hi,
I have a module to manage /etc/hosts that works fine for RHEL, but not on
Solaris. Basically I've defined all our hosts as virtual host resources,
and grouped them various ways by tagging them. These are then realized
based on the tags for each node as appropriate. Hosts can have multiple
tags and not have any issues with duplicate resource declarations as they
are virtual. Any unmanaged host is then purged from the hosts file.
The problem for Solaris occurs with the localhost entries:
::1 localhost
127.0.0.1 localhost
You can't define host resources with the same name.
I would prefer to keep using the host resource if I can as it all works
beautifully on our RHEL servers (the localhost names are unique). I thought
I might be able to:
1. Template the beginning of the hosts file to include the localhost
entries appropriate to the os, writing out to /tmp/hosts_head.
2. Generate another file in /tmp/hosts_body that contains the remainder
of the hosts using my current method of realizing the virtual hosts.
3. Concatenate the two.
However, when I redirect the target for all the host resources to
/tmp/hosts_body, it rips out the contents in the real /etc/inet/hosts:
notice: /Stage[after]/Hosts::Virtual/Host[george]/target: target changed
'/etc/inet/hosts' to '/tmp/hosts_body'
Has anyone solved this problem on Solaris or can offer some suggestions?
Would this work for your usage:
host { 'ip6-localhost':
ip = '::1',
host_aliases = 'localhost',
}
host { 'localhost':
ip = '127.0.0.1'
}
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-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: define-type resources default parameters not available under scope.catalog.resources
On Nov 16, 9:16 am, Theo Cabrerizo Diem d...@carpediem.sh wrote:
Hi All,
I have a define-type resource, which gets called from multiple classes, on
which I would like to read its parameters from a template. This works for
parameters added to the call of the resource but not for those which have a
default value on its definition.
On the example below, I can read the parameter from Webdir[c] but not from
a and b.
If webdir would be a class type instead (and with the restriction of being
able to call it only once) it would work, since
resource(Webdir[a]).parameters includes the ones set by default on the
class definition.
Is this intended or a bug ?
I don't know, but parameterized classes do not serve as a reasonable
reference for how defined type instances should behave. I do suspect,
however, that the behavior you observe is not only intended, but also
consistent with the behavior of native resource instances (see below).
I know that using a native define-type (those written in ruby) I can access
the parameters as intended
Really? I'm not a big templating guy, but if you declare, say
service { 'frob': enable = true }
then what does the following template output?
%= scope.findresource(Service[frob])['hasstatus'] -%
The built-in Service type defines a default value for its hasstatus
property, but I predict (instead of testing ... dangerous :-) ) that
the template will evaluate to a blank / empty string. That would be
exactly analogous to your case.
but, like the example below, it is nice to have
the simplicity for doing the same on define-type resources when they
contain other resources such as file, services, vcsrepo, etc.
I understand, but really you ought to go at it a different way. A lot
of people seem inclined to want in one part of their manifests to
interrogate Puppet about what they themselves declared in a different
part of their manifests. With some notable exceptions, that is a
Puppet anti-pattern.
For the case at hand, I would recommed using the Concat module to
build your httpd configuration from pieces. Each webdir instance
would declare an appropriate fragment, using the knowledge it already
has about its own parameter values. Alternatively, you could let each
webdir manage its piece of the configuration as a separate file, and
make httpd.conf (or whatever) interpolate them all.
John
--
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] Duplicate resource problem for localhost
Hi Nan,
Thanks for the reply. That was the first thing I asked our group, but
unfortunately for the Solaris servers it is the group's policy not to alias
localhost (for various reasons I won't go into here). I'll raise it again,
but if an alternate solution can be found it would be preferable. Any
other ideas?
Cheers,
Karen
On Thu, Nov 17, 2011 at 8:09 AM, Nan Liu n...@puppetlabs.com wrote:
On Wed, Nov 16, 2011 at 1:19 AM, Karen Loomans ka...@loomans.org wrote:
Hi,
I have a module to manage /etc/hosts that works fine for RHEL, but not on
Solaris. Basically I've defined all our hosts as virtual host resources,
and grouped them various ways by tagging them. These are then realized
based on the tags for each node as appropriate. Hosts can have multiple
tags and not have any issues with duplicate resource declarations as they
are virtual. Any unmanaged host is then purged from the hosts file.
The problem for Solaris occurs with the localhost entries:
::1 localhost
127.0.0.1 localhost
You can't define host resources with the same name.
I would prefer to keep using the host resource if I can as it all works
beautifully on our RHEL servers (the localhost names are unique). I
thought
I might be able to:
1. Template the beginning of the hosts file to include the localhost
entries appropriate to the os, writing out to /tmp/hosts_head.
2. Generate another file in /tmp/hosts_body that contains the
remainder
of the hosts using my current method of realizing the virtual hosts.
3. Concatenate the two.
However, when I redirect the target for all the host resources to
/tmp/hosts_body, it rips out the contents in the real /etc/inet/hosts:
notice: /Stage[after]/Hosts::Virtual/Host[george]/target: target
changed
'/etc/inet/hosts' to '/tmp/hosts_body'
Has anyone solved this problem on Solaris or can offer some suggestions?
Would this work for your usage:
host { 'ip6-localhost':
ip = '::1',
host_aliases = 'localhost',
}
host { 'localhost':
ip = '127.0.0.1'
}
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-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] AW: nagios_service does not replace target file
Hi all,
I'm a little bit confused that I did not get a single reply from the list
concerning the problem of not re-created configuration files when using
stored configurations for generating an Icinga/Nagios configuration.
Please tell me at least if my question if this could be a bug seems to be
reasonable (see below).
Is there no one else having the same problem? Any ideas from Puppetlabs?
Thanks Bernd
Well, it turned out that I was not able to create a Puppet configuration
whichdoes a reliable re-creation of the Nagios configuration files. My
workaround isnow to restart the Puppet agent with a cron job and before
restarting I deletethe old configuration files like this:
/bin/logger $0: Preparing Puppet agent for execution
/bin/rm -f ${CFG_DIR}/*
/bin/logger $0: Deleted Icinga configuration files below $CFG_DIR
/bin/logger $0: Starting Puppet agent now
/usr/bin/puppet agent $PUPPET_OPTS
/bin/logger $0: Puppet run finished
Though a little bit ugly, this is now a reliable solution.
I'd like to summarize the problems I've encountered:
1. If stored configurations change within the MySQL database, this will
not bereflected in the Nagios configuration files created by the
Nagios_* resources -as described in my first mail.
2. If I try to do delete the configuration files using a exec resource
beforethe Nagios_* resources, I encounter alternating creation and
deletion of theconfiguration files - as describe in my second mail.
Maybe (2.) was some kind of misconfiguration I did, but at least (1.)
could bea bug. Since I got no reply from the list, it seems that I'm the
only one everrunning into this problem. So I'd like to ask this list and
mainly the Puppetguys if you think this is worth filing a bug?
Thanks
Bernd
-Ursprüngliche Nachricht-
Von: puppet-users@googlegroups.com [mailto:puppet-
us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
Gesendet: Mittwoch, 9. November 2011 13:44
An: 'puppet-users@googlegroups.com'
Betreff: [Puppet Users] AW: nagios_service does not replace target file
Now I tried this:
exec {/bin/rm -f ${icinga::baseconfigdir}/${conf_file_hosts}:
require = File[${icinga::baseconfigdir}],
}
Nagios_host || {
target = ${icinga::baseconfigdir}/${conf_file_hosts},
require = Exec[/bin/rm -f
${icinga::baseconfigdir}/${conf_file_hosts}],
before = File[${icinga::baseconfigdir}/${conf_file_hosts}],
}
file { ${icinga::baseconfigdir}/${conf_file_hosts}:
ensure = present,
owner = puppet,
group = puppet,
mode = 0644,
backup = false,
replace = false,
}
This created alternating behavior of the file
'${icinga::baseconfigdir}/${conf_file_hosts}'. If the file was
generated, the next run will leave it empty. If it's empty, the next
run will regenerate the content as expected and so on.
I encountered the same behavior when using real Nagios resources like
'nagios_hostgroup' for example. Is there something special about Nagios
resources which will create this strange behavior?
Bernd
-Ursprüngliche Nachricht-
Von: puppet-users@googlegroups.com [mailto:puppet-
us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
Gesendet: Dienstag, 8. November 2011 17:48
An: 'puppet-users@googlegroups.com'
Betreff: [Puppet Users] nagios_service does not replace target file
Hi all,
I'm using Puppet 2.6.6 on both clients and master along with stored
configurations. My clients provide Nagios configurations like this
example:
@@nagios_service { check_ping_${hostname}:
check_command = check_ping!100.0,20%!500.0,60%,
use = generic-service,
host_name = $fqdn,
service_description = ${prefix}PING: ${hostname},
}
They are realized on the master with the Nagios_service:
Nagios_service || {
target = ${baseconfigdir}/${conf_file_srvs},
require = File[${baseconfigdir}/${conf_file_srvs}],
}
Since I needed special access rights for the target file (it's
rsynced
from another host), I added an appropriate file resource:
file { ${baseconfigdir}/${conf_file_srvs}:
ensure = present,
owner = puppet,
group = puppet,
mode = 0644,
backup = false,
require = File[${baseconfigdir}],
}
Everything works fine on the first run. But once a client changes its
Nagios resources, the new configuration will not end up in the target
file of Nagios_service.
I checked the table 'resources' within the MySQL database after the
client executes - the changes to the exported resources are
definitely
done there. (E.g.: mysql select title,restype from resources where
host_id=6 and exported=1;)
I tried to poke around and added
content =
to the file resource. Or I removed the 'require' attribute from the
Nagios_service resource. I also tried to keep the ${baseconfigdir}
clean by adding this resource:
file {${baseconfigdir}:
ensure = directory,
owner = puppet,
group = puppet,
mode = 0755,
backup = false,
Re: [Puppet Users] working thru tutorial
On Wed, Nov 16, 2011 at 12:18 PM, Matthew O'Connor thegreendra...@gmail.com wrote: That fixed it. Oh, I think I see what's going on: When I run `puppet httpd.pp`, it runs `ps` and finds a process with `httpd` in the name and so concludes the service is running. If I rename the script to something else then Puppet no longer finds any process with 'httpd' in its name. Perhaps Puppet should have a check that prevents thinking it is the satisfying service? That seems reasonable, but how would you handle the case where you want puppet to handle the puppet service? -- 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: What is the offical variable scope best practice?
Does the @ method is supported by puppet 2.8? During my test, it can also be used not only ahead facts variable but also the variable in its parent class, it is this a wordaround for dynamic scope problem? On Thu, Nov 17, 2011 at 2:39 AM, Nigel Kersten ni...@puppetlabs.com wrote: On Wed, Nov 16, 2011 at 8:03 AM, flex frostyn...@gmail.com wrote: Very thanks for your detailed explanation :) For the last question, what doubt me is only fact variables in a template which is invoked by a define will throw the warning, if the template is invoked by a class, everything is ok. Use it as an instance variable, like @factname http://projects.puppetlabs.com/issues/10248 We should definitely have documented this better, and we'll do so. -- 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. -- System Administrator, Focus on System Management and Basic Development -- 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] working thru tutorial
Hm, I hadn't thought of that. Do you have a time where one instance of Puppet would manage itself - versus managing another running copy of Puppet? On Wed, Nov 16, 2011 at 3:54 PM, Nigel Kersten ni...@puppetlabs.com wrote: On Wed, Nov 16, 2011 at 12:18 PM, Matthew O'Connor thegreendra...@gmail.com wrote: That fixed it. Oh, I think I see what's going on: When I run `puppet httpd.pp`, it runs `ps` and finds a process with `httpd` in the name and so concludes the service is running. If I rename the script to something else then Puppet no longer finds any process with 'httpd' in its name. Perhaps Puppet should have a check that prevents thinking it is the satisfying service? That seems reasonable, but how would you handle the case where you want puppet to handle the puppet service? -- 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] AW: nagios_service does not replace target file
Hi,
the module I'm using is almost setup the same, but I don't experience
the same issue:
the nagios server collects nagios config resources (and sets the target
file for each kind of resource), and there's a resource for the files
themselves which define the permissions.
however, there's no require link between both.
what happens if you try and remove the require link from Nagios_XYZ -
${baseconfigdir}/${conf_file_srvs} ?
On 11-11-16 05:57 PM, Bernd Adamowicz wrote:
Hi all,
I'm a little bit confused that I did not get a single reply from the
list concerning the problem of not re-created configuration files when
using stored configurations for generating an Icinga/Nagios
configuration. Please tell me at least if my question if this could be a
bug seems to be reasonable (see below).
Is there no one else having the same problem? Any ideas from Puppetlabs?
Thanks Bernd
Well, it turned out that I was not able to create a Puppet
configuration whichdoes a reliable re-creation of the Nagios
configuration files. My workaround isnow to restart the Puppet agent
with a cron job and before restarting I deletethe old configuration
files like this:
/bin/logger $0: Preparing Puppet agent for execution
/bin/rm -f ${CFG_DIR}/*
/bin/logger $0: Deleted Icinga configuration files below $CFG_DIR
/bin/logger $0: Starting Puppet agent now
/usr/bin/puppet agent $PUPPET_OPTS
/bin/logger $0: Puppet run finished
Though a little bit ugly, this is now a reliable solution.
I'd like to summarize the problems I've encountered:
1. If stored configurations change within the MySQL database, this
will not bereflected in the Nagios configuration files created by the
Nagios_* resources -as described in my first mail.
2. If I try to do delete the configuration files using a exec resource
beforethe Nagios_* resources, I encounter alternating creation and
deletion of theconfiguration files - as describe in my second mail.
Maybe (2.) was some kind of misconfiguration I did, but at least (1.)
could bea bug. Since I got no reply from the list, it seems that I'm
the only one everrunning into this problem. So I'd like to ask this
list and mainly the Puppetguys if you think this is worth filing a bug?
Thanks
Bernd
-Ursprüngliche Nachricht-
Von: puppet-users@googlegroups.com [mailto:puppet-
us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
Gesendet: Mittwoch, 9. November 2011 13:44
An: 'puppet-users@googlegroups.com'
Betreff: [Puppet Users] AW: nagios_service does not replace target file
Now I tried this:
exec {/bin/rm -f ${icinga::baseconfigdir}/${conf_file_hosts}:
require = File[${icinga::baseconfigdir}],
}
Nagios_host || {
target = ${icinga::baseconfigdir}/${conf_file_hosts},
require = Exec[/bin/rm -f
${icinga::baseconfigdir}/${conf_file_hosts}],
before = File[${icinga::baseconfigdir}/${conf_file_hosts}],
}
file { ${icinga::baseconfigdir}/${conf_file_hosts}:
ensure = present,
owner = puppet,
group = puppet,
mode = 0644,
backup = false,
replace = false,
}
This created alternating behavior of the file
'${icinga::baseconfigdir}/${conf_file_hosts}'. If the file was
generated, the next run will leave it empty. If it's empty, the next
run will regenerate the content as expected and so on.
I encountered the same behavior when using real Nagios resources like
'nagios_hostgroup' for example. Is there something special about Nagios
resources which will create this strange behavior?
Bernd
-Ursprüngliche Nachricht-
Von: puppet-users@googlegroups.com [mailto:puppet-
us...@googlegroups.com] Im Auftrag von Bernd Adamowicz
Gesendet: Dienstag, 8. November 2011 17:48
An: 'puppet-users@googlegroups.com'
Betreff: [Puppet Users] nagios_service does not replace target file
Hi all,
I'm using Puppet 2.6.6 on both clients and master along with stored
configurations. My clients provide Nagios configurations like this
example:
@@nagios_service { check_ping_${hostname}:
check_command = check_ping!100.0,20%!500.0,60%,
use = generic-service,
host_name = $fqdn,
service_description = ${prefix}PING: ${hostname},
}
They are realized on the master with the Nagios_service:
Nagios_service || {
target = ${baseconfigdir}/${conf_file_srvs},
require = File[${baseconfigdir}/${conf_file_srvs}],
}
Since I needed special access rights for the target file (it's
rsynced
from another host), I added an appropriate file resource:
file { ${baseconfigdir}/${conf_file_srvs}:
ensure = present,
owner = puppet,
group = puppet,
mode = 0644,
backup = false,
require = File[${baseconfigdir}],
}
Everything works fine on the first run. But once a client changes its
Nagios resources, the new configuration will not end up in the target
file of Nagios_service.
I checked the table 'resources' within
Re: [Puppet Users] working thru tutorial
On Wed, Nov 16, 2011 at 08:09:11PM -0700, Matthew O'Connor wrote: Hm, I hadn't thought of that. Do you have a time where one instance of Puppet would manage itself - versus managing another running copy of Puppet? I do this. A virtual machine template is configured with a puppet.conf that asks the puppetmaster every minute for its configuration. Part of the first puppet run with a newly duped server involves setting the runinterval to a custom value between 3600 and 7200 seconds. On Wed, Nov 16, 2011 at 3:54 PM, Nigel Kersten [1]ni...@puppetlabs.com wrote: On Wed, Nov 16, 2011 at 12:18 PM, Matthew O'Connor [2]thegreendra...@gmail.com wrote: That fixed it. Oh, I think I see what's going on: When I run `puppet httpd.pp`, it runs `ps` and finds a process with `httpd` in the name and so concludes the service is running. If I rename the script to something else then Puppet no longer finds any process with 'httpd' in its name. Perhaps Puppet should have a check that prevents thinking it is the satisfying service? That seems reasonable, but how would you handle the case where you want puppet to handle the puppet service? � -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to [3]puppet-users@googlegroups.com. To unsubscribe from this group, send email to [4]puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at [5]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. References Visible links 1. mailto:ni...@puppetlabs.com 2. mailto:thegreendra...@gmail.com 3. mailto:puppet-users@googlegroups.com 4. mailto:puppet-users%2bunsubscr...@googlegroups.com 5. 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.
