Re: Off-the-wall TCPware/Multinet Question - VMS

This is a discussion on Re: Off-the-wall TCPware/Multinet Question - VMS ; Hi, >In article , Hans Bachner writes: >>David J Dachtera wrote: >> >>> In both UCX and TCPware, TELNET processes are created by the Job >>> Controller. Thus, TELNET users cannot log in at VMS startup until STDRV >>> has ...

+ Reply to Thread
Results 1 to 2 of 2

Thread: Re: Off-the-wall TCPware/Multinet Question

  1. Re: Off-the-wall TCPware/Multinet Question

    Hi,

    >In article , Hans Bachner writes:
    >>David J Dachtera wrote:
    >>
    >>> In both UCX and TCPware, TELNET processes are created by the Job
    >>> Controller. Thus, TELNET users cannot log in at VMS startup until STDRV
    >>> has done the initial SET LOGINS/INTERACTIVE command. By contrast, in
    >>> Multinet, TELNET processes are created by the MUTLINET_SERVER, and
    >>> logins become possible immediately after Multinet is started, even
    >>> before the startup process has finished (applications may not be ready
    >>> for logins, user disks may not be MOUNTed yet, ...).

    >>
    >>
    >>There may be a solution for this one. After UCX startup, you could add
    >>$ SET LOGIN /INTERACTIVE=1
    >>$ SET LOGIN /INTERACTIVE=0
    >>This will at least allow users with OPER privilege to login from this
    >>point on, while keeping standard users away from the system until the
    >>startup driver allows logins as usual.

    >
    >And I thought DJD meant it the other way.
    >No login for Multinet TELNET until SET LOGIN is done (eg. in SYSTARTUP_VMS)
    >and not as early as now (when maybe even disks are still unmounted)...


    That would be my reading of David's comments too.

    However I've never found this to be an issue either way at the sites I
    manage. I suppose you could avoid it by doing the SET LOGIN/INTER
    command(s) above for MultiNet too, although this wouldn't prevent access by
    privileges users.

    Another option would be to carefully manage the MULTINET:SERVICES.MASTER_SERVER
    file so that MultiNet starts up with TELNET disabled. But it would be
    rather messy to get consistently right.

    Regards,

    Jeremy Begg

    +---------------------------------------------------------+
    | VSM Software Services Pty. Ltd. |
    | http://www.vsm.com.au/ |
    | "OpenVMS Systems Management & Programming" |
    |---------------------------------------------------------|
    | P.O.Box 402, Walkerville, | E-Mail: jeremy@vsm.com.au |
    | South Australia 5081 | Phone: +61 8 8221 5188 |
    |---------------------------| Mobile: 0414 422 947 |
    | A.C.N. 068 409 156 | FAX: +61 8 8221 7199 |
    +---------------------------------------------------------+

  2. Re: Off-the-wall TCPware/Multinet Question

    Jeremy Begg wrote:
    >
    > Hi,
    >
    > >In article , Hans Bachner writes:
    > >>David J Dachtera wrote:
    > >>
    > >>> In both UCX and TCPware, TELNET processes are created by the Job
    > >>> Controller. Thus, TELNET users cannot log in at VMS startup until STDRV
    > >>> has done the initial SET LOGINS/INTERACTIVE command. By contrast, in
    > >>> Multinet, TELNET processes are created by the MUTLINET_SERVER, and
    > >>> logins become possible immediately after Multinet is started, even
    > >>> before the startup process has finished (applications may not be ready
    > >>> for logins, user disks may not be MOUNTed yet, ...).
    > >>
    > >>
    > >>There may be a solution for this one. After UCX startup, you could add
    > >>$ SET LOGIN /INTERACTIVE=1
    > >>$ SET LOGIN /INTERACTIVE=0
    > >>This will at least allow users with OPER privilege to login from this
    > >>point on, while keeping standard users away from the system until the
    > >>startup driver allows logins as usual.

    > >
    > >And I thought DJD meant it the other way.
    > >No login for Multinet TELNET until SET LOGIN is done (eg. in SYSTARTUP_VMS)
    > >and not as early as now (when maybe even disks are still unmounted)...

    >
    > That would be my reading of David's comments too.
    >
    > However I've never found this to be an issue either way at the sites I
    > manage. I suppose you could avoid it by doing the SET LOGIN/INTER
    > command(s) above for MultiNet too, although this wouldn't prevent access by
    > privileges users.
    >
    > Another option would be to carefully manage the MULTINET:SERVICES.MASTER_SERVER
    > file so that MultiNet starts up with TELNET disabled. But it would be
    > rather messy to get consistently right.


    I'd say "untidy", since it could be made to depend on the very end of
    SYSTARTUP_VMS doing something to enable TELNET if Multinet was even
    started.

    BTW: I can't seem to train my fingers to type "Multinet" instead of
    "Mutlinet". Any chance you guys could rename the product? ;-)

    --
    David J Dachtera
    dba DJE Systems
    http://www.djesys.com/

    Unofficial OpenVMS Hobbyist Support Page:
    http://www.djesys.com/vms/support/

    Unofficial Affordable OpenVMS Home Page:
    http://www.djesys.com/vms/soho/

    Unofficial OpenVMS-IA32 Home Page:
    http://www.djesys.com/vms/ia32/

    Coming soon:
    Unofficial OpenVMS Marketing Home Page

+ Reply to Thread