On Aug 24,  5:01pm, Robert Elz wrote:
}     Date:        Sat, 1 Apr 2000 23:14:53 -0800 (PST)
}     From:        Greywolf <greywolf@starwolf.com>
} 
}   | Splitting up security access among individuals is asking for that same
}   | bunch of problems.  Get a competent sysadmin and stop dicking with
}   | splintered access.
} 
} Hmm ... here we have something of the order of a hundred systems to
} administer (maybe 200, I don't keep count) (quite a few NetBSD, though
} various other stuff as well), and depending upon just who you count,
} perhaps 5 sysadmins.  The work gets broken down by function - people do
} different things, and not all of those 5 know root passwds (almost) anywhere
} at all (the almost is to allow for toy systems build mostly for play).

     I will agree that this is a good plan.  However, given that you
have such a small team, they should all be trusted with general sudo
access.  Also, they should all be professionals and competent enough
that they can be trusted to edit a file as simple as rc.conf with
screwing it up.  If either of these conditions aren't true, then you
have bigger problems then those that can be fixed by OS changes.  If
you're thinking about security issues, then there are many ways that
any kind of sudo access can be made into general root access.  For
instance, if they have access to vi in any way, they could ":set
shell=/bin/csh" followed by ":sh".  And, if they don't have access to
vi, then they are probably be severely hampered in their ability to do
their job.  Given things like this, to some extent I would have to
agree with Greywolf's comment.

     Since, we're talking about experience, I'll throw in mine.  I'm
currently self-employed as a contractor.  I have a few clients on
retainer, some on piece work, and some random jobs.  Not counting the
random stuff, I am currently solely responsible or have primary
responsibility (i.e. I don't worry about day-to-day stuff, but deal
with major problems or system configuration changes) for 14 machines
spread out amongst 8 sites with another site currently being brought
on-line, and I've been notified by another client that they will need
to be brought on-line in the next couple of weeks.  There are 6 OS'es
involved (not counting different releases of the same OS):  SunOS
4.1.3, SunOS 5.5, HP-UX 10.20, RedHat Linux, NetBSD, and SCO UNIX.  At
some of the sites, I'm also responsible for various other aspects
(network, client systems, cabling, phone system installation and
maintenance, etc.).  Over the years, I've worked with pretty much every
commercial version of UNIX.  The point of this, is that when I talk
about what works (for me), it's not on a whim, it's based on a lot of
real world experience in a variety of settings doing a variety of jobs
with a variety of OS'es.

     Given my experience, I would order the above systems for ease of
administration, from easiest to hardest as follows:  NetBSD, SunOS
4.1.3, SunOS 5.5, HP-UX 10.20, SCO UNIX, and lastly RedHat Linux.  The
reason why I rank the two BSD based systems first is because their
configuration stuff is contained in a handful of files located in
/etc.  NetBSD comes first, because things like rc.conf split out
configuration information from scripts while still keeping it
centralised.  The SysV based systems come next because they spread out
configuration all over the place, meaning I have to go hunt for what I
need to change, but are otherwise relatively easy to maintain.  RedHat
Linux comes last because it doesn't really follow the BSD or SysV
paradigms, although it is closer to SysV then BSD; but, rather it is a
basterised combination of the two with some really horrible scripts.
It also has extremely poor documentation.  There may be a gazillion
"How-To"'s, but the manpages suck.  I need basic reference material,
not a gazillion out-of-date tutorials that I need to wade through to
find one simple little detail.

} "Get a competent sysadmin" isn't an answer for us, and is actually insulting.
} It isn't an answer for lots of other people either - a NetBSD system only
} costs a couple of thousand (for a good current system - let alone how cleaply
} you can pick up out of date hardware that will function fine) - that much
} will only buy a competent sysadmin for a couple of weeks.   For some functions
} an organisation might be better off buying an accountant with an adding
} machine than a computer if a competent sysadmin were to be a requirement.

     This is where contractors come into play.  And, the easier it is
to maintain a system, the less its administration will cost you (of
course, the reliability of the system also plays a factor here).

} There isn't a lot that can be done for the people who really want a single
} (old style) /etc/rc (not that there ever really was one, since rc.local
} always existed as well).   But for those who prefer to keep rc.conf I
} have a suggestion that might work, and be fairly simple for everyone (including
} those of us who would prefer not to have to continually fiddle that file).

     How often do you make changes to system startup?  I rarely "fiddle
that file" after initial system configuration.

} That is, perhaps the rc.d file could start (for some facility called "frogs")
} 
} 	frogs=NO		# or YES, depending upon whether NetBSD
} 				# feels it should be enabled by default
} 	frog_flags="-feed"
} 
} 	. /etc/rc.conf		# fetch RC_PATH and other noise
} 
} 	test -r /etc/options/frogs && {
} 	    frogs=`sed -n '/^frogs=/s/frogs=\([A-Za-z01]*\).*/\1/p'`
} 	    frog_flags=`sed -n '/^frog_flags=/s/frog_flags=\([^;]*\)/\1/p'`
} 	}
} 
} and then the rest of the script.  (If sed isn't going to be in /bin, then
} for this task, "while read line; do case "$line" ..." type operations will
} work almost as well.)

     I'm not sure I like this idea.  Not only does it spread
configuration information all over the place, but it puts the same
configuration information in multiple places.  One of the first things
you learn in database design, is that you put a single piece of data in
one place and replicate it as necessary.  The problem with this design
is that I have to look in multiples places to figure out how things are
configured, and I have to keep in mind which location takes
precedence.  This will really complicate system maintence.  Of course,
as you say, I can use whatever method I want.  The problem would mainly
happen when I have to solve a crisis on a system maintained by somebody
else (mind you, inexperienced system administrators can produce all
sorts of "interesting" situations).

}-- End of excerpt from Robert Elz