Installing only the puppet client
Forrie
I looked through install.rb and didn't see any specific options,
though I seem to recall another Linux dist that separated them out.
It's possible I'm approaching this incorrectly, though it doesn't make
a lot of sense to install puppetmasterd on systems that are only
clients. Another option, perhaps, is to have puppet actually update
the client portion on the managed systems. Has anyone done this?
Thanks.
Scott Smith
rm /path/to/puppetmasterd
James Turnbull
Hash: SHA1
On 17/01/10 6:33 AM, Forrie wrote:
> Is there a way to deploy/install only the client portion of puppet?
Not via install.rb
> It's possible I'm approaching this incorrectly, though it doesn't make
> a lot of sense to install puppetmasterd on systems that are only
> clients. Another option, perhaps, is to have puppet actually update
> the client portion on the managed systems. Has anyone done this?
IMHO - yes - don't install via source! It's not scalable and it
leads to issues when upgrading.
Use your operating system or distribution's packaging system instead.
You can then easily use Puppet to manage itself on clients - in fact
I recommend it as an approach.
Regards
James Turnbull
- --
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEVAwUBS1JTDiFa/lDkFHAyAQK5SggAjf7+ZnvrgST1qVmmRJWXekMORi7rnAsS
jtFdFjzccr0/DK/wEUFGVZeq++iGDWO8RRGWmd9rUin0G4DakbJZwXDZd0FUuvLJ
ZaB8gfLQazE3YJ5g0jvM6C+mhFogsLIoQxTQf/sALU//+hSp4CkKRqeD4zLrZmrP
FL1lbd3eZazRvkxbwHjJ+Hxc5g1MsZo97rM4B4pj1Dp/JUWFGbcQuqtlTcMAZOhP
w6/NcBlVciIc1oZxGWBUVLcQVQDXvA2S3nm3x/0QPGzDHw/NG9RMh1GkAvdhVREB
WTANo4OPvx1bIg4JV233rZybUR5jLbHMqUflUkQO1zzytp04fgOG0A==
=pBT1
-----END PGP SIGNATURE-----
Forrest Aldrich
On 1/16/10 7:00 PM, James Turnbull wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On 17/01/10 6:33 AM, Forrie wrote:
>
>> Is there a way to deploy/install only the client portion of puppet?
>>
> Not via install.rb
>
>
>> It's possible I'm approaching this incorrectly, though it doesn't make
>> a lot of sense to install puppetmasterd on systems that are only
>> clients. Another option, perhaps, is to have puppet actually update
>> the client portion on the managed systems. Has anyone done this?
>>
> IMHO - yes - don't install via source! It's not scalable and it
> leads to issues when upgrading.
>
> Use your operating system or distribution's packaging system instead.
>
> You can then easily use Puppet to manage itself on clients - in fact
> I recommend it as an approach.
>
>
>
Thanks for your reply!
I think having Puppet distribute itself to clients would be ideal. One
less headache.
I generally don't like to rely on external packaging for certain
software packages -- it complicates things when I want to keep up to
date; and then, when I do want more current code, I just end up
compiling it separately anyway.
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:
/local/company/puppet
/sbin
/bin
/local/company/ruby
/bin
/lib
[ everything from ruby, including rubygems and individual gems ]
Using "alternatives", do something like this:
/usr/sbin/alternatives --install /usr/bin/ruby ruby
/local/company/ruby/bin/ruby 1 \
--slave /usr/bin/rdoc rdoc /local/company/ruby/bin/rdoc \
--slave /usr/bin/ri ri /local/company/ruby/bin/ri \
--slave /usr/bin/irb irb /local/company/ruby/bin/irb \
--slave /usr/bin/erb erb /local/company/ruby/bin/erb \
--slave /usr/bin/testrb testrb /local/company/ruby/bin/testrb
Of course, this relies upon a specific variant of Linux (in our case,
Redhat), but it could still work otherwise.
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.
Thanks,
Forrest
James Turnbull
Hash: SHA1
On 17/01/10 11:27 AM, Forrest Aldrich wrote:
> I generally don't like to rely on external packaging for certain
> software packages -- it complicates things when I want to keep up to
> date; and then, when I do want more current code, I just end up
> compiling it separately anyway.
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.
> 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?
> 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. :)
Regards
James Turnbull
- --
Author of:
* Pro Linux System Administration (http://tinyurl.com/linuxadmin)
* Pulling Strings with Puppet (http://tinyurl.com/pupbook)
* Pro Nagios 2.0 (http://tinyurl.com/pronagios)
* Hardening Linux (http://tinyurl.com/hardeninglinux)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEVAwUBS1JdASFa/lDkFHAyAQKWQQf/Q9M7hILgAkxkO0/jQoTGhpyXmqiu20ZE
z2iWlwPJV007NiU9n92s37SZJRIM5AriEg6Bb2xvLuWuooiuB0n7cf7aXnJ6vvWW
Ka+/I7rmsW48EpG1BEK10qVH0e/PjDpbvMdvOIIXgIRQEUfUnsQIMNYTcyCZx5f1
Rcieb5mfpiHgXdTSvaCfnYVKEPXx101+37gqpDSCgJZbJZuCEG0VWeMHaJX/nzAY
3XoA70p090Uygpvd6onhDoZdplYoNuAnp3iQ8U0rZSQPmkd/II8ZGh7tkWGlr2l3
flYVPZMG7uCDXOudHG8NhBb91xjcR/bmeFjtSbhngQan1bNPuXdSEQ==
=93+N
-----END PGP SIGNATURE-----
Forrest Aldrich
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