Very Computer

by **Matt Kenn** » Fri, 24 Jan 1992 12:08:02

>I am not asking how to make it idiot proof or
>how to make it possible for computer novices to administer, but I *am*
>asking for ideas on how to improve it so that computer literate people
>who aren't UNIX guru's can function decently as a system administrator.
> But if you
>can see ways to improve UNIX, perhaps by designing administration tools
>or whatever, I think it would be interesting to hear your thoughts.

Well, then. Let's talk about the things that you people would like to see
improved in system administration? Let's get down to specifics, and
quit *ing.

As a mere "user" (scientific programmer) and ersatz sysadmin (what else
are grad students for?) here's my ideas...

1) Setting up a cross-mounted NFS network. This happens ALL the time,
everywhere!

Right now, we had to type in and figure out /etc/exportfs for each
individual machine, and figure out how to configure that damn automounter
everywhere, etc. etc. This is the typical situation. Here's a simple
example of what it should be like instead: (I'll use a portion of our setup,
here)

===========================================
What are the names of the machines in this cluster?
poincare, lyapunov, gibbs

Give me a name of a machine:directory that should be available everywhere.

poincare:/usr2

What do you want to call it across the network?

/home/poincare

(do same for gibbs & lyapunov)

Are there any aliases that should be propagated to every machine on the
local network?

Yes. /usr/local -> /home/gibbs/local
/usr/lib/X11 -> /usr/local/lib/X11
/usr/include/X11 -> /usr/local/include/X11R5
/usr/lang -> /home/poincare/lang
etc.

What paths for executable programs should be added to the standard ones?
/usr/local/bin, /usr/local/bin/X11, /usr/lang

What paths for manual pages should be added to the standard ones?
/usr/local/man, /usr/lang/man, /usr/openwin/man

==========================================

This should set up all the appropriate NFS files, .rhosts, etc. etc.
One should have a centralized place that has this information, so that
one could easily change, say to add a new computer, and the tool would
automatically create all the new information needed. This would
save an enormous amount of effort for 95% of the sites out there.

This doesn't require any new technology; a combination of perl, make, cpp,
rsh, and rdist ought do be completely sufficient. Probably somebody could
write it in a couple of weeks; a good one in a few months. Also keep it
lo-tech & simple---no fancy new protocols & object-oriented file systems or
other CS frilly things. We want it to work right when other things
aren't---and be understandable by an average sysadmin in case something goes
wrong! If it doesn't come standard as an OS, one should be able to download
it to one machine, and given that root rsh works everywhere, propagate the
whole system config from that one place. This system ought to be much
simpler to write than "gcc" "X11" or even "xterm" for Gd's sake!

compare that to:
(auto.master)
/- /etc/auto.direct -rw,soft,noquota

and
(auto.direct)
/home/poincare poincare:/usr2
/home/gibbs gibbs:/usr2

and
(/etc/exports)
/usr2 -root=louise:jacobi:legendre:hamilton:gibbs:herbie:poincare:louise.ucsd.
edu:jacobi.ucsd.edu:legendre.ucsd.edu:hamilton.ucsd.edu:herbie.ucsd.edu:gibbs.uc
sd.edu:poincare.ucsd.edu,access=louise:jacobi:legendre:gibbs:hamilton:herbie:poi
ncare:louise.ucsd.edu:jacobi.ucsd.edu:legendre.ucsd.edu:hamilton.ucsd.edu:herbie
.ucsd.edu:gibbs.ucsd.edu:poincare.ucsd.edu

(other machines in our cluster are included here)

Of course, on every machine these are slightly different because you have
to refer only to the other machines and not yourself.

Those silly configuration files, in my opinion should be like Postscript---
humans shouldn't have to ever create them themselves.

