similar to: Custom package install best practices

Howdy. I feel like I am missing something really simply with regards to the way that Puppet works and I am wondering if someone can point me in the write direction. I have written a class that downloads, uncompresses, compiles, and installs Python from source. So far so good. The problem is that it only needs to do this once, when Python is not already in place (or some other custom

We''re running puppet 2.7.11 and facter 1.6.1. We''re at a point where we need to start having some custom facts for our environment but we''re not sure the best way to go around it, so I''m looking for feedback from the community. I''ve setup custom facts with facter now and have successfully polled these and also proven that the puppet clients have

Hi I''m anxious to get puppet into production, and although I''d prefer installing puppet as a .deb package (as most of the servers in our shop runs Debian), I think I''ll try to get some of my not-so- important servers into my test setup by installing puppet with the .tgz files. Upon the first installation I realize that puppetd and puppetmasterd is copied to

We keep our puppet configuration in a revision control system and are trying to facilitate developers using the same modules as production/ staging servers. We define a variable ($servergroup) as test/staging/production and use fileserver defaults from hostname to servergroup to generic. The hostname and $servergroup versions need to be confidential. We have modules specific to an application,

Hi, Sorry to hassle everyone again, yes I''m a newbie!! I''ve created some code and I''m getting a out of sync style error message. Here''s a snipet of the code (to reproduce the problem): package { [ "tar", "gzip", "bzip2", "sed" ]: ensure => latest } define xxx { $xenrelease = ''3.0.4''

Our shop is newly adopting puppet. Our number of nodes is growing and my installation method is thus far manual and tedious. This will change when/if we migrate to Puppet Enterprise. My question is what''s a best practice for managing puppet installations on client nodes? Is it possible to separate out the client portion of the install from the server or is that now fully

So, my configuration attempts are aimed at Linodes . Ubuntu 10.10 to be exact. Linodes are libcloud enabled as well as basically provisioned. What I seek to do is add to that, not build from nothing, since libcloud et. al. give me a base to work with. What is the canonical way to manage this situation? For example: $ puppet resource package --verbose openssh-client package {

Hi, Ubuntu Lucid has a very outdated puppet, 0.25.4 according to: http://docs.puppetlabs.com/guides/puppetlabs_package_repositories.html#for-debian-and-ubuntu I did this to "enable the repository": wget http://apt.puppetlabs.com/puppetlabs-release_1.0-3_all.deb sudo dpkg -i puppetlabs-release_1.0-3_all.deb but this still does not result in installing an up to date puppet apt-get

Hi All, I''m in the process of creating Puppet modules for my load balanced environment. I have multiple Apache nodes behind a load balancer and each Apache virtual host has its own internal IP. I''ve created an Apache module that does this by creating an Apache vhost template and define my own variables that are substituted by variables I''ve defined in my nodes

My manifest includes this snippet class app_client_openbsd { $app_client_pkgs_obsd = [ ''glib2-2.24.1p2'', ''gtar-1.23p1'' ] package { "${app_client_pkgs_obsd}": ensure => ''installed'', source => "http://${installserver}/openbsd/${operatingsystemrelease}/packages/${hardwaremodel}/${name}.tgz", } This

At long last, 0.24.0 has been released. Look for your friendly packagers to package it up in the near future, but in the meantime you can download it: http://reductivelabs.com/downloads/puppet/puppet-0.24.0.tgz I''ll be walking the different release sites (RubyForge et al) and posting it there, too. Look for a related announcement later today on changes in development practices

Hi all. New puppet developer. Very excited. I have the agents communicating with the puppet master. I''m wondering now about best practice for file and user permissions on the puppet master. Most of my wonder probably stems from general lack of understanding in this area. I''d like to get it right though to avoid refactoring later. 1. What''s the best practice, or your

Hi, The following is with the latest (and last) puppetmaster/puppetd on FC5. I use puppet to configure a server and several workstations on my home network. This includes managing several files of >5Mbyte on the workstations. I have had problems recently with timeout errors on some of these files. These errors seem consistent for a particular puppet setup/configuration, but can change when

G''day. I am wondering what the current best practice for building a single file out of distributed fragments is with puppet. Specifically, my problem: 1. Install munin-node on arbitrary machines. 2. Install ''munin.conf'' as a single file on one machine, containing a configuration stanza for every machine that munin-node is installed on. The current best practice

Hello Everyone, I''m looking for a way to install packages from source via puppet, I was able to locate maybe 5 posts on this subject which is very strange, as I would expect people to still use ./configure with their own customized options. For example, I need to compile Curl with c-ares support, for that I need to set an option for ./configure but can''t find a way to do it.

I''ve just committed Facter 1.3.8. All of the work for this release was done by James Turnbull, so everyone should thank him for getting it done. Here''s the changelog: Fixed Rdoc::usage bug on CentOS 5 - closed Puppet #753 and Facter #40 Added support to return multiple interfaces and their IP addresses and MAC addressess as facts. Returns

For whatever reason, the RPMForge package ruby-rrdtool doesn''t play nice on my CentOS 5.1 box with puppetmaster. It installs site_ruby/1.8/i386-linux/RRD.so, which puppetmaster is unable to find (and the suggested test of ruby -rRRDtool -e ''puts :yep'' fails). Using ln to link RRD.so to RRDtool.so works for the command line test, but still fails for puppetmaster. This

Hi As I''m more familiar with cfengine and it''s way to split updates (in update.conf) from the actual grunt work (in cfagent.conf), I''m wondering how to best manage puppet and my manifests with puppet...? Should I define a puppet class that copy the puppet package (in .tgz format) and all the manifests to the client, and then have all my other classes depend on

I like the Stanford Best Practices guide for puppet. One thing I didn''t see it address was handling of separate environments, for example Dev, Test, Staging, Production. My thoughts on this so far, are: brainstorm #1) Handle environment differences with metadata: node devProductName01 { $env = "dev" include ProductName-webserver } node testProductName01 {

All, I am currently trying to find a better way to do change management for my puppet code. Currently we have a single Master with two environments (test and prod). Each module has it''s own git repo, as does our node defs and our hiera data repository. The ''test'' environment is used to control the servers used by our devs and QA team, and prod are the actual