Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site vcvax1.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!cybvax0!vcvax1!paul
From: paul@vcvax1.UUCP (paul)
Newsgroups: net.unix,net.unix-wizards,net.decus
Subject: Re: Limiting logons to licensed number: how?
Message-ID: <112@vcvax1.UUCP>
Date: Thu, 25-Jul-85 10:34:47 EDT
Article-I.D.: vcvax1.112
Posted: Thu Jul 25 10:34:47 1985
Date-Received: Sat, 27-Jul-85 02:36:58 EDT
References: <1029@ucbtopaz.CC.Berkeley.ARPA>
Organization: VenturCom Inc., Cambridge, MA
Lines: 39
Xref: watmath net.unix:5138 net.unix-wizards:14012 net.decus:131

> As a purely academic question: how do outfits like
> DEC (Micro-Vax II) and VenturCom (Venix, DEC Pro/Venix)
> limit the number of "init"'s for logons?  Both companies
> want to charge a user license fee by the logon.

VenturCom has explored a couple of schemes to limiting the number
of simultaneous logins to our VENIX systems.  In VENIX version 2
(a.k.a. PRO/VENIX version 1) the number of logins was enforced by
"init".  In our new VENIX System V release 2 (PRO/VENIX version
2), the number of users is enforced by the kernel.  The latter
scheme is more robust:  the kernel counts the number of control
terminals and prints an error message if an attempt is made to
create more than the licensed number of logins.   Note that this
does NOT restrict the use of an arbitrary number of lines for
printers or for dialing out (e.g. with UUCP or CU).

I should point out that our licensing from AT&T is on a per-user
basis, so we are legally obligated to restrict the number of
users to the licensed number.

> Both seem
> to ignore the fact that often one will want more potentially
> active ports than the cpu and disk would ever support, merely
> to facilitate incoming modem communication at random times.

That's a good point.  In our new VENIX version, we've tried to
ease this problem through a new command called "ttystate" which
can be used to quickly enable and disable login lines.  The
approach which you seem to suggest would involve automatic
dynamic enabling and disabling of login lines.  Although this
seems feasible, I think it could be quite confusing for users
attempting to log in on a line which is sometimes available and
sometimes not.  The "ttystate" command has the virtue of being
simple and deterministic.


Paul Kleppner
VenturCom, Inc.
{harvard,mit-eddie}!cybvax0!vcvax1!paul