Puppet users - Apr 2007 - Installing puppetmasterd, puppetd as services under Red Hat, CentOS

Hi,

Since I''ve installed ruby and ruby-gems from source, then installed
facter and puppet as gems, I don''t get the usual startup scripts
shipped
with RPMs.

Rebuilding the ruby RPM is painful, mostly because Red Hat (and pretty
much every vendor) have this tendency to include random files and patch
the living daylights out of a perfectly good source package so that
converting the ruby 1.6.8 spec file (RHEL3) to repackage ruby 1.8.x is
prohibitively frustrating. The joys of open source vendor lock-in...

Installing from source works reasonably well (despite it not scaling)
but leads to problems like

  /usr/bin/env: ruby: No such file or directory

when one naively tries to use

/usr/local/lib/ruby/gems/1.8/gems/puppet-0.22.3/conf/redhat/client.init
/usr/local/lib/ruby/gems/1.8/gems/puppet-0.22.3/conf/redhat/server.init

:(

Aside: --port=${PUPPET_PORT} makes puppetd gag; that should probably be
fixed.

I''ve worked around this by changing

  #!/usr/bin/env ruby

to

  #!/usr/local/bin/ruby

in puppetmasterd, puppetd, and ralsh, but something tells me this is not
the right way to fix this problem. I tried adding /usr/local/bin to PATH
in the init.d scripts to no effect.

FWIW, when I initially read through the site docs I couldn''t find an
explanation of the right way to install the puppet client and server as
services so I made something up based on random files I found in Trac
(something involving cron.hourly.) I''ve mostly fixed the init scripts
and the daemons but I''m still not convinced that I''m doing
this right -
mainly because it''s taken a lot of work... :)

Thoughts?

-- Bob

> Rebuilding the ruby RPM is painful, mostly because Red Hat 
> (and pretty much every vendor) have this tendency to include 
> random files and patch the living daylights out of a 
> perfectly good source package so that converting the ruby 
> 1.6.8 spec file (RHEL3) to repackage ruby 1.8.x is 
> prohibitively frustrating. The joys of open source vendor lock-in...
I used the FC6 src rpm when I built RHEL4 x86_64 packages and didn''t
have to edit the spec file at all from memory.
> FWIW, when I initially read through the site docs I couldn''t 
> find an explanation of the right way to install the puppet 
> client and server as services so I made something up based on 
> random files I found in Trac (something involving 
> cron.hourly.) I''ve mostly fixed the init scripts and the 
> daemons but I''m still not convinced that I''m doing this
right
> - mainly because it''s taken a lot of work... :)
Are you using the rpms for puppet and puppet-server?  It should just be
a matter of installing them and then starting the puppet/puppetmaster
like you would with any other service (service puppet start).

James

*********************************************************************************
Important Note
This email (including any attachments) contains information which is 
confidential and may be subject to legal privilege.  If you are not 
the intended recipient you must not use, distribute or copy this 
email.  If you have received this email in error please notify the 
sender immediately and delete this email. Any views expressed in this 
email are not necessarily the views of AXA-Tech Australia.   Thank you.
**********************************************************************************

> > FWIW, when I initially read through the site docs I 
> couldn''t find an 
> > explanation of the right way to install the puppet client 
> and server 
> > as services so I made something up based on random files I found in 
> > Trac (something involving
> > cron.hourly.) I''ve mostly fixed the init scripts and the 
> daemons but 
> > I''m still not convinced that I''m doing this right
> > - mainly because it''s taken a lot of work... :)
> 
> Are you using the rpms for puppet and puppet-server?  It 
> should just be a matter of installing them and then starting 
> the puppet/puppetmaster like you would with any other service 
> (service puppet start).
Sorry, missed the bit when you said you''d installed using gems.

James

*********************************************************************************
Important Note
This email (including any attachments) contains information which is 
confidential and may be subject to legal privilege.  If you are not 
the intended recipient you must not use, distribute or copy this 
email.  If you have received this email in error please notify the 
sender immediately and delete this email. Any views expressed in this 
email are not necessarily the views of AXA-Tech Australia.   Thank you.
**********************************************************************************

Hi,

[pardon the rant; it''s late, I''ve had a few beers, and digging
into the
innards of Red Hat packages brings out the worst in me]

