Ideas needed for capturing User login data from sys$sylogin.

[Thomas Ritter]

We want to be able to store user login details in a single location( file). We want the username, nodename, IP address if applicable, UAF Owner Field, and of course login time. Ideally we want to run a suitable executable from sys$sylogin and append data to one file. We have typically two thousand online users using the four node cluster.

What would be a good way to capture this information ?

[Hein van den Heuvel]

Thomas, you may want to start by explaining why the standard accountng file is not good enough to gather the data.

Of course you may want to post-process a standard report, or roll your own into an other database later.

hth,
Hein.

[Robert Gezelter]

Thomas,

I concur with Hein, the simplest way to capture that information is to extract it from the accounting file.

It is also far safer, in that the accounting log does not need to be write-enabled for all users. It can be demonstrated to auditors that it is a safe and trustable information source.

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

[John Gillings]

Thomas,

One potential problem with ACCOUNTNG is it's only written when the process *terminates*, so it's not necessarily useful for very long lived processes, or if there is a power failure, system crash.

An alternative to accounting - you can capture logins as LOGIN AUDITs in the audit journal file. These records are written at login time.

If accounting and/or auditing don't do what you need, use a protected subsystem - see the Guide to OpenVMS System Security for details.

Store your files in the subsystem and run a program with the subsystem identifier to write to the log file. This avoids the necessity for making the logfile world writeable.

In a nutshell, it's a way of having files that can only be accessed from a defined set of images. Your users can append the log file from your subsystem image, but otherwise can't even see them.

[Phil.Howell]

The output from DCL "show process" at login, and "show process/acc" at logout may be enough, I don't think you need an executable for this unless login performance is a problem, or you need the data in a custom format.
I would avoid each user writing to a shared log file, I prefer that each process writes to its own log file. You can combine log files later for analysis/audit.

Something like

$ SHOW PROC/OUT=LOGIN'PID5_8'.LOG
$ APPEND/NEW LOGIN'PID5_8'.LOG USER'PID5_8'.LOG
$ DELETE LOGIN'PID5_8'.LOG;*
$
$!!! DO USER PROCESSING HERE
$
$ SHOW PROC/ACC/OUT=LOGOUT'PID5_8'.LOG
$ APPEND/NEW LOGOUT'PID5_8'.LOG USER'PID5_8'.LOG
$ DELETE LOGOUT'PID5_8'.LOG;*

[Thomas Ritter]

We store meta data in the UAF account field. Others will be analyzing the output. A typical record would be something like this

16-Sep-2007 10:00,nodename,userid,uaf account field, IP address.

I'm concerned about record locking or concurrency. Should each node have its onw file or one common file. Ideally one common file.
Users need to be able to call UAF services.

[Martin Hughes]

If you absolutely must have your own logs updated real-time, then you might want to consider setting up a listener on AUDIT_SERVER.

[John Gillings]

Thomas,

> I'm concerned about record locking or concurrency.

For the volume your users could generate (assuming they don't spend all day doing nothing buy logging in and out!) this really can't be an issue. There are many files which, by definition, will take a worse hammering than your log file without seriously impacting performance (consider just SYSUAF and RIGHTSLIST).

I'd recommend a single, cluster wide file. You may consider making it indexed to take advantage of global buffering, and give youself a few keys to assist in analysis (but don't go too far - and try to avoid duplicates).

Depending on the timing and system clocks you may find occasional records apparently out of order - timestamp as a primary key will hide them.

Something you may need to be concerned about is a process opening the file for exclusive access. This could block access to update the file. Simple solution is to have a "keeper" process which opens the file for shared write access and hibernates, holding the file open. This will also keep any global buffers current and improve the performance of file opens. You only need one across the cluster, but it won't hurt if you have one on each node.

That said, I'm sure you can get all the information you want from the audit journal. SMOP to massage it into the format you want.

[Hein van den Heuvel]

Concurrent access to SYSUAF (and RIGHTLIST) is spread by username and restricted mostly to simple updates (last-login, password)

Concurrent access to a log file would typically be keys by binary timestamp and cause maximal contention effects, on top of slow linear growth.
An alternative it to make the (primary) key be a username, but then you are causing constants bucket splits due to continued inserts all over the files.
Both are a lot more expensive than sysuaf access, but it may well be easily sustainable non the less.

