Topic
13 replies Latest Post - ‏2004-06-29T09:05:03Z by SystemAdmin
SystemAdmin
SystemAdmin
7754 Posts
ACCEPTED ANSWER

Pinned topic User permission on Unix

‏2004-06-17T12:19:12Z |
I'm struggling with setting up a 2nd developer on the same project. I have the project permssions set to 775 with dsadm and dstage as the group. I set the umask to 002 and tried changing it to 0002 in the dsenv files in an attempt to fix my problem. The problem happens when user2 runs a job that have hash files with delete and create option. This causes the job to abort because of the permssion on the Hash file directory in the project changes to 755 with dsadm as the owner. I also had to give user2 dba privilage to get him to run these jobs. What is the best way to do this???

error msg in director:
GetLQTablesBatch19902..HashXref2.ToHashXref2: DSD.UVOpen "HashXref2" is already in your VOC file as a file definition record.
File name =
File not created.
.

Any help is highly appreciated.
Thanks,
Nazek
Updated on 2004-06-29T09:05:03Z at 2004-06-29T09:05:03Z by SystemAdmin
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-17T20:22:37Z  in response to SystemAdmin
    Nazek

    Jobs run as phantoms or background processes. The umask is not read from your .profile or /etc/profile. It has to be set in the kernel or in dsenv. You cannot set umask to 0002 but you can set permissions on the project directory to 4770.

    chmod -R 4770 ProjectDir

    This should allow anyone in the group to delete the files created by another user in the dstage group.

    chgrp -R dstage ProjectDir

    This should fix your problem. After you change dsenv then you need to stop and start DataStage.
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-18T08:38:55Z  in response to SystemAdmin
    Kim,

    I tried changing the permssion on the project to 4770 like you mentioned, but it still changed the permssions on the Hash file directory to 700 after running the job as dsadm/owner. I also set the umask in dsenv to 3007 to match the chmod 4770 and stoped and start DataStage before running the job.

    Anything else that I should try?
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-18T10:38:11Z  in response to SystemAdmin
    umask only takes 3 numbers. I am sure it is not working. You could write a job to check. In the control code:

    cmd = "SH -c umask"
    DSLogInfo(cmd, "Job control")
    execute cmd capturing output
    DSLogInfo(output, "Job control")

    Compile and run this job. You may need to put the full path on umask like /bin/umask.

    The way umask with UNIX works is it only puts execute permission on directories created. Anyway

    umask 002

    or

    umask 007

    Is what you want. The default in your UNIX is probably 022.
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-18T11:40:04Z  in response to SystemAdmin
    I thought umask had to be set in the ds.rc file (DSEngine/sample/ds.rc).
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-18T12:23:52Z  in response to SystemAdmin
    I had to set umask in both the ds.rc and the dsenv files to avoid a bug with recurring scheduled jobs on v6.0.1. I don't know if v7 has the same issues or not (HP-UX, server job)

    Tony
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-18T18:10:05Z  in response to SystemAdmin
    You should not have to do that. The dsenv file should effect all DataStage jobs even ones in the scheduler. If not then I have never seen or heard of this problem. Maybe Ray has.
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-19T19:53:39Z  in response to SystemAdmin
    Haven't seen it, but I work with very few HP-UX servers. It's these that also had the initial Mutex lock issues, and it's also these that blew almost everyone out of the water by changing the location of the system libraries in HP-UX 11.

    I've never had a problem with umask that needed a umask setting in ds.rc (or even uv.rc). Setting it in dsenv has been sufficient. Then again, I've not had any client using cron for recurring scheduled jobs; my "best practice" is to implement this with DataStage job control that is scheduled to run once per day.
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-19T21:44:27Z  in response to SystemAdmin
    I had to set umask in both the ds.rc and the dsenv files to avoid a bug with recurring scheduled jobs on v6.0.1. I don't know if v7 has the same issues or not (HP-UX, server job)[/quote:37bbbc8e71]
    Tony - what bug exactly? We use Control-M for the vast majority of our scheduling, but some still runs thru cron and it is invariably of the recurring type. I've seen no bugs from it, or at least none I've noticed. HP/UX, both 6.x and 7.x server jobs, hence the question.

    -craig
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-21T09:35:04Z  in response to SystemAdmin
    The version 6 installation instructions indicates that umask should only be set in the ds.rc file and not in dsenv. My experience with a recent Datastage install confirms that umask in dsenv does not work for all case. I would recommend you check the iniittab for the location of the ds.rc file that is being used. I'm also assuming that you've restarted the server daemon so your changes will take affect.
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-21T11:45:33Z  in response to SystemAdmin
    Thank you all for your comments.

    Actually the dsenv umask does not work. Support said this changed since version 6, they moved it to ds.rc file and I had to stop and start UV to apply the changes. This worked! I haven't tested the scheduler yet, I will try it to make sure it works too after moving the umask to ds.rc file ( I'm working on 7.1 upgrade having 6.1 in production). I think they need to add this information to the Unix documentation of how to set up new groups/users to projects.
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-28T11:43:38Z  in response to SystemAdmin
    quote:61da5a8098Tony - what bug exactly? We use Control-M for the vast majority of our scheduling, but some still runs thru cron and it is invariably of the recurring type. I've seen no bugs from it, or at least none I've noticed. HP/UX, both 6.x and 7.x server jobs, hence the question.
    [/quote:61da5a8098]

    We had a problem with permissions of hash files and other files created by DataStage jobs. But only if the job was scheduled as a recurring job through the scheduler (i.e. cron). If the job was run manually, or scheduled as a one time job in the scheduler(i.e. at command), it would work correctly. The support engineer that I was working with was able to duplicate this on their systems. This occurred on v6.0.1. I haven't tried it on v7.1.0 yet. When we did a umask command it reported '02' when we ran the job manually or as a one time job in the scheduler. It reported '022' when we ran the job as a recurring job in the scheduler. We had the umask command in the ds.rc file and had to add it to the dsenv file to resolve this issue.

    Craig,
    You may not have seen this, if you already had the umask in the dsenv, as it was before v6 (as others have already stated).

    Tony
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-28T21:50:00Z  in response to SystemAdmin
    Hey Tony - thanks for the clarification! For all I know we've got the same issue (don't think so) but we run all of our jobs under a single userid to hopefully avoid issues like this.

    Take it easy,

    -craig
  • SystemAdmin
    SystemAdmin
    7754 Posts
    ACCEPTED ANSWER

    Re: User permission on Unix

    ‏2004-06-29T09:05:03Z  in response to SystemAdmin
    quote:318d86a2cb...but we run all of our jobs under a single userid to hopefully avoid issues like this...[/quote:318d86a2cb]

    Yeah, we normally do too, Craig. We ran into issues when we had a job fail and the developer was trying to troubleshoot or re-run the job.

    You could tell that the support engineer thought I was looney when I told her how to duplicate it. My reputation was redeemed once she duplicated it on their hardware. :)

    Tony