public access unix accounting & admin

[Karl Denninger]

In article <2484 at sud509.ed.ray.com> heiser at tdw201.ed.ray.com writes:
>This is a question for those of you running public-access Unix systems,
>especially if they're on Esix or other Sysvr3 386 systems.
>
>Is there an accounting program floating around to keep track of 
>"subscription" users?  If a user has paid a subscription for 6 months, what
>method do use to (a) notify the user when the subscription is nearing
>its end, and (b) notify the admin of that fact, and (c) put the account
>in limbo (chahnge the passwd) until such time as the user pays up again.
>I guess it wouldn't be too hard to write something to do this ... but why
>re-invent the wheel...  
>
>Also, is there a program around to allow users to set up their own 
>shell accounts?  I'm not sure I'll even be doing things this way, but it'd
>be interesting to know for future reference.  What I actually plan to do is
>to let all new users login via the bbs, then leave a message if they want
>to have shell access.  Any comments on this?

I have a program called "subscript" which does this.  It uses a file in
/etc, called "subscript", and a program called "validate" which is called
during the user's .profile.  This works for bourne and korn shells.

It does not, however, work for csh.  To fix this, I hacked the program, and
made it smarter.  If it is installed as a login shell (it knows because it's
ppid is 1 in that case) then it will do the check, and if it succeeds
execute "shellname.real".  You move the real shell to that name, and all is
ok.  If it is executed as a subshell it just exec's "shellname.real" with
the original arguments, and doesn't bother with the checks.  This way it
doesn't interfere with people's scripts and system functions.  It also
ignores any UID < 1000 (so you can have "system" accounts which are not
checked).  Additionally there is a bypass flag in the subscription file
which causes the validater to always return success without checks.

Works great.

The validate program prints the expiration date of a user's subscription on
the termianl when it runs, so everyone knows where they stand every time
they log on.  It also has the ability to postdate an account (ie: I enter
one today that comes active next Friday).  

I could probably be convinced to make it available for a small bribe :-)
Nielsen didn't have anything to do with this; I wrote it long before coming
to work here.

--
Karl Denninger	AC Nielsen
kdenning at ksun.naitc.com
(708) 317-3285
Disclaimer:  Contents represent opinions of the author; I do not speak for
	     AC Nielsen on Usenet.