heiser@tdw201.ed.ray.com (09/20/90)
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?
--
Work: heiser@tdw201.ed.ray.com
{decuac,necntc,uunet}!rayssd!tdw201!heiser
Home(1): bill%unixland.uucp@world.std.com -or- uunet!world!unixland!bill
Public Access Unix Coming Soon!
Home(2): Bill.Heiser@f240.n322.z1.fidonet.org (BBS: 1-508-655-3848)
Other: heiser@world.std.com (Pub. Access Unix)karl@naitc.naitc.com (Karl Denninger) (09/20/90)
In article <2484@sud509.ed.ray.com> heiser@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@ksun.naitc.com (708) 317-3285 Disclaimer: Contents represent opinions of the author; I do not speak for AC Nielsen on Usenet.
epeterso@encore.com (Eric Peterson) (09/21/90)
karl@naitc.naitc.com (Karl Denninger) writes: | 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. I saw a .login/.profile of a user at FSU which was smart enough to do all sorts of things based upon the machine, operating system, and shell it was running under. Basically what it did was run the entire .login or .profile through /lib/cpp each time he logged in, with system-dependent code #ifdef'ed in and out. It took quite a while to log in at times, particularly on a slow system, but it worked ... Eric -- Eric Peterson <> epeterson@encore.com <> uunet!gould!epeterson Encore Computer Corp. * Ft. Lauderdale, Florida * (305) 587-2900 x5208 Real Time: Here and now, as opposed to Fake Time, which is there and then.
stevek@swatty.uucp (Steve Kriesel) (09/22/90)
Please Include me in followups regarding public access accounting.. I am currently in the process of setting up Public Access Unix.. Thankx.... .sig is on vacation
davidsen@sixhub.UUCP (Wm E. Davidsen Jr) (09/22/90)
You can write a portable login which won't take forever, but it will
get complex. I have a profile which sits on a machine and is NFS mounted
on a number of others. Some BSD, some SysV, various CPUs, etc. Figures
out if login is from serial, telnet, or X-terminal.
Lot'sa tests.
--
bill davidsen - davidsen@sixhub.uucp (uunet!crdgw1!sixhub!davidsen)
sysop *IX BBS and Public Access UNIX
moderator of comp.binaries.ibm.pc and 80386 mailing list
"Stupidity, like virtue, is its own reward" -me