OT: redhat

[Bill Vermillion]

press any key to reboot  -oops- Fairlight said on Thu, Nov 04 18:22  

> On Thu, Nov 04, 2004 at 05:25:52PM -0500, J. P. Radley may or may not have
> proven themselves an utter git by pronouncing:

> > Make a Master backup extending over more than tape, excluding nothing.

> Not excluding /proc is doing nothing but wasting tape. You
> can't -use- kcore, and it can get -quite- large.

> > Then on a daily basis, you can exclude all kinds of
> > directories with Operating System files which do not change.
> > (Be careful not to exclude directories like, say, /usr/bin if
> > you ever find yourself adding files to them).

> Unless you're adding OS-vendor-supplied packages via rpm,
> things you compile and install yourself should always be added
> under /usr/local anyway. People that don't segregate custom
> files from vendor-supplied files can drive admins--and even
> themselves--up a wall when they need to figure out what's what
> later on.

> You go to backup (or really when it hits is during a partial
> restore) files and you never know what's native and what's been
> tacked in by the admin/user. A good example of this is having
> a /usr/bin/p, which -really- wants to go in /usr/local/bin
> instead. filePro isn't alone; I've never done the installation
> myself, but I've -seen- BackupEdge installed in /usr rather
> than /usr/local. I don't know if that was an installer's choice
> or a default, but it should really default to /usr/local IMHO.

It should - but historical Profile started in /usr as with
a 15MB hard drive - where most of the orignal Profile systems
were installed [Tandy had about a 30% larger installed machine base
than the second largest vendor - DEC with their VAX[en].   Of
course  Radio Shack / Tandy systems usually were only 1 to 3 users
so that left DEC with a larger user base.

> Not having /usr/local is often a holdover from older SysV
> people that weren't exposed to that being in the heirarchy
> until relatively recently.

But Version 7, System III et al came before SysV and nothing seemed
to change.  Upward compatibiltity and all that rot.

> Every time I have to actually create /usr/local itself, I sigh
> and shake my head, knowing the system is probably a complete
> mess already.

It makes great sense to have a full /usr/local hierarchy.  In
the FreeBSD world you can usually totally remove all of
/usr with the exception of /usr/local and have a completely fresh
OS install with nothing at all left over from the old system - at
least as far as the true OS files go.

> If one wants to get -really- technical, configuration and
> temporary files like spools and semaphores should -never- be in
> /usr/* anything. As I understand it, /usr originally stood for
> User Serviceable Routine. Also known as binaries and libraries.
> Hence, the later migration of things like /usr/spool/mail to
> /var/spool/mail when filesystem layout standards like FSSTND
> became more widely adopted. And /usr/adm is a prime example of
> a legacy of misplaced set of files if ever there was one, if
> you want to be -really- technical.

The problem with /var being the mount for spool on anything other
than a smaller business system is you will rapidly run out of 
room in a default install.

I symlilk /var/spool/mail to /usr/mail.

This AM a client with one mail account that gets copies of EVERY
mail to anyone at their company called and said he couldn't get any
mail.

I watched and the problem was that by the time the file was copied
to the .xxx.pop file for tranmission his MS device had timed out.
Normally that all-in-one account was accessed once each week
and archived to DVD.   But it grew large and this AM when he 
called and I watched it was at about 950MB.  I just checked a
moment ago and it was 1.015GB.   So when I get it split and he gets
it in place, his archiving will now become twice a week.

If you are wondering why the file is so large, it is for an
invesigatory firm and there are large documents, still photographs,
and video files.    That and on other place are while the mail
limits are so large - 50MB per mail message :-).  

You have to evalute each system as defaults just don't work as
people find more and more uses for their system.

In the above if you have a pop server and items are under
/var/spool/mail - the temporary .pop files will copied into that
same directory so during the copy time you will double the space
for the file in use.

> And before anyone thinks I'm being really picky, I'm not
> particularly. My report cards used to regularly read:
> "Organisational Skills: Unsatisfactory" when I was a kid. The
> whole point is to standardise systems so that moving between
> them is as relatively seamless as possible.

And you can't standardise systems without setting standards
defining what the system is used for, can you?

> To SCO's credit, they've adopted a lot of this in recent years.
> To many would-be admins' discredit, people still make poor
> choices for the logical layout of their system files--no matter
> what OS they use.

And I still see many in the Linux and FreeBSD world advocating
one large filesystem for everything.  The day they corrupt the 
/ filesystem, and it is the only system, perhaps they will see the
error of their ways.

In multiple filesystem systems [that is not redunant] except for
full HD failure, I've never lost / AND the other file systems.

And planning for the rainy day, if you do make other filesystems
intead of one, if you have a bad crash, quite often you can take
that drive to another system and mount the non-/ systems to recover
data - even if it's in RO mode.

Comparing   man hier on both Linux and FreeBSD I think the
beast is a bit cleaner.  It doesn't add gratuitious names [IMO]
such as 'dos' and leaves those up to the user.

Bill
-- 
Bill Vermillion - bv @ wjv . com