Killing users using the username

[Atul Subhedar]

Hi,

Is there any command in openvms which can be used to kill the users using the username?
My requirement:
application team is doing some activity on the server.The activity will be for 2 days. for this period they want me to kill the users other than the 10 specified usernames ( they will be giving me usernames which are required to login at this time)
I can use, SET LOGINS/INTERACTIVE=10 , to limit the number of logins, but I do not know how to kill the users who are wrongly get connected to the server. I can not watch the logins continuously for 2 days.

any advice? any script that will achive this?

Regards,

Atul

[Hein van den Heuvel]

check out:

http://forums1.itrc.hp.com/service/forums/questionanswer.do?threadId=1109426

carefully read and re-read.

>> SET LOGINS/INTERACTIVE=10

bad idea. That's just a number of users irrespective of the usernames.

1) IF you can give safely give OPER priv to the 10 'special' users then you can just use SET LOGINS/INTERACTIVE=0

2) It might be 'good enough' to temporarely edit SYS$MANAGER:SYLOGIN.COM (or whatever central login script your site uses) and put in code like:

[untested!]

$SPECIAL = ",aap,noot,mies,"
$USER = "," + f$getjpi("","USERNAME") + ","
IF F$MODE.EQS.INTERACTIVE .AND.
F$LOC(USER,SPECIAL).EQ.F$LEN(SPECIAL) ...

The above is actually a bit more tricky to get really fool-proof, but probably will do fine for the 2 day issue.


hth,
Hein.

[Robert Gezelter]

Atul,

There are two relatively straightforward ways to do this, both of which involve adding a check to SYS$MANAGER:SYLOGIN.COM. To wit:

- If all of the members in the server team are in the same group (or if all of them hold SYSPRV, which should not be held by normal users), then a check for users who hold SYSPRV would accomplixh more or less what you desire.

- If the members of the server team are not so easily identified, you can create an identifier (e.g., SERVER_TEAM) and grant it to each of the ten users who are allowed to login).

You want to restrict these checks for interactive users, otherwise a variety of background processes are likely to have problems.

I have used this approach often, with no problems.

- Bob Gezelter, http://www.rlgsc.com

[Atul Subhedar]

Hi Bob,
I think 2nd option will be ok in my situation. can u please tell me how I can achive this.I mean any major changes ? I am comparatively new to openvms, basically a unix and storage guy.

Regards,

Atul

[EdgarZamora_1]

1. Use the AUTHORIZE utility to create an identifier called SERVER_TEAM (or whatever name you wanna call it)

UAF> ADD/ID SERVER_TEAM

2. GRANT the identifier to the users you wish to allow login.

UAF> GRANT/ID SERVER_TEAM username

3. Edit SYS$MANAGER:SYLOGIN.COM and add the following at the beginning of the file:

$ IF F$MODE() .EQS. "INTERACTIVE"
$ THEN
$ RIGHTS = F$GETJPI("","PROCESS_RIGHTS")
$ IF F$LOCATE("SERVER_TEAM",RIGHTS) .EQ. F$LEN(RIGHTS)
$ THEN
$ WRITE SYS$OUTPUT "Logins are currently disallowed!"
$ LOGOUT
$ ENDIF
$ ENDIF

4 SET LOGIN/INTER=0

Not foolproof but it should be ok for 2 days of use.

[Robert Gezelter]

Atul,

I would concur with what Ed posted.

- Bob Gezelter, http://www.rlgsc.com

[Peter Zeiszler]

What Edgar has posted is almost exactly what I have had to do on test machines. Setup group ID and then check if the account has it in sylogin and then make sure the sylogin explains why those without the ID are being booted -- the explanation cuts down on calls.

I would also suggest updating announce and welcome to indicate the system is locked to specific users for "test" activites during those days.

Another thing is if you don't want access or activities via alternate connectivity (i.e. ftp, rservices) which would be to make sure the connections check if its the specific people / user names.

[John Gillings]

re: Edgar,

>>$ RIGHTS = F$GETJPI("","PROCESS_RIGHTS")
>>$ IF F$LOCATE("SERVER_TEAM",RIGHTS) .EQ. F$LEN(RIGHTS)

This test can give incorrect results if the identifier you're searching for is a substring of some other identifier, say "NOT_SERVER_TEAM". You need to bracket both the search and searched strings in delimiters to get a positive match. (I also don't like EQ tests, I always code F$LOCATE checks as GE)

$ RIGHTS=","+F$GETJPI("","PROCESS_RIGHTS")+","
$ IF F$LOCATE(",SERVER_TEAM,",RIGHTS) .GE. F$LENGTH(RIGHTS)

Another trick is to use a file with a "reverse" ACL:

LOGOUT.COM
$ WRITE SYS$OUTPUT "Logins disabled, go away"
$ LOGOUT

add an ACL:

