Re: [Puppet Users] require custom ruby code in custom function
On Monday, 5 March 2012 at 11:37, flex wrote: hi, all: i want to require my own ruby class in a custom function, now i put the ruby file in the same directory with custom function, and require it in the function file like this: require File.join([File.expand_path(File.dirname(__FILE__)), 'test.rb']) but i think this is too ugly, is there any other way? -- System Administrator, Focus on System Management and Basic Development -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com (mailto:puppet-users@googlegroups.com). To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com (mailto:puppet-users+unsubscr...@googlegroups.com). For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. Hi, I'm doing something like this in my scripts (not exactly puppet custom modules/facts but it will do the trick): $LOAD_PATH File.expand_path(File.dirname(__FILE__) + '/../lib') then you can use `require test' construction. Best, -- Dominik Zyla -- 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] Fetch ldap authorized_keys from ldap, copy to puppets local filesystem for needed users
Hello, I'm trying to set up the following environment: Ldap containing users as posixaccount (uid, home directory, and an attribute containing their ssh public key). machines with an attribute indicating which users or user groups are allowed to ssh to the box What I'd like to do is the following: From puppetmaster, browse the ldap and loop on each machine Fetch the users allowed to login Loop on each user Fetch their uid, etc Fetch their ssh public key create the /home/$username/.ssh/authorized_keys file End loop Delete /home/$username for all users having no longer access to the box End loop This is needed because ssh server on machines is configured only with publickey auth so I need to put the authorized_keys file for them to be able to connect to the box. I don't really know where to start... I can manually create the authorized_key file on my puppet nodes but by manually specifying the user and the public key, I have to idea how to get the information from ldap and then loop in my script... I've tried looking at the documentation but don't really know where to start. I've found the wiki page on defining nodes inside ldap but I'm not sure that this is what I need. Thanks for your time, Best regards, Emilien -- 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] Long config retrieval on nodes
Hi all, hoping someone may have encountered a problem similar to this before: On my customer's EC2 based infrastructure, we have implemented the nodeless, truth driven module outlined by Jordan Sissel here http://www.semicomplete.com/blog/geekery/puppet-nodeless-configuration. It's quite an effective model, especially in the realm of EC2... we still have a puppetmaster configuration, and have decided not to go with the masterless option, since we'd like to implement a nagios module using the storeconfigs approach and exported resources. Problem is, we're seeing large latency during agent runs, which appears to be down to the config retrieval step, so much so that we've needed to increase timeouts to avoid our Apache/Mongrel puppetmasterd solution from timing out the connection. I've done some basic profiling, using --summarize and --evaltrace, which shows that the bottelneck *appears* to be happening at the config retrieval level: (This is on our monitoring server) Time: Attachedstorage: 2.00 Class: 0.00 Collectd conf: 0.01 Config retrieval: 85.91 Cron: 0.00 Exec: 34.11 File: 35.56 Filebucket: 0.00 Group: 0.26 Mailalias: 0.17 Mount: 3.48 Nagios command: 0.02 Nagios contact: 0.00 Nagios contactgroup: 0.00 Nagios host: 0.02 Nagios service: 0.12 Nagios servicegroup: 0.00 Package: 3.12 Resources: 0.00 Schedule: 0.01 This agent run has been done with storeconfigs enabled, but it appears that the Nagios resources are being processed fairly quickly; when we disable storeconfigs, the config retrieval can be reduced to almost half as long, which would suggest db latency. We've got the puppetmaster running on a m1.small EC2 instance, which only seems to have a single core - I'm not sure if that's perhaps the cause of the bottleneck? Any suggestions / advice would be much appreciated, thanks in advance! Cheers, Andrew -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/P1szoP5rBmUJ. 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.
[Puppet Users] Re: Autoloading issue when adding type to existing module
Ok, I know standalone isn't the coolest way to run puppet, but I don't feel like I have a node I can sensibly assign as the master. Regardless, this seems like a significant issue. Is it something stupid I'm doing, has anyone else had this problem? Do nodes cache catalogs? What's going on? ...meh. I'm gonna set myself as admin on some rails sites. Then they'll notice me ;-) -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/eLWHlNGt47sJ. 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
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). On Monday, March 5, 2012 4:13:30 PM UTC-5, denmat wrote: Hi, Here's what the docs say: Okay, we can pass parameters into classes now and change their behavior. Great! But classes are still always singletons; you can’t declare more than one copy and get two different sets of behavior simultaneously. And you’ll eventually want to do that! What if you had a collection of resources that created a vhost definition for a web server, or cloned a Git repository, or managed a user account complete with group, SSH key, home directory contents, sudoers entry, and .bashrc/.vimrc/etc. files? What if you wanted more than one Git repo, user account, or vhost on a single machine? Well, you’d whip up a defined resource typehttp://docs.puppetlabs.com/learning/definedtypes.html . So have a look at changing the bar class to a define instead. Cheers, Den -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/u65ZgjblWKEJ. 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: net ads join
Thanks for all of the input. Yeah this code is part of a larger manifest, and no its not verbatim what I have written, but for the topic I figured it would get the jist of what I was trying to do across (and it seems to have done that). You know, I don't know if I just tried the grep only... for some reason I thought I had to use test or something that would return 1 or 0. Creating a custom fact is something I haven't done before, but I might give it a shot. We are a samba shop (I lost the QAS fight). I'll take a look at those links, thanks for referencing them... will post what my solution ends up being. On Mar 5, 3:53 pm, Jeremy Baron jer...@tuxmachine.com wrote: On Mar 5, 2012 3:36 PM, Kinzel, David david.kin...@encana.com wrote: It would be much simpler to use: onlyif = net ads testjoin 21 | grep 'Join is OK' Which will use the return code of grep. Idk the onlyif interface offhand but you probably want a -q on the grep to suppress output. So, grep -q 'Join is OK' or fgrep -q 'Join is OK' -Jeremy -- 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: Developers having access to deploy
Check out InstantLinux as a front-end to puppet: http://www.instantlinux.net/ On Mon, Mar 05, 2012 at 10:51:12PM -0800, Thomas Rasmussen wrote: Thanks for the replies, I can see that there is no easy setup to allow what I'm looking for :-( I will be looking a bit more on the External Node Classifier to see if this will solve my problem. We will be using puppet to fully automate everything that has to be performed on servers, so I will not be interested in using a different system to do the app-deployment than to do the OS deployment. I was hoping that maybe it was possible to do this task through the Dashboard, but I discovered that it was only a standard htpassword setup without any group knowledge or ACLs on nodes. Thomas On Friday, March 2, 2012 10:42:28 AM UTC+1, Thomas Rasmussen wrote: Hi I'm in the process of looking for a way to have developers deploying on their test systems without intervention of sysadmins, to solve this i'd like to use Puppet (either the OSS version or Enterprise, whichever solves the problem). I can manage to only grant access to certain systems and limit the ability to execute puppetd --test, however, the developers would like to create a new version of the application and then this should be put into place instead of the old version, but I can't seem to find a solution to this. I was thinking somewhat on the option to issue a command like this: puppetd --test --my-app-version 3.2.1 And then the puppet manifests will use the my-app-version variable to fetch and deploy this specific version. I know that the manifests should be developed with care, which is also the idea. Or what solutions do people use in case where developers should have access to deploy, but not have access to the puppetmaster server? hope that this can be done. Regards Thomas -- 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 tricks..
On Mar 5, 3:33 pm, Peter Berghold salty.cowd...@gmail.com wrote:
Folks,
I haven't tried this yet, but I certainly intend to.
If I set up an exported file definition such that:
@@file{'munin-node-file':
content= template('blah'),
path = /etc/munin.d/${hostname}.cfg
}
and then
File 'munin-node-file'
Do I understand correctly that I would see multiple files created for the
path I've given? Or am I reaching?
I was under the impression that resource titles needed to be unique
even among collected exported resources. With others claiming to do
exactly as you describe, I'm now questioning that belief. Even if
it's not strictly necessary, however, I still think it's safer and at
least as clear to use
@@file{ munin-node-file-${hostname}:
content= template('blah'),
path = /etc/munin.d/${hostname}.cfg,
tag = 'munin-node-file'
}
and then
File tag == 'munin-node-file'
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Duplicate 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] Duplicate definition + parameterized classes + class scope
Crap. I'm trying to dump Bcfg2 and move to something reasonable. But so
far, all my initial assumptions and patterns for Puppet fail. I think in
terms of heirarchy and inheritence for my systems (all nodes install a core
set of packages, some have exceptions for those core set of packages, etc)
and as best as I can understand it Puppet's DSL really wants me to create a
set of flat, non-hierarchial, non-inheritable set of nodes/classes. And for
me that's completely un-managable.
I'm reviewing the Puppet-user archives now and I'm seeing a lot of people
with similar problems but no good patterns for solutions.
I want to be able do something like this (hierarchial, inheritance with
overloading):
class base {
package { 'sshd' : ensure = present }
package {'ntp: ensure = present }
}
node a,b,c {
class { 'base' : }
}
node d {
class { 'base' : }
Package{'sshd': ensure = false }
}
What I'm afraid I have to do is this (flat, redefine lots of nodes and
duplicate data):
class base
package {'ntp: ensure = present }
# More common packages defined
}
node a,b,c {
class { 'base' : }
package { 'sshd' : ensure = present }
}
node d {
class { 'base' : }
package { 'sshd' : ensure = false}
}
or worse (sometype of parameter passing in the worst, un-managable way):
class base ( # list ever possible ensure parameter, etc ) {
package { 'sshd' : ensure = $ssh_ensure }
package {'ntp: ensure = $ntp_ensure }
# More common packages defined
}
node a,b,c {
class { 'base' : }}
}
node d {
class { 'base' : ssh_ensure = false}
}
I'm open to any and all suggestions.
thx
Chris.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/BEKIgDDLpRYJ.
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] Fetch ldap authorized_keys from ldap, copy to puppets local filesystem for needed users
On Mar 6, 2012, at 3:24 AM, Emilien wrote: Hello, I'm trying to set up the following environment: Ldap containing users as posixaccount (uid, home directory, and an attribute containing their ssh public key). machines with an attribute indicating which users or user groups are allowed to ssh to the box What I'd like to do is the following: From puppetmaster, browse the ldap and loop on each machine Fetch the users allowed to login Loop on each user Fetch their uid, etc Fetch their ssh public key create the /home/$username/.ssh/authorized_keys file End loop Delete /home/$username for all users having no longer access to the box End loop This is needed because ssh server on machines is configured only with publickey auth so I need to put the authorized_keys file for them to be able to connect to the box. I don't really know where to start... I can manually create the authorized_key file on my puppet nodes but by manually specifying the user and the public key, I have to idea how to get the information from ldap and then loop in my script... I've tried looking at the documentation but don't really know where to start. I've found the wiki page on defining nodes inside ldap but I'm not sure that this is what I need. Thanks for your time, I don't think that puppet is really the best tool for the job and that you should probably reexamine the mission and you will find that there are better implementations within LDAP (host based access). I suppose if you were really determined to go down your path, you could write some custom fact that gave you the output of 'ls /home' to get an overview of who had home directories on each server but the puppet way would be to have each server to put everyone's home directory (with public keys) and allow LDAP (PAM/PADL/LDAP) to handle whether a particular user access a particular host. Craig -- 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: Developers having access to deploy
On Mar 5, 2012, at 11:51 PM, Thomas Rasmussen wrote: Thanks for the replies, I can see that there is no easy setup to allow what I'm looking for :-( I will be looking a bit more on the External Node Classifier to see if this will solve my problem. We will be using puppet to fully automate everything that has to be performed on servers, so I will not be interested in using a different system to do the app-deployment than to do the OS deployment. I was hoping that maybe it was possible to do this task through the Dashboard, but I discovered that it was only a standard htpassword setup without any group knowledge or ACLs on nodes. theforeman has a fairly sophisticated users/groups/roles and also servers can 'belong' to individual users and would probably give you everything you want including a very useful ENC Craig -- 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 Mar 6, 2012, at 7:51 AM, chris_sny...@sra.com wrote:
Crap. I'm trying to dump Bcfg2 and move to something reasonable. But so
far, all my initial assumptions and patterns for Puppet fail. I think in
terms of heirarchy and inheritence for my systems (all nodes install a core
set of packages, some have exceptions for those core set of packages, etc)
and as best as I can understand it Puppet's DSL really wants me to create a
set of flat, non-hierarchial, non-inheritable set of nodes/classes. And for
me that's completely un-managable.
I'm reviewing the Puppet-user archives now and I'm seeing a lot of people
with similar problems but no good patterns for solutions.
I want to be able do something like this (hierarchial, inheritance with
overloading):
class base {
package { 'sshd' : ensure = present }
package {'ntp: ensure = present }
}
node a,b,c {
class { 'base' : }
}
node d {
class { 'base' : }
Package{'sshd': ensure = false }
}
What I'm afraid I have to do is this (flat, redefine lots of nodes and
duplicate data):
class base
package {'ntp: ensure = present }
# More common packages defined
}
node a,b,c {
class { 'base' : }
package { 'sshd' : ensure = present }
}
node d {
class { 'base' : }
package { 'sshd' : ensure = false}
}
or worse (sometype of parameter passing in the worst, un-managable way):
class base ( # list ever possible ensure parameter, etc ) {
package { 'sshd' : ensure = $ssh_ensure }
package {'ntp: ensure = $ntp_ensure }
# More common packages defined
}
node a,b,c {
class { 'base' : }}
}
node d {
class { 'base' : ssh_ensure = false}
}
I'm open to any and all suggestions.
I use theforeman which has an ENC that allows nested classes (called hostgroups
in Foreman) so I have a 'base' class and many 'groups' which are pre-defined
collections of what you call the flat modules. Nesting is definitely permitted
and useful in Foreman.
Craig
--
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: Duplicate definition + parameterized classes + class scope
On Mar 6, 7:53 am, chris_sny...@sra.com 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. That would be a travesty, but it's not what Puppet has done. Instead, Puppet has taken entirely different constructs and named them in a manner that confuses you. You know, just to keep you on your toes. Defined resource types don't help me as they don't have inheritance (which is something I very much want). No, you don't. Or at least, the object-oriented kind of inheritance that you think you want is not available from Puppet, so the fact that neither defined types nor classes offer it does not distinguish between the two. Puppet's class inheritance is designed expressly for allowing the properties of resources declared in a superclass to be overridden by a subclass. Even that probably excites the OO programmer in you more than it should. In practice, overriding resource properties is never more than a convenience. Puppet offers several alternatives, some of them cleaner. Supposing that you're a good OO programmer, you will be aware of the classic question of inheritance vs. composition. In my experience, the better choice in OO programming is more often composition than many practitioners recognize, but in Puppet DSL, composition is *almost always* the better choice. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] system poweroff/shutdown module
On Tuesday, 6 March 2012 at 14:30, Darin Perusich wrote: Hello, I was wondering if anyone's written a shutdown/poweroff module to take down some or all of the systems managed by puppet? A quick google search didn't come up with anything so i figured I'd ask before reinventing the wheel. The primary scenario I'm thinking of is there's an extended power outage and the backup generator fails for whatever reason and there's 30 minutes of run time available to nicely take down all the systems. Furthermore I'd want to push the shutdown request to the clients since. Hi, Puppet is not designed for such tasks. Take a look on MCollective which can be helpful here. using it you can divide your systems on collectives/groups and operate on them directly or on single nodes too. MCollective is delivered with Puppet Enterprise. Best, -- Dominik Zyla -- 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: Duplicate definition + parameterized classes + class scope
On Mar 6, 8:51 am, chris_sny...@sra.com chris_sny...@sra.com
wrote:
Crap. I'm trying to dump Bcfg2 and move to something reasonable. But so
far, all my initial assumptions and patterns for Puppet fail. I think in
terms of heirarchy and inheritence for my systems (all nodes install a core
set of packages, some have exceptions for those core set of packages, etc)
and as best as I can understand it Puppet's DSL really wants me to create a
set of flat, non-hierarchial, non-inheritable set of nodes/classes. And for
me that's completely un-managable.
I'm reviewing the Puppet-user archives now and I'm seeing a lot of people
with similar problems but no good patterns for solutions.
I want to be able do something like this (hierarchial, inheritance with
overloading):
class base {
package { 'sshd' : ensure = present }
package {'ntp: ensure = present }
}
node a,b,c {
class { 'base' : }
}
node d {
class { 'base' : }
Package{'sshd': ensure = false }
}
What I'm afraid I have to do is this (flat, redefine lots of nodes and
duplicate data):
class base
package {'ntp: ensure = present }
# More common packages defined
}
node a,b,c {
class { 'base' : }
package { 'sshd' : ensure = present }
}
node d {
class { 'base' : }
package { 'sshd' : ensure = false}
}
or worse (sometype of parameter passing in the worst, un-managable way):
class base ( # list ever possible ensure parameter, etc ) {
package { 'sshd' : ensure = $ssh_ensure }
package {'ntp: ensure = $ntp_ensure }
# More common packages defined
}
node a,b,c {
class { 'base' : }}
}
node d {
class { 'base' : ssh_ensure = false}
}
I'm open to any and all suggestions.
Surprisingly, you have named one of the few types of problems for
which Puppet's class inheritance offers a reasonable solution:
class ssh {
package { 'sshd': ensure = 'present' }
}
class ssh::absent inherits ssh {
Package[ 'sshd' ] { ensure = 'absent' }
}
node default {
include 'sshd'
}
node d inherits default {
include 'ssh::absent'
# no problem that class ssh is also declared
}
All the same, a more forward-looking, probably better solution would
be to rely on hierarchical data instead of hierarchical nodes and
classes. Using the 'hiera' module recently adopted into Puppet, you
could achieve the same effect via just
class ssh {
package { 'sshd': ensure = hiera('sshd_ensure') }
}
node default {
include 'sshd'
}
CAVEAT: hiera configuration and data not shown. It isn't hard to set
up and use, but it isn't automagical, either.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] File checksum
I want to to ensure a file, and if the content changes a subscribed exec
should fire.
file { /etc/opt/microsoft/scx/ssl/scx-host-$fqdn.pem:
checksum = md5,
}
exec { /etc/init.d/scx-cimd restart:
subscribe =
File[/etc/opt/microsoft/scx/ssl/scx-host-$fqdn.pem],
refreshonly = true
}
The file is created by a package (scom) and the content isn't managed by
puppet. I noticed that the exec never fired - I tried making a change to
the file and running puppet, though it doesn't seem like puppet looking at
the md5sum of the file at all.
tl;dr - I want to watch the md5sum of a file and not manage the content, if
md5sum changes, fire an exec.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/-UOseNK-nfMJ.
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 class overwritten by other classes
On Mar 5, 11:33 am, Pablo Fernandez pablo.fernan...@cscs.ch wrote:
Dear Puppeteers,
After many hours of reading manuals, books and google, I'm starting to thing
there is no right way to edit files in puppet, and I must be wrong. A massive
work is ahead (puppetizing our whole cluster) and I would like to start with
the right foot.
My idea is to make puppet a tool that describes the system as it should be,
and files are no different. I don't want to have old entries in the
/root/.ssh/authorized_keys, or in the /etc/sysctl.conf. I want that, when I
remove a configuration item in Puppet, the file comes back to the situation it
was before (as much as possible).
Because of this, using Augeas, or Ssh_authorized_key, or custom shell-scripts
add_line_if_not_present do not help by themselves (removing the item - or
unimporting the containing class - does not remove the line). So, what I
thought, is that I should use default files for those cases, and then edit
afterwards. I do this, for example:
class parent:
file { /root/.ssh/authorized_keys: content = }
class child inherits parent:
ssh_authorized_key { Pablo: blabla }
File [/root/.ssh/authorized_keys] - Ssh_authorized_key [Pablo]
The problem I have is that, every time I run puppetd -t, I see how puppet is
emptying the file, and populating it again, on the same run. And no matter how
many times I run it (no changes in the manifests) it tells me the diffs of
what the changes would be, that leave the file exactly like it was.
Well, yes. You are managing the same physical resources via multiple
Puppet resources. They disagree about the required state for the
physical resource, so each is certain to resync on every run.
And I
noticed this happens with Augeas all the same, and if a file has a
notification on a service, it will trigger a restart.
Do you know a way to avoid this? Having a file changing all the time (even if
it's wrong just for a second) is not what I want, and the same goes for
restarting the service every 30 minutes for no reason.
Others can speak more intelligently about Augeas.
As for your file, you need to stop making contradictory declarations
about it. In principle, you should be able to use the Resources meta-
resource to purge unmanaged authorized keys, but in practice that
doesn't work (yet). See this feature request for more information:
http://projects.puppetlabs.com/issues/1581. You have (at least) these
options:
1) Manage all possible(*) ssh_authorized_keys for every node, ensuring
each one either present or absent as appropriate, but do not
manage the file via a File resource. This approach will only clear
out keys you know to ensure absent, however, which may be a major
shortcoming.
2) Manage the file only via a File resource. The most scalable
approach here would involve writing a template for it, so that you
wouldn't need to maintain a combinatorial number of the different
files.
3) Write a custom provider for ssh_authorized_keys that provides for
purging. Easiest would probably be to base such a thing on the
existing provider. Distribute the provider via pluginsync, and name
it explicitly in your ssh_authorized_key resource declarations. Use
Resources to purge unwanted keys.
Or is there any other method to ensure a file is what you want it to be,
without having all the possible options in different files?
That's what templates are for. In some cases, the Puppet::Concat
module can also be useful for this purpose, but I'm not certain
whether it satisfies your criterion of avoiding resyncing the file on
every run, which is why I didn't mention it above.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] File checksum
On Tue, Mar 6, 2012 at 9:17 AM, Luke Baker bake...@missouri.edu wrote:
I want to to ensure a file, and if the content changes a subscribed exec
should fire.
file { /etc/opt/microsoft/scx/ssl/scx-host-$fqdn.pem:
checksum = md5,
}
Try adding audit = checksum to the file. Though I recall some issues
with noop and where it will change the state.yaml file on noop.
Nan
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Inherited node tagging
Dear all,
I have observed a behavior that doesn't seem (to me) to match the
documentation. Specially, about tagging, the doc says:
Automatic Tagging
All language statements enclosed in a node, define or class structure (read
more about puppet control structures [[Language Tutorial]] ) will
automatically be tagged with the name of that statement. These automatically-
applied tags will be inherited by any object enclosed in that class,
regardless of the depth of enclosure.
But then I print the tags that are visible within each of the scopes:
node 'ANY' {
}
node 'WN' inherits 'ANY' {
}
node 'wn01.domain' inherits 'WN' {
}
And inside each category I do:
$var = inline_template (TAGS: % tags.each do |tag| -%%= tag % % end
-%)
notify { $var: }
To print the visible tags.
And what I get is:
notice: TAGS: node wn01.domain class
notice: TAGS: node wn class
notice: TAGS: node any class
So, the tags are not inherited. Each node prints the tag that is declared in
its own node, but not those from the parent or the children. I have also tried
to do manual tags, and they are not inherited either.
Am I doing something wrong, or is tagging not well documented?
Thanks!
Pablo
--
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: Avoiding duplicate definitions
On Mar 6, 6:02 am, Bruce Richardson itsbr...@workshy.org wrote:
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.
I'd recommend *not* using such a wrapper at all, mainly because
testing for resource definitions via the defined() function introduces
a parse-order dependency.
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.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Statement from Puppet Labs regarding Github Compromise
Over the weekend, we saw github[1] had been attacked, and potentially malicious code was pushed onto the rails project. This was concerning to us at Puppet Labs as we host nearly 100% of our code with github. Our course of action ran as follows: 1. We first checked our Rails based applications for the mass assignment[2][3] issues. This includes the Puppet Forge and Puppet Dashboard. It was determined that neither of these products were vulnerable to mass assignment issues. Other projects using ActiveRecord (without rails) were also verified. 2. We checked our repositories for suspicious commits. During the time of the compromise of github, the attacker could have created a phony git setup and pushed onto one of our projects with a malicious commit. For puppet, facter and dashboard we get notified when a push happens onto a branch. We saw no out-of-place commits occur. Those repositories, and others repositories are being hand-reviewed/audited for anything odd in the last two weeks. This includes repositories for mcollective, puppet modules, and packaging. Github also made a statement saying they have determined that no malicious intent was present[4] in the compromise. At this time, Puppet Labs also believes no harm was done as a result of this github compromise, to our projects. As a reminder, Puppet Labs practices Responsible Disclosure[5]. If you ever have questions or concerns about our security practices, contact us secur...@puppetlabs.com or see our security page[6]. Thanks, Michael Stahnke Community Manager [1]https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation [2]http://guides.rubyonrails.org/security.html#mass-assignment [3]http://blog.mhartl.com/2008/09/21/mass-assignment-in-rails-applications/ [4]https://github.com/blog/1069-responsible-disclosure-policy [5]http://en.wikipedia.org/wiki/Responsible_disclosure [6]http://puppetlabs.com/security/ -- 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.
[Puppet Users] Issue with pe-dashboard-workers
I've almost gotten PE running -- Based on tips from a recent Webinar, I've started on a minimal RHEL 6 system, and have installed the PE 2.03 packages. Once I set up /etc/ hosts (DNS will come later), I started the PE services. Given past problems (possibly just me), I was pleasantly surprised that the puppet-enterprise-updater script was so accommodating as I remembered which systems to update. So I'm to the point where the pe-puppet-dashboard-workers script (from /etc/init.d) borks a bit with the following message: Starting pe-dashboard-workers: Database isn't the current migration version: expected 2018204121, got 0 You must either run 'rake db:migrate' or set environmental variable NO_MIGRATION_CHECK To confirm, the service pe-puppet-dashboard workers status command returns the following message: pe-dashboard-workers dead but pid file exists Given the suggestions, (and a bit of online help) I then navigated to / opt/puppet/share/puppet-dashboard and ran the rake db:migrate command and got the following message: DEPRECATION WARNING: Rake tasks in vendor/plugins/delayed_job/tasks are deprecated. Use lib/tasks instead. (called from /opt/puppet/share/ puppet-dashboard/vendor/rails/railties/lib/tasks/rails.rb:10) rake aborted! no such file to load -- sinatra/base Since I couldn't figure out how to get sinatra/base loaded (perhaps that's a solution), I went back and worked on setting the environment variable with the export NO_MIGRATION_CHECK=1 command. I then tried restarting the pe-puppet-dashboard-workers script, and seemed to get further: Stopping pe-dashboard-workers: pid-file for killed process 3520 found (/opt/puppet/share/puppet-dashboard/tmp/pids/delayed_job.0.pid), deleting. pid-file for killed process 3524 found (/opt/puppet/share/puppet- dashboard/tmp/pids/delayed_job.1.pid), deleting. [ OK ] Starting pe-dashboard-workers: [ OK ] But that wasn't enough, as a status check still shows pe-dashboard-workers dead but pid file exists I've tried rerunning with the PID files deleted from the /var/opt/ cache/pe-puppet-dashboard/pids/ directory, without any changes to the result. Any advice would be appreciated. Thanks, Mike -- 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] Puppet/foreman redundant servers? Cluster, recovery etc
What are the best practices for achieving a maximally redundant and scalable environment? What are you doing? We're rolling out Puppet with Foreman, mysql, Passenger, on a RHEL6 VMWare box. Configs are stored in SVN and Jenkins. Right now we've got those first four things running on the same single server but for production we always want replication whenever possible. -- 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: Duplicate definition + parameterized classes + class scope
John,
I'm running into some snags of my own and your explanations have been
helpful. However, I'd like to ask if you can comment a bit more on the
emphasis Puppet Labs has on parameterized classes versus include. For one,
I'm thinking of modules available via github. Take the
puppetlabs/mcollective module, for example. It's highly parameterized and I
have some wrapper classes like this:
class puppet_base ( $puppet_master = false, $mcollective_client = false
) {
class { 'system_base': } # basics needed by all systems
class { 'puppet':
master = $puppet_master,
require = Class['system_base'],
}
class { 'mcollective_server':
mcollective_client = $mcollective_client,
}
}
class mcollective_server ( $mcollective_client = false ) {
package { 'stomp':
ensure = present,
provider = 'gem',
}
if $mcollective_client {
class { 'activemq':
require = Package['stomp'],
before = Class['mcollective'],
}
}
class { 'mcollective': # puppetlabs/mcollective module
client = $mcollective_client,
}
}
This seemed to me like an appropriate use of parameterized classes and a
way of keeping node definitions simple and readable, like so:
node 'regular-host' {
class { 'puppet_base':
stage = 'first'
}
}
node 'mco-admin-host': {
class { 'puppet_base':
stage = 'first',
mcollective_client = true,
}
}
node 'puppet-master' {
class { 'puppet_base':
stage = 'first',
puppet_master = true,
}
}
I am running into some snags with ensuring curl and rubygems packages are
installed prior to the puppet_base being evaluated (that's a long story),
but that may be more of an issue with better use of stages.
Can you comment on the above and how it is impacted by your explanations of
includes (and smarter classes) vs. parameterization?
Thanks,
Justin
On Tue, Mar 6, 2012 at 8:50 AM, jcbollinger john.bollin...@stjude.orgwrote:
On Mar 6, 8:51 am, chris_sny...@sra.com chris_sny...@sra.com
wrote:
Crap. I'm trying to dump Bcfg2 and move to something reasonable. But so
far, all my initial assumptions and patterns for Puppet fail. I think in
terms of heirarchy and inheritence for my systems (all nodes install a
core
set of packages, some have exceptions for those core set of packages,
etc)
and as best as I can understand it Puppet's DSL really wants me to
create a
set of flat, non-hierarchial, non-inheritable set of nodes/classes. And
for
me that's completely un-managable.
I'm reviewing the Puppet-user archives now and I'm seeing a lot of people
with similar problems but no good patterns for solutions.
I want to be able do something like this (hierarchial, inheritance with
overloading):
class base {
package { 'sshd' : ensure = present }
package {'ntp: ensure = present }
}
node a,b,c {
class { 'base' : }
}
node d {
class { 'base' : }
Package{'sshd': ensure = false }
}
What I'm afraid I have to do is this (flat, redefine lots of nodes and
duplicate data):
class base
package {'ntp: ensure = present }
# More common packages defined
}
node a,b,c {
class { 'base' : }
package { 'sshd' : ensure = present }
}
node d {
class { 'base' : }
package { 'sshd' : ensure = false}
}
or worse (sometype of parameter passing in the worst, un-managable way):
class base ( # list ever possible ensure parameter, etc ) {
package { 'sshd' : ensure = $ssh_ensure }
package {'ntp: ensure = $ntp_ensure }
# More common packages defined
}
node a,b,c {
class { 'base' : }}
}
node d {
class { 'base' : ssh_ensure = false}
}
I'm open to any and all suggestions.
Surprisingly, you have named one of the few types of problems for
which Puppet's class inheritance offers a reasonable solution:
class ssh {
package { 'sshd': ensure = 'present' }
}
class ssh::absent inherits ssh {
Package[ 'sshd' ] { ensure = 'absent' }
}
node default {
include 'sshd'
}
node d inherits default {
include 'ssh::absent'
# no problem that class ssh is also declared
}
All the same, a more forward-looking, probably better solution would
be to rely on hierarchical data instead of hierarchical nodes and
classes. Using the 'hiera' module recently adopted into Puppet, you
could achieve the same effect via just
class ssh {
package { 'sshd': ensure = hiera('sshd_ensure') }
}
node default {
include 'sshd'
}
CAVEAT: hiera configuration and data not shown. It isn't hard to set
up and use, but it isn't automagical, either.
John
--
You received this message because you are subscribed to the Google
Re: [Puppet Users] Puppet/foreman redundant servers? Cluster, recovery etc
On Tuesday, 6 March 2012 at 19:56, Elizabeth Schwartz wrote: What are the best practices for achieving a maximally redundant and scalable environment? What are you doing? We're rolling out Puppet with Foreman, mysql, Passenger, on a RHEL6 VMWare box. Configs are stored in SVN and Jenkins. Right now we've got those first four things running on the same single server but for production we always want replication whenever possible. -- 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 (mailto:puppet-users@googlegroups.com). To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com (mailto:puppet-users+unsubscr...@googlegroups.com). For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. Hi, We're also duplicating all resources as they're going live. We're using drbd and Pacemaker for foreman and apache fallbacks. Works quite well. Best, -- Dominik Zyla -- 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: Puppet in NFS fools Facter
Nothing was copied over. The NFS mount code was built and then exported; 32- and 64-bit respectively. The code was built from scratch and installed with the appropriate locally mounted prefix (in this case, /local). I'm on RHEL 5.x and we only have /proc/self/status which doesn't seem to indicate anything about virtual or physical, for example: Name: cat State: R (running) SleepAVG: 88% Tgid: 1523 Pid:1523 PPid: 31949 TracerPid: 0 Uid:0 0 0 0 Gid:0 0 0 0 FDSize: 256 Groups: 0 1 2 3 4 6 10 VmPeak:58952 kB VmSize:58952 kB VmLck: 0 kB VmHWM: 484 kB VmRSS: 484 kB VmData: 176 kB VmStk:88 kB VmExe:20 kB VmLib: 1448 kB VmPTE:40 kB StaBrk: 06dd2000 kB Brk:06df3000 kB StaStk: 7fffb84776a0 kB Threads:1 SigQ: 1/4096 SigPnd: ShdPnd: SigBlk: SigIgn: SigCgt: CapInh: CapPrm: feff CapEff: feff Cpus_allowed: ,,,,,,,0003 Mems_allowed: ,0001 -- 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: Puppet in NFS fools Facter
Interestingly, the command facter serialnumber correctly pulls that it's a VMware system: # /local/bin/facter serialnumber VMware-56 4d 00 7e e8 3b e8 c9-85 7f 4e XX XX XX XX XX -- 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: Puppet in NFS fools Facter
On another system, same NFS mounts, the facter virtual reports the correct information, that system is running: 2.6.18-194.3.1.el5 The system that doesn't correctly report is: 2.6.18-274.18.1.el5 I don't know if that really matters. -- 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: Inherited node tagging
On Mar 6, 11:39 am, Pablo Fernandez pablo.fernan...@cscs.ch wrote:
Dear all,
I have observed a behavior that doesn't seem (to me) to match the
documentation. Specially, about tagging, the doc says:
Automatic Tagging
All language statements enclosed in a node, define or class structure (read
more about puppet control structures [[Language Tutorial]] ) will
automatically be tagged with the name of that statement. These automatically-
applied tags will be inherited by any object enclosed in that class,
regardless of the depth of enclosure.
But then I print the tags that are visible within each of the scopes:
node 'ANY' {}
node 'WN' inherits 'ANY' {}
node 'wn01.domain' inherits 'WN' {
}
And inside each category I do:
$var = inline_template (TAGS: % tags.each do |tag| -%%= tag % % end
-%)
notify { $var: }
To print the visible tags.
And what I get is:
notice: TAGS: node wn01.domain class
notice: TAGS: node wn class
notice: TAGS: node any class
So, the tags are not inherited. Each node prints the tag that is declared in
its own node, but not those from the parent or the children. I have also tried
to do manual tags, and they are not inherited either.
Am I doing something wrong, or is tagging not well documented?
Both, I think.
The tagging documentation could be clearer, and probably it should
avoid the word inherited because I think that may have misled you.
On the other hand, I think your expectations are incorrect. It is
enclosed objects that are documented to also get tagged, and I would
not consider a node definition to be enclosed by another that
inherits from it.
John
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Applying specific file within list of files in a class
http://docs.puppetlabs.com/references/stable/type.html#file
source
If you specify multiple file sources for a file, then the first source that
exists will be used. This allows you to specify what amount to search paths for
files:
file { /path/to/my/file:
source = [
/modules/nfs/files/file.$host,
/modules/nfs/files/file.$operatingsystem,
/modules/nfs/files/file
]
}
This will use the first found file as the source.
“Sometimes I think the surest sign that intelligent life exists elsewhere in
the universe is that none of it has tried to contact us.”
Bill Waterson (Calvin Hobbes)
- Gmoney greg.caldwe...@gmail.com wrote:
We push a number of standard files to deploy across all our servers,
one of these files /etc/sysctl.conf , whihc is unique based on whether
the server is a VM or a physical host.
What is the best practice of pushing one unique file, which
maintaining the push of the entire class of files?
I am not aware of an exclusion within a class of files. would like to
know how others are approaching this issues. I am running Puppet
2.9.11 on Red Hat 5.6. Thanks in advance for your advice.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Live Mangement
Hi somehow one of my nodes is showing up twice under Live Management. Any ideas why this is happening? or has ayone seen this before? I've searched and its usually a problem of node not showing up instead of showing up twice. Julie -- 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] Complex architecture deployment [new of puppet]
I'm new of puppet and I'd like to know if it is possible to implement this use case with puppet/mcollective/foreman etc. I've a cloudstack environment with different domains. I want to allow users to add to their own domain virtual application bundles that are a topology of VM based on different templates and configured to work together to offer a complex application; for example: two VM that have the role of application server and a VM that has the role of an Apache balancer. Obviously I'd like to have plugin for crating VM, and to manage to configure apache to know the IP/names of the appservers to configure mod_cluster. App servers to be configured to be one a domain master (using JBoss 7.1) and placed in cluster. It would be nice to manage all this by a web interface and have a hot cup of coffee :D Being able to develop missing things I'd like to know if the missing parts are the most or not. Can puppet be instructed to do all this? Any hint, advise? Thanks Luca -- 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] Live Mangement
Do you have more than one mcollectived instances in the process table? `ps aux | grep [m]collective` I've seen this before when I had started two instances of the mcollectived daemon. On Tue, Mar 6, 2012 at 1:51 PM, FirstName LastName octom...@gmail.comwrote: Hi somehow one of my nodes is showing up twice under Live Management. Any ideas why this is happening? or has ayone seen this before? I've searched and its usually a problem of node not showing up instead of showing up twice. Julie -- 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. -- Gary Larizza Professional Services Engineer Puppet Labs -- 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: Issue with pe-dashboard-workers
I don't get it, but a clean uninstall (including db files in /var/lib/mysql) followed by a reinstall seems to have worked. Thanks for listening. On Tuesday, March 6, 2012 10:19:37 AM UTC-8, mic...@linuxexam.com wrote: I've almost gotten PE running -- Based on tips from a recent Webinar, I've started on a minimal RHEL 6 system, and have installed the PE 2.03 packages. Once I set up /etc/ hosts (DNS will come later), I started the PE services. Given past problems (possibly just me), I was pleasantly surprised that the puppet-enterprise-updater script was so accommodating as I remembered which systems to update. So I'm to the point where the pe-puppet-dashboard-workers script (from /etc/init.d) borks a bit with the following message: Starting pe-dashboard-workers: Database isn't the current migration version: expected 2018204121, got 0 You must either run 'rake db:migrate' or set environmental variable NO_MIGRATION_CHECK To confirm, the service pe-puppet-dashboard workers status command returns the following message: pe-dashboard-workers dead but pid file exists Given the suggestions, (and a bit of online help) I then navigated to / opt/puppet/share/puppet-dashboard and ran the rake db:migrate command and got the following message: DEPRECATION WARNING: Rake tasks in vendor/plugins/delayed_job/tasks are deprecated. Use lib/tasks instead. (called from /opt/puppet/share/ puppet-dashboard/vendor/rails/railties/lib/tasks/rails.rb:10) rake aborted! no such file to load -- sinatra/base Since I couldn't figure out how to get sinatra/base loaded (perhaps that's a solution), I went back and worked on setting the environment variable with the export NO_MIGRATION_CHECK=1 command. I then tried restarting the pe-puppet-dashboard-workers script, and seemed to get further: Stopping pe-dashboard-workers: pid-file for killed process 3520 found (/opt/puppet/share/puppet-dashboard/tmp/pids/delayed_job.0.pid), deleting. pid-file for killed process 3524 found (/opt/puppet/share/puppet- dashboard/tmp/pids/delayed_job.1.pid), deleting. [ OK ] Starting pe-dashboard-workers: [ OK ] But that wasn't enough, as a status check still shows pe-dashboard-workers dead but pid file exists I've tried rerunning with the PID files deleted from the /var/opt/ cache/pe-puppet-dashboard/pids/ directory, without any changes to the result. Any advice would be appreciated. Thanks, Mike -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/8vjhuC0oMmsJ. 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: Best practices for excluding certain modules from certain nodes
Thank you both for your great replies. They've both given me a great lead on which direction to head in. I haven't had the time to fully flesh out how I'm going to handle this yet but I know I'll be trying to stay away from parametrized classes for the time being. I'll also be trying to use hiera as much as possible to handle external data and determining which classes get applied to which nodes. Thanks again for the help. Romeo On Mon, Mar 5, 2012 at 04:24, jcbollinger john.bollin...@stjude.org wrote: On Mar 2, 2:12 pm, Romeo Theriault romeo.theria...@maine.edu wrote: On Fri, Mar 2, 2012 at 08:56, Romeo Theriault romeo.theria...@maine.edu wrote: [...] one item I can't seem to find a clean way of dealing with is one-off nodes. For example, let's say I want to apply a class called zabbix::agent to my whole infrastructure, so I put it in common.yaml. But then I find out there are a few nodes that for whatever reason I can't apply this class to. Short of just not inheriting anything from common.yaml is there a clean way to say inherit everything from common except zabbix::agent? How are people dealing with the slight variations in their infrastructure? I realize it's possible to code some logic into the classes for these specific one-off hosts but that seems really hackish and brittle. After a bit more googling I found this informative puppet-users thread: http://groups.google.com/group/puppet-users/browse_thread/thread/6b59... which talks about creating special disabled classes which inherit the widely used class and set certain values to 'undef'. This seems like it's probably the way to go since it's the best method I've seen/heard of so far to deal with this. That is one of the standard approaches to the kind of problem you describe, and it is simultaneously one of the few appropriate uses for class inheritance. The post you referenced provides a rather specific solution, however, and your description of it suggests that you may not yet see how that generalizes. In particular, 1) Overriding resource properties is the entire purpose of class inheritance. 2) A subclass can override resource properties to any value, not just undef. In fact, I think overriding to undef is unusual. 3) Although setting a resource property to undef generally means that *property* is unmanaged, that's a very different thing from making the entire resource be unmanaged. 4) Not managing a resource (or property) is very different from managing it to an atypical state. Either might be what you want. Anyone else dealing with this in a different way? Not I, but I can offer some alternatives anyway. Hiera provides several: A) Put an if block in Class['zabbix-agent'] around everything else in the class body. Use hiera to look up the value controlling whether the condition is satisfied. That provides an opt-out that any node can be made to use simply by setting an appropriate value in its hiera data. B) As I recall (but have not used), hiera provides an ENC-like function whereby you can cause it to declare classes for your nodes based on class names it looks up in your data. You could use that to decide whether to apply Class['zabbix-agent'] instead of declaring it in a class / node declaration that every node uses. Leverage hiera's hierarchical structure. C) Instead of overriding certain resource properties in a subclass, have the erstwhile parent class use hiera to look up the wanted property values in the first place. This is a general-purpose alternative to class inheritance. John -- You received this message because you are subscribed to the Google Groups Puppet Users group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en. -- Romeo -- 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] Wrong header line format errors
I've not made any changes to the config recently, only keeping Puppet and ruby 1.8 up-to-date. Recently, I noted my systems are logging this ambiguous error: Could not retrieve catalog from remote server: wrong header line format I say ambiguous as a google search shows serveral things this could be related to. I'm not sure what this really means, or whether it means something stored on the puppet master is corrupted. Can someone point me in the right direction? Thanks. -- 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: Wrong header line format errors
I answered my own question. It seems there was a missing ' or in one of the configs -- reported in the HTTP log. But the error itself doesn't tell me much. Thanks. -- 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] Resources Loop
Hello,
I'm fairly new to Puppet. I'm trying to setup some Nagios checks for
systems that have additional vhosts or aliases assigned to them (Nagios is
already setup and running without issue). In my node manifest, I have
defined:
$nagios_http_alias_check = [foo1,foo2,foo3]
And in my apache class I have:
# in case there is no aliases listed, just use the hostname
$nagios_http_alias_list = default_value($nagios_http_alias_check,$hostname)
define create_nagios_http_checks {
@@nagios_service {check-http_$nagios_http_alias_list:
use = 'check-http',
host_name = $nagios_http_alias_list,
servicegroups = 'all-service-checks,http-checks'
}
}
create_nagios_http_checks { $nagios_http_alias_list: }
However, when I run puppet, I get an error due to the
$nagios_http_alias_list mashing all the strings into one:
Duplicate definition: Nagios_service[check-http_foo1foo2foo3] is already
defined in file
I know I'm doing something stupid, but I can't figure it out. Any help
greatly appreciated.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To view this discussion on the web visit
https://groups.google.com/d/msg/puppet-users/-/hQp86NpHAoIJ.
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] Setting password hash for virtual users?
I read that this doesn't always work on every OS. However, I'm on
RHEL, and from what I'm reading the following should correctly set /
etc/shadow:
@user { myuser:
require= Group['staff'],
ensure = present,
uid= '2345',
gid= '90',
shell = '/bin/bash',
comment= 'myuser',
home = '/home/myuser',
managehome = true,
password = $1$BfhBSUJv$ajfjgfhdskdgfljkfdglkjfdlkfd., #
fake hash for this post
}
It creates the user and dependency, but doesn't touch /etc/shadow.
I need to be able to set this hash with the virtual user for the
systems we manage.Is there some workaround for this, or is my
syntax incorrect?
--
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] Setting password hash for virtual users?
On Wednesday, 7 March 2012 at 01:38, Forrie wrote:
I read that this doesn't always work on every OS. However, I'm on
RHEL, and from what I'm reading the following should correctly set /
etc/shadow:
@user { myuser:
require = Group['staff'],
ensure = present,
uid = '2345',
gid = '90',
shell = '/bin/bash',
comment = 'myuser',
home = '/home/myuser',
managehome = true,
password = $1$BfhBSUJv$ajfjgfhdskdgfljkfdglkjfdlkfd., #
fake hash for this post
}
It creates the user and dependency, but doesn't touch /etc/shadow.
I need to be able to set this hash with the virtual user for the
systems we manage. Is there some workaround for this, or is my
syntax incorrect?
Hi,
Why did you use `@file' definition instead of `file'? `@file' only creates
virtual resource which will not change anything in your system until you refer
to it using `||' notation. This link should clarify you this topic:
http://docs.puppetlabs.com/guides/virtual_resources.html
Best,
--
Dominik Zyla
--
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] Setting password hash for virtual users?
Hi,
Most likely you need to have ruby-shadow installed on the client.
Den
On 07/03/2012, at 12:11, Dominik Zyla dominik.z...@gmail.com wrote:
On Wednesday, 7 March 2012 at 01:38, Forrie wrote:
I read that this doesn't always work on every OS. However, I'm on
RHEL, and from what I'm reading the following should correctly set /
etc/shadow:
@user { myuser:
require = Group['staff'],
ensure = present,
uid = '2345',
gid = '90',
shell = '/bin/bash',
comment = 'myuser',
home = '/home/myuser',
managehome = true,
password = $1$BfhBSUJv$ajfjgfhdskdgfljkfdglkjfdlkfd., #
fake hash for this post
}
It creates the user and dependency, but doesn't touch /etc/shadow.
I need to be able to set this hash with the virtual user for the
systems we manage. Is there some workaround for this, or is my
syntax incorrect?
Hi,
Why did you use `@file' definition instead of `file'? `@file' only creates
virtual resource which will not change anything in your system until you
refer to it using `||' notation. This link should clarify you this topic:
http://docs.puppetlabs.com/guides/virtual_resources.html
Best,
--
Dominik Zyla
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
--
You received this message because you are subscribed to the Google Groups
Puppet Users group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Re: Developers having access to deploy
Seems as though instantlinux is deploy'ing a customized OS, however we are dealing with mix of different OS'es (This has to work at least on Linux and Solaris), so doesn't seem like an option Thomas On Tuesday, March 6, 2012 3:26:19 PM UTC+1, Chuck Anderson wrote: Check out InstantLinux as a front-end to puppet: http://www.instantlinux.net/ On Mon, Mar 05, 2012 at 10:51:12PM -0800, Thomas Rasmussen wrote: Thanks for the replies, I can see that there is no easy setup to allow what I'm looking for :-( I will be looking a bit more on the External Node Classifier to see if this will solve my problem. We will be using puppet to fully automate everything that has to be performed on servers, so I will not be interested in using a different system to do the app-deployment than to do the OS deployment. I was hoping that maybe it was possible to do this task through the Dashboard, but I discovered that it was only a standard htpassword setup without any group knowledge or ACLs on nodes. Thomas On Friday, March 2, 2012 10:42:28 AM UTC+1, Thomas Rasmussen wrote: Hi I'm in the process of looking for a way to have developers deploying on their test systems without intervention of sysadmins, to solve this i'd like to use Puppet (either the OSS version or Enterprise, whichever solves the problem). I can manage to only grant access to certain systems and limit the ability to execute puppetd --test, however, the developers would like to create a new version of the application and then this should be put into place instead of the old version, but I can't seem to find a solution to this. I was thinking somewhat on the option to issue a command like this: puppetd --test --my-app-version 3.2.1 And then the puppet manifests will use the my-app-version variable to fetch and deploy this specific version. I know that the manifests should be developed with care, which is also the idea. Or what solutions do people use in case where developers should have access to deploy, but not have access to the puppetmaster server? hope that this can be done. Regards Thomas -- You received this message because you are subscribed to the Google Groups Puppet Users group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/Qccy9KQGUVEJ. 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] Puppet staging server
Hi All, I tried to implement a second Puppet server as a staging server with the idea of being able to run puppet in dry run mode against this staging server. I ran into some SSL trouble. When I point at the staging server, I get various SSL related errors and I assume it's because the ca cert is different. I can get around it by clearing /var/lib/puppet/ssl and regenerating/signing the certificate, but I have to do the same thing when I go back to the production server which is not what I was hoping for. Has anyone done this sort of thing? How'd you get around the SSL issues? I could use the same CA cert on both Puppet servers but I assume that won't work as the hostnames are different? Thanks in advance Gonzalo -- 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.
