[56] in Back_Bay_LISA
September bbisa hours
daemon@ATHENA.MIT.EDU (John_Rouillard@dl5000.bc.edu)
Fri Oct 16 15:56:32 1992
From: John_Rouillard@dl5000.bc.edu
Date: Fri, 16 Oct 92 15:05:05 EDT
To: bblisa@inset.com
Hi all:
I figured I had better get this out before I head off to LISA
tomorrow.
These are the hours for the September Back Bay LISA open discussion.
(There isn't enough detail to call these minutes.) Hopefully this will
give the people who were not there a feeling for the issues brought
up.
Facilitated by: Kim Carney (kim@athena.mit.edu)
John Rouillard (rouilj@cs.umb.edu)
I apologize for the lack of attributions in the following. I don't yet
know everybody, or indeed most people well enough to assign names to
the discussions. All of the faults, error, omissions etc. below are my
fault, and not Kim's.
1) John Rouillard presented some ideas for future meetings.
a) Backup systems/policies - backups initiated by systems people,
and users.
This one is the presentation topic for October.
b) Multi-platform support: Making MAC's, PC's, VMS, and UNIX play
together.
For the MAC/Unix connection the Columbia Appletalk Package
(CAP) can be used to allow access to Unix files on the Mac.
For VMS, Multinet seems to have gained some favor in
supplying NFS access to Unix filesystems.
c) Most Replaced System Software: What system software do you
replace.
What software just doesn't cut it as far as not working
properly, or taking too much time to administer etc.
d) Managing Multiple System Administrators.
How do you stop multiple system administrators from colliding
when making changes to system configuration files. This is
actually addressed by systems such as Tivoli by the creation
of junior sysadmins that have a limited role of activities
that they can do.
e) Disaster strategies: Carrying on in the face of machine
crashes/loss.
Do you maintain offsite backups? How would you recover
data/network operations in the event of a fire, or other
disaster?
f) How to "cookie cutter" a system to ease maintenance.
Since everybody loves to spend hours of time doing system
upgrades, what are some methods of reducing the workload
involved.
g) Disk usage/allocation: space wars, managing software packages,
using the automounter.
h) System security measures: tools, and techniques.
Cops, crack, log_tcp, firewalls: what tools are available to help
secure systems, and what are the pitfalls of using them.
i) Making user/sysadmin life easier through software.
If anybody else has any ideas for future meetings, please send them
to Rich Salz (rsalz@osf.org).
2) How do you deal with problems caused by users having root access too
their own workstations? Alternatively, how can you as a sysadmin
try to gain exclusive control of the workstations?
a) Why do people want/need root access:
i) A status symbol.
ii) Improper management by current/past sysadmin staff required
root access to get the jobs done.
iii) They really do need limited root access to do their jobs
(e.g. changing configuration of workstation for testing purposes
etc.). These things change frequently enough, that
tracking down a sysadmin to perform these tasks would be an
impediment to doing productive work.
b) How do I get control back from the users.
i) Probably the best idea presented is to use a form that spells
out in some amount of detail the tasks that that user is
responsible for maintaining. Then a copy of the form is
given to their manager, and to your (the sysadmin's) manager.
Now when something goes wrong, the lines of responsibility
are clearly drawn. Hopefully many of those people who want it
for status, or because of previous improper management will be
sufficiently intimidated by the document that they will give
up root access. At the very least, the document can point out
shortcomings in the management of the workstations by the
users.
c) How can I handle people who do need limited access on their
machines, or across the network.
i) One other alternative is to write canned scripts and allow
access to these scripts as root via a program such as sudo.
This can allow users to run canned responses to conditions
such as printer queue management, or disk full conditions.
2) How is cost for sysadmin services assessed.
a) Sysadmin costs are separately budgeted for mainframe type
systems, but not so under Unix.
b) The gentleman from Tivoli mentioned that very few of the places
he is familiar with allocates/charges money explicitly for
sysadmin services. It is usually deeply hidden in the cost
hierarchy.
c) When writing proposals, some companies cut the 1-2% overhead that
would be figured into the proposal for sysadmin charges in
order to reduce the cost of the bid.
3) What is available for terminal servers?
a) If you are a Unix shop Xylogics (Is this the annex terminal
servers?) is a good server. Cisco also has some good terminal
servers as well.
b) Xyplex servers command language is more VMS based, and would
probably be better in a VMS type shop, although they will
work in a Unix based environment.
4) What options are available for multi-platform mail service?
a) Quickmail is one commercial product that can interface
MacIntosh's with Unix mail.
B) Pop and imap are two protocols that are available for dealing
with mail access for a non-Unix host. Pop clients are
available for IBM-PC's and MacIntosh's. Imap clients are
available for MacIntosh's and a PC port of the pine imap mail
program should be available sometime in December.
--
Send mail for the `bblisa' mailing list to `bblisa@inset.com'.
Mail administrative requests to `bblisa-request@inset.com'.
