BRENT@uwovax.UWO.CDN.UUCP (06/12/87)
We are thinking about getting DECservers (yes, I've queried this one before, but not this aspect). We also have a GANDALF PACX, so the 200's are needed for modem control. I've looked at the User Guide, and frankly, the user can do too much to "his" port, and leave it around for the next unsuspecting connection. I'd like to limit (or inhibit entirely) the following "user" functionality: LOCK, SET/DEFINE PORT PARITY/FLOW/CHARACTER, and perhaps others, since it appears that these could get left around. Am I misreading somethig? Or are these concerns justified? Thanks as always. Brent. -- Brent Sterner *********************** Lord Protector, d i g i t a l Systems * * Computing & Communications Services * b r i n g * Natural Sciences Building * b a c k * The University of Western Ontario * the other 4 bits * London, Ontario, Canada N6A 5B7 * * Telephone (519)661-2151 x6036 *********************** Network <BRENT@uwovax.UWO.CDN> ! VAX CLUSTER <A105@UWOCC1.BITNET> ! IBM 4341 (last resort)
SYSMSH@ULKYVX.BITNET (06/14/87)
> We are thinking about getting DECservers (yes, I've queried >this one before, but not this aspect). We also have a GANDALF >PACX, so the 200's are needed for modem control. I've looked at >the User Guide, and frankly, the user can do too much to "his" >port, and leave it around for the next unsuspecting connection. > I'd like to limit (or inhibit entirely) the following "user" >functionality: LOCK, SET/DEFINE PORT PARITY/FLOW/CHARACTER, >and perhaps others, since it appears that these could get left >around. We've got several DECserver-200's connected to a terminal switch. Modem control is enabled. I ran into the same problems with the DEFINE and LOCK commands. Users were able to alter the permanent characteristics of any random port. LOCK would also not clear out if the line was dropped from the switch. I was forced to disable LOCK and patch out the DEFINE command in the PR801ENG.SYS file. Thats about your only option other than an SPR. If you are interested in the technique drop me a mail msg. I allow the users to do SET commands because they do clear out after the line drops. Someday I'll submit an SPR for making DEFINE PORT an optionally privileged command and making a LOCKED port unlock upon line drop. Mark Hittinger/systems programmer iv/ocis south center University of Louisville, Louisville, Ky 40292 sysmsh@ulkyvx.bitnet sysmsh%ulkyvx.bitnet@wiscvm.wisc.edu
DHASKIN@CLARKU.BITNET (Denis W. Haskin, Manager, Technical Services) (06/16/87)
> Date: Fri, 12 Jun 87 09:02:05 EST > From: Brent Sterner <BRENT@UWOVAX.UWO.CDN> > Subject: DECserver query > > We are thinking about getting DECservers (yes, I've queried this one > before, but not this aspect). We also have a GANDALF PACX, so the 200's > are needed for modem control. I've looked at the User Guide, and frankly, > the user can do too much to "his" [you mean "his or her", right?] port, and > leave it around for the next unsuspecting connection. Well, we have DECserver 100s and 200s but we are not currently using the 200s for modem ports. As local ports, a LOG command is sufficient to set the port to wait for the next connection at *default* settings, and (unless disabled) it will autobaud and stuff like that. I don't know exactly how they behave under modem control; when the connection is broken (that is, carrier is dropped) my assumption would be that a LOGOUT would take effect and the server would be back in its default state. > I'd like to limit (or inhibit entirely) the following "user" functionality: > LOCK, SET/DEFINE PORT PARITY/FLOW/CHARACTER, and perhaps others, since it > appears that these could get left around. You can do it; I think it would DEF BREAK DISABLE (to disallow access to the Local> prompt) and DEF AUTOCONNECT or some such thing. We've done it here. % Denis W. Haskin Manager, Technical Services % % ----------------------------------------------------------------------- % % DHASKIN@CLARKU.BITNET Office of Information Systems (617)793-7193 % % Clark University 950 Main Street Worcester MA 01610 % % % % "Anyone who _moves_ before Most Holy comes back out will spend the rest % % of eternity sipping lava through an iron straw." - Cerebus %
AE@DAL.BITNET (Aidan Evans, Dalhousie University) (06/25/87)
We have DECserver 200/MC's connected to a Develcon Develswitch. Some of the parameters set for each port include: Autobaud enabled, Autoconnect enabled, Autoprompt enabled, Inactivity logout enabled, Modem control enabled, Security enabled In order to use the DEFINE command, or to SET a port other than the one to which you are connected, or to SET certain port characteristics (e.g., to disable security) you must have first entered a "SET PRIVILEGE" command, which prompts for a password. There is a documented default password given in one of the manuals; that password has of course been changed with a "SET PASSWORD" command on all the servers. On our servers, a you can change characteristics of the port to which you are currently connected; these changes disappear when you logout of the port. Logout from the port is NOT synonymous with logging out of VMS. After VMS logout you are still connected through the Develswitch to the server port. So that our users don't have to remember to logout of the server as well as VMS, we have set the server "inactivity timeout" to the minimum allowed, so that after one minute of no activity at the "Local>" prompt, and with no active terminal sessions, the server logs out the port. As for the LOCK command, if a port is locked, disconnecting the terminal from the Develswitch disconnects from the server, and the lock is released. This is useful if you have forgotten the lock password you used. Of course nothing is perfect. I have noticed that the "inactivity logout" seems to be inconsistent. Sometimes it takes a full minute, but it does range downwards to 10 or 20 seconds, or sometimes immediately. Actually, we would prefer to be able to specify the timeout in seconds; on our Control Data CYBER you get ten seconds before "inactivity logout".