As a matter of fact, along these lines, ALL system files that a human
has to localize for any particular site should be in ONE subdirectory, say
/etc/LOCALCONFIG/* (or whatever) and with links from the normal places
into here. This way, it's very easy to save a particular local
installation, to know exactly what's change, and to reconstruct it after
an OS upgrade, or a disk wipe.

2) Sendmail.... This is always a problem. Here at UCSD, we just download
a sendmail configuration that was created by the Net Gurus on campus and
don't worry about it, but others aren't so lucky, I take it, especially
if they have to deal with UUCP and junk like that. I don't know how
to fix this, so I'll leave it up to others.

3) Automatic .login and .cshrc that ALWAYS get executed. This way
any sysadm added paths and manpaths can be automaticaly propagated
instead of having people complain "Why can't I get MATLAB? So and so
just types in "matlab" and it worked but I can't? Why can't I man gcc?"
(I know some places have it---I'm specifically harping on Sun, because
that's what I know)

If people know enough to know about MANPATH and PATH they can make
their own .login's and .cshrc's undo anything the sysadm does as a default.

Furthermore, these should automatically set up xhost + for all machines
on the local network, in general.

4) Programs that automatically set the DISPLAY variable to the console
screen that the person's using, even when rlogin'd to other machines. I
hear very frequently ("Why can't I graph on my screen blah blah what's wrong
with this X windows anyway") Newbies shouldn't have to even worry--
they rlogin, run their graphics programs and it comes up on their screen.
I mean the computer knows you're on somewhere, so why do you have to tell
it again?

I'm sure there are other areas that you out there can think of.

My whole point, is that there are quite a number of very EASY things that
commonly used UNIX systems could do, that are trivial from a fundamental
point of view, but quite serious from a day-to-day perspective.

As part of the DOS vs. Unix flame war: These are all things that standard
UNIX has the capability to do now. On a DOS network, how would I
automatically create directory links on every machine? (rsh? links? what's
that?)

>John
>--

>Senior Partner, Quetzal Computational Associates
>Albuquerque, New Mexico

Matt Kennel

by **Michael Lamoure** » Sat, 25 Jan 1992 05:54:51

|>
|> I'm sure there are other areas that you out there can think of.

I agree with virtually everything that Matt had to say.
Everyone seems to have jumped on the GUI bandwagon ("It can't be easy
if it's not a GUI"). I think there are a great many things that could
be done to make it simpler without too much effort.
One for instance is related to Sun's great automounter idea.
As an administrator and a user I love the automounter. What I hate is
that Sun spent all that time making sure that it interfaced cleanly to
all of their utilities (note the overflowing sarcasm). I don't know a
single user who can stand using Sun's File Manager on our network
because of the cryptic /tmp_mnt garbage that gets stuck in by the
automounter links et al. I'm sorry, it's not transparent. And pwd
and ls see right through the automounter. I had to hack up a Perl
script to perform ls in a sane fashion in automounted directories.
And we played games with dot files to work around the pwd problem.

Another thing that I've always wondered is with find. I'd say
that 90% of the time I use find on the command line I use it like this:

% find . -name file -print

It seems intuitive that these should be defaults if no arguments (I
guess really if one argument) are given like 'find file'. I have an
alias to do this, but should I need an alias to make the command
intuitive? I mean, they made -C the default for ls on the command
line, how much tougher would this be? Oh well, I'm just *ing
anyway. I guess there are a great many other things I should *
about first (like yp).

Michael

--
"The 'alt.sex' news group hierarchy was created so that the times people
wanted to talk about sex didn't interfere with the times they wanted to
talk about Unix kernel hacking." -- Sharon Fisher "Communications Week"

by **peter da sil** » Sat, 25 Jan 1992 07:16:53

> Well, then. Let's talk about the things that you people would like to see
> improved in system administration? Let's get down to specifics, and
> quit *ing.

OK.

Quote:> 1) Setting up a cross-mounted NFS network. This happens ALL the time,
> everywhere!

Not here...

We don't run NFS (well, we do on the Suns because we have to, but not
elsewhere). We run OpenNET and DECnet. You can access anything if you
know its name: your systems would be //poincare, //lyapunov, //gibbs.

Quote:> Give me a name of a machine:directory that should be available everywhere.
> poincare:/usr2

//poincare/usr2

On DECNET, under VMS, you have a similar set of semantics (albeit with a gross
syntax):

POINCARE::DUA1:

The aliases you list should be set up as you install each package, as part
of the package. Same with the bin paths and manual pages.

NFS is just overly complicated... more so than it needs to be. OpenNET and
DECNET are too limited to a single vendor and architecture. There has to be
a happy medium.

Quote:> 2) Sendmail.... This is always a problem.

No kidding. We use smail 2.x. We don't use sendmail for anything.

Quote:> 3) Automatic .login and .cshrc that ALWAYS get executed.

/etc/profile or /etc/csh.login.

Quote:> 4) Programs that automatically set the DISPLAY variable to the console
> screen that the person's using, even when rlogin'd to other machines.

That's for sure. I don't care for X, myself, and wish we had 8 1/2 (where
this problem never comes up)... but this should be handled by rlogin/telnet.

But too much of the MITNIX and Berkeley software in UNIX has too many ad-hoc
design decisions buried in it. I don't know how to fix it, but you can't get
to a better solution from here without backtracking.
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"

by **James Camer** » Mon, 27 Jan 1992 01:28:06

[...]

Quote:> 4) Programs that automatically set the DISPLAY variable to the
> console screen that the person's using, even when rlogin'd to other
> machines.

peter> That's for sure. I don't care for X, myself, and wish we had
peter> 8 1/2 (where this problem never comes up)... but this should
peter> be handled by rlogin/telnet.

I disagree to a point. When I 'rlogin' into a machine from another
within X, there is USUALLY a reason, and I *don't* want my environment
passed unless I explicitly inform it to.

There is a simply csh script which passes the DISPLAY in when you want
to rlogin into another machine. It pops open a new xterm for your use
as well.

Hope this helps!

James

Signal Processing and Interpretation Lab. Boston, Mass (617) 353-2879
------------------------------------------------------------------------------
"But to risk we must, for the greatest hazard in life is to risk nothing. For
the man or woman who risks nothing, has nothing, does nothing, is nothing."
(Quote from the eulogy for the late Christa McAuliffe.)

#!/bin/csh -f
#
# this sets up an xterm on the remote machine at the same time
# performing a xhost for the remote machine on the display machine
#
# First, find the name of the display
#
set command=$0
if ( $#argv == 0 ) then
echo Usage: $command:t hostname
exit 1
endif
set remotehost=$1
shift
set displayhost=`printenv DISPLAY | sed -e 's/:.*//'`
#
# Now we need to see if this has the right name
#
switch ( $displayhost )

