Do you have to be in a Unix Group to use Windows Datastage?

flashgordon · Post by **flashgordon** » Sat Sep 15, 2007 4:59 pm

Hi,

I know this may be a dumb question but I'm working in a large environment where the Datastage unix admin install group feels they're done, the security group wants to be told what do do, and the Dev group (me and others) has little access to the Sun box to see or repair what might not be working. I can see that the Datastage server is running on the Sun box. When I try to open the Project list in a Datastage 7.5.2 Windows client log on I get a "Server not valid or Datastage not running properly" type error message. The Windows client is running against the Datastage port and doesn't really need a Unix group, right? In most of the environments I have worked in the DS Dev userids are in a group with dsadm but I don't think that's a requirement to use the Windows GUI. The Unix Datastage Install manuals don't talk about having to be in a Unix group to use the GUI. So can you run the Datastage client without being in any particular Unix group? For real sticklers for detail this is actually the Peoplesoft implementation of Datastage as a packaged application. Thanks for any help.

Flash Gordon

chulett · Post by **chulett** » Sat Sep 15, 2007 5:20 pm

Please post the exact error that you receive. Also, does everyone have this issue connecting or are you the only lucky one?

You will need a UNIX id on the DataStage server to authenticate against and there's no such thing as a UNIX id that doesn't belong to any group. Obviously, being in the 'wrong' group can be an issue so it would be best to know the particulars of your ids.

What kind of access do you have to the DataStage server? How can you 'see that the DataStage server is running on the Sun bx'? Have you tried connecting to the Sun box through any kind of terminal emulation, like the freeware putty? Depending on your error, it would be good to be able to verify if DataStage itself is running and the 'dsrpc' daemon is as well for starters.

kduke · Post by **kduke** » Sat Sep 15, 2007 7:19 pm

Typical install on UNIX is by root. The admin user is usually dsadm. dsadm is usually in a group like dstage. All DataStage users should be in the dstage group in not then you need to change permissions in the DSEngine directory. I posted the code a long time ago to make that happen. This does not appear to installed properly or your user id is in the wrong group.

flashgordon · Post by **flashgordon** » Sat Sep 15, 2007 9:05 pm

Hi,

Some of the clarifications that were requested. I am going to throw more fuel in the fire. This is not a vanilla Datastage install. I have been told that the user running the Datastage is something like pssoftds8 not dsadm or root. I am pretty sure it is an SE only install, not a joint EE/SE install in use at many places now. I am not on my work machine right now and am doing this from memory in terms of exact error messages.

PeopleSoft support has told me the error message I was getting is often asscociated with a bad last line in the Universe definition in uvodbc.config.

I am the first person trying to access this Datastage install using Datastage. I have an id with a group that allows me to edit files in my home directory /users/... and not much else. I think I can see the directories where Datastage is installed and I can't even cd into the first level of those directories (permission denied). This id is not a restricted shell and ps -elf|grep ata shows something with Datastage running. The box is a very large, very current Sun box.

A question to kduke. If a Unix user is accessing Datastage through a port why does the group or permissions in .../DSEngine/... matter? The Datastage engine performs functions on behalf of the Unix userid (like saving DS jobs in a .../Project/... directory or whatever). The Unix user is not trying to perform these functions directly themselves.

Thanks to kduke and chulett for responding. I am getting the feeling that Unix security matters for a Unix user using the Windows DS client to connect and that's what I was trying to determine before I go in to try to get some mods to the install to get these things working.

Flash Gordon

chulett · Post by **chulett** » Sat Sep 15, 2007 9:20 pm

In the past you were locked into having 'dsadm' as your admin user and so most people still continue to use it. You are no longer required to use that name, however, so I would guess 'psoftds8' is your equivalent. Think of it as the root or superuser for DataStage.

flashgordon wrote:PeopleSoft support has told me the error message I was getting is often asscociated with a bad last line in the Universe definition in uvodbc.config.

That doesn't make a whole lot of sense to me. ODBC plays no role that I am aware of until you try to connect via the ODBC stage in a job or import metadata via the ODBC plug-in. You can't even get connected.

flashgordon also wrote:If a Unix user is accessing Datastage through a port why does the group or permissions in .../DSEngine/... matter? The Datastage engine performs functions on behalf of the Unix userid (like saving DS jobs in a .../Project/... directory or whatever). The Unix user is not trying to perform these functions directly themselves.

No, all that work is done as the logged in user with all the associated permisssions that user and their group have. If the permissions are wrong all kinds of things, both small and large, can go wrong.

See if this FAQ entry helps at all, if not you then your 'DataStage admin':

viewtopic.php?t=107844

flashgordon · Post by **flashgordon** » Sat Sep 15, 2007 9:35 pm

Criag,

Thanks. The FAQ link was helpful. Clearly Unix secuity matters a lot. This was very helpful, thanks.

... Flash

flashgordon · Post by **flashgordon** » Thu Sep 20, 2007 3:00 pm

Hi,

Just to finish this thread and add some PeopleSoft Datastage knowledge to the site if it isn't already there.

If you get a good Peoplesoft Datastage install and you want to add new development id's they have to be added to this group in /etc/group:

psoftupda::108:psoftprd,psoftup2,psoftupd,jonesj,nixonm

to work properly.

... Tom

chulett · Post by **chulett** » Thu Sep 20, 2007 6:43 pm

Thanks for posting that Flash... err, Tom.

Of course, that the actual group number (108) can be different, it is the group name that would be the important part of all this.