[Puppet Users] Conditionals
Hi guys,
I'm trying to get my head around conditionals and variables.
What I'm trying to do now is to distinguish between puppet servers and
puppet clients and deliver some settings differently. How can I do that?
I tried to put a variable in the node classes:
node 'puppet1' {
$puppetmode = master,
include puppetmasterclass
}
node 'client1' {
$puppetmode = client,
include puppetclientclass
}
and then in the classes do something like:
case $puppetmode {
master: {
$baseurl_base = file:///puppet/repos
}
client: {
$baseurl_base = http://puppet1/inst;
}
}
class system::repos {
yumrepo { 'RHEL-5.5-64':
descr = 'RedHat Enterprise Linux 5.5 64-bit',
baseurl = ${baseurl_base}/RHEL-5.5-x86_64/Server,
}
}
But that doesn't work. Another attempt was to do the case statement by
hostname wildcard:
case $hostname {
puppet* {
$baseurl_base = ...
}
}
but that didn't work either.
It's not only about puppet master/client. I will have to know in some
modules in which datacentre a given node is, etc. So was hoping to be
able to set a couple of parameters in the node declaration and then work
with that in the modules.
Can I somehow pass variables or other tokens around the catalogue and
make conditional decisions in other modules based on them?
I'm sure this is something trivial but can't figure out how to do that.
Thanks for any hints!
GiBo
--
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] Conditionals
Hi,
general: it would be nice if you could also send logoutput.
On 05/03/2011 08:34 AM, Giovanni Bordello wrote:
Hi guys,
I'm trying to get my head around conditionals and variables.
What I'm trying to do now is to distinguish between puppet servers and
puppet clients and deliver some settings differently. How can I do that?
I tried to put a variable in the node classes:
node 'puppet1' {
$puppetmode = master,
include puppetmasterclass
}
node 'client1' {
$puppetmode = client,
include puppetclientclass
}
I would not use the colon on the line with the key value pair.
and then in the classes do something like:
case $puppetmode {
master: {
$baseurl_base = file:///puppet/repos
}
client: {
$baseurl_base = http://puppet1/inst;
}
}
class system::repos {
yumrepo { 'RHEL-5.5-64':
descr = 'RedHat Enterprise Linux 5.5 64-bit',
baseurl = ${baseurl_base}/RHEL-5.5-x86_64/Server,
}
}
But that doesn't work. Another attempt was to do the case statement by
hostname wildcard:
case $hostname {
puppet* {
$baseurl_base = ...
}
}
using regexp requires another syntax for the hostname:
/^puppet*$/ instead of puppet*
but that didn't work either.
It's not only about puppet master/client. I will have to know in some
modules in which datacentre a given node is, etc. So was hoping to be
able to set a couple of parameters in the node declaration and then work
with that in the modules.
Can I somehow pass variables or other tokens around the catalogue and
make conditional decisions in other modules based on them?
I'm sure this is something trivial but can't figure out how to do that.
Thanks for any hints!
GiBo
--
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: Resolving/ Expanding module puppet:/// URI in exec line
Hi Nan,
Thanks for the answer - I'm not 100% clear how I could acheive this,
could you expand on your suggestion a little, perhaps with an example?
Would the file resource point at the .gz file in the module? If so how
would I then reference the file resource in the tar command?
Many thanks,
Edd
On May 2, 4:15 pm, Nan Liu n...@puppetlabs.com wrote:
Use a file resource to deploy it to the agent and make the exec depend
on the file resource.
On May 2, 2011, at 7:58, Edd Grant e...@eddgrant.com wrote:
Hi All,
I have defined the following module to untar/unzip and copy the Maven
distributable to a convenient location:
class apache-maven-v3 {
exec { /bin/tar xzf /etc/puppet/modules/apache-maven-v3/files/
apache-maven-3.0.3-bin.tar.gz:
cwd = /usr/local/java,
creates = /usr/local/java/apache-maven-3.0.3,
}
...
}
The above definition executes perfectly however in order to keep the
module portable I want to replace the absolute path to the .gz file
with a puppet:/// URI e.g.
exec { /bin/tar xzf
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz:
When I change the class to use the puppet:/// URI I get the following
error:
(/Stage[main]/Apache-maven-v3/Exec[/bin
/tar xzf
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz]/return
s) change from notrun to 0 failed: /bin/tar xzf
puppet:///modules/apache-maven-v
3/apache-maven-3.0.3-bin.tar.gz returned 2 instead of one of [0] at /
etc/puppet/
modules/apache-maven-v3/manifests/init.pp:11
It appears to me that the puppet:/// URI is not being resolved in the
exec and this is causing the tar command to operate on the literal
path puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz
which of course doesn't exist.
Looking at the docs I can't see any examples of puppet:/// being used
in this way, is there anyway I can obtain the resolved absolute path
to pass this in to my exec? Failing that it there a standard approach
for combining a puppet:/// URI with an exec?
Cheers,
Edd
--
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
athttp://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: Resolving/ Expanding module puppet:/// URI in exec line
Hi Edd,
here is an example:
class apache-maven-v3 {
# prepare local filesystem
file { 'java_path':
path = /usr/local/java,
ensure = directory,
}
# copy file from puppet master to local system
file { 'copy_maven_v3':
path = /usr/local/java/apache-maven-3.0.3-bin.tar.gz,
source =
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz,
}
# extract local file
exec { 'install_maven_v3':
command = /bin/tar zxf
/usr/local/java/apache-maven-3.0.3-bin.tar.gz,
cwd = /usr/local/java,
creates = /usr/local/java/apache-maven-3.0.3,
}
# make sure the order is set properly
File['java_path'] - File['copy_maven_v3'] - Exec['install_maven_v3']
}
kind regards,
Martin
On 05/03/2011 11:06 AM, Edd Grant wrote:
Hi Nan,
Thanks for the answer - I'm not 100% clear how I could acheive this,
could you expand on your suggestion a little, perhaps with an example?
Would the file resource point at the .gz file in the module? If so how
would I then reference the file resource in the tar command?
Many thanks,
Edd
On May 2, 4:15 pm, Nan Liu n...@puppetlabs.com wrote:
Use a file resource to deploy it to the agent and make the exec depend
on the file resource.
On May 2, 2011, at 7:58, Edd Grant e...@eddgrant.com wrote:
Hi All,
I have defined the following module to untar/unzip and copy the Maven
distributable to a convenient location:
class apache-maven-v3 {
exec { /bin/tar xzf /etc/puppet/modules/apache-maven-v3/files/
apache-maven-3.0.3-bin.tar.gz:
cwd = /usr/local/java,
creates = /usr/local/java/apache-maven-3.0.3,
}
...
}
The above definition executes perfectly however in order to keep the
module portable I want to replace the absolute path to the .gz file
with a puppet:/// URI e.g.
exec { /bin/tar xzf
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz:
When I change the class to use the puppet:/// URI I get the following
error:
(/Stage[main]/Apache-maven-v3/Exec[/bin
/tar xzf
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz]/return
s) change from notrun to 0 failed: /bin/tar xzf
puppet:///modules/apache-maven-v
3/apache-maven-3.0.3-bin.tar.gz returned 2 instead of one of [0] at /
etc/puppet/
modules/apache-maven-v3/manifests/init.pp:11
It appears to me that the puppet:/// URI is not being resolved in the
exec and this is causing the tar command to operate on the literal
path puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz
which of course doesn't exist.
Looking at the docs I can't see any examples of puppet:/// being used
in this way, is there anyway I can obtain the resolved absolute path
to pass this in to my exec? Failing that it there a standard approach
for combining a puppet:/// URI with an exec?
Cheers,
Edd
--
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
athttp://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] facter command does not show some facts
Hi, When I run root@node002:/opt/sge# /var/lib/gems/1.8/bin/facter productname it comes back empty. But: root@node002:/opt/sge# /var/lib/gems/1.8/bin/facter |grep productname productname = Sun Fire X2200 M2 facter is version 1.5.7 regards, Andreas -- 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] at which size to use a real webserver
Hi, I'm currently using puppet with the buildin server for testing on a few nodes (~5). But in the future my installation will be bigger. It will have about 110 nodes of our compute cluster and maybe some additional servers (~20). Currently I don't use very complicated manifests and want to manage only a few config files, nfs mounts and the list of installed packages. But maybe this list will grow with my love for puppet. Should I already plan on using a different server? What would you recommend? I will be using apache on one headnode anyway for ganglia nagios. Should I also move puppet to apache? How complicated is this? I'm not familar with Ruby or Rails. Btw. any suggestions for my bootstrapping install of puppet on Ubuntu? Here is my procedure: 1. minimal Ubuntu install using pxeboot with preseed file (from web-URL) 2. some postinstall config: - install facter and puppet from gems (loaded from web server) - install pre-created certs (loaded from web server) - edit /etc/hosts to make puppet server known 3. start puppet for remaining configuration: - additional packages - nfsmount ... regards, Andreas -- 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: Resolving/ Expanding module puppet:/// URI in exec line
many thanks Martin - makes perfect sense!
On May 3, 10:45 am, Martin Alfke tux...@gmail.com wrote:
Hi Edd,
here is an example:
class apache-maven-v3 {
# prepare local filesystem
file { 'java_path':
path = /usr/local/java,
ensure = directory,
}
# copy file from puppet master to local system
file { 'copy_maven_v3':
path = /usr/local/java/apache-maven-3.0.3-bin.tar.gz,
source =
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz,
}
# extract local file
exec { 'install_maven_v3':
command = /bin/tar zxf
/usr/local/java/apache-maven-3.0.3-bin.tar.gz,
cwd = /usr/local/java,
creates = /usr/local/java/apache-maven-3.0.3,
}
# make sure the order is set properly
File['java_path'] - File['copy_maven_v3'] - Exec['install_maven_v3']
}
kind regards,
Martin
On 05/03/2011 11:06 AM, Edd Grant wrote:
Hi Nan,
Thanks for the answer - I'm not 100% clear how I could acheive this,
could you expand on your suggestion a little, perhaps with an example?
Would the file resource point at the .gz file in the module? If so how
would I then reference the file resource in the tar command?
Many thanks,
Edd
On May 2, 4:15 pm, Nan Liu n...@puppetlabs.com wrote:
Use a file resource to deploy it to the agent and make the exec depend
on the file resource.
On May 2, 2011, at 7:58, Edd Grant e...@eddgrant.com wrote:
Hi All,
I have defined the following module to untar/unzip and copy the Maven
distributable to a convenient location:
class apache-maven-v3 {
exec { /bin/tar xzf /etc/puppet/modules/apache-maven-v3/files/
apache-maven-3.0.3-bin.tar.gz:
cwd = /usr/local/java,
creates = /usr/local/java/apache-maven-3.0.3,
}
...
}
The above definition executes perfectly however in order to keep the
module portable I want to replace the absolute path to the .gz file
with a puppet:/// URI e.g.
exec { /bin/tar xzf
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz:
When I change the class to use the puppet:/// URI I get the following
error:
(/Stage[main]/Apache-maven-v3/Exec[/bin
/tar xzf
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz]/return
s) change from notrun to 0 failed: /bin/tar xzf
puppet:///modules/apache-maven-v
3/apache-maven-3.0.3-bin.tar.gz returned 2 instead of one of [0] at /
etc/puppet/
modules/apache-maven-v3/manifests/init.pp:11
It appears to me that the puppet:/// URI is not being resolved in the
exec and this is causing the tar command to operate on the literal
path puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz
which of course doesn't exist.
Looking at the docs I can't see any examples of puppet:/// being used
in this way, is there anyway I can obtain the resolved absolute path
to pass this in to my exec? Failing that it there a standard approach
for combining a puppet:/// URI with an exec?
Cheers,
Edd
--
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
athttp://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] facter command does not show some facts
On Tue, May 3, 2011 at 10:06 AM, Andreas Kuntzagk andreas.kuntz...@mdc-berlin.de wrote: Hi, When I run root@node002:/opt/sge# /var/lib/gems/1.8/bin/facter productname it comes back empty. But: root@node002:/opt/sge# /var/lib/gems/1.8/bin/facter |grep productname productname = Sun Fire X2200 M2 facter is version 1.5.7 This is an issue with dynamic facts (facts key=value where the key is not the same as the ruby file name), so there isn't a productname.rb file. This issue have been addressed by later version of facter (1.5.8?). This does not affect puppet manifests from detecting fact values, only usage of facter on the command line. 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] at which size to use a real webserver
On Tue, May 3, 2011 at 11:21 AM, Andreas Kuntzagk andreas.kuntz...@mdc-berlin.de wrote: 1. minimal Ubuntu install using pxeboot with preseed file (from web-URL) I use FAI personally, which enables me to automatically include the puppet client and kick the 1st run. You could achieve the same thing with preseed, kickstart etc.. I also use the debianized packages as gems are a little more difficult to use when bootstrapping imho. I also use passenger for *everything* (even testing). It's really simple to setup, http://m.etrono.me/posts/5-simple-ish-puppet-infrastructure - a hell of a lot of this could be puppetified, granted.. -- $ echo kpfmAdpoofdufevq/dp/vl | perl -pe 's/(.)/chr(ord($1)-1)/ge' -- 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] Is it necessary for site.pp to change in order to apply a new catalog?
So I then tried doing touch site.pp before doing puppet kick in my script file and then it seemed to pick my new catalog. You should not need to do that. There's a buggy behavior on passenger where you may need to run puppet agent twice: http://projects.puppetlabs.com/issues/5318 This is unrelated to that bug, I've been having to do this since before I switched from webrick to passenger. I have: site.pp: import 'nodes' [other stuff...] nodes.pp: import 'nodes/*' The wildcard is evaluated when the nodes.pp file is compiled. It doesn't get compiled until the mtime changes (unlike the above bug which goes away on its own). Adding new files to the nodes/ directory won't affect mtime of nodes.pp ... so I have a hook in my version control on the puppet master so that nodes.pp is touched each time the repo is updated to a new commit. (I realize separating the wildcard import out of site.pp isn't really doing much, I just wanted to isolate this weird behavior and workaround into its own file). Once upon a time I think I saw a reference to this behavior in the puppet documentation but I can't find it any more ... maybe older version of the Language Guide, or maybe I saw it on the mailing list. -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-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] Could not evaluate: Cannot write SSH authorized keys without user
I just installed puppet on an ubuntu natty narwhal desktop and I'm
getting the following error on one of my puppet classes:
notice: //myclass/Ssh_authorized_key[adminuser]/ensure: created
err: //myclass/Ssh_authorized_key[adminuser]: Could not evaluate:
Cannot write SSH authorized keys without user
ssh_authorized_key { adminuser:
ensure = present,
key = blahblah,
name = adminusername,
target = /root/.ssh/authorized_keys,
type = ssh-rsa
}
This same bit works fine on ubuntu lucid, and debian squeeze. Any
ideas what could be wrong? I checked and the root user is indeed in
both /etc/passwd and /etc/shadow.
Thanks,
Richard
--
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: Force resigning of existing certificates
the ttl setting is 'ca_ttl' i think in puppet.conf.. and yes, you'll ultimately need to re-sign the certs for clients when they expire. the default is 1 year though, so it[ll be a while. On Apr 29, 2011, at 10:32 AM, Jake - USPS wrote: Yea, I'm new to puppet ... sounds like now I have to worry about certs eventually expiring and regenerate/sign them to keep nodes happy? Seems Trevor suggests increasing TTL. How can I do this if I wanted to? Thanks, Jake On Apr 28, 9:30 am, Matt Wise w...@wiredgeek.net wrote: Unfortunately, this is still a 'missing feature' of Puppet IMO. I applaud Foreman for adding it as functionality though in their own code. For our situation, we ended up writing our own CGI script on the Puppet CA servers as well as a client-side script that runs periodically on the clients to verify whether or not their cert is still valid. When their cert gets close-to-expiring, it checks in with the CGI script and supplies the original CSR that the host used for its first cert request to puppet. Our CGI script then has permissions to run some openssl commands, and generates a whole new cert for the client and passes it back. This all happens over SSL of course, and is only allowed for clients that still have a valid certificate anyways. Its not pretty, but its how we solved the problem... and its worked so far. We have ~600 hosts and they each get a new cert every 25 days. Ideally there would be this functionality built into puppet... when a client checked in, the server would check if the cert is within X days of expiring. If it is, it would generate a new cert and pass it back to the client automatically. Of course this would be an 'option', but it seems like an obvious feature addition. I looked and could not find an actual bug report requesting this functionality explicitly, so I opened one: http://projects.puppetlabs.com/issues/7272 On Apr 27, 2011, at 2:54 PM, Ohad Levy wrote: On Thu, Apr 28, 2011 at 12:17 AM, Jake - USPS jacob.m.mcc...@usps.gov wrote: OK, just had to post this! I found a solution to my issues that may help others. http://glarizza.posterous.com/managing-puppet-ssl-certificates fyi - as the original author of that script... the same functionality exists within foreman. Ohad Basically a CGI script located on you CA Server. You can pass the hostname/certname that you want to clean via http to the script and have it clean it off the CA Server. More details in the link above. This is working great for me and I'll be using it until similar functionality is included by default in puppet. Regards, Jake On Apr 14, 8:50 am, Jake - USPS jacob.m.mcc...@usps.gov wrote: Nevermind, looks like its in 2.7.0rc1 http://groups.google.com/group/puppet-users/browse_thread/thread/b3b5... cb01221 (#3360) Add an allow_duplicate_certs option On Apr 14, 8:45 am,Jake-USPSjacob.m.mcc...@usps.gov wrote: Thanks for the reply. I'm just starting to understand puppet, so I would like not to mess with that ... yet. It does look very interesting though, so thanks for bringing that up. Derek, Thanks for the bug. That looks like it includes some things that I would like ... like the allow duplicate cert and whatnot. It looks like its status closed as of 14 hours ago. Does that mean it is in some release of puppet now, or just that code it ready to eventually be implemented? I'd like to start trying it out right away as my 'solution' doesn't seem to work well with dashboard. Thanks, Jake On Apr 14, 8:41 am, Ohad Levy ohadl...@gmail.com wrote: On Thu, Apr 14, 2011 at 4:31 PM,Jake-USPSjacob.m.mcc...@usps.govwrote: Also, what is foreman and how could it help. Not familiar with that product. Foreman takes care for the entire process, things like provisioning, class assignments and reportings are all done though it (and many many other features). see http://theforeman.orgformoredetails. Ohad -- 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 athttp://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 athttp://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.
[Puppet Users] Re: Force resigning of existing certificates
Thanks for the response. I found it in the genconf now. Looks like default is 5y. I'll be changing it for my needs. Thanks! Jake On May 3, 12:53 pm, Matt Wise w...@wiredgeek.net wrote: the ttl setting is 'ca_ttl' i think in puppet.conf.. and yes, you'll ultimately need to re-sign the certs for clients when they expire. the default is 1 year though, so it[ll be a while. On Apr 29, 2011, at 10:32 AM, Jake - USPS wrote: Yea, I'm new to puppet ... sounds like now I have to worry about certs eventually expiring and regenerate/sign them to keep nodes happy? Seems Trevor suggests increasing TTL. How can I do this if I wanted to? Thanks, Jake On Apr 28, 9:30 am, Matt Wise w...@wiredgeek.net wrote: Unfortunately, this is still a 'missing feature' of Puppet IMO. I applaud Foreman for adding it as functionality though in their own code. For our situation, we ended up writing our own CGI script on the Puppet CA servers as well as a client-side script that runs periodically on the clients to verify whether or not their cert is still valid. When their cert gets close-to-expiring, it checks in with the CGI script and supplies the original CSR that the host used for its first cert request to puppet. Our CGI script then has permissions to run some openssl commands, and generates a whole new cert for the client and passes it back. This all happens over SSL of course, and is only allowed for clients that still have a valid certificate anyways. Its not pretty, but its how we solved the problem... and its worked so far. We have ~600 hosts and they each get a new cert every 25 days. Ideally there would be this functionality built into puppet... when a client checked in, the server would check if the cert is within X days of expiring. If it is, it would generate a new cert and pass it back to the client automatically. Of course this would be an 'option', but it seems like an obvious feature addition. I looked and could not find an actual bug report requesting this functionality explicitly, so I opened one: http://projects.puppetlabs.com/issues/7272 On Apr 27, 2011, at 2:54 PM, Ohad Levy wrote: On Thu, Apr 28, 2011 at 12:17 AM, Jake - USPS jacob.m.mcc...@usps.gov wrote: OK, just had to post this! I found a solution to my issues that may help others. http://glarizza.posterous.com/managing-puppet-ssl-certificates fyi - as the original author of that script... the same functionality exists within foreman. Ohad Basically a CGI script located on you CA Server. You can pass the hostname/certname that you want to clean via http to the script and have it clean it off the CA Server. More details in the link above. This is working great for me and I'll be using it until similar functionality is included by default in puppet. Regards, Jake On Apr 14, 8:50 am, Jake - USPS jacob.m.mcc...@usps.gov wrote: Nevermind, looks like its in 2.7.0rc1 http://groups.google.com/group/puppet-users/browse_thread/thread/b3b5... cb01221 (#3360) Add an allow_duplicate_certs option On Apr 14, 8:45 am,Jake-USPSjacob.m.mcc...@usps.gov wrote: Thanks for the reply. I'm just starting to understand puppet, so I would like not to mess with that ... yet. It does look very interesting though, so thanks for bringing that up. Derek, Thanks for the bug. That looks like it includes some things that I would like ... like the allow duplicate cert and whatnot. It looks like its status closed as of 14 hours ago. Does that mean it is in some release of puppet now, or just that code it ready to eventually be implemented? I'd like to start trying it out right away as my 'solution' doesn't seem to work well with dashboard. Thanks, Jake On Apr 14, 8:41 am, Ohad Levy ohadl...@gmail.com wrote: On Thu, Apr 14, 2011 at 4:31 PM,Jake-USPSjacob.m.mcc...@usps.govwrote: Also, what is foreman and how could it help. Not familiar with that product. Foreman takes care for the entire process, things like provisioning, class assignments and reportings are all done though it (and many many other features). see http://theforeman.orgformoredetails. Ohad -- 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 athttp://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 athttp://groups.google.com/group/puppet-users?hl=en. -- You received
[Puppet Users] Re: Deploy puppet via NFS?
Interesting information. Thanks Mohamed and Dominic for this info. Our setup is all local. In the case of an NFS mount - I don't know how easy it would be to tell puppet to look at the NFS mount, instead of /etc/sysconfig, etc., for it's info. In any event, you will still need to have a local /etc/init.d/puppet script. So why bother trying to store the localized items on NFS... ? On Apr 29, 12:14 pm, Dominic Maraglia domi...@puppetlabs.com wrote: On 4/28/11 11:57 AM, Forrie wrote: Thanks for the feedback. It will make life a lot easier if I can deploy/maintain puppet via a RO NFS mount point. I presume you have the local stuff like /etc/ init.d/puppetmaster /etc/sysconfig/puppet /etc/puppet/puppet.conf managed separately and located on each system? Correct. I thought it might be interesting to have the configs on NFS, but I don't know if that would scale very well. I think this is possible, depending on the installation. Some Puppet customers have deploy Puppet world wide, cross continents, where the stateless nature of NFS would not provide a suitable solution. For smaller/geographically confined environments, a single source deployment/management method might be worth researching. Regards, Dominic Thanks! On Apr 26, 8:13 pm, Dominic Maragliadomi...@puppetlabs.com wrote: Hello, On 4/25/11 2:13 PM, Forrie wrote: How do you handle the *.rpm prerequisites of puppet itself. If one installs (deploys) puppet on an NFS mount, presumably you would also include enterprise-ruby (or standard) with those dependencies there. Enterprise Ruby seems to have rolled their own rpms, prefixed with pe-. Actually, we (Puppet) do not package Enterprise Ruby; however, we do package Ruby 1.8.7 and do indeed name the rpm pe-ruby. This is done to differentiate the Puppet stack Ruby from a possible pre-installed vendor Ruby. Puppet Enterprise's (pe) Ruby binary can be found here /opt/puppet/bin/ruby On 4/26/11 12:55 PM, Forrie wrote: I was referring to the RPMs that ship with Enterprise Puppet -- I haven't poked through the code, but if they get installed into the system, then that would pretty much negate (or make more difficult) creating an NFS-deployed Puppet for use. We have not specifically tested a single shared deployment as described by Mohamed (below). We do support and test installation, on all our supported operating systems, from a RO NFS mount point. Cheers, Dominic Maraglia Puppet Labs On Apr 25, 9:43 pm, Mohamed Lrhazilrh...@gmail.com wrote: Sorry ignore my last statement... I did not use REE on Solaris, but used OpenCSW which packages all the software to go under /opt/csw, including ruby and puppet, and makes it straightforward to share the whole /opt/csw readonly over NFS I still think REE with facter and puppet in one directory should be work fine too. Thanks, Mohamed, -- 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: Resolving/ Expanding module puppet:/// URI in exec line
Hi Martin,
Have tried this out and have noticed that the copied .gz file is left
in /usr/share/java after unpacking. I tried adding another file
resource to delete it but because this points to the same filepath as
the initial resource puppet disallows it:
Example below:
class apache-maven-v3 {
require java-app-base
# copy file from puppet master to local system
file { 'copy_maven_v3':
path = /usr/local/java/apache-maven-3.0.3-bin.tar.gz,
source = puppet:///modules/apache-maven-v3/apache-maven-3.0.3-
bin.tar.gz,
}
# extract local file
exec { 'install_maven_v3':
command = /bin/tar zxf /usr/local/java/apache-maven-3.0.3-
bin.tar.gz,
cwd = /usr/local/java,
creates = /usr/local/java/apache-maven-3.0.3,
}
#delete copied archive
# Puppet disallows this...
file { 'delete_copied_archive':
path = /usr/local/java/apache-maven-3.0.3-bin.tar.gz,
ensure = absent,
}
# make sure the order is set properly
File['copy_maven_v3'] - Exec['install_maven_v3'] -
File['delete_copied_archive']
}
gives the following error:
Could not run Puppet configuration client: Cannot alias
File[copy_maven_v3] to [/usr/local/java/apache-maven-3.0.3-
bin.tar.gz]; resource [File, [/usr/local/java/apache-maven-3.0.3-
bin.tar.gz]
] already exists
Is there an elegant puppetesque way of dealing with this? I'm trying
to avoid resorting to exec commands if possible!
Cheers,
Edd
On May 3, 10:45 am, Martin Alfke tux...@gmail.com wrote:
Hi Edd,
here is an example:
class apache-maven-v3 {
# prepare local filesystem
file { 'java_path':
path = /usr/local/java,
ensure = directory,
}
# copy file from puppet master to local system
file { 'copy_maven_v3':
path = /usr/local/java/apache-maven-3.0.3-bin.tar.gz,
source =
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz,
}
# extract local file
exec { 'install_maven_v3':
command = /bin/tar zxf
/usr/local/java/apache-maven-3.0.3-bin.tar.gz,
cwd = /usr/local/java,
creates = /usr/local/java/apache-maven-3.0.3,
}
# make sure the order is set properly
File['java_path'] - File['copy_maven_v3'] - Exec['install_maven_v3']
}
kind regards,
Martin
On 05/03/2011 11:06 AM, Edd Grant wrote:
Hi Nan,
Thanks for the answer - I'm not 100% clear how I could acheive this,
could you expand on your suggestion a little, perhaps with an example?
Would the file resource point at the .gz file in the module? If so how
would I then reference the file resource in the tar command?
Many thanks,
Edd
On May 2, 4:15 pm, Nan Liu n...@puppetlabs.com wrote:
Use a file resource to deploy it to the agent and make the exec depend
on the file resource.
On May 2, 2011, at 7:58, Edd Grant e...@eddgrant.com wrote:
Hi All,
I have defined the following module to untar/unzip and copy the Maven
distributable to a convenient location:
class apache-maven-v3 {
exec { /bin/tar xzf /etc/puppet/modules/apache-maven-v3/files/
apache-maven-3.0.3-bin.tar.gz:
cwd = /usr/local/java,
creates = /usr/local/java/apache-maven-3.0.3,
}
...
}
The above definition executes perfectly however in order to keep the
module portable I want to replace the absolute path to the .gz file
with a puppet:/// URI e.g.
exec { /bin/tar xzf
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz:
When I change the class to use the puppet:/// URI I get the following
error:
(/Stage[main]/Apache-maven-v3/Exec[/bin
/tar xzf
puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz]/return
s) change from notrun to 0 failed: /bin/tar xzf
puppet:///modules/apache-maven-v
3/apache-maven-3.0.3-bin.tar.gz returned 2 instead of one of [0] at /
etc/puppet/
modules/apache-maven-v3/manifests/init.pp:11
It appears to me that the puppet:/// URI is not being resolved in the
exec and this is causing the tar command to operate on the literal
path puppet:///modules/apache-maven-v3/apache-maven-3.0.3-bin.tar.gz
which of course doesn't exist.
Looking at the docs I can't see any examples of puppet:/// being used
in this way, is there anyway I can obtain the resolved absolute path
to pass this in to my exec? Failing that it there a standard approach
for combining a puppet:/// URI with an exec?
Cheers,
Edd
--
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
athttp://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
Re: [Puppet Users] Git Workflow
We have a single master branch and then check various branches out into dev. I wrote up an article about how our env works a few months back. It may be useful to look at. https://cwebber.ucr.edu/2011/03/multiple-environments-in-puppet/ My guess is that eventually we will have multiple dev environments to allow different things to go on at once. --cwebber On 5/3/11 9:16 AM, Stefan Schulte stefan.schu...@taunusstein.net wrote: Hi, I would like to know how your workflow looks like when you're writing manifests. Currently we have the following construct: * 1 git repository with all modules * 3 git branches: dev, staging, prod * 3 puppet environments: dev, staging, prod The modulepath of each environment is a checkout of the corresponding branch. Writing/Editing manifests only happens in dev. If you're done you commit your work to a central repo. If dev is somewhat stable it is merged into staging (fast-forward-merge) etc. This comes with a few problems: * If all your systems are running prod and you change something big (e.g. new filesystem layout) you only have too options: Change all your machines to follow the new standard or take the machines you cannot change out of puppet control. * There are changes I make in dev that I want to take immediate effect. Example: Deploy the SSH-Key of a new employee to all machines. I can add the key in dev and then cherry-pick the commit in the other branches but I'm not yet sure if that is really a good idea. So how do you use environments and branches? One Repository for each module or one repository for all modules? Do you use git tag to tag certain revisions? Do you run your servers agains different releases of your manifests or do you just have one prod environment? -Stefan -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Git Workflow
On 05/03/2011 09:16 AM, Stefan Schulte wrote: Hi, I would like to know how your workflow looks like when you're writing manifests. Currently we have the following construct: * 1 git repository with all modules * 3 git branches: dev, staging, prod * 3 puppet environments: dev, staging, prod The modulepath of each environment is a checkout of the corresponding branch. Writing/Editing manifests only happens in dev. If you're done you commit your work to a central repo. If dev is somewhat stable it is merged into staging (fast-forward-merge) etc. This comes with a few problems: * If all your systems are running prod and you change something big (e.g. new filesystem layout) you only have too options: Change all your machines to follow the new standard or take the machines you cannot change out of puppet control. * There are changes I make in dev that I want to take immediate effect. Example: Deploy the SSH-Key of a new employee to all machines. I can add the key in dev and then cherry-pick the commit in the other branches but I'm not yet sure if that is really a good idea. So how do you use environments and branches? One Repository for each module or one repository for all modules? Do you use git tag to tag certain revisions? Do you run your servers agains different releases of your manifests or do you just have one prod environment? I'd recommend one repository per module. I don't use tags at all. Changes are introduced into the development branch and get merged into the production branch. Differences between servers are typically handled within the module classes (i.e. subclass/conditionals/selectors) rather than having them run against different versions of the module. I can't see how you could keep a sane environment otherwise. -- Russell A Jackson r...@csub.edu Network Analyst California State University, Bakersfield -- 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] Could not evaluate: Cannot write SSH authorized keys without user
On Tue, May 03, 2011 at 10:19:30AM -0700, richard jacobsen wrote:
I just installed puppet on an ubuntu natty narwhal desktop and I'm
getting the following error on one of my puppet classes:
notice: //myclass/Ssh_authorized_key[adminuser]/ensure: created
err: //myclass/Ssh_authorized_key[adminuser]: Could not evaluate:
Cannot write SSH authorized keys without user
ssh_authorized_key { adminuser:
ensure = present,
key = blahblah,
name = adminusername,
target = /root/.ssh/authorized_keys,
type = ssh-rsa
}
This same bit works fine on ubuntu lucid, and debian squeeze. Any
ideas what could be wrong? I checked and the root user is indeed in
both /etc/passwd and /etc/shadow.
Thanks,
Richard
The ssh_authorized_key type has a user property. This is used to chown
the authorized_key file to the correct user.
so the follwing should work:
ssh_authorized_key { adminuser:
ensure = present,
key= blahblah,
name = adminusername,
target = /root/.ssh/authorized_keys,
type = ssh-rsa,
user = 'root', ## added line
}
Actually the target property is now redundant because if you dont set the
target, it will default to ~user/.ssh/authorized_keys.
Puppet may try to guess the user if you dont specify it (like reading
the owner of the target, i dont know) but in your cased failed.
But as long as you have your keys in the normal directory, I would
always specify user instead of target because it is more readably (at
least in my opinion)
-Stefan
pgpHX7z8g1H4z.pgp
Description: PGP signature
[Puppet Users] templates on puppetmaster, shipped via scp to clients
Hi folks, I can't run puppet client on my nodes. I want to fake facter info to process templates and ship them via scp to my nodes. Is it possible? Strategies? This work will be utilized later in a proper Puppet setup, as the ports will open up and I will be able to run the puppet client from the node, as per normal puppet config. Any hints? HOWTOs? Many thanks, -judd -- 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: Force resigning of existing certificates
On Tue, May 3, 2011 at 9:29 PM, Jake - USPS jacob.m.mcc...@usps.gov wrote: Thanks for the response. I found it in the genconf now. Looks like default is 5y. I'll be changing it for my needs. note that the CA itself is signed for 5 years too... (and it seems that the CRL as well - which is wrong). Ohad Thanks! Jake On May 3, 12:53 pm, Matt Wise w...@wiredgeek.net wrote: the ttl setting is 'ca_ttl' i think in puppet.conf.. and yes, you'll ultimately need to re-sign the certs for clients when they expire. the default is 1 year though, so it[ll be a while. On Apr 29, 2011, at 10:32 AM, Jake - USPS wrote: Yea, I'm new to puppet ... sounds like now I have to worry about certs eventually expiring and regenerate/sign them to keep nodes happy? Seems Trevor suggests increasing TTL. How can I do this if I wanted to? Thanks, Jake On Apr 28, 9:30 am, Matt Wise w...@wiredgeek.net wrote: Unfortunately, this is still a 'missing feature' of Puppet IMO. I applaud Foreman for adding it as functionality though in their own code. For our situation, we ended up writing our own CGI script on the Puppet CA servers as well as a client-side script that runs periodically on the clients to verify whether or not their cert is still valid. When their cert gets close-to-expiring, it checks in with the CGI script and supplies the original CSR that the host used for its first cert request to puppet. Our CGI script then has permissions to run some openssl commands, and generates a whole new cert for the client and passes it back. This all happens over SSL of course, and is only allowed for clients that still have a valid certificate anyways. Its not pretty, but its how we solved the problem... and its worked so far. We have ~600 hosts and they each get a new cert every 25 days. Ideally there would be this functionality built into puppet... when a client checked in, the server would check if the cert is within X days of expiring. If it is, it would generate a new cert and pass it back to the client automatically. Of course this would be an 'option', but it seems like an obvious feature addition. I looked and could not find an actual bug report requesting this functionality explicitly, so I opened one: http://projects.puppetlabs.com/issues/7272 On Apr 27, 2011, at 2:54 PM, Ohad Levy wrote: On Thu, Apr 28, 2011 at 12:17 AM, Jake - USPS jacob.m.mcc...@usps.gov wrote: OK, just had to post this! I found a solution to my issues that may help others. http://glarizza.posterous.com/managing-puppet-ssl-certificates fyi - as the original author of that script... the same functionality exists within foreman. Ohad Basically a CGI script located on you CA Server. You can pass the hostname/certname that you want to clean via http to the script and have it clean it off the CA Server. More details in the link above. This is working great for me and I'll be using it until similar functionality is included by default in puppet. Regards, Jake On Apr 14, 8:50 am, Jake - USPS jacob.m.mcc...@usps.gov wrote: Nevermind, looks like its in 2.7.0rc1 http://groups.google.com/group/puppet-users/browse_thread/thread/b3b5... cb01221 (#3360) Add an allow_duplicate_certs option On Apr 14, 8:45 am,Jake-USPSjacob.m.mcc...@usps.gov wrote: Thanks for the reply. I'm just starting to understand puppet, so I would like not to mess with that ... yet. It does look very interesting though, so thanks for bringing that up. Derek, Thanks for the bug. That looks like it includes some things that I would like ... like the allow duplicate cert and whatnot. It looks like its status closed as of 14 hours ago. Does that mean it is in some release of puppet now, or just that code it ready to eventually be implemented? I'd like to start trying it out right away as my 'solution' doesn't seem to work well with dashboard. Thanks, Jake On Apr 14, 8:41 am, Ohad Levy ohadl...@gmail.com wrote: On Thu, Apr 14, 2011 at 4:31 PM,Jake-USPSjacob.m.mcc...@usps.gov wrote: Also, what is foreman and how could it help. Not familiar with that product. Foreman takes care for the entire process, things like provisioning, class assignments and reportings are all done though it (and many many other features). see http://theforeman.orgformoredetails. Ohad -- 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 athttp:// 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
Re: [Puppet Users] Git Workflow
On Tue, May 3, 2011 at 9:46 PM, Stefan Schulte stefan.schu...@taunusstein.net wrote: So how do you use environments and branches? It should be worth looking at http://hunnur.com/blog/2010/10/dynamic-git-branch-puppet-environments/ . Very flexible and useful approach. -- 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] at which size to use a real webserver
On Tue, May 3, 2011 at 9:00 AM, joel.merr...@gmail.com joel.merr...@gmail.com wrote: On Tue, May 3, 2011 at 11:21 AM, Andreas Kuntzagk andreas.kuntz...@mdc-berlin.de wrote: 1. minimal Ubuntu install using pxeboot with preseed file (from web-URL) I use FAI personally, which enables me to automatically include the puppet client and kick the 1st run. You could achieve the same thing with preseed, kickstart etc.. I also use the debianized packages as gems are a little more difficult to use when bootstrapping imho. I also use passenger for *everything* (even testing). It's really simple to setup, http://m.etrono.me/posts/5-simple-ish-puppet-infrastructure - a hell of a lot of this could be puppetified, granted.. -- $ echo kpfmAdpoofdufevq/dp/vl | perl -pe 's/(.)/chr(ord($1)-1)/ge' -- 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. Hi Andreas, Deploying with scaling in mind is the best route at onset. You'll then be able to load test, debug and evaluate _before_ you reach the wall. Which in these days of virtualization can happen between morning and afternoon. -- Cheers, Steven --- Steven Acres UNIX/Linux System Administrator -- 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] chicken and the egg.. pushing custom facter plugins for use within puppet..
Hi,
I've created a number of custom facts that i've added to manifests. If
i add the custom fact, have puppet push the custom fact file to the
host, then after it's pushed it add it to the templates everything
works fine. However if i try and use the module on a fresh host
without the custom facter it fails. When it looks at the templates it
isn't aware of the custom fact yet and errors out.
How can i get it to pull down the facter plugin before it tries to
read the template file?
I have tried:
file {
/etc/somefile:
owner = root,
group = root,
mode= 644,
require = File[/usr/lib/ruby/1.8/facter/custom_fact.rb],
content = template(module/etc/somefile);
}
Any suggestions? I'd prefer not to have to add the custom facter to
the kickstart/jumpstart enviroment.
--MD
--
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] chicken and the egg.. pushing custom facter plugins for use within puppet..
On Tue, May 3, 2011 at 10:04 PM, Michael Dodwell
michael.dodw...@gmail.com wrote:
Hi,
I've created a number of custom facts that i've added to manifests. If
i add the custom fact, have puppet push the custom fact file to the
host, then after it's pushed it add it to the templates everything
works fine. However if i try and use the module on a fresh host
without the custom facter it fails. When it looks at the templates it
isn't aware of the custom fact yet and errors out.
How can i get it to pull down the facter plugin before it tries to
read the template file?
I have tried:
file {
/etc/somefile:
owner = root,
group = root,
mode = 644,
require = File[/usr/lib/ruby/1.8/facter/custom_fact.rb],
content = template(module/etc/somefile);
}
Any suggestions? I'd prefer not to have to add the custom facter to
the kickstart/jumpstart enviroment.
This is solved with pluginsync option. Puppet will download any custom
facts/providers, so you should not distribute them to the agent as
file resources.
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] at which size to use a real webserver
On Tue, May 3, 2011 at 3:21 AM, Andreas Kuntzagk andreas.kuntz...@mdc-berlin.de wrote: Hi, I'm currently using puppet with the buildin server for testing on a few nodes (~5). But in the future my installation will be bigger. It will have about 110 nodes of our compute cluster and maybe some additional servers (~20). Currently I don't use very complicated manifests and want to manage only a few config files, nfs mounts and the list of installed packages. But maybe this list will grow with my love for puppet. Should I already plan on using a different server? What would you recommend? I will be using apache on one headnode anyway for ganglia nagios. Should I also move puppet to apache? How complicated is this? I'm not familar with Ruby or Rails. Agree with Steven, you should consider apache/passenger: http://projects.puppetlabs.com/projects/1/wiki/Using_Passenger On Ubuntu, you can heck if puppet-passenger package is available, and reference the page above if you have any troubleshooting issues. 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] augeas slooow
From a previous email of let...@repeat.com.
...
To avoid that, I added 'lens' and 'incl' parameters to the puppet type a
while ago. If you set these, Augeas will only read a specific file, avoiding
most of the unnecessary overhead.
So, you should say something like
augeas {
add_a_host:
changes = ...,
lens = Hosts.lns,
incl = /etc/hosts
}
in your manifests, and everything will be lightning fast, even without
connection caching.
On May 3, 2011 11:45 AM, Dominic Cleal dcl...@redhat.com wrote:
--
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.