HARRIS Jimmy (AXA-Tech-AU) wrote:
>> Rebuilding the ruby RPM is painful, mostly because Red Hat 
>> (and pretty much every vendor) have this tendency to include 
>> random files and patch the living daylights out of a 
>> perfectly good source package so that converting the ruby 
>> 1.6.8 spec file (RHEL3) to repackage ruby 1.8.x is 
>> prohibitively frustrating. The joys of open source vendor lock-in...
> 
> I used the FC6 src rpm when I built RHEL4 x86_64 packages and
didn''t
> have to edit the spec file at all from memory.
I just tried rebuilding the CentOS 5 ruby SRPM on a CentOS 3 box
resulting in typical Red Hat rebuild hell. For some inexplicable reason,
ruby "needs" libX11-devel which apparently changes name version to
version (this is easy to change to XFree86-devel in CentOS 3 and to
xorg-x11-devel in CentOS 4) and a newer version of autoconf, as if
Ruby''s supplied ''configure'' script just
isn''t good enough.

I understand what the Red Hat build team is doing; regardless, I believe
they need a sound beating. Luckily for them, the Blackboard developers
are top of my list, followed by the Tomcat developers -- it''s a good
thing I only believe in cartoon violence... :/

What I need is a spec file that does

  tar xf ruby-1.8.x.tar.gz
  cd ruby-1.8.x
  ./configure && make && make install

and absolutely nothing else (unit tests would be nice but I won''t
quibble.) No X11, no emacs mode, no tcl/Tk bindings(!), no docs
collected from hither and yon, just the @#$%! interpreter and the
standard @#$%! utilities that come with it.

Note that updating the CentOS 3 systems is a nonstarter; they run just
fine and I have zero motivation to move Oracle for the convenience of
the Red Hat build team. They''ll get upgraded once someone puts a gun to
my head to install 10g and not a second sooner. :)

Anyway, the trick is to tweak the puppet spec file to look for a recent
ruby interpreter instead of the unbuildable ruby RPM (OT: Maybe one day
they''ll update rpm.org with the docs at
http://docs.fedoraproject.org/drafts/rpm-guide-en/ instead of keeping
the stale "Maximum RPM" docs out as bait for the unwary.)
I''ve got my
work cut out for me...

-- Bob

On Mon, 2007-04-30 at 00:39 -0500, Bob Apthorpe wrote:
> Rebuilding the ruby RPM is painful, mostly because Red Hat (and pretty
> much every vendor) have this tendency to include random files and patch
> the living daylights out of a perfectly good source package so that
> converting the ruby 1.6.8 spec file (RHEL3) to repackage ruby 1.8.x is
> prohibitively frustrating. The joys of open source vendor lock-in...
Have you tried going the other way ? Start with the FC6 or RHEL5 ruby
specfile and hack it into shape to build on RHEL3. Haven''t tried it
myself though ...

David

Hi,

David Lutterkort wrote:
> On Mon, 2007-04-30 at 00:39 -0500, Bob Apthorpe wrote:
>> Rebuilding the ruby RPM is painful, mostly because Red Hat (and pretty
>> much every vendor) have this tendency to include random files and patch
>> the living daylights out of a perfectly good source package so that
>> converting the ruby 1.6.8 spec file (RHEL3) to repackage ruby 1.8.x is
>> prohibitively frustrating. The joys of open source vendor lock-in...
> 
> Have you tried going the other way ? Start with the FC6 or RHEL5 ruby
> specfile and hack it into shape to build on RHEL3. Haven''t tried
it
> myself though ...
Yeah; I had a little rant about it last night. Essentially, the RHEL5
SRPM still wants a bunch of irrelevant junk (X11 libraries, etc.) so it
can build emacs mode, tcl/Tk bindings, and a lot of other nonsense. I
suspect I''m going to have to build a spec file from scratch if I want a
simple ruby RPM.

-- Bob

> What I need is a spec file that does
> 
>   tar xf ruby-1.8.x.tar.gz
>   cd ruby-1.8.x
>   ./configure && make && make install
> 
> and absolutely nothing else (unit tests would be nice but I won''t
> quibble.) No X11, no emacs mode, no tcl/Tk bindings(!), no 
> docs collected from hither and yon, just the @#$%! 
> interpreter and the standard @#$%! utilities that come with it.
Have you tried using CheckInstall
(http://asic-linux.com.mx/~izto/checkinstall/)?  I discovered it last
week when I was installing FastCGI for a Rails installation.

It runs "make install" for you and creates an rpm of the resulting
files.  Seemed to work well with FastCGI but I haven''t tried it on
anything more complex yet.

James

*********************************************************************************
Important Note
This email (including any attachments) contains information which is 
confidential and may be subject to legal privilege.  If you are not 
the intended recipient you must not use, distribute or copy this 
email.  If you have received this email in error please notify the 
sender immediately and delete this email. Any views expressed in this 
email are not necessarily the views of AXA-Tech Australia.   Thank you.
**********************************************************************************