case unix: # display on the local host
xhost $remotehost
if ( $status != 0 ) then
echo xhost failed on local machine
exit 1
endif
set displayhost=`hostname`
breaksw

case "": # not an X device
echo The environment variable DISPLAY is not
echo set. You must issue the command \"$command:t\"
echo from an X device.
exit 1
breaksw

default: # display on a remote host
echo "setenv DISPLAY ${displayhost}:0.0 ; xhost $remotehost" | rsh $remotehost csh -t
if ( $status != 0 ) then
echo xhost failed on machine \"$displayhost\".
exit 1
endif
breaksw
endsw

rsh $remotehost xterm -display ${displayhost}:0.0 -ls -n $remotehost $argv &

exit 0

by **Bob Cousi** » Mon, 27 Jan 1992 06:17:29

>> writes:
>> NFS is just overly complicated... more so than it needs to be. OpenNET and
>> DECNET are too limited to a single vendor and architecture. There has to be
>> a happy medium.
>Well, though I risk flamage -- there's AFS.
>You can access anything, even if you don't know what system it's
>located on. In fact, administrators can move things around from one
>system to another, and nobody else ever even knows, unless they dig.
>This implies, of course, that stored files can always have the same
>name, regardless of where you access them from.

This is true. However, the administrative complexity of AFS is in many
ways greater than NFS.

Quote:>You get decent security and access control.

