Puppet users - Mar 2011 - best way of handling source installs

Hi

I have a number of apps that need to be installed from tarballs --
simple tar -zxf; configure;  make install...
with a possible extra parameter to configure (usually prefix).

There are no prepackaged versions of these available as they are very
specialised application (security related).

I can handle these with an exec or series of execs in a define but I
wondered if there was a better way or if someone else has already dome
something along these lines.

I did try google but I could not narrow the search down enough to be
useful...

Russell

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Am 02.03.2011 00:34, schrieb russell.fulton:
> I have a number of apps that need to be installed from tarballs --
> simple tar -zxf; configure;  make install...
> with a possible extra parameter to configure (usually prefix).
> 
> There are no prepackaged versions of these available as they are very
> specialised application (security related).
> 
> I can handle these with an exec or series of execs in a define but I
> wondered if there was a better way or if someone else has already dome
> something along these lines.
Have you thought about solutions like checkinstall, which allow you to
create packages for applications like that easily?
See http://www.asic-linux.com.mx/~izto/checkinstall/


Cheers,
Daniel

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Typically I think people precompile and make custom OS packages. -Brian

On Tue, Mar 1, 2011 at 6:34 PM, russell.fulton
<russell.fulton@gmail.com>wrote:
> Hi
>
> I have a number of apps that need to be installed from tarballs --
> simple tar -zxf; configure;  make install...
> with a possible extra parameter to configure (usually prefix).
>
> There are no prepackaged versions of these available as they are very
> specialised application (security related).
>
> I can handle these with an exec or series of execs in a define but I
> wondered if there was a better way or if someone else has already dome
> something along these lines.
>
> I did try google but I could not narrow the search down enough to be
> useful...
>
> Russell
>
> --
> You received this message because you are subscribed to the Google Groups
> "Puppet Users" group.
> To post to this group, send email to puppet-users@googlegroups.com.
> To unsubscribe from this group, send email to
> puppet-users+unsubscribe@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/puppet-users?hl=en.
>
>

-- 
<http://aws.amazon.com/solutions/solution-providers/brandorr/>

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Mar 1, 2011 at 5:34 PM, russell.fulton <russell.fulton@gmail.com>
wrote:
> Hi
>
> I have a number of apps that need to be installed from tarballs --
> simple tar -zxf; configure;  make install...
> with a possible extra parameter to configure (usually prefix).
>
> There are no prepackaged versions of these available as they are very
> specialised application (security related).
For which OS?

regards/vaden@texoma.net

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Thanks for the responses :)  I''ll respond to all three here....

