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.