[Info-vax] prevent user login during and after startup

[VAXman- at SendSpamHere.ORG]

In article <b41c5e9b-b189-4eca-ade8-3500f466790e at googlegroups.com>, Bob Gezelter <gezelter at rlgsc.com> writes:
>On Tuesday, September 16, 2014 2:33:54 PM UTC-4, bdho... at acm.org wrote:
>> DEC TCP/IP 4.2 (UCX), VAX VMS 7.1, emulated VAX 4000-105A (Charon-VAX)
>>=20
>>=20
>>=20
>> When VMS boots, the UCX services are enabled and running.  The users appa=
>rently are chomping at the bit to login and milliseconds after telnet is st=
>arted, they are logging-in.  Sometimes I have system stuff to do, so I ente=
>r a "ucx disable service telnet" ... then I get complaints about users bein=
>g disconnected and losing work.
>>=20
>>=20
>>=20
>> How can I boot the system so that users can't login?
>>=20
>>=20
>>=20
>> The system manager and operators (right now: me, myself, and I, the three=
> stooges) use the operator console, serial ports, or DECnet to connect to t=
>he system, all users connect with telnet. =20
>>=20
>>=20
>>=20
>> I tried "set logins/interactive=3D0" but some users have OPER privilege. =
> (Loud on-going discussion about users with privileges that they don't need=
>, don't understand, but won't allow to be removed because it makes them fee=
>l important.  I'm considering severely beating my predecessors that "fixed"=
> access problems by adding privs to user accounts ... anyone out there need=
> a VMS system manager / programmer / analyst?)
>>=20
>>=20
>>=20
>> I looked at disabling telnet at startup, but apparently UCX has only "set=
> configuration enable service", there is no "set configuration disable serv=
>ice".  If telnet was disabled on startup, then I could do an "ucx enable se=
>rvice telnet" when needed.  Bugger!
>>=20
>>=20
>>=20
>> The UCX command "set service/limit=3D0 telnet" or "set service/reject=3Dh=
>osts=3D* telnet" looked promising, but that changes the permanent database =
>and apparently would have to be done and undone each startup.
>>=20
>>=20
>>=20
>> I'd rather not totally disable the Ethernet connection or all UCX service=
>s as I want the NTP service to get the clock synced.  The clock (and the re=
>st of the hardware) is emulated so it does not keep time when shutdown.  Th=
>ere are processes that use timestamps and the clock needs to get corrected =
>quickly.
>>=20
>>=20
>>=20
>> Ideally I don't want the users to have any window to login before I'm rea=
>dy for them to login.  The system should be ready for the users and a simpl=
>e command should open the floodgates.  Am I looking at this wrong and shoul=
>d try a different approach?  Is there a command I overlooked?  Is there sha=
>reware or DECUS tape utility that'll help?
>>=20
>>=20
>>=20
>> I guess I could do a "show service telnet/full/permanent", record the res=
>ults, delete the telnet service from the permanent database, then manually =
>add the telnet service and options to the permanent database but not enable=
> it.  Has anyone tried something like this?
>
>First, I must note that I am offsite without my laptop, so I do not have ac=
>cess to check some things.
>
>An approach that I have used in several similar situations is similar to wh=
>at Dan has mentioned: code inserted into SYS$MANAGER:SYLOGIN.COM to check s=
>everal conditions prior to allowing a login to continue.
>
>In this case, that would work.
>
>In any event, my recollection is that the code that actually does the start=
>up of telnet is in SYS$STARTUP:TCPIP$STARTUP.COM. I would have to sit down =
>with a listing (which I cannot do where I am at the moment), but it should =
>be straightforward to suppress the starting of telnet from that point.
>
>At a later point in the startup, when telnet use is acceptable, one can sta=
>rt telnet by invoking SYS$MANAGER:TCPIP$TELNET_STARTUP.COM.

How about an alternate SYSUAF.DAT with ***ONLY*** those accounts you would
allow to access the system prior to your "ssytem" work?  Then, once you have
things established as you'd like, $ DEFINE SYSUAF SYS$SYSTEM:FULL_SYSUAF.DAT
or whatever you'd call/rename your current full SYSUAF.DAT.

Personally, proper system startup should not require you to have to perform
any manual "system schtuff".  If you're having issues with network login at
the inapporpriate time, move your TCP/IP, TELNET, SSH, whatever startups to
a later time.  

-- 
VAXman- A Bored Certified VMS Kernel Mode Hacker    VAXman(at)TMESIS(dot)ORG

I speak to machines with the voice of humanity.