[Puppet Users] Abstracting filebucket source?
I have two puppet configurations, one for the office and one for production. We have some directories in common (both for files and for classes) using SVN externals. So the format is like: puppet-common * files * classes puppet-prod * files * files/common -> puppet-common/files * manifests * manifests/classes * manifests/common -> puppet-common/classes puppet-office * files * files/common -> puppet-common/files * manifests * manifests/classes * manifests/common -> puppet-common/classes However, I'm now running into a situation where I want to have a file installed in the home directory of a user created in one of the common classes. I can define the source to match the puppet URL of one of the servers, but I'd rather dynamically generate that so it works on both environments. How can I reference the puppetmaster dynamically from inside the manifests? Thanks! -- Nathan Clemons http://www.livemocha.com The worlds largest online language learning community -- 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] Fun with hashes and ERB
multipaths {
<% devices.each do |key,value| -%>
multipath {
wwid<%= value %>
alias <%= key %>
}
<% end -%>
}
On Tue, May 17, 2011 at 2:29 AM, Aaron Grewell wrote:
> Hi all,
> I'm trying to figure out the intersection of hashes and ERB. I don't know
> Ruby, so I put this together from examples available online and predictably
> it generates an ERB syntax error. Can you point me in the right direction?
>
> ### Call:
> class {'multipath':
> devices => {
> oradata01 => "360050768018280d1f8000193",
> oradata02 => "360050768018280d1f8000194",
> oradata03 => "360050768018280d1f8000195",
> }
> }
>
> ### Class:
> class multipath ($devices) {
>
> package { "device-mapper-multipath": }
>
> file { "/etc/multipath.conf":
> mode=> "644",
> content => template("multipath/multipath.conf.erb"),
> notify => Service["multipathd"],
> require => Package["device-mapper-multipath"],
> } # file
>
> service { "multipathd":
> ensure => running,
> enable => true,
> require => Package["device-mapper-multipath"],
> } # service
> } # class mapper
>
> ### Template (multipath.conf.erb):
>
> defaults {
> polling_interval30
> failbackimmediate
> no_path_retry 5
> rr_min_io 100
> path_checkertur
> user_friendly_names yes
> }
>
> devices {
> device {
> vendor "IBM"
> product "2145"
> path_grouping_policygroup_by_prio
> prio_callout"/sbin/mpath_prio_alua /dev/%n"
> }
> }
>
> multipaths {
> <% devices.each do |alias,wwid| -%>
> multipath {
> wwid<%= wwid %>
> alias <%= alias %>
> }
> <% end -%>
> }
>
> --
> 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] Plugins don't work the way I think they do?
Hi all,
I'm trying to configure a set of network interfaces, so I downloaded the
puppet-network module from the module forge. I enabled plugin sync per
http://docs.puppetlabs.com/guides/plugins_in_modules.htm and added the
module to my module path, but I'm getting an 'invalid resource type' error
indicating that the custom type included in the module isn't found. Can you
help me figure out what I've missed?
Puppet:
puppet --version
2.6.6
The error:
err: Could not retrieve catalog from remote server: Error 400 on SERVER:
Puppet::Parser::AST::Resource failed with error ArgumentError: Invalid
resource type network_config at
/usr/share/puppet/environments/testing/modules/cluster/manifests/testcluster1.pp:35
The call:
class cluster::testcluster1 ($system_ip, $cluster_ip) {
include network
network_config { "bond0":
type=> "Bonding",
bonding_module_opts => "mode=6 miimon=100",
bootproto => "none",
onboot => "yes",
netmask => "255.255.255.0",
ipaddr => $system_ip,
}
network_config { "eth0": master => "bond0", slave => "yes" }
network_config { "eth1": master => "bond0", slave => "yes" }
} # class cluster::testcluster1
The module:
tree -fi network
network
network/COPYING
network/README.markdown
network/files
network/files/network-restart.rb
network/lib
network/lib/puppet
network/lib/puppet/provider
network/lib/puppet/provider/network_config
network/lib/puppet/provider/network_config/interfaces.rb
network/lib/puppet/provider/network_config/network_scripts.rb
network/lib/puppet/provider/network_interface
network/lib/puppet/provider/network_interface/ip.rb
network/lib/puppet/type
network/lib/puppet/type/network_config.rb
network/lib/puppet/type/network_interface.rb
network/manifests
network/manifests/init.pp
network/manifests/init.pp.example
network/spec
network/spec/unit
network/spec/unit/puppet
network/spec/unit/puppet/provider
network/spec/unit/puppet/provider/network_config
network/spec/unit/puppet/provider/network_config/network_scripts.rb
network/spec/unit/puppet/provider/network_interface
network/spec/unit/puppet/provider/network_interface/ip.rb
--
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: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
- Original Message -
> r...@devco.net ("R.I.Pienaar") writes:
>
> > - Original Message -
> > > john.bollin...@stjude.org (jcbollinger) writes:
> > >
> > > Perhaps. To some extend my non-parameterised classes are _very_
> > > similar
> > > in many ways except for various parameters (creation of logical
> > > volumes
> > > and filesystems, version of mysql to use, creation of certain
> > > cron jobs
> > > for importing informtation into a configuration database, and
> > > other crons
> > > for doing standard jobs, etc) Most of the "completely common"
> > > stuff
> > > has been taken out. However, using extlookup() doesn't really
> > > work for
> > > me "right now" for a simple reason I haven't yet mentioned. I'd
> > > further
> > > like to have a lookup_by_key() function [let's say similar to the
> > > extlookup()
> > > one provided now] but also a lookup_by_regexp() function where I
> > > can match
> > > groups of boxes, in my case mainly based on regexps of their
> > > hostnames
> > > rather than on specific $hostname, or $domain, etc Without
> > > that
> > > I need to add more entries to match by lots of hostnames, which
> > > doesn't work.
> >
> > I think you're really trying to just avoid thinking in the puppet
> > way instead
> > trying to force some previous ideas on how things should work on it
> > rather
> > than figure out how it works.
> >
> > For example, you could just define a fact on your machines that
> > indicate what
> > role they have - perhaps based on your regex hostnames - and then
> > use that in
> > extlookup to select csv file to use. That would achieve your goal
> > and it would
> > be the puppet way of solving it.
>
> Currently I build nodes.pp from an external source and that provides
> the node with it's basic class (and hence role). So that's not
> needed.
so if you just set a variable in the node scope you can use those in
extlookup as I described - much simpler than writing an entire new type
of function.
And combine this with the optional paramter to extlookup that let you
specify a search-first file and you get additional key/dimension you
wish.
Still, just write the functions you need - sounds like you know exactly
what you want and its quite specific so just impliment it :)
If its good and all, you can share it on forge.puppetlabs.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.
Re: [Puppet Users] Re: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
r...@devco.net ("R.I.Pienaar") writes:
> - Original Message -
> > john.bollin...@stjude.org (jcbollinger) writes:
> >
> > Perhaps. To some extend my non-parameterised classes are _very_ similar
> > in many ways except for various parameters (creation of logical volumes
> > and filesystems, version of mysql to use, creation of certain cron jobs
> > for importing informtation into a configuration database, and other crons
> > for doing standard jobs, etc) Most of the "completely common" stuff
> > has been taken out. However, using extlookup() doesn't really work for
> > me "right now" for a simple reason I haven't yet mentioned. I'd further
> > like to have a lookup_by_key() function [let's say similar to the
> > extlookup()
> > one provided now] but also a lookup_by_regexp() function where I can match
> > groups of boxes, in my case mainly based on regexps of their hostnames
> > rather than on specific $hostname, or $domain, etc Without that
> > I need to add more entries to match by lots of hostnames, which
> > doesn't work.
>
> I think you're really trying to just avoid thinking in the puppet way instead
> trying to force some previous ideas on how things should work on it rather
> than figure out how it works.
>
> For example, you could just define a fact on your machines that indicate what
> role they have - perhaps based on your regex hostnames - and then use that in
> extlookup to select csv file to use. That would achieve your goal and it
> would
> be the puppet way of solving it.
Currently I build nodes.pp from an external source and that provides
the node with it's basic class (and hence role). So that's not needed.
One of the irritating things I see when we discuss puppet is the
inevitable "I can't describe my complete problem" as it's
[confidential] my site specific, so you can't have a full
understanding of what I'm doing or why I'm doing it wrong, or provide
me a precise, clear explanation of how better to solve my original
problem.
We talk in generics and that means we never fully understand each
other. I guess the reasons are obvious but it's probably frustrating
to us all.
Nevertheless this thread I started has helped me clarify several
things so I appreciate the time you've spent discussing them with me.
Simon
--
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: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
Hi John, john.bollin...@stjude.org (jcbollinger) writes: ... > Let's not cast things in terms of "correctness," except insomuch as > whether they reliably produce the desired effect on clients. Indeed. As always there is more than one way to solve a problem. > Depending on what you're trying to do with Puppet, however, it is > certainly true that some approaches to structuring your manifests will > make them easier to write and maintain than will others. Personally, > when writing specializations into my manifests, I find it useful to > keep in mind the question of *why* a particular host or group of hosts > is different from others. I have yet to run into an answer that > didn't fall into one of these categories, or a combination of them: > > 1) It has a functional role that some other systems do not In my case 90% of the differences are functional differences, often expressed as part of the hostname. > 2) Its network environment requires differences from some other > systems. There may be some minor differences here but they are the exceptions rather than the rule. > 3) It's just special I have a few of these too. > It has worked well for me so far to model roles via (unparameterized) > classes, assigned to nodes via their node declarations. That leaves > only one level between "common" and "node-specific" where I might need > to customize data. Yes, I have db_server::type_a and db_server::type_b, ... > (That intermediate level could in principal be > parameterized by network domain, but in my case it is by subnet.) > Most of my nodes do not require per-node customization, so I don't end > up with many data files for extlookup. In my case one db_server is pretty much similar to another one. Things vary such as mysql version to use (normally pretty constant), partitions to mount and their location(s), cron jobs to setup. All of these are lower level classes which are almost the same except for a few parameters. I also started with non-parameterised classes so created a large number of nearly duplicate classes and now I'm beginning to parameterise some of these the total number of classes should drop much more easily. Of course if I can lookup the parameters from a "data source" (extlookup or similar) then I can pretty much make many classes identical: all they do is pickup the required parameters and apply them. > > > > > Moreover, I disagree with several of the opinions and conclusions in > > > your post: > > > > > 1) You write: "The extlookup() functionality only allows [... > > > specifying implicitly ...] where to look for this value." That is > > > false. Extlookup does provide for configuration of a standard set of > > > CSV files to search (which can be parameterized by nodes' facts), but > > > the function also has an optional parameter to specify a specific file > > > to be searched first on any given invocation. > > > > Perhaps coming from a database background, I'd like to mirror what > > seems more _natural_ and having values spread around over potentially > > a large number of files seems non-intuitive. > > > If extlookup use would indeed require you to maintain a large number > of separate files then that might be a good reason to find something > better, but in all likelihood you can avoid that, or else structure it > in a sane way. Consider also: > > When you work with a database, do you normally focus on how it maps > data to the host filesystem? Focus no. Again as mentioned I try to simplify the structure by "normalising" it. Here I see I want to lookup a parameter ( say "partition size" ) from somewhere and I need to find it for a server called $hostname. If I can't find a parameter for $hostname, I may be happy if I find the same parameter for $domain, or if not I may be happy with some default value. _My_ preference is to look that up in one place. Also as mentioned in a different message, doing this lookup via a regexp might nicely enable me to keep the list of entries short. > Given the diverse data parameterization you described, if you created > a database for your configuration data, would you really organize > everything into a single table? (And what would be its key?) yes: CREATE TABLE lookup_table ( config_item VARCHAR(200) NOT NULL, lookup_value VARCHAR(200) NOT NULL, return_value VARCHAR(200) NOT NULL PRIMARY KEY ( config_item, lookup_value ) ) SELECT return_value FROM lookup_table WHERE config_item = 'lvsize' AND lookup_value = 'myhostname001' provides a fast lookup of the value. If that fails you can do SELECT return_value FROM lookup_table WHERE config_item = 'lvsize' AND lookup_value = 'example.com' for a more generic response. If that fails you can do: SELECT return_value FROM lookup_table WHERE config_item = 'lvsize' AND lookup_value = 'DEFAULT' Yes, I'm fully aware this could be normalised better but given the limited number of entries it's trivial to understand, trivial to maintain fast to a
Re: [Puppet Users] Should puppet manage its own client configs?
On Mon, May 16, 2011 at 4:08 PM, Chris Phillips wrote: > Why the distinction between the two? What's wrong with using a LAN IP on the > puppetmaster machine as well? To me that's much clearer that misusing > loopback. I seem to recall doing that to allow a newly provisioned puppetmaster to bootstrap itself using puppet (instead of puppetd) and $servername and $serverip are not available for that initial run. -- 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: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
- Original Message - > john.bollin...@stjude.org (jcbollinger) writes: > > Perhaps. To some extend my non-parameterised classes are _very_ similar > in many ways except for various parameters (creation of logical volumes > and filesystems, version of mysql to use, creation of certain cron jobs > for importing informtation into a configuration database, and other crons > for doing standard jobs, etc) Most of the "completely common" stuff > has been taken out. However, using extlookup() doesn't really work for > me "right now" for a simple reason I haven't yet mentioned. I'd further > like to have a lookup_by_key() function [let's say similar to the extlookup() > one provided now] but also a lookup_by_regexp() function where I can match > groups of boxes, in my case mainly based on regexps of their hostnames > rather than on specific $hostname, or $domain, etc Without that > I need to add more entries to match by lots of hostnames, which > doesn't work. I think you're really trying to just avoid thinking in the puppet way instead trying to force some previous ideas on how things should work on it rather than figure out how it works. For example, you could just define a fact on your machines that indicate what role they have - perhaps based on your regex hostnames - and then use that in extlookup to select csv file to use. That would achieve your goal and it would be the puppet way of solving it. > Puppetlabs reccommends. However, with system configuration being a > continual ongoing process I tend to think that a 100% ENC-only style > build using only parameterised classes is going to be a hard thing to > achieve in practice. And the global variables just don't convince me > yet. Perhaps I still have to see the light. ENCs can (now) pass parameters to param classes. So you dont have to do it all with global vars. > > Note also that another part of the Style Guide's approach is that > > classes should avoid including other classes. Although it may not > > be > > immediately obvious, that goes hand-in-hand with extensive use of > > parameterized classes. Do take that into consideration as you > > evaluate the Style Guide's recommendations. > > Hm.. well building bigger blocks from smaller ones tends to be a good > practice to follow, so this recommendation seems counterintuitive. > I'll have to lookup the section and see if they explain why, but > guess it's because the intention is you build your server in terms of > smallish components. +1, I think this is mostly down to the bad design in param classes - they really do not promote the use of many small classes that creates a larger module. Making modules harder to read and making dependencies harder to specify. -- 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: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
john.bollin...@stjude.org (jcbollinger) writes:
> On May 14, 8:52 am, Simon J Mudd wrote:
>
> > However, from the discussion a few things strike me:
> >
> > 1. the use of parameterised classes is recommended heavily. I've just
> > found out about this "new feature" inspite of using puppet for a long
> > time. Hence many recipes that I'm using are not paremeterised and I
> > have a large number of similar classes. This is certainly worth fixing
> > but is quite a painful transition to make given the number of systems
> > in use and the chance of creating heavy breakage during that change.
> > So if you haven't used parameterised classes much that's the first
> > thing that needs looking at.
>
> If you have a complex set of manifests that do not use parameterized
> classes, then I think it much safer to coalesce similar classes with
> the help of extlookup() than by attempting to switch to parameterized
> classes.
Perhaps. To some extend my non-parameterised classes are _very_ similar
in many ways except for various parameters (creation of logical volumes
and filesystems, version of mysql to use, creation of certain cron jobs
for importing informtation into a configuration database, and other crons
for doing standard jobs, etc) Most of the "completely common" stuff
has been taken out. However, using extlookup() doesn't really work for
me "right now" for a simple reason I haven't yet mentioned. I'd further
like to have a lookup_by_key() function [let's say similar to the extlookup()
one provided now] but also a lookup_by_regexp() function where I can match
groups of boxes, in my case mainly based on regexps of their hostnames
rather than on specific $hostname, or $domain, etc Without that
I need to add more entries to match by lots of hostnames, which doesn't
work.
So I'd like something like
$mount_point = lookup_by_regexp( 'mount_point', $hostname, 'regexp_file', '' )
# parameters: lookup_item, lookup_value, regexp file to lookup, default
$lvsize = lookup_by_regexp( 'lvsize', $hostname, 'regexp_file', '' )
class db_lvconfig { db_lvconfig: mount_point => $mount_point, lvsize => $lvsize
} # note: other default parameters not shown like: owner, group, mode, vgname,
lvname
and have in the .csv file something like
mount_point,/dbservera/,/mount_point/for/servera
mount_point,/dbserverb/,/mount_point/for/serverb
mount_point,/dbserverc/,/mount_point/for/serverc
lvsize,/dbservera/,100G
lvsize,/dbserverb/,200G
lvsize,/dbserverc/,300G
Then if $hostname = 'dbservera-001'
it would get $lvsize = '100G', and $mount_point = '/mount_point/for/servera'
If I have 10 dbservera-xxx boxes then this keeps the config simple and the
.csv files much smaller.
> There are a couple of important ways (other than
> parameterization itself) by which parameterized classes differ from
> non-parameterized ones, and the more complex your current manifests,
> the more likely these are to bite you if you parameterize existing
> classes.
Perhaps. for most of my cases I don't think that's the case. I'm
slowly adjusting the configuration of several classes to use
parameterised classes but even these still work nicely with
extlookup() alternatives such as the currently unimplemented
lookup_by_key() or lookup_by_regexp() alternatives I'm thinking of
using.
> Note, however, that it is the use of extlookup() *as an alternative to
> class parameterization* that the style guide recommends against. Do
> not take it as a blanket recommendation against using the feature.
I'm not. You need to have a very considered mindset to build
_everything_ top down using an ENC and classes or globalvariables. If
using global variables as heavily as puppet seem to imply then ensuing
that you have a clear naming policy for this is quite important to
avoid unexpected name clashes (or mistakes) which might go unnoticed.
So I'd certainly like to see real world examples of complete
configurations to be fully convinced this works well. Perhaps after
moving a configuration to use extlookup() type mechanisms it then
becomes easier to make a further step "up" to get to the ENCs style
Puppetlabs reccommends. However, with system configuration being a
continual ongoing process I tend to think that a 100% ENC-only style
build using only parameterised classes is going to be a hard thing to
achieve in practice. And the global variables just don't convince me
yet. Perhaps I still have to see the light.
> Note also that another part of the Style Guide's approach is that
> classes should avoid including other classes. Although it may not be
> immediately obvious, that goes hand-in-hand with extensive use of
> parameterized classes. Do take that into consideration as you
> evaluate the Style Guide's recommendations.
Hm.. well building bigger blocks from smaller ones tends to be a good
practice to follow, so this recommendation seems counterintuitive.
I'll have to lookup the section and see if they explain why, but guess
it's because the intent
[Puppet Users] apt-pinning & puppet package management
Hello!
I have question about Debian package management with puppet. I'm
wondering is there sane way to make puppet respects packages pinning?
i.e., if I have several repos for one package, let's say it is "nginx"
which can be found in lenny & lenny-backports repos. I've created
pinning file like:
Package: nginx
Pin: release a=lenny-backports
Pin-Priority: 600
So, if i have nginx installed from repository "lenny" , 'apt-get
install nginx' will update (if version is newer of course) nginx from
lenny-backports .
When I run puppet, it just ignores package available in pins, I guess
it thinks package already installed. Package is described like:
$packagelist = [ "nginx" ]
package { $packagelist:
ensure => installed,
}
Using "latest" is not the cure, because it will look only on version
(as i understand) and not on pins. I've found
https://github.com/evolvingweb/puppet-apt/blob/master/manifests/force.pp
which looks like something I need, but may be I'm missing something
and there is proper way to do this.
My puppet versions:
root@kappa2:~# dpkg -l|grep puppet
ii puppet 2.6.2-4~bpo50+1
Centralized configuration management - agent
ii puppet-common 2.6.2-4~bpo50+1
Centralized configuration management
root@kappa2:~# puppetd --version
2.6.2
OS - Debian Lenny amd64, puppet from backports.
P.S. Please, CC me on reply.
--
Best regards,
[COOLCOLD-RIPN]
--
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 fails first run
Hey all...new to puppet, but desperately pushing it on everyone I see
around me :)...
I'm running into a relatively minor issue that keeps puppet from
properly completing its first run. Subsequent runs do not have these
issues, and I'm confused why. It appears to be looking for a different
repo's file... First run will create our local.repo file, but log an
error on a totally different file that causes subsequent yumrepos to
be skipped:
CentOS log:
notice //puppet-test-c64//File[RPM-GPG-KEY-xxx]/ensure defined content
as '{md5}b954c7d56ed699642484d8f2a82f4338'
notice //puppet-test-c64//Stage[pre]/Repo/Exec[yum_xxx_gpg]/returns
executed successfully
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo]/descr
descr changed '' to 'CentOS-$releasever - Local'
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo]/baseurl
baseurl changed '' to 'http://reposerver/centos$releasever-$basearch/
RPMS.local/'
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo]/enabled
enabled changed '' to '1'
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo]/gpgcheck
gpgcheck changed '' to '1'
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo]/gpgkey
gpgkey changed '' to 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-xxx'
err //puppet-test-c64//Stage[pre]/Repo/Yumrepo[local.repo] Could not
evaluate: No such file or directory - /etc/yum.repos.d/addons.repo
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[CentOS-Base.repo-
Plus] Dependency Yumrepo[local.repo] has failures: true
warning //puppet-test-c64//Stage[pre]/Repo/Yumrepo[CentOS-Base.repo-
Plus] Skipping because of failed dependencies
notice //puppet-test-c64//Stage[pre]/Repo/Yumrepo[CentOS-Base.repo-
addons] Dependency Yumrepo[local.repo] has failures: true
warning //puppet-test-c64//Stage[pre]/Repo/Yumrepo[CentOS-Base.repo-
addons] Skipping because of failed dependencies
I'm running puppet 2.6.6, and the problem is happening in the 'pre'
runstage defined in site.pp as such:
# Run Stages
stage {
'pre': before => Stage['main'];
}
class {
'repo': stage => 'pre';
}
---
Class 'repo' includes mostly yumrepo declarations to use our local
repositories (and execs to import keys). The local-only repo
(local.repo) should be created first, then all other repos. Class
'repo' is defined as such:
class repo {
package { ['yum','rpm']:
ensure => present,
}
package { 'yum-priorities':
ensure => present,
require => Yumrepo['local.repo'],
}
# Download and import Stern GPG RPM key
file { '/etc/yum.repos.d/':
ensure => directory,
}
file { 'RPM-GPG-KEY-xxx':
ensure => present,
path=> '/etc/pki/rpm-gpg/RPM-GPG-KEY-xxx',
owner => 'root',
group => 'root',
mode=> '0644',
require => Package['rpm'],
source => "puppet://$servername/repo/RPM-GPG-KEY-xxx",
}
exec { 'yum_xxx_gpg':
command => '/bin/rpm --import /etc/pki/rpm-gpg/RPM-GPG-KEY-xxx',
unless => '/bin/rpm -qi gpg-pubkey-xxx',
require => [ File['RPM-GPG-KEY-xxx'],Package['rpm'] ],
}
case $operatingsystem {
centos: {
yumrepo {
'CentOS-Base.repo-base':
name => 'base',
baseurl=> 'http://reposerver/centos$releasever-$basearch/
RPMS.os/',
enabled=> '1',
descr => 'CentOS-$releasever - Base',
gpgcheck => '1',
gpgkey => 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-
CentOS-5',
mirrorlist => 'absent',
require=> Yumrepo['local.repo'],
notify => Exec['yum_clean_all'];
'CentOS-Base.repo-updates':
name => 'updates',
baseurl=> 'http://reposerver/centos$releasever-$basearch/
RPMS.updates/',
enabled=> '1',
descr => 'CentOS-$releasever - Updates',
gpgcheck => '1',
gpgkey => 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-
CentOS-5',
mirrorlist => 'absent',
require=> Yumrepo['local.repo'],
notify => Exec['yum_clean_all'];
'CentOS-Base.repo-addons':
name => 'addons',
baseurl=> 'http://reposerver/centos$releasever-$basearch/
RPMS.addons/',
enabled=> '1',
descr => 'CentOS-$releasever - Addons',
gpgcheck => '1',
gpgkey => 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-
CentOS-5',
mirrorlist => 'absent',
require=> Yumrepo['local.repo'],
notify => Exec['yum_clean_all'];
'CentOS-Base.repo-extras':
name => 'extras',
baseurl=> 'http://reposerver/centos$releasever-$basearch/
RPMS.extras/',
enabled=> '1',
descr => 'CentOS-$releasever - Extras',
gpgcheck => '1',
gpgkey => 'file:///etc/pki/rpm-gpg/RPM-GPG-KEY-
CentOS-5',
mirrorlist => 'absent',
require=> Yumrepo['local.repo'],
notify => Exec['yum_clean_all'];
'CentO
Re: [Puppet Users] Uninstalling the puppet source?
On Mon, May 16, 2011 at 12:54:02PM -0700, Daniel Pittman wrote: > On Mon, May 16, 2011 at 12:50, Robin Lee Powell > wrote: > > On Mon, May 16, 2011 at 12:35:10PM -0700, Robin Lee Powell wrote: > > >> (2) How do I turn the git source into a gem? > > > > Figured (2) out; still wondering about the other. I have all the > > install output, so I can just rm everything, but I'm assuming > > there's something cleaner than that? > > Not that I am aware of. Good for you, saving the output, too. Oh, I didn't, it's just that my .screenrc defaults to 50K lines of backscroll. :D -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/): The language in which "this parrot is dead" is "ti poi spitaki cu morsi", but "this sentence is false" is "na nei". My personal page: http://www.digitalkingdom.org/rlp/ -- 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] Should puppet manage its own client configs?
On 16 May 2011 20:26, Adam Heinz wrote:
I just refer to the puppetmaster as 'puppet' everywhere and drop an
> entry in /etc/hosts for it. Then if I wanted to migrate off a server,
> I would just hardcode away $servername and $serverip on the old
> puppetmaster to point to the new one, and copy the certs over.
>
> node default {
>case $fqdn {
>/puppetmaster/: {
>host { puppet:
>host_aliases => [ "localhost.localdomain", "puppet" ],
>ip => "127.0.0.1",
>name => "localhost",
>}
>}
>default: {
>host { puppet:
>host_aliases => $servername,
>ip => $serverip,
>name => "puppet",
> }
>}
>}
> }
>
Why the distinction between the two? What's wrong with using a LAN IP on the
puppetmaster machine as well? To me that's much clearer that misusing
loopback.
Thanks
Chris
--
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] buglet in ec2 facts in facter 1.5.9rc6
Hello...
I ran into a buglet in facter 1.5.9rc6 (from tmz repo). In normal AWS
instances it works great. In VPC instances if doesn't work. This seems
to be because VPC instances don't use the fe:ff:ff:... MAC addresses.
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:E1:26:30
inet addr:172.17.129.24 ...
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
/sbin/ifconfig
eth0 Link encap:Ethernet HWaddr 02:67:4E:DA:58:16
inet addr:172.17.128.126
/sbin/arp
Address HWtype HWaddress Flags Mask Iface
169.254.169.253 ether 02:67:4E:C0:00:01 C eth0
172.17.128.1 ether 02:67:4E:C0:00:01 C eth0
Of the two VPC EC2 instances I've seen, the MAC address always start
with 02:67:4E. I have only seen two instances, both in the same VPC, so
I don't know if this holds for every VPC instance, YMMV.
in ec2.rb , the following seemed to work:
def has_euca_mac?
!!(Facter.value(:macaddress) =~ %r{^02:67:4[eE]:})
end
--
Christopher McCrory
To the optimist, the glass is half full.
To the pessimist, the glass is half empty.
To the engineer, the glass is twice as big as it needs to be.
--
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] Should puppet manage its own client configs?
On 16 May 2011 20:14, Jonathan Gazeley wrote: > Hi Chris, > > We have configured puppet to manage its own puppet.conf on clients, and to > ensure that puppetd is running on all hosts. However it does not manage > puppet.conf on the puppetmaster, so if we accidentally mess up the config, > we won't break the puppetmaster. > This seems a logical thing to do to me, I'll want to be able to turn on archive_files sometimes, that's one angle I'm keen on. Would be useful to separate the server and client config files though really, then it wouldn't be irresponsible to manage the client side of the master server separately. > The hostname of the puppetmaster is hard-coded, in our case. Can anyone > think of a better way of identifying the puppetmaster, so our manifests will > run anywhere, if we decide to make a different machine the puppetmaster? > > Well yeah, just make puppet a cname and set the certificate name used on the master part of puppet.conf correctly. for this side of things, the client config is totally default, and it just goes to "puppet" via DNS, works perfectly, and I can easily rebuild a server an point the puppet cname to hit it. zero config on that side. Cheers Chris -- 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] Uninstalling the puppet source?
On Mon, May 16, 2011 at 12:50, Robin Lee Powell wrote: > On Mon, May 16, 2011 at 12:35:10PM -0700, Robin Lee Powell wrote: >> >> I'm installing puppet from git per instructions in another thread. >> >> The instructions given at >> http://docs.puppetlabs.com/guides/installation.html for installing >> puppet from source lead to it dumping things all over my Ruby, which >> I really wasn't expecting and doesn't work well with our >> environment. >> >> (1) How do I uninstall it? Sadly, the Ruby install tools don't provide any useful mechanism for this. For better or worse, we just use those, rather than building something else on top. (...although if someone identified a mechanism that we could just pick up and use that would solve this we would totally integrate it.) >> (2) How do I turn the git source into a gem? > > Figured (2) out; still wondering about the other. I have all the > install output, so I can just rm everything, but I'm assuming > there's something cleaner than that? Not that I am aware of. Good for you, saving the output, too. Daniel -- ⎋ Puppet Labs Developer – http://puppetlabs.com ✉ Daniel Pittman ✆ Contact me via gtalk, email, or phone: +1 (877) 575-9775 ♲ Made with 100 percent post-consumer electrons -- 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] Uninstalling the puppet source?
On Mon, May 16, 2011 at 12:35:10PM -0700, Robin Lee Powell wrote: > > I'm installing puppet from git per instructions in another thread. > > The instructions given at > http://docs.puppetlabs.com/guides/installation.html for installing > puppet from source lead to it dumping things all over my Ruby, which > I really wasn't expecting and doesn't work well with our > environment. > > (1) How do I uninstall it? > > (2) How do I turn the git source into a gem? Figured (2) out; still wondering about the other. I have all the install output, so I can just rm everything, but I'm assuming there's something cleaner than that? -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/): The language in which "this parrot is dead" is "ti poi spitaki cu morsi", but "this sentence is false" is "na nei". My personal page: http://www.digitalkingdom.org/rlp/ -- 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] Uninstalling the puppet source?
I'm installing puppet from git per instructions in another thread. The instructions given at http://docs.puppetlabs.com/guides/installation.html for installing puppet from source lead to it dumping things all over my Ruby, which I really wasn't expecting and doesn't work well with our environment. (1) How do I uninstall it? (2) How do I turn the git source into a gem? Thanks. -Robin -- http://singinst.org/ : Our last, best hope for a fantastic future. Lojban (http://www.lojban.org/): The language in which "this parrot is dead" is "ti poi spitaki cu morsi", but "this sentence is false" is "na nei". My personal page: http://www.digitalkingdom.org/rlp/ -- 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] Should puppet manage its own client configs?
On Mon, May 16, 2011 at 3:14 PM, Jonathan Gazeley
wrote:
> The hostname of the puppetmaster is hard-coded, in our case. Can anyone
> think of a better way of identifying the puppetmaster, so our manifests will
> run anywhere, if we decide to make a different machine the puppetmaster?
I just refer to the puppetmaster as 'puppet' everywhere and drop an
entry in /etc/hosts for it. Then if I wanted to migrate off a server,
I would just hardcode away $servername and $serverip on the old
puppetmaster to point to the new one, and copy the certs over.
node default {
case $fqdn {
/puppetmaster/: {
host { puppet:
host_aliases => [ "localhost.localdomain", "puppet" ],
ip => "127.0.0.1",
name => "localhost",
}
}
default: {
host { puppet:
host_aliases => $servername,
ip => $serverip,
name => "puppet",
}
}
}
}
--
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] Should puppet manage its own client configs?
Hi Chris, We have configured puppet to manage its own puppet.conf on clients, and to ensure that puppetd is running on all hosts. However it does not manage puppet.conf on the puppetmaster, so if we accidentally mess up the config, we won't break the puppetmaster. The hostname of the puppetmaster is hard-coded, in our case. Can anyone think of a better way of identifying the puppetmaster, so our manifests will run anywhere, if we decide to make a different machine the puppetmaster? Cheers, Jonathan Jonathan Gazeley Systems Support Specialist ResNet | Wireless & VPN Team IT Services University of Bristol On 05/16/2011 05:09 PM, Chris Phillips wrote: Hi, Is there a general feel on whether puppet should look after its own client configuration files and service status? I'd not foresee problems about a "service ensure enabled" for puppetd and a file object for the puppet.conf but clearly wouldn't want to risk locking ourselves out of the clients from a bad config file being sent down etc. Thanks Chris -- 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] Fun with hashes and ERB
Hi all,
I'm trying to figure out the intersection of hashes and ERB. I don't know
Ruby, so I put this together from examples available online and predictably
it generates an ERB syntax error. Can you point me in the right direction?
### Call:
class {'multipath':
devices => {
oradata01 => "360050768018280d1f8000193",
oradata02 => "360050768018280d1f8000194",
oradata03 => "360050768018280d1f8000195",
}
}
### Class:
class multipath ($devices) {
package { "device-mapper-multipath": }
file { "/etc/multipath.conf":
mode=> "644",
content => template("multipath/multipath.conf.erb"),
notify => Service["multipathd"],
require => Package["device-mapper-multipath"],
} # file
service { "multipathd":
ensure => running,
enable => true,
require => Package["device-mapper-multipath"],
} # service
} # class mapper
### Template (multipath.conf.erb):
defaults {
polling_interval30
failbackimmediate
no_path_retry 5
rr_min_io 100
path_checkertur
user_friendly_names yes
}
devices {
device {
vendor "IBM"
product "2145"
path_grouping_policygroup_by_prio
prio_callout"/sbin/mpath_prio_alua /dev/%n"
}
}
multipaths {
<% devices.each do |alias,wwid| -%>
multipath {
wwid<%= wwid %>
alias <%= alias %>
}
<% end -%>
}
--
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] Should puppet manage its own client configs?
Hi, Is there a general feel on whether puppet should look after its own client configuration files and service status? I'd not foresee problems about a "service ensure enabled" for puppetd and a file object for the puppet.conf but clearly wouldn't want to risk locking ourselves out of the clients from a bad config file being sent down etc. Thanks Chris -- 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: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
Hi Simon,
On May 14, 2:55 am, Simon J Mudd wrote:
> Hi John,
>
> While you obviously disagree with me, thanks for taking the time to
> reply. I may be looking at the problem the wrong way which is why
> I'm trying to figure out if that's the case and why.
Fair enough.
> john.bollin...@stjude.org (jcbollinger) writes:
> > On May 13, 8:07 am, jcbollinger wrote:
> > On the other hand, extlookup() is easy to set up and use, and it is
> > powerful enough for most needs. If you need a more powerful data
> > lookup function then you would be lucky to find a canned one that
> > meets all your needs.
>
> Perhaps but I don't see it as being that bad, and it seems to be
> the closest thing to a solution I could find at the moment. My current
> recipes (perhaps incorrectly) are heavily customised in a way
> which often is not just "host specific" or "domain" specific. Hence
> the need to override the default settings. Other settings though
> may need this thus requiring this to be more dynamic.
Let's not cast things in terms of "correctness," except insomuch as
whether they reliably produce the desired effect on clients.
Depending on what you're trying to do with Puppet, however, it is
certainly true that some approaches to structuring your manifests will
make them easier to write and maintain than will others. Personally,
when writing specializations into my manifests, I find it useful to
keep in mind the question of *why* a particular host or group of hosts
is different from others. I have yet to run into an answer that
didn't fall into one of these categories, or a combination of them:
1) It has a functional role that some other systems do not
2) Its network environment requires differences from some other
systems.
3) It's just special
It has worked well for me so far to model roles via (unparameterized)
classes, assigned to nodes via their node declarations. That leaves
only one level between "common" and "node-specific" where I might need
to customize data. (That intermediate level could in principal be
parameterized by network domain, but in my case it is by subnet.)
Most of my nodes do not require per-node customization, so I don't end
up with many data files for extlookup.
> > Moreover, I disagree with several of the opinions and conclusions in
> > your post:
>
> > 1) You write: "The extlookup() functionality only allows [...
> > specifying implicitly ...] where to look for this value." That is
> > false. Extlookup does provide for configuration of a standard set of
> > CSV files to search (which can be parameterized by nodes' facts), but
> > the function also has an optional parameter to specify a specific file
> > to be searched first on any given invocation.
>
> Perhaps coming from a database background, I'd like to mirror what
> seems more _natural_ and having values spread around over potentially
> a large number of files seems non-intuitive.
If extlookup use would indeed require you to maintain a large number
of separate files then that might be a good reason to find something
better, but in all likelihood you can avoid that, or else structure it
in a sane way. Consider also:
When you work with a database, do you normally focus on how it maps
data to the host filesystem?
Given the diverse data parameterization you described, if you created
a database for your configuration data, would you really organize
everything into a single table? (And what would be its key?)
If you wanted to allow customization of your data with varying scopes
(e.g. supporting both per-node and per-network customization of the
same parameters) then how would you design the DB?
> > 2) You would prefer looking up data via a compound key (config_item,
> > lookup_value) rather than via a simple key (config_item).
> > [...] And even a DB performs multi-key queries
> > slower than single-key searches.
>
> Not if they are part of the primary key. That's part of the point.
Well that's a possible answer for you then. Extlookup performs
lookups based on a single key, and nothing prevents you from using
keys that allow you to flatten your data. For example, you can
structure your data so that instead of extlookup("interface"), you can
extlookup("interface-$subnet-$is_master"). In other words, the
distinction in your examples between "config_item" and
"lookup_value(s)" is artificial and unnecessary. There is no reason
why you could not combine them all into a single field in the CSV.
> > 3) You argue that your suggested formulation of extlookup would be
> > "clearer as the configuration is more explicit then the current
> > extlookup() definition." I think you're missing the point. It would
> > indeed be clearer from which file the data would come, but the
> > objective of extlookup is to separate the *definition* of the data as
> > much as possible from the *use* of the data. And I like that. I
> > prefer that my manifests _not_ specify a bunch of details to every
> > extlookup() call, because th
Re: [Puppet Users] Stopping two services at once
On Mon, May 16, 2011 at 12:16:53PM +0100, Jonathan Gazeley wrote:
> Is there a way to stop and disable two services in one declaration?
> Currently I have this:
>
> # Stop sendmail
> service { "sendmail":
> ensure => stopped,
> enable => false,
> }
>
> # Stop exim
> service { "exim":
> ensure => stopped,
> enable => false,
> }
>
> Is it possible to format that like this?:
>
> service { "disabledemail":
> name => ['sendmail', 'exim'],
> ensure => stopped,
> enable => false,
> }
Are you trying to have simultaneous stoppage or just save typing? You
can achiev the latter by
service { [ 'sendmail', 'exim' ]:
ensure => stopped,
enable => false,
}
--
Bruce
What would Edward Woodward do?
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.
Re: [Puppet Users] Stopping two services at once
On Mon, May 16, 2011 at 7:16 AM, Jonathan Gazeley
wrote:
> Is it possible to format that like this?:
>
> service { "disabledemail":
> name => ['sendmail', 'exim'],
> ensure => stopped,
> enable => false,
> }
I think you mean
service {[ 'sendmail', 'exim']:
ensure => stopped,
enable => false,
}
--
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: Thoughts about extlookup: http://blog.wl0.org/2011/05/thoughts-about-extlookup-in-puppet/
On May 14, 8:52 am, Simon J Mudd wrote: > sjm...@pobox.com (Simon J Mudd) writes: > > > john.bollin...@stjude.org (jcbollinger) writes: > > > > In fact, Puppet Labs's own recently updated style guide recommends > > > against using extlookup(), though that position is controversial. > > > I found the URL:http://docs.puppetlabs.com/guides/style_guide.html > > > "The extlookup() Function > > > Modules should avoid the use of extlookup() in favor of ENCs or other > > alternatives." > > > The statement is clear, but it would be nice to know the reasoning. > > That is if there's a problem with extlookup() then it would be good to > > know what it is. This may have been discussed elsewhere but it > > shouldn't be necessary to have to go and search for this. > > In the end I > did.http://groups.google.com/group/puppet-users/browse_thread/thread/34e4... > It is a good read. Now you know what I meant when I called Puppet Labs's style recommendation "controversial." Personally, I remain unpersuaded that the recommended style is a good technical choice for most people, but I will not rehash the arguments that you have just read. > However, from the discussion a few things strike me: > > 1. the use of parameterised classes is recommended heavily. I've just > found out about this "new feature" inspite of using puppet for a long > time. Hence many recipes that I'm using are not paremeterised and I > have a large number of similar classes. This is certainly worth fixing > but is quite a painful transition to make given the number of systems > in use and the chance of creating heavy breakage during that change. > So if you haven't used parameterised classes much that's the first > thing that needs looking at. If you have a complex set of manifests that do not use parameterized classes, then I think it much safer to coalesce similar classes with the help of extlookup() than by attempting to switch to parameterized classes. There are a couple of important ways (other than parameterization itself) by which parameterized classes differ from non-parameterized ones, and the more complex your current manifests, the more likely these are to bite you if you parameterize existing classes. Note, however, that it is the use of extlookup() *as an alternative to class parameterization* that the style guide recommends against. Do not take it as a blanket recommendation against using the feature. Note also that another part of the Style Guide's approach is that classes should avoid including other classes. Although it may not be immediately obvious, that goes hand-in-hand with extensive use of parameterized classes. Do take that into consideration as you evaluate the Style Guide's recommendations. > [...] if you already have working recipes > perhaps and aren't using an ENC [, extlookup] gives you a way to > clearly remove the conditional logic the recipes currently have. It's > then a smaller step "up" to using an ENC if you want to go that > way. For those that don't it still becomes reasonably clear where the > configuration is parameterised and how/why that's done, so it's still > a more flexible approach. I agree. Furthermore, I maintain that if you are not using an ENC, then parameterized classes offer few advantages to offset their disadvantages. Therefore, if you are not already using an ENC and do not want to switch to one right now, then extlookup() is the best generally available way to externalize your configuration's data. 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] Stopping two services at once
Is there a way to stop and disable two services in one declaration?
Currently I have this:
# Stop sendmail
service { "sendmail":
ensure => stopped,
enable => false,
}
# Stop exim
service { "exim":
ensure => stopped,
enable => false,
}
Is it possible to format that like this?:
service { "disabledemail":
name => ['sendmail', 'exim'],
ensure => stopped,
enable => false,
}
Thanks,
Jonathan
--
Jonathan Gazeley
Systems Support Specialist
ResNet | Wireless & VPN Team
IT Services
University of Bristol
--
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] Going to publish custom modules : Request for comments
On 15 May 2011 20:27, Matthias Saou <
th...@spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net> wrote:
> Dan Bode wrote:
>
> > I have an implementation question:
> >
> > 1. Why are you doing the chkconfig exec:
> >
> > exec { "chkconfig ${title} on":
> > notify => Service["xinetd"],
> > path => [ "/sbin", "/bin" ],
> > onlyif => "chkconfig --list ${title} | egrep -q 'off$'",
> > }
> >
> >
> > why doesnt:
> >
> > service { $title:
> > enable => 'true'
> > }
> >
> > work for this?
>
> Fair question. I'm guessing that I assumed initially that the xinetd
> "sub-services" wouldn't work with the puppet provider. I'm now guessing
> that I should do some testing again and simplify this accordingly.
>
Isn't the difference that IF the service doesn't exist then it won't fail,
whereas the standard service enable definition will need to service to
exist? Unless I'm missing something in the bigger picture, this is an area,
only doing stuff if the files are there to have stuff done upon them, where
puppet seems to fall short.
Thanks
Chris
--
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.
