HP3000-L Archives

August 2003, Week 5

HP3000-L@RAVEN.UTC.EDU

Options: Use Monospaced Font
Show Text Part by Default
Show All Mail Headers

Message: [<< First] [< Prev] [Next >] [Last >>]
Topic: [<< First] [< Prev] [Next >] [Last >>]
Author: [<< First] [< Prev] [Next >] [Last >>]

Print Reply
Subject:
From:
"Paul H. Christidis" <[log in to unmask]>
Reply To:
Date:
Fri, 29 Aug 2003 09:00:20 -0700
Content-Type:
text/plain
Parts/Attachments:
text/plain (85 lines)
Josh's suggestion will not work for all cases either.  HPSTDIN_NETWORK_NODE
only is set for  NS/VT type connections and not for telnet or DTC types
while all DS type connections will show up with the same 'network address'
and 'network node'.

Regards
Paul Christidis

HP-3000 Systems Discussion <[log in to unmask]> wrote on 08/28/2003
11:38:45 PM:

> Hello Listers,
>
> Use HPSTDIN_NETWORK_NODE to ensure only one logon per computer/user. It
> would require all clients to have node names or you could switch to key
off
> ip address if the node name is empty. This would require node names in
> remote sites sharing one ip. You could also have your key be dynamic
based
> on the value of ip address, this could be used for remote sites if you
> wanted to key off of ip address for your local site. To change node name
on
> windows (NT, 2000, XP yes not sure about 98/ME) you need to reboot
therefore
> logged off from the 3000.
>
> When a user logs on
> Check if a file with their node name exists if not then
> Build it and write the current session to it and allow the logon.
> If it does exist  and eof>0 then
> Read session number and check if the session is logged on
> If not then write the current session to the file and allow the logon
> If it is logged on then deny logon.
>
> Josh
>
> -----Original Message-----
> From: Jeff Vance [mailto:[log in to unmask]]
> Sent: Friday, August 29, 2003 1:20 AM
> To: [log in to unmask]
> Subject: Re: [HP3000-L] Limiting user sessions
>
>
> > > # Test if this user.acct session is already logged on
> > > # This user.acct is not logged on, check IP address under
> > > # different user
> > > # Note: each session's IP address is kept under /usr/ip/xx.xx.xx.xx
> > >    # build the IP addr file to capture this user's IP address
> > >   build /tmp/ip/!hpremipaddr;rec=-1,,f,ascii;disc=1
> > > ...
> >
> > The only fly-in-the-ointment I see is how does this file "go away"
> > when you log off?  If you rely on a BYE udc, you could get into
> > situations where a user gets ABORTed, but the file would still be left
> > around, and thus the user couldn't [legitimately] log back on.
>
> Good point! My approach works better if the logon UDC traps the user into
> one or more apps but does not let the user out to the CI, etc. This could
be
> a situation where the NEWCI command is useful.  Short of that, there was
a
> suggestion of using LISTFILE ci.pub.sys,8 and parsing out the remote IP
> addresses.
>
> > Secondly, what about "aggregators" [also known as "NAT"'s] where
> > several users are funneled through the same [external to them] IP
> > address [such as putting a remote office on a DSL line...]
>
> Another good point, and this time it seems the LISTFILE,8 approach fails
> too... If truly different users share the same IP address then one cannot
> key of off hpremipaddr. I wonder if any of the HPSTDIN_@ or HPVT_@
variables
> would provide differentiation?
>
> No good answer yet...  Jeff
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *
>
> * To join/leave the list, search archives, change list settings, *
> * etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

* To join/leave the list, search archives, change list settings, *
* etc., please visit http://raven.utc.edu/archives/hp3000-l.html *

ATOM RSS1 RSS2