× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



On Wed, 23 Oct 2002, Scott Klement wrote:

> > 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

[snip differences between FreeBSD and Linux]

> 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.

Uh huh... good point

>     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.

This is the same as Solaris or IRIX or linux (though linux doesn't support
the immutability flag as well).  Please see what I've written after your
post.

>     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.

Ok.  Again, see below.

>     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.

This part really interests me.  By "hardware configurations" do you mean
different CPU architectures or just difference (for example) network
cards?  Let's say I have the following machines on my lan that I want to
export to:

1. a linux computer with a low-res monitor and limited graphics abilities
(I'm thinking something like a 1U rack machine here)
2. a linux computer with a high-res display and powerful graphics card
3. an SGI Octane2 (high end workstation - very nice display)
4. another (free *nix) machine running on soon to be released AMD 64-bit
CPUs

Let's say the rack machine is the NFS server.  And let's limit the
discussion to tn5250 since that's something we all know womething about :)
Would each machine require its own system wide tn5250rc?  If I want xt5250
to look the same site wide on every machine, regardless of display
resolution/ability, can I export a single tn5250rc or do I need a tn5250rc
for each machine because their displays have different abilities?  And
would I need to export the binaries in some manner maybe like this:

/export/linux-32/tn5250/<tn5250 programs/lib for 32-bit>
/export/linux-64/tn5250/<tn5250 programs/lib for 64-bit>
/export/irix/tn5250/<tn5250 programs/lib for IRIX>

?  Of course with only one IRIX machine I probably wouldn't export the
IRIX stuff (or would I?).

>     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.

Another good point, but see below.

A lot of what is shipped with any *nix install disks is more than "the
base OS" and gets installed in /bin, /usr/bin, etc.  Hopefully what is in
/bin is only the minimum required to boot the machine, with everything in
under /usr.  The line between OS and applications is unclear.  So instead
I'm going to translate what you've said (unless you get mad and tell me
otherwise :) ) to mean that "stuff that came with the CDs" and "the base
OS" are the same.

But suppose that something didn't come with the CDs that you require for
your system, something that you think should (like tn5250!)?  Wouldn't it
make sense to put it under /usr in order to gain all the benefits you
listed?  You could lock it down, back it up, and reinstall without worry.
Development versions would live in /usr/local, but stable in /usr.  That
way if the devel version is giving you fits you can fall back to stable
easily.  Your system backup would contain all the programs you need to
make your system work.  And it would be in a locked down location.  You
would consider it "system software" instead "My Downloads".  Does this
seem reasonable?

As for NFS I don't really know.  All my diskless machines run linux and
have pretty much the same hardware.  Other than that I don't export
anything (the new Octane2 and AMD machines aren't purchased/available
yet).

Of course we don't have to agree here.  I'm just hoping I'm not out to
lunch on this.

James Rich



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.