(IDENTIFIER=SERVER_TEAM,ACCESS=NONE)
(IDENTIFIER=*,ACCESS=READ+EXECUTE)

Add to SYLOGIN.COM
$ @LOGOUT

Since the server team doesn't have execute access to the procedure, they don't execute the logout command. Everyone else does
(including those users who have BYPASS privilege enabled by default ;-)

[Atul Subhedar]

Hi,

Announce and welcome files message is a nice suggestion and I also like the LOGOUT trick. I will try to implement all these 3-4 options on my test machine.

One more thing , any book available for basic scripting on openvms?

Regards,

Atul

[Jon Pinkley]

Atul,

Thanks for providing the "requirement" along with your specific question. If you hadn't, you would have gotten a lot of responses that would have answered your question about killing a process based on its username, but that wouldn't have led to the correct solution to your problem, which is to prevent the users from ever getting past sylogin.com. It is much better not to allow someone to start working, than to kill them once they have started.

You did not specify whether network or batch jobs for other users should be allowed. The script above checks for interactive jobs only. To prevent batch jobs from running, there are better ways than checking in sylogin, because we can tell VMS to not even start.

You can use a command like

$ show queue/bat/all/by

to show all batch entries in all queues that are not empty.

If you have users with batch jobs that submit themselved to run periodically, you may want to find them, and either put them on hold ($ set entry/hold #) or set them to release after the period has expired ($ set entry/after=data_time).

See help set entry for details.

If you choose to use the logout.com trick, make SURE you have an account that has privilege but doesn't have bypass enabled by default. For example, the SYSTEM account will not be able to log in. I would not use that method, but it will work. Just be sure you understand why it works, and what class of users it will affect. Another reason I don't like that solution is that it will throw an error when access is disallowed.

RE: question about basic scripting. Learn to use search in IRTC and Google, That will get you results to most of your question much quicker than users will respond.

I recommend: OpenVMS User's Manual http://h71000.www7.hp.com/doc/731FINAL/DOCUMENTATION/PDF/OVMS_731_USERS.PDF chapters 13-15. And at least a read of the table of contents, since there is a lot of other useful information in that manual.

Cheers,

Jon

[Amit Phadnis]

Hi,

I have tried the method which EdgarZamora has mentioned.
But after doing that, the username to whom the identifier is granted is also not able to login. Also now as I have set the interactive login=0, so I am not able to login.

So pls suggest on this, how should I go further.

Amit.

[Wim Van den Wyngaert]

I would go for the solution of Hein.
The ACL would give audit alarms when access is refused (we monitor file access failures).

But depending on the usage, also exclude network (and even batch and detached) or users could try to do rsh to start a decterm.

Wim

[Jim_McKinney]

> have set the interactive login=0, so I am not able to login

When the interactive login limit is set to 0 only those users with OPER privilege may log in.

[Amit Phadnis]

Ok, But suppose if any of the user don't have OPER priv, in that case how can we go ahead.

[Jon Pinkley]

I don't understand the recommendation to do a set login/int=0 if the identifer was being used to limit logins. My guess is that he meant either steps 1-3 or step 4, but not both.

In general when testing things like this, never log out after you have made the change, leave yourself logged in, and then test from another terminal/terminal emulator session, for exactly this reason. You don't want to burn the bridge behind you.

Another testing technique is to comment out "dangerous commands". For example, if you are writing something that deletes files, comment the delete out, and run with "SET VERIFY" in effect so you can verify that it would have deleted what you
intended, and not something else.

Now to the problem at hand:

If there isn't a privileged user that is currently logged in, and there are no usernames that have both OPER priv as a default privilege AND the identifier, then you need to download the VMS FAQ and read the section on how to get access via the system console. I think you are going to have to halt the system, do a conversation boot, set the startup to the console terminal, etc. It's all well documented in the FAQ.

Hopefully you do have an account with OPER priv that you granted the identifier to. If so, log into that account and issue

$ set login/int=9999

Then any account that has the identifier will be able to log in.

I would put an additional check in your test that allows any account with OPER priv to bypass the LOGOUT

$ IF F$MODE() .EQS. "INTERACTIVE"
$ THEN
$ RIGHTS=","+F$GETJPI("","PROCESS_RIGHTS")+","
$ IF F$LOCATE(",SERVER_TEAM,",RIGHTS) .GE. F$LENGTH(RIGHTS) .AND. F$PRIVILEGE("NOOPER")
$ THEN
$ WRITE SYS$OUTPUT "Logins are currently disallowed!"
$ LOGOUT
$ ENDIF
$ ENDIF

Good Luck,

Jon

[Robert Gezelter]

Atul,

If you are using my suggestion, you do not use SET LOGIN/INTERACTIVE=0 (as was noted by others, that will prevent even those users who hold the identifier).

As to the check for the identifier, my apology for not missing that quirk in Edgar's suggested code (particularly sincere, as I wrote an article on that precise bug on OpenVMS.org, see "Pitfalls of F$LOCATE and other functions", http://www.openvms.org/stories.php?story=03/03/31/6547431 ).

The solution (as noted in that column) is to bracket the identifier list returned by F$GETJPI with "," characters, and include the "," as part of the string that is being searched for (e.g., search for ",SERVER_MANAGERS,") thus guaranteeing that partial matches do not occur.

- Bob Gezelter, http://www.rlgsc.com

[EdgarZamora_1]

Sorry about the SET LOGIN/INTER=0 that was incorrect.

[Amit Phadnis]

Now I am not able to login with any of the user-id. I have even tried with the system id, but it doesn't allow to login into the sesion.
Now,in such case let me know how can I go further for atleast one login from whichI can recover all the settings back.

Amit.

[Jon Pinkley]

Atul,

Here's one possible way to get in without halting the system.

The check is only checking for interactive logins and the set login/int=0 affects only interactive users..

If you have access to a account with network access allowed, and with delete access to the highest version of sylogin.com that was edited, then you can ftp into the system from that username, and rename the highest version of the sylogin.com you created.

i.e. from a system that has access to the test network. This example will use windows ftp.

C:\>ftp testbox
Connected to testbox.
220 testbox.helpme.com FTP Server (Version 5.1) Ready.
User (testbox:(none)): atul
331 Username atul requires a Password
Password:
230 User logged in.
ftp> ren sys$manager:sylogin.com; sylogin.lockout;*
350 File SYS$SYSROOT:[SYSMGR]sylogin.com; will be renamed.
250 File SYS$COMMON:[SYSMGR]SYLOGIN.COM;54 renamed to SYS$COMMON:[SYSMGR]SYLOGIN.LOCKOUT;54
ftp> quit

At this point, the previous version of sylogin.com should be in effect again, so log in and verify that things are working.

Next time, test a copy of the new portion of the command file interactively before you put in in place.

Fortunately, you did this on a test machine.

I you have no privileged accounts with network access, then you will need to follow the advice I gave before, which was to download the frequently asked questions (FAQ) and read the section about getting access to the system via the system console.

Try the FTP method first.

The commands: login to ftp> prompt then issue the commands: cut and paste starting with "ren"

ftp> ren sys$manager:sylogin.com; sylogin.lockout;*
ftp> quit

Good luck,

Jon

[Amit Phadnis]

Hi,
I have used this ftp method to rename the sylogin.com file, but getting failure message to change in the sys$common directory. It renames in the sys$root directory.
So is it like that, we have to use system id and password during ftp and then rename.

whatever I have mentioned above is result when I am using normal username and password.

Pls let me know, so that I can ask the guy with system id to do this.

Amit.

[Jan van den Ende]

Amit,

>>>
It renames in the sys$root directory.
<<<
That is all right, because SYS$MANAGER is just a logical name, that derives off sys$sysroot.
Because it is not a concealed name, the underlying definition is displayed in the report of the action.

hth

Proost.

Have one on me.

jpe

[EdgarZamora_1]

You seem to have access to a system ID. You can also try ftp using the system ID and password and just "put" an empty SYLOGIN.COM into SYS$COMMON:[SYSMGR]

Good luck.

[Sebastian Bazley]

You can also use the following FTP command to show the dates and locations of the files:

dir sys$manager:sylogin.com

[Jon Pinkley]

Atul>>>I have used this ftp method to rename the sylogin.com file, but getting failure message to change in the sys$common directory. It renames in the sys$root directory.<<<<

Atul,

Did you mean renames or remains? I would expect the file to remain if you were getting an error message.

If your sys$manager directory and sylogin.com file protections are properly set up, only privileged usernames will be able to create, delete or modify a file using ftp. You will need to ask the guy with system id to do it. How did you get the file there in the first place? It should have required a privileged account. If it did not, then something has been misconfigured.

Specifically you will an account with SYSPRV (explicit as a DEFAULT privilege or implicit due to UIC group < MAXSYSGRP), since the file should be protected from world WD access.

The rename command I gave will rename the file into the same directory it originally was in, whether it was the SYS$SPECIFIC:[SYSMGR] directory or the more common SYS$COMMON:[SYSMGR] directory.

I tested the command before I posted it, the example was the output (with names changed).

ren sys$manager:sylogin.com; sylogin.lockout;*


Cheers,

Jon

[Amit Phadnis]

Hi Guys,

Finally I am able to recover the situation, by using system ID at the FTP. Using System ID for FTP and then ren for renaming the sylogin command, renames the file in both the sys$root and sys$common directory.
Hence after that we are able to login into the server.

So now, I am back to my original position. Now again we can move ahead with the solutions suggested for Atul's query.

Thanks a lot

Amit Phadnis