Still, I would recommend a simple per-node file shared file. It coudl easily be sequential... but watch it you do NOT want a large buffer size due to pinging between processes. It could readily be a single keyed timestamped indexed file where the indexed file will possibly give useful key and data compression; a readily controllable bucket size; 'pre-ordering' and pre-warning of duplicated (try $PUT, on duplicate increment microseconds, and try put again)

You could roll the per node files up hourly or daily and create create and indexed file with as many 'usefull' additional keys as you like (username+day, node+day+hour?) without excessive incremental costs.


btw... SYSUAF in clusters often have a poor (0%!) XFC cache hit rate due to concurrent write access. Global buffers are highly recommended and will readily score 80% or better hit rate with just a few buffer (20 -100 range).

hth,
Hein.

[Jon Pinkley]

I am not sure what you mean by "Users need to be able to call UAF services."

If you don't want to use the AUDIT facility, and you are only interested in successful logins, then what you propose, "Ideally we want to run a suitable executable from sys$sylogin and append data to one file." will certainly work.

Is your question about what services this executable needs to call the get this information?. Every item you are asking about is in your revised requirements "16-Sep-2007 10:00,nodename,userid,uaf account field, IP address." are available via $getjpi, and do not require any privileges to get. The UAF Owner field (if you are meaning the 31 character field modified by UAF MOD /OWNER="Thomas Ritter") is available via $GETUAI, no privilege needed for a process to get this for its own username.

Specifically $GETJPI items "LOGINTIM","NODENAME","USERNAME","ACCOUNT","TT_ACCPORNAM"

The TT_ACCPORNAM may need some parsing, if all you want it the numeric IP address.

To see what is available with $GETJPI using DCL

Example sys$scratch:userlogin.com

$ logintim = f$extract(0,17,f$getjpi("","LOGINTIM"))
$ nodename = f$edit(f$getjpi("","NODENAME"),"TRIM")
$ username = f$edit(f$getjpi("","USERNAME"),"TRIM")
$ account = f$edit(f$getjpi("","ACCOUNT"),"TRIM")
$ tt_accpornam = f$edit(f$getjpi("","TT_ACCPORNAM"),"TRIM")
$ write sys$output "''logintim',''nodename',''username',''account',''tt_accpornam'"

$ @scr:userlogin
12-APR-2007 05:08,SIGMA,JON,TESTIT,Host: 192.168.172.58 Port: 1235
$

As John Gillings has mentioned, you probably don't want the "single output file" to be accessed without privilege, so you will need to compile this program and link/notraceback, then do one of two things:

1. Install the program with SYSPRV privilege so it can write to the file.

or 2. Create subsystem identifier (uaf add/id/attr=subsystem), then add a subsystem ace to the executatbles ACL, with the subsystem identifier, and protect the "output file" with the subsystem identifier.

Option 2 is considered to be a lower risk than option 1, because the harm that can be done due to holding the identifier is smaller than the harm that can be done with SYSPRV.

RE: worries about concurrency, etc. I don't think you will have any problems, just make user you open the file for shared write access. I am quite certain this is even supported for sequential files although you may want to consider using an indexed file to make looking up specific users easier. And you probably want to append the time to the username (or whatever you use as your keys) so you don't have long chains of duplicate key values. The primary point here it that you first want to see if it is really a problem before you put a lot of resources into optimizing it. John has addressed so things you can do to improve the efficiency as well.

Since you seem resistant to using the auditing facility, can you tell us why? There are certainly advantages to using it, and if you are doing this to satisfy some SOX requirement, then you will more than likely be using it already. And there are already tools to summarize data, etc.

I can understand why the ACCOUNTING file does not fulfill your requirements, since it does not have the ip address, and unless you are using image accounting, does not provide the info until the process logs out. It is also node specific. The Audit journal file does not have these problems.

[Robert Gezelter]

Thomas,

As John noted, the Accounting file is not written till the end of the session. As was also noted, the AUDIT log is written as events happen. An AUDIT listener is only needed in the event that is necessary to process events in real time, if they are merely to be examined later, the audit journal is sufficient.

There is no need for a shared file in this case, and indeed, if this data is being captured for some form of audit requirement, there is a STRONG reason that the file should not be a shared file writeable by all. The Audit log would fit the bill quite handsomely.

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

[Sebastian Bazley]

Depending on the sensitivity/size of the data, why not just log it to OPERATOR.LOG and extract it using a script?

REQUEST/TO=CENTRAL|OPERn "Your message"