|
> > ${PREFIX} should always be /usr/local, unless the --prefix argument is > Secondly, could you explain why you think /etc/tn5250rc seems wrong to > you? I usually compile with these flags: > > ./configure --prefix=/usr --sysconfdir=/etc --localstatedir=/var > > This puts stuff where I like (and it might even follow the linux standards > base - but maybe not). In my world of 97% iSeries I don't meet any other > unix admins. So I'm wondering what other people do and why. > I like to have the programs that come with the operating system installed in / or /usr. The corresponding config files in /etc. The programs that I install later I like to have in /usr/local and their config files in /usr/local/etc. So, the next question is "why?" This is hard to explain, so please bear with me. FreeBSD is a little different from Linux, so I'll first explain the difference. Linux is just a kernel. When you install RedHat or Debian or whichever, they come with the Linux kernel and their own separate bundled packages. FreeBSD, by contrast, is the whole operating system. It includes the kernel, but also includes all of the base utilities that the system needs to run. You never just upgrade the kernel, or upgrade the userland, you always upgrade them together.... they're written and maintained and tested for compatability by the same people at the same time. This way you'd never, for example, upgrade your copy of /bin/sh, and break the /etc/rc script. If they upgraded /bin/sh, they'd test everything, etc. That's the FreeBSD way. If I wanted to, say, install a newer version of perl than the one that comes with the operating system, I'd install it in /usr/local. Now my scripts that need the newer version can run /usr/local/bin/perl and the system scripts that rely on perl will still use /usr/bin/perl. Maximum compatibility, maximum stablility. Call it paranoid if you want... So, using this system I've noticed some other benefits. 1) If I want to wipe out and reinstall the operating system (although that's very, very rare) I can simply save /usr/local/etc and I'll have the same configs for all my local packages, without the operating system configs. This doesn't happen very often, but when it does it sure is nice. 2) I can lock down /bin, /sbin, /etc, /usr/bin, /usr/sbin,etc to guard against viruses and/or hackers. (i.e. chflags schg) I can set things up so that I have to be in single-user mode to unlock these files. This makes it very difficult for a hacker to do much if my system is compromised. Sure, he can mess with local packages, but not with the OS, which is nice. And I can still install/remove local packages, they aren't affected. 3) When backing up/restoring I always have a clear picture of what is part of the operating system (and thus will be replaced when I reinstall the system after a failure) and what is something that I've changed/added. This can save hours. 4) If I want to have more than one machine with different hardware configurations but the same local packages, I can just NFS mount /usr/local from another machine. 5) I don't ever have to worry about a package I install wiping out or changing a system-required file. When I upgrade the OS, I don't have to worry about it wiping out a local package, since they always use different directories, there is no conflict. I'm sure I could come up with more, but I think you get the idea. I imagine that there are other ways of dealing with any/all of these problems/issues, but this way works very well for me. I've also found that even on Linux systems where "everything is a package" I can benefit from the separation of base vs local. I simply install the base packages from the CD (which have generally been very well tested with the release of the OS) into the base area, and install the local packages into /usr/local. This provides me with similar benefits to those that I get with FreeBSD, etc, etc.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.