DSXchange

Hi all,

As part of an audit necessity, we're obliged to begin capture of when users log-on to and log-off from the Datastage engine. Whilst we are looking at the operating system side to capture log-on and log-off activities, I need to address the same within Datastage itself and it would additionally be useful to capture details of:

-Date/Time of log-on
-Date/Time of log-off
-User ID
-Server/Project

I've been looking at Universe tables such as DS_AUDIT, UV.LOGINS, UV.ACCESS to try and determine if/where this information exists but to no avail as yet. Can anyone help on this please?

I'd also be interested to know the availability/limitations in this concern across the v7x and v8x versions so I can cater for these accordingly.

Cheers,

Mark

Hi Mark,

Did you try enabling the server trace option from the Administrator Client?

And at unix server level also we can capture the log file I think, because we are doing it in our AIX server.

What about the same user logging in via terminal services into the server machine ? Does that count as a login (and logout following it) ?

V8 will be different as you can map users.

antonyraj.deva wrote:Hi Mark,

Did you try enabling the server trace option from the Administrator Client?

And at unix server level also we can capture the log file I think, because we are doing it in our AIX server.

Hi Tony,

Which 'log file' are you referring to here please? Our o/s is also AIX.

I haven't yet looked at server tracing being enabled, but I believe that may well degrade performance which would be of concern for a production system. I'll look into that suggestion too though.

Thanks

None of this information is available in the "UniVerse" tables. (You can search DSXchange for DS_AUDIT; DataStage does not use UV.ACCESS and UV.ACCOUNT is the central registry of existence and location of projects.) User login is recorded in operating system or Active Directory.

Hi Mark,

I need to check with the AIX administrator about the log file's exact name.

Will let you know by Monday.

Thanks all, I'll look at capturing this information solely at o/s level instead as it isn't available in the Datastage environment.

Why not use the dsenv file within the dsengine directory.

You should be able to add some type of audit information at this level and then consolidate the information. The only downside would be if you use a single userid as a default user on the system, then the unix ID would be the same.

Regards,

Ray Daignault

The dsenv script must not put any unexpected information onto stdout, and probably does not necessarily capture telnet connections to the server.

Your .profile or dsenv does not execute when you connect to DataStage. Neither does stdprofile because ksh or sh is not invoked. You are connected directly to DataStage. The dsenv script is executed once at start up of DataStage not once per user connection.

There is almost no way to trap this except at the OS. You can sort of see connections in DS_AUDIT when developers save their work. If all they do is look at jobs or run Director then you cannot tell they connected using this table.

Hi Kim,

I've setup Oracle tns information in the dsenv file. This file is executed for all datastage jobs, and I'm pretty sure the client as well.

Ray D

Hi Mark,

The following are the few methods to track user activity at the AIX O/S level.

You can specify in the user's .history file in the /etc/profile with a few lines like these:
This would keep 10,000 events in a uniquely named history files with the date they logged in included in the name of the file.[/color]

Second Method is to cross track user activity.

The "WHO2" is set to the name of the user the person logged on to the box as. The "LOGNAME" is on every AIX machine (I think) and is set to the name of the user you are currently logged in as.

When your history files are created, they will contain your remote login name, the user you did a "su" to, and the date they were created. This makes for easier tracking.

Do not forget put those commands in the /etc/history file.[/color]

The only constraint in these methods is that the respective users can view their own .history files and delete it, thus removing the trace.

The history file is never used when you connect to DataStage because you never log into UNIX using Korn or Bourne shells.

Ray D, it is my understanding that dsenv is inherited from start up and not when people connect to DataStage. That is why if you change it you need to shutdown and restart DataStage.