OS is RedHat Enterprise :(   not my first choice.
>
> Have you thought about solutions like checkinstall, which allow you to
> create packages for applications like that easily?
> Seehttp://www.asic-linux.com.mx/~izto/checkinstall/
>
This looks nice.  If it can create rpms from a standard install that
would work for me -- I would still have to get them into the local
channels which is a real pain. If  one can stash rpms somewhere on the
puppet server and have it install them rather than having yum do the
install that would be even better.

A little background:

I am managing a fairly small set of machines (network security
monitors) and some of these packages are being installed on just two
or three boxes so spending a lot of time building packages is simply
not worth it.  The apps  are also updated fairly frequently and I need
to stay on the bleeding edge :(

That is why I was looking at doing something simple.

Puppet has been really great tool for this and allows me to move apps
around between sensors or build new sensors in a really straight
forward way...

Russell



-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Mar 1, 2011 at 5:40 PM, russell.fulton <russell.fulton@gmail.com>
wrote:
> I am managing a fairly small set of machines (network security
> monitors) and some of these packages are being installed on just two
> or three boxes so spending a lot of time building packages is simply
> not worth it.  The apps  are also updated fairly frequently and I need
> to stay on the bleeding edge :(
I''m firmly of the opinion that time you invest now in automating
package creation as much as possible will repay itself very quickly
and be of immense value over time.

I think this is even more important when you have a lot of churn.
Simply being able to flip between versions of the packages quickly
will surely save an awful lot of time.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On 3/1/2011 9:32 PM, Nigel Kersten wrote:
> On Tue, Mar 1, 2011 at 5:40 PM,
russell.fulton<russell.fulton@gmail.com>  wrote:
>
>> I am managing a fairly small set of machines (network security
>> monitors) and some of these packages are being installed on just two
>> or three boxes so spending a lot of time building packages is simply
>> not worth it.  The apps  are also updated fairly frequently and I need
>> to stay on the bleeding edge :(
>
> I''m firmly of the opinion that time you invest now in automating
> package creation as much as possible will repay itself very quickly
> and be of immense value over time.
>
> I think this is even more important when you have a lot of churn.
> Simply being able to flip between versions of the packages quickly
> will surely save an awful lot of time.
What he said - really.  Three immediate benefits:

  - having the build process entirely scripted in the spec file ensures a 
consistent build process over time.

  - the first time you deploy a new version that explodes, rolling back to a set
of known good binaries is utterly trivial to do in moments.

  - as sensitive boxes (security monitors) it''s very useful to be able
to easily
verify the software binaries, using either the local rpm database or a copy of 
the original rpm.  for a little extra, you can pgp sign your rpm files too.


-- 
Frank Sweetser fs at wpi.edu  |  For every problem, there is a solution that
WPI Senior Network Engineer   |  is simple, elegant, and wrong. - HL Mencken
     GPG fingerprint = 6174 1257 129E 0D21 D8D4  E8A3 8E39 29E3 E2E8 8CEC

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

> > I think this is even more important when you have a lot of churn.
> > Simply being able to flip between versions of the packages quickly
> > will surely save an awful lot of time.
>
> What he said - really.  Three immediate benefits:
>
>   - having the build process entirely scripted in the spec file ensures a
> consistent build process over time.
>
>   - the first time you deploy a new version that explodes, rolling back to
a set
> of known good binaries is utterly trivial to do in moments.
>
>   - as sensitive boxes (security monitors) it''s very useful to be
able to easily
> verify the software binaries, using either the local rpm database or a copy
of
> the original rpm.  for a little extra, you can pgp sign your rpm files too.
>
OK, OK :)

I know this and agree with it in principle.  It is just that at the
moment I am extremely hard
pressed and really don''t have the time to work my way through figuring
out how to build rpms
from scratch.  The package Daniel pointed out looks very promising in
this respect adn I will certainly
look at it.

I''ll repeat the question from my previous post:  Is there a straight
forward way to have a local rpm
repository on the puppet server rather than relying on yum and the RHE
channels?

Thanks, Russell

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

russell.fulton writes:
 > I know this and agree with it in principle.  It is just that at the
 > moment I am extremely hard
 > pressed and really don''t have the time to work my way through
figuring
 > out how to build rpms
 > from scratch.  The package Daniel pointed out looks very promising in
 > this respect adn I will certainly
 > look at it.
 > 
 > I''ll repeat the question from my previous post:  Is there a
straight
 > forward way to have a local rpm
 > repository on the puppet server rather than relying on yum and the RHE
 > channels?

You can just source packages from an HTTP server rather than implicitly
from configured package repositories.

package { "foo":
    source => "http://my.web.server/packages/foo-1.0-1.i386.rpm",
    ensure => installed,
}

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Tue, Mar 1, 2011 at 8:13 PM, russell.fulton <russell.fulton@gmail.com>
wrote:
>
> I''ll repeat the question from my previous post:  Is there a
straight
> forward way to have a local rpm
> repository on the puppet server rather than relying on yum and the RHE
> channels?
Check out mrepo if you want to mirror another repository and
createrepo if you want to create your own yum repository.

If you''re already running Puppet inside of Apache, you''ll just
need to
setup a virtual host to serve up the directory containing the packages
and yum metadata.

It''s actually quite straightforward.  Most of the time is going to
come from reading about how to use mrepo.

createrepo *.rpm works great if you just want to expose a directory as
a yum repo.  Super straight forward.

-Jeff

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

russell.fulton wrote:
> I''ll repeat the question from my previous post:  Is there a
straight
> forward way to have a local rpm repository on the puppet server
> rather than relying on yum and the RHE channels?
It''s trivial to run createrepo /path/to/rpms to create the yum
metadata.  You can then serve that up via http or even via a file://
URI if you like (and your clients can access it).

Or are you trying to get puppet to act as the repository?  If so, I
don''t think there is a sane way to do this.

-- 
Todd        OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
You cannot propel yourself forward by patting yourself on the back.

>>> I am managing a fairly small set of machines (network security
>>> monitors) and some of these packages are being installed on just
two
>>> or three boxes so spending a lot of time building packages is
simply
>>> not worth it. The apps are also updated fairly frequently and I
need
>>> to stay on the bleeding edge :(
>>
>> I''m firmly of the opinion that time you invest now in
automating
>> package creation as much as possible will repay itself very quickly
>> and be of immense value over time.
>>
>> I think this is even more important when you have a lot of churn.
>> Simply being able to flip between versions of the packages quickly
>> will surely save an awful lot of time.
>
> What he said - really. Three immediate benefits:
>
> - having the build process entirely scripted in the spec file ensures a
> consistent build process over time.
>
> - the first time you deploy a new version that explodes, rolling back to
> a set of known good binaries is utterly trivial to do in moments.
>
> - as sensitive boxes (security monitors) it''s very useful to be
able to
> easily verify the software binaries, using either the local rpm database
> or a copy of the original rpm. for a little extra, you can pgp sign your
> rpm files too.
I''ll throw out what is likely an unpopular opinion in this forum, which
is that package-building is not *always* a win.  Russell and I both use 
puppet to manage network security sensors which have some mildly unusual 
properties:

1) The packages being built are sometimes unusually complex to package, 
have poorly designed build processes, and small/closed user-communities. 
  I have one package that builds kernel-modules and writes outside of 
the build-directory during make, and that nobody outside of the security 
community uses.  Every shop has a few packages like this that would 
require a solid week of time to package properly, plus ongoing 
maintenance to track upstream changes.
2) Core libraries (specifically libpcap) often have to be rebuilt.
3) The number of boxes under management can be very small.  I monitor a 
50k node network with 3 boxes.
4) The software builds on these boxes are extremely stable.  Nobody is 
flipping back and forth between versions on a regular basis.

