Re: tlug: NFS question

[Frank Bennett <bennett@example.com>]

Rex Walters <rex@example.com> writes:

> 1) Maintain master copies of passwd, group, shadow, and gshadow on a
>    designated server.  These should NOT be /etc/passwd, /etc/group, etc.
>    but should be stored separately (/etc/MASTER or somesuch).  Create
>    perl scripts to act as substitutes for useradd, etc., that manipulate
>    these files rather than /etc/passwd.  They should be owned by root
>    with 600 permisions.  RCS can be your friend.

I like this, in part because it loosens up a puzzle that was
starting to pester me.  The story of this is a little bit long-
winded; read on only if you're interested and have time.

Mail facilities here are different for undergrads and postgrads.
PG's and staff accounts are maintained on the server that I
control.  UG's have their accounts on central University servers,
accessible only from the central University "Information Center".
It's a long schlep over there from our Faculty, and you sometimes
have to wait for a terminal.  As a result, email is used only
sporadically by students, and that means we have a devil of a
time communicating with them between classes.  University life
shouldn't be like that.

IMAP service from the Center would solve this problem by allowing
transparent access from within the Faculty, but I've no guarantee
that IMAP service will be offered by them.  I've spoken with them
a bit, but I get the feeling that I'm up against 縦割; it's their
turf and their building and, er, that's it.

On the other hand, it seems a bit silly for me to get into the
business of issuing accounts one by one to undergraduate students
(for the obvious reason that there are lots of them).

It struck me, though, that I can work around this problem by
substituting an Expect/Tk widget for xlogin.  The widget will
snatch the user's login name and password, and attempt to log
into the workstation.  This fails.  The next step is to try the
Information Center.  If this succeeds, the widget turns around
and sets up a new mail account and home directory on our server,
and appends the user to passwd.  It then sets up mail forwarding
from the Information Center to the newly created account, and
fetches any existing mail to the new account, leaving the Center
account empty.

The widget will thus piggyback on the Information Center's work
in confirming the identity of each user issued an account, and
gives our students IMAP access without any need for liaison at
all.  We can track account expiration, too: if the login to the
Center account fails on some future occasion, the local account
gets archived and I'm notified by email.

Order out of madness.

Well, admittedly the idea for this Tk widget is a bit mad in
itself.  There will have to be lots and lots of error handling in
there, so at the very best it'll have to wait awhile to be
written.  But the point that the server does not need to be in
sync with the clients --- that the clients' master need not be
/etc/passwd --- reduces the risk that a crash somewhere will
bring the whole system down.  Very useful to know this.

Cheers,
-- 
-x80
Frank G Bennett, Jr         @@
Faculty of Law, Nagoya Univ () email: bennett@example.com
Tel: +81[(0)52]789-2239     () WWW:   http://rumple.soas.ac.uk/~bennett/
---------------------------------------------------------------
Next Nomikai: 20 November, 19:30 Tengu TokyoEkiMae 03-3275-3691
Next Meeting: 12 December, 12:30 Tokyo Station Yaesu central gate
---------------------------------------------------------------
Sponsor: PHT, makers of TurboLinux http://www.pht.co.jp