Yes, using ACLs (limited to 20 entries and only working for directories).
Unfortunately, these break the UNIX semantics associated with chmod(1). Furthermore,
AFS filesystems are not available to local servers. They are only available to
remote machines who have mounted them.

There is also the problem of token expiration. A user must be granted an access token
to use AFS (or DFS) files. This token has an expiration time (typically 25 hours). When
the token expires, file operations begin to fail. This tends to confuse applications.
TransArc told me that they expected everyone to rewrite their programs to make them
compatible.

Quote:>AFS is available on about 20 different OS+hardware platforms
>(Sun,Dec,IBM,HP,Next), though it's still one vendor. DFS will be
>available from dozens of vendors, but that's probably at least a year
>away.

DFS makes AFS look easy to administer. There are some features which apply on a
fileset by fileset basis when applied to a client by client array. In other words,
with 100 filesets and 100 clients, 10,000 entries must be maintained (for things
such as setuid and setgid execution permission). Furthermore, there are subtle
incompatibilities between DFS and traditional UNIX semantics. While NFS has these
problems (and more such as security holes, no guaranteed append, etc.) NFS was
never represented to maintain true UNIX semantics. DFS is advertised to do so.
At least chmod(1) works (more or less) correctly. Under DFS, chmod(1) will work
on UFS filesystems without problems (when exported). However, DFS filesets will
attempt to map chmod(1) operations into ACL controls with (according to the
TransArc person who explained this to me at Usenix) at best dubious results due
to the basic philosophical incompatibilities between ACLs and UNIX.

Quote:>Apologies for the plug -

>Lyle Transarc 707 Grant Street
>412 338 4474 The Gulf Tower Pittsburgh 15219
>Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.

This is not to say that AFS or DFS is bad. They have some wonderful features
which we have needed for a long time. However, we must be careful not to
assume that advances come for free.
--
________________________________________________________________________________

Consultant to Aim Technology Speaking for myself alone.

by **Matthew Farwe** » Mon, 27 Jan 1992 14:10:37

> Another thing that I've always wondered is with find. I'd say
>that 90% of the time I use find on the command line I use it like this:

>% find . -name file -print

>It seems intuitive that these should be defaults if no arguments (I
>guess really if one argument) are given like 'find file'. I have an
>alias to do this, but should I need an alias to make the command
>intuitive?

The posix behaviour for find is close to the one you're looking for.
When you type 'find', it defaults to 'find . -print'. Gnu find is posix
compatible.

Dylan.
--
I refuse to have a virus in my .signature

by **Miles Bad** » Wed, 29 Jan 1992 08:33:30

I only have a user's perspective, but I think AFS beat's the pant's off of
NFS in a installation of more than a few machines (and even with less, since
you automatically become part of a global filesystem). I really wish they
had it here!

It's *much* easier to understand what's going on when you have a consistent
global namespace instead of everyone mounting different things in different
places. The security is obviously much better. You don't have stupid things
like having to wait 3 seconds to use a file on another machine. Even
considering the shortcomings of AFS [like some of the grossly non-unix
semantics (which I guess are supposed to be fixed in DFS)], it's just Better
(oooh, a capital B!).

> This is true. However, the administrative complexity of AFS is in many
> ways greater than NFS.

