topic Re: Killing users using the username in Operating System - OpenVMS

Killing users using the username

Atul Subhedar — Mon, 09 Apr 2007 14:45:35 GMT

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

Re: Killing users using the username

Hein van den Heuvel — Mon, 09 Apr 2007 15:07:56 GMT

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.

Re: Killing users using the username

Robert Gezelter — Mon, 09 Apr 2007 15:14:56 GMT

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

Re: Killing users using the username

Atul Subhedar — Mon, 09 Apr 2007 15:37:16 GMT

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

Re: Killing users using the username

EdgarZamora_1 — Mon, 09 Apr 2007 15:58:05 GMT

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.

Re: Killing users using the username

Robert Gezelter — Mon, 09 Apr 2007 16:01:41 GMT

Atul,

I would concur with what Ed posted.

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

Re: Killing users using the username

Peter Zeiszler — Mon, 09 Apr 2007 18:42:15 GMT

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.

Re: Killing users using the username

John Gillings — Mon, 09 Apr 2007 18:54:25 GMT

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 ;-)

Re: Killing users using the username

Atul Subhedar — Mon, 09 Apr 2007 19:13:18 GMT

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

Re: Killing users using the username

Jon Pinkley — Mon, 09 Apr 2007 20:44:06 GMT

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

Re: Killing users using the username

Amit Phadnis — Tue, 10 Apr 2007 05:48:22 GMT

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.

Re: Killing users using the username

Wim Van den Wyngaert — Tue, 10 Apr 2007 06:08:25 GMT

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

Re: Killing users using the username

Jim_McKinney — Tue, 10 Apr 2007 06:09:47 GMT

> 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.

Re: Killing users using the username

Amit Phadnis — Tue, 10 Apr 2007 06:27:35 GMT

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

Re: Killing users using the username

Jon Pinkley — Tue, 10 Apr 2007 06:40:21 GMT

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

Re: Killing users using the username

Robert Gezelter — Tue, 10 Apr 2007 07:33:55 GMT

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

Re: Killing users using the username

EdgarZamora_1 — Tue, 10 Apr 2007 08:41:19 GMT

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

Re: Killing users using the username

Amit Phadnis — Wed, 11 Apr 2007 01:56:20 GMT

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.

Re: Killing users using the username

Jon Pinkley — Wed, 11 Apr 2007 02:54:11 GMT

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

Re: Killing users using the username

Amit Phadnis — Wed, 11 Apr 2007 07:12:37 GMT

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.