[Date Prev][Date Next]
Re: Goofy RedHat Problem
On Wed, 7 Jul 2004, Quanah Gibson-Mount wrote:
I think you have different support people than we generally deal with.
Not just O/S, but application support people, for instance, who say
things like "Requires Vx.y of O/S z to run". We have had and continue to
have problems because support people do not recognize this distinction.
And, in fact, the distinction is somewhat arbitrary to begin with, since
an operating system is fundamentally a collection of applications. But
that's a much more abstract type of discussion.
Yes, we run into that issue as well (especially with anything dealing with
Oracle). However, what we do do, is run different applications on different
servers (i.e., we have dedicated directory servers, dedicated www servers,
dedicated cgi servers, etc etc). The majority of our infrastructure
applications are opensource, which provide much more flexibility than the
various vendors of our adminstrative application systems, which are
definitely more hobbled/constrained. (although that gets a bit OT for list).
Yeah, I think I'll drop this part to avoid the off-topicness. Let's just
say I can't avoid commercial vendors in my environment as much as I'd
like, since I don't make all the decisions. :)
You shouldn't. It's just going to be an extra pain for you (and for
everyone) when the distros don't keep up, which is why I'm complaining
about them not doing so. I know it can be done, because I have at least
one example of a distribution that is not far behind (Gentoo). If they
can have 2.1.26, then Debian and Redhat can as well. (Particularly
Redhat, which is actually /charging/ you for this.)
I think you may have misinterpreted my intent here. I'm not saying you
shouldn't compile things when they're out of date. I'm saying that they
should never go out of date to the extent that you have to compile them.
(And that, if they are, maybe you need to bug your vendor or switch
Perhaps, but I've yet to see a distro distribute OpenLDAP in the particular
way *I* need to compile it. That's one of the fundamental problems with
distro's even attempting to distribute applications. They are most likely
to compile for the broadest set of consumers, but if you have particular
needs (SASL/GSSAPI for example), the odds that the distro is going to
compile it with that support are quite low.
I'm going to sound like a broken record (or some kind of fanatic) here,
but the Gentoo distribution lets you set the following flags for OpenLDAP:
berkdb, crypt, debug, gdbm, ipv6, kerberos, odbc, perl, readline, samba,
sasl, slp, ssl, tcpd. Setting those pretty much does the things you'd
expect. It is able to do this because it's downloading and compiling
things on your behalf, on the fly, and all you really have to know to do
it is to edit a text file and add, say, 'ssl' to a list of keywords
(called USE flags) you care about. It's also possible to do a custom build
of OpenLDAP with particularly bizarre options and use inject to tell other
packages to build based on it, instead of the stock OpenLDAP build.
Just look at the packages it takes to build up OpenLDAP, and the variety
of options *each* package has. Some even have interdependencies (Look at
Heimdal wanting OpenLDAP libraries wanting Heimdal libraries in some
This is the kind of thing that makes me /want/ to have someone else worry
about how to compile the blasted things. It's not that I can't figure them
out, it's just that I theoretically have better things to do, like rant
about inadequate distributions on mailing lists.
Not only that, how do *I* know that the distro is even using the proper
set of libraries? There are known issues with MIT Kerberos (actively
being fixed, thankfully) that make it unusable (without a bit of work)
in a threaded environment. Unless a distribution is willing to compile
every application with every option (bloat), it is likely that their
software distribution will not meet someone's needs.
Well, of course. Even with something like Gentoo, there are going to be
esoteric cases that are unaccounted for. That's fine, and in those cases
you should compile. My definition of esoteric, however, does not contain
"a release from sometime in the last two years". There are certain minimum
standards that distributions ought to be held to if they're going to have
any utility at all. I expect that a recent version of OpenLDAP compiled
with SSL and the BDB backend would satisfy the needs of a very large
percentage of the userbase.
As for what you know, a distribution that does not tell you what libraries
are used to compile your software is not a distribution that should be
used by anyone, anywhere, at any time, for any purpose.
I'm arguing that it doesn't have to be this way. Why should the skill
"administrate service X" be eternally linked with the skill "compile the
software that runs service X from source"? The only reason that it is
right now is that packages go out of date too quickly, which is exactly
what I'm saying shouldn't happen.
See above. I'll also add that understanding how the software compiles and
works gives you a great understanding of what you are working with, which I
think is essential for the proper administration of service X.
I'm not sure that's really true. Knowing how to compile the software from
source certainly helps, because you're familiar with the maximum
capabilities as well as the ones you're actually putting in, but given
that most people are simply running something like ./configure
--with-special-sauce --with-jumping-peppers --without-frumple && make &&
make test && make install, I'm not sure they're really gaining any deep
knowledge of how the software is put together. (Unless they are reading
every line of output from make. Hands up, everyone who does that...)
See, I think there is a certain class of users which would be quite
comfortable with the maintenance and configuration of a directory server,
but who are not quite up the task of figuring out why make test is
complaining about a shared library exporting a hidden symbol. That's the
class of users which is served by pre- or auto-compiled versions of
Database Applications Developer
Information Technology Services - Harvard Law School
Omnia Mutantur, Nihil Interit