On 09/01/2010 12:36 PM, Leam Hall wrote:
If there's consensus on the latter, that's fine. I have not
heard that
though, nor have I really heard anything that convinces me /opt and
separate filesystems are not the way to go. If you can convince me,
great! It means you've been able to help me learn more.
I've used Unix since 1991 and Linux since 1992 and I'm telling you,
that's not what /opt is for.
/opt is analogous /usr/local, but with each application -- or in some
cases, groups of applications -- in its/their own directory. Both /opt
/and /usr/local are for your own in-house builds of apps -- we use it
extensively on our servers, because we have a lot of in-house software
that we maintain.
If you're building and maintaining your own (say) Apache, it makes
perfect sense for you to put it in /opt. But consider: how would you
like it if your httpd binary -- in /opt -- was overwritten by "yum
update"? I'm guessing you would not be happy with that, because nobody
would be happy with that.
I'm a survivor of various filesystem standards. (Did you know that
binaries for various Net servers used to live in /etc ?) So I'm here to
tell you know, the current FSS is fine, fine business. That's not to
say it couldn't use some improvement -- for instance, I'd love to have
an easy way to change the java symlinks in /etc/alternatives with some
sort of ncurses tool. (Or the same for any large application suite for
which we have /etc/alternatives.) But I know that Internet servers
provided by the distribution live in /usr/sbin, and it's been that way
since before we stopped putting "in." in Net server binary filenames.
The other point I'm hoping to get across is that just because a
Fedora
rule has been made doesn't mean it's the best answer for mixed
environments. Fedora rules so far seem pretty desktop centric and
RH-Linux myopic.
I disagree, and point out that the Linux FSS isn't just a RH thing, it's
used all across Linux distributions. Also, I should mention that Fedora
itself is community-governed, so if you want to depart from the Linux
FSS, you only have to convince a certain X number of people that it
should be changed...but count me out of that, I think both /opt and
/usr/local need to remain off-limits to the distribution.
Most of the SysAdmins I know work with 3-5 different
OS's, 2-4 versions of each, a few applicance OS versions, and take care
of applications 'cause the developers don't have a clue.
This is not only unfair to the developers, it's also the way _we_ used
to do things, maybe around 8 years ago. The world has moved on: if
you're not using (say) Fedora's httpd on your Fedora servers, I have to
wonder what it is that you don't like about Fedora's Apache? I use it
on two of my personal servers that are running Fedora, and I have no
problem with them.
Back in the bad-ol' days, if a distro-provided package didn't do its job
right, we'd grab the sources and build our own version, since that was a
lot easier to keep up with all the issues we were tracking. Nowadays,
it's a simple matter (in Fedora) to grab the SRPM and come up with a
change that can be passed upstream to whomever is interested in it.
The simpler we
can make that job for them the more valuable Fedora Server would be, to me.
On our network, we (at work) make all changes in SRPMS, and keep the
resulting binary rpms in our own repos, to update our 200+ servers.
Though they are a mix of CentOS 5.5 and RH 7.3 servers, the principle is
the same as Fedora, albeit with different build host guests running in
kvm virts. I finally took the time to learn how to manage SRPMS (since
the operations guys had done this long ago), and found the learning
curve really wasn't as steep as I thought it would be.
Even to look as sources, I use Fedora's "yumdownloader --source X"
feature, where "X" is the package name. That way, I not only get the
pristine tgz of the original sources, but I can see what patches folks
with the Fedora Project have added.
Finally, I should mention that there's another advantage to using an
SRPM for a vital server application: so far, I haven't found an SRPM
that won't build working binaries for both Fedora _and_ CentOS 5.5.
This is a beautiful thing for packages that aren't (yet?) in CentOS, but
can be found in Fedora.
Take care, and happy Thursday. :)
-Scott
CTO,
Sonic.net, Inc.