Re: Resources/Documentation for Redhat 9 and LDAP Auth

["Brian" <brianb@sboss.com>]

Full disclosure:  I do not work for, own stock in, or benefit in any way
(financially or otherwise) from Redhat.

Brian K. Jones said:

> I am completely at a loss for words in response to a statement that
> alleges that someone who has built their own RPMs finds the prospect of
> tarballs 'messy'. I have yet to see a messier more unnecessarily
> convoluted method of building software than building your own rpm,
> which, by the way, requires that you get a source distribution anyway,
> which also means you'll probably deal with tarballs at some point.
> ???

It's hardly silly for a user to build an RPM if they use an RPM based
system.  RPM's can keep software packages from overwriting or conflicting
with one another as well as letting you know exactly what files belong to
what package.  If you admin more than one or two machines, having the
absolute exact same binaries, configs, and libraries is essential.  The
ability to roll out upgrades is made much simpler by package management as
is the ability to back out bad upgrades.  The concept of interchangable
parts is as relevant here as it is in the manufacturing world.

Building RPM's is not difficult and I recommend anyone who wants to learn
to build RPM's to pick up the Redhat Linux RPM guide (ISBN #0764549650). 
I find it very useful and better than the docs on rpm.org.

> I just don't view a production deployment of something that may hold
> sensitive data and be given rather enormous responsibility as something
> that should be left to 'default' configurations and builds as supplied
> by a company or entity who has no knowledge of your environment or what
> your needs are.

And I don't understand why people think that an 'entity' who patches and
maintains software for use in an enterprise environment has no clue about
how to package software that not only keeps the files in accordance to the
LSB/FHS but also sometimes includes performance fixes that may or may not
have made it to the upstream providers?

If one gets a source RPM and inspects the spec file, one can see all
options used to build a package, where the files are stored, and what
scripts (if any) are executed.  If it doesn't meet your needs, it's
trivial to change (usually).

I've seen more users misconfigure their applications correctly because
they only knew how to type ./configure; make; make install more often than
I've seen someone have problems as a result of installing a *well-built*
RPM.

YMMV.

--
Brian