OT: redhat

[Fairlight]

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.

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

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.

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

mark->
-- 
Bring the web-enabling power of OneGate to -your- filePro applications today!

Try the live filePro-based, OneGate-enabled demo at the following URL:
               http://www2.onnik.com/~fairlite/flfssindex.html