So (1) and (2) make the cost of packaging higher than most shops for 
security teams, and (2) and (3) make the benefits lower.  I have been 
packaging my sensor software for about 18-months, and had high-hopes 
that it would eventually save me time but it''s always worse than a 
source deployment by a large margin.  I accept the overhead mostly 
because it improves my time-to-recover from a serious problem, and there 
are other benefits.  It''s time invested in maturity, not a
time-savings,
though.

I use mock for my build process, and createrepo to manage the rpms.  The 
infrastructure isn''t actually bad at all.  The time comes in writing
and
rewriting spec-files.  You can sometimes poach work from CentOS of 
Fedora, but some sensor-software has simply never been packaged and you 
have to start from scratch.

So Russell, the short of it is that Puppet doesn''t provide much to help
you manage source-installed software.  You can apply puppet''s features 
to other software-management tools to roll something yourself, you can 
package the software, or you can just keep building from source.  The 
last option is likely to be the least time-consuming IMO.  If you want 
details on my packaging setup, feel free to reach out to me offline.

Cheers,
Mike Lococo

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

On Wed, Mar 2, 2011 at 7:18 AM, Mike Lococo <mikelococo@gmail.com> wrote:
> So Russell, the short of it is that Puppet doesn''t provide much to
help you
> manage source-installed software.  You can apply puppet''s features
to other
> software-management tools to roll something yourself, you can package the
> software, or you can just keep building from source.  The last option is
> likely to be the least time-consuming IMO.  If you want details on my
> packaging setup, feel free to reach out to me offline.
We''ve tossed around in the past the idea of a tarball
"package"
provider, which sounds like it might suit your needs?

If we can come up with a reasonable rough heuristic to work out how to
determine if a tarball package is installed, and whether it needs to
be replaced by a newer version, I''m totally willing to hack this up,
as it''s really quite trivial code.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Firstly thanks to all of you who have chipped in on this thread.
Largely it has confirmed what I already thought.  Mike has explained
the problem well we have very similar set ups and requirements.

When we started on the puppet project 6 months ago there were
two of us -- my partner was familiar with packaging systems and
yum repositories so we decided to go with RHE.  He has now been
moved out of technical stuff altogether and I have been left
struggling
to keep things moving forward.  Hence the scramble.

On Mar 3, 7:54 am, Nigel Kersten <ni...@puppetlabs.com> wrote:
> We''ve tossed around in the past the idea of a tarball
"package"
> provider, which sounds like it might suit your needs?
>
> If we can come up with a reasonable rough heuristic to work out how to
> determine if a tarball package is installed, and whether it needs to
> be replaced by a newer version, I''m totally willing to hack this
up,
> as it''s really quite trivial code.
How about adding a check option to package which allows one to
specify a file to be checked. Another option for packages that have
version files would be to have a version option that took a File and
perhaps an RE that would extract the version into something that
can be compared...

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

