Fwd: Re: System administration utility

[ddm at mclinux.com (Derek D. Martin)]

Oops, forgot to CC: the list on this one. 

----- Forwarded message from "Derek D. Martin" <ddm at mclinux.com> -----

Date: Mon, 20 Aug 2001 17:43:11 -0400
From: "Derek D. Martin" <ddm at mclinux.com>
To: Derek Atkins <warlord at MIT.EDU>
Subject: Re: System administration utility
User-Agent: Mutt/1.2.5i
In-Reply-To: <sjmhev21oc2.fsf at rcn.ihtfp.org>; from warlord at MIT.EDU on Mon, Aug 20, 2001 at 04:14:05PM -0400

Derek Atkins said:

> Why not just use RCS (or CVS)?  Then you also get revision control
> and change history, as well as file locking.

Actually we use both.  IIRC the problem here is that generally, in
order to edit most config files, you need to be effectively root.  If
you check out a file as root, the lock is "owned" by root, and it's
impossible to tell who has the file locked without running around
yelling "who's got the aliases file locked?!?" or some such thing.  If
you've got a large enough group spread out over a fairly large area
(as was the case at one job I worked at) this is a very inefficient
way to determine who is working on a file.

This utility will (in most cases) circumvent that problem, by trying
to figure out who the real user who ran the program was.  The only
time it fails is when the user logged in as root to start with... IOW
if you su to root or use sudo to run the program, or use some other
suid wrapper, it will be able to figure out who you really are.

Some files also aren't well suited to source control, like the
passwd file.  Users can change their own password, but if the
passwd file isn't checked out, their changes will be overwritten next
time someone checks it out.  And users typically can't check out the
passwd file for editing...


-- 
Derek Martin
Senior System Administrator
Mission Critical Linux
martin at MissionCriticalLinux.com


----- End forwarded message -----

-- 
Derek Martin
Senior System Administrator
Mission Critical Linux
martin at MissionCriticalLinux.com

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).