bugoff2@ucbtopaz.CC.Berkeley.ARPA (J. Bradley) (07/24/85)
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. 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. Again as a purely academic question: is the trick done in the kernel, "/unix", or in "init", or where? J. Bradley
paul@vcvax1.UUCP (paul) (07/25/85)
> 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
rad@faron.UUCP (Richard A. Dramstad) (07/27/85)
In article <1029@ucbtopaz.CC.Berkeley.ARPA> bugoff2@ucbtopaz.CC.Berkeley.ARPA (J. Bradley) writes: >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. > ... >Again as a purely academic question: is the trick done in >the kernel, "/unix", or in "init", or where? > >J. Bradley According to some notes I took at the Portland BSD4.3 internals course, Ultrix uses BSD's quota mechanism to enforce AT&T binary license restrictions. Dick Dramstad
kre@ucbvax.ARPA (Robert Elz) (07/30/85)
> According to some notes I took at the Portland BSD4.3 internals > course, Ultrix uses BSD's quota mechanism to enforce AT&T binary > license restrictions. That's true, but "misuses" might be a better word. This raises a question I have never known the answer to. What is a "user" for the purposes of the user count on a binary licenced system. The quota stuff counts uid's with active processes, so that's what DEC has defined a user to be. (On a system licenced for '8 users' the same person can log in 200 times if there are enough tty lines or net ports available). (I believe that DEC add 2 to the number, one for "root" and one spare for random daemons). Another scheme would be to count reead/write opens of tty lines. I believe that plexus does this (probably others, maybe its unisoft). That means that lots of users can log in, start a background process and log out, allowing another user to use the vacated tty line, so there are far more users running processes than the cpu is licenced for. (But not more logged in). Disadvantage of this scheme is that you can't enable "getty"'s on more lines than you're icenced for, even if they won't all be used at once. (The DEC quota scheme doesn't have that restriction). This also doesn't seem to handle net logins at all. So, does anyone know what a "user" is ?? Robert Elz ucbvax!kre kre@ucb-vax.berkeley.edu
mash@mips.UUCP (John Mashey) (08/02/85)
Robert Elz ucbvax!kre kre@ucb-vax.berkeley.edu writes: > (But not more logged in). Disadvantage of this scheme is that you > can't enable "getty"'s on more lines than you're icenced for, > even if they won't all be used at once. (The DEC quota scheme > doesn't have that restriction). This also doesn't seem to handle > net logins at all. > > So, does anyone know what a "user" is ?? > Hard to tell. When I was at Convergent, we settled on a scheme whereby the kernel had a hard-coded constant of the max number of users. Login was tweaked to compare the current number of users to the limit and tell somebody they couldn't login due to exceeding the limit. It ignored names ending in "uucp" in the count. [Of course, almost nothing is absolute protection against a knowledgable super-user, but I believe the intent of the ATT license is to make it difficult for the normal system administrator to figure out where the limit is and change it.] This is a fuzzy problem, which exists only due to the peculiarity of a company selling an operating system that runs on so many different machines not under the control ofthe original seller. After all, vendors have been pricing software for years based on the size of the machines [their own, of course]. Counting users is a rough attempt to scale the price of the software to the price of the hardware, and although has its funnies [after all, an SGI IRIS costs a few dollars more than a PC running PC/IX, but both are 1-user systems], its probably as good as any. IT WOULD BE NICE IF SYS V SUPPORTED SOME RELATIVELY STANDARDIZED WAY OF DOING IT, AND THEN WE COULD QUIT WASTING ENERGY BEING INVENTIVE ON THIS PROBLEM. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
lasse@daab.UUCP (Lars Hammarstrand) (08/05/85)
>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 I hope that you are using the "run level field" in /etc/inittab and the "telinit" command indirect via your "ttystate" command, becauce that is what it is should be used for, switching tty lines on and off I mean. It's the second field in /etc/inittab, and the following arguments serve as directives to the "telinit" command that changes the run level and what lines that should be on or off (From the manual) : 0-6 tells "init" to place the system in one of the "run-levels" 0 - 6. (one of the diggits 0-6) a,b,c tells "init" to process only those /etc/inittab file entries having the a, b or c "run-level" set. Q,q tells "init" to re-examine the /etc/inittab file S,s tells "init" to enter the single user enviroment. When this level change is effected, the the virtual system teletype, "/dev/syscon", is change to the terminal from which the command was executed. (Telinit command is used to direct the actions of "init" and can only be run by someone who is superuser or a member of group: sys) My name: Lars Hammarstrand. My company: Datorisering AB, SWEDEN. UUCP: {seismo,decvax,philabs}!mcvax,ukc,unido!enea!daab!lasse ARPA: decvax!mcvax!enea!daab!lasse@berkley.arpa
paul@vcvax1.UUCP (paul) (08/09/85)
> >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. > I hope that you are using the "run level field" in /etc/inittab and the > "telinit" command indirect via your "ttystate" command, becauce that > is what it should be used for, switching tty lines on and off I mean. Absolutely! In fact, the "ttystate" command is just a shell script that edits /etc/inittab and runs the telinit command, after checking that someone is not logged in on the line. It has a few other options too. I would be willing to post a copy to net.sources if there is enough interest. Although ttystate was written for VENIX System V, it should run under any UNIX System V. It is much easier and more reliable than enabling/disabling login lines "by hand." Paul Kleppner VenturCom, Inc. {harvard,mit-eddie}!cybvax0!vcvax1!paul