on 10:54 Wed 02 Mar, Nigel Kersten (nigel@puppetlabs.com)
wrote:
> On Wed, Mar 2, 2011 at 7:18 AM, Mike Lococo <mikelococo@gmail.com>
wrote:
> 
> > So Russell, the short of it is that Puppet doesn''t provide
much to help you
> > manage source-installed software.  You can apply puppet''s
features to other
> > software-management tools to roll something yourself, you can package
the
> > software, or you can just keep building from source.  The last option
is
> > likely to be the least time-consuming IMO.  If you want details on my
> > packaging setup, feel free to reach out to me offline.
> 
> We''ve tossed around in the past the idea of a tarball
"package"
> provider, which sounds like it might suit your needs?
> 
> If we can come up with a reasonable rough heuristic to work out how to
> determine if a tarball package is installed, and whether it needs to
> be replaced by a newer version, I''m totally willing to hack this
up,
> as it''s really quite trivial code.
While you''re considering providers, another case we encounter fairly
frequently are just general crap ISV or HW vendor-provided blob shell
installers.  Usually a self-unpacking shell script, which may itself
include various internal packaging formats (tarballs, RPMs, etc.).
Dell, VMWare, Oracle, and others.

In the case of these, there''s /ususally/ an unattended install options
(generally driven by an options file), otherwise there are the various
frustrations of EULA approvals, etc.

I haven''t put deep thought into a puppet solution, but the generalized
method would be for the installer script / binary / ISO image, a
configuration script (or arbitrary shell arguments and ancillary file
list(s)), and some arbitrary post-installation test providing some level
of assurance that what you wanted to have installed was actually
installed.

Real packaging tools make this so much more sensible to manage.
Grumble.

-- 
Dr. Ed Morbius, Chief Scientist /            |
  Robot Wrangler / Staff Psychologist        | When you seek unlimited power
Krell Power Systems Unlimited                |                  Go to Krell!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Dr. Ed Morbius writes:
 > While you''re considering providers, another case we encounter
fairly
 > frequently are just general crap ISV or HW vendor-provided blob shell
 > installers.  Usually a self-unpacking shell script, which may itself
 > include various internal packaging formats (tarballs, RPMs, etc.).
 > Dell, VMWare, Oracle, and others.

What we have done is to turn such blob installers into OS packages for
installation via Puppet, rather than try to manage the direct
installation of the blob installer via a convoluted set of execs and
such.  Overall it is still much easier to manage OS package
installation, even with the overhead of having to create the custom
package.  So as one example, we get the blob into the Mock RPM build
environment, unpack it, feed canned input to its configuration script,
and then wrap up the finished file tree as an RPM, then get that RPM
installed on the hosts that need it.

 > I haven''t put deep thought into a puppet solution, but the
generalized
 > method would be for the installer script / binary / ISO image, a
 > configuration script (or arbitrary shell arguments and ancillary file
 > list(s)), and some arbitrary post-installation test providing some level
 > of assurance that what you wanted to have installed was actually
 > installed.

The thing is, RPM or DEB packages already do those things for you, so
why go to so much effort to duplicate that functionality outside your
package system?

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

on 15:20 Wed 02 Mar, Steven VanDevender (stevev@uoregon.edu)
wrote:
> Dr. Ed Morbius writes:
>  > While you''re considering providers, another case we
encounter fairly
>  > frequently are just general crap ISV or HW vendor-provided blob shell
>  > installers.  Usually a self-unpacking shell script, which may itself
>  > include various internal packaging formats (tarballs, RPMs, etc.).
>  > Dell, VMWare, Oracle, and others.
> 
> What we have done is to turn such blob installers into OS packages for
> installation via Puppet, rather than try to manage the direct
> installation of the blob installer via a convoluted set of execs and
> such.  Overall it is still much easier to manage OS package
> installation, even with the overhead of having to create the custom
> package.  So as one example, we get the blob into the Mock RPM build
> environment, unpack it, feed canned input to its configuration script,
> and then wrap up the finished file tree as an RPM, then get that RPM
> installed on the hosts that need it.
In the specific pathological case I''m thinking of (Dell''s
iSCSI
management tools), the net end result is rather poorly defined and spans
a significant chunk of the filesystem -- mostly under /opt/dell, but
some stray (and largely undocumented) bits, mostly under /etc, with bits
under /usr/src.  I''d probably have to compare filesystem snapshots to
identify these cleanly.
 
