[csw-pkgsubmissions] newpkgs puppet, puppetmaster

[Mark Phillips]

On Sun, 13 Mar 2011, Philip Brown wrote:

> On Sun, Mar 13, 2011 at 1:41 PM, Mark Phillips <markp at opencsw.org> wrote:
>> I've had to do some oddities to make this work to CSW path standards. Puppet
>> enforces /var/lib/puppet and /etc/puppet as real paths, and not symlinks. This
>> means if we symlink to /etc/opt/csw/puppet and /var/opt/csw/puppet they'll
>> simply get trounced on as soon as the daemon(s) run up. It also completely
>> ignores our attempts to put our paths in as defaults. To this end, I've HAD
>> to create /etc/puppet - but in it contains an example puppet.conf designed to
>> make the daemon run in CSW paths. Also present in that directory is a
>> README.CSW pointing out how to use CSW paths.
>
>
> Hmm.. I got confused the first few times I read your email. But what I 
> *think* you are saying, is that you were forced to create one somewhat 
> non-standard path, /etc/puppet.. but other than that, your default 
> puppet configurations, make it follow our standard layouts. And you have 
> put documentation in /etc/puppet to explain to people coming from other 
> systems, what the differences are.

Hey Phil,

Yes, that's about it. It was Hobson's Choice really - I need to take up 
this forced behaviour with the puppetlabs folks - but at least everything 
installs into our paths.

> Basically, that your "new" package, mostly follows the pre-existing 
> layout of our older puppet package. Great!

Correct. The old package attempted to set the right paths but then had 
symlinks to make it behave correctly, although it didn't ;) Puppet 
immediately trounced the symlink and made it a path anyway.

> Additionally, I have to say that a nice change you have made is to
> split out the "puppetmaster" into a separate package.

I'd love to take credit for that, but it wasn't my idea - Dago did that. 
But yes, I agree with it; again for the big corporates running 
multiplatform estates it brings us inline with the [rapidly becoming] 
defacto, Linux.

> (Although perhaps more of the stuff belongs in the "puppetmaster"
> package and less in the "puppet" package?

Surprisingly not. Although your understanding is more or less correct, all 
the work is still done on the client end of things - so all the libraries 
containing the 'types' (things in Puppet that do stuff) are required 
locally, else it doesn't know that 'service:' types are handled by 
'service' on Linux, 'svcadm' on Solaris, and so on.

So really all we're doing with the puppet and puppetmaster packages is 
separating out the client and the server. Follows the Linux package too, 
which is split in the same way.

> But okay, releasing as-is)

That's brilliant news, thanks. There are a lot of folks asking for this 
much newer version, it'll go down well with the community that we've 
caught up!

Cheers,

--Mark