Very true (although I've only used the system at cmu, and I assume that since
transarc took it over, they've worked on this). But should think that
although it (the complexity) starts relatively high, it would grow at a much
smaller rate than NFS. Some features like being able to move volumes
(filesets in DFS) around are something I think the sysadmins here would kill
for.

Quote:> Yes, using ACLs (limited to 20 entries and only working for directories).
> Unfortunately, these break the UNIX semantics associated with chmod(1). Furthermore,

In my experience the biggest pain is not having them on individual files (and
this only shows up once in a while, usually on a file that some program
refers to via a fixed path). That it's not chmod compatible mostly seems to
a problem for programs which expect to be able to twiddle the mode bits. For
a user, ACLs are great, especially since you can create your own groups and
then use groups in ACLs.

Quote:> AFS filesystems are not available to local servers. They are only available to
> remote machines who have mounted them.

This is another thing that is mostly a problem for very small installations,
and supposedly fixed in DFS...

Quote:> There is also the problem of token expiration. A user must be granted an access token
> to use AFS (or DFS) files. This token has an expiration time (typically 25 hours). When
> the token expires, file operations begin to fail. This tends to confuse applications.
> TransArc told me that they expected everyone to rewrite their programs to make them
> compatible.

The typical way around this seems to be to have a process that sits around
and re-authenticates you every n hours. The only problem I *know* of is that
this requires the password to be on the machine.

Quote:> DFS makes AFS look easy to administer. There are some features which apply on a
> fileset by fileset basis when applied to a client by client array. In other words,
> with 100 filesets and 100 clients, 10,000 entries must be maintained (for things
> such as setuid and setgid execution permission).

I don't understand the bit about 100 fs & 100 clients at all. Could you
explain what you're talking about in more detail?

Quote:> Furthermore, there are subtle
> incompatibilities between DFS and traditional UNIX semantics. While NFS has these
> problems (and more such as security holes, no guaranteed append, etc.) NFS was
> never represented to maintain true UNIX semantics. DFS is advertised to do so.
> At least chmod(1) works (more or less) correctly. Under DFS, chmod(1) will work
> on UFS filesystems without problems (when exported). However, DFS filesets will
> attempt to map chmod(1) operations into ACL controls with (according to the
> TransArc person who explained this to me at Usenix) at best dubious results due
> to the basic philosophical incompatibilities between ACLs and UNIX.

ACLs are worth the problems (imho). [I don't know how they intend to map
between chmods & acls, but this doesn't seem like a *totally* bogus idea.
The main problem I can think of offhand is programs who use the mode bits
from one file to set those on another (e.g., emacs, tar), which obviously
doesn't do what you probably want-- copying the whole acl...]

I hope this doesn't sound *too* much like a commercial for transarc! I used
to work at the ITC (but not on AFS), but I don't think this has prejudiced me
more than mildly!

-Miles
--
--

Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature.
97% of everything is grunge

by **peter da sil** » Thu, 30 Jan 1992 01:03:32

> It's *much* easier to understand what's going on when you have a consistent
> global namespace instead of everyone mounting different things in different
> places.

Agreed. Another plug for OpenNET: it gives you this, but also gives you full
UNIX semantics on remote files, and as close to UNIX semantics as it can get
on remote files on foreign file systems... I can actually open a "directory"
on a VMS or DOS system and see inode numbers and file names.
--
-- Peter da Silva, Ferranti International Controls Corporation
-- Sugar Land, TX 77487-5012; +1 713 274 5180
-- "Have you hugged your wolf today?"

by **achille petril** » Fri, 31 Jan 1992 03:49:21

Well, having worked with ACLs for years, I'd like to comment:

>> Yes, using ACLs (limited to 20 entries and only working for directories).
>> Unfortunately, these break the UNIX semantics associated with chmod(1). Furthermore,

>In my experience the biggest pain is not having them on individual files (and
>this only shows up once in a while, usually on a file that some program
>refers to via a fixed path). That it's not chmod compatible mostly seems to
>a problem for programs which expect to be able to twiddle the mode bits. For
>a user, ACLs are great, especially since you can create your own groups and
>then use groups in ACLs.

Apollo's DomainOS (now defunct) had since day 1 ACLs, on both files and
directories.
It was a f***ing pain. Users changed the ACLs, added fancy entries, didn't
remove others and then something stopped working. Just figuring out what the
*y ACLs was doing was far too much for the poor guys/gals and then they
called the SA (me).
I was relieved when I could forget about ACL. 9 bits are enough for me.
I don't know about AFS/DFS' ACLs, but I suspect they will become a nightmare
just like any other such scheme, or just not used at all.

Just my 2 cents ...

Achille Petrilli

by **Wallace Coly** » Sun, 02 Feb 1992 14:18:27