Read only access to Project

vmcburney · Post by **vmcburney** » Tue Aug 11, 2009 8:34 pm

I'm not sure how you prevent someone from running jobs. You might be able to supply access through the Information Server Reporting console and maybe Metadata Workbench. If you can navigate the difficult reporting interface you can set up some reports showing error, warning and log messages across jobs plus you can save HTML job reports that show a picture of the job and the properties of each stage in the job. These get saved into the reporting area. If find it all tricky to use and navigate but you might be able to make something of it.

kduke · Post by **kduke** » Tue Aug 11, 2009 10:50 pm

It can be done. It does not work well in version 7. Not sure about 8. You need write permission to the RT_* files to run a job. Take away write permission for whatever group they are in.

chulett · Post by **chulett** » Tue Aug 11, 2009 11:04 pm

So... to clarify... while you can't stop people from trying to run jobs, you can ensure that the jobs won't run properly if they do? What does actually happen in that case, I'm assuming the job aborts before it gets very far, yes?

kduke · Post by **kduke** » Wed Aug 12, 2009 9:55 am

That is correct. The job aborts. If they try to add a new job or save as on an old job then it leaves the next job number locked. Now nobody can add a job untill this lock is released. Lots of little problems. Same for routines.

sjfearnside · Post by **sjfearnside** » Wed Aug 12, 2009 12:10 pm

You may be able to accomplish that by ensuring they are:
- in a restricted role, say operator for the project and
- assigned to the unix group of others that only has read access.

narayana_382 · Post by **narayana_382** » Wed Aug 12, 2009 3:17 pm

I doubt whether we can restrict any user just to view the director logs and not allowing them to run any job.
Operator user only can reset and run the jobs, but cannot make job changes or compile the objects through the designer.
I dont know if there is a rule or group that is less complicated to that was explained above available in 8.1

mandyli · Post by **mandyli** » Mon Aug 17, 2009 1:34 pm

Thanks for your help.

Let try with sjfearnside option.

Thanks
Man

mandyli · Post by **mandyli** » Wed Aug 19, 2009 8:10 pm

Hi

I have tried different option like sjfearnside option also.

But still I can able to run the job from Datastage director.

Is any other option is there.

Thanks Man

chulett · Post by **chulett** » Wed Aug 19, 2009 8:18 pm

Why, there would still be the kduke option. Similar in taste to the sjfearnside option, but with a tangy twist of lemon.

mandyli · Post by **mandyli** » Thu Aug 20, 2009 10:33 am

Hi chulett

Thanks for your reply. I am not able to follow up kduke reply.

kduke : Can you please help me to understand ?

Thanks
Man

kduke · Post by **kduke** » Thu Aug 20, 2009 12:08 pm

The problems with doing it at the UNIX level is that DataStage does not know it is restricted at the UNIX level so it tries to update a job when it is not possible at the UNIX level. This leaves records locked like the next job number. So project becomes frozen to the real developers. So as long as a restriced user never tries to create a job then you are fine.

Similar things happen when you try to run jobs and your user cannot write to the RT_* files. These processes become blocked at the UNIX level. Some admin has to delete these blocked or frozen processes.

It keeps users from doing things that you do not want them to do but it does not work smoothly. Version 8 created more roles to try to resolve this issue. If you work within the limits of the tool then it runs smoothly. You can trick it into doing something it was not designed to do but there is always a price to pay.

Someone owes me a twist of lemon.

chulett · Post by **chulett** » Thu Aug 20, 2009 1:01 pm

On the way, my friend, on the way.

sjfearnside · Post by **sjfearnside** » Thu Aug 20, 2009 2:01 pm

I just did a test and when the UID was in the role of DS/QS operator and had read only unix rights on either the &PH& folder or the DS_JOB folder and I was not able to execute the job from the client or director. When I added the execute priviledge to the folder it was able to execute the job.

These were the folder under the project. In all cases I was able to abort the job regardless of the rights at the unix level. However, with read only rights to the folder I was not able to reset the job.

My environment may be setup different than yours so I can't guarantee it will work for you but try it if you have a test environment.

P.S. There may be some good reasons you would not want to do that but if a UID is setup for non executable person, just ensure they are not in anything but the "other" group priviledge with read only access.

mandyli · Post by **mandyli** » Thu Aug 20, 2009 2:32 pm

Yes

I am on the way.

Thanks for your inputs. I will try it once again for as per sjfearnside suggestion.

Thanks
Man

mandyli · Post by **mandyli** » Thu Aug 20, 2009 2:34 pm

Hi

Here I have one more question.

How will I make &PH& folder or DS_JOB folder read only for one user(UID).

Thanks
Man