Re: [Puppet Users] yum repo on same machine as Puppet Master?
Thomas, By design, PE will not interfere with the vendor httpd package. With a small setup like that, I do not see keeping your repo there as being something you shouldn't do. Just be mindful of the non-puppet services you wish to host from the master. If there is any insecurity or vulnerability in the extra services you host from your master, then Puppet might not be as secure. -- Tom Linkin Professional Services Engineer http://puppetlabs.com/ twitter: @trlinkin On Wednesday, November 21, 2012 at 2:41 PM, Thomas wrote: > I'm a relative newbie using Puppet Enterprise 2.5.3 (I know there are new > versions) > > I currently have my Yum repo served via HTTP on a different machine from my > Puppet Master and I'm considering moving my Yum repo to the same machine that > runs the Puppet Master. Is that a good, bad or indifferent practice? > > My Puppet Master (for now) will manage less than 10 nodes so I'm not worried > about performance. > > Thanks! Thomas Kenny > > -- > 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/-/ZYfycYodG_wJ. > 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 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.
Re: [Puppet Users] How to create a directory if that path does not yet exist?
Marc,
There is no way in the resource declaration for 'file' to stop it from ensuring
your symlink is made into a directory. That is because this is the state you're
asking to have ensured when you compile that resource into a catalog. What you
may want to do is find a way to have the resource either ensure a symlink for
those hosts or not be in your catalog. I recommend the finding a way to have it
ensure a symlink.
You could probably do this most easily by wrapping it in a conditional that
responds to a top-level variable (either from your ENC or in your node
definition). If you are using hiera, perhaps you can keep the variable there.
Another option, could be to create a custom fact that detects when you've
created a symlink. However, this method does not really capture the fact that
you've done the symlink anywhere except on the host. Were this host to fail in
an unrecoverable manner, or even just be rebuilt by someone who is not you,
this detail may be missed.
--
Tom Linkin
Professional Services Engineer
http://puppetlabs.com/
twitter: @trlinkin
On Friday, September 28, 2012 at 11:01 AM, Marc Haber wrote:
> Hi,
>
> I have the following resource defined:
>
> file { "/var/lib/foo":
> ensure => directory,
> owner => root,
> group => root,
> mode => 0755,
> }
>
> On some systems, but not on all, I have /var/lib/foo symlinked to
> another partition with more space. Those symlinks (/var/lib/foo =>
> /space/foo) are replaced during the puppet run with a local directory.
>
> Neither the force nor the replace parameter to the File resource seems
> to stop this behavior.
>
> Is there anyway to obtain this behavior short of using an exec?
>
> Greetings
> Marc
>
> --
> -
> Marc Haber | "I don't trust Computers. They | Mailadresse im Header
> Mannheim, Germany | lose things." Winona Ryder | Fon: *49 621 31958061
> Nordisch by Nature | How to make an American Quilt | Fax: *49 621 31958062
>
> --
> 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 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.
Re: [Puppet Users] Re: Puppet 2.7, hiera 1.0 and hiera as an ENC
Guillem,
Sorry for the delayed response. Anyway, John is correct about what you're
trying to do with Hiera. I can say as far as the ENC Gary has written follows
all the rules of what an ENC 'should do' as per the documentation.
http://docs.puppetlabs.com/guides/external_nodes.html
Keep in mind also, when the ENC is run, the only information it has access to
is the Facts from the node. The manifests are not compiled until after the ENC
returns the classes it has determined should be declared. This ENC does it in
one call to hiera for classes. When this Hiera ENC processes, it never adds the
discovered parameters and other variables to the current running context. While
that could achieve what you want, it could also complicate things in unexpected
ways. So as I said above, when the ENC runs, you only have just the facts from
the host as your current context.
John's suggestion of a new usage model that aligns better with Hiera's design
is probably the best answer. That being a case, I would suggest custom facts to
help you navigate your hiera tree in a more controlled/granular manner.
--
Tom Linkin
Professional Services Engineer
http://puppetlabs.com/
twitter: @trlinkin
On Monday, October 1, 2012 at 10:47 AM, jcbollinger wrote:
>
>
> On Wednesday, September 26, 2012 10:52:19 AM UTC-5, Guillem Liarte wrote:
> > This is the situation I have:
> >
> > All my hosts are the same OS.
> > All my host are in the same puppet environment, so I cannot use
> > %{environment}
> >
> > I have a module that sets all the basic functionality for the OS,
> > resolution, authentication, security, packages, etc
> > I have a module for each application hosted.
> >
> > At the moment all the 'data' is in Puppet, mostly in parametrised classes
> > in site.pp.
> >
> > What I want to get is a hiera set-up that allows me to use this structure:
>
>
> I suspect that one of the reasons you are having trouble is that you are
> trying to employ a usage paradigm that is inconsistent with hiera's design
> (more below).
>
> >
> > :hierarchy:
> > - global # source of application names (classes? modules?) and
> > environments list
> > - basic # data for the basic class
>
> There's nothing wrong with those levels.
>
> > - prod/%{application}/%{hostname}# hostname files for specific
> > data
> > - prod/%{application}/%{env} # environmental data for
> > each application (module)
> > - prod/%{application}/default # default data for an
> > application
>
>
> But there is a problem with those. It may be possible to make it work, but
> it's shaky to use variable hierarchy levels for data selection. That's what
> keys are for. With that said, recent Puppet releases provide automatic
> $calling_module and $calling_class variables, one of which you could probably
> use in place of $application. As I understand it, that's intended to provide
> (better) support for module-specific data, which might be a good way to cast
> that part of your problem.
>
>
> > - nonprod/%{sysclass}/%{hostname}
> > - nonprod/%{sysclass}/%{env}
> > - nonprod/%{sysclass}/default
>
>
> You additionally have a fundamental problem with %{env}. Hiera will attempt
> to resolve that as a Puppet variable, to which the presence of a matching key
> somewhere in the Hiera hierarchy is irrelevant. Hiera needs to know the
> value to resolve the hierarchy (as you have defined it), and it would need,
> in principle, to resolve the hierarchy before it could look up the value in
> your data store.
>
> What actually happens, I'm sure, is that hiera uses the value of $::env that
> it looks up in Puppet at function entry. You might be able to work around
> that by setting that variable in Puppet before looking up other data, such as
> by putting
>
> $env = hiera('env')
>
> at top scope near the beginning of your site.pp.
>
>
> >
> > So in short, I would like hiera to be a source of facts, where I can get
> > information that feeds Puppet in order to classify the nodes and to feed
> > the parametrised classes.
>
>
> As an aside, throwing parametrized classes into this mix has only downside as
> far as I am concerned, except inasmuch as you may want to use parametrized
> classes that are (unwisely) provided by modules written by others. Since you
> want to rely on hiera (which is good), it is superior to write your classes
> like this wherever you are in control of module interfaces:
>
> class mymodule::class1 {
> $param1 = hiera('mymodule::class1::param1')
> $param2 = hiera('mymodule::class1::param2')
> # or with simpler keys enabled by use of
> # %{calling_module} and/or %{calling_class}
> }
>
> There are several advantages, among them that you can encode interclass
> parse-order dependencies via the built-in 'include' function, and that you
> can use hiera's 'hiera_include()' function to assign such classes to nodes.
>
> >
> > I recentl
