Re: [Puppet Users] Installing only the puppet client

Forrest Aldrich
Sun, 17 Jan 2010 01:02:16 -0000

On 1/16/10 7:42 PM, James Turnbull wrote:
> [ ... ]
> It''s easy to create your own packages from the source - certainly
> debs and RPMs for example - the spec file is even distributed with
> the source.
>
Ha!  I didn''t even see that in the conf/ directory  :)

>> Here''s what I''ve been working on today; perhaps
you''ll have some
>> feedback (it''s relevant to the post).   I''m
installing ruby, puppet,
>> gems (under ruby) under a central directory structure.   From there, I
>> can either rsync that to other systems or NFS mount it.  Then, use the
>> local system "alternatives" command to point the relevant
executables
>> (and --slave definitions).  Each system can have it''s own
puppet
>> configuration in /etc that''s managed via Puppet.  An example:
>>
> What''s your intent here? What do you get out of this that a
standard
> Ruby, Puppet, etc installation doesn''t provide?  Especially as you
> can write a manifest to manage all the packages, gems, etc, etc and
> avoid what feels like quite a complex solution?
>
Don''t rain on my complex parade! :-)

My intent was to install the executables in one place and share this
amongst the Redhat systems either via rsync directly or via NFS, using
alternatives to link to them accordingly.   And reducing the dependency
on OS-provided packaging of things like Ruby, where vendors are
generally several revisions behind.

In the past, I''ve been bitten by "system skew" where, even
under the
best conditions, many systems that are supposed to be the same end up
having minor differences.   This is what got me into isolating a few
tools as above.

>
>> One problem I''ve observed is ruby will need to be
"installed" in
>> /local/company/ruby first, where I later rename it to ruby.1.8.7 with a
>> symlink of "ruby" so that the installation is consistent with
shebang paths.
>>
> Yeah - complex. :)
>

You are, of course, right :-)



Thanks,

Forrest