Re: [Puppet Users] Can Puppet Windows version support system variables like "%HOMEDRIVE%"?
On Tue, Mar 13, 2012 at 11:48:20PM -0700, Feifei Jia wrote: > > I'd like to know if Puppet Windows support Windows environment variables? Operating system environment variables are not directly accessible, no, although any that beging FACTER_ will be imported as facts (so that "%FACTER_EXAMPLE%" is available as "$example". You can create your own custom facts to import any others that you want. See here: http://projects.puppetlabs.com/projects/puppet/wiki/Environment_Variables_Patterns -- Bruce The ice-caps are melting, tra-la-la-la. All the world is drowning, tra-la-la-la-la. -- Tiny Tim. -- 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: Avoiding duplicate definitions
On Tue, Mar 06, 2012 at 09:53:57AM -0800, jcbollinger wrote: > > If you decide to use such a wrapper anyway, then you should use it > absolutely everywhere, including updating all third-party modules you > employ. I think it's better, though, to just let the compilation > failures happen -- use them to detect where you need to patch up > conflicts between modules. ^This. I only offered the wrapper since a solution was requested. -- Bruce What would Edward Woodward do? -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Duplicate definition + parameterized classes + class scope
On Tue, Mar 06, 2012 at 05:53:57AM -0800, chris_sny...@sra.com wrote: > I don't understand Puppet Language. How can you take object-oriented > constructs such as 'class' and 'inheritance' and then not allow things like > multiple instances of a class, albeit with differing parameters. Defined > resource types don't help me as they don't have inheritance (which is > something I very much want). It would probably have been less troublesome, in the long run, if Puppet classes had been called something else. Too late now. One thing you need to get used to is that Puppet's DSL is a declarative language, not an imperative one. Some of the things you want, there, aren't actually appropriate. The Puppet DSL works well enough when you use it to create the simplest complete description of what you have. Try and use it like Java or Ruby and it'll fight you all the way. -- Bruce The ice-caps are melting, tra-la-la-la. All the world is drowning, tra-la-la-la-la. -- Tiny Tim. -- 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] Avoiding duplicate definitions
On Mon, Mar 05, 2012 at 11:27:46PM -0800, Thomas Sturm wrote:
> Both solutions don't help when taking this git module from github,
> because we'd have to change it, it would no longer be an atomic piece
> of logic one can just take and use unchanged. Is there some kind of
> best practice for this problem? Or is there some other workaround I
> don't know of or I didn't understand so far?
You haven't missed anything. Virtual resources *are* the best practice
for avoiding duplicate definitions, such as it is. However, you won't
see them used a lot for package resource declarations; well-written
Puppet modules tend to encapsulate a discrete function, so package
conflicts tend to be rare (at least, within an organisation's own code).
Personally, I believe strongly in keeping puppet code as simple as
possible and only adding complexity (e.g. virtual definitions) where a
specific situation requires it. Adding layers of abstraction to code in
Puppet's declarative DSL causes more pain than it solves.
You have a choice of altering the third party code or your own. You
will keep encountering this problem if you use third party modules. I
guess you could do create your own safe package wrapper, something like
this:
define safepackage ( $ensure = present ) {
if !defined(Package[$title]) {
package { $title: ensure => $ensure }
}
}
And either use it everywhere (not necessarily a good idea) or wherever
you hit a problem with third party code.
Your problem is relevant to the earlier post about code reuse. I
considered responding to that (too busy, sorry) and this was one of the
kinds of scenarios that I had in mind.
--
Bruce
I must admit that the existence of Disneyland (which I know is real)
proves that we are not living in Judea in AD 50. -- Philip K. Dick
--
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 possible to conditionally replace a file ?
On Mon, Nov 28, 2011 at 03:01:14PM +, Dan White wrote: > > Thanks for responding. Nice tag line. > > OK, more details: > > In my users class, I want to be able to push out custom dot-files when the > user account is first created. > Unfortunately, if one sets user:managehome => true, the dotfiles are > created by default and the custom file is not pushed out unless you > set file:replace => yes. You realise that this is being done by Unix (Linux?), not Puppet? If you use puppet to replace the system's default dotfiles (on Linux, they'll be in /etc/skel) *before* creating any users, you'll get precisely what you want. Just set up the users so that they depend on the file resources which place the right files in /etc/skel and this will guarantee the files are in there before the users are created (assuming they didn't exist already). The Unix user creation tools will copy the /etc/skel files into the right place when Puppet invokes them. This only fails if you need different dotfiles (differing by content and/or name) for different users. If you don't, simple win -- Bruce Hierophant: someone who remembers, when you are on the way down, everything you did to them on the way up. -- 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 possible to conditionally replace a file ?
On Mon, Nov 28, 2011 at 02:22:51PM +, Dan White wrote: > As far as I can tell, the "replace" parameter is all or nothing. > > What I am looking for is something like the exec/onlyif parameter that I can > use to conditionally replace a file. > > Any thoughts ? There is more than one way to do this. What kind of conditions woud you be testing for? -- Bruce A problem shared brings the consolation that someone else is now feeling as miserable as you. -- 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: Does Node Inheritance work for people?
On Mon, Aug 08, 2011 at 06:25:20AM -0700, Alessandro Franceschi wrote: > NEVER include a class in the inheritance tree (well you can if you > don't redefine variables used in that class but still is not > necessary). > In a nodes inheritance layout BEFORE you set the variables and THEN > you include classes (in my case "role classes"). This is precisely why Puppet's inheritance model is painful. To be safe, you have to include all classes at the specific node. You can hide some of this in role-based classes, but only so much. It causes duplication, noise in the config and is an unnecessary potential source of error. Yes, if you use an ENC, you can avoid some of this by, for example, having a script that queries a database in which the duplication has been removed by normalisation, or by using a language with a sane inheritance model to describe your nodes. That, though, is only hiding the problem and still means much more noise than is necessary in the communication between the ECN and Puppet (which is still a potential source of error, as the same datum transmitted many times is more likely to be corrupted/distorted in one of those instances). -- Bruce I unfortunately do not know how to turn cheese into gold. signature.asc Description: Digital signature
Re: [Puppet Users] Does Node Inheritance work for people?
On Fri, Aug 05, 2011 at 06:33:12AM -0700, Nigel Kersten wrote:
> We have a bunch of problems people regularly run into with node inheritance,
> and it's something we'd like to find a better solution for.
>
> Is anyone using node inheritance and happy with how it works? If so, can you
> describe your setup briefly?
I use node inheritance purely for setting variables that are relevant to
environments or roles. So I'll have a production node or a staging node
and the host node may inherit from that, or from a "production webservers" node
which inherits from production. I give all the role and environement
based nodes names ending in ".template" to avoid potential name clashes.
I use class inheritance for all the configuration and include classes in
the actual host node. I use role-based classes to tie things together
and minimise the number of classes. I make sure we never, ever include
a class in anything except the host node (not in any of the template
nodes from which it inherits), so that we always have the option to
override default values etc. without having to specially design our
classes for every eventuality.
So I'll have a webservers "role" class. This gives me things like
node web01 inherits webserver.production.template {
enabled_sites = [ 'test', 'sample', 'whatever' ]
include webserver
}
This is the only way I have found to make puppet work for me
practically. I don't like it much, but it works. The inheritance model
is, without question, my absolute least favourite thing about Puppet.
Most hated thing, to be accurate. I hate having to specify things at
the node level when the only things declared at the node level should be
the things which are *unique* to the node. I don't much like having to
have parallel node and class inheritance.
A more traditional inheritance model would be much more useful for both
nodes and classes. Oh, and as said by somebody else already, I have
always considered nodes to be a redundant duplication. Nodes are just a
special case of classes and only serve to complicate Puppet's structure.
I appreciate the practical reasons why they were used in the first
place, but I think Puppet would benefit from scrapping nodes and
implementing a better inheritance model for classes. I appreciate
that's quite something of a redesign and would make optimisation more
difficult (at lest, starting from where we are now).
--
Bruce
A problem shared brings the consolation that someone else is now
feeling as miserable as you.
--
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] Single and Double Quotes
On Sun, Jun 05, 2011 at 09:36:59AM -0700, Douglas Garstang wrote: > Hmmm Ok then. I'll change my question to, why doesn't the style > guide say to stick with double quotes for all strings and keep it > consistent? Most languages honour the convention that variables are not expanded within single quotes. I always use single quotes unless expansion is a requirement or the string itself contains single quotes; it signals to the interpreter/compiler that it need not inspect the string contents for expansion and saves a few cpu cycles. It signals the same to the alert human reader who may be debugging the code. I consider that more valuable than consistency for consistency's sake. -- Bruce I must admit that the existence of Disneyland (which I know is real) proves that we are not living in Judea in AD 50. -- Philip K. Dick -- 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] Stopping two services at once
On Mon, May 16, 2011 at 12:16:53PM +0100, Jonathan Gazeley wrote:
> Is there a way to stop and disable two services in one declaration?
> Currently I have this:
>
> # Stop sendmail
> service { "sendmail":
> ensure => stopped,
> enable => false,
> }
>
> # Stop exim
> service { "exim":
> ensure => stopped,
> enable => false,
> }
>
> Is it possible to format that like this?:
>
> service { "disabledemail":
> name => ['sendmail', 'exim'],
> ensure => stopped,
> enable => false,
> }
Are you trying to have simultaneous stoppage or just save typing? You
can achiev the latter by
service { [ 'sendmail', 'exim' ]:
ensure => stopped,
enable => false,
}
--
Bruce
What would Edward Woodward do?
--
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: Set client environment on master
On Thu, Jan 20, 2011 at 10:04:37AM +1100, John Warburton wrote: > On 19 January 2011 17:41, Bruce Richardson wrote: > > > On Wed, Jan 19, 2011 at 05:10:56PM +1100, John Warburton wrote: > > > wishes - https://projects.puppetlabs.com/issues/3910 > > > > *Looks at discussion* Ouch. If the client were still allowed to > > override the environment, even when the server was explicitly set to be > > authoritative, that would make a complete nonsense of "authoritative". > > Glad the discussion has gone the other way. > > > > This may be true for you, but not for all sites. What I am looking for is a > way to set the level of authoritativeness on the server, so that you and I > can coexist. Yes, I get that. We aren't in disagreement at all. I took issue, rather, with the earlier suggestion in the thread that the client be able to override no matter what was set on the server, for "backwards compatibility. -- Bruce Explota!: miles de lemmings no pueden estar equivocados. -- 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: Set client environment on master
On Wed, Jan 19, 2011 at 05:10:56PM +1100, John Warburton wrote: > > I actually want to be able to have it the other way around - the node > classifier sets the default environment, but my client can override if it so > wishes - https://projects.puppetlabs.com/issues/3910 *Looks at discussion* Ouch. If the client were still allowed to override the environment, even when the server was explicitly set to be authoritative, that would make a complete nonsense of "authoritative". Glad the discussion has gone the other way. -- Bruce Get thee behind me, Stan: for it is written, thou hast gotten me into another fine mess. -- Oliver 4:8 -- 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: Dependency resolution for packages
On Wed, Jan 12, 2011 at 03:43:42AM -0800, Sven Sporer wrote: > > This makes no sense to me that the last doesn't always work. > > Someone might come up with an answer, but logs with "--verbose > > --debug" would probably help. Even if you sanitize it with "grep > > vim" it would probably help a lot. > > What do you mean by "the last"? Everything is installed as intended > after the third run. Sometimes, even after the second run. That's what he means. Why this inconsistency? > So I'm not > really sure what causes this inconsistency, but it has something to do > with yum dependency resolution and the dependencies as defined in the > manifest. Are you sure that all the machines were in precisely the same state with regard to packages before the upgrades? -- Bruce Get thee behind me, Stan: for it is written, thou hast gotten me into another fine mess. -- Oliver 4:8 -- 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 Clients requesting classes
On Tue, Jan 11, 2011 at 09:05:43AM -0800, Nigel Kersten wrote: > > I disagree that this approach is fundamentally wrong, but it's not > always appropriate. I'll concede I'm being a little over-emphatic, but the OP's situation didn't read to me as if it had anything to justify that approach. And I did tell him how to do it, anyway. Can't say fairer than that. -- Bruce I must admit that the existence of Disneyland (which I know is real) proves that we are not living in Judea in AD 50. -- Philip K. Dick -- 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] Fwd: [Puppet-dev] Proposal: move parameter/property validation from master to agent
On Tue, Jan 11, 2011 at 10:37:52AM -0800, Nigel Kersten wrote: > This is a reasonably important thread that I think is of interest to > the -users list as well as -dev. I subscribed to puppet-dev a while back and have never seen a single message from it. Assumed it was a quiet list ;) Tried resubscribing and it tells me I am subscribed. Still no messages. -- Bruce Remember you're a Womble. -- 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 Clients requesting classes
On Tue, Jan 11, 2011 at 02:09:27AM -0800, Exinferis wrote: > But what we really want to achieve is not to register every node in > our master configuration (hostnames can totally vary so no wildcard > matching), but to give the nodes the possibility to request a specific > class or to report themselves as a specific type of server. I think that approach is fundamentally wrong. I do not believe that a puppetmaster should allow clients to decide which host they are, or which configuration they receive. The whole point about central configuration is that you manage it centrally; if your clients can decide, how do you determine what is going on without inspecting every host directly? If most of your hosts are going to have the same configuration, but some will differ, why not use the default node for the common configuration and make different entries for other hosts when you need to? What do you gain by having to go and make configuration changes on each host, rather than just changing configurations in one place? I can tell you one thing you lose; you lose the ability to rebuild from scratch a node that died (with, say, an unrecoverable hard disk). If you really want to do this thing, you could achieve it by modifying your default node configuration so that the extra configuration options are contained in classes which are only included if certain facts are true. You then only create those facts on the hosts you want to have those configurations. I urge you not to do this. -- Bruce Hierophant: someone who remembers, when you are on the way down, everything you did to them on the way up. -- 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] Differences between puppet and puppetd
On Tue, Jan 11, 2011 at 02:36:42PM +, Martin Harrigan wrote:
> Hi all,
>
> I am using Puppet to execute an Expect script (http://expect.sourceforge.net)
> on a client. The Puppet recipe, test.pp, is:
>
> exec { '/root/test.exp':
> command => '/root/test.exp',
> logoutput => true
> }
>
>
> Is there any difference in the way Puppet executes a recipe using 'puppet
> --debug --verbose' compared to using puppetd?
One issue will be the path. You really do need to set a path for exec
with a minimum of '/bin/' on it so that puppetd can find /bin/sh, in my
experience. When you run puppet rather than puppetd, it's inheriting
your environment with your path.
--
Bruce
It is impolite to tell a man who is carrying you on his shoulders that
his head smells.
--
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: pushing files with host based variables?
On Mon, Jan 10, 2011 at 11:19:03AM -0800, trey85stang wrote: > Bruce, I think what you are saying is clicking now. > > Now does puppet allow any variable substitution? I do urge you to stop thinking in terms of scripts. It doesn't map well onto the way that Puppet works. If you mean "How do I apply the same changes to multiple nodes, with different values for each host?", then one answer is to put the common actions into a class and set different variable values in each node declaration. Alternatively, put them into a "define" and pass different parameters each time you call it. You can also use defines to repeate the same actions/changes with multiple values within a single context (e.g. a node). You should be able to find examples in the online documentation. -- Bruce I must admit that the existence of Disneyland (which I know is real) proves that we are not living in Judea in AD 50. -- Philip K. Dick signature.asc Description: Digital signature
Re: [Puppet Users] Re: pushing files with host based variables?
On Mon, Jan 10, 2011 at 08:11:02AM -0800, trey85stang wrote: > Upon further reading, it looks like what I want would be better > accomplished with using stored configs? No. That's for something else. Since you have 6000 nodes in your environment, you probably want to look at External Nodes, which would scale better for you than describing all 6000 nodes in a text file. http://docs.puppetlabs.com/guides/external_nodes.html -- Bruce I object to intellect without discipline. I object to power without constructive purpose. -- Spock -- 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: pushing files with host based variables?
On Mon, Jan 10, 2011 at 07:56:49AM -0800, trey85stang wrote:
> Thanks for the reply,
>
> It looks like I would need an entry for every host if I were to take
> that route? My environment would require 6000*3 entries... That
> doesn't seem logical.
>
> Am I understanding this correctly?
No, you're still learning. Here's how to do it (well, one way to do
it):
class role::basic_host {
host { 'localhost':
ip => '127.0.0.1',
host_aliases => 'localhost.localdomain',
ensure => 'present'
}
host { $fqdn:
ip => $primary_ipaddress,
host_aliases => $hostname,
ensure => 'present'
}
host { 'host1.domain.com':
ip => '192.168.1.20',
ensure => 'present'
}
host { 'host2.domain.com':
ip => '192.168.1.30',
ensure => 'present'
}
host { 'unique_host.domain.com':
ip => '192.168.1.250',
ensure => 'present'
}
resources { 'host': purge => true }
}
node host1 {
$primary_ipaddress = '192.168.1.1'
include role::basic_host
}
node host2 {
$primary_ipaddress = '192.168.1.2'
include role::basic_host
}
node host3 {
$primary_ipaddress = '192.168.1.3'
include role::basic_host
include some::other::class
}
You see? No need to define each host resource separately for each node
(nodes are what puppet-configured hosts/computers are called in Puppet).
What you do is you use classes to group together a linked set of
resources, then you include the appropriate classes in your nodes.
Notice that I added a couple of other important entries to the list of
host resources (you wouldn't want to be without those, and the "purge =>
true" line would otherwise remove them)). Note also that I don't need
to specify the values of $fqdn and $hostname, because these are "facts"
which puppet can find out for itself (I do specify $primary_ipaddress in
this example, because a host may have more than one address, not all of
which will be associated with the primary hostname).
Keep asking about anything which doesn't make sense yet.
--
Bruce
The ice-caps are melting, tra-la-la-la. All the world is drowning,
tra-la-la-la-la. -- Tiny Tim.
signature.asc
Description: Digital signature
Re: [Puppet Users] pushing files with host based variables?
On Sun, Jan 09, 2011 at 10:42:19AM -0800, trey85stang wrote:
>
> 192.168.1.20host1.domain.com
> 192.168.1.30host2.domain.com
> 192.168.1.250 unique_host.domain.com
>
> Is there a way to manage this with puppet? What I would like to do is
> be able to check that those 3 entries exist... if not replace the file
> and generate the custom content that needs to be in the file?
If you use host resources, as already recommended, Puppet will create
the entries if they do not exist. If you only want those entries
present, tell Puppet to purge all host entries not specified in the
puppet configuration for that host.
host { 'host1.domain.com':
ip => '192.168.1.20',
ensure => 'present'
}
host { 'host2.domain.com':
ip => '192.168.1.30',
ensure => 'present'
}
host { 'unique_host.domain.com':
ip => '192.168.1.250',
ensure => 'present'
}
resources { 'host': purge => true }
Stop thinking custom scripts; start thinking resources. Most Puppet
configuration consists of specifying which resources you do or don't
want present in which circumstances. Most of the rest of it is about
defining which resources depend on which others (e.g. this running
application depends on that configuration file). You describe how a
system should look and Puppet does what is necessary to make it so.
--
Bruce
I object to intellect without discipline. I object to power without
constructive purpose. -- Spock
--
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] syntax for class names
On Fri, Nov 12, 2010 at 09:32:16AM +1100, Daniel Pittman wrote: > Footnotes: > [1] Like the English language, puppet isn't that pure, and you can work > around this in a whole bunch of ways. Pure-ruby manifests in 2.6 might > be a way to do that, for example. Oh, I knew somebody was going to say that. I don't much like the idea of ruby manifests; it seems to turn Puppet's design upside down. I try to reduce the direct use of Ruby in my puppet configurations to an absolute minimum. -- Bruce It is impolite to tell a man who is carrying you on his shoulders that his head smells. -- 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] syntax for class names
On Thu, Nov 11, 2010 at 12:50:02PM -0800, Eric Snow wrote:
> How do you dynamically create classes?
You don't. 2.6 has parameterized classes but that's not quite what you
mean.
>
> For instance, I have a bunch of users to make. I have all their
> usernames. Each is the same as the others except for the username and
> one other value. I don't want to have to spell out a User for each,
> but would rather set up them up dynamically, in a much cleaner way
> (and more maintainable).
You can use resource defaults to take out most of the drudgery
User {
managed => true,
shell = '/bin/bash'
}
Then you only need type out the varying properties of each user.
>
> It looks like parameterized classes would mostly do it, but is the
> syntax for including a parameterized class the same everywhere? Can a
> parameterized class be virtual?
No. Resources can be virtual but not classes.
If you were hoping to be able to create all of these users by iterating
through a hash, or something similar, then Puppet really doesn't support
that. Puppet's DSL is declaritive and can't be treated like some OO
language (I wish Luke had chosen a name other than "class" for Puppet's
classes; it only confuses people).
Have you noticed that Puppet has arrays and hashes but doesn't have a
keys() function? You *could* have a hash of users and their properties
$users = { john => { shell => '/bin/bash', uid => '501' }, david => {
shell => '/bin/tcsh', uid = '501' }
and have a define which consulted that hash, as in
define hash_user ( $user_hash ) {
user { $name:
ensure => 'present',
managed => true,
shell => $users[$name][shell],
uid => $user_hash[$name][uid]
}
}
But since there is no keys function, you can't do
hash_user { [ keys($users) ]: user_hash => $users }
You have to do
hash_user { [ 'john', 'david' ]: user_hash => $users }
which isn't really saving you a lot.
Bluntly, Puppet wants you to declare your resources explicitly.
> As well, I was hoping to set up some defines in the dynamically
> created user so that they could be used from the class's namespace.
> The alternative is to do them separately and pass in the same
> information that I already passed in to the class, which seems messier
> than just providing them from the class's namespace.
I think there may be a misplaced word in there; it doesn't seem to make
entire sense.
--
Bruce
Get thee behind me, Stan: for it is written, thou hast gotten me into
another fine mess. -- Oliver 4:8
--
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] using puppet to restore root access to a box
On Thu, Nov 11, 2010 at 01:46:50PM -0800, David Birdsong wrote:
> problem--though this appears to remove one of the failed steps. it's
> this line that i was thinking indicates the outer most scope of the
> problem:
> Nov 11 19:38:01 ip- puppet-master[3885]: Stages are not
> supported by 0.24.x client; stage(s) Stage[main] will be ignored
>
> i infer Stage[main] is everything, therefore File {} will never be
> applied on the agent. (still learning the right words to describe
> puppet actions..)
Ah, right. You may find this useful:
http://www.mail-archive.com/puppet-...@googlegroups.com/msg08787.html
If there's a version of 2.6 where that fix has gone in, you need that
version. If not, you could try applying the patch yourself ;)
--
Bruce
Bitterly it mathinketh me, that I spent mine wholle lyf in the lists
against the ignorant. -- Roger Bacon, "Doctor Mirabilis"
signature.asc
Description: Digital signature
Re: [Puppet Users] using puppet to restore root access to a box
On Thu, Nov 11, 2010 at 11:52:26AM -0800, birdsong wrote: > > I'm guessing that I need to somehow serve up a catalog in a non-staged > way, but I have no idea how to do that. Any tips? Should I just > install a 0.24.x master temporarily? If coyping is the problem, don't copy the file; write it. So do content => file( whatever ) rather than source => 'puppet:///whatever' -- Bruce Remember you're a Womble. -- 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] selectors in type defaults
On Tue, Nov 09, 2010 at 10:46:07AM +0100, Arnau Bria wrote:
> Hi all,
>
> I'd like to define a selecto when defining "user" type default:
>
> User {
> ensure => present,
> provider=> useradd,
> managehome => $name ? {
> /^at/ => true,
> default => false,
> }
> }
>
> It is not working and I have not found any place that says that it is
> possible.
>
> Anyone knows if this is possible? and if yes, what am I doing wrong?
You could do this using a define. A resource default isn't some kind
of macro that is invoked whenever an instance of the resource is
evaluated; the code of the defaults declaration is evaluated in place,
when it is first encountered. $name doesn't exist at the time you
declare the defaults. (You're lucky you didn't do this inside a code
block where $name is meaningful, or your error would have been hidden
and produced bizarre side effects).
To do what you want, the way you want to it, you would need to create a
my_user define and put the code in there. However, there's no need to
do it this way at all. What's wrong with just having
User {
ensure => 'present',
provider => 'useradd',
managed => false
}
and then
user { 'at':
managed => true
}
Is there some reason you don't want that? Hmm. Are you perhaps
working under the mistaken assumption that a User defaults declaration
will affect all users on the box? Because the truth is that it will
only affect any users explicitly declared in your Puppet manifests.
--
Bruce
It is impolite to tell a man who is carrying you on his shoulders that
his head smells.
--
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: Prevent users from creating new accounts
On Thu, Nov 04, 2010 at 03:11:43AM -0700, hywl51 wrote: > Yes, you said it. Unfortunately, we have some users running as root > privilege on server, because they cann't work without it. Are they admins or developers? If developers, then there is always a way round - sudo, fakeroot, giving them virtual hosts to play with. If they really need to be adminning the boxes then sudo will take you so far, but past a certain point they have enough privileges to give themselves more privileges. SELinux might be the answer, although you'd have to use it carefully if you wanted to avoid it locking puppet down as well. And if puppet isn't locked down, and they have root access... -- Bruce A problem shared brings the consolation that someone else is now feeling as miserable as you. -- 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] Prevent users from creating new accounts
On Thu, Nov 04, 2010 at 10:40:02AM +0100, Martin Alfke wrote:
>
> Hi,
>
> I would assume that you can define a resource default:
>
> User { ensure => absent }
>
> and afterwards define the users you would like to be present on your system.
No, that would only establish the default for any user resources
declared within Puppet. It would have no effect on users created
outside of puppet with names not used in Puppet.
--
Bruce
I object to intellect without discipline. I object to power without
constructive purpose. -- Spock
--
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] Help with LDAP, Users, and Puppet..
On Tue, Nov 02, 2010 at 09:35:24AM +, Michael Gliwinski wrote: > On Tuesday 02 Nov 2010 01:53:34 Bruce Richardson wrote: > > nsscache is probably at fault. Try removing it from nsswitch on > > a machine which has shown this problem and then see how that affects > > things. > > Why do you think nsscache could be a problem? It and nscd often are. Better to ensure that your LDAP directory is resilient and responsive. Configure pam and nsswitch so that you can still get into a box as a non-LDAP user in the worst case scenario where LDAP is inaccessible. Caching the directory just causes a whole new special kind of latency issues while making problems harder to debug. -- Bruce I unfortunately do not know how to turn cheese into gold. -- 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] Help with LDAP, Users, and Puppet..
On Mon, Nov 01, 2010 at 08:27:30PM -0700, Matt Wise wrote: > nsscache was an attempt at solving the issue... even without nscd > installed, or nsscache, the issue happens extremely frequently. so far > the only fix i have is to do everything with hard-coded GID/UIDs ... Is it only Puppet which has this problem, or do other processes have difficulties resolving usernames and uids? If it's an LDAP/nsswitch configuration issue, may be hard for us to diagnose just by looking at Puppet configs. Are these errors happening with exisiting users or new ones which are being created during puppet runs? -- Bruce I must admit that the existence of Disneyland (which I know is real) proves that we are not living in Judea in AD 50. -- Philip K. Dick -- 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] puppetd misbehaving on a debian based box.
On Mon, Nov 01, 2010 at 09:38:53PM -0400, Peter Berghold wrote: > Deleted and re-installed puppetd and things are working again... that was > wierd. > > Still not sure what happened. Removing the package may have removed a state file that was causing a problem. If it happens again, try taking a copy of /var/lib/puppet before you remove, then compare the contents when you reinstall. May help you find the problem. -- Bruce Bitterly it mathinketh me, that I spent mine wholle lyf in the lists against the ignorant. -- Roger Bacon, "Doctor Mirabilis" signature.asc Description: Digital signature
Re: [Puppet Users] Help with LDAP, Users, and Puppet..
On Mon, Nov 01, 2010 at 02:10:23PM -0700, Matt Wise wrote: > > On the systems we use 'files db ldap' as our nsswitch.conf priority, > and 'db' is a local copy of the ldap data using 'nsscache' on a > regular basis. Looking up a user should never fail and it doesnt > seem to when we log in and check by hand, so I don't know why puppet > is failing. nsscache is probably at fault. Try removing it from nsswitch on a machine which has shown this problem and then see how that affects things. -- Bruce I must admit that the existence of Disneyland (which I know is real) proves that we are not living in Judea in AD 50. -- Philip K. Dick signature.asc Description: Digital signature
Re: [Puppet Users] Re: require service started at another node
> > 2. Make your application server tolerant of database downtime (that > > is, have the applications generate sensible errors while the db is down > > and recover when it is up, rather than just crash and require an > > application server restart). > > If appserver (java app server like jboss) start and can't find db > it's crash and need to restart by hand. We are unable to do anything > with it. Then you need to rethink how you design and deploy your java applications. I have worked with Java, Tomcat, Jboss and similar systems; it is perfectly possible to deploy java applications in a way which allows them to cope with the temporary absence of a database server. -- Bruce Bitterly it mathinketh me, that I spent mine wholle lyf in the lists against the ignorant. -- Roger Bacon, "Doctor Mirabilis" -- 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: require service started at another node
On Sun, Oct 31, 2010 at 11:44:51PM -0700, Leonko wrote: > Hello, Bruce. At now we have hard dependence between file storage, db > server and appserver. If it chain broken at any phase we get the > message from zabbix. But that's not a problem. Zabbix is monitoring software: it *should* tell you when important services are broken. > And we try it automatize this action. Fine. But you can't use a single puppet run to make it all happen. Use puppet on the database server to make sure that postgresql is running properly and use puppet on the application host to make sure that the application server is running *if* the database server is available. Puppet can automate that much for you. If you want to have the minimum time between the database server coming up and the application server starting, there are a number of ways you could do that; the application host could be checking the db connection on a regular basis, for instance, or the db server could signal the application host once the app is up. But really, your best plan is to 1. Make sure that your database service is up early, as resilient as you can make it and rarely restarted. 2. Make your application server tolerant of database downtime (that is, have the applications generate sensible errors while the db is down and recover when it is up, rather than just crash and require an application server restart). -- Bruce Bitterly it mathinketh me, that I spent mine wholle lyf in the lists against the ignorant. -- Roger Bacon, "Doctor Mirabilis" -- 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] require service started at another node
On Fri, Oct 29, 2010 at 04:56:34AM -0700, Leonko wrote: > Hello, > Anybody now how make with puppet dependence on other service on > another node? > > like : require => Service[dbnode:postgresql] > I need ensure that the db is running on another node before start my > appserver. You can't do this directly. Even if you were to use storeconfigs to get at facts about other nodes, all that would tell you is that the database service was running the last time puppet ran on that node. Besides, the important thing to know, even more important than whether the service is running on the dbnode, is whether you can usefully connect to the service from your appserver node. Even if the service is running, other things might prevent that. I think the best approach would be to have a test that runs on your appservernode, connects to your postgres server and does a simple status check. You could do this as a custom fact, so that it set a variable like $dbservice to true or false, or you could do it as an exec. But can your application server really not cope with the database service not being available? Can they not present a useful error message if the database is broken? How will you cope if the database service dies once your appserver has started? -- Bruce If the universe were simple enough to be understood, we would be too simple to understand it. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Moving the puppet master
On Fri, Oct 29, 2010 at 08:48:22AM -0700, Dan Bode wrote: > On Thu, Oct 28, 2010 at 5:41 PM, Jay Adkisson wrote: > > > Hey all, > > > > I need to move my puppet master to a different host with a different > > hostname. Is there a fancy way to do this that doesn't involve manually > > going to each client and cleaning the certificates? > > > > the only thing you need to move is the ca directory. > > ssldir/ca > > then you can regenerate a new master SSL certificate from that CA. As long > as the certificate is signed by the same CA which the clients already trust > it will work without having to touch the clients. If you were careful when creating the original certificate, you won't even have to generate a new cert. I always give the puppetmaster in any domain a CNAME or A record of puppet., whatever it's own name. I then set certname and certdnsnames in the puppetmaster config and start it up - a certificate with the right CN will be created. -- Bruce Get thee behind me, Stan: for it is written, thou hast gotten me into another fine mess. -- Oliver 4:8 -- 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] nagios_service types and "name"
On Wed, Oct 20, 2010 at 05:16:39PM +0100, Bruce Richardson wrote: > It seems that the nagios_service type will not write out the "name" > property of nagios service objects. I had thought this was an oversight > or a bug, till I saw this thread: > > http://www.mail-archive.com/puppet-b...@googlegroups.com/msg10387.html Ah, I should have looked further: http://www.mail-archive.com/puppet-b...@googlegroups.com/msg10162.html OK, so it's a bug not a feature. Patching away - need that functionality. -- Bruce Remember you're a Womble. -- 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] nagios_service types and "name"
On Wed, Oct 20, 2010 at 05:16:39PM +0100, Bruce Richardson wrote:
> desired behaviour, why does the nagios_service type have "use" and
> "register" parameters, because they are useless without the ability to
> attach names to services in the generated nagios config.
Well, "use" is still functional, because I can always put service
templates into puppet templates or just statically copied files, rather
than using the nagios_service resource. But setting "register => 0" on
a nagios_service type is pointless if you can't reuse the resulting
object, because it has no name.
Is it really the case that services, alone out of all the nagios object
types, can't generate object templates from the corresponding puppet
type? What I want to do is this kind of thing:
nagios_service { 'generic-service':
register => '0'
}
nagios_service { 'ping-service':
use => 'generic-service',
service_description => 'Ping'
check_command => 'check_ping!100.0,20%!500.0,60%',
register => '0'
}
and then in some role class...
@@nagios_service { "ping_$fqdn":
use => 'ping-service'
hostname => $fqdn
register => '1'
}
But, unless I'm missing something, I can only do that by creating a file
containing nagios service templates via some other route.
--
Bruce
I must admit that the existence of Disneyland (which I know is real)
proves that we are not living in Judea in AD 50. -- Philip K. Dick
--
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] nagios_service types and "name"
It seems that the nagios_service type will not write out the "name" property of nagios service objects. I had thought this was an oversight or a bug, till I saw this thread: http://www.mail-archive.com/puppet-b...@googlegroups.com/msg10387.html which seems to imply that this is a deliberate "feature". Is this prohibition on "name" really the desired behaviour? This would make it impossible to use the nagios_service resource to generate a service template that can be reused in other service declarations. If it is the desired behaviour, why does the nagios_service type have "use" and "register" parameters, because they are useless without the ability to attach names to services in the generated nagios config. Hopefully I am just missing something and can be pointed patiently to the way to do what I want. -- Bruce What would Edward Woodward do? -- 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: Negate or uninclude a class
On Tue, Oct 19, 2010 at 09:00:16AM -0700, jcbollinger wrote:
> The subclass approach definitely does not override the superclass to
> do nothing. Much to the contrary, it overrides the superclass so that
> together (whether the superclass is directly included or not) they
> ensure the correct configuration for a system that is not, in the
> example, an LDAP client. In other words, the servers are configured
> as non-clients, rather than leaving their client status unmanaged.
> There will be file differences between clients and non-clients, and
> possibly differences in such things as installed packages and service
> configuration. It is wise to manage those differences, whether
> whether via subclassing or otherwise.
That's topsy turvy, in my opinion. I agree with you about the
importance of state, but in that scenario, to me, not being an LDAP
client is the basic state. The basic, clean state of a system should be
something Puppet protects from the start; including classes should
modify or extend that and, in most cases, I expect my configuration to
be protective enough of the core and well known functionality so that
it should make no difference whether a class was previously included and
then dropped or never included in the first place.
Here's my rationale: most of us do not have the luxury of knowing
everything about every aspect of every package that may be installed on
a typical Linux/*nix system (unless you're the chief architect at Red
Hat/SuSE or wherever, in which case you may have a shot). That isn't a
terrible problem; we can know enough about the core to be aware of what
is significant. I certainly know enough about the core components of a
system (nsswitch, pam, fstab and so on), to know what will interfere
with that and what is irrelevant. The seed of any configuration, for
me, would be locking those down in their simple and functional state.
This means that including an ldap::client will extend that, but in the
absence of ldap::client, the core function will be restored. There are
cases where the past inclusion of a class will litter a system with
packages and configuration that do interfere, but those are rare. I do
not share your nervousness about purging - purge and well managed
resources - and judicious use of virtual ones - is generally cleaner
than a whole set of twinned active/inactive classes. It doesn't mean I
never, ever write a disable/cleanup class but it isn't my habit.
It's a defensive approach but, given that I'm not Red Hat's chief
architect, lack the time to weigh every package in the balance but do
have responsibility for relatively up to date Red Hat and Centos systems
(Debian too, but that's a slower moving target), it seems to me both
saner and less work than adding disable classes to everything. It's
also less work and the code is cleaner, so I'd probably do it even if I
were the very source of all knowledge of RHEL's eccentricities.
My basic samba class configures a minimal smb.conf to be aware of the local
workgroup/domain but have no shares and explicitly disables all
samba-related services. samba::member, samba::pdc and others inherit
and extend. No longer including them undoes the damage, so to speak.
This is more than semantic quibbling about how to label different
states; inheriting and overriding a more complex state to impose a
simpler state is not the same as defaulting to the simpler state.
So in my situation, "if { include class }" works very well.
--
Bruce
Explota!: miles de lemmings no pueden estar equivocados.
--
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: Negate or uninclude a class
On Tue, Oct 19, 2010 at 01:36:25PM +0200, Felix Frank wrote:
>
> Subclasses that effectively disable a class are a sound concept.
Subclasses which disable a resource are a sound concept; subclasses
which attempt to negate a claass present many problems, some of which I
have described, none of which you hae addressed.
> How
> this has to be achieved in any specific case can be somewhat
> mind-boggling,
Yes, indeed. All the problems of virtual resources, other included
classes, requirement to extend the disabling class every time the basic
class is changed and so on. And you've presented no solutions to any of
those.
> but the variable approach has severe limitations of its own.
>
> 1. Where is the variable set? You have probably no problem when using
> external node definition, but not everybody does.
You can do it in an internal node definition too. Is there a law
against node definitions in your manifests? But let's assume somebody
doesnt' want to or cannot use nodes. That isn't a problem; I've
designed Puppet configurations that used no nodes at all, or a default
node which simply included a class based on the node's hostname. Still
works - just declare the variable at the right level.
> You cannot define the
> variable in an arbitrary part of your manifest, because you can be
> afflicted by both ordering and scoping issues.
I wouldn't try to declare it in an arbitrary location. I would declare
it in an appropriate location.
>
> 2. The concept of dynamic scoping is going away in future versions (at
> least that is what seems to be a community consensus). Again, if you can
> globally assign the variable value to your node, this is not a problem.
It's not that I'm in love with the way Puppet uses variables - I
certainly amd not - my objection is to the concept of trying to negate a
class by individually trying to break or undo all it's effects. That
latter option is a horrible mess. Unless the community also proposes to
do away with "if", "case" and selectors, there is always going to be a
way of saying "if { include ldap::client }" and that is
always going to be a better solution for the problem *as described by
the original poster*, which is what I was answering.
> But if you want to for every node that includes class B to automatically
> not include class A, you're out of luck (this is true in many cases
> today already, because of the scoping issues).
Well, you've finally given an example that raises a genuine problem, but
the first thing to say is that it's not the problem described by the
poster. Secondly, the problem you describe can be solved by some
variant of
if $variable {
include A
} else {
include B
}
Even if we outlaw simple variables, there are other ways to to signal
state; parameterized classes, defines, creative abuse of virtual
defines, all of them are better than the idea of negating a class
resource by resource.
>
> Variables are about as far as you can get from a panacea in the puppet
> DSL. Granted, class inheritance can be clumsy, awkward and
> unmaintainable in many cases.
Class inheritance is very elegant when used for what it is good for. It
is bad for the purposes of the original poster.
> But all that and more applies to variables
> as well, and it seems to me that variables are going to become a lot
> less useful for such purposes in the future.
Wonderful. As I said, I'm not in love with Puppet's variables. I've
worked with declaritive languages before - done major projects in XSLT
and XSLT - and I'll be delighted to see more structured, less messy ways
of working. I'd be even more delighted to see some of what are
currently functions become genuine keywords. But if you're telling me
that the community is not just proposing to remove dynamic variable
scope but also to remove the ability to say "if { include
class }", not provide any alternatives and force people to have to
clumsily override every resource in a class which they never wanted to
include in the first place, then I'm afraid that the community is an
ass. Hopefully, that's not what you're telling me.
--
Bruce
It is impolite to tell a man who is carrying you on his shoulders that
his head smells.
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] setting type defaults in some classes
On Tue, Oct 19, 2010 at 11:32:26AM +0200, Arnau Bria wrote:
> I don't remember from where I took the idea... but seems that I chose
> wrong place :-) What do you recommend me? any doc to follow?
Unfortunately, I don't think there is great documentation out there; the
core development team is too busy and so are most of the users.
Documentation lags behind. I'd love to add better documentation to
Puppet but I have a very busy and stressful job, so I fail too. But in
any case...
> > the included class had better be in the file found by the
> > autoloader). I hope that's a little clearer.
>
> Reading your answer (and if I thought a little more about it before), my
> question
> could be answered by myself. As you say import "inserts" code, so
> having 2 diff defaults in 2 diff sites does not make much sense, or does not
> behave as I wish.
Great! Now that you understand better how imports and includes work,
you're answering your own questions. I bet you can work out a better
way of laying out your manifests for yourself.
The best advice I can give you is to work with the way puppet
module/class autoloading works, not against it.
>
> If I redefine File defaults in comuting_bacula (in the class, not
> module) it's evaluted and it's more important:
>
> class computing_bacula {
> File { mode => 755 }
> }
> File { 'kaka' }
>
> on client:
> notice: /Stage[main]/Computing_bacula/File[kaka]/mode: mode changed '666' to
> '755'
>
>
> So class defaults "are more important" than site dfaults.
If there is a conflict between an already declared default and a new
default, the new default wins. If there is no conflict, they are added
together. If you go back to my example, I set a default of "ensure =
file" at the top level. Because none of the later defaults had an
"ensure" parameter, all files inherited that default. I also set "mode
= 750" at the top level, but in some places I later declared "mode"
again. In such cases, the declaration in the most immediate scope
always wins.
--
Bruce
What would Edward Woodward do?
signature.asc
Description: Digital signature
Re: [Puppet Users] setting type defaults in some classes
On Mon, Oct 18, 2010 at 11:54:49PM +0200, Arnau Bria wrote: > My fear was that declaring File description in test1 could > change/overwrite general File description. In other words, > only one default possible. Resource defaults respect traditional puppet scope rules. Resource collections, on the other hand, do not and have a global effect. I'm still not entirely sure if that is a good thing, although it can be abused in interesting ways. > > > We also have diff site.pp for diff porjects sharing main site.pp. Is > > > puppet evaluating site..p hiericaly? Or all site.pp are evaluated > > > with same importance. > > > > You're going to have to explain that in a little more detail. It's > > not clear how you have this organised. > ok. le me use site#.pp for future references: > My tree: > > ~puppet/manifests/site1.pp > /services/ >/SERA/site2.pp > /modules2 >/SERB/site3.pp > /modules3 > > -site1.pp defines some defaults and includes services/SERA/site2.pp and > service/SERB/site3.pp > -site2.pp defines its own defaults for modules2 > -site3.pp defines its own defaults for modules3 Do you mean "imports", or do you really mean "includes"? > > are defaults respected? If site1 defines mode 777, site2 defines mode > 750 and site3 mode 644, what is the default? I suppose you must really mean "include"; if you were importing those manifests and had defaults defined inside them, puppet would complain that you were defining defaults twice in the same scope and refuse to proceed. Unless the defaults are wrapped within classes. Your layout looks a little crazy. Why are you calling them all site1, site2, site3.pp? It's not a name with any special power, other than that /etc/puppet/manifest/site.pp is the default manifest for puppetd to run if you don't specify anything else. In any case, once puppet is given a starting manifest, what happens next is entirely down to your code. If you import code, it is "inserted" in place and treated as if you had typed the code directly into the file at the point where the import line is found. If you import code which contains a class, the class will not be evaluated until it is explicitly included. If you include a class that is not already in the code that has been read, puppet will try to autoload it (that is, it will look in some standard locations for manifests with specific names and *import* them if it finds them, then try and include the class - so the included class had better be in the file found by the autoloader). I hope that's a little clearer. Are you actually clear about the difference between importing and including? Which are you really doing there? Oh, and did you base that layout at all on the "style guidelines" from the wiki? Because I personally think those are terrible (sorry to whomever wrote that, but I really think it's an overcomplicated and undocumented mess, that recommended layout). Hmm. I think I spotted something. What do you mean "site2.pp defines its own defaults for modules2"? Is it posssible that site2.pp imports modules2? And that you have a bunch of classes defined in site2.pp? Because if that's the case, I have to tell you that the defaults in site2.pp are irrelevant. What counts is what the defaults are in the scope within which the classes are *included*. I'm only guessing about your code, though. I don't understand your layout and how the different parts of it are linked. -- Bruce I see a mouse. Where? There, on the stair. And its clumsy wooden footwear makes it easy to trap and kill. -- Harry Hill -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] setting type defaults in some classes
On Mon, Oct 18, 2010 at 10:58:56PM +0200, Arnau Bria wrote:
> Hi all,
>
> I'm wondering what puppet does if I define two diff type defaults (like
> file mode, owner) in two different classes. I'm trying to figure it out
> by running puppet and watching some file perms, but I see no changes.
If you're seeing no changes, you aren't testing carefully enough. See
following example:
---
File {
ensure => 'file',
mode => '750'
}
class test1 {
File { mode => '751' }
file { '/tmp/test1': }
include test3
}
class test2 {
file {'/tmp/test2': }
}
class test3 {
file {'/tmp/test3': }
}
file { '/tmp/toplevel': }
include test1
include test2
---
In the above example, files test2 and toplevel have 750 permissions,
test1 and test2 have 751. Is this not what you find? Should answer
your questions.
Resource defaults are inherited. So be careful.
>
> We also have diff site.pp for diff porjects sharing main site.pp. Is
> puppet evaluating site..p hiericaly? Or all site.pp are evaluated with
> same importance.
You're going to have to explain that in a little more detail. It's not
clear how you have this organised.
--
Bruce
I see a mouse. Where? There, on the stair. And its clumsy wooden
footwear makes it easy to trap and kill. -- Harry Hill
--
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 Application Server Deployment
On Mon, Oct 18, 2010 at 01:19:41AM -0700, ajax wrote: > Hello all, > > I wanted to know can i deploy Application Severs like JOnAS (java) > using Puppet from the server. Absolutely, you can. Puppet can deploy it as easily as any other applicaton. Where things become interesting is when you have to decide whether to deploy and configure individual Java applications to JOnAS, or how much of the configuration is done by puppet, how much through the JOnAS console. People have very different philosphical approaches to that. Nice to have the choice, though. -- Bruce What would Edward Woodward do? -- 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: Negate or uninclude a class
On Mon, Oct 18, 2010 at 07:20:10AM -0700, jcbollinger wrote:
>
> On Oct 18, 4:38 am, Bruce Richardson wrote:
> > No, you can't uninclude a class.
>
> Right.
>
> > > Is the only way to do this to inherit the base class and override all
> > > it's resources to do the equivalent of "ensure => absent", then
> > > something like "if (tagged(class)) { include undo-subclass } " where
> > > needed?
>
> [...]
>
> > You *could* do it with overrides but only If you were using a define
> > within your base class for part of the setup and that define took a
> > parameter which told it whether to include the ldap class.
>
> You could write it that way, but Puppet's subclassing feature is
> designed precisely so that you don't need to do so.
Um, I completely disagree with you and the rest of your post actually
backs this up. Class inheritence *only* makes sense if you want to
override the properties of resources. The OP wants not to include a
whole class; what you're telling him to do is not uninclude the class,
but to try and override properties in every resource owned by the class,
so as to make the class effectively do nothing. There are any number of
reasons why that's not a smart thing to do, but here are several that
occur to me immediately.
1. If the resources in the ldap::client class change, the
ldap::client::disabled will have to be changed to match. This
just begs to be a source of error.
2. The structure of the ldap::client class and it's resources may
well have to be distorted to fit this arrangement. Some resources
would have to be set up quite carefully so that they could be
"negated".
3. What do you do about virtual resources that are realized in the
parent class? You can't unrealize them and if you override their
properties, you may well conflict with other modules or classes which
use them. #
4. What do you do about any other classes that are included in the
parent class? Are you going to include "::disabled" versions of
those in the ldap::client::disabled class? What if those classes
are included elsewhere?
Your exmaple cannot achieve the same effect as not including a class;
the empty files you'd litter the filesystem with is only one example.
Forcibly negating everything in a class is not the same as not including
it. Why not just not include it?
> For example, although Bruce's main suggestion could be used if for
> some reason it were important to avoid subclasses, really in that case
> something akin to his define-based suggestion (but without subclasses)
> would be better. That way, if the LDAP client somehow gets turned on
> on your LDAP server, then Puppet will turn it back off. Unconfigured
> means "I don't care"; it must not be confused with "off". The
> subclass usage pattern above achieves the same thing with no
> conditional inclusions and no define, plus it's safe against inclusion
> of "ldap::client" by other parts of the manifest.
I'm sorry, but I think you are quite wrong and your recommendations are
very unwise. I have no objection to class inheritance at all, although
the way it works in puppet is often misunderstoon and it is often
overused as a result. Your proposed example is definitely not a good
use of class inheritance.
"ssh::server::disabled" makes sense, because that's done by overriding
the properties of an existing service resource to make sure it's
disabled. ldap::client::disabled does not make sense; the OP wants the
actions in ldap::client not to be applied, not to be differently
applied.
By far the simplest and safest way not to include a whole class is the
"if $ldap_enabled { include ldap::client }" method; it has no bad side
effects, it works no matter how the internals of the ldap::client
change, it's a tiny bit of code.
--
Bruce
I see a mouse. Where? There, on the stair. And its clumsy wooden
footwear makes it easy to trap and kill. -- Harry Hill
--
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] Negate or uninclude a class
On Mon, Oct 18, 2010 at 02:19:38AM -0700, luke.bigum wrote:
> Hi guys,
>
> Is there any functionality to negate or uninclude a class so as to
> stop it's resources being declared? I'm thinking along the lines of
> having some classes included by default, but in very select
> circumstances to not include it. For example, LDAP auth on all servers
> except the actual LDAP servers themselves.
No, you can't uninclude a class.
>
> Is the only way to do this to inherit the base class and override all
> it's resources to do the equivalent of "ensure => absent", then
> something like "if (tagged(class)) { include undo-subclass } " where
> needed?
You'll have to do it the other way round and optionally include. In the
base server class, have a little block like
if $ldap_auth {
include ldap::auth
}
Then just make sure that this variable is set true by default and set it
explicitly to false for your ldap servers, either in their nodes or
(more logically) in the ldap server class.
You *could* do it with overrides but only If you were using a define
within your base class for part of the setup and that define took a
parameter which told it whether to include the ldap class. Trivial
example:
-
define includer ( $include = true ) {
if $include {
include ldap
}
}
class base {
includer { 'setup': }
}
class child inherits base {
Includer['setup'] { include => false }
}
-
I wouldn't do it that way unless there were other specific benefits to
the define, though. The variable method is simpler.
--
Bruce
What would Edward Woodward do?
--
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: how can i determinate from one class if another class applied?
On Fri, Oct 15, 2010 at 07:06:52AM -0700, walexey wrote:
> i can't imaging something better than add
>
>if tagged(winbind) {
> $winbind = 'winbind'
> } else {
> $winbind = ''
> }
> in ldap-client class
>
> and add
> passwd: files <%= winbind %> ldap
> to nsswithch.conf template.
>
> can you show me the right way?
>
There is more than one way to do this.
A simple way would be to use a variable to indicate whether you want
winbind integration. Then anything that needs to know whether winbind
is active can just check the variable - including the piece of code
where you decide whether nor not to include the winbind class/module.
The canonical Puppet way of dealing with it is to write a custom
resource to manage nsswitch.conf. How good are your ruby skills?
I have found a way to abuse virtual define-based resources so that you
can effectively write your own custom resources in the Puppet DSL,
rather than using Ruby, which I consider to be overkill for a case as
simple as this. I will write it up when I have a moment, this weekend.
Meanwhile, if you aren't great at Ruby, I suggest the simple method I
described first.
node "host.on.which.I.want.winbind.active" {
$winbind_integration = true
include site::role::server
}
class site::role::server {
if $winbind_integration {
include samba::winbind
}
}
nsswitch.conf.erb
passwd: files <% if winbind_integration == true %>winbind<% end %> ldap
nsswitch.conf.erb
It's not the most elegant solution (not the last bit, anyway) but it
works and if you can't trust yourself to set the right variables in the
correct hosts, who can you trust?
--
Bruce
Bitterly it mathinketh me, that I spent mine wholle lyf in the lists
against the ignorant. -- Roger Bacon, "Doctor Mirabilis"
--
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] stages examples/advices
On Fri, Oct 15, 2010 at 12:19:36PM +0200, Arnau Bria wrote:
> 1.-) Stage vs require Class. May we say that stages are groups of class
> requires? So a simple/basic example:
>
> class A {
> require class B
> }
>
> class B{
> require class C
> }
>
> Is like defining :
>
> Stage[pre] -> Stage[main] -> Stage[post]
>
> class { A: stage => pre }
> class { B: stage => main }
> class { C: stage => post }
Is it the same? I haven't investigated stages, but I don't think it
would be. In your first example, Class B will not be evaluated if any
resource in class A fails. Is this true in the second example? I
actually hope not; if it is true, stages have to be used very carefully
indeed.
--
Bruce
What would Edward Woodward do?
--
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: how can i determinate from one class if another class applied?
On Fri, Oct 15, 2010 at 01:04:29AM -0700, luke.bigum wrote:
> Someone correct me if I am wrong, but defined() is useful for checking
> if types or classes exist ("are known about") but does not check
> whether a class is DECLARED - there's a difference. Note the
> documentation sentence "This is useful for checking whether a class is
> defined and only including it if it is".
You're not wrong. That said, I'd actually advice the OP against trying
this kind of thing. Generally, I find specific class dependencies are
something to avoid. The only place I tolerate them is in "role"
classes, which is where I usually set up any dependencies between
modules that are required, and there I don't need to use defined() or
tagged() to check them, because I know precisely which classes have been
included.
Every time you add a dependency to a specific class, you cause problems
for the person who finds a need to creat a new class that inherits from
it. That person will often be you and kicking yourself is not
rewarding. Looking at my manifests and modules, the *only* places I
have a dependency on a named class is in my site::role classes and in
the samba::packages class where the named classes are internal to the
samba module and contain collections of packages (and their
dependencies) relevant to specific versions of Samba.
--
Bruce
Explota!: miles de lemmings no pueden estar equivocados.
--
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] how can i determinate from one class if another class applied?
On Fri, Oct 15, 2010 at 12:40:57AM -0700, walexey wrote: > Hello everybody! > How can i determinate from one class if another class applied to the > this node? Use the defined() function. -- Bruce What would Edward Woodward do? -- 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 node names
On Thu, Oct 14, 2010 at 11:13:00PM +0100, john maclean wrote: > What gives with the hostname "config" extension and where is this set? > > > puppetca --list --all > + pclient1.config > + pclient2 > + puppet.config > That looks to me as if there is something odd in puppet.conf on your nodes. I've never seen puppet do that. -- Bruce I unfortunately do not know how to turn cheese into gold. -- 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 client log events, centralized?
On Wed, Oct 13, 2010 at 04:09:34PM -0700, Forrie wrote: > I've noticed that events for puppet client are logged locally (I'm > just starting out with puppet). Is there a way to have these events > sent to a central parser so they might be easily parsed/sorted/acted- > upon? > > I probably missed a configuration directive. http://projects.puppetlabs.com/projects/1/wiki/Reports_And_Reporting -- Bruce Get thee behind me, Stan: for it is written, thou hast gotten me into another fine mess. -- Oliver 4:8 signature.asc Description: Digital signature
Re: [Puppet Users] Variable of define is used more than once
On Wed, Oct 13, 2010 at 09:20:18PM +0200, Dennis Hoppe wrote:
> > This is almost certainly because of where you have included the monit
> > class, which is not visible in the modules you have attached here. I
> > could speculate about that, but I don't know how you've written the rest
> > of your manifests.
>
> maybe you are right. If i use something like that, my problem seems to
> be solved. Because in this case i am making a node specific declaration,
> which i have to made for all my nodes and services. But i was looking
> for some kind of automatism, because the "monit" module should come with
> certain modules, which are choosing the right "monit" config.
>
> node "rumpel" inherits "default" {
>include apticron
>include ldap::slave
>include metche
>include monit
>monit::lenny::config { "puppet": }
>monit::lenny::config { "puppetmaster": }
>monit::lenny::config { "rsyslog": }
>monit::lenny::config { "ssh": }
>include puppet::master
>include rsyslog::master
> }
What a lot of us do is create classes that describe a particular role
(like "role::storage_server") and put all the smaller classes and
specialized behaviour in that. Then you include the "role" class in the
node and declare any variables that need to be set (or overridden from
their defaults) in the node as well. That keeps the node definition
tidy but also means, since all classes are included at the individual
node level, that the classes pick up the variable values specific to
them.
So I might define a site::role::basic_server class which included monit
and apticron. Then I'd define site::role::puppetmaster, make that
either inherit from or include site::role::basic_server (whichever is
most appropriate), have it define monit::config { "puppetmaster" } and
include puppet::master (and so on). Then I'd have the rumpel node
include site::role::puppetmaster.
The benefits I get from this are a) the ability to assign the same role
to multiple nodes (or to reassign the role from one node to another)
simply and clearly, b) to be sure that the value of any important
variable can be overridden for any one node, c) ... oh, there are other
benefits but those two are good.
I'm not saying that you shouldn't include more than one class in a node,
particularly if you have specialist classes which aren't often used, but
roles are very helpful, especially where you want to establish
particular dependencies between particular modules or classes.
> > You have so many duplicate classes that you're bound to slip somewhere
> > and make the change in one version and not in the other (or do it
> > slightly differently in the other). That kind of thing can be very
> > difficult to trace.
>
> Right, some other people at this mailing list already gave me that
> advice. I know that i have a lot of duplicated code, but i thought this
> would be easier to maintain, if a release is getting end of live status.
Which Debian release you are using is really a minor detail; the intent
behind (for example) a monit module remains the same. In fact, in the
two modules you have included, your twinned lenny/squeeze classes are
*identical* apart from the class names themselves. Even the templates
are identical. You are wasting a lot of time duplicating things that
are the same. I'm a litle confused to see no package dependencies in
those modules - really, a module should be a self-contained unit that
contains everything that describes the core function. Even if you
decide you want a special package-handling module (which can look
attractive when you first come to Puppet but really is normally not
worth it), you should be realizing those packages in the relevant
module.
--
Bruce
It is impolite to tell a man who is carrying you on his shoulders that
his head smells.
--
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] Problems with Solaris 10 & adduser
On Tue, Oct 12, 2010 at 07:59:40AM -0700, nickt wrote: > > err: /Stage[main]/User::Virtual/User[user1]/ensure: change from absent > to present failed: Could not create user user1: Execution of '/usr/ > sbin/useradd -s /bin/bash -c "Full Name" -d /u/user1 -m user1 returned > 1:" What happens if you run /usr/sbin/useradd -s /bin/bash -c "Full Name" -d /u/user1 -m user1 from the command line. -- Bruce Hierophant: someone who remembers, when you are on the way down, everything you did to them on the way up. signature.asc Description: Digital signature
Re: [Puppet Users] Variable of define is used more than once
On Wed, Oct 13, 2010 at 07:05:29PM +0200, Dennis Hoppe wrote:
>
> node "rumpel" inherits "default" {
> include apticron
> include ldap::slave
> include metche
> include puppet::master
> include rsyslog::master
> }
>
> node "samson" inherits "default" {
> include apticron
> include ldap::node
> include metche
> include puppet::node
> include rsyslog::node
> }
>
> If i run "puppetd --test --verbose" on host "rumpel" it is getting the
> "monit" configs for "puppetd" and "puppetmaster", which is intended to
> be. But the host "samson" is also getting the config for "puppetmaster",
> which is reproducible.
This is almost certainly because of where you have included the monit
class, which is not visible in the modules you have attached here. I
could speculate about that, but I don't know how you've written the rest
of your manifests.
One thing, though: you have a huge amount of duplicated code there; it's
more work than you need to do and a potential source of error. Your
lenny and squeeze monit classes, for example, are almost identical; it
would make much more sense to have one class and use selectors ("if",
"case" etc.) for the minor bits which are different. As things stand,
if you change the structure of your monit module, you'll have to make
changes twice: once in the lenny version, once in the squeeze version.
You have so many duplicate classes that you're bound to slip somewhere
and make the change in one version and not in the other (or do it
slightly differently in the other). That kind of thing can be very
difficult to trace.
--
Bruce
What would Edward Woodward do?
--
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 of define is used more than once
On Wed, Oct 13, 2010 at 11:07:27AM -0400, Disconnect wrote: > > Note that I didn't reply to the OP, I replied to Nigel's sarcasm. > You could take this up with one of the Debian puppet package maintainers. Oh, but then you already have... -- Bruce I unfortunately do not know how to turn cheese into gold. -- 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: serialized or limited parallelism
On Tue, Oct 12, 2010 at 08:48:30AM -0700, Philip Brown wrote: > > Is it crucial that the data be current at the beginning any puppet run? > > Is the data itself used in configuring the host, or is it just the > > presence of current data that has an effect on how/when puppet runs? > > > > Weeelll.. this PARTICULAR data, is more just inventory type data. it > is not crucial to the puppet run itself at all. Then I really do advise you not to use Puppet as the transport. Use puppet to set up the data collection and transmission/retrieval processes and let them run independently. > > However, in the future, we will have more interest in adding on > random scripts that need to be run on all machines, but not at > exactly the same time And will *those* be integral to Puppet's operation, or are you just hoping that Puppet can provide you with a way of managing parallel execution? -- Bruce If the universe were simple enough to be understood, we would be too simple to understand it. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Prefixing syslog messages with client names
On Tue, Oct 12, 2010 at 02:27:51PM +0200, Kenneth Holter wrote: > Hi. > > > The puppetmaster is set up to log to syslog, which is working fine. The > downside is that most of the log entries created by the puppetmaster does > not indicate which puppet client that message if from. So basically I have > lots and lots of syslog entries created by the puppetmaster, but no way of > telling which client it references. Just to be clear, you are having your puppet clients tell the puppestmaster what they are doing and then the master is logging that? > > Is there any way to have the puppet master prefix each syslog message with > the name of the client the log message is for? I think it is better to have puppet clients logging to local syslog. You can always configure your syslog daemon to replicate this to another host (rsyslog or syslog-ng will both do this for you quite easily) or have logwatch track it. The benefits of this are a) log redundancy, b) you get to see what the client is doing even when the puppetmaster is down (or not visible to the client) and c) less load on the puppetmaster (logging can become a significant extra load if you have a large network). -- Bruce Explota!: miles de lemmings no pueden estar equivocados. signature.asc Description: Digital signature
Re: [Puppet Users] Re: serialized or limited parallelism
On Mon, Oct 11, 2010 at 06:44:20PM -0700, Philip Brown wrote: > BUUT... maybe I am thinking about this all wrong after all. Possibly > the better way is to give facter a custom set of facts... and then > since facter output gets automatically stored on the master when > puppet runs on the client If you're running storeconfigs, which isn't a given for everybody, not least because it can cause scaling problems of its own (memcached backend for storeconfigs will be such a win). >, that would be a better source for the > repository...? If the data you are feeding back really is directly relevant and important to your puppet configuration rather than incidental, then yes. If you hit scaling issues, though, you'll either need to be looking to an alternative method of delivering and storing the data that does scale well or enhancing your puppet infrastructure (the mcollective suggestion was a good one). Is it crucial that the data be current at the beginning any puppet run? Is the data itself used in configuring the host, or is it just the presence of current data that has an effect on how/when puppet runs? -- Bruce Explota!: miles de lemmings no pueden estar equivocados. -- 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] serialized or limited parallelism
On Mon, Oct 11, 2010 at 02:09:54PM -0700, Philip Brown wrote: > > Example: > Lets say that I want all machines to run some sort of job, that > updates a central database with information about the state of each > puppet client. > > Lets also say, that I have 1000 machines, so if all of them decide to > do it at the exact same time, it would be a Bad Thing. > So I ideally would like some kind of puppet mechanism that says, > "run this script... but only if there are less than 10 other machines > doing the same thing at this particular moment)" It may be simply that your example isn't the best expression of what you want, but I wouldn't do it that way. The first point is that I don't see Puppet as a way of making hosts do things, I see it as a way of making them conform to a desired state. If that's a state where they can pass information back (or have it gathered from them) then fine, but I'd use Puppet to set that up, not be the conduit. A more prosaic reason for not using Puppet as the information transport mechanism is that a puppet run already puts enough of a load spike on the client and master; don't see a good reason to add to that. I also think that such a mechanism would be complex and fragile and have real problems scaling. I would look at using snmp traps to relay that information; it wouldn't be hard to use puppet to create a distributed system which could cope with the load. Do you have an example that would make a more direct case for puppet having the kind of mechanism you're looking for? -- Bruce If the universe were simple enough to be understood, we would be too simple to understand it. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] tidy resource logging conflict
On Wed, Oct 06, 2010 at 09:18:07AM -0700, Patrick wrote:
>
>
> I didn't quite understand what you said.
Here's an example manifest that demonstrates both problems:
file { '/tmp/shared': ensure => 'directory' }
file { '/tmp/shared/notice': ensure => 'file' }
file { '/tmp/shared/verbose':
ensure => 'file',
loglevel => 'verbose'
}
tidy { '/tmp/shared':
recurse => true,
loglevel => 'verbose'
}
The first issue is about loglevel; at puppet's default logging level,
only the creation of the first two resources should be logged. In fact,
the actions of the first two and the final (tidy) are logged, because
tidy is ignoring loglevel.
The second issue is that puppet is logging actions that do not take
place. The tidy resource should delete all files in /tmp/shared *apart*
from the ones created in the manifest. This is expected behaviour and
this is what it does. It's a handy way of making sure that a directory
tree contains *only* the files you mean to be there. However, the
imaginary deletion of those files is being logged. And because it is
imaginary, and the files remain in place, it's logged on *every* run.
>I hope this general rule helps:
>
> If puppet is logging something about a resource every run AND not
> changing anything AND not failing, I think you should file a bug.
Done.
--
Bruce
Explota!: miles de lemmings no pueden estar equivocados.
--
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] tidy resource logging conflict
On Wed, Oct 06, 2010 at 02:06:29PM +0100, Bruce Richardson wrote: > I think it would be reasonable of puppet not to log the tidying of files > which are not actually tidied. Do people agree? In which case I'll > file a bug report. Or have I missed a clean way of resolving this? In fact, I'm finding that I can't do anything to change the loglevel on any tidy resource. This is using Puppet 0.25.5. I don't see any closed or open bugs on this topic in Redmine - can anybody else check and see if this is an issue or has been resolved in 2.6 ? -- Bruce Remember you're a Womble. -- 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 push mode
On Wed, Oct 06, 2010 at 03:19:27PM +0200, Peter Meier wrote: > On 10/06/2010 03:17 PM, Mikel King wrote: > > I am in a similar but different situation. I need to have puppet check > > in only upon boot up and then shutdown until next boot. Does anyone > > know a puppet way of handling this our should I resort to basic sh > > scripting to accommodate this? > > @reboot if your cron supports that? If it doesn't, every Linux distribution and *nix has a set of initscripts (rc scripts on BSDs) that run only on boot. Just run the puppet (rather than puppetd) binary from there. -- Bruce A problem shared brings the consolation that someone else is now feeling as miserable as you. -- 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] puppetd memory consumption
On Wed, Oct 06, 2010 at 03:18:44PM +0200, Peter Meier wrote: > > about how many files are we talking under the hierarchy of the recurse > file resources? and how big are they? And which filesystem type. Some are much more painful to walk than others. -- Bruce What would Edward Woodward do? -- 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] tidy resource logging conflict
One of the nice features of using the Tidy resource to prune a directory hierarchy in puppet is that any File resources you create within that tree will not be touched. However, the tidy resource *will* log that it is tidying them. This is not good. I like puppet to log any changes it makes so that logwatch can pick them up - puppet should only need to make changes if the state of the node is not as described. Unfortunately, with the Tidy logging as it is, where I want to tidy any files not managed by puppet I either have to set the loglevel for the tidy resource so that it doesn't log *anything* or suffer spurious log messages and explicitly filter them out on the logwatch side. I think it would be reasonable of puppet not to log the tidying of files which are not actually tidied. Do people agree? In which case I'll file a bug report. Or have I missed a clean way of resolving this? -- Bruce A problem shared brings the consolation that someone else is now feeling as miserable as you. -- 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] Puppetd attempting to install packages that aren't required
On Tue, Oct 05, 2010 at 12:16:28AM -0700, ncantor wrote:
> In order to get the package to only install on the systems that I
> wanted to have it, I had to move it from a general package definition
> to be inside a class. Is this normal behaviour?
Yes. If you do want packages to be visible at the top level, to
absolutely everything, but only installed when you want them, then you
should make them virtual resources and then realize them where you need
them.
What is your motive for defining packages at the top level? As with
most resources, it's usually better to define them within the
classes/modules which need them and just include the class. This allows
you to concentrate on high level function (e.g. "This node should get
its user and group data from an ldap server at $uri") in your main
config and keep the low level details ("On Debian, the nss_ldap config
file is '/etc/libnss-ldap.conf'") hidden within the module.
--
Bruce
I object to intellect without discipline. I object to power without
constructive purpose. -- Spock
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Puppet truth, nil and templates
Does Puppet have any genuine concept of truth and nil that survives the interface with Ruby? has_variable? only returns false if a variable has never been assigned a value at all in the enclosing scope; there is no way to assign undef to a regular variable (as opposed to a resource parameter) within a scope and so make it undefined for the template. It would be a very useful thing to be able to do; makes for much cleaner code. Have I missed something? -- Bruce I object to intellect without discipline. I object to power without constructive purpose. -- Spock -- 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] mount type attempting remount when ensure => present
On Fri, Oct 01, 2010 at 08:55:34AM -0400, Rob McBroom wrote: > I've added a use case to the bug report. > > On Oct 1, 2010, at 4:30 AM, Bruce Richardson wrote: > > > According to the online documentation (which is autogenerated), "Set to > > present to add to fstab but not change mount/unmount status " > > Where are you seeing that? For as long as I've used Puppet, the type > reference has said: “Set this attribute to present to make sure the > filesystem is in the filesystem table but not mounted (if the filesystem is > currently mounted, it will be unmounted).” http://docs.puppetlabs.com/references/latest/type.html#mount > > See <http://docs.puppetlabs.com/guides/types/mount.html#id75> Some inconsistency on the site, then. -- Bruce Remember you're a Womble. signature.asc Description: Digital signature
Re: [Puppet Users] mount type attempting remount when ensure => present
On Thu, Sep 30, 2010 at 02:13:08PM -0400, Rob McBroom wrote: > > According to the documentation, that's how `ensure => present` is > supposed to work, though I can't imagine the use case for “put it in > fstab but make sure it's never mounted”. According to the online documentation (which is autogenerated), "Set to present to add to fstab but not change mount/unmount status " Which is the opposite of what you say it is doing. But I believe you, because I know I've seen this behaviour reported before, although it may have been on this list and not in a bug report. -- Bruce I see a mouse. Where? There, on the stair. And its clumsy wooden footwear makes it easy to trap and kill. -- Harry Hill signature.asc Description: Digital signature
Re: [Puppet Users] Overwrite default settings in nodes using external nodes.
On Wed, Sep 29, 2010 at 02:59:28PM +0200, Héctor Rivas Gándara wrote:
>
> Also, from my tests I checked that the parameters (please correct me if I am
> wrong):
> - Are stored in global scope: All classes has access to it.
No. The parameters have "node" scope. Any class included within the
node will be able to see the node's values.
> - But if a class defines that parameter, it is used the class value.
Yes. If you want to be able to set a default within a class, but have
that possible to be overridden, you can do something like this:
class example {
if $example_variable {
$variable = $example_variable
} else {
$variable = 'Default Value'
}
}
Personally, I try to avoid setting default values within classes.
> But I do not like too much the extlookup solution because:
> * I can not define a common subset of groups that all host will inheret
> (except the ones that overwrite this value). May be using again the
> "default_connect_allowed_groups" variable.
There's no nice way to do it. Aas I understand it, Puppet's external
nodes code doesn't support arrays, let alone appending to arrays. Every
time I look at using external node classifiers, I walk away from it
again. If I were managing sites of such a scale that it were
unavoidable, I'd be an unhappy person (time to dust off the Ruby
skills).
> * I think that is bad to have configuration in two places: external nodes
> and cvs's files.
I agree.
--
Bruce
A problem shared brings the consolation that someone else is now
feeling as miserable as you.
--
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] Variables with class inheritance and templates
On Tue, Sep 28, 2010 at 09:01:25AM -0700, Darren Worrall wrote: > > Is this a bug, or a limitation of class inheritance? (ie, base classes > are evaluated completely, and subclasses are only allowed to modify > things after the fact?) > They're not classes, they shouldn't have been called classes, it only upsets people who understand OO languages and make intelligent assumptions based on this. The only things you can really override in a subclass are properties of resources defined in the superclass. This is almost the only thing that class inheritance is useful for (not quite, but the points are quite subtle and you need to have banged your head on some of Puppet's walls before you can appreciate them). Don't set variables to explicit variables inside a class unless you really know what you are doing. For the most part, set variables at manifest or node level and include your classes at the appropriate level. If you get your head around the way this works, some of it is very powerful and elegant. But whatever the party line, some of it is also inelegant and hard to work with. I tend to use node inheritance trees for defining variables at the appropriate level and class heirarchies to define function. Then I include the appropriate high-level classes in the right nodes. With care, you can minimise the verbosity in node definitions but it is still noisier than it should be, because of the inheritance model. Look around at the way most people write their puppet configs and you'll find node definitions littered at the top level with all the classes a node needs, because it isn't safe to include them earlier if you're going to want to override values for a subset of nodes. This makes node configuration repetitive where it should be DRY and a potential source of error. Still, puppet's the best option around. -- Bruce The ice-caps are melting, tra-la-la-la. All the world is drowning, tra-la-la-la-la. -- Tiny Tim. -- 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 way to include a variable in many modules ?
On Thu, Sep 23, 2010 at 08:31:26PM +0100, R.I.Pienaar wrote: > > I have two sites with a small number of machines at each. Each site is > > functionally identical. I would like to set up a bunch of templates > > for the various services at each site, with a handful of variables that > > indicate which site the service is configured for. What would be > > "best practice" way to accomplish this in Puppet ? > > > You should consider using extlookup. > > http://docs.puppetlabs.com/references/2.6.1/function.html#extlookup Why? It seems odd to be stepping outside the puppet DSL for something so basic. -- Bruce If the universe were simple enough to be understood, we would be too simple to understand it. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] exec and subsribe
On Fri, Sep 24, 2010 at 01:32:15PM -0700, Luc Suryo wrote: > Hello > > simple question ... if 2 or more EXEC subcribes to a file and that file is > changed would > then all the EXECs be run ? Yes - unless some other condition prevents it (e.g. a failed dependency). > or does it depend whatever the FILE notifies the > EXEC? No. Notify and subscribe set up the same relationship, just like before and require. -- Bruce Remember you're a Womble. -- 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 practice using puppet and SVN in a production environment
On Sat, Sep 25, 2010 at 07:34:19AM -0700, Christian wrote: > Hello community, > > As you all know a good infrastructure deployment in production state > should not involve much technical infrastructure staff anymore. > Routine work should be able to perform by the users themselfs who > should not know anything about the infrastructure implementation > details. I don't think I agree with this, but nothing in your message makes it clear what you mean by "users". What kind of systems are you managing, what is the relationship between you and the users (are they people in another department, customers or what?) and what are their skills? -- Bruce Hierophant: someone who remembers, when you are on the way down, everything you did to them on the way up. -- 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] Users with puppet
On Tue, Sep 21, 2010 at 09:43:26AM +1000, Daniel Pittman wrote: > > I read up on user and group creation and ssh key distribution. The only > > thing i cant wrap my head around is how i should handle passwords. > > I would strongly advise that you deploy an LDAP backed PAM and NSS system, > rather than trying to do all this locally. While it introduces another > dependency into your boot process and network, it substantially reduces the > complexity of doing all this. I absolutely second this. Puppet modules to integrate LDAP into PAM and nsswitch are trivial to write, moving all the complexity into the LDAP servers (which aren't really that complex and can be made robust with little effort). Without centralised authentication, managing users across a large number of systems is asking for trouble unless the number of users is small and there is little variation in their configuration. -- Bruce Bitterly it mathinketh me, that I spent mine wholle lyf in the lists against the ignorant. -- Roger Bacon, "Doctor Mirabilis" -- 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, 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 (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. You're still trusting the client. It's the wrong approach (I'm not criticising you personally, Puppet doesn't leave you much choice if you want to use environments), it's vulnerable to error, fragile and potentially insecure. -- Bruce I unfortunately do not know how to turn cheese into gold. -- 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 Tue, Sep 14, 2010 at 08:34:00AM -0400, Ryan Coleman wrote: > Hi Oliver, try: > > http://projects.puppetlabs.com/projects/1/wiki/Using_Multiple_Environments I've never been fond of the way RoR treats environments (or, at least, the way RoR developers treat them). The thing I really don't like about the way Puppet implements them is the fact that the *client* specifies which environment to use. This is just plain wrong. At the very least, the puppetmaster should be able to ignore or override the client's idea of which environment to use on a per host basis. -- Bruce I see a mouse. Where? There, on the stair. And its clumsy wooden footwear makes it easy to trap and kill. -- Harry Hill signature.asc Description: Digital signature
Re: [Puppet Users] Puppet high-availability
On Tue, Apr 13, 2010 at 07:57:25PM -0700, Scott Smith wrote: > On 4/13/10 3:26 PM, SyRenity wrote: >> Hi. >> >> I asked this question in past on this list, and now working to set it >> running. >> >> My idea is to have 2 Puppet servers, who are also the DNS servers. >> Each one would have itself as the puppet hostname. >> Both of the servers will pull the manifests from external git repo. > > Just set up HAproxy and load balance them. Done. And then don't forget to make your HAproxy config HA, of course. Or whatever it is you choose to use for load balancing (e.g. LVS). If you want to make your DNS/puppet cluster completely self-contained, you could use Hearbeat to make them an HA pair, assign a "float" address for your official puppetmaster service and have Heartbeat manage that (and any services which need to be associated with it). -- Bruce It is impolite to tell a man who is carrying you on his shoulders that his head smells. -- 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 commands giving nothing but a stack trace
On Fri, Apr 09, 2010 at 08:56:39AM -0400, Rob McBroom wrote: > > Bingo. Someone had set it to 128 for all users (without my knowledge). > I changed it to only affect the relevant users and Puppet fires right > up. Thanks. You're running Puppet and somebody changed the ulimit config on the box without telling you? There's ironic and there's plain contrary. -- Bruce Explota!: miles de lemmings no pueden estar equivocados. signature.asc Description: Digital signature
Re: [Puppet Users] is puppet the right tool for me?
On Thu, Apr 08, 2010 at 11:31:18AM +0400, Dmitry V'yal wrote: > Also, currently we're planning to change the geographic location of vps > and to move from gentoo to ubuntu. Looks like a perfect time for big > changes. There's never a perfect time for big changes. Change one thing at a time wherever possible. -- Bruce Hierophant: someone who remembers, when you are on the way down, everything you did to them on the way up. -- 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] How to push config from master ?
On Mon, Apr 05, 2010 at 04:54:30PM +1000, Daniel Pittman wrote: > >>> thank you so much for the reply. i have bunch of webserver, i want to able > >>> be able run svn update to all the webserver from master. > > this is not what puppet specializes in. you can probably do it, but you will > almost certainly find it more productive to use some alternate tool to > implement this feature. I don't understand why so many puppet people say this. Cfengine users do this kind of thing all the time (it's one of the very few things that is possibly slightly easier in Cfengine and is perfectly secure; you can't run arbitrary commands remotely via cfengine any more than you can with puppet). Cfengine does this by allowing you to define arbitary "classes" (which in cfengine means named conditions which are either defined/active or undefined/inactive) when you trigger a run of cfengine either locally or remotely. It's perfectly secure because all you can do is trigger whatever actions are associated with that "class" in the client's config file. The worst you can do is DOS the client machine by repeatedly triggering cfengine (and there are ways to protect against that). Seems to me that the same thing can be achieved with puppetrun and tags (or custom facts or some method you roll for yourself of communicating arbitrary conditions to puppet). What am I missing? -- Bruce I must admit that the existence of Disneyland (which I know is real) proves that we are not living in Judea in AD 50. -- Philip K. Dick -- 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] is puppet the right tool for me?
On Wed, Apr 07, 2010 at 12:10:07PM -0700, Dmitry V'yal wrote: > Hello, > > I'm currently administering a vps running a dozen of php-sites. I use > several scripts for deploying new sites, updating them, taking the > backups and so on. All the system is quite fragile and error-prone. > I'm thinking about some more integrated solution. Can puppet be useful > in my situation? Or is it primarily intended for managing big number > of similarly configured hosts? The latter, but that doesn't necessarily mean puppet couldn't be useful to you. After all, puppet lets you define dependencies so that you can specify that action A is triggered when file B is modified, action C happens if acion A is successful and so on, which must describe half of what your scripts do. It also lets you define templates and then create multiple instances based on those templates and different configurations, which must be the other half of what you do. So I think it can help you. And you may find other things about your vps that it can configure for you. I would create a definition that describes your site layout. Each time you invoke that definition in your script, with different parameters, it'll create the site for you and trigger any necessary actions (like restarting apache). You can also have the directory hierarchy that contains your sites managed by puppet in such a way that it will delete any files that weren't created by your current puppet config. That way, all you have to do is remove the description of a site from your config and all the files previously generated for it will be removed the next time puppet is run. You don't need a puppetmaster to run puppet, you can run it on a single host from local standalone scripts. So you don't need to incur the overhead of running puppetmaster and puppet daemons just for your sites. Of course, you can do this yourself by choosing your own templating system and writing scripts to manipulate it, but puppet can make it much simpler. -- Bruce If the universe were simple enough to be understood, we would be too simple to understand it. -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-us...@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] managing secondary groups
On Mon, Mar 15, 2010 at 09:31:54AM +, Dick Davies wrote: > Offhand, does anyone know the difference between the 2 > constructs below to manage secondary groups ? > This is the 'groupadd' provider I think (CentOS). > Think I'd prefer the former if the result is the same The result will be the same. How did you think it might be different? The path to execution within Puppet will be different, which may or may not matter to you. -- Bruce Remember you're a Womble. -- 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] cfengine like groups
On Mon, Feb 01, 2010 at 05:30:47PM -0600, Anchi Zhang wrote:
> Greetings,
>
> CFEngine 2 (not sure about 3) allows groups definitions such as
>
> groups:
>ntp = { ntpserv1 ntpserv2 }
>
> and the ability to negate such as
>
> links:
> !ntp::
> /etc/inet/ntp.conf -> /etc/inet/ntp.client
>
> I was wondering how I would accomplish something like it in Puppet.
Puppet really works very differently from cfengine and you have to think
in different ways. CFEngine allows you to define arbitary classes
(which means something different in puppet ;) ) based on any logical
combination of already defined classes and to associate actions with
classes. Puppet works with dependencies and it doesn't do groups (which
in CFengine are actually just "classes" which are true if the hostname
matches one of the strings in the given list).
For the simple example you give above, you'd define an ntp class (puppet
style) which created the link (and any other ntp configuration you
require) and then in the node declaration for that host you would
include the ntp class. You can still think of the ntp class as being a
group, if you like, but you declare in the node which "groups" a host is
in.
There are a number of ways to implement group behaviour, though. One is
to use case statements
http://reductivelabs.com/trac/puppet/wiki/LanguageTutorial#case-statement
The problem is where to place such a case statement within your
manifests; if it is included outside of a node declaration then it
doesn't have any access to the variables and classes memberships
declared in the node config. But if you put it in the node declaration,
you have to make sure it is included in every node declaration
(cumbersome, error prone and ever so slightly defeating the point).
Another way is to use an External Node service.
http://reductivelabs.com/trac/puppet/wiki/ExternalNodes
This lets you store your host data in, for example, a Directory service
like LDAP. Most such services will let you define groups where you can
specify a list of nodes and when you then interogate the Directory
service for details of an individual host (which is how Puppet needs the
data), it'll give you back the group memberships as part of that. So
you need to map groups in your directory onto classes in your Puppet
config.
This isn't exactly a lightweight solution either and is a lot of work if
you didn't need this feature for anything else.
There are other ways to do it, but they do mean working against puppet's
design and it can be painful.
FWIW, I really don't like the way nodes work in puppet and have been
trying to work round that every since I started using it.
--
Bruce
What would Edward Woodward do?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-us...@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Notifying a service when exported resources go away
On Tue, Jul 28, 2009 at 11:19:07AM -0400, Eric Gerlach wrote: > > But if I do this, it still doesn't notify the nagios service, so it will > continue to monitor them (and complain to me that they're gone) until I > restart > it. So though that's a nice way to purge the DB, it doesn't really help my > problem. I have to say, I'm unconvinced by the whole storedconfigs mechanism, particularly for this kind of thing. If you're using puppet to configure most or all aspects of your hosts on the network, then your central puppet config already stores enough information about all your hosts to generate a nagios config centrally and push it to the monitoring host. Pushing all this information back from the clients to the puppetmaster and then out again seems to me to be desperately fragile and just asking for trouble. -- Bruce I object to intellect without discipline. I object to power without constructive purpose. -- Spock --~--~-~--~~~---~--~~ 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: File resource type: critical chmod security issue
On Tue, Jul 28, 2009 at 10:47:07AM +0200, Peter Meier wrote: > > Hi > > >> For sure you have to manage the content of each subdirectory separately > >> as they're managed on their own. > > > > I'm sorry, but that fails as far as I'm concerned. I shouldn't be > > having to specify common behaviour multiple times. > > well either your managing a resource or you're not. Something between > will just lead to too many problems and conflicts. or which easier way > do you envision without having these problems? > OK, maybe I didn't express it clearly enough. Puppet won't let me specify one behaviour for /a and another for /a/**. As I said, there are valid reasons for wanting that. -- Bruce A problem shared brings the consolation that someone else is now feeling as miserable as you. --~--~-~--~~~---~--~~ 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: File resource type: critical chmod security issue
On Tue, Jul 28, 2009 at 10:27:57AM +0200, Peter Meier wrote: > For sure you have to manage the content of each subdirectory separately > as they're managed on their own. I'm sorry, but that fails as far as I'm concerned. I shouldn't be having to specify common behaviour multiple times. -- Bruce Those who cast the votes decide nothing. Those who count the votes decide everything. -- Joseph Stalin --~--~-~--~~~---~--~~ 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: File resource type: critical chmod security issue
On Mon, Jul 27, 2009 at 11:01:16PM +0200, Peter Meier wrote: > > Is there a consistent culture or policy in the Puppet community to > > override explicit security configurations? It must be explicitly > > avoided in an audit, if that's the case. If there is no policy, > > perhaps we should define one? > > the only existing culture is that for file resources directories > automatically get the execute bit. I don't yet see why you'd like to > have a directory without the execute flag set, maybe you can explain? On a slight tangent, how about having 755 on a directory but (for example) having 700 or 600 recursively on all the managed directories and files underneath it (and maybe different ownership as well). There are valid reasons for wanting to do this but the last time I tried it, I found it impossible with puppet. Maybe I should look again to see what I missed. -- Bruce I object to intellect without discipline. I object to power without constructive purpose. -- Spock --~--~-~--~~~---~--~~ 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: set password of root
On Wed, May 06, 2009 at 02:02:42PM -0500, Evan Hisey wrote: > > > > But it will still show up unencrypted in processlist. > > > Only on the puppetmaster server, and this would happen no matter how > you generate the password encryption. Not true. There are several utilities that can read from stdin or a file to generate an encrypted passwrd, like mkpasswd. -- Bruce Remember you're a Womble. --~--~-~--~~~---~--~~ 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: set password of root
On Wed, May 06, 2009 at 04:02:54PM +0200, Bj?rn Dyre Dyresen wrote: > It's easy enough to just use sed in a exec to updatet the hash in shadow. I > agree that having a clear text root passord floating around is a bad idea. > That would lead it to be in the manifests, in subversion, in syslog and > probably in the yaml cache like Chad said. Most Linux distributions include a utility called chpasswd, which can read username/password pairs (with the password encrypted) from stdin. It's reasonably secure (you could, for example, push out a file with 400 permissions and then feed it to chpasswd locall6), respects login.defs and is safer than simply running sed against the shadow file. -- Bruce Bitterly it mathinketh me, that I spent mine wholle lyf in the lists against the ignorant. -- Roger Bacon, "Doctor Mirabilis" --~--~-~--~~~---~--~~ 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: I'm struggling with testing configuration changes locally - how to verify templates, syntax, results without checking in manifests
On Mon, Mar 23, 2009 at 09:03:27PM -0700, jawspeak wrote: > > Can anyone point me to a simple way to force a local puppetmaster to > work against my current SVN working directory. And push the changes > locally to my puppetd running? So I can see if I will break things > without checking in? You could use environments for this. Configure your puppetmaster so that the paths for your testing environment point to your SVN checkout and force the environment for the test. http://reductivelabs.com/trac/puppet/wiki/UsingMultipleEnvironments -- Bruce If the universe were simple enough to be understood, we would be too simple to understand it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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: how to override hostname
On Mon, Mar 23, 2009 at 05:18:55AM -0700, thomas wrote:
>
> I am trying to test stand alone puppet manifests invoking /usr/bin/
> puppet.
>
> Is there a way to override current hostname with some other value?
You can override any fact within a class or node, you just can't set it
at the top level.
So you can test things by doing something otherwise odd like:
node default {
$hostname = 'testname'
include test::class
}
--
Bruce
A problem shared brings the consolation that someone else is now
feeling as miserable as you.
--~--~-~--~~~---~--~~
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] apt-get, exec and a simple lesson
Somebody had this problem back in Feb, where "apt-get update" failed and
I have found the solution.
So I had these two simple classes
class debian::apt::sources {
if $debian_apt_sources {
$debian_apt_sources = $debian_apt_sources
} else {
$debian_apt_sources = "#No content specified. Fix me!\n"
warning( "Warning: no content specified for
debian::apt::sources" )
}
file { '/etc/apt/sources.list':
mode => 444,
owner => root,
group => root,
content => $debian_apt_sources,
}
}
class debian::apt::update {
exec { 'apt-get update':
path=> '/usr/bin',
subscribe => File['/etc/apt/sources.list'],
refreshonly => true,
}
}
Sometimes, apt-get update would fail with a generic "returned 100
instead of 0" error. Googling found that a few people had encountered
this, with no solution that i could see. I tracked it down to an error
returned by bzip2, when downloading bzipped packages lists. Moment of
revelation was when I realised that apt-get is in /usr/bin but bzip2 is
in /bin (on Debian, anyway). Changing the debian::apt::update class to
have
path=> '/bin:/usr/bin'
fixed it. So apt-get obviously doesn't use a hardwired path for bzip2
and expects to find it on the PATH. Silly me. Google tells me that a
bunch of Ubuntu and Debian-based consumer devices out there have this
problem as well, doubtless because apt-get has been wrapped in some
custom front-end that makes the same mistake I did.
--
Bruce
Explota!: miles de lemmings no pueden estar equivocados.
--~--~-~--~~~---~--~~
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: Module dependancies.
On Thu, Mar 19, 2009 at 10:13:59AM +, Craig Dunn wrote: > > Whats the best way of depending on a module - for example, I have an lvm > and a mysql module - on booting a clean machine it's important that lvm > be set up before the mysql rpm installs as I want mysql on a volume. I > can't see an easy (clean) way of making sure the mysql module installs > after the lvm module apart from depending on some resource that the lvm > module creates, which seems a bit dirty. > > Is there a better way of doing this? There's no direct way to set up module/class dependencies, no. You can have the main class in your mysql module include the main class in your lvm module, you can do it indirectly through requiring a resource, as you've spotted. For my own purposes, I think I'm going to have to create a generic module named "package", so that I can define package::$packagename classes for any packages that may require special treatment. That way, if I were solving your particular problem, I'd have a resource in the lvm module set to "require => Class[package::lvm']". I'd do it that way because, as I just recently established, this requirement will be satisfied by anything that inherits from 'package::lvm', which allows me to extend the behaviour of the lvm class in different contexts, transparently. -- Bruce Those who cast the votes decide nothing. Those who count the votes decide everything. -- Joseph Stalin --~--~-~--~~~---~--~~ 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: defined() ambiguity?
On Thu, Mar 19, 2009 at 10:12:39AM +, Bruce Richardson wrote: > This isn't an idle line of thought, by the way. There's obviously a lot > of interest in class/module dependencies, which are not easy to create > or test. Puppet would benefit from having a test for whether or not a > specific class has been included and, I think, for whether or not a > specific class *or one that inherits from it* has been included. It's nice to find, though, that "require => Class[$classname]" will create a dependency on $classname *or any class that inherits from it*. I don't think that's documented anywhere - hope I can remember my username/password on the wiki. -- Bruce Bitterly it mathinketh me, that I spent mine wholle lyf in the lists against the ignorant. -- Roger Bacon, "Doctor Mirabilis" --~--~-~--~~~---~--~~ 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] defined() ambiguity?
"defined($classname)" will return true if puppet code that describes the named class can be found, whether or not the class has been included. On the other hand, "defined(File[$filename])" will only return true if the code describing the file has been evaluated and the file "instantiated" (difficult to find the right words to describe how puppet behaves, given it's eccentric use of words like "class" and "define"). These are really two significantly different meanings to "defined" and I wonder if it's helpful to be using the same function for both. I do think it's potentially confusing. This isn't an idle line of thought, by the way. There's obviously a lot of interest in class/module dependencies, which are not easy to create or test. Puppet would benefit from having a test for whether or not a specific class has been included and, I think, for whether or not a specific class *or one that inherits from it* has been included. -- Bruce A problem shared brings the consolation that someone else is now feeling as miserable as you. --~--~-~--~~~---~--~~ 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: Howto depend on a package from another class?
On Wed, Mar 18, 2009 at 06:31:36AM -0400, Trevor Vaughan wrote:
>
> I.e.
>
> class pam-ldap {
> include "openldap-client"
> }
>
> If anyone does know of a problem with this, could you shed some light on it?
There are several potential problems with it; the way puppet works, the
point at which a class is included can be very important. For example,
if the openldap-client class is sensitive to global variables, which
might be set differently in different contexts, then this might include
the class early, before those have been set. It also forces the
inclusion of that specific class, rather than any class that might
inherit from it.
So it all hangs on the way the OP uses these classes, but I do find it
very important in puppet to avoid unnecessary dependences.
--
Bruce
Hierophant: someone who remembers, when you are on the way down,
everything you did to them on the way up.
--~--~-~--~~~---~--~~
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: Howto depend on a package from another class?
On Wed, Mar 18, 2009 at 09:09:47AM +0100, Ivo van der Meer wrote: > > Hi, > > I have a class and want to depend on a Package from another class, how do I > solve this ?? Just depend on the package. Then you don't have to care who provides it. Is is that you want to the dependency on the package to trigger the inclusion of the class which manages it? That would be a different story. -- Bruce If the universe were simple enough to be understood, we would be too simple to understand it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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: Installing latest updates until a certain date
On Tue, Mar 17, 2009 at 12:09:07PM +0100, Patrick Debois wrote: > > You didn't way you wanted arbitrary combinations, just combinations up > > to an arbitrary date, which is simpler to manage. You don't even need > > genuine multiple mirrors; you could use dirvish or rdiff-backup to > > create a series of apparent snapshots. > > > > > Nice idea to use dirvish: that would indeed allow me to avoid > duplication of the repository and if i understand it right, > i can have different enviroments use different snapshots at the same > time. f.i. dev and test on repository X and pre-prod on version Y That's right. Dirvish is great for that kind of thing. It's ungreat as an actual backup tool, of course, because everything has to be on a single filesystem and there's only one copy of each file, but that's an endless argument I have in other places and you don't want to hear about that. > > > > Debian manages that problem with it's release structure, but you > > probably don't want to hear that. > > > > > Would it make sense to use the Build Date or the Signature date for this? Dunno. I just ran out of smarts. -- Bruce If the universe were simple enough to be understood, we would be too simple to understand it. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-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 -~--~~~~--~~--~--~---
