[Puppet Users] Re: Installing a package purely with Hiera configuration
That'll work fine for now, but if you throw everything into site.pp it can
become difficult to manage and inflexible pretty quickly. Have a look at
this part of the docs:
https://docs.puppetlabs.com/learning/modules1.html
Specifically from the "The End of One Huge Manifest" heading.
Andy
On Friday, 5 December 2014 13:45:23 UTC, Brantley Hobbs wrote:
>
> Since it's such a core component, I have added the type you suggested to
> my site.pp manifest and it works just fine. Is there a better place for it?
>
> Thanks for your help!
>
> On Friday, December 5, 2014 7:55:46 AM UTC-5, Andy Taylor wrote:
>>
>> Hiera is just a source of data - you need to have Puppet
>> manifests/modules which interpet the data and act on it.
>>
>> You can achieve installation of packages from Hiera data by using defined
>> types and the create_resources function:
>>
>> https://docs.puppetlabs.com/learning/definedtypes.html
>>
>> https://docs.puppetlabs.com/references/latest/function.html#createresources
>>
>> Basically you need to create a defined type which includes a package
>> resource. Once you've done that you can use the create_resources function
>> to pass the Hiera data to the defined type and install the packages.
>>
>> The defined type would look something like this:
>>
>> define hiera::packages ( $ensure ) {
>>
>> package { $title:
>> ensure => $ensure
>> }
>>
>> }
>>
>> and then the create_resources call would look like this:
>>
>> $packages = hiera('packages')
>>
>> create_resources(hiera::packages, $packages)
>>
>> Hope that helps,
>>
>> Andy
>>
>> On Thursday, 4 December 2014 21:00:34 UTC, Brantley Hobbs wrote:
>>>
>>> Hi all!
>>>
>>> I'm very new to puppet. I have installed a puppet master which
>>> successfully sets the IP address and manages sudo on a couple of nodes.
>>>
>>> I'm using Puppet 3.7 with Hiera, and so far I haven't had to write any
>>> manifest files, apart from the one that pulls in Hiera. As far as I can
>>> tell, this is a best practice.
>>>
>>> Now I would like to manage packages on my agents. I assume that in the
>>> node specific Hiera file, I should be able do something like the following:
>>>
>>> packages:
>>> apache2:
>>> ensure: installed
>>>
>>> However, nothing gets installed. I know I'm taking too simplistic of an
>>> approach, but I'm not sure where to start digging. Most things I've found
>>> say that I need a "wrapper class" to read in the Hiera data and install the
>>> packages. Is there no way to install packages purely from hiera? I've
>>> found some modules that propose to do this, but so far I can't get them to
>>> work. I'd like to do this without additional modules if possible; it seems
>>> like a pretty basic operation.
>>>
>>> Thanks!
>>> Brantley Hobbs
>>>
>>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/f0290ca9-ba55-4e96-8134-62d32808ac5a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Installing a package purely with Hiera configuration
Hiera is just a source of data - you need to have Puppet manifests/modules
which interpet the data and act on it.
You can achieve installation of packages from Hiera data by using defined
types and the create_resources function:
https://docs.puppetlabs.com/learning/definedtypes.html
https://docs.puppetlabs.com/references/latest/function.html#createresources
Basically you need to create a defined type which includes a package
resource. Once you've done that you can use the create_resources function
to pass the Hiera data to the defined type and install the packages.
The defined type would look something like this:
define hiera::packages ( $ensure ) {
package { $title:
ensure => $ensure
}
}
and then the create_resources call would look like this:
$packages = hiera('packages')
create_resources(hiera::packages, $packages)
Hope that helps,
Andy
On Thursday, 4 December 2014 21:00:34 UTC, Brantley Hobbs wrote:
>
> Hi all!
>
> I'm very new to puppet. I have installed a puppet master which
> successfully sets the IP address and manages sudo on a couple of nodes.
>
> I'm using Puppet 3.7 with Hiera, and so far I haven't had to write any
> manifest files, apart from the one that pulls in Hiera. As far as I can
> tell, this is a best practice.
>
> Now I would like to manage packages on my agents. I assume that in the
> node specific Hiera file, I should be able do something like the following:
>
> packages:
> apache2:
> ensure: installed
>
> However, nothing gets installed. I know I'm taking too simplistic of an
> approach, but I'm not sure where to start digging. Most things I've found
> say that I need a "wrapper class" to read in the Hiera data and install the
> packages. Is there no way to install packages purely from hiera? I've
> found some modules that propose to do this, but so far I can't get them to
> work. I'd like to do this without additional modules if possible; it seems
> like a pretty basic operation.
>
> Thanks!
> Brantley Hobbs
>
--
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to puppet-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/puppet-users/7ad3abab-32f7-42b5-9d00-01c0e8db5424%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Challenge: who am i and what do i do
I'd recommend checking out Razor: https://github.com/puppetlabs/razor-server/wiki Although as far as I'm aware it's not production ready yet. On Tuesday, 26 August 2014 20:41:01 UTC+1, Alex Demitri wrote: > > Hi guys - i am fairly new to puppet and i am trying to figure out ways to > implement it in my organization to make good use of it. One thing we > thought would be useful to better our deployment process, is to add a > mechanism that would have a vanilla server getting installed on a VM, boot > up, check into puppet and figure out these three questions: > > 1) Where am I? > - in what Datacenter/Availability zone am I? Based on that, what > syslog servers do i have to use, NTP servers, etc.. > 2) Who am I? > - what server am i? What files do i need for basic functions? > 3) What am I supposed to do? > - based on what server I am, what am i supposed to do? do i have to > run Tomcat? Apache? And if yes, where are my configuration files? > > In short, find a holistic way for a system to come up to speed by itself. > I already thought of using meaningful hostnames for the roles of the > servers but that does not work well in the cloud... > > Thoughts? > > Thanks! > Alex > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/19eb33ce-cf76-43b4-abef-a6b17dad568f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Hiera backend and web interface for multiple users
Hi, What do you all use as your Hiera backend? We've been using yaml for a while now but would like to move to something which is a bit more accessible for our developers. I've been looking at CouchDB and Redis but am struggling to find something which has a relatively easy to use interface with some level of authentication. We use Foreman as our ENC but there is no Hiera integration built in unfortunately. Thanks, Andy -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/870f737e-7cbb-41fd-ab96-9421b156d300%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[Puppet Users] Re: Hiera hashes and arrays in ERB templates
Thanks for your suggestions guys. I did consider using create_resource, but
don't see how I can when I'm trying to apply this Hiera data to a single
file. To expand on my initial post, what I need to do is create multiple
config blocks within one file resource. So this Hiera data:
haproxy_listeners :
"cluster1" :
ip : '192.168.0.2'
port : '80'
servers :
"server1" :
ip : '192.168.0.3'
port : '8080'
"server2" :
ip : '192.168.0.4'
port : '8080'
"cluster2" :
ip : '192.168.0.5'
port : '80'
servers :
"server3"
ip : '192.168.0.6'
port : '8080'
"server4"
ip : '192.168.0.7'
port : '8080'
will result in this being generated in the haproxy config file:
listen cluster1 192.168.0.2:80
server server1 192.168.0.3:8080
server server2 192.168.0.4:8080
listen cluster2 192.168.0.5:80
server server3 192.168.0.6:8080
server server4 192.168.0.7:8080
So I don't see how create_resources can handle this, as that's for creating
multiple Puppet resources, as opposed to multiple blocks within a single
file. The only alternative I can think of at the moment is using
create_resources with a define which utilizes Augeas, but I don't know how
well that will work.
Thanks,
Andy
On Friday, 4 January 2013 16:47:13 UTC, Gavin Williams wrote:
>
> I'm with Andy on this one... I'm doing something very similar with my
> NetApp volume provider (https://github.com/fatmcgav/fatmcgav-netapp/).
>
> I've created a define with the following contents:
> define util::netapp::volume (
> $ensure = present,
> $size,
> $aggr = 'aggr1',
> $snapresv = 0,
> $autoincrement = true,
> $snapschedule = {"minutes" => 0, "hours" => 0, "days" => 0,
> "weeks" => 0}
> ) {
>
> netapp_notify {"volume_define_${name}":
> message => "Processing Volume ${name}",
> }
> ->
> netapp_volume { "v_${name}":
> ensure => $ensure,
> initsize => $size,
> aggregate => $aggr,
> spaceres => "none",
> snapreserve => $snapresv,
> autoincrement => $autoincrement,
> options => {'convert_ucode' => 'on', 'no_atime_update' =>
> 'on', 'try_first' => 'volume_grow'},
> snapschedule => $snapschedule
> }
> ->
> netapp_qtree { "q_${name}":
> ensure => $ensure,
> volume => "v_${name}"
> }
> ->
> netapp_export { "/vol/v_${name}/q_${name}":
> ensure => $ensure,
> persistent => true
> }
>
> }
>
> I've added a default hash to 'snapschedule' in the options list, but that
> can be over-ridden from the Hiera data.
>
> Then use the following to pull the data from hiera and call the define:
> create_resources( util::netapp::volume, hiera('volumes') )
>
> 'Volumes' in hiera yaml looks like:
> volumes:
> vol1:
> ensure: present
> size: '500m'
> vol2:
> ensure: present
> size: '20g'
> snapschedule:
>minutes: 0
>hours: 36
>days: 0
>weeks: 0
>
> You can also use the 'hiera' command to test your yaml structure:
> $ hiera -c hiera.yaml volumes clientcert=act-star-nactl01
> {"vol1"=>{"ensure"=>"present", "size"=>"500m"},
> "vol2"=>{"ensure"=>"present", "size"=>"20g", "snapschedule"=>{"days"=>0,
> "weeks"=>0, "hours"=>36, "minutes"=>0}}}
>
> As you can see from the above output, *snapschedule* for *vol2* is a
> nested hash. This assumes that your resource provider can support hashes on
> the relevant param/property ;)
>
> HTH
>
> Gav
>
> On Friday, 4 January 2013 15:37:25 UTC, llowder wrote:
>>
>>
>>
>> On Friday, January 4, 2013 9:11:28 AM UTC-6, Andy Taylor wrote:
>>>
>>> Hi,
>>>
>>> I'm trying to build a module for haproxy which fetches all the
>>> configuration data from Hiera to populate the haproxy config file. I'
[Puppet Users] Hiera hashes and arrays in ERB templates
Hi, I'm trying to build a module for haproxy which fetches all the configuration data from Hiera to populate the haproxy config file. I've run into a number of issues though when I try to use hashes. Ideally, I want to use something like this: haproxy_listeners : "cluster1" : ip : '192.168.0.2' port : '80' servers : "server1" : ip : '192.168.0.3' port : '8080' So a hash of clusters with each cluster containing a nested hash of servers. Is this possible with Hiera/ERB? It's easy enough to iterate over the first hash, but I can't work out how to extract the contents of the nested hash. Or I might just be approaching this in entirely the wrong way... Any help would be much appreciated. Thanks, Andy -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/vtr8gCCwuBsJ. 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: Conditional based on other module
Thanks for the advice (again!) John. I'd like to avoid the restrictions that the subclass would cause, so will probably just create a separate environment and change the port based on that. Thanks for distinguishing parsed and applied, was getting a bit mixed up I think. Andy On Jun 7, 3:04 pm, jcbollinger wrote: > On Jun 7, 4:30 am, Andy Taylor wrote: > > > > > > > > > > > Hi, > > > I'm currently trying to achieve the following: a program's listen port > > changes depending on the presence of another service, specifically > > with Varnish and Apache. > > > So for example, if Varnish is installed on a server, Apache should > > listen on 8080. If it isn't, then Apache should listen on 80. > > > I've found a few ways of doing it, but was wondering if anyone else > > had run into anything similar and have found a better solution. > > Possible ways so far: > > > 1. Have Varnish/non-Varnish systems separated by environment and have > > a conditional in the module which changes the listen port dependent on > > the environment of the node; > > > 2. Use the 'defined' function (I've done a fair bit of reading on > > this, and it looks like it isn't really recommended due to parse order > > issues, and might even be removed in a future Puppet release) > > > 3. Have the Varnish module create a resource of some sort and have the > > Apache module check for its existence. But I assume I will run into > > parse ordering issues with this, unless I put Varnish in a pre run > > stage or similar. > > As Felix said, subclassing is another option, provided that (in this > example) it is never the case that Varnish is wanted but Apache isn't, > and also that the Apache class is not parameterized. > > Do not do (2) or (3). Both have parse-order issues, and these are not > solved by run stages (nor by any other use of resource relationships) > because stages influence only the order resources are *applied*, not > the order they are *parsed*. > > The bottom line is that you need to give all your classes the details > they need about what the node's configuration is supposed to be. That > information is not conveyed reliably by which classes or resources > have already been declared at any particular point. Subclassing > addresses the problem by associating sub- and superclasses. All other > reliable solutions, including your (1), revolve around one form or > another of configuration variable: a global variable, a class variable > of some well-known params class, a piece of external data (e.g. from > hiera), or a class parameter. (I include the last only for > completeness; I rarely recommend class parameterization to anyone.) > > Personally, I would give the subclass approach careful consideration, > but if I chose not to go that route then I would rely on an external > hiera data store. I might put a specific flag in the data describing > whether Varnish (for this example) is supposed to be present, or else > I might simply rely on the presence or absence of Varnish data for the > node in question. Overall, however, all of the data-driven approaches > are variations on the theme of your (1). > > 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] Re: Conditional based on other module
Thanks for your reply Fenix. By environment I meant Puppet
environment, so for example, I'd have production and development.
Production contains Varnish, Development is always non-Varnish. I then
have a selector in the apache module which, depending on the
environment, grabs a Hiera value, so something like:
$apachelisten = $::environment ? {
'production' => $apache::params::prod_listen,
'development' => $apache::params::dev_listen,
}
Then in params.pp:
class apache::params {
$prod_listen = hiera('apache_prod_listen')
etc.
or do you think there is a better way of doing this with Hiera?
On Jun 7, 10:54 am, Felix Frank
wrote:
> On 06/07/2012 11:30 AM, Andy Taylor wrote:
>
> > 1. Have Varnish/non-Varnish systems separated by environment and have
> > a conditional in the module which changes the listen port dependent on
> > the environment of the node;
>
> What do you mean by "environment"? I think this should be a hiera based
> approach, which would seem all right to me.
>
> > 2. Use the 'defined' function (I've done a fair bit of reading on
> > this, and it looks like it isn't really recommended due to parse order
> > issues, and might even be removed in a future Puppet release)
>
> Exactly. Don't do this.
>
> > 3. Have the Varnish module create a resource of some sort and have the
> > Apache module check for its existence. But I assume I will run into
> > parse ordering issues with this, unless I put Varnish in a pre run
> > stage or similar.
>
> As long as your dependencies are simple, you can do a subclass based
> approach. Say your apache port is defined inside the apache::config
> class, you could devise something like this:
>
> class apache::config::alt_port($port) inherits apache::config {
> # override the contents of ports config file
> File["/etc/apache2/ports.conf"] { content => ... }
>
> }
>
> Then the varnish module includes this subclass
>
> class { "apache::config::alt_port": port => "8080" }
>
> Note that this will get you in trouble as soon as two separate instances
> want to fiddle with apache's port.
> A hiera based approach will most likely allow you to keep things much
> cleaner.
>
> Cheers,
> Felix
--
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] Conditional based on other module
Hi, I'm currently trying to achieve the following: a program's listen port changes depending on the presence of another service, specifically with Varnish and Apache. So for example, if Varnish is installed on a server, Apache should listen on 8080. If it isn't, then Apache should listen on 80. I've found a few ways of doing it, but was wondering if anyone else had run into anything similar and have found a better solution. Possible ways so far: 1. Have Varnish/non-Varnish systems separated by environment and have a conditional in the module which changes the listen port dependent on the environment of the node; 2. Use the 'defined' function (I've done a fair bit of reading on this, and it looks like it isn't really recommended due to parse order issues, and might even be removed in a future Puppet release) 3. Have the Varnish module create a resource of some sort and have the Apache module check for its existence. But I assume I will run into parse ordering issues with this, unless I put Varnish in a pre run stage or similar. Thanks :) -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet/Hiera and Git workflow
The git branches/Puppet environments actually mirror the infrastructure. So we have groups of servers. Unstable is just for nodes which I test new functionality on, dev is for web developers. So it seemed to make sense to mirror the environments in the git repository with branches. On May 29, 9:28 pm, Nigel Kersten wrote: > On Mon, May 28, 2012 at 6:14 AM, Andy Taylor wrote: > > I'm currently trying to work out the best way structure my Puppet > > environments and VCS structure. At the moment I'mk working on > > something like this: > > > Three Git repositories (one for modules, one for Hiera, one for node > > manifests) > > Multiple branches (each branch representing an environment, e.g. > > production, dev, testing etc.) > > > When changes to modules/Hiera are made, the changes will be made to a > > testing branch, and then merged up the branches until it hits > > production (with the appropriate testing of course). So something like > > this: > > > unstable > dev > testing > production > > Do you need a distinction between "unstable" and "dev" ? I've often found > that I don't need those to be separate stages. > > > > > > > > > > > > > What system do you guys use? Any suggestions about the above workflow? > > > Thanks! > > > Andy > > > -- > > 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. > > -- > Nigel Kersten |http://puppetlabs.com| @nigelkersten > Schedule Meetings at:http://tungle.me/nigelkersten -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To post to this group, send email to puppet-users@googlegroups.com. To unsubscribe from this group, send email to puppet-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
[Puppet Users] Re: Puppet/Hiera and Git workflow
Thanks guys, very interesting. I guess the main thing I'm concerned about with my workflow is that I'll be doing a lot of merging, and I'm not sure how sustainable that is. For example: 1. Add new feature to unstable 2. Merge to dev 3. Merge to testing 4. Merge to production The idea being that once I've done step 4, all four branches will be identical. Between each step I'll be doing extensive testing. I'm also a bit worried about how I'm sacrificing agility with this workflow, unless I'm confident enough with a change that I'll merge dev/testing/ production with unstable in one go. On May 29, 12:48 pm, Carlos Rico wrote: > We work only with one Git repository for Puppet, and it contains: > - 1 directory for hiera-data -> structured environments. For instance: > > hiera-data > |--common > | |- us > |--master > | |- us > |--production > (etc) > > - 1 directory for all nodes, and 1 manifests file (xx.pp) for each node type > > - And the rest of Puppet modules > > Carlos. > > El lunes, 28 de mayo de 2012 15:14:54 UTC+2, Andy Taylor escribió: > > > > > > > > > > > I'm currently trying to work out the best way structure my Puppet > > environments and VCS structure. At the moment I'mk working on > > something like this: > > > Three Git repositories (one for modules, one for Hiera, one for node > > manifests) > > Multiple branches (each branch representing an environment, e.g. > > production, dev, testing etc.) > > > When changes to modules/Hiera are made, the changes will be made to a > > testing branch, and then merged up the branches until it hits > > production (with the appropriate testing of course). So something like > > this: > > > unstable > dev > testing > production > > > What system do you guys use? Any suggestions about the above workflow? > > > Thanks! > > > Andy > > El lunes, 28 de mayo de 2012 15:14:54 UTC+2, Andy Taylor escribió: > > > > > > > > > > > I'm currently trying to work out the best way structure my Puppet > > environments and VCS structure. At the moment I'mk working on > > something like this: > > > Three Git repositories (one for modules, one for Hiera, one for node > > manifests) > > Multiple branches (each branch representing an environment, e.g. > > production, dev, testing etc.) > > > When changes to modules/Hiera are made, the changes will be made to a > > testing branch, and then merged up the branches until it hits > > production (with the appropriate testing of course). So something like > > this: > > > unstable > dev > testing > production > > > What system do you guys use? Any suggestions about the above workflow? > > > Thanks! > > > Andy -- 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/Hiera and Git workflow
I'm currently trying to work out the best way structure my Puppet environments and VCS structure. At the moment I'mk working on something like this: Three Git repositories (one for modules, one for Hiera, one for node manifests) Multiple branches (each branch representing an environment, e.g. production, dev, testing etc.) When changes to modules/Hiera are made, the changes will be made to a testing branch, and then merged up the branches until it hits production (with the appropriate testing of course). So something like this: unstable > dev > testing > production What system do you guys use? Any suggestions about the above workflow? Thanks! Andy -- 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: Newbie question: what to start from?
Welcome :) I started here: http://docs.puppetlabs.com/learning/ Lots of good material. On May 17, 10:24 pm, "Anatoliy Lisovskiy (Wavebourn)" wrote: > Hello fellow community members! > > I just joined you in order to find an information about how to start > using Puppet... > > Currently we use cfengine for our legacy system containing several OS > platforms, including physical and virtual servers. For fresh new > hardware and OS versions we decided to go with Puppet due to it's > growing popularity (wow, 4082 members of this group only!). > > I've installed it on a Linux KVM guest, it is up and running. > > What's next, what would you recommend me to do now, in order to avoid > common errors causing messy configuration? Do we have some kind of > FAQ? > > Sincerely, > Anatoliy -- 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: Managing system yum repositories with yumrepo cache issues
Thanks guys. In the end I set up a notify to ping an exec which did a yum clean operation whenever a yumrepo resource was modified. Seems to work fine. Thanks! Andy On May 5, 1:59 am, Eric Shamow wrote: > Just a note - it's better to do yum clean metadata than all in most cases. > > There's no reason to drop all that cached package stuff - you just want to > get rid of the repo index. > > -- > > Eric Shamow > Professional Serviceshttp://puppetlabs.com/ > (c)631.871.6441 > > > > > > > > On Friday, May 4, 2012 at 5:11 PM, Jo Rhett wrote: > > I just have it run a "yum clean all" exec command every time a repo is > > updated. Since they all refer to the same exec, it only happens once after > > the repos are updated. > > > The tricky part is ensuring that anything trying to update software in the > > same run has a require=> set that ensures all the yum repos and the yum > > clean all are completed before they run, or you get: > > > update yum repo > > update package > > yum clean all > > …. > > > I just require the entire yumrepo class, but there may be better ways. > > > On May 4, 2012, at 6:54 AM, Andy Taylor wrote: > > > I'm trying to get my yum module to manage system repositories like > > > CentOS-Base. My yum module is part of a pre run stage so it puts the > > > necessary repositories in place before other modules try to install > > > anything. > > > > I've just run into a problem though; when Puppet installs a repo via > > > yumrepo, it doesn't clear the yum cache. This means that when the > > > modules in the main stage start trying to install packages, many will > > > error as yum doesn't see the new respositories. > > > > Running yum clean metadata fixes this, but I'm not sure how best to > > > automate it in the module. I don't want to turn metadata caching off, > > > or have a regular cron flushing it as I've seeen suggested before - an > > > exec subscribed to /etc/yum.repos.d would be perfect, but that doesn't > > > work. > > > > I'm posting this here prior to putting something in the Puppet Labs > > > bug tracker, as either a feature request or a bug (I think it's fairly > > > essential that adding repositories leads to a refresh of yum cache... > > > shouldn't really have to work around it in my opinion) > > > > Thanks! > > > > Andy > > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "Puppet Users" group. > > > To post to this group, send email to puppet-users@googlegroups.com > > > (mailto:puppet-users@googlegroups.com). > > > To unsubscribe from this group, send email to > > > puppet-users+unsubscr...@googlegroups.com > > > (mailto:puppet-users+unsubscr...@googlegroups.com). > > > For more options, visit this group > > > athttp://groups.google.com/group/puppet-users?hl=en. > > > -- > > Jo Rhett > > Net Consonance : net philanthropy to improve open source and internet > > projects. > > > -- > > You received this message because you are subscribed to the Google Groups > > "Puppet Users" group. > > To post to this group, send email to puppet-users@googlegroups.com > > (mailto:puppet-users@googlegroups.com). > > To unsubscribe from this group, send email to > > puppet-users+unsubscr...@googlegroups.com > > (mailto:puppet-users+unsubscr...@googlegroups.com). > > For more options, visit this group > > athttp://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] Managing system yum repositories with yumrepo cache issues
Hi, I'm trying to get my yum module to manage system repositories like CentOS-Base. My yum module is part of a pre run stage so it puts the necessary repositories in place before other modules try to install anything. I've just run into a problem though; when Puppet installs a repo via yumrepo, it doesn't clear the yum cache. This means that when the modules in the main stage start trying to install packages, many will error as yum doesn't see the new respositories. Running yum clean metadata fixes this, but I'm not sure how best to automate it in the module. I don't want to turn metadata caching off, or have a regular cron flushing it as I've seeen suggested before - an exec subscribed to /etc/yum.repos.d would be perfect, but that doesn't work. I'm posting this here prior to putting something in the Puppet Labs bug tracker, as either a feature request or a bug (I think it's fairly essential that adding repositories leads to a refresh of yum cache... shouldn't really have to work around it in my opinion) Thanks! Andy -- 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: Parametrized classes, definitions and structure
Thanks John for yet another very useful reply, it is much appreciated.
I'm going to do some more reading on Hiera and look at reworking my
modules.
And thank you Ramin for some examples of Hiera in practice, looks very
interesting! Going to have a play around with it next week :)
Thanks!
On Apr 25, 7:01 pm, Ramin K wrote:
> On 4/24/2012 10:31 AM,AndyTaylorwrote:
>
>
>
>
>
>
>
>
>
> > Thank you very much for your detailed reply John. I hadn't looked at
> > Hiera before, it looks very interesting. On the point of it's not good
> > to include node/site data in manifests, it's kind of essential in my
> > eyes to the setup I am trying to implement.
>
> > At my company, one server may serve a site which has very different
> > requirements to another, so I really needed something that was very
> > flexible. To expand on the structure I outlined in my previous post:
> > each server has it's own node.pp file. If you need to change something
> > (e.g. MySQL settings, which will probably the most frequent one that
> > needs changing), you can simply edit that server's node manifest file.
> > The great advantage here is that each site's node manifest serves as
> > documentation of what changes have been made to it. It's also very
> > easy to read and understand for someone new to Puppet.
>
> > From some quick reading of the Hiera posts on the Puppet Labs blog, I
> > guess I could simply have a yaml file for each server with overrides
> > instead of doing it via the node manifest. However, I don't really see
> > the advantage of this approach, except for it would cut out some of
> > the clutter in my Puppet modules. The idea of a hierarchical set of
> > data being considered in line with Facter facts is very interesting
> > though, especially if I combined it with some custom facts of my own;
> > I will do some more reading on that.
>
> > With the class/definition point, I am wherever possible using classes,
> > as usually I'm dealing with the nature of a node (e.g. you are a
> > webserver, database server etc.) The only case I have used definitions
> > is for these configuration file overrides. So if I'm understanding
> > your comments on class/definition use properly, I think I'm sort of
> > taking the right approach to it...
>
> > The key concern for me at the moment is flexibility and scalability...
> > none of my stuff is live yet, and I want to make sure I'm using best
> > practices before I put it all in place. :)
>
> Mr Bollinger did his usual excellent job of thoroughly explaining the
> problem space in other parts of this thread. I'd simply add that using a
> richer data store, such as Hiera, can keep you from doing complicated
> gymnastics in your module code.
>
> I'm using a hiera.yaml file similar to the following with fqdn at the
> top and common at the bottom. I've added a role fact which is reading
> /etc/role on the client. You can use any Facter fact such as %{domain}
> or write your own. %{location} or %{datacenter} seems to be a common one
> for admins with multiple sites.
>
> :hierarchy:
> - %{fqdn}
> - %{role}_%{environment}
> - %{role}
> - %{environment}
> - common
>
> In my mysql::data class I add a variable and give it a default of 256M.
>
> $innodb_buffer_pool_size = hiera('mysql_innodb_buffer_pool_size', '256M')
>
> I can then set the following to deal with the specifics of my environment.
> 512M in my prod environment, production.yaml
> 4G in role db, db.yaml
> 1.5G on role db in environment stage, db_stage.yaml
> 8G on server db01.main.sfo, db01.main.sfo.mydomain.com.yaml
>
> Going one step further you can use hiera_array to merge data. For
> example you might allow a set of servers to monitor all servers and then
> allow the local monitors as well. Assuming a location fact and the
> following data files
>
> common.yaml
> monitoring_hosts:
> - 'mon01.ord'
> - 'mon02.ord'
>
> lax.yaml
> monitoring_hosts:
> - 'mon01.lax'
>
> class someclass::data {
> $hosts = hiera_array('monitoring_hosts')
>
> }
>
> someclass::data::hosts = ['mon01.lax','mon01.ord','mon02.ord']
>
> Hopefully this should give you some ideas of how to use Hiera in your
> new system.
>
> Ramin
--
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: Parametrized classes, definitions and structure
Thank you very much for your detailed reply John. I hadn't looked at
Hiera before, it looks very interesting. On the point of it's not good
to include node/site data in manifests, it's kind of essential in my
eyes to the setup I am trying to implement.
At my company, one server may serve a site which has very different
requirements to another, so I really needed something that was very
flexible. To expand on the structure I outlined in my previous post:
each server has it's own node.pp file. If you need to change something
(e.g. MySQL settings, which will probably the most frequent one that
needs changing), you can simply edit that server's node manifest file.
The great advantage here is that each site's node manifest serves as
documentation of what changes have been made to it. It's also very
easy to read and understand for someone new to Puppet.
>From some quick reading of the Hiera posts on the Puppet Labs blog, I
guess I could simply have a yaml file for each server with overrides
instead of doing it via the node manifest. However, I don't really see
the advantage of this approach, except for it would cut out some of
the clutter in my Puppet modules. The idea of a hierarchical set of
data being considered in line with Facter facts is very interesting
though, especially if I combined it with some custom facts of my own;
I will do some more reading on that.
With the class/definition point, I am wherever possible using classes,
as usually I'm dealing with the nature of a node (e.g. you are a
webserver, database server etc.) The only case I have used definitions
is for these configuration file overrides. So if I'm understanding
your comments on class/definition use properly, I think I'm sort of
taking the right approach to it...
The key concern for me at the moment is flexibility and scalability...
none of my stuff is live yet, and I want to make sure I'm using best
practices before I put it all in place. :)
On Apr 24, 5:13 pm, jcbollinger wrote:
> On Apr 24, 9:13 am, Andy Taylor wrote:
>
>
>
>
>
>
>
>
>
> > Hi,
>
> > I've written a set of Puppet modules to manage servers, but am
> > slightly concerned about the structure I've used as it seems to differ
> > significantly from anything else I've seen in Puppet Forge/elsewhere
> > on the internet.
>
> > I've made extensive use of definitions so that defaults for modules
> > can be overridden in the node manifest for a server. For example:
>
> > node examplenode.example.com {
>
> > include apache
> > include mysql
>
> > define apache::config {
> > listenport => 8080
>
> > }
>
> > define mysql::config
>
> > }
>
> > So in each module, I have a config definition which must be called in
> > each node manifest, even if you don't want to override any defaults
> > (as in the case of MySQL above). I haven't used parametrized classes
> > at all.
>
> > It all works fine,
>
> That it works well is the most important criterion. With that
> said, ...
>
> > but are there any disadvantages to the sort of
> > structure I'm using? Should I be using more parametrized classes
> > instead of definitions?
>
> One problem with using definitions, especially definitions that are
> required to be instantiated for multiple classes to work, is that each
> instantiation of a definition is a separate resource. Each must
> therefore have a unique name among the resources of its type, and each
> will be applied separately. This presents either a management problem
> (who is responsible for instantiating the definition in any given set
> of circumstances?) or an efficiency problem (equivalent definition
> instances are redundantly applied) or both.
>
> Parameterized classes do not present that efficiency problem because
> all classes are singletons. That intensifies the management problem,
> however, because unlike ordinary classes, each parameterized class can
> be declared only once for any given node. In general, few problems
> are best solved by parameterized classes.
>
> You should use defined types only when you need *resources* for which
> there is no native type available. In that case you should know that
> you want resources rather than classes. That might be because nodes
> can have more than one instance of your 'thing', because you want
> support for virtual or exported 'things', or (best) simply because
> your 'thing' is better characterized as something nodes *have* than as
> something that they *are*.
>
> On the other hand, you should use (ordinary) classes where you want
> their singleton nature -- especially idempotency, which is a far more
>
[Puppet Users] Parametrized classes, definitions and structure
Hi,
I've written a set of Puppet modules to manage servers, but am
slightly concerned about the structure I've used as it seems to differ
significantly from anything else I've seen in Puppet Forge/elsewhere
on the internet.
I've made extensive use of definitions so that defaults for modules
can be overridden in the node manifest for a server. For example:
node examplenode.example.com {
include apache
include mysql
define apache::config {
listenport => 8080
}
define mysql::config
}
So in each module, I have a config definition which must be called in
each node manifest, even if you don't want to override any defaults
(as in the case of MySQL above). I haven't used parametrized classes
at all.
It all works fine, but are there any disadvantages to the sort of
structure I'm using? Should I be using more parametrized classes
instead of definitions?
--
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: Creating multiple resources from an array
Thanks for the solution, works great :) And I had to resort to google for the barney reference - I'll pass that right along :) On Mar 13, 9:37 pm, jcbollinger wrote: > And tell Barney I said "hey." -- 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] Creating multiple resources from an array
Hi,
I'm currently trying to write a module to manage Squid, including the
SSL certificates it uses. Sometimes you want Squid to listen on
multiple IPs with multiple certificates, so I'm trying to get Puppet
to push the certificates to the nodes and configure Squid accordingly.
I've run into a problem with the idea of pushing multiple certificates
though. The module has a definition called squid::config, which is
called in each node manifest if you need to override certain settings
on the node. For example, if a node needed Squid to use two
certificates, you would put this in the manifest:
squid::config { "www.example.com":
certificatename => ['www.example.com','www.example2.com']
}
Now, I've got the config file management working fine, but getting it
to push the certificates and private keys is a pain. Essentially I
need Puppet to iterate over the keys in the array as part of a file
resource, like this:
file { "/etc/squid/keys/$certificatename.crt":
ensure => present,
source => "puppet:///modules/squid/certificates/$certificatename.crt"
}
file { "/etc/squid/keys/$certificatename.key.pem":
ensure => present,
source => "puppet:///modules/squid/certificates/
$certificatename.key.pem"
}
It would then grab the .crt files from the /certificates directory and
put them on the node. If I was writing this in Bash, I'd just use a
for loop, but that isn't an option with Puppet as far as I can see...
I've tried a number of different things, but I keep on hitting a brick
wall, to the point that I think I'm just approaching this in entirely
the wrong way. If anyone could give me some advice on how to proceed
it would be much appreciated.
--
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.