>  > I haven''t put deep thought into a puppet solution, but the
generalized
>  > method would be for the installer script / binary / ISO image, a
>  > configuration script (or arbitrary shell arguments and ancillary file
>  > list(s)), and some arbitrary post-installation test providing some
level
>  > of assurance that what you wanted to have installed was actually
>  > installed.
> 
> The thing is, RPM or DEB packages already do those things for you, so
> why go to so much effort to duplicate that functionality outside your
> package system?
Because there''s stuff that isn''t packaged in RPM/DEB, and
there aren''t
enough hours in the day.

I''m not convinced this is a /good/ idea.  It is, however, an idea.
Figure folks can kick it around (or ignore it) and see what interest or
other suggestions there are.

-- 
Dr. Ed Morbius, Chief Scientist /            |
  Robot Wrangler / Staff Psychologist        | When you seek unlimited power
Krell Power Systems Unlimited                |                  Go to Krell!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

Dr. Ed Morbius writes:
 > In the specific pathological case I''m thinking of
(Dell''s iSCSI
 > management tools), the net end result is rather poorly defined and spans
 > a significant chunk of the filesystem -- mostly under /opt/dell, but
 > some stray (and largely undocumented) bits, mostly under /etc, with bits
 > under /usr/src.  I''d probably have to compare filesystem
snapshots to
 > identify these cleanly.

At least the Mock RPM-building tool handles this for you; when building
packages it uses a chrooted environment and tracks what files get put
where so they can be rolled up into a package.

 > > The thing is, RPM or DEB packages already do those things for you, so
 > > why go to so much effort to duplicate that functionality outside your
 > > package system?
 > 
 > Because there''s stuff that isn''t packaged in RPM/DEB,
and there aren''t
 > enough hours in the day.
 > 
 > I''m not convinced this is a /good/ idea.  It is, however, an
idea.
 > Figure folks can kick it around (or ignore it) and see what interest or
 > other suggestions there are.

Seriously, package systems are designed to handle dependency management,
*un*installation, and upgrading in ways that are extremely hard to deal
with if you insist on doing traditional source-based (or your vendor
insists on doing blob-based) installation methods.  Yes, you have to
create and learn how to use a package-building system, although you
might be surprised how easy it is to build custom packages once you''re
over the initial effort of setting up the package build system.  But you
get far better and more consistent results if you do.  It''s an
investment that will pay off in the future.

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.

on 15:38 Wed 02 Mar, Steven VanDevender (stevev@uoregon.edu)
wrote:
> Dr. Ed Morbius writes:
>  > In the specific pathological case I''m thinking of
(Dell''s iSCSI
>  > management tools), the net end result is rather poorly defined and
spans
>  > a significant chunk of the filesystem -- mostly under /opt/dell, but
>  > some stray (and largely undocumented) bits, mostly under /etc, with
bits
>  > under /usr/src.  I''d probably have to compare filesystem
snapshots to
>  > identify these cleanly.
> 
> At least the Mock RPM-building tool handles this for you; when building
> packages it uses a chrooted environment and tracks what files get put
> where so they can be rolled up into a package.
That could be useful, though I''d have to play with it to see if the
vendors'' scripts would run as advertised within a chroot.
>  > > The thing is, RPM or DEB packages already do those things for
you, so
>  > > why go to so much effort to duplicate that functionality outside
your
>  > > package system?
>  > 
>  > Because there''s stuff that isn''t packaged in
RPM/DEB, and there aren''t
>  > enough hours in the day.
>  > 
>  > I''m not convinced this is a /good/ idea.  It is, however, an
idea.
>  > Figure folks can kick it around (or ignore it) and see what interest
or
>  > other suggestions there are.
> 
> Seriously, package systems are designed to handle dependency management,
> *un*installation, and upgrading in ways that are extremely hard to deal
> with if you insist on doing traditional source-based (or your vendor
> insists on doing blob-based) installation methods.  
Please believe you''ve got absolutely *NO* convincing to do for me on
any
of those scores.

Somewhat ironically, the Dell iSCSI shell blob contains within it
several RPMs of varying spec-conformance.

-- 
Dr. Ed Morbius, Chief Scientist /            |
  Robot Wrangler / Staff Psychologist        | When you seek unlimited power
Krell Power Systems Unlimited                |                  Go to Krell!

-- 
You received this message because you are subscribed to the Google Groups
"Puppet Users" group.
To post to this group, send email to puppet-users@googlegroups.com.
To unsubscribe from this group, send email to
puppet-users+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/puppet-users?hl=en.