Hi,
We have a requirement where we need to make some components in our development environment as read-only. E.g. some parameter sets, shared containers etc.
I tried exporting these codes from higher environments and importing in development environment by changing the read-only flag in the dsx. But this does not serve the purpose as if someone gets the export and overwrites it, the the component is not read-only anymore.
Is there a way to make only certain components as read-only in development environment such that those cannot be overwritten(re-imported) and cannot be changed by all users.
Thanks
Making some components in Dev Environment as Read-Only
Moderators: chulett, rschirm, roy
Parameter sets:
Log in to unix and CHMOD 640 the parameter file in question (.../project path/ParameterSets/<parametersetname>/<value file>. The owner of the file should be your dsadm user id so that only the admins have writes to modify the file.
Shared Containers:
Not a wise idea to mark them read only. You technically don't have Read/Write control at a job level in datastage. It can be controled at a project level with a protected project. I would not muck around with file permissions at the shared component level. You could run a shared component validation script that would examine the last modified timestamp and who modified it and smack them... Just make sure you have a gold copy of those items in case you need to restore the orriginals.
Log in to unix and CHMOD 640 the parameter file in question (.../project path/ParameterSets/<parametersetname>/<value file>. The owner of the file should be your dsadm user id so that only the admins have writes to modify the file.
Shared Containers:
Not a wise idea to mark them read only. You technically don't have Read/Write control at a job level in datastage. It can be controled at a project level with a protected project. I would not muck around with file permissions at the shared component level. You could run a shared component validation script that would examine the last modified timestamp and who modified it and smack them... Just make sure you have a gold copy of those items in case you need to restore the orriginals.
Thanks Paul
I changed the permissions to 640 on the value files of the parameter sets and parameter Set and observed that dsadm id is not able to access that parameter set while running the job.
So I changed it to 740. Now the job executes fine but import is also successful on the parameter set. We do not want any user to modify or import(over-write) this parameter set. Is there a way to achieve this?
I changed the permissions to 640 on the value files of the parameter sets and parameter Set and observed that dsadm id is not able to access that parameter set while running the job.
So I changed it to 740. Now the job executes fine but import is also successful on the parameter set. We do not want any user to modify or import(over-write) this parameter set. Is there a way to achieve this?
The owner of the file should always have write authority.
Ensure that none of your users are running jobs or have access to your dsadm user id (credential mapping).
The execution of a datastage job needs to have READ access to that file, not write. So ... can you paste the error message you see when you did the 640 setting?
Ensure that none of your users are running jobs or have access to your dsadm user id (credential mapping).
The execution of a datastage job needs to have READ access to that file, not write. So ... can you paste the error message you see when you did the 640 setting?
Hi Guys,
As a friend used to say:
"You can't protect from the keepers"
You can use in another project the sesitive componnents and export (in read only if you like) the executable only to import in the desired project.
Then it should be safe from change since they have not the source code.
As for the chmod command, I don't recommend starting to restrict the access in the OS level for individual componnents, for various reasons.
Having said that, the chmod will use a binary representation of the 3 sets of digits representing a RWX conotation of Read, Write, eXecute permitions for each of the 3 levels of Owner, Group member and Other
so a 640 is transleted to 110100000 in binary representation
the first 3 digits 110 means the owner will have Read,Write,No eXecute permitions.
The group members (100) will only have Read permitions and other users (000) will have no access to the file.
Having that said, a chmod 550 should result in Read+eXecute to both owner and groupd members but render the file not edit-able.
bare in mind that if you use the root password you have all the access to everything regardless... (if not you can always change it)
IHTH (I Hope This Helps),
As a friend used to say:
"You can't protect from the keepers"
You can use in another project the sesitive componnents and export (in read only if you like) the executable only to import in the desired project.
Then it should be safe from change since they have not the source code.
As for the chmod command, I don't recommend starting to restrict the access in the OS level for individual componnents, for various reasons.
Having said that, the chmod will use a binary representation of the 3 sets of digits representing a RWX conotation of Read, Write, eXecute permitions for each of the 3 levels of Owner, Group member and Other
so a 640 is transleted to 110100000 in binary representation
the first 3 digits 110 means the owner will have Read,Write,No eXecute permitions.
The group members (100) will only have Read permitions and other users (000) will have no access to the file.
Having that said, a chmod 550 should result in Read+eXecute to both owner and groupd members but render the file not edit-able.
bare in mind that if you use the root password you have all the access to everything regardless... (if not you can always change it)
IHTH (I Hope This Helps),
Roy R.
Time is money but when you don't have money time is all you can afford.
Search before posting:)
Join the DataStagers team effort at:
http://www.worldcommunitygrid.org
Time is money but when you don't have money time is all you can afford.
Search before posting:)
Join the DataStagers team effort at:
http://www.worldcommunitygrid.org