Hi All,
I am requested to set-up datastage in such a way that each of our developers logs-in to the datastage clients with their individual unix log-in account, but that all unix objects created/modified by them (or the executed jobs/routines) should be owned by user dsadm.
The objective is to eliminate the usage of shared unix accounts for logging into a client, but that when a individual developer's unix account is later deleted (because that developer has left the project) no objects are unexpectedly deleted as a result. The proposed solution is to make dsadm the owner, so that when the developer's account is deleted no datastage objects are owned by it.
I've had a trawl with Search but am not able to find any topics that address my request.
Is it possible to set-up datastage this way, or is that a silly question?
thanks,
katz
Ownership of UNIX objects created with datastage
Moderators: chulett, rschirm, roy
DataStage is setup normally so all developers are in one UNIX group like dstage including dsadm. This group needs to read and write to each others files so the umask needs to be 002. The group id is set on these directories so that each user in this group can delete the other users files. So there is no conflict.
You can delete that user and the only issue is the files are owned by an unknown user. All UNIX files have a uid associated with them. This uid is the UNIX user id that is in /etc/passwd unless your UNIX ids are set at the domain level and shared to this server then the uid exists on the domain server. LDAP and all these other terms for this concept basically all work the same. There exists a master /etc/passwd which is shared across multiple UNIX machines.
Normally these users are not deleted but have their password changed so this user can no longer log in. Whether you delete or change the password then DataStage will continue to work fine. If you want to find all the programs which need to have setuid set then good luck. There are lots of them. This is a bigger security problem than leaving these all with bad uids.
My suggestion is this is a lot of work for no benefit. If you really want to do this then create a cron job owned by root which does a
chown -R dsadm ProjectDir
for every project directory. Never do this in the DSEngine directory.
You can delete that user and the only issue is the files are owned by an unknown user. All UNIX files have a uid associated with them. This uid is the UNIX user id that is in /etc/passwd unless your UNIX ids are set at the domain level and shared to this server then the uid exists on the domain server. LDAP and all these other terms for this concept basically all work the same. There exists a master /etc/passwd which is shared across multiple UNIX machines.
Normally these users are not deleted but have their password changed so this user can no longer log in. Whether you delete or change the password then DataStage will continue to work fine. If you want to find all the programs which need to have setuid set then good luck. There are lots of them. This is a bigger security problem than leaving these all with bad uids.
My suggestion is this is a lot of work for no benefit. If you really want to do this then create a cron job owned by root which does a
chown -R dsadm ProjectDir
for every project directory. Never do this in the DSEngine directory.
Mamu Kim