[Puppet Users] Re: Best Practices Rewrite - First Draft
Le dimanche 11 octobre 2009 à 12:58 -0700, Paul Lathrop a écrit : Hey everyone, Well, I really was meaning to get this cleaned up and put on the wiki, but the world seems to conspire against it. First couple of times I sat down to do it, I got Nagios pages. The last time was the real winner, though. Tuesday night I sat down to get feedback integrated and post this to the wiki when my partner called to me from the back room. To make a long story short: on Wednesday morning my son, who was originally due Dec. 31st, decided to make an early appearance. He's in the NICU, and doing great, but my attention is probably going to be elsewhere for awhile. Congrats ! signature.asc Description: Ceci est une partie de message numériquement signée
[Puppet Users] Re: Best Practices Rewrite - First Draft
I swear people who use Puppet are more fertile. Congratulations, Paul! Julian. 2009/10/12 Nicolas Szalay nsza...@qualigaz.com: Le dimanche 11 octobre 2009 à 12:58 -0700, Paul Lathrop a écrit : Hey everyone, Well, I really was meaning to get this cleaned up and put on the wiki, but the world seems to conspire against it. First couple of times I sat down to do it, I got Nagios pages. The last time was the real winner, though. Tuesday night I sat down to get feedback integrated and post this to the wiki when my partner called to me from the back room. To make a long story short: on Wednesday morning my son, who was originally due Dec. 31st, decided to make an early appearance. He's in the NICU, and doing great, but my attention is probably going to be elsewhere for awhile. Congrats ! -- Julian Simpson Software Build and Deployment http://www.build-doctor.com --~--~-~--~~~---~--~~ 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: Best Practices Rewrite - First Draft
Julian Simpson a écrit : I swear people who use Puppet are more fertile. Congratulations, Paul! Julian. this is just that they do not let chaos do the job even in biology, all is managed in a central repository secured by ssl certificates where the family keeps his good practice since years now leading to a greater chance of success. Of course i think Paul should have a look at children virtualisation because they tend to proliferate quickly as they come natively with 'i want a brother' service installed and running on port 3year... :) regards, Jean. --~--~-~--~~~---~--~~ 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: Best Practices Rewrite - First Draft
On Sun, Oct 11, 2009 at 12:58 PM, Paul Lathrop paul.lath...@gmail.com wrote: Hey everyone, Well, I really was meaning to get this cleaned up and put on the wiki, but the world seems to conspire against it. First couple of times I sat down to do it, I got Nagios pages. The last time was the real winner, though. Tuesday night I sat down to get feedback integrated and post this to the wiki when my partner called to me from the back room. To make a long story short: on Wednesday morning my son, who was originally due Dec. 31st, decided to make an early appearance. He's in the NICU, and doing great, but my attention is probably going to be elsewhere for awhile. Congratulations Paul! Really glad to hear he's doing well. Hope the same holds true for you and your partner as well. If anyone feels up to grabbing this document and running with it, please feel free. Regards, Paul Lathrop -- nigel --~--~-~--~~~---~--~~ 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: tagmail configuration
On Thu, Oct 8, 2009 at 6:14 PM, Luke Schierer luke.schie...@gmail.comwrote: I am trying to configure tagmail to send emails to different segments of the team based on the classes that are loaded. For the most part it seems to be working, but I'm having trouble with getting a rule that will send an email for everything except events related to a particular class, or those with a particular tag. In my tagmail.conf I have type1, !nolog: gro...@domain.tld type2, !nolog: gro...@domain.tld all, !noisy, !nolog: myem...@domain.tld the type1 and type2 lines appear to work as intended, but the last line doesn't. It is correctly filtering out events specifically tagged with tag = nolog, but it still sends me events from the noisy class.Any ideas on how I can filter out events from this class without tagging each element? Thanks! Luke Googling this, I found http://markmail.org/message/jib4n4bq7qmbsb4q#query:puppet%20tagmail%20exclude%20one%20class+page:1+mid:f6v5hhgl6h624xqx+state:results which seems to indicate that this behavior is considered a bug. Further investigation turns up bug #1035 in the tracker. I am sorry for failing to better research this before posting. --~--~-~--~~~---~--~~ 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] new to puppet. how to add condition in a class?
Hi. II am trying puppet after cfengine and I am looking for a method to use a class if a file exist. exemple I have a condition class. I have to create on the server the condition class but i do not want to have it execute on every client. It is not easy for me to set on the server the condition to execute the class. I prefer runing class on my client if thereis a file exemple if the file /etc/mypuppet/condition is present execute the condition class. Is it possible? How can i do it? thanks for your help. regards --~--~-~--~~~---~--~~ 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] Variable to be available to different puppet clients
Hi all, I am trying to cache data, which should be available to different puppet clients and so far I am not successful. The cached data should reside in a variable and not in a flat file. When the first puppetclient connects to the puppetmaster, then the puppetmaster generates the data dynamically and stores in a variable. Then the data in that variable should be available to different puppet clients without the need for re-generating the data. Could you please help me with it. An example would be great. I posted the question in puppet-dev group and heres the link. The final conclusion was that simply provide the data with an external node tool. People on puppet- users might be able to help you on that. The complete link for the thread : http://groups.google.com/group/puppet-dev/browse_thread/thread/4df9df7d7ef7e4c/6cd926a26fa4e9e8#6cd926a26fa4e9e8 Thanks, Sunil. --~--~-~--~~~---~--~~ 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: Variable to be available to different puppet clients
Sunil, I read the thread. The way Puppet works, it's going to compile a specific catalog for the host making a requests with essentially a blank slate every time. You could do something like extend Ohad's example and add a global variable to the Ruby runtime that gets assigned the first time it is requested instead of using a file to store the state. (Of course that solution creates it's own potential problems.) The only way the data will be available is through the custom function, but the logic can be such that it just returns the value once it has been computed. Another way to share information between hosts is exporting and collecting resources. Do you have an explicit use case? If we know more about the problem you are trying to solve, we might have better solutions. Regards, Andrew Shafer Reductive Labs On Mon, Oct 12, 2009 at 4:31 AM, Sunil_mlec sunilm...@gmail.com wrote: Hi all, I am trying to cache data, which should be available to different puppet clients and so far I am not successful. The cached data should reside in a variable and not in a flat file. When the first puppetclient connects to the puppetmaster, then the puppetmaster generates the data dynamically and stores in a variable. Then the data in that variable should be available to different puppet clients without the need for re-generating the data. Could you please help me with it. An example would be great. I posted the question in puppet-dev group and heres the link. The final conclusion was that simply provide the data with an external node tool. People on puppet- users might be able to help you on that. The complete link for the thread : http://groups.google.com/group/puppet-dev/browse_thread/thread/4df9df7d7ef7e4c/6cd926a26fa4e9e8#6cd926a26fa4e9e8 Thanks, Sunil. --~--~-~--~~~---~--~~ 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] Best Practices Rewrite - First Draft
Julian Simpson writes: I swear people who use Puppet are more fertile. Congratulations, Paul! Or at least using Puppet frees up time for side projects. --~--~-~--~~~---~--~~ 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: Best Practices Rewrite - First Draft
On Mon, Oct 12, 2009 at 5:09 AM, Jean Spirat jeanspi...@squirk.org wrote: Julian Simpson a écrit : I swear people who use Puppet are more fertile. Congratulations, Paul! Julian. this is just that they do not let chaos do the job even in biology, all is managed in a central repository secured by ssl certificates where the family keeps his good practice since years now leading to a greater chance of success. Of course i think Paul should have a look at children virtualisation because they tend to proliferate quickly as they come natively with 'i want a brother' service installed and running on port 3year... :) You guys crack me up. Thanks for all the good wishes! --Paul --~--~-~--~~~---~--~~ 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: Best Practices Rewrite - First Draft
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Paul Lathrop wrote:
You guys crack me up. Thanks for all the good wishes!
--Paul
Congrats +1!
node offspring inherits plathrop {
include littlebundleofjoy
include nosleep
include puppet
}
Cheers
James Turnbull
- --
Author of:
* Pro Linux Systems Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQEcBAEBAgAGBQJK05+OAAoJECFa/lDkFHAyS6MIALBdQoUFnLhQ7zoUwg/4mDK4
4pYRkeSGDWcg8S4l7SqQyI4on6XLVCXtRCqYQGG7pqF2tHuMt4oVed91TH+iwqJ1
Dkx626bmxpVGJpSNN3xOgMPDGfnpkbImOIW/EPGhBTEZELCsggYKL8N1JllZqHcF
lmS40/9WB7x/Dx3weJseiE3O2RkknyQrWFCb3QWiVF/Wp6g8HYT27w8+VCetF8UR
3lJYLQIe2A01IBckfLfyUD4T46WqNMFjchOlrac5yQVP8UE5XAZhGfD2Krvlt3zg
GMZbCLg14NB9J3IDg5aJZ4rGUAuqJzV9r3kH8Phi0JKTzVvnqHaH5iRiu/hmnQI=
=YPt2
-END PGP SIGNATURE-
--~--~-~--~~~---~--~~
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: new to puppet. how to add condition in a class?
william Famy william.f...@gmail.com wrote: I prefer runing class on my client if thereis a file exemple if the file /etc/mypuppet/condition is present execute the condition class. If you want to do this, you'll likely have to create a simple facter fact for your clients so that the puppetmaster receives true if this file exists or false otherwise. But from my puppet experience, you seem to be taking the problem the opposite way from the usual way. It's much more common to decide if a class is to be included or not based on the existing facts (hostname, fqdn etc.), and from the puppetmaster. Matthias --~--~-~--~~~---~--~~ 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: Monitoring the puppetmaster
Pete Emerson pemer...@gmail.com wrote: We've got over 150 hosts hitting the one puppetmaster, and based on what I've seen via searching it seems like we're hitting into scalability issues with Webrick, and the recommendation is to switch to Mongrel or Passenger. Looks to me like Passenger is where the focus is, so I'm working on migrating to 0.25 and Passenger, with multiple master nodes for redundancy and scalability. FWIW, we were also seeing our 0.24 puppetmaster stop responding from time to time, requiring a restart. Since upgrading to 0.25.1rc1, reliability has improved a lot, and the load decreased too, while still using the puppetmaster with the included webrick. Matthias --~--~-~--~~~---~--~~ 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: Mac OS X plist resource type spec
Carl, Nigel, Thanks for working on this. It looks great and will be a valuable addition. Sorry for the late reply. I haven't been watching the lists closely lately. I agree that the name auth_membership is probably a poor choice since auth and membership bring to mind other unrelated topics. Here are a few alternative names: union merge merge_values exclusive inclusive Kyle On Oct 8, 2009, at 12:05 PM, Carl Caum wrote: Sorry it took me so long to reply. I don't actually remember why we decided on auth_membership exactly. I remember I originally had it as purge but that was confusing for obvious reasons. If auth_membership was set to true, it would blow away every other entry in that dict/array that was not known by puppet. This is outlined in the text of the doc. On Mon, Oct 5, 2009 at 10:10 AM, Allan Marcus al...@lanl.gov wrote: Very nice. I think there should be support for delete. Maybe expand ensure parameter with values: present: create key/value if not there, do nothing if there absent: remove the key - the value param would not be needed force: create key/value if not there, force the value to equal the value param I'm not sure why the parameter auth_membership is called that. Would this option let me set or replace one value or an array or dict and not blow away the other values, if it were set to true? If set to false, it would blow away all other array/dict values? Also, will it handle the plists in byhost correctly? Figuring our which plist file to change is half the battle. I know there were some articles in recent MacTech magazines about this topic. Have you read them? This look like it's the beginning of being able to manage MCX items via puppet in a more efficient manner. Awesome. Once it's ready, I can envision a ton of type definition libraries to manage all the common stuff. --- Thanks, Allan Marcus 505-667-5666 On Oct 5, 2009, at 8:52 AM, Carl Caum wrote: Nigel Kersten and I had previously worked on a plist provider spec for Mac OS X. Attached is a PDF of the current state. I would appreciate any input and criticisms. Puppet Plist native type spec.pdf --~--~-~--~~~---~--~~ 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: Mac OS X plist resource type spec
How about merge_exclusive? It shows we want to merge all known entries in the defined dict/array, but also shows we exclusively want those defined. On Oct 12, 2009, at 10:58 PM, Crawford Kyle kcrw...@gmail.com wrote: Carl, Nigel, Thanks for working on this. It looks great and will be a valuable addition. Sorry for the late reply. I haven't been watching the lists closely lately. I agree that the name auth_membership is probably a poor choice since auth and membership bring to mind other unrelated topics. Here are a few alternative names: union merge merge_values exclusive inclusive Kyle On Oct 8, 2009, at 12:05 PM, Carl Caum wrote: Sorry it took me so long to reply. I don't actually remember why we decided on auth_membership exactly. I remember I originally had it as purge but that was confusing for obvious reasons. If auth_membership was set to true, it would blow away every other entry in that dict/array that was not known by puppet. This is outlined in the text of the doc. On Mon, Oct 5, 2009 at 10:10 AM, Allan Marcus al...@lanl.gov wrote: Very nice. I think there should be support for delete. Maybe expand ensure parameter with values: present: create key/value if not there, do nothing if there absent: remove the key - the value param would not be needed force: create key/value if not there, force the value to equal the value param I'm not sure why the parameter auth_membership is called that. Would this option let me set or replace one value or an array or dict and not blow away the other values, if it were set to true? If set to false, it would blow away all other array/dict values? Also, will it handle the plists in byhost correctly? Figuring our which plist file to change is half the battle. I know there were some articles in recent MacTech magazines about this topic. Have you read them? This look like it's the beginning of being able to manage MCX items via puppet in a more efficient manner. Awesome. Once it's ready, I can envision a ton of type definition libraries to manage all the common stuff. --- Thanks, Allan Marcus 505-667-5666 On Oct 5, 2009, at 8:52 AM, Carl Caum wrote: Nigel Kersten and I had previously worked on a plist provider spec for Mac OS X. Attached is a PDF of the current state. I would appreciate any input and criticisms. Puppet Plist native type spec.pdf --~--~-~--~~~---~--~~ 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: new to puppet. how to add condition in a class?
You can technically do this with a custom fact as suggested.
if $myfact {
include specialsauce
}
The rational behind why you would want to avoid this in general is
simple, favor specificity.
Machines shouldn't have a file that then decides how something else
gets configured, you should tell machines what files to have.
Conditional statements provide for necessary flexibility, but they
also add complexity.
We try to avoid situations where we have to look on a system to know
how it is configured.
Find a balance that works for you.
Make sense?
On Mon, Oct 12, 2009 at 3:48 PM, Matthias Saou
th...@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net
wrote:
william Famy william.f...@gmail.com wrote:
I prefer runing class on my client if thereis a file exemple if the
file /etc/mypuppet/condition is present execute the condition class.
If you want to do this, you'll likely have to create a simple facter
fact for your clients so that the puppetmaster receives true if this
file exists or false otherwise.
But from my puppet experience, you seem to be taking the problem the
opposite way from the usual way. It's much more common to decide if a
class is to be included or not based on the existing facts (hostname,
fqdn etc.), and from the puppetmaster.
Matthias
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
