[Puppet Users] Re: Best Practices Rewrite - First Draft
If anyone feels up to grabbing this document and running with it, please feel free. As the original author, I suppose I should take over. Can you send me what you had? -- Digant C Kasundra dig...@stanford.edu Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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
- James Turnbull ja...@lovedthanlost.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 R.I.Pienaar wrote: Pattern collections are much better, I'd rather have articles exploring features that people can learn each feature and then apply to their environment than a best practice since those are almost always full of assumptions about local conditions, patterns are flexible and can be molded to your needs.. What Arri said. I'd like to see logical, interlinked set of patterns that can be built into a logical whole rather than a single, potentially unwieldy document. I suppose that's true. Though I have to say some of the patterns that developed in the PuppetCommon modules seemed bad, to me. I guess the issue really becomes when patterns are developed by people first exploring Puppet as opposed to people that have done it a while. But certainly, I think institutions tend to develop their own patterns. Stanford was glad to share what our collective wisdom was with the Best Practices and Style Guide but I think it might be time for us to pull our work back in-house so can we preserve these documents since they are still very much part of what our team uses. -- Digant C Kasundra dig...@stanford.edu Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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
- R.I.Pienaar r...@devco.net wrote: 'lo, - Julian Simpson simpsonjul...@gmail.com wrote: No objections here. I seem to recall that there had a been a discussion at PuppetCamp about perhaps moving to a pattens collection instead of set of best practices - not sure if anyone has bandwidth to to work on this but it might help to keep it in mind. Pattern collections are much better, I'd rather have articles exploring features that people can learn each feature and then apply to their environment than a best practice since those are almost always full of assumptions about local conditions, patterns are flexible and can be molded to your needs.. That's very true. Different local needs and different levels of complexity and business requirements will definitely drive how things should be done. For instance, if you just want to use puppet to make sure a certain package is installed on all servers, you may not need the complexity of larger instances. We have a practice here (partially represented by the out of date best practices) that works well for a large institution with large amount of classes and large difference and ties to external entities like a CMDB. So well defined patterns can be good, but how to write them and more importantly, how to present them in a common area can be difficult, especially where there are multiple solutions to a given problem. Ideas? -- Digant C Kasundra dig...@stanford.edu Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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
No objections here. I seem to recall that there had a been a discussion at PuppetCamp about perhaps moving to a pattens collection instead of set of best practices - not sure if anyone has bandwidth to to work on this but it might help to keep it in mind. Dan North wrote an article on this.[1] http://www.infoq.com/articles/better-best-practices Ironically I have loads of best practices articles on my blog. D'oh. J. 2009/10/18 Stephen Nelson-Smith sanel...@gmail.com: Hi, If anyone feels up to grabbing this document and running with it, please feel free. Not sure if I accidentally half replied to this already I'd be very happy to pick this up. I'm just starting a new project - bring some best practices to a somewhat chaotic and messy large government Drupal infrastructure (and associated services) and am also doing some puppet training, so gathering together collected wisdom, adding my own experiences from 3 years of running puppet, and maintaining the document seems like an ideal fit. Is everyone ok with this? S. -- Stephen Nelson-Smith Technical Director Atalanta Systems Ltd www.atalanta-systems.com -- 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
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 R.I.Pienaar wrote: Pattern collections are much better, I'd rather have articles exploring features that people can learn each feature and then apply to their environment than a best practice since those are almost always full of assumptions about local conditions, patterns are flexible and can be molded to your needs.. What Arri said. I'd like to see logical, interlinked set of patterns that can be built into a logical whole rather than a single, potentially unwieldy document. Regards 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.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEVAwUBStxEzCFa/lDkFHAyAQJymgf+KaNlFgd5Cn3hpPVPLhMU1StC+EvVcaUi ChvDFrJp+dOB//ZoWUdf5W5BEDKNHVd1SfLZGdaZuv8fqR4dgG2u7B8UVcIKx/8t Te0ocC7KxAxd1IhcYDfu20rcsEkN//WEiJFMoHSBq8fP0ZpzZl8yyCQQFIvtfl/c AbCtAr3K42QH7zUxDqv/7aT/MSK1gqmC7Sl+892vdU/g7mEcfYQsgtXEsyRBHR8P 2040gJGlFa6YsAPySaMLUy3zpbK6pVubtn1FH2Jz+wkJZTyU1pvuBOzzV12foSfE s3MQWh85qo2otKGnSBetNUaCOcbah/Xuedfr5LcRmFLHeu5x1R+RdA== =11hx -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: Best Practices Rewrite - First Draft
hello, - James Turnbull ja...@lovedthanlost.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 R.I.Pienaar wrote: Pattern collections are much better, I'd rather have articles exploring features that people can learn each feature and then apply to their environment than a best practice since those are almost always full of assumptions about local conditions, patterns are flexible and can be molded to your needs.. What Arri said. I'd like to see logical, interlinked set of patterns that can be built into a logical whole rather than a single, potentially unwieldy document. Sorry if you consider this just link spam, but read this url that covers just this: http://blogs.usenix.org/2009/10/16/tom-limoncellis-lisa-2009-training-design-patterns-for-system-administrators/ -- R.I.Pienaar --~--~-~--~~~---~--~~ 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
Hi, If anyone feels up to grabbing this document and running with it, please feel free. Not sure if I accidentally half replied to this already I'd be very happy to pick this up. I'm just starting a new project - bring some best practices to a somewhat chaotic and messy large government Drupal infrastructure (and associated services) and am also doing some puppet training, so gathering together collected wisdom, adding my own experiences from 3 years of running puppet, and maintaining the document seems like an ideal fit. Is everyone ok with this? S. -- Stephen Nelson-Smith Technical Director Atalanta Systems Ltd www.atalanta-systems.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
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: 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: Best Practices Rewrite - First Draft
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. If anyone feels up to grabbing this document and running with it, please feel free. Regards, Paul Lathrop --~--~-~--~~~---~--~~ 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 wrote: I would have assumed that you'd always want to qualify the module names as the best practise. Collisions in namespaces wreak havoc in many other domains. I'm thinking of Java class names being bound to domain names as an approach that works elsewhere. Like rpm/deb packages, modules have a well regulated namespace. Iff there were a clash, those modules would probably come from two different implementors and quite likely do have different enough requirements and overlapping contents that they don't work together anyways. That being said apache just is much easier to type than at.co.black.puppet.apache.[1] Regards, DavidS [1] and also would ruin the pun ;-) --~--~-~--~~~---~--~~ 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
I would have assumed that you'd always want to qualify the module
names as the best practise. Collisions in namespaces wreak havoc in
many other domains. I'm thinking of Java class names being bound to
domain names as an approach that works elsewhere.
Am I being naive?
Best
Julian
2009/9/17 Peter Meier peter.me...@immerda.ch:
Hi
I think that would be terrible. Having two different paths for the
same namespace is confusing and will easily lead to problems.
yeah I feel more this way as well.
However, the example you give is correct: you can't have the same
module name in two modulepaths and usually want to prefix the
classnames to avoid name collisions.
so for the Best Practises:
If we do multiple sources for a file (and I do that a lot, as it makes
puppet so flexible) what would you prefer?
in module foobar and the 0.25 way:
file{'/tmp/a':
source = [ puppet:///files/foobar/${fqdn}/a,
puppet:///files/foobar/a,
puppet:///modules/foobar/${operatingsystem}/a,
puppet:///modules/foobar/a ],
}
or
file{'/tmp/a':
source = [ puppet:///modules/site-foobar/${fqdn}/a,
puppet:///modules/site-foobar/a,
puppet:///modules/foobar/${operatingsystem}/a,
puppet:///modules/foobar/a ],
}
???
cheers pete
--
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
Hi so I took again a look a this rather old thread, as I tried to implement things as I thought I have understood them. good idea! Currently I have all site specific stuff in one big module, but like that I might be able to organize it again in modules per each site specific module adaptions. Question: Is autoloading looking in both module directories? so if it's not found in the module in one module directory it's still looking in the other one? I assume so, but as I haven't used it yet I better ask... ;) modulepath option must be set in your puppet.conf file. yeah, that for sure. But so I assume it looks for ssh::client in every ssh module it can find in the different modulepaths. After this discussion I thought that modules can be scattered amongst the various module paths. But this doesn't seem to be the case. At least my experience shows that puppet simply respects the classes of a module it founds in the first location, all the classes in a second location get ignored. So the best practices would be to have 2 module paths, one with the public modules and one module path with the site-specific module - extensions, prefixed with site? so something like: modules/public/apache - public apache module modules/site/site-apache - site specific implementations of apache To throw up the question: Wouldn't it be nicer if puppet would collect a module's classes from all module pathes? It would at least make my site specific module changes look a bit nicer and I still wouldn't have to mix these. However I see all the problems coming up with this solution. I'm just curious what other people think. cheers pete --~--~-~--~~~---~--~~ 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
- Peter Meier peter.me...@immerda.ch wrote: Hi so I took again a look a this rather old thread, as I tried to implement things as I thought I have understood them. good idea! Currently I have all site specific stuff in one big module, but like that I might be able to organize it again in modules per each site specific module adaptions. Question: Is autoloading looking in both module directories? so if it's not found in the module in one module directory it's still looking in the other one? I assume so, but as I haven't used it yet I better ask... ;) modulepath option must be set in your puppet.conf file. yeah, that for sure. But so I assume it looks for ssh::client in every ssh module it can find in the different modulepaths. After this discussion I thought that modules can be scattered amongst the various module paths. But this doesn't seem to be the case. At least my experience shows that puppet simply respects the classes of a module it founds in the first location, all the classes in a second location get ignored. So the best practices would be to have 2 module paths, one with the public modules and one module path with the site-specific module - extensions, prefixed with site? so something like: modules/public/apache - public apache module modules/site/site-apache - site specific implementations of apache To throw up the question: Wouldn't it be nicer if puppet would collect a module's classes from all module pathes? It would at least make my site specific module changes look a bit nicer and I still wouldn't have to mix these. However I see all the problems coming up with this solution. I'm just curious what other people think. I think that would be terrible. Having two different paths for the same namespace is confusing and will easily lead to problems. However, the example you give is correct: you can't have the same module name in two modulepaths and usually want to prefix the classnames to avoid name collisions. -- Digant C Kasundra dig...@stanford.edu Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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
Hi guys, As Peter points out, this thread is old. Sorry I dropped the ball, I plan on integrating feedback and getting this updated this weekend. --Paul On Wed, Sep 16, 2009 at 6:40 AM, Peter Meier peter.me...@immerda.ch wrote: Hi so I took again a look a this rather old thread, as I tried to implement things as I thought I have understood them. good idea! Currently I have all site specific stuff in one big module, but like that I might be able to organize it again in modules per each site specific module adaptions. Question: Is autoloading looking in both module directories? so if it's not found in the module in one module directory it's still looking in the other one? I assume so, but as I haven't used it yet I better ask... ;) modulepath option must be set in your puppet.conf file. yeah, that for sure. But so I assume it looks for ssh::client in every ssh module it can find in the different modulepaths. After this discussion I thought that modules can be scattered amongst the various module paths. But this doesn't seem to be the case. At least my experience shows that puppet simply respects the classes of a module it founds in the first location, all the classes in a second location get ignored. So the best practices would be to have 2 module paths, one with the public modules and one module path with the site-specific module - extensions, prefixed with site? so something like: modules/public/apache - public apache module modules/site/site-apache - site specific implementations of apache To throw up the question: Wouldn't it be nicer if puppet would collect a module's classes from all module pathes? It would at least make my site specific module changes look a bit nicer and I still wouldn't have to mix these. However I see all the problems coming up with this solution. I'm just curious what other people think. cheers pete --~--~-~--~~~---~--~~ 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
Hi
I think that would be terrible. Having two different paths for the
same namespace is confusing and will easily lead to problems.
yeah I feel more this way as well.
However, the example you give is correct: you can't have the same
module name in two modulepaths and usually want to prefix the
classnames to avoid name collisions.
so for the Best Practises:
If we do multiple sources for a file (and I do that a lot, as it makes
puppet so flexible) what would you prefer?
in module foobar and the 0.25 way:
file{'/tmp/a':
source = [ puppet:///files/foobar/${fqdn}/a,
puppet:///files/foobar/a,
puppet:///modules/foobar/${operatingsystem}/a,
puppet:///modules/foobar/a ],
}
or
file{'/tmp/a':
source = [ puppet:///modules/site-foobar/${fqdn}/a,
puppet:///modules/site-foobar/a,
puppet:///modules/foobar/${operatingsystem}/a,
puppet:///modules/foobar/a ],
}
???
cheers pete
--~--~-~--~~~---~--~~
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
I sketched a schema describing the use of multiple environments and git submodules for Puppet development. It's available on the wiki both in both OpenOffice Draw format and PDF. http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.odg http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.pdf I'll be glad if it could be useful for the best practices. It currently relies heavily on git features, but it's probably doable to sketch something similar with other versionning tools. I'm not a git expert and can't tell from the diagram if the puppetmaster in this configuration can serve out multiple environments at once? And if so, how does it do that? Does it not rely on different paths per environment? --~--~-~--~~~---~--~~ 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
Hi, David Schmitt wrote: * Environments and the workflow surrounding them There is already UsingMultipleEnvironments, which has all the technical stuff. Perhaps a few sentences about how to use the production, testing, and development environment. I sketched a schema describing the use of multiple environments and git submodules for Puppet development. It's available on the wiki both in both OpenOffice Draw format and PDF. http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.odg http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.pdf I'll be glad if it could be useful for the best practices. It currently relies heavily on git features, but it's probably doable to sketch something similar with other versionning tools. François --~--~-~--~~~---~--~~ 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
Francois Deppierraz wrote: Hi, David Schmitt wrote: * Environments and the workflow surrounding them There is already UsingMultipleEnvironments, which has all the technical stuff. Perhaps a few sentences about how to use the production, testing, and development environment. I sketched a schema describing the use of multiple environments and git submodules for Puppet development. It's available on the wiki both in both OpenOffice Draw format and PDF. http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.odg http://reductivelabs.com/trac/puppet/attachment/wiki/PuppetVersionControl/puppetmaster-git-submodules.pdf I'll be glad if it could be useful for the best practices. It currently relies heavily on git features, but it's probably doable to sketch something similar with other versionning tools. The more I think about it, the more I come to believe that puppet manifests should not only be version controlled, but also have a real release and patch cycle. Using submodules would be a convenient way to specify a release when working with git. Thanks for the nice graphics :) Regards, DavidS --~--~-~--~~~---~--~~ 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
Thanks for all the feedback everyone. I'll be working on a second draft and getting it up on the wiki soon! --Paul On Thu, Jul 23, 2009 at 1:06 AM, David Schmittda...@dasz.at wrote: Paul Lathrop wrote: Hi Puppeteers, I spent some time tonight making a first pass at what I hope will eventually be a good replacement for the current Puppet Best Practices page on the wiki. I know this needs *tons of work, but I hit a good pausing point and decided it was time to ask for feedback and contributions. The idea here is to provide some overall guidelines to help newcomers to Puppet establish good habits as well as get the most out of Puppet, and especially to highlight some common mistakes and how to avoid them. Please take a look and flame away. I need feedback, both positive and negative, as well as input as to what the Best Practices actually are (Volcane, I'm looking at you!). I especially need to flesh out that final section. Thanks for picking up that work. It's good to see movement here! There are some thing I'm missing: * How to arrange modules, what constitutes a module? There's this quip If you ever wonder whether X is running, X should be a module. Also, some thoughts about how using external modules works? * Environments and the workflow surrounding them There is already UsingMultipleEnvironments, which has all the technical stuff. Perhaps a few sentences about how to use the production, testing, and development environment. * An overview of the recommended filesystem layout What goes to /etc/puppet, where to put modules and modules in different environments. * Using an external node classifier to split configuration (node+data+class list) and manifests (modules and manifests) * Recommend to replace complete config files instead of editing it in-place. Thank you again for your time and work! Regards, DavidS -- My pants growl with the hunger of a thousand bubblebees. And it feels like a Koala crapped a rainbow in my brain! -MasterShakezula --~--~-~--~~~---~--~~ 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
Digant C Kasundra wrote: * Because of complexity of how and when classes are interpreted, aren't variables often a tricky thing to play with if you are planning to change their values in later scopes? With the current tooling, I think the only real chance is to put all choosing values for variables which will influence my manifests functionality in an external nodes classifier which does proper, flexible and organisation-specific lookups. HAving this, manifests and modules do have a greatly reduced need to change values in later scopes. * Lastly, perhaps this is still my OCD, but I'm still a fan of the style guide. Without it, I dont' think our manifests would be as clean and legible as they currently are. +1 Regards, DavidS --~--~-~--~~~---~--~~ 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
* Because of complexity of how and when classes are interpreted, aren't variables often a tricky thing to play with if you are planning to change their values in later scopes? With the current tooling, I think the only real chance is to put all choosing values for variables which will influence my manifests functionality in an external nodes classifier which does proper, flexible and organisation-specific lookups. HAving this, manifests and modules do have a greatly reduced need to change values in later scopes. I agree. * Lastly, perhaps this is still my OCD, but I'm still a fan of the style guide. Without it, I dont' think our manifests would be as clean and legible as they currently are. +1 :) -- Digant C Kasundra dig...@stanford.edu Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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
Mark Plaksin wrote:
One potential fix for that is to check for deletions, like so:
Thanks for doing work for us :) We noticed the need for this but
haven't had a chance to fix it. Your change works great. I updated the
Wiki.
Cool. Credit for that one goes to Ricky Zhou. When we added this the
Fedora Infrastructure puppet repo, he was the first one lucky enough
to get bitten by it. :)
One other potential problem is if puppet is used to manage selinux
modules. Compiled modules also have a .pp extension. When adding or
updating these files they will pass the if [[ $name =~ [.]pp$ ]]
check. This can be avoided by not version controlling the compiled
modules, but perhaps it might also be reasonable to add a quick bit to
the if test, something like this (untested):
if [[ $name =~ [.]pp$ ]] [ $(file -b $name 2/dev/null) != 'data'
]
The selinux .pp files will return data, while I can't imaging any
puppet manifests being labeled as data. :)
This sounds good to me but maybe it's not safe to assume GNU file (which
supports the -b) is installed on your puppetmaster?
It might not be a safe assumption. Having any file command might not
be safe to assume, really. Worse, the test above wouldn't work
because $name would not be available as a file so the command would
fail. Here's something a little more likely to work (I did test this
one):
diff --git a/puppet-update-hook b/puppet-update-hook
index 539f969..74acaa7 100644
--- a/puppet-update-hook
+++ b/puppet-update-hook
@@ -40,6 +40,9 @@ do
if [[ $name =~ [.]pp$ ]]
then
git cat-file blob $new_sha1 $tmp
+# SELinux modules also have a .pp extension, try to skip them
+ftype=$((file $tmp | awk -F': ' '{print $2}') 2/dev/null)
+[ $ftype = data ] continue
set -o pipefail
$syntax_check $tmp 21 | sed
's|/tmp/git.update...:\([0-9]*\)$|JOJOMOJO:\1|' $log
if [[ $? != 0 ]]
If file isn't available, the hook might still try to syntax check a
non-puppet .pp file, but that's no worse than things are currently.
In testing, there are a few other things I noticed. When making an
initial push with this hook enabled, $2 is 00, which causes git
diff-tree to yield an error. Fixing this would require a bit of
fiddling. I'm also wondering if there's any good reason to keep the
'echo diff-tree:; cat $tree' code? It looks like leftover debugging
to me.
One other potential improvement I have is to use shorter commit id's
when telling a user how to check the diff when a problem is found:
diff --git a/puppet-update-hook b/puppet-update-hook
index 74acaa7..38551ef 100644
--- a/puppet-update-hook
+++ b/puppet-update-hook
@@ -49,7 +49,7 @@ do
then
echo
echo -e $(cat $log | sed 's|JOJOMOJO|'\\${RED}${name}\\${NOBOLD}'|')
2
- echo -e For more details run this: ${CYAN} git diff $old_sha1 $new_sha1
${NOBOLD} 2
+ echo -e For more details run this: ${CYAN} git diff ${old_sha1:0:7}
${new_sha1:0:7} ${NOBOLD} 2
echo
exit_status=1
fi
--
ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~
It is impossible to enjoy idling thoroughly unless one has plenty of
work to do.
-- Jerome K. Jerome
pgpa8s86EZckh.pgp
Description: PGP signature
[Puppet Users] Re: Best Practices Rewrite - First Draft
- Paul Lathrop p...@tertiusfamily.net wrote: Hi Puppeteers, I spent some time tonight making a first pass at what I hope will eventually be a good replacement for the current Puppet Best Practices page on the wiki. I know this needs *tons of work, but I hit a good pausing point and decided it was time to ask for feedback and contributions. The idea here is to provide some overall guidelines to help newcomers to Puppet establish good habits as well as get the most out of Puppet, and especially to highlight some common mistakes and how to avoid them. Please take a look and flame away. I need feedback, both positive and negative, as well as input as to what the Best Practices actually are (Volcane, I'm looking at you!). I especially need to flesh out that final section. I was hoping to redraft this myself when 0.25 came out, but looks like you've beat me to it. Sadly, time doesn't allow me to follow up as closely with the user list as I'd like, (my participation with Puppet as been limited lately to the asynchronous storeconfigs work we've contracted). Here are some comments to consider: * A lot of this does read more like an introduction to Puppet and Puppet concepts, so some of this might need to be broken away elsewhere. * While classes aren't object-oriented, I think treating them as if they are isn't necessarily a bad thing either. Ultimately, when you inherit you are only given yourself permission to override the declared resources, but I also find it to be a good idea to keep this kind of modeling to properly represent what is happening. Ergo, when one class is a derivative of another, I find it better to inherit instead of include, even if I am not overriding a declared resource, simply because modeling shouldn't be a function of what features you are using. * While one shouldn't overuse dependencies, I wouldn't put notify and subscribe in the same boat since they are functionally useful for things besides trying to make Puppet do something in a particular order. I think the intent was just to relate the two parameters to before and require but I would recommend removing it or relocating it so we don't give the impression that using notify or subscribe is a bad idea. * Because of complexity of how and when classes are interpreted, aren't variables often a tricky thing to play with if you are planning to change their values in later scopes? * Lastly, perhaps this is still my OCD, but I'm still a fan of the style guide. Without it, I dont' think our manifests would be as clean and legible as they currently are. -- Digant C Kasundra dig...@stanford.edu Technical Lead, ITS Unix Systems and Applications, Stanford University --~--~-~--~~~---~--~~ 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
Paul Lathrop wrote: Hi Puppeteers, I spent some time tonight making a first pass at what I hope will eventually be a good replacement for the current Puppet Best Practices page on the wiki. I know this needs *tons of work, but I hit a good pausing point and decided it was time to ask for feedback and contributions. The idea here is to provide some overall guidelines to help newcomers to Puppet establish good habits as well as get the most out of Puppet, and especially to highlight some common mistakes and how to avoid them. Please take a look and flame away. I need feedback, both positive and negative, as well as input as to what the Best Practices actually are (Volcane, I'm looking at you!). I especially need to flesh out that final section. Thanks for picking up that work. It's good to see movement here! There are some thing I'm missing: * How to arrange modules, what constitutes a module? There's this quip If you ever wonder whether X is running, X should be a module. Also, some thoughts about how using external modules works? * Environments and the workflow surrounding them There is already UsingMultipleEnvironments, which has all the technical stuff. Perhaps a few sentences about how to use the production, testing, and development environment. * An overview of the recommended filesystem layout What goes to /etc/puppet, where to put modules and modules in different environments. * Using an external node classifier to split configuration (node+data+class list) and manifests (modules and manifests) * Recommend to replace complete config files instead of editing it in-place. Thank you again for your time and work! Regards, DavidS --~--~-~--~~~---~--~~ 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
Paul Lathrop p...@tertiusfamily.net writes: Hi Puppeteers, I spent some time tonight making a first pass at what I hope will eventually be a good replacement for the current Puppet Best Practices page on the wiki. Thanks! Please take a look and flame away. I need feedback, both positive and negative, as well as input as to what the Best Practices actually are (Volcane, I'm looking at you!). I especially need to flesh out that final section. I'm sure you know this but when you talk about version control be sure to mention a syntax-checking pre-commit hook. That has saved us countless hours. This page has hooks for SVN and Git: http://reductivelabs.com/trac/puppet/wiki/PuppetVersionControl --~--~-~--~~~---~--~~ 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
Hi Paul,
Some comments about the doc.
Use double-quotes around node names I would say using single quotes
is better since the Puppet language does not try to parse it for
variables. I have not done any tests in Puppet of single over double
quotes but have seen other interpreted languages recommend single
quote first over double for performance reasons.
At least for me I tend to make Puppet modules very atomic. Meaning
many smaller modules/classes than one large monolithic module. ie you
want to manage ssh. Perhaps break it up into a client and server
class, but one module.
For multi-platform support I've found the best way to support it is
via case statements at the high level
class openssh {
case $operatingsystem {
centos, redhat: { include openssh::redhat }
debian, ubuntu: { include openssh::debian }
default: { fail(${title} is not defined for operating system
${operatingsystem}.) }
}
}
Any common steps can be included in the class or broken out into a
openssh::base class
In some cases you not only want to install the application, but they
are situations to remove it (in my case had a need to ensure the
package is removed for security) I use the naming convention
cups::disable - To install but disable service (primarily for
dependancy with other packages)
cups::remove - To make sure the package and service are not running
Inheritance is great for creating a generic module and creating a site
module for your specific needs (In my case we have a generic proftpd
but then have a site specific for custom DirectAdmin (a hosting
control panel) configurations )
Teyo's recommends two module folders, one dist and another site. site
folder containing modules specific to your install.
-L
--
Larry Ludwig
Reductive 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: Best Practices Rewrite - First Draft
Hi
Use double-quotes around node names I would say using single quotes
is better since the Puppet language does not try to parse it for
variables. I have not done any tests in Puppet of single over double
quotes but have seen other interpreted languages recommend single
quote first over double for performance reasons.
so do I, but maybe another flamewar? ;) But I never thought about the
performance issue, might be a reasonable argument.
At least for me I tend to make Puppet modules very atomic. Meaning
many smaller modules/classes than one large monolithic module. ie you
want to manage ssh. Perhaps break it up into a client and server
class, but one module.
+1
For multi-platform support I've found the best way to support it is
via case statements at the high level
class openssh {
case $operatingsystem {
centos, redhat: { include openssh::redhat }
debian, ubuntu: { include openssh::debian }
default: { fail(${title} is not defined for operating system
${operatingsystem}.) }
}
}
Any common steps can be included in the class or broken out into a
openssh::base class
so do I! so +1
In some cases you not only want to install the application, but they
are situations to remove it (in my case had a need to ensure the
package is removed for security) I use the naming convention
cups::disable - To install but disable service (primarily for
dependancy with other packages)
cups::remove - To make sure the package and service are not running
+1
Inheritance is great for creating a generic module and creating a site
module for your specific needs (In my case we have a generic proftpd
but then have a site specific for custom DirectAdmin (a hosting
control panel) configurations )
+1
Teyo's recommends two module folders, one dist and another site. site
folder containing modules specific to your install.
good idea! Currently I have all site specific stuff in one big module,
but like that I might be able to organize it again in modules per each
site specific module adaptions. Question: Is autoloading looking in
both module directories? so if it's not found in the module in one
module directory it's still looking in the other one? I assume so, but
as I haven't used it yet I better ask... ;)
cheers pete
--~--~-~--~~~---~--~~
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
good idea! Currently I have all site specific stuff in one big module, but like that I might be able to organize it again in modules per each site specific module adaptions. Question: Is autoloading looking in both module directories? so if it's not found in the module in one module directory it's still looking in the other one? I assume so, but as I haven't used it yet I better ask... ;) modulepath option must be set in your puppet.conf file. -L -- Larry Ludwig --~--~-~--~~~---~--~~ 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
Mark Plaksin wrote: I'm sure you know this but when you talk about version control be sure to mention a syntax-checking pre-commit hook. That has saved us countless hours. This page has hooks for SVN and Git: http://reductivelabs.com/trac/puppet/wiki/PuppetVersionControl Indeed, this helps a lot for catching the really obvious typos, thanks Mark for helping to work out a good git hook. One potential fix for that is to check for deletions, like so: --- puppet-update-hook~ 2009-07-23 09:53:52.0 -0400 +++ puppet-update-hook 2009-07-23 09:58:11.0 -0400 @@ -15,6 +15,10 @@ do # skip lines showing parent commit test -z $new_sha1 continue + +# skip deletions +[ $new_sha1 = ] continue + # Only test .pp files if [[ $name =~ [.]pp$ ]] then One other potential problem is if puppet is used to manage selinux modules. Compiled modules also have a .pp extension. When adding or updating these files they will pass the if [[ $name =~ [.]pp$ ]] check. This can be avoided by not version controlling the compiled modules, but perhaps it might also be reasonable to add a quick bit to the if test, something like this (untested): if [[ $name =~ [.]pp$ ]] [ $(file -b $name 2/dev/null) != 'data' ] The selinux .pp files will return data, while I can't imaging any puppet manifests being labeled as data. :) -- ToddOpenPGP - KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp ~~ A lot of people I know believe in positive thinking, and so do I. I believe everything positively stinks. -- Lew Col pgpJekzt1x9JV.pgp Description: PGP signature
[Puppet Users] Re: Best Practices Rewrite - First Draft
Hi good idea! Currently I have all site specific stuff in one big module, but like that I might be able to organize it again in modules per each site specific module adaptions. Question: Is autoloading looking in both module directories? so if it's not found in the module in one module directory it's still looking in the other one? I assume so, but as I haven't used it yet I better ask... ;) modulepath option must be set in your puppet.conf file. yeah, that for sure. But so I assume it looks for ssh::client in every ssh module it can find in the different modulepaths. cheers pete --~--~-~--~~~---~--~~ 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
Todd Zullinger t...@pobox.com writes: One potential fix for that is to check for deletions, like so: Thanks for doing work for us :) We noticed the need for this but haven't had a chance to fix it. Your change works great. I updated the Wiki. One other potential problem is if puppet is used to manage selinux modules. Compiled modules also have a .pp extension. When adding or updating these files they will pass the if [[ $name =~ [.]pp$ ]] check. This can be avoided by not version controlling the compiled modules, but perhaps it might also be reasonable to add a quick bit to the if test, something like this (untested): if [[ $name =~ [.]pp$ ]] [ $(file -b $name 2/dev/null) != 'data' ] The selinux .pp files will return data, while I can't imaging any puppet manifests being labeled as data. :) This sounds good to me but maybe it's not safe to assume GNU file (which supports the -b) is installed on your puppetmaster? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
