Capturing user log-on and log-off activity from Datastage
Moderators: chulett, rschirm, roy
Capturing user log-on and log-off activity from Datastage
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
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
Mark Winter
<i>Nothing appeases a troubled mind more than <b>good</b> music</i>
<i>Nothing appeases a troubled mind more than <b>good</b> music</i>
-
- Premium Member
- Posts: 138
- Joined: Wed Jul 16, 2008 9:51 pm
- Location: Kolkata
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.
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.
TONY
ETL Manager
Infotrellis India
"Do what you can, with what you have, from where you are and to the best of your abilities."
ETL Manager
Infotrellis India
"Do what you can, with what you have, from where you are and to the best of your abilities."
-
- Participant
- Posts: 3337
- Joined: Mon Jan 17, 2005 4:49 am
- Location: United Kingdom
Hi Tony,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.
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
Mark Winter
<i>Nothing appeases a troubled mind more than <b>good</b> music</i>
<i>Nothing appeases a troubled mind more than <b>good</b> music</i>
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
IBM Software Services Group
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
Any contribution to this forum is my own opinion and does not necessarily reflect any position that IBM may hold.
-
- Premium Member
- Posts: 138
- Joined: Wed Jul 16, 2008 9:51 pm
- Location: Kolkata
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
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
-
- Participant
- Posts: 54607
- Joined: Wed Oct 23, 2002 10:52 pm
- Location: Sydney, Australia
- Contact:
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.
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.
Mamu Kim
-
- Premium Member
- Posts: 138
- Joined: Wed Jul 16, 2008 9:51 pm
- Location: Kolkata
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 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:
Code: Select all
HISTSIZE=10000
mkdir -p $HOME/.history
HISTFILE=$HOME/.history/.history.$(date +%Y%m%d.%H%M%S).$$
Second Method is to cross track user activity.
Code: Select all
HISTSIZE=10000
mkdir -p $HOME/.history
WHO2=`w | awk '(\$2=="'$TTY'"){print \$1}'`
HISTFILE=$HOME/.history/.history.${WHO2}.$(date +%Y%m%d.%H%M%S).$$.${LOGNAME}
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.
TONY
ETL Manager
Infotrellis India
"Do what you can, with what you have, from where you are and to the best of your abilities."
ETL Manager
Infotrellis India
"Do what you can, with what you have, from where you are and to the best of your abilities."
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.
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.
Mamu Kim