Re: [Puppet Users] When running puppetd on client get an error
On Thu, 28 Jul 2011, Shiradz wrote: info: Caching catalog for x01.com info: Applying configuration version 'svnver=-1:9644M t=131120' What does the 'svnver=-1:9644M' mean? Trying to understand why the svnver is wrong? The version string is printed by a script that's referenced from the puppet.conf file on the master. Look at what that script is doing, and try running the same or similar commands by hand. --apb (Alan Barrett) -- 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] Testing if a puppet class is going to be installed
On Thu, 07 Jul 2011, Keith Minkler wrote: For example, for setting up the proper nagios monitors, you'd want to say something like if this machine has the apache class, then configure apache monitoring It's not feasible I think to put this logic in the apache class, since you'd have to have a way to build up the nagios config file from parts contained in many classes which sometimes are installed together. I would probably use a concatenated file for this. Define a function in the nagios class that means please monitor this service using these parameters, and let the apache class call that. Behind the scenes, the nagios class would use concat and concat::fragment to do the work. See http://www.devco.net/archives/2010/02/19/building_files_from_fragments_with_puppet.php for an example. --apb (Alan Barrett) -- 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] Trying to write a visudo checker
On Thu, 03 Mar 2011, Rich Rauenzahn wrote: It seems someone got clever and decided to look at exec's and look for managed filenames in argument lists and create implicit dependencies from them? Argh! Yes, the unwanted dependencies are very annoying. Using file names like /dir/subdir/./file instead of /dir/subdir/file is enough to fool the code that adds implicit dependencies. --apb (Alan Barrett) -- 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] External node script flagging errors.
On Tue, 01 Mar 2011, Douglas Garstang wrote:
What is the best way to have an external node script that
encounters an error fail? What should it do? Should it return a
non zero exit code to the OS?
Yes. I am almost sure that works. If not, it's a bug.
Maybe it's caching something.
I think the external node classifier is not re-run if the
facts have not changed. There's a feature request to make
it run every time.
However, it would be nice to have the client error out in such
a way that I know there was a problem with the external node
script loading it's info. Anyone?
Something else I have done, and that might suit you, is let the
node classifier script return an almost-empty non-error result,
like this:
---
parameters:
error_message: Something is wrong
classes: []
Then the top-level site.pp can do something like this:
if $error_message {
fail(External node classifier says: $error_message)
}
--apb (Alan Barrett)
--
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] Where to put External Nodes in Multiple Environments?
On Mon, 28 Feb 2011, Douglas Garstang wrote: For those that are using external nodes (as local files) and multiple environments, where do you put the external node files? How is it possible to use external nodes as local files? I was under the impression that node_terminus=exec or node_terminus=ldap were the only ways of using external nodes. Ie, do you put them down in the environment itself /etc/puppet/env/env1/manifests/extdata/nodes /etc/puppet/env/env.../manifests/extdata/nodes /etc/puppet/env/envN/manifests/extdata/nodes OR, up above the environments? /etc/puppet/manifests/extdata/nodes I don't do this, obviously, because I didn't know it was possible. However, I'd probably be inclined to store the data in an environment-specific directory. --apb (Alan Barrett) -- 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] Where to put External Nodes in Multiple Environments?
On Mon, 28 Feb 2011, Douglas Garstang wrote: How is it possible to use external nodes as local files? I was under the impression that node_terminus=exec or node_terminus=ldap were the only ways of using external nodes. Really? That might be because everyone seems to be on the LDAP external node bandwagon. You can put a external_nodes = script in your puppet.conf file, where script is a script that does whatever it needs to read the local files and dump the output in YAML format. Oh, so you are using an external node classifier script in the usual way, with node_terminus = exec; you are just using unusual terminology to describe it. Puppet knows nothing about external nodes as local files; all it knows is that you have an external node classifier script. The question about where to put the data files used by your script still stands, of course, and I would still probably put them under an environment-specific directory. Yeah, but then you have the problem of not knowing what environment the node is in, and you have to go digging around for it. The more environments you have, the more places you have to dig. I have an external node classifier script whose sole task is to go digging in multiple environment-specific directories to figure out which environment a client node belongs to. --apb (Alan Barrett) -- 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] external_nodes setting with Environments
On Wed, 23 Feb 2011, Douglas Garstang wrote: So... in puppet.conf on the puppet master, there's the external_nodes setting, which defines the location of the external nodes script. If I am using multiple environments, I guess I have to have ONE set of external nodes since external_nodes in puppet.conf is set ONCE, right? If you are using an external_nodes script, then you have to have exactly one such script. The script can be as complex as you like, and it can certainly do different things for different environments (once it figures out which environment a node belongs to). I don't know what you mean by set of external nodes; if you are referring to some sort of data that is used by the external_nodes script, then obviously it depends on how the script is written. --apb (Alan Barrett) -- 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] ssh_authorized_key runs every time
On Wed, 23 Feb 2011, mark risher wrote:
ssh_authorized_key { $username:
ensure = present,
key = abcdefghijklmnop_very_long_string,
You don't have the 'user' or 'type' parameters. Perhaps that's
related to the problem.
--apb (Alan Barrett)
--
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] Do people walk the filebucket tree searching by path?
On Thu, 17 Feb 2011, Nigel Kersten wrote: https://projects.puppetlabs.com/issues/6353 Our old behavior was that when files were backed up to a filebucket, we also wrote out the path information to the 'paths' file in the checksum directory. Do people actually use this functionality? Our sanctioned interface puppet filebucket only ever restored files by checksum, not by path, but from the wiki and some tickets it looks like we do have users who construct find/exec commands to search by path. Yes, I have often searched the filebucket for a path of interest. In theory, the checksum I need is available from a report, but in practice the report may not be readily available. Questions like find all the saved versions of this file are much more easily answered by searching the actual content of the filebucket than by searching all old logs back to the beginning of time. --apb (Alan Barrett) -- 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: Configuration not applied, Finished catalog run in 0.01 seconds
On Wed, 26 Jan 2011, Daniel Pittman wrote: I would love to create a bug for this, because silently is a bad thing: we should either work, or complain about not working, not just silently ignore anything. See issue #4690 and issue #3514. --apb (Alan Barrett) -- 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] Silence reports for one specific resource?
On Fri, 07 Jan 2011, Patrick wrote:
On Jan 6, 2011, at 10:55 PM, Alan Barrett wrote:
I probably wouldn't do this, but:
exec { secret stuff:
command = /bin/false,
unless = do the real work here,
}
I don't know if it's a problem, but this will probably run in noop
mode and noop mode won't do anything except make run failures silent
to you should probably change this by adding noop = false to be
explicit.
Yes, as you imply and as I neglected to state earlier, the unless
command always runs, even in noop mode. If it's successful, then
nothing more happens, and the report indicates that the resource
was in sync.
If the unless command fails in no-noop mode , then the command
command runs, and because the command is /bin/false, thet fails too, and
puppet reports the error.
If the unless command fails in noop mode , then the command command
does not run, but the failure is not completely silent; the report will
show that the resource is out of sync, and in --test or --verbose mode
there will be a log message like Exec[secret stuff] is notrun should be
0 (noop).
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Silence reports for one specific resource?
On Thu, 06 Jan 2011, Mohamed Lrhazi wrote:
I added one resource to all the hosts, which dumps all environment
variables to a file called: /etc/mcollective/facts.yaml
This resource always reports that a change needs to be made, since
that file content is always changing...
How do I silence this resource, so it does not report that every time?
I probably wouldn't do this, but:
exec { secret stuff:
command = /bin/false,
unless = do the real work here,
}
I have a second issue with this new resource... I really would want it
executed each time, and not only when there are other changes in the
pipe and I issue a puppetrun Is there a way to run puppet in noop
mode, excluding one resource from the noop?
exec { run this even in noop mode:
command = whatever,
noop = false, # overrides global noop mode
}
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Managing cronjobs as a file in solaris with appendifnosuchline for specific servers
On Wed, 05 Jan 2011, Nigel Kersten wrote:
define appendifnosuchline($file=, $line=) {
exec { appendline_${file}_${line}:
path= /bin:/usr/bin,
command = /bin/echo ${line} ${file},
unless = grep -qx ${line} ${file},
}
}
appendifnosuchline { ensure_foobar_in_filetest:
file = /tmp/filetest,
line = foobar,
}
That looks to work.
... unless $line begins with - (which will confuse grep or some
versions of echo), or contains space or other shell special characters
(which will confuse the shell), or contains backslash (which is special
to some versions of /bin/echo), or contains regexp secial characters
(which will confuse grep).
Here's my untested attempt:
define appendifnosuchline($file, $line) {
$escaped_line = shellquote($line)
exec { appendline_${title}:
path= /bin:/usr/bin,
command = printf '%s\\n' ${escaped_line} ${file},
unless = grep -qFx -e ${escaped_line} ${file},
}
}
This is untested, and still doesn't handle spaces or shell special
characters in the file name, but it attempts to deal with the other
issues:
* Escape shell special characters in $line;
* Use printf instead of echo to avoid portability problems with
different versions of echo interpreting - or \ differently.
* Use grep -F option to make it search for a fixed string
instead of a regular expression;
* Use grep -e option to avoid problems if $line begins with -;
I also made the $file and $line parameters compulsory, and derived the
title of the exec from the title of the appendifnosuchline instead of
from the file name and line contents (which might be long or ugly).
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Managing cronjobs as a file in solaris with appendifnosuchline for specific servers
On Wed, 05 Jan 2011, Ace wrote: Yes this definitely works although it replaces the file and appends tmp/filetest is a file managed by puppet who's contents are two lines testme and hmm what does this do. The append function appends line works everytime it runs. This is a problem that you were warned about. You have two conflicting rules about the same file; one rule says it must contain exactly two lines, no more and no less -- the two lines must be 'testme' and 'hmm what does this do'; the other rule says it must contain a line that says 'works'. You can't simultaneously satisfy both rules, but puppet tries as hard as it can, removing the works line when it focuses on the file rule, and reinstating the works line when it focuses on the append rule. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] race conditions in using svn update in puppetmaster's /etc/puppet directory?
On Mon, 03 Jan 2011, James Ralston wrote: So, here's my question: if you are currently using the svn update approach to manage /etc/puppet on the puppetmaster, have you taken conscious steps to help avoid a race condition? If so, what are they? And if not, why not? I made a conscious decision not to worry about this. I don't expect any consequences worse than compile errors (when some but not all of a set of mutually-dependent files are updated) or the use of an old version of a file. If it proves to be a problem in practice, then I'll probably use a symlink to switch atomically between two working copies. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Managing cronjobs as a file in solaris with appendifnosuchline for specific servers
On Mon, 03 Jan 2011, Ace wrote: I will be managing the file /var/spool/cron/crontabs/root. I want the cron file to be same across all servers except some servers will have additional cron entries. Since you want to avoid the puppet cron type, I'd suggest using the concat module from https://github.com/ripienaar/puppet-concat. How can I append to the file /var/spool/cron/crontabs/root , something like appendifnosuchline in cfengine? You could probably use augeas for that, if you try hard enough, but I recommend concat. Some of the comments at http://www.devco.net/archives/2010/02/19/building_files_from_fragments_with_puppet.php discuss tradeoffs between concat and augeas. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Documentation of report formats
On Thu, 30 Dec 2010, Paul Berry wrote: Those of you reading puppet-dev may have already noticed that we're making we've documented the changes we're anticipating here: http://projects.puppetlabs.com/projects/puppet/wiki/Report_Format_2 Is there improved support for noop mode? I didn't notice anything like status = out of sync, but did not change due to noop mode. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] # Only restart if we're actually running
On Mon, 20 Dec 2010, Nick Moffitt wrote: With the right harmonics a service could be effectively 99% downtime and ensure = running would prevent me from finding out. The puppet logs would report that the service was being started over and over. I don't use Puppet Dashboard, but perhaps it can do enough log analysis to help? --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Combine multiple CA certificates into a bundle
On Tue, 30 Nov 2010, Ohad Levy wrote: I think you are facing https://projects.puppetlabs.com/issues/3640#note-11 https://projects.puppetlabs.com/issues/3640#note-11which would hopefully be resolved in https://projects.puppetlabs.com/issues/3770. I must admit that I did not have time to continue troubleshooting this further... Thanks. I give up now. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Combine multiple CA certificates into a bundle
I am struggling with using multiple puppet CAs. I think I am missing information about which files are used for which purposes by different parts of puppetmasterd, puppetd, puppetca, and the apache/passenger frontend. I have an old puppetmaster (and CA), which signed certificates for old clients. I want to add a new puppetmaster (and CA) and let it sign certificates for new clients. I want any client (old or new) to be able to work with any master (old or new). I would prefer not to have to set up a centralised CA hierarchy; the self-signed CA certificates would be good enough if I could just figure out how to combine them into usable bundles. It seems to me that I should be able to take the $ssldir/ca/ca_crt.pem files from the two puppetmasters, concatenate them to create a ca-bundle.pem file, and place the bundle in some suitable place where any client or server can use the bundle to verify certificates from any CA. I haven't been able to figure out where that suitable place is. Help? --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Combine multiple CA certificates into a bundle
On Mon, 29 Nov 2010, Alan Barrett wrote: I am struggling with using multiple puppet CAs. I think I am missing information about which files are used for which purposes by different parts of puppetmasterd, puppetd, puppetca, and the apache/passenger frontend. For example, which file on the puppetmaster ends up being copied to $localcacert on the client? Neither of the files referred to by the puppet.conf variables [puppetmasterd].cacert or [puppetmasterd].localcacert seems to be copied to the client. (Running puppet 0.25.5 on all masters and clients.) --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Combine multiple CA certificates into a bundle
On Mon, 29 Nov 2010, Alan Barrett wrote:
It seems to me that I should be able to take the $ssldir/ca/ca_crt.pem
files from the two puppetmasters, concatenate them to create a
ca-bundle.pem file, and place the bundle in some suitable place where
any client or server can use the bundle to verify certificates from
any CA. I haven't been able to figure out where that suitable place
is. Help?
I have a ca-bundle.pem file which contains the concatenation of the ca.pem
files from the two CAs.
I make both cacert and localcacert on the puppetmaster refer to that file:
# extract frmo pupept.conf
[puppetmasterd]
cacert = $ssldir/certs/ca-bundle.pem
localcacert = $ssldir/certs/ca-bundle.pem
The first time I run puppetd on the client it creates
/etc/puppet/ssl/certs/ca.cert with the wrong contents (the cert from
the master that it's talking to atthe moment, not the bundle that I want).
I manually replace the client's /etc/puppet/ssl/certs/ca.cert with a
copy of the bundle.
Now the openssl tests described near the end of
http://projects.puppetlabs.com/projects/1/wiki/Multiple_Certificate_Authorities
work. On the master, I run
cd /etc/puppet/ssl
openssl s_server -Verify 10 \
-cert ./certs/${server_fqdn}.pem \
-key ./private_keys/${server_fqdn}.pem \
-CAfile ./certs/ca-bundle.pem
On the client, I run:
cd /etc/puppet/ssl
openssl s_client -connect ${serevr_fqdn}:4433 -verify 10 \
-cert ./certs/${client_fqdn}.pem \
-key ./private_keys/${client_fqdn}.pem \
-CAfile ./certs/ca.pem # a copy of ca-bundle.pem
and the client successfully connects to the server, and they like
each other's keys and certificates.
If I keep exactly the same openssl s_server running on the pupeptmaster,
and run puppetd instead of openssl s_client on teh client side, it fails.
I run this command:
puppetd --onetime --test --debug \
--server=${server_fqdn} --masterport=4433
and it prints several messages about debug: /File[foo]: Autorequiring
File[bar], then this:
debug: Using cached certificate for ca
debug: Using cached certificate for ${server_fqdn}
debug: Using cached certificate_revocation_list for ca
debug: catalog supports formats [blah blah]; using pson
err: could not retrieve catalog from remote server: \
SSL_connect returned=1 errno=0 \
state=SSLv3 read server certificate B: certificate verify failed
On the server side (the openssl s_server process, not puppet), I see this:
ACCEPT
ERROR
29884:error:14094418:SSL routines:SSL3_READ_BYTES:\
tlsv1 alert unknown ca:s3_pkt.c:1052:SSL alert number 48
shutting down SSL
CONNECTION CLOSED
So, it seems that the puppetd client is doing something different from
the openssl s_client command used for testing. What certificate is
the puppetd client attempting to present, and how can I change that?
There's no apache+passenger in this test, but in reality I would be
using that on the server. This is puppet 0.25.5.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Combine multiple CA certificates into a bundle
On Mon, 29 Nov 2010, Patrick wrote: So, it seems that the puppetd client is doing something different from the openssl s_client command used for testing. What certificate is the puppetd client attempting to present, and how can I change that? Run this on the client for the config puppet is using: puppetd --genconfig I use that all the time. The file names that I passed to openssl s_client are identical to those reported by puppetd --genconfig. Whether or not the clientcrl file (ca_crl.pem) exists seems to have something to do with the problem but I haven't figured out the details. If I delete that file, then the puppetd client can connect, and it downloads a fresh copy of the CRL, after which it can no longer connect. I have configured certificate_revocation=false on the server, but it nevertheless sends the CRL file to the client. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Does puppetmaster knows its own configuration parameters?
On Mon, 01 Nov 2010, Robert Scheer wrote: Is there a way to access the local configuration parameter 'server' within puppet? Or is there another, better solution I am missing? See issue 2807 http://projects.puppetlabs.com/issues/2807. In puppet-2.6, you can say $server = $settings::server In version 0.25, you can say $server = inline_template(%= Puppet.settings[:server] %). --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] noop Out of sync reporting
On Mon, 27 Sep 2010, James Turnbull wrote: I apologise - I thought it was in the Release Notes. There was a lot of content in 2.6.0 and this one must have been missed. It is now: http://projects.puppetlabs.com/projects/puppet/wiki/Release_Notes#Audit+Metaparameter Thanks. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] cucumber-puppet and environments
On Thu, 16 Sep 2010, Bruce Richardson wrote: On Wed, Sep 15, 2010 at 09:31:19PM +0200, Alan Barrett wrote: I use an external node classifier purely for the purpose of setting the environment [...] You're still trusting the client. Yes, for file serving, as I discovered a few messages earlier in this thread, and I don't like that at all. But for compiling the catalog, I do not believe that I trust the client. I have tested with incorrect environments on the client's command line or in the client's puppet.conf, and the server correctly uses the environment from the external node classifier. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] cucumber-puppet and environments
On Fri, 17 Sep 2010, Nigel Kersten wrote:
On Wed, Sep 15, 2010 at 09:31:19PM +0200, Alan Barrett wrote:
I use an external node classifier purely for the purpose of
setting the environment [...]
I have tested with incorrect environments on the client's command
line or in the client's puppet.conf, and the server correctly uses
the environment from the external node classifier.
Are you absolutely positive about this ?
Yes, for puppet 0.25.5.
I just ran /usr/local/sbin/puppetd --onetime --test --noop
--environment=WRONG --tags=notify, and I saw the client perform
GET /WRONG/catalog/host.domain.example?..., but it received
the catalog for the correct environment (and stashed it in
/var/puppet/client_yaml/catalog/host.domain.example), and it performed a
notify whose text contains the correct environment name.
I repeated the test three times, with (1) an environment that does not
exist at all on the server, (2) an environment called UNCONFIGURED,
which is the default as far as puppetmasterd is concerned, and whose
manifest contains not much more than a fail statement, and (3) a
more normal environment that just happened to be incorrect for this
client. I then repeated test (1) (but not the others) by specifying the
incorrect environment in puppet.conf instead of on the command line. I
received identical results every time.
I also know that the server was not trying to trick me by substituting
the correct $environment string into the notify message from the catalog
for some incorrect environment, because all environments contain 'node
default { fail ... }', and the fail as not triggered.
Something that might be relevant here is that my external node
classifier prints this sort of output:
---
parameters:
environment: FOO
whereas somebody told me a few days ago that it's supposed to
put environment at the top level, not inside parameters.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] cucumber-puppet and environments
On Fri, 17 Sep 2010, Nigel Kersten wrote: I just ran /usr/local/sbin/puppetd --onetime --test --noop --environment=WRONG --tags=notify, and I saw the client perform GET /WRONG/catalog/host.domain.example?..., but it received the catalog for the correct environment (and stashed it in /var/puppet/client_yaml/catalog/host.domain.example), and it performed a notify whose text contains the correct environment name. So you're not seeing the mismatch between files and file metadata as described in the bug? Do you have a default modulepath defined that things are falling back to? I haven't tried replicating exactly whats in bug #3910. The tests that I have done so far would not expose the case of files being downloaded from a module in the wrong environment, though I think they would expose catalogs being compiled with a modulepath for the wrong environment. I don't set modulepath at the top level or in the [puppetmasterd] section; it's set only in the environment-specific sections of puppet.conf. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Glassfish asadmin provider
On Wed, 15 Sep 2010, Nigel Kersten wrote:
Does 'type --all asdf' do the right thing on SunOS ?
According to IEEE Std 1003.1, 2004 Edition, type does not take
any options. Anyway, on Solaris-5.8:
for shell in /bin/sh /usr/xpg4/bin/sh /bin/ksh /usr/local/bin/bash ;
do echo [$shell]; ${shell} -c 'type --all asdf; echo status=$?' ;
done
[/bin/sh]
--all not found
asdf not found
status=1
[/usr/xpg4/bin/sh]
asdf not found
status=127
[/bin/ksh]
asdf not found
status=127
[/usr/local/bin/bash]
/usr/local/bin/bash: line 0: type: asdf: not found
status=1
On NetBSD-5.99.27:
for shell in /bin/sh /bin/ksh /usr/pkg/bin/bash ;
do echo [$shell]; ${shell} -c 'type --all asdf; echo status=$?' ;
done
[/bin/sh]
type: Illegal option --
status=2
[/bin/ksh]
/bin/ksh: whence: --: unknown option
status=1
[/usr/pkg/bin/bash]
/usr/pkg/bin/bash: line 0: type: asdf: not found
status=1
I have seen systems where type prints a message about command not
found (or words to that effect) but sets exit status 0 as if it had
been successful. I have found that command -v does the right thing
on the same system. Unfortunately, my notes from the time I noticed
this don't say which system had the problem, but I think it was AIX or
Cygwin.
Compare the POSIX description of the
exit status for type and command at
http://www.opengroup.org/onlinepubs/009695399/utilities/type.html and
http://www.opengroup.org/onlinepubs/009695399/utilities/command.html:
For type exit status 0 means an error occurred, while for command
exit status 0 means the command_name could not be found or an error
occurred.
What I take from the POSIX spec is that one could argue either way about
whether or not it's an error for the type command to report that a
target command does not exist; but for the command -v command it's
clear that nonexistence of the target command should result in non-zero
exit status.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] cucumber-puppet and environments
On Wed, 15 Sep 2010, Nigel Kersten wrote: The external node classifier can override the client's idea of the environment. It can't really. http://projects.puppetlabs.com/issues/3910 I didn't know about that one; my bug in this area is #2834. I use an external node classifier purely for the purpose of setting the environment (and a parameter called $error_message or something, but not any classes). There are minor problems when the master and client disagree, but so far the problems have not been enough to prevent installing a puppet.conf from a template, to make the client specify the correct environment on the next run. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] cucumber-puppet and environments
On Wed, 15 Sep 2010, Nigel Kersten wrote: On Wed, Sep 15, 2010 at 12:31 PM, Alan Barrett a...@cequrux.com wrote: On Wed, 15 Sep 2010, Nigel Kersten wrote: The external node classifier can override the client's idea of the environment. It can't really. http://projects.puppetlabs.com/issues/3910 the environment (and a parameter called $error_message or something, but not any classes). =?0There are minor problems when the master and client disagree, but so far the problems have not been enough to prevent installing a puppet.conf from a template, to make the client specify the correct environment on the next run. I wouldn't class the situation as minor problems I meant to say that the problems I have personally seen have been minor; I haven't noticed the problem you describe, possibly because I deliberately run puppetd with a restrictive tags parameter when I know that the environment is not properly set, or possibly because any incorrect files would have been corrected on the next run, but I agree that issue #3910 is serious. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet use with OLPC's XS
On Wed, 08 Sep 2010, Martin Langhoff wrote:
1 - With a high number of identical nodes, we are very precious about
deploying the exact same sw package (rpm in this case) to all nodes.
Can I declare an exact rpm version/revision in a packages[] section?
Can I later update it with a later version and will it know to upgrade
VIA YUM?
Yes, you can put a version number in the require parameter of a
package resource. As somebody else said, it would be a good idea to
maintain your own package repository.
2 - Can I say install this shellscript and run it once? How?
There's no easy way to do exactly that, but you can easily achieve much
the same result if the script has a way of testing whether its work
needs to be done:
$script = /some/dir/filename
file { $script:
ensure = file,
owner = ..., group = ..., mode = ...,
source = puppet:///wherever,
}
exec { run the script if necessary:
command = $script --really-do-it,
onlyif = $script --check-whether-it-needs-to-be-done,
require = File[$script],
}
2a - Is there an ISConf-like facility that says run it until it
succeeds once? [ Happy to use Makefiles, but if there's a
Puppet-supported elegant way of doing it... ]
Again, no, but there are several alternatives. To run the command
several times per puppet run, you can put a while loop in the command
parameter of a puppet exec resource, or write a wrapper script that
loops. To run a command once per puppet run as long as it keeps
failing, but stop after it has been successful once, can use the
exec/onlyif technique.
I don't want to add anything to the answers others have given to the
remaining questions.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] ANNOUNCE: Puppet 2.6.1 - Release Candidate 2 available!
On Thu, 12 Aug 2010, James Turnbull wrote: http://puppetlabs.com/downloads/puppet/puppet-2.6.1rc2.tar.gz In my brief testing with puppetmasterd --compile, I see performance of 2.6.1rc2 being almost identical to performance of 0.25.5. This is a great improvement over 2.6.0 or 2.6.1rc1, which was about 50% slower than 0.25.5. Thank you! --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Could not retrieve catalog from remote server Duplicate definition
On Wed, 11 Aug 2010, martin kummer wrote: [files] path /etc/puppet/files allow 178.78.72.121 -space here this breaks the puppetmaster silently. this is real bad. this must be a bug. This is puppet bug #3514. It's supposed to be fixed in version 2.6.0. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] variable scoping problems with import
I don't know what I m doing wrong, but I ca't get this to work.
I want some nodes to explicitly set a variable $x, and other nodes
to get a default value. I want to calculate another variable $y
in a different way depending on whether or not $x is set.
## site.pp:
node default {
$x = x set in node
import defs.pp
notify { in node: x=\$x\ y=\$y\: }
}
## defs.pp:
if $x != {
notify { in defs.pp: x WAS ALREADY defined: }
$y = y derived from x in defs.pp
} else {
notify { in defs.pp: x WAS NOT defined: }
$x = x default set in defs.pp
$y = y default set in defs.pp
}
notify { in defs.pp: x=\$x\ y=\$y\: }
## command line:
puppet ./site.pp
## output:
notice: in defs.pp: x WAS NOT defined
notice: //Notify[in defs.pp: x WAS NOT defined]/message: defined 'message' as
'in defs.pp: x WAS NOT defined'
notice: in defs.pp: x=x default set in defs.pp y=y default set in defs.pp
notice: //Notify[in defs.pp: x=x default set in defs.pp y=y default set in
defs.pp]/message: defined 'message' as 'in defs.pp: x=x default set in
defs.pp y=y default set in defs.pp'
notice: in node: x=x set in node y=y default set in defs.pp
notice: //Node[default]/Notify[in node: x=x set in node y=y default set in
defs.pp]/message: defined 'message' as 'in node: x=x set in node y=y
default set in defs.pp'
Why is it seeing $x as undefined, and taking the wrong branch of
the if statement in defs.pp? What can I do differently to make it
do what I want?
If I replace the 'import defs.pp' with an actual copy of defs.pp,
then it works, but I don't want to do that, because it doesn't
scale. I don't particularly want to move the logic to extlookup()
or an external node classifier.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] exec not finding shell builtins/functions?
On Fri, 30 Jul 2010, Daniel Pittman wrote:
Eg, this:
exec { foo: command = ['/bin/ls', '|', 'foo'] }
will pass '|' 'foo' to the ls command, compared to:
exec { foo: command = /bin/ls | foo }
...which passes it to the default system shell.
+1 [I added a missing comma above.]
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: manage_internal_file_permissions, /etc/sysconfig, and/or command line startup...
On Wed, 28 Jul 2010, Tom wrote: Note that you can set =??manage_internal_file_permissions=?? to false to disable this behaviour. So that's what I was trying to do - use manage_internal_file_permissions to disable it. But that doesn't seem to work either, does it? You can't use this from the command line, can you? The command-line equivalent would be --no-manage_internal_file_permissions. Be careful with the hyphens and underlines. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Numerical Comparisons in 0.24.8
On Mon, 26 Jul 2010, Douglas Garstang wrote:
[need to compare two version numbers: 1.18.29-1 and 1.22]
I can't do a pure mathematical comparison because the - is in the
version number. I tried splitting that into two and passing the
version as 1.18.29, but puppet complains about the . you can't
pass a float to a definition?
You can pass a string to a definition. 1.18.29 doesn't look like a float.
This is version 0.24.8 what options do I have?
You can use the versioncmp function. It didn't quite work in puppet
0.24.8, but if you copy lib/puppet/parser/functions/versioncmp.rb from
puppet-0.25.0 then it should work. See issue #2110.
I think you want somethng like this:
if (versioncmp($version, 1.22) = 0) {
# do stuff
}
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Puppet 2.6 Installation
On Tue, 20 Jul 2010, Douglas Garstang wrote: I just grabbed puppet 2.6, and I'm wondering if there's a way to install it to an alternative root location. To install to a different root: ruby ./install.rb --destdir=/tmp/altroot This means that things that belong in /usr/local/lib at run time will be placed in /tmp/altroot/usr/local/lib at install time. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Pushing out all templates in a directory.
On Fri, 16 Jul 2010, Douglas Garstang wrote:
I'm guessing you can't use the content attribute when pushing out all
files in a directory...
file {
/etc/nagios/conf.d:
content = template(nagios/etc/nagios/conf.d),
#source = puppet:///nagios/etc/nagios/conf.d,
recurse = true,
purge = true,
force = true,
ignore = .svn;
}
You can't use content with recursion. You can use source with
recursion. You can also override certain files in a recursively managed
directory:
file { /some/dir:
ensure = directory, recurse = inf,
purge = true, force = true,
source = ...
}
file { /some/dir/subdir/somefile:
ensure = file,
content = template(...),
}
You can also use the hostname or fqdn as part of the name of the source:
source = puppet:///modules/mymodule/somedir.${fqdn}
That's really frustrating. I wanted to easily manage all the nagios
config files, and it looks like I can't now. If I uncomment the source
line, and push our files, it works.
I don't understand how you expected a single template to be able to
populate an entire directory, but if you really need to do this (as
opposed to letting each template create a single file), then I suppose
you could make the template emit some kind of bundle with special
delimiters to separate one embedded file from the next (the moral
equivalent of a tar or shar archive):
file { /stagingarea/bundle:
content = template(...)
}
exec { split bundle into files:
require = /stagingarea/bundle,
command = some script to unpack the bundle from the
staging area and create the files that
you really want,
onlyif = some script to check whether the real files
are out of sync with the bundle,
}
Oh, after writing the above I realised that you probably want a
single template per target file, in the conventional way, but that
you want an easy way of saying all templates in this directory.
You could probably do this using the generate function (to return
a list of files on the puppetmaster), and a definition (to create
one target file per result returned by generate), but I am not
sure of the details.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] External nodes script does not work with multiple environments
On Tue, 13 Jul 2010, Kenneth Holter wrote: So it looks like puppetmaster simply bypass the whole puppet.conf file (or at least the main and puppetmasterd stanzas). I think there was a bug report about puppet.conf being ignored if it contained errors; but I can't find the bug report, and I don't see any errors in your config. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] onlyif for resource type file
On Mon, 28 Jun 2010, Mohamed Lrhazi wrote:
file { /etc/ldap.conf:
owner = root,
group = nscd,
mode= 640,
content = template(gu_auth/ldap.conf.rb),
onlyifnot = grep -E '^PUPPET ME NOT' '/etc/ldap.conf',
}
onlyif doesn't work on file resources, but see bug #651.
For now, you can fake it like this:
file { /etc/ldap.conf.puppet:
owner = root,
group = nscd,
mode= 640,
content = template(gu_auth/ldap.conf.rb),
}
exec { update /etc/ldap.conf:
command = cp /etc/ldap.conf.puppet /etc/ldap.conf,
unless = grep -E '^PUPPET ME NOT' /etc/ldap.conf,
}
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Variable Scoping = Root Canal
On Mon, 28 Jun 2010, Douglas Garstang wrote:
node 'node1.fr.xxx.com' {
$facility_name = sjc
include ldap::client
Not gonna work. It's pointless to define the facility at the node level.
You have to set the facility name somewhere. If not at the node level,
then where?
Also, if you were willing to put include facility::sjc at the node
level, then why is $facility_name = sjc any worse?
I am unlikely to help you any further, unless there's a dramatic
improvement in your attitude, and your ability to adapt examples to your
own use cases.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Installing several packages in order
On Wed, 16 Jun 2010, Roy Nielsen wrote:
I've got a file resource that makes sure a specific directory tree
is created..
$dirs = [/var, /var/lanl, /var/lanl/puppet]
@file { $dirs :
ensure = directory,
owner = root,
group = wheel,
mode = 755,
links = follow,
}
Puppet automatically makes each file depend on its parent directory, so
your exmple should work.
I would think that setting up a $packages array in the right order
and doing something like:
package{ $packages :
ensure = present,
}
No, that won't install the packages in any specific order. There are no
explicit or implicit dependencies between apckages in your example, but
in my case I want each package to explicitly depend on its predecessor
in the array.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Installing several packages in order
On Wed, 16 Jun 2010, Thomas Bellman wrote: in my case I want each package to explicitly depend on its predecessor in the array. How about this: Thank you! I would eventually have written something involving two defines calling eack other, with inline_template to munge the arguments, but I would probably not have found such a simple solution, and I had not yet started writing the code. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Installing several packages in order
I have some software with a list of patches that need to be installed in
order. Different hosts want different patches (e.g. development hosts
get patches that are not yet ready for production).
Obviously I can do this:
package { basepackage:
ensure = present,
}
package { patch1:
ensure = present,
require = Package[basepackage],
package { patch2:
ensure = present,
require = Package[patch1],
}
package { patch3:
ensure = present,
require = Package[patch2],
}
but I'd like to do something like this:
$package_list = [basepackage, patch1, patch2, patch3]
# The above value would actually come from extlookup()
install_packages_in_order { title:
package_list = $package_list
}
define install_packages_in_order($package_list) {
...insert code here...
}
or with alternating package names and version numbers:
$package_list = [basepackage, 1.2.3,
patch1, 1.2.3.0.1,
patch2, 1.2.3.0.2,
patch3, 1.2.3.0.3]
I think I can make this work using some ugly code inside
inline_template, or maybe writing my own parser functions,
but does anybody have any easier suggestions?
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Unable to use custom type loaded from module
On Tue, 15 Jun 2010, Nigel Kersten wrote: I dislike setting a default modulepath, as it means that's the one clients get if they incorrectly specify their environment. I mitigate that by also doing manifestdir = /dev/null manifest = /dev/null/site.pp Are you using an external node classifier? I thought that when I deployed a classifier it stopped that trick from working... but I could be wrong. I use an external node classifier, in conjunction with settings like this: [puppetmasterd] environments = UNCONFIGURED,list,of,good,environments environment = UNCONFIGURED manifestdir = /etc/puppet/UNCONFIGURED # modulepath and manifest not set at this level [UNCONFIGURED] manifest = /etc/puppet/UNCONFIGURED/site.pp modulepath = /etc/puppet/UNCONFIGURED/empty-directory UNCONFIGURED/site.pp contains little more than a fail statement. My external node classifier forces environment = UNCONFIGURED for any client that it doesn't know about. I found that setting manifestdir to something that did not exist caused puppet to create it. I didn't try /dev/null, but I'd be afraid of puppet converting it from a device to a directory. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Unable to use custom type loaded from module
On Tue, 15 Jun 2010, Nigel Kersten wrote: UNCONFIGURED/site.pp contains little more than a fail statement. My external node classifier forces environment = UNCONFIGURED for any client that it doesn't know about. You're not actually doing any work in this environment though are you? No. The fail statement in site.pp causes an error message on the client, and nothing more happens until the configuration is fixed. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Input sought on changing default vardir on OS X.
On Wed, 09 Jun 2010, Nigel Kersten wrote: 0.25.5 changed the default vardir from /var/puppet to /var/lib/puppet and it's caused the odd issue we have to fix in the Mac pkg preflights. After re-reading 'man hier' I'm tempted to change the default on OS X to: /var/db/puppet instead. Yes, /var/db/puppet seems to fit much better on BSDish systems. I dislike /var/lib/puppet because the things in there are not libraries. Maybe it's some sort of Linux standard, but that doesn't make it right. Anyway, it's OK for the default installation to use any directories it likes, provided it's easy to change at build time (and it is easy enough). --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] undefined method 'to_sym' for [var, var]:Array
On Mon, 07 Jun 2010, Jay Christopherson wrote: err: Could not parse for environment DR: undefined method `to_sym' for [ENV1, ENV2]:Array The environment variable is part of the LDAP node definition and in this case, the node in question belongs to two different environments and so has two environment attribute entries The concept of an environment is built in to puppet; see http://docs.puppetlabs.com/guides/environment.html. A node in puppet must always be in exactly one environment, so setting puppet's environment variable to an array is an error. I don't know how you could prevent the LDAP environment variable from being copied to the puppet environment variable, or prevent the LDAP server from reporting the value of that variable, but perhaps you could rename the LDAP variable? --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: External Nodes Examples
On Sun, 06 Jun 2010, Douglas Garstang wrote:
I was just doing a little research on the best way to switch over to
external nodes. It seems like you can't use a combination of the two
systems.
I assume that the two systems means (1) an external node classifier,
and (2) node {...} definitions in site.pp ir something inclided by
site.pp
Apparently if the external node tool can't find an external
node (because it hasn't been cut over yet), then that's a failure.
This makes moving from 'internal' nodes to external nodes BLOODY
difficult.
I don't understand this problem description. When your external node
tool can't find a node, what does it do? If it exits with a non-zero
status, then that's a failure. If it prints something that's not
properly formed YAML, then that's probably a failure. But if it prints
some properly-formatted YAML that represents an empty list of classes
and an empty list of variables, then everything should work just fine.
For example, print this (without the indentation):
---
parameters: {}
classes: []
Puppet will merge this empty list of classes and empty dictionary of
parameters with whatever it gets from relevant node{} definitions
in site.pp.
Taking that into account, here's how I'd suggest that you switch over
from having everything in node definitions to having everything in an
external node classifier.
1. When you start, you have everything in node definitions in site.pp (or
in something included by site.pp), and (this is important) you do NOT
have a default node definition:
node foo {
$var = value for node foo
include someclass
include anotherclass
}
node bar {
$var = value for node bar
include someclass
include a_different_class
}
2. Create an external node classifier that always prints the
well-formed but nearly empty YAML described above, and hook the node
classifier into puppet.conf. Test. At this point, you haven't cut any
nodes over to the external node classifier, but you have the ability to
cut nodes over one by one.
3. Teach your external node classifier that, if the hostname is
foo, it should print the following YAML (without the indentation):
---
parameters:
var: value for node foo
classes:
- someclass
- anotherclass
4. Remove the definition of node foo from site.pp. Test. At this
point, you have cut node foo over from being defined in site.pp to being
defined in the external node classifier, but node bar is still defined
in site.pp.
5. Continue cutting nodes over as fast or as slowly as you like, until
you have done them all.
And a certain person, who shall remain nameless, seems somewhat
detached from reality, when his response to that issue was: Then add
support for a default node.
As far as I understood it, that person was pretty well attached
to reality, was talking about a default node in the external node
classifier (not in site.pp), and was giving essentially the same advice
as am giving in this message.
Just how is that going to help? If you define a default external node,
the error will go away, but since your internal node is now defined
as a default external node that does nothing, any future changes to
the internal nodes until they are cut over and going to be ignored.
Nice... nice...
I am sorry, but I still don't see how the problem that you envisage
would arise. I think I know what a default external node that does
nothing is (it's basically the almost-empty YAML that I mentioned
above), but I don't know how or why you'd have an internal node
definition that referred to the empty external node definition, and I
don't know why you think future changes to node definitions in site.pp
would be ignored. Please explain your concerns (or the results of your
expsriments) in more detail.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: External Nodes Examples
On Sun, 06 Jun 2010, Ashley Penney wrote:
This is currently killing me too. I also heavily used definitions in
nodes for things that didn't really seem to belong in modules (one
offs, mount points for admins to rummage around on the command line,
the odd tweak here and there) and the inability to slowly migrate into
an external node tool is infuriating because of how hard things are to
test.
As several people have mentioned, you can put the weird stuff into a
host-dependent class. So, instead of this:
node foo.domain.example {
$var = value
include someclass
define stuff { ... }
stuff { blah: }
}
you write this:
class complex_stuff_for_node::foo_domain_example {
define stuff { ... }
stuff { blah: }
}
node foo.domain.example {
$var = value
include someclass
include complex_stuff_for_node::foo_domain_example
}
Later, when you are ready to cut this node over to the external node
classifier, you keep the class definition, remove the node definition,
and make the external node classifier print this YAML:
---
parameters:
var: value
classes:
- someclass
- complex_stuff_for_node::foo_domain_example
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: External Nodes Examples
On Sun, 06 Jun 2010, Nicolas Szalay wrote: - Douglas Garstang doug.garst...@gmail.com a =??crit : | I was just doing a little research on the best way to switch over to | external nodes. It seems like you can't use a combination of the two | systems. Apparently if the external node tool can't find an external | node (because it hasn't been cut over yet), then that's a failure. | This makes moving from 'internal' nodes to external nodes BLOODY | difficult. Yup, lookup is done only in one system : node file or external nodes. No, lookup is done first in the external node classifier, then in node definitions in site.pp (or the environment-specific manifest file). I leave nodes without a definition fail but you can also setup a class that reports that this node has no entry in the external node definitions with tag or an exported file. I have the external node classifier set a $errormessage variable if appropriate, and then something included by site.pp fails if the error message is defined. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Arbitrary barriers to bug reporting
On Wed, 02 Jun 2010, James Turnbull wrote: I didn't see anybody ask for the ability to send anonymous bug reports (although thta would certainly be useful). I saw somebody ask for the ability to send bug reports without having to create a new account. For example, that desire could be satisfied by the ability to send a bug report via email, or via a web form in which one of the questions is your email address. I'm still struggling to understand how this mechanism would work. And why it wouldn't be spam'ed? Surely you'd need to provide something to log a ticket that stopped someone scripting a spam attack against the address or the form? Yes, spam might be a problem, but projects exist that allow anybody to email bug reports (NetBSD, FreeBSD, and Debian are a few examples). For example, projects using gnats as the bug tracker could easily reject messages that are not formatted correctly. Projects using an anonymous web form could use a CAPTCHA to slow spammers down. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Arbitrary barriers to bug reporting
On Thu, 27 May 2010, Nigel Kersten wrote: It's not a random barrier though. I agree it should be easier, and I believe there's a bug in about making sure OpenID works, but I stand by my point that it's bloody difficult to track bugs reported anonymously. I didn't see anybody ask for the ability to send anonymous bug reports (although thta would certainly be useful). I saw somebody ask for the ability to send bug reports without having to create a new account. For example, that desire could be satisfied by the ability to send a bug report via email, or via a web form in which one of the questions is your email address. When faced with bug reporting processes that require me to login or to create an accuont, I have several times chosen not to bother. Only in a few cases have I chosen to create the account required. This state of affairs is not useful to the maintainers of the software, who would benefit from bug reports, but who do not benefit from people choosing not to bother reporting problems. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Have I found a bug with variables in nodes?
On Thu, 13 May 2010, Ohad Levy wrote: And the absolute killer: as far as I know, external node classifiers are global, not per environment. It doesn't even get to know which environment the node requested, so it is *impossible* for it to give back the correct information to Puppet. thats not correct (at least in the case of http://theforeman.org). Really? Did feature #2834 get implemented while I wasn't paying attention? --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Have I found a bug with variables in nodes?
On Wed, 12 May 2010, Dan Bode wrote: The external classifier can access client facts from the $vardir/yaml/facts. Ohad said it's possible, not that its pretty ;) it does, the facts yaml file is created before the external node classifier is called ;) Excellent! I'll change my node classifier to use that information. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] revoked host can't be re-added?
On Wed, 21 Apr 2010, Jewels wrote: puppetca --revoke hostname puppetca --clean hostname You added the old cert's serial number to a revocation list, and then removed the cert from puppetca. The cert might or might not still exist on the client. On client re-issue puppetd --server puppet --waitforcert 30 --test Error is : err: Could not retrieve catalog: Certificates were not trusted: sslv3 alert certificate revoked OK, the cert did still exist on the client; the client puppetd tried to use it, the server noticed that its serial number was in the revocation list, and the server refused to do anything more. So how do I get rid of it? I can't find a cert anywhere with either a valid cert or revoked.. Did I do this wrong? How do you remove and re- add a host? Stop puppetd, and rm -rf /etc/puppet/ssl on the client. Next time you start puppetd, it will generate a new key for itself, generate a new certificate signing request for that key, and send the request to the server. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Best practises for managing secret keys with puppet?
On Fri, 26 Mar 2010, Daniel Pittman wrote:
The prospect of putting the secret key into our revision control
system has ... well, little appeal is probably being fair: we could
certainly do it, but it suddenly means that a whole bunch of extra
data has to be treated as high security rather than low security.[2]
I configure puppet to print an error message that explains the
situation:
# util::manually_copied_file -- set permissions on a manually-copied
# file, and print an error message if the file is missing.
#
# usage:
# util::manually_copied_file { /dirname/filename:
# message = where to copy it from, or why it's not in puppet,
# owner = root,
# group = bin,
# mode = 0400,
# }
#
define util::manually_copied_file($message, $owner, $group, $mode)
{
# If the file exists and has a size 0, then do nothing.
# Otherwise, print an error message and fail.
exec { util::manually_copied_file check $name:
unless = /bin/test -s $name,
command = /bin/cat 'EOF'; /bin/false
Please copy ${name} manually - ${message}
EOF
,
logoutput = true,
before = File[$name],
require = [],
}
# Set the ownership and permissions, but do not modify the content
file { $name:
ensure = file,
replace = false,
owner = $owner,
group = $group,
mode = $mode,
}
}
So, on the whole my feeling is that an automatic key distribution
service that was accessible to puppet but (mostly) not to people
would be ideal.
That would be nice.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Problem with Variables and Class Inheritance
On Mon, 22 Mar 2010, Farooque M Haris wrote:
class /*DevelopersManager */#Secondary Class 1
{
*$fileList* = developerUserlist.txt
*$group* = users
*$home *= /home
include StaffManager
}
class /*AdminsManager */#Secondary Class 2
{
*$fileList* = adminUserlist.txt
*$group* = staff
*$home *= /home
include StaffManager
}
Apart from the strange stars and slashes (which I guess are an attempt
at highlighting), this won't work because, no matter how many include
statements you have, each class is really included no more than once.
Whichever of the two include StaffManager lines happens to take effect
first will do what you expect (making those variables available for use
by the StaffManager class). Whichever of the two include StaffManager
lines happens to take effect last will do nothing, because that the
StaffManager class will already have been included.
To do what I think you want, you need something like this:
define StaffManager($filelist, $group, $home) {
# do stuff with $filelist, $group, and $home
}
class DevelopersManager {
StaffManager { developers:
filelist = developerUserlist.txt,
group = users,
home = /home,
}
}
class AdminsManager {
StaffManager { admins:
filelist = adminsUserlist.txt,
group = staff,
home = /home,
}
}
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Package Providers for OS X Server
On Mon, 15 Mar 2010, Gary Larizza Jr. wrote: Visiting here -- http://docs.reductivelabs.com/references/stable/type.html#package It looks like appdmg, pkgdmg, and darwinport are the most viable providers for OS X. I don't use OS X, but it is one of the platforms supported by pkgsrc (see http://www.pkgsrc.org/), and some binary packages are available at ftp://ftp.netbsd.org/pub/pkgsrc/packages/Darwin/ if you don't want to build your own. Puppet doesn't have a pkgsrc package provider, but either of the openbsd or freebsd package providers will probably be close enough. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] disable ssl
On Fri, 12 Mar 2010, Christopher Johnston wrote: Reason I am asking is I am having a bunch of SSL issues in production right now, I need to disable SSL until I get things fixed. As a workaround, perhaps you could use the standalone compile/apply feature (new in 0.25); see http://reductivelabs.com/trac/puppet/wiki/ReleaseNotes#command-line-compile-apply. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] inheriting ssh_authorized_key
On Fri, 12 Mar 2010, Bob Belnap wrote:
I'm trying to reuse an ssh_authorized_key, but I'm having some problems.
If you want to use the same key in different ways (e.g. sometimes
with and sometimes without options = command=...) then you have to
use separate ssh_authorized_key resources, with different titles and
different names, like this:
$bob_ssh_key = *snip*
$bob_ssh_key_type = ssh_dss
ssh_authorized_key {bob:
name = b...@somehost,
ensure = present,
key = $bob_ssh_key,
type = $bob_ssh_key_type,
user = root,
}
ssh_authorized_key {bob to repo: # title cannot be bob
name = b...@somehost to repo, # name cannot be b...@somehost
ensure = present,
key = $bob_ssh_key,
type = $bob_ssh_key_type,
user = repo,
options = command=\svnserve -t --tunnel-user=bob\,
}
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Puppet 100% CPU usage
On Fri, 12 Mar 2010, DieterVDW wrote:
On Mar 12, 11:21 am, Patrick kc7...@gmail.com wrote:
Those files are downloaded and installed using apt, I just want puppet
to make sure they are owned by a certain user and group.
That's the only thing puppet needs to do.
As a workaround, instead of a recursive file resource like this:
file { /some/dir:
ensure = directory,
recurse = inf,
owner = someuser,
group = somegroup,
require = Package[the package that created the files],
}
try an exec resorce like this:
exec { fix permissions in /some/dir:
command = chown -R someuser:somegroup /some/dir,
require = Package[the package that created the files],
}
The exec will be much faster, but it will run every time (adding
a message in the log), even if the files already have the correct
ownership. To get rid of the unwanted log message at the expense of
slower execution, add
onlyif = some command to check whether there's a problem,
The onlyif command could use something involving find to print the
names of bad files, and test to see whether find's output was empty.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] config settings for environments
On Wed, 10 Mar 2010, Rob McBroom wrote: Hello. The documentation on using multiple environments says there are only a couple of settings that make sense per-environment (modulepath, templatedir, manifest) but it=??s not clear to me whether or not those are the only ones supported. I believe that those three are the only variables that may be changed per environment. Specifically, I=??m trying to set config_version. Each of my environments are clones of the same git repo at different points in its history, so using git to determine a config_version should yield different results in different environments. Sorry, you are out of luck. I suggest filing a feature request for the environment name and/or other relevant variables to be passed to the config_version script. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] ssh::auth server dependency on ~/.ssh and a scoping question
On Thu, 25 Feb 2010, Marcello de Sousa wrote:
IF homedir exists = deploy .ssh/authorized_keys , else do nothing
If you don't mind errors when you attempt to apply the manifest and the
homedir does not exist, then you could make the authorized_keys file
depend on something that fails if the homedir does not exist.
Here's an untested example:
# If the directory exists, then the unless clause in the exec
# is satisfied, so the command does not run; but the overall
# exec resource behaves as if it was successful, and anything that
# requires this exec is happy.
#
# If the directory does not exist, then the unless fails, so the
# command runs; but the command is /bin/false, so the command
# reports a failure, the overall exec resource fails, and anything
# that requires this exec will have a failed dependency and will
# therefore not be evaluated.
#
exec { fail if $homedir does not exist:
command = /bin/false,
unless = /usr/bin/test -d $homedir,
}
file { $homedir/.ssh/authorized_keys:
source = puppet:///wherever,
require = Exec[fail if $homedir does not exist],
}
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Cascaded conditionals possible ?
On Mon, 15 Feb 2010, Marcello de Sousa wrote:
I've been trying to use a resolv_conf recipe to setup the DNS servers based
on $domain and $location (a custom fact).
So I cascade the 2 conditionals, but it's not working. Is it supposed to
work ? Or should I look for an alternative ?
Nested selectors are supposed to work. I think you have some missing
commas:
resolv_conf { location_based_resolv:
domainname = $domain,
searchpath = [$domain],
# Here is the cascaded conditional. If I'm in domain1 I want to test 3
# different locations.
nameservers = $domain ? {
domain1.local = $location ? {
Default-First-Site-Name = ['10.2.38.10','10.128.38.21'],
HeadOffice =
['10.128.36.20','10.128.36.11'],
default = ['10.128.36.10','10.2.36.21'],
}
Missing comma here -^
domain2.local = ['10.128.36.20','10.128.36.10'],
default = ['10.128.36.10','10.2.36.20'],
}
I'd put a comma here --^
but it's not essential, because this is the last attribute
in the resource.
}
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Building a better puppetrun and related ideas
On Thu, 11 Feb 2010, Scott Smith wrote: Of course there are change control procedures for getting the manifests updated on the puppetmaster, but that's not enough; it's also necessary to run the puppet client only when specifically authorised. For example, the manifest update and a --noop mode client puppet run might happen during working hours, but the --no-noop client puppet run might happen during a maintenance window after hours. So let me get this straight: You run --noop throughout the day, aggregate the changes that need to be made, and then have a EOD/EOW change control meeting to go over them and determine if you need to run puppet without --noop ? Not exactly, but that would probably be acceptable. What actually happens today is that puppetd is not run at all on the client unless an authorised change is known to be ready for deployment; then puppetd is run in --noop mode to verify that the changes it wants to make are as expected; finallly puppetd is run in --no-noop mode. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Building a better puppetrun and related ideas
On Wed, 10 Feb 2010, Michael DeHaan wrote: We're attempting to provide a reason to not use cron :) I have a requirement that puppet may not change anything on a production host without change control approval in advance. It would be nice if a new version of puppet had better support for this use case. Of course there are change control procedures for getting the manifests updated on the puppetmaster, but that's not enough; it's also necessary to run the puppet client only when specifically authorised. For example, the manifest update and a --noop mode client puppet run might happen during working hours, but the --no-noop client puppet run might happen during a maintenance window after hours. As far as I am aware, the existing combination of puppetd --listen on each client, and puppetrun on a central server, does not handle this use case, so I run puppetd --onetime --noop or puppetd --onetime --no-noop via ssh. --apb (Alan Barrett) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] virtual resource realizing by require?
On Tue, 09 Feb 2010, Frederik Wagner wrote:
I just tried using the define, and hit a problem which I would avoid
(and actually need to avoid) by using the not implemented feature.
Realizing the virtual define across modules forces me to give the
namespace of the define explicitly, i.e. creating the virtual define
@mymount in a class nas-1::virtual (in the Module nas-1) forces me to
realize it in a second module as Nas-1::Virtual::Mymount| |, instead
of just Mymount| |.
Could you put the define in a common module, rather than a NAS-specific
module? For example:
/* In the util module */
define mymount ($mountpoint) {
realize File[$mountpoint]
mount { $mountpoint: require = File[$mountpoint], }
}
/* In the nas-1::virtual class */
@util::mymount { foo: }
/* Wherever you want to instantiate the mount: */
include nas-1::virtual
realize Util::Mymount[foo]
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] virtual resource realizing by require?
On Tue, 09 Feb 2010, Frederik Wagner wrote:
@file{/mountpoint: ensure = directory }
@mount{/mountpoint:
...,
require = File[/mountpoint]
}
in some other class:
Mount| title == /mountpoint |
I would like to automatically realize all resources required by the
mount without explicitly stating it in the module realizing the
mount. All requirements should be encapsulated in the module providing
the @mount.
There is a feature request for this:
http://projects.reductivelabs.com/issues/2084. Until that is
implemented, I think you'll need to work around it using a define.
--apb (Alan Barrett)
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
