On Tuesday, August 21, 2012 6:25:53 PM UTC-4, Tim Mooney wrote:
>
> In regard to: [Puppet Users] package handling in puppet?, lamour said
> (at...:
>
> > so, I've got most of the pieces worked out, but I've hit a major
> roadblock
> > with the way packages are handled in puppet. (according to my limited
> > understanding of puppet, that is) The problem starts with the fact that
> > including the following in two different classes:
> >
> > package { 'perl': ensure => installed }
>
> There are several ways to deal with this.
>
> I know perl is probably a general example of the problem, but at least
> in that case, it's fairly rare that you need to specify the interpreter
> directly. If you're making good use of packages, what you probably
> instead want is something like
>
> package { 'perl-Net-SMTP-SSL':
> ensure => installed,
> require => Yumrepo['your-local-repo-name-or-maybe-epel'],
> }
>
>
Yeah, that's what we're planning on doing, but that only gets you so far.
The real issue with all of this is that I don't want the act of someone
adding a package into a class somewhere to cause puppet to fail due to an
unexpected collision. If I want to avoid that, I need to use some syntax
that doesn't flag conflicts where they don't actually exist. For instance,
I might require perl-DBI in, say, the samba class and the apache class (for
whatever reason). There's not really a problem with that unless I need
both of those classes on the same server. This leaves me with two choices,
allow the errors to happen and fix them as they pop up or just pre-wrap
every package in a class to avoid the problem altogether. Both choices
make me sad. lol
> > This is pretty unfortunate, but we can try to work around it by doing
> this:
> >
> > package { 'test-perl': ensure => installed, alias => 'perl' }
>
> *Definitely* do not do this. There might be other places where this
> kind of chicanery is appropriate, but it's not a good idea here.
>
>
Ok. lol. I probably wouldn't have implemented it this way anyway, but it
was the first work-around that I thought of when we ran into the problem.
> > Another, less gross, way to do it is to do something like this:
>
>
> > if !defined(Package['perl']) {
> > package { 'perl':
> > ensure => installed,
> > }
> > }
>
> I would instead do something more like
>
> file { 'your-unpackaged-perl-script-here.pl':
> ensure => file,
> owner => 'whomever',
> group => 'ditto',
> mode => '0whatever-whatever-whatever',
> require => Package['perl'],
> source => 'puppet:///module_name/script-source-here.pl',
> }
>
>
So, I guess I don't understand this. Does this require not cause a
collision? Does this require cause the resource to become defined? Can
you require more than one package? I'll have to go read the documentation
to learn more about what this does, even though I don't think this helps
me, because I can't see how I could realistically tie all of my package
definitions to files.
> > We also stumbled across the Singleton puppet module, which does almost
> kind
> > of exactly what we want, except it has a dependency on hiera. We haven't
> > really decided whether to use hiera or not. Efforts to rip the hiera
> > dependencies out of Singleton and also getting it to run even with hiera
> > installed have both failed. I'll probably keep looking into modifying
> the
> > ruby code to behave in some useful manner for us, but for now, I'm
> running
> > out of good options.
>
> Don't rip out hiera, it will be part of puppet 3.x. I'm not familiar with
> the Singleton module, but I wouldn't think you would need to resort to
> external modules for something that's pretty fundamental to the problem
> domain.
>
>
Yeah, looking at the documentation again, it seems like I misunderstood how
Singleton works. It seems like the configuration for the Singleton package
is even more involved than the other options we've discussed here, which
kinda defeats the purpose. I think I could probably figure out a way to
make a function to do what I want, but I'm going to save it for when I get
a little more comfortable with ruby. lol
Thanks for all of your advice. It's nice to get a bit of perspective from
people who are already using puppet in the wild.
thanks,
Michael
--
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/-/XzuE9r4bn_oJ.
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.
