DSXchange

Can someone tell me - is the umask hardcoded in Quality Stage? Better yet, how can I change the umask from 022 to 002???

Thanks
Jennifer

QualityStage have nothing to do with the way you set the umask. It is your qsadm account (and the system's global configuration) that determines the umask. Check out how your configurations are set up, and contact your system administrator (You need to specify which shell and which UNIX box you are using so our answers can be more accurate) to determine how their FTP clients and global settings are set as for file uploads and creations.

I've checked all the .profile(s) I can think of and they all have the umask set to 002. Including the qsadm user, my personal .profile, the "group" .profile, etc.

Let me tell you a little more about what is happening:

When creating files/directories under my own id in any other environment/tool, this is how it appears:

[code]drwxrwxr-x 2 jjradnic dstage 8192 Nov 29 09:17 JJRTEST1129[/code]

NOW, when I initially "deploy" a QualityStage job using my own id the "deployment" creates any directories that don't already exist - BUT it creates them with qsadm as the owner (not my id) AND it creates them with the permissions as set forth by a umask 022 (drwxr-xr-x). This is one example:

[code]drwxr-xr-x 2 qsadm dstage 8192 Nov 22 10:47 Logs[/code]

Then the deployment fails as it attempts to move files to those newly created directories because the "group" (which would include my id - under which the deployment is running) does not have "write" permissions to that directory.

Oddly enough, if I deploy a job using the qsadm id any directories that do not exist are created with qsadm as the owner BUT with the correct permissions:
[code]drwxrwxr-x 2 qsadm dstage 8192 Nov 22 10:47 Data[/code]

Still with me?

What we're trying to figure out is:
1. how/why are the directories being created with qsadm as the owner when the job is being run under a different id?

2. even with qsadm as the owner, with the qsadm user .profile set to umask 002, why are these directories being created with permissions of drwxr-xr-x???

For what it's worth, we are running on Unix Tru64.
Any suggestions or ideas?

I am seeing the same behaviour on AIX 5.2, but investigating it is way down on my list of priorities at the moment, with a major deadline looming in the project.

*sigh* I wish I could help you further, but I am afraid that any further suggestions would be talking out of my butt.

It sounds like a remote shell (RSH) privs issue. But I do not know exactly how QualityStage 'deploy' everything (I thought it was SFTP at first, but was wrong on that...)

I'll poke around with some of my friends and see what they know about deployment tools used by QS.

P.S. Why is it created with qsadm user ownership? Because the server is running under QSADM, most likely. But I do not know exactly what they are trying to do under the hood with different users within the dstage group.

The server process (qsserv) are geared for automatic startup, so are forked by the init process (pid 1), which runs as root. Chances are that the root umask is being propagated.

Need to investigate where qsserv or qsadm umask can be changed. The ipe.env.sh file in the $QSHOME/Projects/projname directory looks like a promising candidate.

Ray suggested:
[quote]The ipe.env.sh file in the $QSHOME/Projects/projname directory looks like a promising candidate.[/quote]

I checked the ipe.env.sh file for several different projects and the umask is NOT set in that file...not from what I can tell anyway. I've got our "superuser" checking out the "root" umask setting.

Thanks for the continued help!

Jennifer

Normally umask are not set. But maybe it will actually work if you declare umask there, overriding what root have?

This would be a good compenstation for having root do 775 chmod all the time.

T42 -
I don't think defaulting EVERYTHING to chmod 775 is a good idea. I've seen huge Data Warehousing projects do exactly that and then end up being audited. Auditors tend to raise a huge stink about a chmod 775 on ALL files. If you think about it, does "OTHER" really need to "WRITE" and or "EXECUTE" ALL files. Some files - sure, but certainly not all of them. This is potentially a HUGE security issue.

That's just been my experience - I'm not saying it is right for everybody. I'm just suggesting that caution and a thoughtful process should be used when setting permissions on files and directories.

Jennifer

I agree. I am just trying to find a way to allow things to work for you without too much of a pain.

It's a pain when Ascential wrap everything within a single structure -- logs, files, source code, et cetera. That's why we do convulted stuff such as Version Control to handle migration and control of the projects.

Project folders should not be all-encompassing, imho.

Any luck so far getting this fixed?

Greetings!!
After two days of literally stepping through every little thing that happens once I hit the "Run from Start To Finish" button to deploy a job I believe we've finally found our answer. Here is the explanation as described to me by my systems admin:

The qsserv process creates all project directories via 'mkdir -p' in the QualityStage/bin/script_mkproj shell script. This means that no matter who you're running a "deployment" as, the directories will inherit the owner, group, and permissions from the qsserv process. The installation documentation doesn't make it clear that the umask of the process which fires off qsserv will be blindy taken and used by qsserv. This may result in strange and inconsistent directory permissions. I recommend explicitly calling 'umask' before firing off qsserv to make sure you'll get the directory permissions you want.

Ftp is used to transfer the files -- so ownership and group are inherited from the user that performs the deployment. Ftpd manages the permissions for security reasons, and can usually only be overridden in the call to ftpd (in /etc/inetd.conf usually). In Tru64, I needed to make sure the ftpd call had '-u 770' to allow for group writability upon creating new files.

We are now running flawlessly with no further issues in relation to how permissions are being set! Thanks for all your help! Have a Great Weekend!!

Jennifer